Microsoft Sentinelの「Roles and permissions in the Microsoft Sentinel platform」は、2026年4月22日にMicrosoft Learnで更新され、SIEM、Microsoft Sentinel data lake、Microsoft Defenderポータル移行を前提にした権限設計の整理がより重要になっています。結論から言うと、いま見直すべきポイントは 「Azure RBACだけで考えない」「データレイクはMicrosoft Entra ID RBACやDefender Unified RBACも含めて設計する」「2027年3月31日以降のAzureポータル非対応を前提に移行計画を進める」 の3つです。(Microsoft Learn)
特にsecurity admins、identity teams、compliance teamsは、Microsoft Sentinel ReaderやContributorを付与して終わりではなく、誰がインシデントを操作できるのか、誰がデータレイク全体を読めるのか、誰がプレイブックや自動化を実行できるのかを、実際の業務単位で棚卸しする必要があります。
Microsoft Sentinelの権限設計は「SIEM」と「data lake」で分けて考える
今回の公式記事で最初に押さえるべき点は、Microsoft Sentinelの権限が1つのRBACだけで完結しないことです。Microsoft Sentinel SIEMではAzure RBACが中心ですが、Microsoft Sentinel data lakeではMicrosoft Entra ID RBACやMicrosoft Defender XDR Unified RBACの考え方が関わります。(Microsoft Learn)
従来の運用では、Log AnalyticsワークスペースやSentinelワークスペースに対して、Microsoft Sentinel Reader、Responder、Contributorを割り当てる形が一般的でした。しかし、Defenderポータル統合とデータレイク利用が進むと、権限の確認範囲が広がります。
たとえば、SOCアナリストにMicrosoft Sentinel Responderを付ければインシデント対応はできますが、それだけではプレイブックの作成・編集やデータレイク全体への書き込み権限まではカバーしません。逆に、Security AdministratorやGlobal Administratorのような強い権限を安易に使うと、調査に必要な範囲を超えて広いデータへアクセスできる状態になりやすくなります。
| 観点 | 主に使う権限モデル | 実務で確認すべきこと |
|---|---|---|
| Microsoft Sentinel SIEM | Azure RBAC | インシデント、分析ルール、ワークブック、Content hubを誰が操作できるか |
| Microsoft Sentinel data lake | Microsoft Entra ID RBAC / Unified RBAC / Azure RBAC | 全ワークスペース横断の読み取り・書き込み権限が付いていないか |
| Defenderポータル統合 | Microsoft Defender Unified RBACと既存RBAC | Defender側の権限とAzure側の権限が重複・過剰になっていないか |
| 自動化・プレイブック | Azure RBAC / Logic Apps関連ロール | 実行権限と作成・編集権限を分けているか |
権限設計の失敗でよくあるのは、「Sentinelの画面で見えるかどうか」だけで確認を終えることです。実際には、Azure、Microsoft Entra ID、Defenderポータル、Logic Apps、Log Analyticsの権限が組み合わさって有効権限が決まります。
2026年4月更新で特に確認したいポイント
2026年4月22日更新の公式ドキュメントは、Microsoft Sentinelの権限をSIEMだけでなくdata lakeまで含めて整理しています。記事の更新履歴だけから細かな差分を断定するのは避けるべきですが、少なくとも2026年4月時点の公式本文では、次の観点が実務上の確認ポイントになります。(Microsoft Learn)
Azureポータル前提の運用は期限を意識する
Microsoftは、2027年3月31日以降、Microsoft SentinelをAzureポータルでサポートせず、Microsoft Defenderポータルのみで利用できるようになると案内しています。Azureポータルを使っている既存ユーザーは、Defenderポータルへの移行計画を立てることが推奨されています。(Microsoft Learn)
これは単なる画面移行ではありません。インシデント管理、アラート相関、Automation rule、Playbook、API連携、権限管理の確認ポイントが変わります。たとえば、Defenderポータルでは統合されたインシデントキューやMicrosoft Defender XDRの相関エンジンが関わるため、SOCのトリアージ手順も見直しが必要です。(Microsoft Learn)
2026年中にやるべきことは、次の3つです。
| やること | 担当 | 確認ポイント |
|---|---|---|
| DefenderポータルでのSentinel利用可否を確認 | Security admins | ワークスペース接続、主要機能の表示、インシデント運用 |
| RBACの棚卸し | Identity teams | Azure RBAC、Entraロール、Unified RBACの重複 |
| 監査・証跡要件の確認 | Compliance teams | 誰がデータを読めるか、誰が設定を変更できるか |
移行期限の直前に権限を見直すと、SOCの運用停止や過剰権限の放置につながります。まずは本番環境とは別に、代表的なユーザーグループでDefenderポータル上の操作範囲を確認するのが現実的です。
Microsoft Sentinel built-in rolesの使い分けを再確認する
Microsoft Sentinel SIEMでよく使う組み込みAzureロールは、Reader、Responder、Contributor、Playbook Operator、Automation Contributorです。Microsoft公式記事では、これらのロールが閲覧、インシデント管理、分析ルールやContent hubの管理、プレイブック実行などにどう関わるかを整理しています。(Microsoft Learn)
実務では、次のように分けると権限過多を避けやすくなります。
| ロール | 主な用途 | 向いているユーザー | 注意点 |
|---|---|---|---|
| Microsoft Sentinel Reader | データ、インシデント、ワークブックなどの閲覧 | 監査担当、読み取り専用のSOCメンバー | 調査はできてもインシデント操作はできない |
| Microsoft Sentinel Responder | Reader権限に加えてインシデント管理 | Tier 1 / Tier 2アナリスト | 分析ルールやContent hubの管理には不十分 |
| Microsoft Sentinel Contributor | リソース作成・編集、Content hub管理 | セキュリティエンジニア、Sentinel管理者 | 付与範囲を広げすぎると変更権限が過大になる |
| Microsoft Sentinel Playbook Operator | プレイブックの表示・手動実行 | インシデント対応担当 | Logic Appsの作成・編集権限とは別 |
| Microsoft Sentinel Automation Contributor | SentinelがAutomation ruleへプレイブックを追加するための権限 | サービス用途 | ユーザーアカウント向けではない |
ここで重要なのは、「インシデント対応」と「検知ロジックの変更」を分離することです。たとえば、日常的なSOC担当者にはResponderを基本にし、分析ルールやContent hubを編集する担当者だけにContributorを付与します。これにより、誤って検知ルールを変更したり、不要なソリューションを導入したりするリスクを抑えられます。
ロールはワークスペース単体よりリソースグループに割り当てるのが基本
Microsoftは、Microsoft Sentinelワークスペースを含むリソースグループにロールを割り当てることを推奨しています。理由は、Logic AppsやPlaybookなどの関連リソースも同じロール割り当てでカバーしやすいためです。(Microsoft Learn)
ワークスペース単体にロールを付ける運用も可能ですが、その場合はSecurityInsights solution resourceや関連リソースにも同じ権限を割り当てる必要があり、管理が複雑になります。特にプレイブックを多用する環境では、ワークスペースだけ見て「権限は正しい」と判断すると、実行時に失敗することがあります。
実務でおすすめの割り当て方
| シナリオ | 推奨スコープ | 理由 |
|---|---|---|
| 小規模SOCで1つのSentinel環境を運用 | Sentinel用リソースグループ | ワークスペース、Logic Apps、Playbookをまとめて管理しやすい |
| 複数チームが同じワークスペースを見る | リソースグループ + 必要に応じてカスタムロール | チームごとに閲覧・操作範囲を分けやすい |
| 特定データだけ見せたい | Resource-context RBACやTable-level RBAC | ワークスペース全体の閲覧を避けられる |
| 自動化専用のサービスプリンシパルを使う | 必要最小限のリソースグループまたはワークスペース | 人間の管理者権限と分離できる |
権限の粒度を細かくしすぎると運用負荷が上がります。一方で、すべてをサブスクリプション全体に付けると過剰権限になりがちです。基本は「Sentinel専用リソースグループに役割を集約し、例外だけ個別調整」と考えると管理しやすくなります。
data lake権限は「全体アクセス」と「ワークスペース単位アクセス」を分ける
Microsoft Sentinel data lakeを使う場合、権限設計の重要度はさらに上がります。公式記事では、data lakeの読み取り権限について、Microsoft Entra IDロールによる全ワークスペース横断のアクセスと、特定ワークスペース内のテーブル読み取りを分けて説明しています。(Microsoft Learn)
たとえば、Global Reader、Security Reader、Security Operator、Security Administrator、Global Administratorなどは、data lake内の全ワークスペースに対する広い読み取りアクセスに関わります。一方、特定ワークスペースのデータに限定したい場合は、Azure RBACやDefender XDR Unified RBACのカスタムロールを検討します。(Microsoft Learn)
data lakeで注意すべき権限の違い
| 操作 | 権限設計の考え方 | 注意点 |
|---|---|---|
| 全ワークスペースのデータを読む | Microsoft Entra IDロール中心 | 監査・コンプライアンス上、対象者を厳選する |
| 特定ワークスペースのテーブルを読む | Azure RBACやUnified RBACで限定 | 業務範囲に合わせて最小権限にする |
| KQL jobsやnotebooksでanalytics tierへ書き込む | Security Operator以上の権限が関わる | 調査担当者全員に書き込み権限を渡さない |
| カスタムテーブル作成・保持設定変更 | Operational Insights系のwrite権限を確認 | 誤設定がコストや保持ポリシーに影響する |
| scheduled jobsを管理 | Microsoft Entra IDロールを確認 | 自動実行ジョブが監査対象になる可能性がある |
Compliance teamsが特に見るべきなのは、「誰が全体を読めるか」です。SIEM画面上では限定的な操作に見えても、data lake側で広い読み取り権限があると、調査対象外のログや長期保持データまで参照できる場合があります。
Defender Unified RBACは「有効化後の権限の出どころ」を確認する
Microsoft Defender Unified RBACは、複数のMicrosoft Defender系サービスにまたがる権限管理を一元化する仕組みです。Microsoft Sentinelについてもプレビューとして、DefenderポータルにオンボードされたSentinelワークスペースのアクセス管理をサポートします。(Microsoft Learn)
ただし、ここで混乱しやすい点があります。Unified RBACを使い始めても、Microsoft SentinelのDefenderポータル体験ではARMロールや既存権限も考慮されるため、Unified RBACで想定した範囲より多くのデータが見える可能性があります。Microsoft公式ドキュメントでも、ARM側でより強い権限を持つユーザーは、URBACで設定した範囲より多くのデータをSentinelページで見られる可能性があると説明されています。(Microsoft Learn)
つまり、Unified RBACの導入時は「Unified RBACの画面だけを確認する」のでは不十分です。
Unified RBAC導入時の確認チェック
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| Azure RBACで強い権限が残っていないか | Azure portal / IAM | Owner、Contributor、Log Analytics Contributorが不要に広く付いていないか |
| Entra IDの強いロールが常用されていないか | Microsoft Entra admin center | Global AdministratorやSecurity Administratorが日常運用に使われていないか |
| Unified RBACのスコープが業務と一致しているか | Defender portal | SOC、ID管理、監査の各チームで必要範囲が違うか |
| 既存ロール移行後に権限差分がないか | テストユーザーで実操作 | 見えるデータ、変更できる設定、実行できるアクションを確認する |
Identity teamsは、ロール名だけで判断せず、実際に「どのワークスペース」「どのテーブル」「どのインシデント操作」にアクセスできるかをテストユーザーで確認することが重要です。
PlaybookとAutomation ruleは権限不足・過剰権限の両方が起きやすい
Microsoft Sentinelの自動化では、PlaybookがAzure Logic Apps上に構築されるため、Sentinelのロールだけでは完結しません。公式記事でも、プレイブックを実行するにはMicrosoft Sentinel Playbook Operator、作成・編集にはLogic App Contributorなど、タスクに応じた権限が必要とされています。(Microsoft Learn)
よくある失敗は次の2つです。
1つ目は、SOCアナリストにResponderだけを付け、インシデント対応中にプレイブックを手動実行できないケースです。アナリストが隔離、チケット起票、通知などのアクションを実行するなら、Playbook Operatorの付与を検討します。
2つ目は、プレイブックの実行と編集を同じ人に広く許可してしまうケースです。実行だけが必要な担当者にLogic App Contributorまで付与すると、ワークフローの変更や意図しない外部連携が可能になる場合があります。
プレイブック権限の分け方
| 担当者 | 必要になりやすい権限 | 避けたい付与 |
|---|---|---|
| SOCアナリスト | Microsoft Sentinel Responder + Playbook Operator | Logic App Contributorの広範囲付与 |
| SOAR設計担当 | Microsoft Sentinel Contributor + Logic App Contributor | サブスクリプション全体のOwner |
| 自動化用サービスアカウント | プレイブックがあるリソースグループへの明示的権限 | 個人アカウントの流用 |
| 監査担当 | Reader系ロール | 実行・編集権限 |
特に自動化ルールでプレイブックを実行する場合、Microsoft Sentinelが使うサービスアカウントに対して、プレイブックが存在するリソースグループへの明示的な権限が必要です。権限付与を行う担当者にはOwner権限が必要になる点も、運用フローに含めておく必要があります。(Microsoft Learn)
ゲストユーザーと外部委託SOCはDirectory Readerも確認する
外部SOC、MSSP、グループ会社の担当者など、ゲストユーザーにMicrosoft Sentinelを使わせる場合は、Azure RBACだけでなくMicrosoft Entra ID側のロールも確認します。公式記事では、ゲストユーザーがインシデントを割り当てるにはDirectory ReaderとMicrosoft Sentinel Responderが必要とされています。(Microsoft Learn)
社内ユーザーでは意識しない権限でも、ゲストユーザーでは不足することがあります。たとえば、インシデントは見えるのに担当者割り当てができない、ユーザー情報の参照ができず調査が進まない、といった問題が起こります。
外部委託SOCに権限を渡す場合は、次のような手順で確認すると安全です。
| 手順 | 確認内容 |
|---|---|
| 契約上の業務範囲を整理 | 閲覧だけか、インシデント操作まで必要か |
| テナント参加方式を確認 | B2Bゲストか、専用アカウントか |
| Sentinelロールを付与 | Reader、Responder、Playbook Operatorなど |
| Entra ID側の不足権限を確認 | Directory Readerが必要な操作があるか |
| 操作ログを確認 | 割り当て、コメント、ステータス変更が追跡できるか |
権限不足を避けるためにGlobal Administratorを一時的に付ける運用は避けるべきです。Microsoft公式記事でも、Global Administratorは高い特権を持つため、既存ロールでは対応できない緊急時に限定すべきだとしています。(Microsoft Learn)
コンプライアンス観点では「累積する権限」を重点的に見る
Microsoft Sentinelの権限で見落とされやすいのが、ロール割り当ては累積するという点です。Microsoft Sentinel ReaderとContributorなど、複数のロールを持つユーザーは、意図した以上の権限を持つ可能性があります。(Microsoft Learn)
これは監査で問題になりやすいポイントです。たとえば、ある担当者には本来インシデント閲覧だけを許可したいのに、別のプロジェクトでContributorが残っていると、分析ルールや設定変更が可能になる場合があります。
監査時に見るべきポイント
| 監査観点 | 確認すべきこと | リスク |
|---|---|---|
| 人の異動・退職 | 不要なSentinelロールが残っていないか | 退職者・異動者のアクセス残存 |
| 複数ロールの重複 | Reader、Contributor、Log Analytics Contributorなどが重なっていないか | 想定以上の操作権限 |
| 強いAzureロール | Owner、Contributorが広範囲に付いていないか | Sentinel以外のAzureリソース操作 |
| Entra ID特権ロール | Global Administrator、Security Administratorの常用 | 広範囲データアクセスと権限変更 |
| サービスプリンシパル | 自動化用途の権限が過剰でないか | 不正利用時の影響範囲拡大 |
コンプライアンス対応では、「誰がどのロールを持っているか」だけでなく、「そのロールを組み合わせると何ができるか」まで見る必要があります。特にMicrosoft Sentinel data lakeを使う環境では、長期保持データや複数ワークスペースのデータにアクセスできるため、権限レビューの頻度を高めるべきです。
役割別に見直すべきアクション
Microsoft Sentinelの権限更新を実務に落とし込むには、担当チームごとに見るポイントを分けると進めやすくなります。
Security adminsがやること
Security adminsは、SOC運用に必要な権限と検知・自動化の変更権限を分離します。
まず、アナリストにはResponderを基本にし、プレイブックを実行する担当者にPlaybook Operatorを追加します。分析ルール、Content hub、ワークブック、コネクタ設定を変更する担当者だけにContributorを付与します。
次に、Defenderポータルでの実操作を確認します。Azureポータルではできていた操作がDefenderポータルで同じようにできるか、または運用手順を変える必要があるかを洗い出します。
Identity teamsがやること
Identity teamsは、Azure RBAC、Microsoft Entra IDロール、Defender Unified RBACを横断して確認します。
特に、Global Administrator、Security Administrator、Owner、Contributor、Log Analytics Contributorが広範囲に付いているユーザーを優先して見直します。ロール名が似ていても、Azure側、Entra側、Defender側で意味が異なるため、権限表だけでなく実際の操作確認が必要です。
また、ゲストユーザーや外部SOCに対しては、Directory Readerの必要性も確認します。
Compliance teamsがやること
Compliance teamsは、データアクセス範囲と変更権限の証跡を確認します。
Microsoft Sentinel data lakeを使う場合、全ワークスペース横断の読み取り権限が誰に付いているかを重点的に見ます。加えて、データ保持設定、カスタムテーブル、ジョブ、notebooksの操作権限が監査要件に合っているかを確認します。
監査ログを見るだけでなく、「なぜその人にその権限が必要なのか」を説明できる状態にしておくことが重要です。
最小権限で設計するための実践手順
Microsoft Sentinelの権限を見直す場合、いきなり全ロールを変更するのは危険です。次の順序で進めると、運用影響を抑えながら改善できます。
| ステップ | 作業内容 | 成果物 |
|---|---|---|
| 現状棚卸し | Azure RBAC、Entraロール、Unified RBAC、Logic Apps権限を一覧化 | 権限一覧表 |
| 業務ロール定義 | SOCアナリスト、エンジニア、監査担当、外部SOCなどに分類 | 業務別ロール表 |
| 必要操作の確認 | 閲覧、インシデント操作、ルール編集、プレイブック実行を整理 | 操作マトリクス |
| テストユーザー検証 | DefenderポータルとAzureポータルで実操作を確認 | 権限テスト結果 |
| 本番反映 | 過剰権限を削除し、必要ロールを再割り当て | 更新済みRBAC |
| 定期レビュー | 四半期または半期ごとに見直し | 監査証跡 |
この手順で大切なのは、ユーザー名から考えないことです。先に「業務で必要な操作」を定義し、その後にユーザーやグループを割り当てます。人を起点にすると、例外対応が増え、権限が徐々に肥大化します。
Microsoft Sentinel権限設計で避けたい失敗
Microsoft SentinelのRBAC設計では、次の失敗が起こりやすいです。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 全員にContributorを付ける | 分析ルールや設定を誰でも変更できる | ResponderとContributorを分ける |
| Ownerを運用ロールとして使う | Azureリソース全体への過剰権限になる | Sentinel専用ロールやカスタムロールを使う |
| Playbook実行と編集を分けない | 自動化フローを意図せず変更できる | Playbook OperatorとLogic App Contributorを分離 |
| Unified RBACだけ確認する | Azure RBAC側の強い権限を見落とす | Azure、Entra、Defenderを横断確認 |
| data lakeの全体アクセスを軽視する | 長期保持データや複数ワークスペースへ広くアクセスできる | 全体アクセス権限を限定する |
| ゲストユーザーのEntra権限を確認しない | インシデント割り当てなど一部操作が失敗する | Directory Readerの要否を確認 |
権限設計は、一度作れば終わりではありません。Microsoft SentinelはDefenderポータル統合、data lake、Unified RBACの流れの中で管理範囲が広がっているため、組織の運用変化に合わせて見直す必要があります。
まず着手すべきこと
2026年4月更新の「Roles and permissions in the Microsoft Sentinel platform」を踏まえると、最初に行うべきことは、Microsoft Sentinelのロールを一覧化し、Azure RBACだけでなくMicrosoft Entra IDロール、Defender Unified RBAC、Logic Apps権限まで含めて確認することです。
優先順位は次のとおりです。
- Azureポータル依存の運用を洗い出し、2027年3月31日以降のDefenderポータル移行に備える
- SOCアナリスト、セキュリティエンジニア、監査担当、外部SOCの業務別に必要操作を定義する
- Contributor、Owner、Global Administrator、Security Administratorなどの強い権限を重点的に見直す
- Microsoft Sentinel data lakeを使う、または検討している環境では、全ワークスペース横断アクセスを監査する
- PlaybookとAutomation ruleの実行権限・編集権限を分離する
Microsoft Sentinelの権限管理は、単なる管理画面の設定ではなく、SOC運用の安全性、監査対応、インシデント対応速度に直結します。2026年の時点では、Defenderポータル移行とdata lake利用を前提に、最小権限の原則でRBACを再設計することが現実的な次の一手です。
コメント