Entrega de archivos de alto aseguramiento: descargas protegidas por autenticación de hardware
El enlace no es el lector
La mayoría de los sistemas entregan un archivo privado de la misma manera: generan una URL firmada, la envían y confían en que solo la persona correcta haga clic. La firma impide que un desconocido adivine la dirección. No dice nada sobre quién la abre. Un mensaje reenviado, un buzón compartido, una captura de pantalla en un chat: cualquiera de ellos pone el archivo frente a alguien que el remitente nunca eligió.
Para el contenido rutinario esa brecha es aceptable. Para un contrato, un expediente de personal con habilitación o información no clasificada controlada, es todo el problema. La pregunta no es "¿es válido este enlace?" sino "¿es esta la persona a la que nos referíamos?".
Pida al lector que lo demuestre
La solución agrega un paso antes de que los bytes salgan del servidor: hacer que el destinatario demuestre, con hardware, que es quien nombra la concesión. Una llave de seguridad o una tarjeta inteligente firma un desafío que una contraseña o un enlace copiado no pueden firmar. La gente de seguridad lo llama autenticación resistente al phishing: la credencial no puede escribirse, adivinarse ni entregarse a un sitio falso, porque la prueba es una firma vinculada al sitio real.
Dos rutas de hardware cubren la mayoría de las necesidades. FIDO2 y WebAuthn operan una llave de seguridad o el autenticador integrado de un teléfono. Las tarjetas PIV y CAC, ya emitidas en todo el gobierno, alcanzan el mismo resultado a través de un lector de tarjetas. En cualquier caso el usuario hace una sola cosa, tocar una llave o pasar una tarjeta, y el servidor sabe que el toque ocurrió.
La forma del control
El patrón une dos partes que funcionan bien por separado.
Primero, una URL firmada y con vencimiento. Lleva para quién es el archivo, cuándo muere la concesión, cuántas veces puede usarse y una firma sobre todo ello. Por sí sola, este es el modelo conocido.
Segundo, un escalonamiento al canjear el enlace. Cuando el navegador pide el archivo, el servidor verifica la firma y luego hace una segunda pregunta: ¿ha demostrado esta sesión autenticación de hardware en los últimos minutos? Si sí, el archivo se transmite. Si no, el navegador va a demostrarlo y vuelve al mismo enlace una vez hecho.
El proveedor de identidad hace la criptografía difícil. El servidor de archivos es una parte confiante: lee una afirmación firmada que el proveedor emite después de la ceremonia, verifica que la afirmación supera su umbral y libera el archivo. Nunca reimplementa la criptografía de hardware, y nunca confía en una declaración que no verificó.
Decisiones que lo mantienen honesto
Un control es tan bueno como su peor caso, así que diseñe primero para el peor caso.
Falle cerrado. Si falta algo (no hay afirmación, la audiencia es incorrecta, la concesión venció, el nivel está por debajo del umbral), deniegue y ofrezca el escalonamiento. Una compuerta que se abre cuando no está segura no es una compuerta.
Concesiones cortas y de un solo uso. Vincule cada enlace a un solo uso y a unos minutos de vida. Un enlace que ya se gastó, o que caducó, está muerto: no se reabre y no revela por qué falló.
Vincule la concesión a una persona. Ate el enlace al sujeto para el que fue generado, y al canjearlo verifique que la identidad demostrada coincide. Un enlace que se escapa entonces no le sirve de nada a quien lo encuentra, porque el archivo sigue pidiendo la llave de esa persona, no la del lector previsto.
Confíe en los emisores por nombre. Cuando más de un grupo puede iniciar sesión (el personal en un directorio, los socios en otro), confíe en cada fuente en sus propios términos, con su propia audiencia y su propio nivel requerido, y haga coincidir un token con exactamente una de ellas. Sin coincidencias cruzadas, sin alternativas más laxas. Un token emitido para un contexto no puede abrir un archivo destinado a otro.
Mantenga los tokens fuera del navegador. La prueba debe vivir en una sesión del lado del servidor y en una cookie firmada de corta duración, no en un valor que los scripts de la página puedan leer. Un diseño que deja un token de acceso en el almacenamiento del navegador invita exactamente al robo que la llave de hardware debía impedir.
Haga que la ruta fuerte sea la ruta fácil
La seguridad que molesta a la gente se elude, así que el escalonamiento debe costar un solo toque. El destinatario abre el enlace, el sitio lo envía a su proveedor de identidad, toca la llave y el archivo se descarga. Sin token que copiar, sin código que pegar, sin segunda aplicación. Si inició sesión con la misma llave hace un momento, puede que la sesión ya supere el umbral y el archivo simplemente llegue.
El mismo cuidado se aplica a la falla. Un enlace vencido debe decir, en palabras claras, que ha vencido y que pida uno nuevo, no dejar al lector ante un seguimiento de pila o una página de error escueta.
Dónde se justifica
Esto corresponde a cualquier lugar donde el archivo vale más que el enlace. Información no clasificada controlada bajo normas federales. Expedientes de personal con habilitación y registros de contratos. Datos financieros y de salud con un destinatario designado. Material de junta directiva y de operaciones que debe llegar a una bandeja de entrada y a ninguna otra. Los estándares ya señalan el camino: la guía del NIST sobre aseguramiento de la autenticación, FIPS 201 para PIV, y las especificaciones FIDO2 y WebAuthn para llaves de seguridad. El patrón convierte esos estándares en una compuerta funcional sobre la única acción que importa: la descarga.
La versión corta
Un enlace firmado responde "¿es válida esta dirección?". Los archivos de alto valor necesitan que también se responda la siguiente pregunta: "¿es esta la persona?". Un escalonamiento por hardware en el momento de la descarga la responde, falla cerrado cuando no puede y, construido con cuidado, le cuesta al lector un solo toque.