認証強度は、ユーザーがリソースへのアクセスに使用できる認証方法の組み合わせを指定する Microsoft Entra 条件付きアクセス制御です。 ユーザーは、許可されている組み合わせのいずれかを使って認証を行うことで、強度要件を満たすことができます。
たとえば、認証強度では、機密性の高いリソースにアクセスするために、フィッシングに強い認証方法のみを使用するようにユーザーに要求できます。 無知なリソースにアクセスするために、管理者は、パスワードやテキスト メッセージなど、安全性の低い多要素認証 (MFA) の組み合わせを可能にする別の認証強度を作成できます。
認証強度は、 認証方法のポリシーに基づいています。 つまり、管理者は、Microsoft Entra ID フェデレーション アプリケーション全体で使用する特定のユーザーとグループの認証方法のスコープを設定できます。 認証強度により、機密性の高いリソース アクセス、ユーザー リスク、場所などの特定のシナリオに基づいて、これらの方法の使用方法をさらに制御できます。
前提条件
- 条件付きアクセスを使用するには、テナントに Microsoft Entra ID P1 ライセンスが必要です。 このライセンスをお持ちでない場合は、 無料試用版を開始できます。
認証強度のシナリオ
認証強度を使用すると、お客様が次のようなシナリオに対処するのに役立ちます。
- 機密リソースにアクセスするために、特定の認証方法を要求します。
- ユーザーがアプリケーション内で機密アクションを実行するときに、特定の認証方法を要求します (条件付きアクセス認証コンテキストとの組み合わせ)。
- 企業ネットワークの外部にある機密性の高いアプリケーションにアクセスする場合は、ユーザーに特定の認証方法の使用を要求します。
- リスクの高いユーザーに、より安全な認証方法を要求します。
- リソース テナントにアクセスするゲスト ユーザーに、特定の認証方法を要求します (テナント間の設定との組み合わせ)。
組み込みおよびカスタム認証の強度
管理者は、[認証強度が必要] コントロールで条件付きアクセス ポリシーを作成することで、リソースにアクセスするための認証強度を指定できます。 3 つの組み込み認証強度 (多要素認証強度、パスワードレス MFA 強度、フィッシングに強い MFA 強度) から選択できます。 また、許可する認証方法の組み合わせに基づいて、カスタム認証強度を作成することもできます。
組み込みの認証強度
組み込みの認証強度は、Microsoft が事前に定義した認証方法の組み合わせです。 組み込みの認証強度は常に使用でき、変更することはできません。 Microsoft では、新しい方法が利用可能になったときに、組み込みの認証強度を更新します。
たとえば、組み込みの フィッシング耐性 MFA 強度 認証強度では、次の組み合わせが可能になります。
- Windows Hello for Business またはプラットフォームの資格情報
- FIDO2 セキュリティ キー
- Microsoft Entra 証明書ベースの認証 (多要素)
次の表に、組み込みの各認証強度の認証方法の組み合わせを示します。 これらの組み合わせには、ユーザーが登録する必要があり、管理者が認証方法のポリシーまたは従来の MFA 設定のポリシーで有効にする必要がある方法が含まれます。
- MFA の強度: 多要素認証を要求 する設定を満たすために使用できる組み合わせの同じセット。
- パスワードレス MFA の強度: MFA を満たすがパスワードを必要としない認証方法が含まれます。
- フィッシングに強い MFA 強度: 認証方法とサインイン画面の間の対話を必要とする方法が含まれます。
| 認証方法の組み合わせ | MFA 強度 | パスワードレス MFA 強度 | フィッシングに強い MFA 強度 |
|---|---|---|---|
| FIDO2 セキュリティ キー | ✅ | ✅ | ✅ |
| Windows Hello for Business またはプラットフォームの資格情報 | ✅ | ✅ | ✅ |
| 証明書ベースの認証 (多要素) | ✅ | ✅ | ✅ |
| Microsoft Authenticator (電話によるサインイン) | ✅ | ✅ | |
| 一時的なアクセス パス (1 回限りで複数回使用) | ✅ | ||
| パスワードとユーザーが持っているもの1 | ✅ | ||
| フェデレーション単一要素とユーザーが 1 を持つもの | ✅ | ||
| フェデレーション多要素 | ✅ | ||
| 証明書ベースの認証 (単一要素) | |||
| SMS サインイン | |||
| パスワード | |||
| フェデレーションシングルファクター | |||
| QRコード |
1ユーザーが持っているものは 、テキスト メッセージ、音声、プッシュ通知、ソフトウェア OATH トークン、またはハードウェア OATH トークンのいずれかの方法を指します。
次の API 呼び出しを使用して、すべての組み込みの認証強度の定義を一覧表示できます。
GET https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies?$filter=policyType eq 'builtIn'
カスタム認証強度
条件付きアクセス管理者は、アクセス要件に正確に合わせてカスタム認証の強度を作成することもできます。 詳細については、「 カスタム条件付きアクセス認証の強度を作成および管理する」を参照してください。
制限事項
認証の強度の影響: 条件付きアクセス ポリシーは、最初の認証の後にのみ評価されます。 その結果、認証強度によってユーザーの初期認証が制限されることはありません。
組み込みの フィッシング耐性 MFA 強度 認証強度を使用しているとします。 ユーザーは引き続きパスワードを入力できますが、続行する前に、FIDO2 セキュリティ キーなどのフィッシングに強い方法を使用してサインインする必要があります。
許可コントロールのサポートされていない組み合わせ: 同じ条件付きアクセス ポリシーで、 多要素認証を要求 し、 認証強度 付与コントロールを一緒に要求することはできません。 その理由は、組み込みの 多要素認証の 強度は、[ 多要素 認証の許可の要求] コントロールと同じであるためです。
サポートされていない認証方法: 電子メール ワンタイム パス (ゲスト) 認証方法は、現在、使用可能な組み合わせではサポートされていません。
Windows Hello for Business: ユーザーがプライマリ認証方法として Windows Hello for Business でサインインした場合は、Windows Hello for Business を含む認証強度要件を満たすために使用できます。 ただし、ユーザーがプライマリ認証方法として別の方法 (パスワードなど) を使用してサインインし、認証強度に Windows Hello for Business が必要な場合、ユーザーは Windows Hello for Business でサインインするように求められません。 ユーザーは、セッションを再起動し、 サインイン オプションを選択し、認証強度に必要な方法を選択する必要があります。
既知の問題
認証の強度とサインインの頻度: リソースに認証強度とサインイン頻度が必要な場合、ユーザーは 2 つの異なるタイミングで両方の要件を満たすことができます。
たとえば、1 時間のサインイン頻度と共に、認証強度にパスキー (FIDO2) が必要なリソースがあるとします。 ユーザーがパスキー (FIDO2) を使用してサインインし、24 時間前にリソースにアクセスした。
ユーザーが Windows Hello for Business を使用して Windows デバイスのロックを解除すると、リソースに再度アクセスできます。 昨日のサインインで認証強度の要件を満たし、今日のデバイスのロック解除はサインイン頻度の要件を満たします。
FAQ
認証方法に認証強度またはポリシーを使用する必要がありますか?
認証強度は、 認証方法 ポリシーに基づいています。 認証方法ポリシーは、ユーザーとグループが Microsoft Entra ID 全体で使用できる認証方法のスコープ設定と構成に役立ちます。 認証の強度により、機密性の高いリソース アクセス、ユーザー リスク、場所など、特定のシナリオに対する方法の別の制限が可能になります。
たとえば、Contoso という名前の組織の管理者が、ユーザーがプッシュ通知またはパスワードレス認証モードで Microsoft Authenticator を使用することを許可するとします。 管理者は、 認証方法 ポリシーの Authenticator 設定に移動し、関連するユーザーのポリシーのスコープを設定し、 認証モード を [任意] に設定します。
Contoso の最も機密性の高いリソースの場合、管理者はアクセスをパスワードレス認証方法のみに制限したいと考えています。 管理者は、組み込みの パスワードレス MFA 強度 認証強度を使用して、新しい条件付きアクセス ポリシーを作成します。
その結果、Contoso のユーザーは、Authenticator からのパスワードとプッシュ通知を使用するか、Authenticator (電話によるサインイン) のみを使用して、テナント内のほとんどのリソースにアクセスできます。 ただし、テナント内のユーザーが機密性の高いアプリケーションにアクセスする場合は、Authenticator (電話によるサインイン) を使用する必要があります。
