Een Architectuur voor een Azure-landingszone wijzigen om te voldoen aan de vereisten op meerdere locaties
Organisaties in veel branches zijn onderworpen aan wettelijke vereisten, waaronder vereisten voor gegevenslocatie, gegevensbeveiliging en gegevenssoevereine. Sommige organisaties moeten voldoen aan conflicterende regelgeving op meerdere geografische locaties. In dit geval moeten ze hun Architectuur van de Azure-landingszone wijzigen in overeenstemming met alle toepasselijke voorschriften.
Er kunnen bijvoorbeeld twee conflicterende regelgeving, verordening A en verordening B zijn. Verordening A vereist mogelijk gegevenslocatie in land of regio A, en verordening B vereist mogelijk gegevenslocatie in land of regio B.
Dergelijke regelgevingsconflicten kunnen van toepassing zijn op:
Multinationale organisaties, zoals multinationale bedrijven of niet-gouvernementele organisaties (NGO's), die moeten voldoen aan lokale voorschriften in de landen of regio's waarin ze werkzaam zijn.
Onafhankelijke softwareleveranciers (ISV's) die oplossingen bieden aan organisaties op meerdere locaties en de oplossing moet voldoen aan de lokale voorschriften op elke locatie.
ISV's die oplossingen bieden aan multinationale organisaties die moeten voldoen aan de lokale voorschriften van elk land of elke regio waarin ze werkzaam zijn.
Als u slechts aan één set wettelijke vereisten hoeft te voldoen, raadpleegt u De architectuur van de Azure-landingszone aanpassen om te voldoen aan de vereisten.
Overwegingen voor regelgeving
Wettelijke vereisten zijn doorgaans gerelateerd aan gegevensbescherming, gegevenslocatie, gegevensoverdracht, isolatie of personeelsmachtiging. Deze vereisten kunnen conflicteren tussen meerdere geografische locaties. Voor een verordening van de Europese Unie (EU) kan bijvoorbeeld gegevenslocatie in een EU-land vereist zijn, terwijl voor een verordening van het Verenigd Koninkrijk mogelijk gegevenslocatie in het Verenigd Koninkrijk vereist is.
Als regelgeving leidt tot conflicterende beleidscontroles, moet u de architectuur van de Azure-landingszone en beleidstoewijzingen dienovereenkomstig aanpassen. Zie de sectie in dit artikel, Scenario's die moeten worden gewijzigd voor meer informatie.
Wanneer er meerdere voorschriften van toepassing zijn, hoeft u de Architectuur van de Azure-landingszone niet te wijzigen als:
Voor meerdere voorschriften zijn identieke Azure Policy-toewijzingen vereist.
De controles in de ene verordening vormen een superset van een andere verordening. De supersetcontroles zijn automatisch van toepassing op beide voorschriften.
De besturingselementen in meerdere voorschriften overlappen elkaar niet. Wanneer u meerdere controlesets implementeert, is één implementatie van toepassing op alle regelgeving. Azure Policy-toewijzingen zijn complementair.
Verschillende voorschriften hebben verschillende soorten implementaties. Vanuit regelgevingsperspectief maakt het niet uit welke implementatie u kiest. Er kunnen bijvoorbeeld twee voorschriften zijn die elk een ander autorisatiemodel hebben, maar beide autorisatiemodellen zijn acceptabel. U kunt de implementatie kiezen die het beste past bij uw organisatie.
Tip
U moet ernaar streven om zo weinig mogelijk beleidstoewijzingen en uitzonderingen of uitzonderingen te hebben.
Overwegingen voor ISV's
Er zijn drie implementatiemodellen voor ISV's.
Pure Software as a Service (SaaS): De ISV biedt de oplossing als een service.
Klant geïmplementeerd: De klant implementeert de oplossing in hun eigen omgeving.
SaaS met dubbele implementatie: dit model combineert het door de klant geïmplementeerde model en het pure SaaS-model.
In een puur SaaS-model is de ISV verantwoordelijk voor het beheren van naleving namens de klant. De ISV moet de naleving van de klant en mogelijk aan auditors of toezichthouders aantonen. Als u het SaaS-model gebruikt, is uw architectuur mogelijk onderhevig aan meerdere voorschriften die conflicteren. De ISV moet naleving voor deze verschillende voorschriften beheren. Zie de sectie in dit artikel, Scenario's die moeten worden gewijzigd voor meer informatie.
In een door de klant geïmplementeerd model is de klant verantwoordelijk voor het beheren van naleving. Voor dit model hoeft de ISV de landingszones niet te wijzigen. De oplossing wordt echter geïmplementeerd in een landingszone die de klant implementeert, inclusief beleidscontroles en aangepaste beleidsregels.
Tip
ISV's kunnen beleidsinitiatieven richten op bepaalde nalevingsvereisten om een oplossing te testen. Deze procedure kan helpen bij het minimaliseren van de kans op conflicten met beleidsregels die klanten gebruiken om te voldoen aan hun nalevingsvereisten.
In een SaaS-model met dubbele implementatie zijn alle overwegingen voor het door de klant geïmplementeerde en pure SaaS-model van toepassing.
Overwegingen voor multinationale organisaties
Multinationale organisaties gebruiken verschillende structuren om hun IT-governance te organiseren.
Gedecentraliseerde structuur: IT-functies worden lokaal beheerd op elke geografische locatie.
Gecentraliseerde structuur: IT-functies worden beheerd vanaf een centrale locatie, meestal het hoofdkantoor van de organisatie.
Hybride structuur: globale IT-functies worden centraal geleverd, terwijl IT-functies die alleen lokaal zijn vereist, worden beheerd op elke geografische locatie.
In een gedecentraliseerd scenario is het lokale IT-team verantwoordelijk voor het beheren van naleving en kan de landingszone dienovereenkomstig aanpassen.
In een gecentraliseerd scenario is het centrale IT-team verantwoordelijk voor het beheren van naleving en moet ervoor zorgen dat oplossingen voldoen aan de lokale nalevingsvereisten van alle geografische locaties waar de multinationale organisatie actief is. De nalevingsvereisten van verschillende geografische locaties kunnen conflicteren en het kan nodig zijn om landingszones te wijzigen.
In een hybride scenario zijn de overwegingen voor zowel de gedecentraliseerde als gecentraliseerde scenario's van toepassing. De gecentraliseerde organisatie biedt oplossingen die de lokale organisaties in hun omgeving moeten implementeren. De gecentraliseerde organisatie test ook of deze oplossingen worden geïmplementeerd in alle landingszones van de lokale organisaties.
Scenario's waarvoor wijziging is vereist
Mogelijk moet u landingszones wijzigen als er conflicterende beleidssets zijn die zijn toegewezen aan verschillende implementaties. Er kunnen meerdere oplossingen zijn of één oplossing die beschikbaar moet worden gesteld aan verschillende geografische locaties of gegevensclassificaties.
De benodigde hoeveelheid aanpassingen hangt af van het isolatieniveau waarvoor de verordening vraagt. Hoe meer voorwaarden een verordening heeft, hoe meer de landingszone moet worden gewijzigd. Als regelgeving bijvoorbeeld voorwaarden vereist, zoals gewist personeel, verschillende id-providers of mappen, afzonderlijke beheerinfrastructuur of afzonderlijke connectiviteitsinfrastructuur, vereist de landingszone uitgebreide aanpassingen. Als regelgeving alleen vereist dat de toepassings- en connectiviteitsinfrastructuur worden geïsoleerd, moet de landingszone minimaal worden gewijzigd.
Microsoft Entra-tenants
We raden u aan één Microsoft Entra-tenant te gebruiken voor de meeste scenario's, waaronder multinationale scenario's. Er zijn echter scenario's waarin u mogelijk meerdere Microsoft Entra-tenants wilt of vereisen, zoals:
Als u de zakelijke Microsoft Entra-tenant moet scheiden van de SaaS Microsoft Entra-tenant om de beveiliging te verbeteren en duidelijke grenzen te creëren tussen het product en de bedrijfsvoering.
Als conflicterende regelgeving van toepassing is en u afzonderlijke Microsoft Entra-tenants nodig hebt voor verschillende regelgevingsregelingen. Regelgeving kan bijvoorbeeld goedkeurings- en nationaliteitsvereisten hebben die volledige isolatie nodig hebben tussen Microsoft Entra-tenants of vereisten voor gegevenslocatie waarvoor afzonderlijke tenants zijn vereist. Veelvoorkomende scenario's zijn een ISV die geïsoleerde exemplaren van een SaaS-oplossing of een multinationale organisatie moet implementeren die geïsoleerde exemplaren van dezelfde oplossing moet implementeren.
Wanneer u met meerdere Microsoft Entra-tenants samenwerkt, moet u zorgvuldig plannen voor grote uitdagingen en behoeften. Maak alleen het minimale aantal Microsoft Entra-tenants dat u nodig hebt om te voldoen aan operationele of wettelijke vereisten. U kunt beheergroepen en op rollen gebaseerd toegangsbeheer (RBAC) van Azure gebruiken om de toegang tot abonnementen en resources onder één tenant te beheren, zoals beschreven in de volgende sectie.
Tip
De Microsoft Entra-tenant die u voor uw landingszone selecteert, heeft geen invloed op de verificatie op toepassingsniveau. U kunt nog steeds andere id-providers gebruiken, ongeacht welke tenant u kiest. Voor overheidsklanten en -klanten in gereguleerde branches worden eindgebruikersidentiteiten doorgaans verstrekt wanneer u integreert met een goedgekeurde id-provider, zoals een door de overheid of gecertificeerde id-provider.
In de volgende diagrammen ziet u opties die u kunt gebruiken om Microsoft Entra-tenants te organiseren.
Tip
Als u meerdere Microsoft Entra-tenants hebt om te voldoen aan wettelijke vereisten, noemt u de tenants op basis van de geografische locatie in plaats van specifieke regelgeving, bijvoorbeeld contoso-ops-us.com in het voorbeelddiagram.
Zie Azure-landingszones en meerdere Microsoft Entra-tenants en ISV-overwegingen voor Azure-landingszones voor meer informatie.
Beheergroepen
Als u geen afzonderlijke Microsoft Entra-tenants nodig hebt om strikte isolatie te bieden, moet u meerdere Azure-landingszones implementeren in één Microsoft Entra-tenant. U kunt de hiërarchie van de beheergroep aanpassen om te voldoen aan de vereisten van conflicterende regelgeving.
U kunt een volledige architectuur voor landingszones implementeren voor elke set regelgeving die u wilt scheiden. Voor dit model is de minste hoeveelheid aanpassingen vereist en kunt u profiteren van bestaande automatisering voor implementatie.
Notitie
In dit diagram worden niet alle beheergroepen weergegeven.
De platformbeheergroep delen
Als regelgeving toestaat, kan de platformbeheergroep worden gedeeld. U kunt afzonderlijke beheergroepen maken onder de beheergroep voor landingszones voor elke set regels die moeten worden gescheiden. U kunt het juiste beleid toewijzen aan elk van de toepassingsbeheergroepen. De landingszones van de toepassing delen de beheergroepen die zich onder de platformbeheergroep bevinden. De resources in de toepassingsbeheergroepen kunnen ook worden gescheiden door een abonnement of resourcegroep.
Deze beheergroephiërarchie is een eenvoudig en rendabel ontwerp voor het isoleren van toepassingen met conflicterende regelgeving. In dit ontwerp moeten de platformbeheergroepen voor connectiviteit, identiteit/beveiliging en beheer echter dezelfde beleidsset delen. Mogelijk hebt u verschillende beleidssets nodig voor elke platformbeheergroep als regelgeving beperkingen oplegt voor het delen van connectiviteitsinfrastructuur, identiteitsservices, sleutelbeheerservices of de infrastructuur waaruit de hele omgeving wordt beheerd.
Identiteit en beveiliging isoleren
Als regelgeving verhindert dat u de infrastructuur voor identiteits- en sleutelbeheer deelt, kunt u de platformbeheergroep verdelen. Behoud de beheergroepen voor connectiviteit en beheer in de beheergroep voor gedeelde platforms en heb een identiteits- en beveiligingsbeheergroep die is gekoppeld aan elke set regelgeving.
Deze beheergroephiërarchie is aanzienlijk complexer dan een volledig gedeelde platformbeheergroep, omdat u de platformbeheergroep gedeeltelijk moet repliceren. Als u de complexiteit wilt beperken, kunt u de volledige hiërarchie implementeren voor elk van de regelsets en de gedeelde omgeving en de overbodige beheergroepen negeren of verwijderen.
Connectiviteit isoleren
Veel voorschriften hebben vereisten met betrekking tot het verwerken en opslaan van gegevens op een bepaalde geografische locatie, met weinig vereisten over hoe gebruikers verbinding maken met toepassingen. Voor deze voorschriften kunt u het connectiviteitsbeheer delen, zoals wordt weergegeven in de vorige architectuur. Er zijn mogelijk geen voorschriften waarvoor u infrastructuur in meerdere regio's moet dupliceren, maar mogelijk moet u dit doen voor latentiedoeleinden. Het toegewezen beleid moet ondersteuning bieden voor het dupliceren van infrastructuur in meerdere regio's.
Wanneer regelgeving conflicterende connectiviteitsvereisten heeft, kunt u een connectiviteitsbeheergroep maken die is gekoppeld aan elke set regelgeving. Deze structuur is vergelijkbaar met de vorige architectuur die identiteits- en beveiligingsbeheergroepen koppelt aan elke set regelgeving.
Als regelgeving conflicteert voor connectiviteit en ook identiteit en beveiliging, kunt u het volgende ontwerp gebruiken.
Volgende stappen
- Azure-landingszones en meerdere Microsoft Entra-tenants
- ISV-overwegingen voor Azure-landingszones
- Microsoft Cloud Adoption Framework voor Azure
- Microsoft Entra-id en gegevenslocatie
- Overzicht van de pijler voor beveiliging
- Aanbevelingen voor identiteits- en toegangsbeheer
- De architectuur van de Azure-landingszone aanpassen aan de vereisten