En un banco, toda operación, desde que un cliente inicia sesión hasta que un empleado cambia un límite, empieza con una pregunta: quién está realmente al otro lado y qué tiene permitido hacer. Por eso la identidad y la autenticación dejaron de ser una capa de «login» y se convirtieron en el cimiento sobre el que descansa el resto de la seguridad. Para un director de seguridad, eso significa que el IAM en banca es un asunto de consejo, no solo de TI.
Por nuestra experiencia, lo difícil no es levantar una herramienta de IAM, sino conectarla a decenas de sistemas existentes del banco sin romper servicios ni dejar huecos en el rastro de auditoría. Por eso tratamos estos proyectos como desarrollo de software crítico, con un equipo que entiende tanto la seguridad como la realidad de la arquitectura bancaria. Ese es exactamente el tipo de equipo que desde 2017 desarrolla los sistemas de seguridad y las plataformas digitales de un banco privado global.
¿Por qué la identidad y la autenticación son el núcleo de la seguridad de un banco?
Porque casi todo incidente serio empieza con una identidad robada, no con un cifrado roto. En cuanto alguien suplanta a un cliente o a un empleado, el resto de los controles empiezan a trabajar a su favor. Una capa de identidad bien diseñada le da la vuelta a eso: reduce lo que un atacante puede hacer incluso después de tomar una cuenta.
Para un banco, lo que está en juego no es solo la pérdida económica, también la confianza del cliente y la responsabilidad ante el regulador. Por eso tratamos la identidad como una capa que debe ser a la vez estanca, reproducible en una auditoría y soportable en el uso diario. Cuando una de esas tres dimensiones se cae, las otras dos acaban sufriendo también.
¿Qué es la gestión de identidades (IAM) en un banco?
Dicho simple: el IAM responde a quién puede acceder a qué y en qué condiciones, a lo largo de todo el ciclo de vida de una cuenta. No es una herramienta única, sino un conjunto coherente de procesos y mecanismos. En la práctica abarca varias áreas:
- la identidad del cliente (CIAM), es decir registro, inicio de sesión y recuperación de cuenta en los canales digitales,
- la identidad de empleados y partners, desde el primer día de trabajo hasta la retirada de accesos cuando alguien se va,
- el gobierno de accesos y roles, que decide qué puede hacer realmente cada persona en un sistema,
- las identidades técnicas, es decir cuentas de servicio, API e integraciones, a menudo las más descuidadas.
Unimos estas áreas para que formen una única historia de acceso coherente, en vez de un conjunto de islas de login separadas en cada sistema.
¿Qué es la autenticación reforzada (SCA, MFA) y qué exige la PSD2?
La autenticación reforzada se basa en combinar al menos dos factores independientes de categorías distintas: algo que el usuario sabe (una contraseña, un PIN), algo que tiene (un teléfono, un token) y algo que es (biometría). Eso es lo que hay detrás de las siglas MFA (autenticación multifactor) y SCA (autenticación reforzada de cliente).
En Europa esto ya no es cuestión de buena voluntad. La directiva PSD2 obliga a los bancos a aplicar SCA cuando los clientes acceden a sus cuentas online y cuando inician pagos, con algunas exenciones para transacciones de bajo riesgo. Diseñamos estos mecanismos para cumplir ese requisito sin convertir cada acción en una carrera de obstáculos. Lo clave aquí es la vinculación dinámica de la autenticación a un importe y un beneficiario concretos, porque eso es lo que de verdad dificulta manipular una transacción.
¿Cómo se gobiernan los accesos y los permisos en un banco?
Aquí suele esconderse el mayor riesgo, porque los permisos tienden a «acumularse» con el tiempo. Un empleado cambia de equipo, asume nuevos roles y los antiguos se quedan. Lo ordenamos apoyando el acceso en principios claros:
- el mínimo privilegio necesario en vez de accesos concedidos «por si acaso»,
- roles y grupos ligados a un puesto, no a una persona concreta,
- separación de funciones, para que nadie controle en solitario un proceso sensible entero,
- revisiones y recertificaciones periódicas de los accesos, con caducidad automática de lo que no se usa.
Por encima de eso añadimos un control más estricto para las cuentas privilegiadas (administradores, cuentas de servicio), porque son el objetivo más valioso. Unos permisos bien estructurados hacen que ni siquiera una intrusión exitosa en una cuenta abra todo el banco a un atacante.
¿Cómo se conecta el IAM con los sistemas existentes del banco?
Esta suele ser la parte más dura y menos visible del proyecto. Un banco no parte de cero: tiene sistemas core, banca online, apps móviles y decenas de aplicaciones internas, a menudo con sus propios mecanismos de login. Nuestro objetivo es una única fuente de verdad coherente sobre la identidad a la que esos sistemas se conectan.
Los integramos con estándares modernos como OAuth 2.0, OpenID Connect y SAML, e introducimos single sign-on (SSO) donde tiene sentido. Las aplicaciones antiguas que no hablan ese idioma las envolvemos en capas intermedias en lugar de reescribirlas de inmediato. Eso mantiene la migración gradual y reversible, en vez de un arriesgado cambiarlo todo en un fin de semana.
¿Cómo se garantiza el cumplimiento y la auditoría en el área de identidad?
Para un banco no basta con ser seguro; además hay que poder demostrarlo. Por eso diseñamos pensando en la auditoría desde el principio, en vez de añadir el registro de eventos al final. En la práctica eso significa un rastro de auditoría completo e irrepudiable que muestra quién accedió a qué y cuándo, y quién le concedió ese acceso.
Mapeamos los mecanismos contra requisitos concretos, desde la PSD2 y las guías del supervisor hasta las políticas internas del banco, para que en una inspección responder sea cuestión de lanzar un informe y no de escarbar en logs durante semanas. Con los datos personales nos atenemos a los principios de minimización y responsabilidad proactiva, porque en un banco la identidad y la privacidad siempre van juntas.
¿Qué competencias aportamos a un proyecto de IAM?
Formamos el equipo alrededor de la etapa y la arquitectura concretas, no «por si acaso». En proyectos de identidad y seguridad cubrimos con más frecuencia perfiles como:
- un arquitecto de seguridad / IAM que define el modelo de identidad y permisos,
- ingenieros de integración que conectan el IAM con los sistemas core y los canales digitales,
- desarrolladores backend que construyen servicios de autenticación, API y mecanismos de SCA,
- especialistas de DevOps y seguridad que se ocupan de los despliegues, el hardening y la monitorización.
Un equipo así puede hacerse cargo de toda el área, desde el diseño hasta el mantenimiento, o reforzar al propio equipo del banco justo donde faltan manos o experiencia.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia, con experiencia real trabajando en los sistemas críticos de un banco. Para una institución global líder en banca privada y gestión de activos desarrollamos desde 2017 sus sistemas de seguridad, además de sistemas internos y plataformas digitales, y el equipo implicado ha crecido hasta casi 90 especialistas. Tratamos la gestión de identidades y la autenticación reforzada como un área dentro de esa competencia de seguridad, no como una herramienta aislada.
En estos proyectos nos apoyamos en unas pocas cosas: verificamos las competencias antes de empezar, trabajamos en una zona horaria cercana, así que entramos en revisiones de código y reuniones sin una larga puesta en marcha, y construimos pensando en la auditoría desde el primer día. La mayoría de las veces lo hacemos como software a medida construido por nuestro equipo y, cuando el banco necesita sumar competencias rápido, como refuerzo de equipo.
¿Por dónde empezar con el IAM y la autenticación reforzada?
Empieza por un inventario honesto: qué identidades, sistemas y métodos de login tienes hoy y dónde están los mayores huecos frente a la PSD2 y tus políticas internas. Después elige un canal o un proceso de alto riesgo (por ejemplo el login y los pagos en banca online) y valida ahí el modelo objetivo, en vez de reconstruirlo todo de golpe. Eso define la arquitectura, los estándares y los perfiles que necesitas. Repasamos las diferencias entre modelos de colaboración en nuestro artículo sobre modelos de colaboración en TI.
¿Vas a implantar u ordenar el IAM y la autenticación reforzada en tu banco? Hablemos - buscamos un equipo y una arquitectura para tu entorno y tus requisitos regulatorios.
Implanta con nosotros el IAM y la autenticación reforzada en tu banco