「管理者の承認が必要です」と利用者から連絡を受けた場合は、Microsoft Entra 管理センターの Enterprise apps → Admin consent requests → My Pending から申請を確認します。
ただし、申請のレビュー担当者に指定されているだけでは承認できません。レビュー担当者への指定に加えて、アプリが要求する権限を組織として承認できるMicrosoft Entraの管理ロールが必要です。特にMicrosoft Graphのアプリケーション権限を要求するアプリでは、通常のアプリ管理者では承認できないことがあります。([Microsoft Learn][1])
「管理者の承認が必要です」が出たアプリの申請を確認・審査する方法
アプリの承認依頼は、次の流れで確認します。
- 自分がレビュー担当者に指定されているか確認する
- 要求権限を承認できる管理ロールを持っているか確認する
- Microsoft Entra 管理センターで申請を開く
- 権限、提供元、申請者、利用目的を審査する
- 承認、拒否、ブロックのいずれかを選ぶ
- 必要に応じて利用できるユーザーを制限する
重要なのは、アプリへの管理者同意と、アプリを利用できるユーザーの範囲は別の設定だという点です。
| 設定・操作 | 決める内容 |
|---|---|
| 管理者同意 | アプリにどのAPI権限を許可するか |
| ユーザー割り当て | 誰がそのアプリを利用できるか |
| 拒否 | 今回の申請を承認しない |
| ブロック | 今回だけでなく、同じアプリの今後の申請も止める |
最初に確認することは「レビュー担当者」と「管理ロール」
Microsoft Entra IDの管理者同意ワークフローでは、申請内容を確認する「レビュー担当者」と、実際に権限を承認できる「管理ロール」が分かれています。
そのため、レビュー担当者として通知を受け取っていても、必要な管理ロールがなければ承認操作を完了できません。
レビュー担当者に指定されているか
管理者同意の申請を処理するには、管理者同意ワークフローのレビュー担当者に指定されている必要があります。
レビュー担当者は申請一覧を確認できますが、操作できるのは原則として、自分がレビュー担当者に指定された後に作成された申請です。指定前に提出された申請は、一覧で確認できても処理できない場合があります。([Microsoft Learn][1])
要求権限を承認できる管理ロールがあるか
必要な管理ロールは、アプリが要求しているAPIと権限の種類によって異なります。
| 要求されている権限 | 承認に使用できる主な管理ロール |
|---|---|
| Microsoft Graphのアプリケーション権限を含まない一般的な権限 | Cloud Application Administrator、Application Administrator、AI Administratorなど |
| Microsoft Graphのアプリケーション権限を含む権限 | Privileged Role Administrator |
| 組織が定義した範囲だけを承認する場合 | 必要な同意権限を含むカスタムロール |
Cloud Application Administratorなどは、多くのAPIに対する管理者同意を実行できます。ただし、Microsoft Graphのアプリロール、つまりアプリケーション権限は対象外です。Microsoft Graphのアプリケーション権限を承認するには、Privileged Role Administratorなど、より強い権限が必要です。([Microsoft Learn][2])
レビュー業務を担当するからといって、すべての担当者へ強い管理ロールを恒常的に付与するのは避けるべきです。担当範囲に応じてロールを分け、必要な場合だけ権限を有効化する運用が適しています。
Microsoft Entra 管理センターで承認依頼を開く手順
申請を処理できるアカウントで、Microsoft Entra 管理センターへサインインします。
管理画面では、次の順に開きます。
Entra ID → Enterprise apps → Admin consent requests → My Pending
具体的な流れは次のとおりです。
- Microsoft Entra 管理センターへサインインする
Entra IDを開くEnterprise appsを選択するActivity内のAdmin consent requestsを開くMy Pendingタブを選択する- 審査するアプリを選択する
実際に承認や拒否などの操作を行うのは、My Pending タブです。All (Preview) は申請履歴を確認するための画面であり、申請に対する操作には使用しません。([Microsoft Learn][1])
申請を開いたら確認する3つの画面
アプリを選択したら、少なくとも次の3か所を確認します。
| 確認する画面 | 確認内容 |
|---|---|
Review permissions and consent | アプリが要求するAPI権限 |
App details | アプリ名、提供者などのアプリ情報 |
Requested by | 申請した利用者と申請理由 |
Microsoft Learnでも、要求権限、アプリ情報、申請者と理由をそれぞれ確認したうえで、適切な対応を選ぶ手順が案内されています。([Microsoft Learn][1])
Review permissions and consentで要求権限を確認する
最も重要なのが、アプリの要求権限です。
権限名だけを見るのではなく、次の点を確認します。
- 委任されたアクセス許可か、アプリケーションのアクセス許可か
- 読み取りだけか、作成・変更・削除まで可能か
- ユーザー、メール、ファイル、サイト、グループなど、何にアクセスするか
- 業務目的に対して権限範囲が広すぎないか
- Microsoft Graphのアプリケーション権限が含まれていないか
委任されたアクセス許可は、基本的にサインインしている利用者の代理としてAPIへアクセスする権限です。一方、アプリケーションのアクセス許可は、サインインした利用者がいない状態でも、バックグラウンドサービスなどとして動作するために使用されます。([Microsoft Learn][2])
そのため、同じ「読み取り権限」でも、アプリケーション権限のほうが影響範囲が大きくなることがあります。
たとえば、利用者本人が開けるファイルだけを扱う委任権限と、組織内の広い範囲のファイルへアクセスできるアプリケーション権限では、審査の重みが異なります。
App detailsでアプリと提供者を確認する
App details では、申請されているアプリが想定している製品と一致するかを確認します。
実務では、次の点を照合すると判断しやすくなります。
- アプリ名が利用者の申請内容と一致しているか
- 提供元が利用予定のサービス事業者と一致しているか
- 類似名称の別アプリではないか
- 組織が正式に契約しているサービスか
- 社内開発アプリの場合、管理責任者が明確か
- 利用規約やプライバシーポリシーを確認できるか
アプリ名やロゴだけで安全性を判断してはいけません。申請者が「有名なサービスだから問題ない」と説明していても、要求権限が業務目的に対して過大であれば、承認前に確認が必要です。
Requested byで利用者と申請理由を確認する
Requested by では、誰が、どのような理由でアプリを利用したいのかを確認します。
申請理由が「業務で必要」「便利そうだから」だけでは、要求権限が妥当か判断できません。少なくとも次の内容が分かる状態にします。
- どの業務で使用するのか
- 誰が使用するのか
- どのデータを扱うのか
- 利用期間はどの程度か
- 代替手段があるか
- 権限が必要な理由は何か
たとえば、個人の予定を参照するだけのアプリが、組織全体のユーザー情報、メール、ファイルへの書き込み権限まで要求している場合は、目的に対して権限が過大でないか確認する必要があります。
承認前に使える審査チェックリスト
申請内容を確認するときは、次の順序で判断すると見落としを減らせます。
| 審査項目 | 確認する質問 |
|---|---|
| 業務上の必要性 | このアプリを使わなければ業務を実施できないか |
| 提供者 | 信頼できる事業者または組織内の管理対象アプリか |
| 要求権限 | 業務目的に必要な最小限の範囲か |
| 権限の種類 | 委任権限か、利用者なしで動くアプリケーション権限か |
| 対象データ | メール、ファイル、ユーザー情報など何へアクセスするか |
| 利用者の範囲 | 申請者だけか、部署単位か、組織全体か |
| 管理責任 | 問い合わせ先、管理者、契約終了時の対応が明確か |
| 再確認時期 | 継続利用の必要性をいつ見直すか |
Microsoftは、テナント全体への管理者同意について、組織のデータや高い権限へのアクセスを許可する可能性がある重要な操作と説明しています。権限によっては、メールボックスやサイトへの広範なアクセス、ロール管理などが可能になるため、承認前の確認が必要です。([Microsoft Learn][2])
承認しても申請者だけに限定されるとは限らない
管理者同意の画面に表示されている申請者が1人でも、承認の影響がその利用者だけに限定されるとは限りません。
テナント全体への管理者同意を行うと、アプリが要求した権限について、組織を代表して同意した状態になります。また、ユーザー割り当てを必須にしていない場合は、他の利用者もそのアプリへアクセスできる可能性があります。([Microsoft Learn][1])
利用者を限定したい場合は、対応するエンタープライズアプリで次の設定を検討します。
- アプリのプロパティでユーザー割り当てを必須にする
Users and groupsから利用を許可するユーザーまたはグループを割り当てる- 不要になったユーザーやグループの割り当てを解除する
ユーザー割り当てを必須にすると、原則として、割り当てられたユーザーやアプリだけがアクセストークンを取得できるようになります。ユーザー割り当てを必須にしない場合は、すべてのユーザーがサインインできる設定になるアプリもあります。([Microsoft Learn][3])
管理者同意とユーザー割り当ては両方確認する
「権限を承認したから、申請者だけが使える」と考えるのは危険です。
次の2つを別々に判断してください。
- 管理者同意：アプリに何を許可するか
- ユーザー割り当て：誰にアプリの利用を許可するか
部署限定で利用するSaaSなどでは、管理者同意を行った後にユーザー割り当てを必須とし、対象部署のグループだけを割り当てる方法が考えられます。
承認・拒否・ブロックの違い
審査後は、申請に対して承認、拒否、ブロックのいずれかを選択します。
| 操作 | 今回の申請 | 今後の再申請 | 主な用途 |
|---|---|---|---|
| 承認 | 許可する | 不要 | 権限と利用目的に問題がない |
| 拒否 | 許可しない | 可能 | 情報不足、権限の見直し、利用条件の調整が必要 |
| ブロック | 許可しない | 不可 | 組織で利用させないアプリ、信頼できないアプリ |
承認
承認すると、アプリが要求している権限に対して管理者同意が付与されます。申請者には、アクセスが許可されたことが通知されます。
承認前に、要求権限と業務目的が一致していることを確認します。また、必要に応じてユーザー割り当てを設定し、利用者の範囲を制限します。([Microsoft Learn][1])
拒否
拒否では、今回の申請を承認しません。拒否理由を入力すると、その内容が申請者へ通知されます。
拒否後も、利用者は同じアプリについて再度管理者同意を申請できます。そのため、次のような場合に向いています。
- 申請理由が不足している
- 要求権限の説明が必要
- 契約やセキュリティ確認が終わっていない
- より権限の小さい構成へ変更してほしい
- 利用部署や責任者を明確にしてほしい
「現時点では承認できないが、条件が整えば再審査する」という場合は、ブロックではなく拒否を選びます。([Microsoft Learn][1])
ブロック
ブロックは、今回の申請を拒否するだけでなく、同じアプリに対する今後の管理者同意申請も防止します。
ブロックすると、テナント内に無効状態のサービスプリンシパルが作成され、利用者はそのアプリについて新たな管理者同意を申請できなくなります。([Microsoft Learn][1])
次のような場合に検討します。
- 組織のセキュリティポリシーに適合しない
- 提供元を確認できない
- 業務利用を禁止しているサービスである
- 組織データへのアクセスを許可できない
- 同じ不適切な申請が繰り返されている
ブロックは単なる「強い拒否」ではありません。将来の申請も止める操作であるため、情報不足だけを理由に選ばないようにします。
承認ボタンが表示されないときの確認項目
申請を開けても承認できない場合は、次の順に確認します。
My Pendingを開いているか
操作できるのは My Pending タブです。All (Preview) は履歴確認用であり、そこから承認や拒否は行えません。([Microsoft Learn][1])
レビュー担当者に指定されているか
管理者ロールを持っていても、管理者同意ワークフローのレビュー担当者に指定されていなければ、申請を処理できません。
レビュー担当者への指定前に提出された申請ではないか
レビュー担当者が操作できるのは、自分が担当者に指定された後に作成された申請です。以前から残っている申請の場合は、別のレビュー担当者による処理や再申請が必要になる可能性があります。([Microsoft Learn][1])
要求権限に対応した管理ロールがあるか
Cloud Application Administratorを持っていても、Microsoft Graphのアプリケーション権限を承認できない場合があります。
Review permissions and consent で要求権限を確認し、Microsoft Graphのアプリケーション権限が含まれている場合は、Privileged Role Administratorなど、承認可能なロールを持つ担当者へ引き継ぎます。([Microsoft Learn][2])
正しいテナントを開いているか
複数のMicrosoft Entraテナントを管理している場合は、申請が提出されたディレクトリへ切り替えているか確認します。アプリ名だけでなく、申請者の所属組織も照合すると、別テナントで操作するミスを防げます。
管理者同意を安全に運用するためのポイント
管理者同意は、一度承認して終わりにしないことが重要です。
実務では、次のような運用を整えておくと管理しやすくなります。
- 申請理由に業務名、利用者、扱うデータを記載させる
- アプリの管理責任者を決める
- 高い権限は情報システム部門やセキュリティ担当者も確認する
- 承認日、承認者、要求権限を記録する
- 利用者を限定する場合はユーザー割り当てを必須にする
- 契約終了や業務終了時に権限とサービスプリンシパルを見直す
- 定期的に不要なアプリと権限を棚卸しする
特に、「レビュー担当者だからすべての権限を承認できるようにする」という設計は避けます。申請内容を確認する役割と、高い権限を最終承認する役割を分ければ、過剰な権限付与を抑えられます。
迷ったときは承認せず、拒否とブロックを使い分ける
Microsoft Entra IDでアプリの承認依頼を受けたら、まず Enterprise apps → Admin consent requests → My Pending を開きます。
そのうえで、次の順に確認します。
- 自分がレビュー担当者か
- 要求権限を承認できる管理ロールがあるか
- アプリと提供元を確認できるか
- 要求権限が業務目的に対して最小限か
- 申請者と利用理由が明確か
- 利用者を限定する必要があるか
問題がなければ承認し、情報不足や調整が必要なら拒否します。組織として利用させないアプリの場合に限り、今後の再申請も防ぐブロックを選びます。
承認操作だけを見るのではなく、「何の権限を許可するか」と「誰に利用させるか」を分けて管理することが、Microsoft Entra IDのアプリ承認を安全に運用するポイントです。
[1]: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/review-admin-consent-requests “Review and take action on admin consent requests – Microsoft Entra ID | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/grant-admin-consent “Grant tenant-wide admin consent to an application – Microsoft Entra ID | Microsoft Learn”
[3]: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/application-properties “Properties of an enterprise application – Microsoft Entra ID | Microsoft Learn”
コメント