Consideraciones de arquitectura para la identidad en una solución multiinquilino

La identidad es un aspecto importante de cualquier solución multiinquilino. Los componentes de identidad de su aplicación son responsables de lo siguiente:

• Comprobación de quién es un usuario (autenticación).
• Aplicar los permisos del usuario dentro del ámbito de un inquilino (autorización).

Es posible que sus clientes también deseen autorizar a las aplicaciones externas a acceder a sus datos o a integrarlos en su solución. La identidad de un usuario determina a qué información accederá un usuario o servicio. Es importante que tenga en cuenta sus requisitos de identidad para aislar la aplicación y los datos entre inquilinos.

Antes de definir una estrategia de identidad multiinquilino, primero debe tener en cuenta los requisitos de identidad de alto nivel del servicio, incluidos los siguientes:

• ¿Se usarán identidades de usuario o carga de trabajo para acceder a una sola aplicación o a varias aplicaciones dentro de una familia de productos? Por ejemplo, una familia de productos comerciales podría tener una aplicación de punto de venta y una aplicación de administración de inventario que comparten la misma solución de identidad.
• ¿Tiene pensado implementar la autenticación y autorización modernas, como OAuth2 y OpenID Connect?
• ¿La solución solo proporciona autenticación a las aplicaciones basadas en la interfaz de usuario? O bien, ¿también proporciona acceso de API a sus inquilinos y a terceros?
• ¿Los inquilinos tendrán que federarse en su propio IdP y será necesario admitir varios proveedores de identidades diferentes para cada inquilino? Por ejemplo, puede tener inquilinos con Microsoft Entra ID, Auth0 y Servicios de federación de Active Directory (AD FS), donde cada uno desea federarse con su solución. También debe comprender qué protocolos de federación de los IdP de los inquilinos va a admitir, ya que los protocolos influyen en los requisitos de su propio IdP.
• ¿Hay requisitos de cumplimiento específicos que deben cumplir, como RGPD?
• ¿Sus inquilinos requieren que su información de identidad se encuentre dentro de una región geográfica específica?
• ¿Los usuarios de su solución requieren acceso a los datos de un inquilino o de varios inquilinos dentro de su aplicación? ¿Necesitan la capacidad de alternar rápidamente entre inquilinos o ver información consolidada de varios inquilinos? Por ejemplo, los usuarios que han iniciado sesión en Azure Portal pueden alternar fácilmente entre diferentes suscripciones y directorios de Microsoft Entra ID a los que tienen acceso.

Cuando haya establecido los requisitos de alto nivel, puede empezar a planificar detalles y requisitos más específicos, como los orígenes de los directorios de usuarios y los flujos de registro o inicio de sesión.

Directorio de identidades

Para que una solución multiinquilino autentique y autorice a un usuario o servicio, necesita un lugar para almacenar información de identidad. Un directorio puede incluir registros autoritativos para cada identidad o puede contener referencias a identidades externas que están almacenadas en el directorio de otro proveedor de identidades.

Al diseñar un sistema de identidades para su solución multiinquilino, debe tener en cuenta cuáles de los siguientes tipos de IdP podrían necesitar los inquilinos y los clientes:

• Proveedor de identidades local. Un proveedor de identidades local permite a los usuarios registrarse por sí mismos en el servicio. Los usuarios proporcionan un nombre de usuario, una dirección de correo electrónico o un identificador, como un número de tarjeta de puntos. También proporcionan una credencial, como una contraseña. El IdP almacena tanto el identificador de usuario como las credenciales.
• Proveedor de identidades sociales. Un proveedor de identidades sociales permite a los usuarios usar una identidad que tengan en una red social u otro proveedor de identidades público, como Facebook, Google o una cuenta personal de Microsoft.
• Use el directorio Microsoft Entra ID del inquilino. Puede que los inquilinos ya tengan su propio directorio de Microsoft Entra ID y es posible que quieran que su solución use su directorio como IdP para acceder a su solución. Este enfoque es posible cuando la solución se compila como una aplicación de Microsoft Entra multiinquilino.
• Federación con el proveedor de identidades de un inquilino. Los inquilinos podrían tener su propio IdP, distinto de Microsoft Entra ID, y es posible que quieran que la solución se federe con él. La federación facilita experiencias de inicio de sesión único (SSO) y permite a los inquilinos administrar el ciclo de vida y las directivas de seguridad de sus usuarios, independientemente de la solución.

Debe tener en cuenta si los inquilinos necesitan admitir varios proveedores de identidades. Por ejemplo, es posible que tenga que admitir identidades locales, identidades sociales e identidades federadas, todas dentro de un solo inquilino. Este requisito es habitual cuando las empresas usan una solución tanto para sus propios empleados como para los contratistas. Pueden usar la federación para el acceso de sus propios empleados a la solución, al mismo tiempo que permiten el acceso a los contratistas o a los usuarios invitados, que no tienen una cuenta en el IdP federado.

Almacenamiento de la información de autenticación y autorización de inquilinos

En una solución multiinquilino, debe tener en cuenta dónde almacenar los distintos tipos de información de identidad, incluidos los siguientes:

• Detalles sobre las cuentas de usuario y servicio, incluidos sus nombres y otra información que requieren los inquilinos.
• Información necesaria para autenticar de forma segura a los usuarios, incluida la información necesaria para proporcionar autenticación multifactor (MFA).
• Información específica del inquilino, como roles y permisos de inquilino. Esta información se usa para la autorización.

Tenga en cuenta las siguientes opciones para almacenar información de identidad:

• Almacene toda la información de identidad y autorización en el directorio IdP y compártala entre varios inquilinos.
• Almacene las credenciales de usuario en el directorio IdP y almacene la información de autorización en la capa de aplicación, junto con la información del inquilino.

Determinación del número de identidades de un usuario

Es habitual que las soluciones multiinquilino permitan a un usuario o identidad de carga de trabajo acceder a la aplicación y a los datos de varios inquilinos. Considere si este enfoque es necesario para su solución. En ese caso, debe tener en cuenta las siguientes cuestiones:

• ¿Debe crear una identidad de usuario única para cada persona o crear identidades independientes para cada combinación de inquilino-usuario?
  • Siempre que sea posible, es mejor usar una única identidad para cada persona. Resulta difícil administrar varias cuentas de usuario, tanto para usted como proveedor de soluciones, como para sus usuarios. Además, muchas de las protecciones inteligentes contra amenazas que ofrece un IdP moderno se basan en que cada persona tiene una sola cuenta de usuario.
  • Sin embargo, en algunas situaciones, podría ser necesario que un usuario tenga varias identidades distintas. Por ejemplo, si los usuarios usan su sistema para fines profesionales y personales, es posible que quieran separar sus cuentas de usuario. O bien, si sus inquilinos tienen requisitos estrictos de almacenamiento de datos normativos o geográficos, es posible que requieran que una persona tenga varias identidades para poder cumplir con la normativa o las leyes.
• Si usa identidades por inquilino, evite almacenar las credenciales varias veces. Los usuarios deben tener sus credenciales almacenadas en una sola identidad y debe usar características como las identidades de invitado para hacer referencia a las mismas credenciales de usuario desde los registros de identidad de varios inquilinos.

Conceder a los usuarios acceso a los datos de inquilino

Considere cómo se asignarán los usuarios a un inquilino. Por ejemplo, durante el proceso de registro, puede usar un código de invitación único que introduzcan la primera vez que accedan a un inquilino. En algunas soluciones, puede usar el nombre de dominio de las direcciones de correo electrónico de registro de los usuarios como una manera de identificar el inquilino al que pertenecen. O bien, puede usar otro atributo del registro de identidad del usuario para asignar el usuario a un inquilino. A continuación, debe almacenar la asignación en función de los identificadores únicos inmutables subyacentes, tanto para el inquilino como para el usuario.

Si su solución está diseñada para que un único usuario solo acceda a los datos de un único inquilino, tenga en cuenta las siguientes decisiones:

• ¿Cómo detecta el IdP a qué inquilino accede un usuario?
• ¿Cómo comunica el IdP el identificador de inquilino a la aplicación? Normalmente, se agrega una notificación de identificador de inquilino al token.

Si un solo usuario necesita tener acceso a varios inquilinos, debe tener en cuenta las siguientes decisiones:

• ¿Cómo identifica y concede la solución permisos a un usuario que tiene acceso a varios inquilinos? Por ejemplo, ¿un usuario podría ser administrador en un inquilino de entrenamiento y tener acceso de solo lectura a un inquilino de producción? O bien, ¿podría tener inquilinos independientes para distintos departamentos de una organización, pero necesita mantener identidades de usuario coherentes en todos los inquilinos?
• ¿Cómo alterna un usuario entre inquilinos?
• Si usa identidades de carga de trabajo, ¿cómo especifica una identidad de carga de trabajo el inquilino al que necesita acceder?
• ¿Hay información específica del inquilino almacenada en el registro de identidad del usuario que podría filtrar información entre inquilinos? Por ejemplo, supongamos que un usuario se registró con una identidad social y se le concede acceso a dos inquilinos. El inquilino A enriqueció la identidad del usuario con más información. ¿El inquilino B debería tener acceso a la información enriquecida?

Proceso de registro de usuario para identidades locales o identidades sociales

Es posible que algunos inquilinos necesiten permitir que los usuarios se registren para obtener una identidad en su solución. El registro de autoservicio puede ser necesario si no se requiere la federación con el proveedor de identidades del inquilino. Si se necesita un proceso de registro de autoservicio, debe tener en cuenta las siguientes cuestiones:

• ¿Desde qué orígenes de identidades pueden registrarse los usuarios? Por ejemplo, ¿un usuario puede crear una identidad local y usar también un proveedor de identidades sociales?
• Si solo se permiten identidades locales, ¿solo se permitirán dominios de correo electrónico específicos? Por ejemplo, ¿puede un inquilino especificar que solo puedan registrarse los usuarios que tengan una dirección de correo electrónico @contoso.com?
• ¿Cuál es el nombre principal de usuario (UPN) que se debe usar para identificar de forma única cada identidad local durante el proceso de inicio de sesión? Por ejemplo, una dirección de correo electrónico, un nombre de usuario, un número de teléfono y un número de tarjeta de puntos son opciones habituales para los UPN. Sin embargo, los UPN pueden cambiar con el tiempo. Cuando haga referencia a la identidad en las reglas de autorización o los registros de auditoría de la aplicación, se recomienda usar el identificador único inmutable subyacente de la identidad. Microsoft Entra ID proporciona un identificador de objeto (OID), que es un identificador inmutable.
• ¿Será necesario que un usuario compruebe su nombre UPN? Por ejemplo, si la dirección de correo electrónico o el número de teléfono del usuario se usan como UPN, ¿cómo comprobará que la información es precisa?
• ¿Los administradores de inquilinos necesitan aprobar los registros?
• ¿Los inquilinos requieren una experiencia de registro o una dirección URL específicas del inquilino? Por ejemplo, ¿los inquilinos requieren una experiencia de registro con marca cuando los usuarios se registran? ¿Los inquilinos requieren la capacidad de interceptar una solicitud de registro y realizar una validación adicional antes de continuar?

Acceso al inquilino para usuarios de registro de autoservicio

Cuando a los usuarios se les permite registrarse para obtener una identidad, normalmente debe haber un proceso para que se les conceda acceso a un inquilino. El flujo de registro puede incluir un proceso de concesión de acceso o puede automatizarse en función de la información sobre los usuarios, como sus direcciones de correo electrónico. Es importante planificar este proceso y tener en cuenta las siguientes cuestiones:

• ¿Cómo determinará el flujo de registro que un usuario debe tener acceso a un inquilino específico?
• Si los usuarios ya no deben tener acceso a un inquilino, ¿la solución revocará automáticamente su acceso? Por ejemplo, cuando los usuarios abandonan una organización, debe haber un proceso manual o automatizado que quite su acceso del inquilino.
• ¿Necesita proporcionar una manera de que los inquilinos auditen a los usuarios que tienen acceso a sus inquilinos y sus permisos?

Administración automatizada del ciclo de vida de las cuentas

Un requisito común para los clientes corporativos o empresariales de una solución es un conjunto de características que les permita automatizar la incorporación y retirada de las cuentas. Los protocolos abiertos, como System for Cross-domain Identity Management (SCIM), proporcionan un enfoque estándar del sector para la automatización. Este proceso automatizado normalmente incluye no solo la creación y eliminación de registros de identidad, sino también la administración de permisos de inquilino. Tenga en cuenta las siguientes cuestiones cuando implemente la administración automatizada del ciclo de vida de las cuentas en una solución multiinquilino:

• ¿Los clientes necesitan configurar y administrar un proceso de ciclo de vida automatizado por inquilino? Por ejemplo, cuando se incorpora un usuario, es posible que tenga que crear la identidad en varios inquilinos de su aplicación, donde cada inquilino tiene un conjunto diferente de permisos.
• ¿Necesita implementar SCIM, o en su lugar puede proporcionar federación de inquilinos para mantener el origen de verdad para los usuarios bajo el control del inquilino, en lugar de administrar usuarios locales?

Proceso de autenticación del usuario

Cuando un usuario inicia sesión en una aplicación multiinquilino, su sistema de identidad autentica al usuario. Al planificar el proceso de autenticación, debe tener en cuenta las siguientes cuestiones:

• ¿Los inquilinos deben configurar sus propias directivas de autenticación multifactor (MFA)? Por ejemplo, si sus inquilinos están en el sector de servicios financieros, deben implementar directivas de MFA estrictas, mientras que un pequeño comercio en línea podría no tener los mismos requisitos.
• ¿Los inquilinos deben configurar sus propias reglas de acceso condicional? Por ejemplo, es posible que los distintos inquilinos necesiten bloquear los intentos de inicio de sesión desde regiones geográficas específicas.
• ¿Los inquilinos deben personalizar el proceso de inicio de sesión para cada inquilino? Por ejemplo, ¿necesita mostrar un logotipo de cliente? O bien, ¿es necesario extraer información sobre cada usuario de otro sistema, como un número de puntos, y devolverla al proveedor de identidades para que la añada al perfil del usuario?
• ¿Los usuarios necesitan suplantar a otros usuarios? Por ejemplo, un miembro del equipo de soporte técnico podría querer investigar un problema que tiene otro usuario suplantando su cuenta de usuario sin tener que autenticarse como tal.
• ¿Los usuarios necesitan obtener acceso a las API de la solución? Por ejemplo, los usuarios o las aplicaciones de terceros podrían tener que llamar directamente a sus API para ampliar su solución, sin una interfaz de usuario que proporcione un flujo de autenticación.

Identidades de cargas de trabajo

En la mayoría de las soluciones, una identidad suele representar a un usuario. Algunos sistemas multiinquilino también permiten que las identidades de la carga de trabajo sean utilizadas por los servicios y las aplicaciones para obtener acceso a los recursos de su aplicación. Por ejemplo, es posible que sus inquilinos necesiten acceder a una API proporcionada por su solución para que puedan automatizar algunas de sus tareas de administración.

Las identidades de carga de trabajo son similares a las identidades de usuario, pero normalmente requieren métodos de autenticación diferentes, como claves o certificados. Las identidades de carga de trabajo no usan MFA. En su lugar, las identidades de carga de trabajo suelen requerir otros controles de seguridad, como la renovación periódica de las claves y la caducidad de los certificados.

Si sus inquilinos esperan poder habilitar el acceso a la identidad de carga de trabajo en su solución multiinquilino, debe tener en cuenta las siguientes cuestiones:

• ¿Cómo se crearán y administrarán las identidades de carga de trabajo en cada inquilino?
• ¿Cómo se limitarán las solicitudes de identidad de carga de trabajo al inquilino?
• ¿Necesita limitar el número de identidades de carga de trabajo creadas por cada inquilino?
• ¿Necesita proporcionar controles de acceso condicional en las identidades de carga de trabajo para cada inquilino? Por ejemplo, un inquilino podría querer limitar la autenticación de una identidad de carga de trabajo desde fuera de una región específica.
• ¿Qué controles de seguridad proporcionará a los inquilinos para asegurarse de que las identidades de carga de trabajo se mantienen seguras? Por ejemplo, la renovación automática de claves, la caducidad de claves, la caducidad de certificados y la supervisión del riesgo de inicio de sesión son métodos para reducir el riesgo de que una identidad de carga de trabajo pueda ser utilizada indebidamente.

Federación con un proveedor de identidades para el inicio de sesión único (SSO)

Los inquilinos, que ya tienen sus propios directorios de usuario, pueden querer que su solución se federe en sus directorios. La federación permite que su solución use las identidades de su directorio en lugar de administrar otro directorio con identidades distintas.

La federación es especialmente importante cuando algunos inquilinos desean especificar sus propias directivas de identidad o para habilitar experiencias de inicio de sesión único (SSO).

Si quiere que los inquilinos se federen con su solución, debe tener en cuenta las cuestiones siguientes:

• ¿Cuál es el proceso para configurar la federación de un inquilino? ¿Los inquilinos pueden configurar la federación por sí mismos o el proceso requiere la configuración manual y el mantenimiento por parte de su equipo?
• ¿Qué protocolos de federación admitirá?
• ¿Qué procesos están implementados para asegurarse de que la federación no se puede configurar de forma incorrecta para conceder acceso a otro inquilino?
• ¿Es necesario federar el proveedor de identidades de un solo inquilino a más de un inquilino en su solución? Por ejemplo, si los clientes tienen un inquilino de entrenamiento y otro de producción, es posible que deban federar el mismo proveedor de identidades a ambos inquilinos.

Modelos de autorización

Decida el modelo de autorización que tenga más sentido para su solución. Estos son dos enfoques de autorización habituales:

• Autorización basada en roles. Los usuarios se asignan a roles. Algunas características de la aplicación están restringidas a roles específicos. Por ejemplo, un usuario con rol de administrador puede realizar cualquier acción, mientras que un usuario con un rol inferior podría tener un subconjunto de permisos en el sistema.
• Autorización basada en recursos. Su solución proporciona un conjunto de recursos distintos, cada uno de los cuales tiene su propio conjunto de permisos. Un usuario específico podría ser un administrador de un recurso y no tener acceso a otro recurso.

Estos modelos son distintos, y el enfoque que seleccione afectará a su implementación y a la complejidad de las directivas de autorización que puede aplicar.

Derechos y licencias

En algunas soluciones puede usar licencias por usuario como parte del modelo de precios comerciales. Proporcionaría diferentes niveles de licencias de usuario con distintas funcionalidades. Por ejemplo, los usuarios con una licencia podrían usar un subconjunto de las características de la aplicación. Las funcionalidades a las que pueden acceder usuarios específicos, en función de sus licencias, a veces se denominan derechos.

Aunque la supervisión y la aplicación de derechos es similar a la autorización, normalmente se controla mediante el código de aplicación o mediante un sistema de derechos dedicados, en lugar de ser administrado por el sistema de identidad.

Escala de identidades y volumen de autenticación

A medida que aumentan las soluciones multiinquilino, aumenta el número de usuarios y solicitudes de inicio de sesión que la solución debe procesar. Debe tener en cuenta las siguientes cuestiones:

• ¿El directorio de usuarios se escalará al número de usuarios necesarios?
• ¿El proceso de autenticación controlará el número esperado de inicios de sesión y registros?
• ¿Habrá picos que el sistema de autenticación no pueda controlar? Por ejemplo, a las 9:00 PST, todos los usuarios de la región occidental de Estados Unidos podrían empezar a trabajar e iniciar sesión en su solución, provocando un pico de solicitudes de inicio de sesión. Estas situaciones a veces se denominan tormentas de inicio de sesión.
• ¿La carga alta en otras partes de la solución afecta al rendimiento del proceso de autenticación? Por ejemplo, si su proceso de autenticación requiere llamar a una API de nivel de aplicación, ¿un elevado número de solicitudes de autenticación provocará problemas en el resto de la solución?
• ¿Qué ocurrirá si su IdP deja de estar disponible? ¿Hay un servicio de autenticación de copia de seguridad que pueda asumir el control para proporcionar continuidad empresarial, mientras el IdP no está disponible?

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

• John Downs | Ingeniero principal de software
• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

Otros colaboradores:

• Jelle Druyts | Ingeniero de clientes principal, FastTrack for Azure
• Landon Pierce | Ingeniero sénior de clientes
• Sander van den Hoven | Creador sénior de estrategias de tecnología de asociados
• Nick Ward | Arquitecto sénior de soluciones en la nube

Pasos siguientes

Revise Enfoques de arquitectura para identidad en soluciones multiinquilino.