Service Secret !

Introduction à AWS Secrets Manager
Serveurs et applications nécessitent mots de passe et secrets pour des raisons d'authentification. Lors de la migration d’une de nos applications vers le cloud AWS il y a quelques années, nous en avons profité pour ajouter plus de sécurité à notre référentiel de code en stockant nos secrets dans AWS Secrets Manager.

Qu’est-ce que Secrets Manager
Secrets Manager est un service managé AWS qui fournit un stockage sécurisé pour vos secrets (mots de passe, token d’API, token Oauth, etc.). Son objectif est de rendre les applications plus sécurisées en déplaçant le lieu de stockage des informations d'identification du code source de l'application vers un appel d'une API pour récupérer ces informations d'identification au moment de l'exécution. De cette façon, le risque de compromission est réduit si le code source de l'application est analysé en détails en cas de diffusion fortuite, et la rotation des informations d'identification est grandement facilitée sans nécessité de redéployer de nouvelles versions de l'application.
Les avantages de l'utilisation de Secrets Manager sont :

• La gestion centralisée des secrets
• Les secrets sont toujours chiffrés
• Les secrets peuvent être partagés entre les comptes
• La rotation des informations d'identification peut être automatisée selon un calendrier défini par le client
• La rotation des informations d'identification peut être appliquée automatiquement pour les services de bases de données de type RDS, DocumentDB ou Redshift. Sinon, des fonctions lambda personnalisées peuvent être implémentées et utilisées pour effectuer la rotation pour d'autres types d'identifiants.
   

Mise en œuvre dans le cadre de cette migration
Selon l'environnement (PROD, prePROD, ...), les secrets stockés dans AWS Secrets Manager sont extraits dans le pipeline CI/CD et ajoutés au fichier de configuration de l'application. De cette façon, aucun secret n’est stocké dans le référentiel de code. Grâce à la stratégie IAM, la visibilité du secret est restreinte à l'application (EC2 et Lambda) et uniquement à quelques administrateurs autorisés à créer/lire des secrets.

Pour certaines applications existantes qui sont migrées vers une architecture sans serveur basée sur AWS Lambda, leur fonctionnement est modifié afin d'accéder dynamiquement aux secrets dans Secrets Manager à partir d’une Lambda. De cette façon, les secrets ne sont stockés que dans AWS Secrets Manager et dans le cache lambda.

Création de secrets
Pour créer un secret dans le cadre de l’utilisation de Secrets Manager, il suffit de rechercher et sélectionner Secrets Manager dans la console AWS :

Choisir ensuite de stocker un nouveau secret. Les informations relatives aux coûts sont également disponibles dans la page.

 
Les choix de stockage proposés par Secrets Manager sont essentiellement liés à des bases de données. L’option “Autre type de secret” est à retenir pour ce projet.
  
Saisir une phrase de connexion à la DB, et sélectionner la clé de chiffrement que Secrets Manager utilisera pour chiffrer le secret. Toute clé créée dans AWS KMS (Key Management service) dont on a l’autorisation d’accès peut être utilisée.
 
Choisir ensuite un nom pour le secret et ajouter éventuellement une description. Il est possible de poser un Tag (une balise) sur ce secret pour une exploitation ultérieure (facturation détaillée par exemple).
 
Sur la page suivante, sélectionner la rotation automatique du secret permet d’en changer périodiquement.
 
Pour les DB AWS de type RDS, DocumentDB ou Redshift, Secrets Manager, prendra automatiquement en compte la rotation. Pour les autres cas de figure, il est nécessaire d’implémenter une fonction Lambda qui sera en charge de :

• Créer une nouvelle version du secret,
• Stocker le secret dans Secret Manager
• Configurer le service protégé pour utiliser la nouvelle version
• Vérifier la nouvelle version
• Marquer la nouvelle version : prête pour la production

L’activation de la rotation implique que la première rotation se produira immédiatement après le stockage du secret, puis interviendra ensuite selon l’intervalle défini.

L’étape finale présente une page de synthèse du secret ainsi configuré.Une fois le secret créé, sont présentés en dessous de la page de synthèse, des exemples de code pour de nombreux langages de programmation décrivant comment accéder au secret nouvellement créé.
 

Accès aux secrets
Il est possible d’accéder au secret via l’interface de ligne de commande AWS, avec la commande “get-secret-value” tout en spécifiant l’ID du secret nouvellement créé.
 
Pour accéder à tous les détails du secret sauf son contenu texte chiffré, utiliser “describe-secret”.
 
Contrôle d’accès
Plusieurs types de politiques peuvent être utilisées pour définir les accès aux secrets. Parmi toutes ces politiques, nous allons en présenter deux qui garantissent l’autorisation d’accès aux secrets aux seules personnes autorisées.

Stratégies basées sur l’identité
Également appelées stratégies IAM (Identity and Access Management), elles reposent, comme leur nom l’indique, sur les différentes permissions accordées à des identités définies. Ces permissions peuvent être gérées ou définies en ligne et attachées aux identités AIM via la console AWS ou l’interface de commande en ligne.

Ces stratégies définissent quelle identité a accès à quelle ressource. Pour ce cas de figure, elles peuvent être utilisées pour :

• Accorder à une identité l’accès à de multiples secrets
• Contrôler qui peut créer de nouveaux secrets, et qui peut accéder aux secrets qui seront créés ultérieurement
• Accorder à un groupe IAM l’accès aux secrets

Dans l’exemple ci-dessous, une stratégie a été créée qui donne à johndoe la permission d’accéder à “describeSecret” et “getSecretValue” et interdit l’accès à “get-resource-policy” pour le secret créé dev/MyTestConnectionString/SqlServer
 
Il est clair ci-dessous que l’utilisateur n’a pas l’autorisation d’exécuter la commande “getResourcePolicy”
 
Stratégies basées sur les ressources
Les stratégies basées sur les ressources sont des stratégies en ligne directement attachées aux ressources AWS. Les stratégies basées sur les ressources accordent des autorisations au mandataire spécifié dans la stratégie. Cela peut être utile par exemple pour s'assurer qu'une seule identité IAM a accès à un secret.

Dans l'exemple suivant, l'utilisateur 'johndoe' a l’autorisation d’accès aux actions "DescribeSecret", "GetSecretValue" et "GetResourcePolicy" pour le secret créé pour dev/MyTestConnectionString/SqlServer :
 
Il est clair ci-dessous que l’utilisateur s'est vu refuser l'accès à l'action "GetResourcePolicy" même si elle est explicitement autorisée dans la stratégie basée sur les ressources. Cela est dû au fait que cette action est explicitement refusée à johndoe dans la stratégie basée sur l'identité.
 
Les stratégies basées sur l'identité et sur les ressources sont évaluées ensemble pour déterminer si le mandataire effectuant la demande est autorisé ou non.

Points fondamentaux à retenir :

• Si l’un des deux types de politiques refuse explicitement l’accès, la demande sera refusée.
• Si l’un des deux types de politiques autorise explicitement l’accès et que l'autre ne l’a pas explicitement refusé, la demande est autorisée.
   

Références
https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_iam-policies.html
https://osamaoracle.com/2021/08/15/aws-iam-policy-basics/
https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html