Identity and Access Management (IAM): Definición y ejemplos

¿Qué es Identity and Access Management (IAM)?

Identity and Access Management (IAM, gestión de identidades y accesos) es el conjunto de políticas, procesos y herramientas que deciden quién puede entrar en un sistema y qué puede hacer cada identidad una vez dentro. Una identidad puede ser una persona, un servicio o un dispositivo. IAM responde a tres preguntas: quién eres, qué tienes permitido hacer y qué hiciste.

Cómo funciona IAM

Todo despliegue de IAM combina tres pilares. Actúan en orden: la petición se autentica, después se autoriza y el resultado queda registrado.

El inicio de sesión único (SSO) se apoya encima: una sesión desbloquea varias aplicaciones, normalmente mediante un protocolo como SAML u OpenID Connect, de modo que el acceso se retira en un solo sitio cuando alguien se va.

Modelos de control de acceso

• RBAC (basado en roles): los permisos se asignan a roles como "lector" o "responsable de facturación", y las personas reciben roles. Es el modelo más común y el más fácil de revisar.
• ABAC (basado en atributos): una regla compara atributos del usuario, del recurso y del contexto, por ejemplo "permitir si user.department es igual a resource.department". Más fino, pero más difícil de auditar.
• ACL (lista de control de acceso): cada recurso lleva su propia lista de quién puede hacer qué. Sirve para archivos y sistemas pequeños, pero resulta incómodo a gran escala.

Ejemplo: un trabajo de CI que sube una imagen de contenedor

Un pipeline necesita subir una imagen a un único repositorio del registro. Una configuración débil le da una clave de administrador compartida que vive para siempre en una variable de build. Una configuración IAM sólida le da al trabajo su propia identidad de servicio con un rol que solo permite "subir a este repositorio", emite credenciales que caducan al terminar y registra cada llamada. Si el pipeline se retira, se borra la identidad y nada más cambia.

Errores comunes de IAM

• Cuentas con demasiados privilegios. Permisos de administrador concedidos "solo por ahora" y nunca retirados.
• Credenciales compartidas. Varias personas o servicios con un mismo acceso, así que ninguna línea de log se puede atribuir a nadie.
• Secretos de larga vida en el código. Claves de acceso en git o pegadas en tickets. Mejor usar tokens de corta duración.
• Cuentas obsoletas. Antiguos empleados, colaboradores externos y servicios retirados que siguen con acceso.
• Sin autenticación multifactor en cuentas de administrador. Una contraseña robada se convierte en una brecha total.
• Sin revisiones de acceso. Los permisos se acumulan durante años porque nadie los comprueba.

IAM, seguridad de APIs y pruebas de rendimiento

IAM se aplica en la API: cada llamada lleva un token o una clave que tu gateway comprueba contra roles y políticas. Ese es el tema de la seguridad de APIs, y por eso un buen IAM también debe aguantar tráfico real. Los emisores de tokens limitan peticiones, los tokens caducan en mitad de una prueba larga y renovarlos añade latencia propia. La guía sobre pruebas de rendimiento de APIs con OAuth2 (en inglés) explica esos efectos.

LoadFocus no es un proveedor de identidad, así que tu IAM sigue siendo tuyo. Lo que aporta es el lado del tráfico: pruebas de carga para ver cómo se comportan tus endpoints de login y de tokens bajo carga, y monitorización de APIs para vigilar de forma continua los endpoints protegidos.

Preguntas frecuentes: IAM

¿Cuál es la diferencia entre autenticación y autorización?

La autenticación demuestra quién eres, por ejemplo con contraseña y un segundo factor. La autorización decide después qué puedes hacer, según roles o políticas. Un sistema autentica primero y luego autoriza cada acción.

¿Basta con RBAC?

Para la mayoría de los equipos, sí. Empieza con pocos roles y revísalos con regularidad. Pasa a reglas por atributos solo cuando los roles se multipliquen o el acceso dependa de los datos, por ejemplo cuando un cliente nunca debe ver los registros de otro.

¿Qué es el mínimo privilegio?

Dar a una identidad solo los permisos que necesita para su tarea y nada más. Denegar por defecto y conceder acciones concretas sobre recursos concretos mantiene pequeño el daño de una credencial filtrada.

¿En qué se diferencia IAM de PAM?

IAM cubre todas las identidades y todas las decisiones de acceso. La gestión de accesos privilegiados (PAM) es el subconjunto que protege cuentas poderosas como root, administradores de bases de datos y accesos de emergencia, normalmente con credenciales en una bóveda, grabación de sesiones y accesos limitados en el tiempo.

¿Debo construir mi propio IAM o usar un proveedor?

Usa un proveedor consolidado o el IAM de tu nube. El almacenamiento de contraseñas, la gestión de sesiones, la recuperación de cuentas y los registros de auditoría son fáciles de hacer mal sin darte cuenta, y un fallo ahí afecta a todo lo que hay detrás del login.