Comment puis-je masquer un mot de passe dans les scripts shell ? Il existe un certain nombre de scripts qui accèdent à la base de données. Si nous ouvrons le script, les autres connaissent également le nom d'utilisateur et le mot de passe. Donc, si quelqu'un sait comment se cacher, faites-le moi savoir.
J'ai un moyen :placez le mot de passe dans un fichier et rendez le fichier masqué et personne n'y accédera (modifiez les autorisations et utilisez le fichier dans le script tout en accédant à la base de données).
Réponse acceptée :
Premier , comme plusieurs personnes l'ont déjà dit, il est essentiel de séparer les informations d'identification du script. (En plus d'une sécurité accrue, cela signifie également que vous pouvez réutiliser le même script pour plusieurs systèmes avec des informations d'identification différentes.)
Deuxième , vous devez tenir compte non seulement de la sécurité des informations d'identification, mais également de l'impact si/lorsque ces informations d'identification sont compromises. Vous ne devriez pas avoir un seul mot de passe pour tous les accès à la base de données, vous devriez avoir différentes informations d'identification avec différents niveaux d'accès. Vous pourriez, par exemple, avoir un utilisateur DB qui a la capacité d'effectuer une recherche dans la base de données - cet utilisateur devrait avoir un accès en lecture seule. Un autre utilisateur peut être autorisé à insérer de nouveaux enregistrements, mais pas à les supprimer. Un troisième peut être autorisé à supprimer des enregistrements.
En plus de restreindre les autorisations pour chaque compte, vous devez également avoir des restrictions sur l'endroit où chaque compte peut être utilisé. Par exemple, le compte utilisé par votre serveur Web ne doit pas être autorisé à se connecter à partir d'une autre adresse IP que celle du serveur Web. Un compte avec des autorisations root complètes sur la base de données doit être très restreint en termes d'où il peut se connecter et ne doit jamais être utilisé autrement qu'interactivement. Envisagez également d'utiliser des procédures stockées dans la base de données pour restreindre exactement ce qui peut être fait par chaque compte.
Ces restrictions doivent être implémentées du côté serveur de base de données du système afin que même si le côté client est compromis, les restrictions ne peuvent pas en être modifiées. (Et, évidemment, le serveur de base de données doit être protégé par des pare-feu, etc. en plus de la configuration de la base de données…)
Dans le cas d'un compte de base de données qui n'est autorisé qu'à un accès limité en lecture seule, et uniquement à partir d'une adresse IP particulière, vous n'aurez peut-être pas besoin d'informations d'identification supplémentaires, en fonction de la sensibilité des données et de la sécurité de l'hôte. le script est en cours d'exécution. Un exemple peut être un formulaire de recherche sur votre site Web, qui peut être exécuté avec un utilisateur uniquement autorisé à utiliser une procédure stockée qui extrait uniquement les informations qui seront présentées sur la page Web. Dans ce cas, l'ajout d'un mot de passe ne confère pas vraiment de sécurité supplémentaire, puisque cette information est déjà destinée à être publique et que l'utilisateur ne peut accéder à aucune autre donnée qui serait plus sensible.
Assurez-vous également que la connexion à la base de données est établie à l'aide de TLS, sinon toute personne qui écoute sur le réseau peut obtenir vos informations d'identification.
Troisième , réfléchissez au type d'informations d'identification à utiliser. Les mots de passe ne sont qu'une forme, et non la plus sécurisée. Vous pouvez à la place utiliser une forme de paire de clés publique/privée, ou AD/PAM ou similaire.
Quatrième , tenez compte des conditions dans lesquelles le script sera exécuté :
Connexe :code source de netstat ?S'il est exécuté de manière interactive, vous devez entrer le mot de passe, ou le mot de passe de la clé privée, ou la clé privée, ou être connecté avec un ticket Kerberos valide, lorsque vous l'exécutez - en d'autres termes, le script doit obtenir son informations d'identification directement auprès de vous au moment où vous l'exécutez, au lieu de les lire à partir d'un fichier.
S'il est exécuté à partir d'un serveur Web, envisagez de configurer les informations d'identification au moment où vous démarrez le serveur Web. Un bon exemple ici est celui des certificats SSL - ils ont un certificat public et une clé privée, et la clé privée a un mot de passe. Vous pouvez stocker la clé privée sur le serveur Web, mais vous devez toujours saisir le mot de passe lorsque vous démarrez Apache. Vous pouvez également disposer des informations d'identification sur un type de matériel, tel qu'une carte physique ou un HSM, qui peut être supprimé ou verrouillé une fois le serveur démarré. (Bien sûr, l'inconvénient de cette méthode est que le serveur ne peut pas redémarrer tout seul si quelque chose se passe. Je préférerais cela au risque d'avoir mon système compromis, mais votre kilométrage peut varier...)
Si le script est exécuté à partir de cron, c'est la partie la plus difficile. Vous ne voulez pas que les informations d'identification traînent n'importe où sur votre système où quelqu'un peut y accéder - mais vous voulez qu'elles traînent pour que votre script puisse y accéder, n'est-ce pas ? Eh bien, pas tout à fait raison. Considérez exactement ce que fait le script. De quelles autorisations a-t-il besoin sur la base de données ? Peut-il être restreint afin que peu importe si la mauvaise personne se connecte avec ces autorisations ? Pouvez-vous plutôt exécuter le script directement sur le serveur de base de données auquel personne d'autre n'a accès, au lieu du serveur qui a d'autres utilisateurs ? Si, pour une raison à laquelle je ne peux pas penser, vous devez absolument avoir le script en cours d'exécution sur un serveur non sécurisé et il doit être capable de faire quelque chose de dangereux/destructeur… c'est le bon moment pour repenser votre architecture.
Cinquième , si vous tenez à la sécurité de votre base de données, vous ne devez pas exécuter ces scripts sur des serveurs auxquels d'autres personnes ont accès. Si quelqu'un est connecté à votre système, il le fera avoir la possibilité d'obtenir vos informations d'identification. Par exemple, dans le cas d'un serveur Web avec un certificat SSL, il existe au moins une possibilité théorique que quelqu'un puisse accéder à la racine et accéder à la zone mémoire du processus httpd et extraire les informations d'identification. Il y a eu au moins un exploit ces derniers temps où cela pouvait être fait via SSL, sans même exiger que l'attaquant soit connecté.
Envisagez également d'utiliser SELinux ou AppArmor ou tout ce qui est disponible pour votre système pour restreindre les utilisateurs qui peuvent faire quoi. Ils vous permettront d'empêcher les utilisateurs d'essayer de se connecter à la base de données, même s'ils parviennent à accéder aux informations d'identification.
Si tout cela vous semble exagéré , et vous ne pouvez pas vous permettre ou n'avez pas le temps de le faire - alors, à mon avis (arrogant et élitiste), vous ne devriez rien stocker d'important ou de sensible dans votre base de données. Et si vous ne stockez rien d'important ou de sensible, l'endroit où vous stockez vos informations d'identification n'a pas non plus d'importance. Dans ce cas, pourquoi utiliser un mot de passe ?
Connexe :générer quatre mots aléatoires à partir d'une liste pour les mots de passe de type XKCD ?Enfin , si vous ne pouvez absolument pas éviter de stocker certains types d'informations d'identification, vous pouvez avoir les informations d'identification en lecture seule et détenues par root et root peut accorder la propriété sur une base extrêmement temporaire lorsqu'un script le demande (car votre script doit pas être exécuté en tant que root sauf en cas d'absolue nécessité, et la connexion à une base de données ne la rend pas nécessaire). Mais ce n'est toujours pas une bonne idée.