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.
# Référence de l’élément de politique JSON IAM
Les documents de politique JSON se composent d'éléments. Les éléments sont répertoriés dans l'ordre général d'utilisation dans une politique. L'ordre des éléments n'a pas d'importance. Par exemple, l'élément `Resource` peut venir avant l'élément `Action`. Il n'est pas nécessaire de spécifier d'éléments `Condition` dans une politique. Pour en savoir plus sur la structure générale et la fonction d'un document de politique JSON, consultez [Présentation des politiques JSON](access_policies.md#access_policies-json).
Certains éléments de politique JSON s'excluent mutuellement. Cela signifie que vous ne pouvez pas créer une politique qui les utilise ensemble. Par exemple, vous ne pouvez pas utiliser `Action` et `NotAction` dans la même instruction de politique. Les autres paires qui s'excluent mutuellement sont notamment `Principal`/`NotPrincipal` et `Resource`/`NotResource`.
Les détails inclus dans une politique varient pour chaque service, selon les actions autorisées par le service, les types de ressources qu'il contient, etc. Lorsque vous créez des politiques pour un service spécifique, il peut être utile de consulter des exemples de stratégie pour ce service. Pour consulter la liste de tous les services prenant en charge IAM et pour obtenir des liens vers la documentation de ces services relative à IAM et aux politiques, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md).
Lorsque vous créez ou modifiez une politique JSON, IAM peut effectuer une validation de politique pour vous aider à créer une politique efficace. IAM identifie les erreurs de syntaxe JSON, tandis que IAM Access Analyzer fournit des vérifications de politique supplémentaires avec des recommandations pour vous aider à affiner vos politiques. Pour en savoir plus sur la validation de politiques, veuillez consulter [Validation de politique IAM](access_policies_policy-validator.md). Pour en savoir plus sur les vérifications des politiques IAM Access Analyzer et les recommandations exploitables, veuillez consulter [Validation de politique IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html).
**Topics**
+ [Version](reference_policies_elements_version.md)
+ [Id](reference_policies_elements_id.md)
+ [Statement](reference_policies_elements_statement.md)
+ [Sid](reference_policies_elements_sid.md)
+ [Effect](reference_policies_elements_effect.md)
+ [Principal](reference_policies_elements_principal.md)
+ [NotPrincipal](reference_policies_elements_notprincipal.md)
+ [Action](reference_policies_elements_action.md)
+ [NotAction](reference_policies_elements_notaction.md)
+ [Resource](reference_policies_elements_resource.md)
+ [NotResource](reference_policies_elements_notresource.md)
+ [Condition](reference_policies_elements_condition.md)
+ [Variables et balises](reference_policies_variables.md)
+ [Types de données pris en charge](reference_policies_elements_datatypes.md)
# Éléments de politique JSON IAM : Version
**Remarque pour lever l'ambiguïté**
Cet élément de politique JSON `Version` ne représente pas la même chose qu'une *version de politique*. L'élément de politique `Version` est utilisé dans une politique pour définir la version de la langue de la politique. En revanche, une version de politique est créée lorsque vous apportez des modifications à une politique gérée par le client dans IAM. La politique modifiée ne remplace pas la politique existante. À la place, IAM crée une nouvelle version de la politique gérée. Si vous recherchez des informations sur les différentes versions prises en charge qui sont disponibles pour les politiques gérées, consultez [Gestion des versions des politiques IAM](access_policies_managed-versioning.md).
L'élément de politique `Version` spécifie les règles de syntaxe de langage qui doivent être utilisées pour traiter une politique. Pour utiliser toutes les fonctions de politique disponibles, incluez l'élément `Version` suivant **à l'extérieur de** l'élément `Statement` dans toutes vos politiques.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}
```
------
IAM prend en charge les valeurs d'élément `Version` suivantes :
+ `2012-10-17`. Il s'agit de la version actuelle du langage de politique ; vous devez toujours inclure un élément `Version` et définir sa valeur sur `2012-10-17`. Sinon, vous ne pouvez pas utiliser des fonctions telles que les [variables de politique](reference_policies_variables.md) qui ont été introduites avec cette version.
+ `2008-10-17`. Ceci est une version antérieure du langage de politique. Elle peut figurer dans des politiques existantes antérieures. N'utilisez pas cette version pour les nouvelles politiques ou lors de la mise à jour de politiques existantes. Les nouvelles fonctions, telles que les variables de politique, ne fonctionneront pas avec votre politique. Par exemple, les variables telles que `${aws:username}` ne sont pas reconnues et sont traitées comme des chaînes littérales dans la politique.
# Éléments de politique JSON IAM : Id
L'élément `Id` spécifie un identifiant facultatif pour la politique. L'ID est utilisé de différentes façons, selon les services. L'ID est autorisé dans les politiques basées sur les ressources, mais pas dans celles basées sur une identité.
Dans le cas de services vous permettant de définir un élément `ID`, il est recommandé d'utiliser un UUID (GUID) comme valeur, ou d'incorporer un UUID dans l'ID pour en garantir l'unicité.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "cd3ad3d9-2776-4ef1-a904-4c229d1642ee",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}
```
------
**Note**
Certains AWS services (par exemple, Amazon SQS ou Amazon SNS) peuvent nécessiter cet élément et avoir des exigences d'unicité pour celui-ci. Pour obtenir des informations spécifiques à chaque service sur la création de politiques, reportez-vous à la documentation du service que vous utilisez.
# Éléments de politique JSON IAM : Statement
L'élément `Statement` constitue l'élément principal d'une politique. Cet élément est obligatoire. L'élément `Statement` peut contenir une seule instruction ou un tableau d'instructions. Chaque bloc d'instruction doit être placé entre accolades \$1 \$1. Pour plusieurs instructions, le tableau doit être placé entre crochets [ ].
```
"Statement": [{...},{...},{...}]
```
L'exemple suivant illustre une politique qui contient un tableau de trois instructions dans un même élément `Statement`. (La politique vous permet d'accéder à votre propre « dossier principal » dans la console Amazon S3.) La politique inclut la variable `aws:username`, qui est remplacée par le nom utilisateur provenant de la demande lors de l'évaluation de la politique. Pour de plus amples informations, veuillez consulter [Introduction](reference_policies_variables.md#policy-vars-intro).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {"StringLike": {"s3:prefix": [
"",
"home/",
"home/${aws:username}/"
]}}
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}",
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}/*"
]
}
]
}
```
------
# Éléments de politique JSON IAM : Sid
Vous pouvez fournir un `Sid` (ID d’instruction) en tant qu’identifiant facultatif pour l’instruction de politique. Vous pouvez affecter une valeur `Sid` à chaque instruction d'un tableau de instructions. Vous pouvez utiliser la valeur `Sid` comme description de l'instruction de politique. Dans un service qui vous permet de spécifier un élément `ID` tel que SQS et SNS, la valeur `Sid` est un simple sous-identifiant de l'ID du document de politique. Dans IAM, la valeur `Sid` doit être unique dans une politique JSON.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExampleStatementID",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}
```
------
L'élément `Sid` prend en charge les majuscules ASCII (A à Z), les minuscules (a à z) et les chiffres (0 à 9).
IAM n'expose pas le `Sid` dans l'API IAM. Il n'est pas possible d'extraire une instruction spécifique en vous basant sur cet ID.
**Note**
Certains AWS services (par exemple, Amazon SQS ou Amazon SNS) peuvent nécessiter cet élément et avoir des exigences d'unicité pour celui-ci. Pour obtenir des informations spécifiques à chaque service sur la création de politiques, reportez-vous à la documentation du service que vous utilisez.
# Éléments de politique JSON IAM : Effect
L'élément `Effect` est requis ; il spécifie si l'instruction génère une autorisation ou un refus explicite. Les valeurs valides pour `Effect` sont `Allow` et `Deny`. La valeur `Effect` est sensible à la casse.
```
"Effect":"Allow"
```
Par défaut, l'accès aux ressources est refusé. Pour autoriser l'accès à une ressource, vous devez définir l'élément `Effect` sur `Allow`. Pour remplacer une autorisation (par exemple, pour remplacer une autorisation qui autrement est en vigueur), vous définissez l'élément `Effect` sur `Deny`. Pour de plus amples informations, veuillez consulter [Logique d'évaluation de politiques](reference_policies_evaluation-logic.md).
# AWS Éléments de politique JSON : Principal
Utilisez l'élément `Principal` dans une politique JSON basée sur les ressources pour spécifier le principal qui est autorisé ou non à accéder à une ressource.
Vous devez utiliser l'élément `Principal` dans les [politiques basées sur les ressources](access_policies_identity-vs-resource.md). Plusieurs services prennent en charge les politiques basées sur les ressources, y compris IAM. Le type de politique basée sur les ressources IAM est une politique d'approbation de rôle. Dans les rôles IAM, utilisez l'élément `Principal` dans la politique d'approbation du rôle pour spécifier qui peut endosser le rôle. Lorsqu'il s'agit d'un accès entre comptes, vous devez spécifier l'identifiant à 12 chiffres du compte approuvé. Pour savoir si les principaux des comptes situés en dehors de votre zone de confiance (organisation ou compte de confiance) ont accès à vos rôles, consultez [Qu'est-ce que l'Analyseur d'accès IAM ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).
**Note**
Après avoir créé le rôle, vous pouvez remplacer le compte par « \$1 » pour autoriser tout le monde à endosser le rôle. Dans ce cas, nous vous recommandons vivement de limiter les personnes autorisées à accéder au rôle d'une autre manière, par exemple avec un élément `Condition` qui limite l'accès à certaines adresses IP. Votre rôle ne doit pas être accessible à n'importe qui \$1
D'autres exemples de ressources prenant en charge les politiques basées sur les ressources incluent un compartiment Amazon S3 ou une interface AWS KMS key.
Vous ne pouvez pas utiliser l'élément `Principal` dans une politique basée sur l'identité. Les politiques basées sur l'identité sont des politiques d'autorisations que vous attachez aux identités IAM (utilisateur, groupes ou rôles) . Dans ces cas, le principal est implicitement l'identité à laquelle est attachée la politique.
**Topics**
+ [Comment spécifier un principal](#Principal_specifying)
+ [Compte AWS principes](#principal-accounts)
+ [Principaux de rôles IAM](#principal-roles)
+ [Principaux de séance de rôle](#principal-role-session)
+ [Principaux fédérés OIDC](#principal-federated-web-identity)
+ [Principaux fédérés SAML](#principal-saml)
+ [Principaux de l'utilisateur IAM](#principal-users)
+ [Principaux d'IAM Identity Center](#principal-identity-users)
+ [AWS STS principes d'utilisateurs fédérés](#sts-session-principals)
+ [AWS principes de service](#principal-services)
+ [AWS principes de service dans les régions adhérentes](#principal-services-in-opt-in-regions)
+ [Tous les principaux](#principal-anonymous)
+ [En savoir plus](#Principal_more-info)
## Comment spécifier un principal
Vous spécifiez un principal dans l'élément `Principal` d'une politique basée sur les ressources ou des clés de condition prenant en charge les principaux.
Vous pouvez spécifier l'un des principaux suivants dans une politique :
+ Compte AWS et utilisateur root
+ Rôles IAM
+ Séances de rôle
+ Utilisateurs IAM
+ principaux d’utilisateur fédéré
+ AWS services
+ Tous les principaux
Vous ne pouvez pas identifier un groupe d'utilisateurs en tant que principal dans une politique (telle qu'une politique basée sur les ressources), car les groupes concernent les autorisations, et non l'authentification, et les principaux sont des entités IAM authentifiées.
Vous pouvez spécifier plus d'un principal pour chacun des types de principaux dans les sections suivantes, à l'aide d'un tableau. Les tableaux peuvent inclure une ou plusieurs valeurs. Lorsque vous spécifiez plus d'un principal dans un élément, vous accordez des autorisations à chaque principal. Ceci est un `OR` logique et non un `AND` logique, car vous êtes authentifié comme un unique principal à la fois. Si vous incluez plus d'une valeur, utilisez des crochets (`[` et `]`) et délimitez chaque entrée du tableau par une virgule. L'exemple de politique suivant définit les autorisations pour le compte 123456789012 ou le compte 555555555555.
```
"Principal" : {
"AWS": [
"123456789012",
"555555555555"
]
}
```
**Note**
Vous ne pouvez pas utiliser un caractère générique pour faire correspondre une partie d'un nom de principal ou d'un ARN.
## Compte AWS principes
Vous pouvez spécifier Compte AWS des identifiants dans l'`Principal`élément d'une politique basée sur les ressources ou dans des clés de condition qui prennent en charge les principaux. Cela délègue l'autorité sur le compte. Lorsque vous autorisez l'accès à un autre compte, un administrateur de ce compte doit alors accorder l'accès à une identité (utilisateur ou rôle IAM) de ce compte. Lorsque vous spécifiez un Compte AWS, vous pouvez utiliser l'ARN du compte (arn:aws:iam : ::root*account-ID*) ou une forme abrégée composée du préfixe suivi de l'identifiant du compte. `"AWS":`
Par exemple, soit un ID de compte `123456789012`, vous pouvez utiliser l'une des méthodes suivantes pour spécifier ce compte dans l'élément `Principal` :
```
"Principal": { "AWS": "arn:aws:iam::123456789012:root" }
```
```
"Principal": { "AWS": "123456789012" }
```
L'ARN du compte et l'ID de compte abrégé se comportent de la même manière. Les deux délèguent des autorisations au compte. L'utilisation de l'ARN du compte dans l'élément `Principal` ne limite pas les autorisations au seul utilisateur racine du compte.
**Note**
Lorsque vous enregistrez une politique basée sur les ressources qui inclut l'ID du compte abrégé, le service peut le convertir en ARN principal. Cela ne modifie pas la fonctionnalité de la politique.
Certains AWS services proposent des options supplémentaires pour spécifier un principal de compte. Par exemple, Amazon S3 vous permet de spécifier un [ID d'utilisateur canonique](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId) à l'aide du format suivant :
```
"Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }
```
Vous pouvez également en spécifier plusieurs Compte AWS(ou ID utilisateur canonique) en tant que principal à l'aide d'un tableau. Par exemple, vous pouvez spécifier un principal dans une politique de compartiment à l'aide des trois méthodes.
```
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:root",
"999999999999"
],
"CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be"
}
```
## Principaux de rôles IAM
Vous pouvez spécifier le rôle principal IAM ARNs dans l'`Principal`élément d'une politique basée sur les ressources ou dans des clés de condition qui prennent en charge les principaux. Les rôles IAM sont des identités. Dans IAM, les identités sont des ressources auxquelles vous pouvez attribuer des autorisations. Les rôles font confiance à une autre identité authentifiée pour endosser ce rôle. Il s'agit notamment d'un principal dans l’interface AWS ou d'un utilisateur provenant d'un fournisseur d'identité externe (IdP). Lorsqu'un principal ou une identité endosse un rôle, ils reçoivent des informations d'identification de sécurité temporaires avec les autorisations du rôle endossé. Lorsqu'ils utilisent ces informations d'identification de session pour effectuer des opérations AWS, ils jouent *le rôle principal de session*.
Lorsque vous spécifiez un principal de rôle dans une politique basée sur les ressources, les autorisations effectives du principal sont limitées par tous les types de politique limitant les autorisations pour le rôle. Cela inclut les politiques de séance et les limites d'autorisations. Pour plus d’informations sur l'évaluation des autorisations effectives pour une séance de rôle, veuillez consulter [Logique d'évaluation de politiques](reference_policies_evaluation-logic.md).
Pour spécifier l'ARN du rôle dans l'élément `Principal`, utilisez le format suivant :
```
"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }
```
**Important**
Si votre élément `Principal` dans une politique d’approbation de rôle contient un ARN qui pointe vers un rôle IAM spécifique, alors cet ARN se transforme en l’ID principal unique du rôle lorsque vous enregistrez la politique. Cela permet de réduire le risque d'escalade des privilèges par la suppression et la nouvelle création du rôle. Normalement, vous ne voyez pas cet ID dans la console, car IAM utilise une transformation inverse pour revenir au rôle ARN lorsque la politique d'approbation est affichée. Cependant, si vous supprimez le rôle, vous interrompez la relation. La politique ne s'applique plus, même si vous recréez le rôle, étant donné que le nouvel ID du principal du nouveau rôle ne correspond pas à l'ID stocké dans la politique d'approbation. Dans ce cas, l'ID principal apparaît dans les politiques basées sur les ressources, car il n'est plus AWS possible de le mapper à un ARN valide. Le résultat final est que si vous supprimez et recréez un rôle référencé dans l'élément `Principal` d'une politique d'approbation, vous devez modifier le rôle afin de remplacer l'ID du principal, qui est désormais incorrect, par l'ARN correct. L'ARN se transforme à nouveau en nouvel ID principal du rôle lorsque vous enregistrez la politique. Pour plus d'informations, consultez la section [Comprendre AWS la gestion des rôles IAM supprimés dans Politiques](https://repost.aws/articles/ARSqFcxvd7R9u-gcFD9nmA5g/understanding-aws-s-handling-of-deleted-iam-roles-in-policies).
Vous pouvez également spécifier le principal du rôle comme principal dans une politique basée sur les ressources ou [créer une politique d'autorisation étendue](#principal-anonymous) qui utilise la clé de condition `aws:PrincipalArn`. Lorsque vous utilisez cette clé, le principal de séance de rôle reçoit les autorisations en fonction de l'ARN du rôle qui a été endossé, et non de l'ARN de la séance résultante. Comme la clé ARNs de condition AWS n'est pas convertie en IDs, les autorisations accordées à l'ARN du rôle sont conservées si vous supprimez le rôle puis créez un nouveau rôle portant le même nom. Les types de politiques basées sur l'identité, tels que les limites de permissions ou les politiques de session, ne limitent pas les autorisations accordées à l'aide de la clé de condition `aws:PrincipalArn` avec un caractère générique(\$1) dans l'élément `Principal`, à moins que les politiques basées sur l'identité ne contiennent un rejet explicite.
## Principaux de séance de rôle
Vous pouvez spécifier des séances de rôle dans l'élément `Principal`d'une politique basée sur les ressources ou des clés de condition prenant en charge les principaux. Lorsqu'un principal ou une identité endosse un rôle, ils reçoivent des informations d'identification de sécurité temporaires avec les autorisations du rôle endossé. Lorsqu'ils utilisent ces informations d'identification de session pour effectuer des opérations AWS, ils jouent *le rôle principal de session*.
Le format que vous utilisez pour un rôle principal de session dépend de l' AWS STS opération utilisée pour assumer le rôle.
**Important**
AWS recommande d'utiliser des [principes de rôle IAM dans vos politiques plutôt que des](#principal-roles) principes de session de rôle dans la mesure du possible. Utilisez `Condition` des instructions et des clés de condition pour limiter davantage l'accès lorsque cela est nécessaire.
Pour spécifier l'ARN principal de la session de rôle dans l'`Principal`élément, utilisez le format suivant :
```
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }
```
En outre, les administrateurs peuvent concevoir un processus pour contrôler la façon dont les séances de rôle sont émises. Par exemple, ils peuvent fournir une solution en un clic à leurs utilisateurs qui crée un nom de séance prévisible. Si votre administrateur procède ainsi, vous pouvez utiliser des principaux de séance de rôle dans vos politiques ou clés de condition. Sinon, vous pouvez spécifier l'ARN du rôle comme principal dans la `aws:PrincipalArn` clé de condition. La façon dont vous spécifiez le rôle comme principal peut modifier les autorisations effectives pour la séance résultante. Pour de plus amples informations, veuillez consulter [Principaux de rôles IAM](#principal-roles).
## Principaux fédérés OIDC
Un principal fédéré OIDC est le principal utilisé lors de l'appel d'une AWS STS `AssumeRoleWithWebIdentity` API avec un jeton Web JSON (JWT) à partir d'un IDP conforme à l'OIDC, également connu sous le nom de fournisseur OpenID (OP), pour demander des informations d'identification temporaires. AWS [Un principal fédéré OIDC peut représenter un IDP OIDC dans votre AWS compte, ou les 4 fournisseurs d'identité intégrés :Login with Amazon,Google, et Facebook Amazon Cognito.](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html)
Les utilisateurs, les charges de travail ou les systèmes auxquels un JWT a été attribué par leur IDP OIDC peuvent appeler `AssumeRoleWithWebIdentity` en utilisant le JWT pour demander des informations d'identification de AWS sécurité temporaires pour un rôle IAM configuré pour faire confiance à l'IDP OIDC qui a émis le JWT. Le JWT peut être un jeton d’identification, un jeton d’accès ou un jeton JWT délivré par toute autre méthode, à condition qu’il réponde aux [exigences énumérées par AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html#manage-oidc-provider-prerequisites). Pour plus d’informations, consultez les [Scénarios courants](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_federation_common_scenarios.html) et [Demande d’informations d’identification par le biais d’un fournisseur OIDC](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithwebidentity).
Utilisez ce type principal dans votre politique de confiance en matière de rôles pour autoriser ou refuser les autorisations d'appel `AssumeRoleWIthWebIdentity` en utilisant un IDP OIDC existant dans votre Compte AWS ou l'un des quatre intégrés. IDPs Pour spécifier l'ARN principal fédéré OIDC dans l'`Principal`élément d'une politique de confiance des rôles, utilisez l'un des quatre formats suivants pour l'OIDC intégré : IDPs
```
"Principal": { "Federated": "cognito-identity.amazonaws.com" }
```
```
"Principal": { "Federated": "www.amazon.com" }
```
```
"Principal": { "Federated": "graph.facebook.com" }
```
```
"Principal": { "Federated": "accounts.google.com" }
```
Lorsque vous utilisez un fournisseur OIDC, vous l'ajoutez à votre compte, par exemple GitHub, vous spécifiez l'ARN du fournisseur dans la politique de confiance de votre rôle. Cette configuration vous permet de rédiger des politiques IAM qui contrôlent spécifiquement l’accès des utilisateurs authentifiés via votre fournisseur d’identité personnalisé.
```
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/full-OIDC-identity-provider-URL" }
```
Par exemple, si GitHub était le fournisseur d’identité Web de confiance, l’ARN de session de rôle OIDC dans l’élément `Principal` d’une politique de confiance de rôle utilise le format suivant :
```
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/tokens.actions.githubusercontent.com" }
```
Pour plus d’informations, consultez [Configuration d’OpenID Connect dans Amazon Web Services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).
Les principaux fédérés OIDC ne sont pas pris en charge dans les types de politiques autres que les politiques de confiance des rôles.
## Principaux fédérés SAML
Un principal *fédéré SAML est un principal* utilisé lors de l'appel d'une AWS STS `AssumeRoleWithSAML` API pour demander des informations d' AWS identification temporaires à l'aide d'une assertion SAML. Vous pouvez utiliser votre fournisseur d’identité (IdP) SAML externe (IdP) pour vous connecter, puis endosser un rôle IAM à l’aide de cette opération. Similaire à`AssumeRoleWithWebIdentity`, `AssumeRoleWithSAML` ne nécessite pas AWS d'informations d'identification pour l'authentification. Au lieu de cela, les utilisateurs s'authentifient d'abord auprès de leur fournisseur d'identité SAML, puis effectuent l'appel d'`AssumeRoleWithSAML`API à l'aide de leur assertion SAML, ou sont redirigés vers la page AWS Sign-in/SAML pour se connecter au. AWS Management Console Pour de plus amples informations sur les principaux pouvant endosser un rôle à l'aide de cette opération, veuillez consulter [Comparez les AWS STS informations d'identification](id_credentials_sts-comparison.md).
Utilisez ce type de principal dans votre politique de confiance des rôles pour autoriser ou rejeter des autorisations en fonction du fournisseur d’identité SAML approuvé. Pour spécifier l'ARN de séance du rôle d'identité SAML dans l'élément `Principal` d'une politique d'approbation de rôle, utilisez le format suivant :
```
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }
```
## Principaux de l'utilisateur IAM
Vous pouvez spécifier des utilisateurs IAM dans l'élément `Principal` d'une politique basée sur les ressources ou dans les clés de condition qui prennent en charge les principes.
**Note**
Dans un élément `Principal`, le nom utilisateur faisant partie d'[*Amazon Resource Name* (ARN)](reference_identifiers.md#identifiers-arns) est sensible à la casse.
```
"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" }
```
```
"Principal": {
"AWS": [
"arn:aws:iam::AWS-account-ID:user/user-name-1",
"arn:aws:iam::AWS-account-ID:user/user-name-2"
]
}
```
Lors de la spécification d'utilisateurs dans un élément `Principal`, il n'est pas possible d'utiliser un caractère générique (`*`) signifiant « tous les utilisateurs ». Les principaux doivent toujours nommer des utilisateurs spécifiques.
**Important**
Si votre élément `Principal` dans une politique d'approbation de rôle comporte un ARN qui pointe vers un utilisateur IAM spécifique, IAM transforme l'ARN en ID du principal unique de l'utilisateur lorsque vous enregistrez la politique. Cela permet de réduire le risque d'escalade des privilèges par la suppression et la nouvelle création de l'utilisateur. Cet ID n'est pas fréquent dans la console, car il existe également une transformation inverse, pour revenir à l'ARN de l'utilisateur, lorsque la politique d'approbation est affichée. Cependant, si vous supprimez l'utilisateur, vous interrompez la relation La politique ne s'applique plus, même si vous recréez l'utilisateur. Cela est dû au fait que le nouvel ID du principal du nouvel utilisateur ne correspond pas à l'ID stocké dans la politique d'approbation. Dans ce cas, l'ID principal apparaît dans les politiques basées sur les ressources, car il n'est plus AWS possible de le mapper à un ARN valide. Par conséquent, si vous supprimez et recréez un utilisateur référencé dans l'élément `Principal` d'une politique d'approbation, vous devez modifier le rôle afin de remplacer l'ID du principal qui est désormais incorrect par l'ARN correct. IAM transforme à nouveau l'ARN en le nouvel ID du principal de l'utilisateur lorsque vous enregistrez la politique.
## Principaux d'IAM Identity Center
Dans IAM Identity Center, le principal d'une politique basée sur les ressources doit être défini comme étant le principal Compte AWS . Pour spécifier l'accès, faites référence à l'ARN du rôle du jeu d'autorisations dans le bloc de conditions. Pour en savoir, consultez [Référencement des jeux d'autorisations dans les politiques de ressources, Amazon EKS et AWS KMS](https://docs.aws.amazon.com/singlesignon/latest/userguide/referencingpermissionsets.html) (français non garanti) dans le *Guide de l'utilisateur IAM Identity Center*.
## AWS STS principes d'utilisateurs fédérés
Vous pouvez spécifier des *séances d'utilisateur fédéré* dans l'élément `Principal` d'une politique basée sur les ressources ou dans les clés de condition qui prennent en charge les principaux.
**Important**
AWS recommande de limiter l'utilisation des sessions utilisateur AWS STS fédérées. À la place, utilisez des [rôles IAM](IAM/latest/UserGuide/tutorial_cross-account-with-roles.html).
Un utilisateur principal AWS STS fédéré est créé par le biais de l'`GetFederationToken`opération appelée avec des informations d'identification IAM de longue durée. Les autorisations utilisateur fédérées correspondent à l’intersection entre le principal qui a appelé `GetFederationToken` et les politiques de session transmises en tant que paramètres à l’API `GetFederationToken`.
Dans AWS, les utilisateurs IAM ou an Utilisateur racine d'un compte AWS peuvent s'authentifier à l'aide de clés d'accès à long terme. Pour plus d'informations sur les principaux qui peuvent se fédérer à l'aide de cette opération, veuillez consulter [Comparez les AWS STS informations d'identification](id_credentials_sts-comparison.md).
+ **Utilisateur fédéré IAM** : un utilisateur IAM se fédère à l’aide de l’opération `GetFederationToken` qui donne lieu à une session d’utilisateur fédéré pour cet utilisateur IAM.
+ **Utilisateur racine fédéré** : un utilisateur racine se fédère à l’aide de l’opération `GetFederationToken` qui donne lieu à une session d’utilisateur fédéré pour cet utilisateur racine.
Lorsqu'un utilisateur IAM ou un utilisateur root demande des informations d'identification temporaires pour AWS STS utiliser cette opération, il ouvre une session utilisateur fédérée temporaire. L'ARN de cette séance est basé sur l'identité originale qui a été fédérée.
Pour spécifier l'ARN de la séance d'utilisateur fédéré dans l'élément `Principal`, utilisez le format suivant :
```
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" }
```
## AWS principes de service
Vous pouvez spécifier AWS des services dans l'`Principal`élément d'une politique basée sur les ressources ou dans des clés de condition qui prennent en charge les principaux. Un *principal de service* est un identifiant pour un service.
Les rôles IAM qui peuvent être assumés par un AWS service sont appelés *[rôles de service](id_roles.md#iam-term-service-role)*. Les rôles de service doivent inclure une politique d'approbation. Les *politiques d'approbation* sont des politiques basées sur les ressources attachées à un rôle qui définit les principaux qui peuvent endosser le rôle. Certains rôles de service disposent de politiques d'approbation prédéfinies. Toutefois, dans certains cas, vous devez spécifier le principal du service dans la politique d'approbation. Le principal de service d’une politique IAM ne peut pas être `"Service": "*"`.
**Important**
L'identifiant d'un principal de service inclut le nom du service et se présente généralement dans le format suivant :
`service-name.amazonaws.com`
Le principal de service est défini par le service. Vous pouvez rechercher le principal de service pour certains services en ouvrant l’interface [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md), en vérifiant si le service indique **Oui** dans la colonne **Rôle lié à un service** et en ouvrant le lien **Oui** pour afficher la documentation du rôle lié à un service pour ce service. Recherchez la section **Autorisations de rôles liés à un service** correspondant à ce service pour afficher le principal du service.
L'exemple suivant illustre une politique qui est peut être attachée à un rôle de service. La politique permet à deux services, Amazon ECS et Elastic Load Balancing, d'endosser le rôle. Les services peuvent ensuite effectuer toutes les tâches autorisées par la politique d'autorisation affectée au rôle (non illustré). Pour définir plusieurs principaux de service, vous ne spécifiez pas deux éléments `Service` ; vous ne devez en avoir qu'un seul. À la place, vous utilisez un tableau de plusieurs principaux de service comme valeur d'un élément `Service` unique.
```
"Principal": {
"Service": [
"ecs.amazonaws.com",
"elasticloadbalancing.amazonaws.com"
]
}
```
## AWS principes de service dans les régions adhérentes
Vous pouvez lancer des ressources dans plusieurs AWS régions et vous devez vous inscrire dans certaines d'entre elles. Pour obtenir la liste complète des régions auxquelles vous devez adhérer, consultez [la section Gestion des AWS régions](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) dans le *Références générales AWS*guide.
Lorsqu'un AWS service d'une région optionnelle fait une demande dans la même région, le format du nom principal du service est identifié comme étant la version non régionalisée de son nom principal de service :
`service-name.amazonaws.com`
Lorsqu'un AWS service d'une région optionnelle adresse une demande interrégionale à une autre région, le format du nom principal du service est identifié comme étant la version régionalisée de son nom principal de service :
`service-name.{region}.amazonaws.com`
Par exemple, vous avez une rubrique Amazon SNS dans la région `ap-southeast-1` et un compartiment Amazon S3 dans la région d'adhésion `ap-east-1`. Vous voulez configurer les notifications du compartiment S3 pour publier des messages dans la rubrique SNS. Pour permettre au service S3 de publier des messages dans la rubrique SNS, vous devez accorder au principal de service S3 une autorisation `sns:Publish` via la stratégie d'accès basée sur les ressources de la rubrique.
Si vous spécifiez la version non régionalisée du principal de service S3, `s3.amazonaws.com`, dans la stratégie d'accès à la rubrique, la demande `sns:Publish` du compartiment vers la rubrique échouera. L'exemple suivant indique le principal de service S3 non régionalisé dans l'élément de stratégie `Principal` de la stratégie d'accès à la rubrique SNS.
```
"Principal": { "Service": "s3.amazonaws.com" }
```
Étant donné que le compartiment se trouve dans une région d'adhésion et que la demande est faite en dehors de cette même région, le principal de service S3 apparaît comme le nom du principal de service régionalisé, `s3.ap-east-1.amazonaws.com`. Vous devez utiliser le nom principal du service régionalisé lorsqu'un AWS service d'une région optionnelle adresse une demande à une autre région. Une fois que vous avez spécifié le nom du principal de service régionalisé, si le compartiment adresse une demande `sns:Publish` à la rubrique SNS située dans une autre région, la demande sera réussie. L'exemple suivant indique le principal de service S3 régionalisé dans l'élément de stratégie `Principal` de la stratégie d'accès à la rubrique SNS.
```
"Principal": { "Service": "s3.ap-east-1.amazonaws.com" }
```
Les stratégies de ressources ou les listes d'autorisation basées sur le principal de service pour les demandes inter-région d'une région d'adhésion vers une autre région ne seront réussies que si vous spécifiez le nom du principal de service régionalisé.
**Note**
Pour les stratégies d'approbation de rôle IAM, nous recommandons d'utiliser le nom du principal de service non régionalisé. Les ressources IAM sont globales et le même rôle peut donc être utilisé dans n'importe quelle région.
## Tous les principaux
Vous pouvez utiliser un caractère générique (\$1) pour spécifier tous les principaux dans l'élément `Principal` d'une politique basée sur les ressources ou dans les clés de condition prenant en charge les principaux. [Politiques basées sur les ressources](access_policies.md#policies_resource-based) *accorde* des autorisations et les [clés de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) sont utilisées pour limiter les conditions d'une déclaration de politique.
**Important**
Nous vous recommandons fortement de ne pas utiliser de caractère générique (\$1) dans l'élément `Principal` d'une politique basée sur les ressources avec un effet `Allow`, sauf si vous avez l'intention d'accorder un accès public ou anonyme. Sinon, indiquez les principaux, les services ou les comptes AWS visés dans l'élément `Principal`, puis restreignez davantage l'accès dans l'élément `Condition`. Cela est particulièrement vrai pour les politiques de confiance des rôles IAM, car elles permettent à d'autres principaux de devenir un principal dans votre compte.
Pour les politiques basées sur les ressources, utiliser un caractère générique (\$1) avec un effect `Allow` accorde l'accès à tous les utilisateurs, y compris les utilisateurs anonymes (accès public). Pour les utilisateurs IAM et les principaux de rôle de votre compte, aucune autre autorisation n'est requise. Pour les principaux d'autres comptes, ils doivent également disposer d'autorisations basées sur l'identité dans leur compte qui les autorise à accéder à votre ressource. C'est ce que l'on appelle l'[accès entre comptes](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html).
Pour les utilisateurs anonymes, les éléments suivants sont équivalents :
```
"Principal": "*"
```
```
"Principal" : { "AWS" : "*" }
```
Vous ne pouvez pas utiliser un caractère générique pour une correspondance à une partie d’un nom ou d’un ARN principal.
L'exemple suivant montre une politique basée sur les ressources qui peut être utilisée à la place de [AWS Éléments de politique JSON : NotPrincipal](reference_policies_elements_notprincipal.md) dans le but de refuser explicitement tous les principaux, *à l'exception de* ceux qui sont spécifiés dans l'élément `Condition`. Cette politique doit être [ajoutée à un compartiment Amazon S3](https://docs.aws.amazon.com//AmazonS3/latest/userguide/add-bucket-policy.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny",
"Effect": "Deny",
"Action": "s3:*",
"Principal": "*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*",
"arn:aws:s3:::amzn-s3-demo-bucket"
],
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name"
}
}
}
]
}
```
------
## En savoir plus
Pour plus d’informations, consultez les ressources suivantes :
+ [Exemples de politique de compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html) dans le *Guide de l'utilisateur service de stockage simple Amazon*
+ [Exemples de politiques pour Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#ExamplePolicies_SNS) dans le *Guide du développeur Amazon Simple Notification Service*
+ [Exemples de politique Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSExamples.html) dans le *Guide du développeur Amazon Simple Queue Service*
+ [Politiques de clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) dans le *Guide du développeur AWS Key Management Service *
+ [Identifiants de compte](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) (français non garanti) dans *Références générales AWS*
+ [Fédération OIDC](id_roles_providers_oidc.md)
# AWS Éléments de politique JSON : NotPrincipal
L’élément `NotPrincipal` utilise `"Effect":"Deny"` pour refuser l’accès à tous les principaux, ***sauf*** le principal spécifié dans l’élément `NotPrincipal`. Un principal peut être un utilisateur IAM, un utilisateur principal AWS STS fédéré, un rôle IAM, une session de rôle assumé Compte AWS, un AWS service ou un autre type principal. Pour plus d’informations sur les principaux, consultez [AWS Éléments de politique JSON : Principal](reference_policies_elements_principal.md).
L'élément `NotPrincipal` doit être utilisé avec `"Effect":"Deny"`. Son utilisation avec `"Effect":"Allow"` n'est pas prise en charge.
**Important**
Nous ne recommandons pas l’utilisation de `NotPrincipal`pour les nouvelles politiques basées sur les ressources dans le cadre de votre politique de sécurité et d’autorisation. Lorsque vous utilisez l'élément `NotPrincipal`, il peut être difficile de résoudre les problèmes liés à plusieurs types de politique. Nous recommandons plutôt l'utilisation de la clé de contexte `aws:PrincipalArn` avec les opérateurs de condition ARN.
## Points clés
+ L’élément `NotPrincipal` est pris en charge dans des politiques basées sur les ressources pour certains services AWS , y compris les points de terminaison d’un VPC. Les politiques basées sur les ressources sont des politiques que vous intégrez directement à une ressource. Vous ne pouvez pas utiliser l'élément `NotPrincipal` dans une politique IAM basée sur l'identité ni dans une politique d'approbation du rôle IAM.
+ N'utilisez pas de déclarations de politique basée sur les ressources qui incluent un élément de politique `NotPrincipal` ayant un effet `Deny` sur les utilisateurs IAM ou les rôles auxquels est attachée une politique de limite des autorisations. L'élément `NotPrincipal` ayant un effet `Deny` refusera toujours tout principal IAM auquel est attachée une politique de limite des autorisations, quelles que soient les valeurs spécifiées dans l'élément `NotPrincipal`. Certains utilisateurs ou rôles IAM qui auraient autrement eu accès à la ressource n'y ont donc plus accès. Nous vous recommandons de modifier vos déclarations de politique basée sur les ressources afin d'utiliser l'opérateur de condition [`ArnNotEquals`](reference_policies_elements_condition_operators.md#Conditions_ARN) avec la clé de contexte [`aws:PrincipalArn`](reference_policies_condition-keys.md#condition-keys-principalarn) dans le but de limiter l'accès plutôt que l'élément `NotPrincipal`. Pour plus d'informations sur les limites des autorisations, veuillez consulter [Limites d'autorisations pour les entités IAM](access_policies_boundaries.md).
+ Lorsque vous utilisez `NotPrincipal`, vous devez également spécifier l’ARN du compte du principal non refusé. Dans le cas contraire, la politique peut refuser l'accès à l'ensemble du compte contenant le principal. En fonction du service que vous incluez dans votre politique, AWS peut valider d'abord le compte, puis l'utilisateur. Si un utilisateur assumant un rôle (une personne utilisant un rôle) est en cours d'évaluation, AWS vous pouvez d'abord valider le compte, puis le rôle, puis l'utilisateur assumé. Ce dernier est identifié par le nom de session de rôle qui est spécifié lorsqu'il endosse le rôle. Par conséquent, nous vous recommandons vivement d'inclure explicitement l'ARN du compte d'un utilisateur, ou inclure à la fois l'ARN d'un rôle et l'ARN du compte contenant le rôle.
+ L’élément `NotPrincipal` n’est pas pris en charge dans les politiques de contrôle des services (SCP) et les politiques de contrôle des ressources (RCP).
## Alternatives à l’élément `NotPrincipal`
Lorsque vous gérez le contrôle d'accès dans AWS, il peut arriver que vous deviez refuser explicitement à tous les principaux l'accès à une ressource, à l'exception d'un ou de plusieurs principaux que vous spécifiez. AWS recommande d'utiliser une instruction Deny avec des clés contextuelles de condition globales pour un contrôle plus précis et un dépannage simplifié. Les exemples suivants montrent d’autres approches utilisant des opérateurs de condition tels que `StringNotEquals` ou `ArnNotEquals` pour refuser l’accès à tous les principaux, à l’exception de ceux spécifiés dans l’élément Condition.
## Exemple de scénario utilisant un rôle IAM
Vous pouvez utiliser une politique basée sur les ressources avec une instruction Refuser pour empêcher tous les rôles IAM, à l’exception de ceux spécifiés dans l’élément Condition, d’accéder à vos ressources ou de les manipuler. Cette approche suit le principe AWS de sécurité selon lequel un refus explicite a toujours priorité sur toute instruction d'autorisation et contribue à maintenir le principe du moindre privilège dans l'ensemble de votre AWS infrastructure.
Au lieu d’utiliser `NotPrincipal`, nous vous recommandons d’utiliser une instruction Refuser avec des clés de contexte de condition globales et l’opérateur de condition comme [`ArnNotEquals`](reference_policies_elements_condition_operators.md#Conditions_ARN) pour autoriser explicitement un rôle IAM à accéder à vos ressources. L’exemple suivant utilise [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) pour autoriser explicitement le rôle `read-only-role` à accéder aux compartiments Amazon S3 dans le dossier `Bucket_Account_Audit`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyCrossAuditAccess",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::Bucket_Account_Audit",
"arn:aws:s3:::Bucket_Account_Audit/*"
],
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::444455556666:role/read-only-role"
}
}
}
]
}
```
------
## Exemple de scénario utilisant un principal de service
Vous pouvez utiliser une instruction Refuser pour empêcher tous les principaux de service, à l’exception de ceux spécifiés dans l’élément `Condition`, d’accéder à vos ressources ou de les manipuler. Cette approche est particulièrement utile lorsque vous devez mettre en œuvre des contrôles d’accès précis ou établir des limites de sécurité entre différents services et applications dans votre environnement AWS .
Au lieu d’utiliser `NotPrincipal`, nous vous recommandons d’utiliser une instruction Refuser avec des clés de contexte de condition globales et l’opérateur de condition [`StringNotEquals`](reference_policies_elements_condition_operators.md#Conditions_String) pour autoriser explicitement un principal de service à accéder à vos ressources. L’exemple suivant utilise `aws:PrincipalServiceName` pour autoriser explicitement le principal de service AWS CodeBuild à accéder aux compartiments Amazon S3 dans le dossier `BUCKETNAME`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyNotCodeBuildAccess",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::BUCKETNAME",
"arn:aws:s3:::BUCKETNAME/*"
],
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalServiceName": "codebuild.amazonaws.com"
}
}
}
]
}
```
------
# Éléments de politique JSON IAM : Action
L'élément `Action` décrit les actions spécifiques qui seront accordées ou refusées. Les instructions doivent inclure un élément `Action` ou `NotAction`. Chaque AWS service possède son propre ensemble d'actions qui décrivent les tâches que vous pouvez effectuer avec ce service. Par exemple, la liste des actions pour Amazon S3 se trouve dans [Spécifier les autorisations dans une politique](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-actions.html) du *guide de l'utilisateur d'Amazon Simple Storage Service*, la liste des actions pour Amazon EC2 se trouve dans le manuel [Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-apis.html) Reference, et la liste des actions Gestion des identités et des accès AWS pour se trouve dans [le](https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html) IAM API Reference. Pour consulter la liste d'actions d'autres services, reportez-vous à la [documentation](https://aws.amazon.com/documentation) de référence de l'API pour le service requis.
AWS fournit également des informations de référence de service au format JSON afin de rationaliser l'automatisation des flux de travail de gestion des politiques. Grâce aux informations de référence du service, vous pouvez accéder aux actions, aux ressources et aux clés de condition disponibles à Services AWS partir de fichiers lisibles par machine. Pour plus d’informations, consultez les [Informations sur les Service AWS simplifiés pour l’accès programmatique](https://docs.aws.amazon.com/service-authorization/latest/reference/service-reference.html) dans la Référence des autorisations de service.
Vous spécifiez une valeur en utilisant un espace de noms du service comme préfixe d'action (`iam`, `ec2` `sqs`, `sns`, `s3`, etc.), suivi du nom de l'action à autoriser ou refuser. Le nom doit correspondre à une action prise en charge par le service. Le préfixe et le nom d'action ne sont pas sensibles à la casse. Par exemple, `iam:ListAccessKeys` est identique à `IAM:listaccesskeys`. Les exemples suivants illustrent les éléments `Action` pour différents services.
**Action Amazon SQS**
```
"Action": "sqs:SendMessage"
```
**Action Amazon EC2**
```
"Action": "ec2:StartInstances"
```
**Action IAM**
```
"Action": "iam:ChangePassword"
```
**Actions Amazon S3**
```
"Action": "s3:GetObject"
```
Vous pouvez spécifier plusieurs valeurs pour l'élément `Action`.
```
"Action": [ "sqs:SendMessage", "sqs:ReceiveMessage", "ec2:StartInstances", "iam:ChangePassword", "s3:GetObject" ]
```
Vous pouvez utiliser des caractères génériques à plusieurs caractères (`*`) et des caractères génériques à un seul caractère (`?`) pour donner accès à toutes les actions proposées par le produit spécifique. AWS Par exemple, l'élément `Action` suivant s'applique à toutes les actions S3.
```
"Action": "s3:*"
```
Vous pouvez aussi utiliser des caractères génériques (`*` ou `?`) dans le nom d’action. Par exemple, l'élément `Action` suivant s'applique à toutes les actions IAM qui incluent la chaîne `AccessKey`, y compris `CreateAccessKey`, `DeleteAccessKey`, `ListAccessKeys` et `UpdateAccessKey`.
```
"Action": "iam:*AccessKey*"
```
Certains services vous permettent de limiter les actions disponibles. Par exemple, Amazon SQS vous permet de ne mettre à disposition qu'un sous-ensemble de toutes les actions Amazon SQS possibles. Dans ce cas, le caractère générique `*` ne permet pas de contrôler entièrement la file d'attente ; il autorise uniquement le sous-ensemble d'actions que vous avez partagées. Pour de plus amples informations, veuillez consulter [Comprendre les autorisations](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/acp-overview.html#PermissionTypes) dans le *Guide du développeur Amazon Simple Storage Service*.
# Éléments de politique JSON IAM : NotAction
`NotAction` est un élément de politique avancé qui correspond de manière explicite à tout *sauf à* la liste spécifiée des actions. L'utilisation de `NotAction` peut entraîner une politique plus courte en répertoriant uniquement quelques actions qui ne devraient pas correspondre, plutôt que d'inclure une longue liste d'actions qui correspondront. Les actions spécifiées dans `NotAction` ne sont pas affectées par l’effet `Allow` ou `Deny` d’une déclaration de politique. En revanche, cela signifie que toutes les actions ou services applicables non répertoriés sont autorisés si vous utilisez l'effet `Allow`. En outre, ces actions ou services non répertoriés sont refusées si vous utilisez l'effet `Deny`. Lorsque vous utilisez `NotAction` avec l'élément `Resource`, vous fournissez la portée de la politique. C'est ainsi que l'on AWS détermine les actions ou les services applicables. Pour plus d'informations, consultez l'exemple de politique suivant :
**NotAction avec Allow**
Vous pouvez utiliser l'`NotAction`élément dans une instruction `"Effect": "Allow"` pour donner accès à toutes les actions d'un AWS service, à l'exception des actions spécifiées dans`NotAction`. Vous pouvez l'utiliser avec l'élément `Resource` pour fournir la portée de la politique, en limitant les actions autorisées aux actions pouvant être exécutées sur la ressource spécifiée.
L'exemple suivant permet aux utilisateurs d'accéder à toutes les actions Amazon S3 pouvant être exécutées sur une ressource S3 *sauf* pour supprimer un compartiment. Cette politique n'autorise pas non plus les actions dans d'autres services, car les actions d'autres services ne sont pas applicables aux ressources S3.
```
"Effect": "Allow",
"NotAction": "s3:DeleteBucket",
"Resource": "arn:aws:s3:::*",
```
Il peut arriver que vous souhaitiez autoriser l'accès à un grand nombre d'actions. En utilisant l'élément `NotAction`, vous inversez de manière efficace l'instruction, ce qui réduit la liste des actions. Par exemple, en raison AWS du grand nombre de services, vous souhaiterez peut-être créer une politique permettant à l'utilisateur de tout faire sauf d'accéder aux actions IAM.
L'exemple suivant permet aux utilisateurs d'accéder à toutes les actions de tous les AWS services, à l'exception d'IAM.
```
"Effect": "Allow",
"NotAction": "iam:*",
"Resource": "*"
```
Soyez vigilant lorsque vous utilisez l'élément `NotAction` et `"Effect": "Allow"` dans la même instruction ou une instruction différente dans une politique. `NotAction` correspond à tous les services et les actions qui ne sont pas répertoriés de manière explicite ou applicables à la ressource spécifiée, et peut accorder aux utilisateurs plus d'autorisations que vous n'auriez souhaité.
**NotAction avec Deny**
Vous pouvez utiliser l'élément `NotAction` dans une instruction avec `"Effect": "Deny"` pour refuser un accès à l'ensemble des ressources répertoriées sauf pour les actions spécifiées dans l'élément `NotAction`. Cette combinaison n'autorise pas les éléments répertoriés, mais à la place elle refuse de manière explicite les actions non répertoriées. Vous devez toujours autoriser les actions que vous souhaitez autoriser.
L'exemple conditionnel suivant refuse l'accès aux actions non-IAM si l'utilisateur n'est pas connecté lorsqu'il utilise MFA. Si l'utilisateur est connecté lorsqu'il utilise MFA, le test `"Condition"` échoue et l'instruction `"Deny"` finale n'a aucun effet. Notez, toutefois, que ceci n'accorde à l'utilisateur l'accès à aucune action, mais ne fait que refuser explicitement toutes les autres actions sauf les actions IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "DenyAllUsersNotUsingMFA",
"Effect": "Deny",
"NotAction": "iam:*",
"Resource": "*",
"Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
}]
}
```
------
Pour obtenir un exemple de politique qui refuse l'accès aux actions en dehors de régions spécifiques, à l'exception des actions provenant de services spécifiques, veuillez consulter [AWS: refuse l'accès AWS en fonction de la région demandée](reference_policies_examples_aws_deny-requested-region.md).
# Éléments de politique JSON IAM : Resource
L’élément `Resource` d’une déclaration de politique IAM définit l’objet ou les objets auxquels la déclaration s’applique. Les instructions doivent inclure un élément `Resource` ou `NotResource`.
Vous indiquez une ressource à l’aide d’un Amazon Resources Name (ARN). Le format de l'ARN dépend de la ressource à laquelle vous faites référence Service AWS et de la ressource spécifique à laquelle vous faites référence. Bien que le format de l’ARN varie, vous utilisez toujours un ARN pour identifier une ressource. Pour plus d'informations sur le format de ARNs, consultez[IAM ARNs](reference_identifiers.md#identifiers-arns). Pour plus d'informations sur la façon de spécifier une ressource, reportez-vous à la documentation du service pour lequel vous souhaitez rédiger une instruction.
**Note**
Certains Services AWS ne vous permettent pas de définir des actions pour des ressources individuelles. Dans ces cas, toutes les actions répertoriées dans `Action`ou l’élément `NotAction` s’appliquent à toutes les ressources de ce service. Dans ce cas, vous utilisez le caractère générique (`*`) dans l’élément `Resource`.
L'exemple suivant fait référence à une file d'attente Amazon SQS spécifique.
```
"Resource": "arn:aws:sqs:us-east-2:account-ID-without-hyphens:queue1"
```
L’exemple suivant fait référence à un utilisateur IAM nommé `Bob` dans un Compte AWS.
**Note**
Dans l'élément `Resource`, le nom de l'utilisateur IAM est sensible à la casse.
```
"Resource": "arn:aws:iam::account-ID-without-hyphens:user/Bob"
```
## Utilisation de caractères génériques dans une ressource ARNs
Vous pouvez utiliser des caractères génériques (`*` et `?`) dans les segments individuels d’un ARN (les parties séparées par des deux points) pour représenter :
+ Toute combinaison de caractères (`*`)
+ Tout caractère unique (`?`)
Vous pouvez utiliser plusieurs `*` ou `?` dans chaque segment. Si le caractère générique `*` est le dernier caractère d’un segment d’ARN de ressource, il peut s’étendre pour correspondre au-delà des limites des deux points. Nous vous recommandons d’utiliser des caractères génériques (`*` et `?`) dans les segments d’ARN séparés par deux points.
**Note**
Vous ne pouvez pas utiliser de caractère générique dans le segment de service qui identifie le AWS produit. Pour plus d'informations sur les segments ARN, consultez [Identifiez les AWS ressources avec Amazon Resource Names (ARNs)](reference-arns.md)
L'exemple suivant fait référence à tous les utilisateurs IAM dont le chemin d'accès est `/accounting`.
```
"Resource": "arn:aws:iam::account-ID-without-hyphens:user/accounting/*"
```
L'exemple suivant fait référence à tous les éléments d'un compartiment Amazon S3 spécifique.
```
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
```
Le caractère astérisque (`*`) peut se développer pour remplacer tout ce qui se trouve dans un segment, y compris des caractères tels qu’une barre oblique (`/`) qui pourrait autrement sembler être un délimiteur dans un espace de noms de service donné. Par exemple, considérez l'ARN Amazon S3 suivant comme la même logique d'extension générique qui s'applique à tous les services.
```
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*/test/*"
```
Les caractères génériques de l'ARN s'appliquent à tous les objets suivants dans le compartiment, et pas seulement au premier objet répertorié.
```
amzn-s3-demo-bucket/1/test/object.jpg
amzn-s3-demo-bucket/1/2/test/object.jpg
amzn-s3-demo-bucket/1/2/test/3/object.jpg
amzn-s3-demo-bucket/1/2/3/test/4/object.jpg
amzn-s3-demo-bucket/1///test///object.jpg
amzn-s3-demo-bucket/1/test/.jpg
amzn-s3-demo-bucket//test/object.jpg
amzn-s3-demo-bucket/1/test/
```
Considérez les deux derniers objets de la liste précédente. Un nom d’objet Amazon S3 peut commencer ou se terminer par la barre oblique (`/`) du délimiteur classique. Bien que `/` fonctionne comme un délimiteur, ce caractère n’a pas de signification spécifique lorsqu’il est utilisé dans un ARN de ressource. Il est traité de la même manière que n'importe quel autre caractère valide. L'ARN ne correspondrait pas aux objets suivants :
```
amzn-s3-demo-bucket/1-test/object.jpg
amzn-s3-demo-bucket/test/object.jpg
amzn-s3-demo-bucket/1/2/test.jpg
```
## Spécification de plusieurs ressources
Vous pouvez spécifier plusieurs ressources dans l'`Resource`élément à l'aide d'un tableau de ARNs. L'exemple suivant fait référence à deux tables DynamoDB.
```
"Resource": [
"arn:aws:dynamodb:us-east-2:account-ID-without-hyphens:table/books_table",
"arn:aws:dynamodb:us-east-2:account-ID-without-hyphens:table/magazines_table"
]
```
## Utilisation de variables de politique dans les ressources ARNs
Dans l'élément `Resource`, vous pouvez utiliser des [variables de politique](reference_policies_variables.md) JSON dans la partie de l'ARN qui identifie la ressource spécifique (autrement dit, dans la partie finale de l'ARN). Par exemple, vous pouvez utilisez la clé `{aws:username}` au sein de l'ARN de la ressource pour indiquer que le nom de l'utilisateur actuel doit être inclus dans le nom de la ressource. L'exemple suivant montre comment utiliser la clé `{aws:username}` dans un élément `Resource`. La politique autorise l'accès à une table Amazon DynamoDB correspondant au nom de l'utilisateur actuel.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-east-2:111122223333:table/${aws:username}"
}
}
```
------
Pour plus d'informations sur les variables de politique JSON, consultez [Éléments des politiques IAM : variables et balises](reference_policies_variables.md).
# Éléments de politique JSON IAM : NotResource
`NotResource` est un élément de politique avancé qui correspond explicitement à chaque ressource, à l'exception de celles spécifiées. L'utilisation de `NotResource` peut entraîner une politique plus courte en répertoriant uniquement quelques ressources qui ne devraient pas correspondre, plutôt que d'inclure une longue liste de ressources qui correspondront. Ceci est particulièrement utile pour les politiques applicables au sein d'un même service AWS .
Prenons l'exemple d'un groupe nommé `HRPayroll`. Les membres de `HRPayroll` ne doivent pas être autorisés à accéder aux ressources Amazon S3 sauf au dossier `Payroll` dans le compartiment `HRBucket`. La politique suivante refuse de manière explicite l'accès à toutes les ressources Amazon S3 autres que celles répertoriées. Notez, toutefois, que cette politique n'accorde à l'utilisateur aucun accès aux ressources.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "s3:*",
"NotResource": [
"arn:aws:s3:::HRBucket/Payroll",
"arn:aws:s3:::HRBucket/Payroll/*"
]
}
}
```
------
En règle générale, pour refuser de manière explicite l'accès à une ressource vous rédigez une politique qui utilise `"Effect":"Deny"` et inclut un élément `Resource` qui répertorie individuellement chaque dossier. Toutefois, dans ce cas, chaque fois que vous ajoutez un dossier à `HRBucket`, ou une ressource à Amazon S3 à laquelle personne ne doit accéder, vous devez ajouter son nom à la liste dans l’élément `Resource`. Si vous utilisez un élément `NotResource` à la place, les utilisateurs verront leur accès aux nouveaux dossiers automatiquement refusé sauf si vous ajoutez les noms des dossiers à l'élément `NotResource`.
Lorsque vous utilisez `NotResource`, n'oubliez pas que les ressources spécifiées dans cet élément sont les *seules* ressources qui ne sont pas limitées. Toutes les ressources qui s'appliqueraient à l'action sont limitées. Dans l'exemple ci-dessus, la politique affecte uniquement les actions Amazon S3, et donc uniquement les ressources Amazon S3. Si l’élément `Action` comprenait également des actions Amazon EC2, la politique refuserait alors l’accès à toutes les ressources EC2 non spécifiées dans l’élément `NotResource`. Pour savoir quelles actions d'un service permettent de spécifier l'ARN d'une ressource, consultez [Actions, ressources et clés de condition pour les AWS services](reference_policies_actions-resources-contextkeys.html).
## NotResource avec d'autres éléments
Vous ne devez **jamais** utiliser les éléments `"Effect": "Allow"`, `"Action": "*"` et `"NotResource": "arn:aws:s3:::HRBucket"` ensemble. Cette déclaration est très dangereuse, car elle autorise toutes les actions AWS sur toutes les ressources à l'exception du compartiment `HRBucket` S3. Elle autoriserait même l'utilisateur à s'ajouter une politique qui lui permettrait d'accéder à `HRBucket`. Ne le faites pas.
Soyez vigilant lorsque vous utilisez l'élément `NotResource` et `"Effect": "Allow"` dans la même instruction ou une instruction différente dans une politique. `NotResource` autorise tous les services et ressources qui ne sont pas répertoriés de manière explicite et peut accorder aux utilisateurs plus d'autorisations que vous n'auriez souhaité. L'utilisation de l'élément `NotResource` et `"Effect": "Deny"` dans la même instruction refuse les services et les ressources qui ne sont pas répertoriés de manière explicite.
# Éléments de politique JSON IAM : Condition
L'élément `Condition` (ou *bloc* `Condition`) vous permet de spécifier des conditions lorsqu'une politique est appliquée. L’élément `Condition` est facultatif. Dans l'élément `Condition`, vous créez des expressions dans lesquelles vous utilisez des [opérateurs de condition](reference_policies_elements_condition_operators.md) (égal, inférieur à, etc.) pour faire correspondre les clés et valeurs de contexte de la politique avec les clés et valeurs du contexte de la demande. Pour de plus amples informations sur le contexte de la demande, veuillez consulter [Composants d’une requête](intro-structure.md#intro-structure-request).
```
"Condition" : { "{condition-operator}" : { "{condition-key}" : "{condition-value}" }}
```
La clé de contexte que vous spécifiez dans une condition de politique peut être une [clé de contexte de condition globale](reference_policies_condition-keys.md) ou une clé de contexte spécifique au service. Les clés de contexte de condition globale possèdent le préfixe `aws:`. Les clés de contexte spécifiques au service possèdent le préfixe du service. Par exemple, Amazon EC2 vous permet d'écrire une condition à l'aide de la clé de contexte `ec2:InstanceType`, qui est propre à ce service. Pour connaître les clés de contexte IAM spécifiques au service ayant le préfixe `iam:`, veuillez consulter la rubrique [Clés de contexte IAM et de AWS STS condition](reference_policies_iam-condition-keys.md).
Les *noms* de clé de contexte ne sont pas sensibles à la casse. Par exemple, inclure la clé de contexte `aws:SourceIP` revient à tester `AWS:SourceIp`. La sensibilité à la casse des *valeurs* des clés de contexte dépend de l'[opérateur de condition](reference_policies_elements_condition_operators.md) que vous utilisez. Par exemple, la condition suivante inclut l'opérateur `StringEquals` pour garantir que seules les demandes effectuées par `john` correspondent. Les utilisateurs nommés `John` se voient refuser l'accès.
```
"Condition" : { "StringEquals" : { "aws:username" : "john" }}
```
La condition suivante utilise l'opérateur [`StringEqualsIgnoreCase`](reference_policies_elements_condition_operators.md#Conditions_String) pour la correspondance avec les utilisateurs nommés `john` ou `John`.
```
"Condition" : { "StringEqualsIgnoreCase" : { "aws:username" : "john" }}
```
Certaines clés de contexte prennent en charge des paires clé-valeur qui vous permettent de spécifier une partie du nom de clé. Les exemples incluent la clé de [`aws:RequestTag/tag-key`](reference_policies_condition-keys.md#condition-keys-requesttag)contexte AWS KMS [https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context), la clé de contexte et la clé de [`ResourceTag/tag-key`](reference_policies_condition-keys.md#condition-keys-resourcetag)contexte prises en charge par plusieurs services.
+ Si vous utilisez la clé de contexte `ResourceTag/tag-key` pour un service comme [Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policy-structure.html#amazon-ec2-keys), vous devez spécifier un nom de clé pour `tag-key`.
+ **Les noms de clé ne sont pas sensibles à la casse.** Cela signifie que si vous spécifiez `"aws:ResourceTag/TagKey1": "Value1"` dans l'élément de condition de votre politique, la condition correspond à une clé de balise de ressource nommée `TagKey1` ou `tagkey1`, mais pas aux deux.
+ AWS les services qui prennent en charge ces attributs peuvent vous permettre de créer plusieurs noms de clés qui ne diffèrent qu'au cas par cas. Par exemple, vous pouvez baliser une instance Amazon EC2 avec les interfaces `ec2=test1` et `EC2=test2`. Lorsque vous utilisez une condition comme `"aws:ResourceTag/EC2": "test1"` pour autoriser l'accès à cette ressource, le nom de clé correspond aux deux balises, mais une seule valeur correspond. Cela peut entraîner des échecs de condition inattendus.
**Important**
En tant que bonne pratique, assurez-vous que les membres de votre compte suivent une convention de dénomination cohérente pour les attributs avec paire clé-valeur. Les exemples incluent les balises ou les contextes de chiffrement AWS KMS . Vous pouvez l'appliquer en utilisant la clé de [`aws:TagKeys`](reference_policies_condition-keys.md#condition-keys-tagkeys)contexte pour le balisage ou [https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context-keys](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context-keys)pour le contexte de AWS KMS chiffrement.
+ Pour obtenir une liste de tous les opérateurs de condition et une description de leur fonctionnement, veuillez consulter la rubrique [Opérateurs de condition](reference_policies_elements_condition_operators.md).
+ Sauf indication contraire, toutes les clés de contexte peuvent comporter plusieurs valeurs. Pour savoir comment traiter des clés de contexte qui ont plusieurs valeurs, veuillez consulter la rubrique [Définir les opérateurs pour les clés de contexte à valeurs multiples](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
+ Pour obtenir la liste de l'ensemble des clés de contexte disponibles dans le monde entier, veuillez consulter la rubrique [AWS clés contextuelles de condition globale](reference_policies_condition-keys.md).
+ Pour les clés de contexte de condition définies par chaque service, voir [Actions, ressources et clés de condition pour les AWS services](reference_policies_actions-resources-contextkeys.html).
## Contexte de la demande
Lorsqu'un [principal](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#principal) fait une [demande](intro-structure.md#intro-structure-request) à AWS, AWS rassemble les informations de la demande dans un contexte de demande. Le contexte de la demande comprend des informations sur le principal, les ressources, les actions et d’autres propriétés environnementales. L’évaluation de la politique fait correspondre les propriétés de la politique aux propriétés envoyées dans la demande afin d’évaluer et d’autoriser les actions que vous pouvez effectuer dans AWS.
Vous pouvez utiliser l'élément `Condition` d'une politique JSON pour tester des clés de contexte spécifiques par rapport au contexte de la demande. Par exemple, vous pouvez créer une politique qui utilise la clé de CurrentTime contexte [aws :](reference_policies_condition-keys.md#condition-keys-currenttime) pour [permettre à un utilisateur d'effectuer des actions dans un intervalle de dates spécifique uniquement](reference_policies_examples_aws-dates.md).
L’exemple suivant montre une représentation du contexte de la demande lorsque Martha Rivera envoie une demande pour désactiver son dispositif MFA.
```
Principal: AROA123456789EXAMPLE
Action: iam:DeactivateMFADevice
Resource: arn:aws:iam::user/martha
Context:
– aws:UserId=AROA123456789EXAMPLE:martha
– aws:PrincipalAccount=1123456789012
– aws:PrincipalOrgId=o-example
– aws:PrincipalARN=arn:aws:iam::1123456789012:assumed-role/TestAR
– aws:MultiFactorAuthPresent=true
– aws:MultiFactorAuthAge=2800
– aws:CurrentTime=...
– aws:EpochTime=...
– aws:SourceIp=...
```
Le contexte de la demande est mis en correspondance avec une politique qui autorise les utilisateurs à supprimer leur propre dispositif authentification multifactorielle (MFA), mais uniquement s’ils se sont connectés à l’aide de la MFA au cours de la dernière heure (3 600 secondes).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AllowRemoveMfaOnlyIfRecentMfa",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}",
"Condition": {
"NumericLessThanEquals": {"aws:MultiFactorAuthAge": "3600"}
}
}
}
```
------
Dans cet exemple, la politique correspond au contexte de la demande : l’action est la même, la ressource correspond au caractère générique « \$1 » et la valeur pour `aws:MultiFactorAuthAge` est 2 800, qui est inférieure à 3 600. La politique autorise donc cette demande d’autorisation.
AWS évalue chaque clé de contexte de la politique et renvoie une valeur *vraie* ou *fausse*. L'absence de clé de contexte dans la demande est considérée comme une absence de correspondance.
Le contexte de la demande peut renvoyer les valeurs suivantes :
+ **True** : si le demandeur s'est connecté avec MFA au cours de la dernière heure ou moins, la condition renvoie la valeur *true*.
+ **False** : si le demandeur s'est connecté avec MFA il y a plus d'une heure, la condition renvoie la valeur *false*.
+ **Absence : si le demandeur a fait une demande à l'aide de ses clés d'accès utilisateur IAM dans l' AWS API AWS CLI or, la clé n'est pas présente**. Dans ce cas, la clé est manquante et il n'y a pas de correspondance.
**Note**
Dans certains cas, lorsque la valeur de la clé de condition n’est pas présente, la condition peut toujours retourner vraie. Par exemple, si vous ajoutez le qualificateur `ForAllValues`, la demande renvoie vrai si la clé de contexte ne figure pas dans la demande. Pour éviter que des clés de contexte manquantes ou des clés de contexte contenant des valeurs vides ne soient considérées comme vraies, vous pouvez inclure l’[opérateur de condition Null](reference_policies_elements_condition_operators.md#Conditions_Null) dans votre politique avec une valeur `false` pour vérifier si la clé de contexte existe et si sa valeur n’est pas nulle.
## Bloc Condition
L'exemple suivant illustre le format de base d'un élément `Condition` :
```
"Condition": {"StringLike": {"s3:prefix": ["jane/*"]}}
```
Une valeur de la demande est représentée par une clé de contexte. Dans ce cas, il s'agit de `s3:prefix`. La valeur clé de contexte est comparée à une valeur que vous spécifiez comme valeur littérale, par exemple `jane/*`. Le type de comparaison à effectuer est spécifié par l'[opérateur de condition](reference_policies_elements_condition_operators.md) (ici, `StringLike`). Vous pouvez créer des conditions qui comparent des chaînes, des dates, des numéros et autres à l'aide d'opérateurs de comparaison booléens standard comme est égal à, supérieur à ou inférieur à. Lorsque vous utilisez des [opérateurs de chaîne](reference_policies_elements_condition_operators.md#Conditions_String) ou des [opérateurs ARN](reference_policies_elements_condition_operators.md#Conditions_ARN), vous pouvez également utiliser une [variable de politique](reference_policies_variables.md) dans la valeur de clé de contexte. L'exemple suivant inclut la variable `aws:username`.
```
"Condition": {"StringLike": {"s3:prefix": ["${aws:username}/*"]}}
```
Dans certains cas, les clés de contexte peuvent contenir plusieurs valeurs. Par exemple, une demande à Amazon DynamoDB peut retourner ou mettre à jour plusieurs attributs d'une table. Une politique d'accès aux tables DynamoDB peut inclure la clé de contexte `dynamodb:Attributes`, qui contient tous les attributs spécifiés dans la demande. Vous pouvez tester les divers attributs de la demande par rapport à une liste d'attributs autorisés dans une politique à l'aide d'opérateurs de définition dans l'élément `Condition`. Pour de plus amples informations, veuillez consulter [Définir les opérateurs pour les clés de contexte à valeurs multiples](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
Lorsque la politique est évaluée lors d'une demande, AWS remplace la clé par la valeur correspondante de la demande. (Dans cet exemple, AWS utiliserait la date et l'heure de la demande.) L'évaluation de la condition retourne True ou False, ce qui est pris en compte pour déterminer si la politique dans sa totalité autorise ou refuse la demande.
### Plusieurs valeurs dans un élément Condition
Un élément `Condition` peut contenir plusieurs opérateurs de condition, et chaque opérateur de condition peut également inclure plusieurs paires clé-valeur de contexte. L'illustration suivante décrit ce scénario.
![\[diagrammes de deux blocs de l’opérateur à conditions. Le premier bloc inclut deux espaces réservés aux clés contextuelles, chacun contenant plusieurs valeurs. Le second bloc de conditions inclut une clé de contexte à valeurs multiples.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/AccessPolicyLanguage_Condition_Block.diagram.png)
Pour de plus amples informations, veuillez consulter [Définir les opérateurs pour les clés de contexte à valeurs multiples](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
# Éléments de politique JSON IAM : Opérateurs de condition
Utilisez les opérateurs de condition de l'élément `Condition` pour faire correspondre la clé de condition et la valeur de la politique avec les valeurs du contexte de la demande. Pour en savoir plus sur l'élément `Condition`, consultez [Éléments de politique JSON IAM : Condition](reference_policies_elements_condition.md).
L'opérateur de condition que vous pouvez utiliser dans une politique dépend de la clé de condition que vous choisissez. Vous pouvez choisir une clé de condition globale ou une clé de condition spécifique au service. Pour savoir quel opérateur de condition vous pouvez utiliser pour une clé de condition globale, veuillez consulter [AWS clés contextuelles de condition globale](reference_policies_condition-keys.md). Pour savoir quel opérateur de condition vous pouvez utiliser pour une clé de condition spécifique à un service, consultez [Actions, ressources et clés de condition pour les AWS services](reference_policies_actions-resources-contextkeys.html) et choisissez le service que vous souhaitez consulter.
**Important**
Si la clé que vous spécifiez dans une condition de stratégie n'est pas présente dans le contexte de la requête, les valeurs ne correspondent pas et la condition est *fausse*. Si la condition de stratégie requiert qu'il n'y ait *aucune* correspondance de clé, tels que `StringNotLike` ou `ArnNotLike` et la touche de droite n'est pas présente, la condition est *vraie*. Cette logique s'applique à tous les opérateurs de condition sauf[... IfExists](#Conditions_IfExists)et [Contrôle nul](#Conditions_Null). Ces opérateurs testent si la clé est présente (existe) dans le contexte de demande.
Les opérateurs de condition peuvent être regroupés dans les catégories suivantes :
+ [String](#Conditions_String)
+ [Numérique](#Conditions_Numeric)
+ [Date et heure](#Conditions_Date)
+ [Booléen](#Conditions_Boolean)
+ [Binaire](#Conditions_BinaryEquals)
+ [Adresse IP](#Conditions_IPAddress)
+ [Amazon Resource Name (ARN)](#Conditions_ARN) (disponible uniquement pour certains services.)
+ [... IfExists](#Conditions_IfExists)(vérifie si la valeur clé existe dans le cadre d'une autre vérification)
+ [Null check](#Conditions_Null) (vérifie si la valeur de clé existe en tant que vérification autonome)
## Opérateurs de condition de chaîne
Les opérateurs de condition de chaîne permettent de créer des éléments `Condition` qui limitent l'accès après comparaison d'une clé à une valeur de chaîne.
+ **Variables de politiques** – [Prises en charge](reference_policies_variables.md)
+ **Caractères génériques** – [Pris en charge](#Conditions_String-wildcard)
****
| Opérateur de condition | Description |
| --- | --- |
| `StringEquals` | Correspondance exacte, respect de la casse |
| `StringNotEquals` | Correspondance négative |
| `StringEqualsIgnoreCase` | Correspondance exacte, non respect de la casse |
| `StringNotEqualsIgnoreCase` | Correspondance négative, non respect de la casse |
| `StringLike` | Correspondance avec respect de la casse. Les valeurs peuvent inclure un caractère générique (\$1) correspondant à plusieurs caractères et un caractère générique (?) correspondant à un seul caractère n'importe où dans la chaîne. Vous devez spécifier des caractères génériques pour obtenir des correspondances de chaînes partielles. Si une clé contient plusieurs valeurs, `StringLike` peut être qualifié avec les opérateurs d'ensemble `ForAllValues:StringLike` et `ForAnyValue:StringLike`. Pour de plus amples informations, veuillez consulter [Définir les opérateurs pour les clés de contexte à valeurs multiples](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys). |
| `StringNotLike` | Correspondance avec non respect de la casse. Les valeurs peuvent inclure un caractère générique (\$1) correspondant à plusieurs caractères ou un caractère générique (?) correspondant à un seul caractère n'importe où dans la chaîne. |
**Example opérateur de condition de chaîne**
Par exemple, l'instruction suivante contient un élément `Condition` qui utilise la clé [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) pour spécifier que le principal qui fait la requête doit être balisé avec la catégorie de tâche `iamuser-admin` .
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:*AccessKey*",
"Resource": "arn:aws:iam::111122223333:user/*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/job-category": "iamuser-admin"
}
}
}
}
```
Si la clé que vous spécifiez dans une condition de politique n'est pas présente dans le contexte de demande, les valeurs ne correspondent pas. Dans cet exemple, la clé `aws:PrincipalTag/job-category` est présente dans le contexte de demande si le principal utilise un utilisateur IAM avec des balises attachées. Elle est également incluse pour un principal utilisant un rôle IAM avec des balises ou des balises de session attachées. Si un utilisateur sans la balise tente d'afficher ou de modifier une clé d'accès, la condition renvoie `false` et la demande est implicitement refusée par cette instruction.
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la demande | Résultat |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/job-category": "iamuser-admin"
} | aws:PrincipalTag/job-category:
– iamuser-admin
| Correspondance |
| "StringEquals": {
"aws:PrincipalTag/job-category": "iamuser-admin"
} | aws:PrincipalTag/job-category:
– dev-ops
| Aucune correspondance |
| "StringEquals": {
"aws:PrincipalTag/job-category": "iamuser-admin"
} | Aucun `aws:PrincipalTag/job-category` dans le contexte de la demande. | Aucune correspondance |
**Example utilisation d’une variable de politique avec une chaîne d’opérateur de condition**
L'exemple suivant utilise l'opérateur de condition `StringLike` pour établir une correspondance entre une chaîne et une [variable de politique](reference_policies_variables.md) afin de créer une politique qui permet à un utilisateur IAM de se servir de la console Amazon S3 pour gérer son propre « répertoire de base » dans un compartiment Amazon S3. La politique autorise les actions spécifiées dans un compartiment S3 si l'élément `s3:prefix` correspond à l'un des modèles spécifiés.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"s3:prefix": [
"",
"home/",
"home/${aws:username}/"
]
}
}
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}",
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}/*"
]
}
]
}
```
Le tableau suivant montre comment cette politique AWS est évaluée pour différents utilisateurs en fonction de la [aws:username](reference_policies_condition-keys.md#condition-keys-username) valeur dans le contexte de la demande.
| Condition de politique | Contexte de la requête | Résultat |
| --- | --- | --- |
| "StringLike": {
"s3:prefix": [
"home/",
"home/${aws:username}/"
]
} | aws:username:
– martha_rivera
| "StringLike": {
"s3:prefix": [
"home/",
"home/martha_rivera/"
]
} |
| "StringLike": {
"s3:prefix": [
"home/",
"home/${aws:username}/"
]
} | aws:username:
– nikki_wolf
| "StringLike": {
"s3:prefix": [
"home/",
"home/nikki_wolf/"
]
} |
| "StringLike": {
"s3:prefix": [
"home/",
"home/${aws:username}/"
]
} | Aucun `aws:username` dans le contexte de la demande. | Aucune correspondance |
Pour consulter un exemple de politique qui montre comment utiliser l’élément `Condition` pour limiter l’accès à des ressources en fonction d’un ID d’application et d’un ID utilisateur pour la fédération OIDC consultez [Amazon S3 : permet aux utilisateurs Amazon Cognito d'accéder aux objets dans leur compartiment](reference_policies_examples_s3_cognito-bucket.md).
### Opérateurs de condition de chaîne à valeurs multiples
Si une clé dans la demande contient plusieurs valeurs, les opérateurs de chaîne peuvent être qualifiés avec les opérateurs d’ensemble `ForAllValues` et `ForAnyValue`. Pour plus d’informations sur la logique d’évaluation de plusieurs clés ou valeurs de contexte, consultez [Définir les opérateurs pour les clés de contexte à valeurs multiples](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
| Opérateur de condition | Description |
| --- | --- |
| `ForAllValues:StringEquals` `ForAllValues:StringEqualsIgnoreCase` | Toutes les valeurs de la clé de condition dans la demande doivent correspondre à au moins une des valeurs de votre politique. |
| `ForAnyValue:StringEquals` `ForAnyValue:StringEqualsIgnoreCase` | Au moins une valeur clé de condition dans la demande doit correspondre à l’une des valeurs de votre politique. |
| `ForAllValues:StringNotEquals` `ForAllValues:StringNotEqualsIgnoreCase` | Correspondance négative. Aucune des valeurs de la clé de contexte dans la demande ne correspond à l’une des valeurs de clé de contexte dans votre politique. |
| `ForAnyValue:StringNotEquals` `ForAnyValue:StringNotEqualsIgnoreCase` | Correspondance négative. Au moins une valeur de clé de contexte dans la demande ne doit PAS correspondre à l’une des valeurs de la clé de contexte dans votre politique. |
| `ForAllValues:StringLike` | Toutes les valeurs de la clé de condition dans la demande doivent correspondre à au moins une des valeurs de votre politique. |
| `ForAnyValue:StringLike` | Au moins une valeur clé de condition dans la demande doit correspondre à l’une des valeurs de votre politique. |
| `ForAllValues:StringNotLike` | Correspondance négative. Aucune des valeurs de la clé de contexte dans la demande ne correspond à l’une des valeurs de clé de contexte dans votre politique. |
| `ForAnyValue:StringNotLike` | Correspondance négative. Au moins une valeur de clé de contexte dans la demande ne doit PAS correspondre à l’une des valeurs de la clé de contexte dans votre politique. |
**Example utilisation de `ForAnyValue` avec une chaîne d’opérateur de condition**
Cet exemple montre comment vous pouvez créer une politique basée sur l'identité qui autorise l'utilisation de l'action `CreateTags` d'Amazon EC2 pour attacher des balises à une instance. Lorsque vous utilisez `StringEqualsIgnoreCase`, vous pouvez attacher des balises uniquement si la balise contient la clé `environment` et les valeurs `preprod` ou `storage`. Lorsque vous ajoutez `IgnoreCase` à l’opérateur, vous autorisez toute valeur de balise existante en majuscules, telle que `preprod`, `Preprod` et `PreProd`, à être résolue en vrai.
Lorsque vous ajoutez le modificateur `ForAnyValue` avec la clé de condition [aws:TagKeys](reference_policies_condition-keys.md#condition-keys-tagkeys), au moins une valeur de clé de balise dans la demande doit correspondre à la valeur `environment`. La comparaison `ForAnyValue` est sensible à la casse, ce qui empêche les utilisateurs d’utiliser une casse incorrecte pour la clé de balise, par exemple en utilisant `Environment` au lieu de `environment`.
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
}
}
}
}
```
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la requête | Résultat |
| --- | --- | --- |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– environment
aws:RequestTag/environment:
– preprod
| Correspondance |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– environment
– costcenter
aws:RequestTag/environment:
– PreProd
| Correspondance |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– Environment
aws:RequestTag/Environment:
– preprod
| Aucune correspondance |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– costcenter
aws:RequestTag/environment:
– preprod
| Aucune correspondance |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | Aucun `aws:TagKeys` dans le contexte de la demande. aws:RequestTag/environment:
– storage
| Aucune correspondance |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– environment
Aucun `aws:RequestTag/environment` dans le contexte de la demande. | Aucune correspondance |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | Aucun `aws:TagKeys` dans le contexte de la demande. Aucun `aws:RequestTag/environment` dans le contexte de la demande. | Aucune correspondance |
### Correspondance des caractères génériques
Les opérateurs de condition de chaîne réalisent une correspondance sans modèle qui n'applique pas de format prédéfini. Les opérateurs de condition ARN et de condition de date constituent un sous-ensemble d'opérateurs de chaîne qui appliquent une structure à la valeur de la clé de condition.
Nous vous recommandons d’utiliser des opérateurs de condition qui correspondent aux valeurs auxquelles vous comparez les clés. Par exemple, vous devez utiliser [Opérateurs de condition de chaîne](#Conditions_String) lorsque vous comparez des clés à des valeurs de chaîne. De même, vous devez utiliser [Opérateurs de condition d'Amazon Resource Name (ARN)](#Conditions_ARN) lorsque vous comparez des clés à des valeurs d’ARN.
**Example**
Cet exemple montre comment créer une limite autour des ressources de votre organisation. La condition de cette politique refuse l'accès aux actions Amazon S3 sauf si la ressource à laquelle vous accédez se trouve dans un ensemble spécifique d'unités organisationnelles (OUs) dans AWS Organizations. Un chemin AWS Organizations est une représentation textuelle de la structure d’une entité d’organisation.
La condition exige que `aws:ResourceOrgPaths` contienne l’un des chemins d’UO répertoriés. Comme `aws:ResourceOrgPaths` il s'agit d'une condition à valeurs multiples, la politique utilise `ForAllValues:StringNotLike` l'opérateur pour comparer les valeurs de `aws:ResourceOrgPaths` à la liste de OUs la politique.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyS3AccessOutsideMyBoundary",
"Effect": "Deny",
"Action": [
"s3:*"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringNotLike": {
"aws:ResourceOrgPaths": [
"o-acorg/r-acroot/ou-acroot-mediaou/",
"o-acorg/r-acroot/ou-acroot-sportsou/*"
]
}
}
}
]
}
```
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la requête | Résultat |
| --- | --- | --- |
| "ForAllValues:StringNotLike": {
"aws:ResourceOrgPaths": [
"o-acorg/r-acroot/ou-acroot-mediaou/",
"o-acorg/r-acroot/ou-acroot-sportsou/*"
]
} | aws:ResourceOrgPaths:
– o-acorg/r-acroot/ou-acroot-sportsou/costcenter/
| Correspondance |
| "ForAllValues:StringNotLike": {
"aws:ResourceOrgPaths": [
"o-acorg/r-acroot/ou-acroot-mediaou/",
"o-acorg/r-acroot/ou-acroot-sportsou/*"
]
} | aws:ResourceOrgPaths:
– o-acorg/r-acroot/ou-acroot-mediaou/costcenter/
| Aucune correspondance |
| "ForAllValues:StringNotLike": {
"aws:ResourceOrgPaths": [
"o-acorg/r-acroot/ou-acroot-mediaou/",
"o-acorg/r-acroot/ou-acroot-sportsou/*"
]
} | Aucun `aws:ResourceOrgPaths:` dans la demande. | Aucune correspondance |
## Opérateurs de condition numériques
Les opérateurs de condition numériques permettent de créer des éléments `Condition` qui limitent l'accès après comparaison d'une clé à un entier ou une valeur décimale.
+ **Variables de politiques** – Non prises en charge
+ **Caractères génériques** – Non pris en charge
****
| Opérateur de condition | Description |
| --- | --- |
| `NumericEquals` | Correspondance |
| `NumericNotEquals` | Correspondance négative |
| `NumericLessThan` | Correspondance « Inférieur à » |
| `NumericLessThanEquals` | Correspondance « Inférieur ou égal à » |
| `NumericGreaterThan` | Correspondance « Supérieur à » |
| `NumericGreaterThanEquals` | Correspondance « Supérieur ou égal à » |
Par exemple, l'instruction suivante contient un élément `Condition` qui utilise l'opérateur de condition `NumericLessThanEquals` avec la clé `s3:max-keys` pour spécifier que le demandeur peut répertorier *jusqu'à* 10 objets dans `amzn-s3-demo-bucket` à la fois.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {"NumericLessThanEquals": {"s3:max-keys": "10"}}
}
}
```
------
Si la clé que vous spécifiez dans une condition de politique n'est pas présente dans le contexte de demande, les valeurs ne correspondent pas. Dans cet exemple, la clé `s3:max-keys` est toujours présente dans la demande lorsque vous effectuez l'opération `ListBucket`. Si cette politique autorisait toutes les opérations Amazon S3, seules les opérations incluant la clé de contexte `max-keys` avec une valeur inférieure ou égale à 10 seraient autorisées.
## Opérateurs de condition de date
Les opérateurs de conditions de date vous permettent de créer `Condition` des éléments qui limitent l'accès en comparant une clé à une date/time valeur. Vous pouvez utiliser ces opérateurs de condition avec la clé [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-currenttime](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-currenttime) ou [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-epochtime](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-epochtime). Vous devez spécifier date/time des valeurs avec l'une des [implémentations du W3C des formats de date ISO 8601 ou en utilisant l'](http://www.w3.org/TR/NOTE-datetime)heure Epoch (UNIX).
+ **Variables de politiques** – Non prises en charge
+ **Caractères génériques** – Non pris en charge
****
| Opérateur de condition | Description |
| --- | --- |
| `DateEquals` | Correspondance à une date spécifique |
| `DateNotEquals` | Correspondance négative |
| `DateLessThan` | Correspondance avant une date et heure spécifiques |
| `DateLessThanEquals` | Correspondance à ou avant une date et heure spécifiques |
| `DateGreaterThan` | Correspondance après une date et heure spécifiques |
| `DateGreaterThanEquals` | Correspondance à ou après une date et heure spécifiques |
Par exemple, l’instruction suivante contient un élément `Condition` qui utilise l’opérateur de condition `DateGreaterThan` avec la clé [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tokenissuetime](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tokenissuetime). Cette condition spécifie que les informations d'identification de sécurité temporaires utilisées pour effectuer la demande ont été publiées en 2020. Cette politique peut être mise à jour par programme tous les jours pour s'assurer que les membres du compte utilisent de nouvelles informations d'identification.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:*AccessKey*",
"Resource": "arn:aws:iam::111122223333:user/*",
"Condition": {
"DateGreaterThan": {
"aws:TokenIssueTime": "2020-01-01T00:00:01Z"
}
}
}
}
```
------
Si la clé que vous spécifiez dans une condition de politique n'est pas présente dans le contexte de demande, les valeurs ne correspondent pas. La clé `aws:TokenIssueTime` n'est présente dans le contexte de demande que lorsque le principal utilise des informations d'identification temporaires pour effectuer la demande. La clé n'est pas présente dans AWS CLI les demandes AWS d'API ou de AWS SDK effectuées à l'aide de clés d'accès. Dans cet exemple, si un utilisateur IAM tente d'afficher ou de modifier une clé d'accès, la demande est refusée.
## Opérateurs de condition booléens
Les opérateurs de condition booléens permettent de créer des éléments `Condition` qui limitent l’accès après comparaison d’une clé à `true` ou `false`.
Si une clé contient plusieurs valeurs, les opérateurs booléens peuvent être qualifiés avec les opérateurs d’ensemble `ForAllValues` et `ForAnyValue`. Pour plus d’informations sur la logique d’évaluation de plusieurs clés ou valeurs de contexte, consultez [Définir les opérateurs pour les clés de contexte à valeurs multiples](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
+ **Variables de politiques** – [Prises en charge](reference_policies_variables.md)
+ **Caractères génériques** – Non pris en charge
****
| Opérateur de condition | Description |
| --- | --- |
| `Bool` | Correspondance booléenne |
| `ForAllValues:Bool` | À utiliser avec le type de données Array of Bool. Toutes les valeurs booléennes dans les valeurs clés du contexte doivent correspondre aux valeurs booléennes de votre politique. Pour empêcher les opérateurs `ForAllValues` d’évaluer les clés de contexte manquantes ou les clés de contexte avec des valeurs vides comme Autorisé, vous pouvez inclure l’[opérateur de condition Null](#Conditions_Null) dans votre politique. |
| `ForAnyValue:Bool` | À utiliser avec le type de données Array of Bool. Au moins l’une des valeurs booléennes dans les valeurs clés du contexte doit correspondre aux valeurs booléennes de votre politique. |
**Example opérateur de condition booléens**
L politique basée sur l’identité suivante utilise l’opérateur de condition `Bool` avec la clé [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-securetransport](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-securetransport) pour refuser la réplication d’objets et de balises d’objets vers le compartiment de destination et son contenu si la demande n’est pas effectuée via SSL.
Cette politique ne permet aucune action. Utilisez cette stratégie conjointement à d'autres stratégies qui autorisent des actions spécifiques.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "BooleanExample",
"Action": "s3:ReplicateObject",
"Effect": "Deny",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
```
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la requête | Résultat |
| --- | --- | --- |
| "Bool": {
"aws:SecureTransport": "false"
} | aws:SecureTransport:
– false
| Correspondance |
| "Bool": {
"aws:SecureTransport": "false"
} | aws:SecureTransport:
– true
| Aucune correspondance |
| "Bool": {
"aws:SecureTransport": "false"
} | Aucun `aws:SecureTransport` dans le contexte de la demande. | Aucune correspondance |
## Opérateurs de condition binaires
L’opérateur de condition `BinaryEquals` vous permet de créer des éléments `Condition` qui analysent les valeurs de clé qui utilisent un format binaire. Il compare la valeur de la clé spécifiée, octet par octet, à une représentation encodée au format [Base64](https://en.wikipedia.org/wiki/Base64) de la valeur binaire dans la politique. Si la clé que vous spécifiez dans une condition de politique n'est pas présente dans le contexte de demande, les valeurs ne correspondent pas.
+ **Variables de politiques** – Non prises en charge
+ **Caractères génériques** – Non pris en charge
```
"Condition" : {
"BinaryEquals": {
"key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
}
}
```
| Condition de politique | Contexte de la requête | Résultat |
| --- | --- | --- |
| "BinaryEquals": {
"key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
} | key:
– QmluYXJ5VmFsdWVJbkJhc2U2NA==
| Correspondance |
| "BinaryEquals": {
"key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
} | key:
– ASIAIOSFODNN7EXAMPLE
| Aucune correspondance |
| "BinaryEquals": {
"key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
} | Aucun `key` dans le contexte de la demande. | Aucune correspondance |
## Opérateurs de condition d'adresse IP
Les opérateurs de condition d'adresse IP vous permettent de créer `Condition` des éléments qui limitent l'accès en comparant une clé à une IPv6 adresse IPv4 ou à une plage d'adresses IP. Vous utilisez ces opérateurs avec la clé [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip). La valeur doit être au format CIDR standard (par exemple, 203.0.113.0/24 ou 2001 : : 1234:5678 : :/64). DB8 Si vous spécifiez une adresse IP sans préfixe de routage associé, IAM utilise la valeur de préfixe par défaut `/32`.
Certains AWS services sont compatibles IPv6, en utilisant : : pour représenter une plage de 0. Pour savoir si un service est compatible IPv6, consultez sa documentation.
+ **Variables de politiques** – Non prises en charge
+ **Caractères génériques** – Non pris en charge
****
| Opérateur de condition | Description |
| --- | --- |
| `IpAddress` | Adresse IP ou plage d'adresses IP spécifiée |
| `NotIpAddress` | Toutes les adresses IP à l'exception de l'adresse IP ou de la plage d'adresse IP spécifiée |
**Example Opérateur de condition d’adresse IP**
L’instruction suivante utilise l’opérateur de condition `IpAddress` avec la clé `aws:SourceIp` pour spécifier que la demande doit provenir d’une adresse IP comprise dans la plage 203.0.113.0 à 203.0.113.255.
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:*AccessKey*",
"Resource": "arn:aws:iam::111122223333:user/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
}
```
La clé de condition `aws:SourceIp` est résolue à l'aide de l'adresse IP d'où provient la demande. Si la demande provient d'une instance Amazon EC2, `aws:SourceIp` correspond à l'adresse IP publique de l'instance.
Si la clé que vous spécifiez dans une condition de politique n'est pas présente dans le contexte de demande, les valeurs ne correspondent pas. La clé `aws:SourceIp` figure toujours dans le contexte de demande, sauf lorsque le demandeur utilise un point de terminaison VPC pour effectuer la demande. Dans ce cas, la condition renvoie `false` et la demande est implicitement refusée par cette instruction.
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la requête | Résultat |
| --- | --- | --- |
| "IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
} | aws:SourceIp:
– 203.0.113.1
| Correspondance |
| "IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
} | aws:SourceIp:
– 198.51.100.1
| Aucune correspondance |
L'exemple suivant montre comment combiner IPv4 les IPv6 adresses afin de couvrir toutes les adresses IP valides de votre organisation. Nous vous recommandons de mettre à jour les politiques de votre organisation en fonction de vos plages d' IPv6 adresses, en plus des IPv4 plages dont vous disposez déjà, afin de vous assurer que les politiques continuent de fonctionner pendant votre transition IPv6.
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "someservice:*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"203.0.113.0/24",
"2001:DB8:1234:5678::/64"
]
}
}
}
}
```
La clé de condition `aws:SourceIp` fonctionne uniquement dans une politique JSON si vous appelez l'API que vous testez directement en tant qu'utilisateur. En revanche, si vous utilisez un service pour appeler le service cible en votre nom, ce service voit l'adresse IP du service appelant plutôt que celle de l'utilisateur d'origine. Par exemple, cela peut se produire si vous utilisez AWS CloudFormation pour appeler Amazon EC2 en vue de créer automatiquement des instances. Actuellement, il n'est pas possible de transmettre l'adresse IP d'origine au service cible via un service appelant à des fins d'évaluation dans une politique JSON. Pour ces types d'appels d'API de service, vous ne devez pas utiliser la clé de condition `aws:SourceIp`.
## Opérateurs de condition d'Amazon Resource Name (ARN)
Les opérateurs de condition d'Amazon Resource Name (ARN) permettent de créer des éléments `Condition` qui limitent l'accès après comparaison d'une clé à un ARN. L'ARN est considéré comme étant une chaîne.
+ **Variables de politiques** – [Prises en charge](reference_policies_variables.md)
+ **Caractères génériques** – [Pris en charge](reference_policies_elements_resource.md#reference_policies_elements_resource_wildcards)
****
| Opérateur de condition | Description |
| --- | --- |
| `ArnEquals`, `ArnLike` | Correspondance à l'ARN avec respect de la casse. Chacun des six composants de l'ARN, séparés par deux points, est vérifié séparément et chacun peut inclure un caractère générique correspondant à plusieurs caractères (\$1) ou un caractère générique correspondant à un caractère (?). Les opérateurs de condition `ArnEquals` et `ArnLike` se comportent de manière identique. |
| `ArnNotEquals`, `ArnNotLike` | Correspondance négative à l'ARN. Les opérateurs de condition `ArnNotEquals` et `ArnNotLike` se comportent de manière identique. |
**Example Opérateur de condition de l’ARN**
L'exemple de politique basée sur les ressources suivant montre une politique attachée à une file d'attente Amazon SQS à laquelle vous souhaitez envoyer des messages SNS. Elle donne l'autorisation à Amazon SNS d'envoyer des messages à une ou plusieurs files d'attente de votre choix, mais uniquement si le service envoie le message pour le compte d'une ou plusieurs rubriques Amazon SNS spécifiques. Vous spécifiez la file d'attente dans le champ `Resource`, tandis que la rubrique Amazon SNS est la valeur de la clé `SourceArn`.
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": "SQS:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:123456789012:QUEUE-ID",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-east-1:123456789012:TOPIC-ID"
}
}
}
}
```
La clé [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) figure dans le contexte de demande uniquement si une ressource déclenche un service pour appeler un autre service au nom du propriétaire de la ressource. Si un utilisateur IAM tente d'effectuer cette opération directement, la condition renvoie `false` et la demande est implicitement refusée par cette instruction.
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la requête | Résultat |
| --- | --- | --- |
| "ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-west-2:123456789012:TOPIC-ID"
} | aws:SourceArn:
– arn:aws:sns:us-west-2:123456789012:TOPIC-ID
| Correspondance |
| "ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-west-2:123456789012:TOPIC-ID"
} | aws:SourceArn:
– arn:aws:sns:us-west-2:777788889999:TOPIC-ID
| Aucune correspondance |
| "ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-west-2:123456789012:TOPIC-ID"
} | Aucun `aws:SourceArn` dans le contexte de la demande. | Aucune correspondance |
### Opérateurs de condition d’ARN à valeurs multiples
Si une clé dans la demande contient plusieurs valeurs, les opérateurs d’ARN peuvent être qualifiés avec les opérateurs d’ensemble `ForAllValues` et `ForAnyValue`. Pour plus d’informations sur la logique d’évaluation de plusieurs clés ou valeurs de contexte, consultez [Définir les opérateurs pour les clés de contexte à valeurs multiples](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
| Opérateur de condition | Description |
| --- | --- |
| `ForAllValues:ArnEquals` `ForAllValues:ArnLike` | Tous les éléments contenus ARNs dans le contexte de la demande doivent correspondre à au moins un des modèles d'ARN de votre politique. |
| `ForAnyValue:ArnEquals` `ForAnyValue:ArnLike` | Au moins un ARN du contexte de la demande doit correspondre à un des modèles ARN de votre politique. |
| `ForAllValues:ArnNotEquals` `ForAllValues:ArnNotLike` | Correspondance négative. Aucun des éléments contenus ARNs dans le contexte de la demande ne peut correspondre aux modèles d'ARN de chaîne de votre politique. |
| `ForAnyValue:ArnNotEquals` `ForAnyValue:ArnNotLike` | Correspondance négative. Au moins un ARN dans le contexte de la demande ne doit PAS correspondre à l’un des modèles ARN de votre politique. |
**Example utilisation de `ForAllValues` avec un d’opérateur de condition d’ARN**
L'exemple suivant permet `ForAllValues:ArnLike` de créer ou de mettre à jour une source de livraison logique pour les CloudWatch journaux Amazon Logs. Le bloc de condition inclut la clé de condition [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchlogs.html#amazoncloudwatchlogs-policy-keys](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchlogs.html#amazoncloudwatchlogs-policy-keys)pour filtrer la ressource générant le journal ARNs transmise dans la demande. À l'aide de cet opérateur de condition, tous les éléments de la demande doivent correspondre à au moins un ARN de la politique. ARNs
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "logs:PutDeliverySource",
"Resource": "arn:aws:logs:us-east-1:123456789012:delivery-source:*",
"Condition": {
"ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws:cloudfront::123456789012:distribution/*",
"arn:aws:cloudfront::123456789012:distribution/support*"
]
}
}
}
]
}
```
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la requête | Résultat |
| --- | --- | --- |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | logs:LogGeneratingResourceArns:
– arn:aws::cloudfront:123456789012:distribution/costcenter
| Correspondance |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | logs:LogGeneratingResourceArns:
– arn:aws::cloudfront:123456789012:distribution/costcenter
– arn:aws::cloudfront:123456789012:distribution/support2025
| Correspondance |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | logs:LogGeneratingResourceArns:
– arn:aws::cloudfront:123456789012:distribution/costcenter
– arn:aws::cloudfront:123456789012:distribution/admin
| Aucune correspondance |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | logs:LogGeneratingResourceArns:
– arn:aws::cloudfront:777788889999:distribution/costcenter
| Aucune correspondance |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | Aucun `logs:LogGeneratingResourceArns` dans le contexte de la demande. | Correspondance |
Le qualificateur `ForAllValues` renvoie la valeur true si la demande ne comprend pas de clés de contexte ou si la valeur de clé de contexte aboutit à un jeu de données nul, tel qu’une chaîne vide. Pour éviter que des clés de contexte manquantes ou des clés de contexte contenant des valeurs vides ne soient considérées comme vraies, vous pouvez inclure l’[opérateur de condition Null](#Conditions_Null) dans votre politique avec une valeur `false` pour vérifier si la clé de contexte existe et si sa valeur n’est pas nulle.
## ... IfExists opérateurs de conditions
Vous pouvez ajouter `IfExists` à la fin de n'importe quel nom d'opérateur de condition, à l'exception de la condition `Null`, par exemple,`StringLikeIfExists`. Ceci équivaut à spécifier que « Si la clé de condition est présente dans le contexte de la requête, la clé doit être traitée comme spécifié dans la politique. Si la clé n'est pas présente, la condition évalue l'élément de condition comme vrai. » Les autres éléments de condition dans l'instruction peuvent toujours se traduire par une absence de correspondance, mais pas par une clé manquante lors de la vérification avec `...IfExists`. Si vous utilisez un élément `"Effect": "Deny"` avec un opérateur de condition négatif tel que `StringNotEqualsIfExists`, la demande est toujours refusée, même si la clé de condition n’est pas présente.
**Exemple d'utilisation de `IfExists`**
De nombreuses clés de condition contiennent des informations se rapportant à un type spécifique de ressources et elles ne sont présentes que lorsque vous accédez à ce type de ressources. Ces clés de condition n'existent pas pour les autres types de ressources. Le fait que l'instruction ne s'applique qu'à un type spécifique de ressources ne pose pas problème. Toutefois, dans certains scénarios, une même instruction peut s'appliquer à plusieurs types de ressources, par exemple lorsque l'instruction de politique référence les actions de plusieurs services ou lorsqu'une action donnée d'un service accède à différents types de ressources dans un même service. Dans ce cas, l'inclusion d'une clé de condition applicable uniquement à une des ressources dans l'instruction de politique peut provoquer l'échec de l'élément `Condition` et de ce fait, l'élément `"Effect"` ne s'applique pas.
Prenons l'exemple de politique suivant :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "THISPOLICYDOESNOTWORK",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {"StringLike": {"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]}}
}
}
```
------
L'*intention* de la politique précédente est de permettre à l'utilisateur de lancer n'importe quelle instance de type `t1`, `t2` ou `m3`. Toutefois, le lancement d'une instance requiert non seulement l'accès à l'instance proprement dite, mais également à de nombreuses ressources telles que des images, des paires de clés, des groupes de sécurité, etc. L'ensemble de l'instruction est évalué par rapport à chaque ressource requise pour le lancement de l'instance. Ces ressources supplémentaires n'ont pas la clé de condition `ec2:InstanceType` et, par conséquent, la vérification `StringLike` échoue et l'utilisateur n'est autorisé à lancer *aucun* type d'instance.
Pour éviter ce problème, utilisez l'opérateur de condition `StringLikeIfExists` à la place. De cette façon, le test n'est effectué que si la clé de condition existe. Cela peut être interprété comme suit : « Si la ressource en cours de vérification est dotée d'une clé de condition `ec2:InstanceType`, l'action peut uniquement être autorisée si la valeur de la clé commence par `t1.`, `t2.` ou `m3.`. Si la ressource en cours de vérification n'est pas dotée de cette clé de condition, peu importe. » L'astérisque (\$1) figurant dans les valeurs des clés de condition, lorsqu'il est utilisé avec l'opérateur de condition `StringLikeIfExists`, est interprété comme un caractère générique pour obtenir des correspondances de chaînes partielles. L'instruction `DescribeActions` inclut les actions requises pour afficher l'instance dans la console.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RunInstance",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"StringLikeIfExists": {
"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]
}
}
},
{
"Sid": "DescribeActions",
"Effect": "Allow",
"Action": [
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeVpcs",
"ec2:DescribeKeyPairs",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups"
],
"Resource": "*"
}
]
}
```
------
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la requête | Résultat |
| --- | --- | --- |
| "StringLikeIfExists": {
"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]
} | ec2:InstanceType:
– t1.micro
| Correspondance |
| "StringLikeIfExists": {
"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]
} | ec2:InstanceType:
– m2.micro
| Aucune correspondance |
| "StringLikeIfExists": {
"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]
} | Aucun `ec2:InstanceType` dans le contexte de la demande. | Correspondance |
## Opérateur de condition pour vérifier l'existence de clés de condition
Utilisez un opérateur de condition `Null` pour vérifier si une clé de condition est absente au moment de l'autorisation. Dans l'instruction de politique, utilisez `true` (la clé n'existe pas ; elle est nulle) ou `false` (la clé existe et sa valeur n'est pas nulle).
Vous ne pouvez pas utiliser une [variable de politique](reference_policies_variables.md) avec l'opérateur de condition `Null`.
Par exemple, vous pouvez utiliser cet opérateur de condition pour déterminer si un utilisateur utilise des informations d’identification temporaires ou ses propres informations d’identification pour effectuer une demande. S'il utilise des informations d'identification temporaires, la clé `aws:TokenIssueTime` existe et elle est dotée d'une valeur. L’exemple suivant illustre une condition qui spécifie que l’utilisateur doit avoir recours à des informations d’identification temporaires (la clé ne peut pas être absente) pour exécuter l’API Amazon EC2.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":{
"Action":"ec2:*",
"Effect":"Allow",
"Resource":"*",
"Condition":{"Null":{"aws:TokenIssueTime":"false"}}
}
}
```
------
# Conditions avec plusieurs clés ou valeurs de contexte
Vous pouvez utiliser l'élément `Condition` d'une politique pour tester plusieurs clés ou plusieurs valeurs de contexte pour une seule clé de contexte dans une demande. Lorsque vous faites une demande AWS, par programmation ou par le biais du AWS Management Console, votre demande inclut des informations sur votre principal, votre fonctionnement, vos balises, etc. Vous pouvez utiliser des clés de contexte pour tester les valeurs des clés de contexte correspondantes dans la demande, avec les clés de contexte spécifiées dans la condition de politique. Pour en savoir plus sur les informations et les données incluses dans une demande, consultez [Contexte de la demande](reference_policies_elements_condition.md#AccessPolicyLanguage_RequestContext).
**Topics**
+ [Logique d'évaluation pour plusieurs clés ou valeurs de contexte](#reference_policies_multiple-conditions-eval)
+ [Logique d'évaluation des opérateurs de condition de correspondance négative](#reference_policies_multiple-conditions-negated-matching-eval)
## Logique d'évaluation pour plusieurs clés ou valeurs de contexte
Un élément `Condition` peut contenir plusieurs opérateurs de condition, et chaque opérateur de condition peut également inclure plusieurs paires clé-valeur de contexte. La plupart des clés de contexte prennent en charge l'utilisation de plusieurs valeurs, sauf indication contraire.
+ Si votre instruction de politique dispose de plusieurs [opérateurs de condition](reference_policies_elements_condition_operators.md), ils sont évalués à l'aide d'un opérateur logique `AND`.
+ Si votre instruction de politique dispose de plusieurs clés de contexte attachées à un même opérateur de condition, celles-ci sont évaluées à l'aide d'un opérateur logique `AND`.
+ Si un même opérateur de condition comprend plusieurs valeurs pour une clé de contexte, ces valeurs sont évaluées à l'aide d'un opérateur logique `OR`.
+ Si un même opérateur de condition de correspondance négative comprend plusieurs valeurs pour une clé de contexte, ces valeurs sont évaluées à l'aide d'un opérateur logique `NOR`.
Toutes les clés de contexte d'un bloc d'éléments de condition doivent être résolues sur true (vrai) pour invoquer l'effet `Allow` ou `Deny` souhaité. La figure suivante illustre la logique d'évaluation d'une condition comportant plusieurs opérateurs de condition et des paires clé-valeur de contexte.
![\[Bloc de conditions illustrant l'application des opérateurs AND et OR à plusieurs valeurs et clés de contexte\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/AccessPolicyLanguage_Condition_Block_AND_2.diagram.png)
Par exemple, la politique de compartiment S3 suivante illustre la manière dont la figure précédente est représentée dans une politique. Le bloc de conditions comprend les opérateurs de condition `StringEquals` et `ArnLike`, et les clés de contexte `aws:PrincipalTag` et `aws:PrincipalArn`. Afin d'invoquer l'effet `Allow` ou `Deny` souhaité, toutes les clés de contexte du bloc de conditions doivent être résolues sur true (vrai). L'utilisateur qui fait la demande doit disposer des deux clés de balise du principal, *department* et *role*, qui incluent l'une des valeurs de clés de balise spécifiées dans la politique. De plus, l'ARN principal de l'utilisateur qui fait la demande doit correspondre à l'une des valeurs `aws:PrincipalArn` spécifiées dans la politique pour être évalué comme true (vrai).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExamplePolicy",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::222222222222:root"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
}
}
}
]
}
```
------
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la demande | Résultat |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: legal
aws:PrincipalTag/role: audit
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **Match** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: hr
aws:PrincipalTag/role: audit
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **Aucune correspondance** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: hr
aws:PrincipalTag/role: payroll
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **Aucune correspondance** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | Aucun `aws:PrincipalTag/role` dans le contexte de la demande. aws:PrincipalTag/department: hr
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **Aucune correspondance** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | Aucun `aws:PrincipalTag` dans le contexte de la demande. aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **Aucune correspondance** |
## Logique d'évaluation des opérateurs de condition de correspondance négative
Certains [opérateurs de condition](reference_policies_elements_condition_operators.md), tels que `StringNotEquals` ou `ArnNotLike`, utilisent la correspondance négative pour comparer les paires clé-valeur de contexte de votre politique aux paires clé-valeur de contexte d'une demande. Lorsque plusieurs valeurs sont spécifiées pour une même clé de contexte dans une politique avec des opérateurs de condition de correspondance négative, les autorisations effectives fonctionnent comme un opérateur logique `NOR`. Dans le cas d'une correspondance négative, un opérateur logique `NOR` ou `NOT OR` renvoie la valeur true (vrai) uniquement si toutes les valeurs sont évaluées comme false (fausses).
La figure suivante illustre la logique d'évaluation d'une condition comportant plusieurs opérateurs de condition et des paires clé-valeur de contexte. La figure inclut un opérateur de condition de correspondance négative pour la clé de contexte 3.
![\[Bloc de conditions illustrant l'application des opérateurs AND et OR à plusieurs valeurs et clés de contexte lorsqu'un opérateur de condition de correspondance négative est utilisé\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/AccessPolicyLanguage_Condition_Block_AND_Negated_NOR_2.diagram.png)
Par exemple, la politique de compartiment S3 suivante illustre la manière dont la figure précédente est représentée dans une politique. Le bloc de conditions comprend les opérateurs de condition `StringEquals` et `ArnNotLike`, et les clés de contexte `aws:PrincipalTag` et `aws:PrincipalArn`. Afin d'invoquer l'effet `Allow` ou `Deny` souhaité, toutes les clés de contexte du bloc de conditions doivent être résolues sur true (vrai). L'utilisateur qui fait la demande doit disposer des deux clés de balise du principal, *department* et *role*, qui incluent l'une des valeurs de clés de balise spécifiées dans la politique. Puisque l'opérateur de condition `ArnNotLike` utilise la correspondance négative, l'ARN principal de l'utilisateur qui fait la demande ne doit pas correspondre à l'une des valeurs `aws:PrincipalArn` spécifiées dans la politique pour être évalué comme true (vrai).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExamplePolicy",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::222222222222:root"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
}
}
}
]
}
```
------
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la demande | Résultat |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: legal
aws:PrincipalTag/role: audit
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **Match** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: hr
aws:PrincipalTag/role: audit
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **Aucune correspondance** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: hr
aws:PrincipalTag/role: payroll
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **Aucune correspondance** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | >Aucun `aws:PrincipalTag/role` dans le contexte de la demande. aws:PrincipalTag/department: hr
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **Aucune correspondance** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | Aucun `aws:PrincipalTag` dans le contexte de la demande. aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **Aucune correspondance** |
# Clés de contexte à valeur unique ou à valeurs multiples
La différence entre les clés de contexte à valeur unique et à valeurs multiples réside dans le nombre de valeurs dans le [contexte de la requête](intro-structure.md#intro-structure-request), et non du nombre de valeurs dans la condition de la politique.
+ Les clés de contexte de condition à *valeur unique* ont au plus une valeur dans le contexte de la demande. Par exemple, lorsque vous balisez des ressources AWS, chaque balise de ressource est stockée sous forme de paire clé-valeur. Comme une clé de balise de ressource ne peut avoir qu’une seule valeur de balise, [aws:ResourceTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-resourcetag) est une clé de contexte à valeur unique. N'utilisez pas d'opérateur d'ensemble de conditions avec une clé de contexte à valeur unique.
+ Les clés de contexte de condition *à valeurs multiples* peuvent comporter plusieurs valeurs dans le contexte de la demande. Par exemple, lorsque vous balisez des ressources AWS, vous pouvez inclure plusieurs paires clé-valeur de balise dans une seule demande. Ainsi, [aws:TagKeys](reference_policies_condition-keys.md#condition-keys-tagkeys) est une clé de contexte à valeurs multiples. Les clés de contexte à valeurs multiples nécessitent un opérateur d'ensemble de conditions.
Par exemple, une demande peut provenir d'un seul point de terminaison d'un VPC au maximum. [aws:SourceVpce](reference_policies_condition-keys.md#condition-keys-sourcevpce) est donc une clé de contexte à valeur unique. Étant donné qu'un service peut avoir plus d'un nom de principal de service qui appartient au service, [aws:PrincipalServiceNamesList](reference_policies_condition-keys.md#condition-keys-principalservicenameslist) est une clé de contexte à valeurs multiples.
**Important**
La différence entre les clés de contexte à valeur unique et à valeurs multiples dépend du nombre de valeurs dans le contexte de la demande, et non du nombre de valeurs dans la condition de la politique.
## Points clés
+ Les classifications *À valeur unique* et *À valeurs multiples* sont incluses dans la description de chaque clé de contexte de condition, dans le *Type de valeur* de la rubrique [AWS clés contextuelles de condition globale](reference_policies_condition-keys.md).
+ Les clés de contexte à valeurs multiples dans la [référence d’autorisation de service](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html) utilisent un préfixe `ArrayOf` suivi du type d’opérateur de condition, tel que `ArrayOfString` ou `ArrayOfARN`, indiquant que la demande peut inclure plusieurs valeurs pour une clé de contexte de condition.
+ Vous pouvez utiliser n’importe quelle clé de contexte à valeur unique disponible en tant que variable de politique, mais vous ne pouvez pas utiliser une clé de contexte à valeurs multiples en tant que variable de politique. Pour de plus amples informations sur les variables de politique, veuillez consulter [Éléments des politiques IAM : variables et balises](reference_policies_variables.md).
+ Lors de l’utilisation de clés de contexte comprenant des paires clé-valeur, il est important de noter que même s’il peut y avoir plusieurs valeurs de clé de balise, chacun `tag-key` ne peut avoir qu’une seule valeur.
+ [aws:PrincipalTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-principaltag), [aws:RequestTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-requesttag) et [aws:ResourceTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-resourcetag) sont des clés de contexte à valeur unique.
+ [aws:TagKeys](reference_policies_condition-keys.md#condition-keys-tagkeys) définit les clés de balise autorisées dans une demande, mais n’inclut pas les valeurs des clés de balise. Comme vous pouvez inclure plusieurs paires clé-valeur dans une demande, `aws:TagKeys` est une clé de contexte à valeurs multiples.
+ Les clés de contexte à valeurs multiples nécessitent un opérateur d'ensemble de conditions. N'utilisez pas d'opérateurs d'ensemble de conditions `ForAllValues` ou `ForAnyValue` avec des clés de contexte à valeur unique. L'utilisation d'opérateurs d'ensembles de conditions avec des clés de contexte à valeur unique peut entraîner des politiques trop permissives.
## Définir les opérateurs pour les clés de contexte à valeurs multiples
Pour comparer votre clé de contexte de condition à un [contexte de demande](intro-structure.md#intro-structure-request) à valeurs multiples, vous devez utiliser les opérateurs d'ensemble `ForAllValues` ou `ForAnyValue`. Ces opérateurs d'ensembles sont utilisés pour comparer deux ensembles de valeurs, tels que l'ensemble de balises dans une demande et l'ensemble de balises dans une condition de politique.
Ces qualificatifs `ForAllValues` et `ForAnyValue` ajoutent une fonctionnalité d’opération d’ensemble à l’opérateur de condition afin que vous puissiez tester les clés de contexte avec plusieurs valeurs par rapport à plusieurs valeurs de clé de contexte dans une condition de politique. En outre, si vous incluez une clé de contexte à valeurs multiples dans votre politique avec un caractère générique ou une variable, vous devez également utiliser l'[opérateur de condition](reference_policies_elements_condition_operators.md#Conditions_String) `StringLike`. Les valeurs de clé de condition multiples doivent être placées entre crochets, comme dans un [tableau](reference_policies_grammar.md#policies-grammar-json), par exemple, `"Key2":["Value2A", "Value2B"]`.
### ForAllValues
Le qualificateur `ForAllValues` vérifie si la valeur de chaque membre du contexte de la demande correspond à l’opérateur de condition qui suit le qualificateur. La condition renvoie la valeur `true` si chaque valeur de clé de contexte de la demande correspond à une valeur de clé de contexte de la politique. Il renvoie également `true` s’il n’y a aucune clé de contexte dans la demande.
**Important**
Faites preuve de vigilance si vous utilisez `ForAllValues` avec un effet `Allow`, car cela peut être trop permissif si la présence de clés de contexte manquantes dans le contexte de la demande est inattendue. Vous devez toujours inclure l’opérateur de condition [`Null`](reference_policies_elements_condition_operators.md#Conditions_Null) dans votre politique avec une valeur `false` pour vérifier si la clé de contexte existe et si sa valeur n’est pas nulle. Pour obtenir un exemple, consultez [Contrôle de l'accès en fonction des clés de balise](access_tags.md#access_tags_control-tag-keys).
#### Exemple d'opérateur ForAllValues d'ensemble
Dans l'exemple suivant, ForAllValues est utilisé avec aws : TagKeys pour permettre aux utilisateurs de supprimer des balises spécifiques attribuées à une instance EC2. Cette politique permet aux utilisateurs de supprimer uniquement les balises `environment` et `cost-center`. Vous pouvez les supprimer séparément ou ensemble. Les clés de balise dans la demande doivent correspondre exactement aux clés spécifiées dans la politique.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DeleteTags",
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
}
}
}
]
}
```
------
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la demande | Résultat |
| --- | --- | --- |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | aws:TagKeys:
– environment
| **Match** |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | aws:TagKeys:
– cost-center
| **Match** |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | aws:TagKeys:
– environment
– cost-center
| **Match** |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | aws:TagKeys:
– environment
– dept
| **Aucune correspondance** |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | Aucun `aws:TagKeys` dans le contexte de la demande. | **Aucune correspondance** |
Notez que dans le dernier exemple, le résultat est « Aucune correspondance » car la vérification de la condition Null empêche la correspondance lorsque la clé de contexte est manquante. Une bonne pratique consiste à éviter les politiques trop permissives.
### ForAnyValue
Le qualificateur `ForAnyValue` teste si au moins un membre de l’ensemble des valeurs de clé de contexte de la demande correspond à au moins un membre de l’ensemble des valeurs de clé de contexte de votre condition de politique. La condition renvoie la valeur `true` si l’une des valeurs de clé de contexte de la demande correspond à l’une des valeurs de clé de contexte de la politique. Si aucune clé de contexte correspondante n’est trouvée ou si la clé n’existe pas, la condition renvoie `false`.
**Important**
Lorsque vous utilisez `ForAnyValue` avec un effet `Deny`, si la clé de contexte n’est pas présente dans la demande, la politique est évaluée comme **Aucune correspondance**. Pour garantir un comportement cohérent, ajoutez une vérification de condition [`Null`](reference_policies_elements_condition_operators.md#Conditions_Null) explicite dans votre politique afin de vérifier si la clé de contexte existe. Pour en savoir plus, consultez [Opérateur de condition pour vérifier l'existence de clés de condition](reference_policies_elements_condition_operators.md#Conditions_Null).
#### Exemple d'opérateur ForAnyValue d'ensemble
Dans l'exemple suivant, ForAnyValue est utilisé avec aws : TagKeys pour permettre aux utilisateurs de supprimer des balises spécifiques attribuées à une instance EC2. Cette politique permet aux utilisateurs de supprimer les balises pour une instance si les clés de balise spécifiées dans la demande incluent `environment` ou `cost-center`. La demande peut inclure des clés de balise supplémentaires en plus de celles spécifiées dans la politique, mais doit inclure au moins une des clés spécifiées pour correspondre à la condition.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DeleteTags",
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
}
}
}
]
}
```
------
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la demande | Résultat |
| --- | --- | --- |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– environment
| **Match** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– cost-center
| **Match** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– environment
– cost-center
| **Match** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– environment
– dept
| **Match** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– dept
| **Aucune correspondance** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | Aucun `aws:TagKeys` dans le contexte de la demande. | **Aucune correspondance** |
# Exemples de politiques de conditions
Dans les politiques IAM, vous pouvez spécifier plusieurs valeurs pour les clés de contexte à valeur unique et à valeurs multiples à des fins de comparaison avec le contexte de la demande. L'ensemble suivant d'exemples de politiques montre les conditions de politique avec plusieurs clés et valeurs de contexte.
**Note**
Si vous souhaitez envoyer une politique à inclure dans ce guide de référence, utilisez le bouton **Commentaire** situé au bas de cette page. Pour accéder à des exemples de politiques IAM basées sur l'identité, veuillez consulter la rubrique [Exemples de politiques basées sur l'identité IAM](access_policies_examples.md).
## Exemples de politiques de conditions : clés de contexte à valeur unique
+ Plusieurs blocs de conditions avec des clés de contexte à valeur unique. ([Voir cet exemple](reference_policies_condition_examples-single-valued-context-keys.md#reference_policies_condition_examples-single-valued-context-keys-1).)
+ Un bloc de conditions avec plusieurs clés et valeurs de contexte à valeur unique. ([Voir cet exemple](reference_policies_condition_examples-single-valued-context-keys.md#reference_policies_condition_examples-single-valued-context-keys-2).)
## Exemples de politiques de conditions : clés de contexte à valeurs multiples.
+ Politique de refus avec opérateur d'ensemble de conditions `ForAllValues`. ([Voir cet exemple](reference_policies_condition_examples-multi-valued-context-keys.md#reference_policies_condition_examples-multi-valued-context-keys-1).)
+ Politique de refus avec opérateur d'ensemble de conditions `ForAnyValue`. ([Voir cet exemple](reference_policies_condition_examples-multi-valued-context-keys.md#reference_policies_condition_examples-multi-valued-context-keys-2).)
# Exemples de clés de contexte à valeurs multiples
L'ensemble suivant d'exemples de politiques montre comment créer des conditions de politique à l'aide de clés de contexte à valeurs multiples.
## Exemple : politique de refus avec opérateur de jeu de conditions ForAllValues
Les exemples suivants montrent comment utiliser une politique basée sur l’identité pour interdire l’utilisation d’actions de balisage IAM lorsque des préfixes de clé de balise spécifiques sont inclus dans la demande. Les valeurs pour [`aws:TagKeys`](reference_policies_condition-keys.md#condition-keys-tagkeys) incluent un caractère générique (\$1) pour la correspondance partielle des chaînes. La politique inclut l'opérateur d'ensemble `ForAllValues` avec la clé de contexte `aws:TagKeys`, car la clé de contexte de la demande peut inclure plusieurs valeurs. Afin que la clé de contexte `aws:TagKeys` corresponde, chaque valeur du contexte de la demande doit correspondre à au moins une valeur de la politique.
L’opérateur d’ensemble `ForAllValues` renvoie également vrai s’il n’y a aucune clé de contexte dans la demande.
Vous pouvez éviter que des clés de contexte manquantes ou des clés de contexte contenant des valeurs vides ne soient considérées comme vraies en incluant l’opérateur de condition `Null` dans votre politique avec une valeur `false` pour vérifier si la clé de contexte de la demande existe et si sa valeur n’est pas nulle. Pour de plus amples informations, veuillez consulter [Opérateur de condition pour vérifier l'existence de clés de condition](reference_policies_elements_condition_operators.md#Conditions_Null).
**Important**
Cette politique ne permet aucune action. Utilisez cette stratégie conjointement à d'autres stratégies qui autorisent des actions spécifiques.
**Example Refuser une seule valeur de condition de politique pour une clé de contexte à valeurs multiples**
Dans l’exemple suivant, la politique refuse les demandes dont les valeurs pour `aws:TagKeys` dans la demande n’incluent pas le préfixe **key1**. Le contexte de demande peut comporter plusieurs valeurs, mais en raison de l’opérateur d’ensemble de conditions `ForAllValues`, toutes les valeurs de clé de balise du contexte de demande doivent commencer par le préfixe **key1**.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyRestrictedTags",
"Effect": "Deny",
"Action": [
"iam:Tag*",
"iam:UnTag*"
],
"Resource": [
"*"
],
"Condition": {
"ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
}
}
}
]
}
```
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande. Pour une instruction Refuser, Correspondance est refusée et Aucune correspondance n’est pas refusée, elle peut donc être autorisée par une autre instruction.
| Condition de politique | Contexte de la demande | Résultat |
| --- | --- | --- |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
} | aws:TagKeys:
– key1:legal
| **Aucune correspondance** Peut être autorisé par une autre instruction. |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
} | aws:TagKeys:
– key1:hr
– key1:personnel
| **Aucune correspondance** Peut être autorisé par une autre instruction. |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
} | aws:TagKeys:
– key2:audit
| **Match** |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
} | Aucun `aws:TagKeys` dans le contexte de la demande. | **Match** |
**Example Refuser plusieurs valeurs de condition de politique pour une clé de contexte à valeurs multiples**
Dans l’exemple suivant, la politique refuse les demandes dont les valeurs pour `aws:TagKeys` dans la demande n’incluent pas le préfixe **key1** ou **key2**. Le contexte de demande peut comporter plusieurs valeurs, mais en raison de l’opérateur d’ensemble de conditions `ForAllValues`, toutes les valeurs de clé de balise du contexte de demande doivent commencer par le préfixe **key1** ou **key2**.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyRestrictedTags",
"Effect": "Deny",
"Action": [
"iam:Tag*",
"iam:UnTag*"
],
"Resource": [
"*"
],
"Condition": {
"ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
}
}
}
]
}
```
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande. Pour une instruction Refuser, Correspondance est refusée et Aucune correspondance n’est pas refusée, elle peut donc être autorisée par une autre instruction.
| Condition de politique | Contexte de la demande | Résultat |
| --- | --- | --- |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | aws:TagKeys:
– key1:legal
| **Aucune correspondance** Peut être autorisé par une autre instruction. |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | aws:TagKeys:
– key1:hr
– key1:personnel
| **Aucune correspondance** Peut être autorisé par une autre instruction. |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | aws:TagKeys:
– key1:hr
– key2:audit
| **Aucune correspondance** Peut être autorisé par une autre instruction. |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | aws:TagKeys:
– key3:legal
| **Match** |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | Aucun `aws:TagKeys` dans le contexte de la demande. | **Match** |
## Exemple : politique de refus avec opérateur de jeu de conditions ForAnyValue
L'exemple de politique basée sur l'identité suivant interdit la création d'instantanés de volumes d'instance EC2 si des instantanés sont balisés à l'aide de l'une des clés de balise spécifiées dans la politique, `environment` ou `webserver`. La politique inclut l'opérateur d'ensemble `ForAnyValue` avec la clé de contexte `aws:TagKeys`, car la clé de contexte de la demande peut inclure plusieurs valeurs. Si votre demande de balisage inclut l'une des valeurs de clés de balise spécifiées dans la politique, la clé de contexte `aws:TagKeys` renvoie la valeur true en invoquant l'effet de la politique de refus.
**Important**
Cette politique ne permet aucune action. Utilisez cette stratégie conjointement à d'autres stratégies qui autorisent des actions spécifiques.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:CreateSnapshot",
"ec2:CreateSnapshots"
],
"Resource": "arn:aws:ec2:us-west-2::snapshot/*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
}
}
}
]
}
```
------
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande. Pour une instruction Refuser, Correspondance est refusée et Aucune correspondance n’est pas refusée, elle peut donc être autorisée par une autre instruction.
| Condition de politique | Contexte de la demande | Résultat |
| --- | --- | --- |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
} | aws:TagKeys:
– webserver
| **Match** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
} | aws:TagKeys:
– environment
– webserver
– test
| **Match** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
} | aws:TagKeys:
– environment
– test
| **Aucune correspondance** Peut être autorisé par une autre instruction. |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
} | Aucun `aws:TagKeys` dans le contexte de la demande. | **Aucune correspondance** Peut être autorisé par une autre instruction. |
# Exemples de stratégies de clé de contexte à valeur unique
L'ensemble suivant d'exemples de politiques montre comment créer des conditions de politique à l'aide de clés de contexte à valeur unique.
## Exemple : plusieurs blocs de conditions avec des clés de contexte à valeur unique
Lorsqu'un bloc de conditions comporte plusieurs conditions, chacune associée à une seule clé de contexte, toutes les clés de contexte doivent aboutir à la valeur true pour que l'effet `Allow` ou `Deny` souhaité soit invoqué. Lorsque vous utilisez des opérateurs de condition de correspondance négative, la logique d'évaluation de la valeur de la condition est inversée.
L'exemple suivant permet aux utilisateurs de créer des volumes EC2 et d'appliquer des balises à des volumes pendant la création de volume. Le contexte de la demande doit inclure une valeur pour la clé de contexte `aws:RequestTag/project` et la valeur de la clé de contexte `aws:ResourceTag/environment` peut être n'importe quoi, sauf la production.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:CreateVolume",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:us-east-1:123456789012:volume/*",
"Condition": {
"StringLike": {
"aws:RequestTag/project": "*"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:us-east-1:123456789012:*/*",
"Condition": {
"StringNotEquals": {
"aws:ResourceTag/environment": "production"
}
}
}
]
}
```
------
Le contexte de demande doit inclure une valeur de balise de projet et ne peut pas être créé pour qu'une ressource de production puisse invoquer l'effet `Allow`. Le volume EC2 suivant a été créé avec succès, car le nom du projet est `Feature3` avec une balise de ressource `QA`.
```
aws ec2 create-volume \
--availability-zone us-east-1a \
--volume-type gp2 \
--size 80 \
--tag-specifications 'ResourceType=volume,Tags=[{Key=project,Value=Feature3},{Key=environment,Value=QA}]'
```
## Exemple : un bloc de conditions avec plusieurs clés et valeurs de contexte à valeur unique
Lorsqu'un bloc de conditions contient plusieurs clés de contexte et que chaque clé de contexte possède plusieurs valeurs, chaque clé de contexte doit aboutir à true pour au moins une valeur de clé afin que l'effet `Allow` ou `Deny` souhaité soit invoqué. Lorsque vous utilisez des opérateurs de condition de correspondance négative, la logique d'évaluation de la valeur de clé de contexte est inversée.
L'exemple suivant permet aux utilisateurs de démarrer et d'exécuter des tâches sur des clusters Amazon Elastic Container Service.
+ Le contexte de la demande doit inclure `production` **OR** `prod-backup` pour la clé de contexte `aws:RequestTag/environment`**AND**.
+ La clé de contexte `ecs:cluster` garantit que les tâches sont exécutées sur les clusters ECS d'ARN `default1` **OR** `default2`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:RunTask",
"ecs:StartTask"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
}
}
}
]
}
```
------
Le tableau suivant montre comment cette politique est AWS évaluée en fonction des valeurs des clés de condition figurant dans votre demande.
| Condition de politique | Contexte de la requête | Résultat |
| --- | --- | --- |
| "StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
} | aws:RequestTag: environment:production
ecs:cluster:
arn:aws:ecs:us-east-1:111122223333:cluster/default1
| Correspondance |
| "StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
} | aws:RequestTag: environment:prod-backup
ecs:cluster:
arn:aws:ecs:us-east-1:111122223333:cluster/default2
| Correspondance |
| "StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
} | aws:RequestTag: webserver:production
ecs:cluster:
arn:aws:ecs:us-east-1:111122223333:cluster/default2
| Aucune correspondance |
| "StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
} | Aucun `aws:RequestTag` dans le contexte de la demande. ecs:cluster
arn:aws:ecs:us-east-1:111122223333:cluster/default2
| Aucune correspondance |
# Éléments des politiques IAM : variables et balises
Utilisez des variables de stratégie Gestion des identités et des accès AWS (IAM) comme espaces réservés lorsque vous ne connaissez pas la valeur exacte d'une clé de ressource ou de condition lorsque vous rédigez la politique.
**Note**
Si vous AWS ne parvenez pas à résoudre une variable, l'intégralité de l'instruction peut être invalide. Par exemple, si vous utilisez la variable `aws:TokenIssueTime`, elle est résolue en une valeur uniquement lorsque le demandeur s'est authentifié à l'aide des informations d'identification temporaires (un rôle IAM). Pour empêcher les variables de provoquer des instructions non valides, utilisez le[... IfExists opérateur de condition.](reference_policies_elements_condition_operators.md#Conditions_IfExists)
**Topics**
+ [Introduction](#policy-vars-intro)
+ [Utilisation de variables dans les politiques](#policy-vars-using-variables)
+ [Les balises comme variables de la politique](#policy-vars-tags)
+ [Éléments dans lesquels vous pouvez utiliser des variables de politique](#policy-vars-wheretouse)
+ [Variables de politique sans valeur](#policy-vars-no-value)
+ [Informations de demande que vous pouvez utiliser dans les variables de politique](#policy-vars-infotouse)
+ [Spécification des valeurs par défaut](#policy-vars-default-values)
+ [Pour plus d’informations](#policy-vars-formoreinfo)
## Introduction
Dans les politiques IAM, de nombreuses actions vous permettent de fournir un nom pour des ressources spécifiques auxquelles vous voulez contrôler l'accès. Par exemple, la politique suivante permet aux utilisateurs d'afficher, de lire et d'écrire les objets dans le compartiment S3 `amzn-s3-demo-bucket` pour les projets `marketing`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"],
"Condition": {"StringLike": {"s3:prefix": ["marketing/*"]}}
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/marketing/*"]
}
]
}
```
------
Dans certains cas, vous ne connaissez pas le nom exact de la ressource lorsque vous écrivez la politique. Vous souhaiterez peut-être généraliser la politique de façon à ce qu'elle fonctionne pour de nombreux utilisateurs sans avoir à faire une copie unique de celle-ci pour chaque utilisateur. Au lieu de créer une politique distincte pour chaque utilisateur, nous vous recommandons de créer une politique de groupe unique qui s'applique à tous les utilisateurs du groupe.
## Utilisation de variables dans les politiques
Vous pouvez définir des valeurs dynamiques dans des politiques en utilisant des *variables de politique* qui définissent des espaces réservés dans une politique.
Les variables sont marquées à l'aide d'un préfixe **`$`** suivi d'une paire d'accolades (**`{ }`**) qui incluent le nom de variable de la valeur issue de la demande.
Lorsque la politique est évaluée, les variables de politique sont remplacées par les valeurs provenant des clés contextuelles conditionnelles passées dans la requête. Les variables peuvent être utilisées dans les [politiques basées sur l'identité, les politiques de ressources, les politiques de contrôle des services, les politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) et les [politiques de point de terminaison d’un VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html). Les politiques basées sur l'identité utilisées comme limites d'autorisations prennent également en charge les variables de politique.
Les clés de contexte des conditions globales peuvent être utilisées comme variables dans les demandes entre les AWS services. Les clés de condition spécifiques à un service peuvent également être utilisées comme variables lors de l'interaction avec des ressources AWS , mais elles ne sont disponibles que lorsque des requêtes sont effectuées auprès de ressources qui les prennent en charge. Pour obtenir la liste des clés contextuelles disponibles pour chaque AWS service et ressource, consultez la [https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html). Dans certains cas, vous ne pouvez pas renseigner les clés contextuelles des conditions globales avec une valeur. Pour en savoir plus sur chaque clé, consultez [Clés de contexte de condition globale AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html).
**Important**
Les noms des clés ne sont pas sensibles à la casse. Par exemple, `aws:CurrentTime` équivaut à `AWS:currenttime`.
Vous pouvez utiliser n'importe quelle clé de condition à valeur unique comme variable. Vous ne pouvez pas utiliser de clé de condition à valeurs multiples en tant que variable.
L'exemple suivant illustre une politique pour un rôle ou un utilisateur IAM qui remplace un nom de ressource spécifique par une variable de politique. Vous pouvez réutiliser cette politique en tirant parti de la clé de condition `aws:PrincipalTag`. Lorsque cette politique est évaluée, `${aws:PrincipalTag/team}` autorise les actions uniquement si le nom du compartiment se termine par un nom d'équipe issu de la balise de principal `team`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"],
"Condition": {"StringLike": {"s3:prefix": ["${aws:PrincipalTag/team}/*"]}}
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/${aws:PrincipalTag/team}/*"]
}
]
}
```
------
La variable est marquée à l'aide d'un préfixe `$` suivi d'une paire d'accolades (`{ }`). À l'intérieur des caractères `${ }`, vous pouvez inclure le nom de la valeur de la demande que vous souhaitez utiliser dans la politique. Les valeurs disponibles sont détaillées plus loin sur cette page.
Pour obtenir la liste détaillé de cette clé de condition globale, consultez [aws:PrincipalTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-principaltag) dans la liste des clés de condition globales.
**Note**
Pour utiliser des variables de politique, vous devez inclure l'élément `Version` dans une instruction et la version doit être définie sur une version prenant en charge de telles variables. Les variables ont été introduites dans la version `2012-10-17`. Les versions antérieures du langage de politique ne prennent pas en charge les variables de politique. Si vous n'incluez pas l'élément `Version` et que la valeur correspond à une date de version appropriée, les variables telles que `${aws:username}` sont traitées comme des chaînes littérales dans la politique.
Un élément de politique `Version` varie d'une version de politique. L'élément de politique `Version` est utilisé dans une politique pour définir la version de la langue de la politique. En revanche, une version de politique est créée lorsque vous apportez des modifications à une politique gérée par le client dans IAM. La politique modifiée ne remplace pas la politique existante. À la place, IAM crée une nouvelle version de la politique gérée. Pour en savoir plus sur l'élément de politique `Version`, consultez [Éléments de politique JSON IAM : Version](reference_policies_elements_version.md). Pour en savoir plus sur les versions de politiques, consultez [Gestion des versions des politiques IAM](access_policies_managed-versioning.md).
Une politique qui permet à un principal d'obtenir des objets à partir du chemin /David d'un compartiment S3 ressemble à ceci :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/David/*"
]
}
]
}
```
------
Si cette politique est attaché à l'utilisateur `David`, celui-ci obtient les objets de son propre compartiment S3, mais il vous faudra créer une politique distincte pour chaque utilisateur incluant le nom utilisateur. Vous devez ensuite attacher chaque politique aux utilisateurs individuels.
À l'aide d'une variable de politique, vous pouvez créer des politiques réutilisables. La politique suivante permet à un utilisateur d'obtenir des objets à partir d'un compartiment Amazon S3 si la valeur de la clé de balise `aws:PrincipalTag` correspond à la valeur de la clé de balise `owner` transmise dans la demande.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "AllowUnlessOwnedBySomeoneElse",
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["*"],
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/owner": "${aws:PrincipalTag/owner}"
}
}
}
]
}
```
------
Lorsque vous utilisez une variable de politique à la place d'un utilisateur, il n'est pas nécessaire d'avoir une politique distincte pour chaque utilisateur. Dans l'exemple suivant, la politique est attachée à un rôle IAM endossé par les Product Managers à l'aide d'informations d'identification de sécurité temporaires. Lorsqu'un utilisateur demande à ajouter un objet Amazon S3, IAM remplace la valeur de balise `dept` de la demande actuelle pour la variable `${aws:PrincipalTag}`, puis évalue la politique.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowOnlyDeptS3Prefix",
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/${aws:PrincipalTag/dept}/*"
]
}
]
}
```
------
## Les balises comme variables de la politique
Dans certains AWS services, vous pouvez associer vos propres attributs personnalisés aux ressources créées par ces services. Par exemple, vous pouvez appliquer des balises aux compartiments Amazon S3 ou aux utilisateurs IAM. Ces balises sont des paires clé-valeur. Vous définissez le nom de clé de balise et la valeur qui est associée à ce nom de clé. Par exemple, vous pouvez créer une balise avec une clé **department** et une valeur **Human Resources**. Pour plus d'informations sur le balisage des entités IAM, consultez [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md). Pour plus d'informations sur le balisage des ressources créées par d'autres services AWS , reportez-vous à la documentation de ce service. Pour plus d'informations sur l'utilisation de Tag Editor, consultez [Utilisation de Tag Editor](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html) dans le *Guide de l'utilisateur AWS Management Console *.
Vous pouvez baliser des ressources IAM pour simplifier la découverte, l'organisation et le suivi de vos ressources IAM. Vous pouvez aussi baliser les identités IAM pour contrôler l'accès aux ressources ou au balisage lui-même. Pour en savoir plus sur l'utilisation des balises pour contrôler l'accès, consultez [Contrôle de l'accès aux et pour les utilisateurs et rôles IAM à l'aide de balises](access_iam-tags.md).
## Éléments dans lesquels vous pouvez utiliser des variables de politique
Vous pouvez utiliser des variables de politique dans l'élément `Resource` et les comparaisons de chaîne de l'élément `Condition`.
### Élément de ressource
Vous pouvez utiliser une variable de politique dans l'élément `Resource`, mais uniquement dans la partie ressource de l'ARN. Cette partie de l'ARN apparaît après le cinquième deux-points (:). Vous ne pouvez pas utiliser une variable pour remplacer des parties de l'ARN avant le cinquième deux-points, par exemple le service ou le compte. Pour de plus amples informations sur le format ARN, veuillez consulter [IAM ARNs](reference_identifiers.md#identifiers-arns).
Pour remplacer une partie d'un ARN avec une valeur de balise, encadrez le préfixe et le nom de clé avec `${ }`. Par exemple, l'élément de ressource suivant fait référence à un seul compartiment qui est nommé à l'identique de la valeur de la balise du service de l'utilisateur demandeur.
`"Resource": ["arn:aws::s3:::amzn-s3-demo-bucket/${aws:PrincipalTag/department}"]`
De nombreuses AWS ressources ARNs contiennent un nom créé par l'utilisateur. La politique IAM suivante garantit que seuls les utilisateurs concernés dont les valeurs de balises access-project, access-application et access-environment sont correspondantes peuvent modifier leurs ressources. En outre, en utilisant le [caractère générique \$1](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html), ils peuvent autoriser des suffixes de nom de ressources personnalisés.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAccessBasedOnArnMatching",
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:DeleteTopic"],
"Resource": ["arn:aws:sns:*:*:${aws:PrincipalTag/access-project}-${aws:PrincipalTag/access-application}-${aws:PrincipalTag/access-environment}-*"
]
}
]
}
```
------
### Élément de condition
Vous pouvez utiliser une variable de politique pour les valeurs `Condition` dans n'importe quelle condition impliquant les opérateurs de chaîne ou les opérateurs ARN. Les opérateurs de chaîne incluent `StringEquals`, `StringLike` et `StringNotLike`. Les opérateurs ARN incluent `ArnEquals` et `ArnLike`. Vous ne pouvez pas utiliser une variable de politique avec d'autres opérateurs, tels que les opérateurs `Numeric`, `Date`, `Boolean`, `Binary`, `IP Address` ou `Null`. Pour de plus amples informations sur les opérateurs de condition, veuillez consulter [Éléments de politique JSON IAM : Opérateurs de condition](reference_policies_elements_condition_operators.md).
Lorsque vous faites référence à une balise dans une expression de l'élément `Condition`, utilisez le préfixe et le nom de clé pertinents comme clé de condition. Utilisez ensuite la valeur que vous souhaitez tester dans la valeur de condition.
Par exemple, l'exemple de politique suivant autorise l'accès complet aux utilisateurs, mais uniquement si la balise `costCenter` est attachée à l'utilisateur. La balise doit également avoir la valeur `12345` ou `67890`. Si la balise n'a pas de valeur, ou toute autre valeur, la demande échoue.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:*user*"
],
"Resource": "*",
"Condition": {
"StringLike": {
"iam:ResourceTag/costCenter": [ "12345", "67890" ]
}
}
}
]
}
```
------
## Variables de politique sans valeur
Lorsque les variables de politique font référence à une clé contextuelle de condition qui n'a aucune valeur ou qui n'est pas présente dans le contexte d'autorisation d'une requête, la valeur est effectivement nulle. Il n'existe pas de valeur égale ou similaire. Les clés contextuelles de condition peuvent ne pas être présentes dans le contexte d'autorisation lorsque :
+ Vous utilisez des clés contextuelles de condition spécifiques au service dans les requêtes adressées à des ressources qui ne prennent pas en charge cette clé de condition.
+ Les balises sur les principaux, les sessions, les ressources ou les demandes IAM ne sont pas présentes.
+ Les autres cas répertoriés pour chaque condition globale sont incluses dans le contexte [AWS clés contextuelles de condition globale](reference_policies_condition-keys.md).
Lorsque vous utilisez une variable sans valeur dans l'élément de condition d'une politique IAM, [Éléments de politique JSON IAM : Opérateurs de condition](reference_policies_elements_condition_operators.md) comme `StringEquals` ou `StringLike` ne correspondent pas et la déclaration de politique ne prend pas effet.
Les opérateurs de condition inversés comme `StringNotEquals` ou `StringNotLike` correspondent à une valeur nulle, car la valeur de la clé conditionnelle par rapport à laquelle ils testent n'est pas égale ou similaire à la valeur effectivement nulle.
Dans l'exemple suivant, `aws:principaltag/Team` doit être égal à `s3:ExistingObjectTag/Team` pour autoriser l'accès. L'accès est explicitement refusé lorsque `aws:principaltag/Team` n'est pas défini. Si une variable qui n'a aucune valeur dans le contexte d'autorisation est utilisée dans le cadre de l'élément `Resource` or `NotResource` d'une politique, la ressource qui inclut une variable de politique sans valeur ne correspondra à aucune ressource.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:ExistingObjectTag/Team": "${aws:PrincipalTag/Team}"
}
}
}
]
}
```
------
## Informations de demande que vous pouvez utiliser dans les variables de politique
Vous pouvez utiliser l'élément `Condition` d'une politique JSON pour comparer des clés dans le [contexte de demande](reference_policies_evaluation-logic_policy-eval-reqcontext.md) avec les valeurs de clé spécifiées dans votre politique. Lorsque vous utilisez une variable de politique, AWS substitue une valeur de la clé de contexte de demande à la place de la variable dans votre politique.
### Valeurs de la clé du principal
Les valeurs de `aws:username`, `aws:userid` et `aws:PrincipalType` dépendent du type de principal ayant initialisé la demande. Par exemple, la demande peut être effectuée à l'aide des informations d'identification d'un utilisateur IAM, d'un rôle IAM ou de l' Utilisateur racine d'un compte AWS. La de tableaux suivante affiche les valeurs de ces clés pour différents types de principaux.
****
| Principal | `aws:username` | `aws:userid` | `aws:PrincipalType` |
| --- | --- | --- | --- |
| Utilisateur racine d'un compte AWS | (absent) | Compte AWS ID | Account |
| Utilisateur IAM | IAM-user-name | [ID unique](reference_identifiers.md#identifiers-unique-ids) | User |
| AWS STS utilisateur principal fédéré | (absent) | account:caller-specified-name | FederatedUser |
| Principal fédéré OIDC Pour plus d'informations sur les clés de politique disponibles lors de l'utilisation de la fédération d'identité web, consultez [Clés disponibles pour la AWS fédération OIDC](reference_policies_iam-condition-keys.md#condition-keys-wif). | (absent) | *role-id*:*caller-specified-role-name* où `role-id` est l'[identifiant unique du rôle](reference_identifiers.md#identifiers-unique-ids) et caller-specified-role-name est spécifié par le [RoleSessionName paramètre](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AssumeRole.html#API_AssumeRoleWithWebIdentity_RequestParameters) passé à la AssumeRoleWithWebIdentity demande. | AssumedRole |
| Principal fédéré SAML Pour plus d'informations sur les clés de politique disponibles lors de l'utilisation de la fédération SAML, consultez [Identification unique des utilisateurs dans la fédération SAML](id_roles_providers_saml.md#CreatingSAML-userid). | (absent) | *role-id*:*caller-specified-role-name* où `role-id` est l'[identifiant unique du rôle](reference_identifiers.md#identifiers-unique-ids) et caller-specified-role-name est spécifié par l'élément Attribute avec l'[attribut Name](id_roles_providers_create_saml_assertions.md) défini sur https://aws.amazon.com/SAML/ attributes/RoleSessionName. | AssumedRole |
| Rôle endossé | (absent) | *role-id*:*caller-specified-role-name* où `role-id` est l'[identifiant unique du rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) et caller-specified-role-name est spécifié par le [RoleSessionName paramètre](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters) passé à la AssumeRole demande. | AssumedRole |
| Rôle affecté à une instance Amazon EC2 | (absent) | *role-id*:*ec2-instance-id* où `role-id` est [l'ID unique du rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) et ec2-instance-id est l'[identifiant unique de l'instance EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html). | AssumedRole |
| Appelant anonyme (Amazon SQS, Amazon SNS et Amazon S3 uniquement) | (absent) | anonymous | Anonymous |
Pour les éléments de cette table, notez les points suivants :
+ *absent* signifie que la valeur ne figure pas dans les informations de la demande en cours et par conséquent, toute tentative de correspondance échoue et rend l'instruction non valide.
+ *role-id*est un identifiant unique attribué à chaque rôle lors de sa création. Vous pouvez afficher l'ID du rôle à l'aide de la AWS CLI commande suivante : `aws iam get-role --role-name rolename`
+ *caller-specified-name*et *caller-specified-role-name* sont des noms transmis par le processus appelant (comme une application ou un service) lorsqu'il effectue un appel pour obtenir des informations d'identification temporaires.
+ *ec2-instance-id*est une valeur attribuée à l'instance lors de son lancement et qui apparaît sur la page **Instances** de la console Amazon EC2. Vous pouvez également afficher l'ID de l'instance en exécutant la AWS CLI commande suivante : `aws ec2 describe-instances`
### Informations relatives aux principaux fédérés disponibles dans les demandes
Les principaux fédérés sont des utilisateurs authentifiés à l’aide d’un système autre qu’IAM. Par exemple, une entreprise peut avoir une application à utiliser en interne qui passe des appels à AWS. L'attribution d'une identité IAM à chaque utilisateur de l'entreprise qui utilise l'application peut ne pas convenir. Au lieu de cela, l'entreprise peut utiliser une application proxy (intermédiaire) qui dispose d'une identité IAM unique ou un fournisseur d'identité (IdP) SAML. L'application proxy ou l'IdP SAML authentifie les utilisateurs individuels via le réseau d'entreprise. Une application proxy peut ensuite utiliser son identité IAM pour obtenir des informations d'identification de sécurité temporaires pour des utilisateurs individuels. Un IdP SAML peut en effet échanger des informations d'identité contre des informations AWS de sécurité temporaires. Les informations d'identification temporaires peuvent ensuite être utilisées pour accéder aux AWS ressources.
De même, vous pouvez créer une application pour appareil mobile qui doit accéder aux ressources AWS . Dans ce cas, vous pouvez utiliser la *fédération OIDC* dans laquelle l’application authentifie l’utilisateur à l’aide d’un fournisseur d’identité connu tel que Login with Amazon, Amazon Cognito, Facebook ou Google. L'application peut ensuite utiliser les informations d'authentification de l'utilisateur à partir de ces fournisseurs pour obtenir les informations d'identification de sécurité temporaires permettant d'accéder aux ressources AWS .
La méthode recommandée pour utiliser la fédération OIDC est de tirer parti d'Amazon Cognito et AWS du mobile. SDKs Pour plus d’informations, consultez les ressources suivantes :
+ [Guide de l'utilisateur d'Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html)
+ [Scénarios courants d'informations d'identification temporaires](id_credentials_temp.md#sts-introduction)
### Caractères spéciaux
Quelques variables de politique prédéfinies spéciales sont dotées de valeurs fixes qui vous permettent de représenter des caractères qui, sinon, ont une signification spéciale. Si ces caractères spéciaux font partie de la chaîne que vous essayez de faire correspondre et qu'ils sont insérés littéralement, ils sont susceptibles d'être mal interprétés. Par exemple, un astérisque (\$1) inséré dans la chaîne sera interprété comme un caractère générique, ce qui correspond à n'importe quel caractère, au lieu d'un caractère \$1 littéral. Dans ces cas, vous pouvez utiliser les variables de politique prédéfinies suivantes :
+ **\$1\$1\$1\$1** – permet d'obtenir le caractère \$1 (astérisque).
+ **\$1\$1?\$1** – permet d'obtenir le caractère ? (point d'interrogation).
+ **\$1\$1\$1\$1** – permet d'obtenir le caractère \$1 (dollar).
Ces variables de politique prédéfinies peuvent être utilisées dans n'importe quelle chaîne acceptant les variables de politique standard.
## Spécification des valeurs par défaut
Pour ajouter une valeur par défaut à une variable, entourez la valeur par défaut de guillemets simples (`' '`), puis séparez le texte de la variable et la valeur par défaut par une virgule et une espace (`, `).
Par exemple, si un principal est labelisé avec l’interface `team=yellow`, il peut accéder au compartiment Amazon S3 `ExampleCorp's` nommé `amzn-s3-demo-bucket-yellow`. Une politique avec cette ressource permet aux membres de l'équipe d'accéder à leur compartiment d'équipe, mais pas à ceux des autres équipes. Pour les utilisateurs sans identifications d'équipe, il définit une valeur par défaut de l’interface `company-wide` pour le nom du compartiment. Ces utilisateurs peuvent accéder uniquement au compartiment `amzn-s3-demo-bucket-company-wide` où ils peuvent afficher des informations générales, telles que des instructions pour rejoindre une équipe.
```
"Resource":"arn:aws:s3:::amzn-s3-demo-bucket-${aws:PrincipalTag/team, 'company-wide'}"
```
## Pour plus d’informations
Pour plus d'informations sur les politiques, consultez les ressources suivantes :
+ [Politiques et autorisations dans Gestion des identités et des accès AWS](access_policies.md)
+ [Exemples de politiques basées sur l'identité IAM](access_policies_examples.md)
+ [Référence de l’élément de politique JSON IAM](reference_policies_elements.md)
+ [Logique d'évaluation de politiques](reference_policies_evaluation-logic.md)
+ [Fédération OIDC](id_roles_providers_oidc.md)
# Éléments de politique JSON IAM : Types de données pris en charge
Cette section répertorie les types de données pris en charge lors de la spécification de valeurs dans des politiques JSON. Le langage de politique ne prend pas en charge tous les types d'éléments de politique ; reportez-vous aux sections précédentes pour plus d'informations sur chaque élément.
+ Chaînes
+ Nombres (Ints et Floats)
+ Booléen
+ Null
+ Lists
+ Mappages
+ Structs (simples mappages intégrés)
Le tableau suivant mappe chaque type de données à la sérialisation. Notez que toutes les politiques doivent utiliser le format UTF-8. Pour plus d'informations sur les types de données JSON, reportez-vous à [RFC 4627](https://datatracker.ietf.org/doc/html/rfc4627).
****
| Type | JSON |
| --- | --- |
| String | String |
| Entier | Number |
| Float | Number |
| Booléen | true false |
| Null | null |
| Date | Chaîne conforme au [profil W3C d'ISO 8601](http://www.w3.org/TR/NOTE-datetime) |
| IpAddress | Chaîne conforme à [RFC 4632](https://datatracker.ietf.org/doc/html/rfc4632) |
| List | Tableau |
| Objet | Objet |