Un archivo que se abría sin problema deja de abrirse para algunas personas de una empresa, y para nadie más. El servidor no registra ningún error, la URL se genera como de costumbre y desde cualquier otra red el mismo enlace funciona.

La restricción no está en la documentación de AWS, está en el cortafuegos del cliente

La causa no estaba de nuestro lado. Los cortafuegos corporativos traen una categoría de filtrado dedicada al almacenamiento en la nube: Palo Alto Networks la llama “Online Storage and Backup” y la define como los sitios que ofrecen guardar archivos en línea, gratis o como servicio. Bloquearla es una política de un clic, y es razonable: es una de las formas más directas de frenar la salida de información de una empresa.

El efecto secundario aparece cuando una aplicación entrega sus archivos con una URL firmada, que es el patrón recomendado y el que casi todos usamos. Pone el dominio del proveedor de almacenamiento en el navegador de quien abre el archivo, y ese dominio está justo en la lista que el área de seguridad del cliente acaba de bloquear.

Lo caro de este fallo es dónde ocurre. La petición muere en una red que no es tuya, así que no deja rastro en tus registros: tú generaste una URL correcta y respondiste bien. Quien lo nota es la persona que no puede abrir su documento.

Cambiarle el host a la URL firmada no sirve

La tentación es obvia: si el problema es el nombre del dominio, se le pone otro. Conviene saber por qué no funciona antes de perder la tarde intentándolo.

Una URL firmada lleva la autorización dentro. AWS las describe sin rodeos como bearer tokens que dan acceso a quien las posee, el mismo riesgo del que ya hablamos cuando un secreto viaja en la URL. Lo decisivo es un detalle de la especificación: en la tabla de parámetros de Signature Version 4, la cabecera host figura como obligatoria en el cálculo de la firma. El nombre del servidor al que vas a pedir el archivo está firmado junto con el resto, así que entregar la misma URL apuntando a otro nombre hace que la validación falle. AWS lo documenta como causa frecuente de error de firma: un proxy corporativo que modifique cabeceras o la cadena de consulta provoca exactamente eso.

Lo que sí funciona: repetir la petición firmada desde tu propio servidor

La salida es servir el archivo desde un dominio que la red del cliente no bloquea, que es el tuyo. El navegador pide el archivo a tu servidor, y tu servidor repite esa misma petición hacia el almacenamiento con la ruta y los parámetros byte a byte iguales. Como la petición que llega al proveedor es la original, la firma sigue valiendo y sigue siendo lo que autoriza: caduca sola y cubre un único objeto. Tu servidor no necesita credenciales nuevas ni abre un permiso más amplio.

Tres detalles deciden si esto queda bien o mal:

  • El destino sale de tu configuración, nunca de la petición. Si lo tomas de lo que te mandan, has construido un reenviador abierto. Con el destino fijo, una URL sin firma la rechaza el propio proveedor.
  • Reenvía las peticiones por rango, las que permiten saltar a un minuto concreto de un audio o un video sin descargarlo entero. Si no las pasas, se pierde el adelanto.
  • Cuidado con tus propias cabeceras de seguridad. El archivo ahora se sirve desde tu dominio, así que le aplican las reglas que pusiste para tu aplicación. Una cabecera que impide mostrar la página dentro de un marco era inofensiva mientras el archivo venía del almacenamiento, y en cuanto se mueve rompe el visor de PDF incrustado.

Qué se lleva cualquiera que sirva archivos

La conclusión que vale fuera de nuestro caso: que un archivo se pueda alcanzar es un requisito, no un detalle de infraestructura. “Funciona desde mi red” no es una prueba. Si tus clientes son empresas, sus cortafuegos son parte de tu entorno de producción, y las categorías que suelen bloquear están publicadas y se pueden consultar.

El costo, dicho de frente: el tráfico de archivos pasa ahora por la API y consume su ancho de banda. Se mide, y si pesa, el paso siguiente es un subdominio propio o una red de distribución por delante.

En IntegraLaIA operamos agentes con clientes reales (los casos están en casos), y esta es la clase de restricción que solo aparece operando: no estaba en ningún manual, estaba en la red de quien usa el producto. Cómo tratamos los datos y los accesos está en seguridad.