¿Qué es Identity Fabric? Arquitectura de identidad componible para entornos híbridos

Pocas organizaciones grandes tienen una plataforma de identidad. Tienen un directorio heredado, una suite de IGA implementada para cerrar hallazgos de auditoría, un proveedor de SSO que llegó con la nube, una bóveda de privilegios y decenas de aplicaciones SaaS con sus propios usuarios. Cada pieza funciona por separado, pero no en conjunto: la baja de un empleado tarda días en propagarse de un sistema a los demás, y una sesión comprometida se detecta en una herramienta sin que nadie la revoque en las otras.

Identity Fabric es el nombre que la industria le dio a la respuesta arquitectónica a ese problema.

Qué es y qué no es

Un Identity Fabric es un enfoque de arquitectura, no un producto. Consiste en tratar las capacidades de identidad como servicios interoperables conectados por APIs y estándares abiertos, que operan de forma consistente entre centros de datos propios, nubes públicas y SaaS. Esas capacidades son el gobierno y la administración (IGA), la gestión de accesos (SSO, MFA, federación), los accesos privilegiados (PAM), el directorio, la detección y respuesta a amenazas de identidad (ITDR) y la analítica. La identidad deja de ser una serie de silos y se vuelve una capa transversal, con acuerdos explícitos sobre identidad, contexto y políticas.

Gartner popularizó el término y en 2023 incluyó identity fabric immunity entre sus tendencias de ciberseguridad del año: la infraestructura de identidad es frágil cuando sus elementos están incompletos, mal configurados o son vulnerables, y hay que protegerla con ITDR y, a la vez, completarla y configurarla bien. KuppingerCole publica un Leadership Compass sobre Identity Fabrics con principios afines: modularidad, apertura mediante APIs y flexibilidad de despliegue.

Tampoco es una suite con otro nombre, ni acumular "lo mejor de cada categoría" por tener muchas herramientas. El fabric describe cómo se conectan y se gobiernan las piezas, sin importar cuántas sean.

Por qué importa ahora

Los ataques que comprometen identidades y sesiones son un riesgo central para cualquier organización. Si el ITDR detecta una anomalía pero no puede ordenarle al SSO que revoque la sesión ni al PAM que rote la credencial, la detección sirve de poco. Un fabric está pensado precisamente para esa respuesta entre componentes.

Los estándares maduraron. SAML 2.0 y OpenID Connect permiten desde hace años federar la identidad y autenticar usuarios; OAuth 2.0 es un marco de autorización delegada, y SCIM (RFC 7643 y RFC 7644) estandariza el intercambio y el aprovisionamiento de datos de identidad.

Lo nuevo es el intercambio de señales de riesgo en tiempo real. En septiembre de 2025 la OpenID Foundation aprobó como especificaciones finales el Shared Signals Framework y sus perfiles CAEP (eventos de sesión y dispositivo) y RISC (compromiso de cuentas). Su grupo de trabajo IPSIE, formado en 2024, perfila esos estándares con valores por defecto seguros para que las implementaciones realmente interoperen.

Adoptarlos no elimina por sí solo los adaptadores. La compatibilidad real depende de los perfiles que implemente cada producto, de sus capacidades, del modelo de datos y de los acuerdos operativos entre componentes.

¿Comprar una plataforma o tejer un fabric?

¿No sería más simple una sola suite? En un entorno mediano y homogéneo, puede serlo. Con decenas de miles de identidades, regulación sectorial, sistemas heredados que no se van a retirar y fusiones en el horizonte, la pregunta cambia.

La diferencia está en dónde vive la integración, más que en el número de herramientas. Una suite puede simplificar la integración entre sus propios módulos y, al mismo tiempo, ofrecer APIs y estándares abiertos hacia terceros. Un fabric no prohíbe las suites; lo que hace es diseñar explícitamente los contratos entre capacidades:

APIs documentadas.
Eventos estandarizados.
Un modelo de datos compartido.
Acuerdos sobre cómo se deciden y aplican las políticas, con trazabilidad entre los distintos puntos de decisión.

Una suite puede ser un nodo excelente dentro de un fabric, siempre que exponga sus capacidades por estándares y no solo las consuma. Así se puede reemplazar un componente sin rehacer el resto, o incorporar una capacidad nueva, como ITDR, sin esperar al proveedor principal.

Las piezas que necesita

No tienen que venir de proveedores distintos, pero sí deben estar definidas como servicios con fronteras claras.

Datos de identidad y directorio. Fuente autoritativa de cada atributo, correlación de las cuentas de una misma persona o carga de trabajo en todos los sistemas, y un identificador estable. Sin esto, lo demás gobierna cuentas, no identidades.
Gobierno y administración (IGA). Ciclo de vida, solicitudes, certificaciones, segregación de funciones. Plataformas como OpenText Identity Governance operan aquí; su valor crece cuando sus decisiones se publican como eventos que otros consumen.
Gestión de accesos. Autenticación, MFA, SSO y federación. Un identity broker basado en estándares, como Red Hat SSO, permite que aplicaciones heredadas y SaaS modernos se autentiquen contra las mismas políticas.
Accesos privilegiados (PAM). Bóveda, rotación, sesiones supervisadas, acceso justo a tiempo. CyberArk es el referente; lo relevante es que reciba señales del IGA y del ITDR.
ITDR y analítica. Detección de anomalías y, sobre todo, capacidad de responder a través de los demás: revocar sesiones, forzar una nueva autenticación, suspender cuentas.
Orquestación e integración. Conectores SCIM, bus de eventos, flujos que cruzan sistemas. Es lo que convierte servicios aislados en un tejido, y suele ser la capa más descuidada.

Errores frecuentes

No resolver la correlación. Si el IGA cree que un usuario tiene tres cuentas y el ITDR ve cinco, ninguna política será consistente. Es trabajo de datos, poco vistoso, y es el cimiento.

Orquestar sin gobernar. Mover cuentas entre sistemas no sustituye la certificación, la segregación de funciones ni la evidencia para auditoría.

Conectores a la medida donde ya hay estándar. Cada integración propietaria es una dependencia que alguien tendrá que mantener. Si el sistema soporta SCIM u OpenID Connect, úselos.

Olvidar las identidades no humanas. Cuentas de servicio, workloads y secretos de pipelines ya superan en número a las personas en muchos entornos, y suelen quedar fuera del gobierno.

Un camino pragmático si ya tiene IAM

Nadie construye un fabric desde cero, ni hace falta. El sistema con quince años en producción seguirá ahí; el fabric lo envuelve y lo gobierna. Recomendamos este orden:

Inventario por capacidad, no por producto. Qué servicio cubre hoy cada capacidad y en qué entornos. Lo normal es encontrar duplicidades en unas capas y vacíos en otras, casi siempre en correlación, ITDR y orquestación.
Modelo de datos y fuentes autoritativas. Qué sistema manda sobre cada atributo, cómo se correlacionan las cuentas y cuál es el identificador estable. Todo lo demás se apoya en este modelo, así que conviene versionarlo y someterlo a controles de calidad, porque las fuentes, las aplicaciones y los atributos cambian con el tiempo.
Exponga lo heredado por estándares. Una fachada SCIM frente al directorio; un broker OpenID Connect o SAML frente a las aplicaciones que no saben federarse. El sistema antiguo no cambia; su contrato hacia el fabric sí.
Incorpore la capacidad faltante como servicio conectado. Si falta ITDR, intégrelo desde el inicio con el SSO y el PAM mediante eventos, no como un tablero aislado. CAEP y el Shared Signals Framework facilitan ese intercambio, siempre que los productos implementen perfiles compatibles y acciones de respuesta concretas.
Armonice las políticas y su trazabilidad antes de consolidar herramientas. Defina reglas, atributos, excepciones y responsabilidades comunes, y después compruebe cómo las aplica cada componente, porque no todos comparten el mismo motor ni la misma semántica de autorización. Eso es más valioso, y más alcanzable, que reunirlos en una sola consola.
Mida y retire por capacidad. Cuando un servicio mejor conectado ya cubre una capacidad, retire la duplicada. Un fabric se consolida así, no con una migración masiva.

Si leyó nuestra nota sobre Identity Factory, la relación es sencilla: la Factory es el modelo operativo, es decir, cómo se industrializan los procesos de identidad, y el Fabric es la arquitectura sobre la que corren. Se necesitan mutuamente.

Cómo ayuda una consultoría especializada

Lo difícil de un Identity Fabric no es principalmente técnico. Hay que decidir qué capacidad vive dónde, qué se envuelve y qué se retira, y en qué orden, con la realidad de los contratos de licenciamiento, las auditorías y los equipos que ya existen. Una evaluación independiente que compare las capacidades actuales con la arquitectura objetivo y entregue una ruta priorizada evita comprar lo que no hace falta, y descubre lo que sí falta antes de que lo encuentre un atacante o un auditor. En Clear Intelligence hacemos ese diagnóstico de capacidades y esa hoja de ruta, con plataformas como OpenText, CyberArk y Red Hat SSO.

Fuentes y estándares

Servicios relacionados

Health Check IAM: inventario de capacidades por capa y brechas respecto a una arquitectura de identidad componible.
Integraciones: conecte directorio, IGA, PAM y aplicaciones mediante SCIM, OpenID Connect y señales compartidas.
Hybrid Cloud: políticas de identidad consistentes entre su centro de datos, nubes públicas y SaaS.