

• Le AWS Systems Manager CloudWatch tableau de bord ne sera plus disponible après le 30 avril 2026. Les clients peuvent continuer à utiliser CloudWatch la console Amazon pour consulter, créer et gérer leurs CloudWatch tableaux de bord Amazon, comme ils le font aujourd'hui. Pour plus d'informations, consultez la [documentation Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). 

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Exemples de politiques basées sur l’identité AWS Systems Manager
<a name="security_iam_id-based-policy-examples"></a>

Par défaut, les entités Gestion des identités et des accès AWS (IAM) (utilisateurs et rôles) ne sont pas autorisées à créer ou à modifier AWS Systems Manager des ressources. Ils ne peuvent pas non plus effectuer de tâches à l'aide de la console Systems Manager AWS Command Line Interface (AWS CLI) ou de AWS l'API. Un administrateur doit créer des politiques IAM autorisant les utilisateurs et les rôles à exécuter des opérations d’API spécifiques sur les ressources spécifiées dont ils ont besoin. Il doit ensuite attacher ces stratégies aux utilisateurs ou aux groupes ayant besoin de ces autorisations.

Voici un exemple de politique d'autorisation qui permet à un utilisateur de supprimer des documents dont le nom commence par **MyDocument-** dans l'est des États-Unis (Ohio) (us-east-2). Région AWS

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : [
        "ssm:DeleteDocument"
      ],
      "Resource" : [
        "arn:aws:ssm:us-east-1:111122223333:document/MyDocument-*"
      ]
    }
  ]
}
```

------

Pour apprendre à créer une politique basée sur l'identité IAM à l'aide de ces exemples de documents de politique JSON, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) dans le *Guide de l'utilisateur IAM*.

**Topics**
+ [Bonnes pratiques en matière de politiques](#security_iam_service-with-iam-policy-best-practices)
+ [Exemple : autorisation d’utiliser la console Systems Manager](#security_iam_id-based-policy-examples-console)
+ [Exemple : autorisation pour autoriser les utilisateurs à afficher leurs propres autorisations](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Exemple : autorisation de lire et décrire des paramètres individuels](#security_iam_id-based-policy-examples-view-one-parameter)
+ [Prévention du problème de l’adjoint confus entre services](cross-service-confused-deputy-prevention.md)
+ [Exemples de politiques gérées par le client](#customer-managed-policies)
+ [Affichage de documents Systems Manager basés sur des balises](#security_iam_id-based-policy-examples-view-documents-tags)

## Bonnes pratiques en matière de politiques
<a name="security_iam_service-with-iam-policy-best-practices"></a>

Les stratégies basées sur l’identité déterminent si une personne peut créer, consulter ou supprimer des ressources Systems Manager dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.

Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.

## Exemple : autorisation d’utiliser la console Systems Manager
<a name="security_iam_id-based-policy-examples-console"></a>

Pour accéder à la console Systems Manager, vous devez disposer d'un ensemble minimum d'autorisations. Ces autorisations doivent vous permettre de répertorier et consulter les informations relatives aux ressources Systems Manageret aux autres ressources de votre Compte AWS. 

Si vous créez une politique basée sur l'identité qui est plus restrictive que les autorisations minimales requises, la console ne fonctionnera pas comme prévu pour les entités IAM (utilisateurs et rôles) tributaires de cette politique.

Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement l'API AWS CLI ou l' AWS API. Autorisez plutôt l’accès à uniquement aux actions qui correspondent à l’opération d’API que vous tentez d’effectuer.

Pour garantir que les utilisateurs et les rôles peuvent toujours utiliser la console Systems Manager, associez également la politique SSMRead OnlyAccess AWS gérée par [Amazon SSMFull Access](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMFullAccess.html) [ou Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMReadOnlyAccess.html) aux entités. Pour plus d’informations, consultez [Ajout d’autorisations à un utilisateur](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) dans le *Guide de l’utilisateur IAM*.

## Exemple : autorisation pour autoriser les utilisateurs à afficher leurs propres autorisations
<a name="security_iam_id-based-policy-examples-view-own-permissions"></a>

Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS .

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}
```

## Exemple : autorisation de lire et décrire des paramètres individuels
<a name="security_iam_id-based-policy-examples-view-one-parameter"></a>

**Example Lire et décrire un paramètre**  
Vous pouvez accorder l’accès à un paramètre en attachant la stratégie suivante à une identité.    
****  

```
{
"Version":"2012-10-17",		 	 	 
"Statement": [
  {
    "Effect": "Allow",
    "Action": [
      "ssm:GetParameter",
      "ssm:DescribeParameters"
      ],
    "Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/parameter-name"
  }
]
}
```

# Prévention du problème de l’adjoint confus entre services
<a name="cross-service-confused-deputy-prevention"></a>

Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. En AWS, l'usurpation d'identité interservices peut entraîner la confusion des adjoints. L’usurpation d’identité entre services peut se produire lorsqu’un service (le *service appelant*) appelle un autre service (le *service appelé*). Le service appelant peut être manipulé et ses autorisations utilisées pour agir sur les ressources d’un autre client auxquelles on ne serait pas autorisé à accéder autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services auprès des principaux fournisseurs de services qui ont obtenu l'accès aux ressources de votre compte. 

Nous vous recommandons d'utiliser les clés de contexte de condition globale [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) et [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) dans les politiques de ressources afin de limiter les autorisations à la ressource octroyées par AWS Systems Manager à un autre service. Si la valeur `aws:SourceArn` ne contient pas l'ID de compte, tel qu'un Amazon Resource Name (ARN) pour un compartiment S3, vous devez utiliser les deux clés de contexte de condition globale pour limiter les autorisations. Si vous utilisez les deux clés de contexte de condition globale et que la valeur `aws:SourceArn` contient l'ID de compte, la valeur `aws:SourceAccount` et le compte dans la valeur `aws:SourceArn` doivent utiliser le même ID de compte lorsqu'ils sont utilisés dans la même instruction de politique. Utilisez `aws:SourceArn` si vous souhaitez qu'une seule ressource soit associée à l'accès entre services. Utilisez `aws:SourceAccount` si vous souhaitez autoriser l’association d’une ressource de ce compte à l’utilisation interservices.

Les sections suivantes fournissent des exemples de politiques pour les outils AWS Systems Manager.

## Exemple de politique d'activation hybride
<a name="cross-service-confused-deputy-prevention-hybrid"></a>

Pour les fonctions du service utilisées dans une [activation hybride](activations.md), la valeur de l'`aws:SourceArn` doit correspondre à l'ARN de l' Compte AWS. Assurez-vous de le spécifier Région AWS dans l'ARN dans lequel vous avez créé votre activation hybride. Si vous ne connaissez pas l'ARN complet de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de contexte de condition globale `aws:SourceArn` avec des caractères génériques (`*`) pour les parties inconnues de l'ARN. Par exemple, `arn:aws:ssm:*:region:123456789012:*`.

L'exemple suivant illustre l'utilisation des lés de contexte de condition globale `aws:SourceArn` et `aws:SourceAccount` pour Automation afin de prévenir le problème confus des adjoints dans la Région USA Est (Ohio) (us-east-2).

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement":[
      {
         "Sid":"",
         "Effect":"Allow",
         "Principal":{
            "Service":"ssm.amazonaws.com"
         },
         "Action":"sts:AssumeRole",
         "Condition":{
            "StringEquals":{
               "aws:SourceAccount":"123456789012"
            },
            "ArnEquals":{
               "aws:SourceArn":"arn:aws:ssm:us-east-1:123456789012:*"
            }
         }
      }
   ]
}
```

------

## Exemple de politique de synchronisation des données de ressources
<a name="cross-service-confused-deputy-prevention-rds"></a>

Systems ManagerExplorer, Inventory et Compliance vous permettent de créer une synchronisation des données de ressources afin de centraliser le stockage de vos données d'exploitation (OpsData) dans un bucket Amazon Simple Storage Service central. Si vous souhaitez chiffrer une synchronisation de données de ressource à l'aide de AWS Key Management Service (AWS KMS), vous devez soit créer une nouvelle clé incluant la politique suivante, soit mettre à jour une clé existante et y ajouter cette politique. Les clés de condition `aws:SourceArn` et `aws:SourceAccount` de cette politique empêchent le problème du député confus. Voici un exemple de politique.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "ssm-access-policy",
    "Statement": [
        {
            "Sid": "ssm-access-policy-statement",
            "Action": [
                "kms:GenerateDataKey"
            ],
            "Effect": "Allow",
            "Principal": {
                "Service": "ssm.amazonaws.com"
            },
            "Resource": "arn:aws:kms:us-east-1:123456789012:key/KMS_key_id",
            "Condition": {
                "StringLike": {
                    "aws:SourceAccount": "123456789012"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:ssm:*:123456789012:role/aws-service-role/ssm.amazonaws.com/AWSServiceRoleForAmazonSSM"
                }
            }
        }
    ]
}
```

------

**Note**  
L'ARN dans l'exemple de politique permet au système de chiffrer à OpsData partir de toutes les sources sauf AWS Security Hub CSPM. Si vous devez chiffrer des données Security Hub CSPM, par exemple si vous les utilisez Explorer pour collecter des données Security Hub CSPM, vous devez joindre une politique supplémentaire qui spécifie l'ARN suivant :  
`"aws:SourceArn": "arn:aws:ssm:*:account-id:role/aws-service-role/opsdatasync.ssm.amazonaws.com/AWSServiceRoleForSystemsManagerOpsDataSync"` 

## Exemples de politiques gérées par le client
<a name="customer-managed-policies"></a>

Vous pouvez créer des politiques autonomes que vous gérez dans votre propre Compte AWS. Nous les appelons *politiques gérées par le client*. Vous pouvez associer ces politiques à plusieurs entités principales de votre Compte AWS. Lorsque vous attachez une politique à une entité principale, vous accordez à cette dernière les autorisations définies dans la politique. Pour plus d'informations, consultez[Exemples de politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) dans le *[Guide de l'utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/)*.

Les exemples suivants de politiques utilisateur accordent des autorisations pour différentes actions Systems Manager. Utilisez-les pour limiter l'accès à Systems Manager pour vos entités IAM (utilisateurs et rôles). Ces politiques fonctionnent lorsque vous effectuez des actions dans l'Systems ManagerAPI AWS SDKs, ou le AWS CLI. Pour les utilisateurs qui utilisent la console, vous devez accorder des autorisations supplémentaires propres à la console. Pour de plus amples informations, veuillez consulter [Exemple : autorisation d’utiliser la console Systems Manager](#security_iam_id-based-policy-examples-console).

**Note**  
Tous les exemples utilisent la région USA Ouest (Oregon) (us-west-2) et contiennent un récit fictif. IDs L'ID de compte ne doit pas être spécifié dans le nom de ressource Amazon (ARN) pour les documents AWS publics (documents commençant par`AWS-*`).

 **Exemples** 
+  [Exemple 1 : Autoriser un utilisateur à effectuer des opérations Systems Manager dans une seule région](#identity-based-policies-example-1) 
+  [Exemple 2 : Autoriser un utilisateur à répertorier les documents pour une seule région](#identity-based-policies-example-2) 

### Exemple 1 : Autoriser un utilisateur à effectuer des opérations Systems Manager dans une seule région
<a name="identity-based-policies-example-1"></a>

L'exemple suivant accorde des autorisations pour effectuer des opérations Systems Manager uniquement dans la Région USA Est (Ohio) (us-east-2).

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:*"
            ],
            "Resource": [
                "arn:aws:ssm:us-east-1:111122223333:*"
            ]
        }
    ]
}
```

------

### Exemple 2 : Autoriser un utilisateur à répertorier les documents pour une seule région
<a name="identity-based-policies-example-2"></a>

L'exemple suivant accorde des permissions pour répertorier tous les noms de documents qui commencent par **Update** dans la Région USA Est (Ohio) (us-east-2).

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:ListDocuments"
            ],
            "Resource": [
                "arn:aws:ssm:us-east-1:111122223333:document/Update*"
            ]
        }
    ]
}
```

------

### Exemple 3 : Autoriser un utilisateur à utiliser un document SSM spécifique pour exécuter des commandes sur des nœuds spécifiques
<a name="identity-based-policies-example-3"></a>

L'exemple de politique IAM suivant permet à un utilisateur d'effectuer les opérations suivantes dans la Région USA Est (Ohio) (us-east-2) :
+ Répertorier les documents Systems Manager (documents SSM) et les versions de documents.
+ Afficher les détails des documents.
+ Envoyer une commande à l'aide du document indiqué dans la politique. Le nom du document est défini par l'entrée suivante.

  ```
  arn:aws:ssm:us-east-2:aws-account-ID:document/Systems-Manager-document-name
  ```
+ Envoyer une commande à trois nœuds. Les nœuds sont déterminés par les entrées suivantes dans la seconde section `Resource`.

  ```
  "arn:aws:ec2:us-east-2:aws-account-ID:instance/i-02573cafcfEXAMPLE",
  "arn:aws:ec2:us-east-2:aws-account-ID:instance/i-0471e04240EXAMPLE",
  "arn:aws:ec2:us-east-2:aws-account-ID:instance/i-07782c72faEXAMPLE"
  ```
+ Afficher les détails d'une commande après qu'elle ait été envoyée.
+ Démarrer et arrêter des flux de travail dans Automation, un outil d’ AWS Systems Manager.
+ Obtenir des informations sur les flux de travail Automation.

Si vous souhaitez accorder à un utilisateur l'autorisation d'utiliser ce document pour envoyer des commandes sur n'importe quel nœud auquel l'utilisateur a accès, vous pouvez spécifier l'entrée suivante dans la section `Resource` et supprimer les autres entrées de nœud. L'exemple utilise la Région USA Est (Ohio) (us-east-2).

```
"arn:aws:ec2:us-east-2:*:instance/*"
```

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Action": [
                "ssm:ListDocuments",
                "ssm:ListDocumentVersions",
                "ssm:DescribeDocument",
                "ssm:GetDocument",
                "ssm:DescribeInstanceInformation",
                "ssm:DescribeDocumentParameters",
                "ssm:DescribeInstanceProperties"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": "ssm:SendCommand",
            "Effect": "Allow",
            "Resource": [
                "arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
                "arn:aws:ec2:us-east-1:111122223333:instance/i-0471e04240EXAMPLE",
                "arn:aws:ec2:us-east-1:111122223333:instance/i-07782c72faEXAMPLE",
                
                "arn:aws:ssm:us-east-1:111122223333:document/Systems-Manager-document-name"
            ]
        },
        {
            "Action": [
                "ssm:CancelCommand",
                "ssm:ListCommands",
                "ssm:ListCommandInvocations"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": "ec2:DescribeInstanceStatus",
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": "ssm:StartAutomationExecution",
            "Effect": "Allow",
            "Resource": [
                "arn:aws:ssm:us-east-1:111122223333:document/*",
                "arn:aws:ssm:us-east-1:111122223333:automation-execution/*"
            ]
        },
        {
            "Action": "ssm:DescribeAutomationExecutions",
            "Effect": "Allow",
            "Resource": [
                "*"
            ]
        },
        {
            "Action": [
                "ssm:StopAutomationExecution",
                "ssm:GetAutomationExecution"
            ],
            "Effect": "Allow",
            "Resource": [
                "*"
            ]
        }
    ]
}
```

------

## Affichage de documents Systems Manager basés sur des balises
<a name="security_iam_id-based-policy-examples-view-documents-tags"></a>

Vous pouvez utiliser des conditions dans votre politique basée sur l'identité pour contrôler l'accès aux ressources Systems Manager en fonction des balises. Cet exemple montre comment créer une politique qui permet d'afficher un document SSM. Toutefois, l'autorisation est accordée uniquement si la balise de document `Owner` a la valeur du nom de l'utilisateur. Cette politique accorde également les autorisations nécessaires pour réaliser cette action sur la console.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ListDocumentsInConsole",
            "Effect": "Allow",
            "Action": "ssm:ListDocuments",
            "Resource": "*"
        },
        {
            "Sid": "ViewDocumentIfOwner",
            "Effect": "Allow",
            "Action": "ssm:GetDocument",
            "Resource": "arn:aws:ssm:*:*:document/*",
            "Condition": {
                "StringEquals": {"ssm:ResourceTag/Owner": "${aws:username}"}
            }
        }
    ]
}
```

------

Vous pouvez attacher cette stratégie aux utilisateurs de votre compte. Si un utilisateur nommé `richard-roe` tente d'afficher un document Systems Manager, le document doit avoir la balise `Owner=richard-roe` ou `owner=richard-roe`. Dans le cas contraire, l'accès est refusé. La clé de condition de balise `Owner` correspond à la fois à `Owner` et à `owner`, car les noms de clé de condition ne sont pas sensibles à la casse. Pour plus d'informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l'utilisateur IAM*.