BUS de Identidad como herramienta de seguridad empresarial

Digamos que eres un ingeniero dedicado al desarrollo de software, y que trabajas para una empresa que se encarga de desarrollar software o para una empresa que tiene sistemas a los que les das mantenimiento. O bien puedes ser una persona encargada de buscar las mejores soluciones tecnológicas para tu empresa y mantenerla siempre actualizada, eficiente y segura.

En cualquier caso la llegada de un nuevo requerimiento de desarrollo de una nueva solución software pasa por los siguientes aspectos de seguridad que los muestro en forma de preguntas:

  1. Cómo se gestionarán los usuarios y los roles? En que mecanismo serán almacenados, BBDD, LDAP, ficheros, etc…?
  2. ¿Qué tipos de autenticación se brindarán, la típica de usuario/contraseña, se usará algún tipo de certificado digital, algún token, se usará alguna autenticación contra redes sociales como facebook, google, etc..?
  3. ¿Qué pasa con las BBDD que ya tenemos creadas de usuarios y roles de otras aplicaciones, no podemos reutilizarlas?¿Afectará en algo a las soluciones actuales si las uso?
  4. ¿En la empresa hay un LDAP, se podrá usar, lo uso?
  5. Mi empresa matriz gestiona la autenticación de forma centralizada, ¿podré conectar esta nueva aplicación a dicha autenticación?
  6. ¿Cómo logro que mis clientes, que no tienen por qué estar registrados en este nuevo sistema, puedan acceder al mismo y a sus funcionalidades sin tener que registrarlos?
  7. ¿Qué hago si me piden autenticación en múltiples pasos, para determinados usuarios o para determinados tipos de acceso?
  8. ¿Podré migrar los usuarios que tengo registrados en sistemas viejos a este sistema nuevo, qué tan complicado puede ser? ¿Cómo logro que los atributos de los usuarios de esos sistemas viejos se incluyan en el sistema nuevo?
  9. ¿Si ya mi ecosistema de aplicaciones va creciendo, cómo controlo los temas de seguridad de manera centralizada para no tener que estar entrando una por una a cada aplicación?
  10. En caso que un usuario cause alta o baja de la empresa, ¿tengo que ir sistema por sistema realizando la misma acción?
  11. Mis usuarios tienen que recordar una contraseña más, ¿sería posible lograr una única cuenta para todas las aplicaciones?

Muchas de estas preguntas están asociadas a requerimientos no funcionales de seguridad que generan una arquitectura de seguridad a nivel empresarial, o sea un diseño bien pensado y escalable en el tiempo con el objetivo de garantizar la seguridad de los datos y la información en todo momento.

En el día a día de nuestras empresas, y casi el 100% de las empresas cubanas, no existe una arquitectura de seguridad a nivel empresarial.

Las aplicaciones se compran o se hacen, y ya vienen con sus módulos de seguridad y entonces manualmente hay que proceder al registro de los usuarios, roles, y demás tareas de seguridad. En el mejor de los casos es posible conectarlas a un LDAP, pero falta la integración con otros mecanismos de seguridad. Se dificulta bastante visualizar temas de federación de identidades, aprovisionamiento de usuarios, etc…Primero porque son conceptos que en su mayoría se desconocen, segundo porque no saben como realizarlos, y tercero porque las soluciones propietarias cuestan, y bastante.

Se ha ido extendiendo a través de la comunidad de seguridad un término que unifica las respuestas/soluciones a todas las preguntas anteriores y es el de: BUS de Identidad Empresarial, o EIB.

Este BUS de identidad a groso modo puede verse como un sistema encargado de múltiples formas de autenticación, autorización, gestión de credenciales y mecanismos de seguridad, independiente de protocolos y capaz de realizar transformaciones de las credenciales de autenticación en base a los protocolos y estándares usados por sus proveedores y consumidores.

Con un sistema en el ámbito de una empresa, se le puede dar solución a todas las preguntas planteadas inicialmente y garantizar una correcta arquitectura de seguridad para todos los RNF definidos hacia lo interno de las aplicaciones informáticas.

A continuación se listan 15 requerimientos de forma macro que le pueden dar un poco más de sentido a este concepto:

Requerimiento  # 1. Protocolo de federación agnóstico:

  • No debe acoplarse a un protocolo de federación específico como SAML, OpenID Connect.
  • Capacidad de conectar múltiples proveedores de identidad a través de protocolos de federación de identidad heterogéneos.
  • Debe tener capacidad para transformar tokens de ID entre protocolos de federación heterogéneos.

 

Requerimiento  # 2. Protocolo de transporte agnóstico:

  • No debe acoplarse en un protocolo de transporte específico: HTTP, MQTT

 

Requerimiento  # 3. Autenticación de protocolo de autenticación:

  • No debe acoplarse a un protocolo de autenticación específico, nombre de usuario / contraseña, FIDO, OTP.
  • Autenticadores conectables.

 

Requerimiento  # 4. Transformación de atributos de los usuarios:

  • Debe tener la capacidad de transformar los atributos de los usuarios específicos del proveedor de identidad en atributos específicos del proveedor de servicios
  • Transformaciones simples y complejas de atributos

 

Requerimiento  # 5. Descubrimiento del proveedor de identidad por defecto o local:

  • Debe tener la capacidad de encontrar el proveedor de identidad por defecto correspondiente a la solicitud de federación entrante mirando ciertos atributos en la solicitud.
  • Enrutamiento basado en filtro.

 

Requerimiento  # 6. Autenticación multi-opción:

  • Debe tener la capacidad de presentar varias opciones de inicio de sesión para el usuario, por proveedor de servicios.

 

Requerimiento  # 7. Autenticación de varios pasos:

  • Debe tener la capacidad de presentar autenticación de múltiples pasos (MFA) para el usuario, por proveedor de servicios.

 

Requerimiento  # 8. Autenticación adaptable:

  • Debe tener la capacidad de cambiar las opciones de autenticación en función del contexto.

 

Requerimiento  # 9. Asignación de identidad:

  • Debe tener la capacidad de identificar identidades entre diferentes proveedores de identidad.
  • El usuario debe ser capaz de mantener múltiples identidades con múltiples proveedores de identidad.

 

Requerimiento  # 10. Varias tiendas de atributos:

  • Debe tener la capacidad de conectarse a múltiples almacenes de atributos y crear una vista agregada de la identidad del usuario final.

 

Requerimiento  # 11. Aprovisionamiento en tiempo:

  • Debe tener la capacidad de aprovisionar a los usuarios a los almacenes de usuario conectados de una manera independiente del protocolo.

 

Requerimiento  # 12. Administrar relaciones de identidad:

  • Debe tener la capacidad de administrar las relaciones de identidad entre diferentes entidades y tomar decisiones de autenticación y autorización basadas en eso.

 

Requerimiento  # 13. Aprovisionamiento de confianza:

  • Cada proveedor de servicios debe identificar en qué proveedores de identidad confía.

 

Requerimiento  # 14. Control de acceso centralizado:

  • ¿Quién tiene acceso a qué atributo de usuario? ¿A qué recursos puede acceder el usuario en el proveedor de servicios?

 

Requerimiento  # 15. Monitoreo centralizado:

  • Debe tener la capacidad de monitorear y generar estadísticas sobre cada transacción de identidad que fluye a través del intermediario.

 

 

 

2 opiniones en “BUS de Identidad como herramienta de seguridad empresarial”

    1. En una próxima entrada sacaré como montarnos en una nave espacial de hipervelocidad para llegar a esa vida real, de manera gratis y en el top de la tecnología, con los conocimientos necesarios para montar uno y cada uno de esos escenarios en una empresa estatal cubana.
      Como yo lo veo la única excusa que se tiene en una empresa estatal socialista cubana, que lo necesite, para no tener un bus de identidad al día de hoy es el desconocimiento y el no querer tenerlo.
      Saludos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *