URL signées

Cette page offre une présentation des URL signées. Celles-ci vous permettent de donner un accès limité dans le temps aux ressources à toute personne en possession de l'URL, qu'elle ait ou non un compte Google. Pour découvrir comment créer des URL signées, consultez les sections Processus de signature V4 avec les outils Cloud Storage et Processus de signature V4 avec votre propre programme. Pour découvrir les autres méthodes de contrôle des accès aux buckets et aux objets, consultez la page Présentation du contrôle des accès.

Présentation

Une URL signée est une URL qui fournit une autorisation et une durée limitées pour effectuer une requête. Les URL signées contiennent des informations d'authentification dans leur chaîne de requête, ce qui permet aux utilisateurs sans identifiants d'effectuer des actions spécifiques sur une ressource. Lorsque vous générez une URL signée, vous spécifiez un compte d'utilisateur ou un compte de service qui doit disposer des autorisations suffisantes pour effectuer la requête adressée par l'URL signée. Une fois l'URL signée générée, toute personne disposant de cette URL peut l'utiliser pour effectuer des actions spécifiées, telles que la lecture d'un objet, dans un délai spécifié.

Quand utiliser une URL signée ?

Dans certains cas, il se peut que vous ne vouliez pas forcer vos utilisateurs à posséder un compte Google pour pouvoir accéder à Cloud Storage, mais que vous souhaitiez toujours contrôler les accès selon la logique spécifique à votre application. Le moyen habituel de traiter ce cas d'utilisation consiste à fournir une URL signée à un utilisateur, ce qui lui permet, pendant une durée limitée, de disposer d'un accès en lecture et en écriture à cette ressource ou de la supprimer. Toute personne connaissant l'URL peut accéder à la ressource jusqu'à l'expiration de cette URL. Vous spécifiez l'heure d'expiration lors de la création de l'URL signée.

Options pour générer une URL signée

Cloud Storage dispose de plusieurs méthodes permettant de générer une URL signée :

  • Signature V4 avec authentification du compte de serviceBÊTA : ce mécanisme de signature est décrit ci-dessous.

  • Signature V2 avec authentification du compte de service : pour plus d'informations sur ce mécanisme de signature, cliquez ici.

  • Signature avec authentification HMAC : si vous utilisez Amazon Simple Storage Service (Amazon S3), vous pouvez générer des URL signées pour Cloud Storage à l'aide de vos workflows existants. Il vous suffit de spécifier les ressources Cloud Storage, pointer vers l'hôte storage.googleapis.com et utiliser les identifiants Google HMAC lors de la génération de l'URL signée.

Exemple d'URL signée

Voici un exemple d'URL signée créée à l'aide du processus de signature V4 avec authentification du compte de service :

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

Cette URL signée fournit un accès permettant de lire l'objet cat.jpeg dans le bucket example-bucket. Les paramètres de requête qui en font une URL signée sont les suivants :

  • X-Goog-Algorithm : algorithme utilisé pour signer l'URL.

  • X-Goog-Credential : détails des identifiants utilisés pour créer l'URL signée.

  • X-Goog-Date : date et heure auxquelles l'URL signée est devenue utilisable, au format de base ISO 8601 YYYYMMDD'T'HHMMSS'Z'.

  • X-Goog-Expires : durée pendant laquelle l'URL signée est restée valide, mesurée en secondes à partir de la valeur indiquée dans X-Goog-Date.

  • X-Goog-SignedHeaders : en-têtes devant être inclus dans toute requête utilisant l'URL signée.

  • X-Goog-Signature : chaîne d'authentification permettant aux requêtes utilisant cette URL signée d'accéder à cat.jpeg.

Utiliser des URL signées pour les importations avec reprise

Lorsque vous utilisez des URL signées avec des importations avec reprise pour importer des objets dans votre bucket, vous devez uniquement utiliser l'URL signée dans la requête POST initiale. Aucune donnée n'est importée dans la requête POST ; à la place, la requête renvoie un URI de session utilisé dans les requêtes PUT ultérieures pour importer des données. L'URI de session étant en fait un jeton d'authentification, il n'est pas nécessaire que les requêtes PUT utilisent l'URL signée d'origine. Ce comportement permet au serveur d'effectuer la requête POST, évitant ainsi aux clients de devoir traiter eux-mêmes les URL signées.

Les importations avec reprise sont rattachées à la région dans laquelle elles démarrent. Par exemple, si vous créez une URL d'importation avec reprise aux États-Unis et que vous la transmettez à un client situé en Asie, l'importation transitera toujours par les États-Unis. L'exécution d'une importation avec reprise dans une région autre que celle de son lancement initial peut entraîner des ralentissements. Pour éviter cela, faites en sorte que le serveur génère et signe la requête POST initiale, puis transmettez l'URL signée au client afin que l'importation soit lancée à partir de son emplacement. Ensuite, le client peut utiliser normalement l'URI de session généré pour exécuter des requêtes PUT qui n'ont pas besoin d'être signées.

Considérations relatives aux URL signées

Lorsque vous utilisez des URL signées, tenez compte des points suivants :

  • Les URL signées peuvent généralement être créées pour toute requête de l'API XML. Cependant, pour le moment, les bibliothèques clientes Node.js de Cloud Storage n'ont la capacité de créer des URL signées que pour des objets individuels. Par exemple, elles ne permettent pas de créer des URL signées pour répertorier des objets dans un bucket.

  • Les bibliothèques clientes Python et Go de Cloud Storage ne sont actuellement pas compatibles avec les URL signées V4.

  • Les paramètres de chaîne de requête tels que response-content-disposition et response-content-type ne sont pas validés par la signature. Pour forcer un paramètre "Content-Disposition" ou "Content-Type" dans la réponse, définissez ces paramètres dans les métadonnées de l'objet.

  • Lors de la spécification des identifiants, il est recommandé d'identifier votre compte de service à l'aide de son adresse e-mail. Toutefois, l'utilisation de l'ID de compte de service est également acceptée.

Requêtes canoniques

La requête canonique définit la requête que les utilisateurs doivent effectuer lorsqu'ils utilisent votre URL signée. Elle comprend des informations telles que le verbe HTTP, les paramètres de chaîne de requête et les en-têtes devant être utilisés dans une requête utilisant votre URL signée, ainsi que l'objet, le bucket ou toute autre ressource à laquelle l'URL signée accorde l'accès.

Verbes HTTP

Les URL signées peuvent être utilisées avec les verbes HTTP suivants :

Chemin d'accès à la ressource

La requête canonique contient le chemin d'accès à la ressource à laquelle l'URL signée s'applique. Le chemin d'accès à la ressource correspond à tout ce qui suit le nom d'hôte, mais précède toute chaîne de requête.

Par exemple, si l'URL Cloud Storage est https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg?userProject=my-project, le chemin d'accès à la ressource correspond à /example-bucket/cat-pics/tabby.jpeg.

Si vous utilisez une autre URL Cloud Storage, telle que https://example-bucket.storage.googleapis.com/cat-pics/tabby.jpeg?userProject=my-project, le chemin d'accès à la ressource correspond à /cat-pics/tabby.jpeg.

Pour connaître d'autres points de terminaison d'URL pouvant être utilisés avec des URL signées, consultez la section Points de terminaison de requêtes pour l'API XML.

Lorsque vous définissez le chemin d'accès à la ressource, vous devez effectuer un encodage-pourcent des caractères réservés suivants : ?=!#$&'()*+,:;@[].". Tout autre encodage-pourcent utilisé dans l’URL doit également être inclus dans le chemin d'accès à la ressource.

Chaîne de requête

La requête canonique contient les paramètres de chaîne de requête qui doivent faire partie de toute requête utilisant l'URL signée. La chaîne de requête correspond à tout ce qui suit le point d'interrogation (?) à la fin du chemin d'accès à la ressource.

Par exemple, si l'URL Cloud Storage est https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg?userProject=my-project, la chaîne de requête correspond à userProject=my-project.

Dans la requête canonique, la chaîne de requête doit trier tous les paramètres par nom en appliquant un ordre de tri lexicographique aux valeurs de point de code ; de plus, tous les paramètres doivent être séparés par le caractère &.

Paramètres de chaîne de requête obligatoires

De nombreux paramètres de chaîne de requête, tels que alt, sont ajoutés en fonction des besoins. Cependant, les paramètres de chaîne de requête suivants sont obligatoires dans chaque URL signée :

  • X-Goog-Algorithm : algorithme utilisé pour signer l'URL. Les valeurs valides sont GOOG4-RSA-SHA256 et GOOG4-HMAC-SHA256.
  • X-Goog-Credential : identifiants utilisés pour signer l'URL. Les identifiants comprennent un agent d'autorisation et un champ d'application des identifiants au format [AUTHORIZER]%2F[CREDENTIAL_SCOPE]. L'agent d'autorisation peut être un nom de compte de service ou une clé d'accès HMAC.
  • X-Goog-Date : date et heure actuelles, au format de base ISO 8601 YYYYMMDD'T'HHMMSS'Z'.
  • X-Goog-Expires : durée de vie de l'URL signée, mesurée en secondes à partir de la valeur indiquée dans X-Goog-Date.
  • X-Goog-SignedHeaders : liste de noms d'en-têtes, séparés par des points-virgules, devant être inclus dans toute requête utilisant l'URL signée. L'un de ces en-têtes doit être host.
  • X-Goog-Signature : signature authentifiant la requête.

En-têtes

La requête canonique comprend les en-têtes qui doivent faire partie de toute requête utilisant l'URL signée, y compris les en-têtes personnalisés et les en-têtes d'extension commençant par x-goog. Vous spécifiez les en-têtes dans plusieurs parties de la requête canonique :

  1. Spécifiez les noms des en-têtes dans le paramètre de chaîne de requête X-Goog-SignedHeaders, en séparant chaque nom par un point-virgule (;).
  2. Spécifiez l'en-tête name:value après la partie chaîne de requête de la requête canonique, en séparant chaque paire par une nouvelle ligne (\n).
  3. Spécifiez les noms des en-têtes sur une nouvelle ligne après la liste des paires name:value des en-têtes, en séparant chaque nom par un point-virgule (;).

Lorsque vous spécifiez les paires name:value des en-têtes, tenez compte des points suivants :

  • Tous les noms des en-têtes doivent apparaître en minuscules.
  • Tous les en-têtes doivent être classés par nom d'en-tête en appliquant un ordre de tri lexicographique aux valeurs de point de code.
  • Éliminez les en-têtes en double en créant un nom d'en-tête avec une liste de valeurs séparées par des virgules. Assurez-vous qu'il n'y a pas d'espace entre les valeurs et que l'ordre de la liste correspond à l'ordre dans lequel les en-têtes apparaissent dans votre requête. Pour plus d'informations, consultez la section 3.2 du document RFC 7230.
  • Remplacez les espaces de fin de ligne ou les nouvelles lignes (CRLF ou LF) par un seul espace. Pour plus d'informations sur les espaces de fin de ligne, consultez la section 3.2.4 du document RFC 7230.
  • Supprimez tous les espaces autour des deux points qui apparaissent après le nom de l'en-tête.

    Par exemple, le fait d'utiliser l'en-tête personnalisé x-goog-acl: private sans supprimer l'espace après les deux points renvoie une erreur 403 Forbidden, car la signature de requête que vous avez calculée ne correspond pas à la signature calculée par Google.

Par exemple, si vous disposez de l'ensemble d'en-têtes suivant :

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

la construction dans la requête canonique se présente comme suit :

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

En-têtes obligatoires

La plupart des en-têtes, tels que les en-têtes content-type et les en-têtes d'extension, sont ajoutés en fonction des besoins. Cependant, l'en-tête suivant est obligatoire dans chaque URL signée :

  • host : URI utilisé pour accéder à Cloud Storage.

En outre, les en-têtes suivants ne peuvent pas être utilisés dans les requêtes utilisant une URL signée, à moins d'être explicitement spécifiés dans la requête canonique.

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

Champ d'application des identifiants

Le champ d'application des identifiants apparaît à la fois dans la chaîne à signer et dans le paramètre de chaîne de requête X-Goog-Credential. Il dispose de la structure suivante :

[DATE]/[LOCATION]/storage/goog4_request
  • [DATE] : date au format AAAAMMJJ, qui doit correspondre au jour utilisé dans la chaîne à signer.
  • [LOCATION] : région où la ressource réside ou sera créée. Pour les ressources Cloud Storage, la valeur [LOCATION] est arbitraire. En effet, le paramètre [LOCATION] existe pour maintenir la compatibilité avec Amazon Simple Storage Service (Amazon S3).
  • storage : nom du service.
  • goog4_request : type d'URL signée.

Exemple : 20181102/us/storage/goog4_request

Signer des chaînes avec les outils Google Cloud Platform

Lors de la génération d'une URL signée à l'aide d'un programme, l'une des options pour signer la chaîne consiste à utiliser les outils fournis par GCP.

Service App Identity d'App Engine

La signature dans une application App Engine utilise le service App Identity, qui intègre les identifiants du compte de service App Engine. Par exemple, avec l'API App Identity pour Python, vous pouvez :

  • utiliser la fonction google.appengine.api.app_identity.sign_blob() pour signer les octets de la chaîne que vous avez créée, fournissant ainsi la Signature dont vous avez besoin dans l'assemblage de l'URL signée ;

  • utiliser la fonction google.appengine.api.app_identity.get_service_account_name() pour récupérer un nom de compte de service, qui est l'identifiant GoogleAccessId dont vous avez besoin dans l'assemblage de l'URL signée.

App Engine est également compatible avec d'autres langages :

Le service App Identity fonctionne par rotation des clés privées lors de la signature des blobs. Les URL signées générées à l'aide du service App Identity ont une durée de validité d'environ une heure et sont donc de préférence utilisées pour les accès de courte durée aux ressources.

IAM signBlob

La signature peut être effectuée à l'aide de la méthode IAM signBlob.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.