Pourquoi le stockage de mots de passe dans le contrôle de version est-il une mauvaise idée?
Mon ami m'a simplement demandé: "Pourquoi est-il vraiment si mauvais de mettre différents mots de passe directement dans le code source du programme, alors que nous ne les stockons que sur notre serveur Git privé?"
Je lui ai donné une réponse qui a mis en évidence quelques points, mais j'ai estimé que ce n'était pas assez organisé et j'ai décidé que cela pourrait avoir un sens pour créer une question canonique.
En outre, comment le stockage des mots de passe dans le code source n'est-il pas lié au principe du moindre privilège et aux autres fondements de la sécurité de l'information?
La façon dont je le vois, ne stockant pas les mots de passe dans Git (ou un 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:
- Git rend difficile la suppression des mots de passe de l'historique du code source, ce qui pourrait donner aux gens une fausse idée que le mot de passe a déjà été supprimé dans la version actuelle.
- 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 peuvent avoir des privilèges différents.
- Les logiciels de contrôle des sources ont tendance à devenir assez compliqués, en particulier les systèmes "tout-en-un". Cela signifie qu'il existe un risque que ce système soit éventuellement compromis, entraînant une fuite de mot de passe.
- D'autres développeurs peuvent ignorer que le mot de passe est stocké et peuvent mal gérer le référentiel - avoir des clés dans la source signifie que des précautions supplémentaires devraient être prises lors du partage du code (même au sein de l'entreprise; cela pourrait créer un besoin de canaux cryptés).
I je ne peux pas dire que chaque modèle lié à infosec est bon , mais avant de les casser, c'est toujours une bonne idée de considérer votre modèle de menace et vos vecteurs d'attaque. Si ce mot de passe particulier était divulgué, à quel point 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 d'un code d'application logicielle. Si un administrateur de base de données 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 version en production, et essayer de tout synchroniser? 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
Généralement, les systèmes de contrôle de version fournissent un contrôle d'autorisation afin que seuls les utilisateurs autorisés puissent y accéder. Mais dans un référentiel, les autorisations sont généralement en lecture/écriture ou 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é qui permettent aux développeurs d'obtenir le code source, mais pas les 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. Et si les développeurs y 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 se passe-t-il si vous disposez de plusieurs environnements, comme un environnement de développement, un environnement d'assurance qualité, une mise en scène et une production? Souhaitez-vous stocker tous leurs mots de passe dans le contrôle de version? Comment l'application pourrait-elle savoir 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 définir le nom d'environnement comme paramètre de configuration, vous pouvez définir le mot de passe de la base de données comme paramètre de configuration (avec la chaîne de connexion, le nom d'utilisateur, etc.)
Histoire
Comme d'autres l'ont mentionné, le contrôle de version est conçu pour préserver l'historique. Ainsi, les mots de passe plus anciens seront toujours récupérables, ce qui n'est peut-être pas la meilleure chose.
Compromis
Combien de fois avons-nous vu des titres dans les actualités concernant le code source de certains produits divulgués dans le monde? Le code source est tout ce qui se trouve dans le contrôle de version. C'est probablement la principale raison de ne pas mettre de mots de passe dans le contrôle de version!
Cependant ...
Cela dit, les mots de passe doivent être stockés quelque part . Ce à quoi font allusion les préoccupations ci-dessus 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.
En outre, pour les environnements hors production, j'ai stocké les mots de passe et les clés API pour les systèmes externes dans des fichiers de configuration dans le code source du produit par défaut. Pourquoi? Pour le rendre indolore lorsqu'un développeur extrait le code, il peut simplement le générer et l'exécuter sans avoir à aller chercher des fichiers de configuration supplémentaires. Ce sont des informations d'identification qui changent rarement et ne conduisent à aucun secret commercial. Mais je ne ferais jamais ça avec des secrets de production.
Donc, l'essentiel est ... cela 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, les NSA pour protéger tous les jours zéro qu'ils gardent pendant un jour de pluie devraient être beaucoup plus strictes que les mesures de sécurité prises pour protéger les votes positifs sur un chat- site de publication d'images. À une extrême, je peux penser à un exemple où la conservation des mots de passe/jetons/etc dans un référentiel git privé pourrait être raisonnable:
Si ce référentiel n'est accessible qu'à une seule personne et que l'application ne stocke aucune information de quelque valeur que ce soit.
Dans ce cas, allez en ville! Gardez juste à l'esprit ce que @ d33tah a dit dans sa réponse - nettoyer les choses d'un référentiel 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 gens mais ne voulez pas qu'ils aient un accès complet à tous vos systèmes, alors vous aurez un peu mal à la tête.
Voilà à quoi cela 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 se produit effectivement lorsque vous placez des mots de passe/jetons dans votre référentiel de code). Il est facile de penser "oui, mais je faites confiance aux personnes avec qui je collabore!", Mais c'est tout simplement la mauvaise façon de voir le scénario, pour un certain nombre de raisons:
- Dans la pratique, une grande partie des fuites de données commencent par des acteurs internes (collaborateurs, employés). Par un étude environ 43% des violations de données ont commencé avec un acteur interne. La moitié d'entre elles étaient intentionnelles et l'autre moitié accidentelles.
- Ce dernier point est important et pourquoi il ne s'agit pas seulement 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 oublier que j'ai des informations d'identification? Que faire si j'ai un disque dur de sauvegarde que j'ai oublié de chiffrer et qui 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 référentiel git ( toux référentiel gentoo github toux )? Il y a un certain nombre d'erreurs accidentelles que [~ # ~] i [~ # ~] peut faire, ce qui pourrait entraîner l'exposition de mon référentiel git, et si cela se produit et j'ai des informations d'identification là-dedans et la personne qui trouve eux savent ce qu'ils regardent, je pourrais très bien être arrosé. Cela ressemble à beaucoup de et de mais la réalité est que c'est ainsi que les violations se produisent.
- Même si j'ai confiance en quelqu'un, cela ne signifie pas que je dois lui donner un accès complet à tout [Insérer une citation ringarde sur la façon dont le pouvoir corrompt]. Encore une fois, mettre les 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 la possibilité que vous ne connaissiez pas cette personne aussi bien que vous le pensez, et qu'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 sans fin que je n'ai pas mentionnées) pour libérer accidentellement votre code.
En bref, une bonne sécurité consiste à disposer de défenses en couches. La plupart des hacks se produisent parce que les pirates trouvent des faiblesses dans un domaine qui leur permettent d'exploiter des faiblesses dans un autre domaine, ce qui mène ailleurs, ce qui les mène finalement au grand payer. 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 réalisez qu'il n'a pas été chiffré, vous n'avez pas à demander "S'agit-il d'une attaque ciblée et dois-je maintenant changer toutes les informations d'identification 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 aidera à expliquer dans quels scénarios cela pourrait avoir de l'importance.
La séparation des secrets (mots de passe, certificats, clé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 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 nécessaires pour protéger les secrets. Les politiques de contrôle des sources peuvent être rendues beaucoup plus pratiques pour eux.
Cette convention, comme de nombreuses autres "meilleures pratiques" en matière de sécurité, est un moyen pratique de s'assurer que les choses ne se passent pas mal en raison de mauvaises habitudes ou de la routine.
If vous vous souvenez toujours que vos mots de passe sensibles sont dans votre système de contrôle de version et if vous ne donnez à personne qui ne devrait pas avoir accès au mot de passe le dépôt et if votre référentiel est stocké de manière aussi sûre que ces secrets l'exigent et if votre processus de déploiement est également sûr, sécurisé et protégé contre les personnes non autorisées et if vous pouvez être sûr que toutes les sauvegardes et copies de votre référentiel le sont et ... vous pouvez probablement ajouter quelques "if" supplémentaires 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 paramètres, 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 meilleure pratique qui vous assure de ne pas tomber dans l'un de ces pièges parce que vous n'y avez pas pensé. "aucun mot de passe dans 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 disposez de beaucoup plus de flexibilité pour savoir où, comment et pendant combien de temps vous stockez 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 d'administrateur.
Sous un autre angle plus axé sur la sécurité, juste votre sauvegarde de code pourrait être une cible intéressante pour les concurrents contraires à l'éthique de votre entreprise. Selon votre entreprise, la plupart des concurrents d'un pays où règne l'état de droit n'y toucheront pas de toute façon. Une sauvegarde de code avec les mots de passe sera la cible de toute organisation criminelle intéressée par les données de vos utilisateurs, ou intéressée à faire chanter votre entreprise.
Les dommages causés par une violation du référentiel de code seraient plus importants 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 à l'usurpation d'identité, avec un éventuel procès ou même une action pénale contre vous pour avoir omis de sécuriser leurs données privées (pensez RGPD)?
"Pourquoi est-il vraiment 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 coût de travailler dur pour eux n'est pas trop élevé. Gardez vos clés avec vous, pas à côté de la porte. 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 à l'abri du danger?
Cela dépend également du système de contrôle du code source.
Git a l'attitude que le système de contrôle du code source devrait vous donner un historique fiable du projet. Ce qui n'est pas une mauvaise attitude. Mais il y a l'effet que si vous avez vérifié un mot de passe dans git, il est très difficile de le supprimer de votre référentiel.
Perforce dispose d'une commande "oblitérer" à cet effet. Si vous avez enregistré un mot de passe, ou si quelqu'un enregistre un fichier vidéo non compressé de 8 gigaoctets, ou si quelqu'un a archivé un code tiers qui viole le droit d'auteur de quelqu'un et n'aurait jamais dû être enregistré, ou quelqu'un qui a été viré a enregistré beaucoup de porno sur leur dernier jour de travail, vous pouvez "l'effacer". C'est complètement parti du référentiel et de l'histoire.