「権限分類（低/中/高）をどう決めるか」実務ルール
- 山崎行政書士事務所
- 6 日前
- 読了時間: 9分
― Microsoft Graph 権限の危険シグナル集（情シス向け・社内規程にコピペできる版）
※本稿は Microsoft Entra / Microsoft Graph の公式情報を前提にした、権限ガバナンスの一般論です。個別案件の法的評価（適法性判断・紛争対応など）ではありません。社内規程化・契約や責任分界の整理は、状況に応じて別途設計が必要です。
0. 情シスが直面する“地雷”はここ
ベンダー／SaaS 連携／内製ツールがこう言ってきます。
「Microsoft 365 と連携するので 管理者の同意お願いします」
「Graph 権限はこの通りです（10〜30個）」
「最小権限です（と言い切る）」
ここで情シスが困るのが、“どれが危険で、どこからが高リスクか”を短時間で説明可能な形に落とすことです。
Microsoft も、組織に代わって管理者が同意を付与することは機密性が高い操作であり、アプリや発行元を信頼できない／理由に確信が持てない場合は同意しないよう明記しています。
この「確信が持てる／持てない」を、属人判断ではなく 低/中/高の“提出物”にするのが今回のゴールです。
1. まず前提：Entra の「アクセス許可の分類」と、Graph の「権限の危険度」は同じではない
1-1. Microsoft Entra の「アクセス許可の分類」は、ユーザー同意の制御に直結する仕組み
Entra ではアクセス許可を 「低」「中（プレビュー）」「高（プレビュー）」に分類でき、同意ポリシーで「ユーザーが同意できる権限」を選別できます。
ただし重要な制約があります。
現時点で分類できるのは「管理者の同意を必要としない委任されたアクセス許可のみ」
基本的なサインインに必要な最小権限は openid / profile / email / offline_access（いずれも Graph の委任権限）
つまり、Entra の分類は「すべての Graph 権限を低/中/高にラベリングして終わり」ではなく、“ユーザー同意の許可範囲を制度化するための装置”だと捉えるのが実務的です。
1-2. “危険度評価”は、分類機能の外側で必ず必要になる
現場で問題になるのは、むしろ以下です。
管理者同意が必要な委任権限
アプリケーションのアクセス許可（App-only）
.All、ReadWrite、ディレクトリ・ロール・同意（認可）周り…
これらは、Entra の分類対象外が混ざります。だからこそ、情シスの Change 管理としては、
Entra の分類（ユーザー同意コントロール）
社内ルールとしての低/中/高（審査・承認・棚卸しコントロール）
を 二層構造で運用するのが安定します。
2. Graph 権限は「名前」で8割読める：危険シグナル抽出の基本
Microsoft Graph の権限名は基本的に、
{resource}.{operation}.{constraint}
というパターンで設計されています。
resource：何にアクセスするか（例：User、Mail、Files、Sites、Directory…）
operation：何をするか（例：Read、ReadWrite…）
constraint：範囲（例：All）
このパターンを“機械的に分解”して、以下の3軸で判定すると、説明が崩れません。
3. 低/中/高を決める「3軸＋例外（High直行）」
軸A：権限タイプ（委任か／アプリか）
委任されたアクセス許可（Delegated）
ユーザーがサインインしている前提で、アプリは ユーザーとして動作します。「アプリに付与された権限」と「ユーザー本人の権限」の積集合でしかアクセスできない、というのがポイントです。
アプリケーションのアクセス許可（Application / App-only）
ユーザーがいない前提で、アプリは アプリ自身として動作します。この場合、原則として その権限に紐づくデータ全体にアクセス可能になり得ます。公式例として、Files.Read.All のアプリケーション権限は組織内のすべてのファイル読み取りが可能になり得る、とされています。
→ 実務ルール：App-only が含まれた時点で「高」候補。まず“代替できないか”を問う。
軸B：影響範囲（Blast radius）— .All は原則 High
.All は「全体」を意味し、誤操作・漏えい・悪用時の上限が跳ねます。
→ 実務ルール：
*.Read.All：中〜高（対象リソースの機微度で変動）
*.ReadWrite.All：原則 高
Directory.*.All：原則 高（後述のHigh直行）
軸C：操作内容（Read と ReadWrite は“別物”）
Read：情報開示（漏えい）リスク
ReadWrite / Manage / FullControl：改ざん・破壊・権限拡大リスク
Graph は最小権限を推奨し、必要以上の権限要求はセキュリティ上好ましくない（採用・利用面の問題にもなる）としています。
→ 実務ルール：更新系（Write/Manage/FullControl）が混ざるなら “中”では止めない。基本は 高。
例外：High 直行（“危険シグナル”に該当したら議論を短くしてよい）
以下は「3軸で悩む前に High」として扱うと、運用が崩れません。
4. Graph 権限の危険シグナル集（High直行・または中→高引き上げ）
シグナル1：テナント全体の管理者同意（Tenant-wide admin consent）を要求している
Microsoft は、テナント全体の管理者同意は 機密性の高い操作で、ロール管理・全メールボックス/全サイトへのフルアクセス・完全なユーザー偽装などの例を挙げています。
→ 実務ルール：
「誰がアプリを制御しているか」
「なぜその権限が必要か」
に確信が持てないなら 同意しない。
シグナル2：Directory.AccessAsUser.All（委任の最高権限級）
Graph 公式で、
Directory.AccessAsUser.All は Entra ID 全体で最も高い特権の委任権限
Directory.ReadWrite.All が次点
Directory.Read.All が読取系の最高権限
と明記されています。
→ 実務ルール：これは “説明がつくまで許可しない”でOKです。「なぜ Directory.* が必要か」を機能単位で分解させるのが王道。
シグナル3：認可・ロール付与・権限付与そのものを操作できる
権限参照（Permissions reference）では、認可を付与できる権限（例：AppRoleAssignment.ReadWrite.All、RoleManagement.ReadWrite.Directory）は、アプリが自分や他者に追加の権限を付与できる可能性があるので注意という趣旨の警告があります。
→ 実務ルール：
原則：禁止（高）
例外：特殊な運用が必要（別テナント、厳格な承認、期限、監査）
シグナル4：資格情報（シークレット/証明書）を管理できる
権限参照では、資格情報（credentials）を管理できる権限（例：Application.ReadWrite.All）は、アプリが別の主体として動作し得る／付与された特権を利用し得るため注意、とされています。
→ 実務ルール：ここも原則は 高（禁止寄り）。CI/CD や運用都合で必要と言われたら、設計の見直し（分離・OwnedBy/限定権限・別ID化）を先に検討。
シグナル5：ユーザー同意の “Microsoft推奨” でも除外される権限群
Entra の Microsoft管理ポリシーは、エンドユーザー同意に関する最新推奨に基づいて自動更新されるとされています。
そして「Microsoft が推奨するユーザーの同意ポリシー」では、エンドユーザーが同意できる委任権限から 除外される Graph 権限の例が具体的に列挙されています（Files.Read.All / Sites.ReadWrite.All / Mail.ReadWrite / Chat.ReadWrite / OnlineMeetings.ReadWrite など）。
→ 実務ルール：このリストに載る＝少なくとも“低”ではない。「ユーザー同意は不可、管理者審査が必要」と判断してよい根拠になります。
シグナル6：Exchange プロトコル系 *.AccessAsUser.All（EAS/EWS/IMAP/POP）
同じく Microsoft推奨のユーザー同意ポリシーの除外リストには、EAS.AccessAsUser.All / EWS.AccessAsUser.All / IMAP.AccessAsUser.All / POP.AccessAsUser.All が含まれます。
→ 実務ルール：
新規アプリで出てきたら 高
既存メールクライアント用途でも、例外統制（許可アプリ限定）で扱う
シグナル7：発行元未検証アプリへのユーザー同意を許している／求めている
ユーザー同意の設定では、悪意あるアプリに騙されるリスク軽減のため、検証済みの発行元のアプリにのみユーザー同意を許可することを推奨しています。
→ 実務ルール：発行元が未検証なら、同意は原則 管理者ワークフローに寄せる。（技術的には Entra の同意ポリシーで制御が可能）
5. 実務で使える「低/中/高」社内定義（そのまま規程に貼れる）
ここからが“提出物”向けの定義です（おすすめの落としどころ）。
5-1. 低（Low）：ユーザー同意を許容し得る“入口の最小セット”
定義（Low）
委任のみ
管理者同意不要
対象は主にサインイン／基本プロフィール
.All を含まない
更新系（ReadWrite/Manage/FullControl）を含まない
最小権限（openid / profile / email / offline_access）が Low の基準になる、という整理が公式にあります。
運用Low は Entra のアクセス許可分類と同意ポリシーで“制度化”しやすい領域です。
5-2. 中（Medium）：業務上必要だが、棚卸し・期限・説明責任が必要
定義（Medium）
基本は委任（または範囲限定された仕組み）
データアクセスがある（メール/ファイル/予定表/チャット等）
ただし、範囲が限定的（All ではない、または対象限定設計がある）
変更・付与の経緯を台帳に残し、棚卸し可能である
注意Microsoft の例でも、既定ではユーザーが自分のメールボックスへのアクセスに同意できるが、組織内すべてのファイルの読み書きに同意はできない、と説明されています。 この“差”が Medium と High の境界の考え方になります。
5-3. 高（High）：強い審査・分離・期限・監査がないと事故る
定義（High）
App-only（アプリケーションのアクセス許可）
.All（組織全体）
更新系（ReadWrite/Manage/FullControl）
ディレクトリ／ロール／同意（認可）／資格情報の管理
Microsoft が「機密性が高い操作」と例示する領域に該当
運用
OnePager（用途・データ・代替・撤去手順）必須
期限付き（例：3〜6か月）＋棚卸し必須
“同意を付与する前に、要求されたアクセス許可をよく確認”が公式推奨
6. 5分で回せる「判定フロー」（現場で刺さる手順）
Step 1：まず “委任か／アプリか” を確定
App-only がある → 原則 High（理由：権限スコープの全データにアクセス可能になり得る）
Step 2：権限名を分解して “.All / ReadWrite / Directory” を抽出
.All がある → Blast radius 大（High寄り）
ReadWrite/Manage/FullControl がある → 改ざん・権限拡大（High寄り）
Directory.* / RoleManagement.* / AppRoleAssignment.* → High直行
Step 3：Microsoft推奨ポリシーで除外される領域に該当するかチェック
Mail.* / Files.* / Sites.* / Chat.* / OnlineMeetings.* などの列挙は、ユーザー同意の“除外対象”として示されています。
→ 少なくとも Low ではない（Medium以上／ユーザー同意禁止）
Step 4：代替案を“設計”として提示させる
Graph には、**リソース固有の同意（RSC）**のように、全体（All）ではなく特定インスタンスにスコープを絞る考え方があります。 ここをベンダーが語れない場合は、要件が曖昧な可能性が高いです。
Step 5：最後は “信頼できるか／理由に確信があるか” の門
テナント全体の管理者同意を許可する前に、アプリと発行元を信頼し、理由に確信がないなら同意しない。公式にここまで明言されています。
7. Entra で“制度化”する（属人判断を減らす）
7-1. ユーザー同意設定：既定は「管理者同意不要の委任」だけが対象
ユーザー同意の設定ページは、ユーザー同意を制限・無効化してセキュリティリスクを軽減するためのガイダンスです。
また、ユーザーを騙す悪意あるアプリのリスク低減として、検証済み発行元のアプリに限定する推奨も明記されています。
7-2. アプリ同意ポリシー：Microsoft管理ポリシーは“最新推奨に自動更新”される
同意ポリシーは「ユーザーが同意できるアプリ」を制御する枠組みで、Microsoft管理ポリシーは最新推奨に基づき自動更新されます。
→ 実務ルール：
まず Microsoft管理ポリシーをベースにする
自社の例外だけを追加（台帳で管理）
が運用負荷が低いです。
7-3. 定期棚卸し：同意は“付けたら終わり”にしない
Entra のアプリ管理の文脈でも、アプリ/サービスに付与されたアクセス許可を定期的に確認し、疑わしいアクティビティを評価することが重要、とされています。
8. 付録：危険シグナル（コピペ用・最短版）
社内文書用に短くまとめるなら、これだけで回ります。
High直行
App-only（アプリケーションのアクセス許可）
.All ＋ ReadWrite/Manage/FullControl
Directory.AccessAsUser.All / Directory.ReadWrite.All / Directory.Read.All
RoleManagement.ReadWrite.Directory / AppRoleAssignment.ReadWrite.All（認可・ロール付与）
Application.ReadWrite.All 等（資格情報管理）
Exchange プロトコル系 *.AccessAsUser.All
“テナント全体の管理者同意”を求める（確信なければ同意しない）
Medium→High 引き上げ検討
Mail.* / Files.* / Sites.* / Chat.* / OnlineMeetings.*（ユーザー同意の除外に列挙される領域）
発行元未検証アプリのユーザー同意要求
コメント