Qu’est-ce que la sécurité des CDN ?

La sécurité d’un CDN regroupe les contrôles qui protègent le contenu diffusé depuis la périphérie et ses origines. Les mesures courantes comprennent TLS, les requêtes signées, les règles d’accès, les limites de débit et l’atténuation des attaques par déni de service.

Un CDN se situe entre les spectateurs et l’origine et doit donc sécuriser deux côtés. Côté spectateurs, il termine la connexion TLS, peut absorber le trafic abusif ou en limiter le débit, et peut exiger que chaque requête prouve qu’elle est autorisée, généralement avec une URL signée ou un cookie signé comportant une date d’expiration et vérifié en périphérie. Amazon CloudFront valide d’abord la signature et la politique, puis seulement consulte son cache périphérique ou transmet la requête ; Google Cloud CDN rejette une requête dont la signature est incorrecte sans l’envoyer au serveur d’origine. Valider une signature présente ne revient pas à en exiger une : CloudFront n’exige des requêtes signées que pour les fichiers correspondant à un comportement de cache doté d’un signataire, et Cloud CDN ne bloque pas les requêtes sans aucune signature. Dans ce dernier cas, c’est donc à l’origine de les refuser. Comme le CDN vérifie lui-même la signature, la signature des requêtes ne fragmente pas nécessairement le cache : Cloud CDN indique que toutes les requêtes signées valides pour une même URL de base partagent une entrée de cache, et que les requêtes signées et non signées n’en partagent jamais une. Par ailleurs, lorsqu’une requête comporte un en-tête Authorization, un cache partagé ne doit pas réutiliser la réponse, sauf si celle-ci l’autorise explicitement avec public, s-maxage ou must-revalidate (RFC 9111). Côté origine, le CDN est un client HTTP comme un autre : l’origine accepte les requêtes directes à moins que son accès ne soit réservé au CDN, et la connexion entre les deux n’est chiffrée que si cela a été configuré. La signature contrôle qui peut récupérer une réponse depuis la périphérie. Elle ne chiffre pas les médias.

Une URL signée identifie-t-elle le spectateur ? Non. Il s’agit d’une information d’identification au porteur : la documentation Cloud CDN de Google indique que toute personne connaissant l’URL peut l’utiliser jusqu’à son expiration ou jusqu’au remplacement de la clé de signature. Pour cette raison, elle recommande des délais d’expiration courts et de ne transmettre les URL signées que via HTTPS. Amazon CloudFront peut en outre limiter une politique personnalisée à une adresse ou à une plage d’adresses IP. Une courte durée de validité a un coût, car l’expiration est vérifiée à chaque requête : CloudFront précise qu’un téléchargement déjà en cours se termine, mais qu’une reprise après l’heure d’expiration échoue, tout comme toute requête de plage d’octets ultérieure. Si la durée de validité est plus courte que la session de lecture, la requête suivant l’expiration est donc refusée, à moins que l’application ait entre-temps émis une nouvelle information d’identification dont l’expiration est plus tardive.
URL signées ou cookies signés pour HLS et DASH ? Une liste de lecture ou un manifeste pointe vers de nombreuses URL de segments, et chaque requête doit être autorisée. Une signature sur l’URL de la liste de lecture n’autorise donc pas à elle seule les requêtes de segments. CloudFront et Cloud CDN recommandent tous deux les cookies signés lorsque l’accès concerne plusieurs fichiers, et citent tous deux la vidéo HLS comme exemple ; dans Cloud CDN, le cookie autorise l’accès à chaque URL sous un préfixe jusqu’à son expiration. Il n’est donc pas nécessaire de réécrire les manifestes pour chaque spectateur, et l’accès peut être renouvelé en arrière-plan avec des délais d’expiration courts. Signer chaque URL de segment pour chaque spectateur est possible, mais contraignant, selon Google. Les URL signées restent le choix à privilégier pour les fichiers individuels et les clients qui ne prennent pas en charge les cookies. Sur les deux CDN, une URL signée est prioritaire lorsqu’une requête comporte les deux.
Pourquoi une URL signée correctement générée renvoie-t-elle 403 ? Une cause documentée est que la requête ne correspond plus à ce qui a été signé. CloudFront renvoie 403 lorsqu’une chaîne de requête est ajoutée à une URL après sa signature, et Cloud CDN exige que ses paramètres de signature respectent un ordre fixe, sans modification de la casse. Lorsque l’URL entière est signée, tout ce dont un lecteur, un proxy ou l’origine a besoin dans la chaîne de requête doit figurer dans l’URL avant le calcul de la signature. Les informations d’identification limitées à un préfixe fonctionnent différemment : les signatures de préfixe d’URL et les cookies signés de Cloud CDN ne couvrent pas les paramètres de requête. Des paramètres supplémentaires sont donc acceptés, mais ne sont pas protégés contre les modifications. Sur CloudFront, la ressource désignée dans la politique personnalisée d’un cookie signé est l’URL avec sa chaîne de requête, et un caractère générique dans cette ressource peut correspondre à une chaîne de requête ajoutée. La rotation des clés est une autre cause documentée : Cloud CDN cesse d’accepter une URL dès que sa clé de signature est supprimée. La procédure de CloudFront consiste à ajouter la nouvelle clé publique, à l’utiliser pour signer, puis à supprimer l’ancienne clé uniquement après l’expiration de toutes les URL et de tous les cookies signés avec celle-ci.
Vérifier les signatures en périphérie suffit-il si l’origine est accessible publiquement ? Non. La documentation de CloudFront indique qu’il n’est pas nécessaire de restreindre l’accès à l’origine pour que les URL signées fonctionnent, mais le recommande, car il est sinon possible de contourner CloudFront avec l’URL propre à l’origine ; Cloud CDN fait le même constat pour les buckets de stockage. Pour un bucket, cela signifie supprimer l’accès public en lecture et l’accorder uniquement au CDN : via un contrôle d’accès à l’origine sur CloudFront, ou au compte de service Cloud CDN sur Cloud Storage. Verrouiller un bucket ne vide pas le cache : Cloud CDN répond à une requête non signée à partir d’une entrée de cache déjà présente, et une entrée reste normalement en cache jusqu’à son expiration ou son éviction. Invalidez donc tout ce qui a été mis en cache pendant que le bucket était public, une fois que l’origine refuse les requêtes non signées. Pour les autres origines, les méthodes offrent différents niveaux de sécurité : Cloudflare considère qu’un en-tête de requête secret ou une liste d’autorisation des plages d’adresses IP du CDN est modérément sécurisé, et que le TLS mutuel (Authenticated Origin Pulls) ou un tunnel est très sécurisé. HTTPS côté spectateurs ne couvre pas non plus la liaison avec l’origine. Dans le mode Flexible de Cloudflare, qui s’applique aux connexions HTTPS des spectateurs sur le port par défaut 443, Cloudflare se connecte à l’origine en HTTP non chiffré. CloudFront dispose quant à lui d’un réglage de protocole distinct pour chaque origine. Un en-tête contenant un secret partagé n’est donc protégé que si cette liaison est elle aussi chiffrée.

Configurez ces contrôles lorsque les médias doivent être accessibles uniquement aux spectateurs autorisés ou lorsque le trafic abusif doit être arrêté avant d’atteindre l’origine. Les défaillances ont des effets opposés : une signature expirée ou qui ne correspond plus à la requête bloque les spectateurs légitimes, tandis qu’une origine répondant encore aux requêtes directes, ou un chemin du CDN servant des requêtes sans signature, permet à quiconque de contourner les vérifications. Avant la mise en service, demandez les fichiers protégés sans signature, à la fois via le CDN et depuis le nom d’hôte propre à l’origine, y compris les fichiers que le CDN a mis en cache alors qu’ils étaient encore publics ; chacune de ces requêtes doit être refusée.

Le Smart CDN de Transloadit prend en charge les URL signées. Votre serveur calcule une signature HMAC-SHA256 avec l’Auth Secret à partir du nom du Workspace, du nom du Template, du chemin du fichier et des paramètres de requête triés, puis l’ajoute comme paramètre sig, à côté du paramètre exp qui indique l’expiration. Comme les paramètres de transformation font partie de la chaîne signée, une URL signée dont les paramètres sont modifiés ensuite ne correspond plus à sa signature. Cela ne bloque les requêtes modifiées que si les requêtes non signées sont refusées. Les pages liées ne décrivent pas le traitement d’une requête non signée adressée au même Template ; testez donc ce comportement dans votre propre Workspace avant de vous fier à la signature. L’expiration limite également la durée pendant laquelle un résultat nouvellement généré peut rester en cache. Une échéance plus proche définie avec le paramètre exp renforce donc les restrictions d’accès au détriment de la réutilisation du cache.

Le paramètre exp est exprimé en millisecondes depuis l’époque Unix ; la documentation le décrit comme facultatif, mais recommande fortement de le définir. Les signatures doivent être générées côté serveur, car elles utilisent l’Auth Secret, et l’Auth Key doit être activée pour l’utilisation du Smart CDN. Transloadit décrit le Smart CDN comme une couche de transformation et de diffusion qui ne remplace pas la politique d’autorisation de votre application : la décision d’attribuer une URL signée à un spectateur reste dans votre code.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce que la sécurité des CDN ?

Comment fonctionne la sécurité des CDN

Points clés

Quand la sécurité des CDN est importante

Comment Transloadit contribue à la sécurité des CDN

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle