Enfoques arquitectónicos para la integración de inquilinos y el acceso a datos

Es habitual que los sistemas se integren juntos, incluso a través de los límites de la organización. Al crear una solución multiinquilino, es posible que tenga requisitos para devolver datos a los sistemas de los inquilinos o recibir datos de esos sistemas. En este artículo se describen las consideraciones clave y los enfoques para diseñar y desarrollar integraciones para una solución multiinquilino.

Consideraciones clave y requisitos

Dirección del flujo de datos

Es importante comprender la dirección de los flujos de datos. La dirección del flujo de datos afecta a varios aspectos de la arquitectura, como la forma de administrar la identidad y la topología de red de la solución. Hay dos flujos de datos comunes:

• Exportar, lo que significa que los datos fluyen desde su sistema multiinquilino a los sistemas de los inquilinos individuales

• Importar, lo que significa que los datos proceden de los sistemas de sus inquilinos en su sistema multiinquilino

También es importante tener en cuenta la dirección del flujo de datos de red, que no corresponde necesariamente a la dirección del flujo de datos lógico. Por ejemplo, puedes iniciar una conexión saliente a un inquilino para poder importar los datos desde el sistema del inquilino.

Acceso total o acceso delegado por el usuario

En muchos sistemas, el acceso a datos específicos está restringido a usuarios individuales. Los datos a los que accede un usuario pueden diferir de los que accede otro usuario. Es importante tener en cuenta si trabaja con conjuntos de datos completos o si los datos que importa o exporta dependen de los permisos de acceso de cada usuario.

Por ejemplo, Power BI es un servicio multiinquilino que proporciona informes e inteligencia empresarial sobre almacenes de datos propiedad del cliente. Al configurar Power BI, puedes configurar orígenes de datos para extraer datos de bases de datos, API y otros almacenes de datos. Puedes configurar almacenes de datos de dos maneras diferentes:

• Importe todos los datos del almacén de datos subyacente. Este enfoque requiere que Power BI reciba credenciales para una identidad que tenga permisos para el almacén de datos completo. Después de importar los datos, los administradores de Power BI configuran los permisos de forma independiente. Power BI aplica esos permisos.

• Importe un subconjunto de datos desde el almacén de datos subyacente, en función de los permisos de un usuario. Cuando un usuario crea un origen de datos, usa sus credenciales y permisos asociados. El subconjunto exacto de datos que importa Power BI depende del nivel de acceso del usuario que crea el origen de datos.

Ambos enfoques tienen casos de uso válidos, por lo que es importante comprender claramente los requisitos de los inquilinos.

Si trabajas con conjuntos de datos completos, el sistema de origen trata eficazmente el sistema de destino como subsistema de confianza. Para este tipo de integración, también debes considerar el uso de una identidad de carga de trabajo en lugar de una identidad de usuario. Una identidad de carga de trabajo es una identidad del sistema que no corresponde a un solo usuario. A la identidad de carga de trabajo se le concede un alto nivel de permiso a los datos del sistema de origen.

Como alternativa, si trabajas con datos con ámbito de usuario, es posible que tengas que usar un enfoque como delegación para acceder al subconjunto correcto del conjunto de datos. A continuación, el sistema de destino obtiene eficazmente el mismo permiso que un usuario específico. Para obtener más información, consulte Acceso de usuario delegado. Si usa la delegación, considere cómo controlar escenarios en los que un usuario está desaprovisionado o sus permisos cambian.

Integraciones en tiempo real o integraciones por lotes

Tenga en cuenta si planea usar datos en tiempo real o enviar los datos en lotes.

En el caso de las integraciones en tiempo real, los enfoques siguientes son comunes:

• Solicitud-respuesta es donde un cliente inicia una solicitud a un servidor y recibe una respuesta. Normalmente, las integraciones de solicitud-respuesta se implementan mediante API o webhooks. Las solicitudes pueden ser sincrónicas, donde esperan confirmación y respuesta. Como alternativa, las solicitudes pueden ser asincrónicas y usar algo parecido al patrón asincrónico de Request-Reply para esperar una respuesta.

• La comunicación débilmente acoplada suele habilitarse a través de componentes de mensajería diseñados para acoplar débilmente los sistemas. Por ejemplo, Azure Service Bus proporciona funcionalidades de puesta en cola de mensajes y Azure Event Grid y Azure Event Hubs proporcionan funcionalidades de eventos. Estos componentes se suelen usar como parte de las arquitecturas de integración.

Por el contrario, las integraciones por lotes se administran a menudo a través de un trabajo en segundo plano, lo que puede desencadenarse en horas específicas del día. Las integraciones por lotes a menudo se producen a través de una ubicación de almacenamiento provisional , como un contenedor de almacenamiento de blobs, ya que los conjuntos de datos intercambiados pueden ser grandes.

Volumen de datos

Es importante comprender el volumen de datos que se intercambian a través de una integración, ya que esta información le ayuda a planear la capacidad general del sistema. Cuando planifiques la capacidad de tu sistema, recuerda que los distintos inquilinos pueden tener diferentes volúmenes de datos para intercambiarlos.

En el caso de las integraciones en tiempo real, puedes medir el volumen como el número de transacciones durante un período de tiempo especificado. En el caso de las integraciones por lotes, puedes medir el volumen como el número de registros intercambiados o la cantidad de datos en bytes.

Formatos de datos

Cuando los datos se intercambian entre dos partes, es importante que comprendan claramente el formato y la estructura de los datos. Ten en cuenta las siguientes partes del formato de datos:

• El formato de archivo, como JSON, Parquet, CSV o XML

• El esquema, como la lista de campos incluidos, los formatos de fecha y la nulabilidad de los campos

Cuando trabaje con un sistema multiinquilino, si es posible, normalice y use el mismo formato de datos para todos los inquilinos. Este enfoque le ayuda a evitar tener que personalizar y volver a probar los componentes de integración para los requisitos de cada inquilino. Sin embargo, algunos escenarios requieren diferentes formatos de datos para comunicarse con distintos inquilinos, por lo que es posible que tenga que implementar varias integraciones. Para obtener un enfoque que pueda ayudar a simplificar este tipo de escenario, consulte Componentes de integración que se pueden componer.

Acceso a los sistemas de inquilinos

Algunas integraciones requieren que realices una conexión con los sistemas o almacenes de datos de tu inquilino. Al conectarse a los sistemas del inquilino, debes tener en cuenta cuidadosamente los componentes de red e identidad de la conexión.

Acceso de red

Tenga en cuenta la topología de red para acceder al sistema del inquilino, que puede incluir las siguientes opciones:

• Las conexiones a Internet pueden plantear preocupaciones sobre cómo proteger la conexión y cifrar los datos. Determine cómo proteger la conexión y cifrar los datos al conectarse a través de Internet. Si los inquilinos planean restringir el acceso en función de las direcciones IP, asegúrese de que los servicios de Azure que usa la solución pueden admitir direcciones IP estáticas para las conexiones salientes. Por ejemplo, considere la posibilidad de usar Azure NAT Gateway para proporcionar direcciones IP estáticas, si es necesario. Si necesita una VPN, piense en la manera de intercambiar las claves de forma segura con sus inquilinos.

• Los agentes, que se implementan en el entorno de un inquilino, pueden proporcionar un enfoque flexible. Los agentes también pueden ayudarle a evitar la necesidad de que los inquilinos permitan conexiones entrantes.

• Relays, como Azure Relay, también aportan una forma de evitar conexiones entrantes.

Para obtener más información, consulte Enfoques de redes para multiinquilinato.

Autenticación

Ten en cuenta cómo te autenticas con cada inquilino al iniciar una conexión. Tenga en cuenta los siguientes procedimientos:

• Secretos, como claves de API o certificados. Es importante planear cómo administrar de forma segura las credenciales de los inquilinos. La pérdida de secretos de los inquilinos podría dar lugar a un incidente de seguridad importante, lo que podría afectar a muchos inquilinos.

• Tokens de Microsoft Entra, donde se usa un token que emite el directorio de Microsoft Entra del inquilino. El token se puede emitir directamente a la carga de trabajo mediante un registro de aplicación de Microsoft Entra multi-inquilino o una entidad de servicio específica. Como alternativa, la carga de trabajo puede solicitar permiso delegado para acceder a los recursos en nombre de un usuario específico dentro del directorio del inquilino.

Cualquier enfoque que seleccione, asegúrese de que los inquilinos siguen el principio de privilegios mínimos y no conceden permisos innecesarios al sistema. Por ejemplo, si el sistema solo necesita leer datos del almacén de datos de un inquilino, la identidad que usa el sistema no debe tener permisos de escritura.

Acceso de los inquilinos a los sistemas

Si los inquilinos necesitan conectarse al sistema, considere la posibilidad de proporcionar API dedicadas u otros puntos de integración. A continuación, puede modelar estos puntos de integración como parte del área expuesta de la solución.

En algunos escenarios, puede decidir proporcionar a los inquilinos acceso directo a los recursos de Azure. Tenga en cuenta las ramificaciones cuidadosamente y asegúrese de que comprende cómo conceder acceso a los inquilinos de forma segura. Por ejemplo, puede usar uno de los procedimientos siguientes:

• Use el patrón Valet Key, que usa medidas de seguridad como tokens de firmas de acceso compartido (SAS) para conceder acceso restringido a recursos específicos de Azure.

• Use recursos dedicados para puntos de integración, como una cuenta de almacenamiento dedicada. Se recomienda mantener los recursos de integración separados de los recursos principales del sistema. Este enfoque le ayuda a minimizar el radio de explosión de un incidente de seguridad. También garantiza que si un inquilino inicia accidentalmente un gran número de conexiones al recurso y agota su capacidad, el resto del sistema continúa ejecutándose.

Cumplimiento normativo

Al interactuar directamente con los datos de los inquilinos o transmitirlos, es fundamental que comprenda claramente los requisitos de cumplimiento y gobernanza de los inquilinos.

Enfoques y patrones

Exposición de una API

Las integraciones en tiempo real suelen implicar exponer la API para uso de los clientes u otras partes. Las API requieren consideraciones especiales, especialmente cuando las partes externas las usan. Tenga en cuenta los siguientes factores:

• Defina quién puede acceder a la API.

• Autentique a los usuarios de la API mediante un método seguro y confiable.

• Establezca un límite en el número de solicitudes que cada usuario de API puede realizar durante un período de tiempo específico.

• Proporcione información clara y documentación para cada API. Si procede, implemente un portal para desarrolladores para admitir la detección y la incorporación.

Un procedimiento recomendado es usar una puerta de enlace de API, como Azure API Management, para controlar estos problemas y muchos otros. Las puertas de enlace de API proporcionan un único lugar para implementar directivas que siguen las API. También simplifican la implementación de los sistemas de API de back-end. Para más información, consulte Uso de API Management en una solución multiinquilino.

Patrón Valet Key

En ocasiones, un inquilino podría necesitar acceso directo a un origen de datos, como Azure Storage. Considere seguir el patrón Valet Key para compartir datos de forma segura y restringir el acceso al almacenamiento de datos.

Por ejemplo, puede usar este enfoque para exportar por lotes un archivo de datos grande. Después de generar el archivo de exportación, puede guardarlo en un contenedor de blobs en Azure Storage y, a continuación, generar una SAS de solo lectura con tiempo limitado. Esta firma se puede proporcionar al inquilino, junto con la dirección URL del blob. Después, el inquilino puede descargar el archivo de Azure Storage hasta la fecha de expiración de la firma.

Del mismo modo, puede generar un SAS con permisos para escribir en un blob específico. Al proporcionar una SAS a un inquilino, pueden escribir sus datos en el blob. Mediante la integración de Event Grid para Azure Storage, la aplicación puede recibir notificaciones para procesar e importar el archivo de datos.

webhooks

Los webhooks le permiten enviar eventos a los inquilinos en una dirección URL que le proporcionan. Cuando tenga información que enviar, inicie una conexión al webhook del inquilino e incluya los datos en la carga de la solicitud HTTP.

Si decide crear su propio sistema de eventos de webhook, considere seguir el estándar CloudEvents para simplificar los requisitos de integración de sus clientes.

Como alternativa, puede usar un servicio como Event Grid para proporcionar funcionalidad de webhook. Event Grid funciona de forma nativa con CloudEvents y admite dominios de eventos, que son útiles para soluciones multiinquilino.

Acceso a usuario delegado

Al acceder a los datos de los almacenes de datos de un inquilino, tenga en cuenta si necesita usar la identidad de un usuario específico para acceder a los datos. Al hacerlo, la integración está sujeta a los mismos permisos que tiene el usuario. Este enfoque se suele denominar acceso delegado.

Por ejemplo, supongamos que el servicio multiinquilino ejecuta modelos de aprendizaje automático a través de los datos de los inquilinos. Debe acceder a las instancias de servicios de cada inquilino, como áreas de trabajo de Microsoft Fabric para análisis, Azure Storage y Azure Cosmos DB. Cada inquilino tiene su propio directorio de Microsoft Entra. A la solución se le puede conceder acceso delegado al almacén de datos para poder recuperar los datos a los que puede acceder un usuario específico.

El acceso delegado es más fácil si el almacén de datos admite la autenticación de Microsoft Entra. Muchos servicios de Azure admiten identidades de Microsoft Entra.

Por ejemplo, supongamos que su aplicación web multicliente y los procesos en segundo plano necesitan acceder a Azure Storage utilizando las identidades de usuario de sus inquilinos desde Microsoft Entra ID. Puedes realizar los pasos siguientes:

1. Cree un registro de aplicación multicliente de Microsoft Entra que represente su solución.

2. Conceda permiso delegado a la aplicación para acceder a Azure Storage como el usuario que ha iniciado sesión.

3. Configure la aplicación para autenticar a los usuarios mediante Microsoft Entra ID.

Una vez que un usuario inicia sesión, Microsoft Entra ID emite a la aplicación un token de acceso de corta duración que se puede usar para acceder a Azure Storage en nombre del usuario y emite un token de actualización de larga duración. El sistema debe almacenar el token de actualización de forma segura para que los procesos en segundo plano puedan obtener nuevos tokens de acceso y puedan seguir accediendo a Azure Storage en nombre del usuario.

Mensajería

La mensajería permite la comunicación asincrónica y acoplada de forma flexible entre sistemas o componentes. La mensajería se usa a menudo en escenarios de integración para desacoplar los sistemas de origen y destino. Para obtener más información sobre la mensajería y la multitenencia, consulte Enfoques arquitectónicos para la mensajería en soluciones multitenencia.

Al usar la mensajería como parte de una integración con los sistemas de los inquilinos, considere si debe usar tokens de SAS para Service Bus o Event Hubs. Los tokens de SAS conceden acceso limitado a los recursos de mensajería a usuarios o sistemas externos sin permitirles acceder al resto del subsistema de mensajería.

En algunos escenarios, puede proporcionar diferentes contratos de nivel de servicio o garantías de calidad de servicio a distintos inquilinos. Por ejemplo, un subconjunto de los inquilinos podría esperar que sus solicitudes de exportación de datos se procesen más rápidamente que otras. Mediante el Patrón de Cola de Prioridad, puede crear colas independientes para distintos niveles de prioridad. Luego, puede usar diferentes instancias de trabajo para priorizarlas adecuadamente.

Componentes de integración que admiten composición

A veces, es posible que tenga que integrarte con muchos inquilinos diferentes, cada uno de los cuales usa distintos formatos de datos o diferentes tipos de conectividad de red.

Un método común en la integración es compilar y probar pasos concretos que realizan los siguientes tipos de acciones:

• Recuperar datos de un almacén de datos.
• Transformar datos en un formato o esquema específicos.
• Transmitir datos mediante un transporte de red específico o a un tipo de destino conocido.

Normalmente, cada uno de estos elementos se compilan mediante servicios como Azure Functions y Azure Logic Apps. Después, defina el proceso de integración general mediante una herramienta como Logic Apps o Azure Data Factory, que invoca cada paso predefinido.

Al trabajar con escenarios complejos de integración multiinquilino, resulta útil definir una biblioteca de pasos de integración reutilizables. Puede crear flujos de trabajo para cada inquilino mediante la redacción de las partes aplicables en función de los requisitos de ese inquilino. Como alternativa, puede exponer algunos de los conjuntos de datos o componentes de integración directamente a los inquilinos para que puedan crear sus propios flujos de trabajo de integración.

Del mismo modo, es posible que tenga que importar datos de inquilinos que usen un formato de datos diferente o un transporte diferente al de otros. Un buen enfoque para este escenario es crear conectores específicos del inquilino. Los conectores son flujos de trabajo que normalizan e importan los datos en un formato y una ubicación estandarizados. A continuación, desencadenan el proceso de importación compartido principal.

Si necesita compilar código o lógica específica del inquilino, considere la posibilidad de seguir el Patrón Capa contra daños. Este patrón le ayuda a encapsular componentes específicos del inquilino y mantiene el resto de su solución sin tener en cuenta la complejidad agregada.

Si usa un modelo de precios por niveles, puede requerir que los inquilinos con planes de tarifa bajos sigan un enfoque estándar con un conjunto limitado de formatos de datos y transportes. Los inquilinos con planes de tarifa superiores pueden tener acceso a más personalización o flexibilidad en los componentes de integración que proporcione.

Antipatrones que se deben evitar

• Exponer las bases de datos principales directamente a los arrendatarios. Cuando los inquilinos acceden a los almacenes de datos principales, puede resultar más difícil proteger esos almacenes. También pueden causar accidentalmente problemas de rendimiento que afectan a la solución. Evite proporcionar credenciales a los almacenes de datos a los clientes. No replique directamente los datos sin procesar de la base de datos principal a las réplicas de lectura de los clientes del mismo sistema de base de datos. En su lugar, cree almacenes de datos de integración dedicados. Utiliza el patrón Valet Key para exponer los datos.

• Exponer las API sin una puerta de enlace de API. Las API tienen problemáticas específicas para el control de acceso, la facturación y la medición. Aunque no tenga pensado usar inicialmente directivas de API, es recomendable incluir una puerta de enlace de API antes. De este modo, si necesita personalizar las directivas de API más adelante, no tiene que realizar cambios importantes en las direcciones URL de las que depende un cliente externo.

• Acoplamiento apretado innecesario. El acoplamiento flexible, como el uso de enfoques de mensajería, puede proporcionar una serie de ventajas para la seguridad, el aislamiento del rendimiento y la resistencia. Cuando sea posible, debe acoplar de manera flexible las integraciones con sistemas externos. Si necesita acoplarse estrechamente a un sistema externo, asegúrese de seguir procedimientos recomendados como el patrón Retry, el patrón Circuit Breaker y el patrón Bulkhead.

• Integraciones personalizadas para inquilinos específicos. Las características o el código específicos del inquilino pueden hacer que la solución sea más difícil de probar. También dificulta la modificación de la solución en el futuro, ya que usted debe comprender más caminos de código. En su lugar, intente desarrollar componentes componibles que abstraigan los requisitos de cualquier inquilino específico y reutilícelos en varios inquilinos que tengan requisitos similares.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autores principales

• John Downs | Ingeniero principal de software, Patrones y prácticas de Azure
• Arsen Vladimirskiy | Ingeniero Principal de Clientes, FastTrack para Azure

Otros colaboradores:

• Will Velida | Ingeniero de soporte al cliente 2, FastTrack for Azure
• Filipe Moreira | Arquitecto de soluciones en la nube

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Recurso relacionado

• Enfoques arquitectónicos para la mensajería en soluciones multiinquilino