Cómo acertar con tu proyecto de IGA: empieza por las personas

Por qué los proyectos de IGA fracasan más de lo que deberían

La gobernanza y administración de identidades (IGA) lleva ya el tiempo suficiente implantada como para esperar que la tasa de fracaso fuera baja. Los conceptos están bien establecidos, las principales plataformas son maduras, y no faltan profesionales que ya las hayan implementado antes. Y, sin embargo, los proyectos se siguen alargando, se quedan cortos respecto a su alcance original, o entregan una solución que funciona, pero no del todo bien para esa organización.

Los motivos tienden a agruparse en torno a un conjunto de temas ya conocidos.

El respaldo de la dirección se cita muy a menudo, y sí que importa. Sin un compromiso firme desde arriba, los proyectos son vulnerables a recortes cuando los presupuestos se ajustan o cambian las prioridades.

Los objetivos del programa son otro culpable habitual: o bien se fijaron con una ambición poco realista para lo que la tecnología puede ofrecer, o nunca fueron lo bastante precisos como para ser medibles desde el principio.

Los plazos de entrega se retrasan cuando la planificación se sacrifica a cambio de presentar algo rápido a las partes interesadas. Las decisiones tecnológicas fallan cuando la evaluación se basa en demostraciones de proveedores en lugar de en requisitos documentados. Es fácil dejarse seducir por una plataforma repleta de funciones y descubrir después que las funciones que realmente necesitabas eran justo las que requerían más personalización. Los costes se disparan cuando los requisitos cambian a mitad de la implementación, o cuando se subestima desde el principio el esfuerzo necesario para configurar e integrar la solución.

Todos estos son problemas reales, y todos se han descrito con detalle en muchas otras ocasiones. Pero hay un modo de fracaso que suele quedar en un segundo plano, detrás de varios de los demás, y que recibe mucha menos atención: el proyecto nunca llegó a establecer con claridad para quién se estaba construyendo.

La mayoría de los proyectos de IGA que tienen problemas pueden rastrear al menos parte de la causa hasta suposiciones hechas en una fase temprana sobre los tipos de usuarios, identidades y escenarios de acceso que la solución necesitaría gestionar, suposiciones que resultaron ser incorrectas.

La solución no es complicada, pero sí exige disciplina. Consiste en empezar el proyecto construyendo una imagen completa de tu panorama de identidades, no de la tecnología, ni de las integraciones, ni de los flujos de trabajo. Solo las personas y las identidades que tu programa de gobernanza necesita cubrir. Todo lo demás se deriva de ahí.

El resto de este artículo explica cómo construir esa imagen de tu panorama de identidades y por qué hacerlo marca una diferencia mayor de lo que la mayoría de las organizaciones espera.

Así que estás evaluando la gobernanza de identidades

La tecnología en sí misma rara vez es la razón por la que los proyectos de IGA tienen problemas: la causa raíz casi siempre es empezar por un producto en lugar de entender a las personas.

Tanto si te han pedido que evalúes una plataforma de IGA como si ya estás a mitad de proyecto y las cosas se están complicando, probablemente hayas notado que la tecnología no suele ser la parte difícil.

Las plataformas de IGA (el software que controla quién tiene acceso a qué, automatiza la incorporación y la baja de usuarios, y garantiza que alguien revise esos derechos de acceso periódicamente) son maduras, están bien entendidas y tienen una capacidad amplia. La mayoría de las plataformas principales gestionan los casos de uso básicos sin muchos problemas.

Entonces, ¿por qué tantos proyectos de IGA se disparan en presupuesto, tardan más de lo previsto o acaban con una solución que no encaja del todo?

Por nuestra experiencia, casi siempre se remonta a la misma causa raíz: la organización empezó eligiendo un producto en lugar de entender a sus personas.

Lo más valioso que puedes hacer antes de evaluar a un solo proveedor es entender quién trabaja realmente en tu organización y cómo es su relación con la identidad.

No es tan simple como "entran empleados, salen empleados"

A primera vista, el IGA suena sencillo. Alguien se incorpora a la empresa y recibe cuentas. Alguien se marcha y esas cuentas se deshabilitan. Entre medias, alguien comprueba periódicamente que las personas siguen necesitando lo que tienen.

La realidad en la mayoría de las organizaciones es bastante más complicada. Piensa en algunas de las preguntas que suelen surgir una vez que un proyecto está en marcha:

¿Qué ocurre con los contratistas y el personal de agencia? ¿Aparecen en tu sistema de RR. HH.? Si no es así, ¿de dónde obtiene la plataforma de IGA sus datos?

¿Y los proveedores externos que necesitan acceso a sistemas específicos? ¿Cómo se incorporan y quién gestiona su ciclo de vida?

¿Tienes empleados que trabajan en varias entidades legales o regiones, posiblemente con roles distintos en cada una?

¿Existen cuentas de servicio, cuentas compartidas o identidades de máquina que necesiten gobernarse junto con los usuarios humanos?

¿Qué pasa con los usuarios en roles sensibles (directivos, equipos de finanzas, administradores de TI) que puedan necesitar controles más estrictos o procesos de aprobación distintos?

¿Alguna de tus personas de identidad tiene un acceso por el que un regulador o un auditor preguntará específicamente, y eso cambia cómo hay que revisar o documentar sus permisos?

¿Deberían los permisos durar para siempre, o deberían algunos permisos, especialmente los sensibles, tener una duración limitada?

Ninguno de estos es un caso excepcional. En cualquier organización con más de unos pocos cientos de personas, son la norma. Y si la plataforma de IGA que has elegido no se ha evaluado frente a ellos, lo vas a descubrir por las malas, normalmente durante la implementación, cuando cambiar de rumbo resulta caro.

Aquí entra la persona de identidad

En términos de gobernanza de identidades, una persona (o "persona de identidad") es un tipo diferenciado de usuario cuyo ciclo de vida de identidad, requisitos de acceso o fuentes de datos difieren de forma significativa de los de otros: no personas individuales, sino tipos de personas.

Existe una técnica que lleva décadas formando parte del análisis estructurado de sistemas, tomada originalmente de la ingeniería de software, y que encaja perfectamente para resolver este problema. Recibe distintos nombres (personas de usuario, actores, arquetipos de identidad), pero la idea es sencilla.

Antes de definir qué necesita hacer un sistema, primero defines todos los tipos distintos de personas (y de no personas) a las que ese sistema necesita dar servicio.

Por nuestra experiencia, una organización de tamaño medio suele identificar entre treinta y cincuenta personas de identidad distintas. En organizaciones de sanidad, educación o retail, esa cifra puede fácilmente duplicarse.

Algunos ejemplos para darle vida a esto:

Un empleado permanente que se incorpora a través de tu sistema de RR. HH., con un recorrido de incorporación estándar, aprobación del responsable directo y un conjunto definido de accesos básicos por defecto.

Un contratista contratado a través de una agencia, cuyo registro vive en una hoja de cálculo o en un portal de proveedores en lugar de en RR. HH., y que puede trabajar para varios clientes al mismo tiempo.

Un estudiante o becario con una relación a plazo fijo y un acceso que necesita caducar de forma limpia al final de su período.

Un usuario de TI con privilegios que mantiene cuentas administrativas que necesitan un escrutinio elevado, controles de segregación y, potencialmente, acceso justo a tiempo en lugar de permisos permanentes.

Una identidad no humana, como una cuenta de servicio de una aplicación o una integración de API, que tiene permisos, necesita ser gobernada y desde luego no va a rellenar un formulario de solicitud de acceso de autoservicio.

Cada una de estas personas de identidad interactuará de forma distinta con tu plataforma de IGA. Algunas se incorporarán automáticamente desde un sistema de origen. Otras necesitarán procesos manuales o fuentes de datos alternativas. Algunas necesitarán cadenas de aprobación especializadas; otras necesitarán que su acceso caduque según un calendario.

Por qué esto importa para la selección de la plataforma

Una vez que tienes tu lista de personas de identidad, tus requisitos prácticamente se escriben solos.

Dejas de preguntar "¿esta plataforma soporta altas, cambios y bajas?" (todas dicen que sí) y empiezas a hacer preguntas mucho más concretas:

¿Puede ingerir datos de identidad de múltiples fuentes, como sistemas de RR. HH., hojas de cálculo, LDAP y puntos de conexión SCIM, y conciliarlos en un único registro de identidad?

¿Puede gestionar identidades que no tienen ningún registro en RR. HH., mediante un flujo de incorporación independiente?

¿Puede aplicar políticas de gobernanza distintas a distintos tipos de usuario, de modo que tus contratistas tengan un ciclo de revisión de acceso de 90 días mientras tus usuarios con privilegios lo tengan mensual?

Cuando alguien cambia de rol, ¿puede calcular la diferencia y aprovisionar o retirar lo que corresponda sin intervención humana y sin crear derechos huérfanos?

¿Puede marcar cuando alguien acumula una combinación de derechos de acceso que representa un riesgo, aunque cada derecho individual pareciera inofensivo cuando se concedió? ¿Puede mostrarle a un auditor por qué se aprobó el acceso de cada persona de identidad y quién lo aprobó, con una periodicidad de revisión acorde al riesgo que conlleva esa persona?

Una plataforma de IGA bien diseñada debería poder gestionar todo lo anterior. El ejercicio de las personas de identidad te dice cuáles de esas capacidades son realmente críticas para tu organización y cuáles son simplemente deseables.

También te dice qué pedir que te demuestren cuando evalúes a los proveedores. En lugar de sentarte a ver una presentación genérica del producto, puedes entregarle al proveedor un conjunto de personas de identidad y pedirle que te muestre, de forma específica, cómo gestiona su plataforma cada una de ellas.

El ejercicio de las personas de identidad convierte la evaluación de proveedores de una comparación de funciones en una prueba real de capacidad. Es mucho más difícil ocultar una carencia cuando has pedido un escenario concreto en lugar de una capacidad general.

Cómo se ve una buena implementación en la práctica

Cuando ves una implementación de IGA bien configurada, el pensamiento basado en personas de identidad es visible en la arquitectura. Los distintos tipos de identidad fluyen por rutas de incorporación diferentes. El acceso se asigna según el rol y el contexto, no según listas curadas manualmente. Cuando cambian las circunstancias de alguien (un ascenso, un traslado, una prórroga de contrato), la plataforma responde automáticamente.

Las revisiones de acceso se acotan de forma inteligente: las personas adecuadas revisan los derechos adecuados, con una periodicidad acorde al nivel de riesgo. Cuando un revisor detecta algo que no debería estar ahí, la eliminación es automática y auditable. Cuando se necesita acceso con urgencia, existe un flujo de solicitud y aprobación que deja un rastro claro.

Las combinaciones sensibles de acceso (por ejemplo, la capacidad de generar un pedido de compra y también aprobarlo) se identifican de forma proactiva, no se descubren durante una auditoría. Las excepciones se gestionan con supervisión, en lugar de acumularse silenciosamente.

Nada de esto requiere una plataforma especialmente exótica. Lo que requiere es que alguien, al inicio del proyecto, se tomara el tiempo de entender qué tipos de personas e identidades tiene realmente la organización, y diseñara la solución en torno a ellas.

El beneficio aparece en todos los puntos donde el acceso toca al negocio: los derechos se mueven más rápido porque no necesitan intervención manual, son más precisos porque están vinculados al contexto en lugar de a listas estáticas, y el cumplimiento normativo deja de ser una carrera contrarreloj porque la evidencia se capturó mientras el trabajo ocurría, no se reconstruyó después.

La ventaja práctica

Además de aumentar las probabilidades de éxito de tu proyecto de IGA, el ejercicio de las personas de identidad tiene un par de efectos secundarios útiles.

También beneficia a otros proyectos. La identidad toca prácticamente todo en una organización. Tu lista de personas de identidad será igual de útil al evaluar soluciones de gestión de cuentas con privilegios (PAM), herramientas de gestión de endpoints o cualquier otra cosa que necesite saber quiénes son tus usuarios y qué hacen.

Facilita las conversaciones con las partes interesadas. Cuando puedes referirte a "la persona del contratista" o "la persona del administrador con privilegios" en lugar de describir un requisito técnico abstracto, la conversación se vuelve más concreta. Las partes interesadas del negocio entienden las personas de identidad de una forma en la que no siempre entienden los esquemas de derechos.

Produce una entrada natural para la gobernanza del proyecto. Si utilizas una matriz RACI (Responsable, Aprobador, Consultado e Informado) para gestionar las responsabilidades del proyecto, tu lista de personas de identidad te proporciona la materia prima. Detrás de cada persona de identidad hay un propietario de negocio, un responsable técnico y un conjunto de partes interesadas, todos los cuales necesitan ser consultados, informados o directamente implicados.

Dónde encaja una plataforma como Netwrix Identity Manager

Nada de esto es motivo para retrasar la elección de una plataforma. Es motivo para elegir una construida para trabajar de la manera en que funciona tu lista de personas de identidad, no en contra de ella.

Netwrix Identity Manager gobierna las identidades internas, externas, de invitados, técnicas, de IoT y de agentes de IA bajo el mismo modelo, de modo que un contratista procedente de una hoja de cálculo, una cuenta de servicio de la que nadie en RR. HH. ha oído hablar jamás, un agente de IA que aprovisiona su propio acceso y un empleado permanente que llega a través de tu feed de RR. HH. reciben todos la misma disciplina de ciclo de vida, en lugar de cuatro soluciones improvisadas distintas. Las identidades de terceros y las no humanas tienen su propia ruta de ciclo de vida, incluido el acceso limitado en el tiempo que caduca según lo previsto en lugar de persistir después de que termine un contrato o un período. Incorporar nuevos sistemas tampoco requiere un proyecto de integración a medida: los conectores estándar cubren AD, LDAP, SQL, CSV y SCIM de fábrica, con conectores avanzados y API genéricas disponibles para cualquier cosa más específica de tu entorno.

La gestión de roles funciona de la misma manera. Defines modelos de rol y de política por persona de identidad en lugar de una única política para todos, y la minería de roles utiliza machine learning para analizar los patrones de acceso reales, descubrir estructuras de roles y mantener el modelo actualizado a medida que cambia el uso, de modo que no se limita a reflejar el organigrama del día en que se creó.

La parte de riesgo está construida para esa misma realidad. Un motor de políticas detecta y previene los conflictos de segregación de funciones, y la monitorización continua marca las cuentas huérfanas y las anomalías antes de que salgan a la luz en una auditoría, en lugar de después.

Nada de esto sustituye al ejercicio de las personas de identidad. Es lo que hace posible pasar rápidamente del diseño a la implementación: cada identidad se define y se gobierna según sus propios términos, en lugar de forzarla a pasar por un único conducto y parchearla con excepciones para que encaje. El resultado es menor riesgo, una implementación más rápida y un coste menor.

En resumen

Las plataformas de gobernanza de identidades son maduras y capaces. La tecnología no suele ser lo que hace que los proyectos tengan problemas. Lo que hace que los proyectos tengan problemas es empezar por un producto e intentar encajar después la realidad de la organización en él.

La alternativa (identificar primero tus personas de identidad, usarlas para definir los requisitos y luego evaluar las plataformas frente a esos requisitos) suena obvia cuando se describe. Pero es sorprendentemente poco frecuente en la práctica, y la brecha que llena es importante.

No requiere herramientas especializadas ni conocimientos técnicos profundos. Requiere tiempo, buenas preguntas y la disposición a implicar a las personas adecuadas de toda la organización desde el principio del proceso.

Acierta con las personas de identidad, y el resto del proyecto se vuelve considerablemente más sencillo. Equivócate con ellas, o sáltatelas por completo, y puede que acabes adaptando a posteriori una solución a un problema que no entendiste del todo cuando la compraste.

¿Tienes problemas con tu programa de identidad? Podemos ayudarte a entender tus personas de identidad y cómo Netwrix Identity Manager puede hacer que tu proyecto tenga éxito. Solicita una demo.