第 3 章 Azure ID とガバナンスを管理する（20〜25%）
サブスクリプションとガバナンス
この章で学ぶこと
- Azure Policy を実装して管理する
- リソース ロックを構成する
- リソースに対するタグの適用と管理
- リソース グループの管理
- サブスクリプションの管理
この章に出てくる用語
- Azure Policy
- 「どういう構成のリソースを許すか」を組織のルールとして定め、違反を止めたり記録したりするサービス。 たとえば「タグが無いリソースは作らせない」「指定したリージョン以外には作らせない」といったルールを書いて、スコープ（管理グループやサブスクリプション）に割り当てる。RBAC が「誰が」を見るのに対し、Policy は「何を」を見る。
- Microsoft Cost Management
- 実際にかかった料金を集計・分析し、予算としきい値アラートを設定するサービス。 サブスクリプションやリソースグループ、タグの単位で「どこにいくらかかったか」を出せる。料金は Azure が自動で記録しているので、使うのに事前の構成は要らない。
この 3 つは「制限する仕組み」という点で似ているが、制限している対象が違う。問題文が何を止めたいのかを読み取れば、迷わない。
3 つは重ねて効く。RBAC で共同作成者を持っていても、Policy が「米国リージョンには作らせない」と言えば作れない。さらにロックが掛かっていれば、所有者であっても削除できない。
試験では
リソースロックは RBAC より強い。所有者でも CanNotDelete が掛かったリソースは消せない。ロックを外すには Microsoft.Authorization/locks/* の権限が別途必要で、所有者とユーザーアクセス管理者だけが既定で持っている。
ポリシー定義は条件と効果（effect）を 1 つずつ持つ。効果が何をするかと、どの順で評価されるかが問われる。
| 効果 | すること | こう聞かれたら選ぶ |
|---|---|---|
| deny | 条件に一致する作成・更新をブロックする | 「作らせたくない」 |
| audit | 違反を記録するだけ。作成は許す | 「まず現状を把握したい」 |
| append / modify | 要求にフィールドやタグを追加・変更する | 「タグを自動で付けたい」 |
| deployIfNotExists | 足りないリソースを自動でデプロイして是正する | 「自動で直したい」（マネージド ID が必要） |
| auditIfNotExists | 関連リソースが無い場合に非準拠として記録する | 「設定漏れを洗い出したい」 |
| disabled | そのポリシーを一時的に効かせない | 「一旦止めたい」 |
順序で押さえるのは 2 点だけでいい。append / modify は deny より先に評価されるので、「タグを自動で付けてから、タグが無いものを拒否する」という組み合わせが成立する。そしてdeny は audit より先に評価される。拒否したものを重ねて記録しないためだ。
既存のリソースはどうなるか
ここが実務でも試験でも効く。ポリシーは既定では新規作成と更新のときに評価される。割り当てた瞬間に、既にある違反リソースが直るわけではない。
試験では
「ポリシーを割り当てたのに既存のリソースが直らない」→ 修復タスク（Remediation）を実行する。修復タスクが使えるのは deployIfNotExists と modify の 2 つの効果に限られる。
補足
複数のポリシー定義をまとめたものをイニシアティブ（ポリシーセット）と呼ぶ。「セキュリティ基準を一括で適用したい」といった場合は、ポリシーを 1 つずつ割り当てるのではなくイニシアティブを割り当てる。
# ポリシーを割り当てる （PowerShell: New-AzPolicyAssignment）
az policy assignment create --name tagpolicy \
--policy <ポリシー定義ID> --scope <スコープ>
# 準拠していないリソースを一覧する
az policy state list --filter "complianceState eq 'NonCompliant'"誤削除・誤変更を防ぐための仕組みで、種類は 2 つしかない。親スコープのロックは子に継承される。
| 種類 | 読み取り | 変更 | 削除 | 使いどころ |
|---|---|---|---|---|
| CanNotDelete | ○ | ○ | × | 本番リソースの誤削除を防ぐ。最もよく使う |
| ReadOnly | ○ | × | × | 構成を凍結する。強いので副作用に注意 |
試験では
ReadOnly は思わぬところで効く。たとえばストレージアカウントに ReadOnly を掛けると、ポータルでキーを一覧する操作まで失敗することがある（キーの取得が書き込み扱いのため）。「ロックを掛けたら操作ができなくなった」という設問はこの性質を突いている。
タグは名前と値のペアで、コストの分類やリソースの整理に使う。1 リソースあたり最大 50 個。
試験では
リソースグループに付けたタグは、中のリソースには付かない。継承させたいなら Azure Policy の modify 効果を使う。「コスト分析で部署別に集計したいのにリソースにタグが無い」という筋書きの答えはこれ。
リソースグループはリソースをまとめる論理的な入れ物だ。押さえるべき性質は 4 つ。
- 入れ子にできない。 リソースグループの中にリソースグループは作れない
- 1 つのリソースは 1 つのリソースグループにしか属せない
- 削除すると中身もすべて消える
- リソースグループのリージョンはメタデータの保存先であり、中のリソースは別リージョンでもよい
リソースの移動
リソースは別のリソースグループやサブスクリプションへ移動できる。移動中は対象がロックされ、またすべてのリソースが移動に対応しているわけではない。
試験では
移動してもリージョンは変わらない。 リソースグループを東日本から西日本へ「移した」つもりでも、中の VM は東日本のままだ。リージョンを変えるには作り直すか、Azure Resource Mover を使う。
管理グループ
複数のサブスクリプションをまとめ、ポリシーやアクセス制御を一括適用するための階層。リソースグループと違い、入れ子にできる。最上位はルート管理グループで、テナントに 1 つだけ存在する。
試験では
「全社のすべてのサブスクリプションに同じポリシーを適用したい」→ ルート管理グループに割り当てる。サブスクリプションごとに割り当てる選択肢は手間が増えるだけで誤り。
# リソースグループを作る （PowerShell: New-AzResourceGroup）
az group create --name rg-prod --location japaneast
# リソースを移動する （PowerShell: Move-AzResource）
az resource move --destination-group rg-new \
--ids <リソースID>
# ロックを掛ける （PowerShell: New-AzResourceLock）
az lock create --name nodelete \
--lock-type CanNotDelete --resource-group rg-prod
# タグを付ける （PowerShell: Update-AzTag）
az tag update --resource-id <ID> \
--operation merge --tags env=prodMicrosoft Cost Management で、実際にかかったコストの分析、予算の設定、しきい値を超えたときのアラートを行う。
試験では
予算を超えてもリソースは自動停止しない。 通知が飛ぶだけだ。本当に止めたければ、アラートのアクショングループからAutomation Runbook や Logic Apps を呼び出して自分で止める必要がある。「予算を設定すれば使いすぎを防げる」という選択肢は誤り。
Azure Advisor は、稼働中のリソースを見て改善を推奨してくれる機能だ。推奨は 5 つの観点（柱）に分かれていて、この 5 つの名前がそのまま問われる。
- 信頼性（Reliability）
- セキュリティ（Security）
- パフォーマンス（Performance）
- コスト（Cost）
- オペレーショナルエクセレンス（Operational Excellence）
補足
コストを下げる具体策として Advisor がよく挙げるのは、使われていない VM の停止、サイズの見直し、そして予約インスタンス（Reserved VM Instances）の購入だ。1 年または 3 年の利用を約束するかわりに単価が下がる。
この章のまとめ
- 「誰が操作できるか」を決めるもの
- 「どんな構成を許すか」を決めるもの
- 所有者でも削除できなくする仕組み
- タグを自動で付けたいときのポリシー効果
- 足りないリソースを自動で作って是正する効果と、その必須条件
- deny と audit はどちらが先に評価されるか