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

  • Article

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.

Astuces

Vous devez vous efforcer d'avoir le plus peu d'affectations de stratégie et d'exceptions ou d'exemptions que possible.

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.

Astuces

Les fournisseurs de logiciel indépendants peuvent cibler des initiatives de stratégie à des niveaux d’exigences de conformité particulières pour tester une solution. Cette pratique peut aider à réduire le risque de conflits avec les stratégies que les clients utilisent pour répondre à leurs exigences de conformité.

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 :

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.

Astuces

Le client Microsoft Entra que vous sélectionnez pour votre zone d'atterrissage n'affecte pas l'authentification au niveau de l'application. Vous pouvez toujours utiliser d'autres fournisseurs d'identité, quel que soit le client que vous choisissez. Pour les clients du secteur public et les clients des secteurs réglementés, les identités des utilisateurs finaux sont généralement fournies lorsque vous intégrez un fournisseur d'identité approuvé, tel qu'un fournisseur d'identité certifié ou appartenant au gouvernement.

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

A diagram that shows three ways to organize Microsoft Entra tenants.

Astuces

Si vous avez plusieurs clients Microsoft Entra pour répondre aux exigences réglementaires, nommez les clients en fonction de la localisation géographique plutôt que des réglementations spécifiques, par exemple contoso-ops-us.com dans l'exemple de diagramme.

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.

A diagram that shows separate landing zones for each regulation.

Remarque

Ce diagramme n'affiche pas tous les groupes d'administration.

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é.

A diagram that shows an architecture that shares the platform management group.

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.

A diagram that shows an architecture that isolates identity and security.

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.

A diagram that shows an architecture that isolates connectivity.

Étapes suivantes