Share via

Enfoques de arquitectura para identidad en soluciones multiinquilino

  • Artículo

Casi todas las soluciones multiinquilino requieren un sistema de identidad. En este artículo se describen los componentes comunes de la identidad, incluidas la autenticación y la autorización, y se describe cómo se pueden aplicar estos componentes en una solución multiinquilino.

Nota:

Revise las consideraciones de arquitectura para la identidad en una solución multiinquilino para obtener más información sobre los requisitos y las decisiones clave que debe tomar antes de empezar a crear un sistema de identidad para una solución multiinquilino.

Authentication

La autenticación es el proceso por el que se establece la identidad de un usuario. Al compilar una solución multiinquilino, hay consideraciones y enfoques especiales para varios aspectos del proceso de autenticación.

Federación

Es posible que tenga que federarse con otros proveedores de identidades (IdP). La federación se puede usar para habilitar los escenarios siguientes:

  • Inicio de sesión social, como permitir que los usuarios usen su cuenta de Google, Facebook, GitHub o Microsoft personal.
  • Directorios específicos para inquilinos, por ejemplo, permitiendo que los inquilinos federen su aplicación con sus propios proveedores de identidades, para que no tengan que administrar cuentas en varios lugares.

Para obtener información general sobre la federación, consulte el Patrón Federated Identity.

Si decide admitir proveedores de identidades específicos para el inquilino, asegúrese de aclarar qué servicios y protocolos necesita admitir. Por ejemplo, ¿admitirá el protocolo OpenID Connect y el protocolo de Lenguaje de marcado de aserción de seguridad (SAML)? O bien, ¿solo admitirá la federación con instancias de Microsoft Entra?

Al implementar cualquier proveedor de identidades, tenga en cuenta cualquier escala y límite que se puedan aplicar. Por ejemplo, si usa Azure Active Directory (Azure AD) B2C como proveedor de identidades propio, es posible que tenga que implementar directivas personalizadas para federarse con determinados tipos de proveedores de identidades de inquilino. Azure AD B2C limita el número de directivas personalizadas que puede implementar, lo que podría limitar el número de proveedores de identidades específicos del inquilino con los que puede federarse.

También puede considerar la posibilidad de ofrecer la federación como una característica que solo se aplique a los clientes de un nivel de producto superior.

Inicio de sesión único

Las experiencias de inicio de sesión único permiten a los usuarios alternar entre aplicaciones de forma fluida, sin que se les pida que vuelvan a autenticarse en cada punto.

Cuando los usuarios visitan una aplicación, la aplicación los dirige a un IdP. Si el IdP ve que tienen una sesión existente, emite un nuevo token sin necesidad de que los usuarios interactúen con el proceso de inicio de sesión. Un modelo de identidad federada admite experiencias de inicio de sesión único, ya que permite a los usuarios usar una sola identidad en varias aplicaciones.

En una solución multiinquilino, también puede habilitar otra forma de inicio de sesión único. Si los usuarios tienen autorización para trabajar con los datos de varios inquilinos, es posible que tenga que ofrecer una experiencia fluida cuando los usuarios cambien su contexto de un inquilino a otro. Considere si necesita admitir transiciones fluidas entre inquilinos y, si es así, si su proveedor de identidades necesita volver a emitir tokens con notificaciones de inquilino específicas. Por ejemplo, un usuario que ha iniciado sesión en Azure Portal puede alternar entre distintos directorios de Microsoft Entra, lo que provoca la reautenticación y vuelve a emitir el token de la instancia de Microsoft Entra recién seleccionada.

Evaluación del riesgo de inicio de sesión

Las plataformas de identidad modernas admiten una evaluación de riesgos durante el proceso de inicio de sesión. Por ejemplo, si un usuario inicia sesión desde una ubicación o dispositivo poco habitual, el sistema de autenticación podría requerir comprobaciones de identidad adicionales, como la autenticación multifactor (MFA), antes de permitir que la solicitud de inicio de sesión siga adelante.

Considere si los inquilinos pueden tener diferentes directivas de riesgo que deban aplicarse durante el proceso de autenticación. Por ejemplo, si tiene algunos inquilinos en un sector muy regulado, podrían tener perfiles de riesgo y requisitos diferentes a los de los inquilinos que trabajan en entornos menos regulados. O bien, puede optar por permitir que los inquilinos con planes de tarifa superiores especifiquen directivas de inicio de sesión más restrictivas que los inquilinos que compran un nivel inferior del servicio.

Si necesita admitir diferentes directivas de riesgo para cada inquilino, el sistema de autenticación debe saber en qué inquilino inicia sesión el usuario, de modo que pueda aplicar las directivas correctas.

Si el IdP incluye estas funcionalidades, considere la posibilidad de usar las características nativas de evaluación de riesgos de inicio de sesión del IdP. Estas características pueden ser complejas y propensas a errores si las implementa usted mismo.

Como alternativa, si federa a los propios proveedores de identidades de los inquilinos, se pueden aplicar sus propias directivas de mitigación de inicio de sesión de riesgo, y ellos pueden controlar las directivas y los controles que deben aplicarse. Sin embargo, es importante evitar agregar accidentalmente una carga innecesaria al usuario, como por ejemplo requiriendo dos desafíos de MFA: uno del proveedor de identidades de origen del usuario y otro del suyo propio. Asegúrese de comprender cómo interactúa la federación con cada uno de los proveedores de identidades de los inquilinos y con las directivas que han aplicado.

Suplantación

La suplantación permite a un usuario asumir la identidad de otro usuario sin usar las credenciales de ese usuario.

En general, la suplantación es peligrosa y puede ser difícil de implementar y controlar. Sin embargo, en algunos escenarios, la suplantación es un requisito. Por ejemplo, si opera software como servicio (SaaS), es posible que el personal del departamento de soporte técnico deba asumir la identidad de un usuario para poder iniciar sesión como tal y solucionar un problema.

Si decide implementar la suplantación, considere cómo auditar su uso. Asegúrese de que los registros incluyan tanto el usuario real que realizó la acción como el identificador del usuario suplantado.

Algunas plataformas de identidad admiten la suplantación, ya sea como una característica integrada o mediante código personalizado. Por ejemplo, en Azure AD B2C, puede agregar una notificación personalizada para el id. de usuario suplantado, o bien, puede sustituir la notificación del identificador de usuario en los tokens que se emiten.

Authorization

La autorización es el proceso de determinar lo que un usuario puede hacer.

Los datos de autorización se pueden almacenar en varios lugares, incluidas las siguientes ubicaciones:

  • En su proveedor de identidades. Por ejemplo, si usa Microsoft Entra ID como proveedor de identidades, puede usar características como los roles de aplicación y los grupos para almacenar la información de autorización. Después, la aplicación puede usar las notificaciones de token asociadas para aplicar las reglas de autorización.
  • En la aplicación, Puede crear su propia lógica de autorización y, a continuación, almacenar información sobre lo que cada usuario puede hacer en una base de datos o en un sistema de almacenamiento similar. Después, puede diseñar controles específicos para la autorización de nivel de recurso o basada en roles.

En la mayoría de las soluciones multiinquilino, la asignación de roles y permisos es gestionada por el arrendatario o cliente, no por usted como proveedor del sistema multiinquilino.

Para más información, vea Roles de aplicación.

Adición de información sobre la identidad y el rol del inquilino a los tokens

Tenga en cuenta qué parte, o partes, de la solución deben realizar solicitudes de autorización, incluida la determinación de si un usuario está autorizado a trabajar con datos de un inquilino específico.

Un enfoque común es que el sistema de identidad inserte una notificación de identificador de inquilino en un token. Este enfoque permite a la aplicación inspeccionar la notificación y comprobar que los usuarios están trabajando con el inquilino al que se les permite acceder. Si usa el modelo de seguridad basado en roles, puede optar por ampliar el token con información sobre el rol que tiene un usuario en el inquilino.

Sin embargo, si un único usuario puede acceder a varios inquilinos, es posible que necesite una manera de que los usuarios indiquen con qué inquilino tienen intención de trabajar durante el proceso de inicio de sesión. Después de seleccionar su inquilino activo, el IdP puede incluir la notificación del identificador del inquilino correcto y el rol para ese inquilino dentro del token que emite. También debe tener en cuenta cómo los usuarios pueden alternar entre inquilinos, lo que requiere emitir un nuevo token.

Autorización basada en aplicaciones

Un enfoque alternativo consiste en hacer que el sistema de identidad sea independiente de los identificadores y roles de inquilino. Los usuarios se identifican con sus credenciales o con una relación de federación, y los tokens no incluyen una notificación de identificador de inquilino. En una lista o base de datos independiente se indica qué usuarios tienen acceso a cada inquilino. A continuación, la capa de aplicación puede comprobar si el usuario especificado debe tener permiso para acceder a los datos de un inquilino específico, en función de la búsqueda en esa lista.

Uso de Microsoft Entra ID o Azure AD B2C

Microsoft proporciona Microsoft Entra ID y Azure AD B2C, que son plataformas de identidad administrada que puede usar en su propia solución multiinquilino.

Muchas soluciones multiinquilino son software como servicio (SaaS). La elección de si usar Microsoft Entra ID o Azure AD B2C depende, en parte, de cómo defina los inquilinos o la base de clientes.

Para obtener más información, consulte Consideraciones sobre el uso de Azure Active Directory B2C en una arquitectura multiinquilino.

Antipatrones que se deben evitar

Compilación o ejecución de su propio sistema de identidad

La compilación de una plataforma de identidad moderna es compleja. Hay una serie de protocolos y estándares que admitir, y es fácil implementar incorrectamente un protocolo y exponer una vulnerabilidad de seguridad. Los estándares y los protocolos cambian, y también debe actualizar continuamente el sistema de identidad para mitigar los ataques y admitir características de seguridad recientes. También es importante asegurarse de que un sistema de identidad sea resistente, ya que cualquier tiempo de inactividad puede tener consecuencias graves para el resto de la solución. Además, en la mayoría de los casos, la implementación de un proveedor de identidades no agrega una ventaja a la empresa y es simplemente una parte necesaria de la implementación de un servicio multiinquilino. Es mejor usar en su lugar un sistema de identidad especializado creado, operado y protegido por expertos.

Al ejecutar un sistema de identidad propio, es necesario almacenar hashes de contraseña u otras formas de credenciales que se convierten en un objetivo tentador para los atacantes. Incluso las contraseñas de hash y sal suelen ofrecer una protección insuficiente, ya que la capacidad de cálculo de la que disponen los atacantes puede hacer que se comprometan estas formas de credenciales.

Cuando ejecuta un sistema de identidad, también tiene la responsabilidad de generar y distribuir códigos de MFA o contraseñas de un solo uso (OTP). Estos requisitos significan que necesita un mecanismo para distribuir estos códigos mediante SMS o correo electrónico. Además, es responsable de detectar ataques dirigidos y por fuerza bruta, intentos de inicio de sesión de limitación, auditoría, etc.

En lugar de compilar o ejecutar su propio sistema de identidades, se recomienda usar un servicio o componente comercial. Por ejemplo, considere la posibilidad de usar Microsoft Entra ID o Azure AD B2C, que son plataformas de identidad administrada. Los proveedores de plataformas de identidad administrada tienen la responsabilidad de operar la infraestructura de sus plataformas y, normalmente, admitir los estándares actuales de identidad y autenticación.

No tener en cuenta los requisitos de los inquilinos

Los inquilinos suelen tener opiniones firmes sobre cómo se debe administrar la identidad para las soluciones que usan. Por ejemplo, muchos clientes empresariales requieren la federación con sus propios proveedores de identidad, para habilitar experiencias de inicio de sesión único y evitar la administración de varios conjuntos de credenciales. Otros inquilinos pueden requerir autenticación multifactor u otras formas de protección en torno a los procesos de inicio de sesión. Si el diseño no tiene en cuenta estos requisitos, puede resultar difícil adaptarlos más adelante.

Asegúrese de comprender los requisitos de identidad de los inquilinos antes de finalizar el diseño de su sistema de identidad. Revise las consideraciones de arquitectura para la identidad en una solución multiinquilino para comprender algunos requisitos específicos que suelen surgir.

Combinación de usuarios e inquilinos

Es importante tener en cuenta claramente cómo define la solución a un usuario y a un inquilino. En muchas situaciones, la relación puede ser compleja. Por ejemplo, un inquilino podría contener varios usuarios y un único usuario podría unirse a varios inquilinos.

Asegúrese de tener un proceso claro para el seguimiento del contexto del inquilino dentro de la aplicación y las solicitudes. En algunas situaciones, este proceso puede requerir que incluya un identificador de inquilino en cada token de acceso y que valide el identificador de inquilino en cada solicitud. En otras situaciones, la información de autorización del inquilino y las identidades de usuario se almacenan por separado y se usa un sistema de autorización más complejo para administrar qué usuarios pueden realizar qué operaciones con qué inquilinos.

El seguimiento del contexto de inquilino de un usuario o token es aplicable a cualquier modelo de arrendamiento, ya que una identidad de usuario siempre tiene un contexto de inquilino dentro de una solución multiinquilino. Incluso es recomendable realizar un seguimiento del contexto de inquilino al implementar stamps independientes para un único inquilino, lo que garantiza la perdurabilidad del código base para otras formas de multiinquilino.

Combinación de la autorización de roles y recursos

Es importante seleccionar un modelo de autorización adecuado para la solución. Los enfoques de seguridad basada en roles pueden ser fáciles de implementar, pero la autorización basada en recursos proporciona un control más preciso. Tenga en cuenta los requisitos de los inquilinos y si los inquilinos necesitan autorizar a algunos usuarios a acceder a partes específicas de la solución y no a otras partes.

No escribir los registros de auditoría

Los registros de auditoría son una herramienta importante para entender su entorno y la forma en que los usuarios están implementando su sistema. Al auditar todos los eventos relacionados con la identidad, a menudo puede determinar si su sistema de identidad está siendo atacado, y puede revisar cómo se está utilizando el sistema. Asegúrese de escribir y almacenar los registros de auditoría en el sistema de identidades. Considere si los registros de auditoría de identidad de su solución deben estar disponibles para que los inquilinos los revisen.

Colaboradores

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

Creadores de entidad de seguridad:

Otros colaboradores:

  • Jelle Druyts | Ingeniero de clientes principal, FastTrack for Azure
  • 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 las consideraciones arquitectónicas para la identidad en una solución multiinquilino.