Autenticación multifactor con Keycloak en una entidad pública: los tres niveles que define la norma y las llamadas que acaba recibiendo la mesa de ayuda
Hay un artículo anterior en este blog sobre el acceso unificado en el Estado que se quedó en el qué. Este va al cómo, y sobre todo a lo que cuesta, porque implementamos el múltiple factor de autenticación con Apache Keycloak y el trabajo de verdad no estuvo en configurar el segundo factor.
Los tres niveles, con su número de artículo
El artículo 15 del reglamento de la Ley de Gobierno Digital, aprobado por el D.S. 029-2021-PCM y publicado el 19 de febrero de 2021, define los niveles de confianza en la autenticación, que el propio reglamento abrevia como NCA:
a) Nivel 1: Provee un nivel de confianza básico respecto de la identidad de un ciudadano digital autenticado. Para este nivel se requiere el uso de por lo menos un (01) factor de autenticación. b) Nivel 2: Provee un nivel de confianza razonable (...). Para este nivel se requiere el uso de dos (02) factores de autenticación diferentes entre sí. c) Nivel 3: Provee un alto nivel de confianza (...). Para este nivel se requiere el uso de dos (02) factores de autenticación diferentes entre sí, debiendo uno de ellos estar basado en un módulo criptográfico resistente a manipulaciones.
Tres precisiones antes de usar esa escala en un proyecto.
La primera es de alcance, y la decimos porque casi nadie la dice: el artículo habla del ciudadano digital autenticado y vive en el título de identidad digital del reglamento, pensado para la relación entre la persona y el Estado a través de la plataforma nacional. Un sistema interno de una entidad, el que usan sus propios servidores para entrar a las aplicaciones de trabajo, no está regulado por ese artículo palabra por palabra. Lo usamos como la única escala oficial disponible en el país, y conviene saber que se está usando como referencia y no como obligación directa.
La segunda es el detalle del nivel 2: los dos factores tienen que ser diferentes entre sí. Contraseña más pregunta de seguridad son dos cosas que sabes, o sea un factor repetido. Las tres categorías son las de siempre: algo que sabes, algo que tienes y algo que eres.
La tercera es el nivel 3, que en la práctica saca el problema del terreno del software. «Módulo criptográfico resistente a manipulaciones» es un token, una tarjeta o un certificado en hardware. Un código de seis dígitos generado por una aplicación móvil no llega ahí, por mucho que sea un segundo factor legítimo para el nivel 2. Si alguien te vende nivel 3 con una aplicación de códigos, hay una conversación pendiente.
Lo que Keycloak resuelve, y es bastante
Keycloak trae el segundo factor de serie. La configuración que usamos:
- El segundo factor como acción requerida. Keycloak puede exigir la configuración del generador de códigos en el primer ingreso, lo que evita la campaña de correos pidiendo a la gente que se dé de alta. El usuario no entra hasta que lo configura.
- Flujos de autenticación por condición. No hace falta que el segundo factor aplique a todo el mundo desde el primer día. Se puede condicionar por rol o por grupo, lo que permite empezar por los perfiles con más potestad y ampliar después.
- Códigos de recuperación. Existen, y hay que decidir si se usan, porque son el mecanismo que evita convertir cada incidencia en una llamada.
Eso es la parte de herramienta. Está documentada, se configura en horas y no es donde se va el presupuesto.
Dónde se va el presupuesto: la capa que está debajo
En las entidades donde hemos trabajado, el sistema de seguridad interno no era un producto: era código propio con años encima, y cada aplicación lo consultaba a su manera. Meter un segundo factor delante de eso obliga a tocar lo que hay detrás.
El trabajo real de ese tipo de encargo se parece a esto: solucionar los problemas de acceso que ya existían, rehacer el cambio de contraseña, migrar la parte visual, mover la base de datos a una versión soportada, implementar los servicios de autenticación y autorización como microservicios y mejorar cómo se presenta la autorización de aplicaciones. El segundo factor es una línea de esa lista.
La pieza que hace que todo lo demás encaje es la capa de servicio de integración con la herramienta de identidades. Sin ella, cada aplicación interna se integra por su cuenta con Keycloak, con su propio criterio sobre qué hacer cuando el token caduca, y acabas con doce comportamientos distintos ante la misma situación. Con ella, el comportamiento se define una vez.
Esto enlaza con lo que contamos en el otro artículo de hoy sobre la firma por lote: cuando una sola autenticación autoriza trescientas firmas, el precio de esa sesión sube mucho. La firma por lote es el caso donde el segundo factor deja de ser una política de cumplimiento y pasa a ser una decisión de riesgo. Está en la firma por lote no es un botón.
Las dos llamadas que recibe la mesa de ayuda
Aquí es donde un proyecto de este tipo se gana o se pierde, y donde la documentación de producto no ayuda.
«No tengo correo institucional». Es más frecuente de lo que parece en entidades con personal de campo, personal por locación de servicios o sedes desconcentradas. Si tu segundo factor viaja por correo, esa gente se queda fuera. Si viaja por SMS, dependes de un número personal que nadie mantiene actualizado en el legajo. La salida que menos problemas nos ha dado es el generador de códigos en el móvil, porque no necesita ni correo ni cobertura, con la contrapartida de que hay que enseñar a instalarlo.
«Cambié de celular y no puedo entrar». Esta es la que llega todos los lunes. Y es la que decide el nivel real de seguridad del sistema, porque el camino de recuperación es una autenticación alternativa: si para reponer el segundo factor basta con llamar y decir un nombre, el nivel de confianza del sistema entero es el de esa llamada, no el de los dos factores.
Nuestra recomendación en el sector público es que la reposición la haga el jefe inmediato o la oficina de personal contra el legajo, no la mesa de ayuda contra la voz del solicitante, y que quede registro de quién la autorizó. Es más lento y es lo único que sostiene la escala de niveles cuando alguien la audite.
Dimensionar eso tiene números: conviene estimar el volumen de reposiciones antes de arrancar, porque es un flujo permanente, no un pico de despliegue.
El orden que recomendamos
- Inventario de aplicaciones y de quién entra a cada una. Sin esto no se puede condicionar nada por rol y acabas aplicando el segundo factor a todos a la vez.
- La capa de integración primero, antes que el segundo factor. Es lo que evita que cada aplicación resuelva el vencimiento de sesión a su manera.
- Un grupo piloto con potestades altas, no un piloto de voluntarios del área de sistemas. El área de sistemas no genera las llamadas que hay que medir.
- El procedimiento de reposición escrito y aprobado antes del despliegue. Si sale después, sale improvisado.
- Ampliación por grupos, con la mesa de ayuda avisada de cada tanda.
Lo que no afirmamos
No decimos que implantar un segundo factor sitúe a una entidad en el nivel 2 del artículo 15 a efectos formales. Esa escala está escrita para la autenticación del ciudadano digital y su aplicación a los sistemas internos de una entidad es una decisión de la propia entidad y de su oficina de seguridad de la información.
Tampoco publicamos cifras de reducción de incidentes. No hemos medido un antes y un después con método suficiente para sostenerlas, y las que circulan en el mercado suelen venir de informes de proveedores sobre poblaciones que no se parecen a una entidad pública peruana.
Para terminar
La herramienta es la parte barata. Keycloak hace lo que promete y lleva años haciéndolo. Lo que cuesta es el inventario de aplicaciones, la capa de integración y el procedimiento de reposición, y los tres son trabajo de organización antes que de software.
Hemos hecho esa implantación y el fortalecimiento del esquema de autenticación y autorización que la hizo posible. Si estás en ese punto, conversemos sobre el alcance antes de que el proyecto se defina como «instalar Keycloak».
Última revisión: 15 de septiembre de 2026. Fuente normativa: Reglamento de la Ley de Gobierno Digital, aprobado por D.S. 029-2021-PCM, publicado el 19 de febrero de 2021, artículo 15.
