Dela via

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

  • Artikel

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.

Dricks

Du bör sträva efter att ha så få principtilldelningar och undantag eller undantag som möjligt.

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

Dricks

ISV:er kan rikta in sig på principinitiativ med särskilda efterlevnadskrav för att testa en lösning. Den här metoden kan bidra till att minimera risken för konflikter med principer som kunderna använder för att uppfylla sina efterlevnadskrav.

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:

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.

Dricks

Den Microsoft Entra-klient som du väljer för din landningszon påverkar inte din autentisering på programnivå. Du kan fortfarande använda andra identitetsprovidrar oavsett vilken klientorganisation du väljer. För kunder och kunder inom den offentliga sektorn i reglerade branscher tillhandahålls vanligtvis slutanvändaridentiteter när du integrerar med en godkänd identitetsprovider, till exempel en myndighetsägd eller certifierad identitetsprovider.

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

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

Dricks

Om du har flera Microsoft Entra-klienter som uppfyller regelkraven namnger du klienterna baserat på den geografiska platsen i stället för specifika regler, till exempel contoso-ops-us.com i exempeldiagrammet.

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.

A diagram that shows separate landing zones for each regulation.

Kommentar

Det här diagrammet visar inte alla hanteringsgrupper.

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.

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

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.

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

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.

A diagram that shows an architecture that isolates connectivity.

Nästa steg