Outlook Web App のセキュリティ：MFA による Exchange の保護

はじめに

リモートアクセスに関するセキュリティの議論のほとんどは、VPNから始まります。Outlook Web App（OWA）から始まる議論はほぼ皆無ですが、OWAが実際には何であるかを考えれば、これは奇妙なギャップです。OWAとは、オープンなインターネット上に存在し、あらゆるデバイス上のあらゆるブラウザから、どこからでもアクセス可能な、企業用メールのログインフォームなのです。 設定すべきVPNクライアントも、回避すべきファイアウォールルールも、経由すべきネットワークセグメントもありません。あるのは、ユーザー名入力欄、パスワード入力欄、そしてExchangeサーバーが受け入れると判断した情報だけです。

攻撃者にとって、これはメールボックスへの最短ルートに他なりません。 OWAのログイン情報が侵害された場合、危険になるために横方向の移動は必要ありません。メールボックス自体が標的であるため、それはすでに、即座に危険な状態にあるのです。ビジネスメール詐欺（BEC）にはマルウェアもエクスプロイトも必要なく、ネットワーク侵入を検知するために構築された検出ツールのほとんどを回避してしまいます。必要なのは、1組の有効な認証情報と、それ以外を何も求めないログインページだけです。

オンプレミスおよびハイブリッド Exchange に MFA が標準で提供されない理由

この点での混乱は理解できます。なぜなら、Exchange Online を使用する Microsoft 365 テナントは、事実上自動的に強力な認証を受けられるからです。Entra ID の条件付きアクセスポリシーでは、セッショントークンが発行される前に ID レイヤーでの MFA を要求することができ、その保護は Exchange 固有の設定を一切行わなくても Outlook on the web にも適用されます。純粋なクラウド環境でのみ作業してきたセキュリティチームは、Web メールでの MFA が Exchange の標準的な動作であると当然のように考えてしまいます。

オンプレミスおよびハイブリッド環境のExchangeでは、この動作は継承されません。Exchange Server独自の認証スタック（OWAやExchange管理センターを処理するクライアントアクセスサービスロール）は、Active Directoryに対してユーザー名とパスワードの検証を行い、追加の設定がない限り、それだけで認証の判断が完了します。 オンプレミスの OWA ログインには、ネイティブな第二要素認証は組み込まれていません。ハイブリッド展開では、この状況はさらに複雑になります。一部のメールボックスはすでに Exchange Online に移行され、条件付きアクセスによって保護されている一方で、他のメールボックスはオンプレミスに残っており、ハイブリッド モダン認証やその他の MFA ソリューションが明示的に構成されていない限り、依然として Exchange Server 独自の認証パスに依存している可能性があります。 テナント全体としては「MFAによって保護されている」と組織が信じていても、実際にはメールボックスの相当数が、パスワードのみに依存するオンプレミスの OWA の背後に残っているという状況は十分にあり得ます。

これが運用上重要なギャップとなります。その理由は、オンプレミスのExchangeが設計上本質的にセキュリティが低いからではなく、2つ目の認証要素を追加する責任がExchange管理者に全面的に課せられ、デフォルトで頼れる仕組みがないためです。

OWA や EAC アカウントが侵害された場合、攻撃者に実際に何がもたらされるのか

単一の OWA 認証情報の価値は、「単なるメール」と捉えてしまうと過小評価されがちです。実際には、侵害されたメールボックスアカウントは、そこからいくつかの異なる攻撃経路が分岐する足掛かりとなります。

ビジネスメール詐欺（BEC）は、金銭的な被害が最も直接的に現れるものです。

ビジネスメール詐欺（BEC）は、金銭的な被害が最も直接的に現れる攻撃です。FBIのインターネット犯罪苦情センター（IC3）の記録によると、2025年に米国で報告されたBECによる被害額は30億4600万ドルに達し、投資詐欺に次いで2番目に高い被害額カテゴリーとなりました。これは約24,768件の苦情に分散しており、確認されたインシデント1件あたりの平均被害額は12万ドルを超えています。 BEC攻撃の特徴は、セキュリティフィルターが検知できるようなマルウェアや悪意のあるリンクが一切使用されない点にある。攻撃者は正規のメールボックス内に潜入し、正規のアドレスから送信を行う。多くの場合、既存のスレッド内で返信を行い、銀行のルーティング番号を改ざんしたり、請求書を転送したりする。 メールフローのルールにより、事後的にこの手口を検知することはさらに困難になります。メールボックスへのアクセス権を持つ攻撃者は、「請求書」、「送金」、「支払い」といった単語を含むメッセージを黙って転送または削除する受信トレイルールを作成でき、アカウント所有者には侵害が気づかれないまま、並行して詐欺的なやり取りが続けられるのです。

代理アクセス権限は、このリスクをさらに増大させます。

代理アクセス権限は、このリスクをさらに増大させます。経営幹部のアシスタントや財務チームのメンバーは、通常の業務フローの一環として、経営幹部のメールボックスに対する代理権限や「送信者として」の権限を頻繁に保有しています。つまり、アシスタントのアカウントが1つ侵害されるだけで、その経営幹部の認証情報を一切使用することなく、CFOやCEOから直接送信されたかのように見える通信を送信することが可能になります。

データの漏洩は、目立たないリスクである

データの漏洩は目立たないリスクですが、規制対象組織にとっては、しばしばより重大な影響を及ぼすものです。メールボックスには、長年にわたる添付ファイル、社内メモ、人事関連の通信、顧客とのやり取りが蓄積されています。攻撃者が認証されれば、これらすべてにOWAのインターフェースを通じてアクセス可能です。攻撃者は正当なOWA機能を使用してメールボックスのコンテンツにアクセスし、ダウンロードできるため、別途のデータ流出ツールは必要ありません。

アプローチ 1：OWA および EAC ログインへの MFA の直接適用

最も的を絞った対策は、Active Directoryに接続されている他の要素には一切手を加えることなく、リスクにさらされている特定の攻撃対象領域に対処するものです。Outlook Web AppおよびExchange管理センター向けのMFAは、Exchangeクライアントアクセスサービスロールのコンポーネントとしてインストールされ、Exchangeの認証メカニズムを完全に置き換えるのではなく、既存のOWAおよびEACのログインページの前面に配置されます。 インストール後、ユーザーはまず通常の AD ユーザー名とパスワードで認証を行い、その後、セッションが許可される前に、認証アプリやハードウェアトークンからの OTP の入力、あるいはプッシュ通知の承認など、2 段階目の認証手順を完了します。

適用範囲はインストール時に Active Directory グループのメンバーシップを通じて設定されます。管理者は、全ユーザーに対して直ちに MFA を必須とすることができるほか、より広範な展開を計画している間は、当初は単一の AD グループ（パイロットグループ、あるいは具体的には Exchange 管理センターへのアクセス権を持つグループ）に対してのみ有効にすることも可能です。 この区別は実務上重要です。なぜなら、EACアカウントは個々のメールボックスよりもはるかに大きな組織的リスクを伴うからです。EACへのアクセス権を持つ管理者アカウントは、Exchange環境全体にわたってメールフロー規則の作成、権限の変更、データのエクスポートを行うことができるため、たとえ全ユーザーへの展開に時間がかかっても、EACへのログイン保護が優先される傾向にあるのはまさにこの理由からです。

セッションの挙動は固定ではなく、設定可能です。管理者は、ユーザーに新しいOTPの入力を再要求する頻度（たとえば、OWAを連続して使用してから12時間ごとに1回など）を設定し、繰り返される認証による煩わしさと、共有デバイスや管理対象外のデバイス上で長時間放置されたセッションがもたらすリスクとのバランスを取ることができます。 このコンポーネントは、HOTP、TOTP、およびチャレンジ・レスポンス方式のOCRAをサポートしており、さまざまな種類のOTPトークンを使用する組織に柔軟性を提供します。

アプローチ 2: Active Directory レベルでの MFA — OWA を含むすべてのサービスを対象とする

OWA専用のコンポーネントを導入する前に検討すべき、より限定的な問いがあります。それは、「OWAは、実際にパスワードのみで認証を行っているAD接続サービスの中で唯一のものなのか？」というものです。ほとんどのオンプレミス環境において、正直な答えは「いいえ」です。Winlogon、RDP、そして多くの場合、内部のLDAPに紐づくアプリケーションも同様の状況にあり、ADが強制するパスワードポリシー以外の何ものにも保護されていません。

ディレクトリレベルでの多要素認証は、個々のサービスのログインページではなく、Active Directory自体に統合することで、こうした広範な脆弱性に対処します。 OWA用のコンポーネント、RDP用の別のエージェント、VPN用のRADIUSプロキシなど、それぞれ個別にインストール、設定、保守される一連の独立したMFA導入に代わって、ディレクトリレベルの統合では、静的なパスワードを時間ベースの動的パスワードに置き換えることで、Active Directoryにおけるユーザー認証情報の動作を変更します。これにより、ADに接続されたサービスは、サービスごとに個別のMFAコンポーネントを必要とすることなく、同じ動的認証情報を使用できるようになります。 OWAが対象となるのは、それが特に標的とされたからではなく、ADを参照する他のすべてのサービスと同様に、現在では同じ動的認証情報のチェックを満たさなければならないためです。

このトレードオフはアプローチ1とは逆の方向に向かっています。つまり、より広範な対象範囲を得る代わりに、環境全体におけるAD認証の動作に広範囲にわたる変更が生じます。通常、これは単一のサービスであるOWAコンポーネントの場合よりも、より慎重なテストと段階的な展開を必要とします。 この2つのうちどちらが適切な選択かは、実際には対象範囲によって異なります。ADに接続されている保護されていない表面がOWAのみである組織の場合、それを修正するためにディレクトリに手を加える必要はありません。一方、OWA、RDP、Winlogonのすべてがパスワードのみの認証に依存していることが判明した組織の場合、単一のサービスに対する修正では解決できない、より広範な問題を抱えていることになります。

エンドポイントエージェントなしでディレクトリレベルのメカニズムが機能する仕組み

ディレクトリレベルのMFAを支える仕組みは、それ自体を理解する価値があります。なぜなら、個々のワークステーションやサーバーに何もインストールすることなく、すべてのAD接続サービスに適用できる理由を説明してくれるからです。

動的強力パスワード認証は、各エンドポイントで認証トラフィックを傍受するのではなく、Active Directory自体に保存されているパスワードを変更することで機能します。ユーザーの静的パスワードは、管理者が設定した間隔（30秒の倍数でなければならない）で自動的に変更される、TOTPベースのローテーション型動的パスワードに置き換えられます。 現在の動的パスワードはTOTPアルゴリズムを使用して生成され、ユーザーはProtectimus SMARTアプリまたは対応するチャットボットを通じてこれを確認できます。変更はディレクトリ内で直接行われるため、ADに対して認証を行うあらゆるクライアントやサービス（Winlogon、RDP、OWA、LDAPに依存するアプリケーションなど）は、変更があったことを認識する必要なく、自動的に現在の動的パスワードを使用します。

これが、重要な意味においてこのアプローチを「エージェントレス」にしている理由です。つまり、ノートPC、RDPホスト、またはExchangeクライアントアクセスサーバー上で、第二要素を確認するソフトウェアが実行されていないのです。ディレクトリ自体が適用ポイントとなります。これに伴うトレードオフとして、ドメインコントローラーとの直接的な統合が必要なため、このコンポーネントはクラウド専用サービスではなく、オンプレミス展開の一部として実行されます。

適用範囲の選択：Webメールのみか、AD環境全体か

どちらのアプローチも、根本的な問題（パスワードだけではもはや認証に不十分であるという点）を解決しますが、スタック内の異なるポイントで解決します。したがって、適切な選択は、デフォルトの好みではなく、実情に基づいた正確な現状把握に基づいて行う必要があります。

もし、OWAとEACが、パスワードのみでADに対して認証を行っている唯一のサービスであり（VPNはすでにRADIUSでカバーされ、RDPはすでにロックダウンされており、ADの認証情報を黙って信頼している他のレガシーアプリケーションが存在しない場合）、対象となるOWAコンポーネントは、ディレクトリ上で動作している他のシステムへの影響を最小限に抑えつつ、その特定の脆弱性を解消します。 もし実態調査の結果、複数のサービスが露出していることが判明した場合（ITチームが実際に調査を始めると、これがより一般的な結果となります）、ディレクトリレベルのMFAは、サービスごとに個別のMFA製品を導入するのではなく、単一の統合ポイントからそれらすべてを保護します。

いずれにせよ、FBIのBECによる被害額データは、同じ根本的な事実を指摘しています。すなわち、オープンなインターネット上に公開されている企業のメールボックスへのパスワードのみによるログインは、オンプレミス、ハイブリッド、その他の形態を問わず、Exchangeを運用するいかなる組織にとっても、もはや防御可能な状態ではないということです。