Exemples de politiques d'autorisation pour AWS Secrets Manager - 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 secretsExemple : Autorisations et VPCExemple : Contrôler l'accès aux secrets à l'aide de balisesExemple : Limiter l'accès aux identités avec des balises qui correspondent à celles des secretsExemple : Principal du service

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.

Exemples de politiques d'autorisation pour AWS Secrets Manager

Une stratégie d'autorisations est un texte structuré au format JSON. Consultez Structure d'un document de stratégie JSON.

Les stratégies d'autorisations que vous attachez aux ressources et aux identités sont très similaires. Voici quelques-uns des éléments à inclure dans une stratégie d'accès aux secrets :

  • Principal : à qui accorder l'accès. Voir Spécification d'un principal dans le Guide de l'utilisateur IAM. Lorsque vous attachez une stratégie à une identité, vous n'incluez pas d'élément Principal dans la stratégie.

  • Action : ce qu'ils peuvent faire. Voir Action Secrets Manager.

  • Resource : les secrets auxquels ils peuvent accéder. veuillez consulter Secrets Manager.

    Le caractère générique (*) a une signification différente en fonction de ce qui est attaché la stratégie :

    • Dans une stratégie attachée à un secret, * signifie que la police s'applique à ce secret.

    • Dans une stratégie attachée à une identité, * signifie que la stratégie s'applique à toutes les ressources, y compris les secrets du compte.

Pour attacher une stratégie à un secret, consultez Attacher une stratégie d'autorisation à un secret AWS Secrets Manager.

Pour attacher une stratégie à une identité, consultez Attacher une stratégie d'autorisation à une identité.

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 Attacher une stratégie d'autorisation à un secret AWS Secrets Manager et Attacher une stratégie d'autorisation à une identité.

Les exemples suivants montrent deux manières d'accorder un accès à un secret. Le premier exemple est une stratégie basée sur la ressource que vous pouvez attacher à un secret. Cet exemple est utile lorsque vous souhaitez accorder à plusieurs utilisateurs ou rôles l'accès à un secret unique. Le deuxième exemple est une stratégie basée sur l'identité que vous pouvez attacher à un utilisateur ou un rôle dans IAM. Cet exemple est utile lorsque vous souhaitez accorder un accès à un groupe IAM. Pour autoriser la récupération d'un groupe de secrets lors d'un appel d'API par lots, consultez Exemple : autorisation de récupérer un groupe de valeurs secrètes dans un lot.

Exemple Lire un secret (attacher à un secret)

Vous pouvez accorder à un secret l'accès en attachant la stratégie suivante au secret. Pour utiliser cette stratégie, consultez Attacher une stratégie d'autorisation à un secret AWS Secrets Manager.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::AccountId:role/EC2RoleToAccessSecrets"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}
Exemple Lecture d'un secret chiffré à l'aide d'une clé gérée par le client (attacher à l'identité)

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 stratégie suivante à une identité. Pour utiliser cette stratégie, consultez Attacher une stratégie d'autorisation à 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 (attachez-le à une identité)

Vous pouvez accorder l'accès à un secret en attachant la stratégie suivante à une identité. Pour utiliser cette stratégie, consultez Attacher une stratégie d'autorisation à 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 dans un lot (attacher à l'identité)

Vous pouvez accorder l'accès pour récupérer un groupe de secrets dans un appel d'API par lots en attachant la stratégie 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'appel d'API par lots, Secrets Manager ne les renverra pas. Pour plus d'informations, consultez BatchGetSecretValue. . Pour utiliser cette stratégie, consultez Attacher une stratégie d'autorisation à une identité. 

{
  "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éder à tous les secrets dans un chemin (attacher à l'identité)

La politique suivante autorise l'accès à la récupération de tous les secrets dont le nom commence par « TestEnv/». Pour utiliser cette stratégie, consultez Attacher une stratégie d'autorisation à une identité.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "arn:aws:secretsmanager:Region:AccountId:secret:TestEnv/*"
  }
}
Exemple Accéder aux métadonnées sur tous les secrets (attacher à l'identité)

La stratégie suivante donne DescribeSecret et les autorisations commençant par List: ListSecrets et ListSecretVersionIds. Pour utiliser cette stratégie, consultez Attacher une stratégie d'autorisation à une identité.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "secretsmanager:DescribeSecret",
      "secretsmanager:List*"
    ],
    "Resource": "*"
  }
}
Exemple Correspondance du nom du secret (attacher à l'identité)

La stratégie suivante accorde toutes les autorisations Secrets Manager pour un secret par nom. Pour utiliser cette stratégie, consultez Attacher une stratégie d'autorisation à une identité.

Pour faire correspondre un nom du secret, créez l'ARN pour le secret en regroupant la région, l'ID de compte, le nom du secret et le caractère générique (?) pour faire correspondre les caractères aléatoires individuels. Secrets Manager ajoute six caractères aléatoires aux noms du secret dans leur ARN, de à ce que vous puissiez utiliser ce caractère générique pour faire correspondre ces caractères. 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 il est possible de prévoir toutes les parties de l'ARN d'un secret, à l'exception des 6 caractères aléatoires, l'utilisation de la syntaxe '??????' de caractère générique 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, il est conseillé d'attacher une stratégie d'autorisations à un groupe IAM auquel l'utilisateur appartient. Voir Groupes d'utilisateurs IAM.

Exemple Créer des secrets (attacher à l'identité)

La stratégie suivante autorise la création de secrets et l'affichage d'une liste de secrets. Pour utiliser cette stratégie, consultez Attacher une stratégie d'autorisation à une 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, voir 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 (attacher à l'identité)

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 clé KMS, 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"
              }
          }
      }
  ]
}

Exemple : Autorisations et VPC

Si vous devez accéder à Secrets Manager à partir d'un VPC, vous devez vérifier que les demandes adressées à Secrets Manager proviennent du VPC en incluant une condition dans vos stratégies d'autorisations. Pour de plus amples informations, consultez Conditions de point de terminaison VPC et Utilisation d'un point de terminaison d'un VPC AWS Secrets Manager.

Assurez-vous que les demandes d'accès au secret provenant d'autres AWS services proviennent également du VPC, sinon cette politique leur refusera l'accès.

Exemple Exiger que les demandes passent par un point de terminaison d'un VPC (attacher au secret)

La stratégie de secret suivante autorise un utilisateur à effectuer des opérations dans Secrets Manager uniquement lorsque la requête provient du point de terminaison d'un VPC spécifié vpce-1234a5678b9012c. Pour utiliser cette stratégie, consultez Attacher une stratégie d'autorisation à un secret AWS Secrets Manager.

{
  "Id": "example-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictGetSecretValueoperation",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": "vpce-1234a5678b9012c"
        }
      }
    }
  ]
}
Exemple Exiger que les demandes proviennent d'un VPC (attacher au secret)

La stratégie de secret suivante autorise les commandes à créer et gérer les secrets uniquement lorsqu'ils proviennent de vpc-12345678. En outre, la stratégie autorise les opérations qui utilisent l'accès à la valeur chiffrée du secret uniquement lorsque les demandes proviennent de vpc-2b2b2b2b. Vous pouvez utiliser une stratégie comme celle-ci si vous exécutez une application dans un VPC, mais que vous utilisez un second VPC isolé pour les fonctions de gestion. Pour utiliser cette stratégie, consultez Attacher une stratégie d'autorisation à un secret AWS Secrets Manager.

{
  "Id": "example-policy-2",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAdministrativeActionsfromONLYvpc-12345678",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "secretsmanager:Create*",
        "secretsmanager:Put*",
        "secretsmanager:Update*",
        "secretsmanager:Delete*",
        "secretsmanager:Restore*",
        "secretsmanager:RotateSecret",
        "secretsmanager:CancelRotate*",
        "secretsmanager:TagResource",
        "secretsmanager:UntagResource"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpc": "vpc-12345678"
        }
      }
    },
    {
      "Sid": "AllowSecretValueAccessfromONLYvpc-2b2b2b2b",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpc": "vpc-2b2b2b2b"
        }
      }
    }
  ]
}

Exemple : Contrôler l'accès aux secrets à l'aide de balises

Vous pouvez utiliser des balises pour contrôler l'accès à vos secrets. Le fait d'utiliser des balises pour contrôler les autorisations est utile dans les environnements qui connaissent une croissance rapide et pour les cas où la gestion des stratégies devient fastidieuse. Une des stratégie consiste à attacher des balises à des secrets, puis à accorder des autorisations à une identité lorsqu'un secret a une balise spécifique.

Exemple Autoriser l'accès aux secrets avec une balise spécifique (attacher à une identité)

La politique suivante n'autorise DescribeSecret pas les secrets dotés d'une balise avec la clé « ServerName» et la valeur « ServerABC ». Pour utiliser cette stratégie, consultez Attacher une stratégie d'autorisation à une identité.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "secretsmanager:DescribeSecret",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "secretsmanager:ResourceTag/ServerName": "ServerABC"
      }
    }
  }
}

Exemple : Limiter l'accès aux identités avec des balises qui correspondent à celles des secrets

Une des stratégie consiste à attacher des balises aux secrets ainsi qu'aux identités IAM. Vous devez ensuite créer des stratégies d'autorisations pour autoriser des opérations lorsque la balise de l'identité correspond à celle du secret. Pour un didacticiel complet, consultez Définition des autorisations d'accès aux secrets en fonction des identifications.

Le fait d'utiliser des balises pour contrôler les autorisations est utile dans les environnements qui connaissent une croissance rapide et pour les cas où la gestion des stratégies devient fastidieuse. Pour plus d'informations, consultez Présentation d'ABAC pour AWS.

Exemple Autoriser l'accès aux rôles ayant les mêmes balises que les secrets (attacher à un secret)

La politique suivante accorde l'autorisation GetSecretValue au compte 123456789012 uniquement si l'identification AccessProject a la même valeur pour le secret et le rôle. Pour utiliser cette stratégie, consultez Attacher une stratégie d'autorisation à un secret AWS Secrets Manager.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "123456789012"
    },
    "Condition": {
      "StringEquals": {
        "aws:ResourceTag/AccessProject": "${ aws:PrincipalTag/AccessProject }"
      }
    },
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "*"
  }
}

Exemple : Principal du service

Si la politique de ressources attachée à votre secret inclut un principal de AWS service, nous vous recommandons d'utiliser les clés de condition SourceAccount globales aws : SourceArn et aws :. Les valeurs ARN et compte sont incluses dans le contexte d'autorisation uniquement lorsqu'une demande arrive à Secrets Manager depuis un autre service AWS . Cette combinaison de conditions permet d'éviter un possible scénario du député confus.

Si un ARN de ressources inclut des caractères non autorisés dans une politique de ressource, vous ne pouvez pas utiliser cet ARN de ressource dans la valeur de la clé de condition aws:SourceArn. Utilisez à la place la clé de condition aws:SourceAccount. Pour plus d'informations, consultez les conditions IAM.

Les principaux de service ne sont généralement pas utilisés comme principes dans une politique attachée à un secret, mais certains AWS services l'exigent. Pour plus d'informations sur les politiques de ressources qu'un service vous demande d'attacher à un secret, consultez la documentation du service.

Exemple Autorisation d'un service à accéder à un secret en utilisant un principal de service (attacher à un secret)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "service-name.amazonaws.com"
        ]
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:sourceArn": "arn:aws:service-name::123456789012:*"
        },
        "StringEquals": {
          "aws:sourceAccount": "123456789012"
        }
      }

    }
  ]
}