Les meilleures pratiques pour conserver les mots de passe dans des scripts shell / Perl?

Question

J'ai récemment dû épousseter mes compétences en script Perl et shell pour aider certains collègues. Les collègues en question ont été chargés de fournir des rapports à partir d’une application interne dotée d’un backend de base de données Oracle volumineux, mais ils n’ont tout simplement pas les compétences pour le faire. Alors que certains pourraient se demander si j’ai ces compétences (sourire), apparemment, assez de gens pensent que c’est le cas, ce qui veut dire que je ne peux pas m'en sortir.

Donc, pour ma question - pour extraire les rapports de la base de données, mon script doit évidemment se connecter et exécuter des requêtes. Jusqu'à présent, je n'ai pas réussi à trouver une bonne solution pour stocker le nom d'utilisateur et le mot de passe de la base de données, de sorte qu'ils sont actuellement stockés en texte clair dans le script.

Existe-t-il une bonne solution que quelqu'un d'autre a déjà écrite, peut-être sous forme de module CPAN? Ou encore, y a-t-il autre chose de mieux à faire - comme garder la combinaison utilisateur / mot de passe dans un fichier complètement séparé qui est caché ailleurs dans le système de fichiers? Ou devrais-je les garder trivialement cryptés pour éviter qu'ils ne soient extraits de mes scripts avec un grep à l'échelle du système?

Modifier: La base de données Oracle repose sur un serveur HP-UX.
Le serveur d'applications (exécutant les scripts shell) est Solaris.
Définir que les scripts ne doivent appartenir qu'à moi est illimité, ils doivent appartenir à un compte de service auquel plusieurs membres du personnel de support ont accès.
Les scripts sont destinés à être exécutés en tant que tâches cron.
J'aimerais bien utiliser l'authentification par clé publique, mais je ne connais pas les méthodes pour que cela fonctionne avec Oracle. S'il existe une telle méthode, éclairez-moi!

Answer 1

La meilleure pratique, à mon humble avis, serait de ne PAS contenir de mot de passe dans un script shell / Perl. C'est à cela que sert l'authentification par clé publique.

Answer 2

Si le script s'exécute à distance depuis le serveur.

1. Créer des vues de vos rapports
2. Donnez à l'utilisateur auquel vous vous connectez un accès UNIQUEMENT à sélectionner dans les vues de rapport
3. Enregistrez simplement le mot de passe.

Ainsi, tout ce que l’utilisateur peut faire est de sélectionner les données de son rapport. Même si quelqu'un obtenait le mot de passe, il serait limité à ce qu'il pourrait en faire.

Answer 3

Personnellement, je conserve les mots de passe dans des fichiers de configuration qui sont ensuite distribués indépendamment de l'application et peuvent être modifiés pour une machine / un environnement spécifique. Dans les scripts de shell, vous pouvez les rechercher dans le script principal.

Cependant, Perl propose diverses approches. Vous voudrez peut-être examiner Getopt :: Long pour les options de ligne de commande (et en outre < a href = "http://search.cpan.org/perldoc?Getopt::ArgvFile" rel = "nofollow noreferrer"> Getopt :: ArgvFile pour les stocker dans un simple fichier de configuration), ou regarder quelque chose comme Config :: IniFiles pour quelque chose avec un peu plus de pouvoir derrière. C’est les deux types que j’utilise généralement, mais d’autres modules de fichiers de configuration sont disponibles.

Answer 4

Il n'y a pas de bonne solution. Vous pouvez un peu masquer les mots de passe, mais vous ne pouvez pas les sécuriser.

Si vous avez le contrôle sur votre configuration de base de données, vous pouvez essayer de vous connecter par un canal nommé (au moins, mysql le supporte) sans mot de passe et laisser le système d'exploitation gérer les autorisations.

Vous pouvez également stocker les informations d'identification dans un fichier avec des autorisations restrictives.

Answer 5

Depuis que vous avez tagué ksh & amp; bash je vais assumer Linux.

Le problème est que si l'utilisateur peut lire le script et localiser la méthode utilisée pour masquer / chiffrer le fichier, il sera également en mesure de faire la même chose manuellement.

Une meilleure solution consiste peut-être à:

1. Créez votre script pour qu'il ne puisse être vu / lu / ouvert que par vous. chmod 700 it. Les mots de passe hardcode sont absents.
2. Avoir un "lanceur" " script exécutable par l'utilisateur et faisant un sudo.

Ainsi, l'utilisateur peut voir votre script de lancement, l'examiner pour voir s'il ne comporte qu'une seule ligne de commande. Ils peuvent l'exécuter et cela fonctionne, mais ils ne disposent pas des autorisations nécessaires pour lire le code source du script mentionné.

Answer 6

Je ne suis pas sûr de la version d'Oracle que vous utilisez. Sur les versions antérieures d’Oracle (version de sécurité avancée antérieure à 9i), certains administrateurs de base de données auraient CREER UN UTILISATEUR $ SCOTT IDENTIFIÉ PAR EXTERNALY et définir REMOTE_OS_AUTHENT sur true.

Cela signifie que votre machine Sun distante pourrait vous authentifier en tant que SCOTT, puis que votre base de données Oracle accepterait cette authentification.

C'est une mauvaise idée.

Comme vous pouvez créer une image, tout Windows XP avec un utilisateur local de SCOTT peut ensuite se connecter à votre base de données sans mot de passe.

Malheureusement, c’est la seule option que je connaisse des bases de données Oracle 9i pour ne pas stocker le nom d’utilisateur / mot de passe dans votre script ou dans un endroit accessible par la machine cliente.

Quelle que soit votre solution, il vaut la peine de consulter le Verrouillage du projet avant de valider.

Answer 7

Pour stocker les mots de passe, vous pouvez effectuer une procédure de cryptage en deux étapes, d’abord avec une clé codée dans votre script lui-même, et éventuellement une deuxième fois avec une clé stockée dans un fichier (défini à l’aide des autorisations de fichier permettant un accès restreint).

Dans une situation donnée, vous pouvez ensuite utiliser un fichier de clé (+ clé du script) ou, si les exigences de la situation ne sont pas si grandes, il peut simplement utiliser le cryptage à l'aide de la clé est codée en dur dans le script. Dans les deux cas, le mot de passe serait crypté dans le fichier de configuration.

Il n’existe pas de solution parfaite, car vous devez être en mesure de décrypter et d’obtenir le mot de passe en clair ... et si vous pouvez le faire, quelqu'un d’autre peut le faire aussi, s’il dispose des bonnes informations.

Surtout dans la situation où nous leur donnons un script Perl (contre un exe), ils peuvent facilement voir comment vous utilisez le chiffrement (et la clé codée en dur) ... c'est pourquoi vous devriez autoriser l'option d'utiliser un fichier de clé. (qui peut être protégé par des autorisations de système de fichiers) également.

Quelques exemples pratiques de mise en œuvre sont ici

Answer 8

Sous UNIX, je mets toujours ces scripts à jour et stocke les informations de l'utilisateur et du mot de passe dans un fichier fortement protégé (l'arborescence de répertoires est illisible / consultable par les utilisateurs habituels et le fichier lui-même n'est lisible que par le propriétaire de le script).

Answer 9

Conservez-les dans un fichier séparé, crypté de manière triviale, et créez un utilisateur distinct dans la base de données avec un accès en lecture seule aux tables nécessaires. Si vous pensez que le fichier a été lu, vous pouvez désactiver l'accès à cet utilisateur uniquement.

Si vous voulez avoir l’imagination, un programme SUID peut vérifier les fichiers / proc // exe et cmdline (sous Linux), puis publier le nom d’utilisateur.

Answer 10

J'ai eu / avais un problème similaire avec les développeurs qui déployaient du code SQL sur MSSQL (en fait sur n'importe quelle base de données sur ce serveur MSSQL, le rôle devait donc être SysAdmin) en utilisant ANT à partir d'un serveur Solaris. Encore une fois, je ne voulais pas stocker le nom d'utilisateur et le mot de passe dans les fichiers ANT build.xml, ma solution, qui, je le sais, n'est pas idéale, est la suivante:

1. Stocke les paires nom / valeur pour le nom d'utilisateur et le mot de passe dans un fichier texte brut
2. Cryptez le fichier (sous Solaris) et utilisez une phrase secrète connue de certains administrateurs uniquement
3. Ne laissez que le fichier chiffré sur le système Solaris
4. ANT build.xml exécute un déchiffrement sudo et demande une phrase de passe, qui est entrée par l'administrateur
5. Le nom d'utilisateur et le mot de passe de chargement du fichier déchiffré par les sources ANT sont des variables de la chaîne SQL
6. ANT a immédiatement supprimé le fichier de texte en clair
7. ANT déploie le code et quitte

Tout cela se fait en quelques secondes et le nom d'utilisateur et le mot de passe SQL ne sont jamais visiblement accessibles sur le serveur. Le code étant déployé par les administrateurs autorisés en production, les développeurs n'ont jamais besoin de l'inclure dans leur code.

Je suis sûr que cela pourrait être mieux, mais ...

JB

Answer 11

Dommage que je n’aie jamais vu ce fil auparavant - cela semble très intéressant. J'ajouterai mes deux sous à quiconque viendra sur le fil à l'avenir.

Je recommanderais d'utiliser l'authentification du système d'exploitation sur le serveur de base de données lui-même - REMOTE_OS_AUTHENT est toujours FALSE.

Si vous appelez le script depuis une autre machine, configurez une clé SSH sans expression et utilisez SSH pour y accéder. Vous pouvez ensuite rediriger les résultats SQL vers la machine appelante, qui pourra ensuite traiter ces informations.

Cela évite de coder un mot de passe n'importe où. Bien sûr, si un administrateur malveillant piratait la clé sans expression et l’utilisait, il pourrait également accéder au compte utilisateur de l’hôte de la base de données et effectuer ensuite toutes les opérations que l’utilisateur authentifié par le système d’exploitation. Pour atténuer cela, vous pouvez réduire au minimum les autorisations de la base de données pour cet utilisateur de système d'exploitation - disons "lecture seule".

Ingo

Answer 12

  

Sous Windows, créez un dossier et un fichier contenant les mots de passe en texte clair.   Définissez l'utilisateur qui exécuterait le travail planifié (script ou traitement par lots) comme la seule personne disposant d'un accès en lecture / écriture à ce dossier et à ce fichier. (supprimer même administrateur).   Pour tous les autres scripts, ajoutez du code pour lire le mot de passe en texte clair à partir de ce fichier restreint.

Cela devrait suffire à quelques-uns.

Mots clés: Password HardCoding

Answer 13

Il existe des solutions commerciales ou plus avancées telles que cyberark AIM peut le faire mieux, mais en le faisant gratuitement et sans configuration, j'ai récupéré la clé publique / privée SSH, car l'une de ces paires de clés SSH est probablement déjà créé conforme à la politique de sécurité; deuxièmement, les paires de clés SSH possèdent déjà un ensemble de protocoles standard pour protéger les clés par l’autorisation de fichier, le renforcement continu du système (comme tripwire) ou la rotation de clé.

Voici comment je l'ai fait:

1. Générez les paires de clés ssh si ce n'est pas encore le cas. Les paires de clés et le répertoire seront protégés par le protocole / autorisation système par défaut. ssh-keygen & # 8211; t rsa & # 8211; b 2048

2. utilise la clé publique ssh pour chiffrer la chaîne et stockée dans le même répertoire .ssh $ echo " secretword " | openssl rsautl -encrypt -inkey ~ / .ssh / id_rsa.pub -pubin -out ~ / .ssh / secret.dat

3. utilisez la clé privée ssh pour déchiffrer la clé et transmettez les paramètres aux scripts / AP en temps réel. Le script / programme pour inclure la ligne à déchiffrer en temps réel: string = openssl rsautl -decrypt -inkey ~ / .ssh / id_rsa -in ~ / .ssh / secret.dat

PS - J'ai expérimenté la solution sans agent CYBERARK AIM. c'est un peu pénible qui nécessite d'importants changements / changements d'API pour l'API / script. vous tiendrons au courant comment ça se passe.