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 Vermeidung verwirrter Stellvertreter in OpsWorks Stacks
**Wichtig**
Der AWS OpsWorks Stacks Dienst hat am 26. Mai 2024 das Ende seiner Nutzungsdauer erreicht und wurde sowohl für neue als auch für bestehende Kunden deaktiviert. Wir empfehlen Kunden dringend, ihre Workloads so bald wie möglich auf andere Lösungen zu migrieren. Wenn Sie Fragen zur Migration haben, wenden Sie sich an das AWS Support Team auf [AWS re:POST](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
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 kann ein dienstübergreifendes Identitätswechsels 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 aufrufende Service kann manipuliert werden, um seine Berechtigungen zu verwenden, um Aktionen auf die Ressourcen eines anderen Kunden auszuführen, für die er sonst keine Zugriffsberechtigung haben sollte. Um dies zu verhindern, bietet AWS Tools, mit denen Sie Ihre Daten für alle Services mit Serviceprinzipalen schützen können, die Zugriff auf Ressourcen in Ihrem Konto erhalten haben.
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 den Richtlinien für den Zugriff auf Stacks zu verwenden, um die Berechtigungen zu beschränken, die Stacks einem anderen Dienst für AWS OpsWorks Stacks erteilt. 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` diese Option, wenn dem dienstübergreifenden Zugriff nur ein Stack zugeordnet werden soll. Verwenden Sie diese Option, `aws:SourceAccount` wenn Sie zulassen möchten, dass jeder Stapel in diesem Konto mit der dienstübergreifenden Nutzung verknüpft wird.
Der Wert von `aws:SourceArn` muss der ARN eines OpsWorks Stacks sein.
Der effektivste Weg, sich vor dem Problem des verwirrten Stellvertreters zu schützen, besteht darin, den Kontextschlüssel für `aws:SourceArn` globale Bedingungen mit dem vollständigen ARN des OpsWorks Stacks-Stacks zu verwenden. Wenn Sie den vollständigen ARN nicht kennen oder mehrere Stacks angeben ARNs, verwenden Sie den `aws:SourceArn` globalen Kontextbedingungsschlüssel mit Platzhaltern (`*`) für die unbekannten Teile des ARN. Beispiel, `arn:aws:servicename:*:123456789012:*`.
Der folgende Abschnitt zeigt, wie Sie die Kontextschlüssel `aws:SourceArn` und die `aws:SourceAccount` globalen Bedingungsschlüssel in OpsWorks Stacks verwenden können, um das Problem des verwirrten Stellvertreters zu vermeiden.
## Beugen Sie Exploits mit verwirrten Stellvertretern in Stacks vor OpsWorks
In diesem Abschnitt wird beschrieben, wie Sie dazu beitragen können, Exploits mit verwirrten Stellvertretern in OpsWorks Stacks zu verhindern. Außerdem finden Sie Beispiele für Berechtigungsrichtlinien, die Sie an die IAM-Rolle anhängen können, die Sie für den Zugriff auf Stacks verwenden. OpsWorks Aus Sicherheitsgründen empfehlen wir, die Schlüssel `aws:SourceArn` und die `aws:SourceAccount` Bedingungsschlüssel zu den Vertrauensbeziehungen hinzuzufügen, die Ihre IAM-Rolle mit anderen Diensten unterhält. Die Vertrauensbeziehungen ermöglichen es OpsWorks Stacks, eine Rolle bei der Ausführung von Aktionen in anderen Diensten zu übernehmen, die für die Erstellung oder Verwaltung Ihrer OpsWorks Stacks-Stacks erforderlich sind.
**Um Vertrauensstellungen zu bearbeiten, Schlüssel hinzuzufügen und zu konditionieren `aws:SourceArn` `aws:SourceAccount`**
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Suchen Sie im **Suchfeld** nach der Rolle, die Sie für den Zugriff auf OpsWorks Stacks verwenden. Die AWS verwaltete Rolle ist`aws-opsworks-service-role`.
1. Wählen Sie auf der **Übersichtsseite** für die Rolle die Registerkarte **Vertrauensbeziehungen** aus.
1. Wählen Sie auf der Registerkarte **Vertrauensbeziehungen** die Option **Vertrauensrichtlinie bearbeiten** aus.
1. Fügen Sie auf der Seite **Vertrauensrichtlinie bearbeiten** der Richtlinie mindestens einen der `aws:SourceAccount` Bedingungsschlüssel `aws:SourceArn` oder einen der Bedingungsschlüssel hinzu. Wird verwendet`aws:SourceArn`, um die Vertrauensbeziehung zwischen Cross-Services (wie Amazon EC2) und OpsWorks Stacks auf bestimmte OpsWorks Stacks-Stacks zu beschränken, was restriktiver ist. Fügen Sie hinzu`aws:SourceAccount`, um die Vertrauensbeziehung zwischen Cross-Services und OpsWorks Stacks auf Stacks in einem bestimmten Konto zu beschränken, was weniger restriktiv ist. Im Folgenden wird ein -Beispiel gezeigt. Beachten Sie, dass das Konto identisch sein IDs muss, wenn Sie beide Bedingungsschlüssel verwenden.
1. Wenn Sie mit dem Hinzufügen von Bedingungsschlüsseln fertig sind, wählen Sie **Richtlinie aktualisieren**.
Im Folgenden finden Sie weitere Beispiele für Rollen, die den Zugriff auf Stacks mithilfe von `aws:SourceArn` und `aws:SourceAccount` einschränken.
**Topics**
+ [Beispiel: Zugriff auf Stacks in einer bestimmten Region](#confused-deputy-opsworks-stacks-example1)
+ [Beispiel: Hinzufügen von mehr als einem Stack-ARN zu `aws:SourceArn`](#confused-deputy-opsworks-stacks-example2)
### Beispiel: Zugriff auf Stacks in einer bestimmten Region
Die folgende Erklärung zur Rollenvertrauensstellung greift auf alle OpsWorks Stacks-Stacks in der Region USA Ost (Ohio) zu (). `us-east-2` Beachten Sie, dass die Region im ARN-Wert von angegeben ist`aws:SourceArn`, der Stack-ID-Wert jedoch ein Platzhalter (\$1) ist.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "opsworks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:opsworks:us-east-2:123456789012:stack/*"
}
}
}
]
}
```
------
### Beispiel: Hinzufügen von mehr als einem Stack-ARN zu `aws:SourceArn`
Das folgende Beispiel beschränkt den Zugriff auf ein Array von zwei OpsWorks Stacks-Stacks in der Konto-ID 123456789012.