Übersicht über vorsignierte URLs

Eine vorsignierte URL ist eine Art von HTTP-Anfrage, die vom AWS Identity and Access Management (IAM -) Dienst erkannt wird. Was diese Art von Anfrage von allen anderen AWS Anfragen unterscheidet, ist der Abfrageparameter X-Amz-Expires. Wie bei anderen authentifizierten Anfragen enthalten vorsignierte URL-Anfragen eine Signatur. Bei vorsignierten URL-Anfragen wird diese Signatur übertragen. X-Amz-Signature Die Signatur verwendet kryptografische Operationen von Signature Version 4, um alle anderen Anforderungsparameter zu codieren.

Hinweise

• Signature Version 2 wird derzeit als veraltet eingestuft, wird aber in einigen Fällen immer noch unterstützt. AWS-Regionen Dieses Handbuch bezieht sich auf das Signieren mit Signature Version 4.

• Der empfangende Dienst könnte unsignierte Header verarbeiten, aber die Unterstützung für diese Option ist begrenzt und entspricht den bewährten Methoden. Sofern nicht anders angegeben, gehen Sie davon aus, dass alle Header signiert sein müssen, damit eine Anfrage akzeptiert wird.

Der X-Amz-Expires Parameter ermöglicht die Verarbeitung einer Signatur als gültig mit einer größeren Abweichung von der codierten Datums- und Uhrzeitangabe. Andere Aspekte der Signaturgültigkeit werden noch bewertet. Die Signaturdaten dürfen, sofern sie temporär sind, zum Zeitpunkt der Signaturverarbeitung nicht abgelaufen sein. Die Signieranmeldedaten müssen einem IAM-Prinzipal zugeordnet werden, der zum Zeitpunkt der Verarbeitung über ausreichende Autorisierungen verfügt.

Vorsignierte URLs sind eine Teilmenge der vorsignierten Anfragen

Eine vorsignierte URL ist nicht die einzige Methode, um eine Anfrage für einen future Zeitpunkt zu signieren. Amazon S3 unterstützt auch POST-Anfragen, die üblicherweise ebenfalls vorsigniert sind. Eine vorsignierte POST-Signatur ermöglicht Uploads, die einer signierten Richtlinie entsprechen und deren Ablaufdatum in dieser Richtlinie verankert ist.

Unterschriften für Anfragen können in der future datiert werden, obwohl dies ungewöhnlich ist. Solange die zugrunde liegenden Anmeldeinformationen gültig sind, verbietet der Signaturalgorithmus zukünftige Datierungen nicht. Diese Anfragen können jedoch erst nach ihrem gültigen Zeitfenster erfolgreich bearbeitet werden, was eine future Datierung für die meisten Anwendungsfälle unpraktisch macht.

Was ermöglicht eine vorab signierte Anfrage?

Eine vorsignierte Anfrage kann nur Aktionen zulassen, die aufgrund der Anmeldeinformationen zulässig sind, die zum Signieren der Anfrage verwendet wurden. Wenn die Anmeldeinformationen die in der vorsignierten Anfrage angegebene Aktion implizit oder explizit verweigern, wird die vorsignierte Anfrage beim Senden verweigert. Dies gilt für Folgendes:

• Sitzungsrichtlinien, die mit den Anmeldeinformationen verknüpft sind

• Richtlinien, die dem Prinzipal zugeordnet sind, dem die Anmeldeinformationen zugeordnet sind

• Ressourcenrichtlinien, die sich auf die Sitzung oder den Prinzipal auswirken

• Richtlinien zur Dienststeuerung, die sich auf die Sitzung oder den Prinzipal auswirken

Beweggründe für die Verwendung von vorab signierten Anfragen

Als Sicherheitsingenieur sollten Sie sich darüber im Klaren sein, was Lösungsentwickler dazu bewegt, vorsignierte URLs zu verwenden. Wenn Sie wissen, was notwendig und was optional ist, können Sie besser mit Lösungsentwicklern kommunizieren. Zu den Beweggründen könnten die folgenden gehören:

• Um einen Nicht-IAM-Authentifizierungsmechanismus zu unterstützen und gleichzeitig von der Skalierbarkeit in Amazon S3 zu profitieren. Eine zentrale Motivation besteht darin, direkt mit Amazon S3 zu kommunizieren, um von der integrierten Skalierbarkeit zu profitieren, die dieser Service bietet. Ohne diese direkte Kommunikation müsste eine Lösung die Last aus der erneuten Übertragung von eingehenden Bytes PutObjectund GetObjectAufrufen unterstützen. Je nach Gesamtlast führt diese Anforderung zu zusätzlichen Skalierungsherausforderungen, die ein Solution Builder möglicherweise vermeiden möchte.

  Andere Methoden der direkten Kommunikation mit Amazon S3, wie z. B. die Verwendung temporärer Anmeldeinformationen in AWS Security Token Service (AWS STS) oder Signature Version 4-Signaturen außerhalb von URLs, sind für Ihren Anwendungsfall möglicherweise nicht geeignet. Amazon S3 identifiziert Benutzer anhand von AWS Anmeldeinformationen, wohingegen vorab signierte Anfragen die Identifizierung durch andere Mechanismen als Anmeldeinformationen voraussetzen. AWS Durch vorab signierte Anfragen ist es möglich, diesen Unterschied zu überbrücken und gleichzeitig die direkte Kommunikation für Daten aufrechtzuerhalten.

• Um vom systemeigenen Verständnis eines Browsers für URLs zu profitieren. URLs werden von Browsern verstanden, AWS STS Anmeldeinformationen und Signaturen der Version 4 dagegen nicht. Dies ist bei der Integration mit browserbasierten Lösungen von Vorteil. Alternative Lösungen erfordern mehr Code, benötigen mehr Speicher für große Dateien und werden möglicherweise von Erweiterungen wie Malware- und Virenscannern anders behandelt.

Vergleich mit temporären AWS STS Anmeldeinformationen

Temporäre Anmeldeinformationen ähneln vorsignierten Anfragen. Beide laufen ab, ermöglichen die Festlegung des Zugriffs und werden häufig verwendet, um Nicht-IAM-Anmeldeinformationen mit einer Nutzung zu verbinden, für die AWS-Anmeldeinformationen erforderlich sind. 

Sie können temporäre AWS STS Anmeldeinformationen eng auf ein einzelnes S3-Objekt und eine einzelne Aktion beschränken. Dies kann jedoch zu Skalierungsproblemen führen, da APIs Grenzen haben. AWS STS (Weitere Informationen finden Sie im Artikel How can I resolve API Throttling or „Rate exceeded“ -Fehler für IAM und AWS STS auf der AWS re:POST-Website.) Darüber hinaus erfordert jeder generierte Berechtigungsnachweis einen AWS STS API-Aufruf, was die Latenz und eine neue Abhängigkeit erhöht, die sich auf die Ausfallsicherheit auswirken kann. Temporäre AWS STS Anmeldeinformationen haben außerdem eine Mindestablaufzeit von 15 Minuten, wohingegen eine vorab signierte Anfrage kürzere Zeiträume unterstützen kann. (60 Sekunden sind unter den richtigen Bedingungen praktisch.)

Vergleich mit reinen Signaturlösungen

Die einzige inhärent geheime Komponente einer vorab signierten Anfrage ist ihre Signature Version 4-Signatur. Wenn ein Client die anderen Details einer Anfrage kennt und über eine gültige Signatur verfügt, die diesen Angaben entspricht, kann er eine gültige Anfrage senden. Ohne eine gültige Signatur ist dies nicht möglich.

Vorsignierte URLs und reine Signaturlösungen sind sich kryptografisch ähnlich. Reine Signaturlösungen bieten jedoch praktische Vorteile, z. B. die Möglichkeit, einen HTTP-Header anstelle eines Abfragezeichenfolgenparameters für die Übertragung der Signatur zu verwenden (siehe Abschnitt Protokollierung von Interaktionen und Abhilfemaßnahmen). Administratoren sollten auch berücksichtigen, dass Abfragezeichenfolgen häufiger als Metadaten behandelt werden, während Header seltener als solche behandelt werden.

Andererseits bieten AWS SDKs weniger Unterstützung für die direkte Generierung und Verwendung von Signaturen. Für die Erstellung einer reinen Signaturlösung ist mehr benutzerdefinierter Code erforderlich. Aus praktischer Sicht ist die Verwendung von Bibliotheken anstelle von benutzerdefiniertem Code aus Sicherheitsgründen eine allgemein bewährte Methode. Daher muss der Code für reine Signaturlösungen genauer geprüft werden.

Reine Signaturlösungen verwenden die X-Amz-Expires Abfragezeichenfolge nicht und geben keinen ausdrücklichen Gültigkeitszeitraum an. IAM verwaltet die impliziten Gültigkeitszeiträume von Signaturen, die keine explizite Ablaufzeit haben. Diese impliziten Zeiträume werden nicht veröffentlicht. Sie ändern sich normalerweise nicht, aber sie werden unter Berücksichtigung der Sicherheit verwaltet, sodass Sie sich nicht von den Gültigkeitszeiträumen abhängig machen sollten. Es gibt einen Kompromiss zwischen der expliziten Kontrolle über das Ablaufdatum und der Verwaltung des Ablaufdatums durch IAM.

Als Administrator bevorzugen Sie möglicherweise eine reine Signaturlösung. In der Praxis müssen Sie jedoch Lösungen so unterstützen, wie sie erstellt wurden.