La façon dont je le vois, ne pas stocker les mots de passe dans Git (ou autre contrôle de version) est une convention . Je suppose que l'on pourrait décider de ne pas l'appliquer avec divers résultats, mais voici pourquoi cela est généralement mal vu:

1. Git rend douloureux la suppression des mots de passe de l'historique du code source, ce qui pourrait donner aux gens un faux idée que le mot de passe a déjà été supprimé dans la version actuelle.
2. En plaçant le mot de passe dans le contrôle de code source, vous décidez essentiellement de partager le mot de passe avec toute personne ayant accès au référentiel, y compris les futurs utilisateurs. Cela complique l'établissement de rôles au sein d'une équipe de développeurs, qui peut avoir des privilèges différents.
3. Les logiciels de contrôle de source ont tendance à devenir assez compliqués, en particulier les systèmes «tout-en-un». Cela signifie qu'il y a un risque que ce système soit éventuellement compromis, entraînant une fuite de mot de passe.
4. D'autres développeurs peuvent ne pas savoir que le mot de passe est stocké et peuvent mal gérer le référentiel - avoir des clés dans la source signifie une attention particulière devrait être pris lors du partage du code (même au sein de l'entreprise; cela pourrait créer un besoin de canaux cryptés).

Je ne peux pas dire que chaque modèle lié à infosec est bon, mais avant de les casser, il est toujours judicieux de prendre en compte votre modèle de menace et les vecteurs d'attaque. Si ce mot de passe particulier était divulgué, dans quelle mesure serait-il difficile pour un attaquant de l'utiliser pour nuire à l'entreprise?

Premièrement, la raison non liée à la sécurité:

Workflow de changement de mot de passe

Les mots de passe changent indépendamment du code d'une application logicielle. Si un DBA modifie un mot de passe de base de données, est-il logique que les développeurs doivent mettre à jour le code, obtenir une nouvelle version et une nouvelle mise en production, et essayer de tout chronométrer? Les mots de passe sont un artefact de configuration d'exécution, pas un artefact de développement. Ils doivent être injectés via des fichiers de configuration, des variables d'environnement ou tout autre paradigme de configuration que vous utilisez.

Portée d'autorisation

En général, les systèmes de contrôle de version fournissent un contrôle d'autorisation ainsi seuls les utilisateurs autorisés peuvent y accéder. Mais dans un référentiel, les autorisations sont généralement soit en lecture / écriture, soit en lecture seule, ou peut-être quelques cloches et sifflets comme GitHub fournit. Il est peu probable que vous trouviez des contraintes de sécurité permettant aux développeurs d'obtenir le code source, mais pas des mots de passe. Si vous pouvez cloner un dépôt, vous pouvez cloner un dépôt. Période. Dans de nombreux environnements, les développeurs n'ont pas un accès complet à la production. Parfois, ils ont un accès en lecture seule aux bases de données de production, parfois aucun accès. Que faire si les développeurs ont généralement accès, mais que vous ne voulez pas que tous les stagiaires, les nouvelles recrues, etc. y aient accès?

Environnements

Que faire si vous disposez de plusieurs environnements, comme un environnement de développement, un environnement QA, une mise en scène et une production? Stockeriez-vous tous leurs mots de passe dans le contrôle de version? Comment l'application saurait-elle laquelle utiliser? L'application devrait avoir un moyen de connaître l'environnement, ce qui finirait par être un paramètre de configuration. Si vous pouvez faire du nom d'environnement un paramètre de configuration, vous pouvez faire du mot de passe de la base de données un paramètre de configuration (avec la chaîne de connexion, le nom d'utilisateur, etc.)

Historique

Comme d'autres l'ont mentionné, le contrôle de version est conçu pour préserver l'historique. Les anciens mots de passe seront donc toujours récupérables, ce qui n'est peut-être pas la meilleure chose à faire.

Combien de fois avons-nous vu des manchettes dans les actualités sur le code source d'un produit divulgué dans le monde? Le code source est tout ce qui est dans le contrôle de version. C'est probablement la principale raison pour ne pas mettre les mots de passe dans le contrôle de version!

Cependant ...

Cela dit, les mots de passe doivent être stockés quelque part . Ce à quoi les préoccupations ci-dessus font allusion n'est pas nécessairement qu'elles ne devraient pas du tout être stockées dans le contrôle de version, mais plutôt qu'elles ne devraient pas être stockées dans le référentiel de code source du produit dans le contrôle de version. Avoir un dépôt séparé pour la gestion de la configuration, les opérations, etc. est très raisonnable. La clé est de séparer les opérations du développement en ce qui concerne les informations d'identification de sécurité, pas nécessairement pour éviter complètement le contrôle de version.

De plus, pour les environnements hors production, j'ai stocké les mots de passe et les clés API pour les systèmes externes dans les fichiers de configuration dans le code source du produit par défaut. Pourquoi? Pour rendre les choses faciles lorsqu'un développeur vérifie le code, il peut simplement le construire et l'exécuter sans avoir à aller chercher des fichiers de configuration supplémentaires. Ce sont des informations d'identification qui changent rarement et qui ne mènent à aucun secret commercial. Mais je ne ferais jamais ça avec des secrets de production.

Donc, l'essentiel est ... ça dépend.

Il est toujours important de garder à l'esprit que les suggestions doivent être adaptées à votre cas d'utilisation. Les mesures de sécurité prises par, par exemple, la NSA pour protéger tous les jours zéro qu'ils restent pendant un jour de pluie devraient être beaucoup plus strictes que les mesures de sécurité prises pour protéger les votes à la hausse sur un site de publication d'images de chat. À un extrême, je peux penser à un exemple où conserver les mots de passe / jetons / etc dans un dépôt git privé peut être raisonnable:

Si ce dépôt n'est accessible que par une seule personne et que l'application n'en stocke aucun informations de n'importe quelle valeur.

Dans ce cas, allez en ville! Gardez simplement à l'esprit ce que @ d33tah a dit dans sa réponse - effacer des choses d'un dépôt git peut être étonnamment difficile (le but, après tout, est de garder un historique de tout pour toujours) donc si vous décidez que vous voulez Collaborez avec plus de personnes mais ne voulez pas qu'elles aient un accès complet à tous vos systèmes, alors vous allez avoir un peu mal à la tête.

C'est ce qui se résume vraiment à. Votre référentiel de code est en quelque sorte "public", même s'il n'est partagé qu'avec des collaborateurs. Ce n'est pas parce que vous souhaitez collaborer avec quelqu'un que vous voulez lui donner un accès complet à votre infrastructure (ce qui est effectivement ce qui se passe lorsque vous mettez des mots de passe / jetons dans votre référentiel de code). Il est facile de penser "oui, mais je fais confiance aux personnes avec lesquelles je collabore!", Mais ce n’est tout simplement pas la bonne façon d’envisager le scénario, pour plusieurs raisons:

1. Dans la pratique, une grande partie des fuites de données commence avec des acteurs internes (collaborateurs, employés). Selon une étude, environ 43% des violations de données ont commencé avec un acteur interne. La moitié d'entre elles étaient intentionnelles et l'autre accidentelle.
2. Ce dernier point est important et pourquoi il ne s’agit pas uniquement de confiance. Environ 20% des violations de données sont accidentelles et causées par des personnes internes. Je suis assez intelligent pour savoir que je ne suis pas assez intelligent pour tout faire correctement tout le temps. Que faire si je rends mon référentiel public pour faire de la place à un outil d'intégration amusant et que j'oublie que j'ai des informations d'identification? Que faire si j'ai un disque dur de sauvegarde que j'ai oublié de crypter et qu'il sort de mon bureau? Que faire si l'un de mes mots de passe est divulgué et que quelqu'un l'utilise pour deviner le mot de passe du compte dans mon dépôt git ( toux dépôt github gentoo toux )? Il y a un certain nombre d'erreurs accidentelles que je peux faire qui pourraient entraîner l'exposition de mon référentiel git, et si cela se produit et j'y ai des informations d'identification et la personne qui les trouve sait ce qu'elle regarde, je pourrais très bien être arrosée. Cela ressemble à beaucoup de et , mais la réalité est que c'est ainsi que les violations se produisent.
3. Même si je fais confiance à quelqu'un, cela ne signifie pas que je dois donner leur accès complet à tout [Insérer une citation ringarde sur la façon dont le pouvoir corrompt]. Encore une fois, mettre des informations d'identification dans un référentiel git signifie que je donne potentiellement un accès complet à l'ensemble de mon infrastructure à tous mes collaborateurs. Il y a toujours un risque que vous ne connaissiez pas cette personne aussi bien que vous le pensez, et elle pourrait décider de faire quelque chose qu'elle ne devrait pas faire. Même si vous connaissez personnellement et faites confiance à chacun de vos collaborateurs avec votre vie, cela ne signifie pas qu'ils ne feront pas certaines des erreurs ci-dessus (ou l'une des options infinies que je n'ai pas mentionnées) pour libérer accidentellement votre code.

En bref, une bonne sécurité consiste à avoir des défenses superposées. La plupart des hacks se produisent parce que les pirates trouvent des faiblesses dans un domaine qui leur permet d'exploiter les faiblesses dans un autre domaine, ce qui les mène ailleurs, ce qui les amène finalement au gros gain. Avoir autant de mesures de sécurité en place qu'il est logique pour votre situation est ce qui maintient le tout en sécurité. De cette façon, lorsqu'un disque dur de sauvegarde sort de votre bureau et que vous vous rendez compte qu'il n'a pas été chiffré, vous n'avez pas à demander "Était-ce une attaque ciblée et dois-je maintenant changer tous les identifiants que j'ai partout parce que ils étaient tous dans le référentiel git sur ce lecteur de sauvegarde? ". Encore une fois, selon votre situation, cela peut ne pas s'appliquer à vous, mais j'espère que cela vous aidera à expliquer dans quels scénarios cela pourrait avoir de l'importance.

Garder les secrets (mots de passe, certificats, clés) séparés du code source permet de gérer la source et les secrets selon différentes politiques. Comme, tous les ingénieurs peuvent lire le code source, seules les personnes qui sont directement responsables des serveurs de production peuvent accéder aux secrets.

Cela facilite la vie des développeurs car ils ne sont pas liés par les politiques de sécurité strictes qui sont nécessaires pour protéger les secrets. Les règles de contrôle des sources peuvent être rendues beaucoup plus pratiques pour eux.

Cette convention, comme beaucoup d'autres "bonnes pratiques" de sécurité, est un moyen pratique de s'assurer que les choses ne vont pas mal à cause de mauvaises habitudes ou de mauvaises habitudes.

Si vous vous souvenez toujours que vos mots de passe sensibles se trouvent dans votre système de contrôle de version et si vous ne donnez jamais à quiconque ne devrait pas avoir le mot de passe l'accès au référentiel et si votre référentiel est stocké aussi sûr que ces secrets l'exigent et si votre processus de déploiement est également sûr, sécurisé et protégé contre les personnes non autorisées et si vous pouvez être sûr que toutes les sauvegardes et copies de votre référentiel sont et ... vous pouvez probablement ajouter quelques autres "si" spécifiques à votre contexte.

... alors vous pouvez bien stocker vos mots de passe dans votre système de contrôle de version.

Dans la plupart des cas, au moins un de ces «si» n'est pas suffisamment conforme à vos conditions ou est hors de votre contrôle.

Par exemple, dans de nombreux contextes, vos développeurs ne devraient pas avoir accès à la base de données de production. Ou le système de sauvegarde est sous-traité à un autre service. Ou votre processus de construction est externalisé vers le cloud.

C'est pourquoi en général , ne pas stocker vos mots de passe dans votre système de contrôle de version est une bonne pratique qui vous permet de ne pas tombez dans l'un de ces pièges parce que vous n'y avez pas pensé. "no passwords in git" est plus facile à retenir qu'une longue liste de conditions que vous devez remplir pour stocker en toute sécurité les mots de passe sous contrôle de version.

D'autres réponses sont excellentes, mais considérez également le problème des sauvegardes. Vous avez beaucoup plus de flexibilité sur l'endroit, la manière et la durée de stockage de vos sauvegardes de référentiel de code si elles ne contiennent pas d'informations sensibles sur la façon d'accéder à votre serveur ou à vos comptes administrateur.

D'un autre plus de sécurité- angle ciblé, seule votre sauvegarde de code pourrait être une cible intéressante pour les concurrents non éthiques de votre entreprise. En fonction de votre entreprise, la plupart des concurrents dans un pays de «primauté du droit» n'y toucheraient pas de toute façon. Une sauvegarde de code avec des mots de passe sera la cible de toute organisation criminelle intéressée par les données de vos utilisateurs ou souhaitant faire chanter votre entreprise.

Les dommages causés par une violation du référentiel de code seraient mieux avec les mots de passe pour des raisons similaires. Préférez-vous que votre code source soit volé et publié, ou que tous vos utilisateurs soient exposés à un vol d'identité, avec un procès potentiel ou même une affaire pénale contre vous pour ne pas avoir sécurisé leurs données privées (pensez au RGPD)?

"Pourquoi est-il si mauvais de mettre vos clés directement dans votre porte principale, alors que nous vivons loin de la civilisation?"

Parce que les gens qui veulent faire de mauvaises choses le feront facilement et le le coût de faire dur pour eux n'est pas trop élevé. Gardez vos clés avec vous pas à côté de la porte. Du bon sens.

Repo privé? Combien de personnes ont accès pour le télécharger? Et combien de personnes sont connectées à ses ordinateurs? Et puis ... Sont-ils tous exempts de danger?

Cela dépend également du système de contrôle du code source.

Git pense que le système de contrôle du code source doit vous donner un historique fiable du projet. Ce n'est pas une mauvaise attitude à avoir. Mais il y a l'effet que si vous vérifiez un mot de passe dans git, il est très difficile de le supprimer de votre référentiel.

Perforce a une commande "oblitérer" à cet effet. Si vous avez vérifié un mot de passe, ou quelqu'un enregistre un fichier vidéo non compressé de 8 gigaoctets, ou quelqu'un a enregistré un code tiers qui enfreint les droits d'auteur de quelqu'un et n'aurait jamais dû être enregistré, ou quelqu'un qui a été viré a enregistré beaucoup de contenu pornographique sur leur dernier jour de travail, vous pouvez "effacer". Il a complètement disparu du référentiel et de l'histoire.