Compartir a través de

Implementación de la comunicación entre inquilinos mediante aplicaciones multiinquilino

  • Artículo

En esta guía se proporciona una solución para lograr comunicaciones bidireccionales seguras entre servicios hospedados en suscripciones de Azure que administran distintos inquilinos de Microsoft Entra.

La protección de las comunicaciones multiinquilino en Azure puede ser difícil debido a limitaciones inherentes a muchos servicios. Puede eliminar la necesidad de administrar las credenciales directamente mediante identidades administradas de Azure para obtener tokens de Microsoft Entra ID. Sin embargo, las identidades administradas de Azure no funcionan a través de los límites del inquilino y la alternativa suele ser usar secretos compartidos, como direcciones URL de firma de acceso compartido. Recuerde que si usa secretos compartidos, debe distribuir y rotar de forma segura los secretos a través de los límites de inquilino de Microsoft Entra.

Una opción que evita esta sobrecarga es crear una aplicación multiinquilino para representar la identidad de la carga de trabajo. Mediante un proceso de consentimiento, puede dar a conocer esta identidad de carga de trabajo a un inquilino externo y, en última instancia, permitirle autenticar servicios en el inquilino externo.

En este artículo se presenta una implementación de ejemplo de este patrón que usa código de ejemplo.

Este patrón se puede reutilizar para cualquier escenario multiinquilino que tenga varios servicios que necesiten comunicarse entre los límites del inquilino de Microsoft Entra.

Arquitectura

Diagrama de la arquitectura de comunicación entre inquilinos.

Descargue un archivo de PowerPoint de esta arquitectura.

Flujo de trabajo

El siguiente flujo de trabajo corresponde al diagrama anterior:

  1. Un administrador del lado del proveedor crea un registro de aplicación multiinquilino y configura un secreto de cliente para él.

  2. Un administrador del lado del cliente aprovisiona una entidad de servicio en su inquilino. Esta entidad de servicio se basa en la aplicación multiinquilino que creó el proveedor. Puede realizar este paso de varias maneras. En el ejemplo, hemos optado por crear una URL para proporcionársela al administrador del inquilino del cliente, pero puede utilizar la API de Microsoft Graph en su lugar.

  3. El cliente aplica roles de control de acceso basado en roles (RBAC) a esta nueva entidad de servicio para que esté autorizado para acceder a Azure Service Bus.

  4. La aplicación de funciones del proveedor usa el identificador y el secreto de cliente del registro de la aplicación para enviar un mensaje autenticado a la cola de Service Bus del cliente.

  5. La aplicación de funciones del cliente usa una identidad administrada para leer el mensaje del proveedor de la cola a través de un desencadenador de Service Bus.

  6. Después de recibir el mensaje, la aplicación de funciones del cliente normalmente realiza algún trabajo antes de enviar un mensaje de estado al proveedor. En este caso, con fines de demostración, la aplicación de funciones envía inmediatamente un mensaje de estado al proveedor en una cola independiente en el mismo Service Bus.

  7. Esta aplicación de funciones lee de la cola de estado del inquilino del cliente a través de un temporizador que desencadena Azure Functions.

Detalles del escenario

Un proveedor tiene varios clientes. El proveedor y cada cliente tienen su propio inquilino de Microsoft Entra ID individual y recursos de Azure. El proveedor y cada cliente necesitan un método seguro y bidireccional de comunicación para que puedan intercambiar mensajes a través de colas de Service Bus. La solución debe tener un elemento de identidad atractivo que evite introducir credenciales o secretos innecesarios.

Qué hay que saber sobre las aplicaciones multiinquilino

  • Un objeto de aplicación es una instancia única global de la aplicación.

  • Al registrar una aplicación en Microsoft Entra, se crean automáticamente un objeto de aplicación y un objeto de entidad de servicio en el inquilino.

  • Se crea un objeto de entidad de servicio en cada inquilino que usa la aplicación y hace referencia al objeto de aplicación. Un objeto de aplicación tiene una relación uno a varios con su objeto de entidad de servicio correspondiente.

  • El objeto de aplicación es la representación global de la aplicación y se utiliza en todos los inquilinos. El objeto de entidad de servicio es la representación local que se usa en un inquilino específico.

  • Debe crearse un objeto de entidad de servicio en cada inquilino donde se usa la aplicación para establecer una identidad para acceder a los recursos que protege el inquilino. Una aplicación de un solo inquilino solamente tiene un objeto de entidad de servicio en su inquilino principal. Este objeto de entidad de servicio se crea y permite que se use durante el registro de la aplicación. Una aplicación multiinquilino también tiene un objeto de entidad de servicio creado en cada inquilino donde un usuario de ese inquilino ha dado su consentimiento para su uso.

  • Para acceder a los recursos que están protegidos por un inquilino de Microsoft Entra, la entidad que requiere acceso debe estar representada por una entidad de seguridad.

  • Cuando una aplicación tiene permiso para acceder a los recursos de un inquilino tras el registro o consentimiento, se crea un objeto de entidad de servicio. Esta arquitectura se implementa con el flujo de consentimiento.

¿Cómo envía el proveedor el mensaje al cliente?

Lo ideal es que el proveedor pueda asignar una identidad administrada al recurso de proceso de Azure responsable de enviar mensajes a la cola de un cliente. El inquilino del cliente está configurado para confiar en identidades administradas del inquilino del proveedor. Sin embargo, una verdadera federación entre dos inquilinos de Microsoft Entra, que básicamente permitiría el "uso compartido" de identidades de un inquilino a otro, no es posible actualmente. Por lo tanto, el proveedor debe autenticarse mediante una identidad que el cliente reconozca. El proveedor debe autenticarse en el inquilino de Microsoft Entra del cliente como entidad de servicio que el cliente conozca.

Se recomienda que el proveedor registre una aplicación multiinquilino en su propio inquilino y, a continuación, que cada cliente aprovisione una entidad de servicio asociada en su inquilino. A continuación, el proveedor puede autenticarse en el inquilino del cliente y en las API hospedadas por el cliente mediante esta entidad de servicio. El proveedor nunca necesita compartir un secreto de cliente en este enfoque. La administración de credenciales es responsabilidad exclusiva del proveedor.

¿Cómo envía el cliente el mensaje al proveedor?

Se recomienda que el cliente cree o hospede una cola desde la que pueda leer el proveedor. El cliente escribe un mensaje en la cola. El proveedor sondea repetidamente cada cola del cliente en busca de mensajes mediante un objeto de entidad de servicio. La desventaja de este enfoque es que introduce latencia de sondeo cuando el proveedor recibe un mensaje. El código también debe ejecutarse con más frecuencia en el proveedor, ya que debe reactivarse y realizar la lógica de sondeo en lugar de esperar a que un evento lo desencadene. Sin embargo, la administración de credenciales sigue siendo responsabilidad exclusiva del proveedor, lo que refuerza la seguridad.

Otra posible solución consiste en que el proveedor cree o hospede una cola para cada uno de sus clientes. Cada cliente crea su propia aplicación multiinquilino y solicita que el proveedor la aprovisione en su inquilino como un objeto de entidad de servicio. A continuación, el cliente usa este objeto de entidad de servicio para enviar mensajes a una cola específica del cliente en el lado del proveedor. La administración de credenciales sigue siendo responsabilidad exclusiva del cliente. Una desventaja de este enfoque es que el proveedor debe aprovisionar entidades de servicio asociadas a las aplicaciones de cliente en su inquilino. Este proceso es manual y es probable que los proveedores no quieran que los pasos manuales formen parte del flujo para incorporar un nuevo cliente.

Configuración del código de ejemplo

Los pasos siguientes le guían por el proceso de configuración de la comunicación entre inquilinos entre un proveedor y un cliente.

Configuración del proveedor

La configuración del proveedor incluye los pasos para generar y aprovisionar una entidad de servicio de aplicación multiinquilino y los pasos para aprovisionar el inquilino del cliente.

  1. Cree una aplicación de funciones desencadenada por HTTP para enviar un mensaje para escribir en la cola de comandos de Service Bus del cliente dentro del inquilino del cliente.

  2. Cree una aplicación de funciones desencadenada por tiempo para comprobar periódicamente una cola de estado dentro de Service Bus del cliente dentro del inquilino del cliente.

Creación de una aplicación multiinquilino dentro del inquilino del proveedor

En primer lugar, cree una aplicación multiinquilino en el inquilino del proveedor y aprovisione esa identidad dentro del inquilino del cliente. En este escenario, la identidad es una entidad de servicio. En la arquitectura anterior de este artículo se muestra cómo configurar y aprovisionar una entidad de servicio desde el inquilino del proveedor en el inquilino del cliente. La arquitectura también describe cómo aprovisionar con varios inquilinos de Microsoft Entra.

  1. Elija la opción de organización multiinquilino.

  2. Agregue el siguiente sitio web como URI de redirección: https://entra.microsoft.com. Puede cambiar este URI para satisfacer sus necesidades empresariales.

  3. Registre y anote el valor del ID de la aplicación (cliente).

Creación de un secreto de cliente

  1. Después de crear la aplicación multiinquilino, cree un secreto de cliente para esta entidad de servicio.

  2. Guarde el secreto generado en una ubicación segura. El secreto y el ID de cliente son las credenciales de cliente necesarias para intercambiar el código, en el flujo de código de autorización, y para un token de identificador en el paso siguiente.

Azure Functions - Desencadenado por HTTP

Use la función HTTP para iniciar la implementación desde el inquilino del proveedor mediante el envío de un mensaje a la cola de implementación de Service Bus del cliente. Hemos elegido la función desencadenada por HTTP como método de entrega para iniciar esta prueba de concepto. La entidad de servicio que generó anteriormente actúa como la credencial para acceder al inquilino del cliente y escribir en una cola específica dentro de Service Bus. También debe finalizar la configuración del cliente para que este paso funcione correctamente.

Azure Functions - Desencadenado por temporizador

Use la función desencadenada por temporizador para sondear la cola de estado de implementación desde el inquilino del cliente. La cola de estado de implementación se sondea cada 10 segundos con fines de demostración en esta prueba de concepto. Este enfoque elimina la necesidad de que el cliente tenga una entidad de servicio para acceder al inquilino del proveedor.

Configuración del cliente

  1. Aprovisione la entidad de servicio modificando y usando la dirección URL proporcionada.

  2. Determine la entidad de servicio del proveedor para usar los controles RBAC adecuados.

  3. Cree una función desencadenada por Service Bus para leer un mensaje de una cola de mensajes de Service Bus y colocar un mensaje en otra cola. Con fines de demostración, este flujo es óptimo para probar la funcionalidad.

  4. Cree una identidad administrada asignada por el sistema para la función desencadenada por Service Bus.

  5. Asigne el ámbito de Service Bus de identidad administrada asignada por el sistema.

Aprovisionamiento de la entidad de servicio desde el inquilino del proveedor al inquilino del cliente

  1. Visite la siguiente dirección URL después de reemplazar el parámetro de cadena de consulta client_id por su propio identificador de cliente: https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>.

    También puede aprovisionar la entidad de servicio en otro inquilino de Microsoft Entra con una llamada a la API de Microsoft Graph de administrador, un comando de Azure PowerShell o un comando de la CLI de Azure.

  2. Inicie sesión con una cuenta desde el inquilino del cliente.

  3. En la pantalla de consentimiento, seleccione Aceptar para aprovisionar la aplicación del proveedor en el inquilino del cliente. La dirección URL finalmente le redirige a microsoft.com, que todavía tiene el efecto deseado de aprovisionar la identidad en el inquilino del cliente.

  4. Compruebe la identidad dentro del inquilino de Microsoft Entra del cliente; para ello, vaya a Aplicaciones empresariales para ver la entidad de servicio recién aprovisionada.

Configuración de RBAC para la entidad de servicio aprovisionada

Determine la entidad de servicio del proveedor de la configuración de la entidad de servicio del proveedor para tener roles de "Propietario de datos de Service Bus" en Service Bus. Esta entidad de servicio se usa tanto para escribir en una cola con una función desencadenada por HTTP como para leer desde una cola desde una función desencadenada por el temporizador. Asegúrese de agregar el rol "Propietario de datos de Azure Service Bus" a la entidad de servicio.

Azure Functions - Desencadenador de Service Bus

Siga los pasos del tutorial de funciones basadas en identidades para definir el desencadenador de función desde la cola de Service Bus y para obtener información sobre cómo configurar una identidad administrada. Esta guía le ayuda a desencadenar la aplicación de funciones desde la cola de Service Bus cuando se agrega un mensaje a la cola. También se usa la identidad administrada cuando se coloca un mensaje en una cola diferente. Para fines de demostración, usamos la misma función para insertar el mensaje.

En el espacio de nombres de Service Bus que acaba de crear, seleccione Control de acceso (IAM) . Puede ver y configurar quién tiene acceso al recurso en el plano de control.

Concesión a la aplicación de funciones acceso al espacio de nombres de Service Bus mediante identidades administradas

  1. Asegúrese de agregar el rol "Receptor de datos de Azure Service Bus" a la identidad administrada.

  2. En el selector de identidad administrada, seleccione Aplicación de funciones de la categoría Identidad administrada asignada por el sistema. La etiqueta Aplicación de funciones puede tener un número entre paréntesis junto a ella. Ese número indica cuántas aplicaciones tienen identidades asignadas por el sistema en la suscripción.

Conectar a Service Bus en la aplicación de funciones

  1. En el portal, busque la aplicación de funciones o vaya a ella en la página Aplicación de funciones.

  2. En Configuración de la aplicación, seleccione + Nueva, para crear una nueva configuración de la aplicación en la tabla. Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

Administración del ciclo de vida del secreto de cliente de la entidad de servicio

Si introduce secretos en la arquitectura entre inquilinos, debe administrar el ciclo de vida de los secretos de cliente generados. Consulte Procedimientos recomendados para la administración de secretos para obtener información sobre cómo almacenar, rotar y supervisar los secretos de cliente de forma segura.

Configuración local

Cada subdirectorio contiene una versión de código auxiliar de los archivos local.settings.json, que se puede modificar para ejecutar las funciones de Azure localmente. Para configurar las opciones en Azure, actualice la Configuración de la aplicación.

El comando DefaultAzureCredential enumera varias opciones de configuración antes de que llegue a la credencial de la CLI de Azure. Para evitar confusiones, se recomienda ejecutar el comando az login -t <tenant ID> para seleccionar las credenciales correctas al desarrollar funciones locales.

Colaboradores

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

Creadores de entidad de seguridad:

Pasos siguientes