Inhalte authentifizieren

Cloud CDN bietet drei Möglichkeiten, den Zugriff auf Ihre im Cache gespeicherten Inhalte zu steuern:

  • Mit signierten URLs können Sie Antworten aus Google Cloud global verteilte Caches, wenn Anfragen autorisiert werden müssen. Jeder mit der signierten URL kann für eine begrenzte Zeit auf die Ressource zugreifen.
  • Über signierte Cookies können Sie auch auf Ressource für begrenzte Zeit. Sie sind hilfreich, wenn Sie Zehn- oder Hunderte URLs für jeden Nutzer.
  • Mit der Authentifizierung des privaten Ursprungs können Sie Verbindungen zu Ihrem Amazon Simple Storage Service-Buckets (Amazon S3) oder andere kompatible Objektspeicher verwenden und verhindern, direkt darauf zugreifen können.

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:

  • Beschränken des Zugriffs auf einzelne Dateien, z. B. eine Installation herunterladen.

  • Um Nutzer mit Clientanwendungen zu bedienen, 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 Backend 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 Backend-Dienst, einem Backend-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 Backend 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:

  • Die HTTP-Methode istGET, HEAD, OPTIONS, oder TRACE.
  • Der Parameter Expires ist auf eine zukünftige Zeit eingestellt.
  • 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 Backend weitergeleitet oder aus dem Cache beantwortet. Anfragen vom Typ OPTIONS und TRACE werden immer direkt an das Back-End weitergeleitet und nicht aus dem Cache bereitgestellt werden. 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 diese Objekte mit Cloud CDN ohne Back-End-Änderungen, Cloud CDN überschreibt den Cache-Control-Header, wenn auf Anfragen mit gültigen signierte URLs. Cloud CDN behandelt den Inhalt als im Cache speicherbar und verwendet Der in der Cloud CDN-Konfiguration festgelegte Parameter max-age Die bereitgestellte Antwort enthält weiterhin die Cache-Control-Header, die vom Backend generiert wurden.

Die URL, die von der gcloud CLI zurückgegeben oder von Ihrem benutzerdefinierten kann Code entsprechend Ihren Anforderungen 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.

Eine Anleitung zur Verwendung von signierten URLs mit Cloud CDN Weitere Informationen finden Sie unter Signierte URLs verwenden.

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:

  • Um Zugriff auf mehrere eingeschränkte Dateien zu gewähren

  • Um zu vermeiden, dass Ihre aktuellen URLs geändert werden.

  • Damit URLs nicht jedes Mal aktualisiert werden, 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 regelmäßig über die JavaScript fetch() API bei der Seitennavigation oder anderen Hintergrundmechanismen in integrierten Anwendungen. 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:

  1. Erstellen Sie einen Signaturschlüssel für den angegebenen Back-End-Dienst.
  2. Erstellen Sie einen Cookiewert mit dem zulässigen URL-Präfix, Ablaufdatum, Schlüsselnamen und kryptografischer Signatur.
  3. Setzen Sie das Cookie in Ihrem Anwendungscode aus.

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.

Eine Anleitung zur Verwendung signierter Cookies mit Cloud CDN Siehe Signierte Cookies verwenden.

Authentifizierung des privaten Ursprungs

Durch die Authentifizierung des privaten Ursprungs erhält Cloud CDN langfristig Zugriff auf privaten Amazon S3-Buckets oder kompatiblen Objektspeichern. Cloud CDN kann dann Inhalte aus diesen Quellen bereitstellen, ohne öffentlichen Lesezugriff.

Die Authentifizierung des privaten Ursprungs ist ursprungsorientiert, während signierte URLs und signierte Cookies sind clientseitig. Sie können beide für dieselben Inhalte aktivieren. Die Authentifizierung des privaten Ursprungs schränkt den Zugriff auf Ihre Ursprünge und Inhalte ein, der nicht über das CDN erfolgt. Einstellungen für signierte URLs und Cookies die Nutzer auf Cloud CDN zugreifen können.

Die Authentifizierung des privaten Ursprungs wird für Cloud CDN mit einen globalen externen oder klassischen Application Load Balancer.

Eine Anleitung zum Verwenden der Authentifizierung des privaten Ursprungs mit Cloud CDN finden Sie unter Konfigurieren Sie die Authentifizierung des privaten Ursprungs.

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.

  • Sie haben Ihren Dienst für signierte Anfragen konfiguriert und Ihre URL enthält Signature als Abfrageparameter verwendet wird, versucht Cloud CDN, Ihre URL als signierte URL. 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 Backend.

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

Nächste Schritte