【Microsoft Entra】その自動化アプリ、特権昇格の踏み台かも - Microsoft Graph 権限の棚卸し -

こんにちは！DXソリューション営業本部の大和矢です。

私の本業はセキュリティ系ではなく、普段からログを眺めたりインシデント対応をしているわけではありません。

ですが最近、自己研鑽の一環として SC-100（Microsoft認定：Cybersecurity Architect Expert）を学習・取得しました。
開発や検証の中でも、Entra ID のアプリケーション登録に触れる機会がたびたびあります。
そうした学びと実務での気づきが重なって、本記事を書いてみようと思いました。

本記事は、Microsoftの公式ドキュメント（Microsoft Learn）を頼りに整理したものです。

きっかけは、学習を進める中でのある気づきでした。
私自身は、アプリに権限を付けるときはできるだけ必要最小限に絞り、判断に迷えばAIに聞いたりネットで調べたりしながら、慎重にやっているつもりでいます。
それでも、ふと不安になりました。その「最小限」のつもりの権限の中に、そのアプリ自身を特権昇格の踏み台に変えてしまう危険な権限が紛れ込んでいたとしても、自分はきちんと気づけるだろうか――と。
学習を進めるうちに、その「気づきにくい危険な権限」が具体的にどれで、どう見分ければよいのかが見えてきました。

この記事を読み終えるころには、「どの権限が昇格経路になるのか」を見分け、自社のテナントから機械的に洗い出し、これ以上増やさないための一線まで引けるようになっているはずです。
抽象的な「最小権限が大切」で終わらせず、具体的に確認する方法まで紹介していきます。

なぜ「動いているアプリ」が一番危ないのか

過剰権限の本当のリスクは「データを読まれること」ではありません。
そのアプリ自身が、他者に権限を配れてしまうことです。

Microsoft公式のアクセス許可リファレンスは、AppRoleAssignment.ReadWrite.All のような「権限の付与を許す権限」について、はっきりと注意喚起しています。
すなわち「アプリケーションが自分自身・他のアプリケーション・任意のユーザーに追加の権限を付与できる」ため、付与には注意せよ、というものです（Microsoft Graph のアクセス許可リファレンス）。
別の公式ガイドでも、この権限は「組織内の任意のアプリ・ユーザー・グループに対して権限付与と特権昇格ができる」と明記されています。

ここで、サービスプリンシパル（アプリの実行ID）がユーザーアカウントと決定的に違う弱点を、3つに整理しておきます。
公式の「ワークロードID用の条件付きアクセス」でも、ワークロードIDが従来のユーザーアカウントと異なる理由として、次の3点が挙げられています（ワークロードID用の条件付きアクセス）。

• 多要素認証（MFA）を踏まない：
  アプリはMFAを実行できません。人間向けの最後の砦が効きません。
• ライフサイクル管理が緩い：
  入退社のような棚卸しプロセスがなく、作りっぱなしになりがちです。
• 資格情報をどこかに保存している：
  シークレットや証明書が漏れれば、誰でもそのアプリとして振る舞えます。

つまり、無人で動き続け、MFAも効かず、鍵を抱えたアプリが危険な権限を持っていると、それは「気づかれにくい特権アカウント」になります。
攻撃者がそのアプリのシークレットを1つ手に入れれば、理屈の上では次のような多段の昇格が成立しえます（図1）。

なお、この連鎖は公式の権限定義から導いた理論上の到達可能性モデルであり、私が特定の攻撃を実証したもの（PoC）ではありません。
私自身もペネトレーションテストをするわけではありませんが、「権限の定義上はここまで到達しうる」という前提を持つことが、危険権限を評価する出発点になります。

誤解されがちですが、「うちのアプリはSharePointを読むだけ」でも油断はできません。
そのアプリに付随してAppRoleAssignment.ReadWrite.AllやApplication.ReadWrite.Allが混ざっていれば、実質的にテナント管理者と同じ到達点を持ってしまうからです。
では、具体的にどの権限が「配れる権限＝昇格経路」なのか。次章で分類していきます。

昇格経路になる「危険権限」の見分け方 ― 4カテゴリ

危険権限は、機能名だけでは判断できません。
「その権限で何を書き換えられるか」で見ると、昇格に直結するものは大きく4カテゴリに分けられます。
なお、この4分類は公式が定めた区分ではありません。公式のアクセス許可リファレンスが「注意（Caution）」として警告している権限を、昇格の手口ごとに私が整理したものです。

①と②は、公式が同じ文言で「権限の付与を許す権限（granting authorization）」として警告しているグループです。
③のApplication.ReadWrite.Allは「同意付与の管理はできない」一方で、他アプリへの資格情報追加＝なりすましができるため、結果的に高権限アプリの権限を間接的に乗っ取れます。
④のディレクトリ権限について、公式はアクセス許可リファレンスで「将来的に非推奨になる可能性がある」とまで明記しています。

危険権限のカタログができたら、次は「自社のテナントで今、誰がこれを持っているのか」を機械的に洗い出します。

今すぐやる棚卸し ― 危険権限を持つアプリを抽出する

設計の前に、まず現状把握です。
「Microsoft Graphに対して危険なアプリロールを割り当てられているサービスプリンシパル」を一覧化すれば、踏み台候補を可視化できます。

ポイントは、棚卸しの方向を間違えないことです。
サービスプリンシパルには appRoleAssignments（そのアプリが他リソースから受け取った権限＝アプリが持つ権限）と、appRoleAssignedTo（そのリソースが自分のアプリロールを誰に割り当てたか＝リソース側から見た一覧）という、向きの異なる2つの見方があります。
「Microsoft GraphというリソースSP」を起点に appRoleAssignedTo をたどれば、Graph権限を持つすべてのアプリを横断的に取得できます（図2）。

Graph PowerShellで一覧化する

まずはコマンドで一気に洗い出す方法です。
この棚卸しは「見る」だけなので、必要なのは読み取り専用の Application.Read.All 一つだけです（棚卸しに書き込み権限は要らない、というのも最小権限の実践です）。

# 事前準備（初回のみ・管理者権限は不要）：Microsoft.Graph モジュールを導入
#   Install-Module Microsoft.Graph.Authentication, Microsoft.Graph.Applications -Scope CurrentUser
#
# 棚卸しは読み取り専用スコープで（最小権限）
# このスクリプトに必要なのは Application.Read.All 一つだけ。
# Directory.Read.All まで付けると範囲が広がるので、ここでは付けません。
Connect-MgGraph -Scopes "Application.Read.All"

# Microsoft Graph のサービスプリンシパル（appId は固定値）
$graph = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"

# 危険権限（アプリケーション権限）の GUID 辞書
# 表の4カテゴリは代表例。ここでは公式アクセス許可リファレンスで
# 「注意（Caution）」が付くアプリ権限を、取りこぼさないよう網羅する。
$dangerous = @{
  # 権限の付与を許す権限（granting authorization）
  "06b708a9-e830-4db3-a914-8e69da51d44f" = "AppRoleAssignment.ReadWrite.All"
  "9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8" = "RoleManagement.ReadWrite.Directory"
  "9acd699f-1e81-4958-b001-93b1d2506e19" = "EntitlementManagement.ReadWrite.All"
  # 資格情報を管理できる権限（managing credentials）
  "1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9" = "Application.ReadWrite.All"
  # ディレクトリ権限（広域アクセス／将来非推奨の可能性）
  "19dbc75e-c2e2-444c-a770-ec69d8559fc7" = "Directory.ReadWrite.All"
  "7ab1d382-f21e-4acd-a863-ba3e13f7da61" = "Directory.Read.All"
}

# Graph に割り当てられたアプリロールを全件取得し、危険権限だけを抽出
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $graph.Id -All |
  Where-Object { $dangerous.ContainsKey($_.AppRoleId) } |
  Select-Object @{n='App';        e={$_.PrincipalDisplayName}},
                @{n='Permission'; e={$dangerous[$_.AppRoleId]}},
                CreatedDateTime |
  Sort-Object App

このスクリプトは、Microsoft Graphに対して危険な権限（公式が「注意（Caution）」を付けている AppRoleAssignment.ReadWrite.All ほか）を割り当てられたサービスプリンシパルを、アプリ名・権限名・付与日時の一覧として出力します。
表で示した4カテゴリは代表例です。スクリプトには、これらに加えて表に載せていないDirectory.Read.Allなども含め、公式がCautionを付けたアプリ権限をまとめて登録しています。
この結果が「危険権限を持つアプリの台帳」の出発点になります。

ここまでで分かるのは「危険権限を持っているか」（下の①の軸）までです。②のシークレット有効期限は Get-MgApplication の資格情報（passwordCredentials／keyCredentials）、③の休眠はサービスプリンシパルのサインインログ側で別途突き合わせます。
棚卸し対象は危険権限の保有だけで決めないでください。
公式のアプリケーションのセキュリティ運用ガイドやMicrosoft Entra 推奨事項を読み解くと、優先順位は次の3軸で付けるのが定石のようです。

• ① 危険4カテゴリを持つアプリ：
  言うまでもなく最優先。昇格の踏み台になりうる本丸です。
• ② 有効期限の長いクライアントシークレットを持つアプリ：
  鍵が漏れれば即、踏み台化します。資格情報の寿命は短いほど安全です。公式も推奨事項として有効期限が近いアプリ資格情報の更新や未使用の資格情報の削除を挙げています。
• ③ 長期間サインインのない休眠アプリ：
  使われていないのに権限だけ生きている、典型的な「忘れられた特権」です。サービスプリンシパルのサインインログや、公式の未使用アプリケーションの削除推奨事項（App Health／Workload Identities Premium）で特定できます。

危険権限を「増やさない」― Entra IDに備わった「承認の関門」とCopilot時代の備え

棚卸しで現状が見えたら、次は「これ以上、危険権限を増やさない」仕組みづくりです。
ここで朗報です。特別なツールを入れなくても、Entra IDには「特に危険な権限は、上位の管理者しか承認できない」という関門がもともと備わっています。これを活かさない手はありません。

順を追って説明します。
アプリに権限を与えるときは、管理者がその要求を「承認（同意）」する必要があります。
ふだんは Application Administrator（アプリ管理を担当するロール）が、多くのアプリ権限を承認できます。
ところが Microsoft 公式によると、Microsoft Graph と Azure AD Graph のアプリケーション権限だけは、Application Administrator（や Cloud Application Administrator）では承認できません。
承認するには、Privileged Role Administrator のような、より上位の管理者が必要です（テナントの設定によっては Global Administrator が必要な場合もあります）。
この仕様は、公式のMicrosoft Entra のビルトインロールとテナント全体の管理者同意にはっきり書かれています。

ここが肝心なポイントです。
本記事で挙げてきた危険権限（AppRoleAssignment.ReadWrite.All など）は、すべてこの「Microsoft Graph のアプリケーション権限」に当たります。
つまり 危険な権限ほど、承認できる人が自動的に絞り込まれている――Microsoftが仕様として"関門"を用意してくれている、というわけです。

そして、この関門が本当に効いてくるのは、むしろこれからです。
Power Automate、Copilot Studio のエージェント、Microsoft 365 Copilot のGraphコネクタ――自動化を広げるほど、Microsoft Graph の権限を持つアプリは社内でどんどん増えていきます。
新しく作るアプリを、最初からこの関門（＝上位管理者によるレビュー）に通す運用にしておけば、危険な踏み台が知らないうちに増えるのを防げます。
自動化のスピードを落とさずに安全を保つための、いわば"先行投資"です。

よくある質問（FAQ）

まとめ ― 見つけて、増やさないところから

今回は、自動化のために配ったアプリ権限がなぜ特権昇格の踏み台になるのか、その見極め（4カテゴリ）・棚卸し・そして「これ以上増やさない」付与の境界線までを整理しました。
押さえどころは3つです。

• 危険なのは「動いているデータ連携アプリ」：
  リスクの本質はデータ参照ではなく、「権限を配れる権限」「ロールを操作できる権限」が昇格の核になることです。
• まずは現状把握：
  Graph PowerShell（読み取り専用・最小スコープ）で、自社の危険権限保有アプリを一度洗い出してみましょう。
• 増やさない一線を引く：
  「Application Administratorでは同意できないGraphアプリ権限」を、そのまま「必ず人手でレビューする」ラインに転用すれば、新たな踏み台の流入を止められます。

見つかった危険権限を、すぐにゼロへはできなくても、放置はできません。
本格的な多層防御（ワークロードID向けの条件付きアクセスや継続監視など）に進む前の応急処置として、まずはこの3つから着手すると効果的です。

• 鍵を弱点にしない：
  クライアントシークレットをやめ、証明書やマネージドIDへ寄せます。鍵が漏れても踏み台化しにくくなります。
• 使っていない権限は剥がす：
  休眠アプリや不要になった危険権限は、棚卸しの勢いでそのまま削除します。
• 広い権限は狭い権限へ：
  Application.ReadWrite.All を Application.ReadWrite.OwnedBy に、ディレクトリ系を個別リソース権限に置き換え、影響範囲を縮めます。

まずは本記事のスクリプトで、自社テナントの危険権限を1度洗い出してみてはいかがでしょうか。
「とりあえず強めに付けておいた」あの権限が、思わぬ「踏み台」になっていないか――。
そこに気づき、増やさない一線を引けたなら、最小権限への第一歩は、もう踏み出せています。

ここまでお読みいただき、ありがとうございました。
なお、本記事は Microsoft Entra ID のガバナンス・権限管理に関する内容でした。関連するテーマは、QESブログの「Microsoft Entra ID Governance」カテゴリでもまとめて発信していますので、あわせてご覧いただけますと幸いです。

Microsoft Entra ID Governance ブログ一覧 | QES ブログ
QESのエンジニアが Microsoft Entra ID Governance のアクセス制御・権限管理・ID統制の自動化ノウハウを発信中！
 

※このブログで参照されている、Microsoft、Azure、Microsoft Entra ID、Microsoft Graph、Microsoft 365 Copilot、Microsoft Copilot Studio、Microsoft Power Platform、Power Automateは、米国Microsoft Corporationの米国およびその他の国における商標または登録商標です。