Entra ID の管理者の同意ワークフローでは、構造化された承認プロセスを通じて管理者以外のユーザーがアプリケーションのアクセス許可をリクエストできます。このワークフローが設定されていない場合、ユーザーがアプリケーションにアクセスしようとしても、同意をリクエストする手段がないため、エラーが発生する可能性があります。

<a href="https://learn.microsoft.com/ja-jp/entra/identity/enterprise-apps/configure-admin-consent-workflow#enable-the-admin-consent-workflow">管理者の同意ワークフロー</a>がなければ、管理者以外のユーザーにはアプリケーションのアクセス許可リクエストをエスカレーションできる組み込まれた方法がありません。その結果、ユーザーは回避策に頼るか、ユーザー同意が許可されている場合は、自分でアクセス権を付与することになります ([アプリケーションの無制限のユーザー同意] IoE を参照)。どちらのケースでも、組織はアクセス許可の可視性と制御を失い、最小権限の強制力が弱まります。
同意フィッシング攻撃 (<a href="https://learn.microsoft.com/ja-jp/defender-office-365/detect-and-remediate-illicit-consent-grants">不正な同意付与</a>攻撃とも呼ばれる) は、一見正当に見える悪意のあるアプリにアクセス許可を付与するようにユーザーをだまして誘導します。承認ワークフローがなければ、<a href="https://learn.microsoft.com/ja-jp/graph/permissions-reference#filesreadwrite">Files.ReadWrite</a> (ユーザーファイルへの完全アクセス) や <a href="https://learn.microsoft.com/ja-jp/graph/permissions-reference#mailreadwrite">Mail.ReadWrite</a> (すべてのメールボックスへの読み取りおよび書き込みアクセス) のような疑わしいアクセス許可の範囲にフラグを立てるレビュープロセスがありません。その結果、攻撃者が、パスワード変更や MFA では取り消されない、ユーザーデータへの永続的なアクセス権を取得する可能性があります。
管理者の同意ワークフローがない場合、管理者は監査の目が行き届かない応急的な手段 (メール、チャット、直接の連絡先など) を用いてアクセス許可リクエストを処理しなければなりません。自動化されたリクエストプロセスやリマインダーシステムはなく、承認者、承認対象、承認日時、承認理由がわかる記録も残りません。この監査がないと、アプリケーションのアクセス許可を付与する前に適切にレビューされたことを証明するのが難しくなります。
Microsoft も、<a href="https://learn.microsoft.com/ja-jp/entra/fundamentals/configure-security#admin-consent-workflow-is-enabled">セキュリティを強化するために Microsoft Entra を構成する</a>で、「管理者の同意ワークフローを有効にする」ことを推奨しています。

初期アクセス

フィッシング

権限昇格

アカウント操作: 追加のクラウド認証情報

アカウント操作: 追加のクラウドロール

認証情報アクセス

アプリケーションアクセストークンの窃取

ラテラルムーブメント

代替認証マテリアルの使用: アプリケーションアクセストークン

アプリケーションに管理者の同意ワークフローが設定されていない

検出

アプリケーションに管理者の同意ワークフローが設定されていない

MEDIUM

バージョン 202506240832