El ciclo IAM en acción: una consultora de TI del middle-market

Una cuenta de invitado que nadie recordaba

El equipo de seguridad de un banco hace su revisión trimestral de las cuentas externas de su tenant en la nube y encuentra una identidad de invitado de un consultor de Northcape. El proyecto para el que se creó terminó hace cuatro meses. Una búsqueda rápida encuentra algo peor: el consultor está ahora en un proyecto para uno de los competidores directos del banco. Nadie hizo nada mal a propósito. El consultor pasó a otra cosa, el proyecto se cerró y la cuenta de invitado en el tenant del banco simplemente se quedó ahí. La llamada del banco a Northcape esa tarde no es amistosa.

Sara dirige IAM en Northcape, y este artículo cierra el módulo en algún punto entre los dos extremos anteriores. El hospital cargaba con mucha normativa; la startup tenía poco gobierno y mucha agilidad. Una consultora no es ninguna de las dos cosas. Es una organización madura y consolidada cuyo rasgo definitorio es el movimiento interno constante. Su gente no está en puestos fijos tocando sistemas fijos; rota entre proyectos de clientes, y cada rotación cambia sus accesos. Si el artículo del JML decía que el cambio de puesto es el paso que más descuidan los programas, esta es la organización donde el cambio de puesto es el protagonista.

Northcape es una consultora de TI de 2.000 personas que trabaja para clientes medianos y grandes en desarrollo de aplicaciones, migración a la nube y servicios gestionados. Está bien asentada y es rentable, con una función de TI de verdad y herramientas maduras. Su reto no es la capacidad sino la velocidad del cambio: en cualquier momento, cientos de consultores están saliendo de un proyecto y entrando en otro, y una parte importante de su acceso no vive en los sistemas de Northcape sino dentro de los tenants de los clientes. En la mayoría de las organizaciones el acceso sigue al puesto. En una consultora sigue al proyecto actual, y los proyectos cambian mucho más deprisa que los puestos. Diseña para la asignación, no para el cargo, o tu modelo de acceso describirá siempre dónde estaba la gente.

Poblaciones que dependen del trabajo

Las identidades de Northcape se organizan según cómo se relaciona la gente con el trabajo, no solo con la empresa. Unos 1.500 consultores facturables rotan sin parar entre proyectos, con su identidad procedente del sistema de RR. HH. y sus asignaciones del sistema de asignación de proyectos, el PSA. Unos 150 están en el banquillo entre proyectos, con acceso reducido mientras esperan el siguiente. Unos 200 subcontratistas trabajan desde fuera ligados a proyectos, registrados en la gestión de proveedores y en el PSA. Unas 150 personas de personal interno, en RR. HH., finanzas y TI, tienen puestos estables y convencionales que vienen solo de RR. HH. Y miles de identidades de invitado viven en los directorios de los propios clientes, federadas en sus tenants.

Los grupos interesantes son los dos primeros. Un consultor facturable en un proyecto tiene los accesos de ese proyecto. Un consultor en el banquillo entre proyectos debería tener acceso reducido, solo sistemas internos y ningún entorno de cliente, porque ahora mismo no está atendiendo a nadie. El paso de facturable a banquillo, en las dos direcciones, es un cambio de puesto que ocurre todo el tiempo, y tratar el banquillo como un estado real con su propio conjunto de accesos más pequeño es lo que impide que los consultores sin proyecto lleven encima accesos vivos a clientes sin ningún motivo actual.

Dos fuentes: quién eres y en qué estás

Una organización convencional puede hacer JML solo con el sistema de RR. HH. Northcape no, porque RR. HH. sabe quién es alguien y su categoría, pero no en qué proyecto está esta semana, y el acceso depende de lo segundo. Así que Northcape tiene una segunda fuente autoritativa, el sistema de asignación de proyectos, dueño de las asignaciones, del papel de cada persona en cada proyecto y de las fechas de fin. La identidad, la categoría y el empleo vienen de RR. HH. El proyecto actual y su fecha de fin vienen del PSA, porque la asignación decide quién está en qué y hasta cuándo. La condición de subcontratista viene de la gestión de proveedores, porque los subcontratistas no están en nómina. Y el acceso dentro del tenant de un cliente lo autoriza el directorio del propio cliente, mediante federación.

La plataforma de IGA combina esas fuentes. RR. HH. establece la identidad y su base, el PSA mueve los accesos propios de cada proyecto con fechas de fin firmes, y el resultado es un acceso que refleja la realidad actual. La regla clave que lleva dentro es que el acceso de un proyecto caduca con el proyecto. Como el PSA lleva una fecha de fin para cada asignación, el acceso se puede limitar para que desaparezca cuando se cierra el proyecto, acceso justo a tiempo a escala de todo un encargo.

Entrar en un proyecto

En Northcape el alta, un consultor nuevo que entra en la empresa, es lo raro, y el cambio de puesto, un consultor que pasa de un proyecto a otro, es lo constante. Los dos usan la misma maquinaria, así que la rotación es el flujo que conviene estudiar.

flowchart TB
  accTitle: Un consultor rotando entre proyectos de clientes
  accDescr: Un evento de cambio de asignación en el PSA se dispara cuando un consultor sale del proyecto A y entra en el proyecto B. La plataforma de IGA revoca los accesos del proyecto A, incluido el acceso como invitado federado al tenant del cliente A, y después aprovisiona los accesos del proyecto B con acceso federado al tenant del cliente B y una caducidad fijada en la fecha de fin del proyecto B. El cambio queda registrado para la empresa y para los clientes afectados.
  PSA[Cambio de asignación en PSA<br/>sale de A, entra a B] --> REVOKE[Revocar acceso del proyecto A]
  REVOKE --> DEFED_A[Quitar invitado federado<br/>en tenant del cliente A]
  PSA --> GRANT[Aprovisionar acceso del proyecto B]
  GRANT --> FED_B[Agregar invitado federado<br/>en tenant del cliente B]
  GRANT --> BOX[Acotar a fecha de fin del proyecto B]
  DEFED_A --> LOG[Registrar para firma + clientes]
  FED_B --> LOG
  BOX --> LOG

Es la regla del artículo del JML de que todo cambio de puesto es una pequeña baja más una pequeña alta, convertida en literal e inevitable. Entrar en el proyecto B sin salir del proyecto A no solo acumula privilegios. Deja al consultor con acceso fijo a un cliente al que ya no atiende, lo que en consultoría es una violación de la confidencialidad y de las normas sobre conflictos de interés, no un simple desorden de accesos. La mitad de retirar es la que protege los contratos de la empresa, así que no puede ser opcional ni manual. La llamada del banco era justo por esta mitad.

Accesos que viven en los tenants de los clientes

El giro estructural del IAM en una consultora es que buena parte del acceso de un consultor no está en sistemas que controle Northcape. Está dentro del entorno del cliente. Un consultor que desarrolla software para un cliente entra en el tenant de la nube del cliente, en sus repositorios y en su sistema de tickets. ¿Cómo gobierna Northcape un acceso que no es suyo?

La respuesta es la federación. El consultor se autentica con su identidad de Northcape y se le admite en el tenant del cliente como invitado o usuario externo, por ejemplo mediante la colaboración Microsoft Entra B2B. La autenticación se queda con el empleador y la autorización la da el cliente. Es elegante, pero crea una responsabilidad muy clara a la hora de retirar el acceso. Cuando un consultor sale de un proyecto, es Northcape quien tiene que quitar el acceso de invitado en el tenant del cliente A, no esperar a que el cliente A se dé cuenta. Cuando un consultor deja Northcape del todo, hay que revocar cada identidad de invitado federada en cada cliente, o la persona conserva acceso vivo a varios clientes después de irse. Y la identidad de origen es la pieza clave: desactivarla en la fuente debería cortar el acceso federado en todas partes, y por eso es la empresa la que tiene que encargarse de las bajas en lugar de dejárselas a cada cliente.

Es tentador suponer que, como el acceso vive en el tenant del cliente, las bajas son cosa del cliente. En la práctica no lo son. El cliente no ve tus cambios de asignación y no tiene ningún incentivo para perseguir a tus consultores que se fueron. Si Northcape no saca a su propia gente de los entornos de los clientes, las cuentas de invitado federadas se convierten en huérfanas que cruzan organizaciones: acceso vivo a los sistemas de un cliente en manos de alguien que dejó la empresa hace meses. La federación mueve la puerta; no mueve la responsabilidad.

Bajas repartidas por muchos entornos

Un consultor que deja Northcape es una baja más complicada que en una empresa con un solo tenant, porque su acceso está repartido entre los sistemas de la empresa y un número desconocido de tenants de clientes acumulados a lo largo de su carrera. De inmediato se desactiva su identidad de Northcape, se revocan sus sesiones y se quita el acceso de invitado federado de cada tenant de cliente al que llega esa identidad. Después se concilia la baja con el PSA, revisando el historial de proyectos del consultor para confirmar que no se ha quedado fuera ningún entorno de cliente, porque el registro de proyectos es el mapa de dónde buscar. La cuenta se desactiva y se conserva durante el periodo de retención contractual y normativo antes de borrarse, porque el trabajo de consultoría y las obligaciones de auditoría muchas veces sobreviven años al consultor. Y a los subcontratistas se les acaba el contrato en lugar de dimitir, así que una fecha de fin que falta en el sistema de proveedores se trata como una excepción, igual que con los contratistas del hospital.

La reconciliación importa aquí más que en ningún otro punto del módulo. En una consultora, la lista de sitios a los que alguien tiene acceso es en sí misma difícil de conocer, y el historial de proyectos del PSA es el único mapa fiable de la huella federada que hay que desmontar.

Contratos, auditorías y conflictos de interés

Northcape trabaja bajo ISO/IEC 27001 y SOC 2 y, algo poco habitual, bajo las cláusulas de seguridad de sus propios contratos con clientes, que a menudo fijan requisitos de acceso más estrictos que cualquier marco general. Un cliente puede exigir por contrato que el acceso se retire a las pocas horas de que un consultor salga del proyecto, que ningún consultor que trabaje para un competidor conserve acceso y que la empresa aporte pruebas de ambas cosas cuando se le pidan.

Eso añade algo que no tenían los otros dos casos: la higiene de accesos se convierte en un control de conflictos de interés, no solo de seguridad. La misma disciplina en los cambios de puesto que impide acumular privilegios mantiene los datos del cliente A fuera del alcance de un consultor que ahora está dentro del competidor del cliente A. En consultoría, retirar accesos no es solo reducir la superficie de ataque; es mantener la muralla entre clientes de la que depende la reputación de la empresa. Las pruebas que tiene que aportar una consultora son las mismas pruebas de JML que necesita todo el mundo, aprovisionamiento ligado a las asignaciones, retirada rápida y revisiones periódicas, pero el listón lo ponen los contratos de los clientes, que son más estrictos y menos indulgentes que un marco genérico. Construye el bucle al nivel del cliente más exigente y todas las auditorías serán fáciles; constrúyelo al mínimo del marco y lo renegociarás cliente a cliente para siempre.

El banquillo es un estado, no un hueco

El control que mejor distingue a una consultora madura es tratar el banquillo, los consultores entre proyectos, como un estado propio del ciclo de vida y no como “sigue en el último proyecto hasta que empiece el siguiente”. Cuando un consultor sale de un proyecto y no se le asigna otro enseguida, lo correcto es un cambio de puesto hacia un estado reducido: solo sistemas internos, todas las cuentas de invitado en clientes retiradas y los permisos de los proyectos facturables quitados.

Los profesionales insisten en ello porque la alternativa es la acumulación silenciosa de la que avisa el artículo del JML, en su versión más peligrosa por contrato. Un consultor que pasa seis semanas en el banquillo conservando acceso vivo a los tenants de tres antiguos clientes es un conflicto de interés andante, y cuanto más dura el banquillo, más viejo y más difícil de defender es ese acceso. Atar el estado de acceso al estado de asignación del PSA, de modo que “sin asignar” signifique automáticamente “solo interno”, elimina a la vez la decisión subjetiva y el retraso. El banquillo es también donde la certificación periódica es más fácil: un consultor sin proyecto actual no debería tener ningún acceso a clientes, la revisión de accesos más sencilla de decidir y la más vergonzosa de suspender.

Subcontratistas y entrega desde el extranjero

Northcape no hace todos sus proyectos con sus propios empleados. Los subcontratistas y los centros de entrega en otros países amplían la plantilla, y el perímetro de identidad, mucho más allá de la empresa, y ahí es donde el ciclo de vida cuesta más de hacer cumplir.

A los subcontratistas se les acaba el contrato en lugar de dimitir, como a los contratistas del hospital, así que sus identidades necesitan una fecha de fin firme procedente de la gestión de proveedores y del PSA, y una fecha que falta o que se alarga es una excepción. La entrega desde otros países añade dos cosas que los profesionales tratan de forma explícita. Una es el dispositivo: el acceso desde los puestos gestionados de un centro de entrega se trata de forma distinta al acceso desde un portátil personal sin gestionar. Las políticas de acceso condicional protegen los entornos sensibles de los clientes según el cumplimiento del dispositivo y la ubicación, así que la identidad no es la única señal y el contexto de la petición también cuenta, un adelanto de la autenticación basada en riesgo que se ve en gestión de accesos. La otra es la residencia de los datos: algunos contratos exigen que los datos del cliente no salgan nunca de un país, lo que limita qué centro de entrega puede asignarse al proyecto. La decisión de acceso pasa entonces a depender de dónde está sentada físicamente la persona, una restricción que el PSA tiene que llevar junto a la asignación.

El perímetro de identidad de una consultora es poroso por diseño, y sus controles tienen que llegar a personas que la empresa no emplea, en dispositivos que no posee y en países a los que los datos no pueden viajar.

Lo que usan las consultoras maduras

Las consultoras maduras acaban con una pila reconocible construida en torno a paquetes de acceso con tiempo limitado que se piden y se aprueban, en lugar de concesiones fijas. La gestión de permisos con caducidad, como los paquetes de acceso de Microsoft Entra Entitlement Management, agrupa los accesos que necesita un proyecto y los asigna con una caducidad ligada a su fecha de fin, de modo que la retirada al salir del proyecto ocurre sola y no cuando alguien se acuerda. La colaboración externa gobernada, Microsoft Entra External ID y B2B en el lado del cliente con la empresa de origen llevando el ciclo de vida de los invitados, hace que el acceso federado del diagrama de rotación se cree y se retire bajo control en lugar de quedar en manos de cada cliente. Las revisiones de accesos periódicas, con Entra Access Reviews o con una suite de IGA completa como SailPoint o Saviynt, hacen que los responsables de cada proyecto confirmen quién sigue necesitando acceso al cliente, y atrapan lo que se le escapó a la salida automática. Y las reglas de conflictos de interés en esas mismas herramientas de IGA modelan murallas éticas: reglas que impiden dar a un consultor del cliente A acceso al entorno de un competidor directo, la expresión en el control de acceso de la confidencialidad que la empresa debe por contrato.

Todo eso encaja con el anexo A de ISO/IEC 27001, gestión de identidades, aprovisionamiento y revisión de accesos, y acceso de terceros, y por eso una consultora con esta pila suele superar sin problemas tanto su auditoría de certificación como las evaluaciones de seguridad de sus clientes. La idea a la que vuelven una y otra vez los profesionales es caducar mejor que revocar. En una organización donde la gente se mueve todo el tiempo, un acceso que por defecto termina en una fecha conocida es mucho más seguro que uno que alguien tiene que acordarse de quitar. Las herramientas del sector han convergido en ese principio precisamente porque el cambio de puesto no se detiene nunca.

El trimestre de David

Sigue a David, ingeniero sénior de nube, durante tres meses para verlo funcionar. En enero está asignado al cliente A, un banco, con una identidad de invitado federada en el tenant del banco y un paquete de permisos que caduca en la fecha de fin prevista del proyecto. Trabaja a diario dentro de la nube del banco, entrando con su identidad de Northcape.

A mediados de febrero el proyecto termina antes de tiempo. El PSA registra la salida y pasan tres cosas automáticamente: caduca el paquete de permisos del cliente A, se elimina su acceso de invitado en el tenant del banco y su estado pasa a banquillo, solo acceso interno y ningún entorno de cliente. No lleva encima acceso vivo a un banco al que ya no atiende, y el rastro de auditoría muestra el momento exacto en que terminó cada acceso. Esta es la versión de los hechos en la que el banco nunca tiene que llamar.

Dos semanas después lo asignan al cliente B, una cadena de tiendas. La nueva asignación en el PSA dispara un paquete de permisos nuevo, acceso federado al tenant de la cadena, ajustado a su papel y con caducidad en la fecha de fin del nuevo proyecto. Nadie tuvo que abrir nunca un ticket para quitarle el acceso al banco; caducó por diseño cuando terminó el proyecto. Esa única propiedad, un acceso que por defecto termina, es lo que permite a Northcape rotar a cientos de Davids cada trimestre sin ahogarse en concesiones fijas ni en violaciones de confidencialidad. El contraste con la lucha de la startup es revelador: donde Rebate pelea por acordarse de quitar accesos, Northcape diseña la retirada para que ocurra sola.

Lo que mide Sara

Las métricas de Northcape se inclinan hacia el lado de la retirada, porque ahí viven tanto el riesgo contractual como la exposición a conflictos de interés. Sara vigila lo rápido que desaparece el acceso a un cliente tras la salida de un proyecto, que debería ser dentro de las horas que fija el contrato y no en días; cuántas cuentas de invitado hay en tenants de clientes sin ningún proyecto actual detrás, que deberían ser casi ninguna; qué parte de los accesos termina por caducidad y no porque alguien actúe, que debería ser la inmensa mayoría; si los consultores en el banquillo conservan algún acceso a clientes, que no debería ser ninguno, y si los responsables de los proyectos completan sus revisiones de accesos con la frecuencia que exigen los contratos.

El número de cuentas de invitado huérfanas es la métrica propia de este sector y la que más vigilan los profesionales. Una identidad de invitado en el tenant de un cliente sin ningún proyecto actual que la respalde es la huérfana entre organizaciones que hace posible la federación, la cuenta del banco del principio de este artículo, y sigue siendo invisible a menos que reconcilies dentro del directorio de cada cliente y no solo en el tuyo. El tiempo hasta retirar el acceso al salir de un proyecto es donde se encuentran la auditoría y el contrato: la cláusula de seguridad de un cliente puede fijar una cifra exacta, y Northcape tiene que demostrar que la cumplió con cada consultor que salió alguna vez de ese cliente. Cuando el acceso caduca por diseño al final de un proyecto, las dos cifras se cuidan solas; cuando la retirada es manual, las dos empeoran poco a poco con cada rotación, lo que con cientos de consultores garantiza una brecha tarde o temprano.

Cuando un consultor se pasa al cliente

Un caso propio de las consultoras es el cambio de empleador hacia el cliente: el mismo cliente al que atendía contrata a un consultor, o una transición de servicios gestionados pasa a todo un equipo de la nómina de Northcape a la del cliente. Es a la vez una baja en Northcape y un alta en el cliente, y el momento peligroso es la costura entre las dos.

Si se hace bien, se da de baja la identidad de Northcape del consultor, incluido el acceso de invitado al cliente, mientras el cliente le da en paralelo una identidad propia, de modo que el acceso continúa pero su base cambia de manos limpiamente. Si se hace mal, la cuenta de invitado se queda junto a la nueva cuenta propia, y la persona tiene dos caminos para entrar en los sistemas del cliente, uno de los cuales todavía pertenece nominalmente a Northcape aunque no tiene ningún motivo para conservarlo. Ese invitado sobrante es el cabo suelto entre organizaciones de manual.

La buena práctica es tratar el cambio como un único evento doble y coordinado, con un corte explícito, y no como dos transacciones sin relación que casualmente afectan a la misma persona. El flujo de baja de Northcape tiene que completarse, con el acceso de invitado retirado en todas partes, precisamente porque la persona sigue siendo accesible en el mundo del cliente por otra puerta. Recuerda a la regla del hospital para los médicos que trabajan en las dos alas: cuando las relaciones de una persona cambian de manos, gobierna el acceso de cada relación por separado en lugar de suponer que la continuidad de la persona significa continuidad del acceso.

Lo que enseña la consultora

Las lecciones de Northcape valen para cualquier organización por proyectos o matricial donde la gente se mueve más deprisa que el organigrama. El acceso sigue al proyecto, así que muévelo según la asignación actual y no según el cargo. Cuando RR. HH. no puede responder “¿en qué está?”, añade una segunda fuente autoritativa que sí pueda. Cada rotación quita y da, así que automatiza las dos mitades del cambio de puesto. Las bajas en sistemas ajenos son responsabilidad tuya, porque la federación mueve la puerta y no la responsabilidad. Y el historial de proyectos es el mapa para retirar accesos, porque no puedes quitar lo que no puedes enumerar.

La lección más profunda cierra todo el módulo. En un hospital regulado, en una startup caótica y en una consultora que vive de la rotación se cumple la misma verdad: el valor y el riesgo viven los dos en el lado de la retirada del ciclo de vida. Dar accesos es fácil y popular en todas partes. Lo que distingue a un programa de IAM de verdad, en cualquier sector, es la fiabilidad con la que quita el acceso cuando termina la relación, el puesto o el proyecto que lo justificaba. La cuenta de invitado del banco no fue un fallo tecnológico; fue una retirada de la que nadie era responsable.

Tres preguntas para ponerte a prueba

1. Un consultor pasa del cliente A al cliente B, un competidor directo. Enumera exactamente qué hay que quitar y qué hay que dar, y explica por qué aquí la retirada es una obligación contractual y no solo buena higiene.
2. Un consultor deja Northcape. ¿Cómo te aseguras de que se elimina cada cuenta de invitado federada en los tenants de todos sus clientes anteriores, y qué registro autoritativo te dice dónde buscar?
3. El sistema de RR. HH. de Northcape dice que un consultor es “Senior Developer”, pero ese cargo no dice nada sobre a qué puede llegar hoy. ¿Qué segunda fuente autoritativa lo resuelve y qué atributo concreto aporta que RR. HH. no puede aportar?