¿Qué es una URL firmada?

Una URL firmada contiene una prueba criptográfica de que una parte autorizada concedió acceso a un recurso o una transformación. Su firma suele abarcar una fecha de vencimiento y una ruta o parámetros de consulta específicos de la solicitud.

Un firmante que posee una clave construye una cadena a partir de las partes de la solicitud que quiere autorizar, normalmente la ruta, determinados parámetros de consulta y un vencimiento, calcula una firma a partir de esa cadena y añade la firma a la URL. El servicio verifica la firma y comprueba el vencimiento antes de servir cualquier contenido. Son comunes dos modelos de claves. Con un HMAC, el firmante y el servicio poseen el mismo secreto; Google Cloud CDN y Smart CDN de Transloadit funcionan así. Con un par de claves, el firmante conserva una clave privada y el servicio solo necesita la clave pública; Amazon CloudFront verifica las firmas RSA o ECDSA con las claves públicas de un grupo de claves de confianza. En ambos casos se trata de autorización delegada, no de cifrado. AWS describe las URL prefirmadas como tokens Bearer, y Google indica que cualquiera que posea una URL firmada puede usarla mientras esté activa. Una URL prefirmada es el caso del almacenamiento de objetos: Amazon S3 usa ese nombre para una URL que incluye las credenciales de su creador para un bucket, una clave de objeto y un método HTTP, como una descarga mediante GET o una subida mediante PUT, mientras que Google Cloud Storage llama URL firmada a su equivalente.

¿Se puede añadir o modificar un parámetro de consulta después de firmar? Solo si el esquema lo deja fuera de la firma o la política firmada lo permite. CloudFront devuelve HTTP 403 cuando se añade una cadena de consulta a una URL firmada después de firmarla. Una política personalizada de CloudFront puede ampliar esta posibilidad: su URL Resource puede contener comodines, CloudFront compara la URL solicitada con ese patrón y un asterisco al final de la ruta también abarca la cadena de consulta. imgix devuelve 403 cuando la ruta o los parámetros cambian después de establecer su parámetro s. Los esquemas que firman una solicitud canónica también son sensibles a cómo se realiza la solicitud: las firmas de S3 y Google Cloud Storage V4 abarcan el método HTTP, la ruta, la cadena de consulta ordenada y el encabezado host, por lo que una URL firmada para un método o nombre de host no es válida para otro. Google Cloud CDN hace una excepción deliberada cuando firmas un URLPrefix en lugar de la URL completa: en ese caso, los parámetros de consulta no se firman y se pueden incluir libremente, y una firma es válida para todas las URL que comienzan con el prefijo.
¿Por qué dejaría de funcionar una URL prefirmada antes del vencimiento establecido? Por lo general, porque las credenciales en las que se basa vencieron primero. AWS indica que una URL prefirmada de S3 vence en el momento configurado o cuando vencen las credenciales con las que se creó, lo que ocurra primero, por lo que una URL firmada con credenciales temporales de un rol deja de ser válida al terminar la sesión del rol, aunque se haya solicitado una vigencia mayor. Las URL firmadas de Google Cloud Storage también dejan de funcionar cuando se rota la clave usada para firmarlas. AWS también incluye el desfase del reloj de la máquina que firma y los proxies que modifican encabezados o cadenas de consulta entre las causas de discrepancias en las firmas. Firma con credenciales cuya vigencia supere la de la URL o emite URL con una vigencia menor que la de la sesión.
¿Qué ocurre con una descarga o reproducción que sigue en curso al vencer la URL? El vencimiento se comprueba cuando llega cada solicitud HTTP, no mientras se envía una respuesta. Tanto S3 como CloudFront documentan que una descarga iniciada justo antes del vencimiento continúa y que un cliente que se reconecta después del vencimiento falla. En CloudFront, también falla cualquier solicitud Range GET emitida después del vencimiento. Por tanto, un reproductor que obtiene un archivo grande por rangos o un gestor que reanuda una descarga necesita una vigencia que cubra toda la sesión o una forma de obtener una URL nueva.
¿Exigir URL firmadas en la CDN protege el origen y se siguen almacenando en caché las respuestas firmadas? La CDN comprueba la firma; el origen es un punto de entrada independiente. AWS recomienda, pero no exige, restringir un bucket de S3 para que solo se pueda leer a través de CloudFront. Google advierte que Cloud CDN no bloquea las solicitudes sin firma, por lo que un origen de Cloud Storage situado detrás no debe ser público. En cuanto al almacenamiento en caché, CloudFront y Google Cloud CDN eliminan los parámetros de firma antes de reenviar una solicitud al origen, y Google valida primero la firma y después sirve el contenido desde la caché, almacenando por separado las respuestas a solicitudes firmadas y sin firmar. Esa separación no borra lo que se almacenó en caché mientras el contenido era público: Cloud CDN responde a una solicitud sin firma desde la caché si encuentra allí el contenido, así que, después de cerrar el acceso al origen, invalida las respuestas almacenadas previamente en caché o espera a que venzan. Algunos servicios vinculan la vigencia de la caché con el vencimiento: imgix reemplaza Cache-Control por el tiempo restante hasta expires.

Usa URL firmadas para dar a un navegador, reproductor o socio acceso temporal a contenido multimedia privado sin entregar credenciales de almacenamiento ni hacer público el origen. Una URL firmada autoriza a quien la posee, no a un usuario concreto, así que elige un plazo de validez que aceptarías para un enlace reenviado y añade otra comprobación cuando el acceso deba seguir vinculado a una sola persona.

Smart CDN de Transloadit acepta URL firmadas. Tu backend añade exp como marca de tiempo en milisegundos y el parámetro auth_key, ordena los parámetros de consulta, calcula un HMAC-SHA256 con el Auth Secret a partir del Workspace, el nombre del Template, la ruta del archivo y los parámetros ordenados, y añade el resultado como sig. Como los parámetros de transformación forman parte de la cadena firmada, una URL firmada no se puede editar para solicitar una variante diferente. El vencimiento también limita cuánto tiempo puede almacenarse en caché una respuesta firmada, por lo que un plazo más corto en exp restringe más el acceso y reduce la reutilización de la caché. Para los archivos exportados a tu propio bucket, el Robot /s3/store puede devolver URL firmadas mediante su parámetro sign_urls_for.

La Auth Key usada para firmar debe estar habilitada para el uso de Smart CDN, y la firma debe realizarse en tu backend porque necesita el Auth Secret. La documentación marca exp como opcional y recomienda establecerlo siempre. Las páginas enlazadas describen cómo firmar una URL, pero no cómo se trata una solicitud sin firma al mismo Template ni si se rechaza una solicitud de rango que llega después de exp, así que prueba ambos casos en tu propio Workspace antes de considerar la firma como control de acceso o de elegir una vigencia menor que la duración de una sesión de reproducción.

Explora las capacidades de entrega de Transloadit

¿Qué es una URL firmada?

Cómo funcionan las URL firmadas

Datos clave

Cuándo son importantes las URL firmadas

Cómo ayuda Transloadit con las URL firmadas

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional