Was ist eine signierte URL?
Eine signierte URL enthält einen kryptografischen Nachweis, dass eine autorisierte Partei Zugriff auf eine Ressource oder Transformation gewährt hat. Ihre Signatur deckt üblicherweise einen Ablaufzeitpunkt sowie anfragespezifische Pfad- oder Abfrageparameter ab.
Wie signierte URLs funktionieren
Eine signierende Instanz, die einen Schlüssel besitzt, bildet eine Zeichenfolge aus den Teilen der Anfrage, die sie autorisieren möchte, typischerweise dem Pfad, ausgewählten Abfrageparametern und einem Ablaufzeitpunkt. Sie berechnet eine Signatur für diese Zeichenfolge und hängt sie an die URL an. Der Dienst verifiziert die Signatur und prüft den Ablaufzeitpunkt, bevor er etwas ausliefert. Zwei Schlüsselmodelle sind üblich. Bei einem HMAC besitzen die signierende Instanz und der Dienst dasselbe Geheimnis; so arbeiten Google Cloud CDN und Transloadits Smart CDN. Bei einem Schlüsselpaar behält die signierende Instanz einen privaten Schlüssel, während der Dienst nur den öffentlichen Schlüssel benötigt; Amazon CloudFront verifiziert RSA- oder ECDSA-Signaturen anhand öffentlicher Schlüssel in einer vertrauenswürdigen Schlüsselgruppe. In beiden Fällen handelt es sich um delegierte Autorisierung, nicht um Verschlüsselung. AWS beschreibt vorsignierte URLs als Bearer-Tokens, und Google weist darauf hin, dass jeder, der eine signierte URL besitzt, sie während ihrer Gültigkeitsdauer verwenden kann. Eine vorsignierte URL ist der Anwendungsfall für Objektspeicher: Amazon S3 bezeichnet damit eine URL, die Zugangsdaten der erstellenden Instanz für einen Bucket, einen Objektschlüssel und eine HTTP-Methode enthält, etwa für einen Download mit GET oder einen Upload mit PUT. Google Cloud Storage nennt das entsprechende Konzept eine signierte URL.
Wichtige Fakten
- Kann ein Abfrageparameter nach dem Signieren hinzugefügt oder geändert werden? Nur wenn das Verfahren ihn von der Signatur ausnimmt oder die signierte Richtlinie es erlaubt. CloudFront gibt HTTP 403 zurück, wenn nach dem Signieren eine Abfragezeichenfolge an eine signierte URL angehängt wird. Eine benutzerdefinierte CloudFront-Richtlinie kann dies erweitern: Ihre URL für
Resourcedarf Platzhalter enthalten. CloudFront gleicht die angeforderte URL mit diesem Muster ab, und ein Sternchen am Ende des Pfads erfasst auch die Abfragezeichenfolge. imgix gibt 403 zurück, wenn sich der Pfad oder die Parameter ändern, nachdem der Parametersgesetzt wurde. Bei Verfahren, die eine kanonische Anfrage signieren, kommt es auch darauf an, wie die Anfrage gestellt wird: Signaturen von S3 und Google Cloud Storage V4 erfassen die HTTP-Methode, den Pfad, die sortierte Abfragezeichenfolge und den Headerhost. Eine URL, die für eine bestimmte Methode oder einen bestimmten Hostnamen signiert wurde, ist daher für eine andere Methode oder einen anderen Hostnamen ungültig. Google Cloud CDN bildet eine bewusste Ausnahme, wenn Sie statt der vollständigen URLURLPrefixsignieren: Abfrageparameter werden dann nicht signiert und können frei hinzugefügt werden. Eine Signatur gilt für jede URL, die mit dem Präfix beginnt. - Warum funktioniert eine vorsignierte URL möglicherweise schon vor dem festgelegten Ablaufzeitpunkt nicht mehr? Meist, weil die zugrunde liegenden Zugangsdaten vorher abgelaufen sind. Laut AWS läuft eine vorsignierte S3-URL zum konfigurierten Zeitpunkt oder beim Ablauf der Zugangsdaten ab, mit denen sie erstellt wurde, je nachdem, was zuerst eintritt. Die Gültigkeit einer URL, die mit temporären Rollenzugangsdaten signiert wurde, endet daher mit der Rollensitzung, selbst wenn eine längere Gültigkeitsdauer angefordert wurde. Signierte URLs von Google Cloud Storage funktionieren ebenfalls nicht mehr, wenn der zum Signieren verwendete Schlüssel rotiert wird. Als weitere Ursachen für nicht übereinstimmende Signaturen nennt AWS eine abweichende Systemzeit auf dem signierenden Rechner und Proxys, die Header oder Abfragezeichenfolgen verändern. Signieren Sie mit Zugangsdaten, die länger gültig sind als die URL, oder stellen Sie URLs aus, deren Gültigkeitsdauer kürzer als die Sitzungsdauer ist.
- Was passiert mit einem Download oder einer Wiedergabe, die beim Ablauf noch läuft? Der Ablaufzeitpunkt wird beim Eingang jeder HTTP-Anfrage geprüft, nicht während des Sendens einer Antwort. Sowohl S3 als auch CloudFront dokumentieren, dass ein kurz vor Ablauf gestarteter Download weiterläuft und dass der erneute Verbindungsaufbau eines Clients nach Ablauf fehlschlägt. Bei CloudFront schlägt auch jede Range-GET-Anfrage fehl, die nach Ablauf gestellt wird. Ein Player, der eine große Datei in Bereichen abruft, oder ein Downloadmanager, der Downloads fortsetzt, benötigt daher eine Gültigkeitsdauer, die die gesamte Sitzung abdeckt, oder eine Möglichkeit, eine neue URL zu erhalten.
- Schützt die Pflicht zu signierten URLs am CDN den Origin-Server, und werden signierte Antworten weiterhin gecacht? Das CDN prüft die Signatur; der Origin-Server ist ein separater Zugangspunkt. AWS empfiehlt, einen S3-Bucket so einzuschränken, dass er nur über CloudFront gelesen werden kann, schreibt dies aber nicht vor. Google warnt, dass Cloud CDN Anfragen ohne Signatur nicht blockiert. Der dahinterliegende Origin-Server in Cloud Storage darf daher nicht öffentlich zugänglich sein. Beim Caching entfernen CloudFront und Google Cloud CDN die Signaturparameter, bevor sie eine Anfrage an den Origin-Server weiterleiten. Google validiert zuerst die Signatur und liefert dann aus dem Cache aus, wobei Antworten auf signierte und unsignierte Anfragen getrennt gespeichert werden. Diese Trennung entfernt keine Inhalte, die während ihrer öffentlichen Zugänglichkeit gecacht wurden: Bei einem Cache-Treffer bedient Cloud CDN eine unsignierte Anfrage aus dem Cache. Nachdem Sie den öffentlichen Zugriff auf den Origin-Server gesperrt haben, invalidieren Sie daher die zuvor gecachten Antworten oder warten Sie, bis sie ablaufen. Manche Dienste koppeln die Cache-Gültigkeitsdauer an den Ablaufzeitpunkt: imgix ersetzt
Cache-Controldurch die verbleibende Zeit bisexpires.
Wann signierte URLs wichtig sind
Verwenden Sie signierte URLs, um einem Browser, Player oder Partner zeitlich begrenzten Zugriff auf private Medien zu geben, ohne Zugangsdaten für den Speicher weiterzugeben oder den Origin-Server öffentlich zugänglich zu machen. Eine signierte URL gewährt allen Zugriff, die sie besitzen, und ist nicht an eine bestimmte Person gebunden. Wählen Sie deshalb eine Gültigkeitsdauer, die Sie auch bei einem weitergeleiteten Link akzeptieren würden, und ergänzen Sie eine zusätzliche Prüfung, wenn der Zugriff an eine Person gebunden bleiben muss.
Wie Transloadit bei signierten URLs hilft
Transloadits Smart CDN akzeptiert signierte URLs. Ihr Backend fügt einen Zeitstempel exp in Millisekunden und auth_key hinzu, sortiert die Abfrageparameter, berechnet mit dem Auth Secret einen HMAC-SHA256 über den Workspace, den Template-Namen, den Dateipfad und die sortierten Parameter und hängt das Ergebnis als sig an. Da die Transformationsparameter Teil der signierten Zeichenfolge sind, lässt sich eine signierte URL nicht so ändern, dass sie eine andere Variante anfordert. Der Ablaufzeitpunkt begrenzt auch, wie lange eine signierte Antwort gecacht werden darf. Ein kürzerer Wert für exp schränkt daher den Zugriff stärker ein und verringert die Wiederverwendung des Caches. Für Dateien, die in Ihren eigenen Bucket exportiert werden, kann der Robot /s3/store über seinen Parameter sign_urls_for signierte URLs zurückgeben.
Der Auth Key, der zum Signieren verwendet wird, muss für die Nutzung von Smart CDN aktiviert sein. Die Signierung muss in Ihrem Backend erfolgen, da sie das Auth Secret benötigt. Die Dokumentation kennzeichnet exp als optional und empfiehlt, den Parameter immer zu setzen. Die verlinkten Seiten beschreiben, wie eine URL signiert wird. Sie erläutern jedoch weder, wie eine unsignierte Anfrage an dasselbe Template behandelt wird, noch, ob eine Bereichsanfrage abgelehnt wird, die nach exp eingeht. Testen Sie daher beides in Ihrem eigenen Workspace, bevor Sie die Signierung als Zugriffskontrolle ansehen oder eine Gültigkeitsdauer wählen, die kürzer als eine Wiedergabesitzung ist.
Quellen
- Amazon S3: Objekte mit vorsignierten URLs herunterladen und hochladen (Ablauf, Zugangsdaten, häufige Fragen)
- AWS Signature Version 4: Bestandteile kanonischer Anfragen
- Amazon CloudFront: signierte URLs verwenden (Verifizierungsschritte und Ablaufprüfungen)
- Amazon CloudFront: eine signierte URL mit einer benutzerdefinierten Richtlinie erstellen (Platzhalter in Resource)
- Amazon CloudFront: Zugriff auf Dateien in Caches und auf Ursprungsservern beschränken
- Amazon CloudFront: bei signierten URLs entfernte Abfrageparameter
- Google Cloud CDN: signierte URLs verwenden (Schlüssel, URL-Präfixe, Validierung am Ursprungsserver)
- Google Cloud CDN: Übersicht zur Cache-Invalidierung
- Google Cloud Storage: Übersicht zu signierten URLs
- Google Cloud Storage: kanonische Anfragen für V4-Signaturen
- imgix: Assets mit signierten URLs und Ablaufzeiten absichern