Concepts AWS 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

• 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 de secret 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.

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 :

• Utilisateur unique
• Utilisateurs en alternance

Stratégie de rotation : utilisateur unique

Cette stratégie met à jour les informations d'identification d'un utilisateur dans un seul secret. L'utilisateur doit disposer de l'autorisation nécessaire pour mettre à jour son mot de passe. Il s'agit de la stratégie de rotation la plus simple, et elle 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.

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 des secrets avec les versions. Au lieu de cela, il garde une trace de la valeur précédente du secret en étiquetant cette version de secret AWSPREVIOUS. Pendant la rotation, Secrets Manager effectue également un suivi de la valeur suivante du secret en étiquetant cette version du secret AWSPENDING. Un secret a toujours une version de AWSCURRENT La version AWSCURRENT est ce que Secrets Manager renvoie lorsque vous récupérez la valeur du secret, sauf si vous spécifiez une version différente.

Vous pouvez ajouter d'autres versions avec vos propres étiquettes en utilisant UpdateSecretVersionStage dans l'AWS CLI ou un kit SDK AWS. Vous pouvez attacher jusqu'à 20 étiquettes intermédiaires à un secret. Deux versions d'un secret ne peuvent pas avoir la même étiquette intermédiaire. Si une version ne possède pas d'étiquette, Secrets Manager la considère comme obsolète. Secrets Manager supprime les versions de secrets 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, et Secrets Manager ne supprime pas les versions étiquetées.