Dienstübergreifende verwirrte Stellvertreterprävention für AWS IoT Events - AWS IoT Events

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 verwirrte Stellvertreterprävention für AWS IoT Events

Anmerkung

  • Mit dem AWS IoT Events Dienst können Sie Rollen nur verwenden, um Aktionen in demselben Konto zu starten, in dem eine Ressource erstellt wurde. Dies hilft, einen verwirrten stellvertretenden Angriff in zu verhindern AWS IoT Events.

  • Diese Seite dient als Referenz, um zu erfahren, wie das Problem mit dem verwirrten Stellvertreter funktioniert und verhindert werden kann, falls kontoübergreifende Ressourcen für den AWS IoT Events Dienst zugelassen wurden.

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 Dienststellenübergreifender Identitätswechsel kann 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. 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:SourceArnund die aws:SourceAccountglobalen Bedingungsschlüssel in Ressourcenrichtlinien zu verwenden, um die Berechtigungen einzuschränken, AWS IoT Events die der Ressource einen anderen Dienst gewähren. Wenn der aws:SourceArn Wert die Konto-ID nicht enthält, z. B. ein Amazon S3 S3-BucketARN, müssen Sie beide globalen Bedingungskontextschlüssel verwenden, um die 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. Der Wert von aws:SourceArn muss dem Detektor- oder Alarmmodell entsprechen, das der sts:AssumeRole Anfrage zugeordnet ist.

Der wirksamste Schutz vor dem Problem mit dem verwirrten Deputy ist die Verwendung des aws:SourceArn globalen Condition-Kontextschlüssels mit ARN der gesamten Ressource. Wenn Sie die gesamte ARN Ressource nicht kennen oder wenn Sie mehrere Ressourcen angeben, verwenden Sie den aws:SourceArn globalen Kontextbedingungsschlüssel mit Platzhaltern (*) für die unbekannten Teile von. ARN Beispiel, arn:aws:iotevents:*:123456789012:*.

Die folgenden Beispiele zeigen, wie Sie die Kontextschlüssel aws:SourceArn und die aws:SourceAccount globale Bedingung verwenden können, AWS IoT Events um das Problem des verwirrten Stellvertreters zu vermeiden.

Themen