Les secrets tels que les clés de chiffrement et les informations d'identification ne doivent pas être archivés dans le contrôle de code source pour plusieurs raisons. Le premier est évidemment que les clés de chiffrement et les informations d'identification doivent toujours être basées sur le besoin de savoir, et le contrôle des sources n'est pas un moyen fiable de protéger les informations contre la divulgation. L'autre raison pour laquelle vous ne voudriez pas de tels secrets dans votre contrôle de code source est généralement parce que les secrets sont généralement (mais pas toujours) spécifiques à un certain attribut de l'environnement dans lequel votre application s'exécutera. (Par exemple. Acquérir une clé privée pour créer un fichier numérique signature requise pour une autorisation de service Web, le point de terminaison spécifique de ce service Web peut s'exécuter dans un environnement QA nécessitant une signature QA).
La bonne façon de traiter un environnement (ou un secret global) est de le traiter comme vous le feriez pour tout autre attribut de configuration environnementale, avec des contrôles de sécurité supplémentaires pour faire bonne mesure. Un module de code bien conçu, indépendant et versionnable doit être identique dans tous les environnements, de telle sorte que l'environnement dans lequel ils sont déployés informe l'information sur ses attributs (par exemple, les détails de connexion à la base de données, les informations d'identification, les points de terminaison du service Web, les chemins d'accès aux fichiers, etc.). les détails de configuration cruciaux pour votre application sont externalisés et deviennent des paramètres de configuration de votre environnement.
Maintenant, pour répondre à certains de vos arguments:
En général, ne déplaçons-nous pas simplement le problème?
Une sécurité parfaite n'existe pas, mais «déplacer» le problème vers un domaine où des mesures et des contrôles supplémentaires peuvent être placés améliorera la difficulté et réduira la probabilité de divulgation accidentelle ou malveillante de secrets. Une bonne règle à suivre lors de la conception d'un système où les données confidentielles doivent être protégées est de toujours mettre les contrôles par deux. Je veux dire par là que pour qu'une divulgation accidentelle ou malveillante d'informations confidentielles ou un incident de sécurité se produise, il devrait y avoir une défaillance ou deux ou plusieurs contrôles.
Un bon exemple de cela pourrait être de stocker un fichier crypté sur un serveur. J'ai également une clé de déchiffrement secrète que je dois garder confidentielle dans un autre fichier.
- Stockez la clé et le fichier crypté sur le même serveur (0 contrôles, toute personne ayant accès au serveur peut acquérir trivialement les informations confidentielles)
- Effectuez les étapes ci-dessus et protégez l'accès aux fichiers pour qu'ils ne soient lisibles que par l'utilisateur d'exécution de l'application du système d'exploitation (1 Contrôle, compromettre le mot de passe de l'utilisateur root ou l'utilisateur d'exécution d'application permettra à un attaquant d'acquérir des informations confidentielles)
- Stockez la clé dans un coffre de clés externe, acquérez la clé avec plusieurs mesures de sécurité comme la liste blanche des adresses IP, l'authentification par certificat et d'autres mesures pour l'application qui peut accéder au fichier crypté sur son système de fichiers. (Plusieurs contrôles, plusieurs échecs des contrôles de sécurité doivent se produire pour que les données confidentielles soient compromises)
Encore une fois, la sécurité parfaite n'existe pas, mais l'objectif d'avoir plusieurs contrôles garantit que plusieurs défaillances doivent se produire pour que la divulgation se produise.
Il me semble que des produits comme Azure KeyVault ne sont pas meilleurs et inutilement plus compliqués,
Compliqué oui, inutile est complètement subjectif. Nous ne pouvons pas discuter de l'inutilité d'une sécurité supplémentaire sans tenir compte de manière réaliste de la gravité de la divulgation des données confidentielles. Si l'on pouvait utiliser les données confidentielles pour envoyer des virements électroniques illicites hors de votre institution financière, alors quelque chose comme un coffre-fort est la chose la plus éloignée de l'inutile.
que de garder vos secrets dans un fichier de configuration séparé et de vous assurer qu'il se trouve dans votre .gitignore ou équivalent.
Jusqu'à ce que quelqu'un le vérifie accidentellement dans le contrôle de code source, le secret est désormais intégré pour toujours dans l'historique du contrôle de code source.
Bien sûr, les gens vont probablement s'envoyer des courriers électroniques de manière non sécurisée ...
La sécurité n'est pas seulement un problème technique, c'est aussi un problème de personnes. Ce serait hors sujet, mais je pense qu'à ce stade, vous essayez de vous dissuader de faire le nécessaire.
Existe-t-il un moyen de gérer les secrets qui ne fait pas que déplacer le problème? Je crois que cette question a une seule réponse clairement définie. Par analogie, si je demandais comment HTTPS ne fait pas que déplacer le problème, la réponse serait que les clés CA sont distribuées avec votre système d'exploitation, et nous leur faisons confiance parce que nous faisons confiance à la méthode de distribution du système d'exploitation.
La sécurité ne fait pas toujours disparaître les problèmes, la plupart du temps elle met des contrôles autour d'eux. Votre analogie est succincte car c'est en fait exactement ce que fait la cryptographie à clé publique-privée. Nous «transférons le problème» à l'autorité de certification en accordant une confiance totale et sans équivoque à notre autorité de certification pour garantir l'identité de l'entité propriétaire du certificat public. Fondamentalement, rien de moins qu'une chaîne catastrophique d'échecs (par exemple, la perte de confiance dans l'AC) devrait se produire pour conduire à un problème de sécurité.
Comme pour beaucoup de choses, la sécurité est une ligne que vous devez tracer en fonction de critères subjectifs, de la nature des données, des conséquences de la divulgation, de l'appétit pour le risque, du budget, etc.
