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. # AWS Signaturversion 4 für API-Anfragen **Wichtig** Wenn Sie ein AWS SDK (siehe [Beispielcode und Bibliotheken](https://aws.amazon.com/developer/)) oder AWS Command Line Interface (AWS CLI) Tool zum Senden von API-Anfragen verwenden AWS, können Sie den Signaturvorgang ü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 Access Points mit mehreren Regionen senden, SDKs wechselt die CLI automatisch zur Verwendung von Signature Version 4A ohne zusätzliche Konfiguration. 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. 1. Berechnung einer Signatur anhand Ihrer AWS Anmeldeinformationen. 1. Hinzufügen dieser Signatur zur Anfrage als Autorisierungs-Header. AWS repliziert dann diesen Vorgang und verifiziert die Signatur, wobei der Zugriff entsprechend gewährt oder verweigert wird. Bei symmetrischem SigV4 müssen Sie einen Schlüssel ableiten, der auf einen einzelnen AWS Service in einer einzelnen Region an einem bestimmten Tag beschränkt ist. AWS 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 verwenden oder Funktionen aufrufen AWS CLI , für die mehrere Regionen signiert werden müssen, wird der Signaturtyp automatisch auf SigV4a umgestellt. Details hierzu finden Sie unter [Wie funktioniert SigV4a AWS](#how-sigv4a-works). ## Wie funktioniert SigV4 AWS 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. 1. 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. 1. Wenn ein AWS Dienst eine authentifizierte Anfrage empfängt, erstellt er die **Signatur** anhand 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](reference_sigv-signing-elements.md). ## Wie funktioniert SigV4a AWS 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 ECDSA-Schlüsselpaar ([Elliptic Curve Digital Signature Algorithm](https://csrc.nist.gov/glossary/term/ecdsa)) kann aus Ihrem vorhandenen geheimen Zugriffsschlüssel abgeleitet werden. AWS 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. 1. 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. 1. Wenn ein AWS Dienst eine mit SigV4a signierte Anfrage empfängt, AWS verifiziert er die Signatur nur anhand 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 mit mehreren Regionen finden Sie im Sigv4-Projekt unter. a-signing-examples](https://github.com/aws-samples/sigv4a-signing-examples) GitHub ## Wann müssen Anforderungen signiert werden? Wenn Sie benutzerdefinierten Code schreiben, an den API-Anfragen gesendet werden, müssen Sie Code AWS angeben, der die Anfragen signiert. Möglicherweise schreiben Sie benutzerdefinierten Code, weil: + Sie arbeiten mit einer Programmiersprache, für die kein AWS SDK verfügbar ist. + Sie benötigen die vollständige Kontrolle darüber, an welche Empfänger Anfragen gesendet werden AWS. API-Anfragen authentifizieren zwar den Zugriff mit AWS Sigv4, AWS SDKs und dann AWS CLI authentifizieren Sie Ihre Anfragen mithilfe der von Ihnen bereitgestellten Zugriffsschlüssel. Weitere Hinweise zur Authentifizierung mit AWS SDKs und dem finden Sie unter. AWS CLI[Weitere Ressourcen](#reference_aws-signing-resources) ## 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](security-creds-programmatic-access.md). + **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 an die Anfrage AWS-Service empfängt, verwendet es dieselben Informationen, um einen Hash zu berechnen, und vergleicht ihn mit dem Hashwert in Ihrer Anfrage. Wenn die Werte nicht übereinstimmen, wird die AWS Anfrage abgelehnt. + **Schutz vor potenziellen Replay-Angriffen** In den meisten Fällen muss eine Anfrage AWS innerhalb von fünf Minuten nach dem Zeitstempel in der Anfrage eingehen. Andernfalls wird die AWS Anfrage abgelehnt. AWS SigV4 kann im HTTP-Autorisierungsheader oder als Abfragezeichenfolge in der URL ausgedrückt werden. Weitere Informationen finden Sie unter [Authentifizierungsmethoden](reference_sigv-authentication-methods.md). ## Weitere Ressourcen + Weitere Informationen über den SigV4-Signaturprozess für verschiedene Services finden Sie unter [Anfordern von Signaturbeispielen](reference_sigv-examples.md). + Informationen zum Konfigurieren von Anmeldeinformationen für den programmatischen Zugriff auf die AWS CLI finden Sie unter [Authentifizierungs- und Zugriffsanmeldeinformationen](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-authentication.html) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*. + Sie AWS SDKs enthalten Quellcode GitHub zum Signieren von AWS API-Anfragen. Codebeispiele finden Sie unter [Beispielprojekte im AWS Beispiel-Repository](reference_sigv-examples.md#signature-v4-examples-sdk). + AWS SDK für .NET — [AWS4Signer.cs](https://github.com/aws/aws-sdk-net/blob/master/sdk/src/Core/Amazon.Runtime/Internal/Auth/AWS4Signer.cs) + AWS SDK für C\$1\$1 — [AWSAuthV4Signer.cpp](https://github.com/aws/aws-sdk-cpp/blob/main/src/aws-cpp-sdk-core/source/auth/signer/AWSAuthV4Signer.cpp) + AWS SDK für Go — [sigv4.go](https://github.com/aws/smithy-go/blob/a4c9efcda6aa54c75d1a130d1320a2709eebf51d/aws-http-auth/sigv4/sigv4.go) + AWS SDK für Java [BaseAws— 4Signer.java](https://github.com/aws/aws-sdk-java-v2/blob/master/core/auth/src/main/java/software/amazon/awssdk/auth/signer/internal/BaseAws4Signer.java) + AWS SDK für JavaScript — [Signatur-v4](https://github.com/smithy-lang/smithy-typescript/tree/main/packages/signature-v4) + AWS SDK für PHP [— SignatureV4.php](https://github.com/aws/aws-sdk-php/blob/master/src/Signature/SignatureV4.php) + AWS SDK für Python (Boto) — [signers.py](https://github.com/boto/botocore/blob/develop/botocore/signers.py) + AWS SDK für Ruby — [signer.rb](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sigv4/lib/aws-sigv4/signer.rb) # Elemente einer AWS API-Anforderungssignatur **Wichtig** Sofern Sie nicht die AWS SDKs oder CLI verwenden, müssen Sie Code schreiben, um Signaturen zu berechnen, die Authentifizierungsinformationen in Ihren Anfragen enthalten. Die Signaturberechnung in AWS Signature Version 4 kann ein komplexes Unterfangen sein, und wir empfehlen Ihnen, wann immer möglich, die AWS SDKs oder CLI zu verwenden. Jede HTTP/HTTPS Anfrage, die die Signatur mit Signature Version 4 verwendet, muss diese Elemente enthalten. **Topics** + [ ## Endpunktspezifizierung ](#endpoint-specification) + [ ## Action ](#action) + [ ## Aktionsparameter ](#parameters) + [ ## Date ](#date) + [ ## Authentifizierungsinformationen ](#authentication) ## Endpunktspezifizierung Gibt den DNS-Namen des Endpunkts an, an den Sie die Anforderung senden. Dieser Name enthält normalerweise den Servicecode und die Region. Der Endpunkt für Amazon DynamoDB in der `us-east-1`-Region ist beispielsweise `dynamodb.us-east-1.amazonaws.com`. Für HTTP/1.1-Anforderungen müssen Sie den `Host`-Header einfügen. Für HTTP/2-Anforderungen können Sie den `:authority`-Header oder den `Host`-Header einfügen. Wenn die Anforderung der HTTP/2-Spezifikation entsprechen soll, verwenden Sie nur den `:authority`-Header. Nicht alle Services unterstützen HTTP/2-Anforderungen. Informationen zu den Endpunkten, die von den einzelnen Services unterstützt werden, finden Sie unter [Service-Endpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) in der *Allgemeine AWS-Referenz*. ## Action Gibt eine API-Aktion für den Service an. Zum Beispiel die DynamoDB `CreateTable`-Aktion oder die Amazon-EC2 `DescribeInstances`-Aktion. Informationen zu den Aktionen, die von den einzelnen Services unterstützt werden, finden Sie in der [Service-Autorisierungsreferenz](https://docs.aws.amazon.com//service-authorization/latest/reference/reference.html). ## Aktionsparameter Gibt die Parameter für die in der Anforderung angegebene Aktion an. Jede AWS API-Aktion hat eine Reihe erforderlicher und optionaler Parameter. Die API-Version ist in der Regel ein erforderlicher Parameter. Informationen zu den von einer API-Aktion unterstützten Parametern finden Sie in der API-Referenz für den Service. ## Date Gibt das Datum und die Uhrzeit der Anforderung an. Indem Sie der Anforderung Uhrzeit und Datum hinzufügen, können Sie verhindern, das Dritte Ihre Anforderung abfangen und zu einem späteren Zeitpunkt erneut hochladen. Das Datum, das Sie im Umfang der Anmeldeinformationen angeben, muss mit dem Datum Ihrer Anforderung übereinstimmen. Der Zeitstempel muss in UTC angegeben werden und das folgende ISO-8601-Format verwenden: *JJJJMMDD*T*HHMMSS*Z. Beispiel, `20220830T123600Z`. Geben Sie im Zeitstempel keine Millisekunden an. Sie können ein `date` oder einen `x-amz-date`-Header verwenden oder `x-amz-date` als Abfrageparameter einfügen. Wenn wir keinen `x-amz-date`-Header finden können, suchen wir nach einem `date`-Header. ## Authentifizierungsinformationen Jede Anfrage, die Sie senden, muss die folgenden Informationen enthalten. AWS verwendet diese Informationen, um die Gültigkeit und Authentizität der Anfrage sicherzustellen. + Algorithmus – Der Algorithmus, den Sie als Teil des Signaturprozesses verwenden. + SigV4 – Verwenden Sie `AWS4-HMAC-SHA256`, um Signature Version 4 mit dem `HMAC-SHA256`-Hash-Algorithmus anzugeben. + SigV4a – Verwenden Sie `AWS4-ECDSA-P256-SHA256`, um den `ECDSA-P256-SHA-256`-Hash-Algorithmus anzugeben. + Anmeldeinformationen – Eine Zeichenfolge, die durch die Verkettung der Zugriffsschlüssel-ID und Ihrer Anmeldeinformationen gebildet wird. + SigV4 – Der Gültigkeitsbereich der Anmeldeinformationen umfasst Ihre Zugriffsschlüssel-ID, das Datum im Format *JJJJMMDD*, den Regionscode, den Servicecode und die `aws4_request`-Beendigungszeichenfolge, getrennt durch Schrägstriche (/). Für den Regionscode, den Servicecode und die Abschlusszeichenfolge müssen Kleinbuchstaben verwendet werden. ``` AKIAIOSFODNN7EXAMPLE/YYYYMMDD/region/service/aws4_request ``` + SigV4a – Der Gültigkeitsbereich der Anmeldeinformationen umfasst das Datum im Format JJJJMMTT, den Servicenamen und die `aws4_request`-Beendigungszeichenfolge, getrennt durch Schrägstriche (/). Beachten Sie, dass der Gültigkeitsbereich der Anmeldeinformationen die Region nicht umfasst, da diese in einem separaten Header abgedeckt ist `X-Amz-Region-Set`. ``` AKIAIOSFODNN7EXAMPLE/YYYYMMDD/service/aws4_request ``` + Signierte Header – Die HTTP-Header, die in die Signatur aufgenommen werden sollen, getrennt durch Semikolons (;). Beispiel, `host;x-amz-date`. Für SigV4a müssen Sie einen Regionssatz-Header angeben, der die Regionen festlegt, in denen die Anfrage gültig ist. Der Header `X-Amz-Region-Set` wird als Liste von durch Kommas getrennten Werten angegeben. Das folgende Beispiel zeigt einen Region-Header, der Anfragen in den Regionen „us-east-1“ und „us-west-1“ ermöglicht. ``` X-Amz-Region-Set=us-east-1,us-west-1 ``` Sie können Platzhalter (\$1) in den Regionen verwenden, um mehrere Regionen anzugeben. Im folgenden Beispiel ermöglicht der Header Anfragen in den Regionen „us-west-1“ und „us-west-2“. ``` X-Amz-Region-Set=us-west-* ``` + Signatur – Eine hexadezimalkodierte Zeichenfolge, die die berechnete Signatur darstellt. Sie müssen die Signatur mit dem Algorithmus berechnen, den Sie im `Algorithm`-Parameter angegeben haben. Weitere Informationen finden Sie unter [Authentifizierungsmethoden](reference_sigv-authentication-methods.md). # Authentifizierungsmethoden **Wichtig** Sofern Sie nicht die AWS SDKs oder CLI verwenden, müssen Sie Code schreiben, um Signaturen zu berechnen, die Authentifizierungsinformationen in Ihren Anfragen enthalten. Die Signaturberechnung in AWS Signature Version 4 kann ein komplexes Unterfangen sein, und wir empfehlen Ihnen, wann immer möglich, die AWS SDKs oder CLI zu verwenden. Mit einer der folgenden Methoden können Sie Authentifizierungsinformationen ausdrücken. ## HTTP-Autorisierungs-Header Der HTTP-`Authorization`-Header ist die gängigste Methode zur Authentifizierung einer Anfrage. Alle REST-API-Vorgänge (außer browserbasierte Uploads mit `POST`-Anfragen) erfordern diesen Header. Die folgenden Beispiele zeigen den `Authorization`-Header-Wert für SigV4 und SigV4a. Zur besseren Lesbarkeit werden diesem Beispiel Zeilenumbrüche hinzugefügt. In Ihrem Code muss der Header eine fortlaufende Zeichenfolge sein. Zwischen dem Algorithmus und den Anmeldeinformationen steht kein Komma, die anderen Elemente müssen jedoch durch Kommas getrennt werden. **Example SigV4** ``` Authorization: AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request, SignedHeaders=host;range;x-amz-date, Signature=fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024 ``` **Example SigV4a** ``` Authorization: AWS4-ECDSA-P256-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/s3/aws4_request, SignedHeaders=host;range;x-amz-date;x-amz-region-set, Signature=fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024 ``` Die folgende Tabelle beschreibt die verschiedenen Komponenten des Werts des Autorisierungs-Headers aus dem vorangegangenen Beispiel: | Komponente | Description | | --- | --- | | Autorisierung | Der Algorithmus, der zur Berechnung der Signatur verwendet wurde. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) | | Credential | Ihre Zugriffsschlüssel-ID und die Informationen zum Geltungsbereich. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) Der Wert wird im Format JJJJMMTT angegeben. Der Wert ist S3, wenn eine Anforderung an Amazon S3 gesendet wird. | | SignedHeaders | Eine durch Semikolons getrennte Liste der Anforderungs-Header, die Sie zur Berechnung der Signatur verwendet haben. Die Liste enthält nur Header-Namen und die Header-Namen müssen in Kleinbuchstaben geschrieben sein. Beispiel: `host;range;x-amz-date` Für SigV4a müssen Sie einen Regionssatz-Header angeben, der die Regionen festlegt, in denen die Anfrage gültig ist. Der Header X-Amz-Region-Set wird als Liste von durch Kommas getrennten Werten angegeben. | | Signatur | Die 256-Bit-Signatur, ausgedrückt als 64 hexadezimale Kleinbuchstaben. Beispiel:`fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024` Beachten Sie, dass die Signaturberechnungen je nach gewählter Option zur Übertragung der Nutzlast variieren. | ## Parameter der Abfragezeichenfolge Sie können eine Abfragezeichenfolge verwenden, um eine Anfrage vollständig in einer URL auszudrücken. In diesem Fall verwenden Sie Abfrageparameter, um Anforderungsinformationen bereitzustellen, einschließlich der Authentifizierungsinformationen. Da die Anforderungssignatur Teil der URL ist, wird diese Art von URL oft als vorsignierte URL bezeichnet. Sie können Presigned verwenden URLs , um anklickbare Links in HTML einzubetten, die bis zu sieben Tage gültig sein können. Weitere Informationen finden Sie unter [Authentifizieren von Anfragen: Verwenden von Abfrageparametern (AWS Signature Version 4)](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html) in der *Amazon S3 S3-API-Referenz.* Die folgenden Beispiele zeigen, wie es URLs für Sigv4 und SigV4a vorsigniert ist. Zur besseren Lesbarkeit werden diesem Beispiel Zeilenumbrüche hinzugefügt: **Example SigV4** ``` https://s3.amazonaws.com/amzn-s3-demo-bucket/test.txt ? X-Amz-Algorithm=AWS4-HMAC-SHA256 & X-Amz-Credential=/20130721//s3/aws4_request & X-Amz-Date=20130721T201207Z & X-Amz-Expires=86400 & X-Amz-SignedHeaders=host &X-Amz-Signature= ``` **Example SigV4a** ``` http://s3.amazonaws.com/amzn-s3-demo-bucket/test.txt ? X-Amz-Algorithm=AWS4-ECDSA-P256-SHA256 & X-Amz-Credential=/20240721/s3/aws4_request & X-amz-Region-Set= & X-Amz-Date=20240721T201207Z & X-Amz-Expires=86400 & X-Amz-SignedHeaders=host;x-amz-region-set & X-Amz-Signature= ``` **Anmerkung** Der `X-Amz-Credential`-Wert in der URL zeigt das Zeichen „/“ nur zur besseren Lesbarkeit an. In der Praxis sollte es als %2F codiert werden. Beispiel: `&X-Amz-Credential=%2F20130721%2Fus-east-1%2Fs3%2Faws4_request` Die folgende Tabelle beschreibt die Abfrageparameter in der URL, die Informationen zur Authentifizierung bereitstellen. | Abfragezeichenfolgen-Parametername | Description | | --- | --- | | X-Amz-Algorithm | Die Version der AWS Signatur und der Algorithmus, den Sie zur Berechnung der Signatur verwendet haben. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) | | X-Amz-Credential | Zusätzlich zu Ihrer Zugriffsschlüssel-ID gibt dieser Parameter auch den Geltungsbereich an, für den die Signatur gültig ist. Dieser Wert muss mit dem Gültigkeitsbereich übereinstimmen, den Sie für die Signaturberechnungen verwenden, die im folgenden Abschnitt beschrieben werden. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) Eine Liste der AWS regionalen Zeichenketten finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com//general/latest/gr/rande.html#regional-endpoints) in der *AWS Allgemeinen* Referenz. | | X-Amz-Region-Set | Die Gruppe von Regionen, in denen die Anforderung gültig sein wird. Der Header x-amz-region-set wird als Liste von durch Kommas getrennten Werten angegeben. | | X-Amz-Datum | Das Datums- und Uhrzeitformat muss dem ISO 8601-Standard entsprechen und im `yyyyMMddTHHmmssZ`-Format formatiert sein. Wenn Datum und Uhrzeit beispielsweise „01.08.2016 15:32:41.982-700“ lauten, müssen diese zunächst in UTC (koordinierte Weltzeit) konvertiert und dann als „20160801T223241Z“ übermittelt werden. | | X-Amz-Expires | Gibt den Zeitraum in Sekunden an, für den die generierte vorsignierte URL gültig ist. Zum Beispiel 86 400 (24 Stunden). Es handelt sich um einen Ganzzahlwert. Der Mindestwert, den Sie festlegen können, ist 1 und der Höchstwert 604 800 (sieben Tage). Eine vorsignierte URL kann maximal sieben Tage gültig sein, da der Signaturschlüssel, den Sie bei der Signaturberechnung verwenden, bis zu sieben Tage gültig ist. | | X-Amz- SignedHeaders | Listet die Header auf, die Sie zur Berechnung der Signatur verwendet haben. Für die Signaturberechnungen sind folgende Header erforderlich: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) Für zusätzliche Sicherheit sollten Sie alle Anforderungs-Header signieren, die Sie in Ihre Anfrage aufnehmen möchten. | | X-Amz-Signature | Stellt die Signatur zur Authentifizierung Ihrer Anfrage bereit. Diese Signatur muss mit der vom Service berechneten Signatur übereinstimmen. Andernfalls lehnt der Service die Anfrage ab. Beispiel: `733255ef022bec3f2a8701cd61d4b371f3f28c9f193a1f02279211d48d5193d7` Signaturberechnungen werden im folgenden Abschnitt beschrieben. | | X-Amz-Security-Token | Optionaler Parameter für Anmeldeinformationen, wenn Sie Anmeldeinformationen verwenden, die vom STS-Service stammen. | # Erstellen Sie eine signierte AWS API-Anfrage **Wichtig** Wenn Sie ein AWS SDK (siehe [Beispielcode und Bibliotheken](https://aws.amazon.com/developer/)) oder AWS Command Line Interface (AWS CLI) Tool zum Senden von API-Anfragen verwenden AWS, können Sie diesen Abschnitt ü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 wird. Wenn Sie Anfragen an Access Points mit mehreren Regionen senden, SDKs wechselt die CLI automatisch zur Verwendung von Signature Version 4A ohne zusätzliche Konfiguration. Sie können das AWS SigV4-Signaturprotokoll verwenden, um eine signierte Anfrage für AWS API-Anfragen zu erstellen. 1. Erstellen einer kanonischen Anfrage basierend auf den Anfragedetails. 1. Berechnung einer Signatur anhand Ihrer AWS Anmeldeinformationen. 1. Hinzufügen dieser Signatur zur Anfrage als Autorisierungs-Header. AWS repliziert dann diesen Vorgang und verifiziert die Signatur, wobei der Zugriff entsprechend gewährt oder verweigert wird. Informationen darüber, wie Sie AWS SigV4 zum Signieren von API-Anfragen verwenden können, finden Sie unter. [Anfordern von Signaturbeispielen](reference_sigv-examples.md) In der folgenden Tabelle werden die beim Erstellen einer signierten Anfrage verwendeten Funktionen beschrieben. Für diese Funktionen muss Code implementiert werden. Weitere Informationen finden Sie in den [Codebeispielen im AWS SDKs](reference_sigv.md#reference_aws-signing-resources). | Funktion | Description | | --- | --- | | `Lowercase()` | Wandeln Sie die Zeichenfolge in Kleinbuchstaben um. | | `Hex()` | Kodierung in Kleinbuchstaben im Basis-16-Format. | | `SHA256Hash()` | Kryptografische Hash-Funktion des Secure Hash Algorithm (SHA). | | `HMAC-SHA256()` | Berechnet HMAC mithilfe des SHA256 Algorithmus mit dem bereitgestellten Signaturschlüssel. Dies ist die endgültige Signatur, wenn Sie mit SigV4 signieren. | | `ECDSA-Sign` | Die Signatur basiert auf dem Elliptic Curve Digital Signature Algorithm (ECDSA) und wird mithilfe asymmetrischer Signaturen auf Basis der Kryptografie mit öffentlichen und privaten Schlüsseln berechnet. | | `KDF(K, Label, Context, L)` | [Ein NIST SP800 -108 KDF im Zählermodus unter Verwendung der PRF-Funktion HMAC-SHA256 , wie in NIST SP 800-108r1 definiert.](https://doi.org/10.6028/NIST.SP.800-108r1-upd1) | | `Oct2Int(byte[ ])` | Eine Oktett-zu-Ganzzahl-Funktion gemäß ANSI X9.62. | | `Trim()` | Entfernen Sie alle führenden oder nachgestellten Leerzeichen. | | `UriEncode()` | URI kodieren jedes Byte. UriEncode() muss die folgenden Regeln durchsetzen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/reference_sigv-create-signed-request.html) Die von Ihrer Entwicklungsplattform bereitgestellten UriEncode Standardfunktionen funktionieren möglicherweise aufgrund von Unterschieden in der Implementierung und der damit verbundenen Mehrdeutigkeit der zugrunde liegenden Funktionen nicht. RFCs Wir empfehlen Ihnen, Ihre eigene benutzerdefinierte UriEncode Funktion zu schreiben, um sicherzustellen, dass Ihre Kodierung funktioniert. Ein Beispiel für eine UriEncode Funktion in Java finden Sie unter [Java Utilities](https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-core/src/main/java/com/amazonaws/util/SdkHttpUtils.java#L66) auf der GitHub Website. | **Anmerkung** Beim Signieren Ihrer Anfragen können Sie entweder AWS SigV4 oder AWS SigV4a verwenden. Der Hauptunterschied zwischen den beiden wird dadurch bestimmt, wie die Signatur berechnet wird. Bei SigV4a ist der Regionssatz zwar in der zu signierenden Zeichenfolge enthalten, jedoch nicht Teil des Schritts zur Ableitung der Anmeldeinformationen. ## Signieren von Anfragen mit temporären Sicherheits-Anmeldeinformationen Anstatt langfristige Anmeldeinformationen zum Signieren einer Anfrage zu verwenden, können Sie temporäre Sicherheitsanmeldedaten verwenden, die von AWS -Security-Token-Service () bereitgestellt werden.AWS STS Wenn Sie temporäre Sicherheitsanmeldeinformationen verwenden, müssen Sie dem Autorisierungs-Header `X-Amz-Security-Token` hinzufügen oder es in die Abfragezeichenfolge aufnehmen, um das Sitzungs-Token zu speichern. Bei einigen Services müssen Sie die kanonische Anforderung durch das `X-Amz-Security-Token` ergänzen. Bei anderen Services müssen Sie nur am Ende, nach der Berechnung der Signatur, `X-Amz-Security-Token` hinzufügen. Informationen zu den spezifischen Anforderungen finden Sie in der jeweiligen Dokumentation. AWS-Service ## Zusammenfassung der Signierschritte **Erstellen einer kanonischen Anfrage** Ordnen Sie den Inhalt Ihrer Anfrage (Host, Aktion, Header usw.) in einem standardmäßigen kanonischen Format an. Die kanonische Anfrage ist eine der Eingaben, die zum Erstellen der zu signierenden Zeichenfolge verwendet werden. Einzelheiten zum Erstellen der kanonischen Anfrage finden Sie unter [Elemente einer AWS API-Anforderungssignatur](reference_sigv-signing-elements.md). **Hash der kanonischen Anfrage erstellen** Hashen Sie die kanonische Anfrage mit demselben Algorithmus, den Sie zum Erstellen des Hashs der Nutzlast verwendet haben. Der Hash der kanonischen Anfrage ist eine Zeichenfolge aus hexadezimalen Zeichen in Kleinbuchstaben. **Erstellen einer zu signierenden Zeichenfolge** Erstellen Sie eine Zeichenfolge zum Signieren mit der kanonischen Anfrage und zusätzlichen Informationen wie dem Algorithmus, dem Anfragedatum, dem Umfang der Anmeldeinformationen und dem Hash der kanonischen Anfrage. **Signaturschlüssel ableiten** Verwenden Sie den geheimen Zugriffsschlüssel, um den Schlüssel zum Signieren der Anfrage abzuleiten. **Berechnen der Signatur** Führen Sie eine Keyed-Hash-Operation für die zu signierende Zeichenfolge durch und verwenden Sie dabei den abgeleiteten Signaturschlüssel als Hash-Schlüssel. **Hinzufügen der Signatur zur Anfrage** Fügen Sie die berechnete Signatur einem HTTP-Header oder der Abfragezeichenfolge der Anfrage hinzu. ## Erstellen einer kanonischen Anfrage Um eine kanonische Anfrage zu erstellen, verketten Sie die folgenden Zeichenfolgen, getrennt durch Zeilenumbruchzeichen. Auf diese Weise können Sie sicherstellen, dass die von Ihnen berechnete Signatur mit der AWS berechneten Signatur übereinstimmt. ``` \n \n \n \n \n ``` + *HTTPMethod*— Die HTTP-Methode, z. B.`GET`, `PUT``HEAD`, und`DELETE`. + *CanonicalUri*— Die URI-kodierte Version des absoluten Pfadkomponenten-URI, beginnend mit dem`/`, der auf den Domainnamen folgt, und bis zum Ende der Zeichenfolge oder bis zum Fragezeichen (`?`), wenn Sie Parameter für die Abfragezeichenfolge haben. Wenn der absolute Pfad leer ist, verwenden Sie einen umgekehrten Schrägstrich (`/`). Beim URI im folgenden Beispiel, `/amzn-s3-demo-bucket/myphoto.jpg`, handelt es sich um den absoluten Pfad und Sie codieren das `/` nicht im absoluten Pfad: ``` http://s3.amazonaws.com/amzn-s3-demo-bucket/myphoto.jpg ``` + *CanonicalQueryString*— Die URI-kodierten Parameter der Abfragezeichenfolge. Sie kodieren jeden Namen und jeden Wert einzeln per URI. Sie müssen die Parameter in der kanonischen Abfragezeichenfolge außerdem alphabetisch nach Schlüsselnamen sortieren. Die Sortierung erfolgt nach der Codierung. Die Abfragezeichenfolge im folgenden URI-Beispiel lautet: ``` http://s3.amazonaws.com/amzn-s3-demo-bucket?prefix=somePrefix&marker=someMarker&max-keys=2 ``` Die kanonische Abfragezeichenfolge lautet wie folgt (zur besseren Lesbarkeit wurden diesem Beispiel Zeilenumbrüche hinzugefügt): ``` UriEncode("marker")+"="+UriEncode("someMarker")+"&"+ UriEncode("max-keys")+"="+UriEncode("20") + "&" + UriEncode("prefix")+"="+UriEncode("somePrefix") ``` Wenn eine Anfrage auf eine Unterressource abzielt, ist der entsprechende Abfrageparameterwert eine leere Zeichenfolge (`""`). Der folgende URI identifiziert beispielsweise die `ACL`-Unterressource im `amzn-s3-demo-bucket`-Bucket: ``` http://s3.amazonaws.com/amzn-s3-demo-bucket?acl ``` In diesem Fall wäre das CanonicalQueryString : ``` UriEncode("acl") + "=" + "" ``` Wenn der URI kein `?` enthält, gibt es in der Anfrage keine Abfragezeichenfolge und Sie legen die kanonische Abfragezeichenfolge auf eine leere Zeichenfolge (`""`) fest. Sie müssen weiterhin das Zeilenumbruchzeichen (`"\n"`) einfügen. + *CanonicalHeaders*— Eine Liste von Anforderungsheadern mit ihren Werten. Einzelne Header-Namens- und Wertpaare werden durch das Zeilenumbruchzeichen (`"\n"`) getrennt. Es folgt ein Beispiel für CanonicalHeader. ``` Lowercase()+":"+Trim()+"\n" Lowercase()+":"+Trim()+"\n" ... Lowercase()+":"+Trim()+"\n" ``` CanonicalHeaders Die Liste muss Folgendes enthalten: + HTTP-`host`-Header. + Wenn der `Content-Type` Header in der Anfrage vorhanden ist, müssen Sie ihn der *CanonicalHeaders* Liste hinzufügen. + Alle `x-amz-*`-Header, die Sie in Ihre Anfrage aufnehmen möchten, müssen ebenfalls hinzugefügt werden. Wenn Sie beispielsweise temporäre Sicherheitsanmeldeinformationen verwenden, müssen Sie `x-amz-security-token` in Ihre Anfrage einschließen. Sie müssen diesen Header zur Liste von hinzufügen*CanonicalHeaders*. + Für SigV4a müssen Sie einen Regionssatz-Header angeben, der die Regionen festlegt, in denen die Anfrage gültig ist. Der Header `X-Amz-Region-Set` wird als Liste von durch Kommas getrennten Werten angegeben. Das folgende Beispiel zeigt einen Region-Header, der Anfragen in den Regionen „us-east-1“ und „us-west-1“ ermöglicht. `X-Amz-Region-Set=us-east-1,us-west-1 ` Sie können Platzhalter (\$1) in den Regionen verwenden, um mehrere Regionen anzugeben. Im folgenden Beispiel ermöglicht der Header Anfragen in den Regionen „us-west-1“ und „us-west-2“. `X-Amz-Region-Set=us-west-*` **Anmerkung** Der `x-amz-content-sha256`-Header ist für Anfragen für Amazon S3 AWS erforderlich. Es stellt einen Hash der Anforderungsnutzlast bereit. Wenn keine Nutzdaten vorhanden sind, müssen Sie den Hash einer leeren Zeichenfolge bereitstellen. Jeder Header-Name muss: + Kleinbuchstaben verwenden. + in alphabetischer Reihenfolge erscheinen. + von einem Doppelpunkt (`:`) gefolgt sein. Bei Werten müssen Sie: + alle führenden oder nachgestellten Leerzeichen entfernen. + aufeinanderfolgende Leerzeichen in ein einzelnes Leerzeichen umwandeln. + die Werte für einen mehrwertigen Header durch Kommas trennen. + Sie müssen den Host-Header (HTTP/1.1) oder den :authority-Header (HTTP/2) sowie alle `x-amz-*`-Header in die Signatur einschließen. Sie können optional andere Standard-Header in die Signatur aufnehmen, z. B. content-type. Die in diesem Beispiel verwendeten `Lowercase()`- und `Trim()`-Funktionen werden im vorangehenden Abschnitt beschrieben. Im Folgenden finden Sie ein Beispiel für eine `CanonicalHeaders`-Zeichenfolge. Die Header-Namen sind in Kleinbuchstaben geschrieben und sortiert. ``` host:s3.amazonaws.com x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 x-amz-date:20130708T220855Z ``` **Anmerkung** Für die Berechnung einer Autorisierungssignatur sind nur der Host und etwaige `x-amz-*`-Header erforderlich. Um jedoch Datenmanipulationen vorzubeugen, sollten Sie erwägen, zusätzliche Header in die Signaturberechnung einzubeziehen. Schließen Sie keine hop-by-hop Header ein, die während der Übertragung durch ein komplexes System häufig geändert werden. Dies umfasst alle flüchtigen Transport-Header, die von Proxys, Load Balancern und den Knoten in einem verteilten System verändert werden, einschließlich `connection`, `x-amzn-trace-id`, `user-agent`, `keep-alive`, `transfer-encoding`, `TE`, `trailer`, `upgrade`, `proxy-authorization` und `proxy-authenticate`. + *SignedHeaders*— Eine alphabetisch sortierte, durch Semikolons getrennte Liste kleingeschriebener Request-Header-Namen. Bei den Anforderungs-Headern in der Liste handelt es sich um dieselben Header, die Sie in die Zeichenfolge `CanonicalHeaders` eingeschlossen haben. Für das vorherige Beispiel wäre der Wert von wie folgt: *SignedHeaders* ``` host;x-amz-content-sha256;x-amz-date ``` + *HashedPayload*— Eine Zeichenfolge, die unter Verwendung der Nutzdaten im Hauptteil der HTTP-Anfrage als Eingabe für eine Hash-Funktion erstellt wurde. Diese Zeichenfolge verwendet Hexadezimalzeichen in Kleinbuchstaben. ``` Hex(SHA256Hash(>)) ``` Wenn die Anfrage keine Nutzlast enthält, berechnen Sie einen Hash der leeren Zeichenfolge. Wenn Sie beispielsweise ein Objekt mithilfe einer `GET`-Anfrage abrufen, enthält die Nutzlast nichts. ``` Hex(SHA256Hash("")) ``` **Anmerkung** Schließen Sie für Amazon S3 beim Erstellen einer kanonischen Anfrage die Literalzeichenfolge `UNSIGNED-PAYLOAD` ein und legen Sie beim Senden der Anfrage denselben Wert wie für den Header-Wert `x-amz-content-sha256` fest. `Hex(SHA256Hash("UNSIGNED-PAYLOAD"))` ## Hash der kanonischen Anfrage erstellen Erstellen Sie einen Hash (Digest) der kanonischen Anforderung mithilfe desselben Algorithmus, den Sie zur Erstellung des Hashes der Nutzdaten verwendet haben. Der Hash der kanonischen Anfrage ist eine Zeichenfolge aus hexadezimalen Zeichen in Kleinbuchstaben. ## Erstellen einer zu signierenden Zeichenfolge Um eine zu signierende Zeichenfolge zu erstellen, verketten Sie die folgenden Zeichenfolgen, getrennt durch Zeilenumbruchzeichen. Beenden Sie diese Zeichenfolge nicht mit einem Zeilenumbruch. ``` Algorithm \n RequestDateTime \n CredentialScope \n HashedCanonicalRequest ``` + *Algorithm*— Der Algorithmus, der verwendet wurde, um den Hash der kanonischen Anfrage zu erstellen. + SigV4 – Verwenden Sie `AWS4-HMAC-SHA256`, um den `HMAC-SHA256`-Hash-Algorithmus anzugeben. + SigV4a – Verwenden Sie `AWS4-ECDSA-P256-SHA256`, um den `ECDSA-P256-SHA-256`-Hash-Algorithmus anzugeben. + *RequestDateTime*— Das Datum und die Uhrzeit, die im Bereich der Anmeldeinformationen verwendet wurden. Bei diesem Wert handelt es sich um die aktuelle UTC-Zeit im ISO 8601-Format (zum Beispiel `20130524T000000Z`). + *CredentialScope*— Der Gültigkeitsbereich der Anmeldeinformationen, der die resultierende Signatur auf die angegebene Region und den angegebenen Dienst beschränkt. + SigV4 – Die Anmeldeinformationen umfassen Ihre Zugriffsschlüssel-ID, das Datum im `YYYYMMDD`-Format, den Regionscode, den Servicecode und die `aws4_request`-Abschlusszeichenfolge, getrennt durch Schrägstriche (/). Für den Regionscode, den Servicecode und die Abschlusszeichenfolge müssen Kleinbuchstaben verwendet werden. Die Zeichenfolge hat folgendes Format: `YYYYMMDD/region/service/aws4_request`. + SigV4a – Die Anmeldeinformationen umfassen das Datum im `YYYYMMDD`-Format, den Servicenamen und die `aws4_request`-Abschlusszeichenfolge, getrennt durch Schrägstriche (/). Beachten Sie, dass der Gültigkeitsbereich der Anmeldeinformationen die Region nicht umfasst, da diese in einem separaten Header `X-Amz-Region-Set` abgedeckt ist. Die Zeichenfolge hat folgendes Format: `YYYYMMDD/service/aws4_request`. + *HashedCanonicalRequest*— Der Hash der kanonischen Anfrage, berechnet im vorherigen Schritt. Im Folgenden finden Sie ein Beispiel für eine zu signierende Zeichenfolge. ``` "" + "\n" + timeStampISO8601Format + "\n" + + "\n" + Hex(()) ``` ## Signaturschlüssel ableiten Um einen Signaturschlüssel abzuleiten, wählen Sie eines der folgenden Verfahren zur Berechnung eines Signaturschlüssels für SigV4 oder SigV4a. ### Ableiten eines Signaturschlüssels für SigV4: Um einen Signaturschlüssel für Sigv4 abzuleiten, führen Sie eine Reihe von Schlüssel-Hash-Operationen (HMAC) für das Anforderungsdatum, die Region und den Dienst aus, wobei Ihr AWS geheimer Zugriffsschlüssel der Schlüssel für den ersten Hashing-Vorgang ist. Rufen Sie für jeden Schritt die Hash-Funktion mit den erforderlichen Schlüsseln und Daten auf. Das Ergebnis jedes Aufrufs der Hash-Funktion wird zur Eingabe für den nächsten Aufruf der Hash-Funktion. Das folgende Beispiel zeigt, wie Sie das im nächsten Abschnitt dieses Verfahrens verwendete `SigningKey` ableiten und zeigt die Reihenfolge, in der Ihre Eingabe verkettet und gehasht wird. `HMAC-SHA256` ist die Hash-Funktion, die wie gezeigt zum Hashen der Daten verwendet wird. ``` DateKey = HMAC-SHA256("AWS4"+"", "") DateRegionKey = HMAC-SHA256(, "") DateRegionServiceKey = HMAC-SHA256(, "") SigningKey = HMAC-SHA256(, "aws4_request") ``` **Erforderliche Eingabe** + `Key` – Eine Zeichenfolge, die Ihren geheimen Zugriffsschlüssel enthält. + `Date` – Eine Zeichenfolge, die das im Gültigkeitsbereich der Anmeldeinformationen verwendete Datum im Format *JJJJMMDD* enthält. + `Region` – Eine Zeichenfolge, die den Regionscode enthält (z. B. `us-east-1`). Eine Liste der Region-Zeichenfolgen finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com//general/latest/gr/rande.html#regional-endpoints) im *Allgemeine AWS-Referenz*. + `Service` – Eine Zeichenfolge, die den Service-Code enthält (z. B. `ec2`). + Die zu signierende Zeichenfolge, die Sie im vorherigen Schritt erstellt haben. **So leiten Sie einen Signaturschlüssel für SigV4 ab** 1. Verketten Sie `"AWS4"` und den geheimen Zugriffsschlüssel. Rufen Sie die Hash-Funktion mit der verketteten Zeichenfolge als Schlüssel und der Datumszeichenfolge als Daten auf. ``` DateKey = hash("AWS4" + Key, Date) ``` 1. Rufen Sie die Hash-Funktion mit dem Ergebnis des vorherigen Aufrufs als Schlüssel und der Region-Zeichenfolge als Daten auf. ``` DateRegionKey = hash(kDate, Region) ``` 1. Rufen Sie die Hash-Funktion mit dem Ergebnis des vorherigen Aufrufs als Schlüssel und der Service-Zeichenfolge als Daten auf. Der Service-Code wird durch den Service definiert. Sie können [get-products](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/pricing/get-products.html) in der *CLI für AWS -Preisgestaltung* verwenden, um den Service-Code für einen Service zurückzugeben. ``` DateRegionServiceKey = hash(kRegion, Service) ``` 1. Rufen Sie die Hash-Funktion mit dem Ergebnis des vorherigen Aufrufs als Schlüssel und „aws4\$1request“ als Daten auf. ``` SigningKey = hash(kService, "aws4_request") ``` ### Ableiten eines Signaturschlüssels für SigV4a Um einen Signaturschlüssel für SigV4a zu erstellen, leiten Sie mithilfe des folgenden Verfahrens ein Schlüsselpaar aus dem geheimen Zugriffsschlüssel ab. [Ein Beispiel für eine Implementierung dieser Ableitung finden Sie in der Implementierung der clientseitigen Authentifizierung in der C99-Bibliothek AWS](https://github.com/awslabs/aws-c-auth/blob/e8360a65e0f3337d4ac827945e00c3b55a641a5f/source/key_derivation.c#L291.) ``` n = [NIST P-256 elliptic curve group order] G = [NIST P-256 elliptic curve base point] label = "AWS4-ECDSA-P256-SHA256" akid = [AWS access key ID as a UTF8 string] sk = [AWS secret access Key as a UTF8 Base64 string] input_key = "AWS4A" || sk count = 1 while (counter != 255) { context = akid || counter // note: counter is one byte key = KDF(input_key, label, context, 256) c = Oct2Int(key) if (c > n - 2) { counter++ } else { k = c + 1 // private key Q = k * G // public key } } if (c < 255) { return [k, Q] } else { return FAILURE } ``` ## Berechnen der Signatur Nachdem Sie den Signaturschlüssel abgeleitet haben, berechnen Sie die Signatur, die Sie Ihrer Anfrage hinzufügen möchten. Dieses Verfahren hängt von der verwendeten Signaturversion ab. **So berechnen Sie eine Signatur für SigV4** 1. Rufen Sie die Hash-Funktion mit dem Ergebnis des vorherigen Aufrufs als Schlüssel und der **zu signierenden Zeichenfolge** als Daten auf. Verwenden Sie den abgeleiteten Signaturschlüssel als Hash-Schlüssel für diese Operation. Das Ergebnis ist die Signatur als Binärwert. ``` signature = hash(SigningKey, string-to-sign) ``` 1. Konvertieren Sie die Signatur von der binären in die hexadezimale Darstellung in Kleinbuchstaben. **So berechnen Sie eine Signatur für SigV4a** 1. Signieren Sie mithilfe des Algorithmus für digitale Signaturen (ECDSA P-256) die **zu signierende Zeichenfolge**, die Sie im vorherigen Schritt erstellt haben. Der für diese Signatur verwendete Schlüssel ist der private asymmetrische Schlüssel, der wie oben beschrieben aus dem geheimen Zugriffsschlüssel abgeleitet wird. ``` signature = base16(ECDSA-Sign(k, string-to-sign)) ``` 1. Konvertieren Sie die Signatur von der binären in die hexadezimale Darstellung in Kleinbuchstaben. ## Hinzufügen der Signatur zur Anfrage Fügen Sie Ihrer Anfrage die berechnete Signatur hinzu. **Example Beispiel: Autorisierungsheader** **SigV4** Das folgende Beispiel zeigt einen `Authorization` Header für die Aktion, die `DescribeInstances` SigV4 verwendet. AWS Aus Gründen der Lesbarkeit ist dieses Beispiel mit Zeilenumbrüchen formatiert. In Ihrem Code muss dies eine fortlaufende Zeichenfolge sein. Es steht kein Komma zwischen Algorithmus und `Credential`. Die anderen Elemente müssen jedoch durch Kommas getrennt werden. ``` Authorization: AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20220830/us-east-1/ec2/aws4_request, SignedHeaders=host;x-amz-date, Signature=calculated-signature ``` **SigV4a** Das folgende Beispiel zeigt einen Authorization-Header für die `CreateBucket` Aktion, die AWS SigV4a verwendet. Aus Gründen der Lesbarkeit ist dieses Beispiel mit Zeilenumbrüchen formatiert. In Ihrem Code muss dies eine fortlaufende Zeichenfolge sein. Zwischen Algorithmus und Anmeldeinformationen steht kein Komma. Die anderen Elemente müssen jedoch durch Kommas getrennt werden. ``` Authorization: AWS4-ECDSA-P256-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20220830/s3/aws4_request, SignedHeaders=host;x-amz-date;x-amz-region-set, Signature=calculated-signature ``` **Example Beispiel: Anforderung mit Authentifizierungsparametern in der Abfragezeichenfolge** **SigV4** Das folgende Beispiel zeigt eine Abfrage für die `DescribeInstances` Aktion unter Verwendung von AWS Sigv4, die die Authentifizierungsinformationen enthält. Aus Gründen der Lesbarkeit ist dieses Beispiel mit Zeilenumbrüchen formatiert und ist nicht URL-codiert. In Ihrem Code muss die Abfragezeichenfolge eine fortlaufende Zeichenfolge sein, die URL-codiert ist. ``` https://ec2.amazonaws.com/? Action=DescribeInstances& Version=2016-11-15& X-Amz-Algorithm=AWS4-HMAC-SHA256& X-Amz-Credential=AKIAIOSFODNN7EXAMPLE/20220830/us-east-1/ec2/aws4_request& X-Amz-Date=20220830T123600Z& X-Amz-SignedHeaders=host;x-amz-date& X-Amz-Signature=calculated-signature ``` **SigV4a** Das folgende Beispiel zeigt eine Abfrage für die `CreateBucket`-Aktion mit AWS SigV4a, die die Authentifizierungsinformationen enthält. Aus Gründen der Lesbarkeit ist dieses Beispiel mit Zeilenumbrüchen formatiert und ist nicht URL-codiert. In Ihrem Code muss die Abfragezeichenfolge eine fortlaufende Zeichenfolge sein, die URL-codiert ist. ``` https://ec2.amazonaws.com/? Action=CreateBucket& Version=2016-11-15& X-Amz-Algorithm=AWS4-ECDSA-P256-SHA256& X-Amz-Credential=AKIAIOSFODNN7EXAMPLE/20220830/s3/aws4_request& X-Amz-Region-Set=us-west-1& X-Amz-Date=20220830T123600Z& X-Amz-SignedHeaders=host;x-amz-date;x-amz-region-set& X-Amz-Signature=calculated-signature ``` # Anfordern von Signaturbeispielen Die folgenden Beispiele für AWS Signieranfragen zeigen Ihnen, wie Sie SigV4 verwenden können, um Anfragen zu signieren, die ohne das AWS SDK oder das AWS Befehlszeilentool gesendet wurden. ## Browserbasierter Amazon-S3-Upload mit HTTP POST Unter [Authenticating Requests: Browser-Based Uploads](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-authentication-HTTPPOST.html) werden die Signatur und die relevanten Informationen beschrieben, die Amazon S3 verwendet, um die Signatur nach Erhalt der Anforderung zu berechnen. [Beispiel: Der browserbasierte Upload mit HTTP POST (unter Verwendung von AWS Signature Version 4)](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-post-example.html) bietet weitere Informationen mit einer Beispiel-POST-Richtlinie und einem Formular, das Sie zum Hochladen einer Datei verwenden können. Die Beispielrichtlinie und die fiktive Anmeldeinformation zeigen Ihnen den Workflow und die daraus resultierende Signatur und den Richtlinien-Hash. ## Authentifizierte VPC-Lattice-Anforderungen [Examples for Signature Version 4 (SigV4) authenticated requests](https://docs.aws.amazon.com/vpc-lattice/latest/ug/sigv4-authenticated-requests.html) enthält Python- und Java-Beispiele, die zeigen, wie Sie das Signieren von Anforderungen mit und ohne benutzerdefinierte Interceptors durchführen können. ## Verwenden von Signature Version 4 mit Amazon Translate [Live-Übersetzungen im Metaverse](https://aws.amazon.com/blogs/spatial/live-translations-in-the-metaverse/) zeigt, wie man eine Anwendung erstellt, die eine nahezu Echtzeit-Übersetzungslösung erstellt. Diese speech-to-speech Übersetzerlösung verwendet AWS SigV4 bei der Event-Stream-Kodierung, um Transkriptionen in Echtzeit zu erstellen. ## Verwenden von Signature Version 4 mit Neptune [Example: Connecting to Neptune Using Python with Signature Version 4 Signing](https://docs.aws.amazon.com/neptune/latest/userguide/iam-auth-connecting-python.html) zeigt, wie signierte Anforderungen mithilfe von Python an Neptune gestellt werden. Dieses Beispiel enthält Varianten für die Verwendung eines Zugriffsschlüssels oder temporärer Anmeldeinformationen. ## Signieren von HTTP-Anforderungen für Amazon Glacier Das [Beispiel Signature Calculation for Streaming API](https://docs.aws.amazon.com/amazonglacier/latest/dev/amazon-glacier-signing-requests.html) führt Sie durch die Details der Erstellung einer Signatur für Upload Archive (POST-Archiv), eines der beiden Streaming-Programme APIs in Amazon Glacier. ## Übermitteln von HTTP-Anforderungen an Amazon SWF Unter [Making HTTP Requests to Amazon SWF](https://docs.aws.amazon.com/amazonswf/latest/developerguide/UsingJSON-swf.html#HTTPHeader) werden die Header-Inhalte für eine JSON-Anforderung für Amazon SWF gezeigt. ## Signaturberechnung für Streaming APIs in Amazon OpenSearch Service Das [Signieren einer Amazon OpenSearch Service-Suchanfrage mit dem AWS SDK for PHP Version 3](https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/service_es-data-plane.html) enthält ein Beispiel dafür, wie signierte HTTP-Anfragen an Amazon OpenSearch Service gesendet werden. ## Beispielprojekte im AWS Beispiel-Repository Die folgenden Beispielprojekte zeigen, wie Anfragen signiert werden, um REST-API-Anfragen an AWS Dienste mit gängigen Sprachen wie Python, Node.js, Java, C\$1, Go und Rust zu stellen. ### Projekte mit Signaturversion 4a Das Projekt [sigv4-signing-examples bietet Beispiele dafür](https://github.com/aws-samples/sigv4-signing-examples), wie Anfragen mit SigV4 signiert werden können, um Rest-API-Anfragen AWS-Services mit gängigen Sprachen wie Python, Node.js, Java, C\$1, Go und Rust zu stellen. Das [a-signing-examplessigv4-Projekt](https://github.com/aws-samples/sigv4a-signing-examples) bietet Beispiele für das Signieren von API-Anfragen für mehrere Regionen, zum Beispiel [Multi-Region-Access Points in Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html). ### Veröffentlichen auf AWS IoT Core [Python-Code zum AWS IoT Core Veröffentlichen im HTTPs Protokoll](https://github.com/aws-samples/aws-iot-core-python-node-sigv4-https) bietet Anleitungen zum Veröffentlichen von Nachrichten AWS IoT Core mithilfe des HTTPS-Protokolls und der AWS SigV4-Authentifizierung. Es hat zwei Referenzimplementierungen - eine in Python und eine in NodeJs. [.Net Framework-Anwendung zur Veröffentlichung AWS IoT Core unter Verwendung eines HTTPs Protokolls](https://github.com/aws-samples/aws-iot-core-http-sigv4-dotnet-app) bietet Anleitungen zum Veröffentlichen von Nachrichten AWS IoT Core mithilfe des HTTPS-Protokolls und der AWS SigV4-Authentifizierung. Dieses Projekt beinhaltet auch eine .NET Core-äquivalente Implementierung. # Problembehandlung bei Signature Version 4-Signaturen für AWS API-Anfragen **Wichtig** Sofern Sie nicht die AWS SDKs oder CLI verwenden, müssen Sie Code schreiben, um Signaturen zu berechnen, die Authentifizierungsinformationen in Ihren Anfragen enthalten. Die SigV4-Signaturberechnung kann ein komplexes Unterfangen sein, und wir empfehlen, dass Sie, wann immer möglich, die AWS SDKs oder CLI verwenden. Wenn Sie Code entwickeln, der eine signierte Anfrage erstellt, erhalten Sie möglicherweise HTTP 403 `SignatureDoesNotMatch` von AWS-Services. Diese Fehler bedeuten, dass der Signaturwert in Ihrer HTTP-Anfrage AWS nicht mit der AWS-Service berechneten Signatur übereinstimmt. HTTP `Unauthorized` 401-Fehler werden zurückgegeben, wenn die Berechtigungen es dem Aufrufer nicht erlauben, die Anfrage zu stellen. API-Anforderungen können in folgenden Fällen einen Fehler zurückgeben: + Die API-Anforderung ist nicht signiert und die API-Anfrage verwendet die IAM-Authentifizierung. + Die zum Signieren der Anfrage verwendeten IAM-Anmeldeinformationen sind falsch oder verfügen nicht über die erforderlichen Berechtigungen zum Aufrufen der API. + Die Signatur der signierten API-Anfrage stimmt nicht mit der Signatur überein, die der AWS -Service berechnet hat. + Der API-Anforderungs-Header ist falsch. **Anmerkung** Aktualisieren Sie Ihr Signaturprotokoll von AWS Signature Version 2 (SigV2) auf AWS Signature Version 4 (Sigv4), bevor Sie sich mit anderen Fehlerlösungen befassen. Services wie Amazon S3 und Regionen unterstützen die SigV2-Signierung nicht mehr. **Topics** + [ ## Fehler bei den Anmeldeinformationen ](#signature-v4-troubleshooting-credential) + [ ## Fehler bei der kanonischen Anfrage und beim Signieren der Zeichenfolge ](#signature-v4-troubleshooting-canonical-errors) + [ ## Fehler im Geltungsbereich der Anmeldeinformationen ](#signature-v4-troubleshooting-credential-scope) + [ ## Fehler bei der Schlüsselsignierung ](#signature-v4-troubleshooting-key-signing) ## Fehler bei den Anmeldeinformationen Stellen Sie sicher, dass die API-Anfrage mit SigV4 signiert ist. Wenn die API-Anfrage nicht signiert ist, erhalten Sie möglicherweise den folgenden Fehler: `Missing Authentication Token`. [Fügen Sie die fehlende Signatur](https://docs.aws.amazon.com/IAM/latest/UserGuide/create-signed-request.html#add-signature-to-request) hinzu und senden Sie die Anfrage erneut. Stellen Sie sicher, dass die Authentifizierungsdaten für den Zugriffsschlüssel und den geheimen Schlüssel korrekt sind. Wenn der Zugriffsschlüssel falsch ist, erhalten Sie möglicherweise die folgende Fehlermeldung: `Unauthorized`. Stellen Sie sicher, dass die zum Signieren der Anfrage verwendete Entität berechtigt ist, die Anfrage zu stellen. Details hierzu finden Sie unter [Beheben von Fehlermeldungen bei verweigertem Zugriff](troubleshoot_access-denied.md). ## Fehler bei der kanonischen Anfrage und beim Signieren der Zeichenfolge Wenn Sie die kanonische Anfrage in [Hash der kanonischen Anfrage erstellen](reference_sigv-create-signed-request.md#create-canonical-request-hash) oder [Erstellen einer zu signierenden Zeichenfolge](reference_sigv-create-signed-request.md#create-string-to-sign) falsch berechnet haben, schlägt der vom Service durchgeführte Signaturüberprüfungsschritt mit der Fehlermeldung fehl: ``` The request signature we calculated does not match the signature you provided ``` Wenn der AWS Dienst eine signierte Anfrage empfängt, berechnet er die Signatur neu. Wenn die Werte unterschiedlich sind, stimmen die Signaturen nicht überein. Vergleichen Sie die kanonische Anfrage und die Zeichenfolge mit Ihrer signierten Anfrage mit dem Wert in der Fehlermeldung. Ändern Sie den Signaturprozess, falls es Unterschiede gibt. **Anmerkung** Sie können auch überprüfen, ob Sie die Anfrage nicht über einen Proxy gesendet haben, der die Header oder die Anfrage ändert. **Example Beispiel für kanonische Anforderung** ``` GET -------- HTTP method / -------- Path. For API stage endpoint, it should be /{stage-name}/{resource-path} -------- Query string key-value pair. Leave it blank if the request doesn't have a query string. content-type:application/json -------- Header key-value pair. One header per line. host:0123456789.execute-api.us-east-1.amazonaws.com -------- Host and x-amz-date are required headers for all signed requests. x-amz-date:20220806T024003Z content-type;host;x-amz-date -------- A list of signed headers d167e99c53f15b0c105101d468ae35a3dc9187839ca081095e340f3649a04501 -------- Hash of the payload ``` Um zu überprüfen, ob der Geheimschlüssel mit der Zugriffsschlüssel-ID übereinstimmt, können Sie ihn mit einer bekannten funktionierenden Implementierung testen. Verwenden Sie beispielsweise ein AWS SDK oder die AWS CLI, um eine Anfrage zu stellen AWS. ### Header der API-Anfrage Wenn der Autorisierungsheader leer ist, der Anmeldeinformationsschlüssel oder die Signatur fehlt oder falsch ist, der Header nicht mit einem Algorithmusnamen beginnt oder die Schlüssel-Wert-Paare kein Gleichheitszeichen enthalten, wird einer der folgenden Fehler angezeigt: + Der Autorisierungs-Header darf nicht leer sein. + Der Autorisierungs-Header erfordert den Parameter „Credential“. + Der Autorisierungs-Header erfordert den Parameter „Signatur“. + Die Signatur enthält ein ungültiges Schlüssel-Wert-Paar (fehlendes Gleichheitszeichen) im Autorisierungs-Header. Stellen Sie sicher, dass der SigV4-Autorisierungsheader, den Sie in [Berechnen der Signatur](reference_sigv-create-signed-request.md#calculate-signature) hinzugefügt haben, den richtigen Anmeldeinformationsschlüssel sowie das Anforderungsdatum enthält, entweder mithilfe des HTTP-Datums oder des `x-amz-date`-Headers. Wenn Sie einen IncompleteSignatureException Fehler erhalten haben und die Konstruktion der Signatur korrekt ist, können Sie überprüfen, ob der Autorisierungsheader während der Übertragung nicht geändert wurde, AWS-Service indem Sie einen SHA-256-Hash und eine B64-Kodierung des Autorisierungsheaders in Ihrer clientseitigen Anfrage berechnen. 1. Rufen Sie den [Autorisierungs-Header](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv-authentication-methods.html) ab, den Sie in der Anfrage gesendet haben. Ihr Autorisierungs-Header sieht ähnlich wie das folgende Beispiel aus: ``` Authorization: AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request, SignedHeaders=host;range;x-amz-date, Signature=example-generated-signature ``` 1. Berechnen Sie einen SHA-256-Hash des Autorisierungs-Headers. ``` hashSHA256(rawAuthorizationHeader) = hashedAuthorizationHeader ``` 1. Codieren Sie den gehashten Autorisierungs-Header in das Base64-Format. ``` base64(hashedAuthorizationHeader) = encodedHashedAuthorizationHeader ``` 1. Vergleichen Sie die gehashte und codierte Zeichenfolge, die Sie gerade berechnet haben, mit der Zeichenfolge, die Sie in Ihrer Fehlermeldung erhalten haben. Ihre Fehlermeldung sollte dem folgenden Beispiel ähneln: ``` com.amazon.coral.service#IncompleteSignatureException: The signature contains an in-valid key=value pair (missing equal-sign) in Authorization header (hashed with SHA-256 and encoded with Base64): '9c574f83b4b950926da4a99c2b43418b3db8d97d571b5e18dd0e4f3c3ed1ed2c'. ``` + Wenn sich die beiden Hashes unterscheiden, hat sich ein Teil des Autorisierungs-Headers während der Übertragung geändert. Diese Änderung kann darauf zurückzuführen sein, dass Ihr Netzwerk oder Ihre Client-Handler signierte Header anfügen oder den Autorisierungs-Header auf irgendeine Weise ändern. + Wenn die beiden Hashes übereinstimmen, entspricht der Autorisierungsheader, den Sie in der Anfrage gesendet haben, dem, den Sie erhalten haben. AWS Überprüfen Sie die erhaltene Fehlermeldung, um festzustellen, ob das Problem auf falsche Anmeldeinformationen oder eine falsche Signatur zurückzuführen ist. Diese Fehler werden in den anderen Abschnitten auf dieser Seite behandelt. ## Fehler im Geltungsbereich der Anmeldeinformationen Der in [Erstellen einer zu signierenden Zeichenfolge](reference_sigv-create-signed-request.md#create-string-to-sign) erstellte Anmeldeinformationsbereich beschränkt eine Signatur auf ein bestimmtes Datum, eine bestimmte Region und einen bestimmten Service. Die Zeichenfolge hat das folgende Format: ``` YYYYMMDD/region/service/aws4_request ``` **Anmerkung** Wenn Sie SigV4a verwenden, ist die Region nicht im Gültigkeitsbereich der Anmeldeinformationen enthalten. **Date** Wenn der Geltungsbereich der Anmeldeinformationen nicht dasselbe Datum wie der x-amz-date-Header angibt, schlägt der Schritt zur Signaturüberprüfung mit der folgenden Fehlermeldung fehl: ``` Date in Credential scope does not match YYYYMMDD from ISO-8601 version of date from HTTP ``` Wenn die Anforderung einen Zeitpunkt in der Zukunft angibt, schlägt der Schritt zur Signaturüberprüfung mit der folgenden Fehlermeldung fehl: ``` Signature not yet current: date is still later than date ``` Wenn die Anfrage abgelaufen ist, schlägt der Schritt zur Signaturüberprüfung mit der folgenden Fehlermeldung fehl: ``` Signature expired: date is now earlier than date ``` **Region** Wenn der Geltungsbereich der Anmeldeinformationen nicht dieselbe Region wie die Anfrage angibt, schlägt der Schritt zur Signaturüberprüfung mit der folgenden Fehlermeldung fehl: ``` Credential should be scoped to a valid Region, not region-code ``` **Service** Wenn der Geltungsbereich der Anmeldeinformationen nicht denselben Service wie der host-Header angibt, schlägt der Schritt zur Signaturüberprüfung mit der folgenden Fehlermeldung fehl: ``` Credential should be scoped to correct service: 'service' ``` **Abschlusszeichenfolge** Wenn der Geltungsbereich der Anmeldeinformationen nicht mit aws4\$1request endet, schlägt der Schritt zur Signaturüberprüfung mit der folgenden Fehlermeldung fehl: ``` Credential should be scoped with a valid terminator: 'aws4_request' ``` ## Fehler bei der Schlüsselsignierung Fehler, die durch falsche Ableitung des Signaturschlüssels oder unsachgemäße Verwendung von Kryptografie verursacht werden, sind schwieriger zu beheben. Nachdem Sie überprüft haben, ob die kanonische Zeichenfolge und die zu signierende Zeichenfolge korrekt sind, können Sie auch überprüfen, ob eines der folgenden Probleme vorliegt: + Der geheime Zugriffsschlüssel stimmt nicht mit der Zugriffsschlüssel-ID überein, die Sie angegeben haben. + Es liegt ein Problem mit dem Code zur Schlüsselableitung vor. Um zu überprüfen, ob der Geheimschlüssel mit der Zugriffsschlüssel-ID übereinstimmt, können Sie ihn mit einer bekannten funktionierenden Implementierung testen. Verwenden Sie beispielsweise ein AWS SDK oder den, AWS CLI um eine Anfrage zu AWS stellen. Beispiele finden Sie unter [Anfordern von Signaturbeispielen](reference_sigv-examples.md)