Secret Management avec Vault d’Hashicorp

La sécurité est toujours un sujet d’actualité en informatique. Ceci est également démontré par l’émergence de divers outils liés à la sécurité tels que ceux de Square Keywhiz ou de HashiCorp Vault. Nous avons examiné de plus près Vault et réfléchi à la manière de l’utiliser dans le Adfinis SyGroup.

C’est quoi le Vault?

Dans sa forme la plus simple, Vault est un magasin hiérarchique de clés/valeurs pour stocker les secrets. L’idée est de connecter Vault à une base de données persistante (par exemple MySQL, PostgreSQL, Consul, ….) de votre choix ou d’utiliser le backend de fichiers intégré. L’interaction avec Vault se fait via une HTTP REST API, pour laquelle il existe Client Libraries dans différents langages de programmation.
Mais avant d’entrer dans les détails du fonctionnement de Vault, il convient de clarifier quels problèmes Vault tente de résoudre. Si vous considérez le cycle de vie d’un secret générique, par exemple un mot de passe pour un utilisateur de base de données, il se présente généralement comme suit :

1. l’administrateur définit un secret en tenant compte des directives relatives aux mots de passe à l’échelle de l’entreprise.
2. le mot de passe est stocké dans un gestionnaire de mots de passe de son choix.
3. la liste des mots de passe est ajustée en conséquence lorsque l’utilisateur est supprimé.

Malheureusement, un point important est souvent oublié, à savoir la rotation régulière des Secrets. En supposant que vous pouvez casser n’importe quel cryptage avec suffisamment de temps et de ressources, il serait dévastateur si un attaquant pouvait obtenir une copie de la base de données des mots de passe cryptés.

La vision de HashiCorp est ce qu’on appelle des « secrets dynamiques ». Au lieu que l’administrateur système définisse le mot de passe lors de la configuration d’une application Web, l’application Web collecte le secret elle-même dans Vault à intervalles réguliers. Chaque secret reçoit un TTL, ce qui limite la durée de vie du secret à quelques heures ou quelques jours. Dans un tel scénario, si l’attaquant obtenait les mots de passe cryptés, ce serait « inoffensif » puisque tous les mots de passe sont déjà tournés en un jour.

La centralisation crée également un autre effet secondaire, car elle permet les procédures de bris de glace. Si une vulnérabilité est détectée dans votre propre infrastructure, l’accès au sous-ensemble de secrets affecté peut être bloqué. Une fois que la vulnérabilité a été trouvée et corrigée, les secrets sont tournés et libérés à nouveau.

A ce stade, très peu d’applications prennent en charge Vault en natif. Si vous utilisez HashiCorp’s own Consul comme backend de données, cependant, les fichiers de configuration peuvent être automatiquement régénérés par l’outil consul-template lorsque la clé/valeur est modifiée.
Vault fournit divers Audit Backends (journaux structurés et Syslog) pour enregistrer les modifications apportées à la base de données. Ainsi, les mutations peuvent également être vues plus tard. L’accès aux Secrets peut également être restreint par un système sophistiqué ACL System. Les ACL peuvent à leur tour être liées à divers Backends d’authentification. Ainsi, vous pouvez restreindre l’accès à un chemin d’accès pour un groupe LDAP donné, par exemple à « Read-Only ».
La configuration de Vault se fait via un fichier HCL ou JSON. L’exemple suivant montre une configuration avec un backend consul :

backend "consul" {
address = "127.0.0.1:8500"
path = "vault"
}

listener "tcp" {
address = "0.0.0.0:8200"
tls_disable = 0
tls_cert_file = "/etc/ssl/host.crt"
tls_key_file = "/etc/ssl/host.key"
tls_min_version = "tls12"
}

> Concernant la création du certificat TLS, je vous renvoie à notre Post OpenSSL x509 Create Certificates.

Démo

Pour savoir comment utiliser Vault, voici une petite démonstration.
Dès que le serveur de stockage fonctionne, il doit être initialisé.

$ vault init
Unseal Key 1: aRqypTLVENeZ9Tt1Kw2sy7XlnqHLT8XOUn3yqGTFMvsB
Unseal Key 2: o4Rd/1ZyzBwZaVEksIHsMpCJimv/pOt1+pSfQFiOEUkC
Unseal Key 3: S1x0hTZ5SrqiQlH1Boh8c/teKtfypu/PS6c5aHGj31cD
Unseal Key 4: TNdq4mdDDUMXAlxbtH8GCRRn3KU4HR3VSiefbWDUjtAE
Unseal Key 5: pA9DmAdIi+WsKVyKAnaWSH+wfBk1Hxlv+xQ5RUn5QM4F
Initial Root Token: 53368d66-8d50-ba5a-f953-7ef6b2dc03de
...

$ for KEY in ${UNSEAL_KEYS}; do vault unseal ${KEY}; done
...
Key (will be hidden):
Sealed: false
Key Shares: 5
Key Threshold: 3
Unseal Progress: 0
...

$ vault auth $ROOT_TOKEN
Successfully authenticated! You are now logged in.
token: 1bb7c7c6-6d4e-be92-cb5c-2838ccde3b5c
token_duration: 0
token_policies: [root]
...

Une clé maître est générée et divisée en plusieurs sous-clés (voir Shamir’s Secret Sharing). Parmi les sous-clés générées, un quorum de 3 clés est requis dans la configuration par défaut pour « desceller » l’instance Vault, une procédure qui doit être exécutée chaque fois que l’instance Vault est lancée. Le jeton racine initial est alors nécessaire pour s’authentifier à Vault.
Désormais, les secrets peuvent être écrits dans le secret/ backend par défaut.

$ vault mounts
Path Type Default TTL Max TTL Description
cubbyhole/ cubbyhole n/a n/a per-token private secret storage
secret/ generic system system generic secret storage
sys/ system n/a n/a system endpoints used for control, policy and debugging

$ vault write secret/test secret_key=secret_value
Success! Data written to: secret/test

$ vault list secret/
Keys
----
test

$ vault read secret/test
Key Value
--- -----
refresh_interval 720h0m0s
secret_key secret_value

Ce n’était qu’un petit extrait des fonctionnalités disponibles de Vault. Voici quelques cas d’utilisation supplémentaires qui iraient au-delà de la portée de ce billet de blog :

  • Générer Amazon Web Services IAM Politiques d’IAM
  • Administration de bases de données dynamiques utilisateurs / rôles pour MySQL, PostgreSQL, MongoDB….
  • PKI complet pour la création et la signature de certificats TLS
  • Sécuriser l’accès SSH aux systèmes par l’intermédiaire d’OTP

Je peux recommander à tout le monde de jeter un coup d’œil à l’excellente documentation de Vault. Bientôt il y aura une deuxième partie montrant comment nous avons adapté Vault.