Microsoft Entra と Microsoft Defender for Identity を連携している環境で、2026年4月30日の公式ドキュメント更新「Document sensitive roles for Defender for Identity integrations」を見たときに最初に確認すべき点は、Okta、CyberArk、SailPoint などの連携ロールが、Defender for Identity 上で Sensitive として扱われる対象として明記されたことです。
これは「大きな画面変更」や「すぐに移行作業が必須になる発表」というより、ID セキュリティ運用・監査・アラート調査で使う高リスクロールの定義を見直すべき更新と捉えるのが実務的です。とくに security admins、compliance teams、enterprise IT readers は、ロール棚卸し、例外管理、調査手順書、監査証跡の更新対象として扱うべきです。
Microsoft Entraの公式ドキュメント更新「Document sensitive roles for Defender for Identity integrations」で何が変わったか
今回の更新は、MicrosoftDocs の defender-docs リポジトリに対するコミットとして確認できます。コミットでは defender-for-identity/entity-tags.md が変更され、55行の追加、削除なしの差分として「Defender for Identity integrations」配下に Sensitive ロールが追記されています。(GitHub)
Microsoft Learn の現在の「Defender for Identity entity tags」ページでも、最終更新日が 2026年4月30日となっており、同ページに Okta、CyberArk、SailPoint のロールが Sensitive 対象として掲載されています。(Microsoft Learn)
| 確認項目 | 内容 | 実務上の意味 |
|---|---|---|
| 更新対象 | Defender for Identity の entity tags ドキュメント | Microsoft Entra 単体ではなく、Defender for Identity との連携運用で確認する |
| 主な追加 | Okta、CyberArk、SailPoint の Sensitive ロール | 外部 IdP、PAM、IGA の高権限ロールを調査・監査対象に含める |
| 追加された考え方 | 連携先ロールのメンバーシップを Sensitive として扱う | アラート優先度、アクセスレビュー、インシデント調査に影響する可能性がある |
| すぐにやること | ロール割り当て、所有者、例外、監査証跡の確認 | 既存の「特権 ID 一覧」が Microsoft Entra だけに偏っていないか見直す |
重要なのは、この更新を「Defender for Identity の検出精度に関わるドキュメント整理」として読むことです。Microsoft Defender for Identity では、Sensitive タグを持つエンティティに依存する検出があり、公式ドキュメントでも Sensitive アカウントのタグ付けが検出に関係することが説明されています。(Microsoft Learn)
Sensitiveロールとして扱われることの意味
Defender for Identity の entity tags は、ユーザー、デバイス、グループなどを「Sensitive」「Honeytoken」「Exchange server」といった観点で識別するための仕組みです。公式ドキュメントでは、Sensitive タグはユーザー、デバイス、グループをサポートし、Honeytoken はユーザーとデバイス、Exchange server タグはデバイスを対象にすると説明されています。(Microsoft Learn)
つまり、今回の更新で見るべきポイントは「ロール名が追加された」だけではありません。組織の ID セキュリティ運用では、次のような判断に関係します。
- アラートを受けたとき、そのアカウントを高リスクとして優先調査すべきか
- Microsoft Entra 以外の IdP、PAM、IGA 管理者も特権 ID として棚卸しできているか
- 監査チームが持つ「高権限ロール一覧」に Okta、CyberArk、SailPoint 側のロールが含まれているか
- SOC や CSIRT の調査手順で、外部 ID 基盤の権限まで確認する流れになっているか
とくに Microsoft Entra を中心に ID 管理をしている企業では、「Entra ID の管理者ロールだけ見ていればよい」と考えがちです。しかし実際の侵害調査では、Okta の管理者、CyberArk の保管庫管理者、SailPoint の管理者などが、Microsoft 365 や業務システムへのアクセス経路に強く影響することがあります。
今回明記された主なSensitiveロール
公式ドキュメントでは、Defender for Identity integrations のセクションに、Okta、CyberArk、SailPoint のロールが Sensitive として指定されています。これらのロールにメンバーシップを持つエンティティは、自動的に Sensitive として分類されると説明されています。(Microsoft Learn)
| 連携先 | Sensitiveとして確認すべきロール |
|---|---|
| Okta | Super Administrator、Application Administrator、Group Administrator、API Access Management Administrator、Group Membership Administrator、Help Desk Administrator、Mobile Administrator、Organization Administrator、Read-only Administrator、Report Administrator |
| CyberArk | Administration Role、Cloud Onboarding Admin、Connector Management Admin、Flows Admin、Privilege Cloud Administrators、Privilege Cloud Administrators Basic、Privilege Cloud Administrators Lite、Privilege Cloud Safe Managers、Privilege Cloud Safe Managers Basic、Privilege Cloud Safe Managers Lite、Privilege Cloud Session Admin、Privilege Cloud Session Risk Managers、System Administrator |
| SailPoint | Entra ID 側の Global Administrator、User Administrator、Authentication Administrator、Privileged Authentication Administrator、Helpdesk Administrator、Agent ID Administrator、Application Administrator、Directory Writers、Domain Name Administrator、Password Administrator、Privileged Role Administrator、Hybrid Identity Administrator、Cloud Application Administrator、SailPoint 側の IdentityNow Administrator |
この一覧を見ると、いわゆる「最上位管理者」だけではなく、読み取り専用、レポート、ヘルプデスク、グループ管理、Safe 管理なども含まれている点が重要です。
たとえば、Okta の Read-only Administrator や Report Administrator は「変更できないから安全」と見落とされやすいロールです。しかし、認証ログ、ユーザー属性、グループ構成、アプリ割り当ての情報を把握できる立場であれば、攻撃者にとって価値の高い偵察情報になり得ます。
CyberArk では、Safe Managers 系のロールを「業務上の保管庫管理」とだけ見てしまうと、実際には特権資格情報の利用経路や承認フローに関わるリスクを過小評価する可能性があります。SailPoint では、IdentityNow Administrator や Entra ID ロールとの関係を見直し、IGA 上の承認者と Microsoft Entra 側の特権管理者が同一人物に集中していないか確認すべきです。
Replicating Directory Changes Permissionsも見落とさない
今回のコミットでは、Defender for Identity が自動的に Sensitive として扱う高価値資産の一覧に「Replicating Directory Changes Permissions」も追加されています。(GitHub)
これは Active Directory 連携環境では特に重要です。Microsoft の Windows Server ドキュメントでは、Replicating Directory Changes permission は各ドメインの名前付けコンテキストに対するアクセス制御エントリとして説明されており、ADMA などで Active Directory 内のオブジェクトを検出する場合に、対象アカウントへ明示的に付与されることがある権限です。(Microsoft Learn)
実務では、次のようなアカウントを確認してください。
| 確認対象 | 見るべきポイント |
|---|---|
| Microsoft Entra Connect 関連アカウント | 必要最小限の権限か、不要なレプリケーション権限が残っていないか |
| 同期・ID管理ツールのサービスアカウント | 退役済みツールの権限が残存していないか |
| 監視・棚卸しツールの接続アカウント | ドメイン全体への広すぎる権限がないか |
| 旧システム移行時に作成した一時アカウント | 一時用途のまま恒久化していないか |
注意点は、Replicating Directory Changes Permissions を見つけたからといって、すぐ削除すればよいわけではないことです。ID 同期、ディレクトリ検出、監査ツールが依存している場合があります。削除前に、接続元システム、利用目的、最終利用日、代替権限の有無を確認し、変更管理の手順に乗せて対応してください。
運用影響：アラート調査、アクセスレビュー、監査で何を変えるべきか
今回の Microsoft Entra 関連ドキュメント更新は、日々の運用に次の3つの影響を与える可能性があります。
アラート調査では「Microsoft Entra外の高権限」を見る
Defender for Identity のアラートを調査するとき、Microsoft Entra ID のロールだけを確認して終わると、実態を見落とします。Okta、CyberArk、SailPoint と連携している環境では、アカウントがどの外部管理ロールを持っているかまで確認する必要があります。
たとえば、あるユーザーに Microsoft Entra の明示的な特権ロールがなくても、Okta の Group Administrator を持っていれば、グループ経由でアプリ権限に影響を与える可能性があります。CyberArk の Safe 管理権限を持っていれば、特権資格情報の利用経路に関わる可能性があります。
アクセスレビューでは「誰が持つべきか」まで判断する
ロールが Sensitive として明記されたことで、アクセスレビューでは単に「割り当てがあるか」ではなく、次の観点で判断する必要があります。
- そのロールは現在の職務に必要か
- 常時割り当てではなく、申請制・一時昇格にできないか
- 退職者、異動者、委託先アカウントに残っていないか
- グループ経由の間接割り当てを把握できているか
- 緊急用アカウントの場合、利用手順と監査ログが整備されているか
「管理者だから必要」という説明だけでは不十分です。どの業務で、どの頻度で、どの範囲に対して必要なのかを記録してください。
コンプライアンスでは高権限ロール一覧を更新する
compliance teams は、監査用の特権 ID 一覧や職務分掌表を更新する必要があります。特に、次のような資料を持っている場合は見直し対象です。
| 資料・台帳 | 更新すべき内容 |
|---|---|
| 特権 ID 一覧 | Okta、CyberArk、SailPoint の対象ロールを追加 |
| アクセスレビュー手順書 | Microsoft Entra だけでなく連携先ロール確認を明記 |
| インシデント対応手順 | Sensitive ロール保持者の調査優先度を定義 |
| 監査証跡テンプレート | ロール所有者、承認者、最終レビュー日を記録 |
| 例外管理台帳 | 常時付与が必要な理由と期限を明確化 |
監査で弱くなりやすいのは、「Microsoft Entra の管理者ロールは確認しているが、Okta や CyberArk 側の管理者ロールは別チーム管理で抜けている」というケースです。ID セキュリティの責任分界点を文書化しておくと、調査時の混乱を減らせます。
実務での確認手順
まずは大がかりな移行計画を作るより、現状の高権限ロール棚卸しから始めるのが安全です。
| 手順 | 作業 | 成果物 |
|---|---|---|
| 1 | Microsoft Learn の entity tags ページと GitHub 差分を確認する | 更新内容の把握 |
| 2 | Okta、CyberArk、SailPoint の対象ロール保持者を抽出する | ロール割り当て一覧 |
| 3 | Microsoft Entra のユーザー、グループ、管理者ロールと突き合わせる | 高権限 ID マップ |
| 4 | 退職者、異動者、共有アカウント、外部委託アカウントを確認する | リスク候補リスト |
| 5 | 常時付与が不要なロールを削除または一時昇格方式へ移す | 権限削減計画 |
| 6 | Defender XDR 側で Sensitive として見えるか確認する | 検出・調査観点の確認 |
| 7 | SOC、CSIRT、監査チームの手順書を更新する | 運用ドキュメント更新 |
抽出時は、個人ユーザーだけでなく、グループ、サービスアカウント、緊急用アカウント、外部ユーザーも含めてください。実務で事故につながりやすいのは、管理者が直接割り当てたロールよりも、古いグループ経由で残っている権限です。
移行準備として確認すべきこと
今回の更新そのものは、センサー移行を直接要求する内容ではありません。ただし、Defender for Identity の最近の更新では、センサー v3.x、ID セキュリティ強化、Identity inventory、Identity security recommendations など、Microsoft Entra や外部 ID 基盤を含む可視化の強化が進んでいます。Microsoft の What’s new でも、Defender for Identity の機能はテナントへ段階的に展開される場合があると説明されています。(Microsoft Learn)
移行や運用変更を予定している場合は、次の順序で進めると失敗しにくくなります。
既存の高権限IDを先に整理する
センサーやポータル機能を更新しても、権限設計が古いままだとアラートのノイズが増えます。まずは、Okta、CyberArk、SailPoint、Microsoft Entra、Active Directory の特権ロールを横断して一覧化してください。
変更前後で調査手順を比較する
Sensitive として扱われる対象が増えると、アラート調査時に確認すべきロールやログも増えます。SOC 向けの一次対応手順では、次の確認項目を入れておくと実用的です。
- 対象アカウントが Microsoft Entra の管理者ロールを持つか
- Okta、CyberArk、SailPoint の Sensitive ロールを持つか
- グループ経由の間接付与があるか
- 直近でロール付与、グループ変更、認証方式変更があったか
- 対象アカウントが人間のユーザーか、サービスアカウントか、緊急用アカウントか
段階的ロールアウトを前提にする
Microsoft Defender for Identity の新機能や表示は、テナントによって見えるタイミングが異なる場合があります。公式の What’s new でも、機能が段階的に展開され、テナントに見えない場合は後日確認するよう案内されています。(Microsoft Learn)
そのため、「公式ドキュメントに載っているが自社画面ではまだ見えない」という状況が起きても、すぐに設定ミスと断定しないでください。まずはドキュメント更新日、テナントでの表示、対象ライセンス、接続状態、連携先のロール割り当てを分けて確認することが大切です。
失敗しやすいポイントと回避策
| 失敗しやすいポイント | なぜ問題か | 回避策 |
|---|---|---|
| Microsoft Entra のロールだけ確認する | Okta、CyberArk、SailPoint 側の高権限を見落とす | 外部 ID 基盤も含めた特権 ID 台帳を作る |
| Read-only 系ロールを低リスク扱いする | 認証情報、構成、ログの偵察に使われる可能性がある | 変更権限だけでなく閲覧可能な情報の価値で判断する |
| グループ経由の付与を見ない | 退職者・異動者に権限が残りやすい | 直接付与と間接付与を分けて棚卸しする |
| サービスアカウントを対象外にする | 同期・自動化アカウントが強い権限を持つことがある | 所有者、用途、最終利用日を必ず記録する |
| 監査台帳を更新しない | 実運用と監査資料がずれる | Sensitive ロール一覧を監査テンプレートへ反映する |
| 権限を一括削除する | 同期や運用ツールが停止する可能性がある | 削除前に依存システムと変更計画を確認する |
特に、CyberArk や SailPoint はセキュリティ基盤そのものを管理する製品です。そこにある管理者ロールは、Microsoft Entra のロールと同じか、それ以上に強い影響を持つ場合があります。製品ごとの管理チームが異なる場合でも、ID セキュリティの観点では一つの特権アクセス面として扱うべきです。
すぐに使える確認チェックリスト
以下のチェックリストを使うと、今回の更新に対する初回レビューを進めやすくなります。
| チェック | 確認内容 |
|---|---|
| □ | Okta の対象ロール保持者を抽出した |
| □ | CyberArk の対象ロール保持者を抽出した |
| □ | SailPoint の対象ロール保持者を抽出した |
| □ | Microsoft Entra の管理者ロールと突き合わせた |
| □ | グループ経由の間接割り当てを確認した |
| □ | 退職者、異動者、外部委託アカウントを確認した |
| □ | サービスアカウントと緊急用アカウントを分類した |
| □ | 常時付与が必要なロールと一時昇格でよいロールを分けた |
| □ | Defender XDR 側の Sensitive 表示や調査手順を確認した |
| □ | SOC、CSIRT、監査チームの手順書を更新した |
最初のレビューでは、すべてを完璧に整理しようとするより、まず「誰が Sensitive ロールを持っているか」を見える化してください。その後、不要な権限削除、PIM や承認フローへの移行、監査証跡の整備を進めると、運用に無理が出にくくなります。
まとめ：次に取るべき行動
2026年4月30日の Microsoft Entra 関連ドキュメント更新「Document sensitive roles for Defender for Identity integrations」は、Microsoft Defender for Identity の Sensitive 判定に関わる重要な更新です。ポイントは、Okta、CyberArk、SailPoint の連携ロールが明記され、Microsoft Entra だけでなく外部 ID 基盤や PAM、IGA を含めた特権 ID 管理が求められることです。
まずは、公式ドキュメントの対象ロールを自社のロール台帳に反映し、対象ロール保持者を抽出してください。次に、不要な常時付与、グループ経由の残存権限、所有者不明のサービスアカウントを洗い出します。最後に、Defender XDR の調査手順、アクセスレビュー、監査台帳へ反映すれば、今回の更新を実際のセキュリティ強化につなげられます。
コメント