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.

Das Confused-Deputy-Problem

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. Um dies zu verhindern, AWS stellt Tools bereit, die Ihnen helfen, Ihr Konto zu schützen, wenn Sie Dritten (bekannt als kontoübergreifender Zugriff) oder anderen AWS Diensten (bekannt als dienstübergreifender Zugriff) Zugriff auf Ressourcen in Ihrem Konto gewähren.

Manchmal müssen Sie möglicherweise einer dritten Partei Zugriff auf Ihre AWS Ressourcen gewähren (Delegiertenzugriff). Nehmen wir zum Beispiel an, Sie beschließen, ein Drittanbieter namens Example Corp mit der Überwachung Ihrer Kosten AWS-Konto und der Kostenoptimierung zu beauftragen. Um Ihre täglichen Ausgaben verfolgen zu können, muss Example Corp auf Ihre AWS Ressourcen zugreifen. Example Corp überwacht auch viele andere AWS-Konten Kunden. Sie können eine IAM Rolle verwenden, um eine vertrauenswürdige Beziehung zwischen Ihrem Konto AWS-Konto und dem Example Corp-Konto aufzubauen. Ein wichtiger Aspekt dieses Szenarios ist die externe ID. Dabei handelt es sich um optionale Informationen, die Sie in einer IAM Rollenvertrauensrichtlinie verwenden können, um festzulegen, wer die Rolle übernehmen kann. Die Hauptfunktion des externen Ausweises besteht darin, das Problem des verwirrten Stellvertreters zu lösen und zu verhindern.

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 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.

Vermeidung des Problems des verwirrten Stellvertreters (kontoübergreifend)

In der nachfolgenden Abbildung wird das verwirrte Stellvertreter-Problem dargestellt.

In diesem Szenario wird von Folgendem ausgegangen:

Es passiert Folgendes:

So kann der andere Kunde unautorisiert Zugriff auf Ihre Ressourcen erlangen. Da der Kunde Example Corp dahingehend manipuliert hat, unwissentlich auf Ihre Ressourcen zuzugreifen, ist Beispielunternehmen nun ein "verwirrter Stellvertreter".

Example Corp vermeidet dieses Problem zum Beispiel, indem sie verlangt, in der Vertrauensrichtlinie der Rolle eine ExternalId-Bedingungsprüfung aufzunehmen. Example Corp generiert zum Beispiel einen einzigartigenExternalId-Wert für jeden Kunden und verwendet diesen Wert in seiner Anforderung, um die Rolle zu übernehmen. Der ExternalId-Wert muss unter den Kunden von Example Corp eindeutig sein und von Example Corp kontrolliert werden, nicht von seinen Kunden. Deshalb erhalten Sie diese ID auch von Example Corp und können sie nicht selbst erstellen. Dadurch wird verhindert, dass Example Corp ein verwirrter Stellvertreter ist und Zugriff auf die AWS Ressourcen eines anderen Kontos gewährt.

Stellen Sie sich in unserem Szenario vor, dass Ihre eindeutige ID beim Example Corp 12345 lautet und die ID des anderen Kunden 67890. Die IDs sind für dieses Szenario vereinfacht. Im Allgemeinen sind diese Identifikatoren. GUIDs Angenommen, diese IDs sind innerhalb des Kundenstamms von Example Corp eindeutig und es handelt sich um sinnvolle externe ID-Werte.

Example Corp teilt Ihnen den externen ID-Wert 12345 mit. Sie fügen nun ein Condition-Element zur Vertrauensrichtlinie der Rolle hinzu, dessen sts:ExternalId-Wert 12345 lauten muss. Beispiel:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "Example Corp's AWS Account ID"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "12345"
      }
    }
  }
}

Das Condition-Element in dieser Richtlinie ermöglicht es Example Corp, die Rolle nur zu übernehmen, wenn der AssumeRole API Anruf den externen ID-Wert 12345 enthält. Example Corp stellt sicher, dass jedes Mal, wenn es eine Rolle im Namen eines Kunden übernimmt, immer den externen ID-Wert dieses Kunden in den AssumeRole Anruf mit einbezieht. Selbst wenn ein anderer Kunde Example Corp Ihre zur Verfügung stelltARN, kann er nicht kontrollieren, welche externe ID Example Corp in seiner Anfrage an Example Corp eingibt AWS. So wird verhindert, dass nicht autorisierte Kunden Zugriff auf Ihre Ressourcen erhalten.

Das folgende Diagramm verdeutlicht dieses Konzept.

Die externe ID verhindert, dass andere Kunden Example Corp manipuliert, und unwissentlich Zugriff auf Ihre Ressourcen gewährt.

Vermeidung des Problems des verwirrten Stellvertreters (dienstübergreifend)

Wir empfehlen die Verwendung der globalen Bedingungskontextschlüssel aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, oder aws:SourceOrgPaths in ressourcenbasierten Richtlinien, um die Berechtigungen zu beschränken, die ein Service für eine bestimmte Ressource hat. Wird verwendetaws:SourceArn, um nur eine Ressource mit dienstübergreifendem Zugriff zu verknüpfen. Wird verwendetaws:SourceAccount, damit jede Ressource in diesem Konto der dienstübergreifenden Nutzung zugeordnet werden kann. Wird verwendetaws:SourceOrgID, um zu ermöglichen, dass jede Ressource aus einem beliebigen Konto innerhalb einer Organisation mit der dienstübergreifenden Nutzung verknüpft wird. Wird verwendetaws:SourceOrgPaths, um jede Ressource aus Konten innerhalb eines AWS Organizations Pfads der dienstübergreifenden Nutzung zuzuordnen. Weitere Informationen zu Pfaden und deren Verwendung finden Sie unter Den AWS Organizations -Entitätspfad verstehen.

Die detaillierteste Methode zum Schutz vor dem Problem des verwirrten Stellvertreters besteht darin, den Kontextschlüssel für aws:SourceArn globale Bedingungen mit ARN der gesamten Ressource in Ihren ressourcenbasierten Richtlinien zu verwenden. Wenn Sie die gesamte ARN Ressource nicht kennen oder wenn Sie mehrere Ressourcen angeben, verwenden Sie den aws:SourceArn globalen Bedingungskontextschlüssel mit Platzhaltern (*) für die unbekannten Teile von. ARN Beispiel, arn:aws:servicename:*:123456789012:*.

Wenn der aws:SourceArn Wert die Konto-ID nicht enthält, z. B. ein Amazon S3 S3-BucketARN, müssen Sie beide verwenden aws:SourceAccount und, aws:SourceArn um die Berechtigungen einzuschränken.

Um sich vor dem Confused-Deputy-Problem im großen Maßstab zu schützen, verwenden Sie den globalen Bedingungskontextschlüssel aws:SourceOrgID oder aws:SourceOrgPaths mit der Organisations-ID oder dem Organisationspfad der Ressource in Ihren ressourcenbasierten Richtlinien. Richtlinien, die den Schlüssel aws:SourceOrgID oder aws:SourceOrgPaths enthalten, schließen automatisch die richtigen Konten ein und Sie müssen die Richtlinien nicht manuell aktualisieren, wenn Sie Konten in Ihrer Organisation hinzufügen, entfernen oder verschieben.

Bei non-service-linked Rollenvertrauensrichtlinien hat jeder Dienst in der Vertrauensrichtlinie die iam:PassRole Aktion durchgeführt, um zu überprüfen, ob sich die Rolle in demselben Konto befindet wie der aufrufende Dienst. Daher ist die Verwendung von aws:SourceAccount, aws:SourceOrgID oder aws:SourceOrgPaths mit diesen Vertrauensrichtlinien nicht erforderlich. Mithilfe aws:SourceArn einer Vertrauensrichtlinie können Sie Ressourcen angeben, für die eine Rolle übernommen werden kann, z. B. eine Lambda-FunktionARN. Einige AWS-Services verwenden aws:SourceAccount Vertrauensrichtlinien für neu erstellte Rollen, aber die Verwendung der Schlüssel ist für bestehende Rollen in Ihrem Konto nicht erforderlich. aws:SourceArn

Dienststellenübergreifende Vermeidung verwirrter Stellvertreter für AWS Security Token Service

Bei vielen AWS Diensten müssen Sie Rollen verwenden, damit der Dienst in Ihrem Namen auf die Ressourcen eines anderen Dienstes zugreifen kann. Eine Rolle, die ein Service übernimmt, um Aktionen in Ihrem Namen durchzuführen, wird als Servicerolle bezeichnet. Eine Rolle erfordert zwei Richtlinien: eine Rollenvertrauensrichtlinie, die den Prinzipal angibt, der die Rolle übernehmen darf, und eine Berechtigungsrichtlinie, die angibt, was mit der Rolle gemacht werden kann. Eine Rollenvertrauensrichtlinie ist die einzige Art von ressourcenbasierter Richtlinie in. IAM Andere AWS-Services haben ressourcenbasierte Richtlinien, z. B. eine Amazon S3 S3-Bucket-Richtlinie.

Wenn ein Dienst eine Rolle in Ihrem Namen übernimmt, muss der Service-Prinzipal diests:AssumeRole-Aktion in der Rollenvertrauensrichtlinie ausführen dürfen. Wenn ein Service aufruftsts:AssumeRole, wird ein Satz temporärer Sicherheitsanmeldedaten AWS STS zurückgegeben, die der Service Principal verwendet, um auf die Ressourcen zuzugreifen, die gemäß der Berechtigungsrichtlinie der Rolle zulässig sind. Wenn ein Service eine Rolle in Ihrem Konto übernimmt, können Sie die globalen Bedingungskontextschlüssel aws:SourceArn aws:SourceAccount, aws:SourceOrgID, oder aws:SourceOrgPaths in Ihrer Rollenvertrauensrichtlinie übernehmen, um den Zugriff auf die Rolle nur auf Anffragen zu beschränken, die von erwarteten Ressourcen generiert werden.

In müssen Sie beispielsweise eine Rolle auswählen AWS Systems Manager Incident Manager, damit Incident Manager in Ihrem Namen ein Systems Manager Manager-Automatisierungsdokument ausführen kann. Das Automatisierungsdokument kann automatisierte Reaktionspläne für Vorfälle enthalten, die durch CloudWatch Alarme oder EventBridge Ereignisse ausgelöst werden. Im folgenden Beispiel für eine Rollenvertrauensrichtlinie können Sie den aws:SourceArn Bedingungsschlüssel verwenden, um den Zugriff auf die Servicerolle auf der Grundlage der Incident-Datensätze einzuschränkenARN. Nur Vorfallsdatensätze, die aus der Reaktionsplan-Ressource myresponseplan erstellt werden, können diese Rolle verwenden.

{
  "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/*"
      }
    }
  }
}