Secrets Manager et Parameter Store

Une anti-architecture courante et dangereuse consiste à stocker des secrets (mots de passe de bases de données, clés d’API, jetons OAuth) dans le code source de l’application, les variables d’environnement ou des fichiers de configuration intégrés au contrôle de version. Lorsque ces référentiels sont exposés — rendus accidentellement publics ou consultés par un attaquant — tous les secrets sont immédiatement compromis. AWS fournit deux services gérés pour éliminer ce problème : AWS Secrets Manager pour les identifiants qui nécessitent une rotation automatique, et AWS Systems Manager Parameter Store pour les valeurs de configuration et les secrets qui ne font pas l’objet d’une rotation.

AWS Secrets Manager est un service géré destiné au stockage, à la récupération et à la rotation automatique des secrets. Il chiffre tous les secrets avec KMS (par défaut à l’aide d’une clé gérée par AWS ou de votre CMK). Les secrets peuvent contenir des données structurées quelconques sous la forme d’une chaîne JSON clé-valeur. Secrets Manager facture 0,40 $ par secret et par mois, auxquels s’ajoutent 0,05 $ pour 10 000 appels d’API. Sa principale différence par rapport au magasin de paramètres est la rotation automatique intégrée pour RDS, Redshift, DocumentDB et les secrets personnalisés via des fonctions Lambda de rotation : aucune modification de l’application n’est nécessaire pendant la rotation.

La rotation automatique est la fonctionnalité la plus puissante de Secrets Manager. Pour les bases de données RDS, Secrets Manager effectue nativement la rotation des mots de passe en : 1) générant un nouveau mot de passe ; 2) mettant à jour le mot de passe de l'utilisateur de la base de données dans RDS ; 3) mettant à jour le secret avec le nouveau mot de passe ; 4) vérifiant que les nouveaux identifiants fonctionnent. Tout cela se produit pendant que votre application est en cours d'exécution — sans interruption de service ni intervention manuelle. Les applications appellent toujours get-secret-value pour récupérer le mot de passe actuel ; elles utilisent donc automatiquement les identifiants renouvelés.

Appeler Secrets Manager pour chaque requête adressée à la base de données serait coûteux et lent. La bonne pratique consiste à mettre le secret en cache localement, en mémoire, pendant une courte période. AWS fournit des clients officiels de mise en cache de Secrets Manager pour Java et Python, qui mettent les secrets en cache pendant une TTL configurable. Lorsque le cache expire, le client récupère de nouveau le secret auprès de Secrets Manager. Si une application reçoit une erreur d'authentification (indiquant que le mot de passe a été renouvelé), elle actualise immédiatement le cache et réessaie. Ce modèle offre de bonnes performances et des données à jour sans surcharger l'API Secrets Manager.

AWS Systems Manager (SSM) Parameter Store est un magasin hiérarchique clé-valeur gratuit (pour les paramètres standard) destiné aux données de configuration et aux secrets. Il prend en charge les types de paramètres String, StringList et SecureString. SecureString chiffre les valeurs avec KMS. Contrairement à Secrets Manager, Parameter Store ne prend PAS en charge la rotation automatique — il est conçu pour les valeurs de configuration qui changent peu fréquemment. Les paramètres standard sont gratuits et peuvent stocker jusqu'à 4 Ko. Les paramètres avancés prennent en charge des valeurs plus volumineuses (jusqu'à 8 Ko), des politiques de paramètres (expiration et rappels de rotation), et coûtent 0,05 $ par paramètre et par mois.

Organisez les valeurs de Parameter Store à l'aide d'une structure de chemins hiérarchique qui reflète votre environnement et l'architecture de votre application. Cela permet de créer des politiques IAM précises qui accordent l'accès aux paramètres selon un préfixe de chemin. Par exemple, vous pouvez accorder à une fonction Lambda l'accès uniquement aux paramètres situés sous /prod/payment-service/ — elle ne pourra pas accéder aux paramètres des autres services. Ce principe du moindre privilège appliqué à la configuration empêche un service compromis de lire les secrets d'un autre service.

Choisissez l'un des deux services en fonction de vos exigences : utilisez Secrets Manager lorsque vous avez besoin d'une rotation automatique des secrets, que vous stockez des identifiants de base de données, que le secret doit être partagé entre plusieurs comptes AWS ou que la conformité impose des politiques de rotation documentées. Utilisez Parameter Store lorsque vous avez besoin de valeurs de configuration (non secrètes), que vous souhaitez une solution gratuite pour un stockage clé-valeur simple, que vous avez besoin d'une configuration hiérarchique avec un contrôle d'accès fondé sur les chemins ou que vous devez stocker l'historique des versions des paramètres. De nombreuses architectures utilisent les deux : Parameter Store pour la configuration et Secrets Manager pour les identifiants.

Les fonctions Lambda et les tâches ECS doivent récupérer les secrets au démarrage, et non à chaque invocation. Pour Lambda : récupérez les secrets dans le code d'initialisation (en dehors de la fonction gestionnaire) et mettez-les en cache dans des variables globales — l'environnement d'exécution Lambda persiste entre les invocations, de sorte que les secrets ne sont récupérés qu'une seule fois pendant la durée de vie de chaque environnement. Pour ECS : utilisez le champ secrets dans la définition de tâche pour injecter les valeurs de Secrets Manager ou les SecureStrings de Parameter Store en tant que variables d'environnement — ECS les récupère et les injecte au lancement de la tâche, sans aucune modification du code de l'application.

Une utilisation pratique, mais souvent négligée, de Parameter Store consiste à stocker les ID d'AMI et autres références de déploiement. Au lieu d'inscrire les ID d'AMI en dur dans vos modèles CloudFormation (qui deviennent obsolètes lorsque de nouvelles AMI sont publiées), référencez une valeur de Parameter Store. Votre pipeline CI/CD met à jour l'ID d'AMI dans Parameter Store chaque fois qu'une nouvelle AMI de référence est créée. CloudFormation lit l'ID d'AMI le plus récent dans Parameter Store au moment du déploiement. AWS publie également les ID des dernières AMI Amazon Linux dans des chemins publics de Parameter Store que vous pouvez référencer directement.

La gouvernance des secrets exige de savoir qui y a accédé et à quel moment. AWS CloudTrail enregistre chaque appel d'API à Secrets Manager et Parameter Store : GetSecretValue, PutParameter, GetParameter. Vous disposez ainsi d'une piste d'audit complète pour la conformité. Utilisez les alarmes CloudWatch sur les métriques CloudTrail pour vous alerter lorsque des secrets sont consultés selon des schémas inhabituels — par exemple, si un secret de production est consulté depuis un principal IAM inhabituel ou depuis une adresse IP qui ne se trouve pas dans votre plage connue, déclenchez une alerte afin d'effectuer une investigation.

Dans les architectures à plusieurs comptes, les applications d'un compte ont parfois besoin de secrets gérés dans un autre compte (par exemple, un compte Security central gère tous les mots de passe RDS). Les politiques de ressources de Secrets Manager autorisent l'accès entre comptes. Configurez une politique fondée sur les ressources sur le secret afin d'accorder à un rôle du compte consommateur l'autorisation d'appeler GetSecretValue. Le rôle du compte consommateur doit également disposer d'une politique IAM autorisant les appels vers l'ARN du secret. Les politiques de clé KMS doivent aussi accorder au compte consommateur l'accès à la CMK utilisée pour chiffrer le secret.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : Secrets Manager fournit une rotation automatique pour les identifiants de bases de données et les clés d'API, et constitue le choix privilégié pour les secrets qui doivent être renouvelés ; Parameter Store fournit un stockage de configuration hiérarchique gratuit avec un contrôle d'accès IAM fondé sur les chemins ; et ECS et Lambda peuvent injecter des secrets en tant que variables d'environnement sans modifier le code de l'application. CloudTrail fournit des pistes d'audit pour tous les accès aux secrets. Nous allons maintenant étudier WAF, Shield et Network Firewall.