跨多個租戶將 Azure 登陸區域自動化
如果您的組織有多個 Microsoft Entra 租用戶，每個租用戶中都有一個或多個 Azure 登陸區域（ALZ），那麼自動化是關鍵。 自動化可協助在所有租用戶之間成功大規模操作和維護 ALZ 部署。 有許多方法可將多個租使用者的 ALZ 部署自動化。 您採用的方法取決於貴組織擁有多個 Microsoft Entra 租戶的原因。
例如，如果您是獨立軟體供應商，您可能會有多個Microsoft Entra租戶。 您可能想要將您的公司與 SaaS 解決方案的 Microsoft Entra 租戶分開。 無論是有意或無意，對其他租戶之作業或部署產生影響的風險都會降低。
下列各節提供您可以採取之方法的圖表和指引。 根據需求、考慮和建議，選擇哪一種方法最適合您，以在處理多個Microsoft Entra 租使用者時自動化 Azure 登陸區域部署。
注意
請先閱讀下列文章，以取得 Microsoft Entra 租戶的概觀：
方法
有兩種方法可以自動化部署 Azure 著陸區域至多個 Microsoft Entra 租戶。
方法 1 – 完整隔離 是多租使用者案例中最常見的方法。 此方法會維持 Microsoft Entra 租用戶之間的必要隔離，這是在使用多租戶方法時最常見的需求。
方法 2 – 共用應用程式註冊（多租使用者）與多個服務主體 通常用於受控服務提供者 （MSP） 案例中。 在此方法中，部署戳記模式 可用來大規模自動化跨多個租使用者部署幾乎完全相同的架構。
這兩種方法都以範例和靈感的形式提供。 您可以根據組織的需求來混合和比對部署中的方法。
重要
本文涵蓋自動化 Azure 登陸區域的部署和操作，作為組織擁有的每個 Microsoft Entra 租戶中的平台。 本文中的方法、建議和考慮 不是 應用程式小組用來部署及操作其服務和應用程式到登陸區域（訂用帳戶）。 如需不同登陸區域類型的詳細資訊，請參閱 平臺與應用程式登陸區域。
方法 1 – 完整隔離
在此方法中，主要目標是讓每個 Microsoft Entra 租戶在所有自動化元件中保持隔離，例如：
- Git 存放庫。
- GitHub Actions 或 Azure Pipelines（包括使用自託管的執行個體時）。
- 用於自動化執行工作的身分識別，包括指派給自託管執行者的受管理的身分識別、服務主體名稱（SPN）、使用者或系統管理員。
在此作法中，您需要管理更多在每個 Microsoft Entra 租戶中重複的元件。 某些組織可能會受到法規合規要求的控制，必須實施這種類型的區隔和隔離。
注意
如果您的組織只允許使用受管理的識別進行平台自動化，您必須使用此方法或個別登入每個租戶的方法。 受控識別無法支援跨租戶情境。 如需詳細資訊，請參閱 此常見問題。
平台系統管理員和開發人員的身分識別 - 方法 1
在此方法中，身份識別也應該隔離在每個 Microsoft Entra 租戶中，這意味著每個平台管理員或開發人員都需要在每個租戶內擁有單獨的用戶帳戶，才能在該租戶內執行操作。 這些帳戶也可用來存取每個租用戶的開發人員工具，例如 GitHub 或 Azure DevOps。 請仔細考慮遵循此方法的系統管理員和開發人員生產力的影響。
Microsoft Entra B2B 和/或 Azure Lighthouse 可以被使用，但此選項會使人質疑擁有個別 Microsoft Entra 租戶的必要性。
方法 2 – 多服務主體的多租戶共享應用程式註冊
依據此方法，會在 Microsoft Entra 管理租戶中創建應用程式的註冊。 在每個您想要管理的 Microsoft Entra 租戶中，都會根據應用程式註冊在該租戶中建立一個服務主體名稱 (SPN)。 此動作可讓執行管線工作的工作者和步驟，以單一組認證登入任何 Microsoft Entra 租戶。
提示
如需應用程式註冊與企業應用程式之間關聯性的相關信息（服務原則），請參閱 Microsoft Entra ID中的
重要
在此方法中，單一應用程式註冊及相關聯的企業應用程式（服務主體）應在您的安全信息和事件管理(SIEM)工具中，密切監控任何異常活動，因為這是具有高權限的帳戶。 它應該傳送警示，並可能根據警示嚴重性自動採取動作。
在上一個範例中，單一應用程式註冊位於 contoso.onmicrosoft.com Microsoft Entra 租使用者中，而企業應用程式則位於連結至應用程式註冊的每個Microsoft Entra 租使用者中。 此設定允許管線透過單一應用程式註冊，對所有 Microsoft Entra 租用戶進行身份驗證和授權。 如需詳細資訊，請參閱 讓應用程式多租使用者。
當您使用集中式管線時，您可能需要建置一個小型對應表，其中包含Microsoft Entra租用戶和其他元數據之間的關聯數據，例如環境、相關聯的訂閱、組織名稱和用於驗證及授權的身份物件 ID。 在管線執行期間，此數據可以被呼叫，該步驟使用一些邏輯和條件來控制其部署至哪些 Microsoft Entra 租戶，以及使用哪些身分識別。 數據可以儲存在服務中，例如 Azure Cosmos DB 或 Azure 數據表記憶體。
當您處理多個環境，例如開發、測試或生產環境時，可以使用相同或個別的應用程式註冊和企業應用程式搭配管線來控制它們。
您可能會決定要為每個 Microsoft Entra 租戶使用不同的流程，或使用單一流程。 選擇是根據您的需求。
注意
Azure Lighthouse 的運作方式與這種方法類似，但 Azure Lighthouse 不允許指派具有 DataActions 許可權的 RBAC 擁有者、使用者存取管理員和角色。 如需詳細資訊，請參閱 azure Lighthouse
所有 Azure 登陸區域部署案例通常需要擁有者和使用者存取角色。 此需求會移除 Azure Lighthouse 作為 Azure 登陸區域之整個平臺自動化部署層面的選項，但在某些案例中仍然很有用。 如需詳細資訊，請參閱在 ALZ 多租使用者中
平台系統管理員和開發人員的身分識別 - 方法 2
在此方法中，平台管理員和開發人員通常只需存取 Microsoft Entra 租戶的管理權限。 此存取權會授與給他們對開發工具的存取權，例如 GitHub 或 Azure DevOps，所有租用戶都會藉由這些工具來部署和運行。
他們可能可透過 Microsoft Entra B2B 或 Azure Lighthouse 存取其他 Microsoft Entra 租戶。 他們可能使用與管理租戶相同的帳戶，或者擁有不同的帳戶，例如 第一種方法中的範例。