6 min. de lectura<\/p>\n
El Identity-Sprawl es la norma, no la excepci\u00f3n, en la mediana empresa. Quien analiza tres configuraciones t\u00edpicas en paralelo -Active Directory con sincronizaci\u00f3n de Entra ID y SaaS paralelo, roles h\u00edbridos en hiperescaladores, infraestructura de IdP fragmentada con deudas t\u00e9cnicas- puede ver r\u00e1pidamente d\u00f3nde la documentaci\u00f3n y la estructura real de permisos divergen. Los atacantes ven lo mismo, pero antes.<\/strong><\/p>\n Lo esencial en resumen<\/p>\n Relacionado<\/span>Riesgo de seguridad de Copilot en 2026 \/<\/span> Ransomware 2026: las empresas pagan<\/p>\n La suposici\u00f3n de que las identidades est\u00e1n 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.<\/p>\n Tres configuraciones anonimizadas de entornos t\u00edpicos de mediana empresa ilustran este patr\u00f3n. Las tres son patrones gen\u00e9ricos, no casos aislados. Quien reconozca detalles propios en alguna de estas configuraciones deber\u00eda revisar sus propios controles antes de que lo haga otra persona. Estado de la siguiente evaluaci\u00f3n: abril de 2026.<\/p>\n \u00bfQu\u00e9 es el Identity-Sprawl?<\/p>\n El Identity-Sprawl describe el estado en el que las identidades de usuarios y servicios crecen a trav\u00e9s de m\u00faltiples sistemas separados sin que un proceso de ciclo de vida com\u00fan 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.<\/p>\n<\/div>\n El patr\u00f3n m\u00e1s 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.<\/p>\n En la documentaci\u00f3n consta: AD es la fuente. El proceso de baja desactiva la cuenta de AD, la sincronizaci\u00f3n 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\u00f3n propio desde una prueba realizada hace tres a\u00f1os. El proceso de baja no alcanza a estos sistemas.<\/p>\n A esto se suma un detalle t\u00e9cnico que los administradores de AD conocen bien: las cuentas con Service Principal Name (SPN) son candidatas a Kerberoasting. En la pr\u00e1ctica, las cuentas de servicio de antiguas integraciones de ERP o sistemas de monitorizaci\u00f3n suelen llevar SPNs y contrase\u00f1as d\u00e9biles de una \u00e9poca en que el dominio era m\u00e1s peque\u00f1o. Un usuario de dominio autenticado basta para solicitar tickets de servicio y romperlos offline.<\/p>\n El desequilibrio en la configuraci\u00f3n 1 reside entre la l\u00f3gica limpia de activaci\u00f3n\/desactivaci\u00f3n del AD y las herramientas de SaaS, que no participan en esa l\u00f3gica. Quien solo endurece el AD, endurece la mitad del sistema.<\/p>\n Un inventario pragm\u00e1tico en un entorno de este tama\u00f1o encuentra regularmente entre ocho y veinte herramientas de SaaS que no figuran en el cat\u00e1logo oficial. Automatizaci\u00f3n de marketing, suites de dise\u00f1o, herramientas de gesti\u00f3n de proyectos, soluciones de control horario para determinadas oficinas. Cada una tiene su propio administrador, sus propias pol\u00edticas de contrase\u00f1as y ninguna relaci\u00f3n con el ciclo de vida del AD. En los cambios de personal, las licencias permanecen activas. En los cambios de herramienta, los datos hist\u00f3ricos siguen siendo accesibles.<\/p>\n Las medianas empresas con mayor ambici\u00f3n t\u00e9cnica operan adem\u00e1s 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.<\/p>\n En la documentaci\u00f3n consta: el acceso a la nube se gestiona a trav\u00e9s de Entra ID o una integraci\u00f3n de AWS SSO, y los roles est\u00e1n definidos con m\u00ednimos privilegios. En la realidad, los ingenieros han conservado roles temporales que se crearon para un sprint de migraci\u00f3n en 2024. Una Access Key lleva dos a\u00f1os en un script alojado en un servidor de compilaci\u00f3n. Un rol cross-account se cre\u00f3 para un proveedor externo anterior y nunca se elimin\u00f3.<\/p>\n El punto cr\u00edtico es la capa de transici\u00f3n. Cuando una cuenta de AD puede asumir un rol en Azure a trav\u00e9s de Entra ID y ese rol tiene acceso a KeyVaults o Storage Accounts, se crea un vector que rara vez est\u00e1 documentado en su totalidad. El Pass-the-Hash o el robo de tokens en un equipo local abre posibilidades que van mucho m\u00e1s all\u00e1 del per\u00edmetro cl\u00e1sico de AD en esta constelaci\u00f3n.<\/p>\n A esto se a\u00f1ade una particularidad del mundo de la nube que los auditor\u00edas de AD rara vez tienen en cuenta: los permisos suelen estar basados en roles, pero vinculados a cargas de trabajo que tambi\u00e9n tienen identidades propias. Una m\u00e1quina virtual con Managed Identity, una pipeline con token OIDC, una funci\u00f3n con System-Assigned Identity: no son usuarios en el sentido cl\u00e1sico, pero tienen derechos de acceso. Quien no inventar\u00eda estas identidades de carga de trabajo pasa por alto toda una clase de superficies de ataque potenciales. Las auditor\u00edas de cumplimiento contra ISO 27001 o los requisitos de NIS2 sobre control de acceso rara vez abordan esta capa de forma expl\u00edcita.<\/p>\n El tercer patr\u00f3n aparece con frecuencia tras adquisiciones, reorganizaciones o estructuras de fabricantes que han crecido de forma org\u00e1nica. Un AD local para la organizaci\u00f3n principal, un segundo AD procedente de una filial adquirida, un IdP separado para el entorno de producci\u00f3n y adem\u00e1s Okta o Google Workspace para una l\u00ednea de negocio.<\/p>\n La documentaci\u00f3n suele calificar este estado como \u00abtransitorio\u00bb. La realidad permanece as\u00ed durante a\u00f1os. 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\u00f1as id\u00e9nticas. Los grupos privilegiados como \u00abDomain Admins\u00bb contienen cuentas cuyo prop\u00f3sito original nadie puede ya reconstruir.<\/p>\n El mayor factor de riesgo en la configuraci\u00f3n 3 no es la fragmentaci\u00f3n en s\u00ed, sino la suposici\u00f3n de que es temporal. Mientras ning\u00fan proceso de ciclo de vida elimine las deudas t\u00e9cnicas, el n\u00famero de cuentas de servicio sin propietario identificable crece a\u00f1o tras a\u00f1o.<\/p>\n IAM centralizado – Ventajas<\/p>\n Estado actual fragmentado – Ventajas<\/p>\n IAM centralizado – Desventajas<\/p>\n Estado actual fragmentado – Desventajas<\/p>\n Las t\u00e9cnicas con las que se explotan estas brechas est\u00e1n documentadas y son estables desde hace a\u00f1os. Kerberoasting contra cuentas de servicio con contrase\u00f1as d\u00e9biles. Pass-the-Hash a trav\u00e9s de credenciales en cach\u00e9 local. Ataques Golden Ticket cuando un atacante ha tenido acceso a krbtgt en alg\u00fan momento. Las tres t\u00e9cnicas no requieren zero-days, sino un dominio en el que la disciplina del ciclo de vida ha deca\u00eddo durante a\u00f1os.<\/p>\n Es posible reconstruir un vector de ataque t\u00edpico. Comienza de forma discreta y termina con acceso a sistemas que nunca estaban en el \u00e1mbito de atenci\u00f3n principal.<\/p>\n T0 – Acceso inicial:<\/strong> correo de phishing, sesi\u00f3n comprometida en un port\u00e1til. El atacante se encuentra en el entorno como un usuario de dominio normal.<\/p>\n T+1 d\u00eda – Enumeraci\u00f3n:<\/strong> listado del dominio, grupos y Service Principal Names. Herramientas como BloodHound o t\u00e9cnicas similares mapean las rutas hacia cuentas privilegiadas.<\/p>\n T+2 d\u00edas – Kerberoasting:<\/strong> solicitud de tickets de servicio para cuentas con SPN, fuerza bruta offline contra contrase\u00f1as d\u00e9biles. Varias cuentas de servicio quedan comprometidas.<\/p>\n T+3 d\u00edas – Movimiento lateral:<\/strong> una cuenta de servicio comprometida tiene acceso a un jump host. El Pass-the-Hash o los tokens en cach\u00e9 ampl\u00edan el alcance.<\/p>\n T+5 d\u00edas – Salto a la nube:<\/strong> una cuenta con roles h\u00edbridos permite el salto al entorno en la nube. Las Access Keys en scripts o los roles olvidados aceleran el camino.<\/p>\n T+7 d\u00edas – Objetivo alcanzado:<\/strong> acceso a almacenamiento de archivos, bases de datos o sistemas de copias de seguridad. El entorno est\u00e1 completamente cartografiado desde la perspectiva del atacante.<\/p>\n<\/div>\n El cronograma es gen\u00e9rico, 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.<\/p>\n Desde una perspectiva pr\u00e1ctica, la situaci\u00f3n puede resumirse as\u00ed: la superficie de ataque en los entornos t\u00edpicos 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\u00e9cnicas hist\u00f3ricas. Quien no inventar\u00eda alguna de estas capas no est\u00e1 endureciendo el entorno real, sino su documentaci\u00f3n.<\/p>\n En t\u00e9rminos 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, \u00faltimo inicio de sesi\u00f3n, 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\u00eda de los proyectos fracasan, porque no hay ning\u00fan responsable permanente.<\/p>\n La segunda capa es el endurecimiento de las cuentas ya inventariadas. Cuentas de servicio con SPN: contrase\u00f1as con longitud y complejidad suficientes, rotaci\u00f3n en intervalos documentados. Grupos privilegiados: revisiones peri\u00f3dicas, modelo de administraci\u00f3n por niveles donde sea posible. Cuenta krbtgt: doble restablecimiento en ciclo semestral. Contrase\u00f1as de administrador local: LAPS o soluciones equivalentes. Ninguna de estas medidas es nueva, todas est\u00e1n documentadas, y muchas fracasan en la implementaci\u00f3n durante el trabajo diario.<\/p>\n El orden es importante: el inventario va antes que el endurecimiento. Una medida de endurecimiento aplicada a una cuenta que ya no deber\u00eda estar activa es energ\u00eda desperdiciada. Una medida de endurecimiento aplicada a una cuenta cuya existencia nadie conoce directamente no se aplica. Ambos casos son m\u00e1s frecuentes en la mediana empresa de lo que sugerir\u00eda la suposici\u00f3n de un entorno de cuentas ordenado. Un an\u00e1lisis honesto del estado actual produce generalmente m\u00e1s hallazgos que una herramienta nueva.<\/p>\n 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\u00f3n. Aqu\u00ed tambi\u00e9n aplica: los conceptos est\u00e1n documentados, la implementaci\u00f3n requiere atenci\u00f3n sostenida durante varios trimestres.<\/p>\n La consecuencia pragm\u00e1tica no es el gran proyecto IAM para finales del ejercicio fiscal. Es un inventario sencillo: qu\u00e9 identidades existen, qui\u00e9n las cre\u00f3, qui\u00e9n las utiliz\u00f3 por \u00faltima vez, qu\u00e9 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.<\/p>\n El Identity-Sprawl designa la expansi\u00f3n descontrolada de identidades de usuarios y servicios a trav\u00e9s de m\u00faltiples sistemas, sin que un proceso de ciclo de vida centralizado las mantenga de forma coherente. Los factores desencadenantes t\u00edpicos son la proliferaci\u00f3n no controlada de SaaS, las estructuras de AD con deudas t\u00e9cnicas hist\u00f3ricas y los roles paralelos en hiperescaladores. El t\u00e9rmino se utiliza tanto en publicaciones pr\u00f3ximas al BSI como en el debate internacional sobre IAM.<\/p>\n 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\u00famero de identidades y en los sistemas en los que existen. En la pr\u00e1ctica, ambos fen\u00f3menos se producen conjuntamente y se refuerzan mutuamente.<\/p>\n Un AD regula lo que est\u00e1 documentado y conectado. Las herramientas de SaaS con inicio de sesi\u00f3n local, los roles en la nube sin integraci\u00f3n completa en Entra y las deudas t\u00e9cnicas de adquisiciones frecuentemente quedan fuera de este control. El panorama real de permisos es mayor que lo que es visible en el AD.<\/p>\n Un inventario riguroso de todas las cuentas de servicio, seguido de la rotaci\u00f3n de contrase\u00f1as y la eliminaci\u00f3n de las cuentas que ya no son necesarias. En paralelo: revisi\u00f3n del grupo \u00abDomain Admins\u00bb y otros grupos con privilegios similares. Ambas acciones son posibles sin inversi\u00f3n en herramientas y abordan los vectores de ataque reales m\u00e1s frecuentes.<\/p>\n Ambas t\u00e9cnicas est\u00e1n documentadas, son estables desde hace a\u00f1os y forman parte del repertorio est\u00e1ndar en los tests de penetraci\u00f3n. Funcionan no porque sean nuevas, sino porque las debilidades subyacentes del AD permanecen inalteradas en muchos entornos.<\/p>\n Lecturas recomendadas por la redacci\u00f3n<\/p>\n M\u00e1s de la red MBF Media<\/p>\n Platform Engineering 2026: por qu\u00e9 las Internal Developer Platforms son el nuevo fundamento\n<\/p><\/div>\n E-Rechnung 2026: qu\u00e9 funciona realmente 15 meses despu\u00e9s del inicio obligatorio\n<\/p><\/div>\n Cloud Repatriation 2026: una ilusi\u00f3n estad\u00edstica\n<\/p><\/div>\n<\/div>\n Fuente de la imagen de portada: Pexels \/ Brett Sayles (px:4716292)<\/p>\n","protected":false},"excerpt":{"rendered":"AD con sincronizaci\u00f3n de Entra ID, roles h\u00edbridos en hiperescaladores, infraestructura de IdP fragmentada: tres configuraciones muestran d\u00f3nde divergen la documentaci\u00f3n y la realidad.","protected":false},"author":10,"featured_media":12316,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_focuskw":"Entorno IdP fragmentado pymes","_yoast_wpseo_title":"Identity-Sprawl en la mediana empresa: lo que tres","_yoast_wpseo_metadesc":"Identity-Sprawl en la mediana empresa: tres configuraciones de AD m\u00e1s nube, sus vulnerabilidades y los vectores de ataque que los atacantes explotan de forma rutinaria.","_yoast_wpseo_meta-robots-noindex":"","_yoast_wpseo_meta-robots-nofollow":"","_yoast_wpseo_meta-robots-adv":"","_yoast_wpseo_canonical":"","_yoast_wpseo_opengraph-title":"","_yoast_wpseo_opengraph-description":"","_yoast_wpseo_opengraph-image":"","_yoast_wpseo_opengraph-image-id":0,"_yoast_wpseo_twitter-title":"","_yoast_wpseo_twitter-description":"","_yoast_wpseo_twitter-image":"","_yoast_wpseo_twitter-image-id":0,"_evm_translation_lang":"","featured_post":0,"featured_post_sortierung":0,"_wp_old_slug":[],"footnotes":""},"categories":[223],"tags":[],"class_list":["post-12669","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-case-studies"],"evm_reading_time_minutes":15,"wpml_language":"es","wpml_translation_of":12317,"_links":{"self":[{"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/posts\/12669","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/comments?post=12669"}],"version-history":[{"count":1,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/posts\/12669\/revisions"}],"predecessor-version":[{"id":12701,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/posts\/12669\/revisions\/12701"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/media\/12316"}],"wp:attachment":[{"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/media?parent=12669"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/categories?post=12669"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/tags?post=12669"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Configuraci\u00f3n 1: Active Directory, sincronizaci\u00f3n de Entra ID y SaaS no gestionado<\/h2>\n
Configuraci\u00f3n 2: Active Directory con roles h\u00edbridos en hiperescaladores<\/h2>\n
Configuraci\u00f3n 3: fragmentada, m\u00faltiples IdPs, cuentas de servicio obsoletas<\/h2>\n
IAM centralizado versus estado actual fragmentado<\/h3>\n
\n
\n Dimensi\u00f3n<\/th>\n IAM centralizado<\/th>\n Estado actual fragmentado<\/th>\n<\/tr>\n \n Baja de personal<\/strong><\/td>\n Un proceso que se propaga en cascada a todos los sistemas<\/td>\n Manual por sistema, con lagunas<\/td>\n<\/tr>\n \n Visibilidad<\/strong><\/td>\n Una consola para todas las identidades<\/td>\n Varios portales de administraci\u00f3n, sin comparaci\u00f3n<\/td>\n<\/tr>\n \n Auditor\u00eda<\/strong><\/td>\n Registro consolidado con eventos comparables<\/td>\n Fragmentos de registro en cada sistema<\/td>\n<\/tr>\n \n Esfuerzo de implantaci\u00f3n<\/strong><\/td>\n Elevado, requiere disciplina de procesos y herramientas<\/td>\n Bajo, surge de la ausencia de decisi\u00f3n<\/td>\n<\/tr>\n \n Superficie de ataque<\/strong><\/td>\n Claramente delimitada, puede endurecerse de forma selectiva<\/td>\n Opaca, con deudas t\u00e9cnicas recurrentes<\/td>\n<\/tr>\n<\/table>\n<\/div>\n \n
\n
\n
\n
Lo que los atacantes encuentran de forma rutinaria<\/h2>\n
Vector de ataque t\u00edpico en entornos con Identity-Sprawl<\/h3>\n
Preguntas frecuentes<\/h2>\n
\u00bfQu\u00e9 es exactamente el Identity-Sprawl?<\/h3>\n
\u00bfEn qu\u00e9 se diferencia el Identity-Sprawl del Privilege Creep?<\/h3>\n
\u00bfPor qu\u00e9 no basta con un AD centralizado?<\/h3>\n
\u00bfCu\u00e1l es el mecanismo m\u00e1s r\u00e1pido para reducir la superficie de ataque?<\/h3>\n
\u00bfSiguen siendo relevantes hoy el Kerberoasting o el Pass-the-Hash?<\/h3>\n
\n