Azureを学ぶ Azure Policyのイニシアティブ

Posted at 2025-08-14

本記事は Microsoft Learn の「Azure Policyのイニシアティブ」というモジュールをまとめたものである。

はじめに

Azure Policy は、Azure リソースにルールや効果を適用し、企業や規制の基準に準拠させるためのサービス。ポリシーは JSON で定義され、複数をまとめたものを「ポリシーイニシアチブ」と呼ぶ。

ポリシー: 単一のルールや効果を定義
イニシアチブ: 関連する複数のポリシーをまとめたもの

これにより、

新しいリソースに条件を適用
大規模にコンプライアンスを監視・評価
非準拠リソースの修正
デプロイや運用の一貫性確保

特に政府・公共・金融など規制が厳しい業界で有効で、クラウド利用時の規制遵守やガバナンスを効率的に実現できる。

Azure 向けクラウド導入フレームワーク

Microsoft Azure 向けクラウド導入フレームワークは、Azure の導入や活用を成功させるための包括的な技術ガイドライン。

対象: クラウドアーキテクト、IT担当者、ビジネスリーダー
内容: ベストプラクティス、ドキュメント、ツールを提供
目的: ビジネス戦略とテクノロジー戦略の策定・実装を支援
特徴: 計画から運用までのエンドツーエンド支援

つまり、Azure 導入の「道しるべ」となる公式のフレームワーク。

次の図は、クラウド導入ライフサイクルの各フェーズにおける、Azure 向け Microsoft クラウド導入フレームワークに含まれる様々な手法の概要を示している。

クラウドガバナンスとは、組織におけるクラウド利用を監視・管理し、適切に運用するための仕組み。Azure の「クラウド導入フレームワーク - ガバナンス」は、その構築と改善を行うための体系的な方法を提供する。

対象領域: 規制コンプライアンス、セキュリティ、運用、コスト管理、データ管理、リソース管理、AI など重要分野を網羅
目的:
- 効率的なクラウド利用の定義と維持
- コンプライアンスやセキュリティリスクの低減
- リソースやデータ関連リスクの最小化
- クラウド活動を組織全体の戦略と整合
- ビジネス目標達成を阻害する要因を削減

つまり、クラウドガバナンスは安全・効率的・戦略的にクラウドを使い続けるための管理体制という位置づけになる。

クラウドガバナンスの手順

クラウドガバナンスは、一度作って終わりではなく、常に変化するテクノロジーやリスク、コンプライアンス要件に合わせて進化させていく必要がある。そのためには、継続的な監視・評価・調整が欠かせない。Azure のクラウド導入フレームワーク - ガバナンス手法では、このガバナンスを次の 5つのステップに分けて進める。

ガバナンスチームの構築: ガバナンスを定義・維持・報告する担当チームを組織する
リスク評価: 規制、セキュリティ、運用、コスト、データ、AI などあらゆるリスクを洗い出す
ポリシーの文書化: 許容されるクラウド利用と、それを支えるルールを明文化
ポリシーの適用: Azure Policy などの仕組みでルールを実際の環境に反映
ガバナンスの監視: 利用状況とポリシーの効果を継続的にチェックし、必要に応じて改善

このサイクルを繰り返すことで、クラウド運用を安全かつ効率的に維持できる。

クラウドガバナンスポリシーを定義する際の考慮事項

ビジネスリスク: データ分類やアプリケーション重要度に基づき、変化するビジネスリスクと許容度を文書化する
ポリシーとコンプライアンス: リスク判断を明確なポリシーステートメントに変換し、クラウド利用の境界を定義する
プロセス: ポリシー遵守状況や違反を監視する仕組みを整備する

クラウドガバナンスの5つの中核分野

コスト管理
- コストの評価・監視、IT支出の管理、需要に応じたリソース調整
- 投資の価値を最大化するための重要ポイント
セキュリティベースライン
- すべての導入にセキュリティ基準を適用し、ITセキュリティ要件を満たす
リソースの一貫性
- 構成の一貫性を維持し、オンボーディング、回復、検出可能性のプラクティスを実施
IDベースライン
- ロールの定義・割り当てを統一し、アクセス管理を適切に維持
展開の高速化
- テンプレートの集中管理・標準化により、ポリシー適用や展開を迅速化

Azure Policy によるクラウドガバナンス

Azure Policy は、Microsoft Azure における主要なガバナンスツールであり、組織全体のクラウド環境に対して一貫した標準を適用し、コンプライアンスの維持と監視を可能にする。現在および将来のすべてのリソースにガードレールを設定することで、ポリシー違反の防止や既存リソースの自動修復を実現できる。

主な特徴は以下の通り。

コンプライアンスの可視化と監査
- コンプライアンスデータを単一リポジトリに統合
- ダッシュボードで環境全体の状態を確認可能
- 監査プロセスや違反調査を簡素化
適用できるガバナンスアクション
- 許可リージョンの制限
- データ所在地要件の適用
- 仮想マシンサイズの制限
- リソースタグの一貫した適用
- 多要素認証の必須化
- 診断ログ送信の強制
自動修復機能
- 非準拠リソースの作成阻止
- 既存リソースの自動修復
- 必要に応じて特定リソースを例外として設定可能
DevOps との統合
- CI/CD パイプラインにポリシーを適用
- デプロイ前後のガバナンスを徹底
設計上の考慮
- 環境の安定性や制御を確保しつつ、運用や開発のスピードを損なわないバランスを重視
- 新ポリシー導入前に影響を慎重に評価

Azure Policy を活用することで、組織は安全かつ効率的にクラウド環境を管理し、コンプライアンスとガバナンスを強化できる。

Azure Policy の設計原則

ガバナンスは、Azure 上のアプリやリソースを管理する仕組みで、Azure Policy を使ってポリシーを計画・優先順位付けし、リソースやコストを整理・管理・追跡することが重要。

ガバナンスのための階層

Azure では、適切なガバナンスを実現するために、管理グループ・サブスクリプション・リソースグループ・リソースの4つの管理レベルを提供している。管理グループとサブスクリプションを組み合わせることで、リソースを階層的に整理し、ポリシーやアクセス権を一元管理できる。

コンセプト	説明
リソース	Azure の基本単位。サービスのインスタンス（VM、仮想ネットワーク、データベース、AIサービスなど）。
リソースグループ	複数のリソースをまとめる単位。アクションやアクセス権はグループ内のすべてのリソースに適用される。グループ削除で全リソース削除。
サブスクリプション	管理・課金・スケールの単位。リソースグループを論理的に整理し、コスト管理が可能。Azure へのアクセスやリソース作成に必要。各サブスクリプションには利用制限（クォータ）がある。
管理グループ	サブスクリプションより上位の単位。複数サブスクリプションのアクセス、ポリシー、コンプライアンスを統合管理可能。入れ子構造にして大規模管理が可能。

Azure の管理設定は階層的に適用され、上位レベルの設定は下位レベルに自動的に継承される。管理グループの設定は配下のサブスクリプション全体に、サブスクリプションの設定は配下のリソースグループとリソースに、リソースグループの設定はそのグループ内のリソースに適用される。

Azure リソースマネージャーの概要

Azure Resource Manager (ARM) は、Azure 上のリソースを作成・更新・削除するための管理レイヤーを提供するデプロイ・管理サービス。
Azure の操作は大きく2種類に分けられる。

コントロールプレーン：サブスクリプション内のリソースを管理する操作
データプレーン：各リソースが提供する機能やデータにアクセスする操作

コントロールプレーン

Azure Policy はコントロールプレーン上で動作し、リソースにルールやコンプライアンスを適用する。これは Azure Resource Manager (ARM) と統合されており、ARM は Azure 内のすべてのコントロールプレーン操作を管理する中心的なサービス。

ARM が提供する主な機能は以下の通り。

テンプレートベースのデプロイ：複数リソースを一括で展開可能
ロールベースのアクセス制御 (RBAC)：権限を細かく管理
監査・監視：操作や変更を追跡
タグ付け：リソースの分類と管理
ポリシー適用：例として、ストレージアカウント作成時に暗号化を強制

ARM は、ポータルだけでなく PowerShell、Azure CLI、REST API、SDK からの操作も統一的に処理する。要求は認証・承認された後、該当する Azure リソースプロバイダーに転送され、そこで操作が実行される。

要するに、Azure Policy と ARM を組み合わせることで、ポリシー適用からリソース管理までを一元的かつ自動的に制御できる仕組みになっている。

リソースプロバイダーは、特定の種類のリソースやサービスを作成・管理する機能を提供するコンポーネント。簡単に言うと、Azure の各サービスを扱う「サービスの入口」のようなもの。

役割
- 新しいリソースの作成、更新、削除を担当
- サービス固有の API を通じて操作を実行
- RBAC やポリシーを適用可能にする
例
Microsoft.Compute：仮想マシンやディスクなどの計算リソースを管理
Microsoft.Storage：ストレージアカウントやファイル共有を管理
Microsoft.KeyVault：Key Vault 内のシークレットや証明書を管理

つまり、Azure Resource Manager が「リクエストを受け取る窓口」なら、リソースプロバイダーは「実際にそのリクエストを処理するサービス」になる。

データプレーン

データプレーンはリソース上で実際のデータ操作が行われる場所で、Azure Policy はこれらの操作がポリシーに準拠していることを保証する。データプレーン操作では、ストレージやデータベースなどのリソースに直接アクセスし、アップロード・ダウンロードやクエリなどを実行する。アクセス権はサービス固有の RBAC や ACL で管理され、Azure Resource Manager を経由せずにリソースプロバイダーが直接処理する。

Azure Policy は、各サービスに拡張機能を追加することでポリシーの適用を強化し、特定のリソースプロバイダーと統合できる。現在、以下のプロバイダーでデータ操作（データプレーン）をサポートしている。

Microsoft.Kubernetes.Data：Kubernetes クラスターやポッド、コンテナーなどを管理
Microsoft.KeyVault.Data：Key Vault 内のシークレットや証明書を管理
Microsoft.Network.Data：Virtual Network Manager のカスタムポリシーを管理
Microsoft.ManagedHSM.Data：Managed HSM キーを管理
Microsoft.DataFactory.Data：Data Factory の送信トラフィックドメインを制御
Microsoft.MachineLearningServices.v2.Data：ML モデルのデプロイを管理し、コンプライアンスを報告

要するに、これらのプロバイダーを通じて Azure Policy はリソースごとの操作やコンプライアンス監視を直接行える。

Azure Resource Manager の操作フロー

Azure Policy の評価には、リソースの状態によってグリーンフィールドとブラウンフィールドの 2 つのシナリオがある。

グリーンフィールド
- 新しいリソースを作成または更新する場合のシナリオ
- リクエストはまず RBAC を通過し、アクセス権があれば Azure Policy によって評価される
- 更新時は、既存リソースの差分だけが送信され、現在の状態とマージした結果がポリシー評価に使用される
ブラウンフィールド
- 既存リソースに新しいポリシーを割り当てる場合のシナリオ
- ポリシー評価はコンプライアンススキャンによって行われる（24時間ごとに自動、手動でも可能）
- 既存リソースは削除されず、非準拠のリソースとしてフラグが付けられる
- 今後のリソース作成に対してポリシーが適用される

要するに、グリーンフィールドは「作るときに評価」、ブラウンフィールドは「既存に後から評価」を行う仕組み。

Azure Policy リソース

Azure Policy は、組織の標準をリソースに適用し、コンプライアンス状況をまとめて評価する仕組み。リソースや操作のプロパティをビジネスルールと照らし合わせ、環境全体の状態を一目で把握できる。ポリシーは個別リソースからポリシーレベルまで詳細に分析可能で、Azure では 6種類のポリシーリソースが用意され、それぞれ異なる概念で運用される。

定義

Azure Policy 定義では、リソースのコンプライアンス条件と、その条件が満たされた場合の効果を記述する。ポリシーが評価する対象はスコープによって決まり、Azure のガバナンス階層（管理グループ、サブスクリプション、リソースグループ、リソース）と対応している。

定義の保存場所：管理グループやサブスクリプションに保存
割り当てスコープ：ポリシーやイニシアチブの適用範囲を指定
継承：下位レベルは上位レベルの設定を自動的に継承

これにより、どのリソースが評価され、コンプライアンスにカウントされるかを制御できる。

イニシアティブ

Azure Policy のイニシアティブ（ポリシーセット）は、複数のポリシー定義をまとめて管理できる仕組み。イニシアティブを使うと、ポリシーの割り当てや管理が簡単になり、大規模なコンプライアンス管理を効率化できる。

イニシアティブの利点
- 複数のポリシーを 1 つにまとめて操作可能
- 組織のコンプライアンス目標や規制フレームワークへの準拠を追跡
- JSON で定義可能
種類
- 組み込みイニシアティブ
  - Azure が提供する既存のポリシーセット
  - 規制フレームワークやセキュリティベストプラクティスへの準拠をサポート
- カスタムイニシアティブ
  - 組み込みポリシーでは対応できない場合にユーザーが作成
  - 組織固有のルールや標準に合わせてカスタマイズ可能
拡張例
- Microsoft for Sovereignty イニシアティブは、組み込みイニシアティブを拡張し、データ保護やコンプライアンス違反リスクの軽減を支援
- GitHub の Industry-policy-portfolio リポジトリで複数のカスタムポリシーイニシアティブとコンプライアンスマッピングにアクセス可能

まとめると、イニシアティブを利用することで、ポリシー管理の効率化、コンプライアンスの大規模な追跡、組織固有の要件への柔軟対応が可能になる。

割り当て

ポリシー割り当ては、どのリソースにポリシーやイニシアティブを適用するかを決める仕組みで、ポータルや API 、CLI から作成できる。ポリシーやイニシアティブの定義は管理グループやサブスクリプションに保存され、その場所によって割り当て可能な範囲（スコープ）が決まる。割り当てでは、以下のようなオプションが設定できる。

リソースの場所や種類に応じた段階的な適用（リソースセレクター）
ポリシー定義の効果を変更するオーバーライド
「what-if」シナリオのために実際の強制を無効にする enforcementMode
特定のコンテナーやリソースを評価対象から除外する除外スコープ
非準拠時のメッセージ設定
パラメータ値の割り当て
deployIfNotExists効果のポリシーでの修復アクションを有効化するマネージドID割り当て

これらの設定によって、どのリソースが評価対象になるか、どのリソースがコンプライアンスに含まれるかを柔軟に制御できる。

免除

ポリシー免除機能は、特定のリソースやリソース階層をポリシーやイニシアチブの評価から除外できる機能。免除のポイントを整理すると以下の通り。

免除されたリソースはコンプライアンスにはカウントされるが、評価対象外または一時的に免除される
免除は割り当て作成時ではなく、割り当て後に設定される
リソース階層の子オブジェクトや個別リソースに対して適用可能
免除には2種類ある
- 緩和：ポリシーの目的が別の方法で達成されている場合
- 免除：非準拠状態を一時的に許容する場合

この機能により、例外的な状況でも柔軟にポリシー運用が可能になる。

証明書

ポリシー構成証明は、手動ポリシーでリソースやスコープのコンプライアンス状態を管理・記録するための仕組み。各リソースには割り当てごとに1つ必要で、管理を簡単にするためにスコープを明確に設定して使う。

修復

ポリシー修復タスクは、Azure Policy によって評価されたリソースを自動的にコンプライアンス対応にする機能。modify や deployIfNotExists のポリシーに準拠していない既存のリソースは手動で修復タスクを実行でき、これらのポリシーに該当する新規作成や更新されたリソースは自動的に修復される。

Azure Policy 定義

Azure Policy 定義は、リソースのコンプライアンス条件と、それらの条件が満たされた場合に実行されるアクションまたは効果を記述する。

ポリシー定義の解剖

次の表に示す要素を含むポリシー定義を作成するには、JSON を使用する。

要素	説明	プロパティまたは値
displayName（文字列、最大128文字）	ポリシー定義を識別するために使用される	なし
説明（文字列、最大512文字）	定義が使用される場合のコンテキストを提供	なし
policyType（読み取り専用文字列）	ポリシー定義の元を示す（設定不可）	●Built in: Microsoft 提供・保守 ● Custom: 顧客作成 ● Static: Microsoft所有の規制コンプライアンスポリシー
モード（文字列）	ポリシーのターゲットに応じて構成	● リソースマネージャーモード: o すべて: リソースグループ、サブスクリプション、全リソース種類 o インデックス: リソースグループ、サブスクリプション、全リソース種類 ● リソースプロバイダーモード（組み込み・完全サポート）: o Microsoft.Kubernetes.Data o Microsoft.KeyVault.Data o Microsoft.Network.Data ● リソースプロバイダーモード（組み込み・プレビュー）: o Microsoft.ManagedHSM.Data o Microsoft.DataFactory.Data
バージョン（文字列、オプション）	組み込みポリシー定義は複数バージョンをホスト可能	指定なしの場合は最新バージョンが表示
メタデータ（オブジェクト、オプション、最大1,024文字）	ポリシー定義に関する情報を保存	共通プロパティ（組み込みポリシー用）: ● version: 内容のバージョン ● category: Azure portalのカテゴリ ● preview: プレビュー段階かどうか（true/false） ● deprecated: 非推奨かどうか（true/false） ● portalReview: パラメータ確認要否
パラメータ（オブジェクト、オプション）	ポリシー定義の再利用性を高める	プロパティ: ● 名前 ● 型（文字列、配列、オブジェクト、ブール値、整数、浮動小数点数、日時） ● メタデータ（説明、表示名、強いタイプ、割り当て権限） ● デフォルト値 ● 許可された値 ● スキーマ
ポリシールール（オブジェクト）	ポリシーの効果を定義	ifブロック: 適用条件 thenブロック: 条件がtrueの時の効果

{
  "displayName": "Allowed locations",
  "description": "This policy enables you to restrict the locations your organization can specify when deploying resources. Use to enforce your geo-compliance requirements. Excludes resource groups, Microsoft.AzureActiveDirectory/b2cDirectories, and resources that use the 'global' region.",
  "policyType": "BuiltIn",
  "mode": "Indexed",
  "metadata": {
    "version": "1.0.0",
    "category": "General"
  },
  "parameters": {
    "listOfAllowedLocations": {
      "type": "Array",
      "metadata": {
        "description": "The list of locations that can be specified when deploying resources.",
        "strongType": "location",
        "displayName": "Allowed locations"
      }
    }
  },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "location",
            "notIn": "[parameters('listOfAllowedLocations')]"
          },
          {
            "field": "location",
            "notEquals": "global"
          },
          {
            "field": "type",
            "notEquals": "Microsoft.AzureActiveDirectory/b2cDirectories"
          }
        ]
      },
      "then": {
        "effect": "deny"
      }
    }
  }

論理演算子と条件（ifブロック）

if ブロックは、ポリシーがリソースを評価する条件を定義する部分で、複数の条件を組み合わせて評価でき、すべてまたは一部の条件が満たされればよい場合がある。

ifブロックでサポートされている論理演算子

Operator	タイプ	説明
not	条件またはオペレーター	条件の結果を反転させる
allOf	条件またはオペレーターの配列	論理 AND のように働き、すべての条件が true である必要がある
anyOf	条件またはオペレーターの配列	論理 OR のように働き、1つ以上の条件が true であればよい

{
  "if": {
    "allOf": [
      {
        "field": "location",
        "notIn": "[parameters('listOfAllowedLocations')]"
      },
      {
        "field": "location",
        "notEquals": "global"
      },
      {
        "field": "type",
        "notEquals": "Microsoft.AzureActiveDirectory/b2cDirectories"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

ネストされた論理演算

論理演算は必須ではなく、ネストさせることで複雑な条件を作れる。たとえば、allOf の中に not を組み込むことが可能。

"if": {
    "allOf": [
      {
        "not": {
          "field": "tags",
          "containsKey": "application"
        }
      },
      {
        "field": "type",
        "equals": "Microsoft.Storage/storageAccounts"
      }
    ]
  },

条件

条件では、フィールドや値、件数などのプロパティを評価できる。

評価基準 (Evaluation criteria)	値の型
equals	文字列
notEquals	文字列
like	文字列
notLike	文字列
match	文字列
notMatch	文字列
matchInsensitively	文字列
notMatchInsensitively	文字列
contains	文字列
notContains	文字列
In	文字列の配列
notIn	文字列の配列
containsKey	キー名
notContainsKey	キー名
less	日付、文字列、整数
lessOrEquals	日付、文字列、整数
greater	日付、文字列、整数
greaterOrEquals	日付、文字列、整数
exists	真偽値

{
  "if": {
    "allOf": [
      {
        "value": "[resourceGroup().name]",
        "like": "*netrq"
      },
      {
        "field": "type",
        "notLike": "Network/*"
      }
    ]
  },
  "then": {
    "effect": "deny",
    "details": {
      "count": {
        "field": "Microsoft.Network/virtualNetworks/addressSpace.addressPrefixes[*]",
        "where": {
          "value": "[ipRangeContains('10.0.0.0/24', current('Microsoft.Network/virtualNetworks/addressSpace.addressPrefixes[*]'))]",
          "equals": "greater"
        }
      }
    }
  }
}

ポリシー関数

ポリシー関数は、ポリシールールに追加のロジックを組み込むために使われる。ポリシー定義のルール内や、イニシアティブで割り当てられたパラメータ値内で評価される。基本的に、Resource Manager テンプレートで使える関数はポリシールールでも使用可能だが、一部のポリシー専用関数やユーザー定義関数は除かれる。

関数	説明
addDays(dateTime, numberOfDaysToAdd)	dateTime（必須）：ISO 8601形式の日時文字列 'yyyy-MM-ddTHHss.FFFFFFFZ'。 numberOfDaysToAdd（必須）：加算する日数（整数）。指定した日数を dateTime に加算する。
Field(fieldName)	fieldName（必須）：取得するフィールド名。 If 条件で評価されるリソースからそのフィールドの値を返す。主に auditIfNotExists や deployIfNotExists で、評価対象リソースのフィールド参照に使用。
requestContext().apiVersion	ポリシー評価をトリガーしたリクエストの API バージョンを返す。リソース作成・更新時の PUT/PATCH リクエストで使用された API バージョンが返され、既存リソースのコンプライアンス評価では常に最新バージョンが使用される。
policy()	評価中のポリシーに関する情報を返す。返されるオブジェクトから以下のプロパティにアクセス可能。 "assignmentId", "definitionId", "setDefinitionId", "definitionReferenceId"
ipRangeContains(range, targetRange)	range（必須）：チェックする IP アドレス範囲。 targetRange（必須）：範囲内に含まれているかを確認する IP アドレス範囲。 targetRange が range に含まれていれば true、そうでなければ false を返す。空の範囲や IP ファミリの混在は評価失敗になる。
current(indexName)	count 式内でのみ使用可能な特殊関数。評価中の配列メンバーの値を返す。

効果の種類（then ブロック）

Azure Policy 定義における policyRule の2つ目の部分は then ブロックで、条件に一致したリソースに対して実行される効果を定義する。1つのポリシー定義で複数の効果が有効になる場合があり、パラメータを使って許可される効果（allowedValues）を指定することで、同じ定義を割り当て時に柔軟に使えるようにできる。リソースのプロパティやルール内のロジックによって、どの効果が有効かが決まる。

効果	説明	タイプ
disabled	ポリシーを無効化する効果。Disabled が設定されたポリシー定義では、その割り当ては有効にならず、まずこの効果が評価され、ポリシールールの評価が行われるか決定される。特定の割り当てだけを無効化できる柔軟性がある。	同期評価
append	リソース作成または更新時に追加フィールドをリクエストに付加する効果。Modify による代替が可能で、現在はほぼ非推奨。	同期評価
modify	作成または更新時にサブスクリプションやリソースのプロパティやタグを追加・更新・削除する効果。Azure Policy がリソースマネージャーのリクエストを変更し、コンプライアンスを確保する。	同期評価
deny	定義された基準に合わないリソース要求を拒否する効果。	同期評価
denyAction	リソースに対する特定の操作をスケールでブロックする効果。現在サポートされているのは DELETE のみ。	同期評価
audit	非準拠リソースを評価した際にアクティビティログに警告イベントを作成する効果。リクエスト自体は停止しない。	非同期評価
auditIfNotExists	if 条件に一致するリソースに関連するリソースで、then 条件の詳細に指定されたプロパティを持たない場合に監査する効果。	非同期評価
deployIfNotExists	条件に一致した場合にテンプレート展開を実行する効果。現在評価中のリソースのコンプライアンス状態に応じて関連リソースのデプロイをトリガーできる。	非同期評価
manual	手動でリソースやスコープのコンプライアンスを証明する効果。Manual 効果のポリシー割り当てでは、対象リソースやスコープのコンプライアンス状態をカスタム証明で設定できる。	手動証明

Azure Policy によるリソースの評価

評価トリガー

割り当てられたポリシーやイニシアチブの評価は、以下のタイミングで行われる。

ポリシーやイニシアチブがスコープに新しく割り当てられたとき
既存の割り当てが更新されたとき
Azure Resource Manager、REST API、またはサポートされる SDK を通じてスコープ内のリソースが作成・更新されたとき
管理グループ内でサブスクリプションが作成・移動されたとき（サブスクリプションリソースタイプを対象とするポリシー定義の場合）
ポリシー免除が作成・更新・削除されたとき
標準のコンプライアンス評価サイクルによるとき
マシン構成リソースプロバイダーが管理対象リソースに基づきコンプライアンスの詳細を更新したとき
オンデマンドスキャンが実行されたとき

評価タイミング

Azureで既存リソースに新しいポリシーを適用する場合（ブラウンフィールドシナリオ）、コンプライアンススキャンのタイミングを理解しておくことが重要。

自動フルスキャン
24時間ごとに全リソースを対象に自動でコンプライアンススキャンが実行される
手動スキャン（ブラウンフィールド向け）
既存リソースにポリシーを適用した場合、az policy state trigger-scan でスキャンを手動で起動可能

コンプライアンススキャンが完了するまでの時間は、複数の要因によって変動する。

ポリシー定義の複雑さ
大きく複雑なポリシーはスキャンに時間がかかる
適用されるポリシーの数
多ければ多いほど、スキャンにかかる時間が長くなる
スコープのサイズ
割り当てられたリソースの数や範囲が大きいとスキャン時間も増加
システム負荷
コンプライアンススキャンは低優先度で実行されるため、システムがビジー状態だと遅延する
- 小規模環境でも数分〜数十分かかる場合あり
同期スキャンの影響
同期的に実行されるため、スコープやポリシーが小さくても完了まで時間がかかることがある

スキャンプロセスや潜在的な遅延を理解しておくことで、複雑な環境でもアプリケーション管理がしやすくなり、不要な待機を避けられる。

リソースコンプライアンス状態

Azure Policy では、ポリシーやイニシアティブが割り当てられると、まず適用可能なリソースを特定し、除外や免除されていないリソースを評価する。この評価に基づき、各リソースには次のようなコンプライアンス状態が割り当てられる。

非準拠：ポリシー要件を満たしていない
準拠：ポリシー要件を満たしている
エラー：テンプレートや評価時のエラー
競合：同一スコープ内で矛盾するポリシーが適用されている
保護されています：denyAction 効果により保護されている
免除不明：手動効果の定義で状態が未設定

複数のリソースやポリシーで状態が異なる場合は、個別に評価し優先度に基づいて全体の状態が決まる。コンプライアンス率は、準拠・免除・不明のリソース数を総リソース数（準拠、非準拠、不明、免除、競合、エラーを含む）で割って算出する。

強制モード

強制モード（enforcementMode）は、ポリシー割り当ての設定で、特定のポリシー効果の適用を無効化しつつ評価だけを行える機能。これにより、既存リソースに対してポリシーがどのように作用するかをテストでき、結果を確認してから効果を有効化できる。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up