Azure Policy の効果について

[アーティクル]
03/09/2023

Azure Policy 内の各ポリシー定義には単一の効果があります。その効果によって、ポリシー規則が一致すると評価されたときの動作が決まります。効果の動作は、対象 (新しいリソース、更新されたリソース、または既存のリソース) によって異なります。

現在、ポリシー定義では次の効果がサポートされています。

Append
監査
AuditIfNotExists
Deny
DenyAction (プレビュー)
DeployIfNotExists
Disabled
Manual (プレビュー)
Modify

効果の入れ替え

1 つのポリシー定義に対して、複数の効果を有効にすることができる場合があります。パラメーターは、1 つの定義の汎用性を高めるために、許可される効果の値を指定するためによく使用されます。しかし、すべての効果が交換可能ではないことに注意することが重要です。特定の効果がポリシー定義に対して有効であると見なされるかどうかは、ポリシールールのリソースプロパティとロジックによって決まります。たとえば、AuditIfNotExists 効果を持つポリシー定義のポリシールールには、Audit 効果を持つポリシーには必要でない、追加の詳細が必要です。また、効果の動作も異なります。 Audit ポリシーでは独自のプロパティに基づいてリソースのコンプライアンスが評価され、AuditIfNotExists ポリシーでは子リソースまたは拡張リソースのプロパティに基づいてリソースのコンプライアンスが評価されます。

交換可能な効果に関する一般的なガイダンスを次に示します。

Audit、Deny、および Modify または Append は、多くの場合交換可能です。
AuditIfNotExists と DeployIfNotExists は、多くの場合交換可能です。
Manual は交換できません。
Disabled はどの効果とも交換可能です。

評価の順序

リソースの作成または更新の要求は、まず Azure Policy によって評価されます。 Azure Policy では、リソースに適用されるすべての割り当ての一覧が作成された後、各定義に対してリソースが評価されます。リソースマネージャーモードの場合、Azure Policy では、適切なリソースプロバイダーに要求が渡される前に、さまざまな効果が処理されます。この順序で処理することで、リソースが意図された Azure Policy のガバナンスコントロールを満たさない場合に、リソースプロバイダーによって不要な処理が行われるのを防止します。リソースプロバイダーモードを使用すると、リソースプロバイダーは評価と結果を管理し、その結果を Azure Policy に報告します。

Disabled は、ポリシー規則を評価する必要があるかどうかを判断するために、最初に確認されます。
Append と Modify は、その後で評価されます。これらいずれかによって要求が変更される可能性があるため、その変更によって、Audit または Deny の効果がトリガーされるのが止められる場合があります。これらの効果は、リソースマネージャーモードでのみ使用できます。
次に、Deny が評価されます。 Audit の前に Deny を評価することによって、不要なリソースの二重のログ記録が回避されます。
監査が評価されます。
Manual が評価されます。
AuditIfNotExists が評価されます。
denyAction が最後に評価されます。

リソースマネージャーモードの要求では、リソースプロバイダーによって成功コードが返された後、AuditIfNotExists と DeployIfNotExists が評価され、追加のコンプライアンスのログ記録またはアクションが必要かどうかが判断されます。

さらに、tags の関連フィールドだけを変更する PATCH 要求では、ポリシーの評価が、tags の関連フィールドを検査する条件を含むポリシーに限定されます。

Append

Append は、作成中または更新中に要求されたリソースにフィールドを追加するために使用します。一般的な例としては、ストレージリソースに対して許可される IP の指定が挙げられます。

重要

Append は、タグ以外のプロパティで使用することを目的としています。 Append では、作成要求または更新要求時にリソースにタグを追加することができますが、タグに対しては Modify 効果を使用することをお勧めします。

Append の評価

リソースを作成中または更新中に、リソースプロバイダーによって要求が処理される前に Append による評価が行われます。 Append では、ポリシー規則の if 条件が満たされた場合、リソースにフィールドが追加されます。 Append 効果によって元の要求の値が別の値でオーバーライドされる場合、Append は Deny 効果として機能し、要求は拒否されます。新しい値を既存の配列に追加するには、[*] バージョンの別名を使用します。

Append 効果を使用するポリシー定義が評価サイクルの一部として実行される場合、既存のリソースに対する変更は行われません。代わりに、if 条件を満たすリソースが非準拠とマークされます。

Append のプロパティ

Append 効果には必須の details 配列が 1 つだけあります。 details は配列なので、1 つまたは複数の field/value のペアをとることができます。許容可能なフィールドの一覧については、定義の構造を参照してください。

Append の例

例 1: 非 [*]別名と配列 value を使用して、ストレージアカウントに対して IP 規則を設定する単一の field/value のペア。非 [*] 別名が配列の場合、この効果により、value が配列全体として追加されます。配列が既に存在する場合は、競合から拒否イベントが発生します。

"then": {
    "effect": "append",
    "details": [{
        "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules",
        "value": [{
            "action": "Allow",
            "value": "134.5.0.0/21"
        }]
    }]
}

例 2: 配列 value の [*]別名を使用して、ストレージアカウントに対して IP 規則を設定する単一の field/value のペア。 [*] 別名を使用することで、この効果により、事前に存在している可能性のある配列に value が追加されます。配列がまだ存在しない場合は、配列が作成されます。

"then": {
    "effect": "append",
    "details": [{
        "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]",
        "value": {
            "value": "40.40.40.40",
            "action": "Allow"
        }
    }]
}

Audit

非準拠のリソースが評価された場合、Audit を使用してアクティビティログに警告イベントが作成されますが、要求は停止されません。

Audit の評価

Audit は、リソースの作成中または更新中に Azure Policy によって確認される最後の効果です。リソースマネージャーモードの場合、その後でリソースが Azure Policy によってリソースプロバイダーに送信されます。リソースの作成または更新の要求を評価するときに、Azure Policy では Microsoft.Authorization/policies/audit/action 操作がアクティビティログに追加され、リソースが非対応としてマークされます。標準のコンプライアンス評価サイクルでは、リソースのコンプライアンス状態のみが更新されます。

Audit のプロパティ

リソースマネージャーモードの場合、Audit 効果には、ポリシー定義の then 条件で使用するためのその他のプロパティはありません。

Microsoft.Kubernetes.Data のリソースプロバイダーモードの場合、Audit 効果の details には次のサブプロパティが追加されます。新しいポリシー定義や更新されたポリシー定義では、templateInfo を使用する必要があります。constraintTemplate は非推奨となっています。

templateInfo (必須)
- constraintTemplate とは使用できません。
- sourceType (必須)
  - 制約テンプレートのソースの種類を定義します。指定できる値は PublicURL または Base64Encoded です。
  - PublicURL を指定する場合は、url プロパティと組み合わせて制約テンプレートの場所を指定します。この場所はパブリックにアクセスできる必要があります。
    
    警告
    
    SAS URI、URL トークン、またはシークレットを公開する可能性のあるその他のものをプレーンテキストで使用しないでください。
  - Base64Encoded を指定する場合は、content プロパティと組み合わせて Base 64 でエンコードされた制約テンプレートを指定します。既存の Open Policy Agent (OPA) Gatekeeper v3 制約テンプレートからカスタム定義を作成するには、「制約テンプレートからポリシー定義を作成する」を参照してください。
constraint (非推奨)
- templateInfo とは使用できません。
- 制約テンプレートの CRD 実装です。 {{ .Values.<valuename> }} のように values で渡されるパラメーターを使用します。次の例 2 では、これらの値は {{ .Values.excludedNamespaces }} および {{ .Values.allowedContainerImagesRegex }} です。
namespaces (省略可能)
- ポリシーの評価対象とする Kubernetes 名前空間の配列。
- 空にした場合、つまり値を指定しなかった場合、excludedNamespaces に定義されていないすべての名前空間がポリシーの評価対象になります。
excludedNamespaces (必須)
- ポリシーの評価から除外する Kubernetes 名前空間の配列。
labelSelector (必須)
- matchLabels (オブジェクト) プロパティと matchExpression (配列) プロパティを含んだ "オブジェクト"。ポリシーの評価対象とする Kubernetes リソースを指定できます。ラベルおよびセレクターの指定と一致した Kubernetes リソースが評価対象となります。
- 空にした場合、つまり値を指定しなかった場合、excludedNamespaces に定義された名前空間を除くすべてのラベルおよびセレクターがポリシーの評価対象になります。
apiGroups (templateInfo を使用する場合は必須)
- マッチさせる API グループを含んだ配列。空の配列 ([""]) は、コア API グループです。
- apiGroups 向けの ["*"] の定義は許可されません。
kinds (templateInfo を使用する場合は必須)
- 評価対象とする Kubernetes オブジェクトの kind を含んだ配列。
- kinds 向けの ["*"] の定義は許可されません。
values (省略可能)
- 制約に渡すすべてのパラメーターと値を定義します。それぞれの値は、制約テンプレート CRD に含まれている必要があります。
constraintTemplate (非推奨)
- templateInfo とは使用できません。
- ポリシーの定義を作成または更新するときは、templateInfo に置き換えてください。
- 新しい制約を定義する、制約テンプレート CustomResourceDefinition (CRD) です。このテンプレートは、Rego ロジック、制約スキーマに加えて、Azure Policy からの values で渡される制約パラメーターを定義します。

Audit の例

例 1:リソースマネージャーモードで Audit 効果を使用する。

"then": {
    "effect": "audit"
}

例 2:Microsoft.Kubernetes.Data のリソースプロバイダーモードで Audit 効果を使用する。 details.templateInfo の追加情報では、許可されるコンテナーイメージを制限するために、PublicURL の使用を宣言し、Kubernetes で使用する制約テンプレートの場所を url に設定します。

"then": {
    "effect": "audit",
    "details": {
        "templateInfo": {
            "sourceType": "PublicURL",
            "url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
        },
        "values": {
            "imageRegex": "[parameters('allowedContainerImagesRegex')]"
        },
        "apiGroups": [""],
        "kinds": ["Pod"]
    }
}

AuditIfNotExists

AuditIfNotExists は、if 条件に一致するリソースに関連するリソースで監査を有効にしますが、then 条件の details で指定されるプロパティはありません。

AuditIfNotExists の評価

AuditIfNotExists は、リソースプロバイダーでリソースの作成または更新要求が処理され、成功を示す状態コードが返された後で実行されます。関連するリソースがない場合、または ExistenceCondition によって定義されたリソースが true と評価されない場合、監査が発生します。新規および更新されたリソースの場合、Azure Policy によってアクティビティログに Microsoft.Authorization/policies/audit/action 操作が追加され、リソースは非準拠とマークされます。トリガーされた場合、if 条件を満たしているリソースは、非準拠としてマークされているリソースです。

AuditIfNotExists のプロパティ

AuditIfNotExists 効果の details プロパティは、照合する関連リソースを定義するすべてのサブプロパティを含みます。

Type (必須)
- 照合する関連リソースの型を指定します。
- type が if 条件リソース下にあるリソースの種類である場合、この type のリソースが、ポリシーによって評価対象リソースのスコープ内から照会されます。それ以外の場合、ポリシーは、existenceScope に応じて、評価されたリソースと同じリソースグループまたはサブスクリプション内でクエリを実行します。
Name (省略可能)
- 照合するリソースの正確な名前を指定して、指定した型のすべてのリソースではなく 1 つの特定のリソースを取得します。
- if.field.type と then.details.type の条件値が一致する場合、Name は "必須" になり、子リソースに対し [field('name')] または [field('fullName')] であることが必要です。ただし、代わりに audit の影響を考慮する必要があります。
ResourceGroupName (省略可能)
- 別のリソースグループに由来する関連リソースを照合できるようにします。
- type が if 条件リソースの下にあるリソースである場合は適用されません。
- 既定値は、if 条件リソースのリソースグループです。
ExistenceScope (省略可能)
- 使用できる値は Subscription と ResourceGroup です。
- 照合する関連リソースを取得する範囲を設定します。
- type が if 条件リソースの下にあるリソースである場合は適用されません。
- ResourceGroup については、ResourceGroupName 内のリソースグループに制限されます (指定されている場合)。 ResourceGroupName が指定されていない場合は、if 条件リソースのリソースグループに制限されます。これは既定の動作です。
- Subscription の場合は、関連リソースのサブスクリプション全体を検索します。適切に評価するためには、割り当てスコープがサブスクリプション以上で設定されている必要があります。
- 既定値は ResourceGroup です。
EvaluationDelay (省略可能)
- 関連リソースの存在を評価する必要があるタイミングを指定します。遅延は、リソースの作成または更新要求の結果である評価のみに使用されます。
- 使用できる値は AfterProvisioning、AfterProvisioningSuccess、AfterProvisioningFailure、または ISO 8601 期間の 0 から 360 分の間です。
- AfterProvisioning 値では、ポリシー規則の IF 条件で評価されたリソースのプロビジョニング結果が検査されます。結果に関係なく、プロビジョニングが完了した後に AfterProvisioning が実行されます。プロビジョニングに 6 時間より長くかかると、Afterprovisioning の評価の遅延を判断するときにエラーとして扱われます。
- 既定値は PT10M (10 分間) です。
- 評価の遅延を長く指定すると、リソースの記録されたコンプライアンス状態が次の評価のトリガーまで更新されない場合があります。
ExistenceCondition (省略可能)
- 指定されない場合、type の関連リソースは効果を満たしているため、監査はトリガーされません。
- if 条件のポリシー規則と同じ言語が使用されますが、それぞれの関連リソースに対して個別に評価されます。
- 照合する関連リソースのいずれかが true と評価された場合、効果は条件を満たしているため、監査はトリガーされません。
- [field()] を使用して、if 条件の値と等しいことを確認できます。
- たとえば、(if 条件内の) 親リソースが照合する関連リソースと同じリソースの場所にあることを検証できます。

AuditIfNotExists の例

例: 仮想マシンを評価してマルウェア対策の拡張機能が存在するかどうかを判定し、ない場合に監査します。

{
    "if": {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
    },
    "then": {
        "effect": "auditIfNotExists",
        "details": {
            "type": "Microsoft.Compute/virtualMachines/extensions",
            "existenceCondition": {
                "allOf": [{
                        "field": "Microsoft.Compute/virtualMachines/extensions/publisher",
                        "equals": "Microsoft.Azure.Security"
                    },
                    {
                        "field": "Microsoft.Compute/virtualMachines/extensions/type",
                        "equals": "IaaSAntimalware"
                    }
                ]
            }
        }
    }
}

拒否

Deny は、ポリシーを通して定義された基準に一致していないために失敗するリソース要求を防ぐために使用されます。

Deny の評価

リソースマネージャーモードで照合されたリソースを作成または更新する場合、Deny は、リソースプロバイダーに要求が送信されないようにします。要求は 403 (Forbidden) として返されます。ポータルでは、ポリシーの割り当てによって阻止されたデプロイの状態として、この Forbidden を表示できます。リソースプロバイダーモードでは、リソースプロバイダーによってリソースの評価が管理されます。

既存のリソースの評価では、Deny ポリシー定義と一致するリソースは、非準拠としてマークされます。

Deny のプロパティ

リソースマネージャーモードの場合、Deny 効果には、ポリシー定義の then 条件で使用するためのその他のプロパティはありません。

Microsoft.Kubernetes.Data のリソースプロバイダーモードの場合、Deny 効果の details には次のサブプロパティが追加されます。新しいポリシー定義や更新されたポリシー定義では、templateInfo を使用する必要があります。constraintTemplate は非推奨となっています。

templateInfo (必須)
- constraintTemplate とは使用できません。
- sourceType (必須)
  - 制約テンプレートのソースの種類を定義します。指定できる値は PublicURL または Base64Encoded です。
  - PublicURL を指定する場合は、url プロパティと組み合わせて制約テンプレートの場所を指定します。この場所はパブリックにアクセスできる必要があります。
    
    警告
    
    url には、SAS URI やトークンなど、シークレットが公開されてしまう可能性がある情報は一切使用しないでください。
  - Base64Encoded を指定する場合は、content プロパティと組み合わせて Base 64 でエンコードされた制約テンプレートを指定します。既存の Open Policy Agent (OPA) Gatekeeper v3 制約テンプレートからカスタム定義を作成するには、「制約テンプレートからポリシー定義を作成する」を参照してください。
constraint (省略可能)
- templateInfo とは使用できません。
- 制約テンプレートの CRD 実装です。 {{ .Values.<valuename> }} のように values で渡されるパラメーターを使用します。次の例 2 では、これらの値は {{ .Values.excludedNamespaces }} および {{ .Values.allowedContainerImagesRegex }} です。
namespaces (省略可能)
- ポリシーの評価対象とする Kubernetes 名前空間の配列。
- 空にした場合、つまり値を指定しなかった場合、excludedNamespaces に定義された名前空間を除くすべての名前空間がポリシーの評価対象になります。
excludedNamespaces (必須)
- ポリシーの評価から除外する Kubernetes 名前空間の配列。
labelSelector (必須)
- matchLabels (オブジェクト) プロパティと matchExpression (配列) プロパティを含んだ "オブジェクト"。ポリシーの評価対象とする Kubernetes リソースを指定できます。ラベルおよびセレクターの指定と一致した Kubernetes リソースが評価対象となります。
- 空にした場合、つまり値を指定しなかった場合、excludedNamespaces に定義された名前空間を除くすべてのラベルおよびセレクターがポリシーの評価対象になります。
apiGroups (templateInfo を使用する場合は必須)
- マッチさせる API グループを含んだ配列。空の配列 ([""]) は、コア API グループです。
- apiGroups 向けの ["*"] の定義は許可されません。
kinds (templateInfo を使用する場合は必須)
- 評価対象とする Kubernetes オブジェクトの kind を含んだ配列。
- kinds 向けの ["*"] の定義は許可されません。
values (省略可能)
- 制約に渡すすべてのパラメーターと値を定義します。それぞれの値は、制約テンプレート CRD に含まれている必要があります。
constraintTemplate (非推奨)
- templateInfo とは使用できません。
- ポリシーの定義を作成または更新するときは、templateInfo に置き換えてください。
- 新しい制約を定義する、制約テンプレート CustomResourceDefinition (CRD) です。このテンプレートは、Rego ロジック、制約スキーマに加えて、Azure Policy からの values で渡される制約パラメーターを定義します。 constraintTemplate は、より新しい templateInfo に置き換えることをお勧めします。

Deny の例

例 1:リソースマネージャーモードで Deny 効果を使用する。

"then": {
    "effect": "deny"
}

例 2:Microsoft.Kubernetes.Data のリソースプロバイダーモードで Deny 効果を使用する。 details.templateInfo の追加情報では、許可されるコンテナーイメージを制限するために、PublicURL の使用を宣言し、Kubernetes で使用する制約テンプレートの場所を url に設定します。

"then": {
    "effect": "deny",
    "details": {
        "templateInfo": {
            "sourceType": "PublicURL",
            "url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
        },
        "values": {
            "imageRegex": "[parameters('allowedContainerImagesRegex')]"
        },
        "apiGroups": [""],
        "kinds": ["Pod"]
    }
}

DenyAction (プレビュー)

DenyAction は、リソースに対する意図したアクションの要求をブロックするために使われます。現在、サポートされているアクションは DELETE のみです。この効果により、重要なリソースが誤って削除されるのを防ぐことができます。

DenyAction の評価

該当するアクション名と対象スコープを持つ要求の呼び出しを送信すると、denyAction により、要求は成功しなくなります。要求は 403 (Forbidden) として返されます。ポータルでは、ポリシーの割り当てによって阻止されたデプロイの状態として、この Forbidden を表示できます。

ロックアウトシナリオを防ぐために、Microsoft.Authorization/policyAssignments、Microsoft.Authorization/denyAssignments、Microsoft.Blueprint/blueprintAssignments、Microsoft.Resources/deploymentStacks、Microsoft.Authorization/locks はいずれも DenyAction の適用から除外されています。

Note

プレビュー中は、denyAction 効果の割り当ては Not Started というコンプライアンス状態で表示されます。

サブスクリプションの削除

サブスクリプションの削除中に発生するリソースの削除は、ポリシーによってブロックされません。

リソースグループの削除

ポリシーにより、リソースグループの削除中に DenyAction ポリシーに対して場所とタグをサポートするリソースが評価されます。リソースグループの削除をブロックするのは、ポリシー規則で cascadeBehaviors が deny に設定されているポリシーのみです。場所とタグ、または mode:all が設定されたポリシーをサポートしていないリソースの削除は、ポリシーによってブロックされません。

カスケード削除

カスケード削除が発生するのは、親リソースを削除したときに、そのすべての子リソースも暗黙的に削除される場合です。削除アクションが親リソースを対象としている場合、子リソースの削除はポリシーによってブロックされません。たとえば、Microsoft.Insights/diagnosticSettings は Microsoft.Storage/storageaccounts の子リソースです。 denyAction ポリシーが Microsoft.Insights/diagnosticSettings を対象としている場合、診断設定 (子) に対する削除の呼び出しは失敗しますが、ストレージアカウント (親) の削除によって、診断設定 (子) を暗黙的に削除されます。

この表は、割り当てられた denyAction ポリシーに適用されるリソースと、DELETE 呼び出しのターゲットスコープを考慮して、リソースが削除から保護されるかどうかを説明するものです。この表のコンテキストでは、インデックス付きリソースはタグと場所をサポートするものであり、非インデックス付きリソースはタグと場所をサポートしないものです。インデックス付きと非インデックス付きのリソースの詳細については、定義モードに関する記事を参照してください。子リソースとは、別のリソースのコンテキスト内でのみ存在するリソースのことです。たとえば、仮想マシン拡張機能リソースは、親リソースである仮想マシンの子です。

削除されるエンティティ	ポリシー条件に適用されるエンティティ	実行した操作
リソース	リソース	Protected
サブスクリプション	リソース	Deleted
Resource group	インデックス付きリソース	依存先 `cascadeBehaviors`
Resource group	非インデックス付きリソース	Deleted
子リソース	親リソース	親が保護される、子が削除される
親リソース	子リソース	Deleted

DenyAction のプロパティ

DenyAction 効果の details プロパティには、アクションと動作を定義するすべてのサブプロパティがあります。

actionNames (必須)
- 実行を阻止するアクションを指定する "配列"。
- サポートされているアクション名は delete です。
cascadeBehaviors (省略可能)
- リソースグループの削除によってリソースが暗黙的に削除されるときに実行される動作を定義する "オブジェクト"。
- mode が indexed に設定されているポリシー定義でのみサポートされます。
- 使用できる値は allow または deny です。
- 既定値は deny です。

DenyAction の例

例: 運用環境と等しいタグ環境のデータベースアカウントを対象とした削除の呼び出しをすべて拒否します。カスケード動作は拒否に設定されているため、該当するデータベースアカウントを持つリソースグループを対象とするすべての DELETE 呼び出しをブロックします。

{
   "if": {
      "allOf": [
         {
            "field": "type",
            "equals": "Microsoft.DocumentDb/accounts"
         },
         {
            "field": "tags.environment",
            "equals": "prod"
         }
      ]
   },
   "then": {
      "effect": "DenyAction",
      "details": {
         "actionNames": [ "delete" ],
         "cascadeBehaviors": { "resourceGroup": "deny" }
      }
   }
}

DeployIfNotExists

AuditIfNotExists と同様に、DeployIfNotExists ポリシー定義は条件が満たされたときにテンプレートのデプロイを実行します。 DeployIfNotExists として設定された有効なポリシー割り当てには、修復を行うためのマネージド ID が必要です。

注意

deployIfNotExists で入れ子になったテンプレートがサポートされていますが、リンク済みテンプレートは現在サポートされていません。

DeployIfNotExists の評価

DeployIfNotExists は、リソースプロバイダーによって、サブスクリプションまたはリソースの作成または更新要求が処理され、成功を示す状態コードが返されてから、構成可能な遅延後に実行されます。関連するリソースがない場合、または ExistenceCondition によって定義されたリソースが true と評価されない場合、テンプレートのデプロイが発生します。デプロイの時間は、テンプレートに含まれるリソースの複雑さによって異なります。

評価サイクル中は、リソースを照合する DeployIfNotExists 効果があるポリシー定義は非準拠としてマークされ、リソースに対するアクションは実行されません。準拠していない既存のリソースは、修復タスクで修復できます。

DeployIfNotExists のプロパティ

DeployIfNotExists 効果の details プロパティは、照合する関連リソースおよび実行するテンプレートのデプロイを定義するすべてのサブプロパティを含みます。

Type (必須)
- 照合する関連リソースの型を指定します。
- type が if 条件リソース下にあるリソースの種類である場合、この type のリソースが、ポリシーによって評価対象リソースのスコープ内から照会されます。それ以外の場合、ポリシーは、existenceScope に応じて、評価されたリソースと同じリソースグループまたはサブスクリプション内でクエリを実行します。
Name (省略可能)
- 照合するリソースの正確な名前を指定して、指定した型のすべてのリソースではなく 1 つの特定のリソースを取得します。
- if.field.type と then.details.type の条件値が一致する場合、Name は "必須" になり、子リソースに対し [field('name')] または [field('fullName')] であることが必要です。
ResourceGroupName (省略可能)
- 別のリソースグループに由来する関連リソースを照合できるようにします。
- type が if 条件リソースの下にあるリソースである場合は適用されません。
- 既定値は、if 条件リソースのリソースグループです。
- テンプレートのデプロイが実行される場合は、この値のリソースグループにデプロイされます。
ExistenceScope (省略可能)
- 使用できる値は Subscription と ResourceGroup です。
- 照合する関連リソースを取得する範囲を設定します。
- type が if 条件リソースの下にあるリソースである場合は適用されません。
- ResourceGroup については、ResourceGroupName 内のリソースグループに制限されます (指定されている場合)。 ResourceGroupName が指定されていない場合は、if 条件リソースのリソースグループに制限されます。これは既定の動作です。
- Subscription の場合は、関連リソースのサブスクリプション全体を検索します。適切に評価するためには、割り当てスコープがサブスクリプション以上で設定されている必要があります。
- 既定値は ResourceGroup です。
EvaluationDelay (省略可能)
- 関連リソースの存在を評価する必要があるタイミングを指定します。遅延は、リソースの作成または更新要求の結果である評価のみに使用されます。
- 使用できる値は AfterProvisioning、AfterProvisioningSuccess、AfterProvisioningFailure、または ISO 8601 期間の 0 から 360 分の間です。
- AfterProvisioning 値では、ポリシー規則の IF 条件で評価されたリソースのプロビジョニング結果が検査されます。結果に関係なく、プロビジョニングが完了した後に AfterProvisioning が実行されます。プロビジョニングに 6 時間より長くかかると、Afterprovisioning の評価の遅延を判断するときにエラーとして扱われます。
- 既定値は PT10M (10 分間) です。
- 評価の遅延を長く指定すると、リソースの記録されたコンプライアンス状態が次の評価のトリガーまで更新されない場合があります。
ExistenceCondition (省略可能)
- 指定されない場合、type の関連リソースは効果を満たすため、デプロイはトリガーされません。
- if 条件のポリシー規則と同じ言語が使用されますが、それぞれの関連リソースに対して個別に評価されます。
- 照合する関連リソースのいずれかが true と評価された場合、効果は条件を満たしているため、デプロイはトリガーされません。
- [field()] を使用して、if 条件の値と等しいことを確認できます。
- たとえば、(if 条件内の) 親リソースが照合する関連リソースと同じリソースの場所にあることを検証できます。
roleDefinitionIds (必須)
- このプロパティには、サブスクリプションでアクセス可能なロールベースのアクセス制御ロール ID と一致する文字列の配列を含める必要があります。詳細については、修復 - ポリシー定義の構成に関するページを参照してください。
DeploymentScope (省略可能)
- 使用できる値は Subscription と ResourceGroup です。
- トリガーされるデプロイの種類を設定します。 Subscription はサブスクリプションレベルでのデプロイを示し、ResourceGroup はリソースグループへのデプロイを示します。
- サブスクリプションレベルのデプロイを使用する場合は、Deployment で location プロパティを指定する必要があります。
- 既定値は ResourceGroup です。
Deployment (必須)
- このプロパティは Microsoft.Resources/deployments PUT API に渡されるため、完全なテンプレートのデプロイを含める必要があります。詳細については、Deployments REST API をご覧ください。
- テンプレート内で入れ子になっている Microsoft.Resources/deployments では、複数のポリシー評価間の競合を避けるために、固有の名前を使用する必要があります。 [concat('NestedDeploymentName-', uniqueString(deployment().name))] を使用すると、入れ子になったデプロイの一部として親デプロイの名前を使用できます。
注意

Deployment プロパティ内のすべての関数が、ポリシーではなくテンプレートのコンポーネントとして評価されます。例外は、ポリシーからテンプレートに値を渡す parameters プロパティです。このセクションのテンプレートパラメーター名の value は、この値渡しを実行するために使用されます (DeployIfNotExists の例の fullDbName を参照)。

DeployIfNotExists の例

例: SQL Server データベースを評価して、transparentDataEncryption が有効になっているかどうかを判定します。有効になっていない場合は、有効にするためのデプロイが実行されます。

"if": {
    "field": "type",
    "equals": "Microsoft.Sql/servers/databases"
},
"then": {
    "effect": "DeployIfNotExists",
    "details": {
        "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
        "name": "current",
        "evaluationDelay": "AfterProvisioning",
        "roleDefinitionIds": [
            "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleGUID}",
            "/providers/Microsoft.Authorization/roleDefinitions/{builtinroleGUID}"
        ],
        "existenceCondition": {
            "field": "Microsoft.Sql/transparentDataEncryption.status",
            "equals": "Enabled"
        },
        "deployment": {
            "properties": {
                "mode": "incremental",
                "template": {
                    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
                    "contentVersion": "1.0.0.0",
                    "parameters": {
                        "fullDbName": {
                            "type": "string"
                        }
                    },
                    "resources": [{
                        "name": "[concat(parameters('fullDbName'), '/current')]",
                        "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
                        "apiVersion": "2014-04-01",
                        "properties": {
                            "status": "Enabled"
                        }
                    }]
                },
                "parameters": {
                    "fullDbName": {
                        "value": "[field('fullName')]"
                    }
                }
            }
        }
    }
}

無効

この効果は、状況をテストする場合や、効果がポリシー定義によってパラメーター化されている場合に役立ちます。この柔軟性により、ポリシーのすべての割り当てを無効にするのではなく、単一の割り当てを無効にすることができます。

Note

Disabled 効果を使用するポリシー定義では、割り当て後の既定のコンプライアンスの状態は [準拠している] です。

Disabled 効果の代替は、enforcementMode です。これは、ポリシー割り当てに設定されます。 enforcementMode が Disabled_** のときは、リソースが引き続き評価されます。アクティビティログなどのログ記録や、ポリシーの効果はありません。詳細については、ポリシー割り当て - 強制モードに関するページを参照してください。

Manual (プレビュー)

新しい manual (プレビュー) 効果を使用すると、リソースまたはスコープのコンプライアンスを自己証明できます。評価をアクティブにスキャンする他のポリシー定義とは異なり、Manual 効果を使用すると手動の変更をコンプライアンス状態にできます。 manual ポリシーの対象になるリソースまたはスコープのコンプライアンスを変更するには、構成証明を作成する必要があります。ベストプラクティスは、コンプライアンスの構成証明が必要なリソースの境界を定義するスコープを対象とする manual ポリシーを設計することです。

Note

パブリックプレビュー期間中は、さまざまな Microsoft Defender for Cloud 規制コンプライアンスイニシアチブを通じて、手動ポリシーのサポートを利用できます。 Microsoft Defender for Cloud Premium レベルのお客様は、エクスペリエンスの概要を参照してください。

現在、次の規制ポリシーイニシアチブには、手動効果を含むポリシー定義が含まれています。

FedRAMP High
FedRAMP Medium
HIPAA
HITRUST
ISO 27001
Microsoft CIS 1.3.0
Microsoft CIS 1.4.0
NIST SP 800-171 Rev. 2
NIST SP 800-53 Rev. 4
NIST SP 800-53 Rev. 5
PCI DSS 3.2.1
PCI DSS 4.0
SOC TSP
SWIFT CSP CSCF v2022

次の例では、Azure サブスクリプションを対象とし、初期コンプライアンス状態を Unknown に設定します。

{
  "if": {
    "field":  "type",
    "equals": "Microsoft.Resources/subscriptions"
  },
  "then": {
    "effect": "manual",
    "details": {
      "defaultState": "Unknown"
    }
  }
}

defaultState プロパティには、次の 3 つの値を指定できます。

不明: ターゲットリソースの初期の既定の状態。
準拠: リソースは、手動ポリシー標準に準拠しています
非準拠: リソースは手動ポリシー標準に準拠していません

Azure Policy コンプライアンスエンジンは、該当するすべてのリソースを、定義で指定された既定の状態に評価します (指定されていない場合は Unknown)。 Unknown のコンプライアンス状態は、リソースのコンプライアンス状態を手動で証明する必要があることを示します。効果の状態が指定されていない場合、既定で Unknown になります。 Unknown のコンプライアンスの状態は、コンプライアンスの状態を自分で証明する必要があることを示します。

次のスクリーンショットは、Unknown の状態を持つ手動ポリシー割り当てが Azure portal でどのように表示されるかを示しています。

コンプライアンス理由が

manual 効果を持つポリシー定義が割り当てられている場合は、カスタムの構成証明を使用して、対象となるリソースまたはスコープのコンプライアンス状態を設定できます。構成証明では、メタデータの形式と、選択したコンプライアンス状態に付随する証拠へのリンクを通じて、オプションの補足情報を提供することもできます。手動ポリシーを割り当てるユーザーは、ポリシー割り当てのメタデータの evidenceStorages プロパティを指定することで、証拠の既定の保存場所を推奨できます。

変更

Modify は、作成時または更新時に、サブスクリプションまたはリソースのプロパティまたはタグを追加、更新、または削除するために使用されます。一般的な例としては、コストセンターなどのリソースでタグを更新することが挙げられます。準拠していない既存のリソースは、修復タスクで修復できます。 1 つの Modify 規則には、任意の数の操作を含めることができます。 Modify として設定された有効なポリシー割り当てには、修復を行うためのマネージド ID が必要です。

Modify では次の操作がサポートされています。

リソースタグの追加、置換、または削除。タグに関して、ターゲットリソースがリソースグループでない限り、Modify ポリシーでは常に mode が indexed に設定されている必要があります。
仮想マシンと Virtual Machine Scale Sets のマネージド ID の種類 (identity.type) の値の追加または置換。
特定のエイリアスの値の追加または置換。
- 用途 Azure PowerShell 4.6.0 以降で Get-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' } を使用して、Modify で使用できるエイリアスの一覧を取得します。

重要

タグを管理している場合は、Append ではなく Modify を使用することをお勧めします。Modify では追加の操作タイプが使用でき、既存のリソースを修復する機能が提供されるためです。ただし、マネージド ID を作成できない場合や、リソースプロパティのエイリアスが Modify でまだサポートされていない場合は、Append を使用することをお勧めします。

Modify の評価

リソースを作成中または更新中に、リソースプロバイダーによって要求が処理される前に Modify による評価が行われます。ポリシールールの if 条件が満たされた場合、要求コンテンツに Modify 操作が適用されます。各 Modify 操作では、適用されるタイミングを決定する条件を指定できます。 false 条件の評価を含む操作はスキップされます。

エイリアスを指定すると次の追加のチェックが実行され、要求コンテンツが Modify 操作によって、リソースプロバイダーに拒否されるような形に変更されることがないようにします。

エイリアスのマップ先のプロパティは、要求の API バージョンでは 'Modifiable' としてマークされています。
Modify 操作のトークンの種類は、要求の API バージョンのプロパティで想定されるトークンの種類と一致します。

これらのチェックのいずれかが失敗した場合、ポリシー評価は指定された conflictEffect にフォールバックします。

重要

エイリアスを含む Modify の定義では、auditの競合効果を利用して、マッピングされたプロパティが "Modifiable" でない API バージョンを使用して失敗する要求を回避することをお勧めします。 API バージョン間で同じエイリアスの動作が異なる場合は、条件付き変更操作を使用し

Modify 効果を使用するポリシー定義が評価サイクルの一部として実行される場合、既存のリソースに対する変更は行われません。代わりに、if 条件を満たすリソースが非準拠とマークされます。

Modify のプロパティ

Modify 効果の details プロパティには、修復に必要なアクセス許可を定義するすべてのサブプロパティと、タグ値の追加、更新、または削除に使用する operations が含まれます。

roleDefinitionIds (必須)
- このプロパティには、サブスクリプションでアクセス可能なロールベースのアクセス制御ロール ID と一致する文字列の配列を含める必要があります。詳細については、修復 - ポリシー定義の構成に関するページを参照してください。
- 定義されたロールには、Contributor ロールに与えられているすべての操作が含まれている必要があります。
conflictEffect (省略可能)
- 複数のポリシー定義によって同じプロパティが変更された場合、または Modify 操作が指定したエイリアスで動作しない場合に、どのポリシー定義を "優先" するかを決定します。
  - 新規または更新されたリソースについては、Deny を持つポリシー定義が優先されます。 Audit のポリシー定義では、すべての operations がスキップされます。複数のポリシー定義に Deny 効果がある場合、その要求は競合として拒否されます。すべてのポリシー定義に Audit がある場合、競合しているポリシー定義のどの operations も処理されません。
  - 既存のリソースについては、複数のポリシー定義に Deny 効果がある場合、コンプライアンス状態は競合になります。 Deny 効果があるポリシー定義が 1 つ以下の場合、各割り当ては非準拠のコンプライアンス状態を返します。
- 使用可能な値は、Audit、Deny、Disabled です。
- 既定値は Deny です。
operations (必須)
- 一致するリソースで完了されるすべてのタグ操作の配列です。
- プロパティ:
  - operation (必須)
    - 一致するリソースに対して実行するアクションを定義します。オプションは、addOrReplace、Add、Remove です。 Add は、Append 効果に似た動作をします。
  - field (必須)
    - 追加、置換、または削除するタグです。タグ名は、他の fields と同じ名前付け規則に従う必要があります。
  - value (オプション)
    - タグに設定する値です。
    - このプロパティは、operation が addOrReplace または Add の場合に必要です。
  - condition (オプション)
    - true または false として評価されるポリシー関数による Azure Policy 言語式を含む文字列です。
    - field()、resourceGroup()、subscription() の各ポリシー関数はサポートされていません。

Modify の操作

operations プロパティ配列を使用すると、1 つのポリシー定義から複数のタグを異なる方法で変更できます。各操作は operation、field、および value の各プロパティで構成されます。 operation では、修復タスクがタグに対して行う処理を決定し、field では、どのタグを変更するかを決定し、value では、そのタグの新しい設定を定義します。次の例では、次のようにタグを変更します。

environment タグを "Test" に設定する (異なる値で既に存在している場合でも)。
タグ TempResource を削除する。
Dept タグを、ポリシーの割り当てで構成されたポリシーパラメーター DeptName に設定する。

"details": {
    ...
    "operations": [
        {
            "operation": "addOrReplace",
            "field": "tags['environment']",
            "value": "Test"
        },
        {
            "operation": "Remove",
            "field": "tags['TempResource']",
        },
        {
            "operation": "addOrReplace",
            "field": "tags['Dept']",
            "value": "[parameters('DeptName')]"
        }
    ]
}

operation プロパティには、次のオプションが用意されています。

操作	説明
addOrReplace	プロパティまたはタグが別の値で既に存在する場合でも、定義されたプロパティまたはタグと値をリソースに追加します。
追加	定義されたプロパティまたはタグと値をリソースに追加します。
[削除]	定義されたプロパティまたはタグをリソースから削除します。

Modify の例

例 1:environment タグを追加し、既存の environment タグを "Test" に置き換えます。

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "operations": [
            {
                "operation": "addOrReplace",
                "field": "tags['environment']",
                "value": "Test"
            }
        ]
    }
}

例 2:env タグを削除し、environment タグを追加するか、既存の environment タグをパラメーター化された値に置き換えます。

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "conflictEffect": "deny",
        "operations": [
            {
                "operation": "Remove",
                "field": "tags['env']"
            },
            {
                "operation": "addOrReplace",
                "field": "tags['environment']",
                "value": "[parameters('tagValue')]"
            }
        ]
    }
}

例 3: ストレージアカウントで BLOB のパブリックアクセスが許可されていないことを確認します。Modify 操作は、API バージョンが '2019-04-01' 以上の要求を評価する場合にのみ適用されます。

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/microsoft.authorization/roleDefinitions/17d1049b-9a84-46fb-8f53-869881c3d3ab"
        ],
        "conflictEffect": "audit",
        "operations": [
            {
                "condition": "[greaterOrEquals(requestContext().apiVersion, '2019-04-01')]",
                "operation": "addOrReplace",
                "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
                "value": false
            }
        ]
    }
}

ポリシー定義を階層化する

リソースは複数の割り当ての影響を受ける可能性があります。これらの割り当てのスコープは、同じ場合も異なっている場合もあります。これらの各割り当てにもさまざまな効果が定義されている可能性があります。各ポリシーの条件と効果は個別に評価されます。次に例を示します。

ポリシー 1
- リソースの場所を 'westus' に制限する
- サブスクリプション A に割り当てる
- Deny 効果
ポリシー 2
- リソースの場所を 'eastus' に制限する
- サブスクリプション A のリソースグループ B に割り当てる
- Audit 効果

この設定の結果は次のようになります。

リソースグループ B の既存のリソースで、場所が 'eastus' のリソースは、ポリシー 2 に準拠しているが、ポリシー 1 には準拠していない
リソースグループ B に既に存在するが、場所が 'eastus' でない既存のリソースは、ポリシー 2 に準拠せず、場所が 'westus' でない場合はポリシー 1 にも準拠していない
サブスクリプション A の新しいリソースで、場所が 'westus' でないリソースは、ポリシー 1 によって拒否される
サブスクリプション A のリソースグループ B の新しいリソースで、場所が 'westus' であるリソースは作成されるが、ポリシー 2 には準拠していない

ポリシー 1 とポリシー 2 の両方に Deny 効果がある場合、状況は次のように変化します。

リソースグループ B に既に存在するが、場所が 'eastus' でないリソースは、ポリシー 2 に準拠していない
リソースグループ B に既に存在するが、場所が 'westus' でないリソースは、ポリシー 1 に準拠していない
サブスクリプション A の新しいリソースで、場所が 'westus' でないリソースは、ポリシー 1 によって拒否される
サブスクリプション A のリソースグループ B の新しいリソースは、すべて拒否される

各割り当ては個別に評価されます。そのため、スコープの違いによって発生する隙間をリソースがすり抜けるチャンスはありません。ポリシー定義の階層化による最終的な結果は、累積的に最も制限が厳しいと考えられます。たとえば、ポリシー 1 とポリシー 2 の両方に拒否効果が設定されている場合、重複するポリシー定義と競合するポリシー定義によって、リソースがブロックされます。リソースを対象のスコープ内に必ず作成する必要がある場合は、それぞれの割り当ての除外を見直して、適切なポリシー割り当てが適切なスコープに影響を与えていることを確認してください。

次のステップ

Azure Policy のサンプルを確認します。
「Azure Policy の定義の構造」を確認します。
プログラムによってポリシーを作成する方法を理解します。
コンプライアンスデータを取得する方法を学習します。
準拠していないリソースを修復する方法を学習します。
「Azure 管理グループのリソースを整理する」で、管理グループとは何かを確認します。

Azure Policy の効果について

効果の入れ替え

評価の順序

Append

Append の評価

Append のプロパティ

Append の例

Audit

Audit の評価

Audit のプロパティ

Audit の例

AuditIfNotExists

AuditIfNotExists の評価

AuditIfNotExists のプロパティ

AuditIfNotExists の例

拒否

Deny の評価

Deny のプロパティ

Deny の例

DenyAction (プレビュー)

DenyAction の評価

サブスクリプションの削除

リソース グループの削除

カスケード削除

DenyAction のプロパティ

DenyAction の例

DeployIfNotExists

DeployIfNotExists の評価

DeployIfNotExists のプロパティ

DeployIfNotExists の例

無効

Manual (プレビュー)

変更

Modify の評価

Modify のプロパティ

Modify の操作

Modify の例

ポリシー定義を階層化する

次のステップ

その他のリソース

その他のリソース

リソースグループの削除