Cloud Service
Azure Policy
リソースをルールで統制し、準拠状況を継続評価して逸脱を防ぐガバナンスサービス。AWS の Config ルールと SCP を合わせた相当。
- 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 を割り当てても自動的には削除されません。既存リソースは 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(効果)を持ちます。条件ではリソースのプロパティをエイリアスで参照し、field や allOf / anyOf などの論理演算子で組み立てます。
本番にいきなり 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つでカバーします。
| 観点 | Azure | AWS |
|---|---|---|
| 構成ルールの評価 | Azure Policy(Audit) | Config ルール |
| 組織全体のガードレール | Azure Policy(Deny)/ 管理グループ | SCP(Organizations) |
| 自動修復 | DeployIfNotExists / Modify | Config 修復(SSM Automation) |
| 操作の権限制御 | Azure RBAC | IAM |
| 準拠状況の集約 | 準拠ダッシュボード / Resource Graph | Config / Security Hub |
| 環境のまとめ払い出し | 管理グループ / Landing Zone | Organizations / Control Tower |
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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。