MENU

Azure必須MFA 2025年10月対応ガイド：管理者2名の小規模テナントはセキュリティの既定値と条件付きアクセスをどう選ぶべきか

Azure

2025年10月1日までにAzureテナントで多要素認証（MFA）を有効化するように、Microsoftから通知が届いた管理者も多いと思います。特に管理者アカウントが2名だけの小規模テナントでは、「セキュリティの既定値のままで十分なのか」「条件付きアクセスに切り替えるべきか」で悩みがちです。本記事では、Microsoftの“必須MFA”の正体と、小規模環境における現実的な対応パターンを整理します。

目次

シナリオ整理：管理者2名の小規模テナントに届いた「MFA有効化」の通知

まず、今回想定している状況を整理します。

  • テナントは小規模で、管理者は2名のみ（一般ユーザーがいても少数）
  • Microsoftから「2025年10月1日までに多要素認証（MFA）を有効化してください」という趣旨のメール・ポータル通知が届いている
  • 案内どおりに「条件付きアクセスでMFAポリシーを作ろう」とすると、
    「条件付きアクセスを有効にする前にセキュリティの既定値を無効にする必要があります」
    というメッセージが表示される
  • 現在はセキュリティの既定値（Security defaults）がオンになっていると思われる
  • 疑問は次の2点
    • 「セキュリティの既定値のままにしておき、管理者2人がMFA登録さえしておけば、2025/10/1以降も問題なく運用できるのでは？」
    • 「条件付きアクセスに切り替えるメリットは、小規模テナントにも本当にあるのか？」

結論から先に言うと、

  • “必須MFA”そのものは、セキュリティの既定値か条件付きアクセスかに関係なく適用されます
  • 管理者2名だけのテナントなら、セキュリティの既定値のままでも要件を満たすことは十分可能です
  • ただし、Entra ID P1/P2ライセンスがあるなら条件付きアクセスに移行した方が、将来を考えると運用しやすいケースが多いです

ここからは、その理由を順番に解説していきます。

“必須MFA”の正体：Azure側で何が変わるのか

Azure 全体で進む「必須MFA」のロードマップ

Microsoftは2024年から、Azureおよび管理ポータルへのサインインに対して、段階的にMFAを必須にするロードマップを進めています。公式ドキュメントでは、Azure管理系アプリに対して次のようなフェーズ制でMFAが強制されると説明されています。

フェーズ対象アプリ開始時期（予定）MFAが必須になる操作
フェーズ1Azure ポータル、Microsoft Entra 管理センター、Intune 管理センター、Microsoft 365 管理センター など2024年後半〜順次（Microsoft 365 管理センターは2025年2月〜）これらのポータルでのあらゆる作成・読み取り・更新・削除（CRUD）操作
フェーズ2Azure CLI、Azure PowerShell、Azure モバイルアプリ、IaCツール（Bicep/Terraform等）、Azure Resource Manager REST API / SDK2025年10月1日以降、順次ロールアウト作成・更新・削除（CUD）操作のみMFA必須（読み取りは不要）

ポイントは次の通りです。

  • AzureポータルやEntra管理センターなどのGUI管理ポータルでは、すでにフェーズ1が始まっている
  • 2025/10/1 以降は、CLI / PowerShell / Azureモバイルアプリ / IaC / REST API / SDK での CUD操作にもMFAが必須になる
  • これらはMicrosoft側の強制であり、セキュリティの既定値や条件付きアクセスをどう構成しているかに関係なく適用される

2025年10月1日以降に「必ず」起こること

セキュリティの既定値／条件付きアクセス／ユーザー単位MFAのいずれを使っていても、2025/10/1以降は、次のルールが自動的にかかります。

  • Azure CLI / Azure PowerShell / Azure モバイルアプリ / IaC ツール / Azure Resource Manager REST API / Azure SDK から、
    リソースの作成・更新・削除（CUD）を実行しようとしたユーザーは、必ずMFAを完了している必要がある
  • 読み取り専用の操作（例：リソース一覧取得、構成の確認など）は、MFAなしでも実行可能
  • 対話的なポータル（Azure ポータルやEntra管理センター等）については、フェーズ1の段階ですでにMFA必須になっているケースが多い
  • ブレークグラス（緊急用）アカウントであっても、これらのアプリにサインインして操作する場合はMFAが必要であり、MicrosoftはFIDO2パスキーや証明書ベース認証を推奨しています

つまり、

「セキュリティの既定値のままにするか」「条件付きアクセスに切り替えるか」は、あくまで“どうやってMFAを掛けるか”の話であって、“必須MFAそのものを回避できるかどうか”の話ではないという点が最重要です。

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

セキュリティの既定値とは？

セキュリティの既定値（Security defaults）は、Microsoft Entra ID が無料で提供している「最低限これだけは守って欲しい」ベースラインの設定パックです。

主な特徴は次のとおりです。

  • 追加費用不要（Entra ID Freeでも利用可能）
  • オン／オフの1スイッチだけで有効化できる
  • すべてのユーザーに対して、MFA登録とMFA利用を強く求める
  • レガシー認証（POP/IMAPなど）をブロックし、攻撃に弱いサインイン方式を止める
  • 細かい条件分岐（アプリごと・場所ごと・グループごと）はできない
  • 条件付きアクセスとは排他利用で、両方を同時に有効化することはできない

条件付きアクセス（Conditional Access）とは？

条件付きアクセス（CA）は、Entra ID P1/P2 ライセンスで利用できる、きめ細かなアクセス制御エンジンです。

  • ユーザー／グループ／ロールごとの制御
  • クラウドアプリ単位の制御（例：Azure管理系のみ、M365管理ポータルのみ等）
  • 場所・デバイス・リスク（P2）などの条件
  • MFAの強度（Authentication Strength）を指定可能
    • 通常のMFA強度
    • パスワードレスMFA強度
    • フィッシング耐性MFA強度（FIDO2/パスキーなど）
  • 「レポート専用（Report-only）」モードで事前検証ができる
  • 緊急用アカウントなどを柔軟に除外できる

Microsoftは、P1/P2 ライセンスを持っているテナントに対して、テンプレート化された条件付きアクセスやMicrosoft管理のCAポリシーも提供しており、「管理ポータルへのアクセスは必ずMFA」「全ユーザーにMFA」などを少ない手間で構成できるようにしています。

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

項目セキュリティの既定値条件付きアクセス（CA）
ライセンスEntra ID Free を含む全テナントで利用可Entra ID P1 / P2 が必要（M365 Business Premium / E3 / E5 等に含まれる）
設定の手間オンにするだけ。細かい設計は不要設計・検証が必要だが、テンプレートやMicrosoft管理ポリシーで負担軽減可能
MFAの制御粒度全ユーザーに一律でMFAを求めるイメージ。例外設定はほぼ不可ユーザー／グループ／ロール／アプリ／場所など、多軸で制御可能
MFA強度方法の選択肢は限定的。
フィッシング耐性MFA強度などは指定できない		Authentication Strengthで、
通常MFA・パスワードレス・フィッシング耐性MFAなどを明示的に指定可能
段階導入オンにした瞬間から一気に有効「レポート専用」で影響をモニタリングしてから本番化できる
緊急用（ブレークグラス）アカウント原則としてMFA必須となり、除外しづらいCAの対象から除外しつつ、Azure側の必須MFAはFIDO2等で満たす、といった設計が可能
既存環境との相性レガシーアプリ・サービスアカウントなどが動かなくなる可能性が高い自動化やB2Bゲストなど、複雑な環境でも個別にポリシーを調整しやすい

そしてもう一度強調すると、

「セキュリティの既定値」も「条件付きアクセス」も、Azureが実施する“必須MFA”とは別レイヤーです。どちらを選択しても、2025/10/1 以降に CLI / PowerShell / REST で CUD 操作を行う際にはMFAが必須になる事実は変わりません。

小規模テナントでは「既定値のまま」で足りるのか？

管理者が2名だけで、次のような条件であれば、セキュリティの既定値を有効にしたままでも、2025/10/1以降の必須MFA要件は十分満たせます。

  • 一般ユーザーは少数、もしくは存在しない
  • 管理作業は主にAzureポータルから行っており、CLIやIaCツールの利用頻度は低い
  • サービスアカウントや複雑な自動化（ユーザーIDで動くスクリプト等）がほとんどない

この場合にやるべきことはシンプルです。

  1. 管理者2人が、複数のMFA方法（できればフィッシング耐性を含む）を登録する
  2. Azureポータル／CLI／PowerShellなどから、実際にCUD操作を試してMFAが掛かることを確認する
  3. トラブル時の復旧手順（スマホ紛失、パスキー故障など）をシンプルに決めておく

一方で、たとえ小規模でも、次のような要件がある場合は条件付きアクセスへの移行を真剣に検討した方がよいです。

  • ISMSやSOC2などの監査要件で、「どのアプリにどの認証レベルを求めているか」を明示する必要がある
  • 既にFIDO2・パスキー中心のフィッシング耐性MFAに移行したい、または移行を検討している
  • B2Bゲストや複数テナント間でのアクセス、SaaS連携など、少しずつ環境が複雑になってきている
  • 今後ユーザー数や管理者ロールが増えていく予定がある

まとめると、

状況おすすめ理由
管理者2名・ユーザー少数・シンプル構成セキュリティの既定値のまま設定が簡単で、必須MFA要件も満たせる。運用負荷が最小
P1/P2ライセンスあり＋将来の拡張・監査が気になる条件付きアクセスに移行フィッシング耐性MFAやブレークグラス除外など、高度な設計ができる

パターンA：セキュリティの既定値を使い続ける場合の具体的ステップ

ここからは、実務でそのまま流用できるように、「既定値のまま運用」パターンのチェックリストを整理します。

1. セキュリティの既定値が有効か確認する

Entra 管理センターで次のように確認できます。

  1. Entra 管理センターにグローバル管理者でサインイン
  2. [Entra ID] > [概要] > [プロパティ] を開く
  3. 画面下部の「セキュリティの既定値を管理する」を選択
  4. 「セキュリティの既定値」が有効（Enabled）になっていることを確認

ここで既定値が無効になっている場合、すでに条件付きアクセスや別の仕組みでMFAをかけている可能性があります。

2. 管理者2名のMFA登録を「2経路以上」にしておく

Microsoftは、多要素認証の登録について、複数のサインイン方法を持つことを強く推奨しています。

具体的には、次のような組み合わせが現実的です。

  • 第一候補：パスキー（FIDO2） or Windows Hello / 生体認証対応デバイス
  • 第二候補：Microsoft Authenticator アプリのプッシュ通知
  • 第三候補：SMS / 電話 / TOTP など（あくまで予備として）

登録は、次の画面から行えます。

管理者2名とも、最低でも次を満たす状態にしておくと安心です。

  • パスキー（FIDO2）またはWindows Helloなど、フィッシング耐性のある方法を1つ以上
  • スマホ紛失時のために、別デバイスのAuthenticatorもしくは別のFIDO2キーを追加
  • どうしても物理トークンを用意できない場合は、電話番号によるコード受信も予備として登録

3. 実際にMFAが掛かることを確認する（ポータル／CLI／PowerShell）

「理論上は大丈夫そう」ではなく、実機確認をしておくことが重要です。

  • Azureポータル（https://portal.azure.com）で、リソースグループの作成やタグ編集などのCUD操作を実行し、MFAの挙動を確認
  • Azure CLI / Azure PowerShell を最新版にし、ログイン後に仮のリソース作成コマンドを叩いて、MFAが要求されるかを確認
  • IaCツール（Bicep/Terraform等）を使っている場合は、スクリプトからのデプロイ時にエラーが出ないかを確認

特に、ユーザーID＋パスワードだけで自動実行しているスクリプトがないかは必ず棚卸しておきましょう。Microsoftは、こうした「ユーザーアカウントをサービスアカウント代わりに使っているケース」を、マネージドIDやサービスプリンシパルなどのワークロードIDに移行するよう強く推奨しています。

4. トラブル時の復旧手順・相互支援フローを決めておく

管理者2名しかいない環境では、片方がロックアウトしたときにもう片方が助ける、という前提になります。

  • スマホ紛失時の手順
    • どちらがどの方法でセキュリティ情報を再登録するか
    • Authenticatorの再登録やパスキーの再登録の流れ
  • FIDO2キー紛失時の手順
    • 予備キーでログインし、失くしたキーを無効化する流れ
  • 両方とも何らかの理由でログインできない場合に備え、Microsoftサポートに問い合わせる窓口や契約を明確にしておく

このあたりを、一枚のメモやWikiにまとめておくだけでも、実際のトラブル時の心理的負担を大きく減らせます。

パターンB：条件付きアクセスへ切り替える場合の設計と手順

次に、Entra ID P1/P2 ライセンスがあり、条件付きアクセスへ移行するケースを整理します。小規模テナントでも、次のようなニーズがあるなら CA 移行は十分に「アリ」です。

  • 管理者は常にフィッシング耐性MFA（FIDO2 / パスキー等）でサインインさせたい
  • 緊急用アカウントをCAからは除外しつつ、Azure側の必須MFAにはきちんと対応させたい
  • 将来、ユーザー数やゲスト、サービスアカウントが増えても拡張しやすい仕組みにしておきたい

ステップ1：今の状態を棚卸しする

  • 現状セキュリティの既定値がオンか
  • 既にCAポリシーが存在していないか（存在していても、既定値がオンなら“無効”状態）
  • 自動化や外部連携で、ユーザーアカウントを使っているジョブがないか

特に、自動化部分は必須MFAで止まりやすいポイントなので、早めにワークロードIDへの移行計画を立てておくと安心です。

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

条件付きアクセスを有効化するには、セキュリティの既定値をオフにする必要があります。

  1. Entra 管理センターで [Entra ID] > [概要] > [プロパティ]
  2. 「セキュリティの既定値を管理する」をクリック
  3. ドロップダウンを 「無効（Disabled）」に変更し、理由として「条件付きアクセスを使う」などを選択
  4. [保存] をクリック

この時点では、まだCAポリシーを有効化していないので、「一瞬だけ緩くなる」時間が生まれる点に注意してください。とはいえ、すぐに次のステップでベースラインとなるCAを作成すれば、そのリスクは最小限に抑えられます。

ステップ3：セキュリティの既定値相当のCAポリシーを作る

Microsoftは、「セキュリティの既定値と同等の保護」を簡単に再現できるよう、条件付きアクセスのテンプレートを提供しています。

代表的なテンプレートは次の4つです。

  • 全ユーザーにMFAを要求（Require MFA for all users）
  • 管理者にMFAを要求（Require MFA for administrators）
  • Azure管理へのアクセスにMFAを要求（Require MFA for Azure management）
  • レガシー認証をブロック（Block legacy authentication）

小規模テナントであれば、まずは次の方針がシンプルです。

  • 全ユーザー＋全クラウドアプリに対してMFA必須のポリシーを1本作る
  • ブレークグラスアカウントと、一部自動化に使う専用アカウント（将来的にはワークロードIDに移行）を除外として設定
  • ポリシー状態を最初は「レポート専用（Report-only）」にして数日間のログを確認

問題がないことを確認できたら、ポリシーを「オン（Enable）」に切り替えます。

ステップ4：管理者だけ強いMFA（フィッシング耐性）を要求する

条件付きアクセスの利点を活かすなら、管理者だけはフィッシング耐性MFAを必須にするのがおすすめです。

  • 対象：グローバル管理者などの管理ロール
  • ターゲットリソース：すべてのクラウドアプリ、または管理ポータル系アプリ
  • Grantコントロール：「認証強度を要求」→「フィッシング耐性MFA」を選択
  • 除外：ブレークグラスアカウント

これにより、管理者は

  • FIDO2セキュリティキー
  • Windows Hello for Business
  • 証明書ベース認証（マルチファクター）

などの強固な方法でのみ、重要リソースにアクセスできるようになります。

ステップ5：運用ルールとドキュメントを更新する

条件付きアクセスに切り替えたら、次の情報を1枚の資料にまとめておくと運用が楽になります。

  • 現在有効なCAポリシー一覧（何のためのポリシーかを日本語でメモ）
  • ブレークグラスアカウントのIDと、CAから除外している理由
  • MFA強度の考え方（通常ユーザーは通常MFA、管理者はフィッシング耐性MFAなど）
  • ロールバック手順（誤ったポリシーでロックアウトしかけた場合にどのポリシーを無効にするか）

ブレークグラスアカウントと自動化アカウントの考え方

ブレークグラスアカウント（緊急用）の設計

2025/10/1以降の必須MFAの世界では、ブレークグラスアカウントもMFAから完全に逃れることはできません。AzureポータルやCLIでCUD操作を行う以上、Azure側でMFAが要求されるためです。

したがって、ブレークグラスアカウントは次のように設計するのが現実的です。

  • クラウド専用（オンプレADと同期しない）
  • 長く複雑なパスワード（パスワードマネージャに保管し、日常的には使わない）
  • フィッシング耐性MFA（FIDO2キーなど）を登録し、鍵自体も耐火金庫等で物理的に保管
  • 条件付きアクセスを導入している場合は、CAポリシーの対象から除外する（ただしAzure側の必須MFAからは除外されない点に注意）
  • サインインログに対してアラートを設定し、このアカウントのサインインがあったら必ず調査する

自動化・サービスアカウントの扱い

Microsoftは、ユーザーアカウントを自動化（スクリプト）に使うことをやめ、ワークロードIDに移行してほしいと明言しています。

  • マネージドID
  • サービスプリンシパル＋証明書／クライアントシークレット

などを使うことで、必須MFAの対象外として安定した自動化が可能になります。

もし現時点で、

  • 「ユーザーID＋パスワード」でログインするPowerShellスクリプト
  • ROPC（ユーザー名＋パスワードのみ）を使う古いMSALコード

などが存在する場合は、必ずワークロードID＋最新の認証ライブラリへの移行を検討してください。必須MFAの有無に関係なく、これらの方式は今後ますますサポートされなくなります。

小規模テナントならではの「よくある疑問」

Q. セキュリティの既定値のままでも、本当に何もしなくていい？

A. 「何もしなくていい」は言い過ぎですが、既定値がオンで、管理者2名がMFAをしっかり登録していれば、2025/10/1以降の必須MFAは基本的にクリアできます。ただし、「本番で突然MFA登録を求められて焦る」ことがないよう、事前にポータルやCLIでCUD操作を試してMFAの挙動を確認しておくことを強くおすすめします。

Q. すでに条件付きアクセスでMFAを必須にしている場合、何か変える必要はある？

A. Microsoftは、既にMFAを必須にしているテナントでは大きな変更は不要としています。ただし、今まで「社内IPからはMFA免除」といったポリシーを組んでいた場合でも、AzureポータルやCLI自身がMFAを要求するようになるため、結果的にMFAが必須になるケースが増える点には注意が必要です。

Q. どうしても準備が間に合わない場合、延期はできる？

A. Microsoftは、複雑な環境向けにフェーズ1／フェーズ2の enforcement を延期する仕組みを用意しています。グローバル管理者が専用のURLから延期日を選択できますが、その分攻撃リスクも高まり続けるため、小規模テナントではできるだけ延期せずに対応を完了させることをおすすめします。

Q. ユーザー単位MFA（昔のMFA画面）も設定した方がいい？

A. Microsoftは、条件付きアクセスまたはセキュリティの既定値を使っている場合、ユーザー単位MFAの画面で個別に有効化する必要はないと案内しています。むしろ、設定が二重になって混乱しやすいため、どの方式でMFAを統制するかを1つに決める方が運用しやすくなります。

まとめ：最小構成と将来の拡張性のバランスを取る

この記事で整理した内容を、最後にシンプルにまとめます。

  • Microsoftの“必須MFA”は、セキュリティの既定値／条件付きアクセスに関係なく適用される
    • 2025/10/1以降、Azure CLI・PowerShell・Azureモバイルアプリ・IaC・REST API・SDKでのCUD操作にはMFAが必須
    • 読み取りはMFA不要だが、管理ポータルではすでにCRUD全てにMFAが要求されるフェーズ1が進行中
  • 管理者2名の小規模テナントなら、セキュリティの既定値のままでも要件を満たせる
    • やるべきことは、管理者2名のMFA登録（できればフィッシング耐性＋予備手段）と、実機での動作確認
  • Entra ID P1/P2ライセンスがあるなら、条件付きアクセスへの移行が実務的には有利
    • ユーザー／アプリ／ロール単位で柔軟に制御可能
    • Authentication Strength でフィッシング耐性MFAを強制できる
    • レポート専用モードで検証してから本番化できる
  • ブレークグラスアカウントも、Azure管理に使う限りはMFA必須
    • FIDO2 / パスキーなどのフィッシング耐性MFAを登録し、CAからは除外する設計が現実的
  • 自動化は必ずワークロードIDへ移行
    • ユーザーアカウント＋パスワードのスクリプトやROPCは、必須MFAと相性が悪く、今後も非推奨

要するに、

  • 最低限の対応としては、セキュリティの既定値をオンのまま、管理者2名がしっかりMFA登録を行い、実際にAzureポータルやCLIで動作確認すればOKです。
  • 将来の拡張や監査・セキュリティレベルを重視する場合は、セキュリティの既定値を無効化し、条件付きアクセスで「全ユーザー×全クラウドアプリにMFA必須」「管理者にはフィッシング耐性MFAを要求」という構成に移行するのが王道です。

小規模テナントほど、設定はシンプルに、しかし管理者2人のMFAだけは過剰なくらい強固にする——それが、2025年以降のAzure管理を安全に続けるための、もっとも現実的な落としどころと言えるでしょう。

Azure
Azure MFA Microsoft Entra ID 条件付きアクセス セキュリティの既定値 小規模テナント

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次