AWS Signature Version 4 für API-Anfragen - AWS Identity and Access Management
Funktionsweise von AWS SigV4Funktionsweise von AWS SigV4aWann müssen Anforderungen signiert werden?Warum werden Anforderungen signiert?Weitere Ressourcen

AWS Signature Version 4 für API-Anfragen

Wichtig

Wenn Sie ein AWS-SDK (siehe Beispiel-Code und Bibliotheken) oder AWS Command Line Interface (AWS CLI)-Tool verwenden, um API-Anfragen an AWS zu senden, können Sie den Signaturprozess überspringen, da die SDK- und CLI-Clients Ihre Anfragen mithilfe der von Ihnen bereitgestellten Zugriffsschlüssel authentifizieren. Sofern Sie keinen guten Grund dagegen haben, empfiehlt es sich, stets ein SDK oder die CLI zu verwenden.

In Regionen, die mehrere Signaturversionen unterstützen, müssen Sie beim manuellen Signieren von Anfragen angeben, welche Signaturversion verwendet werden soll. Wenn Sie Anfragen an Multi-Region-Zugriffspunkte stellen, wechseln SDKs und die CLI ohne zusätzliche Konfiguration automatisch zur Verwendung der Signaturversion 4A.

Die Authentifizierungsinformationen, die Sie in einer Anfrage senden, müssen eine Signatur enthalten. AWS Signature Version 4 (SigV4) ist das AWS-Signaturprotokoll zum Hinzufügen von Authentifizierungsinformationen zu AWS-API-Anfragen.

Sie verwenden Ihren geheimen Zugriffsschlüssel nicht zum Signieren von API-Anfragen. Stattdessen verwenden Sie den SigV4-Signaturprozess. Signieren von Anfragen beinhaltet:

  1. Erstellen einer kanonischen Anfrage basierend auf den Anfragedetails.

  2. Berechnung einer Signatur anhand Ihrer AWS-Anmeldeinformationen.

  3. Hinzufügen dieser Signatur zur Anfrage als Autorisierungs-Header.

AWS repliziert dann diesen Prozess und überprüft die Signatur, wobei der Zugriff entsprechend gewährt oder verweigert wird.

Symmetric SigV4 erfordert, dass Sie einen Schlüssel ableiten, der auf einen einzelnen AWS-Service in einer einzelnen AWS-Region an einem bestimmten Tag beschränkt ist. Dadurch sind der Schlüssel und die berechnete Signatur für jede Region unterschiedlich. Das bedeutet, dass Sie wissen müssen, für welche Region die Signatur bestimmt ist.

Asymmetric Signature Version 4 (SigV4a) ist eine Erweiterung, die das Signieren mit einem neuen Algorithmus und das Generieren individueller Signaturen unterstützt, die in mehr als einer AWS-Region überprüfbar sind. Mit SigV4a können Sie eine Anfrage für mehrere Regionen signieren, mit nahtlosem Routing und Failover zwischen den Regionen. Wenn Sie das AWS-SDK oder AWS CLI verwenden, um eine Funktion aufzurufen, die eine Multi-Region-Signatur erfordert, wird der Signaturtyp automatisch für die Verwendung von SigV4a geändert. Details hierzu finden Sie unter Funktionsweise von AWS SigV4a.

Funktionsweise von AWS SigV4

Die folgenden Schritte beschreiben den allgemeinen Prozess der Berechnung einer Signatur mit SigV4:

  1. Die zu signierende Zeichenfolge hängt von der Art der Anfrage ab. Wenn Sie beispielsweise den HTTP-Autorisierungs-Header oder die Abfrageparameter zur Authentifizierung verwenden, nutzen Sie eine Kombination aus Anforderungselementen, um die zu signierende Zeichenfolge zu erstellen. Bei einer HTTP-POST-Anfrage ist die POST-Richtlinie in der Anfrage die von Ihnen signierte Zeichenfolge.

  2. Der Signaturschlüssel besteht aus einer Reihe von Berechnungen, wobei das Ergebnis jedes Schritts in den nächsten einfließt. Der letzte Schritt ist der Signaturschlüssel.

  3. Wenn ein AWS-Service eine authentifizierte Anfrage empfängt, erstellt dieser die Signatur mithilfe der in der Anfrage enthaltenen Authentifizierungsinformationen neu. Wenn die Signaturen übereinstimmen, verarbeitet der Service die Anforderung. Andernfalls wird die Anforderung abgelehnt.

Weitere Informationen finden Sie unter Elemente einer AWS-API-Anforderungssignatur.

Funktionsweise von AWS SigV4a

SigV4a verwendet asymmetrische Signaturen, die auf der Kryptografie mit öffentlichen und privaten Schlüsseln basieren. SigV4a durchläuft einen ähnlichen Prozess zur Ableitung von Anmeldeinformationen mit Gültigkeitsbereich wie SigV4, mit der Ausnahme, dass SigV4a denselben Schlüssel zum Signieren aller Anfragen verwendet, ohne dass ein eindeutiger Signaturschlüssel basierend auf Datum, Service und Region abgeleitet werden muss. Ein Algorithmus zur digitalen Signatur mit elliptischer Kurve (ECDSA) kann aus Ihrem vorhandenen geheimen AWS-Zugriffsschlüssel abgeleitet werden.

Das System verwendet asymmetrische Kryptografie zur Überprüfung von Multi-Region-Signaturen, sodass AWS nur Ihre öffentlichen Schlüssel speichern muss. Öffentliche Schlüssel sind nicht geheim und können nicht zum Signieren von Anfragen verwendet werden. Asymmetrische Signaturen sind für Anfragen an die Multi-Region-API erforderlich, z. B. bei Multi-Region-Zugangspunkten von Amazon S3.

Die folgenden Schritte beschreiben den allgemeinen Prozess der Berechnung einer Signatur mit SigV4a:

  1. Die zu signierende Zeichenfolge hängt von der Art der Anfrage ab. Wenn Sie beispielsweise den HTTP-Autorisierungs-Header oder die Abfrageparameter zur Authentifizierung verwenden, nutzen Sie eine Kombination aus Anforderungselementen, um die zu signierende Zeichenfolge zu erstellen. Bei einer HTTP-POST-Anfrage ist die POST-Richtlinie in der Anfrage die von Ihnen signierte Zeichenfolge.

  2. Der Signaturschlüssel wird durch eine Reihe von Berechnungen aus einem geheimen AWS-Zugriffsschlüssel abgeleitet, wobei das Ergebnis jedes Schritts in den nächsten einfließt. Im letzten Schritt wird das Schlüsselpaar erstellt.

  3. Wenn ein AWS-Service eine mit Sigv4a signierte Anfrage empfängt, überprüft AWS die Signatur nur unter Verwendung der öffentlichen Hälfte des Schlüsselpaars. Wenn die Unterschrift gültig ist, wird die Anfrage authentifiziert und der Service bearbeitet die Anfrage. Anfragen mit ungültigen Signaturen werden abgelehnt.

Weitere Informationen zu SigV4a für API-Anfragen in mehreren Regionen finden Sie im Projekt sigv4a-signing-examples in GitHub.

Wann müssen Anforderungen signiert werden?

Wenn Sie benutzerdefinierten Code schreiben, der API-Anforderungen an AWS sendet, müssen Sie Code einfügen, der die Anforderung signiert. Möglicherweise schreiben Sie benutzerdefinierten Code, weil:

  • Sie arbeiten mit einer Programmiersprache, für die kein AWS SDK verfügbar ist.

  • Sie möchten vollständig kontrollieren, wie Anforderungen an AWS gesendet werden.

Während API-Anfragen den Zugriff mit AWS SigV4 authentifizieren, authentifizieren AWS-SDKs und die AWS CLI Ihre Anfragen mithilfe der von Ihnen bereitgestellten Zugriffsschlüssel. Weitere Informationen über Authentifizierung mit AWS CLI-SDKs und der AWS, finden Sie unter Weitere Ressourcen.

Warum werden Anforderungen signiert?

Das Signieren erhöht die Sicherheit der Anforderungen, und zwar auf folgende Weise:

  • Überprüfung der Identität des Anforderers

    Für authentifizierte Anfragen ist eine Signatur erforderlich, die Sie mithilfe Ihrer Zugriffsschlüssel (Zugriffsschlüssel-ID, geheimer Zugriffsschlüssel) erstellen. Wenn Sie temporäre Sicherheitsanmeldeinformationen verwenden, ist für die Signaturberechnungen auch ein Sicherheitstoken erforderlich. Weitere Informationen finden Sie unter programmgesteuerter Zugriff auf AWS-Sicherheitsanmeldeinformationen.

  • Schutz der Daten während der Übertragung

    Um zu verhindern, dass eine Anforderung während der Übertragung manipuliert wird, werden einige ihrer Elemente verwendet, um einen Hash-Wert (Digest) der Anforderung zu berechnen. Der daraus resultierende Hash-Wert wird in die Anforderung aufgenommen. Wenn die Anforderung bei einem AWS-Service eingeht, verwendet es dieselben Informationen, um einen Hash zu berechnen und gleicht ihn mit dem Hash-Wert in Ihrer Anfrage ab. Wenn die Werte nicht übereinstimmen, wird die Anforderung von AWS abgelehnt.

  • Schutz vor potenziellen Replay-Angriffen

    Meistens muss eine Anforderung AWS innerhalb von fünf Minuten (laut Zeitstempel) erreichen. Andernfalls wird die Anforderung von AWS abgelehnt.

AWS SigV4 kann im HTTP-Autorisierungs-Header oder als Abfragezeichenfolge in der URL ausgedrückt werden. Weitere Informationen finden Sie unter Authentifizierungsmethoden.

Weitere Ressourcen