Comment éviter de stocker des mots de passe dans le contrôle de version?

Question

Quelle stratégie utilisez-vous pour éviter de stocker des mots de passe dans le contrôle de version?

Actuellement, les mots de passe de développement / test / production sont enregistrés dans trois fichiers différents et le fichier approprié est utilisé lors du déploiement. Tout cela est consacré au contrôle de version, mais je ne suis pas très heureux avec cela, car tous les développeurs n'ont pas besoin de connaître ces mots de passe (en particulier les mots de passe externalisés, qui n'ont accès que jusqu'à la fin de leurs projets, ce qui pourrait ne prendre qu'un mois).

Stocker des mots de passe dans la base de données n’est pas une bonne option:

• J'ai besoin de la plupart des données lors de l'initialisation du contexte Spring (application Java) et je ne souhaite pas créer d'échafaudage pour la connexion à une base de données unique, puis la connexion au reste des bases de données et l'initialisation du reste de l'application.
• certains mots de passe sont uniquement liés au déploiement; mot de passe pour accéder à différents serveurs, magasins de clés, etc. ce sont les choses que l'application ne peut pas charger après son démarrage, car elle ne le charge pas du tout

Je songe à déplacer la configuration de déploiement de la machine de développeur vers un ordinateur dédié qui extrait le code du contrôle de version et exécute le script de génération / déploiement, mais je ne suis pas vraiment sûr du meilleur moyen de le faire.

Je dois aussi dire que je ne veux pas de sécurité ultime: je veux juste éviter d'avoir des mots de passe sur le disque de chaque développeur et les rendre trop faciles.

Je vous demande donc vos expériences / meilleures pratiques. Comment faites-vous cela?

Answer 1

Propriétés de configuration spécifiques à l'environnement J'ai tendance à insérer, par exemple, un fichier de propriétés qui ne fait pas partie du contrôle de source et ne fait pas partie du processus de construction. Lors de la configuration d'un nouvel environnement, une partie de cette configuration consiste à créer ce fichier de propriétés qui comprend des éléments tels que les adresses de base de données, les informations d'identification et les noms, les noms des hôtes distants pertinents, etc.

.

Au printemps, vous utilisez le PropertyPlaceholderConfigurer pour charger le fichier de propriétés. Spring doit le trouver, ce qui signifie généralement que vous devez le placer dans un répertoire approprié sous le serveur d'applications.

Sinon, vous utilisez wrapper pour exécuter le serveur d'applications et le démarrage de la machine virtuelle Java. Les options incluent l’ajout de ces fichiers de propriétés au chemin de classe afin que Spring puisse les trouver.

Answer 2

J'ai vu deux approches pour cela:

• Déplacez les mots de passe dans un autre arbre de contrôle de code source auquel les développeurs n'ont pas accès.
• Ne mettez aucun mot de passe dans le contrôle de source, et le responsable de la génération dédié doit taper les mots de passe chaque fois qu'un déploiement est effectué. C’était dans une banque où il y avait un gars à plein temps qui travaillait sur les processus de construction / fusion / rejets.

Answer 3

Cela ne fonctionne pas dans tous les cas, mais c’est la raison pour laquelle l’utilisation glorieuse de NT AUTHORITY \ NETWORK SERVICE comme identité de vos services entre en jeu. Si vous utilisez cette identité, vous n'avez pas besoin de conserver un mot de passe pour. it - vous pouvez simplement utiliser les informations d'identification AD de l'ordinateur sous la forme DOMAINNAME \ MACHINENAME $ pour accéder au réseau et à la base de données protégés.

Il y a, bien sûr, des éléments clés à surveiller. Le plus important est que deux applications partageant une frontière de sécurité ne sont pas hébergées de la même manière sur le même serveur.

Answer 4

Placez les mots de passe dans les variables d’environnement utilisateur o / s.

Seul cet utilisateur ou cette racine peut lire la valeur, de la même manière qu'un fichier, mais avec zéro chance qu'elle soit archivée dans le contrôle de source.

Answer 5

Je pense qu'il est bon d'avoir un paramètre de local en dehors du référentiel.

https://stackoverflow.com/a/21570849/1675586

Answer 6

Au lieu de ne pas les stocker, vous pouvez les stocker sous forme cryptée. Vous n'avez donc pas la peine d'envoyer des fichiers d'informations d'identification par messagerie instantanée ou par e-mail tout le temps qu'un nouveau développeur commence ... Il vous suffit de leur indiquer le mot de passe principal spécifique au projet afin qu'ils puissent chiffrer les informations d'identification.