Microsoft における Exchange SMTP ゲートウェイの構成
簡易メール転送プロトコル (SMTP) ゲートウェイを管理できるようにするだけでなく、セキュリティで保護するように構成することが課題になる場合があります。Microsoft IT の電子メール チームは、Exchange Server 2003 SMTP ゲートウェイのパフォーマンス、セキュリティ、および管理の容易性を最適に構成する際に経験したことをユーザーにご紹介します。
トピック
はじめに
SMTP の課題
推奨の構成変更
利点
詳細情報
はじめに
近年、多くの電子メール メッセージング環境では、セキュリティで保護され、管理が容易なインターネット電子メール接続の確立や保守に関する問題が発生しています。インターネット電子メールのルーティングを可能にする際の作業は比較的容易で、通常、大半のメッセージング プラットフォーム用にきちんと解説されていますが、それに対して堅牢なインターネット電子メール システムの構築は困難になりがちです。多くの IT プロフェッショナルは、この作業を、単に、受信電子メール用に DNS (ドメイン ネーム システム) の MX (Mail Exchanger) を作成し、送信電子メール用に SMTP (簡易メール転送プロトコル) コネクタに相当するものを設計することだと誤解しています。SMTP ゲートウェイのセキュリティ、パフォーマンス、および管理の容易性を最適化することはもっと複雑です。
IT に関するこの資料では、Microsoft Information Technology (Microsoft IT) グループがインターネット電子メール環境を構成する際に直面した問題や課題をご紹介するほか、Microsoft メッセージング環境で、インターネット電子メール フローのセキュリティと管理の容易性を高めるために実装したソリューションをご紹介することを目的としています。このソリューションは、Microsoft® Exchange Server 2003 テクノロジに基づいているので、Exchange Server 2003 を使用して電子メール ゲートウェイ機能を運用し、電子メールの送受信をインターネット経由で行う、他の企業のメッセージング環境に関連してくるでしょう。
注 : セキュリティ上の理由から、このホワイト ペーパーに記載されているフォレスト、ドメイン、内部リソース、組織のサンプル名、および内部で開発されたアプリケーションとファイルの名前は、Microsoft 社内で実際に使用されている名前ではなく、あくまで説明用のサンプルです。また、このドキュメントには、Microsoft IT が自社のデータ センターを運営する方法が記載されています。ここに含まれている手順および方法は、汎用的なデータ センターの運用方法の規範を示すものではなく、Microsoft Customer Support Services によるサポート サービスの対象にはなりません。
SMTP の課題
技術的な詳細を説明する前に、SMTP によってもたらされる課題を調べてみましょう。典型的な SMTP ゲートウェイ システムは、スパム対策やウイルス対策など、企業電子メールのウイルス予防策を適用するためのメッセージング インフラストラクチャとしてよく使用されます。また、次の異なる 2 つの電子メール トランスポート メカニズムを橋渡しする基本的な役割もあります。1 つは、社内メッセージング システムのトランスポートで、信頼性が高く、既に信頼関係があり、認証済みで、機能豊富なほぼ同種のトランスポートで、もう 1 つは、インターネットや境界ネットワーク (DMZ、非武装地帯、スクリーン サブネットなどとも呼ばれます) のトランスポートで、信頼性が低く、匿名で、一般的には信頼関係のない異種トランスポートです。
たとえば、Exchange Server 2003 や Exchange 2000 Server を使用する企業の場合、社内 Exchange SMTP トランスポートの認証、送信者アクセス許可の適用、リンク状態や EXCH50 情報の交換などが行われます。また、適切に設計されたメッセージング環境では、電子メールが媒介する内部メッセージのウイルスやスパムが駆除されます。通常の外部 SMTP トランスポートには、このような特性はありません。
この資料の重要課題である、社内ネットワークと社外ネットワーク間のメッセージ フローの管理における Exchange Server 2003 SMTP ゲートウェイの役割を図 1 に示します。
図 1. Exchange Server 2003 SMTP ゲートウェイの役割
ほとんどの Exchange Server 2003 および Exchange 2000 Server 環境では、Exchange SMTP ゲートウェイをインターネットまたは境界ネットワーク インフラストラクチャに接続する際に次の課題があります。
Exchange SMTP ゲートウェイは、境界ネットワーク内の SMTP ゲートウェイ、またはインターネットからの匿名 SMTP 接続を受け入れる必要があります。多くの企業は、社外からパスワードを入手する攻撃のリスクを最小限に抑えるため、Exchange SMTP 認証を社外システムに公開することを望みません。
Exchange SMTP ゲートウェイは、認証済みの SMTP 接続を社内 Exchange サーバーから受け入れ、その接続から受信した電子メールをインターネットに中継する必要があります。また、システム情報 (リンク状態や EXCH50 情報など) を、認証済みの接続が必要な社内 Exchange サーバーから受け入れて転送する必要がある場合もあります。社内 SMTP システムに対して匿名 SMTP 認証を許可することは望ましくありません。この認証により、そのゲートウェイに対して許可されていない電子メールの送信が可能になるためです。匿名の電子メール送信では、社内環境であっても、送信者アドレスがスプーフィングされる可能性があります。
Exchange SMTP ゲートウェイの管理者は、その環境に着信する SMTP 電子メールやその環境から発信される電子メールにフィルタ処理やアーカイブなど、さまざまな操作を適用することができます。一般的に、インターネットから着信する受信電子メールは、セキュリティの観点から信頼性が低いので、多くの場合、スパム フィルタ、ウイルス スキャン、コンテンツ検査など、追加のセキュリティ チェックの対象にします。送信電子メール トラフィックは、通常、信頼性が高いので、パフォーマンス上の理由から、受信電子メールに対して行われるフィルタ処理やセキュリティ制御の一部が見送られることがあります。
企業には、インターネットに送信する電子メールの量とインターネットから受信する電子メールの量を比較するための簡単な指標とレポート機能が必要です。これらの指標は、多くの場合、容量計画、または スパム フィルタ テクノロジへの IT 投資の評価に使用されます。
ゲートウェイの役割には Exchange Server 2003 SMTP スタックが機能的かつ効率的ですが、その既定の構成では上記の作業の実現は難しくなります。Exchange Server 2003 ベースの SMTP ゲートウェイの代表的な既定の構成を図 2 に示します。
図 2. Exchange Server 2003 ベースの SMTP ゲートウェイの代表的な既定の構成
図 2 の設計は、電子メールのルーティングの観点からは実用的ですが、次の制約と問題点があります。
受信電子メールと送信電子メールの両方が同じ仮想サーバーを通過するので、電子メールのフィルタ処理、ブロック、否認の追加など、さまざまなポリシーを適用することが難しくなります。
認証が社外環境に公開され、社外システムによるパスワードの推測が可能になります。
認証済みのユーザーの中継が許可されるので、社外ユーザーは有効なユーザー名とパスワードを 1 組知っていれば、外部ホストからの電子メールを中継できます。
既定の構成では、インターネット プロトコル (IP) アドレスで既定の SMTP 仮想サーバーを制限できません (たとえば、境界ネットワーク内の SMTP サーバーだけに電子メールの送信を許可するなど)。IP アドレスで制限すると、すべての社内 Exchange サーバーから接続できなくなります。
匿名 SMTP が社内クライアントに公開され、社内クライアントはゲートウェイをすぐに電子メール サーバーに変換できます。社内ユーザーは、SMTP アプリケーションを使ってその電子メール サーバーを対象に電子メールを直接インターネットに中継できるので、このような機能のために確立された企業の手段が迂回されます。
受信電子メールと送信電子メールの指標を計算する簡単な方法はありません。管理者は、多くの場合、追跡ログを手作業で解析してこのデータを入手するという根気のいる作業が必要になります。
推奨の構成変更
Microsoft IT が Exchange Server 2003 ベースの境界ゲートウェイの既定の設計に少し手を加え内部的に実装した方法を使えば、既に説明した制限事項や問題点がすべて解決されます。Microsoft IT がカスタマイズした、Exchange Server 2003 ベースの SMTP ゲートウェイの構成を図 3 に示します。
図 3. Microsoft IT がカスタマイズした SMTP ゲートウェイの構成
Exchange Server 2003 と Exchange 2000 Server はどちらも、1 台の Exchange ホスト コンピュータに複数の SMTP 仮想サーバーを作成できます。このような複数の SMTP 仮想サーバーは、論理的に区別する必要があります。1 つの SMTP 仮想サーバーを受信 SMTP 仮想サーバーに指定し、インターネットからの電子メール トラフィックを処理します。もう 1 つの SMTP 仮想サーバーで送信 SMTP トラフィックを処理します。各サーバーは個別に制御できます。
複数の SMTP 仮想サーバーを作成する最も簡単な方法は、これらのサーバーに異なる IP アドレスに割り当てることです。デュアルホーム コンピュータの場合は、これらの IP アドレスを個別のネットワーク アダプタに割り当てます。1 つのネットワーク アダプタを使用するサーバーの場合は、複数の IP アドレスをその 1 つのネットワーク アダプタに割り当てることができます。複数の SMTP 仮想サーバーを作成するときは、Exchange システム マネージャで、サーバーを個別の IP アドレスに正しくバインドする必要があります。
インターネット用の SMTP コネクタを適切な SMTP 仮想サーバー (図 3 で示した送信 SMTP 仮想サーバー) でホストすると、指定した仮想サーバーだけが電子メールをインターネットに送信するようになります。境界ネットワーク内の MX レコードやスマート ホスティング SMTP サーバーで 2 つ目の SMTP 仮想サーバーの IP アドレスを指すと、そのサーバーを通過するすべての電子メール トラフィックが組織に着信するようになります。
SMTP 仮想サーバーを IP アドレスにバインドする場合、着信 SMTP 接続のみに影響することに注意してください。ゲートウェイ サーバーからの送信 SMTP 接続のソース IP アドレスは、送信ホストの IP アドレス層によって決まります。たとえば、ゲートウェイが 2 つの IP アドレス (172.16.x.1 と 10.x.x.1) を所有していて、リモート ホスト 10.x.x.2 と通信する場合、SMTP 接続のソース IP アドレスは、送信接続を開始した SMTP 仮想サーバーに関係なく、10.x.x.1 になります。
利点
この設計では、SMTP 仮想サーバーに対して、個別に異なるフィルタ処理や他のセキュリティ ポリシーを適用できます。たとえば、インターネットからスプーフィングされる問題を緩和するために、特定のインターネット電子メール エイリアスの送信者フィルタを実装すると、受信 SMTP 仮想サーバーのみでこのようなフィルタを有効にできます。したがって、送信電子メール フローは、このようなフィルタ処理の影響を受けません。
Exchange Server 2003 ゲートウェイ プラットフォームで実行するスパム フィルタ ソリューション (Microsoft Exchange インテリジェント メッセージ フィルタなど) がある場合、そのソリューションを受信 SMTP 仮想サーバーにバインドできます。この方法では、送信電子メールではスパムがスキャンされません。このようなスキャンを行うと、必要以上にサーバーのパフォーマンスに影響する場合があります。
この設計のさらなる利点として、このゲートウェイを通過する受信および送信インターネット電子メール フローの監視がより容易になります。システム モニタには、SMTP 仮想サーバーごとに SMTP カウンタの個別のインスタンスがあります。図 4 に示すように、SMTP 1 のカウンタは 1 つ目の SMTP 仮想サーバー (この場合は送信電子メール) を表し、SMTP 2 は受信インターネット電子メールを表します。
図 4. 2 つの SMTP 仮想サーバーを示すシステムモニタのサンプルスクリーンショット
実稼動中のメールボックスをホストする Exchange サーバーでは、指標の収集を目的に、前述の SMTP 構成を使用しないように注意してください。Exchange サーバーをシャットダウンして再起動すると、起動する 1 つ目の SMTP 仮想サーバーは、Exchange ストアからトランスポートにメッセージを送信する際に使用されるローカル ストアの送信キューに関連付けられます。サーバーでホストされているメールボックスから送信される電子メールの場合、これらのメッセージの処理に使用される SMTP 仮想サーバーは保証されません。これは、受信電子メールと送信電子メールを比較した指標の有効性に影響する場合があります。
詳細情報
Microsoft 製品またはサービスの詳細については、Microsoft Sales Information Center、(800) 426-9400 (アメリカ国内)、Microsoft Canada Information Centre、(800) 563-9048 (カナダ国内) にお問い合わせください。米国 50 州とカナダ以外のお客様は、最寄りの Microsoft オフィスまでご連絡ください。World Wide Web 上の情報については、次のアドレスにアクセスしてください。
https://www.microsoft.com/japan
https://www.microsoft.com/itshowcase (英語)
https://www.microsoft.com/japan/technet/itsolutions/msit/default.mspx
このドキュメントに関する質問、コメント、ご提案、または Microsoft IT Showcase についてのお問い合わせがある場合には、下記のアドレスに電子メールをご送信ください。
showcase@microsoft.com (英語のみ)
このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関するマイクロソフトの確約とは見なされないものとします。また、発行以降に発表される情報の正確性に関して、マイクロソフトはいかなる保証もいたしません。
このホワイト ペーパーに記載された内容は情報提供のみを目的としており、明示、黙示または法律の規定にかかわらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。
お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。マイクロソフトは、個人的な教育目的に限り、このホワイト ペーパーのすべてまたは一部を複製する権利をお客様に付与します。
マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。
別途記載されていない場合、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、出来事などの名称は架空のものです。実在する商品名、団体名、個人名などとは一切関係ありません。
© 2005 Microsoft Corporation.All rights reserved.
このドキュメントに記載された内容は情報提供のみを目的としており、明示または黙示に関わらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。Microsoft、Active Directory、BackOffice、Microsoft Press、SharePoint、Windows、および Windows Server は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。記載されている会社名、製品名には、各社の商標のものもあります。
ドキュメントの位置付け
「Note on IT」は、Microsoft IT に関連する具体的なトピックを技術的な側面から詳しく掘り下げ、簡潔に説明するもので、通常、既存の「IT ショウケース」ドキュメントに関連付けられています。この資料では、Microsoft IT が特定の運用タスクをどのような手順で実行したか、またはハードウェア デバイスやソフトウェア アプリケーションをどのように構成したかについて説明します。また、資料の内容がベスト プラクティスの詳細に関連していたり、ユーザーからよく求められる Microsoft IT 運用に関する重要な情報が含まれることもあります。
対象読者
メッセージング システムのアーキテクトとエンジニア、Active Directory のアーキテクトとエンジニア、Microsoft Exchange Server 2003 の管理者、メッセージング サポート スタッフ。
製品とテクノロジ
Microsoft Exchange Server 2003
簡易メール転送プロトコル (SMTP)