Das Confused-Deputy-Problem

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.

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 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). Sie entscheiden sich beispielsweise dafür, 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 zudem viele weitere AWS-Konten anderer 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, eine optionale Kennung, die Sie in einer Vertrauensrichtlinie für IAM-Rollen 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.

Einige AWS Dienste (Aufrufdienste) verwenden ihren AWS Dienstprinzipal, um auf AWS Ressourcen von anderen AWS Diensten (sogenannten Diensten) zuzugreifen. Bei einigen dieser Dienstinteraktionen können Sie Anrufdienste so konfigurieren, dass sie mit den Ressourcen eines aufgerufenen Dienstes in einem anderen Dienst kommunizieren AWS-Konto. Ein Beispiel hierfür ist die Konfiguration AWS CloudTrail , um in einen zentralen Amazon S3 S3-Bucket zu schreiben, der sich in einem anderen befindet AWS-Konto. Dem aufrufenden Dienst CloudTrail wird mithilfe der Richtlinie des S3-Buckets Zugriff auf Ihren S3-Bucket gewährt, indem eine Allow-Anweisung für hinzugefügt wirdcloudtrail.amazonaws.com.

Wenn ein AWS Dienstprinzipal von einem aufrufenden Dienst auf eine Ressource von einem aufgerufenen Dienst zugreift, autorisiert die Ressourcenrichtlinie des aufgerufenen Dienstes nur den AWS Dienstprinzipal und nicht den Akteur, der den aufrufenden Dienst konfiguriert hat. Beispielsweise könnte ein S3-Bucket, der dem CloudTrail Service Principal ohne Bedingungen vertraut, CloudTrail Logs von dem empfangen AWS-Konten , den ein vertrauenswürdiger Administrator konfiguriert hat, aber auch CloudTrail Logs von einem nicht autorisierten Akteur in seinem Bucket AWS-Konto, sofern dieser den Namen des S3-Buckets kennt.

Das Problem des verwirrten Stellvertreters entsteht, wenn ein Akteur das Vertrauen des Dienstprinzipals eines AWS Dienstes nutzt, um sich Zugriff auf Ressourcen zu verschaffen, auf die er eigentlich keinen Zugriff haben sollte.

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-Aufruf 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 Ihren ARN zur Verfügung stellt, kann er nicht kontrollieren, welche externe ID Example Corp in seiner Anfrage an Example Corp angibt 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)

Das folgende Diagramm veranschaulicht das dienstübergreifende Confused Deputy Problem anhand des Interaktionsbeispiels CloudTrail und Amazon S3, bei dem ein nicht autorisierter Akteur CloudTrail Protokolle in einen Amazon S3 S3-Bucket schreibt, auf den er nicht zugreifen darf.

Um zu verhindern, dass ein unberechtigter Akteur das Vertrauen eines AWS Auftraggebers ausnutzt, um sich Zugriff auf Ihre Ressourcen zu verschaffen, geben AWS Service Principals Informationen über die AWS Ressource und die AWS Organisation an AWS-Konto, für die sie handeln.

Diese Informationen sind in globalen Zustandsschlüsselwerten verfügbar, die in einer Ressourcenrichtlinie oder einer Ressourcenkontrollrichtlinie für Anfragen von AWS Service Principals verwendet werden können. Wir empfehlenaws: SourceArn,, war: SourceAccountaws: ID SourceOrg, oder aws: SourceOrgPaths in Ihren Ressourcenrichtlinien zu verwenden, wenn einem AWS Service Principal die Erlaubnis erteilt wurde, auf eine Ihrer Ressourcen zuzugreifen. Mit diesen Bedingungsschlüsseln können Sie in Ihren Ressourcen- oder Ressourcensteuerungsrichtlinien testen, ob AWS Service Principals, die auf Ihre Ressourcen zugreifen, dies im Namen von AWS Ressourcen tun AWS-Konten, oder ob AWS Organizations Sie es erwarten.

Das folgende Diagramm zeigt das dienstübergreifende Szenario „Confused Deputy“, wenn eine Ressource mit dem aws:SourceAccount globalen Bedingungskontextschlüssel konfiguriert ist und ein nicht autorisierter Akteur aus einem anderen Konto versucht, auf AWS Ressourcen zuzugreifen, auf die er keinen Zugriff haben soll.

Mithilfe vonaws:SourceArn, aws:SourceAccountaws:SourceOrgID, und aws:SourceOrgPaths globalen Bedingungsschlüsseln in einer Richtlinie können Sie sicherstellen, dass Service Principals in Ihrem Namen auf Ihre Ressourcen zugreifen. Wir empfehlen, diese Bedingungsschlüssel immer dann zu verwenden, wenn einem AWS Service Principal Zugriff auf eine Ihrer Ressourcen gewährt wird.

Dienstübergreifendes Schutzes verwirrter stellvertretender Mitarbeiter mit ressourcenbasierten Richtlinien

Die folgende Beispielrichtlinie gewährt dem Service Principal cloudtrail.amazonaws.com Zugriff auf den Amazon S3 S3-Bucket arn:aws:s3: ::amzn-s3-demo-bucket1, nur wenn der Service Principal im Namen von 111122223333 handelt. AWS-Konto

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CloudTrailAclCheck",
            "Effect": "Allow",
            "Principal": {"Service": "cloudtrail.amazonaws.com"},
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                }
            }
        },
        {
            "Sid": "AWSCloudTrailWrite",
            "Effect": "Allow",
            "Principal": {"Service": "cloudtrail.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/[optionalPrefix]/Logs/myAccountID/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                }
            }
        }
    ]
}

Diese Beispiel-Bucket-Richtlinie gewährt dem Service Principal nur dann appstream.amazonaws.com Zugriff auf das Powershell-Skript examplefile.psh in s3://amzn-s3-demo-bucket2, wenn er im Namen der angegebenen AppStream Amazon-Flotte handelt, indem er den Flottenarn mit angibt. aws:SourceArn

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "appstream.amazonaws.com"
                ]
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket2/examplefile.psh",
            "Condition": {
                "ArnEquals": {
                    "aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333:fleet/ExampleFleetName"
                } 
            }
        }
    ]
}

Serviceübergreifend verwechselt Deputy Protection mit Resource Control-Richtlinien

Mithilfe von Richtlinien zur Ressourcensteuerung (Resource Control Policies, RCP) können Sie dienstübergreifende Kontrollen für verwirrte Stellvertreter auf unterstützte Ressourcen anwenden. AWS-Services RCPs ermöglichen es Ihnen, dienststellenübergreifende Kontrollen für verwirrte Stellvertreter zentral auf Ihre Ressourcen anzuwenden. Sie können Bedingungsschlüssel verwenden AWS Organizations, die aws:SourceOrgId an Ihre Organisationseinheiten (OU) oder AWS-Konten an Ihre Organisation RCPs angehängt sind, ohne bestimmte ressourcenbasierte Richtlinien aws:SourceOrgPaths mit Anweisungen versehen zu müssen. Weitere Informationen zu RCPs und unterstützten Diensten finden Sie unter Richtlinien zur Ressourcenkontrolle (RCPs) im AWS Organizations Benutzerhandbuch.

Im folgenden Beispiel verweigert RCP AWS Service Principals den Zugriff auf Amazon S3 S3-Buckets in Ihren Mitgliedskonten, wenn der Wert ungleich o- aws:SourceOrgID ist. ExampleOrg In der ressourcenbasierten Richtlinie des S3-Buckets muss eine entsprechende Zulassung vorhanden sein, damit AWS Service Principals mit einer ID gleich o- S zugelassen werden kann. SourceOrg ExampleOrg

Diese Richtlinie wendet die Kontrolle nur auf Anfragen von Service Principals ("Bool": {"aws:PrincipalIsAWSService": "true"}) an, bei denen der aws:SourceAccount Schlüssel vorhanden ist ("Null": {"aws:SourceAccount": "false"}), sodass Service-Integrationen, die nicht die Verwendung des Bedingungsschlüssels erfordern, und Aufrufe durch Ihre Principals nicht beeinträchtigt werden. Wenn der aws:SourceAccount Bedingungsschlüssel im Anforderungskontext vorhanden ist, wird die Null-Bedingung als wahr ausgewertet, sodass aws:SourceOrgID sie erzwungen wird. Sie können den Operator für die Nullbedingung aws:SourceAccount anstelle von aws:SourceOrgID verwenden, sodass die Kontrolle auch dann gilt, wenn die Anforderung von einem Konto stammt, das keiner Organisation angehört.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RCPEnforceConfusedDeputyProtectionForS3",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:SourceOrgID": "o-ExampleOrg"
        },
        "Null": {
          "aws:SourceAccount": "false"
        },
        "Bool": {
          "aws:PrincipalIsAWSService": "true"
        }
      }
    }
  ]
}