Seguridad en la gestión de la identidad digital: nuevas tendencias

Cuando hablamos de seguridad para las compañías podemos encontrar 5 grandes disciplinas:

• Seguridad en las comunicaciones, sistemas y aplicaciones, la seguridad perimetral y de sistemas clásica, necesaria pero insuficiente, y que ha ido incorporando la securización de las aplicaciones (desde el propio diseño de esta, a la codificación y despliegue).
• Seguridad en el punto de acceso, dispositivos utilizados por los usuarios para el acceso a información y aplicaciones como el ordenador o el móvil.
• Seguridad relativa a aspectos regulatorios y normativos, y la adecuación de la operación de la empresa a las leyes y normativas asociadas a la privacidad de los datos, uso de medios electrónicos y las políticas de cada empresa.
• Ciberseguridad o ciberdefensa, servicios de operación de los elementos de protección, análisis de vulnerabilidades, respuesta antes ataques, gestión del fraude, riesgo reputacional, etc.
•  Y la denominada IAM (Identity and Access Management), centrada en la gestión de la identidad y el control del acceso a servicios, y sobre la que vamos a hablar en este artículo.

Este tipo de seguridad asociada a la identidad debe tratar diferentes problemáticas, y tal como se ha ido implementando con el tiempo, ha generado nuevos retos derivados de, posiblemente, una falta de visión de futuro en su momento. Poco a poco surgen nuevas formas de hacer las cosas y nuevas tecnologías que permitirán dar respuesta a estos retos.

Por lo general, y de forma clásica, este tipo de seguridad se ha centrado en las “3 A”: autenticación (asegurar que el usuario es quien dice ser), autorización (a qué puede acceder ese usuario dentro del servicio o aplicación) y accounting (trazabilidad de todo lo que el usuario realiza desde que entra hasta que sale del servicio). Actualmente existen múltiples mecanismos tecnológicos para controlar las dos primeras y monitorizar la última, pero ¿cuáles son esos nuevos problemas que ha generado esta forma de hacerlo?

• 

Numerosas aplicaciones y usuarios y nuevos métodos de autenticación

Vayamos por partes viendo cómo se han hecho las cosas en el pasado.

Tradicionalmente, cada aplicación implementaba sus propios mecanismos de gestión de identidades, esto es, dentro del código de la aplicación se programaba el método de autenticación, los permisos de cada usuario (qué tipo de tareas podía hacer y a qué información acceder) y los mecanismos de accounting (esto si no se centraba exclusivamente en los accesos a la red).

Ahora, cuando nos encontramos con cientos de aplicaciones y miles de usuarios que requieren de un acceso, el problema es enorme.

Sin entrar en problemas operativos desde el punto de vista de la administración de la seguridad (cada usuario debe ser creado en cada aplicación para poder acceder, principalmente de forma manual), cada aplicación tiene su propio método de autenticación individual, poco o nada reutilizable, y bastante inflexible.

Por otro lado, encontramos el problema de los distintos métodos de autenticación a utilizar. ¿Qué sucede si se quiere introducir dentro de una aplicación un nuevo método de autenticación como, por ejemplo, un OTP (One Time Password) o una autenticación mulifactor? En este caso, sería necesario parar la aplicación, reprogramarla, y desplegarla de nuevo. Algo que si multiplicamos por la cantidad de aplicaciones con que puede contar una compañía supone un gran problema de costes y tiempos, algo que nadie se puede permitir.

Durante años la seguridad se ha enfocado en quién accede y a qué, pero sin diseñar una estrategia de escalabilidad a futuro. Por tanto, ¿qué soluciones encontramos?

De la centralización de la identidad a la identidad como servicio

De la centralización de la identidad a la identidad como servicio

Con el tiempo han aparecido soluciones de repositorios centrales de identidades, como es un directorio activo, que permitirá que, mediante relaciones de confianza (llamadas federaciones), una aplicación delegue la autenticación de un usuario en el directorio activo y, una vez este dé fe de la identidad del usuario, la aplicación lo considere bueno y conceda el acceso. Esto, combinado con la tecnología denominada Single Sign On (SSO), permite autenticarse una vez y que las autenticaciones necesarias en los siguientes accesos a servicios o aplicaciones dentro del ámbito cubierto por el SSO (en donde se han programado estas relaciones de confianza) sean transparentes al usuario (los realizará en background, por ejemplo, su navegador por él).

De esta forma, ha sido posible sacar la tecnología y lógica de seguridad de la aplicación confiando en un tercero. Así podremos realizar cambios en el elemento central, en este caso en el directorio activo y sus mecanismos de autenticación sin tener que modificar las aplicaciones, mejorando así la disponibilidad y la eficiencia.

Recientemente hemos avanzado todavía más, con el concepto Identidad como Servicio (IDaaS), en el que todas las herramientas asociadas a la gestión de identidades están externalizadas en un tercero de confianza (en la mayoría de los casos un proveedor Cloud) que nos permite realizar toda la gestión de la identidad y sus mecanismos de autenticación, autorización y accouting, de forma más simple y centralizada.

• 

Nuevos métodos de autenticación para una mejor experiencia de usuario

Siguiendo la línea anterior, podríamos plantearnos qué sucedería si queremos introducir un nuevo método de autenticación como la biometría, para hacer más sencillos los accesos de una persona y mejorar su experiencia de usuario.

Si pensamos por ejemplo en la app de un banco, veríamos cómo esta aplicación puede establecer una relación de confianza con el dispositivo (el teléfono móvil a través de un registro inicial), que será el que realice la autenticación.

Pero, ¿qué pasaría si el usuario cambia de teléfono móvil, o quiere acceder desde otro dispositivo que no está registrado? No puede hacer uso de este método, teniendo que volver, posiblemente, al método tradicional (usuario y password, y probablemente un OTP generado en el momento del intento de acceso para incrementar la seguridad). Aquí la relación de confianza para realizar la autenticación sería inoperante.

Aquí nacen otras técnicas como el uso de métodos de autenticación passwordless (sin contraseña) o incluso appless (sin aplicación o dispositivo asociado), normalmente basadas en la biometría del usuario, pero que también combinan otras técnicas como es el análisis de contexto en el que se produce el intento de acceso.

Introduciendo las preferencias y el contexto en la autenticación de la identidad digital

Existen herramientas que miden el nivel de riesgo de un intento de conexión de un usuario en base al contexto en el que se produce y son los llamados motores de confianza (Trust Engines), que implementan técnicas UEBA (User and Entity Behavior Analytics).

Por ilustrarlo con un ejemplo, un usuario quiere acceder a un servicio de su compañía eléctrica y, en función de los parámetros de contexto y comportamiento del usuario (dispositivo desde el que intenta acceder, horario, ubicación física, tipo de transacción o consulta…) se permitirá el acceso a la información o a la ejecución de la transacción, o no. Podría ser que se le diese acceso a consultar su consumo, pero no las facturas o realizar cambios en su modelo de tarifa.

El siguiente paso será el poder decidir qué tipo de método de identificación le pido a ese usuario en base a su contexto, esto es, en la misma situación de evaluación de su riesgo, dependiendo del tipo de operación que quiere realizar, le pediremos un tipo de identificación u otra. Siguiendo el ejemplo de nuestro usuario y su compañía eléctrica, si quiere ver sus facturas le podremos autenticar con un biométrico, y si quiere hacer un cambio en su modelo de tarificación, le pediremos que, además, introduzca un código numérico que le hemos enviado por SMS.

Siguiente problema, gestión de cambios en la gestión de la identidad dentro de las aplicaciones

Esto nos introduce el siguiente problema, que es, la flexibilidad en la utilización de diferentes métodos de identificación. Si lo formulamos como una pregunta, ¿qué proceso de actualización de métodos de identificación utilizamos? ¿Cuánto tiempo requiere la programación del motor de decisión y su implementación efectiva?

Ante la llegada de la capacidad de decisión del método de autenticación, la mayoría de las compañías se lanzaron a realizar aplicaciones que decidían en base a parámetros definibles (por ejemplo, el resultado del motor de confianza), pero esta es una aplicación en sí misma, esto es, requiere programación, parada y redespliegue.

Planteemos otra posible situación real, ¿qué sucede si hoy a las 16,00 se descubre un agujero de seguridad de, por ejemplo, los iPhone 12 con iOS inferior al 14.0 que expone los parámetros biométricos de los usuarios? Dependiendo de lo ágiles que seamos en la reprogramación de la aplicación que decide el método y en el despliegue que hagamos, estaremos en un riesgo de que nosotros o nuestros usuarios con este modelo de teléfono y sistema operativo, sufran un ataque, durante días, hasta que lo tengamos solucionado.

Ante esta casuística surgen los brokers u orquestadores de identidad, que son elementos que hacen precisamente esto, permitir la configuración de “user journeys” en donde podemos definir, en base a los parámetros que queramos (tecnología utilizada, políticas de seguridad de la compañía, evaluación de riesgos, conducta y costumbres de los usuarios, tipología de la operación, etc.) qué tipo de método de autenticación utilizamos con el usuario.

Este tipo de aplicaciones permiten la definición sencilla de estos user journeys que, en definitiva, son un árbol de decisión que terminará escogiendo la técnica de autenticación que debe aplicarse a cada usuario en el caso concreto que se presenta. Cuentan con un interfaz de programación low code que hace muy sencillo la definición del árbol de decisión y, como añadido, permiten la creación de nuevos journeys o cambios en los existentes off-line en apenas unos minutos, y, una vez probados, ser implantados de forma inmediata en las aplicaciones, ahorrando tiempos de espera vitales en casos como el ejemplo puesto anteriormente.

Volviendo al ejemplo del teléfono con sistema operativo inseguro en el uso de biometría del dispositivo, podríamos crear una excepción en el árbol de decisión del servicio concreto en minutos, impidiendo el uso de este método en el caso concreto, evitando un riesgo para la seguridad de forma rápida.

Este tipo de tecnologías también nos facilita enormemente mejorar la UX de nuestras aplicaciones, permitiendo incorporar las preferencias de los usuarios a la hora de escoger qué métodos de autenticación prefieren cuando acceden a los servicios de nuestra compañía, siempre dentro de lo que permita la política de seguridad, e incorporar elementos tecnológicos futuros de forma muy sencilla, simplemente integrándolos en el orquestador de identidades e incorporándolos al journey deseado.

Tendencias en identidad digital para seguir el ritmo de la transformación tecnológica

Como vemos, las complejidades de la gestión de los accesos y la identidad son grandes, pero pueden ampliarse todavía más con la explosión del IoT, que ya está creando interrelaciones de identidad ya no solo para usuarios personas sino entre dispositivos (ya sean domésticos o industriales) y las correspondientes aplicaciones.

Por ejemplo, una refinería con decenas de miles de dispositivos interconectados que sufra un problema en el protocolo de seguridad de interconexión de alguno de sus dispositivos deberá de tener la agilidad de modificar el método de autenticación en minutos para evitar grandes riesgos, y así con multitud de casos en cualquier tipo de industria. Es por ello por lo que, aunque las nuevas soluciones como un orquestador de identidades todavía no han sido abrazadas masivamente en el mercado, en los próximos años será algo común poder hacer este tipo de autenticación adaptativa en base a políticas, preferencias y contexto con la agilidad de cambiarlo sobre la marcha y de una manera muy sencilla.