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

  • [アーティクル]

認証強度は、リソースへのアクセスに使用できる認証方法の組み合わせを管理者が指定できるようにする条件付きアクセス制御です。 たとえば、機密リソースへのアクセスにはフィッシングに強い認証方法のみを使用できるようにすることができます。 しかし、機密ではないリソースにアクセスするために、より安全性の低い多要素認証 (MFA) の組み合わせを許可することができます (パスワードと SMS メッセージなど)。

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

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

Screenshot of a Conditional Access policy with an authentication strength configured in grant controls.

認証強度のシナリオ

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

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

認証強度

認証強度には、認証方法の組み合わせを含めることができます。 ユーザーは、許可されている組み合わせのいずれかを使って認証を行うことで、強度要件を満たすことができます。 たとえば、組み込みのフィッシングに強い MFA 強度では、次の組み合わせを使用できます。

  • Windows Hello for Business

    または

  • FIDO2 セキュリティ キー

    または

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

Screenshot showing the phishing-resistant MFA strength definition.

組み込みの認証強度

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

次の表は、各組み込み認証強度の認証方法の組み合わせです。 認証方法ポリシーで使用でき、ユーザーに登録されている方法に応じて、任意の組み合わせをサインインに使用できます。

  • MFA 強度 - [多要素認証を要求する] の設定を満たすために使用できるものと同じ組み合わせのセット。
  • パスワードレス MFA 強度 - MFA を満たすがパスワードを必要としない認証方法を含みます。
  • フィッシングに強い MFA 強度 - 認証方法とサインイン画面の間の相互作用を必要とする方法を含みます。
認証方法の組み合わせ MFA 強度 パスワードレス MFA 強度 フィッシングに強い MFA 強度
FIDO2 セキュリティ キー ✅ ✅ ✅
Windows Hello for Business ✅ ✅ ✅
証明書ベースの認証 (多要素) ✅ ✅ ✅
Microsoft Authenticator (電話によるサインイン) ✅ ✅
一時アクセス パス (1 回限りの使用と、複数回の使用) ✅
パスワード + 使用できるもの 1 ✅
フェデレーション単一要素 + 使用できるもの 1 ✅
フェデレーション多要素 ✅
証明書ベースの認証 (単一要素)
SMS サインイン
パスワード
フェデレーション単一要素

1 "ユーザーが持っているもの" とは、次のいずれかの方法を指します: SMS メッセージ、音声、プッシュ通知、ソフトウェア OATH トークン、ハードウェア OATH トークン。

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

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

カスタム認証強度

管理者は、3 つの組み込み認証強度に加えて、最大 15 個の独自のカスタム認証強度を要件に正確に合わせて作成できます。 カスタム認証強度には、前の表のサポートされている任意の組み合わせを含めることができます。

  1. 少なくとも認証ポリシー管理者として Microsoft Entra 管理センターにサインインします。

  2. [保護]>[認証方法]>[認証強度] に移動します。

  3. [新しい認証強度] を選びます。

  4. 新しい認証強度のわかりやすい [名前] を指定します。

  5. 必要に応じて、[説明] を入力します。

  6. 許可する任意の使用可能な方法を選びます。

  7. [次へ] を選んで、ポリシー構成を確認します。

    Screenshot showing the creation of a custom authentication strength.

カスタム認証強度を更新および削除する

カスタム認証強度を編集できます。 条件付きアクセス ポリシーによって参照されている場合は削除できず、編集を確認する必要があります。 条件付きアクセス ポリシーによって認証強度が参照されているかどうかを調べるには、[条件付きアクセス ポリシー] 列をクリックします。

FIDO2 セキュリティ キーの高度なオプション

カスタム認証強度を使うと、お客様は認証子構成証明 (AAGUID) に基づいて、一部の FIDO2 セキュリティ キーの使用をさらに制限できます。 この機能により、管理者は、リソースにアクセスするために、特定の製造元の FIDO2 キーを要求できます。 特定の FIDO2 セキュリティ キーを要求するには、前の手順のようにしてカスタム認証強度を作成し、[FIDO2 セキュリティ キー] を選んで、[詳細オプション] をクリックします。

Screenshot showing Advanced options.

[Allowed FIDO2 Keys] (許可する FIDO2 キー) の横の [+] をクリックし、AAGUID の値をコピーして、[保存] をクリックします。

Screenshot showing how to add an Authenticator Attestation GUID.

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

必要な認証強度を決定したら、リソースへのアクセスにその認証強度を要求する条件付きアクセス ポリシーを作成する必要があります。 条件付きアクセス ポリシーを適用すると、認証強度によって許可される認証方法が制限されます。

認証方法ポリシーでの認証強度の動作のしくみ

リソースへのアクセスに使用できる認証方法を決定するポリシーが 2 つあります。 いずれかのポリシーの認証方法が有効になっているユーザーは、その方法を使ってサインインできます。

  • [セキュリティ]>[認証方法]>[ポリシー] は、特定のユーザーやグループの認証方法を管理するための、より新しい方法です。 さまざまな方法に対してユーザーとグループを指定できます。 メソッドの使用方法を制御するパラメーターを構成することもできます。

    Screenshot of Authentication methods policy.

  • [セキュリティ]>[多要素認証]>[クラウドベースの多要素認証の追加設定] は、テナント内のすべてのユーザーの多要素認証方法を制御する従来の方法です。

    Screenshot of MFA service settings.

ユーザーが自分で有効な認証に登録できる場合と、管理者が証明書ベースの認証などの方法でユーザーのデバイスを構成できる場合があります。

サインイン時の認証強度ポリシーの評価方法

認証強度の条件付きアクセス ポリシーでは、使用できる方法を定義します。 Microsoft Entra ID は、サインインの間にポリシーをチェックして、ユーザーによるリソースへのアクセスを決定します。 たとえば管理者は、FIDO2 セキュリティ キーまたはパスワードと SMS メッセージを必要とするカスタム認証強度を使用した、条件付きアクセス ポリシーを構成します。 ユーザーは、このポリシーによって保護されたリソースにアクセスします。 サインインの間に、すべての設定がチェックされ、許可されている方法、登録されている方法、条件付きアクセス ポリシーで要求されている方法が決定されます。 使用するには、方法が許可されていて、ユーザーによって (アクセス要求の前またはその一部として) 登録されていて、認証強度を満たしている必要があります。

複数の条件付きアクセス認証強度ポリシーの評価方法

一般に、シングル サインインに適用される条件付きアクセス ポリシーが複数あるときは、すべてのポリシーのすべての条件を満たす必要があります。 同様に、サインインに認証強度を適用する複数の条件付きアクセス ポリシーがあるときは、ユーザーがすべての認証強度ポリシーを満たす必要があります。 たとえば、2 つの異なる認証強度ポリシーで両方に FIDO2 が必要な場合、ユーザーは FIDO2 セキュリティ キーを使用して、両方のポリシーを満たすことができます。 2 つの認証強度ポリシーの一連の方法が異なる場合、ユーザーは複数の方法を使用して、両方のポリシーを満たす必要があります。

セキュリティ情報を登録するための複数の条件付きアクセス認証強度ポリシーの評価方法

セキュリティ情報の登録では、認証強度の評価は異なる方法で扱われます。[セキュリティ情報の登録] ユーザー アクションを対象とする認証強度は、[すべてのクラウド アプリ] を対象とする他の認証強度ポリシーよりも優先されます。 サインインのスコープ内の他の条件付きアクセス ポリシー由来の他のすべての制御の許可 ([デバイスは準拠しているとしてマーク済みであることが必要] など) は、通常どおり適用されます。

たとえば、Contoso が、常にフィッシングに強い認証方法で準拠しているデバイスからサインインするようにユーザーに要求するとします。 Contoso は、一時アクセス パス (TAP) を使用してこれらの認証方法を新入社員が登録できるようにすることも希望しています。 TAP は他のリソースでは使用できません。 この目標を達成するために、管理者は次の手順を実行できます。

  1. ブートストラップと回復という名前のカスタム認証強度を作成します。これには、一時アクセス パス認証の組み合わせを含めます。フィッシングに強い MFA 方法を含めることもできます。
  2. [すべてのクラウド アプリ] を対象とし、フィッシングに強い MFA 認証強度と、[準拠しているデバイスが必要です] 制御の許可を必要とする条件付きアクセス ポリシーを作成します。
  3. [セキュリティ情報の登録] ユーザー アクションを対象とし、ブートストラップと回復の認証強度を必要とする条件付きアクセス ポリシーを作成します。

その結果、準拠しているデバイスのユーザーは、一時アクセス パスを使用して FIDO2 セキュリティ キーを登録し、新しく登録された FIDO2 セキュリティ キーを使用して他のリソース (Outlook など) に対する認証を行うことができます。

Note

複数の条件付きアクセス ポリシーが [セキュリティ情報の登録] ユーザー アクションを対象とし、それぞれが認証強度を適用する場合、ユーザーはサインインするためにこれらすべての認証強度を満たす必要があります。

ユーザー エクスペリエンス

次の要素により、ユーザーがリソースにアクセスできるかどうかが決定されます。

  • 以前に使われていた認証方法はどれか?
  • 認証強度に使用できる方法はどれか?
  • 認証方法ポリシーでユーザーのサインインに許可されている方法はどれか?
  • ユーザーは使用可能な方法に登録されているか?

認証強度の条件付きアクセス ポリシーによって保護されているリソースにユーザーがアクセスすると、Microsoft Entra ID は、ユーザーが前に使っていた方法が認証強度を満たすかどうかを評価します。 満たす方法が使われていた場合、Microsoft Entra ID はリソースへのアクセスを許可します。 たとえば、ユーザーがパスワードと SMS メッセージでサインインするとします。 ユーザーは MFA 認証強度によって保護されたリソースにアクセスします。 この場合、ユーザーは別の認証プロンプトなしでリソースにアクセスできます。

次に、フィッシングに強い MFA 認証強度によって保護されたリソースにユーザーがアクセスするとします。 今度は、Windows Hello for Business などのフィッシングに強い認証方法を提供するように求められます。

ユーザーが認証強度を満たすどの方法にも登録していない場合は、統合された登録にリダイレクトされます。

ユーザーが登録して使用できる方法が認証強度に含まれていない場合、ユーザーはリソースへのサインインをブロックされます。

パスワードレス認証方法を登録する

統合された登録の中断モードの一部として、次の認証方法を登録することはできません。 サインインにこれらの方法を使用することを要求できる条件付きアクセス ポリシーを適用する前に、ユーザーがこれらに登録されていることを確認します。 これらの方法に登録されていないユーザーは、必要な方法が登録されるまでリソースにアクセスできません。

方法 登録の要件
Microsoft Authenticator (電話によるサインイン) Authenticator アプリから登録できます。
FIDO2 セキュリティ キー 統合された登録の管理モードを使って登録できます。
証明書ベースの認証 管理者が設定する必要があります。ユーザーは登録できません。
Windows Hello for Business Windows Out of Box Experience (OOBE) または Windows 設定メニューで登録できます。

フェデレーション ユーザー エクスペリエンス

フェデレーション ドメインの場合は、federatedIdpMfaBehavior を設定することにより、Microsoft Entra の条件付きアクセスまたはオンプレミス フェデレーション プロバイダーによって MFA が適用されることがあります。 federatedIdpMfaBehavior が enforceMfaByFederatedIdp に設定されている場合、ユーザーはフェデレーション IdP で認証を行う必要があり、認証強度要件のフェデレーション多要素の組み合わせのみを満たすことができます。 フェデレーションの設定について詳しくは、「MFA のサポートを計画する」をご覧ください。

フェデレーション ドメインのユーザーの段階的ロールアウトのスコープ内に多要素認証の設定がある場合、ユーザーはクラウドで多要素認証を完了し、フェデレーション単一要素 + 使用できるものの組み合わせのいずれかを満たすことができます。 段階的ロールアウトについて詳しくは、「段階的ロールアウトを有効にする」をご覧ください。

外部ユーザー

認証方法ポリシーは、外部ユーザーに対してフィッシングに強い方法などの特定の認証方法を適用できるため、組織内の機密アプリへの外部アクセスを制限する場合に特に役立ちます。

認証強度の条件付きアクセス ポリシーを外部の Microsoft Entra ユーザーに適用すると、ポリシーはクロステナント アクセス設定の MFA 信頼設定と連携して、外部ユーザーが MFA を実行する必要がある場所と方法を決定します。 Microsoft Entra ユーザーは、ホームの Microsoft Entra テナントで認証を行います。 その後、リソースにアクセスするときに、Microsoft Entra ID によってポリシーが適用され、MFA 信頼が有効になっているかどうかが確認されます。 MFA 信頼を有効にすることは、B2B コラボレーションでは省略可能ですが、B2B 直接接続では "必須" であることに注意してください。

外部ユーザーのシナリオでは、ユーザーがホーム テナントまたはリソース テナントのどちらで MFA を完了しているかにより、認証強度を満たすことができる認証方法が異なります。 次の表では、各テナントで許容される方法を示します。 リソース テナントで外部の Microsoft Entra 組織からの要求を信頼することが選ばれている場合は、下の「ホーム テナント」列にリストされている要求のみが、リソース テナントで MFA に対して受け入れられます。 リソース テナントで MFA 信頼が無効になっている場合、外部ユーザーは、「リソース テナント」列で指定されているいずれかの方法を使って、リソース テナントでの MFA を完了する必要があります。

認証方法 ホーム テナント リソース テナント
第 2 要素としての SMS メッセージ ✅ ✅
音声通話 ✅ ✅
Microsoft Authenticator プッシュ通知 ✅ ✅
Microsoft Authenticator の電話によるサインイン ✅
OATH ソフトウェア トークン ✅ ✅
OATH ハードウェア トークン ✅
FIDO2 セキュリティ キー ✅
Windows Hello for Business ✅

外部ユーザーの認証強度を設定する方法の詳細については、「条件付きアクセス: 外部ユーザー向けの認証強度を要求する」を参照してください。

外部ユーザーのユーザー エクスペリエンス

認証強度の条件付きアクセス ポリシーは、クロステナント アクセス設定の MFA 信頼設定と連携します。 Microsoft Entra ユーザーは、まず、ホーム テナントで自分のアカウントを使って認証を行います。 その後、このユーザーがリソースへのアクセスを試みると、Microsoft Entra ID は認証強度の条件付きアクセス ポリシーを適用し、MFA 信頼が有効になっているかどうかを確認します。

  • MFA 信頼が有効になっている場合、Microsoft Entra ID はユーザーの認証セッションで、ユーザーのホーム テナント内で MFA が満たされたことを示す要求を確認します。 外部ユーザーのホーム テナントで完了した場合に MFA で許容される認証方法については、前の表を参照してください。 ユーザーのホーム テナントで MFA ポリシーが既に満たされていることを示す要求がセッションに含まれていて、その方法が認証強度要件を満たしている場合、ユーザーはアクセスを許可されます。 それ以外の場合、Microsoft Entra ID は、受け入れ可能な認証方法を使用して、ホーム テナントで MFA を完了するチャレンジをユーザーに提示します。
  • MFA 信頼が無効な場合、Microsoft Entra ID は、受け入れ可能な認証方法を使用して、リソース テナントで MFA を完了するチャレンジをユーザーに提示します。 (外部ユーザーによる MFA として許容される認証方法については、上の表をご覧ください。)

制限事項

  • 条件付きアクセス ポリシーは、初期認証の後にのみ評価されます - このため、ユーザーの初期認証は認証強度によって制限されません。 組み込みのフィッシングに強い 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 クラウドにあるホーム テナントに属する外部ユーザーは、詳細オプションでサポートされていません。

よく寄せられる質問

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

認証強度は、認証方法ポリシーが基になっています。 認証方法ポリシーは、特定のユーザーやグループによって 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 ライセンスが必要です。 必要に応じて、無料試用版を有効にすることができます。
  • 統合された登録を有効にする - 認証強度は、MFA と SSPR の統合された登録を使っている場合にサポートされます。 従来の登録を使うと、ユーザーは認証方法ポリシーによって要求されない方法を登録できるため、ユーザー エクスペリエンスが低下します。

次のステップ