Signierte URLs und signierte Cookies

Mit signierten URLs und signierten Cookies von Cloud CDN können Sie Antworten aus den global verteilten Caches von Google Cloud bereitstellen, selbst wenn Anfragen autorisiert werden müssen.

Mit signierten URLs und signierten Cookies von Cloud CDN erreichen Sie ähnliche Ziele: Mit beidem lässt sich der Zugriff auf Ihre im Cache gespeicherten Inhalte steuern. Wenn Sie Inhalte aus den global verteilten Caches von Google Cloud bereitstellen möchten und sich zwischen signierten URLs und signierten Cookies entscheiden müssen, ziehen Sie den folgenden Vergleich von Anwendungsfällen in Betracht.

Signierte URLs

Eine signierte URL beschränkt die Berechtigung und die Zeit zum Senden einer Anfrage.

Anwendungsfälle

In manchen Szenarien möchten Sie möglicherweise nicht, dass Ihre Nutzer für den Zugriff auf Cloud CDN-Inhalte ein Google-Konto benötigen, möchten aber dennoch mithilfe Ihrer anwendungsspezifischen Logik den Zugriff steuern.

Üblicherweise wird dem Nutzer dafür eine signierte URL zur Verfügung gestellt, über die er innerhalb eines begrenzten Zeitraums Lesezugriff auf die entsprechende Ressource erhält. Beim Erstellen der signierten URL geben Sie eine Ablaufzeit an. Jeder, der die URL kennt, kann auf die Ressource zugreifen, bis die Ablaufzeit für die URL erreicht oder der Schlüssel zum Signieren der URL rotiert wurde.

Verwenden Sie signierte URLs in folgenden Fällen:

  • Sie müssen den Zugriff auf einzelne Dateien einschränken, z. B. auf eine herunterladbare Installationsdatei.

  • Ihre Nutzer verwenden Clientanwendungen, die keine Cookies unterstützen.

So funktionieren signierte URLs

Signierte URLs gewähren einem Client vorübergehend Zugriff auf eine private Ressource, ohne dass eine zusätzliche Autorisierung erforderlich ist. Dazu werden ausgewählte Elemente einer Anfrage mit einem stark zufälligen Schlüssel, den Sie generieren, gehasht und kryptografisch signiert.

Wenn bei einer Anfrage die von Ihnen angegebene signierte URL verwendet wird, gilt die Anfrage als autorisiert, den angeforderten Inhalt zu erhalten. Wenn Cloud CDN für einen aktivierten Dienst eine Anfrage mit einer fehlerhaften Signatur empfängt, wird die Anfrage abgelehnt und nicht zur Verarbeitung an Ihr Back-End geleitet.

Im Allgemeinen kann eine signierte URL von jedem genutzt werden, der sie kennt. Normalerweise ist eine signierte URL aber nur für die Verwendung durch den Client gedacht, dem die URL mitgeteilt wurde. Signierte URLs laufen zu einem von Ihnen gewählten Zeitpunkt ab, um das Risiko zu verringern, dass die URL von einem anderen Client verwendet wird. Um das Risiko der Weitergabe einer signierten URL zu minimieren, sollten Sie sie so bald wie möglich ablaufen lassen.

So werden URLs signiert

Bevor Sie URLs signieren können, müssen Sie einen oder mehrere kryptografische Schlüssel in einem Back-End-Dienst, einem Back-End-Bucket oder beidem erstellen. Anschließend signieren Sie eine URL und hashen sie kryptografisch mit der Google Cloud CLI oder Ihrem eigenen Code.

Umgang mit signierten URLs

Wenn die Verarbeitung signierter URLs für ein Back-End aktiviert ist, verarbeitet Cloud CDN Anfragen mit signierten URLs auf spezielle Weise. Insbesondere Anfragen mit einem Signature-Abfrageparameter gelten als signiert. Wenn eine solche Anfrage empfangen wird, überprüft Cloud CDN Folgendes:

  1. Die HTTP-Methode istGET, HEAD, OPTIONS, oder TRACE.
  2. Der Parameter Expires ist auf eine zukünftige Zeit eingestellt.
  3. Die Signatur der Anfrage stimmt mit der Signatur überein, die mithilfe des benannten Schlüssels berechnet wurde.

Wenn eine dieser Prüfungen fehlschlägt, wird eine 403 Forbidden-Antwort zurückgegeben. Sind sie erfüllt, so wird die Anfrage entweder an das Back-End weitergeleitet oder aus dem Cache beantwortet. (OPTIONS- und TRACE-Anfragen werden immer direkt an das Back-End weitergeleitet und nicht aus dem Cache beantwortet.) Für alle gültigen signierten Anfragen für eine bestimmte Basis-URL (der Teil vor dem Parameter Expires) wird derselbe Cache-Eintrag genutzt. Bei Antworten auf signierte und nicht signierte Anfragen werden nicht die gleichen Cache-Einträge verwendet. Antworten werden im Cache gespeichert und bis zu dem von Ihnen festgelegten Ablaufzeitpunkt bereitgestellt.

Inhalte, für die signierte Anfragen erforderlich sind, werden oft mithilfe des Cache-Control-Headers als nicht im Cache speicherbar gekennzeichnet. Um solche Objekte mit Cloud CDN kompatibel zu machen, ohne dass Änderungen am Back-End nötig sind, überschreibt Cloud CDN den Cache-Control-Header, wenn auf Anfragen mit gültigen signierten URLs geantwortet wird. Cloud CDN behandelt den Inhalt als im Cache speicherbar und verwendet den in Ihrer Cloud CDN-Konfiguration festgelegten Parameter max-age. Die bereitgestellte Antwort enthält weiterhin die Cache-Control-Header, die vom Back-End generiert wurden.

Die von der Google Cloud CLI zurückgegebene oder von Ihrem benutzerdefinierten Code erstellte URL kann Ihren Anforderungen entsprechend verteilt werden. Wir empfehlen, nur HTTPS-URLs zu signieren, da HTTPS für eine sichere Übertragung sorgt und dadurch verhindert, dass die Signaturkomponente der signierten URL abgefangen wird. Ebenso sollten Sie die signierten URLs über sichere Transportprotokolle wie TLS oder HTTPS verteilen.

Signierte Cookies

Ein signiertes Cookie beschränkt die Berechtigung und die Zeit zum Senden von Anfragen für eine Gruppe von Dateien.

Anwendungsfälle

Verwenden Sie signierte Cookies in folgenden Fällen:

  • Sie müssen Zugriff auf mehrere Dateien mit eingeschränktem Zugriff gewähren.

  • Sie möchten es vermeiden, Ihre aktuellen URLs zu ändern.

  • Sie möchten es vermeiden, URLs jedes Mal zu aktualisieren, wenn Sie die Autorisierung für den Zugriff auf Inhalte aktualisieren.

Medien mit HLS und DASH streamen

Wenn Sie Video- und Audioinhalte mithilfe des HLS-Protokolls (HTTP Live Streaming) oder des DASH-Protokolls (Dynamic Adaptive Streaming over HTTP) bereitstellen, generieren Sie in der Regel ein Manifest, das eine Liste von URLs für Video- und Audiosegmente enthält. Sie haben möglicherweise mehrere Instanzen jedes Segments, um für einen Client unterschiedliche Codierungen (Codec, Bitrate, Auflösung) bereitzustellen.

Obwohl Sie die signierten URLs von Cloud CDN verwenden können, um den Zugriff auf jede dieser URLs zu signieren und zu autorisieren, ist das dynamische Generieren aller möglichen Kombinationen pro Nutzer aufwendig und erhöht die Ursprungslast und die Anwendungskomplexität.

Signierte Cookies wurden entwickelt, um dieses Problem zu vermeiden. Sie können für den Nutzer ein signiertes Cookie bereitstellen, das ihn autorisiert, auf alle Inhalte zuzugreifen, die mit einer Richtlinie übereinstimmen (URL-Präfix und Ablaufdatum), ohne dass Sie Ihre Medienmanifeste einzeln generieren oder signieren müssen. Sie können den Nutzerzugriff bei der Seitennavigation oder bei anderen Hintergrundmechanismen in nativen Anwendungen regelmäßig über die fetch() API von JavaScript aktualisieren. Durch die Möglichkeit, den Nutzerzugriff zu aktualisieren, können Sie auch kurze Ablaufzeiten verwenden, was Nutzern das Teilen geschützter Inhalte erschwert.

Sie können diese Cookies für Nutzer mit mehreren Browserclients und anderen mit HTTP kompatiblen Clients wie ExoPlayer von Google und AVPlayer von iOS ausstellen.

Binäre Downloads (Spiele)

Ähnlich wie beim Streaming von Medien können Sie, wenn Sie Downloads von Spieleclients anbieten, mehrere Gigabyte umfassende Patches oder Spieldaten aufteilen, um Caching, Entwertung und Gleichzeitigkeit mit größerer Detailgenauigkeit zu ermöglichen.

Die entsprechenden Teile werden dann normalerweise in einem Manifest aufgelistet. Mit signierten Cookies können Sie den Zugriff auf diese Downloads auf authentifizierte Nutzer beschränken, ohne Änderungen am Manifest vornehmen zu müssen oder (wie bei signierten URLs) auf die Vorteile des Cloud CDN-Cachings zu verzichten.

So funktionieren signierte Cookies

Das Konfigurieren und Ausstellen signierter Cookies umfasst drei Schritte:

  • Signierschlüssel für den angegebenen Back-End-Dienst erstellen
  • Cookiewert mit zulässigem URL-Präfix, Ablaufdatum, Schlüsselnamen und kryptografischer Signatur erstellen
  • Cookie im Anwendungscode ausstellen

Cloud CDN überprüft diese signierten Cookies, wenn sie in Anfragen enthalten sind.

Sie können verhindern, dass Nutzer Ihre auf signierten Cookies basierende Zugriffskontrolle umgehen, wenn Sie einen Cloud Storage-Bucket verwenden. Beschränken Sie dazu den Zugriff auf den zugrunde liegenden Bucket, indem Sie die Rolle allUsers entfernen und dem Cloud CDN-Dienstkonto Lesezugriff auf den Bucket gewähren.

Ebenso sollten Ihre VM-Instanzen die Signaturen bei jeder signierten Anfrage validieren, die sie bedienen.

Einschränkungen

  • Sie allein sind für die Einwilligung und die Einhaltung der Datenschutzbestimmungen verantwortlich, soweit das für Ihre signierten Cookies erforderlich ist. Signierte Cookies werden von Ihnen ausgestellt und verwaltet, nicht von Google.

  • Wenn Sie sowohl signierte URLs als auch signierte Cookies verwenden, um den Zugriff auf dieselben Dateien zu steuern, und ein Nutzer mit einer signierten URL Lesezugriff auf eine Datei anfordert, entscheidet Cloud CDN allein anhand der signierten URL, ob die Datei zurückgegeben wird. Cloud CDN berücksichtigt signierte Cookies nur, wenn die URL nicht signiert ist.

  • Wenn Sie Ihren Dienst für signierte Anfragen konfiguriert haben und Ihre URL Signature als Abfrageparameter enthält, versucht Cloud CDN, Ihre URL als signierte URL zu interpretieren. Wenn Cloud CDN versucht, Ihre URL als signierte URL zu behandeln, obwohl Sie das nicht beabsichtigt haben, ist Ihre URL wahrscheinlich keine gültige signierte URL, und Cloud CDN lehnt sie ab.

  • Browser und andere Clients erzwingen gemäß RFC 6265 normalerweise Limits für die Cookiegröße (4 KB pro Cookie) und die Gesamtzahl der Cookies (50 pro Domain). Berücksichtigen Sie die Gesamtnutzlast der von ihrer Domain gesendeten Cookies.

  • Es gelten Cloud CDN-Limits und -Einschränkungen, einschließlich eines Maximums von drei signierten Anfrageschlüsseln pro Back-End.

  • Signierte Anfragen werden nicht anders in Rechnung gestellt als vorhandene Cloud CDN-Anfragen. Für fehlgeschlagene (abgelehnte) Anfragen, z. B. mit abgelaufenen oder anderweitig ungültigen Signaturen, fallen jedoch weiterhin Gebühren für die Cache-Suche an.

Nächste Schritte