Share via

Modyfikowanie architektury strefy docelowej platformy Azure w celu spełnienia wymagań w wielu lokalizacjach

  • Artykuł

Organizacje w wielu branżach podlegają wymaganiom prawnym, w tym wymaganiom dotyczącym rezydencji danych, bezpieczeństwa danych i niezależności danych. Niektóre organizacje muszą przestrzegać sprzecznych przepisów w wielu lokalizacjach geograficznych. W takim przypadku muszą zmodyfikować architekturę strefy docelowej platformy Azure zgodnie ze wszystkimi obowiązującymi przepisami.

Na przykład mogą istnieć dwa sprzeczne przepisy, regulacje A i rozporządzenie B. Rozporządzenie A może wymagać przechowywania danych w kraju lub regionie A, a rozporządzenie B może wymagać przechowywania danych w kraju lub regionie B.

Takie konflikty regulacyjne mogą mieć zastosowanie do:

  • Organizacje wielonarodowe, takie jak międzynarodowe korporacje lub organizacje pozarządowe, które muszą być zgodne z lokalnymi przepisami w krajach lub regionach, w których działają.

  • Niezależni dostawcy oprogramowania (ISV), którzy udostępniają rozwiązania organizacjom w wielu lokalizacjach, a rozwiązanie musi być zgodne z lokalnymi przepisami w każdej lokalizacji.

  • IsV, które dostarczają rozwiązania dla organizacji międzynarodowych, które muszą być zgodne z lokalnymi przepisami każdego kraju lub regionu, w którym działają.

Jeśli musisz spełnić tylko jeden zestaw wymagań prawnych, zobacz Dostosowywanie architektury strefy docelowej platformy Azure w celu spełnienia wymagań.

Zagadnienia prawne

Wymagania prawne są zwykle związane z ochroną danych, miejscem przechowywania danych, transferami danych, izolacją lub odprawą personelu. Te wymagania mogą powodować konflikt między wieloma lokalizacjami geograficznymi. Na przykład rozporządzenie Unii Europejskiej (UE) może wymagać przechowywania danych w kraju UE, podczas gdy rozporządzenie Zjednoczonego Królestwa może wymagać przechowywania danych w Wielkiej Brytanii.

Jeśli przepisy prowadzą do konfliktowych mechanizmów kontroli zasad, należy odpowiednio dostosować architekturę strefy docelowej i przypisania zasad platformy Azure. Aby uzyskać więcej informacji, zobacz sekcję w tym artykule Scenariusze, które wymagają modyfikacji.

W przypadku zastosowania wielu przepisów nie musisz modyfikować architektury strefy docelowej platformy Azure, jeśli:

  • Wiele przepisów wymaga identycznych przypisań usługi Azure Policy.

  • Kontrole w jednym rozporządzeniu są nadzbiorem innego rozporządzenia. Kontrole nadzestawu są automatycznie stosowane do obu przepisów.

  • Kontrole w wielu przepisach nie nakładają się na siebie. Podczas implementowania wielu zestawów kontroli jedna implementacja obejmuje wszystkie przepisy. Przypisania usługi Azure Policy uzupełniają się.

  • Różne przepisy mają różne rodzaje implementacji. Z perspektywy regulacyjnej nie ma znaczenia, którą implementację wybierzesz. Na przykład mogą istnieć dwa przepisy, które mają inny model autoryzacji, ale oba modele autoryzacji są dopuszczalne. Możesz wybrać implementację, która najlepiej pasuje do twojej organizacji.

Napiwek

Należy dążyć do jak najmniejszej liczby przypisań zasad i wyjątków lub wykluczeń.

Zagadnienia dotyczące niezależnych dostawców oprogramowania

Istnieją trzy modele wdrażania niezależnych dostawców oprogramowania.

  • Czyste oprogramowanie jako usługa (SaaS): niezależnego dostawcy oprogramowania udostępnia rozwiązanie jako usługę.

  • Wdrożony przez klienta: klient wdraża rozwiązanie we własnym środowisku.

  • Model SaaS z podwójnym wdrożeniem: ten model łączy model wdrożony przez klienta i czysty model SaaS.

W czystym modelu SaaS niezależnego dostawcy oprogramowania są odpowiedzialni za zarządzanie zgodnością w imieniu klienta. Niezależni dostawcy oprogramowania muszą wykazać zgodność z klientem i potencjalnie audytorom lub regulatorom. Jeśli używasz modelu SaaS, twoja architektura może podlegać wielu przepisom, które mogą powodować konflikt. Niezależnego dostawcy oprogramowania musi zarządzać zgodnością z tymi różnymi przepisami. Aby uzyskać więcej informacji, zobacz sekcję w tym artykule Scenariusze, które wymagają modyfikacji.

W modelu wdrożonym przez klienta klient jest odpowiedzialny za zarządzanie zgodnością. W przypadku tego modelu niezależnego dostawcy oprogramowania nie musi modyfikować stref docelowych. Jednak rozwiązanie jest wdrażane w strefie docelowej wdrażanej przez klienta, w tym w przypadku kontrolek zasad i zasad niestandardowych.

Napiwek

Niezależnych dostawców oprogramowania może kierować inicjatywy zasad na określone wymagania dotyczące zgodności, aby przetestować rozwiązanie. Takie rozwiązanie może pomóc zminimalizować prawdopodobieństwo konfliktów z zasadami używanymi przez klientów w celu spełnienia wymagań dotyczących zgodności.

W modelu SaaS z podwójnym wdrożeniem mają zastosowanie wszystkie zagadnienia dotyczące modelu SaaS wdrożonego przez klienta i czystego modelu SaaS.

Zagadnienia dotyczące organizacji wielonarodowych

Organizacje wielonarodowe używają różnych struktur do organizowania ładu IT.

  • Struktura zdecentralizowana: funkcje IT są zarządzane lokalnie w każdej lokalizacji geograficznej.

  • Scentralizowana struktura: funkcje IT podlegają scentralizowanym miejscu, zazwyczaj siedzibie organizacji.

  • Struktura hybrydowa: globalne funkcje IT są udostępniane centralnie, a funkcje IT wymagane tylko lokalnie są zarządzane w każdej lokalizacji geograficznej.

W scenariuszu zdecentralizowanym lokalny zespół IT jest odpowiedzialny za zarządzanie zgodnością i może odpowiednio dostosować strefę docelową.

W scentralizowanym scenariuszu centralny zespół IT jest odpowiedzialny za zarządzanie zgodnością i musi zapewnić, że rozwiązania spełniają lokalne wymagania dotyczące zgodności wszystkich lokalizacji geograficznych, w których działa organizacja międzynarodowa. Wymagania dotyczące zgodności różnych lokalizacji geograficznych mogą powodować konflikt i może być konieczne zmodyfikowanie stref docelowych.

W scenariuszu hybrydowym mają zastosowanie zagadnienia dotyczące zarówno zdecentralizowanych, jak i scentralizowanych scenariuszy. Scentralizowana organizacja udostępnia rozwiązania, które organizacje lokalne muszą wdrażać w swoim środowisku. Scentralizowana organizacja sprawdza również, czy te rozwiązania są wdrażane we wszystkich strefach docelowych organizacji lokalnych.

Scenariusze wymagające modyfikacji

Może być konieczne zmodyfikowanie stref docelowych, jeśli istnieją sprzeczne zestawy zasad przypisane do różnych wdrożeń. Może istnieć wiele rozwiązań lub pojedyncze rozwiązanie, które należy udostępnić różnym lokalizacjom geograficznym lub klasyfikacjom danych.

Wymagana ilość modyfikacji zależy od poziomu izolacji, do którego wzywa rozporządzenie. Tym więcej warunków, jakie ma rozporządzenie, tym bardziej należy zmodyfikować strefę docelową. Jeśli na przykład przepisy wymagają warunków, takich jak wyczyszczonego personelu, różnych dostawców tożsamości lub katalogów, oddzielnej infrastruktury zarządzania lub oddzielnej infrastruktury łączności, strefa docelowa wymaga obszernej modyfikacji. Jeśli przepisy wymagają tylko odizolowania infrastruktury aplikacji i łączności, strefa docelowa wymaga minimalnej modyfikacji.

Dzierżawy firmy Microsoft Entra

Zalecamy używanie jednej dzierżawy firmy Microsoft Entra w przypadku większości scenariuszy, w tym międzynarodowych scenariuszy. Istnieją jednak scenariusze, w których możesz preferować lub wymagać wielu dzierżaw firmy Microsoft Entra, takich jak:

Podczas współpracy w wielu dzierżawach firmy Microsoft Entra należy dokładnie zaplanować istotne wyzwania i potrzeby. Utwórz tylko minimalną liczbę dzierżaw firmy Microsoft, które muszą spełniać wymagania operacyjne lub prawne. Za pomocą grup zarządzania i kontroli dostępu opartej na rolach (RBAC) platformy Azure można zarządzać dostępem do subskrypcji i zasobów w ramach jednej dzierżawy, zgodnie z opisem w następnej sekcji.

Napiwek

Dzierżawa firmy Microsoft Entra wybrana dla strefy docelowej nie ma wpływu na uwierzytelnianie na poziomie aplikacji. Nadal możesz używać innych dostawców tożsamości niezależnie od wybranej dzierżawy. W przypadku klientów z sektora publicznego i klientów w branżach regulowanych tożsamości użytkowników końcowych są zwykle udostępniane podczas integracji z zatwierdzonym dostawcą tożsamości, takim jak dostawca tożsamości należący do instytucji rządowych lub certyfikowany dostawca tożsamości.

Na poniższych diagramach przedstawiono opcje, których można użyć do organizowania dzierżaw firmy Microsoft Entra.

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

Napiwek

Jeśli masz wiele dzierżaw firmy Microsoft Entra, aby spełnić wymagania prawne, nazwij dzierżawy na podstawie lokalizacji geograficznej, a nie określonych przepisów, na przykład contoso-ops-us.com na przykład na przykładowym diagramie.

Aby uzyskać więcej informacji, zobacz Strefy docelowe platformy Azure i wiele dzierżaw firmy Microsoft Entra oraz zagadnienia dotyczące niezależnego dostawcy oprogramowania dla stref docelowych platformy Azure.

Grupy zarządzania

Jeśli nie potrzebujesz oddzielnych dzierżaw firmy Microsoft Entra w celu zapewnienia ścisłej izolacji, należy wdrożyć wiele stref docelowych platformy Azure w jednej dzierżawie firmy Microsoft Entra. Hierarchię grup zarządzania można dostosować, aby spełnić wymagania przepisów powodujących konflikt.

Możesz wdrożyć pełną architekturę strefy docelowej dla każdego zestawu przepisów, które chcesz oddzielić. Ten model wymaga najmniejszej ilości dostosowywania i umożliwia korzystanie z istniejącej automatyzacji na potrzeby wdrożenia.

A diagram that shows separate landing zones for each regulation.

Uwaga

Ten diagram nie pokazuje wszystkich grup zarządzania.

Udostępnianie grupy zarządzania platformą

Jeśli regulacje zezwalają, można udostępnić grupę zarządzania platformą. Można utworzyć oddzielne grupy zarządzania w grupie zarządzania strefą docelową dla każdego zestawu przepisów, które należy oddzielić. Odpowiednie zasady można przypisać do każdej z grup zarządzania aplikacjami. Strefy docelowe aplikacji współużytkują grupy zarządzania, które znajdują się w grupie zarządzania platformy. Zasoby w grupach zarządzania aplikacjami mogą być również oddzielone subskrypcją lub grupą zasobów.

Ta hierarchia grup zarządzania jest prostym i opłacalnym projektem izolowania aplikacji z sprzecznymi przepisami. Jednak w tym projekcie grupy zarządzania platformy na potrzeby łączności, tożsamości/zabezpieczeń i zarządzania muszą współużytkować ten sam zestaw zasad. Może być konieczne użycie różnych zestawów zasad dla każdej grupy zarządzania platformą, jeśli rozporządzenie nakłada ograniczenia dotyczące udostępniania infrastruktury łączności, usług tożsamości, usług zarządzania kluczami lub infrastruktury, z której jest zarządzane całe środowisko.

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

Izolowanie tożsamości i zabezpieczeń

Jeśli przepisy uniemożliwiają udostępnianie infrastruktury zarządzania tożsamościami i kluczami, możesz podzielić grupę zarządzania platformą. Zachowaj grupy zarządzania na potrzeby łączności i zarządzania w udostępnionej grupie zarządzania platformami oraz mają grupę zarządzania tożsamościami i zabezpieczeniami skojarzoną z każdym zestawem przepisów.

Ta hierarchia grup zarządzania jest znacznie bardziej złożona niż w pełni udostępniona grupa zarządzania platformą, ponieważ trzeba częściowo replikować grupę zarządzania platformą. Aby ograniczyć złożoność, można wdrożyć pełną hierarchię dla każdego zestawu regulacji i środowiska udostępnionego oraz zignorować lub usunąć zbędne grupy zarządzania.

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

Izolowanie łączności

Wiele przepisów ma wymagania związane z przetwarzaniem i przechowywaniem danych w określonej lokalizacji geograficznej, z kilkoma wymaganiami dotyczącymi sposobu łączenia użytkowników z aplikacjami. W przypadku tych przepisów można udostępniać zarządzanie łącznością, jak pokazano w poprzedniej architekturze. Być może nie ma żadnych przepisów, które wymagają duplikowania infrastruktury w wielu regionach, ale może być konieczne do celów opóźnienia. Przypisane zasady muszą obsługiwać duplikowanie infrastruktury w wielu regionach.

Jeśli przepisy mają sprzeczne wymagania dotyczące łączności, można utworzyć grupę zarządzania łącznością skojarzona z każdym zestawem przepisów. Ta struktura jest podobna do poprzedniej architektury, która kojarzy grupy zarządzania tożsamościami i zabezpieczeniami z każdym zestawem przepisów.

Jeśli przepisy powodują konflikt z łącznością, a także tożsamościami i zabezpieczeniami, możesz użyć następującego projektu.

A diagram that shows an architecture that isolates connectivity.

Następne kroki