Microsoft Entra ID に登録された自動化アプリ・API 連携アプリには、強力な Microsoft Graph 権限と、期限付きのクライアントシークレットが紐づいています。放置された「権限を配れる権限」は特権昇格の踏み台に、失効したシークレットは業務停止の引き金になります。読み取り専用の権限だけで始められる棚卸しの進め方と、再発させない仕組みづくりを解説します。
自動化アプリに付与された Graph 権限のうち、AppRoleAssignment.ReadWrite.All のような「権限を配れる権限」を持つアプリは、自身や他のアプリ・ユーザーに追加権限を付与でき、テナント全体への到達経路を作られてしまう恐れがあります。危険なのはデータの読み取りより「権限を配布できる能力」です。
クライアントシークレットの期限が切れた瞬間、そのアプリを使うバッチ・API 連携・自動化は認証エラー（AADSTS7000222）で一斉に停止します。標準の通知メールは Microsoft Entra Workload ID ライセンスが前提で、該当ロールの保持者がいなければ送信されず、失効が「事故」として繰り返されがちです。
Application.Read.All の Microsoft Graph PowerShell だけで現状を一覧化できます。特別な特権ロールがなくても「まず見える化」から始められるのがポイントです。棚卸しで優先的にチェックすべき権限は、次の4つのカテゴリに整理できます。
| 分類 | 代表的な権限 | 何ができてしまうか |
|---|---|---|
| ① 権限を配れる | AppRoleAssignment.ReadWrite.AllEntitlementManagement.ReadWrite.All | 自身・他のアプリ・任意のユーザーに追加権限を付与でき、特権昇格の起点になり得る |
| ② ロールを操作できる | RoleManagement.ReadWrite.Directory | ディレクトリロールの割り当てを操作できる |
| ③ 資格情報・なりすまし | Application.ReadWrite.All（範囲を絞るなら Application.ReadWrite.OwnedBy） | 他アプリにシークレットを追加するなど、なりすましの経路になり得る |
| ④ 広域ディレクトリ | Directory.ReadWrite.AllDirectory.Read.All | ディレクトリ全体の広範な読み書き・読み取り |
権限とシークレット、どちらの棚卸しも Microsoft Graph PowerShell の読み取り専用スコープで実施できます。
Application.Read.All スコープで、Microsoft Graph のサービスプリンシパルへのアプリロール割り当てを走査して危険権限を持つアプリを抽出。あわせてテナント内全アプリのシークレット・証明書の有効期限を一覧化します。
権限は上記4分類に該当するものを重点的に確認し、資格情報は「期限の近さ」「業務影響」「期限の長さ」「シークレットの本数」の観点で整理して、対応の優先順位を付けます。
不要権限の削除・広すぎる権限の縮小（例：Application.ReadWrite.All → Application.ReadWrite.OwnedBy）、期限が近いシークレットの計画的な更新・整理を進めます。
「既存分は棚卸しで是正、新規分はポリシーで作らせない」という役割分担で、事故と危険権限の再発を防ぎます。
Azure 上で動く処理は、シークレット管理そのものが不要なマネージド ID へ移行することで、失効事故の根本原因を取り除けます。
Azure 外（GitHub Actions など）からのアクセスは、ワークロード ID フェデレーションを利用することで長期シークレットの保管を避けられます。
新規のアプリ登録に対しては、アプリケーション管理ポリシーで長すぎる有効期限のシークレットを作らせないよう制限をかけられます。
危険権限の申請時は上位管理者の承認を必須とする運用ルールを整備し、「見つけて、増やさない」状態を維持します。
Microsoft は Azure アクセスの多要素認証（MFA）を段階的に必須化しています。Phase 1（2024年10月〜）は Azure ポータル等の管理UI、Phase 2（2025年10月1日〜）は Azure CLI・PowerShell・IaC ツール・REST API の書き込み操作が対象。延期の最終期限（2026年7月1日）も過ぎ、現在はすべてのテナントで有効です。
ID・パスワードでのサインイン（ROPC：az login -u/-p 等）は失敗し、ユーザーIDのセッションでも書き込み操作時に MFA チャレンジが返り、無人実行では応答できず失敗します。
サービスプリンシパル・マネージド ID は必須MFAの対象外です。「ユーザーIDで自動化しない」を原則に、ワークロードIDへの移行が対応の軸になります。
break-glass アカウントも、条件付きアクセスから除外していてもシステム強制側で MFA が要求されます。FIDO2 パスキーや証明書ベース認証で要件を満たす構成にします。
「ユーザーIDで動いている自動化」を洗い出します。サインインログから ROPC フローを使うアプリを特定し、「誰のIDで、どのスクリプトが、何の操作をしているか」をリスト化します。
Azure Policy の監査モードで MFA 強制の影響を事前に把握できます。条件付きアクセスが無い環境でも利用可能です。
Azure 上の処理はマネージド ID へ、Azure 外の処理はサービスプリンシパル（可能ならクライアントシークレットではなくフェデレーション資格情報や証明書）へ移行します。
棚卸しは一度やって終わりではなく、定期的に回すことで効果を発揮します。ユーザーやゲストのアクセス権については、Microsoft Entra ID Governance のアクセスレビューを使うことで、定期棚卸しの通知・実施・結果適用までを仕組み化できます。アプリ権限・資格情報の棚卸しと組み合わせることで、テナント全体の「置き去りにされた権限」を継続的に統制できます。
本ページは当社エンジニアによる以下の解説記事をまとめたものです。棚卸しの具体的な手順・コマンドは各記事をご覧ください。
Microsoft Entra ID を中心とした権限管理・ID 統制の設計から運用定着まで、経験豊富なエンジニアがご支援します。
相談する →