Azure Policyの組み込みポリシーを割り当てる｜リージョン・タグ・SKU制限とCLI実践

Azure

Azure Policyの概念をひととおり学んだあと、多くの人が最初にやりたくなるのが「とりあえず1個、実際に割り当てて動かしてみる」ことだと思います。理屈は分かった、でも本当にAzureがリソースを取り締まってくれるのか、この目で確かめたい——私もまさにそうでした。

ところがいざ公式のクイックスタートを開くと、ポータルの画面遷移とAzure CLIのコマンドが淡々と並んでいて、「どの組み込みポリシーを選べばいいの？」「パラメーターって何を入れるの？」「割り当てたあと、結果はどこで見るの？」といった、初心者がいちばん知りたいところが行間に埋もれがちです。

「組み込みポリシーってたくさんありすぎて、どれを最初に割り当てればいいの？割り当てたあと、ちゃんと効いてるかはどう確認するの？」

この記事では、Azureにあらかじめ用意されている組み込みポリシーをサブスクリプションに割り当てて、コンプライアンス評価を実際に動かすところまでを、ポータルとAzure CLIの両方で手を動かしながら解説します。題材にするのは、実務でいちばんよく使う定番の3つ——許可リージョンの制限、タグの強制、VMサイズ（SKU）の制限です。読み終わるころには、「組み込みポリシーを1つ選んで、範囲を決めて、割り当てて、結果を確認する」という一連の流れが自分の手で回せるようになります。

なお、そもそもAzure Policyの登場人物（定義・イニシアチブ・割り当て）やRBACとの違い、効果（Deny／Audit）の全体像があやふやな方は、先に Azure Policyとは？RBACとの違い・効果・運用の全体像を図解 に目を通しておくと、この記事の一手一手が何をやっているのかスッと入ってきます。本記事はその実務シリーズの1本目、「割り当てハンズオン編」です。

組み込みポリシーを1つ、ポータルから割り当ててみる

まずは最小の一歩として、組み込みポリシーを1つだけサブスクリプションに割り当ててみます。ここで「割り当てたら評価が動きだす」という感触をつかむのが目的です。ハブ記事でも触れたとおり、定義は棚に置いてあるレシピにすぎず、割り当てて初めて調理（評価）が始まります。その”調理開始”のボタンを実際に押してみる、という工程です。

操作の入り口と割り当ての流れ

Azureポータル（portal.azure.com）で上部の検索窓に「ポリシー（Policy）」と打ち込み、Azure Policyの画面を開きます。左メニューの「割り当て（Assignments）」を選び、上部の「ポリシーの割り当て（Assign policy）」をクリックします。ここからウィザードに沿って進めるだけです。設定画面はタブに分かれていますが、初回に意識すべきは実質4か所だけです。

  • スコープ（Scope）… どの範囲に効かせるか。ここでサブスクリプション（必要ならリソースグループまで）を選びます。
  • ポリシー定義（Policy definition）… 割り当てる組み込み定義を選ぶ欄。「…」ボタンから一覧を開き、名前で検索して選びます。
  • パラメーター（Parameters）… 「許可するリージョンはどこか」「必須にするタグ名は何か」といった、そのポリシーに渡す具体的な値。
  • 効果／適用モード… ブロックする（Deny）のか記録だけする（Audit）のか。ポリシーによっては効果を選べたり、適用モードで挙動を弱められたりします。

「スコープでサブスクリプションを指定した」ということは、ハブ記事で説明した継承が効くということです。つまりそのサブスクリプション配下のすべてのリソースグループ・リソースが評価対象になります。狭く試したいなら、スコープでリソースグループまで絞り込めばOKです。学習で初めて触るときは、まずお試し用のリソースグループ1つをスコープにすると、影響範囲が読めて安心です。

割り当てた瞬間に何もかも起きるわけではない

ここで初心者が必ずといっていいほど戸惑うのが、割り当てを作成した直後にコンプライアンス画面を見ても、まだ結果が出ていないことです。これは失敗ではありません。新しく作った割り当ての評価結果が反映されるまでには数分程度かかるのが仕様です。公式にも「コンプライアンス状態が有効になるまで数分かかる」と明記されています。「効いてないのでは？」と焦ってやり直す前に、コーヒーでも淹れて少し待ってから再確認してください。

結果は、Azure Policyの「コンプライアンス（Compliance）」画面で確認します。割り当てごとに「準拠（Compliant）」か「非準拠（Non-compliant）」か、そして非準拠ならどのリソースが何件引っかかっているかが一覧で見えます。これがAzure Policyの”成績表”です。まずはこの画面にたどり着けたら、割り当ての基本操作はクリアです。

定番①：許可リージョンを制限する（Allowed locations）

ここからは、実務で本当によく使う定番ポリシーを具体的に割り当てていきます。まず筆頭がリージョンの制限です。「うっかり海外リージョンにリソースを作ってしまい、データの越境やレイテンシの問題を引き起こす」——これを仕組みで防ぐ、いちばん定番のガードレールですね。

使う組み込み定義は「Allowed locations（許可された場所）」です。ポリシー定義の選択画面で「location」や「場所」で検索すると出てきます。この定義の役割はシンプルで、指定したリージョン以外にリソースを作らせないというものです。

パラメーターで「許可するリージョン」を指定する

この定義を割り当てると、パラメーターのタブで「許可する場所（allowedLocations）」という項目が出てきます。ここでドロップダウンから、許可したいリージョンを選びます。日本国内で運用するなら、たとえば「Japan East（東日本）」「Japan West（西日本）」だけを選んでおく、という具合です。ここで選んだリージョン以外に作られたリソースが「違反」と判定される、という関係です。

この「Allowed locations」の効果はDenyです。つまり割り当てが効いている状態で、許可外のリージョンにVMやストレージを新規作成しようとすると、その作成がその場でブロックされ、エラーになります。試しに割り当て後、あえて許可していないリージョン（たとえばWest US）にリソースグループやリソースを作ろうとしてみると、Policyに弾かれる挙動が体感できます。これが「ガードレールが本当に効いている」瞬間です。

ちなみにリージョン系には「リソースグループの場所を制限する（Allowed locations for resource groups）」という別の定義もあります。リソース本体とリソースグループでは対象が違うので、両方セットで割り当てるのが実務では定番です。

なお、ハブ記事で強調した「いきなり本番でDenyを付けると事故る」という鉄則は、このリージョン制限でも同じです。既存環境にすでに許可外リージョンのリソースがある場合、Denyのまま割り当てると既存リソースの更新操作まで弾かれて混乱することがあります。本番では、まず後述のAuditで現状を見える化してから締めていくのが安全です。

定番②：タグを強制する（Require a tag and its value）

次の定番がタグの強制です。「このリソースは誰の持ち物か（owner）」「どのコストセンターに紐づくか（costCenter）」といった情報をタグで管理しているのに、付け忘れのリソースが増えていくと、コスト按分も棚卸しもぐちゃぐちゃになります。これを仕組みで防ぐのがタグ系ポリシーです。

タグ関連の組み込み定義はいくつかありますが、初心者がまず押さえたいのは次の2つです。役割がはっきり違うので、目的に合わせて選びます。

  • Require a tag and its value on resources… 指定したタグ名とその値が付いていなければ違反（Deny）にする。「envタグが production でなければ拒否」のように、値まで縛りたいとき。
  • Require a tag on resources… 指定したタグ名が付いてさえいればOK（値は問わない）。「とにかくownerタグは必須」のように、存在だけを強制したいとき。

「タグ名だけ必須にしたいのか、値まで固定したいのか」で選ぶ定義が変わる、という点だけ押さえておけば迷いません。

パラメーターにはタグ名（と値）を入れる

たとえば「Require a tag and its value on resources」を割り当てると、パラメーターでタグ名（Tag Name）とタグ値（Tag Value）の入力を求められます。ここに env と production を入れれば、「env=production というタグが付いていないリソースは違反」というルールになります。存在だけ強制したい「Require a tag on resources」なら、入力するのはタグ名だけです。

ここで一つ、実務でつまずきやすい大事な注意点があります。タグ系のDenyポリシーは「新しく作られる・更新されるリソース」に対して効くのが基本で、すでに存在しているリソースにタグを自動で付けてくれるわけではないという点です。「割り当てたのに既存リソースにタグが生えてこない」と悩む人がいますが、それはこのポリシーの仕事ではありません。

既存リソースにタグを自動で補いたい場合は、ハブ記事で触れたModify効果を持つ別の組み込み定義（「タグとその値をリソースに追加する（Add a tag to resources）」など）を使い、修復（Remediation）タスクを実行します。ここは自動修復の話になり一段複雑なので、本記事では「タグ強制のDeny」と「タグ付与のModify」は別物、とだけ区別しておけば十分です。自動修復の詳しい手順は運用編の子記事で扱います。

定番③：VMサイズ（SKU）を制限する（Allowed virtual machine size SKUs）

3つ目の定番はVMサイズの制限です。これはコスト暴走を防ぐガードレールとして非常によく使われます。「検証環境なのに、誰かがうっかり超高性能な巨大VMを立てて、翌月とんでもない請求が来た」——クラウドあるあるの事故ですが、これも仕組みで止められます。

使う組み込み定義は「Allowed virtual machine size SKUs（許可された仮想マシンのサイズSKU）」です。割り当て時のパラメーターで、許可するVMサイズ（SKU）の一覧を選びます。たとえば「Standard_B2s と Standard_D2s_v5 だけ許可」のように指定すると、それ以外のサイズでVMを作ろうとした時点でDenyされ、作成が弾かれます。

ポイントは、選択肢に出てくるSKU一覧が非常に多いことです。全部を吟味する必要はなく、自分たちの環境で使うサイズだけをホワイトリスト方式で選ぶという発想でOKです。「この環境ではこのサイズ帯しか使わせない」と決め打ちできるので、コストの上限を実質的にコントロールできるわけですね。検証用サブスクリプションに小さいSKUだけ許可しておく、というのは鉄板の使い方です。

ここまでの3つ——リージョン・タグ・SKU——は、Azureのガバナンスを始めるときにほぼ必ず最初に検討される”御三家”です。まずはこの3つを割り当てて動かせるようになれば、組み込みポリシー活用の土台は固まったと言っていいでしょう。

Audit（記録だけ）で割り当てて、まず現状を見える化する

ここまで「Deny（ブロック）」を前提に話してきましたが、実務でいちばん大事なのはいきなりDenyにしないことでした。ハブ記事で「Auditで見える化 → 直す → Denyで締める」という段階的移行を鉄則として紹介しましたが、割り当て操作のレベルでは、これを具体的にどう選ぶかが問われます。ここを実践に落とし込んでおきましょう。

やり方は、大きく2通りあります。

  1. 効果パラメーターがAudit／Denyから選べる定義を使う場合… 割り当て時のパラメーターで、効果（effect）をAuditに設定して割り当てます。これで「違反は記録するがブロックはしない」モードで始められます。
  2. 効果がDeny固定の定義を使う場合（「Allowed locations」など）… 割り当ての「適用モード（Enforcement mode）」を「無効（Disabled／DoNotEnforce）」にして割り当てます。これで評価（コンプライアンス判定）は行われるのに、実際のブロックはかからない状態を作れます。

この「適用モードを無効にして割り当てる」テクニックは、初心者が意外と知らない超実用ワザです。Deny固定のポリシーでも、まずは”見張りだけ”の状態で本番に投入し、コンプライアンス画面で違反の全体像を把握できます。違反リソースを直し終えてから、適用モードを「有効」に戻す——これがハブ記事で説明した段階的移行の、実際の手順そのものです。

そして評価結果は、繰り返しになりますがAzure Policyの「コンプライアンス」画面で確認します。非準拠の割り当てをクリックすると、違反しているリソースが一覧化されるので、それを1つずつ潰していく。この”見える化された宿題リスト”を片付ける作業こそが、段階的移行の中身です。

Azure CLIで割り当てる（az policy assignment create）

ポータルは分かりやすい反面、いくつものサブスクリプションに同じポリシーを繰り返し割り当てるとなると、画面をポチポチするのは非効率です。そこで実務ではAzure CLIでの割り当てを覚えておくと、スクリプト化・自動化への道が一気に開けます。公式クイックスタートの流れに沿って、要点を通訳しておきます。

まずはログインとリソースプロバイダーの登録

Azure CLIでログインし、複数サブスクリプションがある場合は対象を選びます。Azure Policyの評価には Microsoft.PolicyInsights というリソースプロバイダーの登録が必要なので、未登録なら登録しておきます（これを忘れると評価がうまく回らないので、地味に大事な前提です）。

az login

# サブスクリプションが複数あるときは対象をセット
az account set --subscription <subscriptionID>

# 評価に必要なプロバイダーを登録
az provider register --namespace Microsoft.PolicyInsights

組み込み定義のID（GUID）を名前から引く

ここがCLIならではのコツです。組み込みポリシーは内部的にGUID（長い英数字のID）で管理されているため、割り当てにはそのIDが要ります。とはいえGUIDを暗記する必要はなく、表示名で検索してIDを取り出すのが定石です。公式クイックスタートの例（マネージドディスクを使わないVMを監査する定義）で書き方を見てみましょう。

# リソースグループのID（＝スコープ）を取得
rgid=$(az group show --resource-group <resourceGroupName> --query id --output tsv)

# 表示名から組み込み定義のIDを引く
definition=$(az policy definition list \
  --query "[?displayName=='Audit VMs that do not use managed disks']".name \
  --output tsv)

この --query "[?displayName=='...']".name の部分が、「一覧の中から表示名が一致する定義の name（＝GUID）だけを取り出す」というJMESPathのフィルターです。ここの表示名を「Allowed locations」や「Allowed virtual machine size SKUs」に差し替えれば、そのまま定番3ポリシーにも応用できます。

割り当てを作成する

定義IDとスコープが揃ったら、いよいよ az policy assignment create で割り当てます。

az policy assignment create \
  --name 'audit-vm-managed-disks' \
  --display-name 'Audit VM managed disks' \
  --scope $rgid \
  --policy $definition \
  --description 'Azure CLI policy assignment to resource group'

各オプションの意味は次のとおりです。

  • --name… 割り当ての内部名（リソースIDに使われる識別子）。あとで参照・削除するときのキーになります。
  • --display-name… ポータルの画面に表示される、人間向けの分かりやすい名前。
  • --scope… どこに効かせるか。ここではリソースグループのIDを渡していますが、サブスクリプションIDを渡せばサブスク全体が対象になります。
  • --policy… 割り当てる組み込み定義（先ほど引いたGUID）を指定。
  • --description… 割り当ての説明。何のための割り当てか後から分かるようにメモを残せます。

リージョン制限やタグ強制のようにパラメーターが必要なポリシーを割り当てるときは、--params オプションでJSON（またはJSONファイル）を渡します。たとえば「Allowed locations」なら、許可リージョンの配列を --params で指定する、という形です。まずはパラメーター不要のシンプルな定義で create の型を体に入れてから、--params 付きに進むと理解が早いです。

非準拠リソースを確認する

割り当てたら、CLIからも評価結果を見られます。ここでも結果が出るまで数分かかる点は同じなので、少し待ってから実行してください。

# 割り当てのIDを取得
policyid=$(az policy assignment show \
  --name "audit-vm-managed-disks" \
  --scope $rgid \
  --query id \
  --output tsv)

# 非準拠（違反）のリソースだけを一覧
az policy state list --resource $policyid --filter "(isCompliant eq false)"

出力の中で complianceState が NonCompliant になっているものが、ルールに違反しているリソースです。ポータルのコンプライアンス画面で見ていた”成績表”を、コマンドラインから引っ張ってきているだけ、というわけですね。片付けが済んだら、割り当ては az policy assignment delete --name "..." --scope $rgid で削除できます。学習で試したものは、忘れずに掃除しておきましょう。

まとめ

この記事では、Azure Policyの組み込みポリシーを割り当てて評価を動かす実践を、定番3ポリシーとCLIまで通して見てきました。要点を振り返っておきます。

  • 割り当ての基本：ポータルの「割り当て」から、スコープ・定義・パラメーター・効果を指定するだけ。割り当てて初めて評価が動き、結果は「コンプライアンス」画面に出る（数分待つ）。
  • 定番①リージョン：Allowed locations でパラメーターに許可リージョンを指定。効果はDenyで、許可外リージョンの作成を弾く。
  • 定番②タグ：値まで縛るなら Require a tag and its value on resources、存在だけなら Require a tag on resources。既存リソースへの自動付与はModify＋修復の別作業。
  • 定番③SKU：Allowed virtual machine size SKUs で使うサイズだけをホワイトリスト指定し、コスト暴走を防ぐ。
  • 段階的移行の実装：本番はいきなりDenyにせず、効果をAuditにするか適用モードを無効にして”見張りだけ”で投入 → 違反を直す → 締める。
  • CLI：az policy definition list で表示名からGUIDを引き、az policy assignment create で割り当て。az policy state list で非準拠を確認。

ここまでできれば、「用意されている組み込みポリシーを使って、組織のルールを実際に効かせる」という実務の第一歩は踏み出せました。次のステップは、組み込みでは表現できない自社独自のルールを、自分でポリシー定義（JSON）として書くフェーズです。そちらは姉妹記事で扱います。

あわせて読みたい：

タイトルとURLをコピーしました