Cloud Storage-Authentifizierung

Die meisten Vorgänge in Cloud Storage müssen authentifiziert werden. Die einzige Ausnahme sind Vorgänge an Objekten, auf die anonym zugegriffen werden kann. Eine Ressource hat anonymen Zugriff, wenn die Gruppe allUsers in der ACL für die Ressource enthalten ist oder wenn die Gruppe allUsers in einer IAM-Richtlinie enthalten ist, die auf die Ressource angewendet wird. Zur Gruppe allUsers gehört jeder im Internet.

oauth 2.0

Authentication

Cloud Storage nutzt OAuth 2.0 für die API-Authentifizierung und -Autorisierung. Bei der Authentifizierung wird die Identität eines Clients ermittelt. Der genaue Ablauf der Authentifizierung hängt davon ab, wie Sie auf Cloud Storage zugreifen. Es gibt jedoch zwei grundlegende Arten:

  • Bei einem serverbezogenen Ablauf kann eine Anwendung die Anmeldedaten eines Dienstkontos direkt bereithalten, um sich zu authentifizieren. Verwenden Sie diesen Ablauf, wenn Ihre Anwendung mit eigenen Daten anstatt mit denen von Nutzern arbeitet. Google Cloud-Projekte haben Standarddienstkonten, die Sie verwenden können. Alternativ können Sie auch neue erstellen.

  • Bei einem nutzerbezogenen Ablauf kann die Anwendung Anmeldedaten von einem Endnutzer abrufen. Der Nutzer meldet sich an, um sich zu authentifizieren. Verwenden Sie diesen Ablauf, wenn Ihre Anwendung auf Nutzerdaten zugreifen muss. Im Abschnitt Anmeldedaten von Nutzerkonten weiter unten auf der Seite finden Sie Szenarien, in denen ein nutzerbezogener Ablauf angemessen ist.

Sie können auch beide Authentifizierungsarten gemeinsam in derselben Anwendung verwenden. Weitere Hintergrundinformationen zur Authentifizierung finden Sie im Google Cloud-Authentifizierungsleitfaden.

Bereiche

Die Autorisierung dient dazu festzustellen, welche Berechtigungen eine authentifizierte Identität bei einer Reihe von Ressourcen hat. OAuth 2.0 setzt Bereiche ein, um zu ermitteln, ob eine authentifizierte Identität autorisiert ist. Anwendungen verwenden Anmeldedaten, die sie im Rahmen eines nutzer- oder serverbezogenen Authentifizierungsablaufs erhalten haben, zusammen mit einem oder mehreren Bereichen, um für den Zugriff auf geschützte Ressourcen ein Zugriffstoken von einem Google-Autorisierungsserver anzufordern. Beispiel: Anwendung A mit einem Zugriffstoken mit dem Bereich read-only kann nur Daten lesen, während Anwendung B mit einem Zugriffstoken mit dem Bereich read-write Daten lesen und ändern kann. Keine der beiden Anwendungen kann jedoch Access Control Lists (ACLs) für Objekte und Buckets lesen oder ändern. Nur eine Anwendung mit dem Bereich full-control ist dazu in der Lage.

Typ Beschreibung Bereichs-URL
read-only Gewährt nur Lesezugriff auf Daten, einschließlich des Auflistens von Buckets. https://www.googleapis.com/auth/devstorage.read_only
read-write Gewährt Zugriff zum Lesen und Ändern von Daten, jedoch nicht von Metadaten wie IAM-Richtlinien. https://www.googleapis.com/auth/devstorage.read_write
full-control Gewährt vollständige Kontrolle über Daten, einschließlich der Fähigkeit, IAM-Richtlinien zu ändern. https://www.googleapis.com/auth/devstorage.full_control
cloud-platform.read-only Daten in allen Google Cloud-Diensten abrufen Bei Cloud Storage entspricht dies devstorage.read-only. https://www.googleapis.com/auth/cloud-platform.read-only
cloud-platform Daten in allen Google Cloud-Diensten abrufen und verwalten Bei Cloud Storage entspricht dies devstorage.full-control. https://www.googleapis.com/auth/cloud-platform

Authentifizierung über die Befehlszeile

Wenn Sie mit Cloud Storage arbeiten und gcloud storage- oder gsutil-Befehle über die Befehlszeile verwenden, authentifizieren Sie sich in der Regel mit den Anmeldedaten Ihres Nutzerkontos. Führen Sie dazu den Befehl gcloud auth login aus und folgen Sie der Anleitung, die eine Anmeldung in Ihrem Nutzerkonto umfasst.

Authentifizierung der Clientbibliothek

Clientbibliotheken können Standardanmeldedaten für Anwendungen verwenden, um sich einfach bei Google APIs zu authentifizieren und Anfragen an diese APIs zu senden. Mit den Standardanmeldedaten für Anwendungen können Sie Ihre Anwendung lokal testen und bereitstellen, ohne den zugrunde liegenden Code zu ändern. Weitere Informationen und Codebeispiele finden Sie unter Authentifizierung.

  • Google Cloud

    Wenn Sie Ihre Anwendung auf Diensten ausführen, die Angehängte Dienstkonten wie App Engine, Cloud Functions, Cloud Run oder Compute Engine unterstützen, stellt die Umgebung bereits Dienstkonto-Authentifizierungsinformationen bereit, sodass keine weitere Einrichtung erforderlich ist. Bei Compute Engine hängt der Bereich des Dienstkontos davon ab, wie Sie die Instanz erstellt haben Siehe Zugriffsbereiche in der Compute Engine-Dokumentation. Bei App Engine wird der Bereich cloud-platform verwendet.

  • Andere Umgebungen

    Zur Initialisierung Ihrer lokalen Entwicklungs- oder Produktionsumgebung müssen Sie ein Google Cloud-Dienstkonto erstellen, den Schlüssel herunterladen und die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS so festlegen, dass der Schlüssel verwendet wird. Eine detaillierte Anleitung mit Verwendung von Cloud Storage-Clientbibliotheken finden Sie unter Authentifizierung einrichten.

API-Authentifizierung

Für Anfragen mit OAuth 2.0 an die XML API oder die JSON API von Cloud Storage fügen Sie das Zugriffstoken Ihrer Anwendung in den Authorization-Header jeder Anfrage ein, die authentifiziert werden muss. Sie können ein Zugriffstoken aus dem OAuth 2.0 Playground erstellen.

  1. Wählen Sie in derOAuth 2.0 Playground, klickenCloud Storage API Version 1 und wählen Sie dann eine Zugriffsebene für Ihre Anwendung aus (full_control, read_only oder read_write).

  2. Klicken Sie auf Authorize APIs (APIs autorisieren).

  3. Melden Sie sich bei Ihrer Aufforderung in Ihrem Google-Konto an. Klicken Sie im angezeigten Dialogfeld auf Zulassen.

  4. Klicken Sie in Schritt 2 des Playground auf Autorisierungscode gegen Tokens austauschen für den angezeigten Autorisierungscode.

  5. Kopieren Sie das Zugriffstoken und fügen Sie es in den Header Authorization der Anfrage ein:

    Authorization: Bearer OAUTH2_TOKEN

Das folgende Beispiel enthält eine Anfrage zum Auflisten von Objekten in einem Bucket.

JSON API

Verwenden Sie die list-Methode der Objektressource:

GET /storage/v1/b/example-bucket/o HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

Wenn Sie Anfragen über die Befehlszeile oder zum Testen autorisieren möchten, können Sie den Befehl "curl" mit der folgenden Syntax verwenden:

curl -H "Authorization: Bearer OAUTH2_TOKEN" "https://storage.googleapis.com/storage/v1/b/BUCKET_NAME/o"

Für lokale Tests können Sie mit dem Befehl gcloud auth application-default print-access-token ein Token generieren.

XML API

Verwenden Sie eine Anfrage zum Auflisten von Objekten:

GET / HTTP/1.1
Host: example-bucket.storage.googleapis.com
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

Wenn Sie Anfragen über die Befehlszeile oder zum Testen autorisieren möchten, können Sie den Befehl "curl" mit der folgenden Syntax verwenden:

curl -H "Authorization: Bearer OAUTH2_TOKEN" "https://BUCKET_NAME.storage.googleapis.com"

Für lokale Tests können Sie mit dem Befehl gcloud auth application-default print-access-token ein Token generieren.

Da die Verwaltung und Aktualisierung von Zugriffstokens sehr kompliziert ist und der direkte Umgang mit kryptografischen Anwendungen ein hohes Sicherheitsrisiko birgt, sollten Sie unbedingt eine verifizierte Clientbibliothek verwenden.

HMAC-Schlüssel zur Verwendung mit der XML API für den interoperablen Zugriff mit Amazon S3 finden Sie unter HMAC-Schlüssel für Dienstkonten verwalten.

Nutzerkonto-Anmeldedaten

Verwenden Sie Nutzerkonto-Anmeldedaten zur Authentifizierung, wenn Ihre Anwendung im Namen eines Nutzers Zugriff auf Daten benötigt. Andernfalls sollten Sie Dienstkonto-Anmeldedaten einsetzen. In den folgenden Szenarien können Nutzerkonto-Anmeldedaten verwendet werden:

  • Webserveranwendungen
  • Installierte Anwendungen und Desktopanwendungen
  • Mobile Apps
  • Clientseitiges JavaScript
  • Anwendungen auf Geräten mit begrenzter Eingabe

Weitere Informationen zu diesen Szenarien finden Sie in den OAuth 2.0-Szenarien.

Wenn Sie eine Anwendung entwerfen, die mehrere Authentifizierungsoptionen für Endnutzer enthalten soll, verwenden Sie Firebase Authentication. Dies ermöglicht die E-Mail- und Passwortauthentifizierung sowie die föderierte Anmeldung bei Identitätsanbietern wie Google, Facebook, Twitter und GitHub. Weitere Informationen zum Einrichten von Authentifizierungssystemen für verschiedene Anwendungsfälle finden Sie unter Einstieg in Firebase Authentication.

Wenn eine Anwendung in einem nutzerbezogenen Authentifizierungsablauf von einem Nutzer ein Zugriffstoken erhält, hat dieses Token nur die Berechtigungen, die auch der Nutzer hat, der das Token gewährt. Beispiel: Wenn jana@gmail.com read-only-Zugriff auf example-bucket hat, kann eine Anwendung, der Jana read-write-Zugriff gewährt hat, in ihrem Namen keine Daten in example-bucket schreiben.

Nächste Schritte