Identity-Sprawl en la mediana empresa: lo que tres configuraciones típicas de AD más nube revelan sobre la superficie de ataque real
6 min. de lectura
El Identity-Sprawl es la norma, no la excepción, en la mediana empresa. Quien analiza tres configuraciones típicas en paralelo -Active Directory con sincronización de Entra ID y SaaS paralelo, roles híbridos en hiperescaladores, infraestructura de IdP fragmentada con deudas técnicas- puede ver rápidamente dónde la documentación y la estructura real de permisos divergen. Los atacantes ven lo mismo, pero antes.
Lo esencial en resumen
- El Identity-Sprawl surge de herencias de AD, del uso paralelo de SaaS que ha crecido de forma descontrolada y de roles incompletos en hiperescaladores.
- Los permisos documentados y los permisos reales rara vez coinciden plenamente en la mediana empresa.
- El Kerberoasting, el Pass-the-Hash y los ataques Golden Ticket explotan exactamente estas brechas.
- La métrica crítica no es el número de cuentas, sino el delta entre el estado objetivo y el estado real.
- Una gestión centralizada de IAM con un ciclo de vida riguroso reduce la superficie de ataque de forma medible.
RelacionadoRiesgo de seguridad de Copilot en 2026 / Ransomware 2026: las empresas pagan
La suposición de que las identidades están gestionadas de forma centralizada rara vez resiste un inventario riguroso. Bajas de personal, cambios de proyecto, pruebas de SaaS, cuentas de servicio para integraciones desaparecidas: cada una de estas rutinas deja artefactos en alguno de los sistemas de identidad. La suma de estos artefactos constituye la superficie de ataque real, no el organigrama.
Tres configuraciones anonimizadas de entornos típicos de mediana empresa ilustran este patrón. Las tres son patrones genéricos, no casos aislados. Quien reconozca detalles propios en alguna de estas configuraciones debería revisar sus propios controles antes de que lo haga otra persona. Estado de la siguiente evaluación: abril de 2026.
¿Qué es el Identity-Sprawl?
El Identity-Sprawl describe el estado en el que las identidades de usuarios y servicios crecen a través de múltiples sistemas separados sin que un proceso de ciclo de vida común las mantenga de forma coherente. Cada uno de estos sistemas -Active Directory, Entra ID, herramientas de SaaS individuales, IAM en la nube- gestiona un subconjunto. El conjunto total rara vez es conocido en su totalidad por nadie.
Configuración 1: Active Directory, sincronización de Entra ID y SaaS no gestionado
El patrón más frecuente en la mediana empresa: un Active Directory local como sistema rector, Entra ID (antes Azure AD) sincronizado mediante Entra Connect, Microsoft 365 como base de productividad. Junto a esto crece un ecosistema de SaaS que nadie ha inventariado completamente.
En la documentación consta: AD es la fuente. El proceso de baja desactiva la cuenta de AD, la sincronización elimina al usuario de Entra y el acceso a Microsoft 365 queda revocado. En la realidad, existen en paralelo herramientas de SaaS con usuarios locales, herramientas con Google Login para el departamento de marketing y un CRM con inicio de sesión propio desde una prueba realizada hace tres años. El proceso de baja no alcanza a estos sistemas.
A esto se suma un detalle técnico que los administradores de AD conocen bien: las cuentas con Service Principal Name (SPN) son candidatas a Kerberoasting. En la práctica, las cuentas de servicio de antiguas integraciones de ERP o sistemas de monitorización suelen llevar SPNs y contraseñas débiles de una época en que el dominio era más pequeño. Un usuario de dominio autenticado basta para solicitar tickets de servicio y romperlos offline.
El desequilibrio en la configuración 1 reside entre la lógica limpia de activación/desactivación del AD y las herramientas de SaaS, que no participan en esa lógica. Quien solo endurece el AD, endurece la mitad del sistema.
Un inventario pragmático en un entorno de este tamaño encuentra regularmente entre ocho y veinte herramientas de SaaS que no figuran en el catálogo oficial. Automatización de marketing, suites de diseño, herramientas de gestión de proyectos, soluciones de control horario para determinadas oficinas. Cada una tiene su propio administrador, sus propias políticas de contraseñas y ninguna relación con el ciclo de vida del AD. En los cambios de personal, las licencias permanecen activas. En los cambios de herramienta, los datos históricos siguen siendo accesibles.
Configuración 2: Active Directory con roles híbridos en hiperescaladores
Las medianas empresas con mayor ambición técnica operan además cargas de trabajo en AWS o Azure. Los desarrolladores reciben roles, los equipos de DevOps automatizan despliegues y las cuentas de servicio se comunican con recursos en la nube mediante Access Keys o Managed Identities.
En la documentación consta: el acceso a la nube se gestiona a través de Entra ID o una integración de AWS SSO, y los roles están definidos con mínimos privilegios. En la realidad, los ingenieros han conservado roles temporales que se crearon para un sprint de migración en 2024. Una Access Key lleva dos años en un script alojado en un servidor de compilación. Un rol cross-account se creó para un proveedor externo anterior y nunca se eliminó.
El punto crítico es la capa de transición. Cuando una cuenta de AD puede asumir un rol en Azure a través de Entra ID y ese rol tiene acceso a KeyVaults o Storage Accounts, se crea un vector que rara vez está documentado en su totalidad. El Pass-the-Hash o el robo de tokens en un equipo local abre posibilidades que van mucho más allá del perímetro clásico de AD en esta constelación.
A esto se añade una particularidad del mundo de la nube que los auditorías de AD rara vez tienen en cuenta: los permisos suelen estar basados en roles, pero vinculados a cargas de trabajo que también tienen identidades propias. Una máquina virtual con Managed Identity, una pipeline con token OIDC, una función con System-Assigned Identity: no son usuarios en el sentido clásico, pero tienen derechos de acceso. Quien no inventaría estas identidades de carga de trabajo pasa por alto toda una clase de superficies de ataque potenciales. Las auditorías de cumplimiento contra ISO 27001 o los requisitos de NIS2 sobre control de acceso rara vez abordan esta capa de forma explícita.
Configuración 3: fragmentada, múltiples IdPs, cuentas de servicio obsoletas
El tercer patrón aparece con frecuencia tras adquisiciones, reorganizaciones o estructuras de fabricantes que han crecido de forma orgánica. Un AD local para la organización principal, un segundo AD procedente de una filial adquirida, un IdP separado para el entorno de producción y además Okta o Google Workspace para una línea de negocio.
La documentación suele calificar este estado como «transitorio». La realidad permanece así durante años. Las confianzas entre los dominios de AD se configuraron una vez y no se han vuelto a revisar. Las cuentas de servicio existen en ambos directorios, con permisos solapados y, con frecuencia, contraseñas idénticas. Los grupos privilegiados como «Domain Admins» contienen cuentas cuyo propósito original nadie puede ya reconstruir.
IAM centralizado versus estado actual fragmentado
| Dimensión | IAM centralizado | Estado actual fragmentado |
|---|---|---|
| Baja de personal | Un proceso que se propaga en cascada a todos los sistemas | Manual por sistema, con lagunas |
| Visibilidad | Una consola para todas las identidades | Varios portales de administración, sin comparación |
| Auditoría | Registro consolidado con eventos comparables | Fragmentos de registro en cada sistema |
| Esfuerzo de implantación | Elevado, requiere disciplina de procesos y herramientas | Bajo, surge de la ausencia de decisión |
| Superficie de ataque | Claramente delimitada, puede endurecerse de forma selectiva | Opaca, con deudas técnicas recurrentes |
El mayor factor de riesgo en la configuración 3 no es la fragmentación en sí, sino la suposición de que es temporal. Mientras ningún proceso de ciclo de vida elimine las deudas técnicas, el número de cuentas de servicio sin propietario identificable crece año tras año.
IAM centralizado – Ventajas
- Una vista consolidada de todas las identidades
- La baja de personal se propaga en cascada a todos los sistemas
- Los registros de auditoría son rastreables de forma continua
- Los accesos privilegiados pueden endurecerse de forma selectiva
Estado actual fragmentado – Ventajas
- Baja barrera de entrada inicial
- Los equipos individuales pueden trabajar de forma autónoma
- Los cambios de herramienta son posibles localmente
- Sin dependencia centralizada
IAM centralizado – Desventajas
- Elevado esfuerzo de implementación inicial
- Requiere disciplina de procesos en todos los departamentos
- Punto único de fallo en caso de interrupción
- Costes de licencia para plataformas IAM
Estado actual fragmentado – Desventajas
- Número creciente de cuentas huérfanas
- Sin vista de auditoría consolidada
- Brechas en el proceso de baja en cada cambio de personal
- La superficie de ataque escala con el tiempo
Lo que los atacantes encuentran de forma rutinaria
Las técnicas con las que se explotan estas brechas están documentadas y son estables desde hace años. Kerberoasting contra cuentas de servicio con contraseñas débiles. Pass-the-Hash a través de credenciales en caché local. Ataques Golden Ticket cuando un atacante ha tenido acceso a krbtgt en algún momento. Las tres técnicas no requieren zero-days, sino un dominio en el que la disciplina del ciclo de vida ha decaído durante años.
Es posible reconstruir un vector de ataque típico. Comienza de forma discreta y termina con acceso a sistemas que nunca estaban en el ámbito de atención principal.
Vector de ataque típico en entornos con Identity-Sprawl
T0 – Acceso inicial: correo de phishing, sesión comprometida en un portátil. El atacante se encuentra en el entorno como un usuario de dominio normal.
T+1 día – Enumeración: listado del dominio, grupos y Service Principal Names. Herramientas como BloodHound o técnicas similares mapean las rutas hacia cuentas privilegiadas.
T+2 días – Kerberoasting: solicitud de tickets de servicio para cuentas con SPN, fuerza bruta offline contra contraseñas débiles. Varias cuentas de servicio quedan comprometidas.
T+3 días – Movimiento lateral: una cuenta de servicio comprometida tiene acceso a un jump host. El Pass-the-Hash o los tokens en caché amplían el alcance.
T+5 días – Salto a la nube: una cuenta con roles híbridos permite el salto al entorno en la nube. Las Access Keys en scripts o los roles olvidados aceleran el camino.
T+7 días – Objetivo alcanzado: acceso a almacenamiento de archivos, bases de datos o sistemas de copias de seguridad. El entorno está completamente cartografiado desde la perspectiva del atacante.
El cronograma es genérico, pero realista en cuanto a magnitud. Quien no detecta el paso T+3 tampoco suele detectar T+7 hasta que los datos ya han sido exfiltrados.
Desde una perspectiva práctica, la situación puede resumirse así: la superficie de ataque en los entornos típicos de mediana empresa no es solo el AD, sino la suma del AD, las identidades en la nube sincronizadas, el SaaS no gestionado y las cuentas de servicio con deudas técnicas históricas. Quien no inventaría alguna de estas capas no está endureciendo el entorno real, sino su documentación.
En términos operativos concretos, esto implica: un inventario de todas las fuentes de identidad es el requisito previo de cualquier medida adicional. Por cada fuente, tres columnas: cuenta, último inicio de sesión, responsable. Quien no puede rellenar la segunda columna no tiene control sobre la primera. Quien no puede nombrar al responsable en la tercera no tiene un interlocutor para gestionar una baja. En esta sencillez reside el mayor apalancamiento y, al mismo tiempo, el punto donde la mayoría de los proyectos fracasan, porque no hay ningún responsable permanente.
La segunda capa es el endurecimiento de las cuentas ya inventariadas. Cuentas de servicio con SPN: contraseñas con longitud y complejidad suficientes, rotación en intervalos documentados. Grupos privilegiados: revisiones periódicas, modelo de administración por niveles donde sea posible. Cuenta krbtgt: doble restablecimiento en ciclo semestral. Contraseñas de administrador local: LAPS o soluciones equivalentes. Ninguna de estas medidas es nueva, todas están documentadas, y muchas fracasan en la implementación durante el trabajo diario.
El orden es importante: el inventario va antes que el endurecimiento. Una medida de endurecimiento aplicada a una cuenta que ya no debería estar activa es energía desperdiciada. Una medida de endurecimiento aplicada a una cuenta cuya existencia nadie conoce directamente no se aplica. Ambos casos son más frecuentes en la mediana empresa de lo que sugeriría la suposición de un entorno de cuentas ordenado. Un análisis honesto del estado actual produce generalmente más hallazgos que una herramienta nueva.
La tercera capa afecta a las transiciones a la nube. Acceso condicional en Entra ID, Privileged Identity Management para roles temporales, sin acceso cross-account permanente en AWS, identidades de carga de trabajo en lugar de Access Keys de larga duración. Aquí también aplica: los conceptos están documentados, la implementación requiere atención sostenida durante varios trimestres.
La consecuencia pragmática no es el gran proyecto IAM para finales del ejercicio fiscal. Es un inventario sencillo: qué identidades existen, quién las creó, quién las utilizó por última vez, qué derechos tienen hoy. Esta lista, gestionada con honestidad, determina la distancia entre el estado objetivo y el estado real, y por tanto la superficie de ataque real.
Preguntas frecuentes
¿Qué es exactamente el Identity-Sprawl?
El Identity-Sprawl designa la expansión descontrolada de identidades de usuarios y servicios a través de múltiples sistemas, sin que un proceso de ciclo de vida centralizado las mantenga de forma coherente. Los factores desencadenantes típicos son la proliferación no controlada de SaaS, las estructuras de AD con deudas técnicas históricas y los roles paralelos en hiperescaladores. El término se utiliza tanto en publicaciones próximas al BSI como en el debate internacional sobre IAM.
¿En qué se diferencia el Identity-Sprawl del Privilege Creep?
El Privilege Creep describe el crecimiento de los permisos individuales de una cuenta a lo largo del tiempo. El Identity-Sprawl es un nivel superior: el crecimiento en el número de identidades y en los sistemas en los que existen. En la práctica, ambos fenómenos se producen conjuntamente y se refuerzan mutuamente.
¿Por qué no basta con un AD centralizado?
Un AD regula lo que está documentado y conectado. Las herramientas de SaaS con inicio de sesión local, los roles en la nube sin integración completa en Entra y las deudas técnicas de adquisiciones frecuentemente quedan fuera de este control. El panorama real de permisos es mayor que lo que es visible en el AD.
¿Cuál es el mecanismo más rápido para reducir la superficie de ataque?
Un inventario riguroso de todas las cuentas de servicio, seguido de la rotación de contraseñas y la eliminación de las cuentas que ya no son necesarias. En paralelo: revisión del grupo «Domain Admins» y otros grupos con privilegios similares. Ambas acciones son posibles sin inversión en herramientas y abordan los vectores de ataque reales más frecuentes.
¿Siguen siendo relevantes hoy el Kerberoasting o el Pass-the-Hash?
Ambas técnicas están documentadas, son estables desde hace años y forman parte del repertorio estándar en los tests de penetración. Funcionan no porque sean nuevas, sino porque las debilidades subyacentes del AD permanecen inalteradas en muchos entornos.
Lecturas recomendadas por la redacción
- Infostealer 2026: por qué las cookies de sesión robadas eluden la MFA
- Los certificados de Secure Boot caducan en junio de 2026
Más de la red MBF Media
Platform Engineering 2026: por qué las Internal Developer Platforms son el nuevo fundamento
E-Rechnung 2026: qué funciona realmente 15 meses después del inicio obligatorio
Cloud Repatriation 2026: una ilusión estadística
Fuente de la imagen de portada: Pexels / Brett Sayles (px:4716292)
