¿Qué es una URL prefirmada?

Una URL prefirmada otorga autorización por tiempo limitado para una operación de almacenamiento específica, como descargar o subir un solo objeto, sin entregar al destinatario las credenciales secretas del firmante. Su firma fija la operación, el objeto y el vencimiento.

El backend de la aplicación firma una solicitud con sus credenciales de almacenamiento

URL prefirmada entregada al cliente

El servicio de almacenamiento comprueba la firma y el vencimiento y, después, sirve o acepta el objeto

La aplicación firma la solicitud; después, el cliente se comunica directamente con el servicio de almacenamiento.

Un servicio de prefirmado calcula una firma a partir de una solicitud de almacenamiento, usando las credenciales que posee, e incluye los datos de autorización resultantes en la cadena de consulta de la URL. El servicio de almacenamiento vuelve a calcular la firma cuando se usa la URL y comprueba el método, el objeto, los encabezados firmados y el vencimiento, por lo que el secreto nunca tiene que llegar al navegador ni al cliente de descarga. La solicitud se ejecuta con la autoridad de quien la firmó: Amazon S3 indica que una URL prefirmada usa las credenciales de la entidad que la generó y está limitada por los permisos de esa entidad. Amazon S3 las llama URL prefirmadas, Google Cloud Storage las llama URL firmadas y el equivalente en Azure Storage es Shared Access Signature (SAS). Los detalles específicos de almacenamiento de esta entrada proceden de la documentación de esos tres servicios; para un servicio compatible con S3 de otro proveedor, consulta la documentación de ese proveedor. Una URL firmada de CDN es un mecanismo diferente: la CDN la comprueba con las claves configuradas en la CDN y el servicio de almacenamiento no interviene en esa comprobación. En una arquitectura de entrega, una URL prefirmada crea una vía directa y temporal entre un cliente y el almacenamiento de objetos, mientras la aplicación decide quién recibe una.

¿Quién puede usar una URL prefirmada? Cualquiera que tenga la URL completa, hasta que deje de ser válida. AWS describe las URL prefirmadas como tokens Bearer, y Google indica que cualquiera que posea una URL firmada puede usarla mientras esté activa, con o sin cuenta. Una URL prefirmada de S3 puede usarse repetidamente hasta su vencimiento. Una forma de terminar el acceso antes es invalidar la credencial o clave con la que se firmó la URL, lo que invalida todas las URL firmadas con ella: una URL de S3 deja de funcionar cuando la credencial de firma se revoca, se elimina o se desactiva, y una URL firmada de Google, cuando se rota la clave de firma. Otros controles dependen del servicio. Una URL prefirmada de S3 está limitada por los permisos de su firmante, y AWS incluye una política de bucket que deniega explícitamente el acceso al objeto entre las causas de una respuesta 403 Forbidden a una URL prefirmada, por lo que esa denegación detiene las solicitudes dentro del ámbito de la política sin invalidar la credencial. Azure recomienda asociar una SAS de servicio con una política de acceso almacenada para poder revocarla sin regenerar las claves de la cuenta.
¿Por qué dejaría de funcionar una URL prefirmada antes del vencimiento indicado? Porque solo es válida mientras lo sean las credenciales con las que se firmó. AWS documenta que una URL de S3 firmada con credenciales temporales, como las de un rol asumido o un rol de instancia o contenedor, vence cuando vencen esas credenciales, aunque se haya solicitado un vencimiento posterior, y las solicitudes fallan entonces con ExpiredToken. Comprueba la vigencia de las credenciales de firma antes de prometer la vigencia de un enlace: AWS permite establecer la duración máxima de sesión de un rol de IAM asumido mediante su consola, CLI o API entre 1 y 12 horas (1 hora si no se establece un valor) y describe las credenciales de roles de instancia y contenedor como válidas, por lo general, hasta unas 6 horas, mientras que las credenciales de un usuario de IAM pueden firmar una URL de S3 válida hasta 7 días con Signature Version 4. Las soluciones de AWS son renovar las credenciales y generar una URL nueva o, cuando corresponda, firmar con credenciales de mayor vigencia. S3 comprueba el vencimiento cuando comienza una solicitud: una descarga que comenzó antes del vencimiento continúa, pero una solicitud que se reinicia después falla.
¿Por qué falla una URL que no ha vencido con un error de firma? La solicitud ya no coincide con lo que se firmó. En S3, el método HTTP, los encabezados firmados y la cadena de consulta deben coincidir exactamente entre la generación de la URL y su uso. Una URL de S3 firmada con Signature Version 4 enumera sus encabezados firmados en X-Amz-SignedHeaders, y AWS exige que entre ellos estén el encabezado host y todos los encabezados x-amz-* enviados con la solicitud. AWS incluye un tipo de contenido diferente del indicado al firmar entre las causas de SignatureDoesNotMatch, junto con una URL modificada, una región incorrecta, un desfase del reloj de la máquina que firma y proxies que modifican los encabezados o las cadenas de consulta. Las URL firmadas de Google indican en X-Goog-SignedHeaders los encabezados que debe incluir una solicitud.
¿Por qué falla una URL prefirmada válida desde JavaScript en el navegador? La autorización del almacenamiento y CORS son comprobaciones independientes. La configuración de CORS del bucket debe permitir el origen de la página, el método HTTP y los encabezados de la solicitud; Amazon S3 señala que las ACL y las políticas siguen aplicándose cuando CORS está habilitado. Cuando la configuración no permite una solicitud, el navegador se detiene ante una comprobación preliminar fallida antes de enviar la solicitud real o, si la solicitud no necesita comprobación preliminar (como puede ocurrir con un POST con un tipo de contenido de formulario), la envía y oculta la respuesta al script, por lo que un error de CORS por sí solo no demuestra que no se haya subido nada. Como CORS restringe las solicitudes entre orígenes realizadas por scripts en un navegador, la misma URL puede funcionar desde un cliente del lado del servidor y fallar desde una página web.
¿Una URL prefirmada de subida limita lo que se sube? Solo lo que se haya firmado. Una URL prefirmada de S3 para una subida se crea a partir de un bucket, una clave de objeto, un método HTTP y un vencimiento, y subir a una clave que ya existe reemplaza el objeto. Azure advierte que un cliente con acceso de escritura puede subir un blob muy grande (su ejemplo es de 200 GB) y recomienda validar los datos después de escribirlos y antes de usarlos. Cuando el servicio de almacenamiento debe imponer un límite de tamaño, las subidas POST basadas en formularios son la herramienta documentada: el documento de política firmado acepta una condición content-length-range en Google Cloud Storage y en Amazon S3, y el SDK de AWS para Python crea un formulario firmado de este tipo con generate_presigned_post. El límite del propio servicio de almacenamiento para una solicitud sigue aplicándose: una subida mediante una URL prefirmada de S3 es un PUT, Amazon S3 documenta un máximo de 5 GB para un solo PUT, y los objetos más grandes usan la subida multiparte, en la que el objeto se envía por partes. La referencia POST Object de Amazon S3 no indica un límite de tamaño para un solo POST, así que prueba una subida basada en formulario con el archivo más grande que esperas usar antes de depender de ella.

Emite una para subidas directas desde el navegador o descargas privadas cuando el tráfico deba evitar el servidor de la aplicación. Una vigencia excesiva, operaciones demasiado permisivas o la filtración de la URL pueden exponer el objeto al que hace referencia hasta su vencimiento.

Transloadit puede devolver URL prefirmadas de descarga para los archivos que exporta a Amazon S3. Configurar sign_urls_for en el Robot /s3/store añade signed_url y signed_ssl_url al resultado, con el valor del parámetro como plazo de vencimiento en segundos. Las URL se firman con las credenciales de AWS que proporcionas al Robot, por lo que la documentación exige que esa identidad tenga permiso de lectura sobre los objetos además del permiso de escritura usado para la subida.

Una URL devuelta por /s3/store no convierte un objeto privado en público, pero el parámetro acl del Robot tiene como valor predeterminado public-read. Para un bucket privado, la documentación indica que se debe establecer acl en bucket-default, no proporcionar encabezados de ACL ni de concesión de permisos y mantener S3 Block Public Access habilitado. Si usas credenciales temporales de AWS, el Robot no las renueva, y AWS documenta que una URL prefirmada vence junto con las credenciales con las que se firmó, así que compara su vigencia con el valor de sign_urls_for. Signature Authentication de Transloadit y las URL firmadas de Smart CDN son mecanismos independientes que usan tu Auth Secret de Transloadit, no tus credenciales de almacenamiento.

Explora las capacidades de entrega de Transloadit

¿Qué es una URL prefirmada?

Cómo funcionan las URL prefirmadas

Datos clave

Cuándo son importantes las URL prefirmadas

Cómo ayuda Transloadit con las URL prefirmadas

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional