委任されたアクセス許可戦略の策定
この記事は、開発者がアプリケーションでのアクセス許可を管理するための最適なアプローチを実装し、ゼロ トラスト原則を使用して開発するのに役立ちます。 「リソースにアクセスするための認証の取得」で説明されているように、委任されたアクセス許可は委任されたアクセスと共に使用され、アプリケーションがユーザーに代わって動作し、ユーザーがアクセスできるもののみにアクセスできるようにします。 アプリケーションのアクセス許可は、直接アクセスと共に使用され、アプリケーションがアクセス許可が関連付けられているすべてのデータにアクセスできるようにします。 管理者とサービス プリンシパルの所有者のみが、アプリケーションのアクセス許可に同意できます。
アクセス許可と同意のモデルは、主にアプリケーションを参照します。 アクセス許可と同意のプロセスでは、ユーザーが実行できる操作を制御できません。 アプリケーションで実行できるアクションを制御します。
次のベン図を参照してください。 委任されたアクセス許可を使用すると、ユーザーが実行できる操作とアプリケーションで実行できる操作の間に共通部分ができます。 この共通部分は、アプリケーションがバインドされる有効なアクセス許可です。 委任されたアクセス許可を使用するたびに、有効なアクセス許可によって制限されます。
たとえば、アプリの前にユーザーが存在するアプリケーションは、テナント内のすべてのユーザーのプロファイルを更新するアクセス許可を取得します。 これは、アプリケーションを実行するすべてのユーザーが他のユーザーのプロファイルを更新できることを意味するわけではありません。 管理者がアプリケーションに User.ReadWrite.All を付与することを決定した場合、その管理者はユーザー プロファイルを更新するときにアプリケーションが適切な処理を行っていると考えます。 アプリによって変更がログに記録され、情報が適切に保護される場合があります。 管理者は、ユーザーではなく、アプリケーションに関する価値の判断を行います。
最小権限アプローチ
API は複雑になる可能性があります。 単純な API には操作があまりない場合があります。 Microsoft Graph などの複雑な API は、アプリケーションが使用する可能性がある多くの要求をカプセル化します。 アプリケーションに読み取る権利があるからといって、更新する権利が必要というわけではありません。 たとえば、Microsoft Graph には何千もの API があります。 ユーザーのプロファイルを読み取る権限があるからといって、すべての OneDrive ファイルを削除する権限も必要だという理由はありません。
開発者は、次の手順を実行する必要があります。
- アプリが呼び出す API を把握する。
- API のドキュメントと、API に必要なアクセス許可について理解する。
- 最小限のアクセス許可でタスクを実行する。
API は、多くの場合、組織のデータ ストアへのアクセスを提供し、そのデータにアクセスする攻撃者の注目を集めます。
要求したアクセス許可を評価して、ジョブを完了するために絶対的な最小限の特権セットを確実にシークするようにします。 より高い権限のアクセス許可を要求しないでください。代わりに、Microsoft Graph などの API が提供する多数のアクセス許可を慎重に処理してください。 必要に応じ、最小限のアクセス許可を見つけて使用してください。 ユーザーのプロファイルを更新するコードを記述しない場合、アプリケーションに対して要求しません。 ユーザーとグループにのみアクセスする場合、ディレクトリ内の他の情報へのアクセスは要求しません。 ユーザー メールにアクセスするコードを記述しない場合、ユーザー メールを管理するためのアクセス許可は要求しません。
ゼロ トラスト アプリケーション開発の場合:
- アプリケーションの意図と必要なものを定義します。
- 不正を行う者がアプリを意図していない方法で侵害して使用することができないようにします。
- 要件を定義する承認の要求を行います (ユーザーのメールの読み取りなど)。
アクセス許可と同意でのユーザーとテナント管理者の役割
要求を承認できるユーザーは、アクセス許可の要求にいつでも同意できる管理者と、管理者ではない通常のユーザーの 2 つのカテゴリに分類されます。 ただし、テナント管理者は、管理者の同意が必要なアクセス許可と、ユーザーが同意できるアクセス許可に関する最終決定をテナントで行います。
API 設計者でアクセス許可に対する管理者の同意が必要な場合、そのアクセス許可には常に管理者の同意が必要です。テナント管理者はそれを無効にしたり、必要なものをユーザーの同意のみとしたりすることはできません。
API 設計者がユーザーの同意を必要とするアクセス許可を定義する場合、API 設計者によるユーザーの同意の提案は、テナント管理者によって無効にされる可能性があります。テナント管理者は、テナント内の "ビッグ スイッチ" でこれを行うことができます。すべてが管理者の同意を必要とします。 テナント管理者は、アクセス許可と同意の管理により、ユーザーの同意を細分性をより高くして無効にできます。 たとえば、テナント管理者は、ユーザーが検証済みの発行元からのユーザーの同意の要求に同意でき、他の発行元からのものには同意できないようにすることができます。 別の例としては、テナント管理者は、User.Read がユーザーのサインインとプロファイルの読み取りを行えるようにしつつ、メールまたはファイルへのアクセス許可を求めるアプリに対する管理者の同意を必要とするようにできます。
API 設計者は提案を行いますが、テナント管理者には最終決定権があります。 そのため、開発者は、アプリで管理者の同意が必要なタイミングを常には把握できません。 それを計画して設計するのは良いことですが、トークン要求を行うときは、何らかの理由で拒否される可能性があることを覚えておいてください。 アクセス許可に管理者の同意が必要なタイミングは、顧客またはユーザーがアプリケーションを実行しているテナント管理者が決定するため、コードではトークンの取得を適切に処理する必要があります。
JavaScript MSAL の使用例
この例の認証では、JavaScript Microsoft Authentication Library (MSAL) を使用して、すべてのアプリ ロジックがブラウザーから実行されるシングル ページ アプリケーション (SPA) でユーザーをサインインさせます。
関連するクイックスタートの記事から、コード サンプルをダウンロードして実行できます。 これは、JavaScript シングルページ アプリケーション (SPA) が、Proof Key for Code Exchange (PKCE) による認証コード フローを使用して、ユーザーをサインインしたり、Microsoft Graph を呼び出したりする仕組みを示しています。 このコード サンプルは、Microsoft Graph API または任意の Web API を呼び出すためのアクセス トークンを取得する方法を示しています。
次のコード例に示すように、ブラウザーで完全に実行されるアプリケーションはパブリック クライアントである必要があるため、パブリック クライアントをインスタンス化します。 ユーザーは、コードがブラウザーにあるときに、アプリケーションの内部情報を取得することができます。
// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);
その後、MSAL ライブラリを使用します。 MSAL JavaScript には、サインインする特定の API があります。 ブラウザー内で特定の機能を利用する API は 2 つあります。 1 つは、ポップアップ エクスペリエンスでサインインし、もう 1 つは、ブラウザーのリダイレクト エクスペリエンスでサインインします。
次のコード例に示すように、サインイン ポップアップは、ユーザーが signIn 関数を呼び出すことによって実行する必要がある認証を処理します。
function signIn() {
/**
* You can pass a custom request object below. This will override the initial configuration. For more information, visit:
* https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
*/
myMSALObj.loginPopup(loginRequest)
.then(handleResponse)
.catch(error => {
console.error(error);
});
}
アプリは、ユーザーの表示名やユーザー ID など、ユーザーに関する情報を取得できます。 次に、MSAL ライブラリ全体で使用するパターンに従って、Microsoft Graph からユーザーの完全なプロファイルを読み取る承認がアプリに必要です。
次のコード例に示すように、アプリは AcquireTokenSilent を呼び出して承認を取得しようとします。 Microsoft Entra ID がユーザーと対話せずにトークンを発行できる場合は、AcquireTokenSilent がアプリがユーザーの代わりに Microsoft Graph にアクセスするのに必要なトークンを返します。
function getTokenPopup(request) {
/**
* See here for more info on account retrieval:
* https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
*/
request.account = myMSALObj.getAccountByUsername(username);
return myMSALObj.`AcquireTokenSilent`(request)
.catch(error => {
console.warn("silent token acquisition fails. acquiring token using popup");
if (error instanceof msal.InteractionRequiredAuthError) {
// fallback to interaction when silent call fails
return myMSALObj.`AcquireTokenPopup`(request)
.then(tokenResponse => {
console.log(tokenResponse);
return tokenResponse;
}).catch(error => {
console.error(error);
});
} else {
console.warn(error);
}
});
}
ただし、多くの場合、Microsoft Entra ID は、ユーザーと対話しないとトークンを発行できません (たとえば、ユーザーがパスワードを変更した場合や、同意を付与していない場合など)。 そのため、AcquireTokenSilent はユーザーとの対話が必要なアプリケーションにエラーを返します。 アプリがエラーを受け取ると、AcquireTokenPopup の呼び出しにフォールバックされます。
この時点で、Microsoft Entra ID は、ユーザーを認証し、アプリがユーザーに代わって動作することを承認できるように、ユーザーとの会話を行います (たとえば、MFA の実行、パスワードの提供、同意の付与など)。 その後、アプリは次に進むのに必要なトークンを取得します。
ゼロ トラストへの企業の取り組みの主なステップは、ユーザー ID とパスワードだけでなく、より強力な認証方法を採用することです。 上記のコード例を使用すると、企業は、企業が選択したより強力な認証方法に完全に移行できます。 たとえば、多要素認証、FIDO2 キーを使用した完全なパスワードレス、Microsoft Authenticator などです。
次のステップ
- リソースにアクセスするための承認を取得すると、アプリケーションのリソース アクセス許可を取得するときにゼロ トラストを確実に行う方法を理解するのに役立ちます。
- アプリケーションのアクセス許可戦略の開発は、資格情報管理に対するアプリケーションのアクセス許可アプローチを決定するのに役立ちます。
- トークンのカスタマイズでは、Microsoft Entra トークンで受信することができる情報と、最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御を向上させるためにトークンをカスタマイズする方法について説明します。
- グループ クレームとアプリケーション ロールをトークンに設定するでは、アプリケーション ロール定義を使用してアプリケーションを構成し、セキュリティ グループをアプリケーション ロールに割り当てて柔軟性とコントロールを向上させ、最小特権の原則でアプリケーションのゼロ トラスト セキュリティを強化する方法を説明します。
- API 保護では、登録を通じて API を保護し、アクセス許可と同意を定義し、ゼロ トラストの目標を達成するためのアクセスを強制するためのベスト プラクティスについて説明します。
- 別の API からの API の呼び出しは、別の API を呼び出す必要があるAPI がある場合にゼロ トラストを確実に適用し、ユーザーのために動作するアプリケーションをセキュリティを確保して安全に開発する方法について説明します。
- 承認のベスト プラクティスは、アプリケーションに最適な承認、アクセス許可、および同意モデルを実装するのに役立ちます。
- 「ゼロ トラスト ID およびアクセス管理の開発のベスト プラクティス」をアプリケーション開発ライフサイクルで使用して、セキュリティで保護されたアプリケーションを作成します。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示