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

Q: セキュリティの既定値と条件付きアクセスは同時に使えますか？

使えません。どちらか一方です。既定値が有効な間は条件付きアクセス ポリシーを有効にできないため、切り替えは一つの変更作業として計画する必要があります。

要点： セキュリティの既定値（Security defaults）は Microsoft Entra ID に追加費用なしで含まれるスイッチで、有効にするとすべてのユーザーに MFA の登録を求め、管理者のサインインに MFA を必須とし、レガシー認証をブロックします。条件付きアクセスは同じことを自分で書いたルールで実現しますが、対象となるユーザーには Microsoft Entra ID P1 ライセンス（Microsoft 365 Business Premium に含まれる）が必要です。両方を同時に使うことはできません。P1 がなければセキュリティの既定値を有効のままにし、P1 があれば条件付きアクセスのポリシーをまずレポート専用モードで作成し、同じ変更作業の中で既定値を無効にしてポリシーを有効にします。

小規模な Microsoft 365 テナントがこの問題に行き当たる経緯はたいてい同じです。新しいアプリや共有メールボックスが動かなくなり、原因がセキュリティの既定値だと分かり、「既定値をオフにして条件付きアクセスにしよう」という提案が出ます。それが正しい場合もあります。しかし結果的にどちらもない状態になることもあり、それは三つの状態のうち最悪です。

本記事では、小規模企業にとってのセキュリティの既定値と条件付きアクセスの選択を扱います。それぞれが何をするのか、条件付きアクセスに必要なライセンス、判断の仕方、安全な切り替えの順序です。作成すべきポリシーの一覧は繰り返しません。それは条件付きアクセスの基本ポリシーガイドで扱っており、切り替え手順の該当箇所でリンクしています。

セキュリティの既定値は実際に何をするのか？

セキュリティの既定値は Microsoft Entra 管理センターにある一つのスイッチで、追加費用なしにすべてのテナントで使えます。有効にすると次のようになります。

すべてのユーザーが MFA の登録を求められます。 以前は登録を 14 日間先延ばしできる猶予期間がありましたが、Microsoft はこれを廃止しており、ユーザーはサインイン時に登録を求められます。
管理者はサインインのたびに MFA を求められます。 管理者ロールは、パスワードが盗まれたときに最も被害が大きい部分です。
その他のユーザーは、Microsoft のサインインシグナルが必要と判断したときに MFA を求められます。 毎回ではありません。
レガシー認証がブロックされます。 MFA に対応できない古いプロトコルでのサインインは拒否されます。

できないのは、どれかを調整することです。除外はなく、どのアプリで MFA を求めるかも選べず、デバイスや場所に基づく条件もありません。それこそが設計の意図で、ポリシーを管理する人がいないテナントのためのものです。同時に、基本認証のパスワードでメールを送る古い複合機や、特定の一人のスマートフォンに縛りたくない緊急用アカウントなど、何かが動かなくなる原因にもなります。

Microsoft 自身も、Entra ID P1 または P2 のライセンスを持つ組織には条件付きアクセスのほうが適している可能性が高く、要件が複雑な組織は条件付きアクセスを使うべきだとしています。

条件付きアクセスで何が加わるのか？

条件付きアクセスはポリシーエンジンです。各ポリシーは「このユーザーが、このアプリに、この条件でサインインするとき、これ（MFA、準拠デバイス、パスワード変更）を要求する、またはブロックする」と定義します。これにより、セキュリティの既定値ではできないことが可能になります。

特定のアカウントを意図的に除外する。 たとえばパスキーで保護した二つの緊急アクセス用アカウントです。
全員にサインインのたびに MFA を求める。 Microsoft がリスクありと判断したときだけではありません。
デバイスや場所の条件を使う。 たとえばファイルへのアクセスを管理対象のノート PC に限定します。
適用前にテストする。 すべてのポリシーをレポート専用モードで動かし、本来なら何をしていたかを確認できます。

代償は二つあります。条件付きアクセスでは、対象ユーザーに Microsoft Entra ID P1（または P2）ライセンスが必要です。P1 は Microsoft 365 Business Premium と E3・E5 スイートに含まれており、各プランの比較はMicrosoft 365 の料金ページをご覧ください。もう一つは、ポリシーの担当者が必要だということです。一度書いたきり見直されないポリシーは除外が積み重なり、やがてほとんど何も守らなくなります。

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

項目ごとの違い

ライセンス： セキュリティの既定値はすべてのテナントに含まれます。条件付きアクセスは対象ユーザーに Entra ID P1 または P2 が必要です。
制御の細かさ： 既定値は選択肢のない一つのスイッチ、条件付きアクセスは自分で書いて保守するポリシーの集合です。
一般ユーザーへの MFA： 既定値は Microsoft のシグナルが必要と判断したとき、条件付きアクセスはポリシーで決めたとおり（通常は毎回のサインイン）です。
除外： 既定値にはありません。条件付きアクセスでは任意のアカウントやグループを除外でき、これは強みであると同時にリスクでもあります。
レガシー認証： どちらもブロックできます。条件付きアクセスではそのためのポリシーを自分で書く必要があります。
テスト： 既定値にテストモードはありません。条件付きアクセスはまずレポート専用で動かせます。
保守する人： 既定値は Microsoft が、条件付きアクセスは自社または委託先が保守します。

小規模企業はどちらを使うべきか？

三つの質問で決まります。

保護したいユーザーに Entra ID P1 はあるか？ なければセキュリティの既定値を有効のままにしてください。P1 なしで既定値をオフにすれば何も残りません。どちらもないテナントは、監査が真っ先に指摘する種類の穴です。
ポリシーを担当する人はいるか？ P1 があっても、少なくとも四半期に一度ポリシーと除外を見直す人がいないなら、状況が変わるまでは既定値のほうが安全な場合があります。
既定値のせいで具体的に何かが壊れているか？ 古い機器やアプリが一つだけの問題なら、まずそれを直してください（モダン認証やサポートされたメールリレーへの移行など）。それに合わせるためにテナント全体の保護をオフにすべきではありません。

答えが「ある、いる、柔軟性が必要」なら条件付きアクセスに移行しましょう。Intune や Defender の機能を目当てに Business Premium を購入した小規模企業の多くは、すでにライセンスを持っているため、いずれこの段階に至ります。

途中で整理すべき状態がもう一つあります。古いテナントの中には、従来の MFA 設定ページでユーザーごとに MFA を有効にしているものがあります。これは条件付きアクセスと並存させるものではなく、切り替えの際に整理する三つ目の構成として扱ってください。

セキュリティの既定値から条件付きアクセスへ安全に切り替えるには？

セキュリティの既定値と条件付きアクセスは同時に動かせません。既定値が有効な間は、管理センターで条件付きアクセスポリシーを有効にできないからです。そのため切り替えには無防備な時間がどうしても生じます。目標はそれを数週間ではなく数分にすることです。準備を先に済ませ、切り替えは一度に行います。

ライセンスを確認する。 ポリシーの対象となるすべてのユーザーが、単体購入または Business Premium、E3/E5 スイート経由で Entra ID P1 を持っていることを確認します。
レガシー認証を使っているものを洗い出す。 サインインログをクライアントアプリで絞り込み、古いプロトコルを探します。複合機、業務アプリ、古いメールクライアントがここに現れます。切り替え前に修正または置き換えます。
緊急アクセス用アカウントを二つ作る。 クラウド専用、グローバル管理者、強力なパスキーを別々に保管し、専用グループでポリシーから除外して、監視します。
MFA の登録状況を確認する。 既定値の下では全員が登録済みのはずですが、確認してください。Entra でのレポートの作り方はMFA 未設定のユーザーをすべて見つける方法で解説しています。
ポリシーをレポート専用モードで作成する。 条件付きアクセスの基本ポリシーガイドの六つのポリシーを出発点にします。レポート専用のポリシーは、既定値が有効なままでも作成できます。
レポート専用の結果を少なくとも一週間確認する。 本来ならブロックや追加認証の対象になっていた、想定外のサインインがないかを探し、適用前に調整します。
一回の変更作業で切り替える。 セキュリティの既定値を無効にし、直ちに各ポリシーをレポート専用からオンに切り替えます。終える前に、管理者のサインイン、一般ユーザーのサインイン、緊急用アカウントをそれぞれテストします。
Microsoft が管理するポリシーを確認する。 P1 のあるテナントでは、Microsoft がレポート専用の状態で作成したポリシーが表示されることがあります。それぞれを残すか、有効にするか、自社のポリシーでカバーするかを決め、記録します。
サインインログを一週間監視する。 忘れていたサービスアカウントによる失敗は、たいてい最初の数日に現れます。

よくある失敗は？

既定値を「一時的に」オフにして忘れる。 その後テナントは MFA の要件がまったくない状態で動き続けます。
一人の問題を解決するためにグループ全体を除外する。 除外は個別のアカウントを指定し、理由と見直し日を付けるべきです。
緊急アクセス用アカウントがない、あるいは特定の一人のスマートフォンに依存している。
レポート専用を経ずに適用し、 ヘルプデスクへの問い合わせで影響に気づく。
レガシー認証が開いたまま。 それをブロックするポリシーが「後回し」にされていた。
ゲストやサービスアカウントを忘れる。 ゲストユーザーやアプリが使うアカウントもサインインします。各ポリシーの対象に含めるかを意図して決め、記録してください。
見直しの担当者がいない。 誰かのカレンダーに四半期ごとのリマインダーを設定し、ポリシーの一覧とすべての除外を読み直します。誰も見直さないポリシー群は、やがて穴だらけのセキュリティの既定値に逆戻りします。

監査はどこで役立つか？

テナントがすでに条件付きアクセスを使っているなら、問題はどちらを選ぶかではなく、ポリシーが書かれた当初の意図どおりに機能しているかです。どのポリシーが有効か、誰がなぜ除外されているか、レガシー認証は本当にブロックされているか、すべてのアカウントが何らかのポリシーの対象になっているか。これは設定監査の問いです。当社のMicrosoft 365 セキュリティ監査は、ID のレビューの一部として条件付きアクセスポリシーとその除外を確認します。現在の料金はそのページに掲載しています。導入作業そのものを任せたい場合は、MFA ソリューションサービスで設計、ユーザー登録、条件付きアクセスまで対応します。

よくある質問

セキュリティの既定値と条件付きアクセスは同時に使えますか？

使えません。どちらか一方です。既定値が有効な間は条件付きアクセスポリシーを有効にできないため、切り替えは一つの変更作業として計画する必要があります。

条件付きアクセスには Business Premium が必要ですか？

ポリシーの対象となるユーザーに Microsoft Entra ID P1 または P2 が必要です。Business Premium には P1 が含まれ、Microsoft 365 E3・E5 スイートにも含まれます。P1 は単体でも購入できます。

セキュリティの既定値でサイバー保険の質問票に答えられますか？

主要な質問には答えられることが多いです。すべてのユーザーへの MFA 登録、管理者への MFA、レガシー認証のブロックを求めるからです。ただし、メールへのすべてのサインインやすべてのリモートアクセスで MFA を強制しているかを問う書類では、条件付きアクセスの細かな制御が必要になる場合があります。質問を文字どおりに読み、日付入りの証跡で回答してください。