Signierte URLs

Auf dieser Seite erhalten Sie eine Übersicht über signierte URLs, mit denen Sie allen Nutzern, die über die URL verfügen, einen zeitlich begrenzten Zugriff auf Ressourcen gewähren können. Dabei ist es unerheblich, ob die Nutzer ein Google-Konto haben. Informationen zum Erstellen von signierten URLs finden Sie unter Signierte URLs mit gsutil erstellen und Signierte URLs mit einem eigenen Programm erstellen. Wenn Sie andere Möglichkeiten zur Kontrolle des Zugriffs auf Buckets und Objekte kennenlernen möchten, sehen Sie sich die Übersicht über die Zugriffssteuerung an.

Überblick

Eine signierte URL beschränkt die Berechtigung und die Zeit zum Stellen einer Anfrage. Der Abfragestring von signierten URLs enthält Authentifizierungsinformationen, damit Nutzer ohne Anmeldedaten bestimmte Aktionen für eine Ressource ausführen können. Wenn Sie eine signierte URL generieren, geben Sie ein Nutzer- oder Dienstkonto an, das über ausreichende Berechtigungen verfügt, um die Anfrage der signierten URL ausführen zu können. Nachdem Sie eine signierte URL generiert haben, kann sie von allen Nutzern, denen sie bekannt ist, verwendet werden, um innerhalb eines bestimmten Zeitraums bestimmte Aktionen auszuführen, z. B. ein Objekt zu lesen.

Wann sollte ich eine signierte URL verwenden?

Unter bestimmten Voraussetzungen möchten Sie möglicherweise, dass Nutzer nicht zwingend ein Google-Konto besitzen müssen, um auf Cloud Storage zuzugreifen, 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 Lese-, Schreib- oder Löschzugriff auf die entsprechende Ressource erhält. Jeder, der die URL kennt, kann auf die Ressource zugreifen, bis die URL abläuft. Die Ablaufzeit legen Sie beim Erstellen der signierten URL fest.

Optionen zum Generieren einer signierten URL

Cloud Storage unterstützt verschiedene Methoden zum Generieren von signierten URLs:

  • V4-Signaturprozess mit DienstkontoauthentifizierungBETA: Dieser Signaturmechanismus wird unten beschrieben.

  • V2-Signaturprozess mit Dienstkontoauthentifizierung: Weitere Informationen zu diesem Signaturmechanismus finden Sie hier.

  • Signieren mit HMAC-Authentifizierung: Als Nutzer des Amazon Simple Storage Service (Amazon S3) können Sie Ihre vorhandenen Workflows verwenden, um signierte URLs für Cloud Storage zu generieren. Dazu geben Sie einfach Cloud Storage-Ressourcen an, verweisen auf den Host storage.googleapis.com und verwenden die HMAC-Anmeldedaten von Google, um die signierte URL zu generieren.

Beispiel einer signierten URL

Das folgende Beispiel zeigt eine signierte URL, die mit dem V4-Signaturprozess mit Dienstkontoauthentifizierung erstellt wurde:

https://storage.googleapis.com/example-bucket/cat.jpeg?X-Goog-Algorithm=
GOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount
.com%2F20181026%2Fus-central-1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T18
1309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host&X-Goog-Signature=247a2aa45f16
9edf4d187d54e7cc46e4731b1e6273242c4f4c39a1d2507a0e58706e25e3a85a7dbb891d62afa849
6def8e260c1db863d9ace85ff0a184b894b117fe46d1225c82f2aa19efd52cf21d3e2022b3b868dc
c1aca2741951ed5bf3bb25a34f5e9316a2841e8ff4c530b22ceaa1c5ce09c7cbb5732631510c2058
0e61723f5594de3aea497f195456a2ff2bdd0d13bad47289d8611b6f9cfeef0c46c91a455b94e90a
66924f722292d21e24d31dcfb38ce0c0f353ffa5a9756fc2a9f2b40bc2113206a81e324fc4fd6823
a29163fa845c8ae7eca1fcf6e5bb48b3200983c56c5ca81fffb151cca7402beddfc4a76b13344703
2ea7abedc098d2eb14a7

Diese signierte URL ermöglichte den Lesezugriff auf das Objekt cat.jpeg im Bucket example-bucket. Die folgenden Abfrageparameter machen diese URL zu einer signierten URL:

  • X-Goog-Algorithm: Der Algorithmus, mit dem die URL signiert wurde.

  • X-Goog-Credential: Informationen zu den Anmeldedaten, die zum Erstellen der signierten URL verwendet wurden.

  • X-Goog-Date: Das Datum und die Uhrzeit, ab dem bzw. ab der die signierte URL verwendet werden konnte, im ISO 8601-Basisformat YYYYMMDD'T'HHMMSS'Z'.

  • X-Goog-Expires: Die Gültigkeitsdauer der signierten URL, gemessen in Sekunden ab dem Wert von X-Goog-Date.

  • X-Goog-SignedHeaders: Header, die in jeder Anfrage enthalten sein mussten, bei der die signierte URL verwendet wurde.

  • X-Goog-Signature: Der Authentifizierungsstring, der Anfragen mit dieser signierten URL den Zugriff auf cat.jpeg ermöglichte.

Signierte URLs mit fortsetzbaren Uploads

Wenn Sie signierte URLs mit fortsetzbaren Uploads verwenden, um Objekte in einen Bucket hochzuladen, müssen Sie die signierte URL nur für die erste POST-Anfrage einsetzen. Mit der POST-Anfrage werden keine Daten hochgeladen. Stattdessen gibt die Anfrage einen Sitzungs-URI zurück, der in nachfolgenden PUT-Anfragen zum Hochladen von Daten verwendet wird. Da es sich bei dem Sitzungs-URI eigentlich um ein Authentifizierungstoken handelt, muss für die PUT-Anfragen nicht die ursprüngliche signierte URL verwendet werden. Durch dieses Verhalten kann die POST-Anfrage vom Server gestellt werden, ohne dass signierte URLs von den einzelnen Clients verarbeitet werden müssen.

Fortsetzbare Uploads sind an die Region gebunden, in der sie gestartet werden. Wenn Sie zum Beispiel eine URL für fortsetzbare Uploads in den USA erstellen und an einen Client in Asien senden, läuft der Upload weiterhin über die USA. Fortsetzbare Uploads in Regionen, die von der Startregion abweichen, können das Hochladen verlangsamen. Dies können Sie vermeiden, wenn Sie die anfängliche POST-Anfrage über den Server erstellen und signieren, die signierte URL jedoch anschließend an den Client übergeben, damit der Upload von dessen Standort aus initiiert wird. Nach dem Start des Uploads kann der Client den entsprechenden Sitzungs-URI für PUT-Anfragen nutzen, die nicht signiert werden müssen.

Überlegungen zu signierten URLs

Folgendes sollten Sie beim Arbeiten mit signierten URLs beachten:

  • Signierte URLs können normalerweise für jede XML API-Anfrage erstellt werden. Mit den Cloud Storage-Clientbibliotheken für Node.js können signierte URLs derzeit jedoch nur für einzelne Objekte erstellt werden. Sie können z. B. nicht verwendet werden, um signierte URLs zum Auflisten von Objekten in einem Bucket zu erstellen.

  • Die Cloud Storage-Clientbibliotheken für Python und Go unterstützen derzeit keine mit V4 signierten URLs.

  • Abfragestringparameter wie response-content-disposition und response-content-type werden von der Signatur nicht überprüft. Wenn Sie die Angabe von Content-Disposition oder Content-Type in der Antwort erzwingen möchten, können Sie diese Parameter in den Objektmetadaten festlegen.

  • Bei der Angabe von Anmeldedaten wird empfohlen, dass Sie Ihr Dienstkonto anhand der zugehörigen E-Mail-Adresse identifizieren. Sie können aber auch die Dienstkonto-ID verwenden.

Kanonische Anfragen

Die kanonische Anfrage definiert die Anfrage, die Nutzer erstellen müssen, wenn sie Ihre signierte URL verwenden. Sie beinhaltet Informationen wie das HTTP-Verb, die Abfragestringparameter und die Header, die in einer Anfrage mit Ihrer signierten URL angegeben werden müssen, sowie das Objekt, den Bucket oder eine andere Ressource, auf die die signierte URL Zugriff gewährt.

HTTP-Verben

Signierte URLs können mit den folgenden HTTP-Verben verwendet werden:

Ressourcenpfad

Die kanonische Anfrage enthält den Pfad zu der Ressource, auf die die signierte URL angewendet wird. Der Pfad zur Ressource ist der gesamte Teil, der auf den Hostnamen folgt, steht aber immer vor dem Abfragestring.

Beispiel: Bei der Cloud Storage-URL https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg?userProject=my-project lautet der Pfad zur Ressource /example-bucket/cat-pics/tabby.jpeg.

Wenn Sie eine alternative Cloud Storage-URL wie https://example-bucket.storage.googleapis.com/cat-pics/tabby.jpeg?userProject=my-project verwenden, lautet der Pfad zur Ressource /cat-pics/tabby.jpeg.

Informationen zu weiteren URL-Endpunkten, die mit signierten URLs verwendet werden können, finden Sie unter Anfrageendpunkte.

Wenn Sie den Pfad zur Ressource definieren, müssen Sie die folgenden reservierten Zeichen per URL-Encoding umwandeln: ?=!#$&'()*+,:;@[].". Sonstige per URL-Encoding umgewandelte Zeichen, die in der URL verwendet werden, sollten ebenfalls im Ressourcenpfad enthalten sein.

Abfragestring

Die kanonische Anfrage enthält die Abfragestringparameter, die Teil jeder Anfrage mit der signierten URL sind. Der Abfragestring ist der gesamte Teil, der auf das Fragezeichen (?) am Ende des Ressourcenpfads folgt.

Beispiel: Bei der Cloud Storage-URL https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg?userProject=my-project lautet der Abfragestring userProject=my-project.

In der kanonischen Anfrage muss der Abfragestring alle Parameter nach Namen sortieren. Dazu erfolgt eine lexikografische Sortierung nach Codepunktwerten. Alle Parameter sollten mit & getrennt werden.

Erforderliche Abfragestringparameter

Viele Abfragestringparameter wie alt werden nach Bedarf hinzugefügt. Die folgenden Abfragestringparameter müssen jedoch in jeder signierten URL enthalten sein:

  • X-Goog-Algorithm: Der Algorithmus, mit dem Sie die URL signiert haben. Zulässige Werte sind GOOG4-RSA-SHA256 und GOOG4-HMAC-SHA256.
  • X-Goog-Credential: Die Anmeldedaten, mit denen die URL signiert wurde. Anmeldedaten bestehen aus einem Autorisierer und einem Anmeldedatenbereich, die im folgenden Format angegeben werden: [AUTHORIZER]%2F[CREDENTIAL_SCOPE]. Der Autorisierer kann ein Dienstkontoname oder ein HMAC-Zugriffsschlüssel sein.
  • X-Goog-Date: Das aktuelle Datum und die aktuelle Uhrzeit im ISO 8601-Basisformat YYYYMMDD'T'HHMMSS'Z'.
  • X-Goog-Expires: Die Gültigkeitsdauer der signierten URL, gemessen in Sekunden ab X-Goog-Date.
  • X-Goog-SignedHeaders: Eine durch Semikolons getrennte Liste mit Namen von Headern, die in jeder Anfrage mit der signierten URL enthalten sein müssen. Einer dieser Header muss host sein.
  • X-Goog-Signature: Die Signatur, mit der die Anfrage authentifiziert wird.

Header

Die kanonische Anfrage enthält die Header, die Teil jeder Anfrage mit der signierten URL sein müssen. Dies beinhaltet benutzerdefinierte Header und Erweiterungsheader, die mit x-goog beginnen. Die Header müssen in mehreren Teilen der kanonischen Anfrage angegeben werden:

  1. Geben Sie die Headernamen im Abfragestringparameter X-Goog-SignedHeaders an und trennen Sie die einzelnen Werte durch ;.
  2. Geben Sie den Header name:value nach dem Abfragestring-Teil der kanonischen Anfrage an und trennen Sie die einzelnen Paare durch einen Zeilenumbruch (\n).
  3. Geben Sie die Headernamen in einer neuen Zeile an. Beachten Sie dabei die Liste mit name:value-Paaren und trennen Sie die einzelnen Werte durch ;.

Bei der Angabe der name:value-Paare für Header sollten Sie Folgendes beachten:

  • Wandeln Sie alle Headernamen in Kleinbuchstaben um.
  • Sortieren Sie alle benutzerdefinierten Headernamen lexikografisch nach Codepunktwerten.
  • Entfernen Sie doppelt vorkommende Headernamen, indem Sie einen Headernamen mit einer durch Kommas getrennten Liste an Werten erstellen. Achten Sie darauf, dass zwischen den Werten kein Leerzeichen vorhanden ist und dass die Reihenfolge der durch Kommas getrennten Liste der Reihenfolge entspricht, in der die Header in Ihrer Anfrage aufgeführt sind. Weitere Informationen finden Sie unter RFC 7230, Abschnitt 3.2.
  • Ersetzen Sie aufeinanderfolgende Leerzeichen und Zeilenumbrüche (CRLF oder LF) durch ein einzelnes Leerzeichen. Weitere Informationen zu aufeinanderfolgenden Leerzeichen finden Sie unter RFC 7230, Abschnitt 3.2.4..
  • Entfernen Sie alle Leerzeichen vor und nach dem Doppelpunkt, der auf den Headernamen folgt.

    Beispiel: Wenn Sie den benutzerdefinierten Header x-goog-acl: private verwenden, ohne das Leerzeichen hinter dem Doppelpunkt zu entfernen, wird der Fehler 403 Forbidden zurückgegeben, weil die so generierte Anfragesignatur nicht der von Google generierten Signatur entspricht.

Angenommen, Sie haben die folgenden Header:

host: storage.googleapis.com
content-type: text/plain
x-goog-meta-reviewer: jane
x-goog-meta-reviewer: john

Die Konstruktion in der kanonischen Anfrage würde so aussehen:

content-type:text/plain
host:storage.googleapis.com
x-goog-meta-reviewer:jane,john

Erforderliche Header

Die meisten Header, z. B. content-type und Erweiterungsheader, werden nach Bedarf hinzugefügt. Der folgende Header muss jedoch in jeder signierten URL enthalten sein:

  • host: Der URI für den Zugriff auf Cloud Storage.

Die folgenden Header können nur dann in Anfragen mit einer signierten URL verwendet werden, wenn sie in der kanonischen Anfrage explizit angegeben sind.

  • x-goog-project-id
  • x-goog-copy-source
  • x-goog-metadata-directive
  • x-amz-copy-source
  • x-amz-metadata-directive

Anmeldedatenbereich

Der Anmeldedatenbereich ist im zu signierenden String und im Abfragestringparameter X-Goog-Credential enthalten und hat die folgende Struktur:

[DATE]/[LOCATION]/storage/goog4_request
  • [DATE]: Das Datum im Format JJJJMMTT, das dem Tag im zu signierenden String entsprechen muss.
  • [LOCATION]: Die Region, in der sich die Ressource befindet oder erstellt wird. Für Cloud Storage-Ressourcen ist der Wert von [LOCATION] frei wählbar: Der Zweck des Parameters [LOCATION] besteht darin, die Kompatibilität mit Amazon Simple Storage Service (Amazon S3) aufrechtzuerhalten.
  • storage: Der Dienstname.
  • goog4_request: Der Typ der signierten URL.

Beispiel: 20181102/us/storage/goog4_request

Strings mit Google Cloud Platform-Tools signieren

Wenn Sie eine signierte URL mit einem Programm generieren, haben Sie die Möglichkeit, von der GCP bereitgestellte Tools zu verwenden, um den String zu signieren.

App Identity-Dienst von App Engine

Beim Signieren in einer App Engine-Anwendung wird der App Engine Identity-Dienst verwendet, der die Anmeldedaten des App Engine-Dienstkontos verwendet. Mit der Python App Identity API haben Sie z. B. folgende Möglichkeiten:

  • Sie können google.appengine.api.app_identity.sign_blob() verwenden, um die Byte Ihres Strings zu signieren und die Signature anzugeben, die Sie benötigen, wenn Sie die signierte URL zusammenstellen.

  • Sie können google.appengine.api.app_identity.get_service_account_name() verwenden, um einen Dienstkontonamen abzurufen. Dieser entspricht der GoogleAccessId, die Sie benötigen, um die signierte URL zusammenzustellen.

App Engine bietet außerdem Unterstützung in anderen Sprachen:

Der App Identity-Dienst rotiert die privaten Schlüssel beim Signieren der Blobs. Signierte URLs, die mit dem App Identity-Dienst erstellt werden, sind für mindestens eine Stunde gültig und eignen sich am besten für kurzlebigen Zugriff auf Ressourcen.

IAM signBlob

Zum Signieren können Sie die Methode IAM signBlob verwenden.

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...