Transloadit

Was ist eine vorsignierte URL?

Eine vorsignierte URL erteilt eine zeitlich begrenzte Berechtigung für einen bestimmten Speichervorgang, etwa das Herunterladen oder Hochladen eines einzelnen Objekts, ohne dem Empfänger die geheimen Zugangsdaten der signierenden Partei offenzulegen. Ihre Signatur legt den Vorgang, das Objekt und den Ablaufzeitpunkt fest.

Das Anwendungs-Backend signiert eine einzelne Anfrage mit seinen Zugangsdaten für den Speicherdienst
Vorsignierte URL, die an den Client übergeben wird
Der Speicherdienst prüft Signatur und Ablaufzeitpunkt und liefert dann das Objekt aus oder nimmt es entgegen
Die Anwendung signiert die Anfrage; der Client kommuniziert anschließend direkt mit dem Speicherdienst.

So funktionieren vorsignierte URLs

Ein Dienst zum Vorsignieren berechnet mit den von ihm verwalteten Zugangsdaten eine Signatur über eine Speicheranfrage und fügt die daraus entstehenden Autorisierungsdaten in den Query-String der URL ein. Der Speicherdienst berechnet die Signatur erneut, wenn die URL verwendet wird, und prüft die Methode, das Objekt, die signierten Header und den Ablaufzeitpunkt. So muss das Geheimnis nie an den Browser oder den herunterladenden Client gelangen. Die Anfrage wird mit den Befugnissen der signierenden Identität ausgeführt: Laut Amazon S3 verwendet eine vorsignierte URL die Zugangsdaten des Prinzipals, der sie generiert hat, und ist durch dessen Berechtigungen beschränkt. Amazon S3 bezeichnet diese URLs als vorsignierte URLs, Google Cloud Storage als signierte URLs, und das Gegenstück in Azure Storage ist die Shared Access Signature (SAS). Die speicherspezifischen Angaben in diesem Eintrag stammen aus der Dokumentation dieser drei Dienste. Bei einem S3-kompatiblen Dienst eines anderen Anbieters lesen Sie dessen eigene Dokumentation. Eine signierte CDN-URL verwendet einen anderen Mechanismus: Das CDN prüft sie anhand der im CDN konfigurierten Schlüssel, ohne dass der Speicherdienst an dieser Prüfung beteiligt ist. In einer Auslieferungsarchitektur schafft eine vorsignierte URL einen direkten, zeitlich begrenzten Zugriffsweg zwischen einem Client und einem Objektspeicher, während die Anwendung entscheidet, wer eine solche URL erhält.

Wichtige Fakten

  1. Wer kann eine vorsignierte URL verwenden? Alle, die über die vollständige URL verfügen, solange sie gültig ist. AWS beschreibt vorsignierte URLs als Bearer-Tokens, und Google erklärt, dass alle, die eine signierte URL besitzen, diese während ihrer Gültigkeit mit oder ohne Konto verwenden können. Eine vorsignierte S3-URL kann bis zu ihrem Ablauf wiederholt verwendet werden. Eine Möglichkeit, den Zugriff früher zu beenden, besteht darin, die zur Signierung verwendeten Zugangsdaten oder Schlüssel ungültig zu machen. Dadurch werden alle damit signierten URLs ungültig: Eine S3-URL funktioniert nicht mehr, wenn die zum Signieren verwendeten Zugangsdaten widerrufen, gelöscht oder deaktiviert werden, und eine signierte Google-URL funktioniert nicht mehr, wenn der Signaturschlüssel rotiert wird. Weitere Kontrollmöglichkeiten hängen vom Dienst ab. Eine vorsignierte S3-URL ist durch die Berechtigungen der signierenden Identität beschränkt. AWS nennt eine Bucket-Richtlinie, die den Zugriff auf das Objekt explizit verweigert, als eine der Ursachen für eine Antwort mit dem Status 403 Forbidden auf eine vorsignierte URL. Eine solche Verweigerung unterbindet daher Anfragen im Geltungsbereich der Richtlinie, ohne die Zugangsdaten ungültig zu machen. Azure empfiehlt, eine Dienst-SAS mit einer gespeicherten Zugriffsrichtlinie zu verknüpfen, damit sie widerrufen werden kann, ohne die Kontoschlüssel neu zu generieren.
  2. Warum funktioniert eine vorsignierte URL schon vor ihrem angegebenen Ablaufzeitpunkt nicht mehr? Weil sie nur so lange gültig ist wie die Zugangsdaten, mit denen sie signiert wurde. Laut AWS läuft eine S3-URL, die mit temporären Zugangsdaten signiert wurde, etwa denen einer übernommenen Rolle oder einer Instanz- oder Containerrolle, zusammen mit diesen Zugangsdaten ab, selbst wenn ein späterer Ablaufzeitpunkt angefordert wurde. Anfragen schlagen dann mit ExpiredToken fehl. Prüfen Sie die Gültigkeitsdauer der zum Signieren verwendeten Zugangsdaten, bevor Sie eine Gültigkeitsdauer für einen Link zusagen: Bei AWS lässt sich die maximale Sitzungsdauer einer IAM-Rolle, die über die Konsole, CLI oder API übernommen wird, auf einen Wert zwischen 1 und 12 Stunden festlegen (1 Stunde, sofern kein Wert festgelegt wird). Zugangsdaten für Instanz- und Containerrollen sind laut AWS typischerweise bis zu etwa 6 Stunden gültig. Mit den Zugangsdaten eines IAM-Benutzers lässt sich dagegen mit Signature Version 4 eine S3-URL signieren, die bis zu 7 Tage gültig ist. Als Abhilfe nennt AWS, die Zugangsdaten zu erneuern und eine neue URL zu generieren oder gegebenenfalls mit länger gültigen Zugangsdaten zu signieren. S3 prüft den Ablaufzeitpunkt zu Beginn einer Anfrage: Ein Download, der vor diesem Zeitpunkt begonnen hat, wird fortgesetzt. Eine Anfrage, die danach neu gestartet wird, schlägt jedoch fehl.
  3. Warum schlägt eine noch nicht abgelaufene URL mit einem Signaturfehler fehl? Die Anfrage stimmt nicht mehr mit dem überein, was signiert wurde. Bei S3 müssen die HTTP-Methode, die signierten Header und der Query-String bei der Erstellung und der Verwendung der URL exakt übereinstimmen. Eine S3-URL, die mit Signature Version 4 signiert wurde, führt ihre signierten Header in X-Amz-SignedHeaders auf. AWS verlangt, dass der Header host und alle mit der Anfrage gesendeten Header x-amz-* darin enthalten sind. Als Ursachen für SignatureDoesNotMatch nennt AWS einen Inhaltstyp, der von dem beim Signieren angegebenen abweicht, sowie eine veränderte URL, die falsche Region, Uhrzeitabweichungen auf dem signierenden Rechner und Proxys, die Header oder Query-Strings verändern. Signierte Google-URLs nennen die Header, die eine Anfrage enthalten muss, in X-Goog-SignedHeaders.
  4. Warum funktioniert eine gültige vorsignierte URL in Browser-JavaScript nicht? Die Autorisierung beim Speicherdienst und CORS sind getrennte Prüfungen. Die CORS-Konfiguration des Buckets muss den Ursprung der Seite, die HTTP-Methode und die Anfrage-Header zulassen. Amazon S3 weist darauf hin, dass ACLs und Richtlinien weiterhin gelten, wenn CORS aktiviert ist. Lässt die Konfiguration eine Anfrage nicht zu, bricht der Browser nach einer fehlgeschlagenen Preflight-Anfrage ab, bevor er die eigentliche Anfrage sendet. Bei einer Anfrage, die keinen Preflight benötigt (was bei einer POST-Anfrage mit einem Formular-Inhaltstyp der Fall sein kann), sendet er sie hingegen, gibt die Antwort aber nicht an das Skript weiter. Ein CORS-Fehler allein belegt daher nicht, dass nichts hochgeladen wurde. Da CORS ursprungsübergreifende Anfragen beschränkt, die Skripte in einem Browser stellen, kann dieselbe URL bei einem serverseitigen Client funktionieren und auf einer Webseite fehlschlagen.
  5. Begrenzt eine vorsignierte Upload-URL, was hochgeladen wird? Nur im Umfang dessen, was signiert wurde. Eine vorsignierte S3-URL für einen Upload wird aus einem Bucket, einem Objektschlüssel, einer HTTP-Methode und einem Ablaufzeitpunkt erstellt. Beim Hochladen unter einem bereits vorhandenen Schlüssel wird das Objekt ersetzt. Azure warnt, dass ein Client mit Schreibzugriff einen sehr großen Blob hochladen kann (im Beispiel sind es 200 GB), und empfiehlt, Daten nach dem Schreiben und vor der Verwendung zu validieren. Wenn der Speicherdienst eine Größenbegrenzung durchsetzen muss, sind formularbasierte POST-Uploads das dokumentierte Mittel: Das signierte Richtliniendokument akzeptiert in Google Cloud Storage und Amazon S3 eine Bedingung namens content-length-range, und das AWS SDK für Python erstellt ein solches signiertes Formular mit generate_presigned_post. Die eigene Obergrenze des Speicherdienstes für eine einzelne Anfrage gilt weiterhin: Ein Upload über eine vorsignierte S3-URL ist ein PUT. Amazon S3 dokumentiert für einen einzelnen PUT maximal 5 GB; größere Objekte werden per Multipart-Upload in Teilen übertragen. Die Referenz zu POST Object von Amazon S3 nennt keine Größenobergrenze für einen einzelnen POST. Testen Sie daher einen formularbasierten Upload mit der größten erwarteten Datei, bevor Sie sich darauf verlassen.

Wann vorsignierte URLs wichtig sind

Stellen Sie eine solche URL für direkte Browser-Uploads oder private Downloads aus, wenn der Datenverkehr den Anwendungsserver umgehen soll. Eine zu lange Gültigkeit, zu weitreichende erlaubte Vorgänge oder die Offenlegung der URL können das referenzierte Objekt bis zum Ablauf zugänglich machen.

So hilft Transloadit bei vorsignierten URLs

Transloadit kann vorsignierte Download-URLs für Dateien zurückgeben, die es nach Amazon S3 exportiert. Wenn Sie den Parameter sign_urls_for beim Robot /s3/store setzen, werden dem Ergebnis signed_url und signed_ssl_url hinzugefügt. Der Parameterwert legt dabei die Gültigkeitsdauer in Sekunden fest. Die URLs werden mit den AWS-Zugangsdaten signiert, die Sie dem Robot bereitstellen. Die Dokumentation verlangt daher, dass die zugehörige Identität zusätzlich zur Schreibberechtigung für den Upload auch Leseberechtigung für die Objekte besitzt.

Eine von /s3/store zurückgegebene URL macht ein privates Objekt nicht öffentlich. Der Parameter acl des Robots hat jedoch den Standardwert public-read. Für einen privaten Bucket weist die Dokumentation an, acl auf bucket-default zu setzen, keine ACL- oder Grant-Header anzugeben und S3 Block Public Access aktiviert zu lassen. Temporäre AWS-Zugangsdaten werden vom Robot nicht erneuert. Laut AWS läuft eine vorsignierte URL mit den Zugangsdaten ab, mit denen sie signiert wurde. Vergleichen Sie daher deren Gültigkeitsdauer mit dem Wert von sign_urls_for. Signature Authentication von Transloadit und signierte URLs für Smart CDN sind separate Mechanismen, die Ihr Auth Secret von Transloadit verwenden, nicht Ihre Zugangsdaten für den Speicherdienst.

Entdecken Sie Transloadits Möglichkeiten zur Auslieferung

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline

Verbinden Sie Uploads, Verarbeitung, KI, Storage und Auslieferung über eine deklarative API – um Encoding-Stack, Skalierung und ständig wechselnde Formate müssen Sie sich nicht selbst kümmern.

Transloadit kostenlos ausprobieren