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še podniková a saaS řešení Microsoft Entra byla oddělená. Riziko operace nebo nasazení ovlivňujícího druhého tenanta, ať už zamýšleného nebo omylem, 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í přístupu s více tenanty.
Přístup 2 – Registrace sdílené aplikace (více tenantů) s více instančními objekty se běžně používá ve scénářích poskytovatele spravovaných služeb (MSP). V tomto přístupu se dá vzor razítka nasazení použít k automatizaci nasazení téměř identické architektury napříč několika tenanty ve velkém měřítku.
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 aspekty v tomto článku nejsou určeny k použití 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 typechcílových
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 provádění úloh z automatizace, jako jsou spravované identity přiřazené spouštěčům v místním prostředí, 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í na 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 platforem, musíte použít tento přístup nebo přístup, který se přihlásí k jednotlivým tenantům. Spravované identity nepodporují scénáře napříč tenanty. Další informace najdete v těchto nejčastějších dotazech.
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 tenantovi Microsoft Entra, což znamená, že každý správce nebo vývojář platformy 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íce tenantů) s několika instančními objekty
V tomto přístupu se vytvoří registrace aplikace ve správě 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 spouštět úlohy kanálu a kroky pro přihlášení k libovolnému tenantovi Microsoft Entra pomocí jedné sady přihlašovacích údajů.
Tip
Informace o vztahu mezi registracemi aplikací a podnikovými aplikacemi (principy služeb) najdete v tématu Aplikační a instanční objekty v Microsoft Entra ID.
Důležité
V tomto přístupu by se měla monitorovat registrace jedné aplikace a přidružené podnikové aplikace (instanční objekty) za každou 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 je jedna registrace aplikace 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ématu Vytvoření víceklienta aplikace.
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 zpracování více prostředí, jako je vývoj, testování nebo produkce, je možné je řídit stejným nebo samostatným způsobem pomocí stejných nebo samostatných registrací aplikací a podnikových aplikací s kanály.
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 odebere Azure Lighthouse jako možnost pro celý aspekt nasazení automatizace platformy cílových zón Azure, ale v některých scénářích je stále užitečný. Další informace najdete v tématu Využití služby Azure Lighthouse ve víceklientovi 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říklad v prvním přístupu.