Utiliser des requêtes signées

Pour créer une requête signée, composez une chaîne incluant des paramètres qui décrivent le contenu que vous souhaitez protéger et le délai d'expiration de la valeur signée. Vous incluez ensuite la chaîne composée dans votre requête. Media CDN vérifie ensuite que votre requête signée est valide avant de l'exécuter.

Conditions requises pour les requêtes signées

Les demandes signées doivent répondre aux exigences suivantes :

• Utiliser une méthode HTTP GET, HEAD ou OPTIONS. Les autres méthodes ne sont pas acceptées.

• avoir une heure d'expiration définie dans le futur ; En raison des différences potentielles de synchronisation de l'horloge, ainsi que des conditions du réseau client (par exemple, les déconnexions et les tentatives), nous vous recommandons de définir des codes temporels au moins une minute dans le futur, ou au moins la durée du flux vidéo, selon la valeur la plus élevée.

• avoir une signature qui peut être validée par une clé ou un code secret dans un EdgeCacheKeyset ;

Vous ne pouvez pas signer d'autres méthodes HTTP, telles que les requêtes POST, PUT ou DELETE. Si vous devez émettre des URL signées pour les importations destinées aux utilisateurs, consultez la documentation Cloud Storage sur les URL signées.

Configurer des requêtes signées

Les sections suivantes expliquent en détail comment configurer, signer et valider les requêtes signées.

Générer des clés

Créez les clés que Media CDN utilise pour signer les requêtes.

Créer une collection de clés

Créez la collection de clés que Media CDN utilise pour les requêtes signées.

Exiger des requêtes signées

Pour autoriser l'accès à une ressource uniquement aux requêtes signées, vous pouvez associer une liste de clés à une route et définir signedRequestMode sur l'une des valeurs suivantes :

• REQUIRE_SIGNATURES pour les requêtes signées n'utilisant pas de jetons.

• REQUIRE_TOKENS pour les requêtes signées utilisant des jetons.

L'activation des requêtes signées sur une route impose que toutes les requêtes soient signées ou présentent un jeton. Les requêtes sans signature valide (par exemple, nom de clé non valide, signature ou jeton expirés, signature non correspondante, etc.) échouent.

Un EdgeCacheKeyset peut contenir plusieurs clés pour permettre la rotation des clés. Les requêtes valides signées avec l'une des clés listées sont acceptées, et les clés sont testées dans l'ordre. Pour en savoir plus sur la rotation des clés, consultez Alterner les secrets.

Lorsque signedRequestMode est défini sur REQUIRE_SIGNATURES ou REQUIRE_TOKENS, Media CDN valide les accès au cache et les défauts de cache. Cela inclut toutes les requêtes adressées à l'origine.

Voici un exemple de configuration Media CDN qui applique les requêtes signées sur un PathMatcher (route) donné :

gcloud edge-cache services describe prod-media-service

Résultat :

...
  routeAction:
    cdnPolicy:
      cacheMode: CACHE_ALL_STATIC
      signedRequestMode: REQUIRE_SIGNATURES
      signedRequestKeyset: prod-vod-keyset

Pour savoir comment créer des jetons pour les requêtes signées, consultez Générer des jetons.

Pour désactiver la signature des requêtes, vous pouvez définir signedRequestMode sur DISABLED et supprimer la référence à signedRequestKeyset.

Valider les requêtes à l'origine

Lorsqu'une route est configurée avec un mode de signature REQUIRE_SIGNATURES, Media CDN valide que chaque requête correspondante possède une signature valide. L'absence de signature est considérée comme une signature non valide pour ces routes.

Avertissement : N'incluez pas d'informations confidentielles, sensibles ou permettant d'identifier personnellement l'utilisateur dans vos chemins d'URL ni dans vos paramètres de requête. Les URL, y compris l'hôte, le chemin d'accès et les paramètres de requête, sont traitées comme des données de service non identifiables conformément à la section 12 (Champs de ressources) des Conditions d'utilisation spécifiques au service. En termes de confidentialité et de sécurité, il est recommandé que les composants d'URL soient des identifiants opaques générés par le système, et non dérivés des entrées utilisateur.

Pour éviter les cas où la signature est mal configurée et où un utilisateur tente d'accéder directement à votre origine, nous vous recommandons de vérifier que les requêtes sont également signées au niveau de l'origine. Une approche de défense en profondeur pour la protection du contenu permet d'empêcher l'accès et le téléchargement non autorisés de vos contenus sous licence et payants.

Pour les méthodes de signature basées sur les URL, où la signature fait partie des paramètres de requête ou est intégrée en tant que composant de chemin d'URL, la signature et les paramètres associés sont supprimés de l'URL avant que la requête ne soit envoyée à l'origine. Cela empêche la signature de provoquer des problèmes de routage lorsque l'origine gère la requête. Pour valider ces requêtes, vous pouvez inspecter l'en-tête de requête x-client-request-url, qui inclut l'URL de la requête client d'origine (signée) avant la suppression des composants signés.

Remarque : Si vous utilisez Cloud Storage et que vous avez supprimé l'autorisation allUsers (accès public), Cloud Storage refuse l'accès public non authentifié au contenu en votre nom.

Pour valider les requêtes à l'origine, utilisez le même code de validation dans vos points de terminaison de signature de requêtes. Cela permet également d'atténuer les problèmes de clés non concordantes et ceux liés à la rotation des clés.

Rotation des clés

Il est recommandé de faire alterner ou de mettre à jour régulièrement les secrets utilisés par Media CDN. Nous vous recommandons d'alterner les clés tous les 30 à 60 jours, mais ce n'est pas strictement obligatoire.

Étapes suivantes

• Pour en savoir plus sur l'activation et l'accès aux journaux Media CDN, y compris sur le filtrage et l'interrogation de vos journaux, consultez Journalisation.

• Pour configurer Media CDN et un bucket Cloud Storage privé, consultez Connectivité et protection des origines.