Steven LafortuneLas cuentas privilegiadas no se ven comprometidas en la pantalla de inicio de sesión. Se ven comprometidas después de iniciar sesión: cuando se secuestra una sesión, un dispositivo se queda desbloqueado o las credenciales se comparten con demasiada ligereza. Esa es la brecha que la MFA en el checkout de PAM está diseñada para cerrar: en lugar de confiar en quien ya está dentro del perímetro, Devolutions ahora vuelve a verificar la identidad, justo en el momento en que alguien solicita acceso a una cuenta privilegiada.
El problema que resuelve la MFA en el checkout
La MFA estándar de inicio de sesión demuestra quién se autenticó al principio del día. No demuestra quién está frente al teclado una hora después, cuando llega una solicitud de checkout privilegiado. Para cuentas sensibles (administradores de dominio, cuentas de servicio, cualquier cosa con derechos elevados), esa brecha importa. Exigir un nuevo desafío de MFA en el momento exacto del checkout la cierra: ahora la verificación acompaña a la propia solicitud de acceso, y no solo al inicio de sesión.
Habilitar la MFA para el checkout
En Devolutions Server:
- Asegúrese de que los usuarios tienen configurado un método de MFA, ya sea por usuario (
Administration – Users – Multifactor) o aplicado globalmente medianteAdministration – Configuration – Server Settings – Security – Conditional Access Policies(establezca el destino de MFA como Required, Optional per user o Skipped). - Abra las propiedades del proveedor de PAM o de la entrada y vaya a la pestaña Checkout policy.
- Active la opción para exigir MFA en el checkout.
- Guarde los cambios. El requisito se aplicará la próxima vez que se haga el checkout de esa entrada.
En Devolutions Cloud: se aplica la misma lógica a través de Administration – Configuration – Security – Authentication, donde puede activarse la verificación por MFA para el lanzamiento de entradas sensibles. Los métodos admitidos incluyen correo electrónico y TOTP, además de otros proveedores de identidad cubiertos por las opciones de MFA más amplias de la plataforma (Yubikey, Duo, Radius y otros, según su configuración).
Qué ocurre cuando un usuario hace el checkout de una cuenta
El propio flujo de checkout no cambia en apariencia: el usuario elige la entrada, selecciona una duración y envía un motivo o número de incidencia si así se requiere. Lo nuevo ocurre justo ahí, antes de que la solicitud llegue a ningún sitio. Si la entrada requiere MFA, el usuario debe verificarse (un código TOTP, un código por correo electrónico o SMS) como parte del envío de la solicitud. Sin una MFA válida, la solicitud nunca llega al aprobador: la identidad se confirma en el origen, no se añade después como un parche.
Qué ve el aprobador
Los aprobadores no tienen que adivinar si se confirmó la identidad. Cuando una solicitud de checkout llega a sus manos para revisión, la verificación por MFA ya se ha producido; de lo contrario, el solicitante no habría podido enviar la solicitud. La pantalla de aprobación refleja esto, lo que le deja al aprobador una incógnita menos a la hora de decidir y un dato más en el registro de auditoría, por si ese checkout se revisa más adelante.
Por qué es importante
La MFA en el checkout no sustituye a las aprobaciones, la grabación de sesiones ni a sus políticas de checkout actuales; se suma a ellas como un punto de control más, colocado justo donde el riesgo es más alto: el momento en que alguien obtiene acceso a una cuenta privilegiada. Para los equipos que ya usan Devolutions PAM, es simplemente activar una opción de política, no implementar un nuevo sistema.
Si utiliza Devolutions PAM, merece la pena activar esta función. Consulte la documentación a continuación para conocer la configuración completa y cuéntenos cómo le funciona a su equipo.
Recursos:
Adam Listek
Marc Beausejour