

Avis de fin de support : le 20 mai 2026, AWS le support de AWS IoT Events. Après le 20 mai 2026, vous ne pourrez plus accéder à la AWS IoT Events console ni aux AWS IoT Events ressources. Pour plus d'informations, consultez [AWS IoT Events la fin du support](https://docs.aws.amazon.com/iotevents/latest/developerguide/iotevents-end-of-support.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.

# Prévention interservices confuse des adjoints pour AWS IoT Events
<a name="cross-service-confused-deputy-prevention"></a>

**Note**  
Le AWS IoT Events service vous permet uniquement d'utiliser des rôles pour démarrer des actions dans le même compte dans lequel une ressource a été créée. Cela permet d'éviter une attaque adjointe confuse AWS IoT Events.
Cette page vous sert de référence pour voir comment fonctionne le problème de confusion des adjoints et peut être évité si les ressources entre comptes étaient autorisées dans le AWS IoT Events service.

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 recommandons d'utiliser les clés de contexte de condition [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)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 les clés contextuelles dans les politiques de ressources afin de limiter les autorisations qui AWS IoT Events accordent un autre service à la ressource. Si la valeur `aws:SourceArn` ne contient pas l'ID du compte, tel qu'un ARN de compartiment Amazon 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. La valeur de `aws:SourceArn` doit être le modèle de détecteur ou le modèle d'alarme associé à la `sts:AssumeRole` demande.

Le moyen le plus efficace de se protéger contre le problème de député confus consiste à utiliser la clé de contexte de condition globale `aws:SourceArn` avec l’ARN complet de la ressource. 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:iotevents:*:123456789012:*`. 

Les exemples suivants montrent comment utiliser les touches de contexte de condition `aws:SourceAccount` globale `aws:SourceArn` et globale AWS IoT Events pour éviter le problème de confusion des adjoints.

**Topics**
+ [Exemple : accès sécurisé à un modèle AWS IoT Events de détecteur](accessing-a-detector-model.md)
+ [Exemple : accès sécurisé à un modèle AWS IoT Events d'alarme](accessing-an-alarm-model.md)
+ [Exemple : accéder à une AWS IoT Events ressource dans une région spécifiée](accessing-resource-in-specified-region.md)
+ [Exemple : configurer les options de journalisation pour AWS IoT Events](logging-options.md)

# Exemple : accès sécurisé à un modèle AWS IoT Events de détecteur
<a name="accessing-a-detector-model"></a>

Cet exemple montre comment créer une politique IAM qui accorde en toute sécurité l'accès à un modèle de détecteur spécifique dans AWS IoT Events. La politique utilise des conditions pour garantir que seuls le AWS compte et le AWS IoT Events service spécifiés peuvent assumer le rôle, ajoutant ainsi un niveau de sécurité supplémentaire. Dans cet exemple, le rôle peut uniquement accéder au modèle de détecteur nommé*WindTurbine01*.

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

****  

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

------

# Exemple : accès sécurisé à un modèle AWS IoT Events d'alarme
<a name="accessing-an-alarm-model"></a>

Cet exemple montre comment créer une politique IAM qui permet d'accéder en toute sécurité AWS IoT Events aux modèles d'alarme. La politique utilise des conditions pour garantir que seuls le AWS compte et le AWS IoT Events service spécifiés peuvent assumer le rôle.

Dans cet exemple, le rôle peut accéder à n'importe quel modèle d'alarme au sein du AWS compte spécifié, comme indiqué par le `*` caractère générique dans l'ARN du modèle d'alarme. Les `aws:SourceArn` conditions `aws:SourceAccount` et les conditions fonctionnent ensemble pour éviter le problème confus des adjoints.

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

****  

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

------

# Exemple : accéder à une AWS IoT Events ressource dans une région spécifiée
<a name="accessing-resource-in-specified-region"></a>

Cet exemple montre comment configurer un rôle IAM pour accéder aux AWS IoT Events ressources d'une AWS région spécifique. En utilisant des politiques IAM spécifiques ARNs à une région, vous pouvez restreindre l'accès aux AWS IoT Events ressources dans différentes zones géographiques. Cette approche peut aider à maintenir la sécurité et la conformité dans les déploiements multirégionaux. Dans cet exemple, la région est*us-east-1*.

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

****  

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

------

# Exemple : configurer les options de journalisation pour AWS IoT Events
<a name="logging-options"></a>

Une journalisation appropriée est importante pour la surveillance, le débogage et l'audit de vos AWS IoT Events applications. Cette section fournit un aperçu des options de journalisation disponibles dans AWS IoT Events.

Cet exemple montre comment configurer un rôle IAM qui permet de AWS IoT Events consigner des données dans CloudWatch Logs. L'utilisation de caractères génériques (`*`) dans l'ARN de la ressource permet une journalisation complète de votre AWS IoT Events infrastructure.

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

****  

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

------