Una sola llave para el inicio de sesión y la entrega
Las organizaciones que entregan archivos sensibles desde un sistema de gestión de contenidos tienden a desarrollar un segundo sistema de credenciales para protegerlos. El proveedor de identidad custodia el inicio de sesión. El punto de descarga desarrolla sus propias contraseñas, sus propios tokens o, en el extremo, su propia inscripción de llaves de hardware.
Cada sistema paralelo es un segundo lugar donde inscribir, un segundo lugar donde revocar y una segunda historia que contarle a un auditor. La divergencia entre ellos es donde viven los incidentes.
Construimos el arreglo opuesto en nuestra propia plataforma y luego lo usamos nosotros mismos antes de recomendárselo a nadie. Así es como se ve y lo que costó hacerlo bien.
El arreglo
El proveedor de identidad es la única parte que toca la credencial de hardware. Un usuario inscribe una llave de seguridad ahí, una sola vez. El inicio de sesión único ordinario la usa.
Cuando ese usuario abre un enlace a un archivo protegido, la capa de entrega no ejecuta una ceremonia propia. Exige un token cuyas declaraciones muestren que el proveedor de identidad acaba de ejecutar una (el contexto de autenticación, la audiencia que nombra al servicio de entrega y un vencimiento) y rechaza cualquier otra cosa. Cada comparación es exacta. Cada pieza ausente deniega: sin secreto de firma, no hay servicio; sin audiencia, no hay descarga; con el contexto de autenticación incorrecto, un desafío en lugar de bytes.
El resultado visible para el usuario es que una sola llave física abre el sitio y autoriza la descarga, sin una segunda inscripción en ningún lugar y con un solo registro de auditoría que leer.
La capa de entrega es nuestro propio módulo de código abierto para Drupal, de modo que la compuerta es inspeccionable y no una afirmación que hacemos sobre nosotros mismos. El patrón no es específico de él: cualquier servicio dispuesto a verificar tres declaraciones y fallar cerrado puede situarse en el mismo lado del arreglo.
Lección uno: la forma canónica del flujo del proveedor es estructural
Los proveedores de identidad que admiten autenticación escalonada la modelan generalmente como lógica condicional sobre un nivel de autenticación: ejecutar este factor adicional cuando la sesión aún no ha alcanzado el nivel que el cliente solicitó.
Nuestro primer intento mantuvo el formulario ordinario de contraseña fuera de esa estructura condicional, con la teoría razonable de que la ruta de inicio de sesión cotidiana no debía reestructurarse para agregar un paso adicional ocasional. Funcionó en el sentido de que el escalonamiento se activaba. También se activaba en cada inicio de sesión ordinario.
La razón merece interiorizarse, porque generaliza: una condición de nivel suele evaluarse como verdadera cuando la sesión no tiene ningún nivel registrado, y los niveles solo se registran cuando se completa un bloque condicionado por nivel. Deje el formulario de contraseña fuera de esa estructura y cada sesión queda sin nivel, así que cada condición es verdadera, así que el paso de hardware se exige a todos cada vez.
Lo encontramos en minutos, en un entorno que no era de producción, con una cuenta de prueba desechable, que es la única razón por la que es una lección y no un incidente. La corrección era la forma documentada desde el principio, y confirmamos la semántica leyendo el código fuente del proveedor en la versión exacta que ejecutábamos. La documentación en prosa por sí sola no lo habría zanjado.
Lección dos: las fallas peligrosas devuelven éxito
Tres veces en una sola construcción, una interfaz administrativa aceptó una escritura y no hizo nada con ella.
Un objeto de política se envió con un nombre de campo con las mayúsculas incorrectas; el servidor descartó la clave no reconocida y devolvió un éxito. Una vinculación se eliminó enviando una estructura vacía, que la API aceptó e ignoró; la forma documentada de eliminarla era enviar el campo con un valor vacío. Una lista de alcances de token, fijada explícitamente por buenas razones años antes, suprimió en silencio las mismas declaraciones de las que dependía la nueva compuerta; nada en ningún lugar reportó un conflicto, porque desde el punto de vista del servidor no lo había.
Ninguna de esas generó un error. Las tres habrían sido publicadas como "configurado" y se habrían comportado como "no configurado". La única disciplina que detecta esta clase es poco vistosa: después de cada escritura, lea el estado de vuelta y compárelo con lo que pretendía, y antes de confiar en cualquier verificación, demuestre que puede fallar además de aprobar. Una verificación que solo se ha observado aprobando no es una verificación.
Lección tres: escalónelo para que el bloqueo sea estructuralmente imposible
El riesgo en este trabajo no es que la autenticación por hardware sea difícil. Es que los cambios de autenticación son una de las pocas cosas en un entorno tecnológico de software que pueden dejar fuera del sistema a las personas que lo están corrigiendo.
Cuatro reglas lo hicieron imposible en lugar de improbable. La inscripción sigue siendo opcional, de modo que el inicio de sesión existente sigue funcionando para todos en cada paso. El nuevo flujo se vincula a un solo cliente, nunca al predeterminado de todo el realm, de modo que el radio de impacto es una aplicación. Una ruta administrativa que el flujo en prueba no puede gobernar permanece disponible en todo momento; para la mayoría de los proveedores, un realm de administración al que no se aplican los flujos de la aplicación. Y la reversión se ejercita de verdad, antes de la aplicación obligatoria, no se escribe y se espera: desvincular, confirmar que la compuerta está inerte, volver a aplicar, confirmar que regresa.
El orden importa también dentro de la funcionalidad. Acortamos la ventana de aseguramiento (el período durante el cual un toque anterior de la llave sigue autorizando una descarga) solo después de que la aplicación pudiera renovar de forma transparente un token vencido. Hecho en el orden contrario, el ajuste no aumenta el aseguramiento; solo deja a las personas varadas a mitad de sesión y les enseña a desconfiar de la funcionalidad.
Lo que le diríamos a alguien que lo esté considerando
El trabajo técnico son unos pocos días. Las decisiones son la parte en la que vale la pena detenerse: a qué parte se le permite custodiar la credencial, cómo se llama la declaración de aseguramiento, cuánto tiempo sigue siendo válida una ceremonia y qué ocurre cuando una declaración falta en lugar de estar equivocada.
Acierte en esas cuatro y la implementación es pequeña. Equivóquese y habrá construido un segundo sistema de credenciales con pasos adicionales, que es justo lo que intentaba evitar.