Automatizace cílových zón Azure napříč několika tenanty
Pokud má vaše organizace více tenantů Microsoft Entra s cílovými zónami Azure (ALZ) v každé z nich, jednou nebo vícekrát, je automatizace klíčem. Automatizace pomáhá úspěšně provozovat a udržovat nasazení ALZ ve velkém měřítku napříč všemi tenanty. Existuje mnoho přístupů k automatizaci nasazení ALZ napříč několika tenanty. Přístup, který vezmete, závisí na důvodech, proč má vaše organizace více tenantů Microsoft Entra.
Pokud jste například nezávislý dodavatel softwaru, můžete mít několik tenantů Microsoft Entra. Je pravděpodobné, že chcete, aby vaši podnikové a SaaS tenanti Microsoft Entra byli odděleni. Riziko, že operace nebo nasazení ovlivní druhého tenanta, ať už zamýšleně nebo omylem, se snižuje.
Následující části obsahují diagramy a pokyny k postupům, které můžete provést. Zvolte, který přístup je pro vás nejvhodnější na základě vašich požadavků, důležitých aspektů a doporučení pro automatizaci nasazení cílových zón Azure při zpracování více tenantů Microsoft Entra.
Poznámka
Nejprve si projděte následující články a získejte přehled tenantů Microsoft Entra:
Přístupy
Existují dva přístupy k automatizaci nasazení cílových zón Azure napříč několika tenanty Microsoft Entra.
Přístup 1 – Úplná izolace je nejběžnějším přístupem ve scénářích s více tenanty. Tento přístup udržuje požadované oddělení a izolaci mezi tenanty Microsoft Entra, což je nejběžnější požadavek při použití víceklientských přístupů.
Přístup 2 – Registrace sdílených aplikací (multitenantní) s více služebními principály se běžně používá ve scénářích poskytovatelů managed služeb (MSP). V tomto přístupu lze vzor pro nasazení použít k automatizaci nasazení skoro identické architektury ve více tenantech ve velké míře.
Oba tyto přístupy jsou k dispozici jako příklady a inspiraci. Přístupy v nasazeních můžete kombinovat a shodovat podle požadavků vaší organizace.
Důležitý
Tento článek popisuje automatizaci nasazení a provozu cílových zón Azure jako platformy v každém tenantovi Microsoft Entra, kterého má vaše organizace. Přístupy, doporučení a úvahy v tomto článku nejsou určeny k tomu, aby byly používány aplikačními týmy, které nasazují a provozují své služby a aplikace do cílových zón (předplatných). Další informace o různých typech cílových zón najdete v tématu Platform vs. cílové zóny aplikací.
Přístup 1 – úplná izolace
V tomto přístupu je primárním cílem udržovat každého tenanta Microsoft Entra izolovaný od sebe ve všech komponentách automatizace, například:
- Úložiště Git.
- GitHub Actions nebo Azure Pipelines (včetně spouštěčů v místním prostředí, pokud se využívají).
- Identity, které se používají k automatizovanému provádění úkolů, jako jsou spravované identity přiřazené spouštěčům hostovaným interně, hlavní názvy služeb (SPN), uživatelé nebo správci.
V tomto přístupu je k dispozici více komponent pro správu, které se duplikují u každého tenanta Microsoft Entra. Některé organizace můžou mít vynucované kontrolní mechanismy dodržování právních předpisů, které u nich vyžadují tento typ oddělení a izolace.
Poznámka
Pokud vaše organizace umožňuje používat pouze spravované identity pro automatizaci platformy, musíte použít tento přístup nebo přístup, který se přihlašuje ke každému tenantovi zvlášť. Spravované identity dnes nepodporují scénáře mezi tenanty v rámci obecné dostupnosti. Další informace najdete v těchto nejčastějších dotazech.
Tato možnost je nyní k dispozici ve verzi Public Preview pro spravované identity User-Assigned konfigurací vztahu důvěryhodnosti mezi sebou a víceklientské aplikace s id Entra. Další informace o konfiguraci této možnosti najdete v Konfigurace aplikace tak, aby důvěřovala spravované identitě (Preview). To nyní může udělat z přístupu 2 – registrace sdílené aplikace (víceklientská) s více instančními objekty proveditelnou možnost pro vaše nasazení.
Identity pro správce a vývojáře platformy – Přístup 1
V tomto přístupu by se identity měly izolovat také v každém tenantu Microsoft Entra, což znamená, že správce platformy nebo vývojář vyžaduje samostatný uživatelský účet v rámci každého tenanta k provádění operací v rámci tohoto tenanta. Tyto účty se také používají pro přístup k vývojářským nástrojům, jako je GitHub nebo Azure DevOps, pro každého tenanta. Pečlivě zvažte účinky produktivity správců a vývojářů, a to podle tohoto přístupu.
Microsoft Entra B2B a/nebo Azure Lighthouse je možné použít, ale tato možnost se ptá, proč mít samostatné tenanty Microsoft Entra.
Přístup 2 – Registrace sdílené aplikace (vícetenantní) s více servisními principály
V tomto přístupu se vytvoří registrace aplikace v rámci spravujícího tenanta Microsoft Entra. V každém tenantovi Microsoft Entra, kterého chcete spravovat, se v daném tenantovi vytvoří hlavní název služby (SPN) na základě registrace aplikace. Tato akce umožňuje pracovníkům, kteří používají úlohy a kroky kanálu, přihlásit se k libovolnému tenantovi Microsoft Entra pomocí jediné sady přihlašovacích údajů.
Spropitné
Informace o vztahu mezi registracemi aplikací a podnikovými aplikacemi (služby) najdete v tématu Objekty aplikace a instanční objekty služby vMicrosoft Entra ID.
Důležitý
V tomto přístupu by se měla monitorovat registrace jedné aplikace a přidružené podnikové aplikace (služební principy) pro jakoukoli neobvyklou aktivitu v nástrojích pro správu událostí a informací o zabezpečení (SIEM), protože se jedná o vysoce privilegovaný účet. V závislosti na závažnosti výstrahy by měl odesílat výstrahy a potenciálně automaticky provádět akce.
V předchozím příkladu se jedna registrace aplikace nachází v tenantovi contoso.onmicrosoft.com Microsoft Entra a podniková aplikace se nachází v každém tenantovi Microsoft Entra, který je propojen s registrací aplikace. Toto nastavení umožňuje kanálu ověřovat a autorizovat všechny tenanty Microsoft Entra pomocí registrace jedné aplikace. Další informace najdete v tématech Vytvoření víceklientské aplikace a Udělení souhlasu správce v rámci celého tenanta aplikaci.
Spropitné
Spravované identity přiřazené uživatelem ve verzi Public Preview teď můžou podporovat scénáře s více tenanty tím, že konfigurují vztah důvěryhodnosti mezi sebou a víceklientské aplikace Entra ID. Další informace o konfiguraci této možnosti najdete v Konfigurace aplikace tak, aby důvěřovala spravované identitě (Preview).
Pokud používáte centralizovaný kanál, možná budete muset vytvořit malou tabulku mapování, která obsahuje data související s tenanty Microsoft Entra a další metadata, jako jsou prostředí, přidružená předplatná, název organizace a ID objektu identity používané k ověřování a autorizaci. Tato data je možné volat během spuštění kanálu v kroku, který používá určitou logiku a podmínky k řízení toho, do kterého tenanta Microsoft Entra se nasadí a do kterých identit. Data můžou být uložená ve službách, jako je Azure Cosmos DB nebo Azure Table Storage.
Při práci s více prostředími, jako je vývoj, testování nebo produkce, můžete tato prostředí řídit stejným způsobem nebo odděleně pomocí stejných, či samostatných registrací aplikací a podnikových aplikací v rámci nasazovacích kanálů.
Můžete se rozhodnout mít samostatné kanály pro každého tenanta Microsoft Entra nebo použít jeden kanál. Volba je vaše na základě vašich požadavků.
Poznámka
Azure Lighthouse funguje podobně jako tento přístup, ale Azure Lighthouse neumožňuje přiřazení vlastníka RBAC, správce přístupu uživatelů a rolí s oprávněními DataActions. Další informace najdete v tématu Podpora rolí pro Azure Lighthouse.
Role vlastníka a přístupu uživatelů se obvykle vyžadují ve všech scénářích nasazení cílové zóny Azure. Tento požadavek odstraňuje Azure Lighthouse jako volbu pro nasazení automatizace platformy v celém aspektu přistávacích zón Azure, ale v některých scénářích může být stále užitečný. Další informace najdete v tématu využití služby Azure Lighthouse v prostředí víceklientských ALZ.
Identity pro správce a vývojáře platforem – Přístup 2
V tomto přístupu správci platformy a vývojáři obvykle potřebují přístup jenom ke správě tenanta Microsoft Entra. Tento přístup jim uděluje přístup k nástrojům pro vývojáře, jako je GitHub nebo Azure DevOps, a všechny tenanty se nasazují a provozují z nich.
Můžou mít přístup k ostatním tenantům Microsoft Entra přes Microsoft Entra B2B nebo Azure Lighthouse. Používají stejný účet ze spravovaného tenanta nebo můžou mít samostatné účty, jako je příkladu v prvním přístupu.