Azureのガバナンスとコンプライアンス — Azure Policy・リソースロック・Purview
この章の目次開く
組織でAzureを使うと、必ずこういう問題が起きます。「誰かが高額なVMを勝手に作った」「本番のデータベースをうっかり消しかけた」「どこにどんな機密データがあるのか誰も把握していない」——。
これらを 人の注意力ではなく、仕組みで防ぐ のがガバナンスです。この章では3つの道具、Azure Policy(ルールの強制)、リソースロック(保護)、Microsoft Purview(データの可視化)を学びます。
学習者第9章のRBACで「誰が何をできるか」は制御できるんだよね？それでもまだ足りないの？
先生鋭い質問です。RBACは「誰が操作できるか」の制御ですが、権限を持つ人が「何を作るか」までは制御できません。VM作成権限のある人は高額なVMも作れてしまう。そこで「作ってよいものの条件」を決めるのがAzure Policyです。RBACとPolicyは補完関係にあります。
Azure Policy — 組織のルールをリソースに強制する
Azure Policyは、リソースが従うべきルールを定義し、自動で評価・強制するサービス です。
たとえば、こんなルールを作れます。
- リソースは 日本のリージョンにのみ 作成できる
- 仮想マシンは 特定のサイズのみ 許可する
- すべてのリソースに departmentタグを必須 にする
- ストレージアカウントの パブリックアクセスを禁止 する
ポリシーの働き方
ポリシーは、割り当てたスコープ(管理グループ/サブスクリプション/リソースグループ)配下のリソースに対して2つの働きをします。
- 新規作成のブロック — ルール違反のリソースは、そもそも作成できない(デプロイが拒否される)
- 既存リソースの評価 — すでにあるリソースも継続的にチェックし、非準拠(Non-compliant) として一覧化する
第5章で学んだ階層がここでも効きます。管理グループにポリシーを割り当てれば、配下の全サブスクリプションに一括で強制 されます。
リソースロック — 「うっかり」を仕組みで防ぐ
RBACで権限を持っている人でも、操作ミス はします。本番DBの削除ボタンを押してしまう事故は、権限管理では防げません。
リソースロック は、リソース・リソースグループ・サブスクリプションに「保護」をかける機能で、2種類あります。
| ロックの種類 | 効果 |
|---|---|
| 削除ロック (CanNotDelete) | 読み取り・変更はできるが、削除はできない |
| 読み取り専用ロック (ReadOnly) | 読み取り以外(変更も削除も)できない |
重要な性質が2つあります。
- RBACの権限より優先される — 所有者ロールを持っていても、ロックがある限り削除できない
- ロックを外せば操作できる — つまり防いでいるのは悪意ではなく 「うっかり」。削除するには「まずロックを解除する」というワンクッションが入ることに意味がある
学習者なるほど、スマホの「削除前にもう一度確認」ダイアログの、インフラ版みたいなものか。
先生まさにそれです。試験では「管理者でも誤って削除できないようにしたい → リソースロック」が定番。Azure Policy(作れるものの制限)との役割の違いも整理しておきましょう。Policyは 入口の制御、ロックは 既にあるものの保護 です。
Microsoft Purview — データのガバナンス
3つ目の道具は、リソースではなく データそのもの のガバナンスです。
Microsoft Purviewは、組織中に散らばるデータを検出・分類・可視化する統合データガバナンスサービス です。Azure内だけでなく、オンプレミスや他社クラウド、Microsoft 365のデータも対象にできます。
主な働きは3つです。
- データの検出とカタログ化 — 組織のどこにどんなデータがあるかを自動でスキャンし、検索可能な「データの地図(データカタログ)」を作る
- 機密データの分類 — クレジットカード番号やマイナンバーのような機密情報を自動で識別し、ラベル付けする
- データ系列(リネージ)の可視化 — データがどこから来てどう加工されたかの流れを追跡する
「うちの会社に個人情報はどこにある?」という監査・コンプライアンスの問いに答えるためのサービス、と覚えてください。
3つの道具の使い分け
この章の総まとめとして、「どの問題に、どの道具か」を一枚にします。
| 防ぎたい・知りたいこと | 使う道具 |
|---|---|
| ルール違反のリソースを作らせたくない | Azure Policy |
| 複数のポリシーをまとめて管理したい | イニシアチブ |
| 重要リソースの誤削除・誤変更を防ぎたい | リソースロック |
| 組織のどこにどんな(機密)データがあるか把握したい | Microsoft Purview |
| 操作できる人そのものを制限したい | RBAC(第9章) |
ポータルで試してみよう — リソースロックの効果を体感する
リソースロックは、実際に「削除できない」体験をすると一発で覚えられます。無料で試せます。
- 第5章で作ったリソースグループ(例:
rg-learn)を開く - 左メニューの 「ロック」 をクリックし、「+ 追加」 を選ぶ
- ロック名(例:
lock-test)を付け、種類で 「削除」(CanNotDelete)を選んで保存する - その状態でリソースグループの 「リソース グループの削除」 を実行してみる — ロックが原因でエラーになる ことを確認
- 「ロック」画面に戻ってロックを削除すれば、通常どおり削除できるようになる
「所有者権限があってもロックが優先される」「削除には『まずロックを外す』というワンクッションが入る」——本文の2つのポイントを、自分の手で確かめられます。
まとめ
- Azure Policy は「作ってよいものの条件」を強制する。RBAC(誰が操作できるか)と補完関係
- ポリシーは新規作成をブロックし、既存リソースも 非準拠 として継続評価する。まとめて扱うなら イニシアチブ
- リソースロック は削除ロックと読み取り専用ロックの2種類で、RBACの権限より優先 される
- Microsoft Purview はデータの検出・分類・カタログ化を行うデータガバナンスサービス
- Policyは入口の制御、ロックは既存物の保護、Purviewはデータの可視化——と役割で覚える
次の章では、これらの設定やリソース操作を行うための 管理・デプロイツール(Azure Portal・CLI・ARMテンプレート)を学びます。