採用政策驅動的護欄
在使用原則之前,您必須了解它們在 Azure 著陸區參考實作中的使用位置及原因。 本文將協助您瞭解是否希望防止 DeployIfNotExists (DINE) 或 修改策略在您的 Azure 環境中執行變更。
為什麼要使用 DINE 和修改原則?
DINE 和 Modify 原則是 Azure 登陸區域參考實作的一部分。 它們可協助您和貴組織確保您的登錄區(也包含訂用帳戶)及其內的資源符合規範標準。 這些政策也會隨著 Azure 環境的擴展而減少平臺和登陸區小組的操作負擔。
例如,假設已布建新的登陸區域訂用帳戶,並將其放在 「corp」 管理群組中。 DINE 和 Modify 政策接著會針對著陸區域訂用帳戶採取下列動作:
- 啟用適用於雲端Microsoft Defender。 在管理訂用帳戶中設定 Defender for Cloud 匯出至中央 Log Analytics 工作區。
- 根據原則指派中設定的原則參數,為不同支援方案啟用雲端 Defender。
- 設定 Azure 活動記錄,以傳送至管理訂用帳戶中的中心化 Log Analytics 工作區。
- 設定所有資源的診斷設定,以將其傳送至管理訂用帳戶中的中央 Log Analytics 工作區。
- 為虛擬機和 Azure 虛擬機擴展集部署必要的 Azure 監視器代理程式,包括 Azure Arc 連線的伺服器。 將它們連線到管理訂用帳戶中的中央 Log Analytics 工作區。
注意
您可以隨時或在部署 Azure 登陸區域參考實作期間停用上述選項。
上述清單會顯示指派為 Azure 登陸區域加速器一部分的所有原則子集。 如需 Azure 登陸區域參考實作可指派之原則的完整清單,請參閱 azure 登陸區域參考實作中包含的
Azure 登陸區域 bicep 存放庫 是模組化的。 您可以部署上述預設原則,使用 ALZ 預設原則指派模組。
所有指派的原則可協助您和著陸區擁有者保持合規。 不會透過 DINE 或調整政策來部署實際的工作負載資源。 我們也不建議這麼做。 如需詳細資訊,請參閱 我們應該使用 Azure 原則來部署工作負載嗎?。 這些 DINE 原則只會部署或設定輔助或支援的資源或設定。
Azure 登陸區域參考實作會使用 DINE Azure 原則,協助您在 Azure 環境中實現原則驅動的治理。 但是,您可能無法使用 DINE 或修改政策,或您尚未準備好啟用這種類型的 Azure 原則效果, 這是因為:
- 法規合規性政策、標準或法律限制。
- 嚴格的變更控制程式,需要人類核准 Azure 環境內的每個動作。
- 缺乏專業知識、經驗和瞭解如何管理和使用 DINE 原則。
- 組織要求工作負載應用程式小組將在基礎架構即程式碼(IaC)中定義所有工作負載資源配置,包括輔助資源、支援資源和設置。
如果您符合上述範例或類似的案例,本文可協助您瞭解如何採用 Azure 登陸區域概念架構,並遵循其 設計原則。 雖然您一開始不會使用特定原則,但您可以選擇在未來逐漸啟用這些原則。 目標是協助您實現 以政策為導向的治理。
重要
在本文中,您將會看到兩個可能用於強制模式詞彙的值:
- 停用或不強制執行
- 啟用或預設值
Azure 入口網站會針對強制模式使用 [已停用] 和 [已啟用]。 Azure Resource Manager (ARM) 範本及其他 API 介面使用 DoNotEnforce 和 Default 作為相同選項。
如需詳細資訊,請參閱 強制模式。
如果您仍然確定貴組織無法使用 DINE 或修改原則,本文說明如何防止原則對 Azure 環境進行自動變更。。
資源選取器的支援 也適用於原則導向治理,以確保奉行安全部署實務(SDP)。 資源選取器可根據資源位置、資源類型或資源是否具備位置等因素,逐步地實施原則分配的工作。 如需詳細資訊,請參閱本檔。
方法概觀
下圖摘要說明建議的階段式方法:
- 將原則指派中的 強制模式 設定為
DoNotEnforce
:- 藉由使用這項功能,您可以修改指派的行為,以有效地成為僅限稽核的原則,而不需修改基礎原則定義。
- 此方法也可讓您視需要使用 補救工作,在不符合規範的資源上執行手動補救工作,。
- 將原則指派的
強制模式 設為,以便在縮小範圍中重新啟用 DINE 原則指派的自動補救 。 - 您可以選擇使用整個環境,例如 Sandbox 管理群組。
- 或者,您可以使用非關鍵工作負載訂用帳戶。
- 設定 強制模式,將其應用於 Azure 環境中其餘 DINE 原則指派中的
Default
。
由於法規合規性限制,某些客戶永遠無法移過第 1 階段。 這不是問題,而且在必要時仍可維持此狀態。 其他客戶可以繼續進行階段 2 和 3,以完全採用 DINE 和 Modify 原則,以協助其 Azure 環境的原則導向治理。
注意
本文中所述的案例和方法不適用於或建議給大多數客戶。 檢閱 節「為何使用 DINE 和修改政策」以及 節,然後再決定這些政策是否適合並符合您的環境需求。
階段 1:停用 DINE 和修改原則自動化動作
當您指派原則時,預設會套用原則定義中定義的 效果。 建議您保留原則定義。 例如,將原則指派效果保留為 DeployIfNotExists
。
您可以改為使用政策指派中的功能,以最少的努力來影響這種行為,而不必變更政策定義或其效應。
使用 Azure 入口網站將強制模式設定為 [已停用]
此螢幕快照顯示如何使用 Azure 入口網站,在原則指派上將強制模式設定為 停用。 Disabled 也稱為 DoNotEnforce。
使用ARM範本將強制模式設定為 DoNotEnforce
此程式代碼範例示範怎麼用ARM範本,將 enforcementMode
設定為 DoNotEnforce
於策略指派中。
DoNotEnforce
也稱為 Disabled
。
{
"type": "Microsoft.Authorization/policyAssignments",
"apiVersion": "2019-09-01",
"name": "PolicyAssignmentName",
"location": "[deployment().location]",
"properties": {
"description": "PolicyAssignmentDescription",
"policyDefinitionId": "[parameters('policyDefinitionId')]",
"enforcementMode": "DoNotEnforce"
… // other properties removed for display purposes
}
}
藉由使用 強制模式,您可以查看原則對現有資源的影響,而不會啟動原則或觸發 Azure 活動記錄中的項目。 此案例通常稱為「What If」,且符合安全部署做法。
即使 強制模式 設定為 DoNotEnforce
,補救工作 也可以手動觸發。 您可以補救特定不符合規範的資源。 如果強制模式設定為 Default
,您也可以查看 DINE 或修改政策會執行哪些動作。
重要
當執行模式設定為 DoNotEnforce
時,不會在 Azure 活動記錄中產生條目。 如果您想要在建立不符合規範的資源時收到通知,請考慮此因素。
永久停留在階段 1 狀態
如 方法概觀 一節所述,某些客戶可能因其需求而需要長期或甚至永久留在 第1階段。 此狀態有效,客戶可以隨時留在該狀態中。
也許你需要永久或長期留在這個狀態,像幾年。 若是如此,最好是採用 AuditIfNotExists
(AINE) 原則效果和相關聯的定義,並將強制模式設定回 Default
。
注意
藉由變更為使用 AINE 原則,並將強制模式設定為 Default
,您仍然可以達到停用 DINE 的相同目標。
當您將變更從 DINE 為 AINE,並將強制模式重設為 Default
作為階段 1 的長期或永久方案時,您將重新獲得Azure 原則合規性的活動記錄條目。 您可以在整體平台管理作業中,從這些日誌條目建置自動化工作流程。
您將失去執行手動補救工作的功能。 不同於 DINE 原則,AINE 原則不會執行任何部署,無論是自動化或手動部署。
請記得更新原則定義以接受並允許 AuditIfNotExists
原則指派效果。
下表摘要說明不同類型的原則效果和強制模式組合的選項和含意:
政策效果 | 執行模式 | 活動日誌條目 | 補救動作 |
---|---|---|---|
吃飯 | 已啟用或預設 | 是的 | 在創建或資源更新後,由平臺觸發的大規模補救措施。 如果在原則指派之前修改或已有相依資源,則需要手動建立補救工作。 |
吃飯 | 停用或不強制 | 不 | 需要手動建立補救任務。 |
修改 | 啟用或預設 | 是的 | 在建立或更新過程中自動修復。 |
修改 | 停用或不強制執行 | 不 | 需要手動建立一個補救任務。 |
否認 | 啟用或預設 | 是的 | 建立或更新遭拒。 |
否認 | 停用或不強制執行 | 不 | 允許建立或更新。 需要手動補救。 |
審核/AINE | 啟用或預設值 | 是的 | 需要手動補救。 |
審計/AINE | 停用 或 不強制 | 不 | 需要手動補救。 |
附註
檢閱「反應 Azure 原則狀態變更事件」中的指引, 以瞭解如果您打算根據原則狀態事件建置自己的自動化,使用 Azure 事件網格與 Azure 原則的整合是否提供適當的方法。
階段 2:在特定原則上啟用 DINE 和修改原則,或縮小範圍
在此階段中,您將瞭解如何將強制模式設定為針對政策指派的 Default
。
完成 階段 1之後,您決定要在特定原則或縮小範圍上測試和試用 DINE 的完整自動化功能以及修改原則。 您想要使用沙箱管理群組或非生產工作負載訂用帳戶。
若要執行此程式,首先您必須識別將用來測試及嘗試 DINE 和 Modify 原則的完整自動化功能的原則或縮減範圍。
下表顯示一些建議的範圍和原則範例:
當您要... | 從這些範圍中選擇 | 要使用的範例原則 |
---|---|---|
- 測試 DINE/修改自動化補救功能。 - 驗證您的完整部署流程和 CI/CD 管線,包括測試,可能會受到哪些影響。 - 確認工作負載可能受到的影響。 |
- 沙箱訂用帳戶 - 沙箱管理群組 - 非生產工作負載登陸區域訂用帳戶 - 企業級的「canary」環境 |
- 設定 Azure 活動記錄以串流至指定的 Log Analytics 工作區。 - 部署 Defender for Cloud 設定。 - 啟用適用於 VM 或虛擬機擴展集的 Azure 監視器。 - 將診斷設定部署至 Azure 服務。 - 可能只針對計劃內的特定服務啟用。 |
您也可以決定在有限的範圍或一組資源上使用手動補救工作,以測試這些原則如何影響您的環境。 如需如何建立補救工作的詳細資訊,請參閱 Azure 原則檔 建立補救工作。
識別出原則或原則,以及指派原則的縮減範圍之後,下一個步驟是指派原則,並將強制模式設定為 Default
。 保留政策效果,例如DeployIfNotExists
或 Modify
,與您選取的較小範圍一致。
使用 Azure 入口網站將強制模式設定為 [已啟用]
此螢幕快照顯示如何在原則指派上使用 Azure 入口網站將強制模式設定為 已啟用。 Enabled 也被稱為 Default。
使用 ARM 範本將強制模式設定為預設值
此程式碼範例示範如何使用ARM範本,將 enforcementMode
設定為 Default
在原則指派中。
Default
也稱為 Enabled
。
{
"type": "Microsoft.Authorization/policyAssignments",
"apiVersion": "2019-09-01",
"name": "PolicyAssignmentName",
"location": "[deployment().location]",
"properties": {
"description": "PolicyAssignmentDescription",
"policyDefinitionId": "[parameters('policyDefinitionId')]",
"enforcementMode": "Default"
… // other properties removed for display purposes
}
}
測試
此階段的最後一個步驟是執行必要的測試。 您想要確認 DINE 或 Modify 原則是否會影響您的工作負載、程式碼、工具和流程,以及這些原則如何對其產生變化。
執行多個測試以擷取工作負載的整個生命週期。 您想要確保您完全瞭解是否以及如何透過 DINE 或修改原則來進行變更。
測試的一些範例包括:
- 工作負載的初始部署。
- 將程式代碼/應用程式部署到工作負載。
- 第 2 天操作和管理負荷。
- 卸除工作負載。
階段 3:在任何地方啟用 DINE 和修改原則
在此階段中,您將瞭解如何在原則指派中將執行模式設定為 Default
。
我們假設您在 第 2 階段結束時的 測試 已成功通過。 或者,您可能會覺得滿意,因為您現在瞭解 DINE 或調整規則是如何與您的工作負載互動的。 現在,您可以在 Azure 環境的其他部分擴展 DINE 和 Modify 政策的使用。
若要繼續進行,請遵循與 階段 2中步驟類似的步驟。 這次,您會將強制模式設定為 Default
,適用於整個 Azure 環境中的所有 DINE 和修改原則指派。
以下是您在這個階段中執行的主要步驟的大致概況:
- 拿掉在階段 2期間特別用於
測試的指派。 - 逐一查看您 Azure 環境中的每個 DINE 和修改政策指派,並將其執行模式設為
Default
。 此過程如第二階段的範例所示。 - 遵循 建立補救工作中的指引,為不符合規範的現有資源建立補救工作。 如果新資源符合原則規則和存在條件,則會自動加以補救。
雖然在第 3 階段中,我們建議您將所有 DINE 和 Modify 原則的強制模式設為 Default
,但在 Azure 環境中,此選擇仍然是選擇性的。 您可以根據每個政策做出這個選擇,以符合您的需求。
進階政策管理
若要大規模管理 Azure 原則,請考慮實作 企業原則即程式碼(EPAC),以進行原則管理。 EPAC 提供使用 IaC 的有狀態管理體驗。 它通常適用於具有複雜需求的大型政策管理場景。