Partager via

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

  • Article

Il est courant que les systèmes s’intègrent ensemble, même au-delà des limites de l’organisation. Lorsque vous générez une solution multilocataire, vous pouvez être obligé de renvoyer des données aux systèmes de vos locataires ou de recevoir des données de ces systèmes. Dans cet article, nous décrivons les principales considérations et approches relatives à l’architecture et au développement d’intégrations pour une solution multilocataire.

Notes

Si vous fournissez plusieurs points d’intégration, il est préférable de prendre en compte chacun d’eux indépendamment. Souvent, différents points d’intégration ont des exigences différentes et sont conçus différemment, même s’ils connectent ensemble les mêmes systèmes de plusieurs façons différentes.

Principaux éléments et exigences à prendre en compte

Sens d’un flux de données

Il est important de comprendre le sens dans lequel vos données circulent. 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 :

  • L’exportation, qui signifie que les données circulent de votre système multilocataire vers les systèmes de vos locataires individuels.
  • L’importation, qui signifie que les données proviennent des systèmes de vos locataires et sont dirigées vers votre système multilocataire.

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 délégué par l’utilisateur

Dans de nombreux systèmes, l’accès à certaines données est limité à des utilisateurs spécifiques. Les données auxquelles un utilisateur peut accéder peuvent ne pas être les mêmes que celles auxquelles un autre utilisateur a accès. Il est important de déterminer si vous prévoyez d’utiliser des jeux de données complets, ou si les jeux de données que vous importez ou exportez sont basés sur ce à quoi un utilisateur spécifique est autorisé à accéder.

Prenons l’exemple de Microsoft Power BI, qui 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 soit fourni avec des informations d’identification d’une identité qui peut accéder au magasin de données complet. Ensuite, les administrateurs Power BI peuvent configurer séparément les autorisations sur les données importées après leur importation dans Power BI. Power BI applique les 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 la source de données, il utilise ses informations d’identification et les 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 a créé 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. Le système de destination obtient alors réellement la même autorisation qu’un utilisateur spécifique. Pour plus d’informations sur la délégation d’utilisateur, consultez l’approche Accès utilisateur délégué ci-dessous. Si vous utilisez la délégation, réfléchissez à la façon dont vous allez gérer les scénarios où un utilisateur est déprovisionné ou dans lesquels ses autorisations changent.

En temps réel ou par lot

Déterminez si vous utiliserez des données en temps réel ou si les données seront envoyées par lots.

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

  • La demande/réponse est l’endroit où un client lance une demande sur un serveur et reçoit une réponse. En général, 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. Par ailleurs, les demandes peuvent être asynchrones, en utilisant quelque chose comme le modèle de demande/réponse 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 des messages, et Azure Event Grid et Event Hubs fournissent des fonctionnalités de gestion d’événements. 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é à certains moments de la journée. En général, les intégrations par lots sont effectuées via un emplacement de préproduction, 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 d’évaluer le volume de données que vous échangez par le biais d’une intégration, car cette information vous aide à 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 tiers, il est important qu’ils comprennent clairement comment les données seront mises en forme et structurées. Tenez compte des parties suivantes du format de données :

  • Le format de fichier, par exemple JSON, Parquet, CSV ou XML.
  • Le schéma, par exemple la liste des champs qui seront inclus, les formats de date et la possibilité de valeur Null pour les champs.

Lorsque vous travaillez avec un système multilocataire, il est préférable, si possible, de normaliser et d’utiliser le même format de données pour tous vos locataires. De cette façon, vous évitez d’avoir à personnaliser et à retester vos composants d’intégration pour les exigences de chaque locataire. Toutefois, dans certains cas, vous devrez peut-être utiliser différents formats de données pour communiquer avec différents locataires, et donc peut-être implémenter plusieurs intégrations. Consultez la section Composants d’intégration composables pour une approche qui permet de simplifier ce type de situation.

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 :

  • Connectez-vous sur Internet. Si vous vous connectez sur Internet, comment la connexion sera-t-elle sécurisée et comment les données seront-elles chiffrées ? Si vos locataires prévoient d’appliquer une restriction en fonction de vos adresses IP, assurez-vous que les services Azure utilisés par votre solution peuvent prendre en charge les adresses IP statiques pour les connexions sortantes. Par exemple, envisagez d’utiliser une NAT Gateway 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, qui sont déployés dans l’environnement d’un locataire, peuvent fournir une approche flexible et vous aider à éviter que vos locataires autorisent les connexions entrantes.
  • Les relais, comme Azure Relay, fournissent également une approche pour éviter les connexions entrantes.

Pour plus d’informations, consultez les conseils sur les approches de la gestion de réseau pour l’architecture multilocataire.

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 façon dont vous allez gérer de manière sécurisée les informations d’identification de vos locataires. Les fuites des secrets de vos locataires peuvent entraîner un incident de sécurité majeur, ce qui peut avoir un impact sur de nombreux locataires.
  • Jetons Microsoft Entra, où vous utilisez un jeton émis par le propre annuaire Microsoft Entra du locataire. 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 des privilèges minimum et évitez d’accorder des autorisations inutiles à votre 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 des locataires doivent se connecter à votre système, envisagez de fournir des API dédiées ou d’autres points d’intégration, que vous pouvez ensuite modéliser dans le cadre de la surface d’exposition de votre solution.

Dans certains cas, vous pouvez décider de fournir à vos locataires un accès direct à vos ressources Azure. Étudiez soigneusement les conséquences et veillez à comprendre 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 de clé de valet, qui implique l’utilisation de mesures de sécurité telles que des signatures d’accès partagé pour accorder un accès restreint à certaines ressources Azure.
  • 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 permet de réduire le rayon d’impact d’un incident de sécurité. Elle garantit également que, si un locataire établit 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 commencez à interagir directement avec les données de vos locataires ou à transmettre ces données, il est essentiel que vous compreniez clairement les exigences de gouvernance et de conformité de vos locataires.

Approches et modèles à prendre en compte

Exposer des API

Les intégrations en temps réel impliquent généralement l’exposition d’API à vos locataires ou à d’autres parties pour qu’ils les utilisent. Les API nécessitent des considérations spéciales, en particulier lorsqu’elles sont utilisées par des parties externes. Posez-vous les questions suivantes :

  • Qui est autorisé à accéder à l’API ?
  • Comment authentifier les utilisateurs de l’API ?
  • Existe-t-il une limite au nombre de requêtes qu’un utilisateur d’API peut effectuer sur une période ?
  • Comment fournirez-vous des informations sur vos API et de la documentation pour chaque API ? Par exemple, devez-vous implémenter un portail de développement ?

Une bonne pratique consiste à utiliser une passerelle d’API, comme la Gestion des API Azure, pour gérer ces problèmes et bien d’autres. Les passerelles d’API constituent un emplacement unique pour vous permettre d’implémenter des stratégies suivie par vos API, et simplifient l’implémentation de vos systèmes d’API back-end. Pour en savoir plus sur la façon dont Gestion des API prend en charge l’architecture multilocataire, consultez Utiliser Gestion des API Azure dans une solution multilocataire.

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 lors de l’exportation par lots d’un fichier de données volumineux. Une fois que vous avez généré le fichier d’exportation, vous pouvez l’enregistrer dans un conteneur d’objets blob dans le Stockage Azure, puis générer une signature d’accès partagé en lecture seule limité dans le temps. Cette signature peut être fournie au locataire, en même temps que l’URL de l’objet blob. Le locataire peut ensuite télécharger le fichier à partir du Stockage Azure jusqu’à l’expiration de la signature.

De même, vous pouvez générer une signature d’accès partagé avec des autorisations d’écriture sur un objet blob spécifique. Lorsque vous fournissez une signature d’accès partagé à un locataire, il peut écrire ses données dans l’objet 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.

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 générer votre propre système d’événements webhook, envisagez de suivre la norme CloudEvents pour simplifier les exigences d’intégration de vos locataires.

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

Notes

Chaque fois que vous effectuez des connexions sortantes aux systèmes de vos locataires, n’oubliez pas que vous vous connectez à un système externe. Suivez les pratiques cloud recommandées, notamment l’utilisation du modèle Nouvelle tentative, du modèle Disjoncteur et du modèle Cloisonnement pour vous assurer que les problèmes rencontrés dans le système du locataire ne se propagent pas à votre système.

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 des services de chaque locataire, comme Azure Synapse Analytics, le Stockage Azure, Azure Cosmos DB, entre autres. Chaque locataire possède son propre annuaire Microsoft Entra. L’accès délégué au magasin de données peut être accordée à votre solution, ce qui vous permet de 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 une autorisation déléguée d’accéder au Stockage Azure en tant qu’utilisateur connecté.
  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 couramment utilisée dans des scénarios d’intégration pour dissocier les systèmes sources et de destination. Pour plus d’informations sur la messagerie et l’architecture multilocataire, consultez Approches architecturales pour la messagerie dans les solutions multilocataires.

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 signatures d’accès partagé pour Azure Service Bus ou Azure Event Hubs. Les signatures d’accès partagé vous permettent d’accorder à des tiers un accès limité à vos ressources de messagerie, sans leur permettre d’accéder au reste de votre sous-système de messagerie.

Dans certains scénarios, vous pouvez fournir des contrats de niveau de service (SLA) différents ou des garanties de qualité de service (QoS) à 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 de priorité, vous pouvez créer des files d’attente distinctes pour différents niveaux de priorité, avec différentes instances de worker 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.
  • Transmettre les données à l’aide d’un transport réseau particulier ou à d’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 comme Logic Apps ou Azure Data Factory. Ce processus appelle chacune des étapes prédéfinies.

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

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 vers d’autres locataires. Une bonne approche pour ce scénario consiste à générer desconnecteurs spécifiques au locataire. Les connecteurs sont des workflows qui normalisent et importent les données dans un format et un emplacement standardisés, puis qui déclenchent votre processus d’importation partagé principal.

Si vous devez générer une logique ou du code spécifique au locataire, envisagez de suivre le modèle Couche de lutte contre la corruption. Le modèle vous permet d’encapsuler des composants propres au locataire, sans que le reste de votre solution soit affecté par la complexité accrue.

Si vous utilisez un modèle tarifaire à plusieurs niveaux, vous pouvez choisir d’exiger que les locataires à un niveau tarifaire faible suivent une approche standard avec un ensemble limité de formats de données et de transports. Les niveaux tarifaires supérieurs peuvent permettre une plus grande personnalisation ou flexibilité dans les composants d’intégration que vous proposez.

Antimodèles à éviter

  • Exposition de vos magasins de données principaux directement aux locataires. Lorsque les locataires accèdent à vos principales bases de données, il peut devenir plus difficile de sécuriser ces bases de données, et ils pourraient accidentellement causer des problèmes de performance qui affectent votre solution. Évitez de fournir des informations d’identification pour vos bases de données à vos clients, et ne répliquez pas directement les données de votre base de données principale vers les réplicas en lecture des clients du 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, et utilisez le modèle de clé de 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. Ainsi, si vous devez personnaliser vos stratégies d’API à l’avenir, vous n’avez pas besoin d’apporter de changements cassants aux URL dont dépend un tiers.
  • 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. Dans la mesure du possible, il est judicieux de coupler faiblement vos intégrations avec des tiers. Si vous avez besoin d’effectuer un couplage fort à un tiers, veillez à suivre de 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 complique également la modification de votre solution à l’avenir, car vous devez comprendre plus de chemins de code. Au lieu de cela, essayez de générer des composants composables qui restreignent les exigences de tout locataire spécifique, et réutilisez-les sur plusieurs locataires avec des exigences similaires.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Principaux auteurs :

Autre contributeur :

  • Will Velida | Ingénieur client 2, FastTrack pour Azure

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

Étapes suivantes

Consultez Approches architecturales pour la messagerie dans les solutions multilocataires.