Přístup k testování cílových zón Azure
Poznámka:
Tento článek se týká jenom Microsoft Azure a ne jiných nabídek Microsoft Cloud, jako jsou Microsoft 365 nebo Microsoft Dynamics 365.
Některé organizace můžou chtít otestovat nasazení platformy cílových zón Azure pro definice a přiřazení azure Policy, vlastní role a přiřazení na základě role (RBAC) a tak dále. Testy je možné provádět prostřednictvím automatizace pomocí šablon Azure Resource Manageru (šablon ARM), Terraformu, bicepnebo ručně prostřednictvím webu Azure Portal. Tyto pokyny poskytují přístup, který můžete použít k testování změn a jejich dopadu na nasazení platformy cílových zón Azure.
Tento článek lze také použít s pokyny k automatizaci platformy a kritické oblasti návrhu DevOps, protože souvisí s týmy a úkoly funkcí PlatformOps a Central.
Tyto pokyny jsou nejvhodnější pro organizace s robustními procesy správy změn, které řídí změny v hierarchii skupin pro správu produkčního prostředí. Hierarchii kanárských skupin pro správu je možné nezávisle používat k vytváření a testování nasazení před jejich nasazením do produkčního prostředí.
Poznámka:
Termín kanár se používá k zabránění nejasnostem s vývojovými prostředími nebo testovacími prostředími. Tento název se používá jenom pro ilustraci. Můžete definovat libovolný název, který považujete za vhodný pro vaše cílové zóny Azure.
Podobně se termín provozní prostředí používá v rámci těchto pokynů k odkazování na hierarchii skupin pro správu, kterou vaše organizace může mít zavedenou, která obsahuje předplatná a prostředky Azure pro vaše úlohy.
Definice platformy
Důležité
Tyto pokyny nejsou určené pro vývojová prostředí ani testovací prostředí, která budou používat vlastníci aplikací nebo služeb označovaná jako cílové zóny, úlohy, aplikace nebo služby. Ty se umístí a zpracovávají v rámci hierarchie skupin pro správu produkčního prostředí a přidružených zásad správného řízení (RBAC a Azure Policy).
Tyto pokyny platí pouze pro testování na úrovni platformy a změny v kontextu cílových zón Azure.
Podnikové škálování vám pomůže navrhnout a nasadit požadované komponenty platformy Azure, které vám umožní vytvářet a zprovozňovat cílové zóny ve velkém měřítku.
Prostředky platformy v oboru pro tento článek a tento přístup k testování jsou:
| Produkt nebo služba | Poskytovatel prostředků a typ |
|---|---|
| Skupiny pro správu | Microsoft.Management/managementGroups |
| Přidružení předplatného skupin pro správu | Microsoft.Management/managementGroups/subscriptions |
| Definice zásad | Microsoft.Authorization/policyDefinitions |
| Definice iniciativ zásad nebo definice sady zásad | Microsoft.Authorization/policySetDefinitions |
| Přiřazení zásad | Microsoft.Authorization/policyAssignments |
| Definice rolí RBAC | Microsoft.Authorization/roleDefinitions |
| Přiřazení rolí RBAC | Microsoft.Authorization/roleAssignments |
| Předplatná | Microsoft.Subscription/aliases |
Příklady scénářů a výsledků
Příkladem tohoto scénáře je organizace, která chce otestovat dopad a výsledek nové zásady Azure Policy, která řídí prostředky a nastavení ve všech cílových zónách podle principu návrhu zásad správného řízení řízeného zásadami. Nechtějí provést tuto změnu přímo v produkčním prostředí, protože se zajímají o dopad, který by mohl mít.
Použití kanárového prostředí k otestování této změny platformy umožní organizaci implementovat a zkontrolovat dopad a výsledek změny služby Azure Policy. Tento proces zajistí, že splňuje požadavky organizace před implementací služby Azure Policy do produkčního prostředí.
Podobným scénářem může být změna přiřazení rolí Azure RBAC a členství ve skupinách Microsoft Entra. Před provedením změn v produkčním prostředí to může vyžadovat formu testování.
Důležité
Toto není běžný přístup k nasazení ani vzor pro většinu zákazníků. Pro nasazení cílových zón Azure to není povinné.
Obrázek 1: Hierarchie kanárských skupin pro správu
Jak znázorňuje diagram, celá hierarchie skupin pro správu produkčního prostředí Azure cílové zóny je duplikována pod položkou Tenant Root Group. Kanárské jméno se připojí k zobrazovaným názvům a ID skupin pro správu. ID musí být jedinečná v rámci jednoho tenanta Microsoft Entra.
Poznámka:
Zobrazované názvy skupiny pro správu kanárských prostředí můžou být stejné jako zobrazované názvy produkční skupiny pro správu prostředí. To může způsobit nejasnosti pro uživatele. Z tohoto důvodu doporučujeme k zobrazovaným názvům a jejich ID připojit název "kanár".
Hierarchie skupin pro správu kanárských prostředí se pak používá ke zjednodušení testování následujících typů prostředků:
- Skupiny pro správu
- Umístění předplatného
- RBAC
- Role (předdefinované a vlastní)
- Přiřazení
- Azure Policy
- Definice (integrované a vlastní)
- Iniciativy označované také jako definice sady
- Přiřazení
Co když nechcete nasadit celou hierarchii skupin pro správu prostředí?
Pokud nechcete nasadit celou hierarchii skupin pro správu prostředí, můžete otestovat prostředky platformy v rámci hierarchie produkčního prostředí pomocí předplatných sandboxu , jak je znázorněno v diagramu.
Obrázek 2: Hierarchie skupin pro správu na podnikové úrovni se zvýrazněním sandboxů
K otestování Azure Policy a RBAC v tomto scénáři potřebujete jedno předplatné Azure s rolí Vlastník RBAC přiřazenou k identitě, kterou chcete testování dokončit, například uživatelský účet, instanční objekt nebo identita spravované služby. Tato konfigurace vám umožní vytvářet, přiřazovat a opravovat definice a přiřazení služby Azure Policy pouze v rámci rozsahu předplatného sandboxu.
Tento přístup k sandboxu je možné použít také pro testování RBAC v rámci předplatného, například pokud vyvíjíte novou vlastní roli RBAC pro udělení oprávnění pro konkrétní případ použití. Toto testování je možné provést v předplatném sandboxu a otestovat ho před vytvořením a přiřazením rolí v hierarchii.
Výhodou tohoto přístupu je, že předplatná sandboxu je možné použít v době, kdy jsou potřeba, a potom je z prostředí odstranit.
Tento přístup ale neumožňuje testovat dědičnost zásad RBAC a Azure z hierarchie skupin pro správu.
Použití jednoho tenanta Microsoft Entra
Aspekty, které je potřeba vzít v úvahu při použití jednoho tenanta Microsoft Entra, jsou:
- Dodržuje doporučení návrhu na podnikové úrovni pro tenanty Microsoft Entra.
- V jednom tenantovi Microsoft Entra můžete použít různé skupiny Microsoft Entra pro produkční prostředí i prostředí cílových zón Azure se stejnými uživateli, kteří mají přiřazenou příslušnou hierarchii skupin pro správu ve stejném tenantovi Microsoft Entra.
- Zvýšení nebo duplikování licenčních nákladů na Microsoft Entra ID kvůli více identitám v různých tenantech Microsoft Entra
- Tento bod je zvláště relevantní pro zákazníky, kteří používají funkce Microsoft Entra ID P1 nebo P2.
- Změny RBAC budou v kanárských prostředích i produkčních prostředích složitější, protože je pravděpodobné, že uživatelé a skupiny nejsou v obou tenantech Microsoft Entra identické.
- ID uživatelů a skupin navíc nebudou v rámci tenantů Microsoft Entra stejné, protože jsou globálně jedinečné.
- Snižuje složitost a režijní náklady na správu způsobené správou více tenantů Microsoft Entra.
- Privilegovaní uživatelé, kteří musí udržovat přístup a přihlašovat se k samostatným tenantům, aby mohli provádět testování, můžou omylem provádět změny v produkčním prostředí, místo aby prováděli změny v kanárském prostředí a naopak.
- Snižuje pravděpodobnost odchylek konfigurace a selhání nasazení.
- Nevyžaduje vytvoření dodatečných bezpečnostních a prolomených procesů nebo procesů nouzového přístupu.
- Zkracuje třecí plochy a čas potřebný k implementaci změn nasazení cílových zón Azure.
Průvodce implementací
Níže najdete pokyny, jak implementovat a používat hierarchii kanárských skupin pro správu cílových zón Azure společně s hierarchií skupin pro správu produkčního prostředí.
Upozorňující
Pokud k nasazení a správě prostředí cílových zón Azure v současné době používáte portál, může být obtížné přijmout a efektivně používat kanárný přístup z důvodu vysokého rizika, že produkční i kanárová prostředí se často nesynchronizují, a proto neposkytuje hierarchii jako repliku a prostředí produkčního prostředí.
Pokud jste v tomto scénáři, zvažte přechod na přístup nasazení infrastruktury jako kódu pro cílové zóny Azure, jak je uvedeno výše. Nebo si uvědomte potenciální rizika odchylek konfigurace mezi kanárkou a výrobou a pokračujte opatrně.
- Použijte samostatné instanční objekty Microsoft Entra (SPN) nebo identity spravované služby (MSI), které mají udělená oprávnění pro příslušné produkční prostředí nebo kanárnou hierarchii skupin pro správu prostředí.
- Tyto pokyny se řídí principem nejnižších oprávnění (PoLP).
- Pomocí samostatných složek v úložišti Git, větvích nebo úložištích můžete uchovávat infrastrukturu jako kód pro produkční prostředí a nasazení cílových zón Azure v kanárovém prostředí.
- Použití příslušných instančních objektů služby Microsoft Entra (SPN) nebo identit spravovaných služeb (MSI) jako součást kanálů CI/CD v závislosti na tom, jakou hierarchii nasazujete.
- Implementujte zásady git branch nebo zabezpečení pro kanárské prostředí, protože jste v produkčním prostředí.
- Zvažte snížení počtu schvalovatelů a kontrol kanárských prostředí, aby se nezdařilo rychle.
- Pomocí stejných akcí Azure Pipelines nebo GitHubu, které používají proměnné prostředí, můžete změnit, jakou hierarchii nasazujete. Další možností je naklonovat kanály a změnit pevně zakódovaná nastavení tak, aby definovala, která hierarchie se nasazuje.
- Mít sadu kanárských předplatných v samostatném oddělení EA a účtu, který je možné podle potřeby přesunout po hierarchii kanárských skupin pro správu.
- Může být výhodné mít sadu prostředků vždy nasazených do předplatných kanárských prostředí.
- Může být užitečné mít šablony infrastruktury jako kódu, jako jsou šablony ARM, Bicep nebo Terraform, které vytvářejí sadu prostředků, které umožňují ověřování změn v kanárovém prostředí.
- Všechny protokoly aktivit Azure můžete odesílat pro všechna předplatná Azure, včetně jakýchkoli předplatných kanárských prostředí, do produkčního prostředí pracovního prostoru Služby Azure Log Analytics podle doporučení pro návrh cílových zón Azure.
Tip
Pokud už máte cílové zóny Azure nasazené v produkčním prostředí a teď chcete přidat kanárské prostředí. Zvažte klonování aktuálního nasazení hierarchie produkčního prostředí a změna názvů prostředků tak, aby byly předpony schématem pojmenování kanárů.
To je pro zajištění toho, co nasazujete, aby se kanárské prostředí synchronizovaly s produkčním prostředím od začátku. Toho lze snadno dosáhnout při použití nástroje Infrastruktura jako kód společně s úložištěm Git.
Další kroky
Naučte se implementovat prostředí sandboxu cílové zóny.