TL

Cloud Service

Azure Policy

リソースをルールで統制し、準拠状況を継続評価して逸脱を防ぐガバナンスサービス。AWS の Config ルールと SCP を合わせた相当。

中級セキュリティ運用上の優秀性
最終更新: 2026-06-14公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.リソースをルールで評価・強制し、組織のガバナンスを自動で効かせる。
  • 2.監査・拒否・自動修復などの効果で、逸脱を見つけ防ぎ直す。
  • 3.AWS の Config ルールと SCP を合わせた立ち位置に近い。

解決する課題

  • 許可リージョンや許可 SKU を全サブスクリプションで強制したい
  • 必須タグの付与やリソース命名の規約を作成時点で守らせたい
  • パブリック公開ストレージや暗号化なしリソースなど危険な構成を未然に防ぎたい
  • 既存リソースの準拠状況を一覧で可視化し、逸脱を継続的に評価したい
  • 設定漏れ(診断ログ未設定など)を自動で修復したい

主要概念と用語

Azure Policy は「ポリシー定義」「割り当て」「準拠評価」の3層で理解すると整理しやすいです。

  • ポリシー定義(Policy Definition): 評価ルールと効果を JSON で記述したもの。条件(どのリソースに当てはまるか)と effect(当てはまったらどうするか)で構成される
  • イニシアチブ(Initiative / ポリシーセット): 複数のポリシー定義をまとめた束。規制コンプライアンス(CIS / NIST など)の管理セットとして配布される
  • 割り当て(Assignment): 定義またはイニシアチブを、管理グループ・サブスクリプション・リソースグループなどのスコープに適用する操作。除外(exclusion)も指定できる
  • 効果(Effect): 主なものは Audit(準拠状況を記録するだけ)、Deny(非準拠な作成・更新を拒否)、Append / Modify(プロパティを付加・変更)、DeployIfNotExists(不足リソースを自動デプロイ)、AuditIfNotExists、Disabled、Manual など
  • 準拠状態(Compliance State): リソースが準拠か非準拠かの評価結果。ダッシュボードで集計表示される
  • 修復(Remediation)と修復タスク: Modify / DeployIfNotExists の効果で、既存の非準拠リソースを後から直す仕組み。実行にはマネージド ID を使う
  • パラメーター: 定義を再利用可能にするための変数(許可リージョンの一覧などを割り当て時に与える)

仕様・制限・クォータ

  • 評価は作成・更新時(ゲート)と定期評価の両方で走る。新規作成時は Deny がリアルタイムに効き、既存リソースは定期的なスキャンと、割り当て直後のオンデマンド評価で準拠状態が更新される
  • 定期評価には反映までの遅延があるため、割り当て直後に準拠ダッシュボードへ即時反映されるとは限らない
  • スコープは管理グループからリソースまで階層的に効き、上位スコープの割り当ては下位へ継承される
  • 定義・割り当て・パラメーターには数量上限がある(スコープあたりの割り当て数、イニシアチブに含められる定義数など)。具体値は公式ドキュメントを確認すること
  • Deny は新規・変更操作を止めるが、既存の非準拠リソースを自動削除はしない(可視化と修復は別の効果で行う)
  • 対応プロパティはリソースプロバイダーが公開するものに限られ、エイリアス(alias)として参照できる範囲で条件を書く
Deny は既存リソースを消さない

Deny 効果はこれから行われる作成・更新を拒否するためのものです。すでに存在する非準拠リソースは、Deny を割り当てても自動的には削除されません。既存リソースは Audit で可視化し、Modify / DeployIfNotExists と修復タスクで直す、という役割分担を理解しておきましょう。

内部の仕組み

Azure Policy は Azure Resource Manager(ARM)の制御パスに組み込まれた評価エンジンとして動作します。リソースの作成・更新要求が ARM を通過する際に、スコープに割り当てられたポリシー定義の条件と effect が評価されます。

  • ゲート評価: 作成・更新要求が ARM に届いた時点で条件を評価し、Deny なら要求を拒否、Append / Modify ならプロパティを書き換えてから処理を続行する
  • 定期評価: バックグラウンドで既存リソースを走査し、準拠・非準拠を判定して準拠状態を更新する。割り当て直後はオンデマンド評価もトリガーされる
  • 修復: DeployIfNotExists / Modify は割り当てに紐づくマネージド ID を使い、不足している設定やリソース(診断設定など)を自動で展開・修正する
  • 集約: 評価結果は準拠ダッシュボードに集約され、Azure Monitor や Resource Graph から横断的に照会できる

定義は JSON で書かれ、if(条件)と then(効果)を持ちます。条件ではリソースのプロパティをエイリアスで参照し、fieldallOf / anyOf などの論理演算子で組み立てます。

まず Audit、次に Deny へ

本番にいきなり Deny を割り当てると、既存の運用やデプロイが止まる恐れがあります。最初は Audit で影響範囲(非準拠リソースの数)を把握し、関係者と合意してから Deny / Modify へ段階的に切り替えるのが安全です。

設計パターン / ベストプラクティス

  • 管理グループ階層に割り当てて継承を活かす。全社共通ルールは上位の管理グループ、例外はリソースグループの除外で表現する
  • 規制要件はイニシアチブにまとめる。個別定義をバラバラに割り当てず、CIS / NIST などの組み込みイニシアチブや自作のセットで一括管理する
  • パラメーターで定義を再利用可能にする。許可リージョンや許可 SKU の一覧は割り当て時に渡し、定義本体は使い回す
  • 段階的ロールアウト。Audit でベースラインを測り、合意後に Deny へ昇格、設定不足は DeployIfNotExists で自動修復する
  • 必須タグはガバナンスの基盤。Modify でタグを付加し、コスト配分やオーナー特定を自動化する
  • Infrastructure as Code で管理。定義・イニシアチブ・割り当てを Bicep / Terraform で版管理し、レビューと再現性を確保する

運用・監視

  • 準拠ダッシュボードで全体の準拠率を定点観測し、非準拠が増えたら原因スコープを掘り下げる
  • Azure Resource Graph で非準拠リソースをクエリし、レポートやアラートの材料にする
  • 修復タスクの成否を監視する。マネージド ID の権限不足やデプロイ失敗で修復が滞ることがある
  • 割り当て直後は評価遅延を考慮し、即時反映を期待せずオンデマンド評価を回す
  • アクティビティログで Deny による拒否を確認し、正当な操作がブロックされていないかを点検する
  • 関係者には非準拠の通知を仕組み化(Azure Monitor アラートやワークブック)しておく

コスト

Azure Policy 自体の準拠評価・割り当ては基本的に追加料金のかからないガバナンス機能です。ただし、DeployIfNotExists などの修復で実際にデプロイされるリソース(診断設定の送信先となる Log Analytics の取り込みなど)には、それぞれのサービス料金が発生します。コストはポリシー機能そのものより、修復によって作られる下流リソースで決まると考えるとよいでしょう。

項目課金の考え方コスト上の注意
ポリシー評価・割り当てガバナンス機能として追加課金なし評価そのものでは費用は増えにくい
修復で作るリソース展開された各サービスの通常料金診断ログ送信先のログ取り込み量に注意
ゲスト構成・拡張評価対象により別サービス料金が関係する場合あり利用機能ごとに料金体系を確認する

セキュリティ

  • 危険な構成を作成時点で拒否する。パブリック公開や暗号化なしを Deny で止め、攻撃面を縮小する
  • セキュリティベースラインをイニシアチブで強制し、規制コンプライアンスの準拠状況を継続評価する
  • 最小権限の修復 ID。DeployIfNotExists / Modify のマネージド ID には、修復に必要な範囲だけのロールを割り当てる
  • 管理グループでガードレールを統一し、サブスクリプション間の設定ドリフトを防ぐ
  • 例外は除外で明示し、なぜ外したかを版管理の履歴で追えるようにする
アンチパターン

全社ルールをサブスクリプションごとに手作業でコピーして割り当てるのは、設定漏れと不整合の温床です。共通ルールは上位の管理グループに一度だけ割り当てて継承させ、例外は除外で表現してください。また、修復用マネージド ID に広すぎるロール(共同作成者など)を付けるのも避け、必要最小限の権限に絞ります。

Well-Architected の観点

  • セキュリティ: Deny とセキュリティ系イニシアチブで危険な構成を未然に防ぎ、準拠状況を継続評価する。設定ドリフトを抑えるガードレールの中核
  • オペレーショナルエクセレンス: 定義・割り当てを Infrastructure as Code で版管理し、Audit から Deny への段階適用と自動修復で運用負荷を下げる。準拠ダッシュボードで状態を可視化し、改善を継続する

試験で問われるポイント

頻出
  • 効果の使い分け: Audit は記録のみ、Deny は非準拠な作成・更新を拒否、DeployIfNotExists / Modify は既存リソースの自動修復。「既存リソースを直す」のは Deny ではなく DeployIfNotExists / Modify
  • Deny は既存リソースを削除しない。止めるのはこれからの作成・更新だけ
  • スコープと継承: 管理グループに割り当てると配下のサブスクリプションへ継承される。全社ルールは上位スコープへ
  • イニシアチブ: 複数定義の束。規制コンプライアンス(CIS / NIST など)を一括適用するのに使う
  • 修復にはマネージド ID が必要。DeployIfNotExists / Modify の自動修復は割り当ての ID で実行される
  • RBAC との違い: RBAC は「誰が何をできるか(操作の権限)」、Azure Policy は「リソースがどうあるべきか(構成のルール)」を制御する
  • AWS 対応: 構成ルールの評価は Config ルール、組織全体のガードレールは SCP に相当

関連サービス・比較

Azure Policy は「リソース構成のルール化」を担い、操作権限を司る RBAC や、環境を払い出す Blueprints / Landing Zone と組み合わせて使います。AWS では複数サービスにまたがる役割を1つでカバーします。

観点AzureAWS
構成ルールの評価Azure Policy(Audit)Config ルール
組織全体のガードレールAzure Policy(Deny)/ 管理グループSCP(Organizations)
自動修復DeployIfNotExists / ModifyConfig 修復(SSM Automation)
操作の権限制御Azure RBACIAM
準拠状況の集約準拠ダッシュボード / Resource GraphConfig / Security Hub
環境のまとめ払い出し管理グループ / Landing ZoneOrganizations / Control Tower
RBAC と Policy はセットで考える

RBAC は「誰が操作できるか」を、Azure Policy は「リソースがどうあるべきか」を制御します。両者は競合せず補完関係です。たとえば作成権限のあるユーザーでも、許可外リージョンへの作成は Policy の Deny で止められます。

ハンズオン / CLI例

# 組み込みポリシー定義(許可リージョンを制限)を確認する
az policy definition list \
  --query "[?displayName=='Allowed locations'].{name:name, id:id}" -o table

# サブスクリプション スコープに割り当て、許可リージョンを japaneast に限定
az policy assignment create \
  --name allowed-locations \
  --display-name "許可リージョンを japaneast に限定" \
  --policy "e56962a6-4747-49cd-b67b-bf8b01975c4c" \
  --params '{"listOfAllowedLocations":{"value":["japaneast"]}}' \
  --scope "/subscriptions/<SUBSCRIPTION_ID>"

# 割り当てたスコープの準拠状況を集計表示
az policy state summarize \
  --subscription "<SUBSCRIPTION_ID>"

# 非準拠リソースの一覧を確認
az policy state list \
  --filter "complianceState eq 'NonCompliant'" \
  --query "[].{resource:resourceId, policy:policyDefinitionName}" -o table

Azure Service

Azure Policyを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

管理・ガバナンス

比較で見る軸

クラウド: Azure / カテゴリ: 管理・ガバナンス / 難易度: intermediate

導入後に効く点

監査・拒否・自動修復などの効果で、逸脱を見つけ防ぎ直す。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
管理・ガバナンス
難易度
intermediate
関連資格
設計柱
security / operational

判断チェックリスト

  • 自社の用途が「管理・ガバナンス / security」に近いか確認する。
  • 強みである「リソースをルールで評価・強制し、組織のガバナンスを自動で効かせる。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

管理・ガバナンスsecurityoperational