Microsoft 365 セキュリティ監査とペネトレーションテストの違い：保険会社・監査人・取締役会が本当に求めているのはどちらか

要点： Microsoft 365 セキュリティ監査は、公開されたベンチマークに照らしてテナントの設定を確認し、何から直すべきかを示します。ペネトレーションテストは、テスト担当者が実際に侵入を試み、攻撃者がどこまで到達できるかを示します。サイバー保険の質問票は主に設定（MFA、管理者アカウント、メールセキュリティ、ログ）を問うため、監査で答えられます。一部の監査人やフレームワークはペネトレーションテストを名指しで求めます。取締役会は多くの場合両方を必要としますが、順序は「まず設定を直し、その後でテストする」です。

IT 部門の外から「セキュリティテストを実施してほしい」と求められる場面は必ず来ます。サイバー保険の更新書類、取引先のサプライヤー向けセキュリティ質問票、外部監査人、あるいはニュースを見た取締役からかもしれません。こうした依頼がテストの種類まで指定することはほとんどありません。よく挙がる二つの答え、Microsoft 365 セキュリティ監査とペネトレーションテストは別のサービスであり、得られる証跡も異なります。

本記事では、両者を買い手の立場から比較します。それぞれが何を調べるのか、依頼する側が通常何を意図しているのか、そして監査で一覧にできる設定の問題をわざわざペネトレーションテストで見つけ直すことにならないよう、どの順番で進めるべきかを説明します。継続的な脆弱性スキャンやパッチ管理を含む全体像は、脆弱性管理とペネトレーションテストの比較ガイドをご覧ください。本記事は Microsoft 365 テナントに絞って扱います。

Microsoft 365 セキュリティ監査は何を確認するのか？

Microsoft 365 セキュリティ監査は設定のレビューです。Microsoft 365 の中には自社のサーバーがないため、スキャンする対象はなく、範囲はテナントの各設定と、誰がどのデータに到達できるかになります。適切な監査は公開ベンチマーク（通常は CIS Microsoft 365 Foundations Benchmark）に沿って項目ごとに確認し、各コントロールについて適合しているかどうかを証跡付きで記録します。

実際には主に三つの領域を扱います。

• Entra ID の ID 管理： ユーザーごとの MFA の適用状況（サービスアカウントや緊急用アカウントを含む）、条件付きアクセス ポリシーとその除外、特権ロール、レガシー認証、サードパーティ アプリへの同意、ゲスト アカウント。
• Exchange Online と Defender for Office 365： すべてのドメインの SPF・DKIM・DMARC、外部への自動転送と受信トレイ ルール、フィッシング対策と安全なリンクのポリシー、メールボックス監査と監査ログの保持期間。
• SharePoint・OneDrive・Teams とデータ： 外部共有と「すべてのユーザー」リンク、秘密度ラベルと保持ポリシー、Teams の外部アクセス、会社のファイルを開ける個人端末。

成果物は、重大度ごとに分類した指摘事項の一覧、各指摘の裏付けとなる証跡、優先順位付きの是正計画です。質問票に回答する際の証跡として使えるよう設計されていますが、それ自体が何かを認証するものではありません。架空の顧客を使ったMicrosoft 365 監査のサンプルレポート（英語）で形式を確認できます。

監査が行わないのは攻撃そのものです。MFA が未登録のアカウントがいくつあるかは示せますが、そのアカウントでログインを試みることはしません。

Microsoft 365 を対象にしたペネトレーションテストとは？

ペネトレーションテストは、許可を得たうえで期間を区切って侵入を試みる作業で、テスト担当者は成功した手順を一つずつ記録します。中小企業の場合、「ペネトレーションテスト」は通常、インターネットに公開された境界、社内ネットワーク、または特定の Web アプリケーションが対象です。当社のペネトレーションテスト サービスでは、外部、内部、Web アプリケーション、ソーシャルエンジニアリングといった一般的な種類を紹介しています。

Microsoft 365 は少し事情が異なります。プラットフォーム自体は自社のものではないからです。Microsoft は Microsoft 365 を含む自社クラウドサービスを対象とした「Microsoft Cloud Unified Penetration Testing Rules of Engagement」を公開しています。テストは自社のテナントと許可されたアカウントの範囲内に限られ、サービス妨害（DoS）テストや他の顧客を対象とした行為は禁止されています。そのため、Microsoft 365 が関わるペネトレーションテストは、実質的には自社の ID、設定、従業員のテストになります。有効な資格情報を入手できるか、MFA で止められるか、フィッシングで奪われたセッションでメールやファイルに到達できるか、権限の低いアカウントから昇格できるか、といった点です。

これには価値がありますが、その多くが設定に左右されることに注意してください。レガシー認証が有効なままである、管理者がフィッシング耐性のある MFA を使っていない、といった点は監査でも見つかります。テスト担当者も同じ問題を見つけるでしょう。先に直せたはずの指摘に、より高い費用と時間をかけてたどり着くことになります。

セキュリティ監査・ペネトレーションテスト・脆弱性スキャンの比較

三つを並べると

• 答える問い： 監査は「テナントはベンチマークの推奨どおりに設定されているか」、ペネトレーションテストは「実際に侵入できるか、どこまで到達できるか」、脆弱性スキャンは「これらのシステムに現在どの既知の弱点が見えているか」。
• 方法： 監査は設定とログの読み取り専用レビュー、ペネトレーションテストは合意したルール内での許可された攻撃、スキャンは自動化された反復可能な検査。
• Microsoft 365 での範囲： 監査はテナント内のすべてのワークロード、ペネトレーションテストは Microsoft のルールの範囲内で自社の ID・設定・人、ネットワークの脆弱性スキャンは Microsoft 365 の内部をまったく見ません。
• 主な成果物： 監査は重大度別の指摘一覧・証跡・是正計画、ペネトレーションテストは各手順の証拠を伴う攻撃の経緯、スキャンは重大度順の脆弱性リスト。
• 適した証跡の用途： 監査は保険の質問票や設定に関する質問、ペネトレーションテストはそれを名指しで求めるフレームワークや契約、スキャンはサーバーや端末の日常的な衛生管理。
• 陳腐化の速さ： いずれもある時点の状態を示すものです。監査とスキャンは繰り返しやすく、ペネトレーションテストは相対的に負担が大きくなります。

サイバー保険会社は通常何を聞いているのか？

更新書類は文字どおりに読みましょう。多くのサイバー保険の申込質問票が問うのは管理策です。メールとリモートアクセスで MFA を必須にしているか、管理者アカウントは分離され保護されているか、レガシー認証はブロックされているか、バックアップは取得・検証されているか、ログはどれだけ保持されているか。いずれも設定に関する質問で、Microsoft 365 監査はそれぞれに日付入りの回答を用意できます。よくある質問への答え方はMicrosoft 365 の証跡でサイバー保険の質問票に回答する方法で一つずつ解説しています。

書類に「過去 12 か月以内にペネトレーションテストを実施したか」とある場合、通常はインターネットに公開しているシステムについての質問です。小規模な企業であれば、管理策の質問にしっかり答えられていれば「いいえ」でも受け入れられることが少なくありません。書類や保険ブローカーがペネトレーションテストを引受条件にしている場合は実施すべきですが、対象は相手が想定しているシステムに合わせ、設定面の指摘は先に直しておきましょう。そうすれば、テスト報告書の冒頭が避けられたはずの基本的な問題で埋まることを防げます。

保険会社に提出する証跡には二つのルールがあります。必ず日付を入れること、そして「保険会社が承認した」とは決して表現しないことです。判断するのは提出を受けた保険会社自身です。

外部監査人やフレームワークは何を求めているのか？

フレームワークによって異なります。最も確実なのは条文そのものを読むことです。

• ペネトレーションテストを名指しするフレームワーク： PCI DSS v4.0.1 の要件 11.4 は、少なくとも 12 か月に一度、および重要な変更の後に、内部と外部のペネトレーションテストを求めています。PCI の対象範囲にあるなら、監査で代替することはできません。
• 管理策の証跡を求めるフレームワーク： ISO 27001 のサーベイランス審査、SOC 2 報告書、多くの取引先向けサプライヤー質問票は、主に管理策が存在し運用されていることを確認したがります。アクセスレビュー、MFA、ログ、設定基準などです。日付入りのエクスポートを伴う設定監査のほうが、監査人がサンプリングする内容に近いことが一般的です。
• 英国の Cyber Essentials： 質問はクラウドサービスの MFA、管理者アカウント、安全な設定など、設定に関するものです。当社の監査レポートには Microsoft 365 部分の準備状況の一覧が含まれますが、判断するのは認証機関です。
• アジアの規制対象の金融機関： 監督当局の指針は、重要システムへの定期的なペネトレーションテストを期待していることが多くあります。香港とシンガポールの具体的な要件は脆弱性管理とペネトレーションテストのガイドで扱っています。

依頼があいまいな場合（「セキュリティテストの証跡を提出」など）は、どの管理策をサンプリングしているのか監査人に直接尋ねてください。たいていは一言でどちらが必要か決まります。

取締役会が本当に必要としているものは？

取締役会は手法には関心がありません。知りたいのは、どの程度さらされているのか、何をしているのか、それが効いていることをどう確認するのか、の三点です。二つのサービスはその異なる部分に答えます。

監査は「どの程度さらされていて、何から直すか」に答えます。重大度別の一覧、短い是正ロードマップ、項目ごとの工数見積もりは、ほぼそのまま取締役会資料になります。ペネトレーションテストは「実際の攻撃者に耐えられるか」に答えます。攻撃者がどこまで到達できるかの経緯は説得力がありますが、範囲は狭くなります。一人のテスト担当者が決められた日数で見つけた経路を記述したものだからです。

中小企業の取締役会であれば、まず監査を実施し、重大度の高い指摘を是正し、その後にペネトレーションテストで結果を検証する、という依頼が妥当です。この順序なら、取締役会にもわかりやすい「前後比較」が残ります。

どちらを先に実施すべきか？

ほとんどの Microsoft 365 環境では監査が先です。理由は三つあります。

1. 指摘一件あたりのコストが低い。 MFA の除外、古いプロトコル、開きすぎた共有といった設定の穴は、攻撃するより設定を読むほうが早く見つかります。
2. テストの価値が高まる。 強化済みのテナントが相手なら、テスト担当者はより難しい経路に時間を使えます。それこそが費用を払う目的です。
3. すぐに着手できる作業が得られる。 監査の指摘の多くは設定変更で済み、新しいライセンスを必要としません。

契約、フレームワーク、保険会社がペネトレーションテストを期限付きの条件にしている場合に限り、テストを先に行ってください。その場合でも、テスト開始前に簡易的な設定確認を済ませておく価値はあります。

英国・オーストラリアからのご依頼

Microsoft 365 監査は完全リモートで提供します。グローバル管理者が読み取り専用のアプリケーションを承認し、テナントへのアクセス取得後 5〜7 営業日で書面レポートをお届けし、報告会はお客様の営業時間帯で設定します。日常の IT サポートについては、英国の IT サポート（英語）とオーストラリアの IT サポート（英語）のページもご覧ください。

費用と期間の目安は？

監査は Microsoft 365 のユーザー数に応じた一回限りの固定料金で、規模にかかわらず確認範囲は同じです。現在の価格表と、期間限定のキャンペーン（実施中の場合）はMicrosoft 365 セキュリティ監査の料金ページに掲載しています。書面レポートはテナントへのアクセス取得後 5〜7 営業日でお届けします。

ペネトレーションテストは案件ごとに範囲を定めます。工数が対象によって変わるためです。外部アドレスの数、社内ネットワークや Web アプリケーションを含めるか、ソーシャルエンジニアリングを許可するか、などです。一般的な流れは、範囲確認の打ち合わせ、書面のテストルール文書、日単位のテスト期間、報告書、そして是正済み指摘の再テストです。

よくある質問

Microsoft 365 セキュリティ監査と脆弱性診断は同じものですか？

Microsoft 365 に関しては、ほぼ同じです。テナント内にスキャンできる自社インフラがないため、「Microsoft 365 の脆弱性診断」は実質的にベンチマークに照らした設定レビューになります。自社のサーバー、ファイアウォール、ノート PC に対する脆弱性スキャンは別のサービスです。

Microsoft の許可なしに Microsoft 365 のペネトレーションテストを行えますか？

個別に承認を得るのではなく、Microsoft が公開するルールに従って実施します。ルールはテストを自社のテナントと許可されたアカウントに限定し、DoS テストや他の顧客を対象とした行為を禁止しています。信頼できるテスト事業者であれば、こうした制約を書面の範囲定義に明記します。

ペネトレーションテストは監査と同じ問題を見つけますか？

一部は同じです。MFA のないアカウントを見つければテスト担当者はそれを使うため、その穴は両方に現れます。ただしテストは限られた時間内に成功した経路で止まりますが、監査は基準を満たさないすべての管理策を列挙します。組み合わさったときに初めて危険になる問題も含まれます。

保険会社からペネトレーションテストを求められました。監査で代用できますか？

保険会社またはブローカーが同意した場合に限ります。いずれにしても管理策の質問には監査の証跡を使い、ペネトレーションテストが引受条件なのか評価項目なのかを書面で確認してください。条件であれば、相手が想定しているシステムを対象にテストの範囲を決めます。

それぞれどのくらいの頻度で実施すべきですか？

監査は年に一度、さらに合併、新しいテナント、ライセンス変更など大きな変化の後に実施する価値があります。ペネトレーションテストは、フレームワークが求める場合は通常年一回、対象システムに重要な変更があった後にも実施します。

監査で問題は修正されますか？

いいえ。監査は読み取り専用で、成果物は指摘事項と是正計画です。是正は別の作業で、自社のチーム、現在の委託先、または当社が作業ごとのお見積もりで対応します。

次のステップ

「セキュリティテスト」と書かれた質問票、監査人からの依頼、取締役会の決議がお手元にあれば、お送りください。どちらが求められているかをお伝えします。コンサルタントに相談するか、まずMicrosoft 365 セキュリティ監査から始め、指摘が解消した段階でペネトレーションテストを追加してください。