Microsoft 365 / MFAの設定とセキュリティの既定値・条件付きアクセスの選び方

Microsoft 365で多要素認証(MFA)を適用する際、単純な組織全体の基本保護が必要であればセキュリティの既定値を、ユーザー・アプリ・場所・デバイスなど条件別のポリシーが必要であれば条件付きアクセスを検討します。両方式を重ねて有効にする方法はありません。条件付きアクセスには適切なMicrosoft Entraライセンスとポリシー設計が必要です。

セキュリティの既定値と条件付きアクセスの違い

Microsoft の セキュリティの既定値の案内 および 条件付きアクセス展開計画 によると、セキュリティの既定値と条件付きアクセスを同時に使用する方式ではありません。製品別ライセンスは Microsoft Entra ライセンスの説明 で最新の条件を確認してください。

MFA 登録とログイン要求は別の状態です

MFA（多要素認証、マルチファクター認証）は、パスワードに加えて追加の認証手段で本人を確認する方式です。認証アプリを登録した事実、特定のログインでMFAが要求された事実、その要求が実際に満たされた事実を分けて確認する必要があります。登録だけしてポリシーを適用していなければ、意図した保護が実施されない可能性があります。

逆に、毎回認証通知が来ないからといってMFAがオフになっているわけではありません。既存のセッションやトークンの認証状態が認められている場合もあるため、ログイン記録で判断します。以前のユーザー別MFA画面で「使用しない」と表示されていても、セキュリティの既定値や条件付きアクセスでMFAが適用されることがあります。この表示だけを見て、以前の方式のユーザー別MFAを追加でオンにしないでください。

判断する前に確認すべき質問

• 現在のテナントでどの認証ポリシーがすでにオンになっていますか？新しいテナントではセキュリティの既定値が有効になっている場合があります。
• 管理者と一般ユーザーがどの認証方法を登録しましたか？展開前に準備案内が必要です。
• レガシー認証を使う古いアプリや機器はありますか？ブロックすると業務が中断する可能性を確認する必要があります。
• 緊急アクセス用アカウントと復旧手順は準備されていますか？誤った条件付きアクセス ポリシーにより、すべての管理者がロックされる可能性があります。
• 必要な機能を使用するためのライセンスはそのユーザーにありますか？

セキュリティの既定値を確認する手順

1. Microsoft Entra 管理センターに必要な権限でサインインします。
2. [Entra ID] → [概要] → [プロパティ]でセキュリティの既定値管理の場所を見つけます。メニュー構造が変更されている場合は、管理センターの検索で「セキュリティの既定値」を探します。

3. 現在の状態を記録し、影響を受ける管理者・ユーザー・アプリを調査します。組織に通知し、認証登録を準備した後、適用するかどうかを決定します。
4. セキュリティの既定値を選択した場合は、セキュリティの既定値管理 → 有効 → 保存で適用します。設定には条件付きアクセス管理者などの権限が必要です。ユーザーにサポートされている認証方法の登録手順を案内します。
5. 管理者と一般ユーザーで新しいログインフローを確認し、認証登録・サインインログを点検します。既存のログインセッションの維持の有無も展開計画に含めます。全セッションの解除はユーザー業務に影響を与えるため、通知とサポート準備後に承認された範囲で実施します。

セキュリティの既定値には、ユーザーごとの例外を設定する方法は提供されていません。特定の旧型機器だけ保護を回避する必要がある場合、全体のデフォルト保護をオフにする前に、その機器の認証方法を変更するか、条件付きアクセス設計に切り替える必要があるかを検討してください。過去の文書のMFA登録猶予期間を前提としてユーザーへの案内スケジュールは立てません。

条件付きアクセスを導入する際には

Microsoft Entra管理センターで条件付きアクセス → ポリシーを開きます。画面構成によって、Entra IDの保護メニューの下にあるか、管理センターの検索で見つけることができます。ポリシーを作成・修正する役割と適用対象のライセンスを確認してください。一般的な条件付きアクセスにはEntra ID P1が、ユーザー・ログインリスクに基づく条件にはP2などが必要です。

セキュリティの既定値から切り替える場合は、代替ポリシーを設計・検証し、切り替え時間を決める必要があります。セキュリティの既定値をオフにしてレポート専用ポリシーだけを作成しただけでは、同等の保護が継続されるわけではありません。Microsoftは、既定値を解除した後に保護ポリシーを直ちに有効化するよう案内しています。したがって、以下のレポート専用の演習は、既存の保護が維持される試験環境や切り替え計画に基づいて実施し、運用組織の保護を先にオフにする準備段階として使用しません。

1. 新しいポリシーで目的と対象が分かる名前を入力します。例えば「パイロットユーザー MFA 要求」のように作成します。
2. ユーザーに試験グループを含め、対象アカウントと照合します。緊急アクセス用アカウントは緊急アクセス用アカウントの設計に従い、ログインをブロック・制限するポリシーから除外し、別途強力な認証と監視を準備します。
3. 対象リソースで保護するアプリ・リソースを決定します。1つのアプリだけを対象に試験した結果を、全サービスに自動的に適用されたものと解釈しないでください。
4. アクセス制御の［許可］でMFA要求を選択し、ポリシーの状態をレポート専用として保存します。最初からブロック・準拠デバイス・リスク条件をすべて混ぜず、1つの要求がどのような結果をもたらすかを確認します。
5. 試験用アカウントで該当リソースにログインし、サインインイベントのレポート専用の結果でポリシーの適用対象、要件および予想される失敗原因を確認します。レポート専用はこのポリシーのアクセス制御を実際に強制しません。

有効化前後の検証とロールバック

期待される結果をまず表に記録してください。たとえば、試験ユーザーは指定されたアプリでMFA要件が満たされる必要があり、対象外のユーザーは新しいポリシーの影響を受けないことです。ただし、他のポリシーやMicrosoftが義務付けた認証要件は別途適用されることがあるため、1つのポリシーの除外がすべてのMFA免除を意味するわけではありません。

レポート専用結果と実際の試験を確認した後、承認されたパイロットからポリシーを有効化に切り替えます。以降、新しいログインで認証要件とアクセス結果を確認し、適用対象を拡大します。Microsoftの展開計画では、ポリシーを強制する前に少なくとも1週間、レポート専用で影響を確認することを推奨しています。期間を満たすことよりも、主要業務・アプリの実際のログイン事例を確保することが重要です。

障害が発生した場合、失敗イベントの条件付きアクセスタブで適用されたポリシーを確認します。新しいポリシーが原因である場合、用意された管理経路でそのポリシーをレポート専用または無効に戻し、既存の保護が維持されるか確認します。すべてのポリシーを一度にオフにしたり、長期的な例外として放置したりしないでください。復旧後、対象・条件・認証方法を修正し、同じテストを再度通過した後に再適用してください。