Planteamiento y contexto
Esta pregunta de diseño de sistemas evalúa el ciclo de vida y el límite de autorización de las credenciales temporales. El desafío no es envolver las API de firma de almacenamiento de objetos; es mantener un enlace con capacidades estrictamente limitadas y controlable frente a filtraciones, revocación, rotación de claves y acceso multirregión.
Qué evalúa el entrevistador
- Si una URL firmada está vinculada al tenant, objeto, método, versión, rango y expiración.
- Si se distinguen la firma, la autorización en tiempo real, la revocación y los permisos de almacenamiento.
- Si se diseñan la rotación de claves, el almacenamiento en caché breve, la entrega mediante CDN, los límites de tasa (rate limits) y el flujo de auditoría.
- Si se explican los compromisos (trade-offs) de filtración, repetición, desincronización de reloj (clock skew), fallo regional y retraso en la revocación.
Preguntas de aclaración que debe hacer
Confirme si se trata de descarga o carga, objeto único o por lotes, necesidades de Range y multipart, tiempo de vida máximo, revocación a nivel de segundos y participación de la CDN. Pregunte sobre el aislamiento de tenants, la retención de auditoría, la gestión de claves, la recuperación multirregión y la semántica de versiones de objetos.
Estructura de respuesta de 30 segundos
Un servicio de autorización valida primero a quien realiza la llamada y luego firma una URL vinculada al tenant, versión del objeto, operación, condiciones y una expiración corta. La firma cubre una solicitud normalizada y la versión de la clave; el almacenamiento o el edge la verifican. La revocación de alto riesgo utiliza TTL cortos, una lista de denegación o un marcador de versión revocada. La URL otorga solo las capacidades necesarias, mientras que los eventos de auditoría inmutables, la detección de repeticiones, los límites de tasa y la rotación de claves contienen el riesgo.
Análisis detallado paso a paso
1. Definir el modelo de credenciales y permisos
Incluya el tenant, una clave de objeto o ID imposible de adivinar, la versión, el método permitido, el rango de bytes, las restricciones de content-type, el emisor, la expiración y la versión de la clave. Una URL de carga también limita el tamaño, la suma de comprobación (checksum) y el prefijo de destino. El servidor realiza una autorización del objeto en tiempo real antes de firmar; los clientes no pueden editar los parámetros para ampliar los permisos.
2. Elegir las rutas de firma y verificación
Utilice un HMAC compatible con el almacenamiento o una firma asimétrica que cubra el método, la ruta, los parámetros de consulta, los encabezados importantes y la expiración. Canonice los espacios en blanco, la codificación y el orden de los parámetros. El verificador comprueba la ventana de tiempo, la versión de la clave, la firma y las condiciones. Las operaciones sensibles aún utilizan comprobaciones en tiempo real en lugar de colocar cada decisión de autorización en una URL autónoma.
3. Diseñar defensas de revocación, rotación y repetición
Una expiración corta limita el impacto de las filtraciones. Para enlaces de alto valor, Redis o las reglas del edge pueden almacenar un ID de token, una revocación de versión de objeto o una lista de denegación de tenants. Durante la rotación de claves, conserve la versión antigua hasta que finalice el tiempo de vida de la URL más larga y luego elimínela. Las cargas de un solo uso pueden requerir un nonce, el estado del objeto y un marcador de finalización; las descargas repetidas siguen una política de negocio explícita.
4. Escalar el almacenamiento, la CDN y la gestión de fallos
Mantenga la emisión sin estado, con metadatos y revocación en almacenamiento de alta disponibilidad. Envíe los bytes del objeto directamente a través del almacenamiento o una CDN en lugar del servidor de aplicaciones. La política de la CDN debe incluir la firma y los límites de permisos para que la respuesta privada de un tenant no pueda ser reutilizada por otro. Si la gestión de claves o el almacenamiento de revocaciones no están disponibles, aplique un fallo cerrado (fail closed) para nuevas emisiones y accesos de alto riesgo; trate los enlaces de bajo riesgo ya emitidos según su TTL documentado.
5. Observar, limitar la tasa y verificar la seguridad
Audite el emisor, tenant, objeto, método, resultado, región, un resumen de la huella digital del cliente y el motivo de la revocación sin registrar la consulta completa de la URL. Limite la tasa de emisión, los bytes totales y la concurrencia por tenant, usuario, objeto e IP; detecte reutilizaciones anómalas. Pruebe la alteración de parámetros, la expiración, la desincronización de reloj, la rotación, el retraso de revocación, el acceso entre tenants, los aciertos de CDN y el fallo regional.
Ejemplo de respuesta sólida
Tras validar a quien realiza la llamada, el servicio de autorización emite una URL vinculada al tenant, la versión inmutable del objeto, el método, las condiciones y una expiración corta. La firma cubre la ruta canónica, la consulta y los encabezados críticos; el almacenamiento o la CDN la verifican, por lo que la aplicación no actúa como proxy de archivos grandes. Los enlaces de alto riesgo admiten la revocación mediante TTL cortos, una lista de denegación o marcadores de versión. Conserve las claves antiguas hasta que expire el enlace más largo. Audite la emisión y los resultados de acceso sin URL completas, limite la tasa por tenant y objeto, y pruebe la alteración, repetición, desincronización, rotación, revocación, acceso entre tenants y el aislamiento de la CDN.
Errores comunes
- Firmar únicamente una ruta de objeto sin el tenant, método, versión o condiciones de carga.
- Tratar una URL permanente como un mecanismo de revocación y carecer de contención de filtraciones.
- Eliminar una clave antigua inmediatamente durante la rotación y romper enlaces válidos.
- Almacenar en caché contenido privado en la CDN únicamente por la ruta e ignorar las firmas o los tenants.
- Escribir URL firmadas completas en registros, analíticas o mensajes de error.
- Probar únicamente la validez de la firma omitiendo la alteración, la repetición, la desincronización de reloj y el retraso de revocación.
Preguntas de seguimiento y respuestas
¿Por qué no poner toda la autorización en un JWT?
Una URL firmada vincula condiciones a una solicitud de recurso que el almacenamiento puede verificar sin hacer de proxy de grandes volúmenes de bytes, pero no es un sistema de revocación en tiempo real. Los privilegios de alto riesgo aún requieren TTL cortos, revocación de versiones o comprobaciones en tiempo real.
¿Cómo puede surtir efecto la revocación en cuestión de segundos?
Haga que el edge o el verificador consulten una lista de denegación de alta prioridad, un marcador de versión de objeto o el estado del tenant con un TTL de caché muy corto. Esto aumenta las lecturas y la presión de consistencia, por lo que debe aplicarse según el nivel de riesgo.
¿Cómo evita una URL de carga la sobrescritura de otro objeto?
Vincúlela a una clave inmutable o un ID de carga de un solo uso, If-None-Match, tamaño y suma de comprobación. Al completarse, vuelva a comprobar el estado del tenant y del objeto y rechace la sustitución de rutas o la finalización duplicada.
¿Debería una CDN almacenar en caché las URL firmadas?
Puede almacenar en caché los bytes solo cuando la clave, los encabezados y el TTL eviten que las respuestas privadas crucen los límites de permisos. Los recursos de alto riesgo o de muy corta duración pueden omitir la caché compartida, sacrificando la tasa de aciertos en favor del aislamiento y una revocación controlable.