Azure 原則計畫定義結構

發行項
07/17/2024

計畫可讓您將數個相關的原則定義組成群組來簡化指派和管理，因為您可以將一個群組當作單一項目來使用。例如，您可以將相關的標籤原則定義組成單一方案。您可以套用該計畫，而不個別指派每個原則。

您可以使用 JSON 來建立原則計畫定義。原則計畫定義包含下列項目的元素：

顯示名稱
description
中繼資料
version
parameters
原則定義
原則群組 (此屬性是法規合規性 (預覽) 功能的一部分)

下列範例說明如何建立一個處理兩個標籤 (costCenter 和 productName) 的計畫。它會使用兩個內建的原則來套用預設標籤值。

{
    "properties": {
        "displayName": "Billing Tags Policy",
        "policyType": "Custom",
        "description": "Specify cost Center tag and product name tag",
        "version" : "1.0.0",
        "metadata": {
            "version": "1.0.0",
            "category": "Tags"
        },
        "parameters": {
            "costCenterValue": {
                "type": "String",
                "metadata": {
                    "description": "required value for Cost Center tag"
                },
                "defaultValue": "DefaultCostCenter"
            },
            "productNameValue": {
                "type": "String",
                "metadata": {
                    "description": "required value for product Name tag"
                },
                "defaultValue": "DefaultProduct"
            }
        },
        "policyDefinitions": [{
                "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-460c-a204-c1c3969c6d62",
                "definitionVersion": "1.*.*"
                "parameters": {
                    "tagName": {
                        "value": "costCenter"
                    },
                    "tagValue": {
                        "value": "[parameters('costCenterValue')]"
                    }
                }
            },
            {
                "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-187a4f81c498",
                "parameters": {
                    "tagName": {
                        "value": "costCenter"
                    },
                    "tagValue": {
                        "value": "[parameters('costCenterValue')]"
                    }
                }
            },
            {
                "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-460c-a204-c1c3969c6d62",
                "parameters": {
                    "tagName": {
                        "value": "productName"
                    },
                    "tagValue": {
                        "value": "[parameters('productNameValue')]"
                    }
                }
            },
            {
                "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-187a4f81c498",
                "parameters": {
                    "tagName": {
                        "value": "productName"
                    },
                    "tagValue": {
                        "value": "[parameters('productNameValue')]"
                    }
                }
            }
        ]
    }
}

Azure 原則內建和模式位於 Azure 原則範例。

中繼資料

選用 metadata 屬性會儲存原則計畫定義的資訊。客戶可以在 metadata 中，定義適合組織的任何屬性和值。不過，Azure 原則和內建中會使用一些「通用」屬性。

通用中繼資料屬性

version (字串)：追蹤原則計畫定義內容版本的詳細資料。針對內建，此中繼資料版本會遵循內建的版本屬性。建議使用此中繼資料版本的版本屬性。
category (字串)：決定在 Azure 入口網站中的哪個類別下顯示原則定義。

注意

針對法規合規性計畫，category 必須是 [法規合規性]。
preview (布林值)：如果原則計畫定義為預覽即使用 True 或 false 旗標。
deprecated (布林值)：如果原則計畫定義標示為「已取代」，則為 True 或 False 旗標。

版本 (預覽)

內建原則計畫可以裝載多個具有相同 definitionID 的版本。如果未指定版本號碼，則所有體驗都將顯示定義的最新版本。若要查看內建的特定版本，必須在 API、SDK 或 UI 中進行指定。若要參考指派內特定版本的定義，請參閱指派內的定義版本

Azure 原則服務會使用version、 preview和 deprecated 屬性，將狀態和變更層級傳達至內建原則定義或計劃。 version 的格式如下：{Major}.{Minor}.{Patch}。當原則定義處於預覽狀態時，後綴預覽會附加至屬性， version 並視為 布爾值。當原則定義已被取代時，會使用 "deprecated": "true"擷取取代做為定義元數據中的布爾值。

主要版本 (例如：2.0.0)：引進重大變更，例如主要規則邏輯變更、移除參數、預設新增強制效果。
次要版本 (例如：2.1.0)：引進變更，例如次要規則邏輯變更、新增參數允許的值、變更角色 definitionIds、新增或移除計畫內的定義。
修補程式版本 (例如：2.1.4)：引進字串或中繼資料變更，以及緊急安全性案例 (罕見)。

內建計畫已建立版本，並且也可以在內建或自訂計畫中參考內建原則定義的特定版本。如需詳細資訊，請參閱參考定義和版本。

在預覽期間，透過入口網站建立計畫時，您將無法指定內建原則定義參考的版本。透過入口網站建立的自訂計畫中的所有內建原則參考，都會改成預設為最新版本的原則定義。

如需 Azure 原則版本內建的詳細資訊，請參閱內建版本設定。若要深入了解原則已被取代或處於預覽狀態的意義，請參閱預覽和已被取代的原則。

參數

參數可減少原則定義數量來幫助您簡化原則管理。試想參數是表單上的欄位 – name、address、city、state。這些參數一律保持不變，不過它們的值則會根據填寫表單的個人而有所變更。建置原則計畫時，參數也是以相同的方式運作。在原則計畫定義中包括參數，即可在所包括的原則中重複使用該參數。

注意

一旦指派計畫，就無法更改計畫層級參數。因此，建議您在定義參數時，設定 defaultValue。

參數屬性

參數有下列在原則計畫定義中使用的屬性：

name：參數的名稱。由原則規則中的 parameters 部署函式使用。如需詳細資訊，請參閱使用參數值。
type: 判斷參數是字串、陣列、物件、布林值、整數、浮點數還是日期時間。
metadata：定義主要由 Azure 入口網站使用的子屬性，以顯示使用者易讀的資訊：
- description:(選擇性) 參數用途的說明。能用來提供可接受值的範例。
- displayName: 參數在入口網站中顯示的自訂名稱。
- strongType: (選擇性) 透過入口網站指派原則定義時會使用。提供內容感知清單。如需詳細資訊，請參閱 strongType。
defaultValue:(選擇性) 如果沒有提供值，就在指派中設定參數的值。
allowedValues:(選擇性) 提供參數在指派期間所接受的值陣列。

例如，您可以定義原則計畫定義，以限制各種所含原則定義中的資源位置。該原則計畫定義的參數可為 allowedLocations。此參數接著可供每個包括的原則定義使用，並在指派原則計畫期間進行定義。

"parameters": {
    "init_allowedLocations": {
        "type": "array",
        "metadata": {
            "description": "The list of allowed locations for resources.",
            "displayName": "Allowed locations",
            "strongType": "location"
        },
        "defaultValue": [ "westus2" ],
        "allowedValues": [
            "eastus2",
            "westus2",
            "westus"
        ]
    }
}

將參數值傳遞至原則定義

您可以在計畫定義的 policyDefinitions 陣列中，宣告要將哪些計畫參數傳遞至哪些包括的原則定義。雖然參數名稱可以相同，但計畫中使用的名稱與原則定義中不同，可簡化程式碼可讀性。

例如，先前定義的 init_allowedLocations 計畫參數可以傳遞至數個包含的原則定義和其參數 (sql_locations 和 vm_locations)，如下所示：

"policyDefinitions": [
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/0ec8fc28-d5b7-4603-8fec-39044f00a92b",
        "policyDefinitionReferenceId": "allowedLocationsSQL",
        "parameters": {
            "sql_locations": {
                "value": "[parameters('init_allowedLocations')]"
            }
        }
    },
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/aa09bd0f-aa5f-4343-b6ab-a33a6a6304f3",
        "policyDefinitionReferenceId": "allowedLocationsVMs",
        "parameters": {
            "vm_locations": {
                "value": "[parameters('init_allowedLocations')]"
            }
        }
    }
]

此範例參考參數屬性中示範的 init_allowedLocations 參數。

strongType

在 metadata 屬性中，您可以使用 strongType 在 Azure 入口網站中提供多重選取的選項清單。 strongType 可以是支援的資源類型或允許的值。若要判斷資源類型是否適用於 strongType，請使用 Get-AzResourceProvider。

支援部分不是由 Get-AzResourceProvider 傳回的資源類型。這些資源類型為：

Microsoft.RecoveryServices/vaults/backupPolicies

strongType 的非資源類型允許值為：

location
resourceTypes
storageSkus
vmSKUs
existingResourceGroups

原則定義

計畫定義的 policyDefinitions 部分是計畫中所含現有原則定義的「陣列」。如將參數值傳遞至原則定義中所述，此屬性是將計畫參數傳遞至原則定義的位置。

原則定義屬性

每個代表原則定義的 array 元素都有下列屬性：

policyDefinitionId (字串)：要包括的自訂或內建原則定義的識別碼。
policyDefinitionReferenceId (字串)：所包括原則定義的簡短名稱。
parameters：(選用) 將計畫參數傳遞至所包括的原則定義以作為該原則定義中屬性的名稱/值組。如需詳細資訊，請參閱參數。
definitionVersion：(選用) 要參考的內建定義版本。如果未指定任何版本，則會在指派時間參考最新的主要版本，並自動擷取任何次要更新。如需詳細資訊，請參閱定義版本
groupNames (字串陣列)：(選用) 原則定義為其成員的群組。如需詳細資訊，請參閱原則群組。

以下 policyDefinitions 範例具有兩個所包括的原則定義，而每個定義都已傳遞相同的計畫參數：

"policyDefinitions": [
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/0ec8fc28-d5b7-4603-8fec-39044f00a92b",
        "policyDefinitionReferenceId": "allowedLocationsSQL",
        "definitionVersion": "1.2.*"
        "parameters": {
            "sql_locations": {
                "value": "[parameters('init_allowedLocations')]"
            }
        }
    },
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/aa09bd0f-aa5f-4343-b6ab-a33a6a6304f3",
        "policyDefinitionReferenceId": "allowedLocationsVMs",
        "parameters": {
            "vm_locations": {
                "value": "[parameters('init_allowedLocations')]"
            }
        }
    }
]

原則定義群組

計畫定義中的原則定義可以進行分組和分類。 Azure 原則的法規合規性 (預覽) 功能會使用此屬性，以將定義分組到「控制項」和「合規性領域」。此資訊定義於 policyDefinitionGroupsarray 屬性中。您可以在 Microsoft 所建立的 policyMetadata 物件中找到更多群組詳細資料。如需相關資訊，請參閱中繼資料物件。

原則定義群組參數

policyDefinitionGroups 中的每個 array 元素都必須有下列兩個屬性：

name (字串) [必要]：「群組」的簡短名稱。在法規合規性中，為「控制項」。 policyDefinitions 中的 groupNames 會使用此屬性的值。
category (字串)：群組所屬的階層。在法規合規性中，為控制項的「合規性領域」。
displayName (字串)：「群組」或「控制項」的易記名稱。入口網站所使用。
description (字串)：「群組」或「控制項」所涵蓋內容的描述。
additionalMetadataId (字串)：policyMetadata 物件的位置，而此物件具有「控制項」和「合規性網域」的其他詳細資料。

注意

客戶可能會指向現有的 policyMetadata 物件。不過，這些物件為「唯讀」，而且只能由 Microsoft 建立。

NIST 內建計畫定義的 policyDefinitionGroups 屬性範例如下所示：

"policyDefinitionGroups": [
    {
        "name": "NIST_SP_800-53_R4_AC-1",
        "additionalMetadataId": "/providers/Microsoft.PolicyInsights/policyMetadata/NIST_SP_800-53_R4_AC-1"
    }
]

中繼資料物件

Microsoft 所建立的法規合規性內建具有每個控制項的其他資訊。此資訊為：

顯示在 Azure 入口網站法規合規性計畫上「控制項」的概觀上。
可透過 REST API 取得。請參閱 Microsoft.PolicyInsights 資源提供者和 policyMetadata 作業群組。
可透過 Azure CLI 取得。請參閱 az policy metadata 命令。

重要

法規合規性的中繼資料物件為「唯讀」，因此客戶無法建立。

原則群組的中繼資料在 properties 節點中具有下列資訊：

metadataId：群組所關聯的「控制項識別碼」。
category (必要)：「控制項」所屬的「合規性領域」。
title (必要)：「控制項識別碼」的易記名稱。
owner (必要)：識別誰負責 Azure 中的控制項：「客戶」、Microsoft、「共用」。
description：控制項的其他資訊。
requirements：控制項實作責任的詳細資料。
additionalContentUrl：控制項詳細資訊的連結。此屬性通常是文件章節的連結，而章節涵蓋合規性標準中的這個控制項。

以下是 policyMetadata 物件範例。此範例中繼資料屬於 NIST SP 800-53 R4 AC-1 控制項。

{
  "properties": {
    "metadataId": "NIST SP 800-53 R4 AC-1",
    "category": "Access Control",
    "title": "Access Control Policy and Procedures",
    "owner": "Shared",
    "description": "**The organization:**    \na. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:  \n1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and  \n2. Procedures to facilitate the implementation of the access control policy and associated access controls; and  \n
\nb. Reviews and updates the current:  \n1. Access control policy [Assignment: organization-defined frequency]; and  \n2. Access control procedures [Assignment: organization-defined frequency].",
    "requirements": "**a.**  The customer is responsible for developing, documenting, and disseminating access control policies and procedures. The customer access control policies and procedures address access to all customer-deployed resources and customer system access (e.g., access to customer-deployed virtual machines, access to customer-built applications).  \n**b.**  The customer is responsible for reviewing and updating access control policies and procedures in accordance with FedRAMP requirements.",
    "additionalContentUrl": "https://nvd.nist.gov/800-53/Rev4/control/AC-1"
  },
  "id": "/providers/Microsoft.PolicyInsights/policyMetadata/NIST_SP_800-53_R4_AC-1",
  "name": "NIST_SP_800-53_R4_AC-1",
  "type": "Microsoft.PolicyInsights/policyMetadata"
}

下一步

請參閱定義結構
在 Azure 原則範例檢閱範例。
檢閱了解原則效果。
了解如何以程式設計方式建立原則。
了解如何取得合規性資料。
了解如何補救不符合規範的資源。
透過使用 Azure 管理群組來組織資源來檢閱何謂管理群組。

共用方式為