Enmilocalfunciona

Esta vez vamos hablar de la identidad digital y su gestión a nivel empresarial y en general. Es recomendable haber leído mi serie de artículos de introducción al mundo de la seguridad, sobre todo la parte 2 de medidas de seguridad.

¿Qué era lo de la identidad?

La identidad es el punto clave de la identificación, es decir la respuesta a la pregunta ¿quién eres? (ver Hablemos de Seguridad - Parte 2: Medidas de seguridad).

No vamos a entrar en la pregunta filosófica del ¿Quién soy? pero sí vamos a recordar cómo nosotros - los seres humanos - gestionamos la identidad, ya que esto nos dará pistas para entender mejor la identidad digital de hoy y de mañana.

¿De dónde sabemos quiénes somos? - porque nuestros padres nos lo han dicho. La administración de un estado en cambio, se basa en última instancia en la palabra del personal médico quién nos trajo a este mundo, llamado parte médico de alumbramiento.

Vemos que los humanos nos identificamos con nombres (de pila, apellidos, motes, etc.) y cuándo queremos conocer a alguién no solo preguntamos por su nombre sino probablemente también por de dónde viene y qué ha hecho. Es decir, intentamos obtener un identificador (su nombre de pila o un mote si el nombre coincide con otra persona de nuestro grupo social) y algunos atributos más sobre la persona (sus padres, hermanos, dónde y cuándo nació, estudios, trabajos, experiencias, etc.) con el fin de conocer a una persona. Conocemos a una persona cuando tenemos suficiente confianza en la identidad de la persona.

Es decir, para las personas, la identidad es un conjunto de nombres, atributos y vivencias que identifican a una persona.

Aparte de las personas naturales, existen legalmente las personas jurídicas. Estas personas jurídicas identifican a una organización o empresa, no a una persona natural en concreto. Aquí el concepto de identificación es el mismo: nombres (nombre de empresa, razón social, etc.), otros identificadores (C.I.F.), atributos (sector de actividad, cargos representativos, etc.) y vivencias (facturación, número de empleados, etc.).

¿Qué pasa en el mundo digital?

Pues en el mundo digital intentamos transferir o mapear los nombres, atributos y vivencias al ámbito digital. Es decir, codificamos lo que identifica a una persona - tanto natural como jurídica.

Fuente: Wikimedia

Lo que ocurre en el mundo digital es que solo actúan programas de software en nuestro nombre. Por esta razón, cada aplicación o servicio intenta identificar al actor (el usuario, entidad o entity) con un identificador inequívoco y único (identidad o identity). En todos los casos, se intenta crear un ancla con la realidad física u otro sistema software ya existente.
Es decir, en el momento de alta de una entidad en un sistema para obtener una identidad en forma de un identificador (nombre de usuario, correo electrónico, etc.), se utilizan procesos manuales o automatizados para asegurar este enlace entre una persona natural o jurídica (entidad) con un identificador digital.

Este proceso de alta de una identidad digital depende del contexto organizativo y objetivo, que puede requerir distintos niveles de confianza en esta nueva identidad digital.

Los realms y sus registros de identidades

Desde el punto de vista legal, tenemos siempre un contrato detrás de cada alta de una identidad digital (p.ej. contrato laboral, contrato de servicio, contrato marco de colaboración, etc.). De esta relación legal cuelgan los ámbitos principales de una identidad digital en una organización. Los ámbitos, reinos o realms más comunes son:

• B2E: Business to EmployeeAlberga las identidades de los empleados de una organización, asociados con: la firma de un contrato laboral, un número de seguridad social, un documento de identidad del campo legal de la organización como pasaporte o DNI, etc.
• B2C: Business to ClientAlberga las identidades de los clientes o usuarios de una organización, asociados a un contrato de compra, la aceptación de términos legales de servicio o algo similar.
• B2B: Business to BusinessAlberga las identidades de las personas jurídicas o naturales en caso de representantes legales, asociados a un contrato entre dos organizaciones.

Según el nivel de digitalización de cada ámbito, hay que almacenar las identidades digitales de forma persistente y controlada. Debemos recordar que la identidad digital de una persona es el ancla de todas las acciones funcionales y posibles medidas de seguridad como la autenticación, autorización y auditoría.

Suele ser muy grave si existe la posibilidad de mezclar identidades digitales con las correspondientes personas - también llamado robo de identidad.
Es decir, el almacén de identidades o registro de usuarios es un sistema critico en todos los sentidos (funcional, seguridad, rendimiento, disponibilidad, etc.) y en todos los tipos de arquitecturas.

Por lo tanto es de vital importancia que se establezca y se asegure un proceso para el ciclo de vida de las identidades digitales: Alta, Baja, Modificación y Borrado.
En algunos casos es un proceso manual, encargado a personas concretas de una organización, como por ejemplo el alta o la baja de un empleado en el caso de identidades B2E gestionados por el departamento laboral.
En cambio, las identidades B2C tienen un muchos casos ya un ciclo de vida automatizado, dónde la misma persona natural crea su identidad digital en el ámbito B2C de una organización, sin la intervención de algún empleado de dicha organización.

En la práctica, se suelen emplear bases de datos especializadas y centralizadas para el acceso estructurado a una gran cantidad de registros y todo mediante un protocolo de acceso eficaz.
En la mayoría de los casos se emplearán sistemas LDAP o bases de datos genéricas, tanto SQL como noSQL.

¿Qué ocurre cuando la misma persona es empleado y cliente a la vez?

Hemos visto que las identidades digitales se crean por ámbito legal (p.ej. B2E, B2C y B2B). Puede ocurrir el caso que la misma persona natural es usuario en el ámbito B2E con una identidad (p.ej. correo electrónico corporativo) y usuario en el ámbito B2C con otra identidad (p.ej. correo electrónico privado).

Ahora depende del caso de uso y del objetivo de la organización: ¿La organización quiere saber que una acción del ámbito B2C y otra acción del ámbito B2E, fue ejecutado por la misma persona natural?

En el sector retail es común, que empleados (B2E) tengan descuentos para la compra de productos (B2C). En el sector financiero puede ser de obligación legal poder asociar las acciones de un usuario B2C cuando es a la vez empleado, p.ej. para evitar ventajas por información privilegiada.

Para poder asociar varias identidades de varios realms, tenemos dos opciones:

1. Mapear identidades entre realms
2. Centralizar la gestión de identidades

Cuando tenemos solo un almacén de identidades por realm, no es complicado establecer un mecanismo de sincronización y mapeo. El mapeo puede ser mediante atributos adicionales en ambos realms, añadiendo el identificador de un realm como atributo o credencial en el otro realm.

Pero cuando se trata de una organización grande como un grupo de empresas que actúa en varios sectores y en varios países, es muy probable que se requieran varios almacenes de identidades por realm por el simple hecho de la arquitectura técnica crecida durante años o décadas.

Y ahora se añade la gestión de acceso...

Sobre todo en los casos más avanzados de varios registros por realm, no hay que olvidar la importancia de la seguridad de acceso (autenticación, autorización y auditoría). Es decir, hay que gestionar también:

• Secretos y otras credenciales para la autenticación
• Atributos, grupos, roles, perfiles y permisos para la autorización
• Atributos de usuarios y datos de contexto para auditoría

Todas estas necesidades están directamente relacionadas con la identidad digital de cada usuario. Sobre todo el aspecto de autorización tiene un ciclo de vida muy delicado. Es decir, hay muchas aplicaciones evolucionando su funcionalidad y cambiando su modelo de autorización. Adicionalmente, hay muchas personas que cambian de rol, sobre todo en el realm B2E. Un cambio de rol u otro cambio organizativo, debe provocar un cambio de todos los permisos existentes en todas las aplicaciones existentes.

Si no se gestionan bien todos estos cambios relacionados con la identidad digital, las organizaciones  acaban con usuarios con muchos más permisos que los correspondientes a su rol, solo porque tienen mucha antigüedad.

Para controlar las identidades digitales y sus permisos en estos escenarios, se ha optado hasta ahora siempre por un sistema de gestión de identidades centralizado. Vamos a ver primero cómo funcionan estos sistemas de gestión de identidades centralizados.

Gestión de identidades centralizada

Cuando una organización quiere gestionar las identidades de múltiples realms y tomar control de los roles y permisos de cada usuario, suelen implantar un sistema de gestión de identidades (IDM).

En general estos sistemas de gestión de identidades implementan servicios con la siguiente funcionalidad:

• Modelado de la estructura de organización en forma de árbol.
• Modelado de las entidades, realms e identidades (meta-modelos con atributos, validaciones, valores por defecto, etc.)
• Modelado de roles que se asocian a las hojas del árbol organizativo.
• Configuración del almacén maestro de identidades (BBDD o servidores LDAP)
• Integración con almacenes de usuarios comunes (LDAP, BBDD SQL, ficheros CSV, etc.)
• Desarrollo de conectores personalizados de entrada y de salida (p.ej. tablas SQL específicas, formatos de fichero propietarios, etc.)
• Desarrollo de reglas de transformación para los roles definidos. Las reglas transforman las identidades maestras con sus roles a registros de usuarios con atributos y permisos en cada almacén de usuarios o sistema conectado mediante los conectores.
• Desarrollo de workflows de aprobación para la asignación de usuarios a roles dentro de una organización.
• Web Administración: Configuración y desarrollo de todo el modelo arriba indicado.
• Web Gestión: Bandeja de entrada para el trabajo con los flujos de aprobación de roles, altas, bajas y modificaciones.
• Web Usuarios: Los usuarios de cada realm pueden ver sus roles o solicitar nuevos permisos, modificar datos, darse de alta o de baja, etc.
• APIs y SDK para la mayoría de la funcionalidad.

Con un sistema de estas funcionalidades no se da de alta o se cambia ningún usuario en ningún almacén de usuarios si no ha sido a través del almacén maestro y los workflows del sistema de gestión de identidades.

Como ejemplo, vamos a ver cómo es el flujo de un alta de un empleado como desarrollador en una empresa de comercio electrónico.
Una persona del departamento laboral tiene el permiso para dar de alta o de baja un empleado en el sistema gestión de empleados (p.ej. SAP HR, Microsoft Dynamics HR). Este sistema de empleados está conectado mediante un conector de entrada con el sistema de gestión de identidades dónde un alta de usuario arranca un flujo asociado al tipo de empleado. El responsable del departamento destino del nuevo empleado recibe una notificación para entrar al sistema de gestión de identidades y asignar el nuevo empleado a un departamento de la organización que tiene asociado múltiples roles. Además puede asignarle a un proyecto o grupo de trabajo que también conlleva permisos en muchos sistemas y aplicaciones diferentes.
Como resultado del flujo, la identidad maestra del nuevo empleado provoca un cambio en los sistemas conectados a la gestión de identidades, dándole acceso y permisos, por ejemplo:

• Alta y acceso al correo corporativo
• Alta y acceso a la Intranet de empleados
• Alta y acceso a la VPN corporativa
• Alta y acceso a los repositorios de código del equipo de trabajo, p.ej. Github
• Alta y acceso a las nubes públicas y privadas del equipo de trabajo, p.ej. AWS, Azure, Openshift
• Alta como cliente en la tienda online de la empresa con descuentos asociados.

Todos estos cambios en los sistemas destino pueden ser completamente automatizados. Esta automatización puede incluir también los cambios del rol del empleado dentro de la organización. Es decir, el empleado solicita un cambio de departamento que otro compañero aprueba y que le asigna a otro rol dentro del gestor de identidades. Supongamos que el cambio es de técnico a gestión y los cambios ejecutados de forma automática serían:

• Cambio de firma del correo corporativo.
• Cambio de permisos en la Intranet.
• Cambio de visibilidades en la VPN.
• Baja en los respositorios de código fuente.
• Baja en las nubes públicas y privadas.
• Alta y acceso en la nube de CRM, p.ej. Salesforce CRM
• Alta y acceso en los sistemas de analítica BI y BigData, p.ej. Microsoft Power BI

El flujo de cambios puede llegar a ser completamente automatizado y auditado. Toda la lógica que se delega en el gestor de identidades tiene que integrarse en el ciclo de vida de la organización. Es decir, un cambio organizativo y estructural ya no es cambiar un organigrama y enviar un comunicado, sino una tarea para el equipo de desarrollo y mantenimiento del sistema de gestión de identidades.

¡Todo solucionado! o ¿Hay algún problema?

Una buena y eficaz gestión de identidades es necesario y razonable dentro de una organización. Pero existen aspectos de la identificación que puede convertirse en un problema:

• La privacidad de las personas
• Cambios de identidades cross-organización

Cuando queremos ejecutar medidas de seguridad, es imprescindible poder identificar a los actores dentro de un sistema. Pero si no queremos ejecutar medidas de seguridad, sino queremos analizar el comportamiento de los usuarios con objetivos ajenos a la protección, nos movemos en una dirección donde nos chocamos con la necesidad y el derecho a privacidad de los usuarios.

Para no entrar demasiado en detalle, vamos a tratar la privacidad como el deseo de una persona natural de decidir ella misma lo que es privado y lo que es público. Aunque si te interesa el tema, te recomiendo informarte aquí.

De lo que hablamos ocurre sobre todo en el ámbito del B2C dónde los usuarios entran en una relación contractual y un registro de su identidad, simplemente por visitar un sitio Web y con el único fin de ofrecernos publicidad.
En la Unión Europea se ha establecido este derecho de privacidad en forma del Reglamento General de Protección de Datos. En este reglamento se establece que los usuarios siguen siendo los propietarios de sus datos aunque otra organización los recoja y los guarde.

No estamos hablando de los atributos utilizados para mapear un usuario con su identidad digital, sino de los meta-datos que se producen con el uso de un servicio. Como los usuarios son - por temas legítimos de seguridad - debidamente identificados, una organización puede utilizar el audit trail de los usuarios para otros fines, ajenos a la seguridad. Esta práctica es omnipresente en la Web de hoy, ya que como no hay nada gratuito, todo lo que no cuesta se paga con nuestros datos. Sin embargo, los usuarios siguen teniendo el derecho de decidir lo que ocurre con sus datos.

Adicionalmente, si un usuario quiere cambiar de servicio o aplicación y moverse a otra organización con un servicio similar, es hoy en día prácticamente imposible que pueda mover sus datos fácilmente de un servicio a otro.
Para solucionarlo, habría que implantar un estándar de interoperabilidad entre todas las organizaciones lo que resulta prácticamente imposible de conseguir. Otra solución sería, centralizarlo en el lado de cada usuario y por lo tanto descentralizado. Esto es el enfoque de la gestión de identidades descentralizado.

La identidad descentralizada

Si queremos mover el control de una identidad digital al mismo usuario, hay que definir primero un formato interoperable de datos para permitir identificadores verificables descentralizados. Esta definición se está moviendo actualmente con el nombre de Decentralized identifiers o DIDs en un working group del W3C.
Luego hay que establecer una plataforma o framework para permitir la verificación de las identidades digitales por las organizaciones interesados en la identidad de una persona.

Todo este movimiento de control hacia el usuario, respetando su privacidad, se llama Self-sovereign identity o Identidad Soberana.

El camino hacia una Self-Sovereign Identity sigue en curso y existen varias iniciativas al respecto. Existe un buen articulo de Christopher Allen, llamado The Path to Self-Sovereign Identity, donde se enumeran diez principios de Self-Sovereign Identity que expongo aquí sin alterar ya que resultan muy esclarecedores:

• Existencia. Los usuarios deben tener una existencia independiente. Cualquier identidad autosoberana se basa en última instancia en el inefable "yo" que está en el corazón de la identidad. Nunca puede existir totalmente en forma digital. Este debe ser el núcleo del yo que se sostiene y apoya. Una identidad autosoberana simplemente hace públicos y accesibles algunos aspectos limitados del "yo" que ya existe.
• Control. Los usuarios deben controlar sus identidades. Sujeto a algoritmos bien entendidos y seguros que aseguren la continua validez de una identidad y sus reivindicaciones, el usuario es la máxima autoridad sobre su identidad. Siempre deben poder referirse a ella, actualizarla o incluso ocultarla. Deben poder elegir la celebridad o la privacidad como prefieran. Esto no significa que un usuario controle todas las reivindicaciones sobre su identidad: otros usuarios pueden hacer reivindicaciones sobre un usuario, pero no deben ser el centro de la identidad en sí.
• Acceso. Los usuarios deben tener acceso a sus propios datos. Un usuario siempre debe poder recuperar fácilmente todas las reivindicaciones y otros datos de su identidad. No debe haber datos ocultos ni guardianes. Esto no significa que un usuario pueda modificar necesariamente todas las reivindicaciones asociadas a su identidad, pero sí que debe ser consciente de ellas. Tampoco significa que los usuarios tengan igual acceso a los datos de otros, sólo a los suyos propios.
• Transparencia. Los sistemas y algoritmos deben ser transparentes. Los sistemas utilizados para administrar y operar una red de identidades deben ser abiertos, tanto en su funcionamiento como en su gestión y actualización. Los algoritmos deben ser libres, de código abierto, conocidos y lo más independientes posible de cualquier arquitectura particular; cualquiera debe poder examinar su funcionamiento.
• Persistencia. Las identidades deben ser duraderas. Preferiblemente, las identidades deben durar para siempre, o al menos tanto como el usuario desee. Aunque puede ser necesario rotar las claves privadas y cambiar los datos, la identidad permanece. En el mundo de Internet, que evoluciona rápidamente, este objetivo puede no ser del todo razonable, por lo que al menos las identidades deben durar hasta que hayan quedado obsoletas por los nuevos sistemas de identidad. Esto no debe contradecir el "derecho al olvido"; el usuario debe poder disponer de una identidad si así lo desea y las reivindicaciones deben modificarse o eliminarse según proceda con el tiempo. Para ello se requiere una firme separación entre una identidad y sus reivindicaciones: no se pueden atar para siempre.
• Portabilidad. La información y los servicios sobre la identidad deben ser transportables. Las identidades no deben estar en poder de una entidad tercera singular, aunque sea una entidad de confianza de la que se espera que funcione en el mejor interés del usuario. El problema es que las entidades pueden desaparecer, y en Internet, la mayoría de ellas finalmente lo hacen. Los regímenes pueden cambiar, los usuarios pueden trasladarse a diferentes jurisdicciones. Las identidades transportables aseguran que el usuario siga teniendo el control de su identidad pase lo que pase, y también pueden mejorar la persistencia de una identidad a lo largo del tiempo.
• Interoperabilidad. Las identidades deben ser tan ampliamente utilizables como sea posible. Las identidades tienen poco valor si sólo funcionan en nichos limitados. El objetivo de un sistema de identidad digital del siglo XXI es lograr que la información sobre la identidad esté ampliamente disponible, cruzando las fronteras internacionales para crear identidades mundiales, sin perder el control del usuario. Gracias a la persistencia y la autonomía, estas identidades ampliamente disponibles pueden entonces estar continuamente disponibles.
• Consentimiento. Los usuarios deben aceptar el uso de su identidad. Todo sistema de identidad se construye en torno a compartir esa identidad y sus reivindicaciones, y un sistema interoperable aumenta la cantidad de intercambio que se produce. Sin embargo, el intercambio de datos sólo debe tener lugar con el consentimiento del usuario. Aunque otros usuarios, como un empleador, una oficina de crédito o un amigo, puedan presentar reclamaciones, el usuario debe ofrecer su consentimiento para que éstas sean válidas. Tenga en cuenta que este consentimiento puede no ser interactivo, pero aún así debe ser deliberado y bien entendido.
• Minimización. La divulgación de las reclamaciones debe reducirse al mínimo. Cuando se divulguen datos, esa divulgación debe entrañar la cantidad mínima de datos necesaria para cumplir la tarea en cuestión. Por ejemplo, si sólo se pide una edad mínima, no se debe revelar la edad exacta, y si sólo se pide una edad, no se debe revelar la fecha de nacimiento más precisa. Este principio puede apoyarse con una divulgación selectiva, pruebas de rango y otras técnicas de conocimiento cero, pero la no correlación sigue siendo una tarea muy difícil (tal vez imposible); lo mejor que podemos hacer es utilizar la minimización para apoyar la privacidad de la mejor manera posible.
• Protección. Hay que proteger los derechos de los usuarios. Cuando hay un conflicto entre las necesidades de la red de identidad y los derechos de los usuarios individuales, la red debe errar en el lado de la preservación de las libertades y derechos de los individuos sobre las necesidades de la red. Para garantizar esto, la autenticación de la identidad debe realizarse mediante algoritmos independientes que sean resistentes a la censura y a la fuerza y que se ejecuten en un

Traducción: DeepL

Cabe resaltar que el enfoque de la identidad soberana es que el propio usuario decide en todo momento lo que ocurre con sus datos. Es decir, quién tiene acceso a qué información, en qué momento y durante cuánto tiempo.
Incluso se puede llegar a implementar un mecanismo de conocimiento cero dónde se puede demostrar el conocimiento de un dato sin tener que revelar el dato. Ver también ZKProof Standards.

A nivel europeo se está trabajando en el European Self-Sovereign Identity Framework o ESSIF que sea a la vez compatible con el reglamento europeo de electronic IDentification, Authentication and trust Services o eIDAS.

El European Self-Sovereign Identity Framework intenta resolver los siguientes problemas:

• Adquisición y mantenimiento de datos
• Procesamiento de datos
• Silos de datos
• Falta de control de datos
• Problemas de privacidad
• Falta de universalidad
• Falta de interoperabilidad
• Limitaciones del eIDAS
• Falta de certificaciones

Fuente: SSI Meetup - Understanding the European Self-Sovereign Identity Framework (ESSIF)

Para los que quieran entrar más en detalle del ESSIF, recomiendo la lectura de la visión y de la referencia de conceptos de arquitectura.

Por el otro lado existe una plataforma de identidad soberana en EEUU llamado sovrin. En este caso se trata de una organización sin ánimo de lucro que da un servicio de gestionar tu identidad de forma soberana. La identidad en si es gratuita, pero la definición de atributos o credenciales sí que cuesta.

Vemos que el tema del Self-Sovereign Identity sigue siendo un tema de investigación y habrá que seguir el desarrollo de este tipo de iniciativas.

Conclusión

Hemos entrado un poco en detalle de la identidad digital como base de todas las interacciones con el mundo digital, cada vez más presente e imprescindible.
Hay que tener en cuenta que el tema de la gestión de identidades no ha terminado aún y que estamos envueltos en el proceso de reencuentro de poderes entre administraciones estatales, empresas globales y las personas como individuos.