Microsoft Defender ポータルで Microsoft Sentinel を運用している管理者が最初に確認すべき結論は、SIEM、Microsoft Sentinel data lake、プレイブック、API連携を同じ権限設計で扱わないことです。2026年5月10日に更新された公式情報では、Microsoft Sentinel SIEM は Azure RBAC、Microsoft Sentinel data lake は Microsoft Entra ID RBAC を使う前提が明確に整理され、さらに Defender ポータルへの移行を見据えた権限確認が重要になっています。(Microsoft Learn)
特に注意したいのは、2027年3月31日以降、Microsoft Sentinel は Azure portal でサポートされなくなり、Microsoft Defender portal での利用に一本化される点です。Azure portal 前提でインシデント対応、分析ルール、プレイブック、API連携を組んでいる環境では、権限だけでなく運用手順や自動化条件も見直す必要があります。(Microsoft Learn)
まず押さえるべき結論：権限管理は3層で考える
Microsoft Defender の「Roles and permissions in the Microsoft Sentinel platform」を読むうえで重要なのは、ロール名を丸暗記することではありません。実務では、次の3層に分けて確認すると判断しやすくなります。
| 確認する領域 | 主な権限モデル | 管理上のポイント |
|---|---|---|
| Microsoft Sentinel SIEM | Azure RBAC | インシデント、ワークブック、分析ルール、Content hub、プレイブック操作を役割別に分ける |
| Microsoft Sentinel data lake | Microsoft Entra ID RBAC / Azure RBAC / Unified RBAC | 全ワークスペース横断の権限と、特定ワークスペース単位の権限を混同しない |
| Defender ポータルの統合運用 | Microsoft Defender unified RBAC、Azure RBAC | Unified RBAC を有効化しても ARM/Azure RBAC の権限が残るため、過剰権限に注意する |
公式情報では、Microsoft Sentinel SIEM の組み込みロールとカスタムロールには Azure RBAC、Microsoft Sentinel data lake の組み込みロールとカスタムロールには Microsoft Entra ID RBAC を使うと説明されています。つまり、従来の Sentinel ワークスペース権限だけを確認しても、Data lake や Defender ポータル側の表示・操作範囲を完全には把握できません。(Microsoft Learn)
何が変わるのか：Azure portal前提の運用からDefenderポータル前提へ
今回の公式情報で管理者が最も重く見るべき点は、Microsoft Sentinel の運用基盤が Microsoft Defender portal へ寄っていくことです。
Microsoft Sentinel は Defender portal 上で、Microsoft Defender XDR と組み合わせても、単体でも利用できます。Defender portal ではインシデント管理や高度なハンティングなどを統合し、ツールの行き来を減らす設計になっています。多くの新規オンボーディング環境では、2025年7月1日以降に Defender portal へ自動的にオンボードされるケースもあります。(Microsoft Learn)
ただし、画面が統合されるだけではありません。次のような運用上の影響があります。
| 項目 | 管理者・開発者が見るべき影響 |
|---|---|
| ポータル移行 | 2027年3月31日以降を見据え、Azure portal 前提の手順書・教育資料・運用フローを更新する |
| 権限設計 | Azure RBAC、Microsoft Entra ID RBAC、Defender unified RBAC の役割を分けて棚卸しする |
| データ収集 | 既存コネクタは原則継続するが、Defender 関連コネクタの表示場所やスキーマ差分を確認する |
| 自動化 | インシデント名、プロバイダー名、SecurityIncident テーブルのフィールド差分に依存した条件を見直す |
| API連携 | 統合インシデントやアラートは Microsoft Graph API の利用を検討し、既存の SecurityInsights API 連携はレスポンス差分を確認する |
Defender portal へ移行しても、既存のデータ収集アーキテクチャや Log Analytics の取り込みパイプライン自体は維持されます。一方で、Defender XDR connector によるアラート連携、Defender for Cloud の重複イベント対策、Defender portal で表示されない一部コネクタなど、運用画面と確認手順には差分があります。(Microsoft Learn)
影響を受ける対象者
この更新は、セキュリティ管理者だけでなく、SOC運用、SIEM設計、データ分析、API連携を担当するチームにも影響します。
| 対象者 | 主な確認ポイント |
|---|---|
| セキュリティ管理者 | 誰に Reader、Responder、Contributor を付与しているか。Global Administrator や Owner が常用されていないか |
| SOCアナリスト | Defender portal の統合インシデントキューで、従来と同じトリアージができるか |
| セキュリティエンジニア | 分析ルール、Content hub、プレイブック、Logic Apps の編集権限が適切か |
| データ分析担当 | Microsoft Sentinel data lake の読み取り・書き込み・ジョブ管理権限が過剰でないか |
| 開発者・自動化担当 | APIレスポンス、インシデントURL、providerName、automation rule の条件に差分がないか |
| MSSP・マルチテナント運用担当 | GDAP、Azure Lighthouse、Microsoft Entra B2B、マルチワークスペース構成の制約を確認する |
特に、Microsoft Sentinel data lake を使う場合は、ワークスペースが Defender portal と Microsoft Sentinel data lake の両方にオンボードされている必要があります。Data lake は KQL や Jupyter notebooks を使った長期データ分析を想定した領域であり、通常のインシデント対応権限とは別に考える必要があります。(Microsoft Learn)
Microsoft Sentinel SIEMの組み込みロールを実務目線で整理する
Microsoft Sentinel SIEM でよく使う組み込み Azure ロールは、次のように役割分担すると分かりやすくなります。公式情報では、これらのロールは Microsoft Sentinel ワークスペースを含むリソースグループに割り当てることが推奨されています。リソースグループ単位にすると、Logic Apps やプレイブックなど関連リソースも同じ権限設計に含めやすくなります。(Microsoft Learn)
| ロール | できることの目安 | 向いている担当者 |
|---|---|---|
| Microsoft Sentinel Reader | データ、インシデント、ワークブック、推奨事項などの閲覧 | 監査担当、閲覧中心のSOCメンバー |
| Microsoft Sentinel Responder | Reader 権限に加え、インシデント管理 | 一次対応を行うSOCアナリスト |
| Microsoft Sentinel Contributor | Responder 権限に加え、ソリューション導入、分析ルールやリソース作成・編集 | セキュリティエンジニア、SIEM管理者 |
| Microsoft Sentinel Playbook Operator | プレイブックの一覧表示、閲覧、手動実行 | インシデント対応中に自動化を実行する担当者 |
| Microsoft Sentinel Automation Contributor | Sentinel が自動化ルールにプレイブックを追加するためのロール | ユーザーではなくサービス用途 |
実務では、Reader、Responder、Contributor の境界を曖昧にしないことが重要です。たとえば、インシデントの状態変更だけを任せたい担当者に Contributor を付与すると、分析ルールやコンテンツ管理まで操作できる可能性があります。逆に、分析ルールの作成や Content hub の管理を任せる担当者には、Responder では足りません。
追加ロールが必要になる作業を見落とさない
Microsoft Sentinel の権限設計でよくある失敗は、「Sentinel のロールを付けたのに作業できない」というものです。原因の多くは、プレイブック、ワークブック、データコネクタなど、Sentinel 外の関連リソースにも権限が必要になる点を見落としていることです。
| 作業 | 追加で確認すべき権限 |
|---|---|
| データソース接続 | ワークスペースへの書き込み権限。コネクタごとの追加権限も確認 |
| Content hub の管理 | リソースグループレベルの Microsoft Sentinel Contributor |
| プレイブックの実行 | Microsoft Sentinel Playbook Operator |
| プレイブックの作成・編集 | Logic App Contributor |
| 自動化ルールからプレイブックを実行 | サービスアカウントにプレイブックのリソースグループへの明示的な権限 |
| ゲストユーザーによるインシデント割り当て | Directory Reader と Microsoft Sentinel Responder |
| ワークブックの作成・削除 | Microsoft Sentinel 系ロールに加え、Workbook Contributor |
プレイブックは Azure Logic Apps を基盤とする別リソースです。Sentinel の Contributor を持っていても、Logic Apps の編集や実行に必要な権限が不足していれば、SOAR運用は途中で止まります。公式情報でも、プレイブック実行や作成・編集には Microsoft Sentinel Playbook Operator と Logic App Contributor の使い分けが示されています。(Microsoft Learn)
Data lakeの権限は「全体アクセス」と「ワークスペース単位」を分ける
Microsoft Sentinel data lake では、通常の SIEM 運用よりも広いデータアクセスが発生しやすくなります。KQLジョブ、Notebook、長期保存データの分析を使う担当者には便利ですが、権限を広く付けすぎると、複数ワークスペースをまたいだデータ閲覧・書き込みが可能になる場合があります。
読み取り権限では、Global reader、Security reader、Security operator、Security administrator、Global administrator などの Microsoft Entra ID ロールが、Data lake 内の全ワークスペースに対する広いアクセスに使われます。一方、特定ワークスペース内のテーブル読み取りであれば、Log Analytics Reader、Microsoft Sentinel Reader、Reader などの Azure RBAC ロールを検討できます。(Microsoft Learn)
書き込み権限も同様です。Data lake のテーブルや分析層への書き込みには Security operator、Security administrator、Global administrator などが使われますが、特定ワークスペースへの出力やテーブル操作では、microsoft.operationalinsights/workspaces/write、microsoft.operationalinsights/workspaces/tables/write、microsoft.operationalinsights/workspaces/tables/delete などを含むロールが必要になります。(Microsoft Learn)
ここでの判断基準はシンプルです。
- 全ワークスペース横断の分析が必要な人だけに、広い Microsoft Entra ID ロールを付与する
- 通常のSOC分析や特定部門向け調査は、ワークスペース単位の Azure RBAC で絞る
- system tables の読み書きは、Microsoft Defender XDR unified RBAC のカスタムロール要件を確認する
- Notebook や KQLジョブを使う担当者は、読み取りだけでなくジョブ管理権限も確認する
Defender unified RBACを使う場合の注意点
Microsoft Defender unified RBAC は、複数のセキュリティソリューションの権限を Microsoft Defender portal 上で一元管理するための仕組みです。Microsoft Sentinel についても、Defender portal にオンボードされたワークスペースの統合アクセス管理をサポートし、Unified RBAC で行った Sentinel ロール割り当ては Azure RBAC に同期されます。ただし、有効化後は Unified RBAC が権限の基準になります。(Microsoft Learn)
ここで注意すべき点は2つあります。
1つ目は、Unified RBAC を有効化しても、Defender portal の Sentinel 体験では ARM/Azure RBAC の権限も尊重されることです。Azure 側で広い権限を持つユーザーは、Unified RBAC で想定したより多くのデータを見られる可能性があります。(Microsoft Learn)
2つ目は、Microsoft Sentinel のサービスプリンシパルや GDAP ユーザーグループへの権限割り当ては Unified RBAC でサポートされない点です。これらが必要な場合は、Microsoft Sentinel では Azure RBAC を使い続ける必要があります。(Microsoft Learn)
Unified RBAC有効化前の確認リスト
| 確認項目 | 見るべきポイント |
|---|---|
| 有効化単位 | Microsoft Sentinel はワークスペース単位で有効化が必要 |
| 操作権限 | Microsoft Entra ID の Security Administrator と、Subscription Owner または User Access Administrator + Sentinel Contributor が必要 |
| Global Administrator | ワークスペースへの自動権限付与ではなく、自分を含め権限を割り当てる権利として考える |
| 既存Azure RBAC | Owner、Contributor、Log Analytics Contributor など広い権限が残っていないか確認 |
| 自動化アカウント | サービスプリンシパルや運用アカウントは Azure RBAC 側で管理が必要なケースがある |
公式情報では、Microsoft Sentinel を Unified RBAC で有効化するには、Microsoft Entra ID の Security Administrator に加え、Subscription Owner、または User Access Administrator と Sentinel Contributor の組み合わせが必要とされています。また、Global Administrator であってもワークスペースに対する自動的なアクセス権を持つわけではありません。(Microsoft Learn)
Defenderポータル移行時に確認すべき設定
ワークスペースのオンボード権限
Microsoft Sentinel を Defender portal へ接続するには、Log Analytics ワークスペースで Microsoft Sentinel が有効になっていることに加え、オンボード操作を行うアカウントに適切なロールが必要です。代表的には、サブスクリプションの Owner、または User Access Administrator と Microsoft Sentinel Contributor の組み合わせが必要です。(Microsoft Learn)
単一ワークスペース環境では比較的整理しやすいですが、複数ワークスペースを扱う場合は、プライマリワークスペースとセカンダリワークスペースの扱いを確認してください。Defender portal は、1つの Microsoft Entra テナント内でプライマリワークスペースと複数のセカンダリワークスペースを接続する構成をサポートします。(Microsoft Learn)
Azure RBACの反映範囲
Defender portal に接続した後も、既存の Azure RBAC 権限に基づいて Microsoft Sentinel 機能を利用できます。Azure RBAC の変更は Defender portal に反映されるため、移行直後に「Defender側だけ」を見て権限が整理されたと判断するのは危険です。(Microsoft Learn)
確認すべきなのは、次のような広いロールです。
- Subscription Owner
- Contributor
- Reader
- Log Analytics Contributor
- Log Analytics Reader
- User Access Administrator
- Security Administrator
- Global Administrator
特に Owner、Contributor、Log Analytics Contributor は、Sentinel 専用ロールより広い権限を持つ場合があります。公式情報でも、ロール割り当ては累積されるため、Microsoft Sentinel Reader と Contributor の両方を持つユーザーは想定以上の権限を持つ可能性があると注意されています。(Microsoft Learn)
自動化ルールとプレイブックの移行注意点
Defender portal への移行で見落としやすいのが、インシデント対応の自動化です。Microsoft Sentinel のプレイブックは Azure Logic Apps 上のワークフローとして動作しますが、Defender portal では一部の操作やトリガー条件に差分があります。
| 項目 | 注意点 |
|---|---|
| Incident provider 条件 | Defender portal ではすべてのインシデントが Microsoft XDR provider として扱われるため、条件依存のルールを確認する |
SecurityIncident の Description | オンボード後に Description フィールドが含まれなくなるため、条件や外部チケット連携で使っている場合は修正する |
| インシデント名 | 相関処理で既存インシデント名が変わる可能性があるため、条件にはタイトルより分析ルール名やタグを使う |
| プレイブック実行遅延 | Defender インシデントが Sentinel に反映されるまで最大数分の遅延が発生し、プレイブック実行も遅れる場合がある |
| 手動実行 | Defender portal ではアラートやエンティティに対する一部の手動プレイブック実行がサポートされない |
公式情報では、Defender portal へオンボード後、SecurityIncident テーブルに Description フィールドが含まれなくなるため、そのフィールドを自動化ルール条件や外部チケット連携で使っている場合は動作しなくなる可能性があると説明されています。また、インシデントタイトルを条件にするのではなく、分析ルール名やタグを使うことが推奨されています。(Microsoft Learn)
これは、ServiceNow などの外部チケットシステムと連携している環境では特に重要です。インシデント説明文、プロバイダー名、URL、タグ、重大度などを同期している場合は、テスト環境または限定ワークスペースで移行後の値を確認してから本番展開するのが安全です。
API連携を持つ開発者が確認すべきポイント
開発者や自動化担当者は、Microsoft Sentinel API と Microsoft Graph API の役割分担を見直す必要があります。
Defender portal の統合エクスペリエンスでは、アラート、インシデント、高度なハンティングなどの自動化に Microsoft Graph REST API v1.0 を使えます。一方、Microsoft Sentinel API は分析ルールや自動化ルールなど Sentinel リソースへの操作を引き続きサポートします。統合インシデントやアラートを扱う場合、公式情報では Microsoft Graph REST API の利用が推奨されています。(Microsoft Learn)
特に確認したい差分は次の通りです。
| 項目 | Azure portal前提 | Defender portal前提 |
|---|---|---|
| インシデントURL | incidentUrl | providerIncidentUrl が追加される。incidentUrl は残るが Sentinel portal を指す |
| プロバイダー名 | providerName = "Azure Sentinel" | providerName = "Microsoft XDR" |
| アラート製品名 | alertProductNames | 取得時に ?$expand=alerts が必要になる場合がある |
| サービス情報 | なし | serviceSource が使われる |
| 検出元 | なし | detectionSource が使われる |
| 製品名 | なし | productName が使われる |
既存コードで providerName が "Azure Sentinel" の場合だけ処理する、incidentUrl をそのままチケットに貼る、アラート製品名をトップレベルのフィールドとして取得する、といった実装をしている場合は要注意です。Defender portal 移行後に条件が一致せず、チケット作成、通知、エスカレーション、証跡保存が失敗する可能性があります。(Microsoft Learn)
管理者が今すぐ行うべき棚卸し
Microsoft Defender と Microsoft Sentinel の権限見直しは、いきなりロールを削除するのではなく、影響範囲を可視化してから段階的に進めます。おすすめの順序は次の通りです。
| 手順 | 作業内容 | 完了の目安 |
|---|---|---|
| 1 | Microsoft Sentinel ワークスペース、関連リソースグループ、Logic Apps、Automation、Content hub 利用状況を一覧化する | 権限対象のリソースが漏れなく見えている |
| 2 | ユーザー、グループ、サービスプリンシパル、ゲストユーザーのロールを棚卸しする | Owner、Contributor、Global Administrator の常用者が分かる |
| 3 | Reader、Responder、Contributor、Playbook Operator の役割を職務に合わせて再定義する | SOC、運用、設計、監査の境界が明確になる |
| 4 | Data lake を使う担当者を特定し、全体アクセスとワークスペース単位アクセスを分ける | 広い Entra ID ロールの付与理由が説明できる |
| 5 | Defender unified RBAC を有効化するワークスペースを決める | Azure RBAC との重複や残存権限を把握している |
| 6 | 自動化ルール、プレイブック、API連携をテストする | providerName、URL、Description、インシデント名依存の問題を潰せている |
| 7 | SOC手順書と教育資料を Defender portal 前提に更新する | アナリストが統合インシデントキューで迷わず対応できる |
権限の見直しでは、最小権限の原則を徹底してください。公式情報でも、Global Administrator は非常に強い権限であり、既存ロールで対応できない緊急時に限定することが推奨されています。(Microsoft Learn)
失敗しやすいポイントと回避策
Contributorを便利ロールとして使い回す
Microsoft Sentinel Contributor は便利ですが、分析ルール、Content hub、リソース編集まで可能になるため、一次対応者全員に付与するには広すぎる場合があります。インシデント管理が主目的なら、まず Microsoft Sentinel Responder を検討します。
プレイブックの権限をSentinel側だけで判断する
プレイブックは Logic Apps です。実行だけなら Playbook Operator、作成・編集なら Logic App Contributor が必要です。自動化ルールから実行する場合は、サービスアカウントにプレイブックが存在するリソースグループへの明示的な権限が必要です。
Data lakeの広域ロールを安易に付与する
Security administrator や Global administrator などのロールは、Data lake 全体に広い影響を持つ場合があります。長期ログ分析やNotebook実行が必要な担当者でも、まずワークスペース単位の権限で足りるかを確認しましょう。
Unified RBACを有効化すればAzure RBACの問題も消えると思い込む
Defender portal の Sentinel 体験では ARM/Azure RBAC の権限も尊重されます。Unified RBAC だけを見て「このユーザーは制限済み」と判断すると、Azure 側の Contributor や Log Analytics Contributor によって想定以上の閲覧・操作が可能な場合があります。
APIや自動化条件を移行後に初めてテストする
Defender portal 移行後は、providerName、インシデントURL、アラート取得方法、SecurityIncident のフィールドなどが変わります。検知後の通知、チケット作成、証跡出力、チャット通知など、運用に直結する処理は移行前に必ず検証してください。
まとめ：次にやるべきこと
Microsoft Defender の「Roles and permissions in the Microsoft Sentinel platform」で確認すべきポイントは、単なるロール一覧ではありません。重要なのは、Microsoft Sentinel SIEM、Microsoft Sentinel data lake、Defender portal の統合運用を分けて権限設計し、2027年3月31日以降の Defender portal 前提に運用を移行していくことです。
まずは、現在の Microsoft Sentinel ワークスペースに対して、誰が Azure RBAC、Microsoft Entra ID RBAC、Microsoft Defender unified RBAC のどの権限を持っているかを棚卸ししてください。次に、Contributor や Owner などの広い権限を職務単位で見直し、プレイブック、Data lake、API連携、自動化ルールを移行テストします。
権限管理は、移行直前にまとめて直すと障害になりやすい領域です。早い段階で「閲覧」「インシデント対応」「コンテンツ管理」「自動化」「データ分析」「API連携」に分けて整理しておくことで、Defender portal への移行後も安全で運用しやすい Microsoft Sentinel 環境を維持できます。
コメント