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.
Überblick über Presigned 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 X-Amz-Expires Abfrageparameter. 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 Anfragen URLs sind eine Teilmenge der vorab signierten 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
-
Identitätsbasierte 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
-
Richtlinien zur Ressourcensteuerung, 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ösungsersteller dazu bewegt, vorsignierte Lösungen zu verwenden. URLs Wenn Sie wissen, was notwendig und was optional ist, können Sie besser mit Solution Buildern kommunizieren. Zu den Beweggründen könnten unter anderem 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. Abhängig von der Gesamtlast führt diese Anforderung zu zusätzlichen Skalierungsherausforderungen, die ein Solution Builder möglicherweise vermeiden möchte.
Andere Möglichkeiten 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 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 zu profitieren. URLs URLs werden von Browsern verstanden, AWS STS Anmeldeinformationen und Signature Version 4-Signaturen 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 es Grenzen gibt. AWS STS APIs (Weitere Informationen finden Sie im Artikel How can I resolve API Throttling or „Rate exceeded“ -Fehler für IAM und AWS STS
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 Lösungen 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 zur Ü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.
Bieten Sie andererseits weniger AWS SDKs 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 ausdrücklichen 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 die Lösungen jedoch so unterstützen, wie sie erstellt wurden.
