この記事は、開発者が、アプリケーションのリソース アクセス許可を取得するときに ゼロ トラスト を最も確実にする方法を理解するのに役立ちます。 電子メールや予定表データなどの保護されたリソースにアクセスするには、アプリケーションでリソース所有者の 承認が必要です。 リソース所有者は、アプリの要求に 同意 または拒否できます。 リソース所有者が同意を付与すると、アプリはアクセス トークンを受け取ります。リソース所有者がアクセスを拒否しても、アプリはアクセス トークンを受け取りません。
概念レビュー
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 トークンで受け取ることができる情報について説明します。 最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御を向上させるためにトークンをカスタマイズする方法について説明します。
- 「トークンでのグループ要求とアプリ ロールの構成」は、アプリ ロール定義を使用してアプリを構成し、セキュリティ グループをアプリ ロールに割り当てる方法を説明しています。 これらの方法は、最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御を向上するのに役立ちます。
- 委任されたアクセス許可戦略を開発 すると、アプリケーションでアクセス許可を管理するための最適なアプローチを実装し、ゼロ トラスト原則を使用して開発することができます。
- アプリケーションのアクセス許可戦略を開発 すると、資格情報管理に対するアプリケーションのアクセス許可アプローチを決定するのに役立ちます。
- Azure リソースのマネージド ID が Azure 上のサービス (非ユーザー アプリケーション) に最適なクライアント資格情報プラクティスである理由を説明するユーザーがいない場合は、アプリケーション ID 資格情報を指定します。
- 承認のベスト プラクティスは 、アプリケーションに最適な承認、アクセス許可、および同意モデルを実装するのに役立ちます。
- アプリケーション開発ライフサイクル ゼロ トラスト ID とアクセス管理開発のベスト プラクティスを使用して、セキュリティで保護されたアプリケーションを作成します。
- ゼロ トラスト アプローチを用いたIDを中心としたアプリの構築は、ゼロ トラスト アイデンティティとアクセス管理の開発におけるベストプラクティスに関する記事の続きであり、ソフトウェア開発ライフサイクル (SDLC) でゼロ トラスト アプローチによるIDの活用を支援します。