条件付きアクセスの認証強度

認証強度は、リソースへのアクセスに使用できる認証方法の組み合わせを指定することができる条件付きアクセス制御です。 ユーザーは、許可されている組み合わせのいずれかを使って認証を行うことで、強度要件を満たすことができます。

たとえば、認証強度では、機密性の高いリソースへのアクセスにフィッシング耐性のある認証方法のみを使用することを要求できます。 機密性の低いリソースにアクセスするために、管理者はパスワードとテキスト メッセージの組み合わせのような、安全性の低い多要素認証 (MFA) の組み合わせを許可する別の認証強度を作成できます。

認証強度は認証方法ポリシーに基づいており、管理者は、Microsoft Entra ID のフェデレーション アプリケーション全体で使われる、特定のユーザーやグループに対する認証方法のスコープを設定できます。 認証強度を使うと、機密リソースへのアクセス、ユーザー リスク、場所などの特定のシナリオに基づいて、これらの方法の使用をさらに制御できます。

認証強度のシナリオ

認証強度を使用すると、お客様が次のようなシナリオに対処するのに役立ちます。

• 機密リソースにアクセスするために、特定の認証方法を要求します。
• ユーザーがアプリケーション内で機密アクションを実行するときに、特定の認証方法を要求します (条件付きアクセス認証コンテキストとの組み合わせ)。
• ユーザーが企業ネットワークの外部にある機密アプリケーションにアクセスするときに、特定の認証方法の使用を要求します。
• リスクの高いユーザーに、より安全な認証方法を要求します。
• リソース テナントにアクセスするゲスト ユーザーに、特定の認証方法を要求します (テナント間の設定との組み合わせ)。

認証強度

管理者は、[認証強度が必要] コントロールで条件付きアクセス ポリシーを作成することで、リソースにアクセスするための認証強度を指定できます。 3 つの組み込み認証強度 (多要素認証強度、パスワードレス MFA 強度、フィッシングに強い MFA 強度) から選択できます。 また、許可する認証方法の組み合わせに基づいて、カスタム認証強度を作ることもできます。

組み込みの認証強度

組み込みの認証強度は、Microsoft によって事前に定義されている認証方法の組み合わせです。 組み込みの認証強度は常に使用でき、変更することはできません。 Microsoft は、新しい方法が利用可能になったら、組み込みの認証強度を更新します。

たとえば、組み込みのフィッシングに強い MFA 強度では、次の組み合わせを使用できます。

• Windows Hello for Business

  または

• FIDO2 セキュリティ キー

  または

• Microsoft Entra 証明書ベースの認証 (多要素)

各組み込みの認証強度の認証方法の組み合わせを次の表に示します。 これらの組み合わせには、ユーザーが登録する必要があり、認証方法ポリシーまたは従来の MFA 設定ポリシーで有効にする必要があるメソッドが含まれます。

• MFA 強度 - [多要素認証を要求する] の設定を満たすために使用できるものと同じ組み合わせのセット。
• パスワードレス MFA 強度 - MFA を満たすがパスワードを必要としない認証方法を含みます。
• フィッシングに強い MFA 強度 - 認証方法とサインイン画面の間の相互作用を必要とする方法を含みます。

¹ ユーザーが持っているものとは、テキスト メッセージ、音声、プッシュ通知、ソフトウェア OATH トークン、またはハードウェア OATH トークンのいずれかの方法を意味します。

次の API 呼び出しを使って、すべての組み込み認証強度の定義の一覧を取得できます。

GET https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies?$filter=policyType eq 'builtIn'

条件付きアクセス管理登録者は、アクセス要件に正確に適合するようにカスタム認証強度を作成することもできます。 詳細については、カスタム条件付きアクセスの認証強度に関する記事を参照してください。

制限事項

• 条件付きアクセス ポリシーは、初期認証の後にのみ評価されます - このため、ユーザーの初期認証は認証強度によって制限されません。 組み込みのフィッシングに強い MFA 強度を使っているとします。 その場合でも、ユーザーはパスワードを入力できますが、続ける前に、FIDO2 セキュリティ キーなどのフィッシングに強い方法に登録する必要があります。

• 多要素認証の要求と、認証強度の要求を、同じ条件付きアクセス ポリシーで併用することはできません - 組み込み認証強度の "多要素認証" は、"多要素認証の要求" 許可制御と同等であるため、これら 2 つの条件付きアクセス許可制御を一緒に使うことはできません。

• 認証強度で現在サポートされていない認証方法 - Email ワンタイム パス (ゲスト) 認証方法は、使用可能な組み合わせに含まれていません。

• Windows Hello for Business – ユーザーがプライマリ認証方法としてWindows Hello for Business を使用してサインインした場合は、これを使用して、Windows Hello for Business を含む認証強度要件を満たすことができます。 ただし、ユーザーがプライマリ認証方法としてパスワードなどの別の方法でサインインし、認証強度が Windows Hello for Business を必要とする場合は、Windows Hello for Business を使用してサインインするように求めるプロンプトが表示されルことはありません。 ユーザーはセッションを再起動し、[サインイン オプション] を選択し、認証強度に必要な方法を選択する必要があります。

既知の問題

• FIDO2 セキュリティ キーの詳細オプション - リソース テナントとは異なる Microsoft クラウドにあるホーム テナントに属する外部ユーザーは、詳細オプションでサポートされていません。

• 認証強度ブレードの二重表現 - Windows Hello for Business や macOS のプラットフォーム資格情報などのプラットフォーム資格情報は、どちらも Windows Hello for Business の認証強度で表されます。 macOS のプラットフォーム資格情報を使用できるカスタム認証強度を構成するには、Windows Hello For Business を使います。

よく寄せられる質問

認証強度または認証方法ポリシーを使う必要があるのですか?

認証強度は、認証方法ポリシーが基になっています。 認証方法ポリシーは、特定のユーザーやグループによって Microsoft Entra ID 全体で使われる認証方法のスコープを設定して構成するのに役立ちます。 認証強度を使うと、機密リソースへのアクセス、ユーザー リスク、場所など、特定のシナリオに対する方法について別の制限が可能になります。

たとえば、Contoso の管理者は、ユーザーがプッシュ通知またはパスワードレス認証モードで Microsoft Authenticator を使用できるようにしたいと考えています。 管理者は、認証方法ポリシーの Microsoft Authenticator 設定に移動し、関連するユーザーのポリシーのスコープを設定して、[認証モード] を [任意] に設定します。

次に、管理者は Contoso の最も機密性の高いリソースについて、アクセスをパスワードレス認証方法のみに制限したいと考えています。 管理者は、組み込みのパスワードレス MFA 強度を使って、新しい条件付きアクセス ポリシーを作成します。

その結果、Contoso のユーザーは、テナント内のほとんどのリソースには、パスワードと Microsoft Authenticator からのプッシュ通知を使うか、Microsoft Authenticator (電話サインイン) のみを使って、アクセスできます。 一方、テナント内のユーザーが機密アプリケーションにアクセスするときは、Microsoft Authenticator (電話サインイン) を使う必要があります。

前提条件

• Microsoft Entra ID P1 - 条件付きアクセスを使うには、テナントに Microsoft Entra ID P1 ライセンスが必要です。 必要に応じて、無料試用版を有効にすることができます。

次のステップ

• カスタム条件付きアクセスの認証強度
• 外部ユーザーの場合の認証強度のしくみ
• 認証強度のトラブルシューティング