URL signées

Cette page présente les URL signées, qui donnent un accès limité dans le temps à une ressource Cloud Storage spécifique. Toute personne disposant de l'URL signée peut l'utiliser lorsqu'elle est active, qu'elle possède 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 devez spécifier un compte disposant des autorisations suffisantes pour effectuer la requête adressée par l'URL signée.

    • Dans la plupart des cas, il s'agit d'un compte de service.

    • Si vous créez votre propre programme pour générer des URL signées, il est possible d'utiliser un compte utilisateur, si celui-ci est associé à une clé HMAC.

Une fois l'URL signée générée, toute personne qui en dispose 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. Vous spécifiez une heure d'expiration lors de la création de l'URL signée. Toute personne connaissant l'URL peut accéder à la ressource jusqu'à ce que l'heure d'expiration de cette URL soit atteinte ou jusqu'à la rotation de la clé utilisée pour signer l'URL.

Les utilisations les plus courantes des URL signées sont les importations et les téléchargements, car dans ce cas, les données d'objet sont déplacées entre les demandeurs et Cloud Storage. Dans la plupart des autres cas, tels que la copie d'objets, la composition d'objets ou la modification de métadonnées, la création d'une URL signée et son attribution à un utilisateur constitue une étape supplémentaire inutile. Vous devriez plutôt envisager une conception dans laquelle l'entité responsable de la création de l'URL signée envoie directement la requête souhaitée à Cloud Storage.

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 service : ce mécanisme de signature est décrit ci-dessous.

  • 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, de pointer vers l'hôte storage.googleapis.com et d'utiliser les identifiants HMAC Cloud Storage 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-central1%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 : informations sur les 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. Dans cet exemple, l'URL signée expire dans 15 minutes. La valeur d'expiration la plus longue est de 604 800 secondes (sept jours).

  • 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

En général, il n'est pas nécessaire de créer des URL signées pour les importations avec reprise, car après la requête d'importation, les requêtes PUT suivantes pour importer les données de l'objet utilisent un URI de session, qui sert de jeton d'authentification. Cela signifie que les requêtes PUT n'utilisent aucune URL signée.

Bien que vous puissiez créer et utiliser une URL signée pour la requête POST initiale afin de lancer l'importation, dans la plupart des cas, le serveur peut lancer l'importation avec reprise à la place. Le serveur envoie ensuite l'URI de session au client pour effectuer l'importation. Cela évite la complexité de faire créer une URL signée par le serveur, ainsi que la complexité de faire gérer l'URL signée par le client et d'initier l'importation pouvant être reprise.

Comme les URL signées, un URI de session peut être utilisé par toute personne en sa possession pour importer des données. Important : Assurez-vous de transmettre l'URI de session via HTTPS lorsque vous le communiquez à un client.

Considérations relatives aux URL signées

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

  • Les URL signées ne peuvent être utilisées que pour accéder aux ressources Cloud Storage via des points de terminaison d'API XML.

  • Les URL signées peuvent généralement être créées pour toute requête de l'API XML. Il existe toutefois deux exceptions :

    • Les URL signées qui utilisent des signatures V4 ne peuvent pas être utilisées dans les requêtes dont le corps utilise l'encodage fragmenté.

    • Pour le moment, les bibliothèques clientes Node.js de Cloud Storage ne peuvent 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.

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

  • Veillez à omettre l'en-tête d'autorisation des requêtes utilisant une URL signée. Si les deux sont utilisés, Cloud Storage peut s'authentifier sur les identifiants fournis dans l'en-tête plutôt que sur l'URL signée. Cela pourrait permettre des accès indésirables aux ressources.

Requêtes canoniques

Les URL signées utilisent des requêtes canoniques dans le cadre des informations codées dans leur paramètre de chaîne de requête X-Goog-Signature. Lorsque vous créez une URL signée avec les outils Cloud Storage, la requête canonique requise est créée et intégrée automatiquement. Toutefois, lorsque vous créez une URL signée avec votre propre programme, vous devez définir vous-même la requête canonique et l'utiliser pour créer une signature.

Niveau d'accès 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.

Étapes suivantes