¿Qué es IGA y por qué importa?

Una pregunta que nadie sabe responder rápido

Pregúntale al equipo de TI de una empresa en crecimiento quién tiene acceso al sistema de nómina, y la respuesta suele empezar con “déjame revisar”. Alguien exporta la lista de usuarios. Otra persona señala que la exportación no incluye a quienes entran a nómina a través del portal de RR. HH. Una tercera recuerda que a dos contratistas se les dio acceso temporal durante la migración del año pasado y no está segura de que se les haya quitado. Al final de la tarde hay una hoja de cálculo, y nadie confía del todo en ella.

Esa tarde es el problema que IGA viene a resolver. En los cinco dominios de IAM describimos IGA en pocas líneas como el área que lleva la lista de quién puede entrar y comprueba que la lista siga siendo correcta. Alcanzaba para ubicarlo en el mapa junto a la gestión de accesos, los accesos privilegiados, la identidad de clientes y la detección de amenazas. No alcanza para llevar un programa, dimensionar un presupuesto o explicarle a una dirección financiera por qué una plataforma de IGA merece dinero.

Este artículo va más allá, alrededor de dos preguntas que sostienen el resto del módulo. ¿Cuál es exactamente la diferencia entre administrar identidades y gobernarlas, dos cosas que la gente suele mezclar? ¿Y qué hace que una organización decida, un día concreto, que este es el año en que financia IGA?

Administrar y gobernar son trabajos distintos

“Identity Governance and Administration” se suele decir de corrido, como una sola expresión. Las dos mitades responden preguntas distintas, pertenecen a personas distintas en un programa maduro, y confundirlas es una de las razones más comunes por las que los proyectos de IGA se estancan.

La administración de identidades es la parte operativa. Ejecuta los cambios de acceso: crear una cuenta, añadir a alguien a un grupo, correr un conector contra Active Directory, cumplir una solicitud aprobada, deshabilitar a alguien que se fue. Si puedes señalar una línea de log que dice que algo cambió a las 14:03, estás viendo administración.

El gobierno de identidades es la parte de supervisión. Decide si un cambio debe hacerse y comprueba después que lo que se hizo era correcto. Abarca las políticas, las revisiones de acceso, las reglas de separación de funciones, el diseño de roles y la evidencia que piden los auditores. Si puedes señalar una decisión, como “este acceso sigue estando justificado” o “estos dos permisos no deben tenerse nunca a la vez”, estás viendo gobierno.

Las dos forman un ciclo, no una pila. La administración ejecuta lo que el gobierno aprueba, y el gobierno revisa lo que la administración ejecutó. Cada una por separado falla de una forma reconocible. Una empresa con administración y sin gobierno aprovisiona rápido y nunca comprueba si algo de eso sigue teniendo sentido; la cuenta del contratista sigue activa dieciocho meses después de terminado el contrato porque mirarla no es trabajo de nadie. Una empresa con gobierno y sin administración tiene una política bien escrita que no puede aplicar, porque quitar el acceso que la política señala sigue significando escribirle a un owner de aplicación y esperar tres semanas.

flowchart LR
  accTitle: La administración y el gobierno de identidades forman un ciclo
  accDescr: Una necesidad de acceso lleva a la administración de identidades a aprovisionarlo. La persona usa el acceso, y el gobierno de identidades lo revisa, lo audita y lo contrasta con las reglas de separación de funciones. Si el gobierno confirma que el acceso sigue haciendo falta, la persona lo sigue usando. Si ya no está justificado, la administración lo retira.
  REQ([Necesidad de acceso]) --> IA[Administración<br/>aprovisiona, asigna, conecta]
  IA --> USE[La persona usa el acceso]
  USE --> IG[Gobierno<br/>revisa, audita, verifica SoD]
  IG -->|Sigue haciendo falta| USE
  IG -->|Ya no se justifica| REVOKE[Administración<br/>retira el acceso]
  REVOKE --> DONE([Acceso retirado])

La división suele coincidir con equipos reales. Ingeniería de IAM y operaciones de TI suelen encargarse de la administración: configuran conectores, construyen flujos y mantienen el aprovisionamiento funcionando. Cumplimiento, riesgo y los owners de negocio y de aplicación suelen encargarse del gobierno: deciden qué es un acceso correcto en sus sistemas y firman las revisiones. Esa frontera entre equipos es también el lugar donde los programas más se atascan, con un lado esperando la respuesta del otro.

Cuando un proveedor de IGA dice “nosotros hacemos IGA”, conviene preguntarle en qué mitad del ciclo es más fuerte. Algunos productos nacieron como motores de aprovisionamiento y sumaron funciones de gobierno después; otros nacieron como herramientas de revisión y analítica y sumaron conectores después. Ninguna de las dos historias es mala, pero dice dónde está maduro el producto y dónde tu programa tendrá que compensar con proceso.

Lo que IGA no es

Tres malentendidos le hacen más daño a un programa de IGA que cualquier error técnico, porque definen qué decide construir un equipo desde el principio.

El primero es creer que IGA es solo certificación de accesos. Las revisiones son la parte más visible del gobierno, la campaña que llega cada trimestre a la bandeja de cada jefe, así que es fácil confundirlas con el todo. Un programa que solo hace revisiones, sin arreglar el aprovisionamiento lento, los conectores que faltan o unos roles demasiado vagos para juzgarlos, produce campañas que los jefes aprueban sin leer, porque no tienen forma real de saber qué están aprobando. Las revisiones son un resultado del gobierno, no la disciplina entera.

El segundo es pensar que IGA es solo para grandes empresas. El tamaño ayuda a predecir la necesidad, pero lo que de verdad la dispara es la complejidad. Una fintech de 200 personas con quince integraciones reguladas y una rotación constante de contratistas puede quedarse chica para una gestión de accesos en hojas de cálculo mucho antes que una fábrica de 2.000 personas con una plantilla estable. La pregunta útil no es cuántos empleados hay. Es si alguien puede responder “quién tiene acceso a qué y por qué” sin días de búsqueda.

El tercero es creer que comprar una plataforma es el gobierno. Una herramienta no decide si un rol tiene sentido, si una combinación de accesos riesgosa es tolerable para este negocio o si un revisor mira de verdad lo que aprueba. Esas siguen siendo decisiones humanas aunque la plataforma esté desplegada por completo. Lo que hace la herramienta es volverlas visibles, repetibles y registradas.

A quién cubre IGA

IGA nació alrededor de los empleados, y los empleados siguen siendo la mayor parte de su trabajo. Pero las identidades que tiene que gobernar en una organización moderna van mucho más allá de la nómina.

Los contratistas y proveedores son el segundo grupo evidente. Muchas veces hacen el mismo trabajo que los empleados, con el mismo acceso, pero llegan por compras y no por RR. HH., sus contratos terminan en fechas de las que nadie en TI se entera y aparecen una y otra vez en los hallazgos de “cuenta todavía activa meses después” que tanto gustan a los auditores. Los socios que entran por federación desde su propia organización son un tercer grupo, que se gobierna distinto porque es otro quien tiene autoridad sobre quiénes son. Y luego están las identidades que no son personas: cuentas de servicio, usuarios de integración, clientes de API, automatizaciones. No tienen jefe ni registro en RR. HH., tienden a acumular accesos amplios porque alguien necesitaba que una integración funcionara rápido y cada vez son el primer objetivo de los atacantes. Los agentes de IA que actúan en nombre de alguien son los últimos en llegar a este grupo, y gobernarlos plantea las mismas preguntas con más filo: quién es el owner de este agente, a qué puede llegar y quién decidió que eso era apropiado.

Los clientes, en cambio, suelen quedar fuera del alcance de IGA. Sus identidades las gestiona la IAM de clientes, con prioridades muy distintas: autorregistro, consentimiento, escala de millones. Las preguntas de gobierno que hace IGA, como quién aprobó este acceso o si sigue haciendo falta, no tienen mucho sentido para alguien que se registra en una app.

Señales de que la hoja de cálculo ya no alcanza

Las organizaciones pequeñas gestionan el acceso perfectamente con una hoja de cálculo y una persona de TI cuidadosa. El momento en que eso deja de funcionar casi nunca se anuncia; aparece como un conjunto de síntomas pequeños.

Las solicitudes de acceso llegan como correos en texto libre y se resuelven copiando el acceso de un compañero. Nadie puede decir, sin un día de búsqueda, qué cuentas pertenecen a personas que ya se fueron. La misma persona tiene tres nombres de usuario distintos en tres sistemas y nadie está seguro de que sea la misma. Las revisiones de acceso, si existen, son hojas de cálculo enviadas por correo a jefes que responden “se ve bien”. Los auditores piden evidencia y reciben capturas de pantalla. Y cuando alguien cambia de puesto se queda con todo lo del puesto anterior, porque quitarlo no es tarea de nadie.

Cualquiera de estos síntomas se puede manejar. Tres o cuatro juntos suelen significar que la organización cruzó el umbral de complejidad, y que el costo del enfoque manual, en tiempo, hallazgos de auditoría y riesgo, ya es mayor que el de un programa.

Dónde termina IGA y empiezan otros dominios

Una prueba sencilla aclara casi toda la confusión con los dominios vecinos. Si el ticket dice “no puedo iniciar sesión”, corresponde a la gestión de accesos, el dominio anterior a este. Si dice “¿por qué esta cuenta sigue teniendo derechos de administrador en una base de datos de producción?”, empieza en IGA, con la pregunta de si ese acceso debería existir y quién lo revisó por última vez, y suele terminar en la gestión de accesos privilegiados, porque una cuenta de administración que necesita una bóveda, grabación de sesiones y elevación con tiempo limitado ya excede lo que IGA gobierna bien por sí solo. IGA decide si una identidad debe tener un entitlement. PAM añade controles sobre cómo se usa un entitlement privilegiado una vez otorgado. Más adelante en este dominio hay un artículo sobre ese traspaso.

El mismo martes, dos veces

La diferencia que marca IGA se ve mejor en una sola empresa que en definiciones. Daniel dirige operaciones de TI en una empresa de logística de 900 personas que creció rápido con tres adquisiciones regionales y todavía gestiona las solicitudes de acceso desde un buzón compartido.

Un lunes, Sara entra en el equipo de operaciones con clientes. Su jefa le escribe al equipo de Daniel pidiendo “el acceso de siempre”, una frase que significa algo distinto para cada persona que la lee. El equipo de Daniel copia lo que recibió la última persona contratada en ese puesto hace seis meses, antes de que dos de los sistemas implicados cambiaran su modelo de permisos. Sara recibe parte de su acceso el miércoles, el jueves descubre que nadie pidió el módulo de visibilidad de almacén que necesita y empieza a trabajar a pleno el lunes siguiente, con una semana de retraso.

Mientras tanto, un contratista de una de las oficinas adquiridas, cuyo contrato terminó en marzo, sigue con la cuenta activa en julio. Nadie se da cuenta, porque no existe ningún proceso cuyo trabajo sea darse cuenta. La cuenta aparece cuatro meses después en una auditoría externa como hallazgo: acceso sin justificación de negocio documentada. La auditoría se alarga seis semanas, porque reconstruir quién tuvo acceso a qué y quién lo aprobó significa juntar hilos de correo y hojas de cálculo que nunca fueron pensadas más que como listas de pendientes.

Ahora imagina la misma empresa dieciocho meses después de empezar un programa de IGA. La jefa de Sara pide su acceso desde un catálogo que ya sabe lo que necesita una analista de operaciones con clientes, porque los owners de las aplicaciones definieron ese paquete una vez y se reutiliza siempre. La solicitud se enruta sola para su aprobación, el acceso se aprovisiona el mismo día y Sara está trabajando el martes por la mañana.

La cuenta del contratista no se queda olvidada, porque la fecha de fin del contrato se le asoció al crearla, así que el acceso termina con el contrato. Cuando llegan los auditores, cada otorgamiento, aprobación y revisión ya existe como reporte. La auditoría dura las dos semanas que estaban previstas.

Las personas, las aplicaciones y las regulaciones son idénticas en las dos versiones. Lo que cambió es el proceso, y ese proceso es lo que IGA nombra y lleva a la práctica.

Qué consigue que se financie un programa

Nadie financia “una mejor higiene de identidades” en abstracto. Los programas de IGA consiguen dinero cuando un hecho concreto vuelve tangible, de golpe, el costo de no tener uno. Hay cuatro tipos de hecho que se repiten una y otra vez.

El cumplimiento normativo es el más común. Se acerca una auditoría de SOX, HIPAA, PCI DSS o el RGPD, o la anterior salió mal. Los auditores hacen alguna versión de la misma pregunta sea cual sea el marco: muéstrame quién tiene acceso a este sistema, quién lo aprobó y cuándo se revisó por última vez. Una organización que solo puede responder con una consulta en vivo contra producción y una semana de conciliación manual acaba de demostrar que el control en realidad no existe, diga lo que diga su política.

El riesgo es el segundo. Una brecha en una empresa del sector, un hallazgo en una prueba de penetración o un incidente interno en el que “¿quién tiene administración en esa base de datos?” resultó ser una pregunta que nadie en la sala sabía responder. Los programas que nacen del riesgo suelen empezar acotados, limpiando el acceso de administración permanente y las combinaciones peligrosas más evidentes antes de intentar revisiones en toda la empresa.

La eficiencia es el tercero, y suele venir de operaciones de TI o de RR. HH., no de seguridad. TI está tapada de tickets de acceso, la incorporación de personal se arrastra y la primera semana de cada persona nueva se pierde en parte esperando. El argumento aquí es de velocidad y de tiempo del personal, no de riesgo.

Las fusiones y adquisiciones son el cuarto. Dos directorios, dos convenciones de nombres, dos ideas de qué es un “jefe”, y una fecha límite para mostrarle al directorio o a un regulador una sola imagen de quién puede acceder a qué. Este tipo de trabajo de IGA es comprimido y no perdona; casi nunca hay tiempo para diseñar roles con cuidado, solo para conciliar lo que existe lo bastante bien como para gobernarlo.

Dos casos breves hacen concretos los motivos de riesgo y de fusión. Una empresa de pagos hace una prueba de penetración de rutina, y el hallazgo que llega al CISO no es una explotación ingeniosa. Es que once cuentas de servicio en tres sistemas tienen el equivalente a derechos de administrador de dominio, y nadie sabe explicar por qué más de cuatro los siguen necesitando. Ese hallazgo, y no una brecha, consigue financiar dentro del trimestre una limpieza de cuentas privilegiadas y de accesos en conflicto. En el otro caso, una aseguradora mediana compra a un competidor regional y descubre al planificar la integración que las dos empresas usan el título “suscriptor” para puestos con límites de aprobación muy distintos. Nadie pensaba resolver el diseño de roles durante una integración de 90 días, pero el directorio quiere un único reporte de accesos antes del cierre de la operación, así que el trabajo se hace igual: apurado, imperfecto, y rehecho como corresponde al año siguiente.

flowchart LR
  accTitle: Motivos de negocio, los fallos que hay detrás y la capacidad de IGA que resuelve cada uno
  accDescr: Cuatro motivos de negocio llevan cada uno a un fallo concreto que resuelve una capacidad de IGA específica. Una fecha límite de cumplimiento lleva a una evidencia de auditoría que tarda semanas en reconstruirse, y se resuelve con revisiones de acceso y pista de auditoría. Un incidente de riesgo lleva a que nadie sepa quién tiene derechos de administrador, y se resuelve con verificaciones de separación de funciones y limpieza de cuentas huérfanas. Una acumulación de solicitudes lleva a personas nuevas que esperan días su acceso, y se resuelve con un catálogo de autoservicio y un ciclo de vida automatizado. Una fusión lleva a cuentas duplicadas en dos directorios, y se resuelve con un ciclo de vida único entre fuentes.
  C[Fecha límite de cumplimiento] --> CB[La evidencia tarda semanas en reconstruirse]
  R[Incidente o pentest] --> RB[Nadie sabe quién es administrador]
  E[Solicitudes acumuladas] --> EB[Personas nuevas esperan días su acceso]
  M[Fusión] --> MB[Cuentas duplicadas en dos directorios]
  CB --> CF[Revisiones de acceso + pista de auditoría]
  RB --> RF[Verificación de SoD + limpieza de huérfanas]
  EB --> EF[Catálogo de autoservicio + ciclo de vida automatizado]
  MB --> MF[Un solo ciclo de vida entre fuentes]

Los programas reales casi nunca tienen un solo motivo. La mayoría de los casos de negocio combinan dos, normalmente el cumplimiento con alguno de los otros. El cumplimiento es lo que abre la conversación del presupuesto; el dolor operativo es lo que mantiene el programa financiado después del primer año.

Quién patrocina el programa suele seguir al motivo. Los programas impulsados por cumplimiento suelen tener como patrocinador al CISO o a la dirección de riesgo y empiezan por las revisiones de acceso y los reportes de auditoría. Los impulsados por riesgo también los patrocina seguridad, pero empiezan por las verificaciones de separación de funciones y la limpieza de cuentas huérfanas. Los de eficiencia los patrocinan operaciones de TI o RR. HH. y empiezan por las solicitudes de autoservicio y un proceso joiner-mover-leaver automatizado. Los de fusión los patrocina la dirección de TI o la oficina de integración y empiezan por unificar las identidades de las fuentes de ambas organizaciones. Saber en cuál de estos casos estás ayuda a entender por qué la primera fase de un programa se ve como se ve.

Gobierno antes de que haya plataforma

Muchas organizaciones necesitan gobierno antes de poder justificar la compra de nada, y no tener plataforma no es motivo para saltárselo. Casi todo lo importante se puede empezar a mano.

Nombra un owner para cada aplicación importante, alguien del negocio que pueda decir quién debería tener acceso y por qué. Acuerda que a quienes se van se les retire el acceso del directorio y de los sistemas más sensibles su último día, y lleva una lista de verificación sencilla que lo demuestre. Una vez por trimestre, exporta los usuarios de los dos o tres sistemas más sensibles, envía cada lista a su owner pidiéndole que marque lo que debe salir y guarda la respuesta junto con la prueba de que los retiros se hicieron. Pide que el acceso se solicite con un formulario de unos pocos campos obligatorios en lugar de un correo en texto libre.

Nada de esto escala bien, y no pasa nada. Construye los hábitos y la titularidad que una plataforma automatizará después, y produce los registros que le muestran a un auditor que los controles existen. Cuando el programa finalmente se financia, empieza con owners que ya conocen su papel y con datos sobre dónde están los problemas.

Medir la mitad del gobierno

Las cifras de retorno que siguen describen sobre todo la administración: tickets, horas, días. El gobierno necesita sus propias medidas, porque un programa puede aprovisionar rápido y seguir gobernando mal.

Algunas útiles son la proporción del acceso sensible revisado dentro de su ciclo previsto, el número de conflictos de separación de funciones abiertos y su antigüedad, la proporción de entitlements y aplicaciones con un owner nombrado y la proporción del acceso que puede rastrearse hasta una aprobación, una regla o una revisión. Rara vez aparecen en el primer caso de negocio, pero son las que debería mirar un comité de dirección cuando el programa ya está en marcha, porque muestran si el ciclo realmente se cierra. Un programa cuya cola de tickets bajó mientras la proporción de acceso sensible revisado no se movió ha automatizado la administración y ha dejado el gobierno donde estaba.

Cómo se ve el retorno cuando el programa funciona

IGA es poco común entre las inversiones de seguridad porque buena parte de su retorno aparece en cifras operativas y no solo en pérdidas evitadas. Hay tres cifras que aparecen en los reportes de casi todos los programas maduros.

La primera es cuántas solicitudes y cambios de acceso siguen necesitando que una persona los interprete, los enrute y los ejecute a mano. Con un catálogo de autoservicio y ejecución automática, las solicitudes rutinarias dejan de necesitar a nadie, y la cola que queda son los casos de verdad excepcionales.

La segunda es cuántas horas se dedican a preparar una auditoría. La diferencia entre correr un reporte y reconstruir la historia a partir del correo se multiplica por cada marco con el que se audita a la organización cada año.

La tercera es cuánto se tarda en quitarle a alguien todo su acceso después de que se va o termina su contrato. Es la que más les importa a reguladores y aseguradoras, porque mide cuánto tiempo sigue abierto el acceso de un exempleado como puerta de entrada.

Un ejemplo de dimensionamiento

Volvamos a la empresa de Daniel. Tiene unas 40 aplicaciones conectadas y una rotación anual del 15%, algo normal para ese tamaño. Antes del programa, TI atendía unos 60 tickets de acceso por semana, casi todos a mano. Cada ciclo de auditoría de SOX le llevaba a una analista de cumplimiento unas tres semanas reconstruyendo quién tuvo acceso y cuándo. Y entre que alguien se iba y su acceso desaparecía de todos los sistemas pasaban, de media, casi nueve días.

A los dieciocho meses, alrededor del 70% de las solicitudes rutinarias son de autoservicio, y la cola manual bajó a unas 20 por semana, sobre todo los casos excepcionales que debería atender una cola humana. La preparación de la auditoría lleva unos cuatro días, porque el historial de revisiones ya existe. El retiro del acceso es en el día para todo lo que dispara la baja en RR. HH., y solo unos pocos sistemas que todavía no tienen conector tardan más. El equipo de TI no creció. El trabajo rutinario dejó de pasar por personas, y su criterio se reservó para las excepciones.

Ninguna de estas cifras es una constante. Dependen de cuántas aplicaciones estén conectadas, de lo bien diseñados que estén los roles y de lo disciplinado que sea el ciclo de revisiones, así que tómalas como la forma del retorno y no como números para copiar en un caso de negocio. Organizaciones como la Identity Defined Security Alliance publican estudios sobre la madurez de los programas de identidad si necesitas cifras citables.

La lección práctica para un programa nuevo es registrar el punto de partida de estas medidas durante el primer mes, antes de desplegar ninguna herramienta, aunque sea a mano y de forma aproximada. Los programas que se lo saltan muchas veces no pueden demostrar su retorno dieciocho meses después, no porque no haya mejorado nada sino porque nadie anotó cómo era antes la cola de tickets o la preparación de auditorías. Una línea base aproximada gana a ninguna cada vez que un comité pregunta si el programa valió la pena.

Cuánto tarda y por qué

A veces la dirección espera que un programa de IGA tome un trimestre. La mayoría de las organizaciones medianas necesitan de dieciocho a veinticuatro meses para llegar a un funcionamiento estable, y conviene conocer las razones de antemano, porque condicionan el plan.

Buena parte del tiempo se va en los datos, no en el software. El sistema de RR. HH. tiene que convertirse en una fuente confiable de quién es cada persona y qué puesto ocupa, y eso suele significar limpiar años de registros inconsistentes. Emparejar las cuentas de decenas de aplicaciones con las personas correctas es un trabajo lento y manual en la primera pasada.

Otra parte grande se va en el tiempo de la gente. Los owners de aplicación tienen que definir qué significan sus entitlements y quién debería tenerlos. Los jefes tienen que aprender a revisar el acceso en lugar de aprobarlo por reflejo. Cada una de esas conversaciones compite con el trabajo de todos los días.

Y los conectores llegan de a poco. Un programa suele empezar por el directorio y un puñado de sistemas críticos y luego suma aplicaciones por oleadas, cada una con sus pruebas y su owner al que hay que sumar. Las primeras oleadas muestran resultados en meses; el alcance completo tarda más. Decirlo desde el principio, y mostrar las primeras cifras de la primera oleada, protege al programa de que lo juzguen por un plazo que nunca iba a cumplir.

Cómo suelen ser los primeros noventa días

Los programas que empiezan bien suelen dedicar sus tres primeros meses a una lista corta y poco vistosa, en lugar de desplegarlo todo a la vez.

Registran la línea base descrita antes: la cola de tickets, el tiempo de preparación de auditorías, el tiempo de retiro en las bajas. Acuerdan con RR. HH. que su sistema será la fuente autoritativa de los empleados, y con compras de dónde salen los registros de los contratistas. Hacen un inventario de aplicaciones, aunque sea aproximado, y las ordenan por riesgo, para que los primeros conectores vayan a los sistemas que más importan.

También eligen un logro rápido y visible. El más común son las bajas: conectar el evento de baja de RR. HH. con el directorio y con el puñado de aplicaciones más sensibles, para que el acceso desaparezca el día en que alguien se va. Es un trabajo acotado, fácil de medir, y ataca el hallazgo que más repiten los auditores. Otra opción frecuente es una sola revisión de acceso de un sistema crítico, hecha como corresponde, con contexto y con cada revocación confirmada, que limpia riesgo real y les muestra a los jefes cómo es una revisión con sentido.

Lo que no hacen en los primeros noventa días es diseñar todos los roles de la empresa ni conectar todas las aplicaciones. Eso viene después, por oleadas, con el crédito que dan los primeros resultados.

Cómo se relaciona con estándares y marcos

La división entre administración y gobierno, y las obligaciones que hay detrás, salen directamente de los marcos que citan auditores y profesionales:

• NIST SP 800-53, control AC-6 (mínimo privilegio) es el lenguaje de control al que remiten la mayoría de las auditorías SOX y FedRAMP cuando piden evidencia de que el acceso se revisa y se retiran los privilegios innecesarios, que es la mitad de gobierno de este artículo escrita como control.
• ISO/IEC 27001, Anexo A, exige una política de control de acceso documentada y la revisión periódica de los derechos de acceso de los usuarios, la misma obligación formulada para la auditoría de un sistema de gestión.
• Los capítulos sobre gobierno de identidades y gestión del ciclo de vida del IDPro Body of Knowledge son lo más parecido que tiene la profesión a una definición compartida, escrita por profesionales, de la división que se usa aquí.
• ISACA publica guías de auditoría y aseguramiento para programas de IAM, útiles cuando un caso de negocio tiene que hablar el idioma que usará el auditor.

No hace falta memorizar números de control para llevar bien un programa. Saber que “revisar el acceso cada trimestre” viene de un control concreto, y no de la opinión de alguien sobre buenas prácticas, es lo que convierte un requisito de gobierno en algo que un owner de negocio no puede simplemente rechazar.

Volviendo a las dos preguntas

¿Cuál es la diferencia entre administrar identidades y gobernarlas? La administración hace el trabajo: crea la cuenta, asigna el entitlement, corre el conector. El gobierno decide si el trabajo debe hacerse y comprueba que se hizo bien: la política, la revisión, la pista de auditoría. Ninguna de las dos es por sí sola el verdadero IGA. La disciplina es el ciclo entre ambas.

¿Y qué hace que una organización financie ese ciclo? Casi siempre una fecha límite con nombre: una auditoría, un incidente, una cola de tickets que alguien por fin contó, una fusión con fecha de cierre. En ese momento la tecnología importa mucho menos que tener una respuesta honesta a quién tiene acceso a qué y por qué. Es la pregunta a la que vuelven todos los motivos de este artículo, y el resto del módulo trata de responderla de forma confiable: de dónde salen los datos, cómo funcionan los eventos de alta, cambio y baja, qué se está otorgando realmente y quién responde de cada parte.

Resumen

• La administración de identidades ejecuta los cambios de acceso: aprovisionamiento, conectores, ejecución de solicitudes.
• El gobierno de identidades decide si esos cambios deben hacerse y comprueba que fueron correctos: políticas, revisiones, separación de funciones, evidencia de auditoría.
• IGA es el ciclo entre las dos, y la frontera entre ambas suele ser una frontera entre equipos.
• IGA no es solo revisiones, no es solo para grandes empresas y no lo aporta una herramienta por sí sola. Cubre empleados, contratistas, socios e identidades no humanas, pero normalmente no a los clientes.
• Los programas se financian por un hecho concreto, casi siempre el cumplimiento combinado con riesgo, eficiencia o una fusión.
• El retorno aparece en el volumen de tickets manuales, el tiempo de preparación de auditorías y el tiempo de retiro del acceso de quien se va, y depende de roles bien diseñados y de una línea base registrada. Sigue también medidas de gobierno, como la cobertura de revisiones y los entitlements con owner.

Tres preguntas para ponerte a prueba

1. Un colega dice: “Compramos una herramienta de IGA, así que el gobierno ya está cubierto”. ¿Qué le falta a esa frase y qué le preguntarías después?
2. ¿Cuál de los cuatro motivos esperarías que produjera la primera fase más acotada de un programa, y por qué?
3. En el primer martes de Daniel, Sara esperó una semana su acceso. ¿Qué capacidad acortaría esa espera más rápido y cuál tardaría más en dar frutos?

Ejercicio práctico

Elige una organización que conozcas bien: tu empleo, tu universidad o un club con herramientas compartidas.

1. Enumera cinco sistemas que se usen allí y, para cada uno, intenta responder tres preguntas: quién tiene acceso hoy, quién lo aprobó y cuándo se revisó por última vez. Anota cuánto tardaste en cada respuesta y dónde tuviste que buscar.
2. Para cada sistema, decide si los huecos que encontraste son problemas de administración (el acceso tarda en darse o en quitarse) o de gobierno (nadie decide ni comprueba si el acceso es correcto).
3. Cuenta cuántas de las “señales de que la hoja de cálculo ya no alcanza” de este artículo se cumplen.
4. Escribe dos frases que podrías usar para abrir un caso de negocio: el motivo que aplica y la medida que registrarías este mes como línea base.