Azure Policy 定義の効果の基本

  • [アーティクル]

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

サポートされている Azure Policy 定義の効果を次に示します。

効果の入れ替え

1 つのポリシー定義に対して、複数の効果を有効にすることができる場合があります。 パラメーターは、割り当て時に 1 つの定義の汎用性を高めるため、許可される効果の値 (allowedValues) を指定するためによく使用されます。 しかし、すべての効果が交換可能ではないことに注意することが重要です。 特定の効果がポリシー定義に対して有効であると見なされるかどうかは、ポリシー ルールのリソース プロパティとロジックによって決まります。 たとえば、効果 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 を評価することによって、不要なリソースの二重のログ記録が回避されます。
  • audit が評価されます。
  • manual が評価されます。
  • auditIfNotExists が評価されます。
  • 最後に denyAction が評価されます。

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

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

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

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

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

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

  • リソース グループ B 内の既存のリソースで eastus 内にあるものは、ポリシー 2 に準拠しているが、ポリシー 1 には準拠していない
  • リソース グループ B 内の既存のリソースで eastus 内にないものは、ポリシー 2 に準拠しておらず、westus 内にない場合はポリシー 1 にも準拠していない
  • ポリシー 1 が、サブスクリプション A 内の新しいリソースで westus 内にないものを拒否する
  • サブスクリプション A 内かつリソース グループ B 内の新しいリソースで、westus 内にあるものは作成されるが、ポリシー 2 には準拠していない

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

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

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

次のステップ