Azure RBACの最小権限設計と運用｜スコープ継承・PIM・マネージドID・アクセスレビュー

Azure RBACのロール割り当てに慣れてくると、次にぶつかるのが「で、誰にどこまで権限を配ればいいの？」という設計の問題です。とりあえず動かしたいから所有者（Owner）を配ってしまう——気持ちはよく分かります。私も学びはじめの頃は、権限エラーが出るたびにOwnerを付けて解決した気になっていました。でもそれ、実務ではいちばんやってはいけない配り方なんですね。

この記事は、Azure RBACシリーズの締めくくりとして、最小権限（Least Privilege）で安全に設計・運用するための考え方をまとめます。具体的には、スコープの継承、拒否割り当てとPIM（時間制限付きの特権）、マネージドIDへのロール割り当て、そしてアクセスレビューと監査の4本柱。公式のMicrosoft Learnは正確ですが用語が硬いので、つまずきどころを日本語で噛み砕いていきます。読み終わるころには、「Ownerを配りすぎず、スコープを絞って渡す」設計判断が自分でできるようになります。

「割り当てのやり方は分かった。でも、権限を配りすぎない”ちょうどいい設計”ってどうやるの？」

なお、そもそもRBACの3要素（プリンシパル・ロール定義・スコープ）や組み込みロールがあやふやな方は、先に 【初心者向け】Azure RBACとは？ロール割り当ての3要素と組み込みロールを実務目線で解説 に目を通しておくと、この記事の位置づけがはっきりします。本記事はそのハブの子記事で、割り当ての基本操作やカスタムロールの作り方は姉妹記事の「ロールの割り当てとカスタムロール」に譲り、ここでは設計と運用に集中します。

スコープの継承と最小権限の設計

最小権限の設計は、まずスコープ（権限が効く範囲）の継承を理解するところから始まります。ここを押さえないと、「思ったより広い範囲に権限が届いてしまった」という事故が起きます。

Azureのスコープはマンションのマスターキーにたとえると分かりやすいです。上から順に、管理グループ（建物全体）→サブスクリプション（各フロア）→リソースグループ（部屋の集まり）→個々のリソース（一つの部屋）という入れ子構造になっています。ここで大事なルールは一つ。上位スコープで付けた権限は、その配下すべてに自動的に継承されるということです。

つまり、サブスクリプションのスコープで「共同作成者（Contributor）」を付けると、その下にあるすべてのリソースグループ・すべてのリソースに共同作成者権限が届きます。フロアのマスターキーを渡せば、そのフロアの全部屋に入れてしまう、というイメージですね。便利な反面、これが配りすぎの温床になります。「このアプリの1リソースだけ触ってほしい」人に、うっかりサブスクリプションスコープで権限を付けてしまうと、関係ない他チームのリソースまで触れる状態になってしまうわけです。

設計の原則：必要な最小の範囲・最小の役割で渡す

そこで最小権限の設計です。原則はシンプルで、「その人・そのシステムが仕事を完了するのに必要な、いちばん狭いスコープ・いちばん弱いロール」を選ぶということ。判断の順番はこうです。

まずスコープを絞れないかを考えます。サブスクリプション全体ではなく、対象のリソースグループ、さらに言えば単一リソースで足りないか。ある開発者がWebアプリ用のApp Serviceだけ触るなら、そのApp Serviceを含むリソースグループのスコープで十分なはずです。次にロールを弱められないか。見るだけでいいなら閲覧者（Reader）、作って直す必要があるなら共同作成者、といった具合に、Ownerや広い権限は「本当にそれが要るとき」まで取っておきます。

合言葉は「狭いスコープ・弱いロール」。困ったら上に付けたくなりますが、そこをこらえるのが設計です。

特に注意したいのがユーザーアクセス管理者（User Access Administrator）とOwnerです。この2つは「他人に権限を割り当てる権限」を持っています。つまりOwnerを渡した相手は、そこから先、自分でどんどん権限を配れてしまう。権限が芋づる式に増える起点になりやすいので、この2ロールは本当に管理を任せる少数の人だけにとどめ、しかもできるだけ狭いスコープで渡すのが鉄則です。公式でも詳しくは スコープの概要 にまとまっています。

拒否割り当てとPIM：許可を絞り込む2つの仕組み

スコープとロールで「許可」を最小にしても、それだけでは守りきれない場面があります。そこで登場するのが拒否割り当てとPIMです。この2つは方向性が違うので、分けて理解しておきましょう。

拒否割り当て：許可より「拒否」が優先される

RBACの基本は「許可の積み上げ」です。あるスコープで共同作成者を付ければ、そのスコープでできることが増えていく。ところが、Azureには拒否割り当て（Deny assignments）という逆向きの仕組みもあります。これは特定のアクションを明示的に禁止するもので、重要なルールが一つあります。拒否は許可より常に優先されるということです。

たとえば、あるユーザーにOwner（何でもできる）が付いていても、同じスコープに「このリソースの削除を拒否」という拒否割り当てがあれば、そのユーザーは削除できません。会社にたとえるなら、社長（Owner）であっても「この金庫だけは開けてはいけない」という張り紙（拒否）が勝つ、というイメージです。

ここで初心者がつまずくのが、拒否割り当ては自分では作れないという点です。ポータルで「拒否を追加」というボタンを探しても見つかりません。拒否割り当ては、Azure BlueprintsやマネージドアプリケーションといったAzure側の仕組みが、リソースを守るために自動で設定するものだからです。私も最初、公式ドキュメントを読んで「じゃあどこで設定するの？」と画面をさまよいました。ここは「拒否割り当てという概念があって、許可より強い。ただし手動作成は基本できない」と理解しておけば十分です。詳細は 拒否割り当ての解説 にあります。

PIM：特権を「常時」ではなく「必要なときだけ」

もう一つの武器がPIM（Privileged Identity Management／特権ID管理）です。これは最小権限を時間軸で実現する考え方だと思ってください。

従来のやり方だと、管理者はOwnerをずっと持ちっぱなしです。しかし、その人が実際にOwner権限を使う瞬間は、月に数回あるかどうか。残りの時間、強い権限を握っているのはリスクでしかありません。アカウントが乗っ取られたら、その強い権限がそのまま攻撃者の手に渡ってしまうからです。

PIMは、この特権を「割り当て済み（Active）」ではなく「対象（Eligible）」にしておく仕組みです。ふだんは権限がオフの状態で、必要になったら本人がアクティブ化（有効化）を申請し、承認やMFAを経て、数時間だけその権限が有効になる。時間が過ぎれば自動的に元のオフに戻ります。マンションの例えで言えば、マスターキーを常に持ち歩くのではなく、必要なときだけ管理人に申請して一時貸出のキーを借り、返却期限が来たら自動で失効する、というイメージです。

これにより「強い権限を持てる資格はあるが、ふだんは持っていない」状態が作れます。攻撃者に狙われる時間窓が劇的に短くなり、しかもアクティブ化の履歴が残るので「誰がいつ特権を使ったか」も追えます。なおPIMはMicrosoft Entra ID P2ライセンスが必要な有償機能です。学習で試すなら評価版テナントで触れます。「拒否＝空間的に禁止」「PIM＝時間的に制限」と対にして覚えておくと整理しやすいです。

マネージドIDへのロール割り当て：シークレットを消す

ここまでは「人」への権限の話でした。でも実務では、アプリやサービスがAzureのリソースにアクセスする場面のほうがむしろ多い。たとえば、App ServiceからStorageやKey Vaultを読みにいく、といったケースです。ここで最小権限を語るうえで欠かせないのがマネージドID（Managed Identity）です。

なぜマネージドIDが最小権限に効くのか

昔ながらのやり方だと、アプリがStorageに接続するには接続文字列やアクセスキー（シークレット）をアプリの設定やコードに書き込む必要がありました。これが厄介で、シークレットは漏れる・使い回される・更新を忘れるの三重苦。GitHubにうっかり接続文字列を上げてしまう事故は、いまだに後を絶ちません。

マネージドIDは、このシークレットそのものをなくす仕組みです。App ServiceやVMといったAzureリソースに「システム割り当てマネージドID」を有効にすると、そのリソース自身がEntra IDの中に一つのアイデンティティ（プリンシパル）を持ちます。社員でいうと、アプリに専用の社員証が発行されるようなものです。そして、この社員証（マネージドID）に対してRBACのロールを割り当てると、アプリはパスワードを一切持たずに、必要なリソースへアクセスできるようになります。認証トークンの取得と更新はAzureが裏で自動的にやってくれるので、開発者はシークレットの管理から解放されます。

割り当ての流れ

操作自体は、人にロールを割り当てるのとほとんど同じです。対象リソース（たとえばStorageアカウント）の「アクセス制御（IAM）」を開き、「ロールの割り当ての追加」で、プリンシパルの種類として「マネージドID」を選ぶだけ。あとは対象のApp ServiceやVMのマネージドIDを検索して指定します。CLIならこんな形になります。

# App ServiceのマネージドIDに、対象Storageの「閲覧者」だけを付ける例
az role assignment create \
  --assignee-object-id <マネージドIDのオブジェクトID> \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" \
  --scope <対象Storageのリソーススコープ>

各項目を補足しておきます。

• --assignee-object-id：割り当て先のマネージドIDのオブジェクトID。対象リソースの「ID」メニューから確認できます。
• --assignee-principal-type ServicePrincipal：マネージドIDはサービスプリンシパルとして扱われるため、これを指定するとエラーになりにくいです。
• --role：ここが最小権限の肝。「Storageを読むだけ」ならStorage Blob Data Readerのように、Ownerや広いロールではなく用途に特化した細かいロールを選びます。
• --scope：付ける範囲。サブスクリプション全体ではなく、そのStorageアカウント単位まで絞るのが理想です。

ポイントは、マネージドIDを使うと最小権限が徹底しやすくなることです。人と違って「あれもこれも触るかも」という曖昧さがなく、そのアプリがやることは決まっています。だから「このアプリはこのStorageを読むだけ」とスコープもロールもピンポイントで絞れる。シークレットを消せるうえに権限も絞れるので、まさに最小権限設計のお手本になります。仕組みの全体像は マネージドIDの概要 が詳しいです。

アクセスレビューと監査：配った権限を棚卸しする

最後は運用の話です。どれだけ丁寧に最小権限で設計しても、時間が経つと権限は必ず溜まっていきます。異動した人の古い権限、終わったプロジェクト用の割り当て、テストで付けたまま外し忘れたOwner——こうした「掃除されない権限」が、いつの間にかセキュリティの穴になります。設計しっぱなしにせず、定期的に見直す仕組みが要るわけです。

アクセスレビュー：定期的な棚卸しを自動化する

アクセスレビュー（Access Reviews）は、Entra IDのガバナンス機能で、「この権限、まだ必要ですか？」を定期的に確認するプロセスを自動化する仕組みです。会社の「棚卸し」を思い浮かべると分かりやすい。半年に一度、在庫を数えて要らないものを処分するのと同じことを、権限に対してやるわけです。

たとえば「あるグループのメンバー全員に、3か月ごとにアクセスが必要か確認する」というレビューを設定すると、期限が来るたびにレビュー担当者（本人やその上司、リソース管理者など）に確認依頼が飛びます。担当者は一覧を見て「この人はもう不要」と判断すれば、その場でチェックを外す。設定によっては、期限までに応答がなかった権限を自動で剥奪することもできます。手作業で全員の権限を追いかけるのは現実的に無理なので、この「聞いて回る」部分を仕組みに任せられるのが大きい。詳しくは アクセスレビューの概要 にまとまっています。なお、これもEntra ID P2相当のガバナンス機能である点は押さえておいてください。

監査：アクティビティログで「誰が何をしたか」を追う

棚卸しと並んで大事なのが監査（Audit）です。「いつ・誰が・どの権限を割り当てたか／変更したか」を後から追えるようにしておく。ここで使うのがアクティビティログ（Activity Log）です。

Azureポータルで対象リソースやサブスクリプションの「アクティビティログ」を開くと、操作の履歴が時系列で並んでいます。ロール割り当てを追いたいときは、操作名で絞り込みます。CLIならこんな具合です。

# 直近のロール割り当て作成イベントを拾う例
az monitor activity-log list \
  --offset 7d \
  --query "[?contains(operationName.value, 'roleAssignments/write')].{time:eventTimestamp, caller:caller, resource:resourceId}" \
  --output table

• --offset 7d：さかのぼる期間。ここでは直近7日間。
• roleAssignments/write：ロール割り当ての「作成・変更」を表す操作名。これで絞ると権限まわりの動きだけ抽出できます。
• caller：その操作を行った人（誰が付けたか）。監査でいちばん見たい情報です。

注意点として、アクティビティログの標準の保持期間は90日です。それより長く残したい、あるいは横断的に分析・アラートを組みたい場合は、診断設定（Diagnostic settings）でログをLog Analyticsワークスペースやストレージに流し込んでおく必要があります。「監査で見返そうとしたらログが消えていた」は、実務で本当に起きるつまずきなので、重要な環境では最初にログの転送先を決めておくと安心です。

まとめ：RBACを安全に設計・運用できる状態へ

Azure RBACシリーズの締めとして、最小権限で設計・運用するための4本柱を見てきました。要点を振り返ります。

• スコープ継承と最小権限：上位スコープの権限は配下すべてに継承される。だからこそ「狭いスコープ・弱いロール」で渡すのが原則。OwnerやUAAは配りすぎない。
• 拒否割り当てとPIM：拒否は許可より優先される（空間的な制限）。PIMは特権を常時ではなく必要なときだけ有効化する（時間的な制限）。
• マネージドID：アプリ専用のアイデンティティにロールを割り当て、シークレットをなくす。用途が決まっているので最小権限を徹底しやすい。
• アクセスレビューと監査：溜まった権限を定期的に棚卸しし、アクティビティログで「誰がいつ権限を変えたか」を追える状態にしておく。

ここまで来れば、あなたは「とりあえずOwner」から卒業して、必要な範囲・必要な役割・必要な期間だけを渡し、配ったあとも棚卸しできる状態です。これがRBACを安全に設計・運用するということ。RBACシリーズの概要（ハブ）→割り当ての実務→そして本記事の設計・運用まで押さえれば、Azureの権限管理はひととおり自分の武器になっているはずです。

あわせて読みたい：

• 【初心者向け】Azure RBACとは？ロール割り当ての3要素と組み込みロールを実務目線で解説（このシリーズの親記事・全体像）
• ロールの割り当てとカスタムロール（ポータル・CLIでの実際の割り当て手順と、組み込みロールで足りないときのカスタムロールの作り方）