Autenticación multifactor e identidad en ayuntamientos: cómo contratar MFA y control de accesos
La autenticación multifactor en ayuntamientos es una de las medidas más efectivas para reducir el riesgo asociado a credenciales robadas, phishing y accesos indebidos. Sin embargo, implantar MFA de forma aislada no resuelve todos los problemas de identidad. La entidad necesita saber quién tiene acceso a cada sistema, con qué nivel de privilegio, cómo se crean y eliminan cuentas y qué ocurre cuando una persona cambia de puesto o deja la organización.
Por eso conviene plantear el proyecto como una combinación de identidad, autenticación y gobierno de accesos. Puede incluir directorio corporativo, SSO, MFA, gestión de cuentas privilegiadas, acceso remoto, revisión periódica de permisos e integración con aplicaciones municipales.
La contratación debe alinearse con el Esquema Nacional de Seguridad y con la estrategia de adecuación ENS del ayuntamiento. También debe coordinarse con la ciberseguridad gestionada municipal, porque los eventos de identidad son una de las fuentes de detección más importantes.
Qué es la autenticación multifactor
MFA exige combinar más de un factor para validar el acceso. Puede utilizar algo que el usuario conoce, algo que posee o una característica inherente.
El objetivo es impedir que una contraseña robada sea suficiente para entrar. Si un atacante obtiene credenciales mediante phishing, todavía necesitaría superar el segundo factor.
El diseño debe valorar usabilidad, seguridad y compatibilidad con los sistemas existentes.
MFA no es solo un código SMS
Existen aplicaciones de autenticación, notificaciones push, claves físicas, certificados, biometría y otros mecanismos.
La elección depende del nivel de riesgo y del tipo de usuario. Las cuentas administrativas pueden requerir factores más resistentes al phishing que una cuenta de bajo impacto.
El pliego debe permitir evolucionar métodos sin rehacer toda la arquitectura.
Inventario de identidades
Antes de desplegar MFA conviene inventariar cuentas de empleados, proveedores, aplicaciones, servicios y administradores.
Una auditoría tecnológica municipal ayuda a detectar cuentas antiguas, duplicadas o compartidas.
El inventario debe relacionar identidad, sistema, propietario y nivel de privilegio.
Directorio corporativo
Centralizar identidades facilita aplicar políticas coherentes. Puede utilizarse un directorio local, cloud o híbrido según arquitectura.
El directorio debe ser fuente de referencia para usuarios y grupos cuando sea posible.
Esto reduce la creación manual de cuentas independientes en cada aplicación.
Single Sign-On
SSO permite acceder a varias aplicaciones mediante una identidad común. Reduce contraseñas y simplifica altas y bajas.
La integración debe utilizar estándares soportados por cada plataforma.
Una arquitectura SSO bien diseñada facilita aplicar MFA y políticas de acceso de forma centralizada.
Altas de usuarios
El proceso de alta debe comenzar con una solicitud aprobada y definir qué grupos y aplicaciones necesita la persona.
La automatización puede crear cuentas, asignar licencias y notificar al responsable.
La automatización de procesos administrativos puede utilizarse para reducir tareas manuales y mantener trazabilidad.
Cambios de puesto
Cuando un empleado cambia de unidad, no debería acumular indefinidamente permisos antiguos.
El proceso debe revisar accesos existentes y asignar únicamente los necesarios para la nueva función.
La gestión de identidad debe contemplar movilidad interna como un evento tan importante como el alta o la baja.
Bajas de usuarios
Las cuentas de personas que dejan la organización deben desactivarse con rapidez.
También hay que transferir buzones, archivos, propiedad de documentos y responsabilidades sobre aplicaciones.
Un flujo automatizado puede reducir el riesgo de olvidar cuentas secundarias.
Cuentas de proveedores
Los adjudicatarios pueden necesitar acceso temporal a sistemas. Estas cuentas deben tener propietario, fecha de caducidad y permisos limitados.
No conviene mantener accesos genéricos abiertos durante años por comodidad.
La contratación de mantenimiento de software municipal debe coordinarse con estas reglas.
Cuentas compartidas
Las cuentas compartidas dificultan la trazabilidad. Si varias personas utilizan las mismas credenciales, resulta difícil saber quién realizó una acción.
Siempre que sea posible deben sustituirse por identidades nominales y roles.
Cuando una cuenta técnica no pueda eliminarse, debe protegerse y documentarse.
Cuentas privilegiadas
Los administradores representan uno de los mayores riesgos si sus credenciales son comprometidas.
Conviene separar cuentas de uso diario y cuentas administrativas, aplicar MFA fuerte y limitar privilegios.
Las operaciones sensibles deberían quedar registradas y revisarse.
Mínimo privilegio
Cada usuario debería disponer únicamente de los permisos necesarios para su trabajo.
El exceso de privilegios aumenta el impacto de errores y cuentas comprometidas.
El proyecto debe incluir una revisión inicial y un proceso periódico de recertificación.
Roles y grupos
Gestionar permisos mediante roles facilita mantener coherencia.
En lugar de configurar usuario por usuario, pueden definirse perfiles por unidad o función.
Las excepciones deben documentarse para evitar que se conviertan en la norma.
Acceso remoto
VPN, escritorios remotos y herramientas de soporte deben incorporar MFA cuando el riesgo lo justifique.
El acceso puede condicionarse al dispositivo, ubicación, horario o nivel de cumplimiento.
El SOC debería monitorizar intentos anómalos y cambios de privilegios.
Acceso condicional
Las políticas de acceso condicional permiten adaptar controles al contexto. Un inicio desde un dispositivo desconocido puede requerir una verificación adicional.
Estas reglas deben diseñarse con pruebas para evitar bloquear trabajo legítimo.
El ayuntamiento necesita un procedimiento de excepción y recuperación.
Dispositivos de confianza
La identidad puede combinarse con gestión de dispositivos para reducir riesgo.
Un equipo corporativo actualizado puede recibir un tratamiento distinto de un dispositivo personal no gestionado.
El contrato debe definir qué plataformas participan y qué información se utiliza para la decisión.
Aplicaciones municipales heredadas
Algunas aplicaciones antiguas no soportan SSO o MFA moderno. El proyecto debe identificarlas desde el inicio.
Pueden requerir gateways, proxies, integración adicional o una estrategia de sustitución.
La integración de sistemas municipales puede ayudar a diseñar soluciones intermedias sin crear nuevos silos.
Sede y aplicaciones ciudadanas
La identidad de empleados no debe confundirse con los mecanismos de identificación de ciudadanos.
El proyecto debe separar claramente acceso interno, acceso de proveedores y autenticación de usuarios externos.
La sede electrónica municipal tiene sus propios requisitos y servicios de identificación.
Cloud y SaaS
Las aplicaciones cloud suelen facilitar integración con proveedores de identidad.
La migración a la nube en ayuntamientos debería revisar SSO, MFA y roles antes de trasladar usuarios.
Esto evita replicar permisos históricos en una arquitectura nueva.
Software a medida
Las nuevas aplicaciones deberían integrarse con identidad corporativa en lugar de crear contraseñas propias cuando sea razonable.
La guía sobre software a medida para Administraciones Públicas explica cómo incluir autenticación, permisos y trazabilidad desde diseño.
El desarrollador debe documentar roles y mecanismos de integración.
APIs y cuentas de servicio
Las integraciones utilizan tokens, certificados o cuentas técnicas.
Estas identidades también deben inventariarse, rotarse y limitarse.
No conviene utilizar credenciales personales dentro de scripts o conectores.
Gestión de secretos
Contraseñas de servicio, claves API y certificados deben almacenarse en mecanismos adecuados.
El acceso a secretos debe quedar restringido y auditado.
Cuando cambia un proveedor, las credenciales relacionadas deben rotarse.
Logs de autenticación
Los inicios de sesión correctos y fallidos, altas, cambios de roles y eventos de MFA deben registrarse.
Estos datos alimentan el SOC y SIEM municipal.
La conservación debe equilibrar investigación, privacidad y capacidad.
Detección de accesos anómalos
Intentos desde países inusuales, múltiples fallos, MFA repetido o cambios rápidos de ubicación pueden ser señales de compromiso.
Las alertas deben investigarse con contexto y evitar respuestas automáticas demasiado agresivas.
El servicio debe definir casos de uso y responsables.
Fatiga de MFA
Un atacante puede intentar enviar múltiples solicitudes push esperando que el usuario acepte una por error.
El diseño debe utilizar mecanismos resistentes a este patrón cuando el proveedor lo permita.
La formación también debe explicar que una solicitud inesperada debe rechazarse y notificarse.
Recuperación de acceso
Los usuarios pueden perder un dispositivo o cambiar de teléfono. Debe existir un procedimiento seguro para recuperar MFA.
La recuperación no puede convertirse en una puerta trasera más débil que el propio segundo factor.
El soporte debe verificar identidad con criterios definidos.
Break glass
Las cuentas de emergencia permiten recuperar administración si el proveedor de identidad está caído.
Deben estar muy protegidas, monitorizadas y probarse periódicamente.
Su existencia no debe convertirse en un acceso cotidiano para evitar controles.
Revisión periódica de permisos
Responsables de unidades pueden revisar qué personas tienen acceso a sus aplicaciones.
La recertificación detecta cuentas antiguas y privilegios acumulados.
El proceso debe ser sencillo para que se complete de forma real y no se limite a aprobar listados sin revisar.
MFA para administradores
Las cuentas con capacidad para cambiar configuraciones, usuarios o datos críticos deberían tener una protección reforzada.
Pueden utilizarse factores resistentes a phishing y estaciones administrativas dedicadas según el nivel de riesgo.
El ENS y la categorización del sistema orientan la proporcionalidad.
MFA para empleados
El despliegue general debe considerar colectivos, dispositivos y aplicaciones.
Puede realizarse por fases, empezando por accesos remotos y servicios más críticos.
La comunicación previa reduce incidencias durante la activación.
Onboarding del proyecto
La implantación debe comenzar con inventario de aplicaciones, usuarios, métodos actuales y excepciones.
Después se configura una fase piloto con un grupo representativo.
Los resultados permiten ajustar políticas antes de extenderlas.
Piloto
El piloto debe probar login, recuperación, dispositivos nuevos, cambio de puesto, acceso remoto y aplicaciones antiguas.
También conviene medir volumen de incidencias y tiempos de soporte.
La aceptación debe basarse en escenarios reales.
Migración por fases
Un despliegue gradual reduce riesgo. Puede agruparse por unidad, aplicación o criticidad.
El calendario debe evitar periodos especialmente sensibles.
Cada fase necesita criterios de cierre y resolución de excepciones.
Soporte a usuarios
Durante el despliegue aumentan consultas por dispositivos, códigos y recuperación.
El contrato debe definir canales, horario y procedimientos de soporte.
La documentación debe ser clara y adaptada a usuarios no técnicos.
SLA
Una persona bloqueada puede quedar sin acceso a herramientas críticas. El soporte necesita tiempos acordes al impacto.
Los SLA pueden diferenciar problemas individuales y fallos globales del sistema de identidad.
La guía de pliego técnico municipal ayuda a convertirlos en requisitos medibles.
Disponibilidad del proveedor de identidad
La autenticación se convierte en una dependencia crítica. El contrato debe revisar disponibilidad, redundancia y procedimientos ante caída.
También conviene conocer qué aplicaciones pueden mantener sesiones existentes durante una interrupción.
Las cuentas de emergencia forman parte del plan de continuidad.
Copias y configuración
La identidad también necesita recuperación. Configuraciones, grupos, políticas y documentación deben poder reconstruirse.
La guía sobre backup y disaster recovery municipal ayuda a integrar esta dependencia en el plan general.
El proveedor debe explicar qué elementos se pueden exportar.
Autenticación sin contraseña y evolución futura
La estrategia de identidad debería permitir evolucionar hacia mecanismos resistentes al phishing y reducir la dependencia de contraseñas cuando las aplicaciones y el nivel de riesgo lo permitan. El pliego puede exigir compatibilidad con estándares modernos, dispositivos corporativos y métodos de recuperación controlados.
También conviene revisar periódicamente qué aplicaciones siguen obligando a mantener autenticación heredada, porque esos sistemas suelen concentrar excepciones y dificultar una política homogénea. La hoja de ruta debe fijar prioridades para integrarlos, aislarlos o sustituirlos sin interrumpir servicios municipales.
Cómo preparar el pliego
El pliego debe definir directorios, aplicaciones, usuarios, métodos de MFA, SSO, políticas, cuentas privilegiadas, altas y bajas, soporte, logs, SLA y reversibilidad.
La categoría de contratación pública reúne criterios complementarios para servicios tecnológicos.
También debe quedar claro quién aporta licencias y cómo se calculará su crecimiento.
Criterios técnicos de adjudicación
Puede valorarse metodología de migración, compatibilidad, seguridad, automatización de ciclo de vida, soporte, reporting y transferencia de conocimiento.
La propuesta debe explicar cómo gestionará aplicaciones heredadas y excepciones.
La facilidad de reversibilidad también debe formar parte de la evaluación.
Qué puede aportar BlackHold Consulting
Los proyectos de identidad necesitan integración y automatización. BlackHold Consulting trabaja en digitalización e integración de procesos, automatización de procesos, automatización administrativa y gestión documental automatizada.
También dispone de capacidades en procesos tecnológicos complejos, consultoría tecnológica, agentes e integraciones y servicios de automatización. Estas capacidades pueden aplicarse a altas, bajas, integraciones, soporte y gobierno de identidades mediante la contratación pública que corresponda.
Checklist antes de contratar MFA e identidad
Inventario
¿Se conocen usuarios, aplicaciones y cuentas técnicas?
MFA
¿Los factores se adaptan al nivel de riesgo?
SSO
¿Las aplicaciones principales pueden integrarse?
Privilegios
¿Las cuentas administrativas están separadas y controladas?
Ciclo de vida
¿Altas, cambios y bajas tienen un proceso trazable?
Logs
¿Los eventos alimentan la monitorización de seguridad?
Soporte
¿Existe recuperación segura de acceso?
Salida
¿La entidad puede cambiar de proveedor sin reconstruir todas las identidades?
Preguntas frecuentes
La aplicación debe ser proporcional al riesgo y a las medidas exigibles para cada sistema, aunque ampliar MFA a los accesos relevantes reduce de forma importante el riesgo de credenciales robadas.
Depende del riesgo, compatibilidad y usuarios. Las cuentas privilegiadas suelen requerir métodos más resistentes al phishing.
MFA añade factores de autenticación; SSO permite utilizar una identidad común para acceder a varias aplicaciones.
Con cuentas nominales o controladas, permisos mínimos, MFA y fecha de caducidad cuando proceda.
Debe existir un proceso seguro de recuperación y registro de un nuevo factor.
Automatizando cambios de puesto, revisando grupos y realizando recertificaciones periódicas.
Conclusión
La autenticación multifactor aporta mucho valor, pero su eficacia aumenta cuando forma parte de una estrategia completa de identidad y accesos. Inventario, SSO, ciclo de vida, mínimo privilegio y monitorización deben diseñarse conjuntamente.
El ayuntamiento necesita saber quién accede a cada sistema y disponer de mecanismos rápidos para conceder, modificar y retirar permisos.
Un proyecto bien contratado reduce el riesgo de credenciales comprometidas, simplifica la administración y proporciona una base más sólida para integrar aplicaciones cloud, sistemas municipales y nuevos servicios digitales.
La integración segura de sistemas y aplicaciones cloud no es solo un reto de la administración pública: las empresas privadas se enfrentan a lo mismo al digitalizarse. En BlackHold Consulting explican cómo exigir garantías de seguridad y control de accesos al contratar un desarrollo de software.
Fotografía: indra projects / Pexels.
