Entra IDセキュリティの既定値群vs条件付きアクセス【2026年版】違い・使い分け・移行ガイド

「セキュリティの既定値群」はなぜ重要なのか

Microsoft 365やEntra ID（旧Azure Active Directory）を使っている企業のテナント管理者が一度は目にする「セキュリティの既定値群（Security Defaults）」。この機能は、多くの企業が「とりあえず有効にしておけばいい」と思っている一方で、「有効にしたらMFAが強制されてユーザーが困った」というトラブルも頻発しています。

Microsoftの調査によれば、セキュリティの既定値群を有効化するだけで、アカウント乗っ取りのリスクを80%以上低減できるとされています（Microsoft Security Blog, 2024）。しかし、有効化のタイミングや無効化が必要なケースを誤ると、業務に支障が出ることもあります。

本記事では、セキュリティの既定値群の仕組み・有効化手順・無効化が必要なケース・代替策としての条件付きアクセスまでを、テナント管理者向けに実務目線で解説します。

セキュリティの既定値群（Security Defaults）とは

セキュリティの既定値群とは、Microsoftが提供するEntra ID（旧Azure AD）の基本的なセキュリティ設定のプリセットです。2019年10月以降に作成されたテナントではデフォルトで有効になっており、既存テナントでも推奨設定として案内されています。

Security Defaultsが有効化する主な機能

Security Defaultsで防げる攻撃

• パスワードスプレー攻撃：多数のアカウントに同じパスワードを試す攻撃
• クレデンシャルスタッフィング：漏洩したID/パスワードリストを使った不正ログイン
• レガシー認証プロトコルを悪用した攻撃：MFAを回避できる古いプロトコル経由の侵入

Microsoftのデータによると、多要素認証（MFA）を有効にするだけでアカウント侵害の99.9%以上を防げるとされています。

Security Defaultsの設定確認・有効化手順

現在の状態を確認する方法

1. Microsoft Entra 管理センター（entra.microsoft.com）にグローバル管理者でサインイン
2. 左メニューから「Identity」→「Overview」→「Properties」を選択
3. 画面下部の「セキュリティの既定値群の管理」をクリック
4. 「セキュリティの既定値群を有効にする」のトグルで現在の状態を確認

または、旧Azureポータル（portal.azure.com）からは「Microsoft Entra ID」→「プロパティ」→「セキュリティの既定値群の管理」でアクセスできます。

有効化する手順

上記画面のトグルを「はい（有効）」に切り替えて保存するだけです。有効化後は次の変化が起きます。

1. 全ユーザーに「Microsoft Authenticatorの登録を求める」メッセージが表示される
2. 14日間の猶予期間中は登録をスキップ可能（期間後は強制）
3. レガシー認証を使っているクライアントはサインインできなくなる

有効化前に確認すべきこと：古いメールクライアント（Outlook 2010以前など）を使っているユーザーはいないか / SMTP AUTH・IMAPを使う業務アプリや複合機はないか / スクリプトやサービスアカウントでパスワード認証を使っている箇所はないか

セキュリティの既定値群の有効化で起きがちな問題

問題1: レガシークライアントからのメール送受信ができなくなる

症状：複合機（スキャン→メール転送）や古い業務システムのメール送信が突然失敗する。

原因：Security Defaultsはレガシー認証（SMTP AUTH等）をブロックするため、モダン認証に対応していない機器・アプリが使えなくなります。

対処法：複合機のFirmwareを更新してモダン認証（OAuth 2.0）に対応させる。対応できない場合は、特定のサービスアカウントのみレガシー認証を許可する条件付きアクセスポリシーを設定（Security Defaultsを無効化して条件付きアクセスへ移行）。

問題2: MFAの登録方法がわからないと問い合わせが殺到する

対処法：有効化前に社内通知メールを送り、Microsoft Authenticatorのダウンロード・設定手順のマニュアルを配布する。ヘルプデスク対応を事前に準備しておく。

問題3: 海外出張中のユーザーがログインできない

症状：海外IPからのアクセスをブロックするルールがある場合、MFA確認用のSMSが届かない、または認証が失敗する。

対処法：Microsoft Authenticatorアプリのプッシュ通知方式に切り替えると、海外でもモバイルデータ通信があれば認証できる。

Security Defaultsの無効化が必要なケース

注意：Security Defaultsを無効化した後は、必ず条件付きアクセスポリシーを設定して同等以上のセキュリティを確保してください。無効化しただけでは裸の状態になります。

Security Defaults vs 条件付きアクセス（Conditional Access）

推奨判断フロー：

1. Microsoft 365 Business BasicやE3を使っていてP1ライセンスがない → Security Defaults を有効化
2. Microsoft 365 Business Premium以上 or Entra ID P1/P2を持っている → 条件付きアクセスに移行を検討
3. 複合機・業務システムでレガシー認証が必須 → Security Defaultsを無効化して条件付きアクセスで除外ポリシーを設定

P1/P2ライセンスとSecurity Defaultsの関係

Security Defaultsを使える状態でも、Microsoft 365 Business PremiumやEntra ID P1以上のライセンスがあれば、より細かい制御ができる条件付きアクセスへの移行が推奨されます。

P1で追加できる主な条件付きアクセス機能：

• 場所（国・IPアドレス）ベースのアクセス制御
• デバイスコンプライアンス（Intuneで管理されたデバイスのみ許可）
• サインインリスクベースのMFA要求（Entra ID Protection）

P2で追加できる機能：

• ユーザーリスクベースのポリシー
• 特権ID管理（PIM: Privileged Identity Management）

Security Defaults有効化前の最終チェックリスト

• 全ユーザーのスマートフォン（Authenticatorアプリ導入用）の有無を確認
• レガシー認証を使っているシステム・機器をリストアップ（複合機・業務アプリ・スクリプト）
• 社内ヘルプデスクにMFA登録手順マニュアルを配布
• 緊急アクセスアカウント（ブレークグラスアカウント）の扱いを決定
• 有効化後の14日間猶予期間中にヘルプデスク増員を手配
• 有効化日をユーザーに事前通知（1〜2週間前に告知推奨）

まとめ：まず有効化・そして条件付きアクセスへ

セキュリティの既定値群（Security Defaults）は、無料で使えるMFA強制機能として、アカウント乗っ取りリスクを劇的に低減できます。特にP1ライセンスを持っていない中小企業では、有効化しない理由がない設定です。

一方、複合機やレガシー業務システムがある環境では、事前調査と関係者への周知が必要です。段階的に「Security Defaults有効化 → トラブル対応 → 条件付きアクセスへ移行」という順序で進めると、セキュリティ水準を着実に引き上げられます。

AEVUSでは、Entra IDを含むMicrosoft 365環境のセキュリティ設定診断・評価を行っています。「Security Defaultsを有効にしたいが影響範囲が不安」という方は、まずお気軽にご相談ください。

関連記事

• Entra ID セキュリティ設定チェックリスト【2026年版】
• クラウド設定ミス10選と対策【AWS・Azure・Microsoft 365対応】
• Microsoft 365 セキュリティアセスメントガイド

セキュリティの既定値群から条件付きアクセスへの移行手順

セキュリティの既定値群（Security Defaults）は手軽にベースラインセキュリティを適用できる反面、ポリシーの細かな制御ができません。条件付きアクセスへ移行することで、組織の実態に合わせた柔軟なアクセス制御が実現できます。以下の5ステップで計画的に移行を進めてください。

ステップ1：移行前の準備

• ライセンスの確認：条件付きアクセスはMicrosoft Entra ID P1以上（またはMicrosoft 365 Business Premium）が必要です。Entra管理センターの「ライセンス」ページでP1/P2ライセンスが全対象ユーザーに割り当てられていることを確認します。
• 現在のサインインログの確認：Entra管理センター →「監視とヘルス」→「サインイン ログ」で、過去30日間のサインイン状況をエクスポートします。レガシー認証（SMTP AUTH、POP3、IMAP、EWS等）を使用しているユーザーやアプリを洗い出しておきます。
• 緊急アクセス用アカウントの確認：条件付きアクセスポリシーから除外するブレークグラスアカウント（緊急アクセス用グローバル管理者アカウント）が2つ以上存在することを確認します。このアカウントはMFAを要求せず、フィッシング耐性のある認証方法（物理セキュリティキーなど）と組み合わせて管理します。
• MFA登録状況の確認：Microsoft Graph PowerShellを使用してMFA未登録ユーザーのリストを取得します。MFA未登録ユーザーには、移行前にセルフサービスMFA登録（aka.ms/mfasetup）を案内し、登録を完了させておきます。

ステップ2：セキュリティの既定値群の無効化

条件付きアクセスポリシーを作成・検証した後、セキュリティの既定値群を無効化します。両者は同時に有効にできないため、必ずポリシーの準備が完了してから実施してください。Entra管理センター →「Identity」→「概要」→「プロパティ」→「セキュリティの既定値群の管理」リンクをクリックし、トグルを「無効」に切り替えます。無効化の理由として「My organization is using Conditional Access」を選択して保存します。

ステップ3：条件付きアクセスポリシーの作成

セキュリティの既定値群が提供していた保護と同等以上のポリシーを条件付きアクセスで再現します。最低限、以下のポリシーを作成してください。

• 全ユーザーへのMFA要求：対象ユーザーを「すべてのユーザー」、対象クラウドアプリを「すべてのクラウドアプリ」に設定し、アクセス制御の「許可」で「多要素認証を要求する」を選択します。
• レガシー認証のブロック：条件の「クライアントアプリ」で「レガシー認証クライアント」にチェックを入れ、アクセス制御を「ブロック」に設定します。
• 管理者へのMFA要求：対象ユーザーを「ディレクトリ ロール」で特権ロールに絞り、MFAを要求します。

新規ポリシーは最初に「レポート専用」モードで作成することを強く推奨します。レポート専用モードではポリシーが実際には適用されませんが、サインインログにシミュレーション結果が記録されます。

ステップ4：テスト（レポート専用モードでの検証）

ポリシーを「レポート専用」モードで最低1週間運用し、影響を分析します。Entra管理センターのサインインログで「失敗（レポート専用）」となっているサインインを特定し、どのユーザー・アプリが影響を受けるかを把握します。影響を受けるユーザーへの事前周知や、サービスアカウントへの除外設定を追加します。「What If」ツールを使用して、特定ユーザー・条件に対するポリシー適用結果をシミュレーションします。

ステップ5：本番適用

テスト結果を踏まえて問題がないことを確認したら、各ポリシーの状態を「レポート専用」から「オン」に切り替えます。影響の小さいポリシー（レガシー認証のブロックなど）から順に有効化し、ヘルプデスクが対応できる時間帯（平日の午前中など）を選択します。有効化後24時間はサインインログを監視し、予期しないブロックが発生していないか確認します。

条件付きアクセス 推奨ポリシー設定チェックリスト

カテゴリー1：MFA必須化

カテゴリー2：レガシー認証ブロック

カテゴリー3：管理デバイス要件

カテゴリー4：リスクベース認証

カテゴリー5：場所ベースのポリシー

Entra ID セキュリティ設定でよくあるトラブルと対処法

トラブル1：条件付きアクセスポリシーの適用でユーザーがロックアウトされた

症状：新しいポリシーを有効化した直後から、ユーザーがサインインできなくなりヘルプデスクに問い合わせが殺到する。

対処法：緊急アクセス用ブレークグラスアカウントでEntra管理センターにサインインします（このアカウントはすべての条件付きアクセスポリシーから除外している必要があります）。「保護」→「条件付きアクセス」から問題のポリシーを特定し、状態を「オフ」に変更します。サインインログで影響を受けたユーザーと失敗理由を確認し、除外グループにロックアウトされたユーザーを一時的に追加してアクセスを回復させます。

予防策：ポリシー作成時は必ず「レポート専用」モードで1週間以上検証する。緊急アクセスアカウント（2アカウント以上）をすべてのポリシーの除外グループに含める。

トラブル2：MFAが設定できないユーザーが発生している

症状：MFA登録を案内しても「認証方法が表示されない」「電話番号の登録ができない」というユーザーからの問い合わせが発生する。

対処法：Entra管理センター →「保護」→「認証方法」→「ポリシー」で、Microsoft Authenticator・SMS・音声通話等が有効になっているか確認します。条件付きアクセスポリシーがMFA登録自体をブロックしている可能性がある場合は、「ユーザー操作」として「セキュリティ情報の登録」を対象にしたポリシーを確認します。スマートフォンを業務に使用できないユーザーにはFIDO2セキュリティキー（YubiKey等）を認証方法として用意します。Entra管理センター →「ユーザー」→対象ユーザー →「認証方法」から一時アクセスパス（TAP）を発行し、ユーザーがTAPを使って初回サインインしてから認証方法を登録できるようにすることも有効です。

トラブル3：セキュリティの既定値群を無効化した後に不審なサインインが増加した

症状：既定値群を無効化して条件付きアクセスへ移行した直後から、サインインログに海外IPからの攻撃が多数記録されるようになった。

対処法：Entra管理センターのサインインログでフィルターを「失敗」「クライアントアプリ：その他のクライアント」に設定し、レガシー認証経由の攻撃が発生していないか確認します。レガシー認証ブロックポリシーが「オン」（「レポート専用」ではない）になっているかを確認します。「保護」→「認証方法」→「パスワード保護」でSmart Lockout設定を確認し、攻撃が激しい場合はしきい値を下げることを検討します。

予防策：既定値群の無効化と同時に、MFA必須ポリシーおよびレガシー認証ブロックポリシーを「オン」の状態に切り替える。移行当日は30分ごとにサインインログを確認する。

トラブル4：サービスアカウントや自動化スクリプトがMFAで止まる

症状：Azure DevOps、Power Automate、サードパーティSaaSとの連携スクリプトが、MFA必須ポリシーの適用後にエラーを返すようになった。

対処法：Azureリソースを使用している場合は、システム割り当てマネージドIDまたはユーザー割り当てマネージドIDを使用することで、資格情報の管理とMFAの問題を根本的に解消できます（最推奨）。Microsoft Entra管理センターでアプリ登録を行い、クライアントシークレットまたは証明書を使用した認証に切り替えることも有効です。サービスプリンシパルは条件付きアクセスのユーザーポリシー対象外です。

トラブル5：ゲストユーザーやB2Bユーザーがアクセスできなくなった

症状：取引先や外部パートナーがSharePoint・Teamsへのアクセス時にブロックされる。

対処法：「クロステナントアクセス設定」（Entra管理センター →「外部 ID」→「クロステナントのアクセス設定」）で、信頼できるパートナーテナントのMFA要求を信頼する設定を有効にします。これにより、相手テナントで既にMFAを完了しているユーザーは自組織で改めてMFAを求められなくなります。ゲストユーザー向けの条件付きアクセスポリシーを別途作成し、対象を「すべてのゲストおよび外部ユーザー」に限定した上でアクセス可能なアプリとMFA要件を適切に設定します。