MFAは、複数の要素を組み合わせて本人確認を行う仕組みです。パスワードに加えて認証アプリなどを使うことで、パスワードだけに依存する場合よりも、不正アクセスのリスクを減らせます。
対象はMicrosoft 365の認証を管理する担当者です。適用方式の選択、設定、登録確認、例外管理を順に説明します。管理画面の表示は更新されるため、操作時には末尾のMicrosoft公式資料と照合してください。
設定前に現在の適用方式を確認する
最初に確認するのは、既にどの仕組みでMFAを適用しているかです。「ユーザーごとのMFA」の画面で無効と表示されていても、セキュリティの既定値群や条件付きアクセスによって保護されている場合があります。この表示だけを見て、一括で有効にしないようにします。
主な選択肢は、次の二つです。
| 方式 | 選択の目安 | 確認する点 |
| セキュリティの既定値群 | 組織全体に基本的な保護を適用したい場合 | 個別ユーザーの除外など、任意の細かな設定はできない |
| 条件付きアクセス | 対象ユーザーやアクセス条件に応じて制御したい場合 | 原則として適用対象ユーザーにMicrosoft Entra ID P1以上が必要 |
Business PremiumにはMicrosoft Entra ID P1が含まれます。ただし、条件付きアクセスの対象者に必要なライセンスが割り当てられているかは別途確認します。ユーザーリスクなどに基づく制御には、さらに上位のライセンスが必要になる場合があります。
また、管理者が普段使う認証方法を利用できなくなった場合に備え、後述する緊急アクセス用アカウントも準備します。
セキュリティの既定値群を有効にする
セキュリティの既定値群は、追加のライセンス費用なしで利用できる基本的な保護です。MFAの登録・利用を求めるほか、旧式の認証をブロックします。有効化する前に、業務で使うメールソフト、メール送信機器、スクリプトなどの接続方式を調べます。旧式の認証や、ブロック対象となる認証フローに依存している場合は、接続方法の変更が必要です。
設定の基本手順は次のとおりです。
1. 条件付きアクセス管理者以上の権限を持つアカウントで、Microsoft Entra管理センターにサインインします。
2. ［Entra ID］→［概要］→［プロパティ］を開きます。
3. ［セキュリティの既定値群の管理］を選択します。
4. セキュリティの既定値群を有効にして、保存します。
有効化の前に、利用者へ登録手順、実施日、問い合わせ先を案内します。既存セッションへの影響や再認証の手順も確認してください。
この方式では、一般ユーザーにMFAを求めるタイミングをMicrosoftが判断します。任意のユーザーを除外したり、自社で細かな適用条件を指定したりしたい場合は、条件付きアクセスを検討します。
条件付きアクセスでMFAを求める
条件付きアクセスでは、対象ユーザー、対象リソース、アクセス条件と、許可に必要な認証を組み合わせて設定します。以下は、MFAを要求するポリシーを作成する基本的な流れです。既存ポリシーとの関係や、自動処理への影響も確認して進めます。
1. 条件付きアクセス管理者以上の権限で、Microsoft Entra管理センターにサインインします。
2. ［Entra ID］→［条件付きアクセス］→［ポリシー］から、新しいポリシーを作成します。
3. 対象ユーザーと、必要な除外対象を指定します。緊急アクセス用アカウントの扱いは、後述の方針に沿って確認します。
4. 対象リソースを指定します。組織全体の基本保護では、すべてのリソースを対象とする構成を検討します。
5. ［許可］で［アクセス権の付与］を選び、［認証強度を要求する］で利用者の認証方法に合うMFAの強度を指定します。画面のラベルは更新や言語設定で異なるため、公式手順の該当項目も確認してください。
6. 最初は［レポート専用］で保存し、サインインログなどで影響を確認します。
7. 対象を限定した適用テストを行い、問題がないことを確認してから、予定した範囲へ広げます。
レポート専用では、ポリシーの判定結果を確認できますが、MFAは強制されません。実際に利用できるかは、有効化したテスト用の適用範囲でも確認します。
外部認証方法を利用している場合など、認証強度の指定ではなく別の許可設定が必要になるケースもあります。構成はMicrosoftの公式手順と照合してください。
セキュリティの既定値群から移行する場合は、代わりとなる保護を準備し、切り替え時に保護の空白が生じないようにします。MFAポリシーを一つ作るだけで、旧式認証のブロックなど、既定値群の保護をすべて置き換えられるわけではありません。
利用者の登録と実際の適用状況を確認する
管理者側の設定が終わっても、利用者の準備は残っています。Microsoft Authenticatorを使う場合は、アプリをインストールするだけでなく、職場のアカウントを登録し、案内に沿って確認操作を完了します。実施前に手順を配布し、登録できない場合の連絡先も伝えておきます。
確認するのは、次の三点です。
- 対象者が、ポリシーで利用できる認証方法を登録しているか
- ブラウザーや普段の業務アプリで、必要なアクセスができるか
- サインインログで、MFAの要件やポリシーが意図どおり適用されているか
適用しにくいアカウントは用途を分けて考える
MFAを適用できないように見えるアカウントがあっても、すぐに除外するのではなく、誰が、何のために、どの方式で使っているかを調べます。
スマートフォンを使えない社員
私物のスマートフォンを使えないことだけで、MFAの対象外にする必要はありません。会社支給端末やセキュリティキーなどを候補にし、採用している適用方式と認証方法のポリシーで使えるかを確認します。認証手段を用意できるかだけでなく、紛失時の再登録や本人確認の担当も決めておきます。
機器やプログラムが使うアカウント
自動処理で使うアカウントは、人が追加認証を行うことを前提にすると、処理が停止する場合があります。まず、接続先、利用権限、認証方式、管理担当を確認します。対応する環境では、マネージドIDやサービスプリンシパルなど、人のサインインに依存しない方式への移行を検討します。これらは一般ユーザーとは異なる管理対象であり、権限や資格情報の管理も別途必要です。
移行まで一時的な除外が必要な場合
条件付きアクセスで一時的な除外を設定する場合は、理由、承認者、担当者、期限、代替対策を記録します。「システム対応が済むまで」とする場合も、改修予定と次の確認日を明確にします。期限が来たら自動的に延長するのではなく、除外を取り消せるかを確認します。
セキュリティの既定値群では任意のユーザー除外ができないため、例外が必要なら、認証方式の変更や条件付きアクセスへの移行を含めて構成を検討します。
緊急アクセス用アカウントは通常の例外と分けて管理する
Microsoftは、緊急アクセス用として2つ以上のクラウド専用アカウントを用意することを推奨しています。*.onmicrosoft.comドメインを使い、オンプレミスからの同期やフェデレーションに依存しない構成とします。全体管理者の役割を常時利用できるようにし、通常の管理者が使えない場面に備えます。緊急用にはFIDO2セキュリティキーなど、フィッシング耐性のある認証方法を用意します。通常用と緊急用の両方が、同じ認証サービスや端末の障害で使えなくならないように構成します。
条件付きアクセスでは、サインインをブロック・制限するポリシーからの除外を確認します。ただし、これは無保護で運用するという意味ではありません。フィッシング耐性のある認証、資格情報の安全な保管、使用時の通知を組み合わせます。
緊急アクセス用アカウントは、移行期限までの一時的な例外とは異なります。日常業務では使用せず、少なくとも90日ごとにサインインと管理操作、通知が機能することを確認します。
Microsoft 365のセキュリティは設定後も例外と復旧手段を見直す
MFAの導入は、設定を保存して終わりではありません。対象者が登録を完了し、業務で利用でき、管理者が適用状況を確認できるところまで進めます。その後も、入退社、端末変更、システム改修に合わせて、対象と認証方法を見直します。一時的な除外と緊急アクセス用アカウントは別々に管理し、それぞれの目的に沿って確認を続けます。
既存ポリシー、ライセンス、利用中の接続方式が分かる資料があれば、Advangeが現在の保護を確認しながら展開方法を一緒に検討します。対象者、例外、復旧手段の定期的な見直しまで含めて、無理のない計画を立てましょう。
参考資料
Microsoft セキュリティの既定値群
Microsoft 条件付きアクセスの概要
Microsoft 緊急アクセス用アカウント
参照日 2026年11月4日
