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 compilar una solución multiinquilino, es posible que tengas requisitos para devolver datos a los sistemas de los inquilinos o para recibir datos de esos sistemas. En este artículo, se describen las consideraciones y enfoques clave para diseñar y desarrollar integraciones para una solución multiinquilino.

Nota:

Si proporcionas varios puntos de integración, es mejor tener en cuenta cada uno de ellos de forma independiente. A menudo, los distintos puntos de integración tienen requisitos diferentes y están diseñados de forma diferente, incluso si se conectan los mismos sistemas de varias maneras diferentes.

Consideraciones clave y requisitos

Dirección del flujo de datos

Es importante comprender la dirección en la que fluyen tus 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 tu sistema multiinquilino a los sistemas de los inquilinos individuales.
• Importar, lo que significa que los datos proceden de los sistemas de tus inquilinos en tu 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 completo o delegado por el usuario

En muchos sistemas, el acceso a determinados datos está restringido a usuarios específicos. Los datos a los que un usuario puede acceder podrían no ser los mismos que los datos a los que otro usuario puede acceder. Es importante tener en cuenta si esperas trabajar con conjuntos de datos completos o si los conjuntos de datos que importas o exportas se basan en lo que un usuario específico tiene permiso para acceder.

Por ejemplo, considera Microsoft Power BI, que 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:

• Importa todos los datos del almacén de datos subyacente. Este enfoque requiere que Power BI se proporcione con credenciales para una identidad que pueda acceder al almacén de datos completo. A continuación, los administradores de Power BI pueden configurar por separado los permisos para los datos importados después de importarlos en Power BI. Power BI aplica los 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 el origen de datos, usa sus credenciales y los permisos asociados. El subconjunto exacto de datos que Importa Power BI depende del nivel de acceso del usuario que creó 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 de datos 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 sobre la delegación de usuarios, consulta el enfoque de acceso de usuario delegado a continuación. Si usas la delegación, ten en cuenta cómo controlarás los escenarios en los que un usuario está desaprovisionado o sus permisos cambian.

Lotes o en tiempo real

Ten en cuenta si vas a trabajar con datos en tiempo real o si los datos se enviarán en lotes.

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

• Solicitud/respuesta es donde un cliente inicia una solicitud a un servidor y recibe una respuesta. Normalmente, las integraciones de solicitud y 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, usando algo como el patrón de solicitud-respuesta asincrónica para esperar una respuesta.
• La comunicación de acoplamiento flexible suele habilitarse a través de componentes de mensajería diseñados para sistemas de acoplamiento flexible. Por ejemplo, Azure Service Bus proporciona funcionalidades de puesta en cola de mensajes y Azure Event Grid y 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 determinados momentos del día. Normalmente, las integraciones por lotes tienen lugar a través de una ubicación de almacenamiento provisional, como un contenedor de almacenamiento de blobs, porque los conjuntos de datos intercambiados pueden ser grandes.

Volumen de datos

Es importante comprender el volumen de datos que intercambias a través de una integración, ya que esta información te ayuda a planificar la capacidad general de tu 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 se intercambian datos entre dos partes, es importante que ambos comprendan claramente cómo se formatearán y estructurarán los datos. Ten en cuenta las siguientes partes del formato de datos:

• Formato de archivo, como JSON, Parquet, CSV o XML.
• Esquema, como la lista de campos que se incluirán, los formatos de fecha y la nulabilidad de los campos.

Si trabajas con un sistema multiinquilino, si es posible, es mejor estandarizar y usar el mismo formato de datos para todos los inquilinos. De este modo, evitas tener que personalizar y volver a probar los componentes de integración para los requisitos de cada inquilino. Sin embargo, en algunas situaciones, es posible que tengas que usar diferentes formatos de datos para comunicarte con distintos inquilinos, por lo que es posible que tengas que implementar varias integraciones. Consulta la sección Componentes de integración que admiten composición para obtener un enfoque que pueda ayudar a simplificar este tipo de situación.

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:

• Conéctate a través de Internet. Si te conectas a través de Internet, ¿cómo se protegerá la conexión y cómo se cifrarán los datos? Si tus inquilinos planean restringir en función de las direcciones IP, asegúrate de que los servicios de Azure que usa la solución pueden admitir direcciones IP estáticas para las conexiones salientes. Por ejemplo, considera la posibilidad de usar 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 aportar un enfoque flexible y pueden ayudarle a evitar la necesidad de que sus inquilinos permitan conexiones entrantes.
• Las retransmisiones, como Azure Relay, también aportan un enfoque para evitar conexiones entrantes.

Para obtener más información, consulte las instrucciones sobre los método de red para multiinquilino.

Authentication

Tenga en cuenta cómo se autentica 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 creado por el propio 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 multiinquilino 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.

Independientemente del procedimiento que elija, asegúrese de que tus inquilinos sigan el principio de privilegios mínimos y evite conceder permisos innecesarios al sistema. Por ejemplo, si el sistema solo necesita leer datos del almacén de datos de un inquilino, la identidad que use el sistema no debe tener permisos de escritura.

Acceso de los inquilinos a los sistemas

Si los inquilinos necesitan conectarse tu sistema, considere la posibilidad de proporcionar API dedicadas u otros puntos de integración, que después puede modelar como parte del área expuesta de la solución.

En algunas situaciones, puede decidir dar a los inquilinos acceso directo a sus recursos de Azure. Tenga muy en cuenta las ramificaciones y asegúrese de conocer bien 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 implica el uso de medidas de seguridad como firmas de acceso compartido para conceder acceso restringido a determinados recursos 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 procedimiento 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 empezar a interactuar directamente con los datos de tus inquilinos o transmitir esos datos, es fundamental que tenga un conocimiento claro de los requisitos de cumplimiento y gobernanza de sus inquilinos.

Procedimientos y patrones que se deben tener en cuenta

Exposición de una API

Las integraciones en tiempo real suelen implicar exponer las API a sus inquilinos u otras partes para usarlas. Las API requieren consideraciones especiales, especialmente cuando las usan las partes externas. Tenga en cuenta las preguntas siguientes:

• ¿Quién tiene acceso a la API?
• ¿Cómo autenticará los usuarios de la API?
• ¿Hay un límite en el número de solicitudes que un usuario de API puede realizar durante un período de tiempo?
• ¿Cómo proporcionará información sobre las API y la documentación de cada API? Por ejemplo, ¿necesita implementar un portal para desarrolladores?

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 y simplifican la implementación de los sistemas de API de back-end. Para obtener más información sobre cómo API Management admite la arquitectura multiinquilino, consulte Uso de Azure 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 la posibilidad de seguir el patrón Valet Key para compartir datos de forma segura y restringir el acceso al almacén de datos.

Por ejemplo, podría usar este procedimiento al 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 firma de acceso compartido de solo lectura enlazada a tiempo. Esta firma se puede proporcionar al inquilino, junto con la dirección URL del blob. A continuación, el inquilino puede descargar el archivo de Azure Storage hasta la expiración de la firma.

De forma similar, puede generar una firma de acceso compartido con permisos para escribir en un blob específico. Al proporcionar una firma de acceso compartido 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 la posibilidad de seguir el estándar CloudEvents para simplificar los requisitos de integración de sus inquilinos.

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

Nota:

Siempre que realice conexiones salientes a los sistemas de los inquilinos, recuerde que se está conectando a un sistema externo. Sigue los procedimientos recomendados en la nube, incluido el uso del patrón Retry, el patrón Circuit Breaker y el patrón Bulkhead para asegurarse de que los problemas del sistema de su inquilino no se propagan al sistema.

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 procedimiento se suele denominar acceso delegado.

Por ejemplo, suponga que el servicio multiinquilino ejecuta modelos de aprendizaje automático a través de los datos de sus inquilinos. Debe acceder a las instancias de servicios de cada inquilino, como Azure Synapse Analytics, Azure Storage, Azure Cosmos DB y otros. Cada inquilino tiene su propio directorio de Microsoft Entra. Se puede conceder a su solución acceso delegado al almacén de datos, para que pueda recuperar los datos a los que un usuario específico pueda acceder.

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 multiinquilino y los procesos en segundo plano necesitan acceder a Azure Storage mediante sus identidades de usuario de los inquilinos de Microsoft Entra ID. Puedes realizar los pasos siguientes:

1. Crea un registro de aplicación de Microsoft Entra multiinquilino que represente su solución.
2. Conceda permiso delegado a la aplicación para acceder a Azure Storage como 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 normalmente en escenarios de integración para desacoplar los sistemas de origen y destino. Para obtener más información sobre mensajería y multiinquilino, consulte Procedimientos de arquitectura para la mensajería en soluciones multiinquilino.

Al usar la mensajería como parte de una integración con los sistemas de tus inquilinos, considere si debería usar firmas de acceso compartido para Azure Service Bus o Azure Event Hubs. Las firmas de acceso compartido le permiten conceder acceso limitado a los recursos de mensajería a terceros, sin permitirles acceder al resto de su subsistema de mensajería.

En algunos escenarios, puede proporcionar diferentes acuerdos de nivel de servicio (SLA) o garantías de calidad de servicio (QoS) a diferentes 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 Cola de prioridad, puede crear colas independientes para distintos niveles de prioridad, con diferentes instancias de trabajo para priorizarlas en consecuencia.

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 los datos mediante un transporte de red determinado o a un tipo de destino conocido.

Normalmente, cada uno de estos elementos se compilan mediante servicios como Azure Functions y Azure Logic Apps. A continuación, define el proceso de integración general mediante una herramienta, como Logic Apps o Azure Data Factory, e invoca cada uno de los pasos predefinidos.

Al trabajar con escenarios complejos de integración multiinquilino, puede resultar útil definir una biblioteca de pasos de integración reutilizables. Después, puede crear flujos de trabajo para cada inquilino para componer las partes aplicables, en función de los requisitos de ese inquilino. Como alternativa, es posible que pueda exponer algunos de los conjuntos de datos o los componentes de integración directamente a sus inquilinos, para que puedan crear sus propios flujos de trabajo de integración a partir de ellos.

Del mismo modo, es posible que tenga que importar datos de inquilinos que usan un formato de datos diferente o un transporte diferente a otros usuarios. 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 y, 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. El patrón le ayuda a encapsular componentes específicos del inquilino, a la vez que mantiene el resto de su solución sin tener en cuenta la complejidad agregada.

Si usa un modelo de precios por niveles, puede optar por requerir que los inquilinos en un plan de tarifa bajo sigan un enfoque estándar con un conjunto limitado de formatos de datos y transportes. Los planes de tarifa más altos pueden habilitar más personalización o flexibilidad en los componentes de integración que ofrece.

Antipatrones que se deben evitar

• Exponer los almacenes de datos principales directamente a los inquilinos. Cuando los inquilinos acceden a los almacenes de datos principales, puede ser más difícil proteger esos almacenes de datos y podrían generar por error problemas de rendimiento que afecten a la solución. Evite dar sus credenciales de los almacenes de datos a los clientes y no replique directamente los datos 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 y use 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 en el futuro, no es necesario realizar cambios importantes en las direcciones URL de las que depende un tercero.
• 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, es una buena idea acoplar de forma flexible sus integraciones con terceros. Si necesita acoplarte estrechamente a un tercero, asegúrese de seguir procedimientos recomendados como el patrón Reintento, 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 hace que sea más difícil modificar la solución en el futuro, ya que tiene que comprender más rutas de acceso de código. En su lugar, intente crear componentes que puedan crear componentes que abstraigan los requisitos de cualquier inquilino específico y reutilícelas en varios inquilinos con requisitos similares.

Colaboradores

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

Creadores de entidad de seguridad:

• John Downs | Ingeniero principal de software
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

Otro colaborador:

• Will Velida | Ingeniero de clientes 2, FastTrack for Azure

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

Pasos siguientes

Consulte Procedimientos de arquitectura para la mensajería en soluciones multiinquilino.