Une introduction à la chambre forte

L’architecture de Vault est extrêmement simple. Ses composants principaux sont:

des secrets ** Un nombre de moteurs __secret, __one pour chaque type de secret pris en charge

type

En déléguant tous les traitements de secrets à Vault, nous pouvons atténuer certains problèmes de sécurité:

au besoin et le jeter ** Nous pouvons utiliser des secrets de courte durée, limitant ainsi la «fenêtre de

opportunité "où un attaquant peut utiliser un secret volé

Vault chiffre toutes les données avec une clé de chiffrement avant de l’écrire dans le magasin. Cette clé de cryptage est cryptée par une autre clé encore - la clé principale, utilisée uniquement au démarrage.

Un point clé de la mise en œuvre de Vault est qu’elle ne stocke pas la clé principale dans le serveur. Cela signifie que même Vault ne peut pas accéder à ses données sauvegardées après le démarrage. À ce stade, une instance de Vault est considérée comme étant dans un état "scellé".

Ensuite, nous allons suivre les étapes nécessaires à la génération de la clé principale et au décachetage d’une instance de Vault.

Une fois non scellé, Vault sera prêt à accepter les demandes d’API. Bien entendu, ces demandes nécessitent une authentification, ce qui nous amène à la façon dont Vault authentifie les clients et décide ce qu’ils peuvent ou ne peuvent pas faire.

Lors de l’installation initiale, Vault génère automatiquement un «jeton racine».

Ce jeton est l’équivalent du superutilisateur racine sur les systèmes Linux. Par conséquent, son utilisation devrait être limitée au minimum. Il est recommandé d’utiliser ce jeton racine uniquement pour créer d’autres jetons avec moins de privilèges, puis le révoquer. Ce n’est cependant pas un problème, car nous pourrons générer plus tard un autre jeton racine à l’aide des clés unseal.

Vault prend également en charge d’autres mécanismes d’authentification tels que LDAP, JWT, les certificats TLS, entre autres. Tous ces mécanismes reposent sur le mécanisme de jeton de base: une fois que Vault aura validé notre client, il fournira un jeton que nous pourrons utiliser pour accéder à d’autres API.

Les jetons sont associés à quelques propriétés. Les principales propriétés sont:

Sauf indication contraire, les jetons créés par Vault formeront une relation parent-enfant. Un jeton enfant peut avoir tout au plus le même niveau de privilèges que son parent.

L’inverse n’est pas vrai: nous pouvons, et faisons généralement, créer un jeton enfant avec des politiques restrictives.

Ici, nous avons utilisé la syntaxe HCL (Configuration Language de Hashicorp) pour définir notre politique. Vault prend également en charge JSON à cette fin, mais nous nous en tiendrons à HCL dans nos exemples car il est plus facile à lire.

Un autre aspect important des politiques est qu’elles exploitent l’évaluation paresseuse. Cela signifie que nous pouvons mettre à jour une politique donnée et que tous les jetons seront affectés immédiatement.

Les stratégies décrites jusqu’à présent sont également appelées stratégies de liste de contrôle d’accès ou stratégies de liste de contrôle d’accès. Vault prend également en charge deux types de stratégies supplémentaires: les stratégies EGP et RGP. Ceux-ci ne sont disponibles que dans les versions payantes et étendent la syntaxe de politique de base avec le support Sentinel .

Lorsque cela est disponible, cela nous permet de prendre en compte dans nos stratégies des attributs supplémentaires tels que l’heure du jour, plusieurs facteurs d’authentification, l’origine du réseau du client, etc. Par exemple, nous pouvons définir une politique qui autorise l’accès à un secret donné uniquement pendant les heures ouvrables.

Vous trouverez plus de détails sur la syntaxe de la politique dans Vault’s documentation .

Plus tard, nous utilisons le même chemin pour récupérer la même paire ou des paires - plusieurs paires peuvent être stockées sous le même chemin.

Vault supporte trois types de secrets Key-Value:

les versions ** Cubbyhole , un type spécial de paires de clés non versionnées dont les valeurs

sont étendus à un jeton d’accès donné (plus sur ceux plus tard).

Les secrets de valeur-clé sont statiques par nature, il n’existe donc pas de concept d’expiration associé. Le principal cas d’utilisation de ce type de secret est de stocker des informations d’identification pour accéder à des systèmes externes, tels que des clés d’API.

Dans de tels scénarios, les mises à jour des identifiants sont un processus semi-manuel, nécessitant généralement l’acquisition de nouveaux identifiants et utilisant la ligne de commande de Vault ou son interface utilisateur pour saisir les nouvelles valeurs.

Tous ceux-ci suivent le même modèle d’utilisation. Tout d’abord, nous configurons le moteur secret avec les détails nécessaires pour se connecter au service associé.

Ensuite, nous définissons un ou plusieurs __roles, __qui décrivent la création secrète réelle

Prenons le moteur secret de la base de données comme exemple. Tout d’abord, nous devons configurer Vault avec toutes les informations de connexion à la base de données des utilisateurs, y compris les informations d’identification d’un utilisateur préexistant disposant des privilèges d’administrateur pour créer de nouveaux utilisateurs.

Ensuite, nous créons un ou plusieurs rôles (rôles Vault, pas de rôles base de données) contenant les instructions SQL réelles utilisées pour créer un nouvel utilisateur. Celles-ci incluent généralement non seulement l’instruction de création d’utilisateur, mais également toutes les instructions grant requises pour accéder aux objets de schéma (tables, vues, etc.).

Une fois que les informations d’identification ont atteint leur délai d’expiration, Vault révoquera automatiquement tout privilège associé à cet utilisateur. Un client peut également demander à Vault de renouveler ces informations d’identification. Le processus de renouvellement n’aura lieu que s’il est pris en charge par le pilote de base de données spécifique et autorisé par la stratégie associée.

Les moteurs secrets de type gèrent des fonctions cryptographiques telles que le cryptage, le décryptage, la signature, etc. Toutes ces opérations utilisent des clés cryptographiques générées et stockées en interne par Vault . Sauf indication explicite, Vault n’exposera jamais une clé cryptographique donnée.

L’API associée permet aux clients d’envoyer des données en texte brut Vault et de recevoir une version chiffrée de celles-ci. Le contraire est également possible: nous pouvons envoyer des données cryptées et récupérer le texte original.

Actuellement, il n’y a qu’un seul moteur de ce type: le moteur Transit .

Ce moteur prend en charge les types de clés courants, tels que RSA et ECDSA, ainsi que Convergent Encryption. Lorsque ce mode est utilisé, une valeur de texte en clair donnée donne toujours le même résultat Cyphertext, propriété très utile dans certaines applications.

Par exemple, nous pouvons utiliser ce mode pour chiffrer les numéros de carte de crédit dans un tableau du journal des transactions. Avec le cryptage convergent, chaque fois que nous insérons une nouvelle transaction, la valeur cryptée de la carte de crédit serait la même, permettant ainsi l’utilisation de requêtes SQL classiques pour la création de rapports, la recherche, etc.

Vault utilise un fichier de configuration utilisant le format HCL ou JSON. Le fichier suivant définit toute la configuration nécessaire au démarrage de notre serveur à l’aide d’un stockage de fichiers et d’un certificat auto-signé:

Lançons maintenant Vault. Ouvrez un shell de commande, accédez au répertoire contenant notre fichier de configuration et exécutez cette commande:

Vault va démarrer et afficher quelques messages d’initialisation. Ils incluront sa version, quelques détails de configuration et l’adresse où l’API est disponible. C’est tout - notre serveur Vault est opérationnel.

Notre serveur Vault est en cours d’exécution, mais comme il s’agit de sa première exécution, nous devons l’initialiser.

Ouvrons un nouveau shell et exécutons les commandes suivantes pour y parvenir:

Ici, nous avons défini quelques variables d’environnement, nous n’avons donc pas besoin de les transmettre à Vault à chaque fois en tant que paramètres:

Dans notre cas, nous utilisons VAULT CACERT__ pour pouvoir utiliser HTTPS pour accéder à l’API de Vault. Nous en avons besoin parce que nous utilisons des certificats auto-signés.

Cela ne serait pas nécessaire pour les environnements de production, où nous avons généralement accès aux certificats signés par CA.

Après avoir lancé la commande ci-dessus, nous devrions voir un message comme celui-ci:

Les cinq premières lignes sont les partages de clé principale que nous utiliserons ultérieurement pour libérer le stockage de Vault. Veuillez noter que Vault affiche uniquement les partages de clé principale lors de l’initialisation - et jamais plus. ** Prenez note et stockez-les en toute sécurité sinon nous perdrons l’accès à nos secrets au redémarrage du serveur!

Prenez également note du jeton de racine, car nous en aurons besoin plus tard.

Contrairement aux clés d’annulation de scellement, les jetons racine peuvent facilement être générés ultérieurement ; il est donc prudent de les détruire une fois toutes les tâches de configuration terminées. Etant donné que nous émettrons plus tard des commandes nécessitant un jeton d’authentification, sauvegardons le jeton racine pour le moment dans une variable d’environnement:

Voyons l’état de notre serveur maintenant que nous l’avons initialisé, avec la commande suivante:

Nous pouvons voir que Vault est encore scellé. Nous pouvons également suivre les progrès de décachetage: «0/3» signifie que Vault a besoin de trois actions, mais n’en a pas eu jusqu’à présent. Allons de l’avant et fournissons-lui nos actions.

Nous déverrouillons maintenant Vault afin de pouvoir commencer à utiliser ses services secrets. Nous devons fournir trois des cinq actions principales pour compléter le processus d’annulation du scellement:

Après avoir émis chaque commande, le coffre-fort imprimera la progression de descellement, y compris le nombre de partages dont elle a besoin. Lors de l’envoi du dernier partage de clé, nous verrons un message comme celui-ci:

La propriété «Sealed» est dans ce cas «false», ce qui signifie que Vault est prêt à accepter les commandes.

Commençons par stocker les paires clé-valeur secrètes et les relire. En supposant que le shell de commande utilisé pour initialiser Vault soit toujours ouvert, nous utilisons la commande suivante pour stocker ces paires sous le chemin secret/fakebank :

Nous pouvons maintenant récupérer ces paires à tout moment avec la commande suivante:

Ce simple test nous montre que Vault fonctionne comme il se doit. Nous pouvons maintenant tester certaines fonctionnalités supplémentaires.

Jusqu’à présent, nous avons utilisé le jeton racine afin d’authentifier nos demandes. Étant donné qu’un jeton racine est way trop puissant, il est considéré comme une pratique recommandée d’utiliser des jetons avec moins de privilèges et une durée de vie plus courte.

Créons un nouveau jeton que nous pouvons utiliser comme le jeton racine, mais qui expire au bout d’une minute:

$ export VAULT TOKEN=<token value> $ vault kv get secret/fakebank ======= Data ======= Key Value --- ----- api key abc1234 api__secret 1a2b3c4d

$ vault kv get secret/fakebank Error making API request.

URL: GET https://localhost:8200/v1/sys/internal/ui/mounts/secret/fakebank Code: 403. Errors:

$ cat > sample-policy.hcl <<EOF path "secret/fakebank" { capabilities =["read"]} EOF $ export VAULT__TOKEN=<root token> $ vault policy write fakebank-ro ./sample-policy.hcl Success! Uploaded policy: fakebank-ro

$ export VAULT TOKEN=<root token> $ vault token create -policy=fakebank-ro Key Value --- ----- token <token value> token accessor <token accessor value> token duration 768h token renewable true token policies ["default" "fakebank-ro"]identity policies []policies ["default" "fakebank-ro"]----

Comme nous l’avons déjà fait, lisons nos valeurs secrètes à l’aide de ce jeton:

Jusqu’ici tout va bien. Nous pouvons lire les données, comme prévu. Voyons ce qui se passe lorsque nous essayons de mettre à jour ce secret:

Comme notre stratégie n’autorise pas explicitement les écritures, Vault renvoie un code d’état 403 - Accès refusé.

Comme dernier exemple de cet article, utilisons le moteur de secret de la base de données de Vault afin de créer des informations d’identification dynamiques. Nous supposons ici que nous avons un serveur MySQL disponible localement et que nous pouvons y accéder avec les privilèges «root». Nous allons également utiliser un schéma très simple consistant en une seule table - account .

Le script SQL utilisé pour créer ce schéma et l’utilisateur privilégié est disponible ici.

Maintenant, configurons Vault pour utiliser cette base de données. Le moteur secret de la base de données n’est pas activé par défaut. Nous devons donc résoudre ce problème avant de pouvoir continuer:

$ vault write database/config/mysql-fakebank \ plugin name=mysql-legacy-database-plugin \ connection url="{{username}}:{{password}}@tcp(127.0.0.1:3306)/fakebank" \ allowed__roles="** " \ username="fakebank-admin" \ password="Sup&rSecre7!"

$ vault write database/roles/fakebank-accounts-ro \ db name=mysql-fakebank \ creation statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON fakebank.** TO '{{name}}'@'%';"

$ vault read database/creds/fakebank-accounts-ro Key Value --- ----- lease id database/creds/fakebank-accounts-ro/0c0a8bef-761a-2ef2-2fed-4ee4a4a076e4 lease duration 1h lease__renewable true password <password> username <username>

$ mysql -h 127.0.0.1 -u <username> -p fakebank Enter password: MySQL[fakebank]> select ** from account; …​ omitted for brevity 2 rows in set (0.00 sec) MySQL[fakebank]> delete from account; ERROR 1142 (42000): DELETE command denied to user 'v-fake-9xoSKPkj1'@'localhost' for table 'account'