AWS Systems Manager Incident Manager steht neuen Kunden nicht mehr offen. Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter [Änderung der AWS Systems Manager Incident Manager Verfügbarkeit](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-availability-change.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 Vermeidung verwirrter stellvertretender Mitarbeiter in Incident Manager
<a name="cross-service-confused-deputy-prevention"></a>

Das Problem des verwirrten Stellvertreters ist ein Problem der Informationssicherheit, das auftritt, wenn eine Entität, die nicht berechtigt ist, eine Aktion auszuführen, eine Entität mit mehr Rechten zur Ausführung der Aktion aufruft. Auf diese Weise können böswillige Akteure Befehle ausführen oder Ressourcen ändern, zu deren Ausführung oder Zugriff sie sonst nicht berechtigt wären.

In AWS kann ein dienstübergreifendes Identitätswechsels zu einem verwirrten Szenario für Stellvertreter führen. *Ein dienstübergreifender Identitätswechsel liegt vor, wenn ein Dienst (der *anrufende Dienst) einen anderen Dienst (den angerufenen Dienst*) anruft.* Ein böswilliger Akteur kann den anrufenden Dienst verwenden, um Ressourcen in einem anderen Dienst mithilfe von Berechtigungen zu ändern, über die er normalerweise nicht verfügen würde.

AWS bietet Dienstprinzipalen verwalteten Zugriff auf Ressourcen in Ihrem Konto, um Sie beim Schutz Ihrer Ressourcen zu unterstützen. 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 Ihren Ressourcenrichtlinien zu verwenden. Diese Schlüssel schränken die Berechtigungen ein, AWS Systems Manager Incident Manager die dieser Ressource einen anderen Dienst gewähren. Wenn Sie beide Kontextschlüssel für globale Bedingungen verwenden, müssen der `aws:SourceAccount` Wert und das Konto, auf das im `aws:SourceArn` Wert verwiesen wird, dieselbe Konto-ID verwenden, wenn sie in derselben Richtlinienanweisung verwendet werden.

Der Wert von `aws:SourceArn` muss der ARN des betroffenen Incident-Datensatzes sein. Wenn Sie den vollständigen ARN der Ressource nicht kennen oder wenn Sie mehrere Ressourcen angeben, verwenden Sie den `aws:SourceArn` globalen Kontextbedingungsschlüssel mit dem `*` Platzhalter für die unbekannten Teile des ARN. Sie können beispielsweise festlegen `aws:SourceArn` auf`arn:aws:ssm-incidents::111122223333:*`. 

Im folgenden Beispiel für eine Vertrauensrichtlinie verwenden wir den `aws:SourceArn` Bedingungsschlüssel, um den Zugriff auf die Servicerolle auf der Grundlage des ARN des Incident-Datensatzes einzuschränken. Nur Incident-Datensätze, die anhand des Reaktionsplans `myresponseplan` erstellt wurden, können diese Rolle verwenden.

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

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": { "Service": "ssm-incidents.amazonaws.com" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "ArnLike": {
        "aws:SourceArn": "arn:aws:ssm-incidents:*:111122223333:incident-record/myresponseplan/*"
      }
    }
  }
}
```

------