¿Qué es la seguridad de las CDN?

La seguridad de CDN comprende los controles que protegen el contenido entregado desde los nodos perimetrales y sus orígenes. Entre las medidas habituales se incluyen TLS, solicitudes firmadas, reglas de acceso, límites de frecuencia y mitigación de ataques de denegación de servicio.

Una CDN se sitúa entre los espectadores y el origen, por lo que tiene dos lados que proteger. Del lado de los espectadores, termina las conexiones TLS, puede absorber tráfico abusivo o limitar su frecuencia y puede exigir que cada solicitud demuestre su autorización, normalmente mediante una URL firmada o una cookie firmada que incluye una fecha de vencimiento y se verifica en el borde. Amazon CloudFront valida primero la firma y la política y solo entonces consulta su caché de borde o reenvía la solicitud; Google Cloud CDN rechaza una solicitud con una firma incorrecta sin enviarla al backend. Validar una firma presente no equivale a exigirla: CloudFront exige solicitudes firmadas solo para los archivos que coinciden con un comportamiento de caché que tiene un firmante, y Cloud CDN no bloquea una solicitud que no incluye ninguna firma, por lo que, en ese caso, el origen debe rechazarla. Como la propia CDN verifica la firma, la firma no tiene por qué fragmentar la caché: Cloud CDN indica que todas las solicitudes firmadas válidas para la misma URL base comparten una entrada de caché y que las solicitudes firmadas y sin firmar nunca comparten una entrada. Por separado, cuando una solicitud incluye un encabezado Authorization, una caché compartida no debe reutilizar la respuesta a menos que se autorice explícitamente con public, s-maxage o must-revalidate (RFC 9111). Del lado del origen, la CDN es simplemente otro cliente HTTP: el origen acepta solicitudes directas a menos que se restrinja su acceso a la CDN, y la conexión entre ambos se cifra solo si así se configura. La firma controla quién puede obtener una respuesta desde el borde. No cifra el contenido multimedia.

¿Una URL firmada identifica al espectador? No. Es una credencial al portador: la documentación de Cloud CDN de Google indica que cualquier persona que conozca la URL puede usarla hasta que venza o se rote la clave de firma y, por ese motivo, recomienda plazos de validez cortos y distribuir las URL firmadas solo a través de HTTPS. Amazon CloudFront también puede restringir una política personalizada a una dirección IP o un rango de direcciones IP. Un plazo de validez corto tiene un costo, porque el vencimiento se comprueba en cada solicitud: CloudFront documenta que una descarga que ya está en curso se completa, pero una que se reanuda después del vencimiento falla, al igual que cualquier solicitud de rango posterior. Por lo tanto, si el plazo de validez es más corto que la sesión de reproducción, la siguiente solicitud después del vencimiento se rechaza, a menos que la aplicación ya haya emitido una nueva credencial con un vencimiento posterior.
¿URL firmadas o cookies firmadas para HLS y DASH? Una lista de reproducción o un manifiesto apunta a muchas URL de segmentos, y cada solicitud debe estar autorizada, por lo que una firma en la URL de la lista de reproducción no autoriza por sí sola las solicitudes de segmentos. Tanto CloudFront como Cloud CDN recomiendan cookies firmadas cuando el acceso abarca varios archivos, y ambos citan el video HLS como ejemplo; en Cloud CDN, la cookie autoriza todas las URL bajo un prefijo hasta su vencimiento, por lo que no es necesario reescribir los manifiestos para cada espectador, y el acceso puede renovarse en segundo plano con plazos de validez cortos. Es posible firmar la URL de cada segmento para cada espectador, pero, en palabras de Google, resulta laborioso. Las URL firmadas siguen siendo la opción para archivos individuales y para clientes que no admiten cookies. En ambas CDN, una URL firmada tiene prioridad cuando una solicitud incluye ambas.
¿Por qué una URL firmada generada correctamente devuelve 403? Una causa documentada es que la solicitud ya no coincide con lo que se firmó. CloudFront devuelve 403 cuando se añade una cadena de consulta a una URL después de firmarla, y Cloud CDN exige que sus parámetros de firma sigan un orden fijo y mantengan las mayúsculas y minúsculas. Cuando se firma la URL completa, todo lo que un reproductor, proxy u origen necesite en la cadena de consulta debe estar en la URL antes de calcular la firma. Las credenciales con permisos restringidos por prefijo funcionan de otra manera: las firmas de prefijos de URL y las cookies firmadas de Cloud CDN no abarcan los parámetros de consulta, por lo que se aceptan parámetros adicionales, pero no están protegidos contra modificaciones. En CloudFront, el recurso especificado en la política personalizada de una cookie firmada es la URL con su cadena de consulta, y un comodín en ese recurso puede coincidir con una cadena de consulta añadida. La rotación de claves es otra causa documentada: Cloud CDN deja de aceptar una URL cuando se elimina su clave de firma, y el procedimiento de CloudFront añade la nueva clave pública, pasa a firmar con ella y elimina la clave anterior solo después de que hayan vencido todas las URL o cookies firmadas con ella.
¿Basta con verificar las firmas en el borde si el origen es accesible públicamente? No. La documentación de CloudFront indica que no es obligatorio restringir el origen para que funcionen las URL firmadas, pero lo recomienda porque, de lo contrario, alguien puede eludir CloudFront usando la URL del propio origen; Cloud CDN señala lo mismo sobre los buckets de almacenamiento en la nube. Para un bucket, esto significa eliminar el acceso público de lectura y concedérselo únicamente a la CDN: mediante un control de acceso al origen en CloudFront o a la cuenta de servicio de Cloud CDN en Google Cloud Storage. Restringir el acceso a un bucket no vacía la caché: Cloud CDN responde a una solicitud sin firma desde una entrada de caché que ya exista, y una entrada normalmente permanece hasta que vence o se expulsa, por lo que debes invalidar todo lo que se almacenó en caché mientras el bucket era público una vez que el origen rechace las solicitudes sin firma. Para otros orígenes, los métodos ofrecen distintos niveles de seguridad: Cloudflare clasifica un encabezado secreto de solicitud o una lista de rangos de IP permitidos de la CDN como moderadamente seguros, y TLS mutuo (Authenticated Origin Pulls) o un túnel como muy seguros. HTTPS para los espectadores tampoco cubre el tramo hasta el origen. En el modo Flexible de Cloudflare, que se aplica a HTTPS de los espectadores en el puerto predeterminado 443, Cloudflare se conecta al origen mediante HTTP sin cifrar, y CloudFront tiene una configuración de protocolo independiente para cada origen, por lo que un encabezado con un secreto compartido solo está protegido cuando ese tramo también está cifrado.

Configura estos controles cuando el contenido multimedia deba llegar solo a espectadores autorizados o cuando sea necesario detener el tráfico abusivo antes de que llegue al origen. Los fallos apuntan en direcciones opuestas: una firma que ha vencido o ya no coincide con la solicitud bloquea el acceso de espectadores legítimos, mientras que un origen que sigue respondiendo a solicitudes directas, o una ruta de CDN que atiende solicitudes sin firma, permite que cualquiera se salte las comprobaciones. Antes del lanzamiento, solicita archivos protegidos sin firma tanto a través de la CDN como desde el nombre de host del propio origen, incluidos los archivos que la CDN almacenó en caché mientras aún eran públicos; todas esas solicitudes deben rechazarse.

Smart CDN de Transloadit admite URL firmadas. Tu backend calcula una firma HMAC-SHA256 con el Auth Secret sobre el nombre del Workspace, el nombre del Template, la ruta del archivo y los parámetros de consulta ordenados, y la añade como sig junto a un vencimiento exp. Como los parámetros de transformación forman parte de la cadena firmada, una URL firmada cuyos parámetros se cambian después ya no coincide con su firma. Esto solo bloquea las solicitudes alteradas si se rechazan las solicitudes sin firma, y las páginas enlazadas no describen cómo se trata una solicitud sin firma al mismo Template, así que pruébalo en tu propio Workspace antes de confiar en la firma. El vencimiento también limita cuánto tiempo puede permanecer en caché un resultado recién generado, por lo que un exp más corto restringe más el acceso a costa de la reutilización de la caché.

exp se expresa en milisegundos desde la época Unix; la documentación lo describe como opcional, pero recomienda encarecidamente configurarlo. Las firmas deben generarse en el servidor porque usan el Auth Secret, y la Auth Key debe estar habilitada para usar Smart CDN. Transloadit describe Smart CDN como una capa de transformación y entrega que no sustituye la política de autorización de tu aplicación: la decisión sobre qué espectador recibe una URL firmada sigue estando en tu código.

Explora las capacidades de entrega de Transloadit

¿Qué es la seguridad de las CDN?

Cómo funciona la seguridad de las CDN

Datos clave

Cuándo importa la seguridad de las CDN

Cómo ayuda Transloadit con la seguridad de las CDN

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional