本記事は GitHub Copilot および Microsoft Foundry を活用して作成されています。内容の正確性については各公式ドキュメントをご確認ください。
クラウドのガバナンスを語るうえで避けて通れないのが Azure Policy です。
本記事では「カスタムポリシーは作らず、Built-in（組み込み）ポリシーだけで実用的な統制を始める」ことをゴールに、Azure Policy の基礎から、CAF（クラウド導入フレームワーク）に沿ったカテゴリ設計、そしてよく使う Built-in ポリシーとサンプルパラメータまでをまとめます。
想定読者: これから Azure のガバナンス設計を始める情報システム部門・クラウド基盤担当の方
目次
- 日本のお客様向け Azure Policy 実践ガイド ～Built-in だけで始めるガバナンス～
1. Azure Policy とは
Azure Policy は、Azure リソースが組織のルール（標準・コンプライアンス要件）に準拠しているかを評価・強制するためのサービスです。
ポイントは大きく3つです。
- 自動評価: 「こうあるべき」というルール（ポリシー定義）を JSON で宣言すると、Azure が自動的に評価します。評価は約24時間ごとに再実行されるほか、ポリシー割り当ての作成・更新時や、対象リソースの作成・更新時にもトリガーされます。評価対象は新規作成リソースだけでなく、割り当てスコープ内の既存リソースもすべて含まれるため、ルールを追加すると既存環境の準拠状況も自動的に可視化されます。
-
適用範囲: 管理グループ（MG）→ サブスクリプション → リソースグループ → リソースの階層に割り当てます。上位スコープへの割り当ては下位へ自動的に継承されるため、中間ルート MG に割り当てれば配下の全サブスクリプションへ一括適用できます。一方で、特定のサブスクリプションやリソースグループを評価対象から外したい場合は、割り当て時の除外（exclusion） や、ポリシー定義の
notScopes指定で柔軟に除外できます。 - イニシアティブ（ポリシーセット）: 複数のポリシーを束ねた「イニシアティブ」として一括管理できます（例: 後述の MCSB）。
ガバナンスの基本は「上位の管理グループに Built-in ポリシーを割り当て、組織全体へ継承させる」ことです。Azure Landing Zone（ALZ）も同じ考え方で設計されています。
用語: 本記事では「管理グループ」を MG、「中間ルート MG」を ALZ の最上位（テナントルート直下の組織用ルート）として扱います。
2. 効果（Effect）の種類
Azure Policy の挙動は「効果（Effect）」で決まります。代表的な4つ（＋関連）を押さえれば十分です。
| 効果 | 挙動 | 既存リソース | 新規作成 | 主な用途 |
|---|---|---|---|---|
| Disabled | 割り当てるが評価しない | 影響なし | 影響なし | 一時的な無効化、段階導入の初期値 |
| Audit | 違反を記録するだけ（ブロックしない） | 非準拠としてレポート | 作成は許可 | まず現状把握したいとき |
| Deny | 違反するリソースの作成・更新を拒否 | 既存は変更されない | ブロック | 確実に守らせたいルール |
| DeployIfNotExists (DINE) | 不足している構成を自動展開 | 修復タスクで是正可 | 作成後に自動構成 | 診断設定や Defender の自動有効化 |
補足としてよく出てくる効果:
- AuditIfNotExists (AINE): 関連リソースが存在しない/非準拠なら監査。「NSG が付いていない」等の関連チェックに使用。
- Modify: 作成・更新時にプロパティやタグを追加・変更（例: タグの継承付与）。
Disabled / Audit / Deny / DINE の違いを一言で
- Disabled = 何もしない（評価すらしない）
- Audit = 見張るだけ（止めない）
- Deny = 止める
- DINE = 足りないものを作る
段階導入のセオリー
いきなり Deny で割り当てると既存ワークロードが壊れるリスクがあります。実務では次の順で“締めていく”のが定石です。
Disabled → Audit（現状把握）→ Deny（強制）
補足: 同じポリシー（同一 GUID）を二重に割り当てると効果が衝突します。より厳しい効果（Deny > Audit > Disabled）が優先されるため、二重割り当ては避けましょう。
3. 統制すべきカテゴリ（CAF の定義より）
統制対象は、Microsoft の Cloud Adoption Framework（CAF）の Govern で定義されたカテゴリに沿って整理すると漏れがありません。本記事では以下のカテゴリ ID を使います。
| ID | カテゴリ | 統制の狙い |
|---|---|---|
| RC | Regulatory compliance（規制対応） | データ所在地・許可リージョンなど法令/規制対応 |
| SC | Security（セキュリティ） | ネットワーク露出・暗号化・脅威防御 |
| CM | Cost management（コスト管理） | SKU 制限など無駄なコストの抑制 |
| OP | Operations（運用） | 監視・ログ・アラートの自動化 |
| DG | Data（データ） | 暗号化・転送保護・キー管理 |
| RM | Resource management（リソース管理） | 命名・タグ・リソース種別の統制 |
| ID | Identity（ID） | MFA・特権アカウントの統制 |
重要: Azure Policy “だけ” では完結しない
Azure Policy は強力ですが、万能ではありません。評価できるのは「Azure リソースの構成」に限られます。次のような領域は、専用サービスと組み合わせることで初めて統制が完成します。
| 領域 | Azure Policy の役割 | 組み合わせるべきサービス |
|---|---|---|
| 脅威検知・セキュリティ態勢 | Defender プランの有効化を強制（DINE） | Microsoft Defender for Cloud が検知・スコアリング |
| データガバナンス・分類 | ストレージの暗号化等を強制 | Microsoft Purview がデータ分類・カタログ・DLP |
| ID・アクセス制御 | 特権アカウントの MFA を監査するのみ | Entra 条件付きアクセス / PIM が強制 |
| 運用アラート | アラートルールを展開（DINE） | Azure Monitor（AMBA） が通知・可視化 |
たとえば「全アカウントの MFA 必須化」や「PIM による Just-In-Time 特権昇格」は Azure Policy では強制も監査もできません。これらは Entra ID（条件付きアクセス・PIM）側で構成します。
結論: Policy は“予防と強制”、Defender/Purview/Monitor は“検知と運用” という役割分担で設計しましょう。
4. よく使われる Built-in Policy 一覧とサンプルパラメータ
ここからは実際に割り当てる Built-in ポリシーの一覧です。前提としてカスタムポリシーは使わず、Built-in（と一部 ALZ 標準イニシアティブ）から選定しています。
表の見方:
- MCSB v2 に含まれるか: 〇 = Microsoft cloud security benchmark v2 に内包され、評価（監査）は自動で行われる。ただし Effect を変更できるのはパラメーター化された一部（約 16 個）のみのため、希望の Effect（例: Deny）で強制したい場合は個別割り当てが必要。空白 = 個別追加が必要。
- 効果（Prod / 非Prod）: 本番は厳しめ（Deny）、非本番は緩め（Audit/Disabled）の推奨値。
| CAF ID | カテゴリ | 種別 | 名称（英語） | 名称（日本語） | ポリシーID | MCSB v2 | 効果（Prod / 非Prod） | パラメータ | 推奨スコープ |
|---|---|---|---|---|---|---|---|---|---|
| SC01 | Security | イニシアティブ | Microsoft cloud security benchmark v2 | Microsoft クラウド セキュリティ ベンチマーク v2 | 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 |
〇 | 項目毎 | 各 *Effect
|
中間ルート MG |
| SC02 | Security | イニシアティブ（複数ポリシーの束） | Configure Microsoft Defender for Cloud plans | Microsoft Defender for Cloud プランの構成 |
Configure Microsoft Defender for Cloud plans（組み込みイニシアティブ / MDC_Defender_Full_Plans_DINE） |
DeployIfNotExists | 各 Defender プラン（pricingTier=Standard）・拡張機能の有効化 |
中間ルート MG | |
| RC01 | Regulatory compliance | ポリシー | Allowed locations | 許可される場所 | e56962a6-4747-49cd-b67b-bf8b01975c4c |
Deny / Deny | listOfAllowedLocations=[japaneast,japanwest] |
中間ルート MG | |
| RC02 | Regulatory compliance | ポリシー | Allowed locations for resource groups | リソースグループに許可される場所 | e765b5de-1225-4ba3-bd56-1ac6695af988 |
Deny / Deny | listOfAllowedLocations=[japaneast,japanwest] |
中間ルート MG | |
| SC03 | Security | ポリシー | Network interfaces should not have public IPs | NIC はパブリックIPを持つべきでない | 83a86a26-fd1f-447c-b59d-e51f44264114 |
〇 | Deny / Audit | effect |
中間ルート MG |
| SC04 | Security | ポリシー | Storage accounts should disable public network access | ストレージはパブリックネットワークアクセスを無効化すべき | b2982f36-99f2-4db5-8eff-283140c09693 |
〇 | Deny / Audit | effect |
Prod MG=Deny |
| SC05 | Security | ポリシー | All Internet traffic should be routed via your deployed Azure Firewall | 全インターネットトラフィックは Azure Firewall 経由にすべき | fc5e4038-4584-4632-8c85-c0448d374b2c |
AuditIfNotExists / Disabled | effect |
Landing zones MG | |
| SC06 | Security | ポリシー | Subnets should be associated with a Network Security Group | サブネットは NSG に関連付けるべき | e71308d3-144b-4262-b144-efdc3cc90517 |
〇 | AuditIfNotExists | effect |
中間ルート MG |
| SC07 | Security | ポリシー | Azure DDoS Protection should be enabled | Azure DDoS Protection を有効にすべき | a7aca53f-2ed4-4466-a25e-0b45ade68efd |
〇 | AuditIfNotExists / Disabled | effect |
Prod MG |
| SC08 | Security | ポリシー | Key vaults should have deletion protection enabled | Key Vault は削除保護（purge protection）を有効にすべき | 0b60c0b2-2dc2-4e1c-b5c9-abbed971de53 |
〇 | Deny / Audit | effect |
中間ルート MG |
| SC09 | Security | ポリシー | Network Watcher flow logs should have traffic analytics enabled | NSG フローログを有効にすべき | 27960feb-a23c-4577-8d36-ef8b5f35e0be |
Audit / Disabled | effect |
中間ルート MG | |
| CM01 | Cost management | ポリシー | Allowed virtual machine size SKUs | 許可される VM サイズ SKU | cccc23c7-8427-4f53-ad12-b6a63eb452b3 |
Disabled / Deny | listOfAllowedSKUs=[Standard_D2s_v5,...] |
非Prod/Sandbox MG | |
| OP01 | Operations | イニシアティブ | Deploy Azure Monitor Baseline Alerts (AMBA) | Azure Monitor ベースライン アラートの展開 | AMBA イニシアティブ群 | DeployIfNotExists | Log Analytics ワークスペースID | Platform / Landing zones MG | |
| OP02 | Operations | イニシアティブ（複数ポリシーの束） | Enable allLogs category group resource logging for supported resources to Log Analytics | サポート対象リソースの allLogs ログを Log Analytics へ有効化 | 0884adba-2312-4468-abeb-5422caed1038 |
DeployIfNotExists |
logAnalytics(送信先WS), diagnosticsLogCategoryGroup(audit/allLogs) |
Platform MG | |
| OP03 | Operations | ポリシー | Configure subscriptions to send activity logs to Log Analytics | アクティビティログを Log Analytics へ送信 | 2465583e-4e78-4c15-b6be-a36cbc7c8b0f |
DeployIfNotExists | logAnalytics |
各サブスク | |
| DG01 | Data | ポリシー | Secure transfer to storage accounts should be enabled | ストレージはセキュア転送(HTTPS)を有効にすべき | 404c3081-a854-4457-ae30-26a93ef643f9 |
〇 | Deny / Audit | effect |
中間ルート MG=Deny |
| DG02 | Data | ポリシー | App Service apps should only be accessible over HTTPS | Web アプリは HTTPS のみでアクセス可能にすべき | a4af4a39-4135-47fb-b175-47fbdf85311d |
〇 | Deny / Audit | effect |
中間ルート MG |
| DG03 | Data | ポリシー | Managed disks should be double encrypted | マネージドディスクは二重暗号化(CMK)すべき | 702dd420-7fcc-42c5-afe8-4026edd20fe0 |
〇 | Audit / Disabled | effect |
Prod MG |
| DG04 | Data | ポリシー | Storage accounts should use customer-managed key (CMK) for encryption | ストレージは CMK を使用すべき | 6fac406b-40ca-413b-bf8e-0bf964659c25 |
〇 | Audit / Disabled | effect |
Prod MG |
| DG05 | Data | ポリシー | Storage accounts should have the specified minimum TLS version | ストレージは最小 TLS バージョンを満たすべき | fe83a0eb-a853-422d-aac2-1bffd182c5d0 |
〇 | Deny / Audit | minimumTlsVersion=TLS1_2 |
中間ルート MG |
| RM01 | Resource management | ポリシー | Not allowed resource types | 許可されないリソースの種類 | 6c112d4e-5bc7-47ae-a041-ea2d9dccd749 |
Deny / Deny | listOfResourceTypesNotAllowed |
中間ルート MG | |
| RM02 | Resource management | ポリシー | Require a tag on resources | リソースにタグを必須にする | 871b6d14-10aa-478d-b590-94f262ecfa99 |
Deny / Audit |
tagName（CostCenter/Environment/Owner） |
中間ルート MG | |
| RM03 | Resource management | ポリシー | Inherit a tag from the resource group | リソースグループからタグを継承 | cd3aa116-8754-49c9-a813-ad46512ece54 |
Modify | tagName |
中間ルート MG | |
| ID01 | Identity | ポリシー | Users must authenticate with multi-factor authentication to create or update resources | リソースの作成・更新時にユーザーは多要素認証で認証する必要がある | 4e6c27d5-a6ee-49cf-b2b4-d8fe90fa2b8b |
〇 | Audit | effect |
中間ルート MG |
| ID02 | Identity | ポリシー | A maximum of 3 owners should be designated for your subscription | サブスクリプションのオーナーは最大3名にすべき | 4f11b553-d42e-4e3a-89be-32ca364cad4c |
〇 | AuditIfNotExists | effect |
各サブスク |
| ID03 | Identity | ポリシー | Storage accounts should prevent shared key access | ストレージは共有キー認証を禁止すべき（マネージドID利用） | 8c6a50c6-9ffd-4ae7-986f-5fa6111f9a54 |
〇 | Audit / Deny | effect |
Prod MG |
ID01 の3ポリシー: owner=
e3e008c3-56b9-4133-8fd7-d3347377402a/ write=931e118d-50a1-4457-a5e4-78550e086c52/ read=81b3ccb4-e6e8-4e4a-8d05-5df25cd29fd4
サンプルパラメータセット（許可リージョン: 日本）
RC01 / RC02 を「日本リージョンのみ許可」で割り当てる例です（Azure CLI）。
# 許可リージョンを日本に限定するパラメータ（RC01: Allowed locations）
az policy assignment create \
--name "allowed-locations-japan" \
--display-name "Allowed locations (Japan only)" \
--policy "e56962a6-4747-49cd-b67b-bf8b01975c4c" \
--scope "/providers/Microsoft.Management/managementGroups/<中間ルートMG名>" \
--params '{
"listOfAllowedLocations": { "value": ["japaneast", "japanwest"] }
}'
補足: RC01（Allowed locations）は
globalリージョンのリソース（Front Door・DNS など）を自動的に評価免除するため、listOfAllowedLocationsにglobalを含める必要はありません。RC02（リソースグループ用）とセットで割り当てることで、リソース本体とメタデータの双方を日本リージョンに限定できます。
タグ必須化（RM02）のサンプル:
# CostCenter タグを必須にする（無いと Deny）
az policy assignment create \
--name "require-costcenter-tag" \
--policy "871b6d14-10aa-478d-b590-94f262ecfa99" \
--scope "/providers/Microsoft.Management/managementGroups/<中間ルートMG名>" \
--params '{ "tagName": { "value": "CostCenter" } }'
許可 VM サイズ SKU の制限（CM01）のサンプル:
# 汎用・バースト系の標準サイズのみ許可し、高額な GPU/大型 SKU の乱立を防ぐ
az policy assignment create \
--name "allowed-vm-skus" \
--policy "cccc23c7-8427-4f53-ad12-b6a63eb452b3" \
--scope "/providers/Microsoft.Management/managementGroups/<非Prod/Sandbox MG名>" \
--params '{
"listOfAllowedSKUs": {
"value": [
"Standard_B2s", "Standard_B2ms", "Standard_B4ms",
"Standard_D2s_v5", "Standard_D4s_v5", "Standard_D8s_v5",
"Standard_E4s_v5", "Standard_E8s_v5"
]
}
}'
許可しないリソース種別の制限（RM01）のサンプル:
# 非推奨のクラシックリソースや、誤用・高コストにつながりやすい種別の作成を Deny
az policy assignment create \
--name "not-allowed-resource-types" \
--policy "6c112d4e-5bc7-47ae-a041-ea2d9dccd749" \
--scope "/providers/Microsoft.Management/managementGroups/<中間ルートMG名>" \
--params '{
"listOfResourceTypesNotAllowed": {
"value": [
"Microsoft.ClassicCompute/virtualMachines",
"Microsoft.ClassicStorage/storageAccounts",
"Microsoft.ClassicNetwork/virtualNetworks",
"Microsoft.Compute/galleries/images",
"Microsoft.Network/expressRouteCircuits"
]
}
}'
5. MCSB v2 に含まれる Policy の例
Microsoft cloud security benchmark（MCSB）v2 は、Microsoft Defender for Cloud のセキュリティ標準として提供される組み込みイニシアティブで、414 個の Built-in ポリシーを束ねています（ポリシーID: 1f3afdf9-d0c9-4c3d-847f-89da613e70a8）。割り当て直後の Effect は 大半が Audit／AuditIfNotExists（約 95%） で、リソース作成をブロックする Deny はごく少数（4 件）にとどまります。なお、割り当ての effect パラメーターで変更できるのはパラメーター化された一部（約 16 個）のみで、残りは Effect がイニシアティブ定義に固定（ハードコード）されています。
注意: 本記事執筆時点（2026 年 6 月）で MCSB v2 はプレビュー（Preview） です。本番環境への適用前に最新の提供状況を確認してください。詳細は Microsoft クラウド セキュリティ ベンチマーク v2 の概要（プレビュー） を参照してください。
つまり「MCSB を割り当てておけば、上表で〇が付いたポリシーは評価（監査）が自動で行われる」という点がメリットです。ただし注意点があります。MCSB v2 のイニシアティブ割り当てでは、各ポリシーの Effect を変更できるのはパラメーター化された一部（約 16 個）のみで、残りは Effect がイニシアティブ定義に固定（ハードコード）されています。そのため、特定のポリシーを希望する Effect（例: Deny）で強制したい場合は、その組み込みポリシーを個別に割り当てる必要があります（MCSB 本体の評価はそのまま残ります）。
MCSB v2 に内包される代表例:
| 名称 | ポリシーID | MCSB の主な統制 |
|---|---|---|
| Secure transfer to storage accounts should be enabled | 404c3081-a854-4457-ae30-26a93ef643f9 |
データ保護（転送時の暗号化） |
| App Service apps should only be accessible over HTTPS | a4af4a39-4135-47fb-b175-47fbdf85311d |
データ保護（HTTPS 強制） |
| Subnets should be associated with a Network Security Group | e71308d3-144b-4262-b144-efdc3cc90517 |
ネットワークセキュリティ |
| Accounts with owner permissions should be MFA enabled | e3e008c3-56b9-4133-8fd7-d3347377402a |
特権アクセス管理 |
| A maximum of 3 owners should be designated for your subscription | 4f11b553-d42e-4e3a-89be-32ca364cad4c |
特権アクセス管理 |
ポイント: MCSB は「監視・評価」が主目的。Defender プランの実際の有効化は別途
Deploy-MDFC-Config（SC02）のような DINE イニシアティブで行います。MCSB（評価）と Defender 有効化（強制）は役割が異なる点に注意してください。
MCSB v2 は AI ワークロードも考慮している
MCSB v2 では、近年の生成 AI 利用拡大を踏まえ、AI サービス（Microsoft Foundry など）に関する統制も含まれるようになりました。代表的なものとして、次のような観点があります。
- 利用可能なモデルの制限: デプロイできる AI モデルを許可リストで限定する（例: 承認済みモデルのみデプロイ可能にする）
- ネットワーク分離: AI サービスのパブリックネットワークアクセス無効化・プライベートエンドポイント利用
- データ保護・認証: 顧客管理キー（CMK）による暗号化、ローカル認証の無効化（Entra ID 認証への統一）
ただし注意点として、Azure Policy で制御できるのは「リソース構成レベル」のガードレール（どのモデルを・どのネットワークで・どの認証方式で使えるか）までです。プロンプトインジェクション対策や有害コンテンツのブロックといった実行時の入出力制御は、Azure AI Content Safety（コンテンツフィルター）側で実装すべき領域です。
役割分担: Azure Policy = AI リソースの構成ガードレール（許可モデル・ネットワーク・暗号化）／コンテンツフィルター = 実行時のプロンプト・応答の安全性制御。両者を組み合わせて初めて AI ガバナンスが完成します。
6. AMBA に含まれる Policy（アラート）の例
AMBA（Azure Monitor Baseline Alerts） は、Azure サービスに対する推奨アラートルールをポリシー（DINE）で自動展開するイニシアティブ群です。ALZ では管理グループ階層（Connectivity / Management / Identity / Landing Zone など）ごとに割り当てられます。
AMBA は「ログを集める（OP02）」のではなく「異常を通知する」ための仕組みで、メトリックアラート・アクティビティログアラート・サービス正常性アラートを展開します。代表的に展開されるアラート例:
| 対象 | アラート例 | 種類 |
|---|---|---|
| Virtual Machine | CPU 使用率・利用可能メモリ・OS ディスク IOPS 超過 | メトリックアラート |
| Storage Account | 可用性低下・スロットリング発生 | メトリックアラート |
| Key Vault | リクエスト遅延・可用性低下 | メトリックアラート |
| サブスクリプション全体 | Service Health（計画メンテ・障害・アドバイザリ） | サービス正常性アラート |
| すべてのリソース | リソース削除・ポリシー違反などの操作 | アクティビティログアラート |
補足: AMBA は OSS として GitHub で公開・更新されており、ALZ の既定割り当てに組み込まれています。詳細は Azure Monitor Baseline Alerts を参照してください。
OP01（AMBA）と OP02（診断ログ）の違い
混同しやすいので整理します。
- OP01 = AMBA: 「異常を検知して通知」する（アラート）
- OP02 = 診断ログ: 「リソースログを Log Analytics へ集約」する（ログ転送）
両方を組み合わせて初めて「ログが集まり、異常時に通知が飛ぶ」運用が完成します。
7. まとめ
- Azure Policy は Built-in だけでも実用的なガバナンスが組めます。まずはカスタムを作らず、組み込みとイニシアティブから選定しましょう。
- 効果は Disabled → Audit → Deny の順で段階導入するのが安全です。
- 統制カテゴリは CAF（RC/SC/CM/OP/DG/RM/ID） で整理すると漏れません。
- Policy 単独では完結しない領域（脅威検知・データ分類・ID 強制）は、Defender / Purview / Entra（条件付きアクセス・PIM）/ Azure Monitor（AMBA） と組み合わせて設計します。
- セキュリティ系の多くは MCSB v2 に内包されるため、まず MCSB を割り当て、
effectで締めていくのが効率的です。
そして見逃せないのが、これらのガバナンス機能の多くが無料で使えるという点です。
- Azure Policy 自体は追加料金なしで利用できます。Built-in ポリシーの割り当て・評価・コンプライアンスレポートにサービス課金は発生しません。
- MCSB v2 の割り当て・評価も無料です（Defender for Cloud の Foundational CSPM／無料枠で利用可能）。
- AMBA のイニシアティブ展開そのものも無料です。
つまり、本記事で紹介した「Built-in ポリシー＋ MCSB ＋ AMBA」によるガバナンスの土台は、ほぼコストをかけずに始められるわけです。
ただし注意: Policy が展開・有効化する先のリソースには料金が発生します。たとえば Defender for Cloud の各保護プラン（拡張機能）、AMBA が作成するアラートルール、診断ログの Log Analytics 取り込み・保持などは従量課金の対象です。「ガバナンスの仕組み（Policy）は無料、守る対象や付随リソースは有料」と整理しておくと安心です。
ガバナンスは「一度に完璧」を目指すより、Audit で現状を可視化 → 段階的に Deny へという進め方が現実的です。本記事のテーブルをチェックリストとして活用いただければ幸いです。