2024-10-10

Azure Policyとは？その役割や仕組み、設定方法をわかりやすく解説！

この記事のポイント

Azure Policyはリソースの作成・更新時にルールを強制し、組織のポリシーに沿ったリソース管理を実現
ポリシー定義、イニシアチブ定義、割り当ての3つの要素で構成され、柔軟なルール適用が可能
カスタムポリシーの作成や組み込みポリシーの活用により、多様な管理ニーズに対応
Azure RBACと異なり、リソースの状態そのものを制御し、コンプライアンスを自動的に監査
リソース作成の制限、セキュリティ設定の強制、コスト管理など、幅広い活用シーンに対応

監修者プロフィール

坂本将磨

Microsoft AIパートナー、LinkX Japan代表。東京工業大学大学院で技術経営修士取得、研究領域：自然言語処理、金融工学。NHK放送技術研究所でAI、ブロックチェーン研究に従事。学会発表、国際ジャーナル投稿、経営情報学会全国研究発表大会にて優秀賞受賞。シンガポールでのIT、Web3事業の創業と経営を経て、LinkX Japan株式会社を創業。

Azure Policyは、組織のガバナンスを確立し、クラウドリソースを効率的に管理するための重要なサービスです。
ひとたびルールを定義してしまえば、自動的にリソースのコンプライアンスを監査し、管理することが可能です。

本記事では、Azure Policyがどのようにリソースの作成や設定を標準化し、組織のポリシーに準拠させるか、その役割や仕組みをわかりやすく解説していきます。
また、ポリシールールの作成から割り当て、監査までの各ステップを具体的に紹介し、実際の運用シーンに応じた活用のヒントも提供します。

クラウドリソースの管理をさらに効果的に行うためにも、Azure Policyの理解を深め、リソースの管理におけるリスクを軽減しましょう。

Azure RBACとの違い - リソース側の状態を制御

リソース作成の制限（特定のリージョンのみ許可など）

セキュリティ設定の強制（暗号化の有効化など）

コスト管理（特定のサイズの仮想マシンのみ許可など）

まとめ

Azure Policyとは

Azure Policyは、クラウドリソースを管理するためのサービスです。主に、企業や組織が決めたルールに基づいてAzure上のリソースを管理・制御し、コンプライアンスを確保するために使われます。

Azure Policyアイコン

組織全体でAzureリソースを安全かつ効率的に管理し、ガバナンス（管理体制）を強化してくれる、そんなAzure Policyについて紹介します。

Azure Policyの役割と特徴

では最初に、Azure Policyの主要な役割とAzure RBACとの違いを説明していきます。

ルールに沿ったリソース作成の強制

Azure Policyは、リソースを作成・更新する際に事前に設定されたルール（ポリシー）を必ず守らせる働きをします。

そのルールとは、以下のようなものがあげられます。

特定のリソースタイプの作成を禁止: 組織が不必要なリソースを作成しないように制限。
リソースに必要なタグの設定を強制: 例えば、プロジェクト名や部門名などのタグを必ず設定させるというルールを設定すれば、タグがないとリソースを作成できません。
許可されたリージョンでの作成を制限: たとえば、特定のリージョンでしかリソースを作れないルールを設定した場合、他のリージョンでリソースを作成しようとすると、Azure Policyがそれを拒否します。

このようにして、Azure Policyを活用することで、組織が定めたルールや推奨される手法（ベストプラクティス）に従って、Azure上でリソースを管理できるのです。

ルール違反のリソースを監査

以下のような特徴により、既存のリソースが組織のポリシーに従っているかを定期的に監査し、違反を検出してくれます。

定期的なスキャン: リソースを定期的にスキャンし、設定したルールに違反しているリソースを自動的に検出します。
違反リソースの詳細なレポート生成: 違反が見つかった場合、管理者はどのリソースがどのルールに違反しているのか、詳細なレポートを確認できます。
コンプライアンスダッシュボード: Azureポータル内で、環境全体のコンプライアンス状況を一目で把握できるダッシュボードを利用できます。

こうした機能を利用することで、どのリソースが準拠しているか、どのリソースが違反しているかを可視化し、簡単に把握することができるのです。

Azure RBACとの違い - リソース側の状態を制御

Azure PolicyとAzure RBAC(Role-Based Access Control)は、どちらもAzureリソースを管理するためのツールですが、対象とする領域が異なります。

以下がその主な違いです。

Azure RBAC
誰が何をできるかを制御します。つまり、ユーザーやグループに特定の操作を許可するかどうかの権限を決定します。

例えば、特定のユーザーに仮想マシンを作成したり、リソースグループを削除する権限を与えることができます。
Azure Policy
何がどのように存在するべきかを制御します。つまり、リソースそのものの状態や設定を管理し、組織のルールや規制に従っているかをチェックします。

例えば、「仮想マシンのサイズを特定のタイプに制限」することや、「特定のリージョンでのみリソースを作成できるようにする」など、リソースの構成そのものを制限します。

このように、Azure RBACとAzure Policyは守備範囲が異なるため、両者を組み合わせることで権限管理とリソースの標準化・コンプライアンスを効率的に行うことができるのです。

Azure RBACについては、こちらの記事もご覧ください。
Azure RBACとは？設定手順やカスタムロールをわかりやすく解説！

Azure Policyの仕組み

では、Azure Policyはどのような仕組みになっているのでしょうか。

以下、主要な構成要素とその関係性について説明していきます。

ポリシー定義 - 個々のルール

ポリシー定義とは、Azure Policyの基本的なルールセットを表し、リソースが従うべき条件と、それに対するアクションを指定します。

特定のリソースタイプに適用されるルールを定義: どのリソースタイプ（例えばストレージアカウント、仮想マシンなど）に適用されるかを指定しています。
JSON形式で記述:JSONフォーマットで書かれています。
条件（if）と効果（then）で構成: 特定の条件（if）が満たされるときに、何らかの効果（then）が実行されるという形で記述されます。

以下の例は、すべてのリソースが「Japan East」リージョンでのみ作成されるように制限するポリシーです。

json
{
  "if": {
    "field": "location",
    "notIn": ["japaneast"]
  },
  "then": {
    "effect": "deny"
  }
}

このポリシーでは、もしリソースが「Japan East」以外のリージョンに作成されようとした場合に、その作成を拒否します。

イニシアチブ定義とは？

イニシアチブ定義とは、関連する複数のポリシー定義をまとめたセットで、特定の目的を達成するために作成されます。

特徴は次のとおりです。

関連するポリシーをまとめて管理することで、管理が容易になります。
特定の目的（例：セキュリティ基準の遵守）達成のために必要な一連のポリシーを定義しています。
個別にポリシーを適用するより、関連するポリシーをまとめて割り当てることで、適用や管理が効率化されます。

例えば、セキュリティ基準遵守のためのイニシアチブの中身としては以下が考えられるでしょう。

- ストレージアカウントの暗号化を強制するポリシー 
- すべての仮想マシンのディスクに暗号化を適用することを要求するポリシー
- すべての仮想ネットワークに対して、ネットワークセキュリティグループ（NSG）の適用を強制するポリシー

このように、イニシアチブ定義は、組織が特定の基準（例えば、セキュリティやコンプライアンス）を確実に満たすためのポリシーセットを簡単に適用・管理する手段なのです。

割り当て

割り当てとは、ポリシーやイニシアチブを特定のスコープ（範囲）に適用するプロセスです。その具体的内容は以下のとおりです。

スコープの選択
スコープとは、ポリシーやイニシアチブを適用する範囲のことです。スコープには、サブスクリプション、リソースグループ、個別リソースなどが含まれます。
例えば、特定のサブスクリプション全体にポリシーを適用したり、リソースグループ内のリソースだけに適用することができます。
除外の設定
スコープ内の特定のリソースを、ポリシーやイニシアチブの適用から除外することができます。
パラメータの指定
一部のポリシーやイニシアチブには、ポリシーの適用に関する特定のパラメータ（変数）を指定することが求められます。
例えば、「許可されたリージョンのみでリソースを作成する」というルールがあるポリシーの場合、「リージョン」がパラメータとして指定されます。

割り当てが完了すると、そのスコープ内のリソースが評価され、ポリシーに従わないリソースに対して警告が出たり、修正が強制されたりします。

Azure Policyの使い方

さて、ここからはAzure Policyの実際の使い方を解説していきます。

カスタムポリシーとは

ここでは、カスタムポリシーの作成手順を紹介します。

手順紹介の前にカスタムポリシーとは何かというと、Azure Policyにおいて、ユーザーが独自に定義したルールや要件を適用するためのポリシーです。

下で紹介する組み込みポリシと異なり、カスタムポリシーは組織やプロジェクトの特定の要件に合わせて、柔軟にルールを作成することができます。

カスタムポリシーの作成の流れ

ここでの流れは、以下のようになります。

Azure Portalにログイン
「Policy」サービスに移動
「定義」セクションでポリシーやイニシアチブを作成
「割り当て」セクションで、選択したポリシーやイニシアチブをスコープに割り当て

カスタムポリシーの作成手順

では、ここから具体的手順を紹介します。

Azureポータルにサインイン
Azureポータルにアクセスし、Azureアカウントでサインインします。

Azureポータル画面

ポリシー定義画面

最後に下の[保存]をクリックします。

保存ボタン
①Azure Policyのメイン画面に移動したら、左側のメニューから「割り当て（Assignments）」を選択します。
②画面右上の「ポリシーの割り当て」ボタンをクリックして、新しいポリシー割り当てのウィザードを開きます。

割り当て画面
「ポリシーの割り当て」画面が表示されるので、必要事項を設定します。

ポリシーの割り当て画面
すべての設定が完了したら、「確認および作成」ボタンをクリックし、「作成（Create）」をクリックします。

確認および作成ボタン

これで選択したスコープ内にポリシーが適用され、対象となるリソースの作成や更新に対してポリシーの評価が行われます。

ポリシー定義の構造と基本的な読み方

ここでAzure Policyのポリシー定義のJSON構造についてご説明します。

Azure Policyのポリシー定義のJSON構造は、リソースに適用されるルールを記述するためのスクリプトのようなものです。
主に「if」と「then」のセクションで構成されており、リソースが条件に合致するかどうか、また合致した場合に何をするかを定義します。

ポリシー定義の要素は、以下のとおりです。

properties
ポリシー全体のプロパティ情報が含まれます。
- displayName: ポリシーのわかりやすい表示名。
- description: ポリシーがどのような目的で使われるかの説明。
- policyType: ポリシーの種類（CustomやBuiltInなど）。
- mode: このポリシーがどのリソースに適用されるかを指定。例えば「All」であればすべてのリソースタイプに適用されます。
parameters
ポリシーで使用するパラメータが定義されます。例えば「許可されるリージョン」などをパラメータにできます。
policyRule実際のポリシーのルールを定義します。
- if: このセクションで条件を定義します。例えば、
```
typeが「Microsoft.Storage/storageAccounts」の場合
```
など、リソースの種類やプロパティに応じて条件を指定します。
- then: 条件が満たされた場合のアクションを指定します。よく使われるアクションとしては以下のようなものがあります。
  - deny: リソースの作成や更新を拒否。
  - audit: ポリシー違反のリソースを監査する。
  - modify: リソースを自動的に修正する。

例: 特定リージョン以外でのリソース作成を禁止するポリシー

{
  "properties": {
    "displayName": "許可されたリージョンでのみリソースを作成",
    "description": "指定されたリージョン以外でのリソース作成を禁止する",
    "policyType": "Custom",
    "mode": "All",
    "parameters": {
      "allowedRegions": {
        "type": "Array",
        "metadata": {
          "displayName": "許可されたリージョン",
          "description": "リソース作成が許可されるリージョン"
        }
      }
    },
    "policyRule": {
      "if": {
        "not": {
          "field": "location",
          "in": "[parameters('allowedRegions')]"
        }
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

ifセクションでリージョンの条件をチェックし、合致しない場合はdeny効果を適用します。

組み込みポリシーの活用

Azure Policyには、上記でご紹介したカスタムポリシーのほかに、事前に作成された組み込みポリシーも多数用意されており、すぐに利用できます。特徴は次のとおりです。

ユースケース対応: 事前に設計されたポリシーで、特定の業務やセキュリティにすぐに対応可能。
カスタマイズ可能: 組み込みポリシーは必要に応じてカスタマイズすることができます。
カテゴリ別に整理: セキュリティ、コンプライアンス、コスト管理など、目的別にポリシーが整理されています。

組み込みポリシーを確認するには、Azureポータル画面の「Policy」→「定義」セクションを選ぶと、すべての組み込みポリシーのリストが表示されます。

ポリシーはカテゴリ別に整理されているので、コンプライアンスやセキュリティ関連のポリシーを簡単に見つけることができます。

組み込みポリシーのリスト

Azure Policyの料金

さて、ここでAzure Policyの気になる料金ですが、ポリシー自体の定義や管理には追加コストがかかりません。ただし関連する追加サービスを使用する際に費用がかかる可能性があるため、必要に応じてこれらの要素も考慮する必要があります。

詳細はMicrosoftの公式ドキュメントも参考にしてください。

Azure Policyの活用例

では最後に、Azure Policyの具体的な活用シーンを紹介していきましょう。

リソース作成の制限（特定のリージョンのみ許可など）

上記でもご紹介したように、Azure Policyを使用して、リソースが「Japan East」や「US West」などの特定のリージョンでしか作成できないように制御することができます。

{
  "if": {
    "field": "location",
    "notIn": ["japaneast"]
  },
  "then": {
    "effect": "deny"
  }
}

このポリシー定義では、Azureリソースが「Japan East」以外のリージョンに作成されようとした場合に、そのリソースの作成を拒否します。

こうして、リソースが許可されたリージョンでのみ作成されるように制限でき、法規制や内部方針に準拠したリソース配置が実現するのです。

セキュリティ設定の強制（暗号化の有効化など）

Azure Policyを利用することで、セキュリティに関する設定（暗号化など）を強制し、組織内のすべてのリソースがセキュリティ基準を遵守するように管理できます。

例えば、すべての仮想マシンのディスクが暗号化されていることを強制するポリシーは以下のように設定します：

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
      },
      {
        "field": "Microsoft.Compute/disks/encryptionSettings.enabled",
        "equals": "false"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

このポリシーは、もし仮想マシンのディスク暗号化が無効の場合、そのリソースの作成や更新を拒否します。

コスト管理（特定のサイズの仮想マシンのみ許可など）

Azure Policyは、コスト管理のためにも効果的に活用できます。

例えば、特定の仮想マシンサイズ（例えば、Standard_B1sやStandard_D2_v3など）のみ作成できるように制限するポリシーを作成してみましょう。

ポリシー定義例

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
      },
      {
        "field": "Microsoft.Compute/virtualMachines/sku.name",
        "notIn": ["Standard_B1s", "Standard_D2_v3"]
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

このポリシーでは、仮想マシンのサイズが「Standard_B1s」や「Standard_D2_v3」以外の場合、そのリソースの作成を拒否します。