Microsoft IntuneのRBAC（Role-based access control）でまず押さえるべき結論は、日常運用に強すぎる管理者権限を使わず、組み込みロール・カスタムロール・スコープタグ・承認フローで権限を細かく分けることです。今回の公式情報で特に重要なのは、複数ロール割り当て時の権限の広がり、Scoped permissionsの扱い、Multi Admin ApprovalによるRBAC変更の承認、そしてIntune AdministratorやGlobal Administratorの使い方の見直しです。
Microsoft IntuneのRBACは、単に「誰に管理画面を触らせるか」を決める機能ではありません。アプリ、構成プロファイル、コンプライアンスポリシー、デバイス操作、監査データなどに対して、誰が、どの範囲で、どの操作までできるかを制御する仕組みです。Microsoft Learnでは、Intune RBACをMicrosoft Entra ID RBACの拡張として説明し、最小権限の原則に沿って管理者へ必要な権限だけを付与する考え方を示しています。(Microsoft Learn)
この記事では、Microsoft IntuneのRBACに関する公式情報をもとに、管理者・セキュリティ担当・ヘルプデスク・開発者が確認すべき変更点、影響範囲、設定チェック、移行時の注意点を実務目線で整理します。なお、Intuneのサービス更新は段階的に展開されるため、テナントによって表示や利用開始時期が前後する可能性があります。(Microsoft Learn)
Microsoft IntuneのRBACで何が変わるのか
今回のポイントは、RBACの考え方が「管理者にロールを割り当てる」だけでなく、権限の過剰付与を検出し、承認し、監視する運用へ寄っていることです。
特に確認すべき変更・注目点は次のとおりです。
| 注目ポイント | 管理上の意味 | 実務で必要な対応 |
|---|---|---|
| Intune AdministratorやGlobal Administratorの常用を避ける | 強い権限を日常作業に使うと、誤操作や侵害時の影響が大きい | 組み込みIntuneロールまたはカスタムロールへ切り替える |
| Multi Admin ApprovalがRBAC変更に対応 | ロール権限、管理者グループ、メンバーグループの変更に二重承認をかけられる | 重要なRBAC変更は承認者を分け、変更申請フローを整える |
| Scoped permissionsがパブリックプレビューで提供 | 複数ロール割り当て時に権限が意図せず広がる問題を抑えられる | 有効化前にPermissions Assessment Reportで影響を確認する |
| 監視ビューが重要になる | 管理者ごとの実効権限や、どのロールから権限が来ているかを確認できる | 定期棚卸しや監査時に「Admin permissions」「Roles by permission」を使う |
| Security Copilot連携時のRBACアクセスにも注意 | Intune RBACロールがCopilot in Intuneのアクセスに関係する | Copilot利用組織ではRBAC設計をAI機能の利用範囲まで含めて見直す |
Microsoftは、Global AdministratorをIntuneの日常管理に使うことを推奨していません。また、Intune Administratorも多くの日常業務には強すぎるため、必要な場合だけ一時的に使い、通常は組み込みIntuneロールまたはカスタムロールを使う方針が示されています。(Microsoft Learn)
RBACの基本構造を理解する
Microsoft IntuneのRBACは、主に次の4つを組み合わせて管理します。
| 要素 | 役割 | 具体例 | 間違いやすい点 |
|---|---|---|---|
| ロール | 何ができるかを決める | アプリ管理、構成プロファイル管理、読み取り専用など | ロールだけでは管理対象の範囲は決まらない |
| 管理者グループ | 誰に権限を与えるかを決める | 東京拠点IT管理者、ヘルプデスク担当者 | グループに不要なメンバーがいると全員に権限が付く |
| Scope Groups | どのユーザー・デバイスを管理できるかを決める | 東京拠点のユーザー、営業部デバイス | 安易にAll usersやAll devicesを選ぶと範囲が広がる |
| Scope Tags | どのIntuneオブジェクトを見えるようにするかを決める | Tokyo、HR、Kiosk、Finance | タグ設計がないと、地域別・部門別の分離が難しくなる |
ロールは「操作権限」、Scope Groupsは「管理対象」、Scope Tagsは「見えるIntuneオブジェクト」を制御します。たとえば、シアトル拠点の管理者にPolicy and Profile Managerロールを割り当て、Scope Groupsをシアトルのユーザー・デバイスに限定し、Scope TagsもSeattleにすることで、該当拠点のポリシーやプロファイルだけを扱わせる設計ができます。(Microsoft Learn)
影響を受ける対象者
Intune管理者
最も影響を受けるのは、Microsoft Intune admin centerで日常的にアプリ、ポリシー、デバイス、登録設定を管理している管理者です。
これまでIntune AdministratorやGlobal Administratorで作業していた場合、まずは作業内容を棚卸しし、以下のように権限を分けるべきです。
| 業務 | 推奨される方向性 |
|---|---|
| アプリ配布を担当 | Application Managerまたは必要権限だけのカスタムロール |
| 構成プロファイル・コンプライアンスポリシーを担当 | Policy and Profile Managerまたはカスタムロール |
| セキュリティベースラインやEndpoint securityを担当 | Endpoint Security Manager |
| 問い合わせ対応・リモート操作を担当 | Help Desk Operator |
| 監査・確認のみ | Read Only Operator |
| RBACの設計・割り当てを担当 | Intune Role Administratorまたは必要権限を持つカスタムロール |
Intuneの組み込みロールは一般的な管理シナリオ向けに用意されていますが、権限や説明の編集はできません。標準ロールでは権限が広すぎる場合、カスタムロールで必要な権限だけを組み合わせる判断が重要です。(Microsoft Learn)
ヘルプデスク担当者
ヘルプデスク担当者には、デバイス同期、リモートロック、ワイプ、アプリやポリシーの確認など、サポート業務に必要な操作だけを与えるのが基本です。
注意したいのは、Help Desk Operatorに便利だからといって、対象デバイスをAll devicesに広げすぎることです。たとえば「国内拠点の端末だけをサポートする」「キオスク端末は別チームが管理する」といった分担があるなら、Scope GroupsとScope Tagsで範囲を分けます。
セキュリティ管理者
セキュリティ担当者は、Endpoint Security、コンプライアンスポリシー、Conditional Access、Microsoft Defender for Endpointとの連携などに関わります。
ただし、Security AdministratorなどMicrosoft Entra側のロールはIntune内の権限も持つ場合があります。Microsoft Learnでは、IntuneにアクセスできるEntraロールの多くを特権ロールとして扱い、日常的なIntune管理にはIntuneの組み込みRBACロールを使うことを推奨しています。(Microsoft Learn)
開発者・自動化担当者
Microsoft Graph API、PowerShell、CI/CD、運用スクリプトでIntuneを操作している開発者も影響を受けます。
特に注意すべき点は次の3つです。
- Graph APIやPowerShell上では、Intune AdministratorがIntune Service Administratorとして表示される
- Scoped permissionsを有効化すると、これまで成功していた更新処理がスコープ外で失敗する可能性がある
- Multi Admin Approvalを有効にしたRBAC変更は、承認されるまで反映されない
自動化アカウントを強い管理者権限で動かしている場合、短期的には便利でも監査上のリスクが高くなります。アプリ登録、サービスアカウント、運用スクリプトごとに「読み取りだけでよいのか」「作成・更新・削除まで必要か」を分けて検証してください。
管理者が確認すべき設定
Microsoft IntuneのRBACを見直すときは、次の順番で確認すると漏れを減らせます。
| 確認項目 | 確認場所 | 見るべきポイント |
|---|---|---|
| 既存ロール | Tenant administration > Roles > All roles | 組み込みロールとカスタムロールの使い分け |
| ロール割り当て | 各ロール > Assignments | どのグループに権限が付いているか |
| 管理者グループ | Admin Groups | 不要なメンバーや退職者、兼務者が残っていないか |
| Scope Groups | Scope (Groups) | All users、All devicesを安易に使っていないか |
| Scope Tags | Scope (Tags) | 地域・部門・用途ごとに分離できているか |
| 実効権限 | Roles > Monitor > Admin permissions | 特定アカウントが実際に持つ権限 |
| 権限の由来 | Roles > Monitor > Roles by permission | どのロール割り当てから権限が来ているか |
| 承認設定 | Tenant administration > Multi Admin Approval | RBAC変更に二重承認をかけるか |
| Scoped permissions | Roles > Settings | 有効化前にレポートを生成したか |
ロール割り当ては個人ではなくグループに対して行います。グループに所属する全員がそのロールの権限を受け取るため、割り当て前にグループのメンバーを必ず確認する必要があります。また、複数グループから得た権限は累積し、明示的な「拒否」はできません。(Microsoft Learn)
Scoped permissionsを有効化する前に確認すべきこと
Scoped permissionsは、複数のロール割り当てとスコープタグを使う環境では非常に重要です。従来の既定動作では、同じ権限カテゴリに対して複数のロール割り当てがある場合、権限がマージされ、想定より広いアクセスを許すことがあります。
たとえば、同じ管理者グループに次の2つを割り当てているケースを考えます。
| 割り当て | 権限 | Scope Tag | 本来の意図 |
|---|---|---|---|
| 割り当てA | Mobile Appsの読み取りのみ | Headquarters | 本社アプリは確認だけ |
| 割り当てB | Mobile Appsの作成・更新・削除 | Regional Office | 地方拠点アプリは管理可能 |
既定動作では、同じMobile Appsカテゴリの権限がマージされ、本社側でもフル権限に近い操作ができてしまう可能性があります。Scoped permissionsを有効にすると、各ロール割り当ての権限が自身のスコープタグ内に閉じるため、意図した権限分離に近づきます。(Microsoft Learn)
ただし、Scoped permissionsの有効化は一方向の変更で、元に戻せません。有効化前にTenant administration > Roles > SettingsでPermissions Assessment Reportを生成し、どの管理者グループで権限が減るのか、業務に支障が出ないかを確認する必要があります。(Microsoft Learn)
有効化を検討しやすいケース
- 部門別・地域別・委託先別に管理範囲を厳密に分けたい
- 1人の管理者が複数ロールを持っている
- Scope Tagsをすでに本格運用している
- 監査で「必要以上の権限」を指摘されている
- 委託先や外部運用チームにIntune管理を一部委任している
すぐに有効化しない方がよいケース
- ロール割り当てやスコープタグの設計書がない
- どの管理者が何をできるべきか整理されていない
- 自動化スクリプトや運用手順が強い権限を前提にしている
- 検証用テナントや限定ユーザーでの動作確認をしていない
- Permissions Assessment Reportの結果を関係者に共有していない
Scoped permissionsはセキュリティ強化に役立ちますが、準備不足のまま有効化すると「昨日まで更新できたアプリが更新できない」「別拠点のポリシーが見えない」といった問い合わせにつながります。まずはレポートを出し、影響がある管理者グループごとに業務テストを行うのが安全です。
Multi Admin ApprovalでRBAC変更を保護する
Multi Admin Approvalは、重要な変更を別の管理者が承認するまで適用しない仕組みです。公式情報では、RBAC変更に対してもMulti Admin Approvalが対応し、ロール権限、管理者グループ、メンバーグループ割り当ての変更に承認を求められると説明されています。(Microsoft Learn)
RBAC変更にMulti Admin Approvalを使う場合は、次の設計が重要です。
| 設計項目 | 推奨 |
|---|---|
| 申請者と承認者 | 同じ担当者に集中させず、別チームまたは上位者を承認者にする |
| 承認対象 | RBAC、スクリプト、アプリ、構成ポリシーなどリスクの高い変更を優先する |
| 緊急時対応 | 承認者不在時の代替承認者を決めておく |
| 監査 | 承認・却下・保留の履歴を定期確認する |
| 運用ルール | 「誰が、何を、なぜ変更するか」を申請文に残す |
よくある失敗は、承認者グループに普段の作業者をそのまま入れてしまうことです。それでは二重承認の意味が薄れます。RBAC変更はテナント全体の管理権限に直結するため、少なくともIntune運用担当とセキュリティ担当で相互確認できる体制にしましょう。
移行・展開の進め方
Microsoft IntuneのRBACを見直す場合、いきなりロールを削除したり、Scoped permissionsを有効化したりするのは危険です。以下の順番で進めると、業務影響を抑えながら最小権限に近づけられます。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 現状把握 | すべてのロール割り当て、管理者グループ、Scope Groups、Scope Tagsを洗い出す | RBAC棚卸し表 |
| 業務整理 | 管理者ごとの日常作業を分類する | 業務別権限マトリクス |
| 権限設計 | 組み込みロールで足りるか、カスタムロールが必要か判断する | ロール設計書 |
| グループ整理 | 不要なメンバー、退職者、兼務者、外部委託アカウントを見直す | 管理者グループ一覧 |
| スコープ設計 | 地域・部門・デバイス種別ごとのScope GroupsとScope Tagsを決める | スコープ設計書 |
| 影響確認 | Permissions Assessment Reportを生成する | 影響分析レポート |
| 検証 | 限定ユーザーでアプリ更新、ポリシー作成、デバイス操作を試す | 検証結果 |
| 段階展開 | チーム単位でロールを切り替える | 展開計画 |
| 監査 | Admin permissionsとRoles by permissionで実効権限を確認する | 定期監査ログ |
ロールを割り当てるには、Tenant administration > Roles > All rolesから対象ロールを選び、Assignmentsで管理者グループ、Scope Groups、Scope Tagsを指定します。スコープグループには管理対象のユーザーやデバイスだけを入れ、管理範囲を意図的に限定することが重要です。(Microsoft Learn)
カスタムロールを作るべき判断基準
組み込みロールで業務を安全に回せるなら、まずは組み込みロールを使うのが現実的です。一方で、次のようなケースではカスタムロールを検討します。
- Help Desk Operatorでは権限が広すぎる
- アプリの読み取りは許可したいが、削除は許可したくない
- デバイス構成プロファイルの作成は許可するが、セキュリティベースラインは触らせたくない
- 監査レポートの閲覧だけを外部担当者に許可したい
- 自動化スクリプトに必要な最小権限だけを与えたい
カスタムロールでは、特定の職務に必要な権限を組み合わせて定義できます。Microsoft Learnでは、アプリ、ポリシー、構成プロファイルなどを管理する部署向けに、必要権限をまとめたカスタムロールを作成できると説明しています。(Microsoft Learn)
ただし、カスタムロールを増やしすぎると管理が難しくなります。名前だけでは意図が分からないロールが乱立すると、監査や引き継ぎで混乱します。ロール名には「対象」「権限レベル」「用途」を入れると管理しやすくなります。
例：
| 悪い名前 | 改善例 |
|---|---|
| AppAdmin2 | JP-MobileApps-ReadOnly |
| TestRole | HQ-DeviceConfig-Update |
| VendorRole | VendorA-Helpdesk-RemoteTasks |
| CustomAdmin | Finance-PolicyProfile-Manage |
Scope Tags設計で失敗しやすいポイント
Scope Tagsは便利ですが、設計を誤ると「見えるはずのポリシーが見えない」「逆に他部門のオブジェクトが見える」といった問題が起きます。
特に注意したいのは次の点です。
| 注意点 | 影響 | 対策 |
|---|---|---|
| カスタムスコープタグを作っていない | 一部ポリシー画面でScope Tags設定が見えない場合がある | Default以外のタグを最低1つ作る |
| タグなしのロール割り当てがある | 権限に応じて広いオブジェクトが見える | 役割ごとにScope Tagsを明示する |
| 自動タグ割り当てと手動タグを混在 | 自動割り当てが手動タグを上書きする場合がある | 割り当てルールを文書化する |
| 1つの管理者に複数タグを重ねる | 実効権限が分かりにくくなる | Admin permissionsで確認する |
| Windows Autopilot Devicesなど未対応オブジェクトを想定する | タグで分離できない対象が残る | 未対応オブジェクトを別途運用ルールで管理する |
公式情報では、ロールは管理者がどのオブジェクトに何をできるかを決め、Scope Tagsは管理者がどのオブジェクトを見られるかを決めると説明されています。また、Scope Tagsを持たない管理者は、権限に応じてすべてのタグ相当のオブジェクトを見られる点にも注意が必要です。(Microsoft Learn)
開発者・自動化担当が確認すべきこと
IntuneのRBAC変更は、管理画面だけでなく自動化にも影響します。PowerShell、Graph API、運用バッチ、チケットシステム連携などでIntuneを操作している場合、次の観点で確認してください。
| 確認項目 | 理由 |
|---|---|
| 実行アカウントのロール | 強すぎる権限で動いていないか確認する |
| 操作対象のScope Groups | スクリプトが対象外デバイスに触れないか確認する |
| Scope Tags | 取得・更新対象のポリシーやアプリが見えるか確認する |
| Create/Update/Delete権限 | 読み取りだけでよい処理に更新権限を与えていないか確認する |
| MAAの影響 | RBAC変更が即時反映される前提の処理を見直す |
| Scoped permissions後の挙動 | 複数ロールのマージを前提にした処理が失敗しないか確認する |
特に避けたいのは、「開発や運用が楽だから」という理由でIntune Administratorをサービスアカウントに付ける運用です。侵害時の影響範囲が大きくなるため、読み取り専用、レポート取得、アプリ更新、デバイス操作など、処理単位で必要権限を分けてください。
直近の関連動向：Copilot in Intuneを使う組織はRBACを再確認
Microsoft IntuneがSecurity Copilotのデータソースとして有効になっている場合、Intune RBACロールとCopilot in Intuneのアクセスにも関係があります。公式のWhat’s newでは、Microsoft Entra IDのIntune AdministratorロールがSecurity Copilotのownerアクセスを継承し、その他の組み込み・カスタムIntune RBACロールはcontributorアクセスを継承すると説明されています。(Microsoft Learn)
これは、AI機能を使う組織では「Intuneで見える範囲」がそのまま調査・要約・分析に関わる可能性があるということです。Copilotの利用を始める前に、RBAC、Scope Tags、監査ログ、承認フローを整理しておくと、便利さとセキュリティのバランスを取りやすくなります。
よくある失敗と対策
Intune Administratorを日常作業で使い続ける
初期構築時はIntune Administratorが必要な場面があります。しかし、構築後もそのまま日常運用に使うと、誤操作やアカウント侵害時の影響が大きくなります。
対策は、日常作業用アカウントを別に用意し、業務に合った組み込みロールまたはカスタムロールへ切り替えることです。必要なときだけPrivileged Identity Managementを使って一時的に昇格する設計も検討できます。Intuneでは、Entra IDのIntune Administratorロールと、PIM for Groupsを使ったIntune RBACロールの昇格という2つの方法が示されています。(Microsoft Learn)
管理者グループのメンバーを確認せずにロールを割り当てる
RBACロールはグループに割り当てます。グループの中に不要なユーザーがいれば、そのユーザーにも権限が付与されます。
対策は、ロール割り当て前にグループメンバーを棚卸しし、動的グループやネストされたグループの扱いも確認することです。特に委託先、兼務者、退職予定者、異動者が含まれていないかを見ます。
All usersやAll devicesを安易に選ぶ
Scope GroupsでAll usersやAll devicesを選ぶと、管理範囲が一気に広がります。全社管理者なら問題ない場面もありますが、地域管理者や委託先には過剰です。
対策は、管理対象ごとにMicrosoft Entra security groupを分け、必要なユーザー・デバイスだけをScope Groupsに入れることです。除外グループを使う場合は、その除外グループがRBACのスコープグループに含まれるか、別途スコープグループとして指定されている必要があります。(Microsoft Learn)
Scoped permissionsをレポートなしで有効化する
Scoped permissionsは一度有効化すると戻せません。影響確認なしで有効化すると、運用担当者の権限が想定以上に減り、アプリ更新やポリシー変更が止まる可能性があります。
対策は、Permissions Assessment Reportを複数回生成し、影響を受けるグループ、ロール、スコープタグ、権限差分を確認することです。必要ならExcelにエクスポートし、管理者チームや委託先と事前に合意してから有効化します。(Microsoft Learn)
まず実施すべきチェックリスト
Microsoft IntuneのRBACを見直すなら、次の順番で始めるのが現実的です。
- Intune AdministratorとGlobal Administratorを日常運用で使っている人数を確認する
- Tenant administration > Roles > All rolesで、すべてのロール割り当てを棚卸しする
- 管理者グループに不要なメンバーがいないか確認する
- All users、All devicesを使っている割り当てを洗い出す
- Scope Tagsが地域・部門・用途ごとに機能しているか確認する
- Admin permissionsで主要管理者の実効権限を確認する
- 複数ロールを持つ管理者グループを洗い出す
- Permissions Assessment Reportを生成し、Scoped permissions有効化時の影響を見る
- RBAC変更にMulti Admin Approvalを使うか検討する
- 自動化アカウントやGraph API連携の権限を見直す
最初から完璧なRBAC設計を作る必要はありません。まずは「強すぎる管理者権限の常用をやめる」「管理者グループを整理する」「Scope GroupsとScope Tagsで管理範囲を絞る」の3点から始めるだけでも、Intune運用の安全性は大きく改善します。
まとめ：RBAC見直しはIntune運用の安全性を上げる近道
Microsoft IntuneのRBACで重要なのは、管理者に必要な作業を止めずに、不要な権限を減らすことです。
今回の公式情報から読み取るべき実務上のポイントは、次の5つです。
- Intune AdministratorやGlobal Administratorを日常管理に使い続けない
- 組み込みロールで足りない場合は、職務単位のカスタムロールを作る
- Scope GroupsとScope Tagsで、管理対象と表示範囲を分ける
- 複数ロール割り当てによる権限の広がりをPermissions Assessment Reportで確認する
- RBAC変更にはMulti Admin ApprovalやPIMを組み合わせ、承認と一時昇格を運用に組み込む
次に取るべき行動は、既存のRBAC割り当てを棚卸しし、強すぎる権限を持つ管理者アカウントを洗い出すことです。そのうえで、日常作業に必要な権限だけを組み込みロールまたはカスタムロールへ移し、Scoped permissionsとMulti Admin Approvalの導入可否を段階的に判断してください。
コメント