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 den global verteilten Caches von Google Cloud bereitstellen, wenn Anfragen autorisiert werden müssen. Jeder, der die signierte URL hat, kann für eine begrenzte Zeit auf die Ressource zugreifen.
  • Mit signierten Cookies können Sie auch für einen begrenzten Zeitraum auf eine Ressource zugreifen. Sie sind hilfreich, wenn Sie Dutzende oder Hunderte von URLs für jeden Nutzer signieren müssen.
  • Mit der privaten Ursprungsauthentifizierung können Sie Verbindungen zu Ihren Amazon S3-Buckets (Amazon Simple Storage Service) oder anderen kompatiblen Objektspeichern einschränken und verhindern, dass Nutzer direkt darauf zugreifen.

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.

  • Anzeigen für Nutzer mit Clientanwendungen ausliefern, 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. OPTIONS- und TRACE-Anfragen werden immer direkt an das Backend 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 Backend generiert wurden.

Die von der gcloud 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.

Eine Anleitung zur Verwendung signierter URLs mit Cloud CDN 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:

  • Sie können 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 integrierten 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:

  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. Stellen 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 finden Sie unter Signierte Cookies verwenden.

Authentifizierung des privaten Ursprungs

Die Authentifizierung über einen privaten Ursprung ermöglicht Cloud CDN langfristigen Zugriff auf private Amazon S3-Buckets oder kompatible Objektspeicher. Cloud CDN kann dann Inhalte von diesen Ursprüngen bereitstellen, ohne öffentlichen Lesezugriff zu verwenden.

Die Authentifizierung des privaten Ursprungs ist ursprünglich gerichtet, während signierte URLs und signierte Cookies clientseitig sind. 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. Mit signierten URLs und Cookies wird festgelegt, welche Nutzer auf Cloud CDN zugreifen können.

Die Authentifizierung über einen privaten Ursprung wird für Cloud CDN mit einem globalen externen Application Load Balancer oder einem klassischen Application Load Balancer unterstützt.

Eine Anleitung zur Verwendung der Authentifizierung über einen privaten Ursprung mit Cloud CDN finden Sie unter Authentifizierung über einen privaten Ursprung konfigurieren.

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 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