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

Cuando el Mover es el evento principal

Cerramos el módulo entre nuestros dos extremos. El hospital era pesado en regulación; la startup era liviana en gobernanza y rápida de pies. Una consultora no es ninguna de las dos — es una organización madura y consolidada cuyo rasgo definitorio es el movimiento interno constante. Su gente no se sienta en roles fijos tocando sistemas fijos; rota entre proyectos de clientes, y cada rotación remodela su acceso. Si el artículo de JML te dijo que el Mover es el paso que más programas descuidan, aquí está la organización donde el Mover es el evento principal.

Conoce a Northcape — una consultora de TI de 2.000 personas que sirve a clientes del middle-market y empresariales en desarrollo de aplicaciones, migración a cloud y servicios gestionados. Northcape está bien establecida y es rentable, con una función de TI real y herramental maduro. Su reto no es la capacidad; es la velocidad del cambio: en cualquier momento, cientos de consultores están saliendo de un proyecto y entrando a otro, y una porción significativa de su acceso vive no en los sistemas de Northcape sino dentro de los tenants de sus clientes.

La organización y sus poblaciones de identidad

Las poblaciones de Northcape se organizan en torno a cómo la gente se relaciona con el trabajo, no solo con la firma:

Las poblaciones interesantes son las dos primeras. Un consultor facturable en un proyecto tiene su acceso; un consultor en la banca entre proyectos debería tener acceso reducido — solo sistemas internos, ningún entorno de cliente — porque no está sirviendo a nadie actualmente. La transición entre facturable y banca, en ambas direcciones, es un Mover que ocurre constantemente, y tratar la “banca” como un estado real con su propio conjunto de acceso reducido es lo que evita que los consultores ociosos carguen acceso de cliente vivo que no tienen razón actual de conservar.

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

Una organización convencional puede correr JML solo con el HRIS. Northcape no puede, porque el HRIS sabe quién es alguien y su grado pero no en qué proyecto está esta semana — y el acceso lo impulsa lo último. Así que Northcape corre una segunda fuente autoritativa: un sistema de staffing de proyectos (PSA) que es dueño de las asignaciones, los roles en el proyecto y las fechas de fin de proyecto.

La plataforma IGA une estos feeds: el HRIS establece la identidad y su línea base, el PSA impulsa el acceso específico del proyecto con fechas de fin firmes, y el resultado es acceso que refleja la realidad actual. La regla crucial codificada: el acceso del proyecto expira con el proyecto. Como el PSA lleva una fecha de fin para cada asignación, el acceso puede acotarse en el tiempo para desvanecerse cuando el proyecto cierra — un patrón just-in-time a escala de proyectos enteros.

Joiner y Mover: entrar a un proyecto

En Northcape, el Joiner (un consultor nuevo que entra a la firma) es el evento raro, y el Mover (un consultor rotando entre proyectos) es el constante. Los dos comparten la misma maquinaria, así que tratamos la rotación de proyecto como el flujo canónico.

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 al proyecto B. La plataforma IGA revoca el conjunto de acceso del proyecto A, incluido el acceso de invitado federado al tenant del cliente A, luego aprovisiona el conjunto de acceso del proyecto B con acceso federado al tenant del cliente B y un acotamiento en el tiempo fijado a la fecha de fin del proyecto B. El cambio se registra para la firma y 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

Esta es la regla del artículo de JML “cada Mover es un pequeño Leaver más un pequeño Joiner” hecha literal e inevitable. Entrar al proyecto B sin salir del proyecto A no solo crea privilege creep — deja al consultor con acceso fijo a un cliente que ya no sirve, lo cual en consultoría es una violación de confidencialidad y conflicto de interés, no simplemente acceso desordenado. La mitad de revocar es la mitad que protege los contratos de la firma, así que no puede ser opcional ni manual.

El reto distintivo: acceso que vive en los tenants de los clientes

El giro estructural de la IAM de consultoría es que gran parte del acceso de un consultor no está en sistemas que Northcape controla — está dentro del entorno del cliente. Un consultor que construye software para un cliente inicia sesión en el tenant cloud del cliente, sus repositorios, su sistema de tickets. ¿Cómo gobierna Northcape un acceso que no posee?

La respuesta es la federación. El consultor se autentica con su identidad de Northcape y es admitido al tenant del cliente como invitado o usuario externo — por ejemplo vía colaboración Microsoft Entra B2B. La autenticación se queda con el empleador; la autorización la otorga el cliente. Esto es elegante pero crea una responsabilidad de desaprovisionamiento aguda:

• Cuando el consultor sale, Northcape debe quitar el acceso de invitado en el tenant del cliente A — no esperar a que el cliente A se dé cuenta.
• Cuando el consultor deja Northcape por completo, cada identidad de invitado federada en cada cliente debe revocarse, o la persona conserva acceso vivo a múltiples clientes tras la salida.
• La identidad de origen es el eje: deshabilitarla en la fuente debería cascadear para cortar el acceso federado en todas partes, y por eso la firma debe impulsar el offboarding en lugar de delegarlo a cada cliente.

Leaver: salida a través de muchos entornos

Un consultor que deja Northcape es un Leaver más complejo que en una empresa de un solo tenant, porque su acceso está disperso por los sistemas de la firma y un número desconocido de tenants de clientes acumulados durante su trayectoria. El flujo:

• De inmediato: deshabilitar la identidad de origen de Northcape, revocar sesiones, y cascadear para quitar el acceso de invitado federado de cada tenant de cliente que la identidad alcance.
• Reconciliar contra el PSA: cruzar el historial de proyectos del consultor para confirmar que no se omitió ningún entorno de cliente — el registro de proyectos es el mapa de dónde buscar.
• Desactivar, luego eliminar: como siempre, retener la cuenta deshabilitada durante la ventana de retención contractual y regulatoria antes de eliminar, porque el producto de trabajo de consultoría y las obligaciones de auditoría a menudo sobreviven al consultor por años.
• Variante de subcontratista: los subcontratistas vencen en lugar de renunciar, así que una fecha de fin de proveedor faltante se trata como una excepción, exactamente igual que con los contratistas del hospital.

El paso de reconciliación importa más aquí que en cualquier otra parte del módulo: en una consultora, la lista de lugares donde 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 a desmantelar.

Cumplimiento y la dimensión de conflicto de interés

Northcape vive bajo ISO/IEC 27001 y SOC 2, y — de forma única — bajo las cláusulas de seguridad de sus propios contratos con clientes, que a menudo imponen requisitos de acceso más estrictos que cualquier marco general. Un cliente puede exigir contractualmente que el acceso se remueva dentro de horas tras la salida de un consultor de un proyecto, que ningún consultor que sirva a un competidor conserve acceso, y que la firma produzca evidencia de ambos a solicitud.

Esto agrega una dimensión ausente en los otros dos casos: la higiene de acceso es un control de conflicto de interés, no solo de seguridad. La misma disciplina de Mover que previene el privilege creep también previene que los datos del cliente A sean alcanzables por un consultor ahora incrustado en el competidor del cliente A. En consultoría, el desaprovisionamiento no es solo reducir superficie de ataque — es honrar el muro entre clientes del que depende la reputación de la firma.

La banca: un estado real, no un hueco

El único control que distingue la IAM de una consultora madura es tratar la banca — consultores entre proyectos — como un estado de ciclo de vida de primera clase, no como “todavía en el último proyecto hasta que empiece el siguiente”. Cuando un consultor sale y no se le re-asigna de inmediato, el comportamiento correcto es un Mover hacia un estado de acceso reducido: solo sistemas internos, cada invitado federado de cliente removido, los permisos de proyecto facturable retirados.

Los profesionales lo aplican porque la alternativa es la acumulación silenciosa contra la que advierte el artículo de JML, en su forma más peligrosa contractualmente. Un consultor que pasa seis semanas en la banca conservando acceso vivo a los tenants de tres clientes anteriores es una exposición ambulante de conflicto de interés — y mientras más larga la banca, más rancio e indefendible se vuelve ese acceso. Atar el estado de acceso al estatus de asignación del PSA, de modo que “sin asignar” signifique automáticamente “solo interno”, elimina el juicio manual y la demora. La banca es también donde la certificación periódica tiene más palanca: un consultor con ningún proyecto actual debería tener ningún acceso de cliente, que es la revisión de acceso más fácil de adjudicar del mundo y la más vergonzosa de reprobar.

Subcontratistas y entrega offshore

Northcape no entrega cada proyecto con sus propios empleados con gafete. Los subcontratistas y los centros de entrega offshore extienden la plantilla — y el perímetro de identidad — mucho más allá de la firma, y son donde el ciclo de vida es más difícil de aplicar.

Los subcontratistas vencen en lugar de renunciar, exactamente como los contratistas del hospital, así que sus identidades deben cargar una fecha de fin firme del sistema de gestión de proveedores y del PSA, con una fecha faltante o extendida tratada como excepción. La entrega offshore agrega dos dimensiones más que los profesionales manejan explícitamente:

• Postura del dispositivo: el acceso desde las estaciones gestionadas de un centro offshore se trata distinto del acceso vía un dispositivo personal no gestionado. Las políticas de conditional access condicionan los entornos sensibles de clientes al cumplimiento del dispositivo y la ubicación, así que la identidad no es la única señal — el contexto de la solicitud también importa (un anticipo directo de la autenticación basada en riesgo que cubriremos en Access Management).
• Residencia de datos: algunos contratos de clientes exigen que sus datos nunca salgan de una jurisdicción, lo que restringe qué centro de entrega puede dotarse al proyecto siquiera. Aquí la decisión de acceso se entrelaza con dónde se sienta físicamente el humano — una restricción que el PSA debe cargar junto con la asignación.

La lección es que el perímetro de identidad de una consultora es poroso por diseño, y los controles tienen que alcanzar a personas que la firma no emplea, en dispositivos que no posee, en países a donde los datos no tienen permitido viajar.

Lo que los profesionales realmente operan: gestión de permisos y revisiones de acceso

Las consultoras maduras convergen en un stack de buenas prácticas reconocible construido en torno a paquetes de acceso acotados en el tiempo, de solicitar-y-aprobar en lugar de otorgamientos fijos:

• Gestión de permisos con expiración — por ejemplo los paquetes de acceso de Microsoft Entra Entitlement Management — agrupa el acceso que un proyecto necesita y lo asigna con una expiración atada a la fecha de fin del proyecto, de modo que el desaprovisionamiento al salir es automático y no recordado.
• Colaboración externa gobernada — Microsoft Entra External ID / B2B del lado del cliente, con la firma de origen impulsando el ciclo de vida del invitado — para que el acceso federado del diagrama anterior se cree y se remueva bajo control, no se deje a cada cliente.
• Revisiones de acceso recurrentes — Entra Access Reviews o el equivalente en una suite IGA completa (SailPoint, Saviynt) — donde los líderes de proyecto recertifican quién sigue necesitando acceso de cliente, atrapando lo que el roll-off automático dejó pasar.
• Aplicación de SoD y conflicto de interés — el mismo herramental IGA modela muros éticos: reglas que impiden que a un consultor en el cliente A se le otorgue acceso al entorno de un competidor directo, la expresión a nivel de acceso de la confidencialidad que la firma debe contractualmente.

Estos mapean limpiamente al Anexo A de ISO/IEC 27001 — gestión de identidad, aprovisionamiento y revisión de acceso, y la gestión del acceso para partes externas — por lo que una consultora que opera este stack tiende a pasar sin problemas tanto su auditoría de certificación como las evaluaciones de seguridad de sus clientes. La idea unificadora a la que los profesionales regresan una y otra vez es la expiración sobre la revocación: en una organización donde la gente se mueve constantemente, el acceso que por defecto termina en una fecha conocida es mucho más seguro que el acceso que debe recordarse quitar. El herramental de toda la industria ha convergido en ese principio precisamente porque el Mover nunca para.

El trimestre de un consultor: la rotación en la práctica

Sigue a David, un ingeniero cloud senior, a lo largo de tres meses para ver girar la maquinaria. 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 cuya expiración se fija al fin planificado del proyecto. Trabaja dentro del entorno cloud del banco a diario, autenticándose con su identidad de Northcape.

A mediados de febrero el proyecto cierra antes. El PSA registra la salida, y tres cosas ocurren automáticamente: el paquete de permisos del Cliente A expira, su acceso de invitado federado en el tenant del banco se remueve, y su estatus pasa a banca — acceso solo interno, ningún entorno de cliente. No carga acceso vivo a un banco que ya no sirve, y el rastro de auditoría muestra el timestamp exacto en que terminó cada acceso.

Dos semanas después es asignado al Cliente B, un minorista. Una nueva asignación en el PSA dispara un paquete de permisos fresco — acceso federado al tenant del minorista, acotado a su rol, expirando en la fecha de fin del nuevo proyecto. En ningún momento alguien abrió un ticket para quitar su acceso del banco; expiró por diseño cuando lo hizo el proyecto. Esa única propiedad — acceso que por defecto termina — es lo que le permite a Northcape rotar a cientos de Davids cada trimestre sin ahogarse en otorgamientos fijos ni violaciones de confidencialidad. El contraste con la lucha de la startup es instructivo: donde Rebate pelea por acordarse de quitar el acceso, Northcape diseña que la remoción ocurra sola.

Medir la IAM de una consultora

Las métricas que importan en Northcape están inclinadas hacia el lado de remoción, porque ahí viven tanto el riesgo contractual como la exposición de conflicto de interés:

El conteo de huérfanas de invitado federado es la métrica única de este sector y la que los profesionales vigilan con más fuerza: una identidad de invitado sentada en el tenant de un cliente sin un proyecto actual que la respalde es la huérfana entre organizaciones que la federación hace posible, y es invisible a menos que reconcilies dentro del directorio de cada cliente, no solo el tuyo. El tiempo de desaprovisionamiento al salir es donde se encuentran la auditoría y el contrato — la cláusula de seguridad de un cliente puede especificar un número firme, y Northcape debe poder probar que lo cumplió para cada consultor que alguna vez salió de ese cliente. Cuando el acceso expira por diseño al fin del proyecto, ambas métricas se cuidan solas; cuando la remoción es manual, ambas se degradan en silencio con cada rotación, lo que a lo largo de cientos de consultores es una garantía de brecha eventual.

Rebadging: cuando un consultor se vuelve empleado del cliente

Un caso límite distintivo de las consultoras es el rebadging — un consultor es contratado por el mismo cliente al que servía, o una transición de servicios gestionados mueve a todo un equipo de la nómina de Northcape a la del cliente. Es a la vez un leaver de Northcape y un joiner en el cliente, y el momento peligroso es la costura entre ambos.

Manejado bien, la identidad de origen del consultor en Northcape se da de baja — incluido el acceso de invitado federado al cliente — mientras el cliente le aprovisiona una identidad nativa en paralelo, de modo que el acceso es continuo pero la base de ese acceso cambia de manos limpiamente. Manejado mal, el invitado federado persiste junto a la nueva cuenta nativa, dejando a la persona con dos vías de acceso a los sistemas del cliente, una de las cuales Northcape todavía posee nominalmente pero ya no tiene razón de tener. Ese invitado huérfano es un cabo suelto entre organizaciones de manual.

La buena práctica es tratar el rebadging como un evento dual coordinado con un cutover explícito, no como dos transacciones inconexas que casualmente involucran al mismo humano. El flujo leaver de Northcape debe correr hasta completarse — acceso de invitado removido en todas partes — precisamente porque la persona sigue siendo alcanzable en el mundo del cliente por una puerta distinta. El principio hace eco de la regla de doble afiliación del hospital: cuando las relaciones de un humano cambian de manos, gobierna el acceso de cada relación en sus propios términos en lugar de asumir que la continuidad de la persona significa continuidad del acceso.

Lo que enseña este caso

Northcape se generaliza a cualquier organización basada en proyectos o matricial donde la gente se mueve más rápido que los organigramas:

La lección más profunda cierra el bucle de todo el módulo: a través de un hospital regulado, una startup caótica y una consultora impulsada por rotaciones, se sostiene la misma verdad — el valor y el riesgo viven ambos en el lado de remoción del ciclo de vida. Otorgar acceso es fácil y popular en todas partes; la disciplina que distingue a un programa de IAM real, en cada sector, es con cuánta fiabilidad quita el acceso cuando la relación, el rol o el proyecto que lo justificaba termina.

Tres preguntas para autoevaluarte

1. Un consultor rota del cliente A al cliente B, un competidor directo. Lista exactamente qué debe revocarse, qué debe otorgarse, y por qué la mitad de revocar es una obligación contractual aquí y no solo buena higiene.
2. Un consultor deja Northcape. ¿Cómo garantizas que cada cuenta de invitado federada en todos los tenants de sus clientes pasados se remueva, y qué registro autoritativo te dice dónde buscar?
3. El HRIS de Northcape dice que un consultor es “Desarrollador Senior”, pero ese título no implica nada sobre lo que puede acceder hoy. ¿Qué segunda fuente autoritativa resuelve esto, y qué atributo específico aporta que el HRIS no puede?