Una gran organización tiene miles de usuarios, cientos de sistemas y decenas de miles de permisos de acceso. Un empleado que hace cinco años estaba en el departamento de créditos y ahora trabaja en marketing probablemente conserve aún sus antiguos privilegios. Un contratista cuyo proyecto terminó puede seguir teniendo una cuenta activa. Las cuentas de servicio creadas para una integración temporal permanecen durante años con la misma contraseña. Nada de esto es por sí solo un desastre, pero en conjunto generan un nivel de riesgo que ningún auditor pasará por alto y que ningún equipo de seguridad puede gestionar a mano.
Aquí es esencial distinguir dos conceptos. La gestión de identidades y accesos (IAM) responde a la pregunta de si esta persona es quien dice ser y si puede hacer esto ahora mismo: autenticación, inicio de sesión único, verificación multifactor y emisión de tokens. El gobierno y la administración de identidades (IGA) aborda una pregunta más profunda: si esta persona debería tener este acceso, quién lo aprobó y cuándo debe revisarse. Las organizaciones que solo tienen IAM cierran bien la puerta principal, pero no saben a quién han entregado una llave.
La arquitectura preferida diseña ambos como capas complementarias sobre una única fuente de identidad compartida. En el centro se sitúa un directorio de identidades alimentado por el sistema de RR. HH. y el maestro de partes, que sigue cada identidad a lo largo de su ciclo de vida, desde la incorporación hasta la salida. La capa IAM, basada en estándares abiertos como OpenID Connect y SAML, se encarga de la autenticación y la emisión de tokens para cada aplicación, API y agente. La capa IGA gestiona los roles, las políticas, los flujos de solicitud y aprobación, las revisiones periódicas de accesos y la segregación de funciones, y aprovisiona el resultado como privilegios concretos en los sistemas de destino.
La primera consideración práctica es diseñar el modelo de roles. Los roles deben derivarse de la estructura real de la organización y de las descripciones de los puestos, no de los accesos existentes; de lo contrario, todos los permisos excesivos acumulados en el pasado se formalizan como roles. Un enfoque viable combina roles base asignados por unidad y puesto con privilegios solicitados individualmente. Por ejemplo, cada empleado de oficina recibe automáticamente el rol base de oficina, pero el acceso para aprobar financiaciones por encima de un umbral definido requiere una solicitud, la aprobación de un responsable y una fecha de caducidad.
La segunda consideración es automatizar el ciclo de vida. El control de seguridad más eficaz es retirar los accesos a tiempo, y eso solo es fiable cuando está conectado a los eventos de RR. HH. Cuando el registro de un empleado pasa al estado de baja, las cuentas deben desactivarse, los tokens revocarse y los privilegios retirarse en ese mismo momento. Un traslado entre unidades debe eliminar el rol antiguo y conceder el nuevo, no limitarse a añadir el nuevo. Esta vinculación orientada a eventos desplaza la carga de trabajo del equipo de seguridad de la revisión manual a la supervisión de las excepciones.
La tercera consideración son las identidades no humanas. Los servicios, las tareas programadas, los dispositivos IoT y, cada vez más, los agentes de IA necesitan una identidad, un conjunto de privilegios y un responsable designado. Estas identidades deben pasar por el mismo ciclo de vida y la misma revisión periódica que los usuarios humanos. Un agente que actúa en nombre de un usuario debe disponer de un token de alcance limitado y vida corta, y cada acción que realice debe atribuirse a ambas identidades, el agente y el usuario, para que la pista de auditoría no pierda a ninguna de las dos.
En este ámbito los errores abundan. Primero, empezar por una herramienta en lugar de por el modelo de datos y el proceso; ningún producto puede definir roles que nadie ha definido. Segundo, las revisiones de acceso meramente formales, en las que los responsables lo aprueban todo sin leerlo; la solución es mostrar contexto, como la última vez que se usó cada privilegio, y mantener cada revisión breve. Tercero, ignorar los sistemas heredados sin interfaces estándar que todavía se gestionan mediante archivos y acceso directo a la base de datos. Cuarto, agrupar IAM e IGA en un único proyecto enorme que pierde credibilidad antes de aportar su primer valor.
En Niadad, la plataforma Shanasa aporta la capa de identidad y acceso basada en estándares abiertos: autenticación centralizada, inicio de sesión único, verificación multifactor y emisión de tokens para usuarios, servicios y agentes. La plataforma Parsa asume la capa de políticas y gobierno: definición de roles y políticas de acceso, flujos de solicitud y aprobación, revisiones periódicas y segregación de funciones. En el programa bancario de Niadad, ambas se sitúan junto al maestro de partes Ashna y la pasarela de API, de modo que la identidad se gestiona como una cadena coherente desde el origen hasta el punto de aplicación.
La seguridad empresarial se reduce, en última instancia, a una pregunta sencilla: ¿puede decir en cualquier momento quién tiene acceso a qué y por qué? IAM responde al quién; IGA responde al porqué. Una organización que cuenta con ambos no solo supera sus auditorías, sino que puede abrir con confianza sus sistemas a nuevos usuarios, socios y agentes sin perder el control. El trabajo nunca termina, porque las organizaciones cambian constantemente; pero con la arquitectura adecuada, mantenerse al día se convierte en rutina y no en una emergencia periódica.