La plataforma de IGA de un proveedor de servicios tecnológicos estaba configurada para propagar los eventos del ciclo de vida de las identidades (aprovisionamiento, cambios de rol y bajas de accesos) a todas las aplicaciones conectadas mediante conectores de SCIM y de sincronización de directorios. La lista de aplicaciones conectadas de la IGA incluía diecisiete sistemas. Durante una auditoría de incorporación para un nuevo encargo de un cliente, el equipo de seguridad del proveedor descubrió que un ingeniero que se había ido recientemente seguía teniendo acceso activo al espacio de trabajo compartido del proyecto del cliente en Confluence. La investigación determinó que el cliente había implementado una nueva instancia autoalojada de Confluence seis semanas antes de la salida del ingeniero para apoyar un proyecto específico. El equipo del proyecto había añadido la nueva instancia al entorno sin notificar a los administradores de la IGA y sin incorporarla a la lista de conectores de la IGA. Cuando se dio de baja al ingeniero, la IGA dio de baja correctamente sus accesos en los diecisiete sistemas conectados. El decimoctavo sistema, la nueva instancia de Confluence, no se vio afectado porque la IGA no sabía que existía. El acceso del ingeniero a Confluence persistió no porque fallara el proceso de baja de accesos, sino porque el sistema estaba fuera del alcance del proceso.
¿Qué es realmente el riesgo de propagación de identidades entre sistemas?
La propagación de identidades entre sistemas es el proceso mediante el cual los eventos del ciclo de vida de las identidades (creación de usuarios, cambios de rol y bajas de accesos) se comunican desde una fuente central de identidades (normalmente un IdP o una plataforma de IGA) a todos los sistemas conectados, lo que garantiza que el estado de las identidades sea coherente en todo el panorama de aplicaciones. Cuando un empleado se incorpora, el aprovisionamiento crea cuentas en todos los sistemas pertinentes. Cuando cambia un rol, las modificaciones de acceso se aplican de forma coherente. Cuando un empleado se va, la baja de accesos elimina el acceso de todos los sistemas simultáneamente. Las fallas de propagación se producen cuando algunos sistemas no reciben estos eventos del ciclo de vida, ya sea porque la vía de propagación está incompleta o porque se añadieron sistemas al entorno sin registrarlos para recibir los eventos del ciclo de vida.
La brecha del inventario de conectores es el principal modo de falla de la propagación. Las plataformas de IGA propagan a los sistemas que conocen, es decir, los sistemas que se han incorporado como conectores y se han configurado para recibir eventos del ciclo de vida. Los sistemas que se añaden al entorno sin incorporarse a la IGA son invisibles para el proceso de propagación. En entornos empresariales dinámicos, donde los equipos implementan con regularidad nuevas aplicaciones, servicios en la nube y herramientas de desarrollo, la brecha entre la lista de conectores de la IGA y el inventario real de aplicaciones crece continuamente, salvo que exista un proceso activo que vincule la implementación de nuevos sistemas con su incorporación a la IGA.
El problema de los sistemas en la sombra amplifica la brecha de conectores. Las aplicaciones implementadas por equipos concretos para fines específicos de un proyecto (una nueva herramienta de colaboración para un encargo de un cliente, un entorno de desarrollo para una iteración, un panel de monitoreo para la implementación de un sistema) con frecuencia eluden por completo el proceso de aprovisionamiento de TI. El equipo implementa la aplicación, crea cuentas y la utiliza sin notificar a TI ni al equipo de IGA. Cuando los miembros del equipo se van, la baja de accesos de la IGA no llega a la aplicación porque nunca se registró. Las cuentas persisten indefinidamente y a veces se descubren meses después durante una auditoría no relacionada.
- Nuevos sistemas no registrados en la lista de conectores de la IGA: aplicaciones implementadas sin notificar a los administradores de la IGA
- Aplicaciones en la sombra implementadas por los equipos: sistemas creados fuera del proceso de aprovisionamiento de TI sin integración de eventos del ciclo de vida
- Lista de conectores no actualizada con el inventario actual de aplicaciones: el alcance de la IGA se queda atrás respecto del alcance real del entorno
- Sin proceso de descubrimiento de nuevas aplicaciones: ningún mecanismo para identificar sistemas que no están en la lista de conectores de la IGA
- Exhaustividad de la propagación no verificada: se supone que la baja de accesos de la IGA abarca todos los sistemas
Por qué es importante
La propagación de identidades entre sistemas es importante para TPRM porque los proveedores que acceden a los entornos de los clientes a través de varios sistemas (espacios de trabajo de proyectos, herramientas de colaboración con clientes, entornos de desarrollo compartidos) pueden tener brechas en la baja de accesos de la IGA en los sistemas vinculados al entorno del cliente que se implementaron específicamente para el encargo. Estos son precisamente los sistemas con más probabilidades de quedar fuera de la lista estándar de conectores de la IGA: implementados rápidamente para un fin específico, gestionados por un equipo de proyecto en lugar de TI y no registrados en la IGA antes de que termine el encargo.
La ventana de acceso posterior a la salida es la dimensión con consecuencias más inmediatas. Cuando un empleado del proveedor que gestionaba un encargo para un cliente se va, la baja de accesos de la IGA elimina su acceso corporativo. Pero la herramienta de colaboración implementada para el encargo, el entorno de desarrollo compartido y el espacio de trabajo del proyecto específico del cliente pueden estar todos fuera de la lista de conectores de la IGA, y el acceso a todos ellos persiste hasta que alguien lo identifica y lo elimina específicamente.
Dónde se equivocan la mayoría de los equipos
La falla más constante es considerar que la automatización de IGA ofrece una baja de accesos exhaustiva sin verificar que la lista de conectores de IGA coincida con el inventario actual de aplicaciones. La IGA es exhaustiva para los sistemas de su lista de conectores. Verificar la exhaustividad requiere comparar la lista de conectores con el inventario real de aplicaciones, una conciliación que la mayoría de las organizaciones realiza con poca frecuencia o no realiza en absoluto.
- Considerar exhaustiva la automatización de IGA sin verificar la lista de conectores
- Sin conciliación del inventario de aplicaciones con la lista de conectores de la IGA
- La implementación de nuevas aplicaciones no activa su registro en la IGA
- No se realiza el descubrimiento de aplicaciones en la sombra
- Verificación de accesos posterior a la salida que no abarca los sistemas ajenos a la IGA
Cómo se ve una buena práctica
Los programas maduros de propagación de identidades mantienen una lista de conectores de la IGA actualizada que coincide con el inventario real de aplicaciones, mediante procesos que vinculan la implementación de nuevas aplicaciones con su registro en la IGA, la conciliación periódica de la lista de conectores con el panorama de aplicaciones y el escaneo de descubrimiento de sistemas que no están dentro del alcance de la IGA.
- La implementación de nuevas aplicaciones activa su registro en la IGA: un proceso que exige la incorporación a la IGA antes de completar la implementación de la aplicación
- Conciliación periódica de la lista de conectores: comparación del alcance de la IGA con el inventario actual de aplicaciones
- Descubrimiento de aplicaciones en la sombra: escaneo de aplicaciones que no están en la lista de conectores de la IGA
- Verificación de accesos posterior a la salida: confirmación de que la baja de accesos abarcó todos los sistemas, incluidas las aplicaciones ajenas a la IGA
- Inventario de aplicaciones como artefacto de gobierno: lista actualizada de todas las aplicaciones con su estado de conexión a la IGA
Herramientas
Descubrimiento de SaaS: Grip Security, Nudge Security, BetterCloud
Las plataformas de descubrimiento de SaaS identifican las aplicaciones en uso en una organización, incluidas las aplicaciones en la sombra implementadas por los equipos sin registrarlas ante TI. Estas plataformas detectan el acceso a aplicaciones mediante la telemetría de extensiones del navegador, el análisis del tráfico de red o el análisis de los registros del proveedor de identidad. Para los profesionales de TPRM, preguntar si el proveedor utiliza el descubrimiento de SaaS para identificar aplicaciones que no están dentro del alcance de su IGA constituye una pregunta concreta sobre la detección de aplicaciones en la sombra.
IGA con descubrimiento de aplicaciones: SailPoint, Saviynt
Las plataformas modernas de IGA ofrecen capacidades de descubrimiento de aplicaciones, que identifican aplicaciones en las que los usuarios tienen cuentas que no se gestionan mediante la IGA. Para los profesionales de TPRM, preguntar si la IGA del proveedor incluye un descubrimiento de aplicaciones que identifique sistemas no registrados con cuentas de usuario constituye una pregunta concreta sobre la detección de brechas de propagación.
Desafíos de gobernanza
El desafío de gobierno de la exhaustividad de la propagación de identidades es el problema del cambio continuo del entorno. Los inventarios de aplicaciones cambian constantemente: se implementan nuevas herramientas, se retiran las antiguas y cambia el alcance de las implementaciones existentes. La lista de conectores de la IGA que era exacta en la última conciliación pierde exactitud progresivamente a medida que evoluciona el entorno. Mantener la exhaustividad requiere un descubrimiento automatizado que identifique continuamente los nuevos sistemas o un proceso que vincule cada nueva implementación de aplicaciones con su registro en la IGA antes de que la aplicación entre en uso.
- Exigir el registro en la IGA antes de implementar nuevas aplicaciones: un control de gobierno en el proceso de implementación
- Implementar el descubrimiento de SaaS para detectar aplicaciones en la sombra
- Conciliación periódica de la lista de conectores con el inventario actual de aplicaciones
- Verificación de accesos posterior a la salida que incluya los sistemas ajenos a la IGA
- Incluir la exhaustividad de la propagación en la evaluación del gobierno de accesos
Si usted forma parte de un equipo pequeño
Tras la próxima salida de personal de un proveedor, realice una verificación que la mayoría de las organizaciones nunca hace: pida al proveedor que confirme que la baja de accesos abarcó todos los sistemas a los que tenía acceso la persona que se fue, no solo los sistemas gestionados por la IGA, sino también cualquier herramienta específica de proyecto, plataforma de colaboración con clientes y aplicación implementada por los equipos. La respuesta sacará a la luz tanto los sistemas fuera del alcance de la IGA como si el proveedor cuenta con un proceso para identificarlos.
- Pedir a los proveedores que confirmen, en cada salida, que la baja de accesos abarcó todos los sistemas, incluidas las aplicaciones ajenas a la IGA
- Preguntar si el proveedor tiene un proceso para identificar aplicaciones que no están dentro del alcance de su IGA
- Preguntar con qué frecuencia se concilia la lista de conectores de la IGA con el inventario real de aplicaciones
- Preguntar si la implementación de nuevas aplicaciones activa su registro en la IGA
Qué exigir
Pregunte directamente:
"Cuando dan de baja a un miembro del personal que tenía acceso a nuestro entorno, ¿esa baja abarca todos los sistemas a los que tenía acceso, incluidas las herramientas específicas de proyectos, las plataformas de colaboración con clientes y las aplicaciones implementadas por los equipos que no se gestionan mediante su IGA central?"
"¿Con qué frecuencia concilian la lista de conectores de su IGA con su inventario real de aplicaciones para identificar sistemas en los que los usuarios tienen cuentas que no se gestionan mediante el proceso de ciclo de vida de la IGA?"
Evidencia que debe esperar
- Lista de conectores de la IGA con la fecha de la última conciliación
- Capacidad o proceso de descubrimiento de aplicaciones en la sombra
- Proceso de verificación de accesos posterior a la salida que abarca los sistemas ajenos a la IGA
- Proceso de registro en la IGA al implementar nuevas aplicaciones
A un proveedor que confirma la baja automatizada de accesos mediante IGA se le debe preguntar específicamente si esa automatización abarca las aplicaciones implementadas para fines específicos de proyectos que pueden no estar en la lista de conectores de la IGA. La automatización abarca lo que la IGA conoce. La pregunta es qué es lo que la IGA no conoce.
Cómo demostrarlo
- Registros de conciliación de la lista de conectores de la IGA
- Registros del descubrimiento de aplicaciones en la sombra
- Verificación de accesos posterior a la salida que incluya los sistemas ajenos a la IGA
- Proceso de registro en la IGA al implementar nuevas aplicaciones
Conclusión clave
La IGA dio de baja al usuario en diecisiete sistemas. El decimoctavo sistema, la instancia de Confluence que el equipo del proyecto había implementado seis semanas antes, nunca estuvo en la lista de conectores. La automatización funcionó. El alcance estaba incompleto. La exhaustividad de la propagación de identidades exige que la IGA conozca todos los sistemas en los que los usuarios tienen cuentas: no solo los sistemas registrados cuando se implementó la IGA, sino cada sistema añadido al entorno desde entonces. La lista de conectores es el alcance del gobierno. El inventario de aplicaciones es el alcance real. La brecha entre ambos es donde las personas que se fueron conservan el acceso. Concilie las listas. Registre las nuevas implementaciones. Verifique la exhaustividad tras cada salida. La automatización solo es tan completa como lo que conoce.