Cette page décrit brièvement les options fournies par Media CDN pour empêcher la distribution non autorisée de votre contenu.
Media CDN propose les options suivantes pour protéger votre contenu contre une distribution non autorisée.
Jetons (approche recommandée) : Media CDN utilise des jetons pour protéger le contenu.
Un jeton est un support d'échange de requêtes signées tel qu'un cookie signé, un URI avec des paramètres de requête ou un composant de chemin d'accès. Les jetons valides présentés par les spectateurs sont utilisés pour authentifier l'accès à votre contenu. Un spectateur avec un si un jeton est incorrect ou manquant, l'utilisateur ne pourra pas accéder à votre contenu.
Vous pouvez choisir d'utiliser une authentification à jeton unique ou à double jeton. Les jetons sont requis pour l'authentification à double jeton.
Lorsque l'authentification à double jeton est utilisée, Media CDN utilise deux un jeton de courte durée et un jeton de longue durée.
Google recommande d'utiliser des jetons pour les nouvelles intégrations, car ils présentent les avantages suivants :
- Assurez la compatibilité avec les réseaux de diffusion de contenu (CDN) autres que Google.
- Prise en charge de la signature sur chemin d'accès uniquement.
- Activer la signature de plusieurs en-têtes.
- Proposez un contrôle précis des accès et une révocation.
- Minimisez l'impact des jetons compromis.
- Peut intégrer des données et des identifiants de session arbitraires.
Signatures : Media CDN utilise une seule signature pour protéger le contenu. Les signatures vous permettent d'effectuer une signature d'URL complète, y compris concernant l'hôte et le protocole.
Vous pouvez utiliser les deux options en même temps pour protéger votre contenu.
Fonctionnement de l'authentification à double jeton
L'authentification à doule jeton utilise deux jetons pour authentifier les requêtes adressées à votre contenu : un jeton de courte durée pour le lancement de la lecture et un jeton de longue durée pour le reste de la session de lecture.
Pour utiliser l'authentification à double jeton, vous devez configurer votre serveur d'applications pour émettre des jetons de courte durée aux agents utilisateur. Ensuite, vous configurez Media CDN pour répondre aux jetons de courte durée. Vous pouvez placer le jeton dans un paramètre de requête de votre choix ou le placer dans un cookie. Pour en savoir plus, consultez Utilisez l'authentification à double jeton.
Les jetons de courte durée générés par votre serveur d'applications contribuent à protéger les instances (parfois appelés playlists de multivariantes). Le délai d'expiration de la requête signée est suffisamment court pour demander un fichier manifeste principal, mais pas pour observer tout le contenu d'un fichier manifeste.
Lorsque Media CDN reçoit une requête avec un jeton de courte durée autorisé, il génère un jeton de longue durée signé. Vous pouvez utiliser le jeton dans un paramètre de requête portant un nom unique ou dans un cookie. Le jeton de longue durée permet d'afficher un programme complet. Les jetons de longue durée signés générés par Media CDN utilisent des signatures Ed25519 signées avec des clés gérées par Google associées à une ressource EdgeCacheKeyset
.
Vous pouvez personnaliser le délai d'expiration des jetons de courte durée et de longue durée. La bonne pratique recommandée consiste à configurer un délai d'expiration d'une minute pour les jetons de courte durée générés sur votre serveur d'applications. Vous devez définir le délai d'expiration des jetons de longue durée générés par Media CDN sur une durée supérieure à la durée de votre contenu, avec une durée maximale d'un jour.
Flux de requêtes pour l'authentification par double jeton
La section suivante décrit le flux de requête :
Un visiteur demande des métadonnées à votre serveur d'applications pour le contenu multimédia qu'il souhaite afficher. Votre serveur d'applications renvoie l'URI du fichier manifeste principal signé avec un jeton de courte durée.
Votre application de lecteur demande le fichier manifeste principal à Media CDN. La requête inclut le jeton de courte durée en tant que valeur d'un paramètre de requête d'URI au format de paramètre de requête nommé unique.
Media CDN vérifie le jeton de courte durée et les paramètres signés du jeton.
- Si le jeton est valide, Media CDN crée un jeton de signature de longue durée. Media CDN renvoie le jeton dans un en-tête Set-Cookie ou en modifiant les URI du fichier manifeste et du segment dans le fichier manifeste principal de manière à inclure le jeton.
- Si le jeton n'est pas valide, Media CDN envoie une réponse
HTTP 403 Forbidden
.
L'application de lecteur reçoit le fichier manifeste principal de Media CDN, puis demande la playlist de contenu multimédia ou les segments multimédias référencés dans le fichier manifeste principal. La requête doit inclure le jeton de longue durée, soit en tant que cookie signé, soit en tant que paramètre d'URI.
Media CDN vérifie le jeton de signature de longue durée :
- Si le jeton de longue durée est valide pour la requête spécifique, Media CDN diffuse le contenu demandé.
- Si le jeton de longue durée n'est pas valide (jeton arrivé à expiration ou chemin non valide), Media CDN envoie une réponse
HTTP 403 Forbidden
.
Le processus se répète jusqu'à la fin de la lecture du contenu multimédia ou jusqu'à l'expiration de la signature de longue durée.
Formats de jetons compatibles pour les requêtes signées à double jeton
Les requêtes signées par double jeton Media CDN acceptent plusieurs formats, en fonction du type de jeton.
Requêtes signées de courte durée
Pour les requêtes signées de courte durée, Media CDN accepte par défaut les jetons signés avec des signatures Ed25519. Vous pouvez également utiliser des codes HMAC (Hash-based Message Authentification Code) pour assurer la compatibilité avec le code d'application existant et avec les autres CDN.
Pour utiliser les codes HMAC, stockez le secret HMAC en utilisant Secret Manager. Vous accordez ensuite l'accès au compte de service Media CDN pour qu'il puisse accéder au secret stocké. Google recommande d'utiliser en utilisant la signature asymétrique avec des signatures Ed25519 pour la sécurité et les performances.
Le compte de service Media CDN appartient au projet Media CDN et ne s'affiche pas dans la liste des comptes de service de votre projet. Le compte de service n'accorde l'accès qu'aux ressources Media CDN des projets que vous autorisez explicitement.
Le compte de service a le format suivant :
service-PROJECT_NUMBER@gcp-sa-mediaedgefill.iam.gserviceaccount.com
Où PROJECT_NUMBER est le numéro de votre projet.
Pour activer le compte de service Media CDN du service, créez au moins une ressource Media CDN (par exemple, EdgeCacheOrigin
).
Requêtes signées de longue durée
Pour les requêtes signées de longue durée, Media CDN utilise des signatures Ed25519 signées avec des clés gérées par Google associées à une ressource EdgeCacheKeyset
.
Media CDN accepte un format de jeton unique pour les jetons de longue durée, qui peut être utilisé dans un paramètre de requête portant un nom unique pour les flux HLS, ou dans un cookie.
Fonctionnement des requêtes signées
Une requête signée utilise des signatures ou des jetons pour vérifier que chaque visiteur est authentifié pour accéder au contenu. Vous pouvez configurer Media CDN de sorte que l'accès soit limité à l'un des éléments suivants :
- Un URI ou un préfixe d'URI spécifique, pendant une durée limitée.
- Un client spécifique.
- Pour les requêtes signées utilisant des jetons, jusqu'à cinq chemins d'accès avec des caractères génériques.
Pour utiliser des requêtes signées, vous devez générer des clés pour signer et valider les signatures. Vous configurez ensuite des routes, ce qui vous permet d'optimiser le comportement en fonction du type de contenu, des attributs client et de vos exigences d'actualisation. Les requêtes signées peuvent être appliquées individuellement par route, ce qui vous aide à protéger des points de terminaison spécifiques.
Chaque service Media CDN peut utiliser une collection de plusieurs clés. La collection de clés est également appelée keyset. Les collections de clés vous permettent d'alterner les clés et de distribuer des clés privées sur votre propre infrastructure sans interruption.
Vous pouvez configurer Media CDN pour qu'il utilise des requêtes signées ou des jetons afin de protéger le contenu.
Pour les requêtes signées utilisant des jetons, vous pouvez placer le jeton dans l'un des éléments suivants :
- Un paramètre de requête de votre choix.
- Un cookie.
Pour en savoir plus, consultez la section Générer des jetons.
Pour les requêtes signées utilisant des signatures, vous pouvez utiliser l'un des formats suivants :
- Un URI exact avec des paramètres de requête: vous spécifiez un
URLPrefix
avec l'URI exact et ajouter les mêmes paramètres de requête à plusieurs URI. - Un préfixe d'URI avec des paramètres de requête: vous spécifiez un préfixe
URLPrefix
avec un préfixe d'URI et ajouter les mêmes paramètres de requête à plusieurs URI. - Un composant de chemin d'accès : vous spécifiez un composant de chemin d'accès, qui permet aux URI de fichier manifeste relatifs d'hériter du composant d'URI signé.
- Un cookie signé : vous spécifiez un préfixe d'URI dans un cookie, ce qui permet d'accéder à n'importe quel URI avec le préfixe que vous avez spécifié.
Pour en savoir plus, consultez la section Générer des signatures.
Remarques
Les sections suivantes décrivent différents facteurs à prendre en compte pour éviter la distribution non autorisée de vos contenus.
Points à noter concernant la sécurité
Media CDN valide toutes les requêtes correspondant à une route configurée avec
cdnPolicy.signedRequestMode
sur REQUIRE_SIGNATURES
ou REQUIRE_TOKENS
.
Nous vous recommandons de valider les requêtes à l'origine. Bien que Media CDN rejette les requêtes non valides et non signées pour une route qui nécessite des signatures, les clients peuvent trouver un moyen d'accéder directement à votre origine. Une couche de validation supplémentaire permet d'adopter une approche de défense en profondeur pour protéger vos contenus.
Le tableau suivant explique les scénarios de validation de Media CDN une requête:
La requête comporte une signature | Signature valide ? | signedRequestMode | Comportement | Code d'état |
---|---|---|---|---|
Non | N/A | REQUIRE_SIGNATURES ou REQUIRE_TOKENS |
Les requêtes sans signature ni jeton sont traitées comme si la signature était non valide. | HTTP 403 |
Oui | Non | REQUIRE_SIGNATURES ou REQUIRE_TOKENS |
Une signature ou un jeton est considéré comme non valide s'il a expiré ou si une URL non concordante ou clé incorrecte. Les signatures ou jetons non valides sont rejetés au niveau du CDN. | HTTP 403 |
Oui | Oui | REQUIRE_SIGNATURES ou REQUIRE_TOKENS |
Une signature ou un jeton est validé, et la réponse est diffusée avec le contenu d'un cache ou de l'origine. | HTTP 200 |
Oui | Oui | Aucune ou DISABLED |
Aucune validation n'est effectuée, et une réponse est directement envoyée à l'utilisateur. | HTTP 200 |
Oui | Non | Aucune ou DISABLED |
Aucune validation n'est effectuée, et une réponse est directement envoyée à l'utilisateur. | HTTP 200 |
Lorsque votre application détecte une signature non valide, assurez-vous que votre
l'application répond par un code d'état HTTP 403 (Forbidden)
.
Les codes d'état HTTP 403
ne peuvent pas être mis en cache.
Si votre application envoie un code d'état pouvant être mis en cache à une adresse les demandes futures valides risquent d'être refusées par erreur.
Limites applicables aux URI
La plupart des clients HTTP modernes acceptent des URI comportant jusqu'à 8 000 caractères. Cependant, certains appareils anciens ou spécifiques peuvent avoir des limites plus strictes. En général, un URI signé ajoute environ 125 caractères à l'URI de requête, qui inclut les éléments suivants :
- Si tous les noms de champs sont utilisés, environ 67 caractères pour chaque champ (
Expires=
etKeyName=
, par exemple). - Pour l'horodatage Unix, 10 caractères.
- Pour
KeyName
, 5 caractères. - Pour la valeur
Signature
encodée en base64, 43 caractères.
La bonne pratique consiste à limiter les URI à moins de 2 000 caractères en utilisant des paramètres de requête en tant que jetons. Utiliser des URI plus courts permet d'éviter que les appareils n'envoient des URI tronqués à Media CDN.
Anciens appareils de lecture de flux vidéo
Certains anciens appareils de lecture de flux vidéo peuvent ne pas être pleinement compatibles avec l'association de cookies aux fichiers manifestes ou aux requêtes de segments multimédias. Si vous utilisez des appareils souffrant de problèmes connus concernant la gestion des cookies HTTP, configurez Media CDN pour qu'il utilise les paramètres de requête pour les requêtes signées et l'échange de double jeton.
Conformité avec les règles de consentement et de confidentialité
Vous êtes seul responsable de la conformité avec les règles de consentement et de confidentialité lors de l'utilisation de cookies pour échanger des jetons de courte durée. Lorsque Media CDN est configuré pour utiliser des requêtes signées à double jeton, Google émet et gère les cookies utilisés pour les jetons de longue durée.
Facturation
Pour en savoir plus sur la facturation de Secret Manager, consultez la page Tarifs.
Les récupérations de secrets par Media CDN sont mises en cache en interne, ce qui réduit considérablement le taux de récupération des secrets depuis Secret Manager. La réduction du taux de récupération réduit également considérablement les taux d'accès à Secret Manager, et donc les montants facturés.
Pour en savoir plus sur la mise en cache des secrets dans Media CDN, consultez la page Présentation des clés.