![]()
| 概要 | |
| はじめに | |
| スパム対策 | |
| ウィルス対策 | |
| メッセージングにおけるその他の防御テクノロジ | |
| ベスト プラクティス | |
| まとめ | |
| 詳細情報 |
迷惑メール (スパム)、ウィルス、悪意のあるソフトウェア (マルウェア) などの脅威がインターネット上で高まっていることは、他の企業と同様、Microsoft にとっても懸案事項となっています。この問題はここ数年でしだいに深刻になっており、インターネットに接続しているあらゆる企業が攻撃に対して予防措置を講じなければならない段階にまで来ています。インターネットの脅威は、もはや電子メール メッセージそのものだけに限らず、電子メールに関連したその他の脅威も発生しています。たとえば、SMTP (Simple Mail Transfer Protocol) 層でのサービス拒否 (DoS) 攻撃、ばく大な量の電子メールによってメッセージング システムをダウンさせることを目的としたメール爆弾攻撃、大量の有効な電子メール アドレスを盗み出そうとするディレクトリ収集攻撃などがあります。
1998 年以前は、スパムやウィルスその他の電子メール攻撃に対する防御ツールはほとんどなく、あってもごくわずかでした。これは、この問題が事実上存在しなかったためです。しかし、今日のインターネット環境においては、このような脅威に対する防御メカニズムを 1 つだけでなく数多く利用することが不可欠であると、Microsoft IT 部門では考えています。このアプローチでは、Microsoft やサード パーティのソフトウェア製品を、ゲートウェイからクライアントにいたるまで、メッセージ環境全体にわたって、複数の層に展開します。Microsoft IT 部門は、このような脅威に対抗するために自社に設けられたすべての防御メカニズムを総称してメッセージングにおける防御対策と呼んでいます。
1998 年以降、Microsoft IT 部門ではメッセージングにおける数多くの防御機能を Microsoft® Exchange インフラストラクチャ全体にわたって展開しています。最近は、ウィルス対策システムやスパム対策システムのアーキテクチャの向上によって、Microsoft IT 部門ではこれらの機能を実行するために環境内で必要とされるサーバー台数を 50% 近くにまで整理統合できるようになりました。このようなアーキテクチャの変化に加えて、Microsoft IT 部門では、インターネット メール ゲートウェイ層とクライアント層の両方で防御力を高めるというアプローチを採用しています。これによって運用コストを削減すると共に、悪意のある迷惑メールに対する保護レベルの向上を実現しています。
Microsoft IT 部門では、Microsoft のサーバー メッセージング製品である Microsoft Exchange Server 2003 のメッセージングにおける防御機能を使用して、従来は、電子メールをスキャンするサード パーティ製ソフトウェアによって提供されていたウィルス対策機能やスパム対策機能を強化しています。Microsoft IT 部門で最近展開されているこのような機能の例として、次のものがあります。
| • | 接続のフィルタリング。サード パーティから提供される、既知のスパム送信者のリアルタイム ブロック リストを使用します。 |
| • | 送信者と受信者のフィルタリング、および受信者の照合。 |
| • | Microsoft Exchange インテリジェント メッセージ フィルタ。内容に基づいてスパムをフィルタリングするソフトウェアです。 |
このドキュメントの執筆時点で、インターネットから Microsoft IT 部門の電子メール ゲートウェイに送信されるメッセージの平均量は、1 日あたり 800 万から 1,000 万に及んでいます。電子メールのフィルタリングに多層構造によるアプローチを採用した結果、受信電子メールが複数のメカニズムによって分析されるようになり、それぞれのメカニズムによって、通過が許されるスパムの量が段階的に減少します。以下では、フィルタリングの各段階について説明しています。これらは、このドキュメントの執筆時点における Microsoft IT 部門の電子メール フィルタリング層の効果を示しています。数値は 1 日あたりの平均量に基づいています。
1. | 接続のフィルタリング。すべての SMTP 受信接続のうちおよそ 25% がブロックされます。ブロックされる接続は、サード パーティのリアルタイム ブロック リストに列挙された既知のスパム発信源によるものです。 |
2. | 送信者と受信者のフィルタリング。接続のフィルタリング後に受信されたメッセージのうち 59% が除去されます。 |
3. | インテリジェント メッセージ フィルタ。送信者と受信者のフィルタリング後に残ったメッセージのうち 38% が除去されます。 |
以上の各段階を通過した残りの電子メールに対して、ウィルス スキャンが実行されます。この段階を通過した電子メールはメールボックス サーバーに送られ、ユーザーはそこで電子メールにアクセスできます。電子メール クライアントでもフィルタリング ソフトウェアが実行され、ユーザーに到達するスパムの量はさらに減少します。図 1 に示すように、すべてのフィルタリングが実行された後は、1 日に受信するインターネット電子メールの総量のうち平均でわずか 15% 程度しか残らなくなります。
最近の攻撃では、Microsoft IT 部門で受信する 1 日の電子メール量が 2 倍、3 倍、さらには 4 倍までに増大することがありますが、同部門の現在の防御層では、そのような攻撃によるユーザーへの影響が最小限または皆無になる程度にまで、メッセージング環境が保護され続けています。
Microsoft IT 部門は、同部門のメッセージング インフラストラクチャ内部でスパムやウィルス、電子メール攻撃などを撃退するためにどのような措置を講じているのかについて、毎日問い合わせを受けています。このドキュメントでは、これらの問題に対処するためのあらゆる戦略、プロセス、および課題について詳しく説明しています。また、このペーパーでは、Microsoft IT 部門において Exchange Server 2003– をベースとする機能 (インテリジェント メッセージ フィルタなど) を利用した結果得られた経験と、迷惑メールを除外するためのサード パーティ ソリューションについても、重点的に説明しています。
このペーパーは、分散環境において現在 Exchange Server 2003 を実行しているか、または Exchange Server 2003 へのアップグレードを検討している Microsoft ユーザーで、各自のメッセージング インフラストラクチャに送られてくるスパムや悪意のある電子メールの流れを管理したいと考えているユーザーを対象としています。特に、大規模または中小規模の企業の経営責任者や技術責任者、IT 設計者、および、インフラストラクチャ内のインターネット電子メールの流れを管理する責任を負っている運用管理者を対象としています。このペーパーで説明している概念のほとんどは Exchange Server 2003– をベースとするテクノロジを中心としていますが、以前のバージョンの Exchange を実行している環境にも当てはまる場合があります。
メモ : セキュリティ上の理由により、このペーパーで使用されているドメイン、社内リソース、組織などの名称は、必ずしも Microsoft 社内で実際に使用されている名称を表すものとは限りません。これらは説明や例示のみを目的としています。
迷惑メール (スパム) や悪意のあるコード (ウィルス、ワーム、トロイの木馬、マクロ、スクリプト、無許可の ActiveX® コントロールなど) の横行は、インターネットにアクセスしたり電子メールを利用したりする人にとって、ますます大きな問題になっています。個人レベルでの ID の盗み読みから、組織や企業、行政機関などに対する悪意を持った組織的な攻撃にいたるまで、ユーザーは電子メールに関する今日のセキュリティの脅威から免れることはできません。
数多くの大企業と同様に、Microsoft もまたセキュリティの脅威にさらされる主要な標的になっています。そのため、Microsoft IT 部門ではデータ センターからデスクトップ コンピュータにいたるまで、自社のリソースを絶えず油断なく保護する作業を行っています。Microsoft IT 部門では、電子メールをベースとするスパムやウィルス、その他の攻撃に対抗するための戦略、実装、および手続きを継続的に改良していくことで、この問題について事前対応的にアプローチしています。
スパムやウィルスや電子メール攻撃がビジネスに与える影響は大きく、これらの脅威に対して対抗手段を用意していない企業は大きなダメージを受けることがあります。スパムはもはや単なる嫌がらせだけの存在ではありません。企業にとっては、金銭的な面だけでなく、処理時間や帯域幅の使用、管理作業、リソースの消費などの面からみても、高いコストを強いられます。同様に、ウィルスや電子メール攻撃についても、ダウンタイムの発生だけで済めばまだよい方で、最悪の場合には企業にとってきわめて重要なリソースや知的財産がねらわれる恐れがあります。
2003 年 9 月、世界の IT 産業の調査分析を行っている大手調査会社 Gartner, Inc. から、『Stop Spam from Killing Workforce Productivity』(James Lundy、Maurene Caplan Grey、Arabella Hallawell 著) というレポートが発表されました。このレポートで、彼らは次のように述べています。「ほぼ 100% の企業がスパムの影響を受けており、そのうち平均的なビジネス メールボックスの 50% にスパムが届いています。また、効果的なスパムフィルタリング テクノロジを備えている企業は 10% にも達していません。しかし、企業ではスパムが生産性に影響を及ぼす大きな問題であることを認識してきており、対抗手段の検討に着手しつつあります。」
このレポートから 1 年も経たないうちに、電子メールのセキュリティ ソリューションや管理ソリューションを提供している業界大手の Postini Inc. から、世界中の電子メール総量のうち 82% 超がスパムで占められている、という趣旨のレポートが同社の Web サイトで報告されました。この他、投資回収率 (ROI) に重点を置いた、調査や助言のサービスを世界規模で提供している Nucleus Research, Inc. からも、2004 年 6 月に『Spam: the Serial ROI Killer』という調査レポートが発表されました。このレポートでは、Fortune 500 の企業に勤務している 82 人の従業員を調査した結果、彼らが 1 日平均で 15 分近く、平均で 29 のスパム メッセージを振り分ける作業に時間を費やしていることが明らかになりました。Nucleus Research では、スパムを原因とする生産性損失のコストは、2004 年に大規模な企業で従業員 1 人あたり 2,000 米国ドル近くに上ると推定しています。しかし、スパム フィルタを使用している企業は、スパム フィルタを使用していない企業と比べて、スパムを受信する量がおよそ 20% 少なくなるとも推定しています。
Microsoft IT 部門による、メッセージングにおける防御戦略が時間と共にどのように進化していったのかを示すために、Microsoft のネットワークとその基礎となるメッセージング インフラストラクチャの規模や範囲について説明します。
Microsoft の社内ネットワークは世界最大規模のコンピュータ ネットワークの 1 つです。このネットワークは世界各地に点在する数多くのサブネットワークで構成され、次のものが含まれています。
| • | 3 つのエンタープライズ データ センター |
| • | 世界各地の 19 のデータ センター |
| • | 77 の国の約 230 都市にある 300 を超えるサイト |
| • | 3,300 を超える IP (Internet Protocol) サブネット |
| • | 2,000 を超えるルータ |
| • | 世界各地の 10,000 を超えるサーバー |
| • | 350,000 を超える LAN ポート |
このような巨大なネットワーク インフラストラクチャを最大限に活用するため、世界各地 7 か所に配置された 160 台の Exchange Server 2003 サーバー (このうち 47 台は Microsoft Windows Server™ 2003 を実行するクラスタ化されたメールボックス サーバー) で構成される複雑なメッセージング環境が使用されています。このメッセージング インフラストラクチャを管理する作業はたいへんな労力を伴います。およそ 52,000 人の従業員が使用する 100,000 のメールボックスが同インフラストラクチャによってサポートされ、それぞれのメールボックスごとに 200 MB の容量制限が設定されています。世界中でやりとりされる電子メールの総量は 1 日あたり平均 1,100 万メッセージを超え、これらのうち 300 万が社内の電子メールです。毎日インターネットから受信される電子メールのうち約 85% が、スパムや、ウィルスに感染した電子メール、または宛先の無効な電子メールとして除外されています。
Microsoft IT 部門が自社のメッセージング環境をセキュリティ保護する手段は絶えず進化しています。その明白な原因として、インターネット上でスパムやウィルスが爆発的に増加し、電子メール関連の脅威の性質が絶えず変化していることが挙げられます。この問題に対処するため、すべての企業がさらに積極的に経営資源を投入しなければならない状態にあり、柔軟性や即応性が必要とされています。Microsoft IT 部門は、メッセージングにおける防御対策には、多層構造によるアプローチが不可欠だと考えています。単一の手段だけでは、たとえそれがどれほど満足のいくものであっても、インターネット電子メールに関連したさまざまなリスクの種類に対抗するには不十分です。多様な手段を利用してスパムやウィルスをネットワーク全体の複数の場所でフィルタリングすることは、十分な防御手段を構築するうえで必要不可欠であり、それによって複数の保護層が形成されます。
Microsoft IT 部門のメッセージングにおける防御対策のアプローチが絶えず進化しているもう 1 つの理由として、同部門の運用環境の性質が挙げられます。Microsoft IT 部門では、Microsoft のベータ レベルの未公開ソフトウェアを運用環境で頻繁に使用しています。ハイテク産業界ではこのような方法を “ドッグフーディング (dogfooding)”、つまり “自分のドッグフードを食べる (eating your own dogfood)” と呼んでいます。これによって、開発の初期の段階で Microsoft IT 部門から重要なフィードバックが製品グループに提供され、顧客にリリースされる製品の品質向上に役立てられます。そういった例の 1 つが、インテリジェント メッセージ フィルタです。同製品は、顧客に公開される前に Microsoft IT 部門の運用環境で使用されていました。(インテリジェント メッセージ フィルタの詳細については、http://www.microsoft.com/japan/exchange/downloads/2003/imf/default.mspx を参照してください)。ドッグフーディングは、Microsoft IT 部門が採用する戦略、同部門が使用するサード パーティ ソフトウェア ソリューション、およびサーバー自体の管理という観点から、独特の課題をもたらしますが、それらは克服できないものではありません。
1999 年から 2004 年 6 月まで、Microsoft では同社のインターネット電子メールおよびメッセージングにおける防御アーキテクチャにおいて、3 段階のアプローチを利用していました。このトポロジは互いに連結した 3 組のサーバー セットをベースとするもので、スパム対策、ウィルス対策、メッセージ内容のフィルタリング、インターネット電子メール ルーティングの各機能を提供していました。受信したインターネット電子メール メッセージはすべてこのサーバー セットを通過し、それから Exchange メールボックス サーバーにルーティングされていました (図 2 を参照)。
2004 年 7 月の直前まで、第 1 層のサーバー群は Exchange Server 2003 のゲートウェイで構成され、ネットワークの一番外側に設置されていました。第 1 層では、インテリジェント メッセージ フィルタとサード パーティのスパム対策ソリューションによって、送信者のフィルタリング、受信者のフィルタリング、およびインターネットからの受信メッセージのスパム ブロックが実行されていました。スパムでないと判断されたメッセージはすべて、第 1 層から、電子メールのウィルス スキャン専用の SMTP サーバー層に転送されていました。ウィルス対策スキャンが実行された後、ウィルスのないメッセージはすべて、第 2 層から第 3 層のサーバー群に渡されました。第 3 層は SMTP ルーティング サーバーとして構成された Exchange サーバー群で、社内へのメッセージ転送が実行されていました。そして、メッセージが第 3 層から Exchange メールボックス サーバーに配信され、そこで電子メール クライアントを通じ、各自のメッセージにアクセスすることができました。
このアーキテクチャが導入されていたころ、Microsoft IT 部門では、スパム対策やウィルス対策の製品を提供しているサード パーティの各ベンダについて評価を行い、要件を満たすソリューションを選定していました。ソリューションは最初に、Microsoft Exchange 2000 Server と Microsoft Windows® 2000 Server 上で実行されていました。このアーキテクチャは数年間、インターネット電子メールの脅威に十分対抗できていましたが、脅威が進化を続けるにつれて、また Exchange Server プラットフォームが拡張されることに伴い、Microsoft IT 部門では時間をかけてアーキテクチャを見直すことになりました。Microsoft IT 部門は次のような目標を掲げました。
| • | ウィルス スキャン機能を Exchange Server 2003 のゲートウェイ プラットフォームに統合することによって、同環境の総所有コスト (TCO) を低減すること。 |
| • | インターネット電子メール配信の均質性を確立し、メッセージのルーティングからサード パーティの SMTP サーバーをなくすこと。 |
| • | スパム度レベル (SCL : Spam Confidence Level) をはじめとする Exchange Server 2003 の特定の機能をソリューションに統合すること。Exchange Server 2003 のスパム対策機能の詳細については、http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/ast_anti_spam.asp (英語) を参照してください。 |
| • | Microsoft IT 部門のインターネット電子メールのルーティング トポロジを簡潔にすること。 |
| • | メッセージングにおける防御機能を統合した、Exchange Server 2003 をベースとするスケーラブルなゲートウェイ プラットフォームを構築すること。 |
現在、Microsoft IT 部門では、インターネット電子メールおよび電子メール スキャン用の最新のインフラストラクチャ設計 (図 3 を参照) を使用して、メッセージングにおける防御に関する前述の目標を実現しています。ゲートウェイ層のウィルス対策機能用プラットフォームとして Exchange Server 2003 を選択したことで、専用のウィルス スキャン サーバー セットが不要になり、Microsoft IT 部門では直ちに TCO を低減することができました。Exchange Server 2003 プラットフォームの使用によって、Microsoft IT 部門では、統合アプローチに準拠し、Exchange のネイティブの SMTP スタックを使用する、新しいウィルス対策ソリューションを選択できるようになりました。
メッセージングにおける以前の防御対策の構成と比較して、Microsoft IT 部門が現在準拠している設計とアプローチでは、Exchange 独自の機能がより多く使用されています。ここでは、インテリジェント メッセージ フィルタやサード パーティのスパム フィルタリングに加え、受信されるすべての電子メール メッセージが Exchange Server 2003 ソフトウェアから提供される次のセキュリティ機能によって管理されます。
| • | 接続のフィルタリング |
| • | 送信者と受信者のフィルタリング (空白の送信者のフィルタリングを含む) |
| • | 受信者の照合 |
| • | リアルタイム ブロック リストをベースとするフィルタリング |
| • | 送信者の表示名解決の抑制 |
これらの管理機能によって、従来のスパム フィルタリング ソフトウェアを超える保護機能が得られます。Microsoft IT 部門ではこれらの管理機能を Exchange ゲートウェイ サーバーの一番外側に実装し、そこに到達する可能性が最も高い、大量の悪意のあるメッセージの排除に役立てています。それ以外のメッセージは Exchange Server 2003 の SMTP ルーティング サーバーに転送されてウィルス スキャンが実行され、それからメールボックス サーバーに渡されます。
スパム対策やウィルス対策の保護機能の強化に加えて、Microsoft IT 部門の現在のゲートウェイ構成では負荷分散の強化やインターネット電子メールの可用性の強化も図られています。サード パーティの SMTP サーバーへの依存をなくし、代わりに Exchange Server 2003 のネイティブのトランスポート機能をゲートウェイ インフラストラクチャ全体にわたって使用することによって、Microsoft IT 部門では Exchange Server 2003 ゲートウェイ サーバーと Exchange Server 2003 SMTP ルーティング サーバーの間でメッシュ構造のトポロジを確立しています。ネットワーク層への災害や大規模災害に対する保護を目的として、Microsoft IT 部門では、インターネット ゲートウェイとメッセージングにおける防御インフラストラクチャを複数のデータ センターに分散しています。この分散により、1 か所での障害発生が避けられ、インターネット電子メールのルーティングとスキャンが可能な物理経路と論理経路が複数確保されるようになります。
スパムをフィルタリングしてインターネットから除去することは、Microsoft IT 部門のメッセージング インフラストラクチャが行う重要な機能の 1 つです。Microsoft の電子メール ドメインを標的にしたスパムは受信メッセージの全体量の中で高い割合 (およそ 85%) を占めているため、Microsoft IT 部門はスパム フィルタリング ソリューションを自ネットワークの一番外側である Exchange Server 2003 ゲートウェイ サーバー上に実装することにしました。迷惑メッセージをネットワーク境界のできるだけ近くで阻止することによって、そういったメッセージが社内システムを通過したために必要とされる処理や転送のオーバーヘッドがなくなり、帯域幅の消費や処理時間が最小限に抑えられます。
Microsoft IT 部門では、スパムのフィルタリング手段としてインテリジェント メッセージ フィルタをはじめとする複数の手段を利用しています。インテリジェント メッセージ フィルタは一番外側である Exchange Server 2003 ゲートウェイ サーバー上で実行され、Exchange プラットフォームと密接に統合されています。
インターネット電子メールが着信した際に最初に通過しなければならないフィルタが、インテリジェント メッセージ フィルタです。このフィルタは、メッセージング環境の一番外側にある Exchange Server 2003 ゲートウェイ サーバー上で実行されています。Microsoft の研究グループでは、もともとはインテリジェント メッセージ フィルタのテクノロジを Microsoft Hotmail® 向けに開発しました。これは、Microsoft Hotmail においてスパムが顧客の苦情として大きな問題になっていたためです。インテリジェント メッセージ フィルタには、Exchange Server 2003 が提供する SCL フレームワークが利用されています。インテリジェント メッセージ フィルタは、メッセージの特定の部分を分類し、経験則に基づくメッセージ分析を実行します。そして、スキャンされた個々のメッセージに SCL レベル値を割り当てます。SCL レベル値は 0 〜 9 の範囲で、メッセージに割り当てられたレベル値が高いほど、そのメッセージがスパムである可能性が高くなります。
管理者が設定したしきい値を超える SCL レベル値のメッセージに対してフィルタリング アクションを実行するよう、Exchange Server 2003 環境を構成することが可能です。インテリジェント メッセージ フィルタでは 2 つのしきい値が使用されます。これらは、Exchange Server 2003— のゲートウェイしきい値、およびストアしきい値として設定されます。
ゲートウェイしきい値には次の 2 つの構成要素があります。
| • | 実行するアクション |
| • | 設定したアクションが実行される SCL レベル値 |
たとえば、ゲートウェイしきい値を 6 に設定した場合は、6 以上の SCL レベル値のすべてのメッセージについて、設定したフィルタリング アクションが実行されます。設定可能なアクションは次のとおりです。
| • | 削除。メッセージをアーカイブせずに削除します。 |
| • | 拒否。最初にメッセージ全体を受信しますが、メッセージがスパムと判断された場合は、拒否通知が送信者に送信されます。 |
| • | アーカイブ。メッセージを削除しますが、後で確認できるようにメッセージのコピーをサーバー上に作成します。 |
| • | アクションなし。メッセージに対して何も実行しません。メッセージは SCL のレベル値と共に、通常どおりルーティングされます。 |
メモ : 受信したすべての電子メール メッセージについて、まずゲートウェイしきい値が適用され、それからストアしきい値が適用されます。
削除、拒否、アーカイブの各アクションには、それぞれ固有の利点と欠点があります。一定以上の SCL レベル値のメッセージについて削除または拒否することを組織で決めた場合は、それらのメッセージがそれ以上の場所に到達することはありません。メッセージの削除では、メッセージがディスクに書き込まれず、ウィルス スキャンが実行されません。システムを経由して送信されることがないため、無駄な処理時間がなくなるという利点があります。しかし、そのメッセージがメールの流れから永久に除去され、復元の可能性がなくなるため、強硬なアクションと考えられます。削除アクションは、設定したしきい値において、誤ってスパムと判断されてしまう正規のメッセージの数が少ない場合に効果があります。
削除アクションと同様に、拒否アクションでも、スパムと判断されたメッセージがメールの流れから除去されます。ただし、削除とは異なり、拒否ではステータスが SMTP エラー (到達不可能) メッセージの形式で送信者に提供されます。環境によっては、セキュリティ上の理由から、フィルタリング アクションについてスパム メッセージの送信者に知らせたくない場合があります。
組織でアーカイブ アクションを使用すると、スパムとしてブロックされた電子メールを調べ、誤ってスパムと判断されたメッセージの数から、設定する適切な SCL ゲートウェイしきい値の決定に役立てることができます。しかし、適切なツールを使用して、アーカイブされた内容を調べ、メッセージが誤ってスパムと判断されたかどうかを評価することがなければ、日常的な運用におけるアーカイブ アクションの利点は小さくなります。メッセージの内容を物理的にチェックする人間の眼が、最も信頼できるツールとなる場合が多くありますが、電子メールの量が 1 日あたり数十万から数百万にも及ぶと、アーカイブされた個々のメッセージを視覚的にチェックすることはまったく現実的ではありません。代わりの手段として、件名行や、その他のメッセージ プロパティごとにデータを集計する独自の自動化プロセスを使用し、それから数千のメッセージをサンプルとして調べる方法が考えられます。管理者は、このプロセスを簡素化するために、このようなデータを集計する基本的なスクリプトを作成することもできます。
メッセージのアーカイブに必要なディスク容量は、その環境の電子メール トラフィックの量や、受信するスパムの割合に比例します。そのため、大量の電子メールを受信する組織がアーカイブを予定する場合は、スパムのフィルタリング ゲートウェイに必要な格納容量について慎重に計画を立てる必要があります。Microsoft IT 部門は現在、Microsoft のメッセージング環境がインターネットから日常的に受信する電子メールの数を考慮して、ゲートウェイしきい値に削除アクションを使用しています。ただし、インテリジェント メッセージ フィルタの初期テスト中はアーカイブ アクションを使用していました。
ストアしきい値は、メールボックス サーバーに到達した電子メール メッセージの中で、ユーザー メールボックスの迷惑メール フォルダに移動する SCL レベル値を決めます。ストアしきい値は、ストア ルーティングを実行できるようにゲートウェイしきい値よりも低く設定する必要があります。たとえば、ゲートウェイしきい値を 6 に設定した場合、ストアしきい値は任意のアクションを実行できるように 4 に設定する必要があります。このストアしきい値の設定により、ストアしきい値よりも高い SCL レベル値に対しアクションを実行します。この動作はゲートウェイの設定とは異なります。ゲートウェイの設定の場合、SCL の設定値と等しいか、またはそれよりも高い SCL レベル値に対しアクションが実行されます。たとえば、SCL レベル値として 5 が与えられた受信メッセージは、ゲートウェイしきい値は通過しますが、ストアしきい値よりは大きいため、自動的にユーザーの迷惑メール フォルダに送られます。レベル値が 4 以下の受信メッセージはどちらのしきい値も通過するため、受信者の受信トレイに直接到達します。
ゲートウェイしきい値とストアしきい値の最も効果的なバランスは、組織のメッセージング環境によってまったく異なります。可能な限り最大限のスパムをインフラストラクチャのできるだけ早い段階で食い止めると同時に、誤ってスパムと判断されてしまうメッセージの数を最小限に保つことが、目標になります。管理者は各自の環境に応じて、インテリジェント メッセージ フィルタの設定を調整します。
ゲートウェイしきい値を高く設定すると、インフラストラクチャを通過しなければならないメッセージの量が増え、最終的にユーザーがデスクトップ層で処理せざるをえなくなる、という欠点が生じます。この結果、ストレージや帯域幅、管理など、インフラストラクチャの複数の側面でコストが増大します。
Microsoft IT 部門では低めのゲートウェイしきい値を使用しています。これは、Microsoft で受信する電子メールの量が多く、その中のスパムの割合も高いためです。それにもかかわらず、Microsoft IT 部門は正規の電子メールの削除に関して、0 に近い許容できるレベルを維持しています。一般に、正規のメッセージが誤ってスパムと判断されてしまったことを最もよく表す指標は、ユーザーの苦情です。一般には、インテリジェント メッセージ フィルタのしきい値を高めに設定して保守的な状態で始め、それから必要に応じてしきい値を低めに調整していくのが最善です。インテリジェント メッセージ フィルタではパフォーマンス カウンタの完全なリストが提供されます。管理者はこれらのカウンタを使用することで、受信メッセージ ベース全体で SCL レベル値の分散を調べ、それに応じて的確な判断を下し、各自の環境に合わせてしきい値を微調整できます。
数年前、電子メール ユーザーにとってスパムが初めて問題になった際、Microsoft IT 部門は他の多くの企業と同じように、サード パーティが提供する企業向けスパム対策ソフトウェア ソリューションだけに頼っていました。現在、Microsoft IT 部門は運用環境でインテリジェント メッセージ フィルタを使用しています。インテリジェント メッセージ フィルタは、インターネット ゲートウェイでスパムに対する保護層としての機能を果たします。
ウィルス対策およびスパム対策の新しいアーキテクチャの開発と合わせ、インテリジェント メッセージ フィルタや、接続のフィルタリング、リアルタイム ブロック リスト、送信者のフィルタリング、受信者の照合、添付ファイルのブロックを使用することで、Microsoft IT 部門はインターネット電子メールにおけるスパムの量を大幅に減らすことに成功しています。
理想としては、スパムがクライアント層に絶対に到達しないことが望まれます。しかし現実には、一部のスパムが Microsoft のネットワークを通過してユーザーのデスクトップ コンピュータに到達しています。その主な理由の 1 つは、ニュースレターなど一部の正規の電子メール メッセージに、スパムの特徴とされる情報が含まれていることです。このため、疑いのあるメッセージがすべて削除される程度までフィルタリングのしきい値を低く設定することは、望ましいことではありません。また、ユーザー個人が、企業全体で単一に行われている設定セットでは満たせない、個別の設定を使用している場合もあります。
Microsoft IT 部門ではやや低めのしきい値を使用しています。これによりスパムと似た特徴を持つ一部のメッセージが最終的にデスクトップ コンピュータに到達することが可能になります。そのため、同部門ではクライアント層でさらなる防御層を提供しています。Microsoft Office Outlook® 2003 および Outlook Web Access 2003 のユーザーは、差出人セーフ リストと差出人受信拒否リストを設定することができます。差出人セーフ リストには、信頼された電子メール アドレス名とドメイン名が格納されます。ユーザーは、これらの差出人のメッセージを常に受信します。逆に、差出人受信拒否リストには、ユーザーがメッセージの受信を拒否する差出人のアドレス名とドメイン名が格納されます。
Exchange Server 2003 では、信頼された送信者からのメッセージはすべてユーザーの受信トレイに配信され、受信拒否された送信者からのメッセージはすべてユーザーの迷惑メール フォルダに配信されます。この動作は、メッセージに割り当てられている SCL レベル値に関係なく実行されます。したがって、Outlook 2003 や Outlook Web Access 2003 のユーザーは、個人の設定により、各自のメールボックスについて、ストア層で設定された迷惑メールのフィルタリングを無効にすることができます。ただし、ユーザーはゲートウェイ層でのフィルタリング アクションをクライアント層で無効にすることはできません。メッセージがゲートウェイしきい値を超えた場合は、クライアント層の設定にかかわらず、ユーザーの受信トレイには配信されません。
ユーザーはまた、Outlook 2003 の迷惑メール フィルタのアクションをカスタマイズすることもできます。このフィルタは、メッセージをクライアントへの着信と同時に分析し、それらのメッセージをスパムとして扱うべきかどうかを判断します。ユーザーは、保護なしのレベルから、安全な送信者からのメッセージだけを許可するレベルまで、希望する保護のレベルを選択できます。迷惑メール フィルタに捕捉されたメッセージは、Outlook にあるユーザーの迷惑メール フォルダに直接移動されます。ユーザーはそのフォルダでメッセージを確認することも、削除することもできます。
スパムは厄介な存在であり、メッセージング環境においてパフォーマンスや生産性の問題を引き起こします。その一方で、ウィルスやワーム、トロイの木馬など、悪意のあるソフトウェアは、スパムよりもずっと大きなセキュリティ上の脅威をあらゆる企業にもたらします。1 つのウィルス攻撃が深刻な影響を及ぼすことがあります。最も軽微な場合は、除去のために多少ダウンタイムが発生する程度で済みますが、最悪の場合は、インフラストラクチャに壊滅的な損害が発生し、機密データが汚染または破壊されることがあります。
組織においては、電子メール ウィルスの問題に取りかかる前に、まずスパムをメッセージング環境から除去することによって、ウィルスのフィルタリングに伴うオーバーヘッド コストの大半を減らすことができます。通常、Microsoft IT 部門は毎日 1,000 万を超える電子メール メッセージをインターネットから受信し、処理しています。それらのメッセージのうち 85% 以上はスパムとして識別され、メールの流れから除去されます。ウィルスのスキャンを行う前にゲートウェイ層でスパムを除外する結果、処理サイクル、帯域幅、メッセージの格納容量などの面で大幅な節約になります。
ほとんどのメッセージング トポロジは、ウィルス対策の防御手段をさまざまな場所に展開することができます。メッセージングにおける防御に対し、多層構造のアプローチを維持する場合、ネットワーク環境全体にわたって複数の層にウィルス対策防御手段を展開するのが最も優れた方法だと、Microsoft IT 部門は考えています。この措置を講ずることで、パフォーマンスのオーバーヘッドは増加しますが、リスクは最小限に抑えられます。Microsoft IT 部門は、パフォーマンスとリスクの間でバランスのとれた点があると考えています。それぞれの組織は、各自の環境に応じて、ウィルス対策防御手段の展開場所をいくつ、どの層に設けるのかを決める必要があります。
組織のメッセージング環境には、ウィルス対策ソリューションを展開できる層として、従来から次の 3 つが存在します。
| • | ゲートウェイ |
| • | メールボックス サーバー |
| • | クライアント |
徹底した防御手段の概念を次に示します。Microsoft IT 部門は、図 4 に示すように、電子メールのウィルス対策システムの中心を SMTP ゲートウェイ層とクライアント層に設けることを選択しました。インターネット電子メールのトポロジ設計と、電子メール ルーティングの個別の最適化により、Microsoft IT 部門が管理する環境と外部のメッセージング システムとの間で交換されるメッセージが、ウィルス対策管理システムを必ず通過するようにできます。
インターネットから受信したメッセージは、まずスパムがないかスキャンされ、それから Exchange Server 2003– をベースとする SMTP ルーティング サーバーに転送され、ウィルスがないかすべてのメッセージがスキャンされます。その後、それらのメッセージがメールボックス サーバーに配信されます。ゲートウェイ層にウィルス対策防御を設ける一方で、Microsoft IT 部門は、クライアント層であるユーザーのデスクトップ コンピュータにもウィルス対策防御機能を設けることによって、多層構造による防御アプローチを一貫して実施しています。Microsoft IT 部門が管理する環境内のすべてのクライアント コンピュータは、サード パーティ製のウィルス対策ソフトウェアのインストール、設定、実行、および最新版への更新が必須となっています。また、技術的な管理や技術的なポリシーを通じ、クライアント層でのウィルス対策防御を常に実施することで、Microsoft IT 部門は、メッセージングの領域以外の、攻撃を伴うウィルス関連の脅威に対抗できるようになります。たとえば、ウィルス対策ソフトウェアをユーザーのデスクトップ コンピュータで実行することは、ファイル レベルでの感染や、ネットワーク接続から伝染するウィルスの防止に役立ちます。
また、Microsoft IT 部門が管理する環境の外部にウィルスが不用意に伝染するのを防ぎ、責任のリスクを最小限に抑えるために、送信電子メールのウィルス チェックについても、まずクライアント層で行い、それから SMTP ゲートウェイ層で行っています。
Microsoft IT 部門は、毎日の運用の一部分としてサード パーティ ソフトウェアを Exchange Server メールボックス サーバーで実行し、ウィルス対策防御の中心をストア層に置くという管理方法はとっていません。顧客から、その理由をたずねる質問がよく寄せられています。Microsoft IT 部門におけるドッグフーディングの作業のため、これらのサーバーには、たとえばプレリリース ビルドの Exchange Server ソフトウェアが絶えずインストールされるなど、頻繁に変更が加えられています。そのため、これらのサーバー上で信頼して実行できるウィルス対策ソフトウェアを見つけることが難しくなっています。ウィルス対策ベンダは、新しいバージョンの Exchange Server 上で実行されるソリューションについて、テストや開発の時間を必要とします。したがって、新しいバージョンの Exchange Server がリリースされた後も、リリースされたバージョンに対応するウィルス対策ソフトウェアが何か月にもわたって使用できない可能性があります。ウィルス対策ソリューションによってはベータ版の Exchange Server 上で実行できるものもありますが、Microsoft IT 部門ではそのようなソリューションの安定性に頼るというリスクを負うことはできません。このような理由から、現在 Microsoft IT 部門では電子メールのウィルス対策管理の中心をクライアント層とゲートウェイ層に置いています。別の環境では、ウィルス対策防御のための独自の要件について評価する必要があり、保護機能を実装する層として別の層を選択することも考えられます。しかし、組織でどのようなソリューションを選択する場合でも、多層構造による徹底した防御対策のアプローチを採用することで、単一層のアプローチよりも効果的なセキュリティ レベルが実現するといえます。
ゲートウェイ層とクライアント層での事前スキャンに加えて、Microsoft IT 部門では万一ウィルスが発生した場合に備えて、Exchange Server 2003 メールボックス サーバー上で緊急のウィルス対策セキュリティ管理と処理を実施することができます。これらの管理や手続きの詳細については、IT 導入事例ホワイト ペーパー「Incident Response: Managing Security at Microsoft」(http://www.microsoft.com/downloads/details.aspx?FamilyId=36E889BE-4FB0-447A-943A-7484CBA0E7C1&displaylang=en) (英語) を参照してください。
Microsoft IT 部門では、受信電子メールと送信電子メールで、スキャン ポリシーおよび処理を別々に管理しています。インターネットからの受信電子メールはインターネットへの送信電子メールよりも信頼性が低いため、より制限が強いポリシーが適用されます。
Microsoft IT 部門において受信電子メールと送信電子メールとで別々のポリシーが使用されている例の 1 つに、ウィルスの通知があります。たとえば、インターネットからの受信メッセージにウィルスが含まれている場合は、その感染が除去され、必要に応じて社内の受信者に通知があります。通知メッセージには、感染源の特定に必要な情報や、場合によっては修正手段を講ずるのに必要な情報が記載されています。感染メッセージの送信元である外部の送信者に対しては、以下の理由により、自動的な通知はありません。
| • | 送信者がなりすまし (偽装) である可能性があり、その場合、メッセージの実際の発信者に通知が送られない可能性があること。 |
| • | ウィルスに感染した多数の電子メール メッセージによって通知が行われる結果、アドレスのなりすましを受けた悪意のない送信者に対して DoS 攻撃が発生する恐れがあること。 |
| • | 通知によって、ウィルス対策システムの能力が外部ユーザーに知られてしまい、その情報が悪用される恐れがあること。 |
受信電子メールに対する制限が強いセキュリティ ポリシーのもう 1 つの例として、添付ファイルの削除があります。添付ファイルが削除されることで、危険性のある実行可能ファイルなどの添付ファイルが、受信したインターネット メールの流れから削除されるため、悪意のあるコードが電子メールを通じて環境内に侵入するリスクを緩和するのに役立ちます。添付ファイルの削除については、この後このドキュメントで詳しく説明します。
送信電子メールは受信電子メールよりも信頼性が高いため、送信電子メールに関する Microsoft IT 部門のポリシーは制限が少なくなっています。特定のファイルの種類の添付ファイルは、送信メッセージから自動的には削除されません。ただし、送信メッセージから感染が検出された場合は、その感染が除去されます。そして、送信元の社内ユーザーに通知が送られ、コンピュータにウィルスがないかスキャンするよう求めます。Microsoft の従業員が誤ってウィルスを外部に送信してしまった場合は、その送信者が感染源を特定できるように Microsoft IT 部門から通知が送られます。
受信電子メールと送信電子メールで異なるセキュリティ ポリシーを実装するには、電子メールのウィルス対策ソリューションが電子メールの方向を認識する必要があります。また、スキャンされた電子メール メッセージの方向を、権限の条件 (IP アドレスや認証など) を基にして特定する必要もあります。この機能がないと、なりすましの電子メールによってウィルス スキャン システムがかく乱され、正しくないセキュリティ ポリシーが適用されてしまう可能性があります。
Microsoft IT 部門では、ウィルス対策防御手段として、SMTP ゲートウェイ層とクライアント層という多層構造によるアプローチを採用しましたが、その次のステップとして、どのテクノロジ ソリューションを利用するか決める必要がありました。パフォーマンス、相互運用性、そしてセキュリティ上の理由から、ゲートウェイ層におけるウィルス スキャン ソリューションの戦略として、Exchange Server 2003 のゲートウェイ プラットフォーム、特に Microsoft IT 部門の Exchange SMTP ルーティング サーバーに注力することにしました。
Microsoft IT 部門では、Exchange Server 2003 プラットフォームを使用したウィルス対策ソリューションを統合するにあたり、2 つの選択肢がありました。
| • | Exchange Server 2003 のウィルス スキャン アプリケーション プログラミング インターフェイス (VSAPI) 2.5 の機能をトランスポート層で使用する |
| • | Exchange Server 2003 によって提供されるトランスポート イベント シンク モデルを使用する |
ウィルス対策ベンダは、自身のソリューションを導入するために、VSAPI 2.5 とトランスポート イベント シンクのどちらかを選択することが考えられます。これら 2 つの手段はどちらも同様の機能を持っていますが、完成した製品段階では結果が異なります。たとえば、ソリューションに VSAPI を使用した場合は、Exchange Server 2003 によって提供されるメッセージの解析および解読機能が利用できます。したがって、そのベンダが、メッセージを開く処理の詳細にかかわることや、ベンダ独自のメッセージ解析処理を実行することがない場合は、VSAPI を使用する可能性が高くなります。一方、メッセージの流れをより詳細に制御する場合、ベンダはトランスポート イベント シンクのアプローチを採用する可能性が高くなります。トランスポート イベント シンクを使用する場合は、ウィルス対策ソリューションの側で独自のメッセージ解析やレポート生成、パフォーマンス監視その他の動作を実行することが前提になります。
Microsoft IT 部門では、自環境の要件に最も適したウィルス対策ソフトウェアのベンダを選定する前に、広範な評価を実施しました。顧客は各自の環境に応じた独自の要件を持っており、それらの要件は Microsoft IT 部門の要件と大幅に異なる可能性があります。しかし、評価基準のいくつかは多くの環境でほぼ同様である可能性があります。Microsoft IT 部門において評価段階で考慮された技術的な要素のいくつかを次に示します。
機能 :
| • | ウィルスや、その他のマルウェアを検出する機能 |
| • | さまざまなメッセージ タイプ、エンコード、および形式のサポート |
| • | Exchange Server 2003 ゲートウェイ プラットフォームとの連携機能 (複数の SMTP 仮想サーバーのサポートなど) |
| • | メールの方向を認識する機能 (受信、送信、社内の各電子メールで異なるポリシーを使用できること) |
| • | ファイルのフィルタリング機能と添付ファイルのブロック機能 |
| • | 障害に対するトレランス、障害からの復旧 |
| • | ウィルス対策における、アクションと通知のカスタマイズのサポート |
| • | 複数のウィルス スキャン エンジンのサポート |
パフォーマンス :
| • | ソリューション全体のスループット |
| • | システムのオーバーヘッド |
| • | 通常負荷時とピーク負荷時のパフォーマンス特性 |
ユーザビリティとサポート :
| • | リモートでの監視および管理 |
| • | 複雑さと管理上のオーバーヘッド |
| • | ベンダによる製品サポートの品質 |
| • | 既存の運用ツールやプロセスとの連携 |
ウィルス対策戦略の一環として、Microsoft IT 部門では一部の種類の添付ファイルを拡張子と種類に基づいて、受信した電子メール メッセージから自動的に削除しています。ゲートウェイ層のウィルス対策ソフトウェアは、特定の種類 (.exe、.cmd、.com など) の添付ファイルについて、ウィルスによる感染を受けているかどうかに関係なく、それらを自動的に削除します。この種の添付ファイルはウィルス感染の危険性が高く、それらをネットワークの一番外側で削除することは、ウィルス対策署名がまだ開発または展開されていない可能性のある未知または新規のマルウェアから環境を保護するのに役立ちます。添付ファイルが削除された場合でも、メッセージそのものは配信され、社内の受信者は適切な通知を受け取ります。
Microsoft IT 部門では、添付ファイルが削除された場合でもメッセージを受信者に配信することが重要だと考えています。削除された添付ファイルの内容が正常な場合、受信者は他の方法を使用してその情報を取得できます。たとえば、送信者にデータを別の形式にパッケージ化してもらったり、FTP (ファイル転送プロトコル) など別のファイル転送手段を使用したりする方法があります。
ワームなど一部の種類のマルウェア感染が発生すると、多数の受信者を宛先とする大量の電子メールが同一の電子メール ゲートウェイまたは SMTP ルーティング サーバーに送られることがあります。感染したペイロードによってもたらされる脅威の他に、これらの大量のメッセージが電子メール システムにパフォーマンスの問題を引き起こすことが考えられます。このような電子メール メッセージの場合、添付ファイルを削除したり、ウィルスをメッセージから削除したりすることで、感染はなくなりますが、攻撃の DoS 的な面は緩和されません。この種の脅威に効果的に対抗するため、Microsoft IT 部門では、添付ファイルの削除とメッセージの削除を統合したソリューションを導入しました。大量のメールを生成するウィルスが原因でメッセージの感染が発生した場合、システムによってメッセージ全体がメールの流れから削除されます。その結果、同環境に与えるパフォーマンスのオーバーヘッドが最小限に抑えられます。
署名ベースのウィルス対策防御機能は、ウィルス定義ファイルの品質によってその効果が決まってしまう可能性があります。これらの定義ファイルは署名ファイルまたはパターン ファイルと呼ばれます。新規のウィルス攻撃から組織を保護し続けるには、署名ファイルを常に最新に保つ必要があります。もう 1 つ考慮しなければならない重要な点は、最新のスキャン エンジンを使用するということです。スキャン エンジンは、メッセージの解析およびスキャンを実行するメッセージ処理コンポーネントです。
Microsoft IT 部門では、最新のウィルス対策署名ファイルとスキャン エンジンをダウンロードする方法として、プル方式を採用しています。プル方式を採用することで、柔軟なスケジュールでダウンロードすることが可能になり、電子メール ウィルス スキャン システムをすべて、一貫した最新の状態に保つのに役立ちます。自動ダウンロード中に、利用できる更新ファイルがあれば、Microsoft IT 部門はプル方式によるダウンロードを手動で行うこともできます。この機能により、Microsoft IT 部門は、緊急事態の際に柔軟に対応することが可能になります。
Microsoft IT 部門は、ウィルス対策の管理について、明確なポリシーと、適切に定義されたプロセスを整然と配置することがきわめて重要と考えており、プロセスや手続きを可能な限り自動化しています。たとえば、ウィルス対策ソフトウェアが常に最新に保たれていて、すべてのサーバー上で常時実行されるようにするため、Microsoft IT 部門はゲートウェイに展開されたウィルス対策署名ファイルとスキャン エンジンについて、それらのバージョンを検証するプロセスを自動化しました。特定のサーバーで最新の署名ファイルが実行されていないなどの問題が検出された場合には、その問題に関する通知が管理者に送られます。
ウィルスの検出数に加え、電子メールの処理量に関する毎日の統計情報を監視することも、管理プロセスの重要な要素の 1 つです。たとえば、Microsoft IT 部門で検出されるウィルスの数は、ある日には 20,000 であったり、別の日には 200,000 であったりします。統計情報は、Microsoft IT 部門が遭遇したウィルス攻撃をすべてそのまま反映しているため、そこから傾向をつかむことは困難です。Microsoft は、日常的に攻撃の標的になっていますが、Microsoft IT 部門よりも大きな悪影響が別の企業で発生することもあります。こうした矛盾は、具体的には、攻撃の標的となっているドメインが原因となって起こります。毎日の統計情報に基づく指標を参考にすることで、管理者は業界内で発生した過去の攻撃の日時にさかのぼって関連付けを行い、特定の時間に発生した攻撃の影響を判断することができます。
このペーパーでは主にメッセージング環境について説明しています。したがって、ウィルス スキャンに関する議論はメッセージング レベルが中心になっています。しかし、Microsoft IT 部門は Exchange Server 2003 サーバー上で、ファイル レベルのウィルス対策スキャンも実行していることに触れる必要があります。このスキャンはメッセージ レベルでのスキャンとは完全に別のものであり、それ自体が、電子メールをベースとする感染からメッセージング環境を保護するわけではありません。
ファイル レベルでのスキャンは、インフラストラクチャの 1 要素である Exchange サーバーそのものを保護するうえできわめて重要です。オペレーティング システム レベルでのウィルス対策保護機能がなければ、サーバーの保守や修正プログラムの適用、トラブルシューティングなど、通常の運用操作が原因となって、サーバーが感染してしまう恐れがあり、その結果メッセージング サービスの可用性が低下したり、データが損失する可能性が発生します。
ファイル レベルのウィルス対策ソフトウェアを Exchange Server 2003 サーバー上で利用する組織は、さらなる予防措置を講じる必要があります。通常、ファイル レベルのウィルス対策ソフトウェアは Exchange 固有のデータ (Exchange のデータベース ファイルやログ ファイルなど) の内部構造を認識しません。そのため、それらの内容をスキャンした結果がサーバーの障害につながり、データ破壊を起こすことがあります。ファイル レベルのウィルス対策ソフトウェアを使用する場合は、メールボックス ストアや、トランザクション ログ、一時ディレクトリ、メッセージ キュー、その他の関連ファイルの場所など、Exchange Server– 関連のデータについて、それらを除外するように特別に設定する必要があります。メッセージング環境でよく見られる誤りとして、ファイル レベルのソフトウェアを Exchange サーバーに対し正しく設定していないことが挙げられます。Exchange でのウィルス対策ツールの使用に関する詳細については、Microsoft サポート技術情報の Knowledge Base の文書「Exchange Server 2003 とウイルス対策ソフトウェアの概要」(http://support.microsoft.com/default.aspx?scid=kb;ja;823166&sd=tech) および「Exchange とウイルス対策ソフトウェア」(http://support.microsoft.com/default.aspx?scid=kb;ja;328841&sd=tech」) を参照してください。
Microsoft IT 部門の多層構造による防御アプローチでは、事務所のデスクトップも、リモート環境で使用されるノート パソコンも、クライアント層でウィルス スキャンを実行することが求められます。Outlook 2003 の実行に加え、ウィルス対策ソフトウェアをすべてのクライアント システムで実行して、ウィルスから保護します。
Microsoft IT 部門では、クライアント層のウィルス対策ソフトウェアに対して厳密なポリシーを守っています。Microsoft の全従業員は、自社のネットワークにアクセスするため、デスクトップ コンピュータやノート パソコンなどの各クライアント コンピュータに Computer Associates の eTrust Antivirus をインストールして設定し、最新版に保つことが求められています。eTrust ソフトウェアは、あらゆるファイルについて、ユーザーがそれらのファイルをシステム上で頻繁に実行しているかどうかをリアルタイムでスキャンします。この動作はユーザーからはまったく見えません。スキャンが継続的に行われ、利用可能な更新プログラムがある場合は、それが取得されます。
Microsoft IT 部門ではログオン スクリプトのフレームワークを使用して、すべての従業員が必ずクライアント コンピュータに eTrust をインストールして実行するようにしています。ユーザーが自社ネットワークにログオンしようとするとき、ログオン スクリプトによって、クライアント層のウィルス対策サービスの状態を確認するなどのセキュリティ チェックがシステム上で実行されます。Microsoft IT 部門ではまた、社内で開発したツールやプロセスを使用して、自社ネットワークを絶えず監視しています。1 日を通じて決められた間隔で、ネットワークに接続しているすべてのコンピュータをスキャンし、修正プログラム レベルで準拠しているかどうか、および eTrust ウィルス対策ソフトウェアが存在するかどうかをチェックしています。クライアント システムで eTrust が実行されていない場合は、そのユーザーに通知が送られ、最新の eTrust ウィルス対策ソフトウェアをインストールする手順が示されます。ユーザーが指定の時間内にソフトウェアをインストールしなかった場合は、ユーザーのシステムが条件に沿うまで、そのユーザーのネットワークへのアクセスが拒否されます。
ゲートウェイ層の場合と同様に、クライアントにおいても添付ファイル管理機能を備えたウィルス スキャンをさらに実行することは、ユーザーのコンピュータのセキュリティを確保するうえでたいへん重要です。Outlook 2003 の添付ファイル ブロック機能は、以前のリリース バージョンから改善されています。Outlook のユーザーは、悪意のあるファイルの可能性がある、さまざま種類のファイルについて、それらの受信を拒否できるようになりました。この機能はゲートウェイ層での添付ファイルの削除機能と一貫しています。添付ファイルのブロックの詳細については、Microsoft サポート技術情報の Knowledge Base の文書「Microsoft Outlook で添付ファイルが開かない」(http://support.microsoft.com/default.aspx?scid=kb;ja;829982&sd=tech) を参照してください。
添付ファイルのブロックに加えて、Outlook 2003 では外部プログラムからのアドレス帳へのアクセスが制限されています。このため、アドレス帳から受信者が収集され、それらの受信者に電子メールが配布されて悪意のあるコードが広がる、という可能性が最小限に抑えられます。Outlook 2003 では、現在ログインしているユーザー以外のユーザーや、Outlook 2003 以外の外部プログラムが、Outlook のアドレス帳にアクセスしようとした場合に、ユーザーの画面に自動的に通知が表示されます。
Outlook 2003 はまた Web ビーコンと呼ばれる不正行為にも対応しています。Web ビーコンとは、有効な電子メール アドレスを特定、収集する際に利用される手段の 1 つです。たとえば、送信者は特別にコーディングされたイメージを電子メール メッセージの中に含め、それを無防備の受信者に送ることがあります。このイメージは、表示されたときに受信者の有効な電子メール アドレスを送信者に知らせるようにコーディングされています。Outlook 2003 ではイメージが自動的に表示されなくなったため、ユーザーは Web ビーコンから保護されます。
Microsoft IT 部門では、古いバージョンの Outlook クライアントが Exchange サーバーにアクセスするのを事前にブロックすることで、自社のメッセージング インフラストラクチャにおいて、クライアントのバージョン管理を日常的に実施しています。電子メール クライアント ソフトウェアのバージョン管理によって、ユーザーは最新バージョンの Outlook に組み込まれているセキュリティ機能を必ず利用するようになります。
メッセージングにおける総合的な防御戦略によって、ウィルスやスパムに対する防御だけでなく、それ以外の電子メール関連の脅威に対しても防御が可能になります。このような脅威としては、たとえばメール爆弾があります。メール爆弾は、システムのシャットダウンを目的として大量の迷惑メールを特定の受信者や電子メール システム全体に送り付ける行為です。この種の攻撃は単なる嫌がらせでもスパムでもなく、標的のはっきりした DoS 攻撃です。
また、別の種類の脅威としてディレクトリ収集攻撃があります。これは、電子メールの送信コマンドに対するサーバーの応答を分析することによって、大量の有効な受信者アドレスを盗み出そうするものです。ディレクトリ収集攻撃は、スパム実行者が可能な限りのあらゆる組み合わせの英数字ユーザー名を使用して電子メール サーバーにスパムを送信したときに発生します。電子メール サーバーが、配信できないメッセージを送信者に返すように設定されている場合、スパム実行者は受信した結果を分析してどの電子メール アドレスが返されなかったかを調べ、それを有効なアドレスと確定することが可能です。
以上のような脅威に対抗するには、スパム対策のソリューションや、ウィルス対策のソリューションだけでは不十分です。今日、Microsoft IT 部門では Exchange Server 2003 のセキュリティ機能を利用してこの種の脅威に対処しています。ここではこれらの機能について説明します。
Exchange Server 2003 には接続のフィルタリングと呼ばれる機能が組み込まれています。この機能は、接続サーバーの IP アドレスを、拒否 IP アドレスのリスト (リアルタイム ブロック リストとも呼ばれます) と比較します。IP アドレスの比較は SMTP セッションの開始直後に実行されるため、メッセージ送信のごく初期の段階で、組織のゲートウェイへの接続をブロックできます。リアルタイム ブロック リストに列挙されているサーバーは、メッセージを送信できる状態になる前に、接続が切断されます。このアプローチにより、メッセージング層とネットワーク層の両方でパフォーマンスが節約できます。
組織は、グローバル受信許可リストとグローバル受信拒否リストを手動で作成するか、またはサード パーティが管理している既知のブロック IP アドレス (リアルタイム ブロック リストとも呼ばれます) を使用して、Exchange Server 2003 による接続のフィルタリングを実施できます。
組織は、受信拒否 IP アドレスの静的リストを独自に作成できます。グローバル受信拒否リストには、その名前が示すとおり、そこからの電子メールの受信をすべて拒否する IP アドレスとネットワークが記載されています。これとは逆に、グローバル受信許可リストも作成できます。これは、電子メールに関するブロックやフィルタリングのポリシーを適用しない IP アドレスとネットワークのリストです。グローバル受信許可リストには、信頼関係が確立されている子会社や取引先に関連する IP アドレスを含めることが考えられます。このような措置は、組織においてメッセージが誤って悪意のあるものと判断されてしまう危険を回避したい場合に行い、特定の送信者が使用する電子メール サーバーの IP アドレスを、信頼されたものとして組織のグローバル受信許可リストに追加します。
メモ : グローバル受信許可リストやグローバル受信拒否リストを使用する以外に、IP アドレスに基づいて接続を許可または拒否するように Exchange Server 2003 を設定することもできます。この設定は SMTP 仮想サーバーごとに行うことができ、グローバル IP のフィルタリング機能であるグローバル受信許可リスト、グローバル受信拒否リスト、およびリアルタイム ブロック リストよりも優先されます。
リアルタイム ブロック リストは、確認されている既知のスパム発信源の IP アドレスで構成される、ドメイン ネーム システム (DNS) に基づくデータベースです。リアルタイム ブロック リストは、インターネットを継続的に監視し、既知のスパム発信源を追跡することをビジネスとしている企業から入手できます。攻撃側の IP アドレスが検出されると、それらがリアルタイム ブロック リストのデータベースに追加されます。これらのリストは、通常、無償で入手できます。メッセージングの管理者が、より幅広いサービスを希望する場合は、手数料を支払って入手します。
Exchange Server 2003 は、サード パーティのリアルタイム ブロック リストの使用が可能です。サード パーティのリアルタイム ブロック リストを使用するように設定した場合、Exchange Server 2003 サーバーは送信側サーバーの IP アドレスをリアルタイム ブロック リストのデータベースと照らし合わせてチェックし、一致するものが見つかった場合は接続を拒否します。
リアルタイム ブロック リストの機能では、メッセージの内容ではなく送信側サーバーの IP アドレスに基づいて、フィルタリング方法が決まります。このためリアルタイム ブロック リストは、技術的にはサード パーティ製のスパム対策ソフトウェアとは別のカテゴリに属します。リアルタイム ブロック リストは門番のような役割を果たし、悪意のある、または疑わしい、既知のサーバーからのメッセージが、環境内に侵入するのを防ぎます。リアルタイム ブロック リストを通過したメッセージはネットワークへの進入に一歩近づくことになりますが、その次は、スパム対策ソフトウェアなど、次層のメッセージングにおける防御手段によってその内容がチェックされます。
Microsoft IT 部門で毎日実行されるリアルタイム ブロック リスト関連の DNS クエリの件数は数千万にも及びます。このため、Microsoft IT 部門では事前に決められた時間ごとに (通常は 1 日に複数回)、リアルタイム ブロック リストのミラー コピーを自社環境内のローカル DNS サーバーに転送しています。リアルタイム ブロック リストを提供する業者の大半は、1 日あたり 250,000 回を超える量のクエリが実行されるため、リストのローカル コピーが必要になります。リアルタイム ブロック リストのコピーをリスト業者から転送する操作は、ゾーン転送と呼ばれます。Microsoft IT 部門は、リアルタイム ブロック リスト関連の DNS クエリが、Exchange Server 2003 ゲートウェイのローカル DNS サーバーに対して実行されるように、それらのゲートウェイを設定しました。
リアルタイム ブロック リストの各提供業者が提供しているリストやサービスの種類はそれぞれ異なるため、Microsoft IT 部門はいくつかの業者から慎重に選出しました。決定にあたっては、業者に対して次のような質問をし、その回答を参考にしました。
| • | リストの品質。リストに追加された新しい IP アドレスが、本当にスパム実行者かどうか、だれかが確認していますか。だれでもリストへの追加を実行できますか。 |
| • | リストのセキュリティ。リストに対してなんらかのセキュリティ チェックを実施していますか。誤って、または不正に追加された IP アドレスがないことをだれかが確認していますか。 |
| • | リストの更新プロセス。確認のプロセスはどういったものですか。リストへの追加が自動化されている場合、スパム行為が停止された後のリストからの削除も自動化されていますか。リストはどの程度迅速に更新されますか。 |
| • | リストの転送プロセス。Windows DNS と直接互換性のある BIND (Berkeley Internet Name Domain) 様式の完全転送または増分転送が可能ですか。 |
組織においてリアルタイム ブロック リストのサービスを使用する際に最も考慮しなければならないことの 1 つは、正規の送信者がリストに誤って追加された場合に備え、それに対処するプロセスを準備しておくことです。Microsoft IT 部門では、リアルタイム ブロック リストによって拒否された送信者に通知を行うように、ゲートウェイを設定しました。ブロックされた接続に対して生成される通知メッセージでは、メッセージが拒否された理由と、ブロックの根拠となったリアルタイム ブロック リスト、およびその提供業者が示されます。送信者はリアルタイム ブロック リスト提供業者と連絡をとり、問題を解決して、自身の IP アドレスをリストから削除してもらう必要があります。
正規の送信者がブロックされることを懸念したり、送信者が自発的にリアルタイム ブロック リスト提供業者と連絡を取るかどうか確信が持てない場合、その組織は、電子メール アカウントや配布グループを作成して Exchange Server 2003 の例外リストに追加することもできます。例外リストに追加された受信者に対して直接送信されたメッセージについては、リアルタイム ブロック リストの規則がバイパスされます。このバイパス用の電子メール アドレスを使用する際に注意すべきことは、スパム実行者がこの電子メール アドレスに対してスパムを開始する可能性があることです。そのような場合は、該当アドレスを容易に変更できます。
大規模な企業では、リアルタイム ブロック リストのデータベースのローカル コピーを自社の DNS サーバー上で管理することを選択する場合がありますが、そのような場合には、関係するすべてのチームが互いに緊密に連携して調整や作業を行うことが重要です。たとえば Microsoft では、DNS エンジニアリング チームがリアルタイム ブロック リストの DNS データベース上にローカル ミラー コピーを準備しましたが、これらの情報を主に使用する Exchange Server ゲートウェイは Exchange のサポート グループで管理されています。サポート グループは、自身の作業について十分な調整を行い、厳格なプロセスに従いました。一部の大きなリストは DNS のインフラストラクチャのパフォーマンスに影響を与える可能性がありました。DNS エンジニアリング チームでは、そのようなリストが自らの環境にどれだけの影響を与えるかを調べるために、必要なテストや評価を実施しました。どちらのグループも、それぞれの目標を達成するために緊密な連携作業を続けています。
送信者のフィルタリングでは、着信した個々の電子メール メッセージについてその差出人アドレスが調べられ、管理者が設定したブロック対象送信者のリストと比較されます。このリストには、Microsoft IT 部門が電子メールを受け取らない送信元の電子メール アドレスとドメインが含まれています。一般に、このリストには、ビジネスとは関係のないサイトからの電子メールなど、大量の迷惑メールを送信しているアドレスが含まれます。Microsoft IT 部門ではこのような送信者をスパム送信者とは見なさず、単に、組織が電子メールの受信を希望しない送信元のドメインまたは個人と見なしています。
送信者のフィルタリングだけでは、絶えず変化を続けるスパム メッセージに十分対抗できるだけの手段にはなりません。スパム電子メールはしばしば動的な、またはランダムの送信者から送られることがあるため、特定の送信者アドレスに基づくフィルタリングはあまり効果的ではありません。しかし、特定の発信源や電子メール ドメインから送られるメール爆弾攻撃のリスクを緩和する意味で、送信者のフィルタリングが役に立つ可能性があります。Microsoft IT 部門の環境では、送信者のフィルタリングだけで毎日数十万のメッセージがブロックされています。
通常、正規の電子メール メッセージには有効な送信者電子メール アドレスが含まれています。差出人アドレスが空白のメッセージは、通常は正規のものではありません。Microsoft IT 部門では Exchange Server 2003 を利用してこの種のメッセージをゲートウェイでブロックしています。これにより、受信するスパムの量がさらに最小限に抑えられます。
Microsoft IT 部門は、Exchange Server 2003 ゲートウェイ サーバーで受信者の照合機能も展開しています。この機能により、受信者の有効性がプロトコル レベルで保証され、そのうえで責任を持ってメッセージを配信することができます。存在しないユーザーに送られるメッセージはこの機能によって拒否されます。
受信者の照合が役に立つ理由は、他のフィルタが必ずしもこの種のメッセージを捕捉するとは限らないためです。この種の大量の迷惑メールを処理した場合、メッセージング サーバーやネットワーク全体に不必要な負担がかかります。この機能がなければ、システムはリソースを消費して電子メールを配信し、それが戻されることになりますが、この機能があるためにその分の電子メールの処理量が減少します。
管理者が受信者の照合を実装する際は十分な注意が必要です。受信者の照合を実装すると、メッセージング環境がディレクトリ収集攻撃を受けやすくなる可能性があります。これらの攻撃のリスクを低減するには、無効な受信者を対象とする要求に対して、その応答を遅らせるのが一般的な方法です。こうすることで電子メール アドレスを短時間に収集しようとする行為を防ぐことができ、なおかつ無効な受信者を宛先とするメッセージがブロックされます。Microsoft IT 部門では、無効な受信者に対するサーバーの応答を遅らせる一方で、有効なメッセージは引き続き通常どおり受信するように、Exchange Server 2003 ゲートウェイを設定することによって、ディレクトリ収集攻撃のリスクを最小限に抑えています。この処理の詳細については、Microsoft サポート技術情報の Knowledge Base の文書「Exchange Server 2003 電子メール アドレスの列挙を禁止するのに、セキュリティ アップデートが役立つよう入手できます。」(http://support.microsoft.com/default.aspx?scid=kb;ja;842851&sd=tech) を参照してください。
Exchange Server 2003 の受信者のフィルタリング機能を使用することで、Microsoft IT 部門では標的のはっきりしたメール爆弾攻撃から環境を保護したり、その影響を小さくしたりできます。しばしば、この種の攻撃の標的となっている受信者は、インターネットからのメッセージの受信をまったく必要としていないことがあります。受信者のフィルタリングでは、だれ宛てにメッセージが送信されているのかなどの条件に基づいて、メッセージがゲートウェイ層で拒否されます。
受信者のフィルタリングは、リアルタイムでのスパムの脅威に対抗するという点では、リアルタイムでのスパム対策ソリューションほど効果的ではありませんが、メール爆弾攻撃のリスクを低減するという点では非常に役立ちます。Microsoft IT 部門では最近、受信者のフィルタリングの使用によって、たった 1 日でわずか数人の受信者を宛先とする数百万のメッセージをブロックすることができました。
電子メール配布グループは、組織にとって非常に便利なものですが、メッセージの量が増える可能性があり、メッセージング環境に新しい脆弱性を及ぼす恐れがあります。配布グループには多数の受信者が含まれることがあり、悪意のある迷惑メールを送信する者にとって格好の標的になります。悪意のある電子メールを大きな配布グループに送信することに成功した場合、同じメッセージを特定の個人の受信者に送信した場合と比べてはるかに深刻な影響を及ぼします。
Microsoft IT 部門では Exchange Server 2003 の機能を使用して、管理者が電子メール配布グループを 2 つの方法で制限できるようにしています。1 つは、指定した送信者からのメッセージだけを受信するように、管理者が配布グループを設定する方法です。もう 1 つは、認証されたユーザーからのメッセージだけを受信するように、管理者が配布グループを設定する方法です。送信者が認証されない場合、保護された配布グループへのメッセージはブロックされます。Microsoft IT 部門ではさらにもう一歩対策を強化し、インターネットに対する電子メールの送受信を必要としないすべての配布グループに対し制限をかけています。つまり、外部ユーザーがこれらの配布グループに送信することはできません。
Microsoft IT 部門では、匿名で送信された受信電子メール メッセージについて、管理者が、Exchange Server 2003 の機能を使用して、それらの送信者表示名の解決を抑制できるようにしています。通常、送信者のアドレスが、Active Directory® ディレクトリ サービスで検出されたプロキシ アドレスと一致すると、Outlook 2003 クライアントによって、送信者アドレスが該当する表示名に自動的に解決されます。Exchange Server 2003 を使用した場合、管理者は送信者の表示名の自動解決を抑制できるようになりました。表示名の解決が抑制されている場合、Outlook 2003 が表示名を解決しないようにメッセージがマークされます。その結果、受信者にはグローバル アドレス一覧からの表示名ではなく、someone@example.com のようなインターネット電子メール アドレスが Outlook のメッセージ ヘッダーに表示されます。この機能によって、受信者はメッセージが Exchange Server 2003 組織の外部から発信されていて、そのため、なりすましの可能性があることを視覚的に確認することができます。
Microsoft IT 部門では、個々の顧客の環境はそれぞれ異なるものの、スパムやウィルス、電子メール攻撃、その他の電子メール関連のセキュリティ脅威に関してはすべての顧客が同じ問題に直面していると認識しています。それぞれの顧客がユーザビリティを維持しつつ、可能な限り最高水準の防御手段を備えることができるように、Microsoft IT 部門では以下のベスト プラクティスを開発または実装しています。
| • | 最も効果的な成果が得られるように、多層構造による防御手段を使用する。インターネット上でスパムや悪意のあるソフトウェアが横行している今日では、どのような企業においても、単一の防御手段だけではもはや効果的ではありません。ほんの 1 年前、Microsoft IT 部門では 1 つのフィルタリング ソリューションしか使用しておらず、スパムのうち 40% しかブロックできませんでした。現在、受信するインターネット電子メールの量は 1 日に数千万メッセージに及び、そのうち 85% がブロックされています。今日、多層構造による防御アプローチを導入したことによって、Microsoft IT 部門ではほぼすべてのスパムをブロックすることが可能になっています。 | ||||||
| • | スパムのスキャンをメッセージング ゲートウェイで実行する。社内ネットワークを経由して送られてくるスパムの量を最小限に抑えるため、Microsoft IT 部門ではゲートウェイ層でのスパムのスキャンを始めています。ここで重要なことは、できるだけネットワークの外側の近くでスキャンを行う、ということです。メッセージをスキャンした後は、疑いのあるメッセージについて、アーカイブ、拒否、削除、または何もアクションを実行しない、のいずれかを選択します。Microsoft IT 部門にとっては、スパムをゲートウェイで削除するという選択肢に最も意味があります。これは、スパムの疑いのあるメールを配信し格納するコストが高すぎるためです。スキャンをどこで実行するのか、そしてどのようなアクションが意味があるのかについては、それぞれの組織が自ら決める必要があります。ネットワークを往来して処理されるスパムの量を、できるだけ少なくすることが目標です。 | ||||||
| • | ウィルスのスキャンの前にスパムのスキャンを実行する。スパム対策スキャンでは、インターネットから受信したメッセージが高い割合でブロックされます。そのため、ウィルスのスキャンを行う前にスパムのスキャンを行うのが適切です。後でスパムと判断されるメッセージに対し、先にウィルス スキャンすることはコスト的に無駄です。このようなメッセージは最終的にブロックされるからです。これらのメッセージを格納したり、ネットワークを通じて送受信したりするには、より多くのディスク領域、ネットワーク帯域幅、およびサーバー処理サイクルが必要になります。 | ||||||
| • | 感染したメッセージについてはウイルス除去ではなく削除を実行する。ウィルス対策ソリューションによっては、検出したウィルスをメッセージから取り除き、メッセージの内容を保てるものがありますが、そのような試みが完全に有効だとは限らない場合があります。したがって、このようなメッセージをシステムを通じて送信した場合、潜在的なリスクが発生します。大量のメールを伴うワームなど、感染の種類によっては、ウイルスが除去されていても大量のメッセージが結果としてシステムのパフォーマンス低下に結び付くことがあります。Microsoft IT 部門では、感染したメッセージについてはウイルス除去ではなく削除を実行することを選択しています。これは、それほど大量の電子メールを毎日受信しているからです。ウイルスが除去されたメッセージは、ネットワーク上での送受信や格納が必要とされる電子メールの、全体量を増やすことになります。しかし、電子メールの削除に慎重な姿勢をとり、感染した電子メールのウイルス除去を試みる企業があることも、Microsoft IT 部門は認識しています。 | ||||||
| • | 特定のファイルの種類の添付ファイルを削除する。Microsoft IT 部門では添付ファイルのブロックについて、署名ベースのウィルス スキャンにさらなる価値を加えるものと考えています。未知のマルウェアや最近発生したマルウェアは、電子メールの添付ファイルの中に埋め込まれて送信されます。また、署名ファイルがまだ入手できなかったり、配備されていなかったりする場合があります。添付ファイルの削除はこのような危険から環境を保護するのに役立ち、さらなる防御層を提供します。適切なプラクティスは、電子メール ゲートウェイ層で添付ファイルの削除を実装し、添付ファイルを削除するゲートウェイ層のポリシーを、クライアントで強制的に行う、添付ファイルをブロックするポリシーと一致させる方法です。 | ||||||
| • | インターネット送信者へのセキュリティ通知を無効にする。Microsoft IT 部門では、次のような理由から、インターネット上の送信者に対して一切通知を送信しないことが適切だと考えています。
| ||||||
| • | 受信と送信の両方の電子メールについてウィルス スキャンを行う。Microsoft IT 部門のメッセージング環境では、受信電子メールをスキャンすることによってウィルスから環境を守ることが主要な問題となっていますが、社内のユーザーが送信電子メールを通じ、誤ってウィルスを送信することによって他のユーザーや外部の受信者に感染が広がるのを防ぐこともまた、同様に重要な問題です。 | ||||||
| • | インターネットへの送信電子メールが感染している場合にセキュリティ通知を生成する。社内のユーザーが感染したメッセージを誤って外部に送信した場合、そのユーザーのコンピュータが感染している可能性があります。そのような社内ユーザーに対して、システムから感染を除去するように通知を送り、感染した電子メールがそれ以上送信されないようにする必要があります。 | ||||||
| • | 制限された配布グループを使用する。制限された配布グループでは、どのユーザーが特定の配布グループにメッセージを送信できるのかを管理者が制御できます。これによって電子メールの全体量を減らし、リスクを緩和するのに役立ちます。Exchange Server 2003 が持つこの機能では、さまざまな制御レベルが用意されています。 | ||||||
| • | クライアント システムでウィルス対策ポリシーを一貫して強制的に実行する。メッセージング インフラストラクチャ全体で一貫性を保つことは、メッセージング環境の安全を確保するうえできわめて重要です。個々のユーザーは、プロセスにおける自分の役割と、利用できる制御レベルについて、認識し、理解する必要があります。 | ||||||
| • | ネットワークの一番外側とルーティングを管理する。Microsoft IT 部門の多層構造を利用したメッセージングにおける防御アプローチを、自らの組織にそのまま導入する場合は、メッセージング インフラストラクチャ全体に、できるだけ多くの防御手段を実装してください。その際、できるだけインターネットに近い側から始め、それからインフラストラクチャの各層へ、さらにクライアント層へと広げるようにします。また、それぞれの防御手段が互いに補い合うようにします。 | ||||||
| • | 空白の送信者をブロックする。通常、空白の送信者から受信した電子メールは正規のものではありません。スパム電子メールでは、メッセージの発信元の正体を隠すために空白の送信者が使用されることがあります。この理由から、Microsoft IT 部門では送信者が指定されていない電子メールは受信しないことが適切だと判断しています。 | ||||||
| • | 特定の IP アドレスやドメイン名からの電子メールをブロックする。標的のはっきりしたスパム攻撃やメール爆弾攻撃で、悪意のあるメッセージが特定の発信源から送られている場合は、IP アドレスに基づくフィルタリングや送信者のフィルタリングを行うことが、迅速かつ効果的な対抗手段となり、攻撃側のメッセージ トラフィックをブロックしてインフラストラクチャへの影響を小さくするのに役立ちます。 |
今日のほとんどの企業で行われているように、Microsoft IT 部門においてもまた、スパムやウィルス、電子メール攻撃など、自らのインフラストラクチャへのセキュリティ脅威に対して、絶えず油断なく対処する必要があります。Microsoft IT 部門は、その独自の運用環境から、いくつかの特異な課題に直面しています。その運用環境では、サーバーやプラットフォーム、アプリケーション、そしてオペレーティング システムが、リリース版とプレリリース版の両方を含めて複雑に混在しています。Microsoft IT 部門は、お客様のインフラストラクチャのセキュリティを守るうえでも主要な原則は同じであると考えています。
Microsoft IT 部門のメッセージングにおける防御戦略での最も重要なテーマは、多層構造によるアプローチが必要不可欠である、ということです。スパムやウィルスその他の悪意のある攻撃に対して、インフラストラクチャの単一の層だけで対処しようとすることは、十分ではありません。そのため、Microsoft IT 部門では、ウィルス対策ソフトウェアをメッセージング インフラストラクチャ全体の複数の層で展開しています。そして、サード パーティのソリューションと、Exchange Server 2003 や Outlook 2003 に組み込まれた無数の機能を組み合わせることで、防御力を強化しています。
Microsoft IT 部門の戦略では、大量のスパムや悪意のあるメッセージのネットワークへの侵入を防ぐというのが基本原理です。そのため、広範なフィルタリング プロセスをネットワーク ゲートウェイで利用しています。また、従来のメッセージング トポロジから、1 セットの専用サーバーを取り除くことによって、ネットワーク インフラストラクチャを合理化しています。このような取り組みはすべて、Microsoft IT 部門の TCO の削減に貢献しています。Microsoft IT 部門は、自らの環境の流動的な性質について認識しており、絶えず変化しながらインターネットを通じてネットワークに侵入しようとする危険に対処するため、今後もメッセージングにおける防御戦略の見直しを続けていきます。
インターネットでは、次の Web サイトで当社の情報をご覧いただけます。
http://www.microsoft.com/japan/
http://www.microsoft.com/japan/showcase/