3.0 KiB
ADR 0001: no usar Redis como caché de contraseñas
- Estado: aceptado
- Alcance: autenticación SGU y fallback sin conexión
Contexto
SGU puede tardar varios segundos o quedar temporalmente fuera de servicio. Se consideró instalar Redis persistente en el mismo Windows Server que hospeda el broker y Active Directory, almacenando un hash con sal/clave o una contraseña cifrada.
Decisión
No se almacenarán contraseñas, contraseñas cifradas, hashes, HMAC ni otros verificadores de contraseña en Redis. Tampoco se instalará Redis en el controlador de dominio.
El mecanismo de continuidad es el ya proporcionado por Windows:
- una autenticación SGU exitosa sincroniza la contraseña original a AD;
- AD valida esa contraseña mientras el controlador es accesible;
- Windows conserva su verificador de inicio de sesión de dominio para equipos desconectados;
- si SGU o el broker no responde, el Credential Provider entrega la misma credencial a Windows y deja que AD/LSA decidan.
Motivos
- Un hash no permite recuperar la contraseña original. Comparar la contraseña presentada contra otro verificador solo duplicaría el material atacable que ya mantienen AD y Windows.
- Una contraseña cifrada es un secreto reversible; colocar la clave de descifrado junto al broker convierte el caché en una bóveda de credenciales reutilizables.
- Un caché persistente aceptaría durante más tiempo una contraseña revocada y añadiría una tercera fuente de verdad entre SGU y AD.
- Redis persistente escribe RDB/AOF a disco. La documentación de Redis recomienda controles adicionales como TLS, ACL y cifrado del lado cliente.
- Redis Open Source no tiene un servicio Windows nativo propio; Redis documenta Memurai o WSL para Windows. Ninguna opción debe ampliar la superficie de ataque de un controlador de dominio.
- Microsoft recomienda reducir el software instalado en controladores de dominio y tratarlos como sistemas sensibles de propósito único.
Referencias:
- https://learn.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/cached-domain-logon-information
- https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack
- https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/
- https://redis.io/docs/latest/operate/oss_and_stack/install/archive/install-redis/install-redis-on-windows/
- https://redis.io/docs/latest/operate/rs/security/recommended-security-practices/
Alternativa permitida en el futuro
Redis podría ser útil para metadatos no secretos —nombre normalizado, dependencia, puesto o control de tasa distribuido— si existe más de una instancia del broker. En ese caso debe ejecutarse en un servidor miembro o VM Linux separada, usar TLS y ACL, tener TTL corto y nunca participar en la decisión de aceptar una contraseña. Con una sola instancia, un caché en memoria es más simple y no añade otra dependencia al inicio de sesión.