サイバー保険 MFA 要件：Microsoft 365 で「すべてに MFA」とは実際に何を指すのか

要点： サイバー保険の質問票が「すべてに MFA を適用しているか」と尋ねるとき、それは通常、すべてのユーザー、すべての管理者、すべてのリモート入口、すべてのメールボックスを指し、例外は隠すのではなく明記することを求めています。Microsoft 365 では、日付入りの認証方法登録レポートと、それを強制する条件付きアクセス ポリシーのエクスポートで示します。本記事は MFA の一問だけを扱います。どのアカウントが対象か、どの方式が認められるか、例外をどう書くか、どの証拠を添えるかです。

多くのサイバー保険 MFA 要件は、更新時の質問票に一、二行で現れます。「リモート アクセスと電子メールを含め、すべてのユーザーに多要素認証を強制していますか」、そして最近増えているのが「すべての特権アカウントに MFA を強制していますか」です。質問は短いものの、正直に「はい」と答えるための作業は短くありません。後から「おおむね、はい」だったと分かる「はい」は、保険金請求の場面で最も問題になる種類のものです。

本記事はこの一問に留まります。質問票全体の答え方は、保険会社が求める Microsoft 365 の証拠のガイドで、香港企業が更新時に実際に経験することは香港での更新の視点で扱っています。ここでは MFA の一行を分解します。「すべて」が何を意味するか、どの方式が数えられるか、例外を「いいえ」と読まれないようにどう申告するか、そして Microsoft 365 テナントから何をエクスポートすれば証拠として使えるように設計された資料になるかです。

主に英国とオーストラリアの企業を念頭に書いています。この質問について当社に相談される方の多くがその地域にいるためですが、テナントの設定自体はどこでも同じです。

サイバー保険の質問票にある「すべてに MFA」とは何を指すのか

保険会社がこの言葉を定義することはほとんどないため、最も安全な読み方は最も広い読み方です。実務上、質問は六つのサインインの集合について尋ねており、完全な答えは六つすべてをカバーします。

• すべてのユーザー。 Microsoft 365 にサインインできるライセンス付きアカウントのすべてで、オフィス勤務の社員だけではありません。パートタイム、アカウントを持つ外部委託先、「Teams しか使わない」経理アシスタントも含まれます。
• すべての管理者。 Entra ID で特権ロールを持つすべてのアカウントです。グローバル管理者、Exchange 管理者、SharePoint 管理者、ユーザー管理者、セキュリティ管理者など。質問票では別の行になっていることがよくあります。
• リモート アクセス。 外部から社内システムに入れるすべての入口です。VPN、リモート デスクトップ ゲートウェイ、公開アプリケーション。クラウド中心の企業ではこれは主に Microsoft 365 そのものですが、VPN 機器がまだあるなら対象です。
• 電子メールと Web メール。 Outlook on the web、モバイル メール、そしてメールボックスを読めるすべてのプロトコル。これが別建てで挙げられる理由は、IMAP、POP、SMTP AUTH などのレガシー プロトコルがブロックされていない限り MFA を完全に迂回できるからです。
• 特権アカウントとサービス アカウント。 サインインが有効な共有メールボックス、「スキャナー」用アカウント、連携用アカウント、古いオンプレミス同期アカウント。保険会社は、MFA がひっそり効いていないのはこうした場所だと知っています。
• サードパーティ アプリケーション。 Microsoft 365 の ID（シングル サインオン）を使うクラウド アプリは MFA ポリシーを引き継ぎます。独自のログインを持つアプリは引き継がず、それについて尋ねる質問票もあります。

六つすべてに「はい」と言えるなら、すべてに MFA が適用されています。四つに「はい」、二つに「いいえ、理由は」と言えるなら、それでも正直に記述できる状態であり、後述の例外の節の主題です。

Microsoft 365 テナントで MFA が実際にカバーしているアカウントはどれか

正直な答えは MFA をどの方法で有効にしたかによります。サポートされる二つの仕組みは挙動が異なるからです。操作手順はMicrosoft 365 で MFA を有効にする手順ガイドにあります。ここでは、それぞれが質問票にとって何を意味するかを述べます。

セキュリティの既定値群はテナント全体の一つのスイッチです。オンにすると、すべてのユーザーが MFA の登録を求められ、管理者は常に MFA を要求され、レガシー認証はブロックされ、Azure の管理ポータルには MFA が必要になります。除外はありません。質問票にとっては好都合で、答えは「はい、テナント ポリシーによりすべてのユーザーに強制」、証拠は設定画面のスクリーンショットと登録レポートです。

条件付きアクセスは Microsoft Entra ID P1 で利用できるポリシー エンジンで、Microsoft 365 Business Premium に含まれます。全員に、管理者に、特定のアプリケーションに、あるいはリスクのあるサインインに MFA を要求でき、グループの除外もできます。柔軟性が価値であり、同時に問題でもあります。除外の一つひとつが MFA なしでサインインできるかもしれないアカウントであり、質問票が暗に尋ねているのはまさにそこです。よく設計されたベースライン、たとえば当社の条件付きアクセス ベースライン ガイドの六つのポリシーには、「すべてのユーザーに MFA を要求」「管理者に MFA を要求」「レガシー認証をブロック」が含まれ、それぞれが小さく名前の付いた緊急アクセス グループだけを除外します。

質問票が本当に探っているのは、「MFA をオンにした」と「サインインできるすべてのアカウントが実際に認証を求められる」の間の隙間です。隙間は通常、四つの場所にあります。

• 登録を求められたことがないアカウント。 ポリシーの対象でありながら、ポリシー適用後に一度もサインインしていなければ、認証方法が未登録のことがあります。登録レポートに表れます。
• 膨らんだ除外グループ。 二年の間に、取締役、コンサルタント、「IT の人」が加わった緊急アクセス除外グループ。
• まだ許可されているレガシー認証。 IMAP、POP、SMTP AUTH、古い Office クライアントは、ポリシーでブロックしない限りパスワードだけで認証できます。「はい」が実は「いいえ」である最も多い理由です。
• サインインが有効な共有メールボックスとサービス アカウント。 共有メールボックスはサインインをブロックすべきです。そうでなければ、パスワードを持ち、たいてい MFA のないユーザー アカウントです。

保険会社はどの MFA 方式について尋ね、何がフィッシング耐性とみなされるのか

この二年ほどで、質問は「MFA はあるか」から「どの種類か」に移りました。管理者がフィッシング耐性のある MFA を使っているかを直接尋ねる質問票もあれば、SMS がまだ使われているかを尋ねるものもあります。Microsoft 365 は複数の方式をサポートしますが、同等ではありません。

SMS・音声通話 vs 認証アプリ vs フィッシング耐性のある方式

• SMS と音声通話。 コードが電話番号に送られます。誰でも使え、アプリは不要ですが、最も弱い選択肢です。SIM スワップ詐欺も、コードを中継するリアルタイムのフィッシング ページも、これを破ります。多くの質問票が現在、これが唯一の方式かを尋ねており、望ましい答えは「いいえ、管理者では無効化済み」です。
• 認証アプリのプッシュ通知と番号照合。 ユーザーが通知を承認し、画面に表示された番号を入力します。Microsoft はプッシュ通知に番号照合を必須としており、「うっかり承認」の問題を塞ぎました。プロンプト連打には耐えますが、サインイン全体を中継する精巧なフィッシング ページには依然として脆弱です。一般ユーザーの妥当な既定です。
• フィッシング耐性のある方式：パスキー（FIDO2）、Windows Hello for Business、証明書ベースの認証。 資格情報が本物のサインイン ページに結び付けられるため、中継ページは再生できません。質問票の「フィッシング耐性 MFA」はこれを指し、少なくともグローバル管理者にはこれを期待する質問票が増えています。条件付きアクセスには「認証強度」の制御があり、指定グループに要求できます。
• 一時アクセス パスなどの回復用の方式。 オンボーディングと回復には適していますが、「ユーザーはどの MFA を使っているか」への答えにはなりません。

中小規模のテナントで守りやすい立場は、全ユーザーに番号照合付きの認証アプリ、認証強度ポリシーで特権ロールにフィッシング耐性のある方式を要求、SMS と音声は無効化するか記録済みの予備グループに限定、というものです。まだそこに至っていないなら、現在地と変更予定の時期を書いてください。保険会社は計画を引き受けることはできますが、後に事実でないと分かる記述を引き受けることはできません。

MFA の例外を「いいえ」と読まれないように書くには

ほぼすべての実在するテナントに例外があり、質問票にはたいてい自由記述欄があります。間違いは、欄を空にして「はい」にチェックすることです。より良い型は、「はい、以下の記録済みの例外あり」にチェックし、各例外について三つの情報を並べることです。何か、なぜ MFA が適用されないか、どの補完的な統制がカバーしているか。

• 緊急アクセス（ブレークグラス）アカウント。 MFA や条件付きアクセスが壊れたときにテナントを回復できるよう、MFA ポリシーから除外したクラウド専用の二つのアカウント。補完的な統制はオフライン保管の非常に長いパスワード、サインインのアラート、日常使用の禁止です。標準的でよく理解されている例外であり、名前を挙げて書くべきです。
• 共有メールボックス。 サインインがブロックされていれば（それが正しい設定です）、そもそも例外ではありません。そう書きます。「共有メールボックスは対話型サインインを無効化しており、ライセンス付きで MFA 保護されたユーザー アカウントからのみアクセスされる」。
• サービス アカウントと連携アカウント。 スキャンをメールで送る複合機、メールボックスを読むオンプレミスのアプリケーション。正直な書き方はプロトコルと統制です。「一つのサービス アカウントが固定の社内 IP から SMTP AUTH を使用し、条件付きアクセスでその場所に制限している。OAuth への移行を予定済み」。Microsoft は SMTP AUTH の基本認証の廃止を発表しているため、この例外には自然な終了日があり、質問票にそう書けます。
• レガシー デバイス。 認証アプリを動かせない倉庫の PC。デバイスに結び付いた方式（Windows Hello for Business）へ移すか、デバイス、ユーザー、到達できるデータ、交換日を記録します。
• ゲスト。 Teams や SharePoint に招待された外部ユーザー。条件付きアクセス ポリシーがゲストに MFA を要求しているか（要求すべきです）、相手のホーム テナントの MFA を信頼しているかを明記します。

このように書かれた例外は、穴ではなくガバナンスとして読まれます。「はい」と空欄を見た引受担当者は推測するしかありませんが、統制と日付の付いた五つの名前付き例外を見た担当者はリスクに値段を付けられます。

保険会社はどんな証拠を求め、Microsoft 365 から何をエクスポートできるのか

質問票そのものは申告であり、証拠はその背後にあります。更新時、請求時、あるいはブローカーがより良い市場にリスクを置こうとするときに求められることがあります。以下はすべて、何も購入せずにテナントから出せるもので、エクスポート時にテナントが日付を付けます。

1. 認証方法の登録レポート。 Entra ID は、どのユーザーがどの方式を登録し、誰が「MFA 対応」かを報告します。CSV にエクスポートします。ポリシーの意図ではなくアカウントごとのカバー状況を示すため、MFA の質問に対して最も役立つ一枚です。
2. 条件付きアクセス ポリシーのエクスポート。 各ポリシーのユーザー、除外、クラウド アプリ、条件、許可の制御。除外のリストが、例外の節が完全であることの証明になります。
3. レガシー認証のサインイン レポート。 サインイン ログを過去 30 日のレガシー クライアント アプリで絞り込んだもの。空であることが望む答えで、空でなければ「ブロック済み」と言う前に対処すべきデバイスが分かります。
4. 特権ロールのメンバー。 各管理者ロールのアカウント一覧と、それぞれが使う方式。「特権アカウントの MFA」の行に対応します。
5. セキュリティの既定値群または認証強度のスクリーンショット。 テナント名と日付が見える設定画面。
6. 短い例外台帳。 前節の五項目に、責任者とレビュー日を添えたもの。

当社の Microsoft 365 セキュリティ監査はまさにこの一式を、専門外の経営者にも読める形で作成します。サンプルの監査レポート（英語ページ）は MFA の指摘がどう示されるかを示しています。方式未登録のアカウント数、その中の管理者、まだ開いているレガシー プロトコル、ポリシーの除外、それぞれに修正手順とロールバックが付きます。レポートと証拠ワークブックは、保険の質問票で証拠として使えるように設計されています。引受の結果を決めるものではなく、当社がそう言うこともありません。

正直な「はい」が間違いだったと分かるよくある場所はどこか

MFA の申告をテナントと照合したときに最もよく見つかるのが以下です。珍しいものは一つもありません。

• ユーザーごとに「有効」だが「強制」されていない MFA。 古いユーザー単位の MFA 設定には「有効」と「強制」の状態があり、「有効」はユーザーが登録を完了するまでパスワードのみのサインインを許します。何年も前にこの方法で設定されていれば、一部のアカウントがまだこの状態かもしれません。
• レポート専用モードのままの条件付きアクセス ポリシー。 レポート専用はポリシーをテストする正しい方法ですが、何も強制しません。作成した日からレポート専用のままのポリシーは、質問票の目的では存在しないのと同じです。
• 誰もレビューしない除外グループ。 二つの緊急アカウントのために作られたグループに、今は九人のメンバーがいます。
• ブロックされていないレガシー認証。 セキュリティの既定値群はブロックしますが、条件付きアクセスはポリシーが明示する場合にのみブロックします。そのポリシーがなければ、パスワードで IMAP が通ります。
• ポリシー エンジンのない Microsoft 365 Business Basic テナント。 Entra ID P1 がなければ、選択肢はセキュリティの既定値群か何もなしです。販売代理店が開設してから一度も見直されていないテナントでは、「何もなし」が驚くほど多くあります。
• 日常のアカウントを使う管理者。 同じアカウントがメールを読み、添付ファイルを開き、同時にグローバル管理者を保持しています。MFA はオンかもしれませんが、一通のフィッシングの影響範囲はテナント全体です。これを直接尋ねる質問票も出てきています。

これらはどれも設定であり、プロジェクトではありません。難しいのは、自分のテナントにどれが当てはまるかを知ることで、だからこそ最初の一歩は作り直しではなく読むことです。

MFA の質問は Cyber Essentials などの制度とどう関係するのか

英国の読者には直接の重なりがあります。Cyber Essentials のバージョン 3.3 は、クラウド サービスでの MFA を推奨ではなく要件として扱い、MFA を提供しているのに無効のままのクラウド サービスは自動的に不合格です。Cyber Essentials の設定ごとのガイドで Microsoft 365 側を説明しています。実務上のポイントは、上記の証拠一式が保険会社と制度の評価者の両方に答えるので、一度作って最新に保つ価値があるということです。

オーストラリアの読者の場合、質問票は Essential Eight の成熟度モデルを参照することが多く、MFA は八つの戦略の一つで、成熟度レベルは「リモート ユーザーの MFA」と「全員にフィッシング耐性のある MFA」を区別します。要求の厳しい保険会社を満足させる Microsoft 365 の構成と、高い成熟度レベルに達する構成は同じ構成です。当社はどちらの制度に対しても認証や評価は行いません。テナントを読み、何が示されるかをお伝えします。

証拠パックを作成し、お客様の勤務時間に合わせて説明できる提供者が必要なら、英国（英語ページ）とオーストラリア（英語ページ）のページで当社のリモート提供の仕組みを説明しており、監査ページにも英国・オーストラリアの購入者向けの節があります。

よくある質問

「すべてのユーザーに MFA」にはゲストや外部ユーザーも含まれますか

質問票が「すべてのユーザー」と書いていれば、通常は含まれます。Entra ID では、ゲストは条件付きアクセスで選択できる範囲なので MFA を要求でき、テナント間アクセス設定で相手組織の MFA を信頼するなら、二度尋ねる代わりにそれを受け入れることもできます。どちらを選んでも例外欄に書いてください。

SMS ベースの MFA はまだ保険会社に受け入れられますか

一般ユーザーには受け入れ、管理者には反対する会社もあれば、SMS を使っているかどうか自体の申告を求める会社もあります。特定の保険会社がどう扱うかはお伝えできませんし、正直な人なら誰もできません。言えるのは、特権ロールで SMS と音声を無効化し、フィッシング耐性のある方式に移すことは小さな変更であり、この質問自体を消せるということです。

Microsoft 365 の用語で、フィッシング耐性のある MFA とは何ですか

パスキー（FIDO2 セキュリティ キー、または Authenticator アプリのデバイスに結び付いたパスキー）、Windows Hello for Business、証明書ベースの認証です。条件付きアクセスは認証強度ポリシーでこのいずれかを要求でき、通常は管理者ロールから適用します。

Microsoft 365 セキュリティ監査で、すべてに MFA があることを証明できますか

読み取った日付時点でテナントがどう構成されているかを、除外とまだ開いているレガシー プロトコルを含め、アカウントごとに示します。レポートは証拠として使えるように設計されています。認証ではなく、引受担当者が納得するかどうかは当社ではなく先方の判断です。

Microsoft 365 Business Basic を使っています。それでも「はい」と答えられますか

はい。セキュリティの既定値群をオンにすれば、サブスクリプション以外のライセンスなしで、すべてのユーザーに MFA 登録を強制し、レガシー認証をブロックします。何も除外できなくなりますが、小さなテナントではそれがむしろ利点のことが多いです。除外や、管理者へのフィッシング耐性のある方式の強制が必要なら Entra ID P1 が必要で、Business Premium に含まれています。

Cyber Essentials は Microsoft 365 上の MFA をどう扱いますか

制度のバージョン 3.3 は、クラウド サービスが MFA を提供している場合は常に MFA を要求し、利用可能なのに無効の MFA はその統制項目で自動的に不合格として扱われます。監査は認証を付与も保証もしません。評価者が見つける前に、テナントがどこで不足するかをお伝えします。

証拠を揃えるのにどれくらいかかりますか

MFA が条件付きアクセスで既に強制されているなら、半日です。登録レポート、ポリシー、レガシー サインイン レポート、ロール メンバーをエクスポートし、例外台帳を書きます。そうでなければ、エクスポートが先に直すべきものを教えてくれます。当社の監査は、読み取り専用の同意から 5〜7 営業日で同じ指摘を優先順位付きのリストとして返し、1〜10 ユーザーのテナントで US$450 からです。

次のステップ

更新の質問票が手元にあるなら、登録レポートと条件付きアクセスのエクスポートから始めてください。それだけで MFA の行の大半に答えられます。誰かにテナント全体を読んでもらい証拠パックを書いてもらいたいなら、Microsoft 365 セキュリティ監査は人数別の固定料金で、リモートで 5〜7 営業日で提供します。MFA がそもそも正しく展開されていなかったという結果なら、当社の MFA ソリューションチームがその作業を行い、会計事務所での展開事例は、ロックアウトを許容できない企業での段階的な展開の様子を示しています。あるいは質問票を持ってコンサルタントにご相談ください。