Ändra en Arkitektur för Azure-landningszoner för att uppfylla kraven på flera platser

Organisationer i många branscher omfattas av regelkrav, inklusive krav på datahemlighet, datasäkerhet och datasuveränitet. Vissa organisationer måste följa motstridiga regler på flera geografiska platser. I det här fallet måste de ändra sin Arkitektur för Azure-landningszoner i enlighet med alla tillämpliga regler.

Det kan till exempel finnas två motstridiga bestämmelser, förordning A och förordning B. Förordning A kan kräva datahemvist i land eller region A, och förordning B kan kräva datahemvist i land eller region B.

Sådana regelkonflikter kan gälla för:

• Multinationella organisationer, till exempel multinationella företag eller icke-statliga organisationer som måste följa lokala regler i de länder eller regioner som de är verksamma i.

• Oberoende programvaruleverantörer (ISV:er) som tillhandahåller lösningar till organisationer på flera platser, och lösningen måste följa de lokala reglerna på varje plats.

• ISV:er som tillhandahåller lösningar till multinationella organisationer som måste följa de lokala reglerna för varje land eller region som de är verksamma i.

Om du bara behöver uppfylla en enda uppsättning regelkrav kan du läsa Anpassa Arkitekturen för Azure-landningszoner för att uppfylla kraven.

Regelöverväganden

Regelkrav gäller vanligtvis dataskydd, datahemvist, dataöverföringar, isolering eller personalfrigång. Dessa krav kan vara i konflikt mellan flera geografiska platser. En eu-förordning (EU) kan till exempel kräva datahemvist i ett EU-land, medan en brittisk förordning kan kräva datahemvist i Storbritannien.

Om regler leder till motstridiga principkontroller måste du justera arkitekturen och principtilldelningarna i Azure-landningszonen i enlighet med detta. Mer information finns i avsnittet i den här artikeln Scenarier som kräver ändringar.

När flera regler gäller behöver du inte ändra arkitekturen för Azure-landningszonen om:

• Flera förordningar kräver identiska Azure Policy-tilldelningar.

• Kontrollerna i en förordning är en supermängd av en annan förordning. Superuppsättningskontrollerna gäller automatiskt för båda reglerna.

• Kontrollerna i flera regler överlappar inte varandra. När du implementerar flera kontrolluppsättningar omfattar en enda implementering alla regler. Azure Policy-tilldelningar kompletterar varandra.

• Olika regler har olika typer av implementering. Ur ett regelperspektiv spelar det ingen roll vilken implementering du väljer. Det kan till exempel finnas två regler som var och en har en annan auktoriseringsmodell, men båda auktoriseringsmodellerna är acceptabla. Du kan välja den implementering som passar din organisation bäst.

Överväganden för ISV:er

Det finns tre distributionsmodeller för ISV:er.

• Ren programvara som en tjänst (SaaS): ISV tillhandahåller lösningen som en tjänst.

• Kund distribuerad: Kunden distribuerar lösningen i sin egen miljö.

• SaaS med dubbel distribution: Den här modellen kombinerar den kunddistribuerade modellen och den rena SaaS-modellen.

I en ren SaaS-modell ansvarar ISV för att hantera efterlevnad för kundens räkning. Isv måste visa efterlevnad för kunden och eventuellt till granskare eller tillsynsmyndigheter. Om du använder SaaS-modellen kan din arkitektur omfattas av flera regler som kan vara i konflikt. ISV måste hantera efterlevnad för dessa olika regler. Mer information finns i avsnittet i den här artikeln Scenarier som kräver ändringar.

I en kunddistribuerad modell ansvarar kunden för att hantera efterlevnad. För den här modellen behöver ISV inte ändra landningszonerna. Lösningen distribueras dock i en landningszon som kunden distribuerar, inklusive eventuella principkontroller och anpassade principer.

I en SaaS-modell med dubbla distributioner gäller alla överväganden för den kunddistribuerade och rena SaaS-modellen.

Överväganden för multinationella organisationer

Multinationella organisationer använder olika strukturer för att organisera sin IT-styrning.

• Decentraliserad struktur: IT-funktioner styrs lokalt på varje geografisk plats.

• Centraliserad struktur: IT-funktioner styrs från en centraliserad plats, vanligtvis organisationens huvudkontor.

• Hybridstruktur: Globala IT-funktioner tillhandahålls centralt, medan IT-funktioner som krävs endast lokalt styrs på varje geografisk plats.

I ett decentraliserat scenario ansvarar det lokala IT-teamet för att hantera efterlevnad och kan skräddarsy sin landningszon i enlighet med detta.

I ett centraliserat scenario ansvarar det centrala IT-teamet för att hantera efterlevnad och måste se till att lösningarna uppfyller de lokala efterlevnadskraven för alla geografiska platser där den multinationella organisationen är verksam. Efterlevnadskraven för olika geografiska platser kan vara motstridiga och det kan vara nödvändigt att ändra landningszoner.

I ett hybridscenario gäller överväganden för både decentraliserade och centraliserade scenarier. Den centraliserade organisationen tillhandahåller lösningar som de lokala organisationerna behöver distribuera i sin miljö. Den centraliserade organisationen testar också att dessa lösningar distribueras i alla landningszoner i de lokala organisationerna.

Scenarier som kräver ändringar

Du kan behöva ändra landningszoner om det finns motstridiga principuppsättningar som har tilldelats till olika distributioner. Det kan finnas flera lösningar eller en enda lösning som måste göras tillgänglig för olika geografiska platser eller dataklassificeringar.

Den mängd ändringar som krävs beror på den isoleringsnivå som krävs i förordningen. Ju fler villkor en förordning har, desto mer måste landningszonen ändras. Om regler till exempel kräver villkor som rensad personal, olika identitetsprovidrar eller kataloger, separat hanteringsinfrastruktur eller separat anslutningsinfrastruktur, kräver landningszonen omfattande ändringar. Om reglerna bara kräver att programmet och anslutningsinfrastrukturen isoleras behöver landningszonen minimal ändring.

Microsoft Entra-klienter

Vi rekommenderar att du använder en enda Microsoft Entra-klient för de flesta scenarier, inklusive multinationella scenarier. Det finns dock scenarier där du kanske föredrar eller kräver flera Microsoft Entra-klienter, till exempel:

• Om du behöver separera företagets Microsoft Entra-klientorganisation från SaaS Microsoft Entra-klientorganisationen för att förbättra säkerheten och skapa tydliga gränser mellan produkten och verksamheten.

• Om motstridiga regler gäller och du behöver separata Microsoft Entra-klienter för olika regelsystem. Regler kan till exempel ha behörighets- och nationalitetskrav som behöver fullständig isolering mellan Microsoft Entra-klienter eller krav på datahemvist som kräver separata klienter. Vanliga scenarier är en ISV som behöver distribuera isolerade instanser av en SaaS-lösning eller en multinationell organisation som behöver distribuera isolerade instanser av samma lösning.

När du samarbetar mellan flera Microsoft Entra-klienter måste du noggrant planera för betydande utmaningar och behov. Skapa bara det minsta antalet Microsoft Entra-klienter som du behöver för att uppfylla drifts- eller regelkraven. Du kan använda hanteringsgrupper och rollbaserad åtkomstkontroll i Azure (RBAC) för att styra åtkomsten till prenumerationer och resurser under en enda klientorganisation, enligt beskrivningen i nästa avsnitt.

Följande diagram visar alternativ som du kan använda för att organisera Microsoft Entra-klienter.

Mer information finns i Azure-landningszoner och flera Microsoft Entra-klienter och ISV-överväganden för Azure-landningszoner.

Hanteringsgrupper

Om du inte behöver separata Microsoft Entra-klienter för att tillhandahålla strikt isolering bör du distribuera flera Azure-landningszoner i en enda Microsoft Entra-klientorganisation. Du kan justera hanteringsgruppshierarkin för att uppfylla kraven i motstridiga regler.

Du kan distribuera en fullständig landningszonarkitektur för varje uppsättning regler som du vill separera. Den här modellen kräver minst anpassning och gör att du kan dra nytta av befintlig automatisering för distribution.

Dela plattformshanteringsgruppen

Om förordningen tillåter kan plattformshanteringsgruppen delas. Du kan skapa separata hanteringsgrupper under hanteringsgruppen för landningszoner för varje uppsättning regler som måste separeras. Du kan tilldela lämpliga principer till var och en av programhanteringsgrupperna. Programlandningszonerna delar de hanteringsgrupper som finns under plattformshanteringsgruppen. Resurserna i programhanteringsgrupperna kan också avgränsas med prenumeration eller resursgrupp.

Den här hanteringsgruppshierarkin är en enkel och kostnadseffektiv design för att isolera program med motstridiga regler. I den här designen måste dock plattformshanteringsgrupperna för anslutning, identitet/säkerhet och hantering dela samma principuppsättning. Du kan behöva olika principuppsättningar för varje plattformshanteringsgrupp om regleringen medför begränsningar för delning av anslutningsinfrastruktur, identitetstjänster, nyckelhanteringstjänster eller den infrastruktur som hela miljön hanteras från.

Isolera identitet och säkerhet

Om regler hindrar dig från att dela infrastrukturen för identitets- och nyckelhantering kan du dela upp plattformshanteringsgruppen. Behåll hanteringsgrupperna för anslutning och hantering i den delade plattformshanteringsgruppen och ha en identitets- och säkerhetshanteringsgrupp som är associerad med varje uppsättning regler.

Den här hanteringsgruppshierarkin är betydligt mer komplex än en fullständigt delad plattformshanteringsgrupp eftersom du delvis måste replikera plattformshanteringsgruppen. För att begränsa komplexiteten kan du distribuera den fullständiga hierarkin för var och en av regeluppsättningarna och den delade miljön och ignorera eller ta bort de överflödiga hanteringsgrupperna.

Isolera anslutningen

Många regler har krav som rör bearbetning och lagring av data på en viss geografisk plats, med få krav på hur användare ansluter till program. För dessa regler kan du dela anslutningshanteringen enligt föregående arkitektur. Det kanske inte finns några regler som kräver att du duplicerar infrastrukturen i flera regioner, men du kan behöva göra det i svarstidssyfte. De tilldelade principerna måste ha stöd för duplicering av infrastruktur i flera regioner.

När regler har motstridiga anslutningskrav kan du skapa en anslutningshanteringsgrupp som är associerad med varje uppsättning regler. Den här strukturen liknar den tidigare arkitekturen som associerar identitets- och säkerhetshanteringsgrupper med varje uppsättning regler.

Om regler står i konflikt med anslutningen och även identitet och säkerhet kan du använda följande design.

Nästa steg

• Azure-landningszoner och flera Microsoft Entra-klienter
• ISV-överväganden för Azure-landningszoner
• Microsoft Cloud Adoption Framework för Azure
• Microsoft Entra-ID och datahemvist
• Översikt över säkerhetspelaren
• Rekommendationer för identitets- och åtkomsthantering
• Anpassa Arkitekturen för Azure-landningszoner efter behov