Planteamiento y alcance
Esta pregunta de producto evalúa cómo transformar un control de seguridad en una experiencia por niveles. El objetivo no es hacer que cada página vuelva a pedir una contraseña; es definir acciones de alto valor, señales de riesgo, fortaleza de autenticación, recuperación y medición.
Qué evalúa el entrevistador
- Si puedes clasificar el riesgo de las acciones según el valor del activo y su irreversibilidad.
- Si comprendes los roles diferenciados de la reautenticación, MFA, la confianza del dispositivo y las señales de riesgo.
- Si puedes gestionar la accesibilidad, el uso multidispositivo, el SSO empresarial y la recuperación de cuentas.
- Si puedes evaluar en conjunto la seguridad, la tasa de éxito, el abandono y el costo de soporte.
Preguntas de clarificación para hacer
Confirma los roles de usuario, permisos de tenant, reversibilidad, sensibilidad de los datos, capacidades del proveedor de identidad empresarial, duración actual de la sesión, cobertura de MFA y canales de recuperación. Clarifica también el modelo de amenazas: secuestro de sesión, dispositivos compartidos, errores internos o toma de control de cuentas tras un inicio de sesión de alto riesgo.
Estructura para una respuesta de 30 segundos
Construiría una matriz de riesgo por acción: una exportación completa de un tenant, cambio de MFA, cambio de método de pago o eliminación de tenant es de alto riesgo; ver un reporte es de bajo riesgo. Las acciones de alto riesgo activarían una reautenticación por tiempo limitado, utilizando preferentemente un factor robusto existente o WebAuthn, con requisitos más estrictos tras eventos de riesgo o en un nuevo dispositivo. El flujo necesita una razón clara, alternativas accesibles, recuperación controlada y eventos de auditoría. Lo implementaría gradualmente y mediría los bloqueos de alto riesgo, la finalización legítima, el abandono, los eventos de toma de control y el costo de soporte, en lugar de limitarme al conteo de solicitudes de verificación.
Solución paso a paso
1. Definir el riesgo por acción, no por página
Puntúa las acciones por radio de impacto, irreversibilidad, elevación de privilegios y sensibilidad de los datos. La eliminación de tenants, la exportación de datos personales, el cambio de factores de recuperación y el otorgamiento de permisos de administrador pertenecen al conjunto de alto riesgo; las lecturas comunes y las preferencias reversibles suelen requerir menos fricción. Producto, seguridad, legal y soporte deben aprobar la matriz en conjunto.
2. Elegir la fortaleza de autenticación y el tiempo de vida
Las acciones de alto riesgo pueden requerir la credencial principal más MFA, o una ceremonia de WebAuthn resistente al phishing. La aserción de reautenticación debe estar vinculada al usuario, al tenant, al alcance de la acción y a un tiempo de vida corto; no debe convertirse en un pase de larga duración. Señales como un nuevo dispositivo, una ubicación inusual o una recuperación completada deben acortar el tiempo de vida o elevar el requisito, no convertirse automáticamente en el único motivo de denegación.
3. Diseñar una experiencia comprensible y accesible
Explica por qué es necesaria la verificación, qué protege y qué sucede tras completarla. Ofrece soporte para uso mediante teclado, lectores de pantalla y alternativas que no dependan de una sola biometría; los usuarios de SSO empresarial deben redirigirse a su proveedor de identidad. No reveles reglas internas de riesgo en los mensajes de error ni dejes a los usuarios atrapados en un bucle tras fallos repetidos.
4. Planificar rutas de recuperación y de excepción
Los dispositivos MFA perdidos, la aprobación multidispositivo, la recuperación de cuentas y la asistencia de administradores empresariales necesitan rutas explícitas. La recuperación en sí misma es de alto riesgo, por lo que una pregunta de seguridad de respaldo más débil no debe eludir la autenticación escalonada. Registra el motivo, notifica a los usuarios pertinentes y limita que un factor de recuperación recién añadido autorice inmediatamente acciones sensibles.
5. Conectar el control a la autorización y auditoría del backend
Una solicitud en el frontend no es protección. El servidor debe validar la aserción de reautenticación de la sesión, la acción y el alcance del tenant para que no pueda reproducirse contra otra API. Los eventos de auditoría registran el actor, el tenant, la acción, el método de autenticación, las señales de riesgo resumidas y el resultado; los registros no deben retener secretos ni credenciales completas. Los servicios que manejan datos sensibles aún requieren TLS configurado correctamente.
6. Validar la seguridad y los resultados de producto por etapas
Comienza con tenants internos y un pequeño porcentaje de acciones de alto riesgo. Observa el éxito de la autenticación, el abandono, la recuperación, las denegaciones falsas y los tickets de soporte antes de expandir. Las métricas de seguridad incluyen acciones de alto riesgo bloqueadas, secuestro de sesión y recuperación anómala; las métricas de experiencia incluyen tiempo de finalización, tasa de éxito y solicitudes repetidas. Si el riesgo disminuye mientras los fallos legítimos aumentan, ajusta los niveles de acción, el tiempo de vida o la recuperación en lugar de simplemente desactivar el control.
Ejemplo de respuesta de alta calidad
Confirmaría el modelo de amenazas con seguridad, soporte y administradores empresariales, para luego clasificar las acciones por radio de impacto, irreversibilidad, elevación de privilegios y sensibilidad de datos. Una exportación completa del tenant, cambio de MFA, cambio de método de pago o eliminación de tenant es de alto riesgo, mientras que la visualización de reportes se mantiene con baja fricción. Las acciones de alto riesgo activan una aserción de corta duración vinculada al usuario, al tenant y a la acción, preferiblemente mediante WebAuthn o MFA empresarial; un nuevo dispositivo, ubicación inusual o recuperación reciente eleva el requisito. La UI explica el motivo y admite rutas para teclado, lector de pantalla e IdP empresarial, mientras que la recuperación no puede usar un factor más débil para eludir la protección. El servidor valida la aserción y registra un evento de auditoría; el frontend no puede autorizar por sí solo. Haría un lanzamiento gradual y supervisaría bloqueos de alto riesgo, éxito legítimo, abandono, toma de control y costo de soporte, para luego ajustar la matriz y el tiempo de vida con base en la evidencia.
Errores comunes
- Exigir un nuevo inicio de sesión en cada página hasta que los usuarios eludan o desactiven el control.
- Mostrar un diálogo de reautenticación en el frontend mientras la API ignora el alcance de la acción.
- Usar SMS o una pregunta de seguridad como la única ruta de recuperación de alto riesgo sin un modelo de amenazas.
- Omitir el SSO empresarial, la accesibilidad, las rutas multidispositivo o los casos de MFA extraviado.
- Medir el conteo de solicitudes de verificación sin datos de toma de control, falsas denegaciones, tiempo de finalización o soporte.
- Escribir señales de riesgo sin procesar en el texto para el usuario o en los registros de auditoría, exponiendo detalles de detección.
Preguntas de seguimiento y respuestas
¿Cuándo es suficiente un solo inicio de sesión?
Las lecturas o preferencias de bajo riesgo, reversibles y con un radio de impacto pequeño pueden reutilizar la sesión actual. Omitir la autenticación escalonada depende del riesgo de la acción, el estado de la sesión y la política de la organización; decir que “el usuario ya ha iniciado sesión” no es suficiente.
¿Un nuevo dispositivo siempre debe bloquear una acción sensible?
No. Un nuevo dispositivo es una señal para elevar el nivel de certeza, no una prueba de intención maliciosa. Exige un MFA más robusto, notifica a un administrador del tenant o acorta el tiempo de vida de la aserción, y luego realiza ajustes con datos de falsas denegaciones y toma de control.
¿Cómo se evita la reproducción de una aserción de reautenticación?
Vincúlala en el servidor al usuario, tenant, acción, recurso y a una ventana de tiempo corta, luego consúmela o rótala tras una operación exitosa. Un indicador genérico de “verificado” no debe autorizar todas las API sensibles.
¿Qué sucede si el usuario no puede completar el MFA?
Ofrece una ruta de recuperación auditada, como la asistencia de un administrador empresarial u otro factor robusto, con notificaciones y un periodo de enfriamiento. La recuperación en sí no debe eludir directamente la protección de acciones de alto riesgo.