通信

マイクロソフトの Exchange エッジ トランスポート サーバー

Kay Unkroth

概要:

• Exchange エッジ トランスポート サーバーの役割
• テスト ラボをセットアップする
• トランスポート エージェントとトランスポート イベント
• エージェントの内部構成

この記事で使用しているコードのダウンロード: ExchangeEdge2007_10.exe (354KB)

マイクロソフトでは、通常の 1 営業日に約 1,300 万件のメッセージをインターネット経由で受信し、そのうちの 1,050 万件を正当でないメッセージとしてブロックしています。インターネット上でスパム攻撃やウイルスが発生している場合などの危機的な状況では、

これが 9,000 万件を超えることもあります。もちろん、これはマイクロソフト固有の現象ですが、詐欺、スパム、フィッシング、電子メールによって媒介されるウイルス、ディレクトリ ハーベスト攻撃、分散型サービス拒否 (DDoS) 攻撃などの問題は、マイクロソフト固有のものではありません。このような問題がある中で、大量に送信されてくる、正当でない、悪意のあるコンテンツをメッセージング環境から排除しながら、従業員に正当なメッセージを確実に配信するにはどうすればよいでしょうか。

信頼できるメッセージングの保護を実現する方法の 1 つは、Exchange Server 2007 エッジ トランスポート サーバーと Forefront Security for Exchange Server をインターネットと組織の運用環境の間にある境界ネットワークに展開することです。これにより、10 を超えるエッジ トランスポート エージェントから構成されるチームを境界に配置して、運用システムとユーザーを保護できます。望ましくないコンテンツをできるだけ早い時点でブロックすることの重要性は明らかです。ただし、メッセージング環境が危機的な状況に置かれる可能性があることを考えると、コンテンツがサーバーに配信される前にブロックするのが理想的です。ただ、単にメッセージをブロックする以外にも、メッセージングを保護する手段は多数あります。

これは、Exchange Server 2007 と Forefront Security for Exchange Server で提供されるスパム対策およびウイルス対策エージェントのアーキテクチャと主要機能を説明する 2 部シリーズの第 1 部です。説明を現実的かつ実践的なものにするために、この第 1 部の記事では、マイクロソフトが自社の運用環境で採用しているメッセージング保護の設計を再現したテスト ラボを構築する方法について説明します。その後、Exchange Server 2007 のエッジ トランスポートのアーキテクチャについて詳しく説明します。

この記事では、スクリプトとバッチ ファイルを頻繁に使用して、重要な構成作業のほとんどを自動化します。これらのファイルには、実行される各手順を説明したコメントも含まれています。これらのスクリプトは、TechNet Magazine Web サイト (technetmagazine.com/code07.aspx) からダウンロードできます。**

エッジ トランスポートのトポロジ

図 1 は、Microsoft IT がマイクロソフトの運用環境に実装しているエッジ トランスポートの設計を示しています。エッジ トランスポートのアーキテクチャについて説明する前に、非常に興味深い設計上の特徴をいくつか示します。実装の詳細に興味がある場合は、補足記事「Exchange に関する詳細情報」に記載されている IT ショウケースのホワイト ペーパーを参照してください。

図 1** マイクロソフトのエッジ トランスポートのトポロジ **(画像を拡大するには、ここをクリックします)

図 1 を分析すると、マイクロソフトのエッジ トランスポートのトポロジは十分に冗長であることがわかります。どこにも単一障害点はありません。また、負荷分散を実現するために、外部では DNS ラウンド ロビンを使用し、内部では複数のブリッジヘッドがあるメッセージング コネクタを使用しています。また、すべてのトランスポート サーバー (ハブ トランスポートとエッジ トランスポート) で、ウイルスをスキャンするための Forefront Security for Exchange Server が実行されていることにも注意してください。これにより、メッセージ ルーティング トポロジ内のトランスポート サーバーにメッセージが届いた時点で、すべての受信メッセージ、送信メッセージ、および内部メッセージをスキャンできます。

セキュリティに関連するもう 1 つの重要な設計上の特徴は、エッジ トランスポート サーバーが社内の Active Directory® 環境の一部ではないことです。実際、エッジ トランスポート サーバーを Active Directory フォレストに展開する必要はありません。ただし、Microsoft IT では、管理フレームワークの一貫性を維持したり、共通のポリシー セットを適用したり、シングル サインオンをサポートしたりするために、すべてのエッジ トランスポート サーバーをエクストラネット フォレストに展開し、運用環境から分離しています。

また、インターネット経由で送信されてきたすべてのメッセージは、北米にあるエッジ トランスポート サーバーを介してマイクロソフトに配信されていることもわかります。ダブリンとシンガポールにあるエッジ トランスポート サーバーは、送信メッセージのみを処理します。すべての受信トラフィックを北米のエッジ トランスポートで処理するメリットは、セキュリティとスパム対策を一元的に管理しながら、内部メッセージング バックボーン上の大規模な地域データセンターから送信メッセージが転送されないようにできることです。

マイクロソフトのエッジ トランスポート トポロジを設計したのは、Microsoft IT のシステム エンジニアである Omesh Desai です。Omesh に最も重要な設計上の特徴を尋ねたところ、次のような回答を得ました。「マイクロソフトのエッジ トランスポートの設計では、Exchange 自体のスパム対策およびウイルス対策機能を利用して、メッセージング バックボーン内の複数の層でメッセージングを保護しています。メッセージング境界のセキュリティを確保することが最優先ですが、単純な管理モデルも私たちにとっては重要です。エッジ トランスポート サーバーは、より強力なファイアウォール構成によってセキュリティを強化すると同時に、IP 評価サービス、コンテンツ フィルタの自動更新、セーフリスト集約、および電子メールの消印の検証によってスパム フィルタの精度を高めるのに役立っています。すべての内部のサーバー間通信は、既定で暗号化されています。また、可能であれば、外部の送信先との通信も暗号化しています。

エッジ トランスポート サーバーには、2 つのデュアルコア 64 ビット プロセッサと 8 GB のメモリを使用しています。これら 6 台のサーバーは、2 つのデータセンター間で負荷分散されており、インターネット上でウイルスが発生した場合など、メッセージの送信量が急増しても対応できるだけの十分な処理能力を確保しています。」

エッジ トランスポートのテスト ラボ

テスト ラボをセットアップする

架空のドメイン名とプライベート IP アドレスを使用することがベスト プラクティスであるため、ここでは AdventureWorks.com と 192.168.xxx.0 ～ 24 の IP アドレスを使用します。負荷分散やフォールト トレランスはテストしないため、冗長システムやファイアウォール アレイは用意していません (もちろん、セキュリティ上の理由から、Microsoft IT が実際に使用しているファイアウォール システムについて説明することはできません)。いずれにしても、このような詳細情報は、このテストにとって重要ではありません。

テスト環境では、Exchange Server 2007 と共に使用される最も一般的なファイアウォール システムの 1 つである ISA Server 2006 を使用します。外部ファイアウォールと内部ファイアウォールの両方で ISA Server 2006 を実行することにより、テスト環境の複雑さを抑えています。ただし、運用環境では、セキュリティを確保するために、外部と内部で別々のファイアウォール システムを使用することをお勧めします。また、この記事の範囲には含まれないため、IP セキュリティ (IPsec) ポリシーの展開や、トランスポート層セキュリティ (TLS) 用の環境の準備は行いませんでした。

ただし、バーチャル マシンと 32 ビットの評価版ソフトウェアは使用しました。この評価版は、マイクロソフト Web サイトからダウンロードできます。マイクロソフトは、32 ビット版の Exchange Server 2007 の運用をサポートしていませんが、テスト環境でこれが問題になることはありません。

このテスト ラボでは、できる限り既定の設定を使用しています。Exchange Server 2007 のセットアップを実行し、エッジ トランスポート サーバーで運用環境をサブスクライブする前に特に注意する必要があるのは、IP 構成、ファイアウォール、および DNS ゾーンのみです。IP 構成の詳細については、この記事のダウンロード ファイルに含まれている Test Lab - IP Configuration.xls ファイルを参照してください。同じ IP アドレスの割り当てを使用する場合は、ISA01_Firewall_Policies.vbs スクリプトを ISA01 コンピュータ上で直接実行して外部ファイアウォール ISA01 を構成し、ISA02_Firewall_Policies.vbs を使用して内部ファイアウォール ISA02 を構成できます。この記事のダウンロード ファイルには、DNS サーバーを構成するためのバッチ ファイル (INTERNET01_DNS_Config.bat、AD01_DNS_Config.bat、および AD02_DNS_Config.bat) も含まれています。これらのバッチ ファイルは DNS コマンド ライン ツール (dnscmd.exe) を使用するため、Windows サポート ツールをインストールしておく必要があります。このツールをインストールしなかった場合、DNS コンソールを使用して DNS レコードを手動で作成する必要があります。

既存の環境の影響を受けないようにするために、テスト ラボはインターネットに接続されていません。このような環境の分離は、優れた予防策です。インターネットに接続されていないため、署名の更新、IP 評価、およびコンテンツ フィルタの更新のダウンロードはすべて失敗しますが、テストではこのことは重要ではありません。エラー メッセージが表示されないようにするには、Forefront Server Security Administrator コンソールの [スキャナの更新] を参照し、すべてのスキャン エンジンの更新頻度を 1 回に設定して、過去の日付を指定します。

これらの機能の実際の動作を確認するには、テスト環境を構築することをお勧めします。当然ながら、運用システムをテスト目的で使用することは絶対に避けてください。この環境では、少なくとも、メールボックス、クライアント アクセス、およびハブ トランスポート サーバーの役割を持つ Exchange Server 2007 サーバーが 1 台必要です。エッジ トランスポート サーバーの役割を割り当てる場合は、2 台目の Exchange サーバーが必要になります。複数の役割を持つサーバーにすべてのトランスポート エージェントを展開する場合は、Install-AntispamAgents.ps1 スクリプト (ハブ トランスポート サーバーの %ProgramFiles%\Microsoft\Exchange Server\Scripts フォルダにあります) を実行することで、エッジ トランスポート サーバーのインストールを省略できます。しかし、この方法では Microsoft IT の展開を再現することは非常に困難です。より実際に近い環境をテスト ラボに実装するには、さらに数台のサーバーを含める必要があります。図 2 は、この記事用の調査に使用したテスト環境を示しています。より詳細な図は、この記事のダウンロードに含まれています。ラボのセットアップの詳細については、補足記事「テスト環境をセットアップする」を参照してください。

図 2** エッジ トランスポートのテスト環境 **(画像を拡大するには、ここをクリックします)

Microsoft IT は、エッジ トランスポート サーバーのサブスクリプションを設定し、関連するコネクタを構成する作業で、すべての既定のコネクタを削除してから 4 つの送信コネクタを作成することにより、さまざまな種類の簡易メール転送プロトコル (SMTP) ホストや内部のハブ トランスポート サーバーとの効率的な通信を実現しました。１ つ目の送信コネクタは、特定のアドレス空間の定義に一致しないすべての送信先を対象とする汎用のインターネット コネクタです。

2 つ目の送信コネクタは、拡張 SMTP (HELO ドメイン) をサポートしていない既知の送信先用の詳細なアドレス空間が定義されているインターネット コネクタです。Microsoft IT はこのコネクタの ForceHELO パラメータを $true に設定して、SMTP 接続の確立時に発生する、EHLO、失敗応答 500、HELO という不要なシーケンスを回避しています。

3 つ目の送信コネクタは、TLS をサポートし、暗号化された接続を経由してセキュリティで保護された通信を行うパートナーや他のリモート ドメイン (TLS ドメイン) 用の詳細なアドレス空間が定義されているインターネット コネクタです。このコネクタでは、RequireTLS パラメータが $true に設定されています。

4 つ目の送信コネクタは、受信したインターネット メッセージを企業環境内のハブ トランスポート サーバーに転送する受信コネクタです。エッジ トランスポート サーバーの構成の詳細についても、この記事の最後の補足記事「Exchange に関する詳細情報」に記載されている IT ショウケースのホワイト ペーパーを参照してください。

Microsoft IT と同様のコネクタ トポロジをテスト ラボに適用するために、Omesh が Microsoft IT 用に作成したスクリプトに基づいたプロシージャを使用しました。セキュリティ上の理由から、個々のコマンドは大幅に変更し、短縮していますが、結果として得られるコネクタ トポロジは、Microsoft IT のトポロジに対応しています。次にその手順を示します。

1. 複数の役割を持つ Exchange サーバー (HUB-MBX-01) とエッジ トランスポート サーバー (EDGE01) で、既定のコネクタを削除します。
2. HUB-MBX-01 で、この記事のダウンロードに含まれている HUB-MBX-01_recv_connector.ps1 スクリプトを実行して、新しい受信コネクタを作成します。
3. EDGE01 で、EDGE01_recv_connector.ps1 スクリプトを実行して、内部と外部のメッセージング接続用の新しい受信コネクタを 2 つ作成します。
4. EDGE01 で、次のコマンドを実行して、サブスクリプション ファイルを作成します。

    New-EdgeSubscription -FileName 
    "c:\subscriptionfile.xml" 

生成されたサブスクリプション ファイルをハブ トランスポート サーバーのルート フォルダ (c:\subscriptionfile.xml) にコピーします。

5. HUB-MBX-01 で、サブスクリプション ファイルのパスが c:\subscriptionfile.xml であることを確認し、HUB-MBX-01_complete_subscription.ps1 スクリプトを実行します。このスクリプトは、送信コネクタを自動的に作成することなく、エッジ同期のサブスクリプション ファイルをインポートし、インターネットおよび内部接続用の送信コネクタを作成した後、結果として得られた構成をエッジ同期によってエッジ トランスポート サーバーにレプリケートします。

6. 構成を検証するために、インターネット ホストから Contoso.User@contoso.com と Fabrikam.User@fabrikam.com としてテスト メッセージを Administrator@adventureworks.com に送信してから、受信したメッセージに返信することによって、受信および送信メッセージの転送が機能することを確認します。

各スクリプト ファイルをメモ帳で開き、構成を実行するスクリプトで使用されているコマンドレットとパラメータを確認することをお勧めします。これらのコマンドレットとパラメータの詳細については、オンラインで Exchange Server 2007 の製品ドキュメントを参照してください。

エッジ トランスポートのアーキテクチャ

では、エッジ トランスポート エージェントにアクセスしてみましょう。これらのエージェントは、エッジ トランスポート サーバーの役割がインストールされたときから、HELO または EHLO が送信されてくるのを待機しています。エッジ トランスポート サーバー上で Get-TransportAgent コマンドレットを実行すると、図 3 に記載されている 11 個のエントリが表示されます。すべてのエージェントは既定で有効になっており、適切な設定を使用してメッセージを保護します。

Figure 3 トランスポート エージェント

Get-TransportAgent コマンドレットの結果と図 3 の一覧には、優先度の高い順にエージェントが列挙されていますが、これはエージェントが処理を実行する順序ではありません。基本的に、処理順序は登録されたエージェントに対応する SMTP 受信イベントとルーティング イベントの発生順序によって決まります。エージェントとイベントの関係については、図 4 を参照してください。この図は、トランスポート エージェントがエッジ トランスポートのアーキテクチャにどのように統合されているかを示しています。

図 4** エッジ トランスポート アーキテクチャ内のトランスポート エージェント **(画像を拡大するには、ここをクリックします)

トランスポート イベントは、メッセージ処理のさまざまな段階で発生し、スパム フィルタ処理、ウイルス スキャン、およびその他の作業を行うために、追加のコードを呼び出します。このように疎結合された拡張可能な設計では、エッジ トランスポートのプロセス (EdgeTransport.exe) がイベント ソースの役割を想定します。イベント ハンドラ、つまりトランスポート エージェントは、Microsoft® .NET Framework 2.0 を基盤としたマネージ委任オブジェクトであり、コールバック通知を受信するためにイベント ソースに登録されます。

図 5 は、Forefront Security が展開されているエッジ トランスポート サーバーにインストールされたすべてのエージェントがどのイベントに登録されているかを示しています。登録されているエージェントの数が多いため、これらの登録状況を整理するのは難しいかもしれませんが、がっかりしないでください。Get-TransportPipeline | Format-List コマンドをエッジ トランスポート サーバー上で実行すると、各トランスポート イベントにどのエージェントが登録されているかをより容易に分析できます。Microsoft Exchange Transport サービス (MSExchangeTransport.exe) が実行中で、前回サービスが再起動されてから少なくとも 1 つのメッセージがエッジ トランスポート サーバーから送信されていることを確認します。出力からわかるように、同じイベントの種類に複数のエージェントを登録することも、複数のイベントに個々のエージェントを登録することもできます。イベントに登録できるかどうかは、対応するエージェントの処理要件によってのみ決まります。

図 5** イベントへのトランスポート エージェントの登録状況 **(画像を拡大するには、ここをクリックします)

最も重要なイベントの 1 つは OnSubmittedMessage ルーティング イベントです。このイベントはメッセージが送信キューに配信されたときに発生します。すべてのメッセージは、SMTP、ファイル システム、またはその他のメカニズムのいずれを経由して送信されたかにかかわらず、このキューを通過する必要があります。カテゴライザは、Exchange Server トランスポート アーキテクチャの主要なコンポーネントの 1 つで、受信者の解決、メッセージの分岐とルーティング、および配信状態通知 (DSN) の生成を行います。したがって、OnSubmittedMessage イベントは、すべての受信メッセージを処理する必要があるエージェントの登録先として最適です。FSE ルーティング エージェントは、OnSubmittedMessage イベントに登録されている Forefront Security コンポーネントで、すべての受信メッセージをウイルス スキャン エンジンに渡します。FSE ルーティング エージェントが OnSubmittedMessage イベントに登録されているため、すべてのメッセージはウイルス対策ソリューションを経由することになります。

では、なぜすべてのエージェントを OnSubmittedMessage イベントに登録して、作業完了というわけにいかないのでしょうか。理由は、サーバーが配信の成功を確認する前の可能な限り早い時点で、望ましくないメッセージをブロックする必要があるためです。このイベントの前にメッセージをブロックしないと、スパムやウイルス攻撃の発生中に、サーバーが 9,000 万件の不要なメッセージを処理し、9,000 万件の配信不能レポート (NDR) を生成する可能性があります。これは、悪意のないユーザーにとっては深刻な脅威となります。スパムおよびウイルス攻撃は、必ずと言ってよいほど偽装された発信者情報を使用します。元のメッセージを作成していない受信者に数百万件の NDR が送信された場合、自分の組織のリソースと送信先の組織のリソースが無駄に使用されるだけでなく、悪意のあるユーザーがメール フラッディング攻撃や DDoS 攻撃を行う機会を与えることにもなります。悪意のある送信者の攻撃をできるだけ早く回避することは、自分自身を保護するだけでなく、他のユーザーを保護することにもなります。

メッセージを効率的にブロックするには、サーバーが "250 OK" 状態コードを返してデータの受信を確認する前に、トランスポート エージェントがリモート ホストとの SMTP 対話に割り込む必要があります。SMTP のストア アンド フォワードの原則に従うと、メッセージの配信が確認されていない場合、サーバーは NDR を生成することなく、受信したデータを安全に破棄できます。SMTP 受信エージェントは、この動作を実現できます。SMTP 受信イベント (リモート ホストによるサーバーへの接続、SMTP セッションの確立、SMTP コマンドの送信、メッセージの送信、および接続の終了) に基づいて、トランスポート パイプラインが SMTP 受信エージェントを起動するため、SMTP 受信エージェントは SMTP セッションと対話することができます (各操作に関連する SMTP 受信イベントについては、図 6 を参照してください)。Exchange Server 2007 のすべてのスパム対策エージェントは、配信前にメッセージを拒否し、リモート SMTP ホストを切断できるため、SMTP 受信エージェントとして実装されます。

Figure 6 SMTP セッション イベント

処理を行う状況という点から、SMTP 受信エージェントとルーティング エージェントの違いを認識しておくことは重要です。ルーティング エージェントはメッセージのすべてのプロパティにアクセスできますが、SMTP 受信エージェントは SMTP セッションと対話するため、状況に応じて動作が異なります。たとえば、スパム フィルタは、リモート ホストが実際にメッセージを転送するまで、メッセージのプロパティを操作できません。したがって、このエージェントを正しい SMTP 受信イベントに登録することが重要です。詳細については、補足記事「トランスポート エージェントの開発」を参照してください。

Exchange に関する詳細情報

• Microsoft Exchange Server 2007 のエッジ トランスポートとメッセージング保護 (Microsoft IT ショウケースのテクニカル ホワイト ペーパー)
• Windows PowerShell スクリプト センター
• Exchange Server 2007 TechCenter
• Microsoft Exchange チーム ブログ「EHLO さえあれば」

第 2 部の前に

トランスポート アーキテクチャとテスト シナリオの詳細に進む前に一息入れましょう。この記事では、Microsoft IT と同様のエッジ トランスポート サーバーの展開から、メッセージ処理中にトランスポート パイプラインで発生する内部イベントに至るまで、さまざまな基本事項を説明しました。この 2 部シリーズの次の記事では、いくつかの興味深いテスト シナリオを使用して、エッジ トランスポート エージェントの動作について詳しく説明します。

それまでは、Microsoft Visual Studio 2005 Professional Edition の 90 日間の試用版 (go.microsoft.com/fwlink/?LinkId=98043) をダウンロードし、Steve の説明に従って、テスト環境でサンプル エージェントのコンパイルとインストールを実行することをお勧めします。開発者でなくても、これらの作業は非常に簡単に実行できると思います。Exchange Server 2007 では、Visual Studio 2005 を使用してカスタム エージェントを非常に便利に開発できるため、このようなコンポーネントに依存するビジネス アプリケーションが増えたとしても驚くことではありません。

Kay Unkroth は、15 年間、マイクロソフトのサーバー テクノロジを専門とするサポート エンジニア、システム開発者、コンサルタント、トレーナー、著者としての職歴を持つ企業家です。また、ドキュメント管理とローカライズ サービスの専門企業 Biblioso Corporation の共同創立者であり、会長でもあります。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.