委任されたアクセス許可とアプリケーションのアクセス許可

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

Microsoft Entra ID における委任されたアクセス許可とアプリケーションのアクセス許可を比較し、セキュアな API、自動化、アプリ開発に適したアクセスモデルを選択する方法を解説します。

Automatically translated with AI from the original post. Read the English original

Cover: Stop OAuth Consent Attacks in Microsoft Entra ID

Microsoft Entra ID を扱う際、誰が何をできるのか、そしてどのような条件でできるのかを把握することは、単なる技術的な細部ではありません。Microsoft のクラウドにおけるセキュアなアプリ開発、自動化、そして ID 管理全体の土台となるものです。ユーザーがアプリに代理で操作させるために必要最小限のアクセスを許可する方式（委任されたアクセス許可）と、アプリに単独で操作させる権限を与える方式（アプリケーションのアクセス許可）には、大きな違いがあります。

設定を誤ると、意図しないデータ漏えい、コンプライアンス上の問題、さらにはセキュリティインシデントを招くおそれがあります。正しく設計すれば、より円滑な自動化、明確なガバナンス、そして監査担当者の満足につながります。本ガイドでは、これらのアクセス許可の種類の基本的な仕組み、実際の運用での動作、そして環境に最適な選択をするために必要なセキュリティ、ガバナンス、運用面の観点を網羅的に解説します。アクセス許可を正しく位置づけましょう。大きな権限には、それに見合った重い責任が伴うのですから。

Microsoft ID におけるアクセスモデルの背景と概要

Microsoft Entra ID のアクセス許可は、単にチェックボックスをオンにするためのものではありません。Microsoft 365、Azure などにまたがって、アプリとユーザーがどのように連携するかを支える基本的な仕組みです。Microsoft が ID をクラウドに移行した際、サービスやサードパーティ製ツールが、すべてのものをすべての人に無制限に開放することなく、安全にやり取りできる方法が必要でした。そこで登場したのが、委任されたアクセス許可とアプリケーションのアクセス許可です。

これらのモデルにより、誰が何にアクセスできるかを細かく管理できます。個々のユーザーが承認できる範囲と、管理者のみが許可すべき範囲の境界を明確にできるのです。従来の AD サービスアカウントや、すべてか無かかの大雑把なアクセス制御から得た教訓（時には痛い経験を伴うものでした）の結晶といえます。これらのモデルを理解することは、単なる基本的な衛生管理ではありません。コンプライアンスへの対応、ゼロトラストの実践、そしてセキュリティの設定ミスによって日々の運用が止まらないようにするうえで、極めて重要です。

アプリケーションのアクセス許可と委任されたアクセス許可: 中核となる概念と実際のシナリオ

委任されたアクセス許可とアプリケーションのアクセス許可の違いを、分かりやすく整理します。委任されたアクセス許可は、アプリが「補助役」として動く仕組みと考えてください。特定のユーザーがサインインしている間だけアクセスでき、そのユーザーができる操作の範囲に限定されます。一方、アプリケーションのアクセス許可では、アプリが独自の鍵束を持つ、監視のない管理者のように独立して動作します。その際にユーザーが存在する必要はまったくありません。

委任されたアクセス許可では、認証に必ずユーザーが関与します。たとえば、ユーザーのメールやカレンダーにアクセスする必要があるアプリにサインインすると、そのユーザーの権限で一時的にアプリが動作することを許可したことになります。ユーザーがサインアウトすると、この一時的な権限は失効します。これは、Web フロントエンド、Teams ボット、モバイルの生産性アプリなど、ユーザーの要求に応じて処理を行うアプリに最適です。

アプリケーションのアクセス許可では、アプリ自体が独自の ID（サービスプリンシパル）として認証され、独自のトークンを取得します。これは、SharePoint と CRM の間でデータを夜間に同期するシステム連携のような、自動化やバックグラウンドジョブを支える仕組みです。ユーザーの操作は不要で、アプリは独自のスケジュールと、管理者が承認したアクセスレベルの範囲内でタスクを実行します。

たとえば、ユーザーのプロビジョニングを自動化する必要があるとします。夜間にユーザーアカウントを静かに更新するバックグラウンドサービスです。この場合、アクセスを承認する人が待機しているわけではないため、委任されたアクセス許可は役に立ちません。一方、ユーザーがアクティブな間にパーソナライズされた機能を提供する必要がある場合、たとえば OneDrive と連携するドキュメント署名アプリなら、委任されたアクセス許可が力を発揮します。

実際のシナリオでは、両方を組み合わせることが多くあります。そのため、ユースケースにどちらのモデルが適しているかを把握することは、ユーザーエクスペリエンス、ガバナンス、セキュリティのいずれにおいても重要です。必要以上の鍵を渡したくはありませんが、深夜3時に誰もサインインしていないためサービスが締め出される事態も避けたいものです。

Microsoft Entra の委任されたアクセス許可の内部: 認証フローと制限事項

Microsoft Entra IDの委任されたアクセス許可は、ユーザーが操作する従来型の認証フローに沿って動作します。ユーザーがMicrosoftの資格情報を使ってアプリケーションにサインインすると、このフローが始まります。この時点で、アプリは特定のアクセス許可（スコープ）を要求し、どの種類のデータや操作へのアクセスを求めているのかをユーザー（場合によっては管理者）に示します。

要求されたアクセス許可がユーザーの同意のみで足りる場合、ユーザーは同意画面でその場で承認できます。組織内のすべてのユーザーのメールボックスを読み取るなど、より機密性の高いアクセス許可には管理者の同意が必要です。同意が得られると、アプリはユーザーのIDと割り当てられたロールに直接紐づいたアクセストークンを受け取ります。

このアクセストークンによって、アプリはMicrosoft GraphやMicrosoft 365のAPIを呼び出せます。ただし、常にユーザーの権限のもとで動作します。そのため、ユーザーが一般社員であれば、アプリが突然管理者向けの機能に手を伸ばすことはできません。ユーザーがサインアウトした時点で、アプリのアクセスも失効します。これにより、影響範囲を小さく抑えられます。

ただし、委任されたアクセス許可には限界があります。無人で動作するシナリオでは機能しにくいのです。バックグラウンド処理、cronジョブ、ユーザーのログインを前提としないサービス連携を実行する場合、委任されたアクセス許可では対応できません。すべてがユーザーの存在に依存するため、サポート業務、自動化、夜間バッチ処理はいずれも行き詰まってしまいます。

セキュリティ面の検討も必要です。広範なアクセス権を持つユーザーが巧妙に同意させられると、アプリがそのアクセス許可を悪用するおそれがあります。これは同意フィッシング攻撃の代表的な手口です。そのため、どのユーザーがどのアクセス許可を付与できるかを厳格に管理し、同意画面が実際に何を意味するのかについて、十分な啓発トレーニングを行うことが欠かせません。

Microsoft Entra IDにおけるアプリアクセスの過剰な許可とトークンのセキュリティ

アクセス許可に関しては、多ければ良いわけではありません。実際、過剰な許可、つまり不要または過度な権限を与えることは、特にアプリケーションのアクセス許可で顕著ですが、機密データの漏えいや重大なセキュリティインシデントを招くおそれがあります。たとえば、アプリに会社全体のすべてのメールボックスへの読み取りと書き込みのアクセスを与えたとします。実際に必要なのが予定表イベントの読み取りだけだったとすると、攻撃対象領域を不必要に大きくしてしまったことになります。

この危険は理論上のものではありません。攻撃者はOAuthの同意の悪用を利用し、多要素認証さえも回避しています。巧妙な同意プロンプトでユーザーや管理者をだまし、リスクの高いアクセス許可を承認させるのです。いったん侵入されると、悪意のあるアプリはパスワードが変更されたり、MFAが強制されたりしても、アクセスを維持することが少なくありません。攻撃者の影響力は持続し、従来の防御策では効果が見込めなくなります。実際の事例を詳しく知りたい方は、こちらの解説をご覧ください。攻撃者がEntra IDでOAuthの同意を悪用する仕組みと、それを防ぐための最善の方法を紹介しています。

議論は過剰な許可だけにとどまりません。トークンや資格情報（クライアントシークレットや証明書を含む）も、適切に保護されていなければ攻撃者にとって格好の標的になります。アプリのみの登録で漏えいしたクライアントシークレットがあれば、攻撃者はそのサービスになりすますことができてしまいます。そのため、資格情報の衛生管理が不可欠です。可能な限りマネージドIDを使用し、シークレットを定期的にローテーションし、クライアント資格情報をコードや保護されていないファイルに保存しないようにしましょう。人間以外によるアクセスに依存する環境では、Microsoft Entra ワークロード ID の利用も検討してください。シークレットを使わずに監査可能なアクセスを実現でき、従来のサービスアカウントにまつわる面倒な問題も解消できます。ゼロトラストにワークロード IDが欠かせない理由について、さらに詳しくはこちらの解説をご覧ください。

最後に、適切な監視は欠かせません。サインインログとOAuthの付与を定期的に確認し、不審な同意やトークンの使用に対してアラートを設定して、同意フィッシングやトークンの窃取に先手を打ちましょう。実際の侵害事例（Microsoft 365の攻撃チェーンなど）からは、攻撃者が統制の甘いガバナンスを突いていることがわかっています。可視性が高いほど、防御は確かなものになります。鍵を守り、アクセス許可を絞り込み、アプリを適正に保ちましょう。