Tema 11

11. IAM: aprovisionamiento, desprovisionamiento y ciclo de vida de identidades

Una identidad no es estática. Nace, cambia, acumula relaciones, gana y pierde accesos, se suspende, se reactiva o se elimina. La gestión de identidades y accesos, o IAM, se ocupa de gobernar ese ciclo de vida. Si esta capa falla, aparecen cuentas huérfanas, privilegios residuales y autorizaciones que ya no reflejan la realidad del negocio.

Objetivo Entender cómo se gobiernan identidades a lo largo del tiempo
Enfoque Operativo, arquitectónico y orientado a riesgo real
Resultado Diseñar altas, cambios y bajas con menor deuda de acceso

11.1 Introducción

Muchos problemas de seguridad no nacen en el login ni en el modelo de permisos, sino en cómo una organización crea, modifica y retira identidades y accesos. Cuando este proceso es improvisado, el sistema deja de reflejar el estado real del negocio.

Una persona cambia de rol y conserva privilegios anteriores. Un proveedor termina su contrato y su cuenta sigue activa. Un servicio deja de existir, pero su secreto permanece vigente. Todos estos casos son fallas del ciclo de vida.

IAM, Identity and Access Management, intenta resolver precisamente eso: que la identidad digital y sus permisos evolucionen de forma coherente con la realidad operativa y con las políticas de seguridad.

11.2 Qué es IAM

IAM es el conjunto de procesos, políticas, datos y tecnologías orientados a administrar identidades y controlar accesos de manera consistente a lo largo del tiempo. No es solo una herramienta ni solo un directorio: es una disciplina que conecta identidad, autenticación, autorización, gobierno y operación.

Un sistema IAM bien implementado busca responder preguntas como:

  • ¿Cómo se crea una identidad?
  • ¿Qué accesos recibe inicialmente y por qué?
  • ¿Qué ocurre si cambia de puesto, unidad o relación contractual?
  • ¿Cómo se revocan accesos cuando ya no corresponden?
  • ¿Cómo se audita todo este ciclo?

11.3 El problema del ciclo de vida

Una identidad no debería verse como una foto estática. En el tiempo pasan eventos que afectan directamente el acceso:

  • Alta de un nuevo usuario o servicio.
  • Cambio de rol, área o tenant.
  • Asignación temporal a un proyecto.
  • Suspensión, licencia o inactividad prolongada.
  • Baja definitiva o retiro de una integración.

Cada uno de estos eventos debería modificar atributos, permisos o estados. Si el sistema no acompaña esos cambios, el acceso se vuelve inconsistente con la realidad.

11.4 Fases del ciclo de vida de una identidad

De manera simplificada, el ciclo de vida suele incluir varias etapas:

  • Creación o alta: nace la identidad en el ecosistema.
  • Aprovisionamiento: se generan cuentas, relaciones y accesos iniciales.
  • Mantenimiento: se actualizan atributos y permisos ante cambios.
  • Suspensión o transición: se restringe o pausa el acceso temporalmente.
  • Desprovisionamiento: se retiran cuentas, sesiones, credenciales y privilegios.
  • Retención o archivo: se conserva la trazabilidad necesaria sin mantener acceso activo.

No todos los sistemas implementan todas estas fases con el mismo nivel de formalidad, pero ignorarlas casi siempre genera deuda de seguridad.

11.5 Aprovisionamiento: dar acceso inicial

El aprovisionamiento es el proceso por el cual una identidad obtiene sus cuentas, grupos, roles, atributos y permisos iniciales en los distintos sistemas donde debe operar.

Puede ocurrir de forma:

  • Manual: alguien crea cuentas y asigna permisos.
  • Automatizada: reglas o flujos generan accesos según atributos.
  • Híbrida: parte automática y parte sujeta a aprobación.

Un buen aprovisionamiento no consiste en “dar de alta rápido”, sino en dar de alta con precisión. Si el acceso inicial ya nace sobredimensionado, el resto del ciclo empieza mal.

11.6 Aprovisionamiento por atributos y por roles

En muchos entornos el aprovisionamiento inicial se apoya en reglas derivadas de atributos o roles. Por ejemplo, un usuario del área de ventas recibe acceso a CRM, correo y determinados reportes; un desarrollador recibe repositorios, herramientas de CI/CD y entornos técnicos.

Este enfoque reduce trabajo manual, pero exige datos confiables. Si el atributo “área” está mal cargado o llega tarde desde el sistema maestro, el aprovisionamiento puede asignar accesos incorrectos desde el inicio.

11.7 Cambios durante la vida de la identidad

El momento más delicado no siempre es el alta, sino el cambio. Las organizaciones viven moviendo personas, redefiniendo equipos y ajustando responsabilidades. Si los accesos no cambian al mismo ritmo, aparecen privilegios acumulados que ya no tienen justificación.

Algunos cambios típicos que deberían gatillar revisión automática o semiautomática:

  • Cambio de puesto o función.
  • Transferencia a otra unidad o región.
  • Asignación temporal a proyecto especial.
  • Cambio de proveedor de identidad o tenant.
  • Actualización del nivel de sensibilidad del rol.

11.8 El problema de los privilegios residuales

Un privilegio residual es un acceso que permanece activo aunque ya no corresponde al estado actual de la identidad. Es uno de los problemas más frecuentes y peligrosos en IAM porque suele pasar desapercibido.

Ejemplos comunes:

  • Un usuario cambia de equipo, pero conserva permisos del equipo anterior.
  • Una cuenta técnica ya no usada sigue pudiendo consultar datos sensibles.
  • Un proveedor finalizó contrato, pero mantiene acceso remoto o a portales internos.

Estos accesos son peligrosos porque parecen legítimos mientras nadie revise contexto real y justificación vigente.

11.9 Desprovisionamiento: retirar acceso cuando ya no corresponde

El desprovisionamiento es el proceso de retirar cuentas, credenciales, sesiones y permisos cuando una identidad deja de necesitar acceso. Es una de las etapas más importantes del ciclo de vida y, paradójicamente, una de las peor resueltas en muchas organizaciones.

Un desprovisionamiento serio debería considerar:

  • Desactivar autenticación.
  • Revocar sesiones activas.
  • Retirar roles, grupos y permisos.
  • Invalidar claves, tokens y certificados asociados.
  • Actualizar ownership de recursos que queden huérfanos.

No basta con “deshabilitar el usuario” en un solo sistema si todavía existen cuentas derivadas o secretos vigentes en otros.

11.10 Cuentas huérfanas

Una cuenta huérfana es aquella que sigue existiendo sin un dueño válido, sin una relación vigente con el negocio o sin una identidad claramente responsable. Estas cuentas son especialmente riesgosas porque suelen quedar fuera del monitoreo cotidiano.

Pueden surgir por:

  • Salidas de empleados o contratistas mal gestionadas.
  • Aplicaciones legacy sin integración con el proceso central.
  • Cuentas técnicas creadas para urgencias y nunca retiradas.
  • Migraciones o fusiones de sistemas sin limpieza suficiente.
Una cuenta sin dueño claro es un riesgo incluso si nadie la está usando hoy. El problema no es solo el uso actual, sino la posibilidad de uso futuro sin detección temprana.

11.11 Joiner, mover, leaver

En IAM suele hablarse del modelo Joiner, Mover, Leaver para representar tres eventos principales:

  • Joiner: la identidad ingresa al ecosistema.
  • Mover: cambia su rol, ubicación o relación organizacional.
  • Leaver: deja de pertenecer al ecosistema o pierde necesidad de acceso.

Este esquema es útil porque resume tres momentos donde la mayoría de los errores de IAM se concentran. Un sistema maduro debería tener procesos claros y medibles para los tres.

11.12 Sistemas fuente y datos autoritativos

El ciclo de vida de identidad depende de fuentes de verdad. En muchas organizaciones, ciertos atributos vienen de RR.HH., otros de CRM, otros de sistemas académicos o de plataformas de proveedores.

Por eso es fundamental definir:

  • Qué sistema crea la identidad.
  • Qué sistema es dueño de cada atributo relevante.
  • Qué evento dispara altas, cambios y bajas.
  • Qué ocurre cuando los datos son inconsistentes.

Sin esta base, el IAM termina apoyándose en datos ambiguos y el aprovisionamiento se vuelve inestable.

11.13 Automatización versus intervención manual

Automatizar IAM reduce errores y acelera el ciclo, pero no significa que todo deba fluir sin controles. Algunas decisiones pueden y deben seguir requiriendo validación humana, especialmente cuando se trata de acceso privilegiado o situaciones excepcionales.

La cuestión no es elegir entre manual o automático de forma absoluta, sino decidir qué partes conviene estandarizar y qué partes requieren criterio adicional. Una automatización mala escala errores más rápido; una operación completamente manual escala lentitud e inconsistencia.

11.14 IAM para identidades no humanas

Muchos equipos piensan IAM solo para personas, pero hoy las identidades no humanas son igual o más críticas. Servicios, cuentas de aplicación, pipelines, workloads cloud y automatizaciones también tienen ciclo de vida.

Eso implica responder preguntas como:

  • ¿Quién es dueño de esta cuenta técnica?
  • ¿Qué sistema justifica que exista?
  • ¿Cuándo expira o debe revisarse?
  • ¿Cómo se rotan sus secretos?
  • ¿Qué pasa si el servicio deja de existir?

Una identidad técnica olvidada puede ser una puerta mucho más peligrosa que una cuenta de usuario común.

11.15 Revisiones de acceso y recertificación

El ciclo de vida no termina con asignar y retirar. También hace falta revisar periódicamente si los accesos vigentes siguen teniendo sentido. Esta práctica suele llamarse recertificación o access review.

Su objetivo es detectar:

  • Permisos residuales.
  • Excesos de privilegio.
  • Cuentas sin uso o sin dueño claro.
  • Asignaciones inconsistentes con el rol actual.

La revisión periódica compensa el hecho de que los procesos de cambio nunca son perfectos. Sin ella, la acumulación de accesos tiende a crecer con el tiempo.

11.16 Métricas útiles en IAM

Un programa IAM maduro necesita medir, no solo ejecutar. Algunas métricas útiles pueden ser:

  • Tiempo promedio de alta de identidad.
  • Tiempo de baja efectiva tras evento de salida.
  • Cantidad de cuentas huérfanas detectadas.
  • Porcentaje de accesos revisados periódicamente.
  • Número de excepciones temporales que se volvieron permanentes.
  • Incidentes relacionados con privilegios residuales.

Estas métricas ayudan a pasar de una gestión reactiva a una disciplina gobernada.

11.17 Errores frecuentes en IAM

  • Dar altas rápidas sin revisar precisión del acceso inicial.
  • No retirar accesos al cambiar de rol o proyecto.
  • Depender de correos o tickets manuales sin trazabilidad suficiente.
  • No integrar sistemas legacy al proceso de baja.
  • Ignorar cuentas técnicas en revisiones de ciclo de vida.
  • No definir fuentes autoritativas claras para atributos críticos.
  • Confundir deshabilitar login con retirar efectivamente todo el acceso.

11.18 Señales de madurez en un programa IAM

  • Altas y bajas basadas en eventos confiables.
  • Roles y accesos iniciales definidos por función real.
  • Procesos de cambio que corrigen permisos anteriores.
  • Desprovisionamiento completo y medible.
  • Visibilidad sobre cuentas huérfanas y técnicas.
  • Revisiones periódicas y evidencia de corrección.

La madurez no se mide por tener una gran plataforma IAM, sino por la coherencia entre identidad real, datos, permisos y operación.

11.19 Qué debes recordar de este tema

  • IAM gobierna identidades y accesos a lo largo de todo su ciclo de vida.
  • Altas, cambios y bajas son eventos críticos para la seguridad.
  • Los privilegios residuales y las cuentas huérfanas son síntomas clásicos de mala gestión de ciclo de vida.
  • El desprovisionamiento debe retirar no solo cuentas, sino también sesiones, secretos y ownerships asociados.
  • Las identidades no humanas también requieren gobierno IAM.
  • La revisión periódica compensa fallas inevitables de los procesos de cambio.

11.20 Conclusión

La seguridad de identidad no depende solo de autenticar o autorizar correctamente en un instante dado. Depende de que la identidad siga representando la realidad del negocio a lo largo del tiempo. IAM aporta esa continuidad: crea, modifica, revisa y retira acceso de manera coherente, reduciendo una de las fuentes más persistentes de riesgo operativo.

En el próximo tema abordaremos directorios e identidad centralizada: LDAP, Active Directory y proveedores cloud, que suelen ser pilares estructurales del ecosistema IAM.