為組織開發治理模型時，請務必記住 ，Azure Resource Manager 是管理資源的一種方式。 Azure DevOps 和持續整合和持續傳遞 （CI/CD） 自動化在未正確保護的情況下，可能是非預期的安全性後門。 這些資源應該藉由鏡像 Resource Manager 所使用的角色型存取控制 （RBAC） 模型來保護。
端對端治理的概念與廠商無關。 此處所述的實作會使用 Azure DevOps ，但也會簡短提及替代方案。
潛在的使用案例
此參考實作和示範開放原始碼，其用途是作為 DevOps 新手組織的教學工具，且需要建立治理模型以部署至 Azure。 請仔細閱讀此案例，以瞭解此範例存放庫中所使用的模型背後的決策。
任何治理模型都必須系結至組織的商務規則，這些規則會反映在存取控制的任何技術實作中。 此範例模型會使用虛構的公司搭配下列常見案例（具有商務需求）：
符合商務網域和許可權模型的 Microsoft Entra 群組
該組織有許多垂直業務領域，例如「水果」和「蔬菜」，基本上獨立運作。 在每個商務網域中，有兩個層級或許可權會對應至不同的*-admins或*-devsMicrosoft Entra 群組。 這可讓開發人員在雲端中設定許可權時成為目標。部署環境
每個小組都有兩個環境：- 生產。 只有系統管理員具有較高的許可權。
- 非生產環境。 所有開發人員都有更高的許可權（鼓勵實驗和創新）。
自動化目標
每個應用程式都應該實作 Azure DevOps，而不只是持續整合 （CI），而且應該實作持續部署 （CD）。 例如，部署可以透過 Git 存放庫的變更自動觸發。到目前為止的雲端旅程
組織從隔離的專案模型開始，以加速雲端旅程。 但現在，他們正在探索打破孤島的選項，並鼓勵合作，建立「共同作業」和「超市」專案。
此簡化圖表顯示 Git 存放庫中的分支如何對應至開發、預備和生產環境：
下載此圖表 的 SVG。
架構
此圖顯示如何從 Resource Manager 和 CI/CD 連結至 Microsoft Entra ID，是擁有端對端治理模型的關鍵。
下載此架構 的 SVG。
注意
為了讓概念更容易理解，此圖表只會說明 「蔬菜」 領域。 「水果」網域看起來會類似，並使用相同的命名慣例。
工作流程
編號反映了 IT 系統管理員和企業架構設計人員考慮及設定其雲端資源的順序。
Microsoft Entra ID
我們會整合 Azure DevOps 與 Microsoft Entra ID ，以便有單一平面進行身分識別。 這表示開發人員針對 Azure DevOps 和 Resource Manager 使用相同的 Microsoft Entra 帳戶。 不會個別新增使用者。 相反地，成員資格是由 Microsoft Entra 群組指派，因此我們可以移除開發人員在單一步驟中存取資源的存取權，方法是移除其 Microsoft Entra 群組成員資格。 針對 每個網域 ，我們會建立：
- Microsoft Entra 群組。 每個網域有兩個群組（本文稍後的步驟 4 和 5 會進一步說明）。
- 服務主體。 每個環境 一個明確的服務主體 。
生產環境
為了簡化部署，此參考實作會使用資源群組來代表生產環境。 實際上，您應該使用不同的訂用 帳戶 。
此環境的特殊許可權存取僅限於系統管理員。
開發環境
為了簡化部署，此參考實作會使用資源群組來代表開發環境。 實際上，您應該使用不同的訂用 帳戶 。
Resource Manager 中的角色指派
雖然我們的 Microsoft Entra 組名意指角色，但在設定角色指派 之前 ，不會套用存取控制。 這會將角色指派給特定範圍的 Microsoft Entra 主體。 例如，開發人員在生產環境中具有參與者角色。
Microsoft Entra 主體 開發環境 （Resource Manager） 生產環境 （Resource Manager） veggies-devs-group負責人 讀者 veggies-admins-group負責人 負責人 veggies-ci-dev-sp自訂角色 * – veggies-ci-prod-sp– 自訂角色 * * 為了簡化部署，此參考實作會將
Owner角色指派給服務主體。 不過，在生產環境中，您應該建立 自訂角色 ，以防止服務主體移除您放在資源上的任何 管理鎖定 。 這有助於保護資源免于意外損毀，例如資料庫刪除。若要瞭解個別角色指派背後的原因，請參閱 本文稍後的考慮一節 。
Azure DevOps 中的安全性群組指派
安全性群組的運作就像 Resource Manager 中的角色一樣。 利用內建角色，並預設為 開發人員的參與者 。 管理員指派給 提高許可權的專案管理員istrator 安全性群組，讓他們能夠設定安全性許可權。
請注意，Azure DevOps 和 Resource Manager 有不同的 許可權模型：
因此，和
-devs群組的成員資格-admins必須互斥。 否則，受影響的人員在 Azure DevOps 中的存取權會低於預期。群組名稱 Resource Manager 角色 Azure DevOps 角色 fruits-all– – fruits-devs參與者 參與者 fruits-admins擁有者 Project 管理員istrators veggies-all– – veggies-devs參與者 參與者 veggies-admins擁有者 Project 管理員istrators infra-all– – infra-devs參與者 參與者 infra-admins擁有者 Project 管理員istrators 在有限的共同作業案例中，例如邀請蔬菜小組在單 一 存放庫上共同作業的水果小組，他們會使用群組
veggies-all。若要瞭解個別角色指派背後的原因，請參閱 本文稍後的考慮一節 。
服務連線
在 Azure DevOps 中， 服務連線是 認證周圍的泛型包裝函式。 我們會建立服務連線，以保存服務主體用戶端識別碼和用戶端密碼。 Project 管理員istrators 可以視需要設定此 受保護資源的 存取權，例如在部署前需要人工核准時。 此參考架構在服務連線上有兩個最低保護：
Git 存放庫
由於我們的服務連線會透過 分支控制項 系結至分支，因此設定 Git 存放庫的許可權並套用 分支原則 非常重要。 除了要求 CI 組建通過之外，我們也要求提取要求至少有兩個核准者。
元件
替代項目
端對端治理的概念與廠商無關。 雖然本文著重于 Azure DevOps，但 Azure DevOps Server 可作為內部部署替代專案。 或者，您也可以使用 Jenkins 和 GitLab 等 選項，針對開放原始碼 CI/CD 開發管線使用一組技術。
Azure Repos 和 GitHub 都是用來使用開放原始碼 Git 版本控制系統所建置的平臺。 雖然其功能集有些不同，但兩者都可以整合到 CI/CD 的全域治理模型中。 GitLab 是另一個 Git 型平臺，可提供強大的 CI/CD 功能。
此案例使用 Terraform 作為其基礎結構即程式碼 （IaC） 工具。 替代方案包括 Jenkins、 Ansible 和 Chef 。
考量
若要在 Azure 中實現端對端治理，請務必瞭解從開發人員電腦到生產環境路徑的安全性和許可權設定檔。 下圖說明使用 Azure DevOps 的基準 CI/CD 工作流程。 紅色鎖定圖示 
表示使用者必須設定的安全性許可權。 未設定或設定許可權時，您的工作負載會變得脆弱。
下載此工作流程 的 SVG。
若要成功保護您的工作負載，您必須在工作流程中使用安全性許可權設定和人為檢查的組合。 任何 RBAC 模型都必須同時延伸至管線和程式碼，這一點很重要。 這些通常會以特殊許可權身分識別執行，如果指示這麼做，將會終結您的工作負載。 若要避免這種情況發生，您應該在存放庫上設定 分支原則 ，以在接受觸發自動化管線的變更之前要求人工核准。
| 部署階段 | 責任 | 描述 |
|---|---|---|
| 提取要求 | 使用者 | 工程師應該對等檢閱其工作，包括管線程式碼本身。 |
| 分支保護 | [共用] | 將 Azure DevOps 設定 為拒絕不符合特定標準的變更，例如 CI 檢查和對等檢閱（透過提取要求）。 |
| 管線即程式碼 | 使用者 | 如果管線程式碼指示其執行此動作，組建伺服器將會刪除整個生產環境。 使用提取要求和分支保護規則的組合來協助避免這種情況，例如人工核准。 |
| 服務連線 | [共用] | 設定 Azure DevOps 以限制對這些認證的存取。 |
| Azure 資源 | [共用] | 在 Resource Manager 中設定 RBAC。 |
設計治理模型時，請務必考慮下列概念和問題。 請記住 此範例組織的潛在使用案例 。
1. 保管庫使用分支原則保護您的環境
因為您的原始程式碼會定義並觸發部署，因此您的第一道防線是保護您的原始程式碼管理 （SCM） 存放庫。 在實務上，這可藉由搭配分支 原則使用 提取要求工作流程來達成，這些工作流程 定義可接受程式碼前的檢查和需求。
規劃端對端治理模型時，特殊許可權使用者 （ veggies-admins ） 將負責設定分支保護。 用來保護您的部署的常見分支保護檢查包括：
要求 CI 組建通過。 適用于建立基準程式碼品質，例如程式碼 Linting、單元測試，甚至是病毒和認證掃描等安全性檢查。
需要對等檢閱 讓另一個人為雙重檢查程式碼如預期般運作。 對管線程式碼進行變更時，請特別小心。 結合 CI 組建，讓對等檢閱變得不那麼乏味。
如果開發人員嘗試直接推送至生產環境，會發生什麼事？
請記住，Git 是分散式 SCM 系統。 開發人員可以直接認可至其本機 production 分支。 但是，當 Git 正確設定時，Git 伺服器會自動拒絕這類推送。 例如：
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'
請注意，範例中的工作流程與廠商無關。 提取要求和分支保護功能可從多個 SCM 提供者取得，包括 Azure Repos 、 GitHub 和 GitLab 。
一旦程式碼接受至受保護的分支，組建伺服器就會套用下一層存取控制（例如 Azure Pipelines ）。
2.安全性主體需要哪些存取權？
在 Azure 中 ，安全性主體 可以是 使用者主體 或 無前端主體 ，例如服務主體或受控識別。 在所有環境中，安全性主體都應該遵循 最低許可權 原則。 雖然安全性主體在生產前環境中可能已擴充存取權，但生產 Azure 環境應將站立許可權降到最低，偏向 Just-In-Time 存取和 Microsoft Entra 條件式存取。 為使用者主體製作 Azure RBAC 角色指派，以配合這些最低許可權主體。
與 Azure DevOps RBAC 不同的 Azure RBAC 模型也很重要。 管線的目的是將直接存取 Azure 降到最低。 除了創新、學習和問題解決等特殊案例之外，大部分與 Azure 的互動都應該透過目的建置和閘道管線進行。
針對 Azure Pipeline 服務主體，請考慮使用 自訂角色 來防止其移除資源鎖定，並針對其目的執行其他破壞性動作。
3.為用來存取生產環境的服務主體建立自訂角色
提供 CI/CD 組建代理程式擁有者角色和許可權是常見的錯誤。 如果您的管線也需要執行身分識別角色指派或其他特殊許可權作業，例如金鑰保存庫原則管理，則參與者許可權是不夠的。
但如果被告知這麼做，CI/CD 建置代理程式將會刪除整個生產環境。 為了避免無法復原的破壞性變更 ，我們會建立自訂角色，以：
- 移除金鑰保存庫存取原則
- 移除設計應防止資源遭到刪除的管理鎖定 （受管制產業中常見的需求）
若要這樣做，我們會建立自訂角色並移除 Microsoft.Authorization/*/Delete 動作。
{
"Name": "Headless Owner",
"Description": "Can manage infrastructure.",
"actions": [
"*"
],
"notActions": [
"Microsoft.Authorization/*/Delete"
],
"AssignableScopes": [
"/subscriptions/{subscriptionId1}",
"/subscriptions/{subscriptionId2}",
"/providers/Microsoft.Management/managementGroups/{groupId1}"
]
}
如果移除太多許可權，請參照 Azure 資源提供者作業 官方檔中的完整清單 ，並視需要調整您的角色定義。
部署此案例
此案例延伸至 Resource Manager 以外。 這就是為什麼我們使用 Terraform ，這可讓我們也能夠在 Microsoft Entra ID 中建立主體，並使用單一基礎結構即程式碼工具啟動 Azure DevOps。
如需原始程式碼和詳細指示，請流覽 Azure 示範上的 GitHub 存放庫 治理 - 從 DevOps 到 ARM 。
定價
Azure DevOps 成本取決於您組織中需要存取的使用者數目，以及其他因素，例如所需的並行組建/版本數目和使用者數目。 Azure Repos 和 Azure Pipelines 是 Azure DevOps 服務的功能。 如需詳細資訊，請參閱 Azure DevOps 定價 。
在 Microsoft Entra ID 中，此案例所需的群組存取管理類型會在 進階版 P1 和 進階版 P2 版本中提供。 這些層的定價是以每個使用者為基礎計算。 如需詳細資訊，請參閱 Microsoft Entra 定價 。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- Julie Ng |高級服務工程師
下一步
- 請造訪 Azure 示範上的治理 - 從 DevOps 到 ARM 的此案例 的程式碼存放庫。
- 檢閱雲端採用架構的 雲端治理指南 。
- 什麼是 Azure 角色型存取控制 (Azure RBAC)？
- 雲端採用架構：Azure 中的資源存取管理
- Azure Resource Manager 角色
- Azure DevOps 安全性群組