IAM en la banca: cómo integrarlo en el control de accesos

¿Con qué tecnologías debe integrarse el Identity Access Management en la banca?

Una guía operativa sobre la integración del IAM debe comenzar con el mapeo de los dominios que intervienen en el control de accesos. Los sistemas de RR. HH. y los registros corporativos representan la fuente principal de información sobre identidad, función, ubicación, situación contractual y pertenencia organizativa. Los directorios y los proveedores de identidad (Identity Provider) gestionan la autenticación, los atributos, los grupos y el Single Sign-On. Las plataformas IGA y PAM supervisan, respectivamente, las solicitudes, aprobaciones, recertificaciones, revisiones de acceso, cuentas privilegiadas y sesiones administrativas.

Junto a estos sistemas permanecen los dominios aplicativos e infraestructurales: core banking, plataformas heredadas, cloud, SaaS, API, automatización de cargas de trabajo y herramientas de seguridad. En los sistemas modernos, la integración puede realizarse mediante federación, API o aprovisionamiento automático; en los sistemas legacy pueden ser necesarios conectores específicos, sincronizaciones controladas, intercambio de archivos o procedimientos de reconciliación. El aspecto central es mantener la coherencia entre identidades, atributos, políticas, autorizaciones y monitorización.

El control de acceso físico entra en este modelo únicamente cuando tiene un impacto directo sobre la seguridad, el cumplimiento normativo o la continuidad operativa: instalaciones administrativas, centros de datos, salas de servidores, salas de control, locales técnicos, cámaras acorazadas, áreas de cumplimiento normativo o espacios gestionados por proveedores TIC. En estos contextos, el ACS puede recibir del IAM identidades, roles, atributos, estado del usuario, fechas de expiración y políticas; al mismo tiempo, puede devolver eventos físicos útiles para auditorías, SIEM/SOC y flujos de trabajo de seguridad.

Pensemos, por ejemplo, en un proveedor TIC autorizado para intervenir en una sala de servidores: el sistema de RR. HH. o de gestión de proveedores registra la identidad externa; el IAM la vincula a un patrocinador interno y a una fecha de vencimiento; el sistema IGA (Identity Governance and Administration) gestiona la aprobación; el sistema ACS habilita el acceso físico únicamente durante la ventana temporal autorizada; mientras que el SIEM o la sala de control reciben los eventos necesarios para auditoría y monitorización. Sin esta cadena de integración, la credencial física, la cuenta de aplicación, el acceso VPN y la autorización operativa se gestionarían por separado.

En un entorno bancario, el IAM actúa por tanto como una capa de coherencia entre identidades, atributos y políticas, mientras que cada sistema aplica el control dentro de su propio dominio. La calidad de la integración se mide por la capacidad de hacer trazable el paso entre identidad, autorización, aplicación del control (enforcement) y monitorización.

Mejores prácticas para integrar IAM y control de accesos en la banca

Las mejores prácticas para la integración del IAM en la banca deben partir del perímetro en el que el diálogo con los sistemas ACS aporta un valor real. La convergencia entre identidad digital y control de acceso físico no afecta de forma indiscriminada a todas las sedes bancarias, sino principalmente a las instalaciones administrativas y a los entornos críticos. En estos contextos, el IAM proporciona al ACS la información necesaria para asignar, modificar o revocar un acceso; a su vez, el ACS devuelve eventos útiles para la monitorización, la seguridad, la auditoría y los flujos operativos.

De ello se derivan las siguientes mejores prácticas:

1. Definir el perímetro e integrar IAM y ACS en la gestión de credenciales de acceso

El primer paso consiste en determinar dónde la integración entre IAM y Access Control System resulta realmente necesaria. En la banca no tiene sentido extender esta lógica de manera indiscriminada a todas las sedes o sucursales: el valor surge especialmente allí donde el acceso físico protege infraestructuras, datos, procesos sensibles o responsabilidades operativas.

Definir el perímetro significa identificar qué áreas requieren un control físico vinculado a la identidad digital, qué roles pueden acceder a ellas, qué atributos deben evaluarse, qué autorizaciones deben tener una fecha de vencimiento y qué eventos deben incorporarse a los procesos de monitorización y auditoría.

Una vez definido el perímetro, la integración entre IAM y ACS debe basarse en una comunicación bidireccional. El IAM proporciona al sistema ACS identidades, roles, atributos, estado del usuario, fechas de expiración y políticas; el ACS aplica esta información a los puntos de acceso físicos y devuelve eventos útiles para auditoría, monitorización y seguridad.

El modelo más tradicional es el RBAC (Role-Based Access Control): el acceso se determina en función del rol que el usuario desempeña dentro de la organización, asignando permisos y credenciales coherentes con la función empresarial. Se trata de una lógica útil para accesos recurrentes y estandarizables, por ejemplo diferenciando entre personal TI, funciones de compliance, operadores de seguridad, técnicos de mantenimiento o proveedores autorizados.

Sin embargo, en los contextos más críticos, el rol por sí solo puede no ser suficiente. Dos usuarios con la misma función pueden requerir autorizaciones distintas en función de la ubicación, el turno, el área a la que deben acceder, la duración de la intervención, el nivel de confidencialidad del recurso o una situación de emergencia.

En estos casos adquiere relevancia el ABAC (Attribute-Based Access Control): el acceso se evalúa en tiempo real sobre la base de atributos del usuario, del recurso y del contexto, como departamento, situación contractual, ubicación, horario, nivel de riesgo o ventana temporal autorizada.

Para un banco, esto significa que cada credencial de acceso puede vincularse a una cadena verificable compuesta por identidad, atributo, política, aprobación, duración, utilización, revisión y revocación. El valor de la integración IAM-ACS radica, por tanto, en hacer que el acceso físico sea coherente con el modelo de gobernanza de identidades, trazable a lo largo del tiempo y más fácil de revocar cuando se producen cambios.

2. Definir la fuente autorizada de la identidad

Para los empleados, esta función suele ser desempeñada por los sistemas de recursos humanos; para proveedores, empresas subcontratadas y consultores, puede ser necesario integrar sistemas de gestión de proveedores o contratistas. Para las cuentas de servicio y las identidades técnicas se requieren registros específicos, responsables claramente definidos y vinculación con los activos o aplicaciones que las utilizan.

Sin esta distinción, el IAM puede propagar información incompleta o incoherente hacia aplicaciones, infraestructuras y sistemas físicos.

3. Normalizar los atributos

Rol, unidad organizativa, ubicación, tipo de contrato, nivel de riesgo, propietario, fecha de inicio, fecha de finalización y estado de la identidad deben mantenerse coherentes entre el IAM, los directorios, las aplicaciones, los sistemas físicos y las plataformas de auditoría.

Los atributos constituyen la base de las políticas de acceso: si no están actualizados o adecuadamente gestionados, incluso un modelo avanzado de control de accesos puede generar autorizaciones incorrectas.

4. Diseñar el ciclo joiner-mover-leaver

Las contrataciones, cambios de puesto, traslados, suspensiones, cambios de proveedor y bajas deben activar flujos de aprovisionamiento, modificación, recertificación o revocación. Esto se aplica a los accesos a aplicaciones, a los accesos privilegiados y, cuando sea relevante, a los accesos físicos a centros de datos, salas de servidores, salas de control, locales técnicos y áreas de compliance.

La revocación oportuna sigue siendo uno de los controles más importantes: una cuenta digital no desactivada, una credencial privilegiada aún válida o una tarjeta física no revocada pueden convertirse en vulnerabilidades operativas.

5. Integrar IGA, PAM y procesos ITSM

El IGA permite gestionar solicitudes, aprobaciones, segregación de funciones y campañas de revisión de accesos; el PAM supervisa cuentas privilegiadas, sesiones administrativas, elevaciones temporales de privilegios, accesos break-glass, credenciales técnicas y rotación de secretos.

En los entornos bancarios más estructurados, estos controles también deberían integrarse con los procesos de IT Service Management, de forma que sea posible relacionar accesos, tickets, cambios, incidencias, aprobaciones operativas y trazabilidad de auditoría.

6. Aplicar MFA y autenticación adaptativa a los accesos de alto riesgo

VPN, consolas cloud, aplicaciones críticas, sesiones administrativas y operaciones sensibles requieren controles proporcionales al contexto, dispositivo utilizado, red, ubicación geográfica y comportamiento del usuario.

La misma lógica puede extenderse a los accesos físicos más sensibles. En los escenarios de virtualización de credenciales, por ejemplo, la emisión de una credencial en un smartphone puede supeditarse a la verificación de identidad mediante SSO o un Identity Provider corporativo, asignando el acceso en función del rol, las políticas y la duración de la autorización.

7. Centralizar la monitorización y las evidencias

Los eventos del IAM deben alimentar los sistemas SIEM y SOC junto con los registros procedentes de PAM, cloud, aplicaciones, VPN, API y, cuando sea pertinente, sistemas físicos.

Esta correlación permite detectar anomalías que un único sistema no sería capaz de identificar: un acceso privilegiado fuera de horario, una sesión VPN anómala, una llamada API incoherente o una entrada física en un área técnica pueden adquirir un significado diferente cuando se analizan de forma conjunta.

Por último, la integración debe generar evidencias auditables: cada autorización debería poder reconstruirse a lo largo de todo su ciclo de vida, desde la solicitud y la aprobación hasta la asignación, el uso, la revisión y la revocación.

Este aspecto es especialmente relevante a la luz de la evolución del marco regulatorio europeo: DORA exige a los operadores financieros una gestión estructurada de los riesgos TIC, mientras que las directrices de la EBA sobre riesgos TIC y seguridad destacan la necesidad de controles documentados, responsabilidades claramente definidas y mecanismos verificables a lo largo del tiempo.

Para integrar el IAM en la banca, es necesario superar una gestión de accesos construida en silos y pasar a un modelo en el que identidades, privilegios, aplicaciones, infraestructuras, sistemas físicos y procesos de auditoría se gobiernen de forma coherente. El principal desafío consiste en la capacidad de vincular cada acceso a un rol, una responsabilidad, una política, una duración y una evidencia verificable.

En un ecosistema financiero cada vez más híbrido, regulado e interconectado, el Identity Access Management se convierte así en una herramienta clave para la seguridad y la gobernanza operativa. Su eficacia depende de la calidad de las integraciones: con sistemas de RR. HH., directorios, IGA, PAM, cloud, API, SIEM/SOC, sistemas legacy y control de acceso físico.

Solo de este modo el control de accesos en la banca puede convertirse en un proceso verdaderamente trazable y coherente con los requisitos de resiliencia que exige el sector.