採用原則驅動的護欄

使用原則之前，您必須了解它們在 Azure 登陸區域參考實作內的位置，以及原因。 本文將協助您瞭解是否要防止 DeployIfNotExists （DINE） 或修改原則在您的 Azure 環境中進行變更。

為什麼要使用 DINE 和修改原則？

DINE 和 Modify 原則是 Azure 登陸區域參考實作的一部分。 它們可協助您和貴組織確保登陸區域，也稱為訂用帳戶，且其內的資源符合規範。 這些原則也會隨著 Azure 環境調整而移除平臺和登陸區域小組的操作負擔。

例如，假設已布建新的登陸區域訂用帳戶，並將其放在 「corp」 管理群組中。 DINE 和 Modify 原則接著會針對登陸區域訂用帳戶採取下列動作：

• 啟用 適用於雲端的 Microsoft Defender。 設定 適用於雲端的 Defender 匯出至管理訂用帳戶中的中央 Log Analytics 工作區。
• 根據原則指派上設定的原則參數，為不同的支援供應項目啟用 適用於雲端的 Defender。
• 設定要傳送至管理訂用帳戶中中央 Log Analytics 工作區的 Azure 活動記錄。
• 設定要傳送至管理訂用帳戶中中央 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 原則。
• 工作負載應用程式小組會在基礎結構中定義所有工作負載資源設定的組織需求，包括輔助資源、支援資源和設定。

如果您符合上述範例或類似的案例，本文可協助您瞭解如何採用 Azure 登陸區域概念架構 ，並遵循其 設計原則。 雖然您一開始不會使用特定原則，但您可以選擇在未來逐漸啟用這些原則。 目標是協助您達成 原則導向治理。

重要

在本文中，您將會看到兩個可能用於強制模式詞彙的值：

• Disabled 或 DoNotEnforce
• 已啟用或預設

Azure 入口網站 會針對強制模式使用 Disabled 和 Enabled。 Azure Resource Manager （ARM） 範本和其他 API 介面使用相同的選項使用 DoNotEnforce 和 Default。

如需詳細資訊，請參閱 強制模式。

如果您仍然確定貴組織無法使用 DINE 或修改原則，本文說明如何防止原則對 Azure 環境進行自動變更。。

注意

此作業不是永久性的。 如果您稍後決定使用 DINE 或修改原則，則平臺小組的成員可以隨時重新啟用原則。

如需詳細資訊，請參閱階段 2 和階段 3。

資源選取器的支援也適用於原則導向治理，以確保遵守 保管庫 部署實務（SDP）。 資源選取器會根據資源位置、資源類型，或資源是否具有位置等因素，逐步推出原則指派的功能。 如需詳細資訊，請參閱本檔。

方法概觀

下圖摘要說明建議的階段式方法：

1. 將原則 指派上的強制模式 設定為 DoNotEnforce ：
   • 藉由使用這項功能，您可以修改指派的行為，以有效地成為僅限稽核的原則，而不需修改基礎原則定義。
   • 這個方法也可讓您視需要使用補救工作，對不符合規範的資源 執行手動補救工作 。
2. 將原則指派上的強制模式設定為 Default ，以在縮減範圍上重新啟用 DINE 原則指派的自動補救：
   • 您可以選擇使用整個環境，例如沙箱管理群組。
   • 或者，您可以使用非關鍵工作負載訂用帳戶。
3. 將 強制模式 設定為 Default 在整個 Azure 環境中其餘的 DINE 原則上的原則指派。

由於法規合規性限制，某些客戶永遠無法移過第 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 指派效果。

下表摘要說明不同類型的原則效果和強制模式組合的選項和含意：

原則效果	強制模式	活動記錄項目	補救動作
吃飯	已啟用或預設	Yes	建立或資源更新之後，平臺觸發的大規模補救。 在原則指派之前修改或預先存在相依資源時，手動建立所需的補救工作。
吃飯	Disabled 或 DoNotEnforce	No	需要手動建立補救工作。
Modify	已啟用或預設	Yes	在建立或更新期間自動補救。
Modify	Disabled 或 DoNotEnforce	No	需要手動建立補救工作。
拒絕	已啟用或預設	Yes	建立或更新遭拒。
拒絕	Disabled 或 DoNotEnforce	No	允許建立或更新。 需要手動補救。
Audit/AINE	已啟用或預設	Yes	需要手動補救。
Audit/AINE	Disabled 或 DoNotEnforce	No	需要手動補救。

注意

如果您打算根據原則狀態事件建置自己的自動化，請檢閱回應 Azure 原則 狀態變更事件中的指引，以瞭解是否使用 Azure 事件方格 與 Azure 原則 整合提供適當的方法。

階段 2：在特定原則上啟用 DINE 和修改原則，或縮小範圍

在這裡階段中，您將瞭解如何在原則指派上將強制模式設定為 Default 。

完成 第 1 階段之後，您決定要測試並試用特定原則上或縮小範圍上的 DINE 和 Modify 原則的完整自動化功能。 您想要使用沙箱管理群組或非生產工作負載訂用帳戶。

若要執行此程式，首先您必須識別將用來測試及嘗試 DINE 和 Modify 原則的完整自動化功能的原則或縮減範圍。

注意

您可能想要檢閱及實 作企業級 平台的測試方法。 如此一來，您就可以在相同租使用者內的個別管理群組階層中測試原則和其他平台變更。

這種方法也稱為「Canary」部署。

下表顯示一些建議的範圍和原則範例：

當您要...	...從這些範圍中選擇	要使用的範例原則
- 測試 DINE/修改自動化補救功能。 - 確認完整的部署程式和 CI/CD 管線，包括測試，可能會受到影響。 - 確認工作負載可能受到的影響。	- 沙箱訂用帳戶 - 沙箱管理群組 - 非生產工作負載登陸區域訂用帳戶 - 企業級的“Canary” 環境	- 設定 Azure 活動記錄以串流至指定的 Log Analytics 工作區。 - 部署 適用於雲端的 Defender 組態。 - 啟用 適用於 VM 的 Azure 監視器 或 虛擬機器擴展集。 - 將診斷設定部署至 Azure 服務。 - 可能只針對計劃內的特定服務啟用。

您也可以決定在有限的範圍或一組資源上使用手動補救工作，以測試這些原則如何影響您的環境。 如需如何建立補救工作的詳細資訊，請參閱建立補救工作 Azure 原則 檔。

識別出原則或原則，以及指派原則的縮減範圍之後，下一個步驟是指派原則，並將強制模式設定為 Default。 保留原則效果，例如 或 Modify，DeployIfNotExists如同您選取的範圍縮小。

使用 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 中步驟類似的步驟。 這一次，您會在所有 DINE 和修改整個 Azure 環境的原則指派上，將強制模式設定為 Default 。

以下是您在這個階段中執行的步驟概觀：

• 拿掉在階段 2 期間特別用於測試的指派。
• 瀏覽 Azure 環境中的每個 DINE 和修改原則指派，並將強制模式設定為 Default。 此程式會顯示在階段 2 的範例中。
• 遵循建立補救工作中的 指引，為不符合規範的現有資源建立補救工作。 如果新資源符合原則規則和存在條件，則會自動加以補救。

雖然在階段 3 中，建議您針對 Azure 環境中的所有 DINE 和 Modify 原則，將強制模式設定為 Default ，但這個選擇仍然是選擇性的。 您可以根據每個原則做出這個選擇，以符合您的需求和需求。

進階原則管理

若要大規模管理 Azure 原則，請考慮實作企業原則即程序代碼 （EPAC） 來管理原則。 EPAC 提供使用 IaC 的具狀態管理體驗。 它通常適用於具有複雜需求的大型原則管理案例。