Garder les secrets hors du contrôle des sources - déplaçons-nous simplement le problème?


10

J'ai hérité de certains projets dans lesquels les secrets étaient dans le contrôle de code source dans App.config et des fichiers similaires. Heureusement, ce n'est pas un référentiel public, donc le risque n'est pas aussi grave qu'il aurait pu l'être. J'examine de meilleures façons de gérer cela, comme Azure KeyVault. (Mais je n'ai pas l'intention que cette question soit spécifique à cette solution.)

En général, ne déplaçons-nous pas simplement le problème? Par exemple, avec Azure KeyVault, l'ID d'application et le secret d'application deviennent les éléments dont vous avez besoin pour échapper au contrôle des sources. Voici un exemple malheureusement typique de la façon dont cela a tendance à mal tourner. D'autres approches finissent par être similaires, avec des clés API ou des fichiers de clés que vous devez protéger.

Il me semble que des produits comme Azure KeyVault ne sont pas meilleurs, et inutilement plus compliqués, 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. Ce fichier devrait être partagé au besoin via un canal latéral. Bien sûr, les gens vont probablement s'envoyer des courriers électroniques de manière non sécurisée ...

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. (Si nous devrions être une question distincte ...)

Réponses:


12

Vous pourriez dire que vous ne faites que déplacer le problème. En fin de compte, il devra y avoir un secret stocké quelque part auquel votre application a accès afin d'avoir des mots de passe, des clés ssh, peu importe.

Mais, si c'est fait correctement, vous déplacez le problème d'un endroit difficile à sécuriser correctement vers un autre que vous pouvez mieux protéger. Par exemple, mettre des secrets dans un dépôt github public, c'est un peu comme laisser vos clés de maison collées à votre porte d'entrée. Quiconque les désire n'aura aucun mal à les trouver. Mais si vous déménagez, disons un magasin de clés sur un réseau interne sans connectivité extérieure, vous avez de bien meilleures chances de sécuriser vos mots de passe. Cela ressemble plus à garder vos clés dans votre poche. Il n'est pas impossible de les perdre (l'équivalent de donner votre mot de passe Azure par exemple), mais cela limite votre exposition par rapport à l'enregistrement de vos clés sur votre porte.


4

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.


0

Il vaut la peine d'envisager un git secretprojet ( http://git-secret.io/ ) afin de garder les fichiers secrets dans git repo cryptés avec une clé asymétrique. Les clés publiques sont également en dépôt, la clé privée ne l'est pas.

Les caractéristiques de cette approche sont les suivantes:

  • lorsqu'un nouvel utilisateur / machine doit déchiffrer des fichiers sécurisés - il publie / envoie sa clé publique gpg (gnu privacy guard aka pgp). L'utilisateur qui peut déjà décrypter les fichiers sécurisés peut les rechiffrer avec une nouvelle clé supplémentaire - après que le nouvel utilisateur peut décrypter les fichiers sécurisés avec sa clé privée.
  • vous devez évidemment contrôler qui peut valider / pousser vers le dépôt git. Sinon, l'attaquant peut valider sa propre clé publique et attendre que quelqu'un autorisé rechiffre les fichiers sécurisés avec cette nouvelle clé publique compromise.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.