承認のベスト プラクティス

ゼロ トラストの原則の使用を開始する方法を学習する上で、この記事は、「リソースへアクセスするための認可の取得」、「委任されたアクセス許可戦略の策定」、「アプリケーションのアクセス許可戦略の策定」に続くものです。 これは、あなたが開発者としてアプリケーションにとって最適な認可、アクセス許可、同意モデルを実装するのに役立ちます。

アクセス制御が必要なアプリケーションまたはソリューション内に認可ロジックを実装できます。 認証方法が認証済みエンティティに関する情報に依存している場合、アプリケーションは認証時に交換される情報 (セキュリティ トークン内で提供される情報など) を評価できます。 セキュリティ トークンに情報が含まれていない場合、アプリケーションは外部リソースを呼び出すことができます。

認可ロジックをアプリケーション内に完全に埋め込む必要はありません。 代わりに、専用の認可サービスを使用して、認可の実装と管理を一元化することができます。

アクセス許可のベスト プラクティス

Microsoft Entra ID で最も広く採用されているアプリケーションは、同意と認可のベスト プラクティスに従います。 「Microsoft Graph の操作に関するベスト プラクティス」と「Microsoft Graph のアクセス許可リファレンス」を確認して、アクセス許可要求を熟考する方法を確認します。

• 最小限の特権を適用します。 必要なアクセス許可のみを要求します。 増分同意を使用して、詳細なアクセス許可を適時要求します。 ジャスト・イン・タイムおよびジャスト・エナフ・アクセス（JIT/JEA）、リスクベースのアダプティブ・ポリシー、データ保護により、ユーザー・アクセスを制限します。

• シナリオに基づいて適切なアクセス許可の種類を使います。 同じアプリでアプリケーションと委任されたアクセス許可の両方を使用しないでください。 サインインしているユーザーが存在する対話型アプリケーションを構築する場合は、アプリケーションで委任されたアクセス許可を使う必要があります。 ただし、バックグラウンド サービスやデーモンなど、サインインしているユーザーなしでアプリケーションを実行する場合は、アプリケーションでアプリケーションのアクセス許可を使う必要があります。

• サービス使用条件とプライバシー ステートメントを提供します。 ユーザーの同意エクスペリエンスにより、サービス使用条件とプライバシー ステートメントがユーザーに表示され、アプリが信頼できるものであることを伝えます。 これらはユーザー向けマルチテナント アプリで特に重要です。

アクセス許可を要求するタイミング

一部のアクセス許可では、管理者がテナント内で同意を付与する必要があります。 管理者の同意エンドポイントを使用し、テナント全体にアクセス許可を付与できます。 アクセス許可またはスコープを要求するために従うことができるモデルは 3 つあります。

• サインイン時または最初のアクセス トークン要求時に動的なユーザーの同意を実装します。 動的なユーザーの同意では、アプリの登録に何も必要ありません。 特定の条件下で必要なスコープを定義できます (初めてユーザーをサインインする場合など)。 そのアクセス許可を要求し、同意を受け取った後は、アクセス許可を要求する必要はありません。 しかし、サインイン時または最初のアクセス時に動的なユーザーの同意を得られない場合、それはアクセス許可エクスペリエンス全体に影響を与えます。

• 必要に応じて、増分のユーザーの同意を要求します。 増分の同意と動的なユーザーの同意を組み合わせることで、一度にすべてのアクセス許可を要求する必要はありません。 いくつかのアクセス許可を要求した上で、ユーザーがアプリケーション内の異なる機能に移動する際に、追加の同意を要求することができます。 このアプローチでは、ユーザーがアプリケーションにアクセス許可を段階的に付与することで、ユーザーの快適性レベルを上げることができます。 たとえば、アプリケーションが OneDrive へのアクセスを要求する場合に、Calendar へのアクセスも要求していると、疑いを生じさせるかもしれません。 代わりに、後で OneDrive に対してカレンダーのリマインダーを追加するようにユーザーに依頼します。

• /.default スコープを使用します。 /.default スコープは、アプリケーションの登録に入力した内容を確認し、必要な同意を把握し、まだ付与されていないすべての同意を求めるという前の既定のエクスペリエンスを効果的に模倣します。 必要なアクセス許可はアプリの登録に含まれているため、コードに含める必要はありません。

検証済みの発行元になる

Microsoft のお客様は、ユーザーのサインインまたは API の呼び出しによって、アプリケーションがMicrosoft ID プラットフォームにアクセスできるようにするタイミングを決定するのが難しい場合があります。 ゼロ トラストの原則を採用する際、次のことが必要です。

• 可視性と制御の強化。
• より積極的で簡単な事後対応型の意思決定。
• データを安全に保ち、意思決定の負担を軽減するシステム。
• 信頼できる開発者向けアプリの導入の高速化。
• 発行元が検証するリスクの低いアクセス許可を持つアプリに対する制限付き同意。

Microsoft Graph などの API 内のデータへのアクセス権は、リッチなアプリケーションの構築を可能にしますが、組織や顧客は、アプリが要求するアクセス許可をアプリの信頼性と共に評価します。

Microsoft Verified Publisher になると、アプリケーション要求を承諾する際のエクスペリエンスを顧客に簡単に提供できます。 アプリケーションが検証済みの発行元から取得された場合、ユーザー、IT 担当者、および顧客は、Microsoft とビジネス関係を持つユーザーからアプリケーションを取得していることを知っています。 発行元の名前の横に青いチェックマークが表示されます (下のアクセス許可要求同意プロンプトの例のコンポーネント #5。Microsoft Entra アプリケーションの同意エクスペリエンスのコンポーネント テーブルを参照してください)。 ユーザーは、同意プロンプトから検証済みの発行元を選択して、詳細情報を表示できます。

検証済みの発行元である場合、ユーザーと IT 担当者は、検証済みのエンティティであることから、アプリケーションを信頼します。 発行元の検証により、アプリケーションのブランド化が向上し、透明性が向上し、リスクが軽減され、顧客に対して企業の導入がスムーズになります。

次のステップ

• 「委任されたアクセス許可戦略の策定」は、アプリケーション内のアクセス許可を管理するための最適なアプローチを実装し、ゼロ トラスト原則を使用して開発を行うのに役立ちます。
• 「アプリケーションのアクセス許可戦略の策定」は、資格情報管理に対するアプリケーションのアクセス許可のアプローチを決定するのに役立ちます。
• 「ゼロ トラスト ID およびアクセス管理の開発のベスト プラクティス」をアプリケーション開発ライフサイクルで使用して、セキュリティで保護されたアプリケーションを作成します。
• アプリケーション プロパティ のセキュリティのベスト プラクティスでは、リダイレクト URI、アクセス トークン、証明書とシークレット、アプリケーション ID URI、アプリケーションの所有権について説明します。
• 「トークンのカスタマイズ」では、Microsoft Entra トークンで受け取ることができる情報について説明しています。 最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御性を向上させるようにトークンをカスタマイズする方法について説明しています。
• 「トークンでのグループ要求とアプリ ロールの構成」では、アプリ ロール定義を使用してアプリを構成し、セキュリティ グループをアプリ ロールに割り当てる方法を示します。 これらの方法は、最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御性を向上させるのに役立ちます。
• API 保護では、登録を通じて API を保護し、アクセス許可と同意を定義し、ゼロ トラストの目標を達成するためのアクセスを強制するためのベスト プラクティスについて説明します。
• 「リソースにアクセスするための認可の取得」は、アプリケーションのリソース アクセス許可を取得するときにゼロ トラストを保証する最善の方法を理解するのに役立ちます。