MS_AzurePolicy

Azure Policy

• 戻る
  • グループ・ポリシー
  • Azureの監視と管理
    Azureのアクセス制御と権限
    • Azure Policy
    • Azure Security Center
    • Azure Blueprints

概要

グループ・ポリシーの Azure 版

• 既存のリソースについて、設定内容が適切か否かを評価する
• リソースのプロパティに対する制限（基本は許可、明示的に禁止）。

２つの出来ること。

以下、２つのことができるようになる

• リソース作成・変更を行う際、指定されている設定が適切か否かを確認する
• 既存のリソースについて、設定内容が適切か否かを評価する

RBAC とは、位置付けが異なる。

このため、併用して不適切な設定変更を検知・禁止する。

• RBAC
  リソースに対する操作そのものを制限。基本は禁止、明示的に許可。

• Azure Policy
  リソースのプロパティに対する制限。基本は許可、明示的に禁止。

補足（この対比が本ページの核）: 両者は「誰が」と「何を」で分かれる。

RBAC        : 「誰が」その操作をして良いか      → 既定は拒否（allow-list）
Azure Policy: 「どんな設定の」リソースなら良いか → 既定は許可（deny-list）

したがって、RBAC で権限を持っている人が、
ポリシー違反の設定をしようとしたときに止めるのが Azure Policy である。
「所有者（Owner）だからポリシーを無視できる」わけではない
（ポリシーの割り当て解除権限を持つかどうかは別問題）点が重要。

詳細

Edition

無償版 (Basic)

有償版 (Premium)

移行メモ（正誤）: Azure Policy 自体に Basic / Premium といった
有償エディションは存在しない。ポリシーの定義・割り当て・評価は無償である。
課金が発生するのは、以下のような周辺サービスを併用する場合に限られる。

• ゲスト構成（Guest Configuration）による VM 内部の設定評価
• Defender for Cloud の有償プラン（ポリシーを利用するが課金対象はそちら）

原文執筆時点の何らかの機能区分を指したものと解されるが、
現在の製品体系には該当しないため、上記のとおり訂正する。

定義

• "if" と "then" の組み合わせでポリシーを記述
• 単項目までで、複数の項目の関連チェックは難しい。

if ブロック

以下の組み合わせで記述

• 論理式（not, allOf, anyOf）と
• 条件（equals, notEquals, like, notLike, contains, exists, in, notIn, ...）

then ブロック

deny, audit などを指定

補足（効果 = effect の一覧）: 現在指定できる主な効果は次のとおり。

effect	動作
audit	違反を記録するだけ（まずはこれで様子を見る）
deny	作成・更新そのものを拒否
append / modify	不足しているプロパティ・タグを自動的に付与
deployIfNotExists	不足しているリソース（診断設定など）を自動デプロイ
auditIfNotExists	関連リソースが無い場合に違反として記録
disabled	一時無効化

実務では audit → 影響を確認 → deny に切り替えるという段階適用が定石。
また deployIfNotExists / modify はマネージド ID が必要で、
修復タスク（Remediation）で既存リソースにも適用できる。

定義の例

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
      },
      {
        "field": "Microsoft.Compute/virtualMachines/osDisk.uri",
        "exists": "True"
      }
    ]
  },
  "then": {
    "effect": "audit"
  }
}

注意点

RBAC とは位置付けが異なる

複雑な条件指定はできない

カスタム・ポリシー開発は大変

• 特に "deny"（操作禁止）ポリシーの作成は、開発・デバッグが非常に大変
• 一方で、Azure Security Center のビルトイン・ポリシーの利用は簡単

補足（現在の緩和策）: カスタム ポリシー開発の負担は、
次の 3 つでかなり軽減できるようになっている。

• ビルトイン定義とイニシアチブが大幅に増えた
  （「Azure セキュリティ ベンチマーク」「NIST SP 800-53」等の
  規制コンプライアンス イニシアチブが標準提供される）。
• What-If 相当の確認: 割り当てを audit で入れ、
  コンプライアンス結果から影響範囲を事前に把握できる。
• 除外（exemption）: 例外を認めるリソースを
  期限付きで明示的に除外でき、
  「一部の例外のためにポリシー自体を外す」事態を避けられる。

参考

Microsoft Learn

• Azure Policy のドキュメント
  https://learn.microsoft.com/ja-jp/azure/governance/policy/
• ポリシー定義の構造の詳細
  https://learn.microsoft.com/ja-jp/azure/governance/policy/concepts/definition-structure
• 効果について
  https://learn.microsoft.com/ja-jp/azure/governance/policy/concepts/effect-basics

Azure Security Center

---

Tags: 移行, インフラストラクチャ, クラウド, セキュリティ, Azure