Azure Policy の効果について

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

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

次の効果は "非推奨" です。

重要

EnforceOPAConstraint 効果または EnforceRegoPolicy 効果の代わりに、リソース プロバイダー モード Microsoft.Kubernetes.DataAuditDeny を使用します。 組み込みのポリシー定義が更新されています。 これらの組み込みポリシー定義の既存のポリシー割り当てが変更された場合、effect パラメーターは、更新された allowedValues リスト内の値に変更する必要があります。

評価の順序

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

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

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

さらに、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 プロパティと組み合わせて制約テンプレートの場所を指定します。 この場所はパブリックにアクセスできる必要があります。

        警告

        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 (必須)
  • labelSelector (必須)
    • matchLabels (オブジェクト) プロパティと matchExpression (配列) プロパティを含んだ "オブジェクト"。ポリシーの評価対象とする Kubernetes リソースを指定できます。ラベルおよびセレクターの指定と一致した Kubernetes リソースが評価対象となります。
    • 空にした場合、つまり値を指定しなかった場合、excludedNamespaces に定義された名前空間を除くすべてのラベルおよびセレクターがポリシーの評価対象になります。
  • apiGroups (templateInfo を使用する場合は必須)
    • マッチさせる API グループを含んだ 配列。 空の配列 ([""]) はコア API グループに、["*"] はすべての API グループに一致します。
  • kinds (templateInfo を使用する場合は必須)
    • 評価対象とする Kubernetes オブジェクトの kind を含んだ 配列
  • 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 (必須)
    • 照合する関連リソースの型を指定します。
    • details.typeif 条件リソース下にあるリソースの型である場合、この type のリソースが、ポリシーによって評価対象リソースのスコープ内から照会されます。 それ以外の場合は、評価対象リソースと同じリソース グループ内から照会されます。
  • Name (省略可能)
    • 照合するリソースの正確な名前を指定して、指定した型のすべてのリソースではなく 1 つの特定のリソースを取得します。
    • if.field.typethen.details.type の条件値が一致する場合、Name は "必須" になり、子リソースに対し [field('name')] または [field('fullName')] であることが必要です。 ただし、代わりに audit の影響を考慮する必要があります。
  • ResourceGroupName (省略可能)
    • 別のリソース グループに由来する関連リソースを照合できるようにします。
    • typeif 条件リソースの下にあるリソースである場合は適用されません。
    • 既定値は、if 条件リソースのリソース グループです。
  • ExistenceScope (省略可能)
    • 使用できる値は SubscriptionResourceGroup です。
    • 照合する関連リソースを取得する範囲を設定します。
    • typeif 条件リソースの下にあるリソースである場合は適用されません。
    • ResourceGroup の場合は、if 条件リソースのリソース グループまたは ResourceGroupName で指定されたリソース グループに制限されます。
    • Subscription の場合は、関連リソースのサブスクリプション全体を検索します。 適切に評価するためには、割り当てスコープがサブスクリプション以上で設定されている必要があります。
    • 既定値は ResourceGroup です。
  • EvaluationDelay (省略可能)
    • 関連リソースの存在を評価する必要があるタイミングを指定します。 遅延は、リソースの作成または更新要求の結果である評価のみに使用されます。
    • 使用できる値は AfterProvisioningAfterProvisioningSuccessAfterProvisioningFailure、または 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 (必須)
  • labelSelector (必須)
    • matchLabels (オブジェクト) プロパティと matchExpression (配列) プロパティを含んだ "オブジェクト"。ポリシーの評価対象とする Kubernetes リソースを指定できます。ラベルおよびセレクターの指定と一致した Kubernetes リソースが評価対象となります。
    • 空にした場合、つまり値を指定しなかった場合、excludedNamespaces に定義された名前空間を除くすべてのラベルおよびセレクターがポリシーの評価対象になります。
  • apiGroups (templateInfo を使用する場合は必須)
    • マッチさせる API グループを含んだ 配列。 空の配列 ([""]) はコア API グループに、["*"] はすべての API グループに一致します。
  • kinds (templateInfo を使用する場合は必須)
    • 評価対象とする Kubernetes オブジェクトの kind を含んだ 配列
  • 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"]
    }
}

DeployIfNotExists

AuditIfNotExists と同様に、DeployIfNotExists ポリシー定義は条件が満たされたときにテンプレートのデプロイを実行します。

注意

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

DeployIfNotExists の評価

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

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

DeployIfNotExists のプロパティ

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

  • Type (必須)

    • 照合する関連リソースの型を指定します。
    • 最初に if 条件リソースの下にあるリソースを取得しようとし、次に if 条件リソースと同じリソース グループ内を検索します。
  • Name (省略可能)

    • 照合するリソースの正確な名前を指定して、指定した型のすべてのリソースではなく 1 つの特定のリソースを取得します。
    • if.field.typethen.details.type の条件値が一致する場合、Name は "必須" になり、子リソースに対し [field('name')] または [field('fullName')] であることが必要です。
  • ResourceGroupName (省略可能)

    • 別のリソース グループに由来する関連リソースを照合できるようにします。
    • typeif 条件リソースの下にあるリソースである場合は適用されません。
    • 既定値は、if 条件リソースのリソース グループです。
    • テンプレートのデプロイが実行される場合は、この値のリソース グループにデプロイされます。
  • ExistenceScope (省略可能)

    • 使用できる値は SubscriptionResourceGroup です。
    • 照合する関連リソースを取得する範囲を設定します。
    • typeif 条件リソースの下にあるリソースである場合は適用されません。
    • ResourceGroup の場合は、if 条件リソースのリソース グループまたは ResourceGroupName で指定されたリソース グループに制限されます。
    • Subscription の場合は、関連リソースのサブスクリプション全体を検索します。 適切に評価するためには、割り当てスコープがサブスクリプション以上で設定されている必要があります。
    • 既定値は ResourceGroup です。
  • EvaluationDelay (省略可能)

    • 関連リソースの存在を評価する必要があるタイミングを指定します。 遅延は、リソースの作成または更新要求の結果である評価のみに使用されます。
    • 使用できる値は AfterProvisioningAfterProvisioningSuccessAfterProvisioningFailure、または ISO 8601 期間の 0 から 360 分の間です。
    • AfterProvisioning 値では、ポリシー規則の IF 条件で評価されたリソースのプロビジョニング結果が検査されます。 結果に関係なく、プロビジョニングが完了した後に AfterProvisioning が実行されます。 プロビジョニングに 6 時間より長くかかると、Afterprovisioning の評価の遅延を判断するときにエラーとして扱われます。
    • 既定値は PT10M (10 分間) です。
    • 評価の遅延を長く指定すると、リソースの記録されたコンプライアンス状態が次の評価のトリガーまで更新されない場合があります。
  • ExistenceCondition (省略可能)

    • 指定されない場合、type の関連リソースは効果を満たすため、デプロイはトリガーされません。
    • if 条件のポリシー規則と同じ言語が使用されますが、それぞれの関連リソースに対して個別に評価されます。
    • 照合する関連リソースのいずれかが true と評価された場合、効果は条件を満たしているため、デプロイはトリガーされません。
    • [field()] を使用して、if 条件の値と等しいことを確認できます。
    • たとえば、(if 条件内の) 親リソースが照合する関連リソースと同じリソースの場所にあることを検証できます。
  • roleDefinitionIds (必須)

    • このプロパティには、サブスクリプションでアクセス可能なロールベースのアクセス制御ロール ID と一致する文字列の配列を含める必要があります。 詳細については、修復 - ポリシー定義を構成するを参照してください。
  • DeploymentScope (省略可能)

    • 使用できる値は SubscriptionResourceGroup です。
    • トリガーされるデプロイの種類を設定します。 Subscriptionサブスクリプション レベルでのデプロイを示し、ResourceGroup はリソース グループへのデプロイを示します。
    • サブスクリプション レベルのデプロイを使用する場合は、Deploymentlocation プロパティを指定する必要があります。
    • 既定値は 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')]"
                    }
                }
            }
        }
    }
}

無効

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

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

EnforceOPAConstraint

この効果は、Microsoft.Kubernetes.Data のポリシー定義 モード で使用されます。 これは、OPA Constraint FrameworkOpen Policy Agent (OPA) に対して定義された Gatekeeper v3 受付制御ルールを、Azure 上の Kubernetes クラスターに渡すために使用されます。

重要

EnforceOPAConstraint 効果を持つ限定プレビュー ポリシー定義と、関連する Kubernetes Service カテゴリは、"非推奨" になっています。 代わりに、リソース プロバイダー モード Microsoft.Kubernetes.DataAudit 効果と Deny 効果を使用します。

EnforceOPAConstraint の評価

Open Policy Agent アドミッション コントローラーは、クラスター上の新しい要求をリアルタイムで評価します。 15 分ごとにクラスターのフル スキャンが完了し、結果が Azure Policy に報告されます。

EnforceOPAConstraint のプロパティ

EnforceOPAConstraint 効果の details プロパティには、Gatekeeper v3 受付制御ルールを記述するサブプロパティがあります。

  • constraintTemplate (必須)
    • 新しい制約を定義する、制約テンプレート CustomResourceDefinition (CRD) です。 このテンプレートは、Rego ロジック、制約スキーマに加えて、Azure Policy からの values で渡される制約パラメーターを定義します。
  • constraint (必須)
    • 制約テンプレートの CRD 実装です。 {{ .Values.<valuename> }} のように values で渡されるパラメーターを使用します。 以下の例では、これらの値は {{ .Values.cpuLimit }}{{ .Values.memoryLimit }} です。
  • values (省略可能)
    • 制約に渡すすべてのパラメーターと値を定義します。 それぞれの値は、制約テンプレート CRD に含まれている必要があります。

EnforceOPAConstraint の例

例:Kubernetes でコンテナーの CPU とメモリのリソース制限を設定する、Gatekeeper v3 の受付制御ルールです。

"if": {
    "allOf": [
        {
            "field": "type",
            "in": [
                "Microsoft.ContainerService/managedClusters",
                "AKS Engine"
            ]
        },
        {
            "field": "location",
            "equals": "westus2"
        }
    ]
},
"then": {
    "effect": "enforceOPAConstraint",
    "details": {
        "constraintTemplate": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/Kubernetes/container-resource-limits/template.yaml",
        "constraint": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/Kubernetes/container-resource-limits/constraint.yaml",
        "values": {
            "cpuLimit": "[parameters('cpuLimit')]",
            "memoryLimit": "[parameters('memoryLimit')]"
        }
    }
}

EnforceRegoPolicy

この効果は、Microsoft.ContainerService.Data のポリシー定義 モード で使用されます。 これは、Rego で定義されている Gatekeeper v2 受付制御ルールを Azure Kubernetes Service 上の Open Policy Agent (OPA) に渡すために使用されます。

重要

EnforceRegoPolicy 効果を持つ限定プレビュー ポリシー定義と、関連する Kubernetes Service カテゴリは、非推奨 になっています。 代わりに、リソース プロバイダー モード Microsoft.Kubernetes.DataAudit 効果と Deny 効果を使用します。

EnforceRegoPolicy の評価

Open Policy Agent アドミッション コントローラーは、クラスター上の新しい要求をリアルタイムで評価します。 15 分ごとにクラスターのフル スキャンが完了し、結果が Azure Policy に報告されます。

EnforceRegoPolicy のプロパティ

EnforceRegoPolicy 効果の details プロパティには、Gatekeeper v2 受付制御ルールを記述するサブプロパティがあります。

  • policyId (必須)
    • Rego 受付制御規則にパラメーターとして渡される一意の名前。
  • policy (必須)
    • Rego 受付制御規則の URI を指定します。
  • policyParameters (省略可能)
    • rego ポリシーに渡すパラメーターと値を定義します。

EnforceRegoPolicy の例

例:AKS で指定されたコンテナー イメージのみを許可する Gatekeeper v2 受付制御ルール。

"if": {
    "allOf": [
        {
            "field": "type",
            "equals": "Microsoft.ContainerService/managedClusters"
        },
        {
            "field": "location",
            "equals": "westus2"
        }
    ]
},
"then": {
    "effect": "EnforceRegoPolicy",
    "details": {
        "policyId": "ContainerAllowedImages",
        "policy": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/KubernetesService/container-allowed-images/limited-preview/gatekeeperpolicy.rego",
        "policyParameters": {
            "allowedContainerImagesRegex": "[parameters('allowedContainerImagesRegex')]"
        }
    }
}

変更

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

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

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

重要

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

Modify の評価

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

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

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

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

重要

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

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

Modify のプロパティ

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

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

Modify の操作

operations プロパティ配列を使用すると、1 つのポリシー定義から複数のタグを異なる方法で変更できます。 各操作は operationfield、および 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 プロパティには、次のオプションが用意されています。

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 の両方に拒否効果が設定されている場合、重複するポリシー定義と競合するポリシー定義によって、リソースがブロックされます。 リソースを対象のスコープ内に必ず作成する必要がある場合は、それぞれの割り当ての除外を見直して、適切なポリシー割り当てが適切なスコープに影響を与えていることを確認してください。

次のステップ