Improve SGU logon resilience and client UX

2026-09-01 10:37:40 -06:00
parent 3d0897316d
commit da01343985
27 changed files with 869 additions and 37 deletions
@@ -0,0 +1,60 @@
+# 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:
+
+1. una autenticación SGU exitosa sincroniza la contraseña original a AD;
+2. AD valida esa contraseña mientras el controlador es accesible;
+3. Windows conserva su verificador de inicio de sesión de dominio para equipos
+   desconectados;
+4. 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.