Microsoft Entra Privileged Identity Management（PIM）のアラートを有効化しているのに、PIMを通さずに特権ロールが付与されたときだけ検知されない――。本記事では、Microsoft 365 管理センター経由のロール付与で通知が来なかった事象の原因、当時の回避策、2024年8月の修正後に確認すべき点、監査ログでの二重監視の作り方を整理します。
起きていた現象（PIM外のロール付与が検知されない）
Microsoft Entra PIM（旧 Azure AD PIM）の「アラート（Alerts）」には、想定外の権限付与を早期に見つけるための検知項目が用意されています。その中でも運用で特に重要なのが、「PIM を経由せずに付与されたロール」（＝PIM外で付与されたロール割り当て）を検知し、グローバル管理者（Global Administrator）へ通知する仕組みです。
ところが当時、次のような“不可解な差”が発生しました。
- PIM のアラートで該当項目を有効化し、リスクレベルも High に設定している
- ライセンス（Microsoft 365 Business Premium ＋ Entra ID P2）も付与済み
- しかし、Microsoft 365 管理センター（admin.microsoft.com）から Helpdesk Administrator などを直接付与しても、通知が来ない／アラート画面にも検知結果が出ない
- 一方で、PIM からロール付与（または昇格）を行うと、通知が届く
| 操作 | 操作経路 | 期待される動作 | 実際の動作（当時） |
|---|---|---|---|
| 特権ロールを直接付与（PIM外） | Azure ポータル | 「PIM外で付与」アラートがトリガー、メール通知 | 通知されるケースがある |
| 特権ロールを直接付与（PIM外） | Microsoft 365 管理センター | 「PIM外で付与」アラートがトリガー、メール通知 | 通知されない／検知結果が出ない |
| PIM経由でロール付与・昇格 | PIM（Entra 管理センター） | 通知される（PIMの監視対象） | 通知される |
結論から言うと、これは設定ミスではなく、付与経路に依存した PIM 側の既知不具合（当時）が原因でした。
PIMアラートの位置づけ（なぜ“外”の付与監視が重要か）
PIM は「必要なときだけ特権を使う」「常時特権を避ける」ための仕組みです。PIM を正しく運用できている場合、管理者の権限は次のような状態になっているのが理想です。
| 状態 | 意味 | リスク | 推奨 |
|---|---|---|---|
| Eligible（資格あり） | 普段は権限を持たず、必要時に昇格して利用 | 比較的低い（要承認・MFA等を挟める） | 基本はこの設計 |
| Active / Permanent（常時有効） | 常に管理者権限が有効 | 高い（侵害時の被害が大きい） | 最小限、緊急用のみ |
| PIM外の直接付与 | 監査や承認フローを迂回して付与されることがある | 非常に高い（意図しない権限拡大を見逃しやすい） | 検知・通知・是正をセットで実装 |
特に「PIM外の直接付与」は、人的ミス（誤付与）・内部不正・侵害後の横展開など、いずれのケースでも起点になりやすい事象です。だからこそ、PIM のアラートでグローバル管理者へ確実に通知したい、という要求は非常に現実的です。
まず確認したい：設定ミスを切り分けるチェックリスト
今回のケースは不具合が原因でしたが、現場では「設定が抜けていた」だけで同じ症状に見えることもあります。再現性のある切り分けができるように、最低限ここは押さえておくと安全です（画面構成や名称は更新される場合があります）。
ライセンスと対象スコープ
- Entra ID P2（PIM 利用に必要）を対象ユーザー／管理者に割り当てているか
- 対象が「Entra ロール（ディレクトリ ロール）」なのか、「Azure リソース ロール」なのかを混同していないか
- PIM で管理対象ロールになっているか（ロールを PIM 管理に切り替えていないと、期待したアラートにならない場合がある）
アラートの有効化と通知設計
- PIM のAlertsで「PIM外で付与されたロール」を有効化しているか
- リスクレベル（High など）だけでなく、通知先（誰にメールするか）が設計されているか
- グローバル管理者の個人メールに依存せず、配布グループ（例：ga-alerts@…）を通知先にするなど、運用として受信漏れが起きない形にしているか
- 通知メールが迷惑メール判定されていないか（SPF/DKIM/DMARC・隔離ポリシーなども含めて確認）
再現テストの作り方（失敗しない手順）
「検知しない」を証明するには、テストの条件を固定することが重要です。おすすめは、同じロール・同じ対象ユーザー・同じ実行者で、経路だけを変えて比較することです。
- テスト用のユーザーを用意し、付与するロール（例：Helpdesk Administrator）を決める
- 実行者（付与する側）は、操作できる権限を持つ管理者アカウントを使用する
- 経路A：PIM を使わずに付与（Azure ポータル or Microsoft 365 管理センター）
- 経路B：PIM を使って付与（Eligible→Activate、または PIM で割り当て）
- PIM の Alerts 画面と、通知メール受信の両方を確認する
- 同時に、Entra の監査ログ（Audit logs）にも痕跡が残るか確認する
| 確認ポイント | 見る場所 | 目的 |
|---|---|---|
| PIMが検知したか | PIM > Alerts | 検知の有無と、検知条件の傾向を把握 |
| メールが飛んだか | 通知先メールボックス | 運用上の“気づき”が成立するか確認 |
| 監査証跡が残ったか | Entra ID > 監査ログ | PIMに頼らない代替監視の可否を確認 |
原因：付与経路に依存してアラートがトリガーされない既知不具合（当時）
当時の結論は次のとおりです。
- PIM の「PIM外でのロール付与」を検知するアラートが、付与経路によってはトリガーされない事象が発生していた
- 特に、Microsoft 365 管理センター（admin.microsoft.com）経由のロール付与で、検知されないケースが確認された
- Azure ポータルからの“PIM外”付与では、検知されるケースがあった（＝条件が完全一致しない）
ここがポイントで、運用担当者が「同じロールを付与しているのに、なぜ通知が来たり来なかったりするのか」と悩む原因になります。実際には、管理センターごとに内部的に使っているAPIやイベントの出方が異なることがあり、PIM 側の検知ロジックが特定のイベントを拾い損ねるような形になっていた、と考えるのが自然です（あくまで推測であり、詳細は Microsoft 側の実装に依存します）。
| 観点 | Azure ポータル | Microsoft 365 管理センター |
|---|---|---|
| 目的 | Entra / Azure の管理機能を中心に操作 | Microsoft 365 の管理作業を中心に操作 |
| ロール付与の“見え方” | Entra ロール付与の典型的な流れになりやすい | 同じ結果でも内部イベントが異なる場合がある |
| PIMアラート（当時） | 検知されるケースあり | 検知されないケースが確認 |
そして重要なのは、ユーザー側の操作（アラート無効化→再有効化、ブラウザ変更、通知先変更など）では改善しない場合があるという点です。根本対応は Microsoft 側の修正を待つ必要がありました。
当時の暫定回避策：通知が必須なら“経路”をコントロールする
不具合が疑われる状況では、「設定をいじって直す」よりも「検知できる運用に寄せる」方が安全です。当時、現実的だった回避策は次の2つです。
PIM経由での付与・昇格を徹底する
- ロールを常時付与せず、Eligible を基本とする
- 承認・MFA・理由入力・チケット番号など、PIM 側で強制できる統制を活用する
- 日常運用の“作業手順書”に「PIM経由で行う」を明文化して、属人化を減らす
PIM 経由の操作なら、少なくとも「PIM が認識できるイベント」として扱われやすく、通知の信頼性も高くなります。
どうしても PIM 外で付与する必要がある場合は Azure ポータル経由を検討する
例外的に、緊急対応や一時的な恒久権限付与などで PIM 外の付与が必要になることがあります。その場合、当時はAzure ポータル経由なら検知されるケースが確認されていたため、暫定的に経路を寄せる、という判断が現実的でした。
| 回避策 | メリット | デメリット | 向いているケース |
|---|---|---|---|
| PIM経由で付与 | 統制（承認/MFA/理由）を乗せられる。運用標準にしやすい | 設定・運用設計が必要。即時付与が難しい場合がある | 原則運用、日常の管理作業 |
| Azure ポータル経由で付与（暫定） | 当時は検知されるケースがあった | 不具合回避に依存する。根本解決ではない | 例外対応、緊急時の暫定運用 |
ただし、これはあくまで“当時の回避策”です。経路による差に依存した運用は、UI変更やバックエンド変更で再度崩れる可能性があります。そこで、次の章で紹介する監査ログベースの二重監視が重要になります。
最終的な解決：2024年8月5日の修正展開で検知が安定
その後、2024年8月5日に修正が展開され、Azure ポータル／Microsoft 365 管理センターの両方で、PIM 外のロール付与でもアラートがトリガーされるようになりました。テナントで再テストし、動作することも確認できました。
ただし、こうした修正はテナントやロール種別・検知のタイミングによって見え方が変わることがあります。修正後に「直ったはず」と思い込まず、次の観点で再テストしておくと安心です。
- 同じロールで、Azure ポータル／Microsoft 365 管理センターの両方から “PIM外” 付与を試す
- 通知先メール（配布グループ推奨）で、メール受信を確認する
- PIM > Alerts の検知結果に反映されるかを確認する
- 監査ログ（Audit logs）にも同一の操作が記録されているかを確認する
| 修正後に期待する状態 | 確認方法 | 補足 |
|---|---|---|
| 経路に関係なく「PIM外付与」が検知される | 同条件で経路だけ変えてテスト | 同時に監査ログで突合すると切り分けが早い |
| 通知メールが確実に届く | 配布グループ＋監視用メールボックスで受信 | 担当者の退職や転属に影響されない設計が理想 |
| 検知遅延を把握できている | テスト時刻と受信時刻を記録 | リアルタイム性が必要なら二重監視で補完 |
補足：監査ログベースの二重監視を併用すると安心
PIM のアラートは便利ですが、今回のように“経路依存の不具合”が起きることもあります。重要ロールについては、PIM に加えて監査ログベースの監視（Sentinel / Logic Apps 等）を併用すると、検知漏れに強い運用になります。
どのログを使うべきか（選択肢と特徴）
| ログ/機能 | 強み | 注意点 | 向いている用途 |
|---|---|---|---|
| Entra ID 監査ログ（Audit logs） | ロール割り当ての証跡として一次情報になりやすい | 保持期間・検索性は契約や連携先に依存 | ロール付与の監視、事後追跡 |
| Microsoft Sentinel（分析ルール） | KQL で柔軟に検知し、インシデント化できる | 設計・運用が必要（誤検知の調整など） | 継続監視、SOC運用 |
| Logic Apps（通知の自動化） | メール/Teams/チケット起票などワークフロー化できる | 単体だと検知ロジックが弱いことがある | 通知・エスカレーションの自動化 |
Sentinelでの検知ルール例（ロール割り当てを拾う）
以下は考え方を掴むためのサンプルです。実際のテーブル名・列名は接続方式によって異なるため、まずは Sentinel に取り込まれている Entra 監査ログのテーブルを確認し、環境に合わせて調整してください。
例：特権ロールの割り当て（追加/削除）を検知するKQL
// 監視したいロール名（組織の運用に合わせて調整）
let HighPrivRoles = dynamic([
"Global Administrator",
"Privileged Role Administrator",
"Security Administrator",
"Conditional Access Administrator",
"Exchange Administrator",
"SharePoint Administrator",
"Helpdesk Administrator"
]);
AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName has_any ("Add member to role", "Add eligible member to role", "Remove member from role", "Remove eligible member from role")
| mv-expand TargetResources
| extend Target = tostring(TargetResources.displayName)
| where Target in (HighPrivRoles)
| project TimeGenerated, OperationName, Target,
InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
InitiatedByApp = tostring(InitiatedBy.app.displayName),
Result = tostring(Result),
CorrelationId
| order by TimeGenerated descこのクエリだけでも「いつ・誰が・どのロールを」操作したかの可視化は可能です。さらに「PIM外」を厳密に分けたい場合は、PIM経由の操作に共通する特徴（アプリ名・サービス名など）をログから抽出し、除外条件として加えるのが実践的です。
例：PIM経由っぽい操作を除外して“外”を強調する（要チューニング）
let HighPrivRoles = dynamic([
"Global Administrator",
"Privileged Role Administrator",
"Security Administrator",
"Conditional Access Administrator",
"Exchange Administrator",
"SharePoint Administrator",
"Helpdesk Administrator"
]);
AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName has_any ("Add member to role", "Add eligible member to role")
| mv-expand TargetResources
| extend Target = tostring(TargetResources.displayName)
| where Target in (HighPrivRoles)
| extend InitiatedByUPN = tostring(InitiatedBy.user.userPrincipalName),
InitiatedByApp = tostring(InitiatedBy.app.displayName)
// 「PIMっぽい」アプリ名/サービス名は環境で異なるため、監査ログを見て調整する
| where InitiatedByApp !has "Privileged Identity Management"
| project TimeGenerated, OperationName, Target, InitiatedByUPN, InitiatedByApp, CorrelationId
| order by TimeGenerated descポイントは、「PIM外」の判定を最初から完璧にしようとしないことです。まずはロール付与のイベントを確実に拾い、ログを見ながら除外条件を育てる方が、誤検知・見逃しを減らせます。
通知の設計（グローバル管理者へ“確実に届く”形にする）
通知が“飛ぶ”だけでは不十分で、運用として気づけることが大切です。おすすめの設計は次のとおりです。
- 通知先は個人ではなく、配布グループ（DG）や共有メールボックスにする
- 件名・本文に、誰が／誰に／どのロールを／どの経路でを入れる（相関IDやログURLがあると調査が早い）
- 通知を受けた後のアクション（取り消し・承認・チケット化）を手順化する
- “緊急停止”の判断ができるよう、Break-glass（緊急用）アカウントは別枠で管理する
| 設計項目 | 推奨 | 理由 |
|---|---|---|
| 通知先 | ga-alerts@…（DG/共有MB） | 担当変更に強く、受信漏れを減らせる |
| 通知チャネル | メール＋Teams（可能なら） | メール見落とし対策、即時性の補完 |
| 重複通知 | 相関IDで抑制、一定時間でまとめる | アラート疲れ（Alert fatigue）を防ぐ |
| 運用フロー | 「正当性確認→不要なら剥奪→原因調査」 | 検知から是正までを最短化できる |
運用の安全策：ロール付与そのものを“起きにくく”する
監視は重要ですが、監視だけだと「付与されてしまった後」の対応になります。併せて、権限付与が起きにくい設計に寄せると、事故の確率を大きく下げられます。
- ロール管理権限を最小限にする（誰でも付与できる状態を作らない）
- 管理者は PIM を前提にし、恒久権限を極小化する
- 役割分離（例：日常運用は Helpdesk Administrator、変更承認は Privileged Role Administrator）を明確にする
- アクセス レビューで定期的に「本当にそのロールが必要か」を棚卸しする
- 緊急用アカウント（Break-glass）は多要素や条件付きアクセスの設計とセットで扱い、普段は使用しない
| よくある落とし穴 | 起きる問題 | 現実的な対策 |
|---|---|---|
| 通知先が個人のグローバル管理者 | 休暇・退職・メール見落としで気づけない | 共有MB/DGへ送る。監視用の当番体制を作る |
| PIMの通知だけに依存 | 不具合・遅延・設定変更で検知漏れが起きる | 監査ログ＋Sentinel/Logic Apps で二重化 |
| ロールの範囲が広すぎる | 誤付与の影響が大きい | 最小権限のロール設計、職務分掌、レビュー |
よくある質問
PIMのアラートをHighにしても通知されないことがあるのはなぜ？
本来は「PIM外で付与されたロール」を検知するためのアラートですが、当時は付与経路によってトリガーされない不具合がありました。設定が正しくても起き得るため、ログでの切り分け（監査ログで付与イベントが残っているか）と、二重監視が重要です。
Microsoft 365 管理センターで付与すると何が違うの？
ユーザー体験としては「同じロールを付与した」結果になりますが、内部的には管理センターごとに使うAPIやイベントの扱いが異なることがあります。PIM の検知が特定のイベントに依存していると、結果として“拾える経路／拾えない経路”が発生し得ます。
修正後も監査ログ監視は必要？
必要です。修正で改善しても、将来の変更や新しい管理経路の追加、組織側の設定変更で再び「想定外の見逃し」が起きる可能性はゼロではありません。特権ロールは一度の見逃しが致命傷になり得るため、PIM＋監査ログの二段構えが現実的です。
まとめ
PIM の「PIM外で付与されたロール」アラートは、特権ロールの誤付与や不正付与を早期に検知するうえで非常に有効です。しかし当時は、Microsoft 365 管理センター経由のロール付与で検知されないケースがあり、経路に依存した既知不具合が原因でした。その後、2024年8月5日の修正展開で改善が確認できました。とはいえ、重要ロールの監視は一つの仕組みに依存しないことが鉄則です。PIM の通知に加えて、監査ログを使った二重監視と、そもそも“付与が起きにくい”運用設計まで含めて整備しておくと、長期的に安全で安定した管理体制を作れます。
コメント