Úprava architektury cílové zóny Azure tak, aby splňovala požadavky napříč několika umístěními

  • Článek

Organizace v mnoha odvětvích podléhají zákonným požadavkům, včetně rezidencí dat, zabezpečení dat a požadavků na suverenitu dat. Některé organizace musí dodržovat konfliktní předpisy v různých geografických lokalitách. V tomto případě musí upravit architekturu cílové zóny Azure v souladu se všemi platnými předpisy.

Mohou existovat například dvě konfliktní předpisy, nařízení A a nařízení B. Nařízení A může vyžadovat rezidenci dat ve zemi nebo oblasti A a nařízení B může vyžadovat rezidenci dat ve zemi nebo oblasti B.

Tyto regulační konflikty se můžou vztahovat na:

  • Mezinárodní organizace, jako jsou nadnárodní společnosti nebo nevládní organizace, které musí dodržovat místní předpisy v zemích nebo oblastech, ve kterých působí.

  • Nezávislí dodavatelé softwaru (ISV), kteří poskytují řešení organizacím na více místech, a řešení musí dodržovat místní předpisy v každém umístění.

  • Nezávislí výrobci softwaru, kteří poskytují řešení nadnárodním organizacím, které potřebují dodržovat místní předpisy každé země nebo oblasti, ve které pracují.

Pokud potřebujete splnit jenom jednu sadu zákonných požadavků, přečtěte si téma Přizpůsobení architektury cílové zóny Azure tak, aby splňovala požadavky.

Důležité informace o právních předpisech

Zákonné požadavky obvykle souvisejí s ochranou dat, rezidencí dat, přenosy dat, izolací nebo volným přístupem pracovníků. Tyto požadavky můžou kolidovat mezi několika geografickými lokalitami. Například nařízení Evropské unie (EU) může vyžadovat rezidenci dat v zemi EU, zatímco nařízení Spojeného království může vyžadovat rezidenci dat ve Spojeném království.

Pokud předpisy vedou ke konfliktům řízení zásad, musíte odpovídajícím způsobem upravit architekturu cílové zóny Azure a přiřazení zásad. Další informace najdete v části tohoto článku Scénáře, které vyžadují úpravy.

Pokud platí více předpisů, nemusíte upravovat architekturu cílové zóny Azure, pokud:

  • Několik předpisů vyžaduje identická přiřazení azure Policy.

  • Ovládací prvky v jednom nařízení jsou nadmnožinou jiného nařízení. Ovládací prvky nadmnožina se automaticky vztahují na obě předpisy.

  • Ovládací prvky v několika pravidlech se nepřekrývají. Při implementaci více kontrolních sad se jedna implementace vztahuje na všechny předpisy. Přiřazení azure Policy doplňují.

  • Různé předpisy mají různé typy implementace. Z hlediska právních předpisů nezáleží na tom, kterou implementaci zvolíte. Mohou existovat například dvě předpisy, které mají každý jiný autorizační model, ale oba autorizační modely jsou přijatelné. Můžete zvolit implementaci, která nejlépe vyhovuje vaší organizaci.

Tip

Měli byste se snažit mít co nejméně přiřazení zásad a výjimky nebo výjimky.

Důležité informace pro nezávislé výrobce softwaru

Existují tři modely nasazení pro nezávislé výrobce softwaru.

  • Čistý software jako služba (SaaS): Poskytovatel softwaru poskytuje řešení jako službu.

  • Zákazník nasazený: Zákazník nasadí řešení ve svém vlastním prostředí.

  • SaaS s duálním nasazením: Tento model kombinuje model nasazený zákazníkem a čistý model SaaS.

V čistém modelu SaaS zodpovídá výrobce softwaru za správu dodržování předpisů jménem zákazníka. IsV musí prokázat dodržování předpisů zákazníkovi a potenciálně auditorům nebo regulačním orgánům. Pokud používáte model SaaS, může být vaše architektura předmětem více předpisů, které můžou kolidovat. IsV musí řídit dodržování těchto různých předpisů. Další informace najdete v části tohoto článku Scénáře, které vyžadují úpravy.

V modelu nasazeného zákazníkem zodpovídá zákazník za správu dodržování předpisů. U tohoto modelu isV nemusí upravovat cílové zóny. Řešení se ale nasadí do cílové zóny, kterou zákazník nasadí, včetně všech ovládacích prvků zásad a vlastních zásad.

Tip

Nezávislí výrobci softwaru můžou cílit na iniciativy zásad v konkrétních požadavcích na dodržování předpisů pro testování řešení. Tento postup může pomoct minimalizovat pravděpodobnost konfliktů se zásadami, které zákazníci používají ke splnění požadavků na dodržování předpisů.

V modelu SaaS s duálním nasazením platí všechny aspekty modelu SaaS nasazeného zákazníkem a čistě saaS.

Důležité informace pro nadnárodní organizace

Nadnárodní organizace používají různé struktury k uspořádání zásad správného řízení IT.

  • Decentralizovaná struktura: IT funkce se řídí místně v každém geografickém umístění.

  • Centralizovaná struktura: IT funkce se řídí centralizovaným místem, obvykle ústředím organizace.

  • Hybridní struktura: Globální IT funkce jsou poskytovány centrálně, zatímco IT funkce vyžadované pouze místně se řídí v jednotlivých geografických umístěních.

V decentralizovaném scénáři zodpovídá místní IT tým za správu dodržování předpisů a může odpovídajícím způsobem přizpůsobit cílovou zónu.

V centralizované situaci zodpovídá centrální IT tým za správu dodržování předpisů a musí zajistit, aby řešení splňovala místní požadavky na dodržování předpisů všech geografických lokalit, kde mezinárodní organizace působí. Požadavky na dodržování předpisů různých geografických lokalit můžou kolidovat a může být nutné upravit cílové zóny.

V hybridním scénáři platí důležité informace o decentralizovaných i centralizovaných scénářích. Centralizovaná organizace poskytuje řešení, která místní organizace potřebují nasadit ve svém prostředí. Centralizovaná organizace také testuje, že se tato řešení nasazují ve všech cílových zónách místních organizací.

Scénáře, které vyžadují úpravy

Pokud jsou k různým nasazením přiřazené konfliktní sady zásad, může být potřeba upravit cílové zóny. Může existovat několik řešení nebo jediné řešení, které je potřeba zpřístupnit pro různá geografická umístění nebo klasifikace dat.

Množství požadovaných úprav závisí na úrovni izolace, kterou nařízení požaduje. Čím více podmínek nařízení má, tím více cílové zóny je potřeba upravit. Pokud například předpisy vyžadují podmínky, jako jsou vymazání pracovníci, různí zprostředkovatelé identit nebo adresáře, samostatná infrastruktura pro správu nebo samostatná infrastruktura připojení, vyžaduje cílová zóna rozsáhlou změnu. Pokud předpisy vyžadují pouze izolaci infrastruktury aplikace a připojení, cílová zóna potřebuje minimální úpravy.

Tenanti Microsoft Entra

Pro většinu scénářů, včetně nadnárodních scénářů, doporučujeme použít jednoho tenanta Microsoft Entra. Existují však scénáře, ve kterých můžete preferovat nebo vyžadovat více tenantů Microsoft Entra, například:

Při spolupráci napříč několika tenanty Microsoft Entra je potřeba pečlivě naplánovat významné výzvy a potřeby. Vytvořte pouze minimální počet tenantů Microsoft Entra, které potřebujete ke splnění provozních nebo regulačních požadavků. Pomocí skupin pro správu a řízení přístupu na základě role v Azure (RBAC) můžete řídit přístup k předplatným a prostředkům v rámci jednoho tenanta, jak je popsáno v další části.

Tip

Tenant Microsoft Entra, kterého vyberete pro cílovou zónu, nemá vliv na ověřování na úrovni aplikace. I nadále můžete používat jiné zprostředkovatele identity bez ohledu na to, kterého tenanta zvolíte. Pro zákazníky z veřejného sektoru a zákazníky v regulovaných odvětvích se identity koncových uživatelů obvykle poskytují při integraci se schváleným zprostředkovatelem identity, jako je poskytovatel identity vlastněný státní správou nebo certifikovaný zprostředkovatel identity.

Následující diagramy znázorňují možnosti, které můžete použít k uspořádání tenantů Microsoft Entra.

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

Tip

Pokud máte více tenantů Microsoft Entra pro splnění zákonných požadavků, pojmenujte tenanty na základě zeměpisného umístění, nikoli na konkrétní předpisy, například contoso-ops-us.com v ukázkovém diagramu.

Další informace najdete v tématu Cílové zóny Azure a několik tenantů Microsoft Entra a důležitých informací o nezávislých výrobců softwaru pro cílové zóny Azure.

Skupiny pro správu

Pokud k zajištění přísné izolace nepotřebujete samostatné tenanty Microsoft Entra, měli byste do jednoho tenanta Microsoft Entra nasadit několik cílových zón Azure. Hierarchii skupin pro správu můžete upravit tak, aby řešila požadavky konfliktních předpisů.

Můžete nasadit úplnou architekturu cílové zóny pro každou sadu předpisů, které chcete oddělit. Tento model vyžaduje nejmenší míru přizpůsobení a umožňuje využít stávající automatizaci pro nasazení.

A diagram that shows separate landing zones for each regulation.

Poznámka:

Tento diagram nezobrazuje všechny skupiny pro správu.

Sdílení skupiny pro správu platformy

Pokud to regulace umožňuje, může být sdílena skupina pro správu platformy. V rámci skupiny pro správu cílové zóny můžete vytvořit samostatné skupiny pro správu pro každou sadu předpisů, které je potřeba oddělit. Ke každé skupině pro správu aplikací můžete přiřadit příslušné zásady. Cílové zóny aplikace sdílejí skupiny pro správu, které jsou pod skupinou pro správu platformy. Prostředky ve skupinách pro správu aplikací je také možné oddělit podle předplatného nebo skupiny prostředků.

Tato hierarchie skupin pro správu je jednoduchý a nákladově efektivní návrh pro izolování aplikací s konfliktními předpisy. V tomto návrhu ale musí skupiny pro správu platformy pro připojení, identitu/zabezpečení a správu sdílet stejnou sadu zásad. Pokud nařízení omezuje sdílení infrastruktury připojení, služeb identit, služeb správy klíčů nebo infrastruktury, ze které se spravuje celé prostředí, může pro každou skupinu pro správu platformy vyžadovat různé sady zásad.

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

Izolace identity a zabezpečení

Pokud vám předpisy brání ve sdílení infrastruktury pro správu identit a klíčů, můžete skupinu pro správu platformy rozdělit. Udržujte skupiny pro správu pro připojení a správu ve skupině pro správu sdílených platforem a mají skupinu pro správu identit a zabezpečení přidruženou ke každé sadě předpisů.

Tato hierarchie skupin pro správu je výrazně složitější než plně sdílená skupina pro správu platformy, protože musíte částečně replikovat skupinu pro správu platformy. Pokud chcete omezit složitost, můžete nasadit úplnou hierarchii pro každou sadu nařízení a sdílené prostředí a ignorovat nebo odstranit nadbytečné skupiny pro správu.

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

Izolace připojení

Řada předpisů má požadavky související se zpracováním a ukládáním dat v určitém geografickém umístění s několika požadavky na to, jak se uživatelé připojují k aplikacím. U těchto předpisů můžete sdílet správu připojení, jak je znázorněno v předchozí architektuře. Nemusí existovat žádná nařízení, která by vyžadovala duplikování infrastruktury ve více oblastech, ale pro účely latence možná budete muset. Přiřazené zásady musí podporovat duplikování infrastruktury ve více oblastech.

Pokud mají předpisy konfliktní požadavky na připojení, můžete vytvořit skupinu pro správu připojení, která je přidružená ke každé sadě předpisů. Tato struktura je podobná předchozí architektuře, která ke každé sadě předpisů přidruží skupiny pro správu identit a zabezpečení.

Pokud kolidují předpisy pro připojení a také identitu a zabezpečení, můžete použít následující návrh.

A diagram that shows an architecture that isolates connectivity.

Další kroky