注意
本文僅適用於 azure Microsoft，不適用於任何其他Microsoft雲端供應專案，例如 Microsoft 365 或 Microsoft Dynamics 365。
某些組織可能會想要測試其 Azure 登陸區域平臺部署的 Azure 原則定義和指派、角色型訪問控制 （RBAC） 自定義角色和指派等等。 您可以使用 Azure Resource Manager 範本（ARM 範本）、Terraform、Bicep，或透過 Azure 入口網站手動完成測試。 本指南提供一種方法，可用來測試變更及其對 Azure 登陸區域平臺部署的影響。
本文也可以與平臺自動化和 DevOps 重要設計區域指引搭配使用，因為它與 PlatformOps 和 Central 功能小組和工作相關。 此外，也可以結合 採用原則驅動護欄 中的指引，以取得對 Azure 登陸區域部署推出原則變更的技術。
本指南最適用於管理生產管理群組階層變更的健全變更管理程序的組織。 Canary 管理群組階層可以獨立用來撰寫和測試部署，再將它們部署到生產環境。
注意
Canary 一詞用於避免與開發環境或測試環境混淆。 此名稱僅供說明之用。 您可以為您的 Canary Azure 著陸區環境定義任何您認為合適的名稱。
同樣地，在整個指引中使用 生產環境/階層 一詞來參考貴組織可能已具備的 Azure 登陸區域管理群組階層，其中包含您工作負載的 Azure 訂用帳戶和資源。
平台定義
重要
本指南不適用於應用程式或服務擁有者將使用的開發環境或測試環境，稱為登陸區域、工作負載、應用程式或服務。 這些會置於生產環境中的 Azure 著陸區域管理群組階層，並與相關治理（RBAC 和 Azure 原則）一起處理。
如需開發、測試、使用者驗收測試（UAT）和應用程式工作負載和小組的生產環境指引，請參閱 在 Azure 登陸區域中管理應用程式開發環境。
本指南僅適用於 Azure 登陸區域內容中的平臺層級測試和變更。
Azure 登陸區域可協助您設計和部署必要的 Azure 平台元件，讓您能夠大規模建構及運作登陸區域。
本文範圍中的平台資源及此測試方法如下：
| 產品或服務 | 資源提供者和類型 |
|---|---|
| 管理群組 | Microsoft.Management/managementGroups |
| 管理群組訂用帳戶關聯 | Microsoft.Management/managementGroups/subscriptions |
| 原則定義 | Microsoft.Authorization/policyDefinitions |
| 政策倡議定義或政策集定義 | Microsoft.Authorization/policySetDefinitions |
| 原則指派 | Microsoft.Authorization/policyAssignments |
| RBAC 角色定義 | Microsoft.Authorization/roleDefinitions |
| RBAC 角色指派 | Microsoft.Authorization/roleAssignments |
| 訂用帳戶 | Microsoft.Subscription/aliases |
範例案例和結果
此案例的範例是一個組織，其想要根據原則驅動的治理設計原則，測試新 Azure 原則 的影響和結果，以控管所有登陸區域中的資源和設定。 他們不想直接對生產環境進行這項變更，因為他們擔心它可能造成的影響。
使用 Canary 環境來測試此平台變更，可讓組織實作及檢閱 Azure 原則 變更的影響和結果。 此程式可確保其符合組織的需求，再將 Azure 原則 實作至生產環境。
類似的案例可能是 Azure RBAC 角色指派和Microsoft Entra 群組成員資格的變更。 在生產環境中進行變更之前，可能需要一種測試形式。
重要
對於大多數客戶來說，這不是常見的部署方法或模式。 Azure 登陸區域部署不是強制性的。
圖 1：Canary 管理群組階層。
如圖所示，整個 Azure 著陸區生產管理群組階層會在 Tenant Root Group 下重複。
Canary 名稱會被附加到管理群組的顯示名稱和識別碼上。 識別碼在單一 Microsoft Entra 租用戶內必須是唯一的。
注意
金絲雀管理群組名稱可以與生產管理群組名稱相同。 這可能會導致使用者混淆。 因此，我們建議將名稱 「canary」 附加至顯示名稱和標識碼。
接著會使用 Canary 管理群組階層來簡化下列資源類型的測試：
- 管理群組
- 訂閱配置
- RBAC
- 角色 （內建和自訂）
- 指派
- Azure 原則
- 定義 （內建和自訂）
- 計劃，也稱為集合定義
- 指派
如果您不想部署 Canary 管理群組階層，該怎麼辦？
如果您不想部署 Canary 管理群組階層，您可以使用 沙箱訂閱 在生產環境階層內測試平台資源，如下圖所示。
圖 2：強調沙盒環境的 Azure 著陸區域管理群組階層。
若要在此案例中測試 Azure 原則 和 RBAC，您需要將擁有者 RBAC 角色指派給您想要完成測試的單一 Azure 訂用帳戶，例如使用者帳戶、服務主體或受控服務識別。 此設定可讓您在沙箱訂用帳戶的範圍內撰寫、指派及修正 Azure Policy 的定義和指派。
例如，如果您正在開發新的自定義 RBAC 角色來授與特定使用案例的許可權，此沙盒方法也可用於訂用帳戶內的 RBAC 測試。 此測試全都可以在沙箱訂用帳戶中完成，並在階層中建立和指派較高角色之前進行測試。
這種方法的優點是沙箱訂用帳戶可在需要的時間使用，然後從環境中刪除。
不過，此方法不允許您在管理群組階層中測試 RBAC 和 Azure 原則的繼承情況。
實作指導
以下指引說明如何實作和使用 Azure 登陸區域的 Canary 管理群組階層，以及生產環境 Azure 登陸區域管理群組階層。
警告
如果您今天使用 Azure 入口網站來部署和管理您的 Azure 登陸區域環境，可能會因為生產環境和金絲雀環境經常不同步的高風險，難以有效地採用和使用金絲雀策略，因此無法提供與生產環境類似複本的階層和環境。
如果您在此情況中，如上所列，請考慮採用 Azure 登陸區域的基礎設施即程式碼 (IaC) 部署方法。 或者請注意金絲雀版本與生產環境之間設定飄移的潛在風險，並謹慎處理。 如需詳細資訊，請參閱 使用 IaC 更新 Azure 登陸區域。
- 使用個別的 Microsoft Entra 服務主體（SPN）或受控識別（MI），這些主體會授予相關生產環境或金絲雀環境 Azure 登陸區域管理群組階層的許可權。
- 本指南遵循最低權限原則 （PoLP）
- 使用 Git 存放庫、分支或存放庫內的個別資料夾來保存生產環境和 Canary 環境 Azure 登陸區域部署的 IaC。
- 根據部署的階層而定，使用相關的Microsoft Entra 服務主體 （SPN） 或受控識別 （MIS） 作為 CI/CD 管線的一部分。
- 實作 Canary 環境的 Git 分支原則或安全性，和生產環境中的設置一致。
- 在金絲雀環境中考慮減少核准者和檢查程序，以迅速偵測失敗。
- 使用相同的 Azure Pipelines 或 GitHub 動作，以使用環境變數來變更要部署的階層。 另一個選項是複製管線，並修改硬式編碼設定，以定義要部署的階層。
- 使用 Azure Pipelines DevOps 範本 或 GitHub Actions 工作流程範本 可協助您遵守 「不要重複您自己」（DRY） 原則。
- 在個別的計費帳戶下擁有一組金絲雀訂閱，例如企業合約（EA）帳戶或 Microsoft 客戶合約（MCA）發票區段，可根據需要在金絲雀管理群組階層中移動。
- 將一組資源始終部署在金絲雀環境的訂閱中，以加快變更至金絲雀環境的測試和驗證可能會有所幫助。
- 有一組範例應用程式工作負載架構，您可以部署到 Canary 環境中的 Canary 訂用帳戶，以測試 Azure 原則和 RBAC 的變更。 這可協助您在部署變更並將變更推動至生產環境之前先驗證變更。
- 這些範例工作負載可以使用用來部署生產應用程式工作負載的相同 IaC 範本來部署。 這可協助您確保「Canary」環境與生產環境同步，而且您測試的變更是正確且適用於生產環境。
- 您應該持續檢閱和更新範例工作負載，以確保它們與組織中最新的架構和設計模式相關且最新。
- 如果您為應用程式小組提供參考架構，也請考慮將這些架構部署到 Canary 環境。 這可協助您根據參考架構驗證變更，並確保它們適用於生產環境。
- 根據 Azure 登陸區域設計建議，將所有 Azure 訂用帳戶的所有 Azure 活動記錄，包括任何 Canary 環境訂用帳戶傳送至生產環境 Azure Log Analytics 工作區。
- 這有助於您的安全性和作業小組監視金絲雀環境中，是否有任何可能因對生產環境進行 Azure 原則和 RBAC 變更測試而產生的變更或問題。
提示
如果您已在生產環境中部署 Azure 著陸區，且現在想要新增金絲雀環境。 請考慮複製您目前的生產環境階層部署，並修改資源名稱，以使用金絲雀命名方案作為前置詞。
這是為了確保您部署用以啟用「Canary」環境的內容，從一開始就與生產環境同步。 搭配 Git 存放庫使用 IaC 工具時，可以輕鬆地達成此目的。
使用單一 Microsoft Entra 租戶
當您使用單一 Microsoft Entra 租使用者時，需要考慮以下事項。
- 使用單一租戶符合 Azure 登陸區域設計建議，適用於 Microsoft Entra 租戶。
- 在單一 Microsoft Entra 租用戶中，您可以針對生產環境與 Canary Azure 登陸區環境使用不同的 Microsoft Entra 群組，並將相同的使用者指派給其相關的管理群組階層結構。
- 因為在不同 Microsoft Entra 租戶之間存在多重身分識別而導致 Microsoft Entra ID 授權成本增加或重複。 這與使用 Microsoft Entra ID P1 或 P2 功能的客戶特別相關。
- RBAC 變更在金絲雀環境和生產環境中都更為複雜，因為在兩個 Microsoft Entra 租戶中，使用者和群組可能不相同。
- 請考慮使用者和群組標識碼在 Microsoft Entra 租用戶之間不會相同，因為它們是全域唯一的。
- 減少因管理多個 Microsoft Entra 租戶所造成的複雜性和管理負擔。
- 例如，擁有特殊權限的使用者必須維護存取並登入不同租戶執行測試時，可能會不小心對生產環境而不是測試環境進行變更。
- 降低設定漂移和部署失敗的可能性。
- 不需要建立額外的安全性措施和緊急存取程序。
- 減少摩擦，以及實作 Azure 登陸區域部署變更所需的時間。
下一步
一旦有了 canary 環境，您就可以開始測試 Azure Policy 和 RBAC 變更，再將它們部署到生產環境的 Azure 登陸區域管理群組階層。
當您在 Canary 環境中測試 Azure 原則的變更時，您可以遵循 採用原則驅動防護措施 指引中所述的相同方法，將其升階至生產環境。 這可以透過使用政策指派的強制模式功能來實現。 在實施 Azure 原則至生產環境並達到預期效果之前，使用本指南中所述的方法讓您能進行額外的測試階段，這將有助於您建立對 Azure 原則變更的信心。
您也可以檢閱應用程式小組的沙箱環境，以用於開發及測試其工作負載。 這是 Canary 環境的個別概念，可用來為應用程式小組在部署至生產環境之前開發及測試其工作負載提供安全的環境。