IAM
En seguridad de empresa, IAM es la gestión de identidades y accesos: los sistemas que establecen quién o qué es una identidad, a qué puede acceder, y cómo se concede, se revisa y se revoca ese acceso. Cubre por igual las identidades humanas y las no humanas, y en la mayoría de los parques las no humanas son ya la población más grande y la menos gobernada.
Cómo funciona
Bajo el término caben cuatro funciones que se compran en sitios distintos, y eso es parte de por qué la foto rara vez está completa. La autenticación establece la identidad. La autorización decide a qué puede llegar. La gestión del ciclo de vida se ocupa de las altas, los cambios y las bajas, que es donde vive la mayor parte del riesgo operativo. La gobernanza aporta la evidencia: quién aprobó este acceso, cuándo se revisó por última vez, y si eso se le puede enseñar a un auditor.
Por encima hay dos especialidades. La gobernanza de identidades cubre las campañas de certificación, la separación de funciones y las peticiones de acceso. La gestión de accesos privilegiados cubre las cuentas que pueden cambiar el propio sistema. Un regulador o un auditor de ISO 27001 o del ENS pedirá la evidencia de gobernanza, no el diseño de la autenticación.
Qué sale mal
El proceso de baja es el hueco clásico y sigue ahí. Las cuentas humanas se deshabilitan razonablemente bien porque alguien se da cuenta cuando una persona se va. Lo que sobrevive es todo lo demás que colgaba de ella: la cuenta de servicio que creó, la clave de API metida en un script, el token de acceso personal en un repositorio, la aplicación de terceros a la que dio su consentimiento. Como no se va nadie, no se revoca nada.
El segundo es la forma de la población. Las cuentas de servicio, las identidades de carga de trabajo, las claves de API, las credenciales de máquina y ahora los agentes automáticos superan con mucho a las personas en un parque moderno, y no tienen responsable, ni formulario de alta, ni fecha de baja. Ahí es donde ocurre el compromiso, y por eso la identidad no humana es una disciplina propia y no una nota al pie de esta ficha.
El tercero es el privilegio permanente. El acceso concedido para siempre porque hizo falta una vez es la materia prima de todos los attack paths que dibujamos, y se acumula precisamente porque quitarlo da miedo y concederlo no.
Dónde aparece esto en una auditoría
En un proyecto de cloud enumeramos las identidades y sus permisos efectivos, no sus políticas asignadas, porque las dos cosas dejan de coincidir en cuanto se resuelven la herencia, las relaciones de confianza y la asunción de roles. El hallazgo suele ser una cadena: esta identidad puede asumir aquel rol, que puede modificar aquella política, que concede administración. Informamos además de las cuentas cuyo dueño nadie ha sabido nombrar, porque esa lista predice el próximo incidente mejor que cualquier carencia de control. Esto forma parte de cómo probamos la identidad y los permisos en un parque cloud.