リソースにアクセスするための認可を得る

開発者は、この記事を読むと、アプリケーションのリソース アクセス許可を取得するときにゼロ トラストを実現する最適な方法を理解できます。 アプリケーションで、メール、予定表のデータなどの保護されたリソースにアクセスするには、リソース所有者の認可が必要です。 リソース所有者は、アプリの要求に "同意" すること、または拒否することができます。 リソース所有者が同意すると、アプリはアクセス トークンを受け取ります。リソース所有者がアクセスを拒否すると、アプリはアクセス トークンを受け取りません。

概念レビュー

Microsoft ID プラットフォームを使用して、アプリケーションを認証および承認し、アクセス許可と同意を管理できます。 いくつかの概念から始めましょう。

• 認証 (AuthN に短縮される場合もあり) は、要求された ID が正確であることを証明するプロセスです。 Microsoft ID プラットフォームでは、認証の処理に OpenID Connect プロトコルが使用されます。 承認 (AuthZ に短縮される場合もあり) は、認証されたパーティに何かを行うアクセス許可を付与します。 認証されたパーティがアクセスできるデータを指定します。 Microsoft ID プラットフォームでは、承認の処理に OAuth2.0 プロトコルが使用されます。 承認オプションには、アクセス制御リスト (ACL)、ロールベースのアクセス制御、属性アクセス制御 (ABAC) が含まれます。 多くの場合、認証は承認の要素です。

• アプリケーションは、委任アクセス (サインインしているユーザーに代わって動作) または直接アクセス (アプリケーション自体の ID としてのみ動作) を使って、データにアクセスできます。 委任アクセスには、委任されたアクセス許可 (スコープとも呼ばれます) が必要です。要求を行うには、クライアントとユーザーを個別に承認する必要があります。 直接アクセスには、アプリケーションのアクセス許可 (アプリ ロールとも呼ばれます) が必要な場合があります。アプリケーションに付与されたアプリ ロールは、アプリケーションのアクセス許可と呼ばれることがあります。

• 委任されたアクセスで使用される委任されたアクセス許可では、アプリケーションがユーザーに代わって動作し、ユーザーがアクセスできるアクセスのみを許可します。 直接アクセスで使用されるアプリケーションのアクセス許可では、アプリケーションはアクセス許可が関連付けられているデータにアクセスできます。 管理者とサービス プリンシパルの所有者のみが、アプリケーションのアクセス許可に同意できます。

• "同意" は、アプリケーションがアクセス許可を受け取る方法です。 ユーザーまたは管理者が、保護されたリソースにアプリケーションがアクセスすることを認可します。 同意プロンプトには、アプリケーションに必要なアクセス許可とパブリッシャー情報が一覧表示されます。

• "事前認可" は、リソース アプリケーションの所有者がクライアント アプリへのアクセスを許可する方法です。 Azure portal で、または PowerShell と Microsoft Graph などの API を使って、それを行うことができます。 事前認可されたアクセス許可のセットに対する同意プロンプトをユーザーに表示する必要なしに、リソースのアクセス許可を付与できます。

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

アプリケーションは、ユーザーが存在する場合 (委任されたアクセス許可) と、ユーザーがいない場合 (アプリケーションのアクセス許可) の 2 つのモードで動作します。 アプリケーションの前にユーザーがいる場合は、そのユーザーの代わりに行動する必要があります。アプリケーション自体の代わりに動作するべきではありません。 ユーザーがアプリケーションを指示している場合は、そのユーザーの代理人として機能します。 トークンが識別するユーザーに代わって機能するアクセス許可を取得しています。

サービスの種類のアプリケーション (バックグラウンド タスク、デーモン、サーバー間プロセス) には、自分を識別したり、パスワードを入力したりできるユーザーがいません。 サービス アプリケーションの代理として機能するには、アプリケーションのアクセス許可が必要です。

ゼロ トラスト アプリケーション承認のベスト プラクティス

アプリケーションおよび呼び出し先リソースに存在するユーザーに接続するとき、認可アプローチはコンポーネントとして認証を持っています。 アプリケーションがユーザーに代わって機能している場合、ユーザーが誰であるかを通知したり、アプリケーションがユーザーを決定したりするための呼び出し元アプリケーションは信頼されません。 Microsoft Entra ID は、トークン内のユーザーに関する情報を検証し、直接提供します。

アプリケーションがリソースにアクセスできるように、アプリケーションが API を呼び出すか、アプリケーションを承認する必要がある場合、最新の承認スキームでは、アクセス許可と同意フレームワークによる承認が必要になる場合があります。 リダイレクト URI、アクセス トークン (暗黙的なフローに使用)、証明書とシークレット、アプリケーション ID URI、およびアプリケーションの所有権を含む「アプリケーション プロパティのセキュリティのベスト プラクティス」を参照してください。

次のステップ

• 「トークンのカスタマイズ」では、Microsoft Entra トークンで受け取ることができる情報について説明しています。 最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御性を向上させるようにトークンをカスタマイズする方法について説明しています。
• 「トークンでのグループ要求とアプリ ロールの構成」は、アプリ ロール定義を使用してアプリを構成し、セキュリティ グループをアプリ ロールに割り当てる方法を説明しています。 これらの方法は、最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御性を向上させるのに役立ちます。
• 「委任されたアクセス許可戦略の策定」は、アプリケーションのアクセス許可を管理するための最適なアプローチを実装し、ゼロ トラスト原則を使用して策定するのに役立ちます。
• 「アプリケーションのアクセス許可戦略の開発」は、資格情報管理に対するアプリケーションのアクセス許可のアプローチを決定するのに役立ちます。
• 「ユーザーがいない場合にアプリケーション ID 資格情報を提供する」では、Azure リソース用マネージド ID が Azure 上のサービス (非ユーザー アプリケーション) に対するクライアント資格情報のベスト プラクティスである理由について説明します。
• 承認のベスト プラクティスは、アプリケーションに最適な承認、アクセス許可、および同意モデルを実装するのに役立ちます。
• 「ゼロ トラスト ID およびアクセス管理の開発のベスト プラクティス」をアプリケーション開発ライフサイクルで使用して、セキュリティで保護されたアプリケーションを作成します。
• ID に対するゼロ トラストアプローチを使用したアプリの構築は、ゼロ トラスト ID およびアクセス管理の開発のベスト プラクティスに関する記事から引き続き行われ、ソフトウェア開発ライフサイクル (SDLC) で ID にゼロ トラストアプローチを使用するのに役立ちます。