Approches architecturales pour l’intégration des locataires et l’accès aux données

Il est courant que les systèmes s’intègrent, même au-delà des limites de l’organisation. Lorsque vous créez une solution mutualisée, vous devez peut-être renvoyer des données aux systèmes de vos locataires ou recevoir des données de ces systèmes. Cet article décrit les principales considérations et approches relatives à l’architecture et au développement d’intégrations pour une solution mutualisée.

Principaux éléments et exigences à prendre en compte

Sens d’un flux de données

Il est important de comprendre la direction de vos flux de données. Le sens du flux de données affecte plusieurs aspects de votre architecture, comme la façon dont vous gérez l’identité et la topologie de réseau de votre solution. Il existe deux flux de données courants :

• Exporter, ce qui signifie que les données circulent de votre système mutualisé vers les systèmes de vos locataires individuels

• Importer, ce qui signifie que les données proviennent des systèmes de vos locataires dans votre système mutualisé

Il est également important de prendre en compte le sens du flux de données réseau, qui ne correspond pas nécessairement au sens du flux de données logique. Par exemple, vous pouvez établir une connexion sortante à un locataire afin de pouvoir importer les données à partir du système du locataire.

Accès complet ou accès délégué par l’utilisateur

Dans de nombreux systèmes, l’accès à des données spécifiques est limité aux utilisateurs individuels. Les données auxquelles un utilisateur accède peuvent différer de ce qu’un autre utilisateur accède. Il est important de déterminer si vous travaillez avec des jeux de données complets ou si les données que vous importez ou exportez dépendent des autorisations d’accès de chaque utilisateur.

Par exemple, Power BI est un service multilocataire qui fournit des rapports et des informations décisionnelles sur les magasins de données appartenant au client. Lorsque vous configurez Power BI, vous configurez des sources de données pour extraire des données de bases de données, d’API et d’autres magasins de données. Vous pouvez configurer des magasins de données de deux façons différentes :

• Importez toutes les données du magasin de données sous-jacent. Cette approche nécessite que Power BI reçoive les informations d’identification d’une identité disposant d’autorisations sur le magasin de données complet. Après avoir importé les données, les administrateurs Power BI configurent les autorisations indépendamment. Power BI applique ces autorisations.

• Importez un sous-ensemble de données à partir du magasin de données sous-jacent, en fonction des autorisations d’un utilisateur. Lorsqu’un utilisateur crée une source de données, il utilise ses informations d’identification et ses autorisations associées. Le sous-ensemble exact de données que Power BI importe dépend du niveau d’accès de l’utilisateur qui crée la source de données.

Les deux approches ont des cas d’utilisation valides. Il est donc important de bien comprendre les exigences de vos locataires.

Si vous utilisez des jeux de données complets, le système source traite efficacement le système de destination comme un sous-système approuvé. Pour ce type d’intégration, vous devez également envisager d’utiliser une identité de charge de travail au lieu d’une identité d’utilisateur. Une identité de charge de travail est une identité système qui ne correspond pas à un seul utilisateur. L’identité de la charge de travail reçoit un niveau d’autorisation élevé pour les données dans le système source.

Autrement, si vous utilisez des données de portée utilisateur, vous devrez peut-être utiliser une approche telle que la délégation pour accéder au sous-ensemble correct de données à partir du jeu de données. Ensuite, le système de destination obtient efficacement la même autorisation qu’un utilisateur spécifique. Pour plus d’informations, consultez Accès utilisateur délégué. Si vous utilisez la délégation, envisagez de gérer les scénarios où un utilisateur est déprovisionné ou ses autorisations changent.

Intégrations en temps réel ou intégrations par lots

Déterminez si vous envisagez d’utiliser des données en temps réel ou d’envoyer les données par lots.

Pour les intégrations en temps réel, les approches suivantes sont courantes :

• La requête-réponse est un mécanisme où un client initie une demande vers un serveur et reçoit une réponse. En règle générale, les intégrations de demande-réponse sont implémentées à l’aide d’API ou de webhooks. Les demandes peuvent être synchrones, où elles attendent un accusé de réception et une réponse. Vous pouvez également utiliser des requêtes asynchrones et utiliser un modèle de Request-Reply asynchrone pour attendre une réponse.

• La communication faiblement couplée est souvent activée par le biais de composants de messagerie conçus pour les systèmes à couplage faible. Par exemple, Azure Service Bus fournit des fonctionnalités de mise en file d’attente de messages, et Azure Event Grid et Azure Event Hubs offrent des fonctionnalités d’événement. Ces composants sont souvent utilisés dans le cadre d’architectures d’intégration.

En revanche, les intégrations par lots sont souvent gérées par le biais d’un travail en arrière-plan, qui peut être déclenché à des moments spécifiques de la journée. Les intégrations par lots se produisent souvent via un emplacement intermédiaire tel qu’un conteneur de stockage d’objets blob, car les jeux de données échangés peuvent être volumineux.

Volume de données

Il est important de comprendre le volume de données que vous échangez via une intégration, car ces informations vous aident à planifier la capacité globale de votre système. Lorsque vous planifiez la capacité de votre système, n’oubliez pas que différents locataires peuvent avoir différents volumes de données à échanger.

Pour les intégrations en temps réel, vous pouvez mesurer le volume sous la forme de nombre de transactions sur une période spécifiée. Pour les intégrations par lots, vous pouvez mesurer le volume sous la forme du nombre d’enregistrements échangés ou de la quantité de données en octets.

Formats de données

Lorsque les données sont échangées entre deux parties, il est important qu’elles comprennent clairement le format et la structure des données. Tenez compte des parties suivantes du format de données :

• Format de fichier, tel que JSON, Parquet, CSV ou XML

• Le schéma, tel que la liste des champs inclus, les formats de date et la possibilité de nullabilité des champs

Lorsque vous travaillez avec un système multilocataire, le cas échéant, normalisez et utilisez le même format de données pour tous vos locataires. Cette approche vous permet d’éviter de devoir personnaliser et retester vos composants d’intégration pour les besoins de chaque locataire. Toutefois, certains scénarios nécessitent différents formats de données pour communiquer avec différents locataires. Vous devrez peut-être donc implémenter plusieurs intégrations. Pour une approche qui peut vous aider à simplifier ce type de scénario, consultez les composants d’intégration composables.

Accès aux systèmes des locataires

Certaines intégrations vous obligent à établir une connexion aux systèmes ou magasins de données de votre locataire. Lorsque vous vous connectez aux systèmes de votre locataire, vous devez examiner attentivement les composants de gestion de réseau et d’identité de la connexion.

Accès réseau

Réfléchissez à la topologie de réseau pour accéder au système de votre locataire, laquelle peut inclure les options suivantes :

• Les connexions Internet peuvent poser des problèmes concernant la sécurisation de la connexion et le chiffrement des données. Déterminez comment sécuriser la connexion et chiffrer les données lorsque vous vous connectez sur Internet. Si vos locataires prévoient de restreindre l’accès en fonction de vos adresses IP, assurez-vous que les services Azure que votre solution utilise peuvent prendre en charge les adresses IP statiques pour les connexions sortantes. Par exemple, envisagez d’utiliser la passerelle NAT Azure pour fournir des adresses IP statiques, si nécessaire. Si vous avez besoin d’un VPN, réfléchissez à la manière d’échanger des clés en toute sécurité avec vos locataires.

• Les agents, déployés dans l’environnement d’un locataire, peuvent fournir une approche flexible. Les agents peuvent également vous aider à éviter la nécessité pour vos locataires d’autoriser les connexions entrantes.

• Les relais, comme Azure Relay, fournissent également une approche pour éviter les connexions entrantes.

Pour plus d’informations, consultez Approches réseau pour la multi-tenant.

Authentification

Réfléchissez à la façon dont vous vous authentifiez auprès de chaque locataire lorsque vous établissez une connexion. Tenez compte des approches suivantes :

• Les secrets, tels que les clés API ou les certificats. Il est important de planifier la gestion sécurisée des informations d’identification de vos locataires. Les fuites de secrets de vos locataires peuvent entraîner un incident de sécurité majeur, ce qui peut potentiellement affecter de nombreux locataires.

• Jetons Microsoft Entra, où vous utilisez un jeton que l’annuaire Microsoft Entra du locataire émet. Le jeton peut être émis directement à votre charge de travail à l’aide d’une inscription d’application Microsoft Entra multilocataire ou d’un principal de service spécifique. Votre charge de travail peut également demander une autorisation déléguée pour accéder aux ressources pour le compte d’un utilisateur spécifique dans l’annuaire du locataire.

Quelle que soit l’approche que vous sélectionnez, assurez-vous que vos locataires respectent le principe de privilège minimum et n’accordent pas vos autorisations inutiles au système. Par exemple, si votre système doit uniquement lire des données à partir du magasin de données d’un locataire, l’identité utilisée par votre système ne doit pas disposer d’autorisations d’écriture.

Accès des locataires à vos systèmes

Si les locataires doivent se connecter à votre système, envisagez de fournir des API dédiées ou d’autres points d’intégration. Vous pouvez ensuite modéliser ces points d’intégration dans le cadre de la surface d’exposition de votre solution.

Dans certains scénarios, vous pouvez décider de fournir à vos locataires un accès direct à vos ressources Azure. Tenez compte des ramifications soigneusement et assurez-vous que vous comprenez comment accorder l’accès aux locataires de manière sécurisée. Par exemple, vous pouvez utiliser l’une des approches suivantes :

• Utilisez le modèle Valet Key, qui utilise des mesures de sécurité telles que des jetons SAP (Shared Access Signatures) pour accorder un accès restreint à des ressources Azure spécifiques.

• Utilisez des ressources dédiées pour les points d’intégration, comme un compte de stockage dédié. Il est recommandé de séparer les ressources d’intégration de vos ressources système principales. Cette approche vous aide à réduire le rayon d’explosion d’un incident de sécurité. Il garantit également que si un locataire initie accidentellement un grand nombre de connexions à la ressource et épuise sa capacité, le reste de votre système continue à s’exécuter.

Conformité

Lorsque vous interagissez ou transmettez directement les données de vos locataires, il est essentiel que vous compreniez clairement les exigences de gouvernance et de conformité de vos locataires.

Approches et modèles

Exposer des API

Les intégrations en temps réel impliquent souvent l’exposition d’API pour que vos locataires ou d’autres parties puissent les utiliser. Les API nécessitent des considérations particulières, en particulier lorsque des parties externes les utilisent. Tenez compte des facteurs suivants :

• Définissez qui peut accéder à l’API.

• Authentifier les utilisateurs de l’API à l’aide d’une méthode sécurisée et fiable.

• Définissez une limite sur le nombre de requêtes que chaque utilisateur d’API peut effectuer sur une période spécifique.

• Fournissez des informations claires et de la documentation pour chaque API. Si nécessaire, implémentez un portail de développement pour prendre en charge la découverte et l’intégration.

Une bonne pratique consiste à utiliser une passerelle d’API, comme Gestion des API Azure, pour gérer ces problèmes et bien d’autres. Les passerelles d’API vous donnent un emplacement unique pour implémenter des stratégies que vos API suivent. Ils simplifient également l’implémentation de vos systèmes d’API back-end. Pour plus d’informations, consultez Utiliser gestion des API dans une solution mutualisée.

Modèle de clé de valet

Parfois, un locataire peut avoir besoin d’un accès direct à une source de données, comme le Stockage Azure. Envisagez de suivre le modèle de clé de valet pour partager des données de manière sécurisée et limiter l’accès au magasin de données.

Par exemple, vous pouvez utiliser cette approche pour exporter par lots un fichier de données volumineux. Après avoir généré le fichier d’exportation, vous pouvez l’enregistrer dans un conteneur blob dans Azure Storage, puis générer une SAS limitée dans le temps et en lecture seule. Cette signature peut être fournie au locataire, accompagnée de l'URL du blob. Le locataire peut ensuite télécharger le fichier à partir du stockage Azure jusqu’à la date d’expiration de la signature.

De même, vous pouvez générer un SAS avec des autorisations d’écriture dans un objet blob spécifique. Lorsque vous fournissez un SAS à un locataire, celui-ci peut écrire ses données dans le BLOB. En utilisant l’intégration d’Event Grid pour le Stockage Azure, votre application peut ensuite être avertie qu’elle doit traiter et importer le fichier de données.

Points d'ancrage Web (Webhooks)

Les webhooks vous permettent d’envoyer des événements à vos locataires à une URL qu’ils vous fournissent. Lorsque vous avez des informations à envoyer, vous établissez une connexion au webhook du locataire et vous incluez vos données dans la charge utile de requête HTTP.

Si vous choisissez de construire votre propre système d’événements webhook, envisagez de suivre la norme CloudEvents pour simplifier les exigences d’intégration de vos clients.

Vous pouvez également utiliser un service comme Event Grid pour fournir des fonctionnalités webhook. Event Grid fonctionne en mode natif avec CloudEvents et prend en charge les domaines d’événements, qui sont utiles pour les solutions mutualisées.

Accès utilisateur délégué

Lorsque vous accédez à des données à partir des magasins de données d’un locataire, déterminez si vous devez, pour cela, utiliser l’identité d’un utilisateur spécifique. Lorsque c’est le cas, votre intégration est soumise aux mêmes autorisations que celles dont dispose l’utilisateur. Cette approche est souvent appelée accès délégué.

Par exemple, supposons que votre service multilocataire exécute des modèles Machine Learning sur les données de vos locataires. Vous devez accéder aux instances de services de chaque locataire, telles que les espaces de travail Microsoft Fabric pour l’analytique, le stockage Azure et Azure Cosmos DB. Chaque locataire possède son propre annuaire Microsoft Entra. Votre solution peut bénéficier d’un accès délégué au magasin de données afin de pouvoir récupérer les données auxquelles un utilisateur spécifique peut accéder.

L’accès délégué est plus facile si le magasin de données prend en charge l’authentification Microsoft Entra. De nombreux services Azure prennent en charge les identités Microsoft Entra.

Par exemple, supposons que votre application web multilocataire et vos processus en arrière-plan doivent accéder au Stockage Azure en utilisant les identités utilisateur de vos locataires à partir de Microsoft Entra ID. Vous pouvez effectuer les étapes suivantes :

1. Créez une inscription d’application Microsoft Entra multilocataire qui représente votre solution.

2. Accordez à l'application l'autorisation déléguée d'accéder au Stockage Azure en tant qu'utilisateur authentifié.

3. Configurez votre application pour authentifier les utilisateurs à l’aide de Microsoft Entra ID.

Une fois qu’un utilisateur se connecte, Microsoft Entra ID émet pour l’application un jeton d’accès de courte durée qui peut être utilisé pour accéder au Stockage Azure pour le compte de l’utilisateur, et il émet un jeton d’actualisation de plus longue durée. Votre système doit stocker le jeton d’actualisation de manière sécurisée afin que vos processus en arrière-plan puissent obtenir de nouveaux jetons d’accès et continuer à accéder au stockage Azure pour le compte de l’utilisateur.

Messagerie

La messagerie permet une communication asynchrone et faiblement couplée entre des systèmes ou des composants. La messagerie est souvent utilisée dans les scénarios d’intégration pour dissocier les systèmes source et de destination. Pour plus d’informations sur la messagerie et l’architecture mutualisée, consultez les approches architecturales pour la messagerie dans les solutions mutualisées.

Lorsque vous utilisez la messagerie dans le cadre d’une intégration avec les systèmes de vos locataires, déterminez si vous devez utiliser des jetons SAP pour Service Bus ou Event Hubs. Les jetons SAP accordent un accès limité à vos ressources de messagerie aux utilisateurs ou systèmes externes sans leur permettre d’accéder au reste de votre sous-système de messagerie.

Dans certains scénarios, vous pouvez fournir différents contrats de niveau de service ou des garanties de qualité de service à différents locataires. Par exemple, un sous-ensemble de vos locataires peut s’attendre à ce que leurs demandes d’exportation de données soient traitées plus rapidement que d’autres. En utilisant le modèle File d’attente prioritaire, vous pouvez créer des files d’attente distinctes pour différents niveaux de priorité. Ensuite, vous pouvez utiliser différentes instances de travail pour les hiérarchiser en conséquence.

Composants d’intégration composables

Parfois, vous devrez peut-être effectuer une intégration à de nombreux locataires différents, chacun utilisant différents formats de données ou différents types de connectivité réseau.

Une approche courante dans l’intégration consiste à créer et à tester des étapes individuelles qui effectuent les types d’actions suivants :

• Récupérer des données à partir d’un magasin de données.
• Transformer les données en un format ou un schéma spécifique.
• Transmettez des données à l’aide d’un transport réseau spécifique ou à un type de destination connu.

En général, vous créez ces éléments individuels à l’aide de services comme Azure Functions et Azure Logic Apps. Vous définissez ensuite le processus d’intégration global à l’aide d’un outil tel que Logic Apps ou Azure Data Factory, qui appelle chaque étape prédéfinie.

Lorsque vous travaillez avec des scénarios d’intégration multilocataires complexes, il est utile de définir une bibliothèque d’étapes d’intégration réutilisables. Vous pouvez créer des flux de travail pour chaque locataire en composant les éléments applicables en fonction des exigences de ce locataire. Vous pouvez également exposer certains des jeux de données ou des composants d’intégration directement à vos locataires afin qu’ils puissent créer leurs propres flux de travail d’intégration.

De même, vous devrez peut-être importer des données à partir de locataires qui utilisent un format de données différent ou un transport différent des autres. Une bonne approche pour ce scénario consiste à construire des connecteurs spécifiques au locataire. Les connecteurs sont des flux de travail qui normalisent et importent les données dans un format et un emplacement standardisés. Ils déclenchent ensuite votre principal processus d’importation partagée.

Si vous devez générer une logique ou un code spécifique au locataire, envisagez de suivre le modèle de couche anti-corruption. Ce modèle vous permet d'encapsuler des composants spécifiques aux locataires et de garder le reste de votre solution inconscient de la complexité ajoutée.

Si vous utilisez un modèle de tarification hiérarchisé, vous devrez peut-être exiger que les locataires à des niveaux tarifaires bas suivent une approche standard avec un ensemble limité de formats de données et de transports. Les locataires à des niveaux tarifaires plus élevés peuvent avoir accès à plus de personnalisation ou de flexibilité dans les composants d’intégration que vous fournissez.

Antimodèles à éviter

• Exposition directe de vos bases de données principales aux utilisateurs. Lorsque les locataires accèdent à vos magasins de données principaux, il peut devenir plus difficile de sécuriser ces magasins. Ils peuvent également provoquer accidentellement des problèmes de performances qui affectent votre solution. Évitez de fournir aux clients des informations d’identification pour vos magasins de données. Ne répliquez pas les données brutes directement de votre base de données primaire vers les réplicas en lecture accessibles aux clients dans le même système de base de données. Au lieu de cela, créez des magasins de données d’intégration dédiés. Utilisez le modèle de clé valet pour exposer les données.

• Exposition d’API sans passerelle API. Les API ont des impératifs particuliers concernant le contrôle d’accès, la facturation et le contrôle. Même si vous ne prévoyez pas initialement d’utiliser des stratégies d’API, il est judicieux d’inclure une passerelle API de manière anticipée. De cette façon, si vous devez personnaliser vos stratégies d’API ultérieurement, vous n’avez pas à apporter de modifications cassants aux URL dont dépend un client externe.

• Couplage fort inutile. Le couplage faible, comme lors de l’utilisation d’approches de messagerie, peut offrir un large éventail d’avantages pour la sécurité, l’isolation des performances et la résilience. Si possible, vous devez coupler vos intégrations avec des systèmes externes. Si devez effectuer un couplage fort à un système externe, veillez à suivre les bonnes pratiques telles que le modèle Nouvelle tentative, le modèle Disjoncteur et le modèle Cloisonnement.

• Intégrations personnalisées pour des locataires spécifiques. Les fonctionnalités ou le code propres au locataire peuvent rendre votre solution plus difficile à tester. Cela rend également plus difficile la modification de votre solution à l’avenir, car vous devez comprendre plus de chemins de code. Au lieu de cela, essayez de créer des composants composables qui abstraitent les exigences pour un locataire spécifique et les réutilisent sur plusieurs locataires qui ont des exigences similaires.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Principaux auteurs :

• John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

Autres contributeurs :

• Will Velida | Ingénieur clientèle 2, Azure FastTrack
• Filipe Moreira | Architecture de solution cloud

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Ressource associée

• Approches architecturales pour la messagerie dans les solutions multilocataires