Nicht autorisierte Verteilung verhindern

Auf dieser Seite werden die Optionen beschrieben, die Media CDN bietet, um eine nicht autorisierte Verteilung Ihrer Inhalte zu verhindern.

Media CDN bietet die folgenden Optionen, um Ihre Inhalte vor unbefugter Verteilung zu schützen.

  • Tokens (empfohlen): Media CDN verwendet Tokens zum Schutz von Inhalten.

    Ein Token ist ein Medium zum Austausch signierter Anfragen, z. B. ein signiertes Cookie, ein URI mit Abfrageparametern oder eine Pfadkomponente. Von Nutzern bereitgestellte gültige Tokens werden verwendet, um den Zugriff auf Ihre Inhalte zu authentifizieren. Ein Nutzer mit einem ungültigen oder fehlenden Token kann nicht auf deine Inhalte zugreifen.

    Sie können sich für die Authentifizierung mit einem oder mehreren Tokens entscheiden. Für die Dual-Token-Authentifizierung werden Token benötigt.

    Bei der Dual-Token-Authentifizierung verwendet Media CDN zwei Token, ein Kurzzeit- und ein Langzeit-Token.

    Google empfiehlt Tokens für neue Integrationen, da sie folgende Vorteile bieten:

    • Kompatibilität mit Content Delivery Networks (CDNs) von Drittanbietern
    • Nur-Pfad-Signatur unterstützen
    • Aktivieren Sie die Signatur mehrerer Header.
    • Detaillierte Zugriffssteuerung und Widerruf anbieten.
    • Minimieren Sie die Auswirkungen von manipulierten Tokens.
    • Es können beliebige Daten und Sitzungs-IDs eingebettet werden.

  • Signaturen: Media CDN verwendet eine einzelne Signatur zum Schutz von Inhalten. Mithilfe von Signaturen können Sie vollständige URLs signieren, einschließlich Host und Protokoll.

Sie können beide Optionen gleichzeitig verwenden, um Ihre Inhalte zu schützen.

So funktioniert Dual-Token-Authentifizierung

Bei der Dual-Token-Authentifizierung werden zwei Token zur Authentifizierung von Anforderungen an Ihre Inhalte verwendet: ein Kurzzeit-Token für den Beginn der Wiedergabe und ein Langzeit-Token für den Rest der Wiedergabesitzung.

Für die Verwendung der Dual-Token-Authentifizierung konfigurieren Sie Ihren Anwendungsserver so, dass Tokens mit kurzer Dauer für User-Agents ausgestellt werden. Anschließend konfigurieren Sie Media CDN so, dass es auf die Kurzzeit-Tokens reagiert. Sie können das Token in einem Abfrageparameter Ihrer Wahl oder in einem Cookie platzieren. Weitere Informationen finden Sie unter Dual-Token-Authentifizierung verwenden.

Von Ihrem Anwendungsserver generierte Kurzzeit-Tokens helfen, primäre Manifeste (manchmal auch multivariate Playlists genannt) zu schützen. Der Ablauf der signierten Anfrage ist kurz genug, um ein primäres Manifest anzufordern, aber nicht den gesamten Inhalt eines Manifests.

Wenn Media CDN eine Anfrage mit einem autorisierten Kurzzeit-Token empfängt, wird ein signiertes Langzeit-Token generiert. Sie können das Token entweder in einem Abfrageparameter mit einem einzelnen Namen oder in einem Cookie verwenden. Das Token mit langer Dauer unterstützt die Anzeige eines Programms in voller Länge. Die von Media CDN generierten signierten Long-Duration-Tokens verwenden Ed25519-Signaturen, die mit von Google verwalteten Schlüsseln signiert sind, die einer EdgeCacheKeyset-Ressource zugeordnet sind.

Sie können die Ablaufzeit von Kurzzeit- und Langzeit-Tokens anpassen. Als Best Practice empfiehlt Google, dass Sie die Ablaufzeit der auf Ihrem Anwendungsserver generierten Kurzzeit-Tokens auf eine Minute konfigurieren. Sie müssen die Ablaufzeit von Langzeit-Token, die von Media CDN generiert werden, auf eine Dauer einstellen, die größer ist als die Länge Ihrer Inhalte, maximal jedoch auf einen Tag.

Anfrageablauf für die Dual-Token-Authentifizierung

Im Folgenden wird der Anfrageablauf beschrieben:

  1. Ein Betrachter fordert von Ihrem Anwendungsserver Metadaten für die Medien an, die er ansehen möchte. Ihr Anwendungsserver gibt den URI des primären Manifests zurück, das mit einem Kurzzeit-Token signiert ist.

  2. Ihre Spieleranwendung fordert das primäre Manifest von Media CDN an. Die Anfrage enthält das Kurzzeit-Token als Wert eines URI-Abfrageparameters im Format eines benannten Abfrageparameters.

  3. Media CDN überprüft das Kurzzeit-Token und die signierten Parameter des Tokens.

    1. Wenn das Token gültig ist, erstellt Media CDN ein Langzeit-Signaturtoken. Media CDN gibt das Token entweder in einem Set-Cookie-Header zurück oder durch Ändern der Manifest- und Segment-URIs im primären Manifest, um das Token aufzunehmen.
    2. Wenn das Token ungültig ist, antwortet Media CDN mit der Antwort HTTP 403 Forbidden.

  4. Die Spieleranwendung empfängt das primäre Manifest von Media CDN und fordert dann die Medien-Playlist oder die Mediensegmente an, auf die im primären Manifest verwiesen wird. Die Anfrage muss das Token für die lange Dauer enthalten, entweder als signiertes Cookie oder als URI-Parameter.

  5. Media CDN prüft das Langzeit-Signaturtoken:

    1. Wenn das Langzeit-Token für die jeweilige Anfrage gültig ist, stellt Media CDN den angeforderten Inhalt bereit.
    2. Wenn das Langzeit-Token nicht gültig ist (aufgrund eines abgelaufenen Tokens oder eines ungültigen Pfads), antwortet Media CDN mit der Antwort HTTP 403 Forbidden.

  6. Der Vorgang wird wiederholt, bis die Medienwiedergabe endet oder die Langzeit-Signatur abläuft.

Unterstützte Tokenformate für signierte Dual-Token-Anfragen

Signierte Dual-Token-Anfragen von Media CDN unterstützen je nach Tokentyp mehrere Formate.

Signierte Anfragen mit kurzer Laufzeit

Für signierte Anfragen mit kurzer Laufzeit unterstützt Media CDN standardmäßig Tokens, die mit Ed25519-Signaturen signiert wurden. Sie können auch Hash-basierte Nachrichtenauthentifizierungscodes (HMACs) mit Symmetrieschlüsseln verwenden, um die Kompatibilität mit dem vorhandenen Anwendungscode und anderen CDNs sicherzustellen.

Um HMACs zu verwenden, verwenden Sie Secret Manager zum Speichern des HMAC-Secrets. Anschließend gewähren Sie dem Media CDN-Dienstkonto Zugriff auf das gespeicherte Secret. Als Best Practice empfiehlt Google die Verwendung der asymmetrischen Signatur mit Ed25519-Signaturen für Sicherheit und Leistung.

Das Media CDN-Dienstkonto gehört zum Media CDN-Projekt und wird nicht in der Liste der Dienstkonten Ihres Projekts angezeigt. Das Dienstkonto gewährt nur Zugriff auf Media CDN-Ressourcen in den Projekten, die Sie explizit zulassen.

Das Dienstkonto hat die folgenden Rollen:

service-PROJECT_NUMBER@gcp-sa-mediaedgefill.iam.gserviceaccount.com

Dabei ist PROJECT_NUMBER die Projektnummer.

Zum Aktivieren des Media CDN-Dienstkontos müssen Sie mindestens eine Media CDN-Ressource erstellen, z. B. EdgeCacheOrigin.

Signierte Anfragen mit langer Laufzeit

Für signierte Anfragen mit langer Laufzeit verwendet Media CDN Ed25519-Signaturen, die mit von Google verwalteten Schlüsseln signiert werden, die mit einer EdgeCacheKeyset-Ressource verknüpft sind.

Media CDN unterstützt ein einzelnes Tokenformat für Tokens mit langer Laufzeit, die entweder in einem einzelnen Abfrageparameter für HLS-Streams oder in einem Cookie verwendet werden können.

So funktionieren signierte Anfragen

Eine signierte Anfrage verwendet Signaturen oder Tokens, um zu prüfen, ob jeder Betrachter für den Zugriff auf Inhalte authentifiziert ist. Sie können Media CDN so konfigurieren, dass der Zugriff auf einen der folgenden Bereiche beschränkt ist:

  • Entweder ein genauer URI oder URI-Präfix für eine begrenzte Zeit
  • Ein bestimmter Client
  • Bei signierten Anfragen mit Token, bis zu fünf Pfade mit Platzhalter

Um signierte Anfragen zu verwenden, generieren Sie Schlüssel zum Signieren und Verifizieren von Signaturen. Anschließend konfigurieren Sie Routen, mit denen Sie das Verhalten basierend auf dem Inhaltstyp, den Clientattributen und Ihren Aktualitätsanforderungen optimieren können. Signierte Anfragen können pro Route erzwungen werden, wodurch Sie bestimmte Endpunkte schützen können.

Jeder Media CDN-Dienst kann eine Sammlung mehrerer Schlüssel verwenden. Die Sammlung von Schlüsseln wird auch als Schlüsselsatz bezeichnet. Mit Schlüsselsätzen können Sie Schlüssel rotieren und private Schlüssel ohne Unterbrechung auf Ihre eigene Infrastruktur verteilen.

Sie können Media CDN so konfigurieren, dass signierte Anfragen oder Tokens verwendet werden, um Inhalte zu schützen.

Bei signierten Anfragen, die Token verwenden, können Sie das Token in einem der folgenden Bereiche platzieren:

  • In einem Abfrageparameter Ihrer Wahl
  • In einem Cookie

Weitere Informationen finden Sie unter Tokens generieren.

Für signierte Anfragen mit Signaturen können Sie eines der folgenden Formate verwenden:

  • Genauer URI mit Abfrageparametern: Sie geben ein URLPrefix mit dem genauen URI an und hängen dieselben Abfrageparameter an mehrere URIs an.
  • URI-Präfix mit Abfrageparametern: Sie geben ein URLPrefix mit einem URI-Präfix an und hängen dieselben Abfrageparameter an mehrere URIs an.
  • Pfadkomponente: Sie geben eine Pfadkomponente an, mit der relative Manifest-URIs die signierte URI-Komponente übernehmen können.
  • Ein signiertes Cookie: Sie geben ein URI-Präfix in einem Cookie an, das den Zugriff auf jeden URI mit dem von Ihnen angegebenen Präfix ermöglicht.

Weitere Informationen finden Sie unter Signaturen generieren.

Hinweise

In den folgenden Abschnitten werden verschiedene Faktoren erläutert, die Sie berücksichtigen sollten, um den unbefugten Vertrieb Ihrer Inhalte zu verhindern.

Sicherheitsaspekte

Media CDN validiert alle Anfragen, die mit einer Route übereinstimmen, die mit einem cdnPolicy.signedRequestMode von REQUIRE_SIGNATURES oder REQUIRE_TOKENS konfiguriert ist.

Wir empfehlen, Anfragen an der Quelle zu validieren. Auch wenn Media CDN ungültige und nicht signierte Anfragen für eine Route ablehnt, für die Signaturen erforderlich sind, finden Clients möglicherweise eine Möglichkeit, direkt auf deinen Ursprung zuzugreifen. Eine zusätzliche Validierungsebene trägt dazu bei, Ihre Inhalte mit einem mehrschichtigen Schutz zu versehen.

In der folgenden Tabelle werden Szenarien erläutert, in denen Media CDN eine Anfrage validiert:

Anfrage hat Signatur Ist die Unterschrift gültig? signedRequestMode Verhalten Statuscode
Nein – REQUIRE_SIGNATURES oder REQUIRE_TOKENS Anfragen ohne Signaturen oder Tokens werden so behandelt, als wäre die Signatur ungültig. HTTP 403
Ja Nein REQUIRE_SIGNATURES oder REQUIRE_TOKENS Eine Signatur oder ein Token gilt als ungültig, wenn es abgelaufen ist oder eine nicht übereinstimmende URL oder einen falschen Schlüssel hat. Ungültige Signaturen oder Tokens werden am CDN-Edge abgelehnt. HTTP 403
Ja Ja REQUIRE_SIGNATURES oder REQUIRE_TOKENS Eine Signatur oder ein Token wird validiert und die Antwort wird mit Inhalten aus einem Cache oder dem Ursprung bereitgestellt. HTTP 200
Ja Ja „Kein“ oder DISABLED Es wird keine Validierung durchgeführt und dem Nutzer wird direkt eine Antwort gesendet. HTTP 200
Ja Nein „Kein“ oder DISABLED Es wird keine Validierung durchgeführt und dem Nutzer wird direkt eine Antwort gesendet. HTTP 200

Wenn Ihre Anwendung eine ungültige Signatur erkennt, muss sie mit einem Statuscode HTTP 403 (Forbidden) antworten. HTTP 403-Statuscodes können nicht zwischengespeichert werden.

Wenn Ihre Anwendung einen cachefähigen Statuscode an eine ungültige Anfrage sendet, werden gültige zukünftige Anfragen möglicherweise fälschlicherweise abgelehnt.

URI-Limits

Die meisten modernen HTTP-Clients unterstützen URIs mit einer Länge von bis zu 8.000 Zeichen. Einige Legacy- oder Nischengeräte können jedoch strengere Limits haben. Im Allgemeinen fügt ein signierter URI dem Anfrage-URI etwa 125 Zeichen hinzu, einschließlich der folgenden:

  • Wenn alle Feldnamen verwendet werden, werden etwa 67 Zeichen für jedes Feld verwendet, z. B. Expires= und KeyName=.
  • Für Unix-Zeitstempel: 10 Zeichen
  • Für den KeyName: fünf Zeichen
  • Für den base64-codierten Signature-Wert: 43 Zeichen

Als Best Practice sollten Sie URIs mit weniger als 2.000 Zeichen beibehalten. Verwenden Sie dazu Abfrageparameter als Tokens. Kürzere URIs verhindern, dass Geräte abgeschnittene URIs an Media CDN senden.

Legacy-Videostreaminggeräte

Einige Legacy-Videostreaming-Geräte unterstützen das Anhängen von Cookies an Manifest- oder Mediensegmentanfragen möglicherweise nicht vollständig. Wenn Sie Geräte mit bekannten Problemen bei der Verarbeitung von HTTP-Cookies haben, konfigurieren Sie Media CDN so, dass Abfrageparameter für signierte Anfragen und den Austausch von Dual-Token verwendet werden.

Sie allein sind für die Einwilligung und die Einhaltung der Datenschutzbestimmungen verantwortlich, wenn Sie Cookies zum Austausch von Kurzzeit-Tokens verwenden. Wenn Media CDN für die Verwendung von signierte Dual-Token-Anfragen konfiguriert ist, stellt Google die Cookies für Langzeit-Tokens aus und verwaltet sie.

Abrechnung

Weitere Informationen zur Abrechnung von Secret Manager finden Sie unter Preise.

Medien-CDN-Abrufe für Secrets werden intern im Cache gespeichert, wodurch die Rate von Secret-Abrufen aus Secret Manager erheblich reduziert wird. Durch die reduzierten Abrufe werden auch die Zugriffsraten erheblich reduziert, die Secret Manager beobachtet und Ihnen in Rechnung stellt.

Weitere Informationen zum Secret-Caching in Media CDN finden Sie unter Schlüsselübersicht.