このHelp Net Securityのインタビューでは、ExchangeのMicrosoft MVPであるScott Schnoll氏が、Microsoftがクラウドを保護し、組織が自身のデータ、アイデンティティ、設定を保護しなければならない共有責任モデル（Shared Responsibility Model）を説明しています。
このディスカッションでは、プリンタ、スキャナ、ERP依存関係のため存続しているSMTP AUTHなどのレガシープロトコルを含む、明日にでも変更する価値のあるデフォルト設定をカバーしています。Schnoll氏は、条件付きアクセス、PIM、継続的なモニタリングなどの見落とされたコントロール、およびPOP、IMAP、クライアント側のメールボックスルール周辺の監査ログのブラインドスポットを強調しています。また、サードパーティメールゲートウェイが価値を追加する場合と、中規模チームに重複支出を生じさせる場合のバランスについても検討しています。
初めて組織に入ったときに、Exchange Onlineが「Microsoftの問題なので安全」だと言われた場合、その会話は通常、次の10分間でどこに向かいますか？
これは素晴らしい最初の質問です。なぜなら、私は今、顧客とその会話をしているからです。まず、Microsoftのクラウドにおける共有責任モデル（Shared Responsibility Model）と呼ばれるものを説明することから始めます。攻撃者がExchange Online自体を攻撃するのではなく、むしろExchange Onlineテナントを攻撃することを顧客に理解させることは常に重要です。彼らはあなたのアイデンティティ、あなたの設定、そして（多くの顧客の場合）あなたのモニタリング不足とユーザー教育の欠如を攻撃します。
その名前が示すように、共有責任モデルでは、Microsoftと組織は展開のさまざまな側面についてそれぞれ責任を持っています。Microsoftは多くのセキュリティおよびコンプライアンスコントロールを備えていますが、テナント管理者がテナントを適切に保護するために利用できるコントロールと同じ数が存在します。
もちろん、クラウドでは、Microsoftはデータセンター、ネットワーク、サーバ、コンピュートリソース、アイデンティティおよびインフラストラクチャ、およびいくつかのアプリケーションを提供しています。Microsoftはまた、物理的および論理的なアクセスコントロール、ネットワーキングコントロール、モニタリングなど、環境のための多くのコントロールを提供しています。
しかし、すべてのMicrosoftクラウド展開では、組織はそのデータとアイデンティティを所有しています。したがって、組織は、利用可能な設定を通じて制御するクラウドコンポーネントとともに、そのデータとアイデンティティのセキュリティを保護する責任があります。MicrosoftはExchange Online用の様々なセキュリティコントロールを提供していますが、アクセスを管理し、データ、アカウント、エンドポイントを保護する責任は組織に残ります。
Microsoftはクラウドを保護し、顧客がExchange Onlineテナントを保護するのを支援するために、Microsoftは変更管理、アンチマルウェア、アンチスパムおよび他の悪意のあるソフトウェアからの保護、ベースライン脅威保護、パッチ管理、およびデータレプリケーションと冗長性などのための多くのコントロールを提供しています。
Microsoftはまた、アイデンティティとアクセスの管理、証明書、電子メール認証、eDiscoveryと検索、および多くのセキュリティおよびコンプライアンスツール用のコントロールとツールを管理者に提供しています。そして、提供されたこれらのコントロールは自動的に設定されません。代わりに、組織はビジネスニーズとリスク許容度に基づいてそれらを設定します。実際、顧客とこれを進めているので、ビジネスニーズに基づいて顧客が実装できる300以上の技術的、運用的、およびドキュメンテーション制御があることを知ることができます。これらのコントロールはクラウド設定、ディレクトリアクセス、セキュリティ、コンプライアンス、エンドポイント管理、リスク評価などにまたがっています。
つまり、あなたは家族とすべての物を新しい賃貸住宅に移しました。大家はドア、窓、屋根などを提供します。大家は家を保護することに関心がありますが、家の人々と物資を保護する責任はあなたにあります。あなたのニーズに合わせて環境を強化することはあなたの責任です。より良いロック、カメラ、警報システムなどが欲しいと決断するかもしれません。これらはすべてセキュリティを改善するために実行できることであり、これらは大家によって提供されていないため、あなたの責任になります。
クラウドでも同じ原則です。それはあなたのデータあなたのユーザーです。それらを保護することはあなたの責任です。
Exchange Onlineのどのデフォルト設定がMicrosoftが明日変更することを望みますか、そしてなぜそれはこんなに長く存続しているのですか？
ああ、もしそれが簡単だったら。レガシープロトコルと認証のサポートを含む、変更されたり削除されたりするのを見たい物が数個あります。たとえば、認証済みSMTP送信、別名SMTP AUTHのようなもの。これはPOP3およびIMAP4クライアント、および最新の認証方法を使用しないアプリケーション、サーバ、デバイスがメッセージを送信するために使用します。
SMTP認証を定義するRFCは10年以上前に作成されました。今日では、Exchange Onlineに接続するすべての最新メールクライアント（Outlook、Outlook Mobile、OWAなど）はSMTP AUTHを使用しません。このため、Microsoftは強くSMTP AUTHを無効にする（テナント全体で、または必要に応じて例外を含む）ことを推奨しています。
残念ながら、SMTP AUTHを引き止めているのは、顧客が使用するデバイスとアプリケーションによるそれのサポート不足です。これはプリンタとスキャナ、HVAC システム、ERP システム、レガシー アプリケーションなどを含みます。顧客が最新の認証（OAuth など）をサポートしないクライアントを使用し続ける限り、Microsoftがそれを完全に無効にすることは困難です。
メッセージング サービスの中断は進められないものであることに私たちは皆同意しています（政治的に危険であることは言うまでもありません）。実際のところ、一部の顧客にとって、メール フローを中断することは、いくつかのレガシープロトコルを有効なままにしておくことより悪いことです。セキュリティのベストプラクティスはMicrosoftのメールフロー（またはその他のもの）を中断する意思より速く移動し、動いているという事実です。したがって、Exchange Onlineからセキュアでないレガシープロトコルを削除するには数年かかる可能性があります。そして、このケース（および他の重要なクラウド廃止予定）で見たように、Microsoftが期限を設定した場合でも、その期限は、レガシー認証がまだ使用中であることを示す測定結果に基づいて拡張されることが多く、もちろん、より多くの時間を求める顧客からのエスカレーションに基づいています。
ほとんどの中規模組織がまだ間違っているとお考えの交渉の余地のないコントロールについて説明してください。Microsoftのドキュメンテーションとチームが運用化する内容とのギャップはどこにありますか？
これは興味深い質問ですが、中規模組織だけに適用されるかどうかは確実ではありません。あらゆるサイズの組織が見落とすもの、または物事が単に見落とされるものがあります。Microsoftのドキュメンテーションは完璧ではありませんが、かなり包括的であり、十分に文書化されていないセキュリティまたは他のコントロールを思い出すことはできません（そのような場合でも、追加の改善が役に立つ可能性があります）。
顧客が管理するために文字通り数百のコントロールがあるため、コントロールを見落とすか、誤って設定することは簡単であり、コントロールを実装することは実際よりも多くの保護を提供していると仮定することは簡単です。たとえば、MFAを有効にした顧客がいますが、それだけで認証ギャップが解決されると考えています。これらの同じ顧客はPOP、IMAP、およびレガシー認証を有効にしたままにしており、基本的にMFAによって提供される保護を無用にしています。また、本当に堅実なポリシーを作成した顧客もいますが、その後、しばしば永続的になる「一時的な例外」を許可することでギャップを開きます。
私にとって、条件付きアクセス、PIM、JIT昇格、およびマルチ管理者承認などのアイデンティティおよびアクセスコントロールは交渉の余地がありません。監査、暗号化、外部転送、およびデータ保護を提供するコントロールも同じです。Microsoft 365のセキュリティデフォルトは良いですが、出発点としてのみです。テナントを適切に保護するために実装および監視する必要があるコントロールははるかに多くあります。そして、コントロールが適切に構成および実装されたら、継続的なモニタリングが行われる必要があります。継続的なモニタリングの欠如は、多くの場合、組織の最大の運用上の失敗であり、残念ながら多くの組織が欠いているものです。組織はすべての利用可能なコントロールを実装できますが、アイデンティティ、権限、制御の有効性、およびシステムアクティビティの定期的なレビューがなければ、コントロール自体は十分ではありません。
アカウントが侵害された場合、インシデント対応者がExchangeログで一貫して見落とす成果物は何ですか？統一監査ログのどのブラインドスポットについて警告しますか？
最初から言うと、誰でも悪用できる監査ギャップを露出させたくないため、これに答えるのに少し躊躇します。現実は、メールボックス監査ログはメールボックスアイテムがアクセスされたことを示す可能性がありますが、正確にどのメッセージが読まれたか、またはデータが流出したかどうかを常に確実に証明することはできません。
確かに監査ログの情報を使用するニュアンスがあります。インシデント対応者は、クライアント側のメールボックスアクセスアーティファクト、委譲されたアクセスアクティビティ、および攻撃者が悪用するがログに完全に表示されない非Exchange ワークロードを見落とすことが多いです。あなたの言葉を使うと、監査ログはIMAP/POPアクセス、トークンリプレイ、レガシープロトコルの悪用、およびメールボックスルール作成可視性のギャップに関する「ブラインドスポット」も持ち、これらはすべて監査が有効な場合でも攻撃者が完全に気づかれないようにすることができます。
攻撃者が使用する戦術の1つは、メールを静かに外部アドレスに転送したり、特定のメッセージを自動削除したりするクライアント側のメールボックスルールを作成することです。これらのルールの作成と使用は、監査ログに完全にキャプチャされないかもしれません。同様に、POPやIMAP などのレガシープロトコルを使用してメールボックスにアクセスすると、最小限のまたは全く監査イベントが生成されません。サインインログでキャプチャされた認証アクティビティが表示されますが、その後のメールボックスアクセス、メッセージとフォルダバインディング、およびその他のアクティビティは、ログに単に表示されません（この場合、セッションは対話的なメールボックスアクションではなくプロトコル同期として扱われるため）。POP自体は特にアイテムレベルのセキュリティをバイパスし、メールボックス内のメッセージのダウンロードと削除の両方をトリガーできることを考えると、特に問題です。
数年前、Microsoftはアクセスされたメッセージとフォルダを詳細に示し、同期が発生したかどうかを示すMailItemsAccessedの監査を追加しました。しかし、レガシークライアント（POP、IMAP、および古いバージョンのOutlook）からこのデータをキャプチャしていません。したがって、レガシークライアントが攻撃の一部として使用される場合、法医学的観点からはメールボックスがアクセスされたことをおそらく判断できますが、攻撃者が正確に何を読んだかを常に判断できるとは限りません。
これらのギャップを説明するために、対応者は通常、Entra IDサインインログ、メッセージトレース、Defender for Cloud Apps、条件付きアクセスログ、メールボックス監査データ、および管理デバイスからのエンドポイントテレメトリなど、複数のデータソースを確認する必要があります。Exchange Online監査は完全なストーリーを伝えない可能性があるため。
Exchange Onlineの前またはそばにあるサードパーティメールセキュリティゲートウェイの価値についてのあなたの見方は何ですか？数学はどこで機能しますか、そしてそれは重複支出はどこですか？
これはコストと重複支出に関する具体的な答えを提供することが難しい質問の1つです。短い答えは、サードパーティメールセキュリティゲートウェイは、組織がレガシールーティング、専門的なコンプライアンスツール、または高度な脅威層の多様性を必要とする場合など、非常に具体的なニーズについて価値を追加できるということです。しかし、多くのExchange Online顧客にとって、それらを使用すると重複支出が発生し、検出精度を低下させる可能性があり、運用の複雑性を導入することは言うまでもありません。
ほとんどの顧客にとって、数学はMicrosoftのネイティブスタックが満たすことができない要件を持つ場合にのみ機能します。たとえば、顧客が専門的なルーティングや暗号化、または集中メールトランスポート（またはレガシーハイブリッドメールフロー）を使用する必要がある場合、サードパーティゲートウェイを使用することが最良の解決策である可能性があります。しかし、組織がスパムまたはメッセージ衛生機能のみが必要な場合、またはビジネスメールの侵害、内部の脅威、およびOAuth悪用などのことを検出したい場合、Exchange Onlineのネイティブ機能を使用することが、サードパーティゲートウェイに依存するより優れています。
翻訳元: https://www.helpnetsecurity.com/2026/04/29/scott-schnoll-microsoft-exchange-online-security/
