

Hinweis zum Ende des Supports: Am 20. Mai 2026 AWS endet der Support für AWS IoT Events. Nach dem 20. Mai 2026 können Sie nicht mehr auf die AWS IoT Events Konsole oder AWS IoT Events die Ressourcen zugreifen. Weitere Informationen finden Sie unter [AWS IoT Events Ende des Supports](https://docs.aws.amazon.com/iotevents/latest/developerguide/iotevents-end-of-support.html).

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Dienstübergreifende verwirrte Stellvertreterprävention für AWS IoT Events
<a name="cross-service-confused-deputy-prevention"></a>

**Anmerkung**  
Mit dem AWS IoT Events Dienst können Sie Rollen nur verwenden, um Aktionen in demselben Konto zu starten, in dem eine Ressource erstellt wurde. Dies hilft, einen verwirrten stellvertretenden Angriff in zu verhindern AWS IoT Events.
Diese Seite dient als Referenz, um zu erfahren, wie das Problem mit dem verwirrten Stellvertreter funktioniert und verhindert werden kann, falls kontoübergreifende Ressourcen für den AWS IoT Events Dienst zugelassen wurden.

Das Problem des verwirrten Stellvertreters ist ein Sicherheitsproblem, bei dem eine Entität, die keine Berechtigung zur Durchführung einer Aktion hat, eine privilegiertere Entität zur Durchführung der Aktion zwingen kann. In: AWS Dienststellenübergreifender Identitätswechsel kann zu einem Problem mit dem verwirrten Stellvertreter führen.

Ein dienstübergreifender Identitätswechsel kann auftreten, wenn ein Dienst (der *Anruf-Dienst*) einen anderen Dienst anruft (den *aufgerufenen Dienst*). Der Anruf-Dienst kann so manipuliert werden, dass er seine Berechtigungen verwendet, um auf die Ressourcen eines anderen Kunden zu reagieren, auf die er sonst nicht zugreifen dürfte. Um dies zu verhindern, AWS bietet Tools, mit denen Sie Ihre Daten für alle Dienste mit Dienstprinzipalen schützen können, denen Zugriff auf Ressourcen in Ihrem Konto gewährt wurde. 

Wir empfehlen, die Kontextschlüssel [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)und die [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)globalen Bedingungsschlüssel in Ressourcenrichtlinien zu verwenden, um die Berechtigungen einzuschränken, AWS IoT Events die der Ressource einen anderen Dienst gewähren. Wenn der `aws:SourceArn`-Wert die Konto-ID nicht enthält, z. B. einen Amazon-S3-Bucket-ARN, müssen Sie beide globale Bedingungskontextschlüssel verwenden, um Berechtigungen einzuschränken. Wenn Sie beide globale Bedingungskontextschlüssel verwenden und der `aws:SourceArn`-Wert die Konto-ID enthält, müssen der `aws:SourceAccount`-Wert und das Konto im `aws:SourceArn`-Wert dieselbe Konto-ID verwenden, wenn sie in der gleichen Richtlinienanweisung verwendet wird. 

 Verwenden Sie `aws:SourceArn`, wenn Sie nur eine Ressource mit dem betriebsübergreifenden Zugriff verknüpfen möchten. Verwenden Sie `aws:SourceAccount`, wenn Sie zulassen möchten, dass Ressourcen in diesem Konto mit der betriebsübergreifenden Verwendung verknüpft werden. Der Wert von `aws:SourceArn` muss dem Detektor- oder Alarmmodell entsprechen, das der `sts:AssumeRole` Anfrage zugeordnet ist.

Der effektivste Weg, um sich vor dem Confused-Deputy-Problem zu schützen, ist die Verwendung des globalen Bedingungskontext-Schlüssels `aws:SourceArn` mit dem vollständigen ARN der Ressource. Wenn Sie den vollständigen ARN der Ressource nicht kennen oder wenn Sie mehrere Ressourcen angeben, verwenden Sie den globalen Bedingungskontext-Schlüssel `aws:SourceArn` mit Platzhaltern (`*`) für die unbekannten Teile des ARN. Beispiel, `arn:aws:iotevents:*:123456789012:*`. 

Die folgenden Beispiele zeigen, wie Sie die Kontextschlüssel `aws:SourceArn` und die `aws:SourceAccount` globale Bedingung verwenden können, AWS IoT Events um das Problem des verwirrten Stellvertreters zu vermeiden.

**Topics**
+ [Beispiel: Sicherer Zugriff auf ein AWS IoT Events Detektormodell](accessing-a-detector-model.md)
+ [Beispiel: Sicherer Zugriff auf ein AWS IoT Events Alarmmodell](accessing-an-alarm-model.md)
+ [Beispiel: Greifen Sie auf eine AWS IoT Events Ressource in einer bestimmten Region zu](accessing-resource-in-specified-region.md)
+ [Beispiel: Konfigurieren Sie die Protokollierungsoptionen für AWS IoT Events](logging-options.md)

# Beispiel: Sicherer Zugriff auf ein AWS IoT Events Detektormodell
<a name="accessing-a-detector-model"></a>

Dieses Beispiel zeigt, wie Sie eine IAM-Richtlinie erstellen, die den Zugriff auf ein bestimmtes Detektormodell in sicher gewährt. AWS IoT Events Die Richtlinie verwendet Bedingungen, um sicherzustellen, dass nur das angegebene AWS Konto und der angegebene AWS IoT Events Dienst die Rolle übernehmen können, wodurch eine zusätzliche Sicherheitsebene hinzugefügt wird. In diesem Beispiel kann die Rolle nur auf das angegebene Detektormodell zugreifen*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"
                }
            }
        }
    ]
}
```

------

# Beispiel: Sicherer Zugriff auf ein AWS IoT Events Alarmmodell
<a name="accessing-an-alarm-model"></a>

Dieses Beispiel zeigt, wie eine IAM-Richtlinie erstellt wird, die den sicheren AWS IoT Events Zugriff auf Alarmmodelle ermöglicht. Die Richtlinie verwendet Bedingungen, um sicherzustellen, dass nur das angegebene AWS Konto und der angegebene AWS IoT Events Dienst die Rolle übernehmen können.

In diesem Beispiel kann die Rolle auf jedes Alarmmodell innerhalb des angegebenen AWS Kontos zugreifen, wie durch den `*` Platzhalter im Alarmmodell-ARN angegeben. Die `aws:SourceArn` Bedingungen `aws:SourceAccount` und die Bedingungen wirken zusammen, um das Problem des verwirrten Stellvertreters zu verhindern.

------
#### [ 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/*"
                }
            }
        }
    ]
}
```

------

# Beispiel: Greifen Sie auf eine AWS IoT Events Ressource in einer bestimmten Region zu
<a name="accessing-resource-in-specified-region"></a>

Dieses Beispiel zeigt, wie eine IAM-Rolle für den Zugriff auf AWS IoT Events Ressourcen in einer bestimmten AWS Region konfiguriert wird. Indem Sie ARNs in Ihren IAM-Richtlinien regionsspezifische Angaben verwenden, können Sie den Zugriff auf AWS IoT Events Ressourcen in verschiedenen geografischen Gebieten einschränken. Dieser Ansatz kann dazu beitragen, Sicherheit und Compliance in Bereitstellungen in mehreren Regionen aufrechtzuerhalten. Die Region in diesem Beispiel ist. *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:*"
                }
            }
        }
    ]
}
```

------

# Beispiel: Konfigurieren Sie die Protokollierungsoptionen für AWS IoT Events
<a name="logging-options"></a>

Die korrekte Protokollierung ist wichtig für die Überwachung, das Debuggen und die Prüfung Ihrer AWS IoT Events Anwendungen. Dieser Abschnitt bietet einen Überblick über die Protokollierungsoptionen, die in AWS IoT Events verfügbar sind.

Dieses Beispiel zeigt, wie eine IAM-Rolle konfiguriert wird, die es ermöglicht, Daten AWS IoT Events in CloudWatch Logs zu protokollieren. Die Verwendung von Platzhaltern (`*`) im Ressourcen-ARN ermöglicht eine umfassende Protokollierung in Ihrer gesamten AWS IoT Events Infrastruktur.

------
#### [ 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:*"
                }
            }
        }
    ]
}
```

------