Concepts AWS Secrets Manager - AWS Secrets Manager

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Concepts AWS Secrets Manager

Les concepts suivants sont essentiels pour comprendre le fonctionnement de Secrets Manager.

Secret

Dans Secrets Manager, un secret se compose d'informations secrètes, de la valeur de secret et de métadonnées sur le secret. Une valeur de secret peut être une chaîne ou binaire. Pour stocker plusieurs valeurs de chaîne dans un secret, nous vous recommandons d'utiliser une chaîne de texte JSON avec des paires clé/valeur, par exemple :

{ "host" : "ProdServer-01.databases.example.com", "port" : "8888", "username" : "administrator", "password" : "EXAMPLE-PASSWORD", "dbname" : "MyDatabase", "engine" : "mysql" }

Les métadonnées d'un secret comprennent :

  • Un Amazon Resource Name (ARN) avec le format suivant :

    arn:aws:secretsmanager:<Region>:<AccountId>:secret:SecretName-6RandomCharacters

    Secrets Manager inclut six caractères aléatoires à la fin du nom du secret pour garantir que l'ARN secret est unique. Si le secret d'origine est supprimé, puis est créé qu'un nouveau secret portant le même nom, les deux secrets ont des ARN différents en raison de ces caractères. Les utilisateurs ayant accès à l'ancien secret n'ont pas automatiquement accès au nouveau secret car les ARN sont différents.

  • Le nom du secret, une description, une politique de ressources et des balises.

  • L'ARN pour un clé de chiffrement, une AWS KMS key que Secrets Manager utilise pour chiffrer et déchiffrer la valeur du secret. Secrets Manager stocke toujours le texte du secret sous une forme chiffrée et chiffre le secret en transit. Voir Chiffrement et déchiffrement secrets dans AWS Secrets Manager.

  • Des informations sur la façon d'effectuer une rotation du secret, dans le cas où vous configurez la rotation. Consultez Rotation.

Secrets Manager utilise des politiques d'autorisation IAM pour garantir que seuls les utilisateurs autorisés peuvent accéder au secret ou le modifier. Consultez Authentification et contrôle d'accès pour AWS Secrets Manager.

Un secret dispose de versions qui détiennent des copies de la valeur de secret chiffrée. Lorsque vous modifiez la valeur du secret ou que ce dernier est tourné, Secrets Manager crée une nouvelle version. Consultez Version.

Vous pouvez utiliser un secret sur plusieurs Régions AWS en faisant une réplication. Lorsque vous répliquez un secret, vous créez une copie du secret primaire appelé secret de réplica ou de l'original. Le secret de réplica reste lié au secret primaire. Consultez Réplication d'un secret AWS Secrets Manager vers d'autres Régions AWS.

Consultez Création et gestion des secrets avec AWS Secrets Manager.

Version

Un secret dispose de versions qui détiennent des copies de la valeur de secret chiffrée. Lorsque vous modifiez la valeur du secret ou que ce dernier est tourné, Secrets Manager crée une nouvelle version.

Secrets Manager ne stocke pas d'historique linéaire des secrets avec les versions. Il assure plutôt le suivi de trois versions spécifiques en les étiquetant :

  • Version actuelle : AWSCURRENT

  • Version précédente : AWSPREVIOUS

  • Version en attente (pendant la rotation) : AWSPENDING

Un secret possède toujours une version étiquetée AWSCURRENT et Secrets Manager renvoie cette version par défaut lorsque vous récupérez la valeur du secret.

Vous pouvez également étiqueter les versions avec vos propres étiquettes en appelant update-secret-version-stage dans l'AWS CLI. Vous pouvez attacher jusqu'à 20 étiquettes aux versions d'un secret. Deux versions d'un secret ne peuvent pas avoir la même étiquette intermédiaire. Les versions peuvent avoir plusieurs étiquettes.

Secrets Manager ne supprime jamais les versions étiquetées, mais les versions non étiquetées sont considérées comme obsolètes. Secrets Manager supprime les versions obsolètes lorsqu'il y en a plus de 100. Secrets Manager ne supprime pas les versions créées il y a moins de 24 heures.

La figure suivante montre un secret qui contient des versions étiquetées par AWS et des versions étiquetées par le client. Les versions sans étiquette sont considérées comme obsolètes et seront supprimées ultérieurement par Secrets Manager.

Rotation

La rotation est un processus où vous mettez à jour le secret périodiquement pour rendre l'accès au informations d'identification plus difficile pour un pirate informatique. Dans Secrets Manager, vous pouvez définir la rotation automatique de vos secrets. Lorsque Secrets Manager effectue une rotation de secret, il met à jour les informations d'identification dans le secret et dans la base de données ou le service. Consultez Rotation des secrets d'AWS Secrets Manager.

Astuce

Pour certains Secrets gérés par d'autres services, vous utilisez la rotation gérée. Pour utiliser Rotation gérée, vous devez d'abord créer le secret via le service de gestion.

Stratégie de rotation

Secrets Manager propose deux stratégies de rotation :

Stratégie de rotation : utilisateur unique

Cette stratégie met à jour les informations d'identification d'un utilisateur dans un seul secret. Pour les instances Amazon RDS Db2, étant donné que les utilisateurs ne peuvent pas modifier leurs propres mots de passe, vous devez fournir des informations d'identification d'administrateur dans un secret distinct. Il s'agit de la stratégie de rotation la plus simple, qui convient à la plupart des cas d'utilisation. Nous vous recommandons en particulier d'utiliser cette stratégie pour les informations d'identification des utilisateurs ponctuels (ad hoc) ou interactifs.

Lorsque le secret effectue une rotation, les connexions de base de données ouvertes ne sont pas supprimées. Pendant la rotation, peu de temps s'écoule entre le moment où le mot de passe dans la base de données change et le moment où le secret est mis à jour. Pendant cette durée, le risque que la base de données refuse les appels utilisant les informations d'identification mises en rotation est faible. Pour pallier ce risque, vous pouvez utiliser une stratégie de nouvelle tentative appropriée. Après la rotation, les nouvelles connexions utilisent les nouvelles informations d'identification.

Stratégie de rotation : utilisateurs en alternance

Cette stratégie met à jour les informations d'identification de deux utilisateurs dans un seul secret. Vous créez le premier utilisateur et lors de la première rotation, la fonction de rotation le clone pour créer le second utilisateur. Chaque fois que le secret effectue une rotation, la fonction de rotation alterne l'utilisateur dont elle met à jour le mot de passe. Comme la plupart des utilisateurs n'ont pas l'autorisation de se cloner eux-mêmes, vous devez fournir les informations d'identification pour un superuser dans un autre secret. Nous recommandons d'utiliser la stratégie de rotation d'utilisateur unique lorsque les utilisateurs clonés de votre base de données ne disposent pas des mêmes autorisations que l'utilisateur d'origine, ainsi que pour les informations d'identification des utilisateurs ponctuels (ad hoc) ou interactifs.

Cette stratégie est appropriée pour les bases de données avec modèles d'autorisations où un rôle possède les tables de base de données et un second rôle est autorisé à accéder aux tables de la base de données. Elle convient également aux applications qui requièrent une haute disponibilité. Si une application récupère le secret pendant la rotation, elle obtient quand même un ensemble d'informations d'identification valide. Après la rotation, les informations d'identification user et user_clone sont valides. Il y a même moins de chances que les applications obtiennent un refus pendant ce type de rotation qu'avec la rotation utilisateur unique. Si la base de données est hébergée sur une batterie de serveurs où la propagation de la modification du mot de passe à tous les serveurs prend du temps, la base de données risque de refuser les appels utilisant les nouvelles informations d'identification. Pour pallier ce risque, vous pouvez utiliser une stratégie de nouvelle tentative appropriée.

Secrets Manager crée l'utilisateur cloné avec les mêmes autorisations que l'utilisateur d'origine. Si vous modifiez les autorisations de l'utilisateur d'origine après la création du clone, vous devez également modifier les autorisations de l'utilisateur cloné.

Par exemple, si vous créez un secret avec les informations d'identification d'un utilisateur de base de données, le secret contient une version avec ces informations d'identification.

Première rotation : la fonction de rotation crée un clone de votre utilisateur avec un mot de passe généré et ces informations d'identification deviennent la version actuelle du secret.

Deuxième rotation : la fonction de rotation met à jour le mot de passe de l'utilisateur d'origine.

Troisième rotation : la fonction de rotation met à jour le mot de passe de l'utilisateur cloné.