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é
Attachez les stratégies d'autorisation aux identités[IAM : utilisateurs, groupes et rôles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html). 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 de plus amples informations, consulter [Ajout et suppression d'autorisations d'identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
Vous pouvez accorder des autorisations à un rôle qui représente une application ou un utilisateur dans un autre service. Par exemple, une application s'exécutant sur une instance EC2 Amazon EC2 peut avoir besoin d'un accès à une base de données. Vous pouvez créer un rôle IAM attaché au profil d'instance EC2, puis utiliser une stratégie d'autorisations pour accorder au rôle l'accès au secret contenant les informations d'identification pour la base de données. Pour plus d'informations, consultez [Utilisation d'un rôle IAM pour accorder des autorisations à des applications s'exécutant sur des instances Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html). Les autres services auxquels vous pouvez attacher des rôles incluent [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/c-getting-started-using-spectrum.html), [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-permissions.html), et [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html).
Vous pouvez aussi accorder des autorisations aux utilisateurs authentifiés par un système d'identité autre qu'IAM. Par exemple, vous pouvez associer des rôles IAM 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html).
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.
+ Accorder à un groupe IAM l'accès aux secrets.
**Topics**
+ [Exemple : Autorisation pour récupérer des valeurs de secrets individuels](#auth-and-access_examples_identity_read)
+ [Exemple : autorisation de lire et de décrire des secrets individuels](#auth-and-access_examples-read-and-describe)
+ [Exemple : autorisation de récupérer un groupe de valeurs secrètes dans un lot](#auth-and-access_examples_batch)
+ [Exemple : Caractères génériques](#auth-and-access_examples_wildcard)
+ [Exemple : Autorisation de créer des secrets](#auth-and-access_examples_create)
+ [Exemple : refuser une AWS KMS clé spécifique pour chiffrer des secrets](#auth-and-access_examples_kmskey)
## 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html). Pour plus d'informations sur la façon d'attacher une stratégie, consultez [Politiques basées sur les ressources](auth-and-access_resource-policies.md) et [Politiques basées sur l’identité](#auth-and-access_iam-policies).
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](#auth-and-access_examples_batch).
**Example 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é. \$1
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf"
},
{
"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": "arn:aws:kms:us-east-1:123456789012:key/key-id"
}
]
}
```
## Exemple : autorisation de lire et de décrire des secrets individuels
**Example 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": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf"
}
]
}
```
## Exemple : autorisation de récupérer un groupe de valeurs secrètes dans un lot
**Example Lire un groupe de secrets par lots**
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*, et *SecretARN2**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`.](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_BatchGetSecretValue.html) .
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:BatchGetSecretValue",
"secretsmanager:ListSecrets"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName1-AbCdEf",
"arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName2-AbCdEf",
"arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName3-AbCdEf"
]
}
]
}
```
## 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.
**Example 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:us-east-1:123456789012:secret:TestEnv/*"
}
}
```
**Example 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": "*"
}
}
```
**Example 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é](#auth-and-access_iam-policies).
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-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:us-east-1:123456789012:secret:a_specific_secret_name-a1b2c3",
"arn:aws:secretsmanager:us-east-1:123456789012: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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html).
**Example 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é](#auth-and-access_iam-policies).
****
```
{
"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 [Authentification et contrôle d’accès pour AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) dans le *Guide du développeur AWS Key Management Service *.
**Example Refuser la clé AWS gérée `aws/secretsmanager`**
La politique suivante interdit l'utilisation du Clé gérée par AWS `aws/secretsmanager` pour créer ou mettre à jour des secrets. Cette politique exige que les secrets soient chiffrés à l'aide d'une clé gérée par le client. La stratégie comprend deux déclarations :
1. La première déclaration`Sid: "RequireCustomerManagedKeysOnSecrets"`, refuse les demandes de création ou de mise à jour de secrets à l'aide du Clé gérée par AWS `aws/secretsmanager`.
1. La deuxième déclaration`Sid: "RequireKmsKeyIdParameterOnCreate"`, refuse les demandes de création de secrets qui n'incluent pas de clé KMS, car Secrets Manager utiliserait par défaut le Clé gérée par AWS `aws/secretsmanager`.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RequireCustomerManagedKeysOnSecrets",
"Effect": "Deny",
"Action": [
"secretsmanager:CreateSecret",
"secretsmanager:UpdateSecret"
],
"Resource": "*",
"Condition": {
"StringLikeIfExists": {
"secretsmanager:KmsKeyArn": ""
}
}
},
{
"Sid": "RequireKmsKeyIdParameterOnCreate",
"Effect": "Deny",
"Action": "secretsmanager:CreateSecret",
"Resource": "*",
"Condition": {
"Null": {
"secretsmanager:KmsKeyArn": "true"
}
}
}
]
}
```