Signierte Cookies verwenden

Diese Seite bietet eine Übersicht über signierte Cookies und eine Anleitung für deren Verwendung mit Cloud CDN. Signierte Cookies ermöglichen zeitlich begrenzten Ressourcenzugriff auf eine Reihe von Dateien, unabhängig davon, ob die Nutzer Google-Konten haben.

Signierte Cookies sind eine Alternative zu signierten URLs. Sie schützen den Zugriff, wenn das separate Signieren von Dutzenden oder Hunderten von URLs für jeden Nutzer in Ihrer Anwendung nicht möglich ist.

Mit signierten Cookies haben Sie folgende Möglichkeiten:

• Einen Nutzer autorisieren und ihm ein zeitlich begrenztes Token für den Zugriff auf Ihre geschützten Inhalte zur Verfügung stellen (anstatt jede URL zu signieren).
• Den Zugriff des Nutzers auf ein bestimmtes URL-Präfix wie https://media.example.com/videos/ festlegen und dem autorisierten Nutzer nur Zugriff auf geschützte Inhalte innerhalb dieses URL-Präfixes gewähren.
• Ihre URLs und Medienmanifeste unverändert lassen, die Paketerstellung vereinfachen und die Cache-Fähigkeit verbessern.

Wenn Sie den Zugriff auf bestimmte URLs beschränken möchten, können Sie signierte URLs verwenden.

Vorbereitung

Führen Sie die folgenden Schritte aus, bevor Sie signierte Cookies verwenden:

• Achten Sie darauf, dass Cloud CDN aktiviert ist. Eine Anleitung hierzu finden Sie unter Cloud CDN verwenden. Sie können signierte Cookies in einem Backend konfigurieren, bevor Sie Cloud CDN aktivieren. Dies wird jedoch erst wirksam, wenn Cloud CDN aktiviert ist.

• Aktualisieren Sie bei Bedarf auf die aktuelle Version der Google Cloud CLI:

  gcloud components update
  

Einen Überblick finden Sie unter Signierte URLs und signierte Cookies.

Schlüssel für signierte Anfragen konfigurieren

Schlüssel für signierte URLs oder signierte Cookies werden in mehreren Schritten erstellt, die in den folgenden Abschnitten beschrieben werden.

Sicherheitsaspekte

In den folgenden Fällen validiert Cloud CDN Anfragen nicht:

• Die Anfrage wurde nicht signiert.
• Bei dem Backend-Dienst oder Backend-Bucket für die Anfrage ist Cloud CDN nicht aktiviert.

Signierte Anfragen müssen immer am Ursprung validiert werden, bevor die Antwort zurückgegeben wird. Dies liegt daran, dass Ursprünge zur Bereitstellung einer Mischung aus signierten und unsignierten Inhalten verwendet werden können und ein Client direkt auf den Ursprung zugreifen kann.

• Cloud CDN blockiert keine Anfragen ohne einen Abfrageparameter Signature oder HTTP-Cookie Cloud-CDN-Cookie. Anfragen mit ungültigen oder auf sonstige Weise fehlerhaften Anfrageparametern werden abgelehnt.
• Wenn die Anwendung eine ungültige Signatur erkennt, prüfen Sie, ob Ihre Anwendung mit dem Antwortcode HTTP 403 (Unauthorized) antwortet. HTTP 403-Antwortcodes können nicht zwischengespeichert werden.
• Antworten auf signierte und nicht signierte Anfragen werden separat gespeichert. Eine erfolgreiche Antwort auf eine gültige signierte Anfrage wird daher nie zum Bereitstellen einer unsignierten Anfrage verwendet.
• Wenn Ihre Anwendung einen cachefähigen Antwortcode an eine ungültige Anfrage sendet, werden gültige zukünftige Anfragen eventuell fälschlicherweise abgelehnt.

Achten Sie bei Cloud Storage-Back-Ends darauf, den öffentlichen Zugriff zu entfernen, damit Cloud Storage Anfragen ablehnen kann, denen eine gültige Signatur fehlt.

In der folgenden Tabelle ist die Funktionsweise zusammengefasst.

Schlüssel für signierte Anfragen erstellen

Wenn von Cloud CDN signierte URLs und signierte Cookies unterstützt werden sollen, erstellen Sie einen oder mehrere Schlüssel in einem Backend-Dienst und/oder Backend-Bucket mit aktiviertem Cloud CDN.

Für jeden Backend-Dienst oder -Bucket können Sie entsprechend Ihren Sicherheitsanforderungen Schlüssel erstellen und löschen. Für jedes Backend können gleichzeitig bis zu drei Schlüssel konfiguriert sein. Wir empfehlen, Schlüssel regelmäßig zu rotieren. Löschen Sie dazu den ältesten, fügen einen neuen hinzu und verwenden den neuen Schlüssel beim Signieren von URLs und Cookies.

Sie können denselben Schlüsselnamen in mehreren Backend-Diensten und -Buckets verwenden, da jeder Schlüsselsatz von den anderen unabhängig ist. Schlüsselnamen können bis zu 63 Zeichen lang sein. Verwenden Sie zum Benennen Ihrer Schlüssel die Zeichen A–Z, a–z, 0–9, _ (Unterstrich) und - (Bindestrich).

Bewahren Sie Schlüssel nach dem Erstellen sicher auf. Jeder, der einen Ihrer Schlüssel kennt, kann signierte URLs oder signierte Cookies erstellen, die von Cloud CDN akzeptiert werden, bis der Schlüssel aus Cloud CDN gelöscht wird. Die Schlüssel werden auf dem Computer gespeichert, auf dem Sie die signierten URLs generieren. Cloud CDN speichert die Schlüssel auch, um Anfragesignaturen zu prüfen.

Damit die Schlüssel geheim bleiben, werden die Schlüssel/Wert-Paare nicht in Antworten auf API-Anfragen aufgenommen. Wenn Sie einen Schlüssel verlieren, müssen Sie einen neuen erstellen.

Führen Sie die folgenden Schritte aus, um einen Schlüssel für signierte Anfragen zu erstellen.

head -c 16 /dev/urandom | base64 | tr +/ -_ > KEY_FILE_NAME

gcloud compute backend-services \
   add-signed-url-key BACKEND_NAME \
   --key-name KEY_NAME \
   --key-file KEY_FILE_NAME

gcloud compute backend-buckets \
   add-signed-url-key BACKEND_NAME \
   --key-name KEY_NAME \
   --key-file KEY_FILE_NAME

Cloud Storage-Berechtigungen konfigurieren

Wenn Sie Cloud Storage verwenden und eingeschränkt haben, wer die Objekte lesen kann, müssen Sie Cloud CDN zum Lesen der Objekte berechtigen. Fügen Sie dazu das Cloud CDN-Dienstkonto den ACLs von Cloud Storage hinzu.

Sie müssen das Dienstkonto nicht erstellen. Das Dienstkonto wird automatisch erstellt, wenn Sie einem Backend-Bucket eines Projekts zum ersten Mal einen Schlüssel hinzufügen.

Fügen Sie mindestens einen Schlüssel zu einem Backend-Bucket in Ihrem Projekt hinzu, bevor Sie den folgenden Befehl ausführen. Ansonsten verursacht der Befehl einen Fehler, da das Dienstkonto von Cloud CDN mit Cache-Füllung erst erstellt wird, wenn Sie mindestens einen Schlüssel für das Projekt hinzufügen.

gcloud storage buckets add-iam-policy-binding gs://BUCKET \
  --member=serviceAccount:service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

Ersetzen Sie PROJECT_NUMBER durch Ihre Projektnummer und BUCKET durch Ihren Storage-Bucket.

Das Cloud CDN-Dienstkonto service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com ist nicht in der Liste der Dienstkonten in Ihrem Projekt enthalten. Dies liegt daran, dass das Cloud CDN-Dienstkonto zu Cloud CDN gehört und nicht zu Ihrem Projekt.

Weitere Informationen zu Projektnummern finden Sie in der Hilfe zur Google Cloud Console unter Projektnamen, ‑nummer und ‑ID finden.

Maximale Cache-Zeit anpassen

Cloud CDN speichert Antworten für signierte Anfragen unabhängig vom Cache-Control-Header des Backends im Cache. Die maximale Zeit, für die Antworten ohne erneute Validierung im Cache gespeichert werden können, wird durch das Flag signed-url-cache-max-age festgelegt. Sie beträgt standardmäßig eine Stunde und kann wie hier gezeigt geändert werden.

Führen Sie einen der folgenden Befehle aus, um die maximale Cache-Zeit für einen Backend-Dienst oder -Bucket festzulegen:

gcloud compute backend-services update BACKEND_NAME
  --signed-url-cache-max-age MAX_AGE

gcloud compute backend-buckets update BACKEND_NAME
  --signed-url-cache-max-age MAX_AGE

Namen der Schlüssel für signierte Anfragen auflisten

Führen Sie einen der folgenden Befehle aus, um die Schlüssel in einem Backend-Dienst oder -Bucket aufzulisten:

gcloud compute backend-services describe BACKEND_NAME

gcloud compute backend-buckets describe BACKEND_NAME

Schlüssel für signierte Anfragen löschen

Wenn mit einem bestimmten Schlüssel signierte URLs nicht mehr akzeptiert werden sollen, führen Sie einen der folgenden Befehle aus, um diesen Schlüssel aus dem Backend-Dienst oder Backend-Bucket zu löschen:

gcloud compute backend-services \
   delete-signed-url-key BACKEND_NAME --key-name KEY_NAME