Modifier une architecture de zone d'atterrissage Azure pour répondre aux exigences de plusieurs emplacements

Les organisations de nombreux secteurs sont soumises à des exigences réglementaires, notamment la résidence des données, la sécurité des données et les exigences de souveraineté des données. Certaines organisations doivent se conformer aux réglementations contradictoires sur plusieurs localisations géographiques. Dans ce cas, elles doivent modifier leur architecture de zone d'atterrissage Azure conformément à toutes les réglementations applicables.

Par exemple, il peut y avoir deux réglementations contradictoires, la réglementation A et la réglementation B. La réglementation A peut exiger la résidence des données dans le pays ou la région A, et la réglementation B peut exiger la résidence des données dans le pays ou la région B.

Ces conflits réglementaires peuvent s'appliquer aux entités suivantes :

• Les organisations multinationales, notamment les sociétés multinationales ou les organisations non gouvernementales (ONG), qui doivent respecter les réglementations locales dans les pays ou régions dans lesquels elles opèrent.

• Les fournisseurs de logiciel indépendants qui fournissent des solutions aux organisations dans plusieurs emplacements, et la solution doivent se conformer aux réglementations locales de chaque emplacement.

• Les fournisseurs de logiciel indépendants qui fournissent des solutions aux organisations multinationales qui doivent se conformer aux réglementations locales de chaque pays ou région dans lequel elles opèrent.

Si vous n'avez besoin de respecter qu'un seul jeu d'exigences réglementaires, consultez Personnaliser l'architecture de la zone d'atterrissage Azure pour répondre aux exigences.

Considérations réglementaires

Les exigences réglementaires sont généralement liées à la protection des données, à la résidence des données, aux transferts de données, à l'isolation ou à l'autorisation du personnel. Ces exigences peuvent être contradictoires entre plusieurs localisations géographiques. Par exemple, une réglementation de l'Union européenne (UE) peut exiger la résidence des données dans un pays de l'UE, tandis qu'une réglementation du Royaume-Uni peut exiger la résidence des données au Royaume-Uni.

Si les réglementations entraînent des contrôles de stratégie contradictoires, vous devez ajuster l'architecture de la zone d'atterrissage Azure et les affectations de stratégie en conséquence. Pour plus d'informations, consultez la section de cet article intitulée Scénarios qui nécessitent une modification.

Lorsque plusieurs réglementations s'appliquent, vous n'avez pas besoin de modifier l'architecture de la zone d'atterrissage Azure dans les cas suivants :

• Plusieurs réglementations nécessitent des affectations Azure Policy identiques.

• Les contrôles d'une réglementation sont un super jeu d'une autre réglementation. Les contrôles d'un super jeu s'appliquent automatiquement aux deux réglementations.

• Les contrôles de plusieurs réglementations ne se chevauchent pas. Lorsque vous implémentez plusieurs jeux de contrôles, une seule implémentation couvre toutes les réglementations. Les affectations Azure Policy sont complémentaires.

• Diverses réglementations ont différents types d'implémentation. Dans la perspective réglementaire, l'implémentation que vous choisissez importe peu. Par exemple, il peut y avoir deux réglementations qui ont chacun un modèle d'autorisation différent, mais les deux modèles d'autorisation sont acceptables. Vous pouvez choisir l'implémentation qui convient le mieux à votre organisation.

Considérations relatives aux fournisseurs de logiciel indépendants

Il existe trois modèles de déploiement pour les fournisseurs de logiciels indépendants.

• Software as a service (SaaS) Épuré : le fournisseur de logiciel indépendant fournit la solution en tant que service.

• Déployé par le client : le client déploie la solution dans son propre environnement.

• SaaS à double déploiement : ce modèle combine le modèle déployé par le client et le modèle SaaS Épuré.

Dans un modèle SaaS Épuré, le fournisseur de logiciel indépendant est responsable de la gestion de la conformité au nom du client. Le fournisseur de logiciel indépendant doit démontrer la conformité au client et potentiellement aux auditeurs ou aux organismes de réglementation. Si vous utilisez le modèle SaaS, votre architecture peut être soumise à plusieurs réglementations qui peuvent être contradictoires. Le fournisseur de logiciel indépendant doit gérer la conformité pour ces différentes réglementations. Pour plus d'informations, consultez la section de cet article intitulée Scénarios qui nécessitent une modification.

Dans un modèle déployé par le client, le client est responsable de la gestion de la conformité. Pour ce modèle, le fournisseur de logiciel indépendant n'a pas besoin de modifier les zones d'atterrissage. Toutefois, la solution est déployée dans une zone d'atterrissage que le client déploie, y compris les contrôles de stratégie et les stratégies personnalisées.

Dans un modèle SaaS à double déploiement, toutes les considérations relatives au modèle SaaS déployé par le client et Épuré s'appliquent.

Considérations relatives aux organisations multinationales

Les organisations multinationales utilisent différentes structures pour organiser leur gouvernance informatique.

• Structure décentralisée : les fonctions informatiques sont régies localement dans chaque localisation géographique.

• Structure centralisée: les fonctions informatiques sont régies à partir d'un lieu centralisé, généralement le siège social de l'organisation.

• Structure hybride : les fonctions informatiques globales sont fournies de manière centralisée, tandis que les fonctions informatiques requises uniquement localement sont régies dans chaque localisation géographique.

Dans un scénario décentralisé, l'équipe informatique locale est responsable de la gestion de la conformité et peut adapter sa zone d'atterrissage en conséquence.

Dans un scénario centralisé, l'équipe informatique centrale est responsable de la gestion de la conformité. Elle doit s'assurer que les solutions répondent aux exigences de conformité locales de toutes les localisations géographiques où opère l'organisation multinationale. Les exigences de conformité de différentes localisations géographiques peuvent être contradictoires et il peut être nécessaire de modifier les zones d'atterrissage.

Dans un scénario hybride, les considérations relatives aux scénarios décentralisés et centralisés s'appliquent. L'organisation centralisée fournit des solutions que les organisations locales doivent déployer dans leur environnement. L'organisation centralisée teste également que ces solutions sont déployées dans toutes les zones d'atterrissage des organisations locales.

Scénarios nécessitant une modification

Vous devrez peut-être modifier les zones d'atterrissage s'il existe des jeux de stratégies contradictoires qui sont attribués à différents déploiements. Il peut y avoir plusieurs solutions ou une solution unique qui doit être mise à la disposition de différentes localisations géographiques ou classifications de données.

La quantité de modifications requise dépend du niveau d'isolation que la réglementation exige. Plus les conditions d'une réglementation sont remplies, plus la zone d'atterrissage doit être modifiée. Par exemple, si les réglementations nécessitent des conditions telles que le personnel effacé, divers fournisseurs d'identité ou répertoires, une infrastructure de gestion distincte ou une infrastructure de connectivité distincte, la zone d'atterrissage nécessite une modification étendue. Si les réglementations exigent uniquement que l'infrastructure d'application et de connectivité soit isolée, la zone d'atterrissage a besoin d'une modification minimale.

Clients Microsoft Entra

Nous vous recommandons d'utiliser un seul client Microsoft Entra pour la plupart des scénarios, y compris les scénarios multinationaux. Toutefois, il existe des scénarios où vous pouvez préférer ou exiger plusieurs clients Microsoft Entra. Il s’agit notamment des scénarios suivants :

• Si vous devez séparer le client Microsoft Entra d'entreprise du client Microsoft Entra SaaS pour améliorer la sécurité et créer des limites claires entre le produit et les opérations d'entreprise.

• Si des réglementations contradictoires s'appliquent et que vous avez besoin de clients Microsoft Entra distincts pour différents régimes réglementaires. Par exemple, les réglementations peuvent avoir des exigences d'autorisation et de nationalité qui nécessitent une isolation complète entre les clients Microsoft Entra ou les exigences de résidence des données qui nécessitent des clients distincts. Les scénarios courants incluent un fournisseur de logiciel indépendant qui doit déployer des instances isolées d'une solution SaaS ou une organisation multinationale qui doit déployer des instances isolées de la même solution.

Lorsque vous collaborez sur plusieurs clients Microsoft Entra, vous devez planifier soigneusement les défis et les besoins importants. Créez uniquement le nombre minimal de clients Microsoft Entra dont vous avez besoin pour répondre aux exigences opérationnelles ou réglementaires. Vous pouvez utiliser des groupes d'administration et le contrôle d’accès en fonction du rôle (RBAC) d’Azure pour régir l'accès aux abonnements et aux ressources d'un même client, comme décrit dans la section suivante.

Les diagrammes suivants montrent les options que vous pouvez utiliser pour organiser les clients Microsoft Entra.

Pour plus d'informations, consultez les zones d'atterrissage Azure et plusieurs clients Microsoft Entra et considérations relatives aux fournisseurs de logiciels indépendants pour les zones d'atterrissage Azure.

Groupes d'administration

Si vous n'avez pas besoin de clients Microsoft Entra distincts afin de fournir une isolation stricte, vous devez déployer plusieurs zones d'atterrissage Azure dans un seul client Microsoft Entra. Vous pouvez ajuster la hiérarchie des groupes d'administration pour répondre aux exigences des réglementations contradictoires.

Vous pouvez déployer une architecture complète de zone d'atterrissage pour chaque jeu de réglementations que vous souhaitez séparer. Ce modèle nécessite une quantité minimale de personnalisation et vous permet de bénéficier de l'automatisation existante pour le déploiement.

Groupe d'administration de plateforme

Si la réglementation l'autorise, le groupe d'administration de la plateforme peut être partagé. Vous pouvez créer des groupes d'administration distincts sous le groupe d'administration de zone d'atterrissage pour chaque jeu de réglementations qui doivent être séparés. Vous pouvez affecter les stratégies appropriées à chacun des groupes d'administration d'applications. Les zones d'atterrissage de l'application partagent les groupes d'administration qui se trouvent sous le groupe d'administration de la plateforme. Les ressources des groupes d'administration d'applications peuvent également être séparées par abonnement ou groupe de ressources.

Cette hiérarchie de groupes d'administration est une conception simple et rentable pour isoler les applications avec des réglementations contradictoires. Toutefois, dans cette conception, les groupes d'administration de plateforme pour la connectivité, l'identité/sécurité et la gestion doivent partager le même jeu de stratégies. Vous pouvez avoir besoin de jeux de stratégies différents pour chaque groupe d'administration de plateforme si la réglementation impose des restrictions sur le partage de l'infrastructure de connectivité, des services d'identité, des services de gestion de clés ou de l'infrastructure à partir de laquelle l'environnement entier est managé.

Isoler l'identité et la sécurité

Si les réglementations vous empêchent de partager l'infrastructure de gestion des identités et des clés, vous pouvez diviser le groupe d'administration de la plateforme. Conservez les groupes d'administration pour la connectivité et la gestion dans le groupe d'administration de plateforme partagée et disposez d'un groupe d'administration d'identité et de sécurité associé à chaque jeu de réglementations.

Cette hiérarchie de groupe d'administration est beaucoup plus complexe qu'un groupe d'administration de plateforme entièrement partagé, car vous devez répliquer partiellement le groupe d'administration de la plateforme. Pour limiter la complexité, vous pouvez déployer la hiérarchie complète pour chacun des jeux de réglementations et l'environnement partagé, et ignorer ou supprimer les groupes d'administration superflus.

Isoler la connectivité

De nombreuses réglementations ont des exigences relatives au traitement et au stockage des données dans une localisation géographique donnée, avec peu d'exigences concernant la façon dont les utilisateurs se connectent aux applications. Pour ces réglementations, vous pouvez partager la gestion de connexions, comme indiqué dans l'architecture précédente. Il se peut qu'il n'existe aucune réglementation qui vous oblige à dupliquer l'infrastructure dans plusieurs régions, mais vous devrez peut-être le faire à des fins de latence. Les stratégies affectées doivent prendre en charge l'infrastructure de duplication dans plusieurs régions.

Lorsque les réglementations ont des exigences de connectivité contradictoires, vous pouvez créer un groupe d'administration de connectivité associé à chaque jeu de réglementations. Cette structure est similaire à l'architecture précédente qui associe les groupes d'administration d'identité et de sécurité à chaque jeu de réglementations.

Si les réglementations sont contradictoires pour la connectivité et également l'identité et la sécurité, vous pouvez utiliser la conception suivante.

Étapes suivantes

• Zones d'atterrissage Azure et plusieurs clients Microsoft Entra
• Considérations relatives aux fournisseurs de logiciels indépendants pour les zones d'atterrissage Azure
• Microsoft Cloud Adoption Framework pour Azure
• Microsoft Entra ID et résidence des données
• Vue d'ensemble du pilier de sécurité
• Recommandations la gestion des identités et des accès
• Personnaliser l'architecture d'une zone d'atterrissage Azure pour répondre aux besoins