Azure環境で「誰かがユーザーのロールを変更した瞬間」に気づけないと、権限昇格や設定改ざんが長時間見逃されるリスクがあります。この記事では、Azure Monitor（監視）を使ったRBACロール変更のアラート設定と、Microsoft Entra ID（旧Azure AD）の管理者ロール（例：グローバル管理者）変更をPIMや監査ログで検知して通知する方法を、実務で迷わない手順と設計のコツまでまとめて解説します。
なぜ「ロール変更の通知」が重要なのか
ロール（権限）の変更は、クラウド運用における“最重要イベント”のひとつです。とくに管理者系ロールは、付与された瞬間から次のような影響が出ます。
- 権限昇格（Privilege Escalation）：本来できない操作（リソース削除、鍵の閲覧、ポリシー無効化等）が可能になる
- 痕跡の消去：監査ログ設定の変更、アラート無効化、ログ保管先の削除などをされる可能性
- 横展開：他サブスクリプションや他環境へのアクセスを足がかりにされる可能性
そのため「変更を検知してすぐ通知する」ことは、ゼロトラストや最小権限の考え方とも相性がよく、セキュリティ監査の観点でも効果が高い対策です。
まず整理：監視したい「ロール」は2種類ある
質問で例に出ている「グローバル管理者」は、AzureのサブスクリプションRBACではなく、Microsoft Entra IDの“ディレクトリ ロール（管理者ロール）”です。ここを混同すると「Azure Monitorで設定したのに通知が来ない」という事故が起きやすいので、最初に切り分けます。
| 種類 | 対象 | 代表例 | 主なログ | おすすめの通知手段 |
|---|---|---|---|---|
| Azure RBAC ロール | Azureリソース（サブスクリプション/リソースグループ/リソース） | 所有者、共同作成者、閲覧者、ユーザーアクセス管理者 | Azure Activity Log（アクティビティログ） | Azure Monitorのアクティビティログ アラート（＋必要ならLog Analyticsで高度化） |
| Entra ID 管理者ロール | テナント（ID管理、条件付きアクセス、管理者操作） | グローバル管理者、特権ロール管理者、ユーザー管理者 | Entra 監査ログ（Audit logs） | PIMの通知／監査ログ→Log Analytics→Azure Monitorのログ アラート |
結論として、「Azure RBACのロール変更」と「Entra IDの管理者ロール変更」は、監視の仕組みを分けて設計するのが最短・最確実です。
全体像：おすすめの監視設計（最小構成〜堅牢構成）
運用負荷と検知精度のバランスを考えると、次の組み合わせが現実的です。
| やりたいこと | 最小構成（すぐできる） | 堅牢構成（おすすめ） |
|---|---|---|
| Azure RBACのロール付与/変更/剥奪を通知したい | Azure Monitor（アクティビティログ アラート） | アクティビティログ→Log Analytics→KQLで精密フィルタ→ログ アラート |
| グローバル管理者など特権ロールの割り当て変更を通知したい | PIMの通知（追加受信者を設定） | 監査ログ→Log Analytics→KQLで変更内容を抽出→ログ アラート（＋PIM通知） |
| Teams等へ通知し、インシデント運用に繋げたい | アクション グループ（メール中心） | アクション グループ→Webhook/Logic Apps→Teamsへ整形通知＋チケット連携 |
Azure MonitorでRBACロール割り当ての変更を検知する
検知できるイベント（アクティビティログ）
Azure RBACの変更は、多くの場合アクティビティログ（Activity Log）に記録されます。アラート条件として狙う代表的な操作は以下です。
| 狙う操作 | 意味 | 運用上のポイント |
|---|---|---|
| roleAssignments/write | ロール割り当ての作成/更新（付与・変更） | 最優先で通知対象。誰に何のロールを付けたかを必ず確認できる設計にする |
| roleAssignments/delete | ロール割り当ての削除（剥奪） | 不正対策だけでなく、誤操作の早期発見にも有効 |
| roleDefinitions/write（必要に応じて） | カスタムロール定義の作成/更新 | カスタムロールの権限追加は“静かな権限昇格”になりやすい |
「グローバル管理者を別の管理者ロールに変更」という話はEntra ID側の事象ですが、Azureリソース上の権限（所有者など）も同時に監視しておくと、侵害時に横展開の兆候を早く掴めます。
基本：Azureポータルでアクティビティログ アラートを作る手順
ここでは、最短で実装できるAzure Monitorのアクティビティログ アラートを作成します。画面構成は更新されることがありますが、流れはほぼ共通です。
- Azureポータルにサインイン
- 左メニュー（または検索）から「Monitor（監視）」を開く
- 「Alerts（アラート）」を選択し、「Create」→「Alert rule（アラート ルール）」を作成
- Scope（スコープ）で監視対象を選ぶ
- サブスクリプション全体で監視するのが基本（抜け漏れを防ぐ）
- 運用要件により、特定リソースグループ単位に分けることも可能
- Condition（条件）で「Activity Log」系のシグナルを選び、以下を設定
- Event category：Administrative（管理）を中心に確認
- Operation name：roleAssignments/write（まずはこれ）
- 必要なら roleAssignments/delete も別ルールで作成（重要度を分ける）
- Actions（アクション）でAction group（アクション グループ）を指定（なければ新規作成）
- メール、SMS、Webhook、Logic Appsなどを登録可能
- まずはメールで確実に受け取り、後からTeams連携などを追加するとスムーズ
- Detailsでアラート ルール名、重大度、説明を入力して保存
これで「誰かがRBACロールを付与・変更した」タイミングで通知できるようになります。
通知先の設計：アクション グループを“運用目線”で作る
アラートは作って終わりではなく、誰が、どの手段で、どれくらいの温度感で受け取るかが重要です。迷ったら次の設計が現場で使いやすいです。
| 通知手段 | 向いている用途 | 注意点 |
|---|---|---|
| メール | 一次通知、監査証跡として残したい | 夜間対応が必要なら別手段も併用 |
| SMS/音声 | 重大度が高い（所有者付与など） | 誤検知が多いと運用が破綻するので絞り込み必須 |
| Webhook / Logic Apps | Teams通知、チケット発行、SIEM連携 | 本文整形（誰が何をしたか）を作り込むと効果が跳ね上がる |
| ITSM連携 | 承認・変更管理プロセスと統合 | 運用設計（SLA/担当/優先度）が先に必要 |
おすすめは、重大度ごとにアクション グループを分けることです。たとえば「所有者（Owner）付与」は即時にTeams＋オンコールへ、「閲覧者付与」はメールのみ、といった温度感が作れます。
より精密に：Log Analytics + KQLで“特定ロール/特定ユーザー”を絞り込む
アクティビティログ アラートは手軽ですが、条件の粒度に限界があります。実務では次のような要望が出がちです。
- 「所有者（Owner）を付与した時だけ通知したい」
- 「特定の運用アカウントによる変更は除外したい」
- 「変更された“対象ユーザー”や“ロール名”を通知本文に入れたい」
この場合は、アクティビティログをLog Analyticsワークスペースに送って、KQLで抽出→ログ アラートにすると運用が一気に楽になります。
流れ（概要）
- 監視対象サブスクリプションで、Diagnostic settings（診断設定）を使い、Activity LogをLog Analyticsへ送信
- Log AnalyticsでAzureActivityテーブルをKQLで検索して、必要な情報が取れることを確認
- Azure Monitorで「ログ（Log）」条件のアラート ルールを作成し、KQLクエリを条件として設定
- アクション グループで通知（メール/Teams連携等）
KQL例：RBACロール割り当て変更（付与・変更）を抽出
AzureActivity
| where OperationNameValue has "Microsoft.Authorization/roleAssignments/write"
| project TimeGenerated, SubscriptionId, ResourceGroup, Caller, OperationNameValue, ActivityStatusValue, Properties上記でイベントが拾えることを確認したら、次は“通知に必要な情報”を抽出します。アクティビティログの詳細は環境や操作経路で差が出ることがあるため、まずは実データを見てから parse_json() を使って掘るのがコツです。
実務のコツ
- まずは広めに拾う → 次にロール名/ロールID/対象プリンシパルで絞る
- 誤検知が多いと通知が形骸化するので、“Owner付与だけは別ルール”のように分割する
- 「アラートが鳴ったら何を確認するか」を決めてから通知本文を設計する（運用が回る）
Microsoft Entra IDの管理者ロール（グローバル管理者等）の変更を検知する
ここが重要ポイントです。グローバル管理者や特権ロール管理者などは、Azure RBACではなくEntra IDのディレクトリ ロールです。したがって、RBAC向けのアクティビティログ監視だけでは取りこぼします。
Entra IDの管理者ロール変更を通知する代表的な方法は、次の2系統です。
- PIM（Privileged Identity Management）を使って通知する：特権ロール運用の王道。Eligible/Activeや永続割り当ての抑止に強い
- 監査ログ（Audit logs）をLog Analyticsへ送り、Azure Monitorでアラート化：PIM未導入でも監視でき、通知本文も作り込みやすい
方法A：PIMで特権ロールの変更を監視し、メール通知を飛ばす
PIMを使っている（またはこれから使う）なら、特権ロールの割り当て・有効化の通知を設計できます。PIMはライセンス要件が絡むため、導入前に契約状況（Microsoft Entra ID P2 など）を確認してください。
PIMでできること（通知の観点）
- 特権ロールが新規に割り当てされた／削除されたときの通知
- Eligible（割り当て可能）→ Active（有効化）になったときの通知
- 永続的（Permanent）な割り当てが作られた場合の警告や、是正を促す運用
設定手順（代表的な流れ）
- Microsoft Entra 管理センターを開く
- Privileged Identity Management（PIM）へ移動
- 管理対象（例：Microsoft Entra roles）を開く
- 監視したいロール（例：グローバル管理者）を選択
- Role settings（ロール設定）で、通知（Notifications）とアラート（Alerts）を調整
- 必要に応じて追加の通知先（追加受信者）を登録（セキュリティ担当・監査担当など）
実務では「ロールのメンバー自身に通知」だけだと不十分なことが多いです。必ず“独立した監視先（SOC/情報システム/監査用メーリングリスト）”にも飛ばす設計にします。
| 通知イベント | おすすめの受信者 | 理由 |
|---|---|---|
| 特権ロールの割り当てが作成/更新/削除 | セキュリティ担当、監査用ML、運用リーダー | 不正・誤操作を即検知し、変更管理と突合できる |
| ロールが有効化（Active化）された | 運用当番、SOC | “今まさに強い権限が使われている”状態を見逃さない |
| 永続割り当て（Permanent）が発生 | 責任者＋監査 | 最小権限の逸脱。是正対象として扱いやすい |
PIM運用のコツ
- グローバル管理者など最重要ロールは、可能な限りEligible + 承認 + MFA + 理由必須で固める
- ブレークグラス（緊急用）アカウントは別枠で管理し、使用時に必ず通知が飛ぶようにする
- 通知だけで終わらせず、月次で「誰が何回有効化したか」をレビューすると抑止力が上がる
方法B：Entra IDの監査ログをLog Analyticsへ集約し、Azure Monitorでアラート化する
PIMが未導入でも、監査ログ（Audit logs）を活用すれば「管理者ロールの変更」を検知できます。さらにLog Analytics＋KQLにすると、通知文に誰が（実行者）、誰に（対象）、何のロールを、追加/削除したかを入れやすく、運用が強くなります。
全体の流れ
- Microsoft Entra IDの監査ログをLog Analyticsワークスペースへ送信（診断設定）
- Log AnalyticsでAuditLogsテーブルを確認し、ロール管理イベントが入っていることを確認
- KQLで「管理者ロール変更」を抽出するクエリを作る
- Azure Monitorのログ アラートで、クエリ結果が出たら通知するルールを作成
KQL例：管理者ロールの付与/削除（監査ログ）を探す
（まずは環境に入っているイベント名を把握するための“探索用”クエリ）
AuditLogs
| where TimeGenerated > ago(7d)
| where Category has "RoleManagement"
| summarize count() by ActivityDisplayName
| order by count_ desc上で出てきた ActivityDisplayName を手がかりに、付与/削除に絞ります。次は“通知に必要な情報”を抜き出す例です。
KQL例：直近のロール変更を一覧化（実行者・対象・操作）
AuditLogs
| where TimeGenerated > ago(1d)
| where Category has "RoleManagement"
| project TimeGenerated, ActivityDisplayName, InitiatedBy, TargetResources, Result監査ログは TargetResources 等が配列になっていることが多く、そのままだと読みにくいので、必要に応じて展開して「対象ユーザー」「ロール名」を取り出します。実データの形に合わせて調整するのが前提ですが、一般的には次のような方向性で作り込みます。
- 操作の種類：追加（Add）/削除（Remove）/Eligible割り当て/Active化など
- 対象ロール：グローバル管理者、特権ロール管理者、条件付きアクセス管理者など
- 実行者：人間か、アプリ/自動化か（サービスプリンシパル等）
ログ アラートの設計ポイント
- グローバル管理者に関する変更は、検知間隔を短く（例：5分）、重大度も高くする
- メールだけでなく、Teamsへ整形通知（実行者・対象・ロール・結果・時刻）を送ると初動が速い
- “変更管理のチケット番号が無い変更”を運用で止めたいなら、通知先を監査・統制の窓口に必ず入れる
補足：Azure MonitorとPIMの使い分けを「迷わない」ための判断基準
「どっちを使えばいいの？」となりやすいので、判断基準を短くまとめます。
| 状況 | 最適解 | 理由 |
|---|---|---|
| Azureリソースの権限（Owner等）を監視したい | Azure Monitor（Activity Log / AzureActivity） | RBACの変更がActivity Logで追える |
| グローバル管理者などテナント管理者ロールを監視したい | PIM通知＋監査ログアラート | PIMは特権運用の標準。監査ログで独立検知もできる |
| 「付与した人」「付与された人」「ロール名」を通知に入れたい | Log Analytics＋KQLアラート | 通知本文を運用向けに整形しやすい |
アラート運用で差がつくベストプラクティス
重大度と通知経路を“ロール別”に分ける
ロール変更アラートは重要ですが、全部を同じ温度感で通知すると疲弊します。おすすめの切り分け例です。
| 対象 | 重大度の目安 | 通知先 | 理由 |
|---|---|---|---|
| グローバル管理者の追加/削除 | 高 | オンコール＋SOC＋監査ML（Teamsも） | テナント全体に影響。即対応が必要 |
| Azure RBACのOwner付与/剥奪 | 高 | 運用当番＋セキュリティ | リソース破壊・設定改ざんが可能になる |
| 閲覧者（Reader）付与 | 中〜低 | メール（監査目的） | 情報漏えい観点では重要だが緊急性は低いことが多い |
「検知」だけでなく「確認項目」を決めておく
アラートが鳴ったときに、確認が属人化していると対応が遅れます。最低限、次のチェックをテンプレ化すると強いです。
- 実行者：誰が変更したか（人/アプリ/自動化）
- 対象：誰に付与/剥奪されたか
- ロール：何のロールか（Owner/Global Adminなど）
- 正当性：変更管理（申請・承認）と一致するか
- 影響範囲：どのスコープ（サブスクリプション/テナント）か
ログ保管と“改ざん耐性”も忘れない
権限を取られた後に真っ先に狙われるのはログです。次のような設計にしておくと安心です。
- ログの送信先（Log Analytics/ストレージ）へのアクセス権を最小化する
- 必要ならストレージ側で保持ポリシーや不変性（運用要件に応じて）を検討する
- アラートの設定変更自体も監視対象に入れる（監視の無効化を検知）
よくあるつまずきと確認ポイント
- 通知が来ない：スコープが想定より狭い（別サブスクリプションで起きている）、アクション グループの受信設定（迷惑メール等）、アラート ルールが無効になっていないかを確認
- グローバル管理者の変更をActivity Logで追えない：それは正常です。Entra ID管理者ロールは監査ログ（Audit logs）側、またはPIMで監視します
- 通知が多すぎて埋もれる：Owner/特権ロールだけ高重大度に分離、Log Analyticsで絞り込み（許可リスト・対象ロール限定）を実施
- 誰に何を付けたかが通知から分からない：アクティビティログ アラートだけだと情報が不足しがち。Log Analytics＋KQLで“運用に必要な項目”を抽出して通知本文を整形
すぐ使える構成例
小規模〜中規模（まずは確実に通知を受ける）
- Azure Monitor：サブスクリプションに対して roleAssignments/write と roleAssignments/delete のアクティビティログ アラート
- PIM：グローバル管理者など最重要ロールで、割り当て/有効化の通知を有効化（追加受信者に監査ML）
- 通知はメール中心（運用に慣れたらTeams連携を追加）
大規模・監査要件が強い（通知を“インシデント対応”に繋げる）
- Azure Activity LogとEntra監査ログをLog Analyticsへ集約
- Log Analytics（KQL）で「特権ロール変更」「Owner付与」を高精度抽出
- Azure Monitorログ アラート→Logic Apps→Teams通知（誰が/誰に/何を/結果）＋チケット発行
- PIMは“運用統制”として併用（Eligible/承認/MFA/理由必須）
まとめ
Azureで「ユーザーのロール変更を検知して通知する」には、まずRBAC（Azureリソースのロール）とEntra ID（グローバル管理者などの管理者ロール）を分けて考えるのが近道です。RBACはAzure Monitorのアクティビティログ アラートから始め、必要に応じてLog Analytics＋KQLで精密化します。管理者ロールはPIMの通知を軸に、監査ログを集約して独立にアラート化すると、抜け漏れのない監視と“回る運用”を両立できます。
コメント