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.
Serviceübergreifende Confused-Deputy-Prävention
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, dienstübergreifender Identitätswechsel kann zum Problem des verwirrten Stellvertreters 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 aws:SourceArn
und die aws:SourceAccount
globalen Bedingungsschlüssel in Ressourcenrichtlinien zu verwenden, um die folgenden Berechtigungen einzuschränken AWS Systems Manager stellt der Ressource einen weiteren Dienst zur Verfügung. Wenn der aws:SourceArn
-Wert nicht die Konto-ID enthält, z. B. den Amazon-Ressourcenname (ARN) eines S3-Buckets, müssen Sie beide globale Bedingungskontext-Schlü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.
Die folgenden Abschnitte enthalten Beispielrichtlinien für AWS Systems Manager Werkzeuge.
Beispiel für hybride Aktivierungsrichtlinien
Bei Servicerollen, die bei einer Hybrid-Aktivierung verwendet werden, muss der Wert von aws:SourceArn
der ARN des AWS-Konto sein. Stellen Sie sicher, dass Sie AWS-Region im ARN angeben, in dem Sie Ihre Hybrid-Aktivierung erstellt haben. 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:ssm:*:
.region
:123456789012
:*
Das folgende Beispiel veranschaulicht die Verwendung der globalen Bedingungskontext-Schlüssel aws:SourceArn
und aws:SourceAccount
für Automatisierung, um das Confused-Deputy-Problem in der Region USA Ost (Ohio) (us-east-2) zu verhindern.
{ "Version":"2012-10-17", "Statement":[ { "Sid":"", "Effect":"Allow", "Principal":{ "Service":"ssm.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"
123456789012
" }, "ArnEquals":{ "aws:SourceArn":"arn:aws:ssm:us-east-2:123456789012
:*" } } } ] }
Beispiel-Richtlinie für Ressourcen-Datensynchronisierung
Systemmanager-Inventar, Explorer, und Compliance ermöglichen es Ihnen, eine Ressourcendatensynchronisierung zu erstellen, um die Speicherung Ihrer Betriebsdaten (OpsData) in einem zentralen Amazon Simple Storage Service-Bucket zu zentralisieren. Wenn Sie eine Ressourcendatensynchronisierung mithilfe von AWS Key Management Service (AWS KMS) verschlüsseln möchten, müssen Sie entweder einen neuen Schlüssel erstellen, der die folgende Richtlinie enthält, oder Sie müssen einen vorhandenen Schlüssel aktualisieren und diese Richtlinie hinzufügen. Die aws:SourceArn
und aws:SourceAccount
-Bedingungsschlüssel in dieser Richtlinie verhindern das Confused-Deputy-Problem. Hier ist eine Beispielrichtlinie.
{ "Version": "2012-10-17", "Id": "ssm-access-policy", "Statement": [ { "Sid": "ssm-access-policy-statement", "Action": [ "kms:GenerateDataKey" ], "Effect": "Allow", "Principal": { "Service": "ssm.amazonaws.com" }, "Resource": "arn:aws:kms:us-east-2:123456789012:key/
KMS_key_id
", "Condition": { "StringLike": { "aws:SourceAccount": "123456789012" }, "ArnLike": { "aws:SourceArn": "arn:aws:ssm:*:123456789012:role/aws-service-role/ssm.amazonaws.com/AWSServiceRoleForAmazonSSM" } } } ] }
Anmerkung
Der ARN im Richtlinienbeispiel ermöglicht es dem System, OpsData aus allen Quellen außer AWS Security Hub zu verschlüsseln. Wenn Sie Security Hub Hub-Daten verschlüsseln müssen, z. B. wenn Sie Explorer Um Security Hub Hub-Daten zu sammeln, müssen Sie eine zusätzliche Richtlinie anhängen, die den folgenden ARN spezifiziert:
"aws:SourceArn":
"arn:aws:ssm:*:
account-id
:role/aws-service-role/opsdatasync.ssm.amazonaws.com/AWSServiceRoleForSystemsManagerOpsDataSync"