Politiques basées sur l’identité - AWS Secrets Manager
Exemple : Autorisation pour récupérer des valeurs de secrets individuelsExemple : autorisation de lire et de décrire des secrets individuelsExemple : autorisation de récupérer un groupe de valeurs secrètes dans un lotExemple : Caractères génériquesExemple : Autorisation de créer des secretsExemple : refuser une AWS KMS clé spécifique pour chiffrer des secrets

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.

Politiques basées sur l’identité

Vous pouvez associer des politiques d'autorisation aux IAMidentités : utilisateurs, groupes d'utilisateurs et rôles. Dans le cadre d'une stratégie basée sur les identités, vous spécifiez à quels secrets l'identité peut accéder et les actions que l'identité peut effectuer sur les secrets. Pour plus d'informations, consultez la section Ajouter et supprimer des autorisations IAM d'identité.

Vous pouvez accorder des autorisations à un rôle qui représente une application ou un utilisateur dans un autre service. Par exemple, une application exécutée sur une EC2 instance Amazon peut avoir besoin d'accéder à une base de données. Vous pouvez créer un IAM rôle attaché au profil d'EC2instance, puis utiliser une politique d'autorisation pour accorder au rôle l'accès au secret contenant les informations d'identification de la base de données. Pour plus d'informations, consultez Utiliser un IAM rôle pour accorder des autorisations aux applications exécutées sur des EC2 instances Amazon. Les autres services auxquels vous pouvez associer des rôles incluent Amazon Redshift et AWS LambdaAmazon. ECS

Vous pouvez également accorder des autorisations aux utilisateurs authentifiés par un système d'identité autre queIAM. Par exemple, vous pouvez associer IAM des rôles aux utilisateurs d'applications mobiles qui se connectent avec Amazon Cognito. Le rôle accorde aux informations d'identification temporaires de l'application les autorisations figurant dans la stratégie d'autorisation du rôle. Vous pouvez ensuite utiliser une stratégie d'autorisations pour accorder au rôle l'accès au secret. Pour de plus amples informations, consultez Fournisseurs d'identité et fédération.

Vous devez utiliser des stratégies basées sur les identités pour :

  • Accorder à une identité l'accès à plusieurs secrets.

  • Contrôler qui peut créer de nouveaux secrets et qui peut accéder aux secrets qui n'ont pas encore été créés.

  • Accordez à un IAM groupe l'accès aux secrets.

Exemple : Autorisation pour récupérer des valeurs de secrets individuels

Pour accorder l'autorisation de récupérer des valeurs de secrets, vous pouvez attacher des stratégies à des secrets ou des identités. Pour savoir comment déterminer le type de stratégie à utiliser, consultez Stratégies basées sur l'identité et Stratégies basées sur une ressource. Pour plus d'informations sur la façon d'attacher une stratégie, consultez Politiques basées sur les ressources et Politiques basées sur l’identité.

Cet exemple est utile lorsque vous souhaitez accorder l'accès à un IAM groupe. Pour autoriser la récupération d'un groupe de secrets lors d'un API appel par lots, voirExemple : autorisation de récupérer un groupe de valeurs secrètes dans un lot.

Exemple Lire un secret chiffré à l'aide d'une clé gérée par le client

Si un secret est chiffré à l'aide d'une clé gérée par le client, vous pouvez autoriser l'accès à la lecture du secret en attachant la politique suivante à une identité. \

{
"Version": "2012-10-17",
"Statement": [
{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "SecretARN"
},
{
  "Effect": "Allow",
  "Action": "kms:Decrypt",
  "Resource": "KMSKeyARN"
}
]
}

Exemple : autorisation de lire et de décrire des secrets individuels

Exemple Lisez et décrivez un secret

Vous pouvez accorder l'accès à un secret en attachant la stratégie suivante à une identité.

{
"Version": "2012-10-17",
"Statement": [
  {
    "Effect": "Allow",
    "Action": [
      "secretsmanager:GetSecretValue",
      "secretsmanager:DescribeSecret"
      ],
    "Resource": "SecretARN"
  }
]
}

Exemple : autorisation de récupérer un groupe de valeurs secrètes dans un lot

Exemple Lire un groupe de secrets par lots

Vous pouvez autoriser l'accès pour récupérer un groupe de secrets lors d'un API appel par lots en associant la politique suivante à une identité. La politique restreint l'appelant afin qu'il ne puisse récupérer que les secrets spécifiés par SecretARN1, SecretARN2, et SecretARN3, même si l'appel par lots inclut d'autres secrets. Si l'appelant demande également d'autres secrets lors de l'APIappel par lots, Secrets Manager ne les renverra pas. Pour plus d'informations, consultez BatchGetSecretValue. . 

{
"Version": "2012-10-17",
"Statement": [
{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:BatchGetSecretValue",
    "secretsmanager:ListSecrets"
  ],
  "Resource": "*"
},
{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Resource": [
    "SecretARN1",
    "SecretARN2",
    "SecretARN3"
    ]
}
]
}

Exemple : Caractères génériques

Vous pouvez utiliser des caractères génériques pour inclure un ensemble de valeurs dans un élément de stratégie.

Exemple Accédez à tous les secrets d'un chemin

La politique suivante autorise l'accès à la récupération de tous les secrets dont le nom commence par »TestEnv/".

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:Region:AccountId:secret:TestEnv/*"
}
}
Exemple Accédez aux métadonnées de tous les secrets

La stratégie suivante donne DescribeSecret et les autorisations commençant par List: ListSecrets et ListSecretVersionIds.

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
  "secretsmanager:DescribeSecret",
  "secretsmanager:List*"
],
"Resource": "*"
}
}
Exemple Nom du secret correspondant

La stratégie suivante accorde toutes les autorisations Secrets Manager pour un secret par nom. Pour utiliser cette stratégie, consultez Politiques basées sur l’identité.

Pour faire correspondre un nom de secret, vous créez le ARN secret en associant la région, l'identifiant du compte, le nom du secret et le caractère générique (?) pour faire correspondre des caractères aléatoires individuels. Secrets Manager ajoute six caractères aléatoires aux noms des secrets. Vous pouvez donc utiliser ce joker pour faire correspondre ces caractères. ARN Si vous utilisez la syntaxe "another_secret_name-*", Secrets Manager met en correspondance le secret souhaité avec les 6 caractères aléatoires ainsi que "another_secret_name-<anything-here>a1b2c3".

Comme vous pouvez prévoir toutes les parties d'un secret à l'exception ARN des 6 caractères aléatoires, l'utilisation de la '??????' syntaxe des caractères génériques vous permet d'accorder en toute sécurité des autorisations à un secret qui n'existe pas encore. Soyez conscient toutefois, que si vous supprimez le secret, puis le recréez avec le même nom, l'utilisateur reçoit automatiquement l'autorisation sur le nouveau secret, même si les 6 caractères ont changé. 

{
"Version": "2012-10-17",
"Statement": [
{
  "Effect": "Allow",
  "Action": "secretsmanager:*",
  "Resource": [
    "arn:aws:secretsmanager:Region:AccountId:secret:a_specific_secret_name-a1b2c3",
    "arn:aws:secretsmanager:Region:AccountId:secret:another_secret_name-??????"
  ]
}
]
}

Exemple : Autorisation de créer des secrets

Pour accorder à un utilisateur l'autorisation de créer un secret, nous vous recommandons d'associer une politique d'autorisation au IAM groupe auquel appartient l'utilisateur. Voir les groupes IAM d'utilisateurs.

Exemple Créez des secrets

La stratégie suivante autorise la création de secrets et l'affichage d'une liste de secrets. Pour utiliser cette stratégie, consultez Politiques basées sur l’identité.

{
"Version": "2012-10-17",
"Statement": [
{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:CreateSecret",
    "secretsmanager:ListSecrets"
  ],
  "Resource": "*"
}
]
}

Exemple : refuser une AWS KMS clé spécifique pour chiffrer des secrets

Important

Pour refuser une clé gérée par le client, nous vous recommandons de restreindre l'accès au moyen d'une politique de clés ou d'une attribution de clés. Pour plus d'informations, consultez la section Authentification et contrôle d'accès AWS KMS dans le guide du AWS Key Management Service développeur.

Exemple Refuser la clé AWS gérée aws/secretsmanager

La politique suivante indique comment refuser l'utilisation de la clé AWS gérée aws/secretsmanager pour créer ou mettre à jour des secrets. Cela signifie que les secrets doivent être chiffrés à l'aide d'une clé gérée par le client. Si la aws/secretsmanager clé existe, vous devez également inclure son identifiant de clé. Vous incluez également la chaîne vide car Secrets Manager l'interprète comme la clé AWS aws/secretsmanager gérée. La deuxième déclaration rejette les demandes de création de secrets qui n'incluent pas de KMS clé, car Secrets Manager l'interprète comme la clé AWS aws/secretsmanager gérée.

{
"Version": "2012-10-17",
"Statement": [
  {
      "Sid": "RequireCustomerManagedKeysOnSecrets",
      "Effect": "Deny",
      "Action": [
          "secretsmanager:CreateSecret",
          "secretsmanager:UpdateSecret"
      ],
      "Resource": "*",
      "Condition": {
          "ForAnyValue:StringLikeIfExists": {
              "secretsmanager:KmsKeyId": [
                  "*alias/aws/secretsmanager",
                  "*<key_ID_of_the_AWS_managed_key>",
                  ""
              ]
          }
      }
  },
  {
      "Sid": "RequireKmsKeyIdParameterOnCreate",
      "Effect": "Deny",
      "Action": "secretsmanager:CreateSecret",
      "Resource": "*",
      "Condition": {
          "Null": {
              "secretsmanager:KmsKeyId": "true"
          }
      }
  }
]
}