Qui n’est jamais tombé sur un mot de passe de base de donnée codé en dur au milieu d’un script ? Cela a pu vous arriver par hasard ou plus déplaisant encore en plein incident. Incident résultant du changement de ce mot de passe qui a “fortuitement” entraîné des interruptions de services de plusieurs applications en apparence sans lien avec le compte de service qui vient d’être remplacé ou mis à jour.
Tout aussi déplaisant, il a pu s’avérer que ledit script se soit retrouvé consultable par des personnes non autorisées qui en ont profité pour enregistrer le mot de passe pour quelques besoins personnels…
Alors que faire ?
La solution tient en un seul mot : Vault (coffre-fort). Vous avez pour cela le choix entre de nombreuses solutions proposées par AWS, HashiCorp, Beyondtrust et tant d’autres. Dans cet article, nous allons nous concentrer sur le service AWS SecretsManager pour sa simplicité d’intégration avec les services consommateurs des secrets (Lambda, Fargate, EKS, EC2…) et son faible coût (AWS SecretsManager pricing).
AWS SecretsManager vous permet de stocker, récupérer et renouveler des secrets dont vous pouvez contrôler finement l’accès via une “Resource Policy”. C’est là que se joue une bonne partie de la simplicité d’intégration, car vous allez pouvoir référencer les rôles/identités IAM des ressources que vous souhaitez autoriser à consulter le secret (par exemple une lambda) via cette Resource Policy.
Bien entendu, vous allez vouloir chiffrer ces secrets et le service AWS KMS est fait pour ça. Vous allez pouvoir créer une clé de chiffrement qui est propre au projet ou à l’application propriétaire du secret et également gérer les droits d'utilisation de cette clé dans une Resource Policy.
Un petit schéma ?
Pour que notre lambda à gauche puisse accéder au secret en haut à droite, il faut que son rôle dispose des permissions nécessaires pour récupérer la valeur du secret, le déchiffrer et qu’il soit autorisé dans les deux Resource Policies (Secret policy et Key policy).
Là, vous devriez entrevoir pourquoi ce mécanisme de gestion des secrets peut être à responsabilité partagée. En effet, rien ne vous empêche de confier la responsabilité des différentes briques (Lambda, SecretsManager et KMS) à des personnes ou des équipes différentes. On pourrait parfaitement imaginer que votre équipe de sécurité soit responsable de l’administration des clés KMS pour l’ensemble de vos projets, que le secret soit administré par l’équipe qui en est propriétaire (par exemple l’équipe propriétaire de la base de données) et enfin la lambda par l’équipe d’un autre projet consommateur du secret.
De plus, vous pouvez également distribuer cette infrastructure sur plusieurs comptes AWS avec un compte pour les clés KMS, un autre où se trouve le secret et un dernier où se trouve le projet consommateur du secret.
Avantage bonus, en mettant en place ce type de gestion des secrets, vous aurez fait un premier pas sur le chemin de la rotation automatique des secrets. En effet, en centralisant les secrets dans SecretsManager, vous n’avez, côté client, que ce point de stockage à mettre à jour lors des rotations. Ainsi, périodiquement ou en cas de suspicion de compromission, vous pouvez le renouveler et dès le prochain appel de vos projets, tous vos consommateurs récupéreront la nouvelle version du secret.
Opter pour une gestion partagée réduit les risques d’exposition involontaire d’un secret. Pour que la valeur d’un secret puisse être récupérée par une entité non autorisée, il faut nécessairement trois choses :
- Qu’elle ait suffisamment de droits pour joindre les services SecretsManager et KMS
- Que la Resource Policy du secret soit suffisamment peu restrictive pour autoriser une identité peu ou pas identifié à y accéder
- Que la Resource Policy de la clé de chiffrement KMS soit elle aussi trop permissive
Résumé
En résumé, vous avez beaucoup à gagner à centraliser vos secrets dans un vault.
- Simplification de la gestion par la centralisation.
- Plus besoin d’envoyer le secret à une équipe pour qu’elles l’ajoutent dans leur configuration. Leur application le récupérera en direct dans le vault.
- Identification claire des consommateurs de chaque secret.
- Clarification des périmètres de responsabilité entre l’émetteur et le consommateur du secret.
- Rotation automatique plus facilement implémentable.
- Conditionnement de l’accès aux secrets. Les Resources Policies vous permettent d’ajouter des conditions pour accéder aux ressources en se basant par exemple sur l’heure et le jour, l’adresse IP source, un compte AWS d’origine, un service AWS…
- Des accès réellement temporaires aux secrets. Vous pouvez mettre une expiration de l’accès au secret dans la Resource Policy et la rotation automatique se chargera d’invalider l’ancienne valeur. (fini les accès pour faire un test qui passe ensuite en production de façon non maîtrisée)
- Les opérations Secrets Manager et KMS étant toutes deux tracées par CloudTrail, vous disposerez un historique complet des accès aux secrets pour tout besoin réglementaire et/ou de conformité.
Il peut aussi y avoir quelques points de frictions qu’il vous faudra évaluer pour déterminer si le gain est suffisant.
- La disponibilité du vault (ce critère ne doit pas être oublié durant la sélection du fournisseur de service ou du choix de l’architecture à mettre en place)
- L’intégration avec d’anciens systèmes à configuration statique (il faudra alors, si possible, dynamiser cela avec des scripts d’injection de configuration et un système de notification pour les rotations de secrets)
- Un besoin de rigueur au démarrage des projets pour que les équipes émettrices, consommatrices et de sécurité se coordonnent pour la création des accès aux secrets.
Références
https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples_cross.html
https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html
Merci pour votre lecture. Si cet article vous a plu, merci de le partager sur vos réseaux 😉
Timothée Taron - Avril, 2023
VOUS AVEZ UN PROJET ?
Audit, migration, infogérance ?
Skale-5 vous écoute : contact@skale-5.com
Nous suivre :
