Quels sont les avantages de sécurité de Hashicorp Vault par rapport au stockage de secrets (mots de passe, clés API) dans des variables d'environnement?
Il semble y avoir une recommandation générale de stocker des secrets dans l'instance Hashicorp Vault (ou un logiciel de gestion de clés similaire) et d'éviter de transmettre des secrets via des variables d'environnement. Dans quels scénarios particuliers l'utilisation de Vault est-elle meilleure du point de vue de la sécurité que l'utilisation de variables d'environnement?
La promesse de Vault est "des secrets en tant que service". Il prend en charge le stockage statique des secrets (pensez à Redis/Memcached crypté), le cryptage intermédiaire (donnez le texte brut du coffre-fort, le coffre-fort rend le texte chiffré que vous stockez dans une base de données) et l'acquisition dynamique de secrets.
Du côté du secret statique, les données sont cryptées en transit et au repos. Les données peuvent être stockées en mémoire, sur le système de fichiers ou dans des outils tiers comme Etcd ou Consul. C'est idéal pour les secrets au niveau de l'application. Vault prend en charge la rotation en ligne de la clé de chiffrement sous-jacente. Si vous avez des exigences de conformité FIPS/HIPPA/PCI, Vault permet de cocher facilement la plupart de ces cases avec la configuration par défaut.
Avec le chiffrement passe-système (ou "transit" comme on l'appelle en interne), Vault agit comme un service de chiffrement, acceptant les données en clair, les chiffrant et renvoyant le texte chiffré. J'ai écrit sur ce processus beaucoup plus en détail sur le blog HashiCorp, mais le processus est simple. Ce texte chiffré est ensuite géré par votre application. Lorsque l'application a besoin du texte en clair, elle s'authentifie et est autorisée dans Vault, fournit à Vault le texte chiffré et Vault renvoie le texte en clair (à nouveau, s'il est autorisé). Il y a une tonne d'avantages ici, mais les plus importants sont: 1. Vous n'avez pas à créer un service de chiffrement symétrique dans votre application; faites simplement un appel API, et 2. Les clés de chiffrement sont stockées dans un service complètement séparé et isolé; si un attaquant doit compromettre plusieurs systèmes. De plus, le backend de transit de Vault prend en charge ce concept appelé "clés dérivées". Cela permet des choses comme les clés de chiffrement par ligne pour les données stockées dans une base de données, de sorte que même si un attaquant avait un vidage de base de données et pouvait forcer brutalement la première clé de chiffrement, cette clé ne décrypterait pas les autres lignes de la base de données. Tout comme le backend secret statique, le backend de transit prend en charge la rotation des clés.
Les backends secrets dynamiques, à mon avis, sont l'endroit où Vault se sépare vraiment des autres solutions ou des solutions maison. Vault peut se connecter et générer dynamiquement des informations d'identification à partir d'éléments tels que des bases de données, des informations d'identification cloud, des certificats d'autorité de certification, gérer l'accès SSH, etc. Contrairement aux informations d'identification traditionnelles, ces informations d'identification sont associées à un bail, semblable à quelque chose comme DNS ou DHCP. Lorsqu'une application reçoit un justificatif d'identité, elle reçoit également un "bail" ou une durée de vie de ce justificatif d'identité. Au fil du temps, l'application (ou un service) doit communiquer avec Vault qu'il utilise toujours ces informations d'identification ou Vault les révoquera. Cela permet d'éliminer l'étalement secret tout en fournissant un moyen programmatique d'accéder aux informations d'identification. Étant donné que cela est programmatique, chaque instance de l'application (ou python dans votre exemple) reçoit un secret différent. Vous pouvez facilement révoquer les informations d'identification d'une seule application sans affecter le système entier.
Voici quelques cas d'utilisation qui pourraient vous aider à obtenir votre adhésion en interne:
Utilisez Vault's authentification GitHub pour authentifier vos développeurs et opérateurs. L'appartenance à l'équipe GitHub est mappée à la stratégie dans Vault. Tout membre de l'équipe des opérations obtient un accès SSH à prod, et tout membre de l'équipe de développement a la possibilité de générer des informations d'identification de compte AWS dynamiques dans l'environnement de transfert pour les tests.
Utilisez Vault authentification AppRole pour que les applications s'authentifient auprès de Vault et récupèrent un jeton. À partir de là, la stratégie de l'application lui permet de récupérer des données de démarrage, telles que des informations d'identification de base de données. Si l'application se bloque, les informations d'identification de la base de données sont automatiquement révoquées à l'expiration du bail.
Vous avez détecté une fuite de données. Vous pouvez immédiatement révoquer toutes les informations d'identification affectées. C'est ce qu'on appelle une procédure de "bris de glace".
En complément, vous pouvez utiliser un outil comme Consul Template pour extraire les valeurs de Vault dans un modèle que votre application peut ensuite utiliser. Votre application n'a pas besoin d'être "compatible avec Vault".
Et enfin, probablement pas lié à votre problème compte tenu de la publication, mais il convient de souligner que Vault résout également le défi "personne n'a un accès complet au système" auquel la plupart des organisations sont confrontées. En utilisant algorithme de partage secret de Shamir , le processus de mise en ligne d'un serveur Vault est très similaire au déverrouillage d'un coffre de banque traditionnel - plusieurs personnes doivent saisir leur clé simultanément pour déverrouiller. Vous pouvez également en savoir plus sur modèle de sécurité de Vault .
Pour les vidéos qui ont des démos et des trucs, consultez: