MFAの次に条件付きアクセスで何を設定するか

「MFAは全員に設定済みです。これでひとまず安心ですよね」セキュリティのご相談で耳にする言葉です。

MFA（多要素認証）が守るのは「本人確認」の部分です。正しい本人が、会社の管理していない私物PCから社内データを開く、という動きまでは止まりません。ここで使うのが条件付きアクセス（サインインの条件を決めて、満たさないアクセスを遮断するMicrosoft Entra IDの機能）です。「誰が」だけでなく「どこから、どの端末で」まで見て、通すかどうかを判断できます。

ではMFAの次に、条件付きアクセスで何を設定すればよいのでしょうか。答えは、新しいポリシーを作ることではありません。 先にやることは、いま貴社のテナントに何が効いているかを確かめることです。 MFAの強制もレガシ認証のブロックも、Microsoftが自動で入れている場合があり、知らずに作ると二重になるか、逆に既存の保護を外してしまうからです。

テナントに効いているものを先に見る

見る場所は2つに分かれます。

ひとつはセキュリティの既定値群です。 Microsoftが用意した既定の保護で、2019年10月22日以降に作られたテナントでは、作成時に有効になっている場合があります。オンかオフかだけの設定で、対象や条件は調整できません。ポリシーの一覧には並ばないため、Microsoft Entra管理センターの「Entra ID」から「概要」の「プロパティ」に進んで、状態を確かめてください。

もうひとつが条件付きアクセスのポリシーの一覧で、「Entra ID」の「条件付きアクセス」にあります。ここを開くと、作った覚えのないポリシーが並んでいることがあります。出どころは3つで、それぞれ管理の仕方が違います。

Microsoft管理の条件付きアクセスポリシー: Microsoftが対象のテナントに自動で作成するポリシーです。一覧の「作成者」列にMicrosoftと表示されます。
ベースラインセキュリティモードのポリシー: Microsoft 365管理センターで推奨設定をまとめて有効にすると、その一部が条件付きアクセスポリシーとして現れるものです。管理はMicrosoft 365管理センター側で行います。
自社で作ったポリシー: 前任者が作ったものが、制御をかけずに影響だけを記録するレポート専用の状態で残っている、といったケースもあります。

見るときは、ポリシーがあるかどうかで止めないでください。状態（オン、オフ、レポート専用）、対象のユーザーとリソース、除外されているアカウント、要求している制御まで、1本ずつ控えます。この一覧が、このあとの判断の材料になります。

ポリシーを組み立てる3つの部品と、効く範囲

条件付きアクセスのポリシーは、3つの部品でできています。

割り当て: 誰に、どのリソースへのアクセスで適用するかを決めます。ユーザーやグループ、対象のアプリやサービスを指定します。
条件: どういう状況のときに効かせるかを絞ります。ネットワークの場所、デバイスのプラットフォーム、クライアントアプリの種類、サインインのリスク評価などを使います。
制御: 当てはまったときにどうするかです。アクセスをブロックするか、MFAや準拠デバイスやアプリ保護ポリシーを要求したうえで許可するかを選びます。

割り当てと条件に当てはまったサインインにだけ制御がかかり、当てはまらないサインインはそのまま通ります。あるポリシーで除外したユーザーも、別のポリシーの対象に入っていればそちらの制御は受けます。逆に、どのポリシーの対象にもなっていないユーザーは、条件付きアクセスによる制御を受けずに通ります。「除外した＝素通りする」でも「除外していない＝守られている」でもないため、除外を設定したら、そのユーザーが実際にどう扱われるかを試してください。

セキュリティの既定値群を切るなら、代わりを先に決める

セキュリティの既定値群と条件付きアクセスは、併用できません。条件付きアクセスのポリシーがあると既定値群は有効にできない関係で、条件付きアクセスに移るには既定値群を無効にする必要があります。

問題は、切った瞬間に既定値群の保護が外れることです。既定値群は次のことをまとめて行っています。

すべてのユーザーにMFAへの登録を求めます。
管理者にMFAの実行を求めます。
必要に応じて、一般のユーザーにもMFAの実行を求めます。
レガシ認証（先進認証を使わない認証要求。Office 2010のような古いクライアントや、古いメールプロトコルを使うクライアントが該当します）をブロックします。MFAに対応していないため、放っておくとここからMFAを迂回されます。
デバイスコードフロー（入力手段が限られる機器のために、別の端末にコードを入力してサインインする方式）をブロックします。2026年7月1日以降に作られたテナントでは、これも既定値群に含まれます。
Azure portalなど、特権が必要な操作を保護します。

Microsoftは、既定値群を無効にしたあとは直ちに条件付きアクセスポリシーを有効にするよう案内しています（2026年8月時点の公表情報）。ここで使えるのが、Microsoft管理のポリシーに用意されている「セキュリティの既定値からのアップグレード」向けの4本です。レガシ認証のブロック、Azureの管理へのMFA要求、管理者へのMFA要求、すべてのユーザーへのMFA要求で、既定値群が担っていた範囲を条件付きアクセス側でまかなえます。

順序としては、この4本のうちどれを使うか、除外するアカウントをどうするかを先に決めておきます。既定値群を無効にしたら、決めたポリシーをその場で有効にしてください。無効にしてから中身を検討し始めると、その間ずっと保護が空いた状態になります。

そのうえで、移行するかどうかは分けて考えます。既定値群のままで支障がなく、端末や場所による制御も当面必要ないなら、無理に移す必要はありません。準拠デバイスを要求したい、特定のグループだけ条件を変えたい、といった個別の要求が出てきた時点が、移行を決める場面です。

Microsoft管理のポリシーは、放っておくと有効になる

Microsoft管理の条件付きアクセスポリシーは、レポート専用の状態でテナントに作成されます。そのままにしておくと、展開から30日以内に自動で有効になります（通知の内容によっては、それより早く有効になる場合もあります）。有効になる2週間前に、メールとMicrosoft 365のメッセージセンターで通知が届きます。

管理者ができることは決まっています。すぐに有効にすることも、状態を「オフ」にしてオプトアウトすることもできます。除外するアカウントも指定できます。一方で、名前を変えることと削除することはできません。設定をもっと変えたい場合は、ポリシーを複製して自社版を作る形になります。

ここで気をつけていただきたいのが、緊急時に使う管理者アカウントの除外です。 Microsoftが作ったポリシーであっても、そのアカウントを除外するのは管理者の仕事で、自動では入りません。

もうひとつは、通知を受け取る人を決めておくことです。情シスが1人か兼任という体制では、メッセージセンターを見る担当が決まっていないまま、2週間前の通知を誰も開かずに有効化の日を迎えることがあります。通知の宛先を個人の受信箱だけにせず、複数人が読める場所にも届くようにしておいてください。そのうえで、有効化の予定日を見つけたらカレンダーに入れて、当日までに影響を確かめる時間を取ります。

自社で設計するのはここから

既定の保護の上に何を足すか、が情シスの設計する部分です。中小企業のご支援では、端末の条件から入ることがほとんどです。

準拠デバイスの要求は、Intune（Microsoftの端末管理サービス）などに登録され、準拠ポリシーの基準を満たしていると判定された端末からのアクセスだけを許す制御です。使うには前提が3つあります。

端末がMicrosoft Entra IDに登録されていることが要ります。
Intune側で準拠ポリシーが定義されていることが要ります。何をもって準拠とするかを先に決める作業です。
対象のユーザーにIntuneのライセンスが要ります。Microsoft 365 Business Premiumには含まれています。

対応するのは、Microsoft Entra IDとIntuneに登録されたWindows 10以降、iOS、Android、macOSです。

ここで誤解しやすいのが、準拠デバイス＝会社支給端末ではない点です。判定しているのは所有者ではなく、登録の有無と準拠ポリシーへの適合です。私物PCでも登録されて基準を満たせば通ります。会社が支給した端末だけに絞りたいなら、端末の登録そのものを制限する設計を別に用意してください。

私物スマホについては、準拠デバイスを求めて締め出す以外の道があります。端末を管理せずアプリの中だけを保護する方式で、私物スマホで社内データをどこまで扱わせるかに、選択肢の分かれ目と設定の順序をまとめました。準拠デバイスの前提となるMDMの整備そのものは、MacとWindowsが混在する会社のデバイス管理とPCを「箱から出してすぐ使える」状態にするキッティング自動化で扱っています。

場所の条件は、拠点や国を限定する要件が先にあるのでなければ、端末より優先度を落として構いません。判定に使われるのはIPアドレスと、そこから推定した国や地域です。出張や在宅、モバイル回線で意図しない判定が起きやすく、逆に攻撃側は経路を変えれば回避できます。海外からのアクセスが業務上ないなら、想定しない国からのサインインをブロックする使い方が現実的です。

サインインのリスクを条件にする制御には、Microsoft Entra ID 保護（サインインの挙動から乗っ取りの疑いを判定する機能）が要ります。これはMicrosoft Entra ID P2の機能です。条件付きアクセス自体はMicrosoft Entra ID P1で使え、Microsoft 365 Business Premiumにも含まれています。一方でP2は、Business Premium単体には含まれません（2026年8月時点の公表情報）。使うならDefenderスイートなどのアドオンでP2を足すことになるため、費用と効果を見てから判断してください。

締め出さないための備えと、戻し方

条件付きアクセスで影響が最も大きい失敗は、設定を誤って自分を含む全員が締め出されることです。ポリシーを触る前に、緊急アクセス用アカウント（管理者が全員ロックアウトされたときのために用意する、通常運用では使わない管理者アカウント）を準備してください。 Microsoftの推奨は次のとおりです。

2つ以上作り、フェデレーションや同期をしないクラウド専用のアカウント（.onmicrosoft.com）にします。
グローバル管理者ロールを、条件付きの割り当てではなく常に有効な状態で割り当てます。緊急時にロールを有効化する手順が挟まると、その手順自体が使えないことがあります。
認証はパスキー（FIDO2）が推奨で、公開鍵基盤（PKI）を既に運用しているなら証明書ベース認証も選べます。
通常の管理者アカウントとは別の認証方式にします。同じ方式だと、その方式が使えない障害で共倒れになります。
サインインをブロックまたは制限するポリシーから除外します。レポート専用の間はアクセスが止まらないため除外は要りませんが、オンにする前には必ず入れてください。
少なくとも90日ごとに、サインインと管理操作ができること、そして監視のアラートが実際に飛ぶことを確かめます。
サインインログと監査ログをAzure Monitorなどに送り、このアカウントが使われたら管理者へ通知が飛ぶようにアラートを設定します。これは既定では有効になっていません。

除外を検討するアカウントは、ほかにもあります。 Microsoft Entra Connectの同期アカウントのようなサービスアカウントは、特定の人に紐づかない非対話型のアカウントで、MFAや準拠デバイスを要求すると止まります。社外のゲストユーザーも、「すべてのユーザー」に準拠デバイスを要求すると、そのままでは締め出されます。ゲストについては、相手先のテナントが出すMFAや準拠デバイスの情報を信頼する設定もあるので、除外するか信頼するかを決めておいてください。

展開そのものは段階を踏みます。

レポート専用で作る: 制御はかけず、有効だったら誰が引っかかっていたかをサインインログで確認します。Microsoftは適用前に最低1週間の観察を推奨しています。
What Ifツールで確かめる: 特定のユーザーと条件を指定して、どのポリシーが適用されるかを事前にシミュレートできます。入力した条件の範囲でしか見ないため、実際に試すことの代わりにはなりません。
パイロットグループに適用する: 情シス自身、次に協力を得られる部門、という順で対象を広げます。
サインインログを見続ける: 全社に広げたあとも、想定外のブロックが出ていないかをしばらく確認します。

レポート専用モードは万能ではありません。「ユーザーアクション」を対象にしたポリシーは評価されず、ログにも出ません。また、準拠デバイスを要求するレポート専用ポリシーでは、macOS、iOS、Androidの利用者に証明書の選択を求める画面が繰り返し出ることがあります。レポート専用なのでアクセスは止まりませんが、問い合わせの元になります。プラットフォームごと除外すればプロンプトは出なくなるものの、その分の影響は評価できなくなります。観察の期間を区切って除外し、オンにする前に除外を戻して確かめる、という進め方をおすすめします。

想定外の締め出しが出たときの戻し方は3通りです。ポリシーを無効にする、対象のユーザーやグループを除外する、ポリシーを削除する、のいずれかで止まります。削除しても30日間は論理削除の状態で残り、その期間内なら復元できます。除外で急場をしのいだ場合は、原因を直したあとで対象に戻すところまでを一続きの作業にしてください。

どこから決めるか

冒頭の「MFAは全員に設定済みです」という言葉には、ここまでで一段細かく答えられます。確かめるべきは、MFAが登録されているかではなく、何によって強制されているかです。既定値群なのか、Microsoft管理のポリシーなのか、自社で作ったポリシーなのかで、次に触る場所も、触ったときに外れるものも変わります。

順序としては、テナントの棚卸しから始めて、緊急アクセス用アカウントを整え、既定の保護を落とさないように代わりを決めて切り替え、そのうえで端末の条件を足していくことになります。自社の要件から設計するポリシーは、この最後に来ます。手前の3つは、いま効いているものを壊さないための作業です。

貴社のテナントで何が効いていて、どこから手を付けるべきかを一緒に整理したい場合は、デバイス管理導入支援のページをご覧ください。