|
| |
| Sun Java System Messaging Server 6 2004Q2 配備計画ガイド | |
第 9 章
セキュリティで保護された Messaging Server の設計この章では、セキュリティの手法の概要、一般的なセキュリティ脅威、およびセキュリティニーズ分析の手順の概要について説明します。
この章には、以下の節があります。
セキュリティ戦略の作成セキュリティ戦略の作成は、配備計画のなかで最も重要なステップの 1 つです。セキュリティ戦略は、組織のセキュリティに対するニーズを満たし、ユーザーに不便を強いることなくセキュリティが確保されたメッセージ環境を提供するものでなければなりません。
さらに、セキュリティ戦略は単純なものにして、管理を容易に行えるようにしておく必要があります。複雑なセキュリティ戦略を用いると、ユーザーがメールにアクセスできなかったり、ユーザーや権限のない侵入者によってアクセスされては困る情報が変更されたり、収集されたりする問題が生じます。
RFC 2196、『Site Security Handbook』に、セキュリティ戦略を構築するための 5 つのステップが記されています。
- 何を保護するのかをはっきりさせる
たとえば、保護対象のリストにはハードウェア、ソフトウェア、データ、従業員、文書、ネットワークインフラストラクチャ、または組織の評判などが含まれます。
- 何から保護するのかを判断する
例: 権限のないユーザー、スパマー、またはサービス拒否攻撃
- システムに対する脅威の可能性を推測する
大規模なサービスプロバイダの場合、セキュリティが脅威に晒される可能性は小規模な組織よりもはるかに高いといえます。さらに、組織の性格がセキュリティに対する脅威を誘発することも考えられます。
- 費用対効果の高い方法で資産を守る対策を導入する
たとえば、SSL 接続を設定する際のオーバーヘッドによって、メッセージング配備のパフォーマンスに対する負荷が発生する可能性があります。セキュリティ戦略を設計するうえで、セキュリティニーズとサーバーの能力のバランスを取る必要があります。
- 戦略を常時見直し、弱点が発見されるたびに戦略を練り直して、よりすぐれたものに改善する
定期的な監査を行い、セキュリティポリシーの全体的な有効性を検証します。監査は、ログファイルと SNMP エージェントが記録した情報を調査することで行います。SNMP の詳細については、『Sun Java System Messaging Server 管理ガイド』を参照してください。
セキュリティ戦略では、以下の項目についても計画する必要があります。
物理的なセキュリティ
インフラストラクチャの重要部分への物理的なアクセスを制限します。たとえば、ルーター、サーバー、配線クローゼット、サーバールーム、データセンターを、窃盗、改竄、その他の悪用から保護するために、物理的な制限を設けます。権限を持たない人物にサーバールームへの侵入を許し、ルーターの配線を抜かれることがあるようでは、ネットワークとサーバーのセキュリティも無意味なものとなります。
サーバーセキュリティ
重要なオペレーティングシステムアカウントとデータへのアクセスを制限することも、セキュリティ戦略の一部となります。この保護は、オペレーティングシステムで利用できる認証とアクセス制御のメカニズムにより行われます。
さらに、最新のオペレーティング環境のセキュリティパッチをインストールし、数ヶ月ごとに、またベンダーからのセキュリティ警告に対応して、パッチを更新する必要があります。
ネットワークセキュリティ
ネットワークへのアクセスを制限することは、セキュリティ戦略の重要なポイントとなります。通常は、ファイアウォールを使用してネットワークへの全般的なアクセスを制限します。ただし、電子メールはサイト外から使用できるようにしておく必要があります。SMTP がそのサービスの 1 つに該当します。
ネットワークのセキュリティを確保するには、以下の条件が必要となります。
メッセージングセキュリティ
Messaging Server には、以下のセキュリティ機能があります。
この章の後半では、メッセージングシステムを保護するセキュリティ手法について説明します。
配備におけるメッセージングコンポーネントの保護この節では、メッセージング配備でコンポーネントをセキュリティで保護する方法について説明します。
MTA リレーの保護
セキュリティで保護された MTA リレーにより、リソースの処理とサーバーを保護します。権限を持たないユーザーからメッセージがリレーされた場合、または大量のスパムが配信された場合には、応答速度が遅くなり、ディスク容量が圧迫され、エンドユーザーのための処理リソースが消費されます。スパムはサーバーのリソースを浪費するだけでなく、エンドユーザーを煩わせるものでもあります。
以下の表で、MTA リレーに対する最も一般的な脅威について説明します。
MTA リレーに関するこの節では、配備で使用できるセキュリティオプションについて説明します。
アクセス制御
アクセス制御を使用して、特定のユーザーから (へ) のメッセージをシステムレベルで拒否できます。また、特定のユーザー間でより複雑なメッセージトラフィックの制限を構成することもできます。さらに、ユーザーに独自の受信メッセージのフィルタ設定を許可し、メッセージヘッダの内容に基づいてメッセージを拒否することなどができます。
エンベロープレベルでアクセス制御を行いたい場合は、マッピングテーブルを使用してメールのフィルタリングを行います。ヘッダベースでアクセス制御を行いたい場合、またはユーザー独自の制御を行いたい場合は、サーバー側のルールとともに一般的なメールボックスフィルタを使用します。
マッピングテーブルの概要
メールサービスへのアクセスを制御するには、一定のマッピングテーブルを使用します。以下の表で、マッピングテーブルの使用により、だれがメールを送信または受信できるのか、あるいは送受信ともにできるのかを制御する方法を説明します。詳細は、『Sun Java System Messaging Server 管理ガイド』を参照してください。
以下の図は、メール受信プロセスの中でマッピングテーブルが使用される場所を示したものです。
図 9-1 マッピングテーブルとメール受信プロセス
MTA サービスディスパッチャーが管理するすべてのネットワークポートで、PORT_ACCESS 拒否応答が保証されている場合は、リモートホストから最初の接続が行われた時点で、それが実行されます。FROM_ACCESS による拒否は、送信側が受信者情報またはメッセージデータを送信する前に、MAIL FROM: コマンドへの応答として行われます。SEND_ACCESS またはMAIL_ACCESS による拒否は、送信側がメッセージデータを送信する前に、RCPT TO:: コマンドへの応答として行われます。SMTP メッセージが拒否された場合は、Messaging Server がメッセージデータを受信せずメッセージデータを確認しないため、そのような拒否を処理するためのオーバーヘッドが最小になります。複数のアクセス制御マッピングテーブルが存在する場合、Messaging Server はそれらをすべて調べます。
マッピングテーブルによるリレー防止設定
アクセス制御マップを使うことによって、Messaging Server システムが SMTP メールのリレーに利用されるのを防ぐことができます。たとえば、メールシステムを使ってジャンクメールを多数のメールボックスに送信しようとする者がいるような場合です。
Messaging Server のデフォルトでは、ローカルの POP メールクライアントおよび IMAP メールクライアントによるリレーを含むすべての SMTP リレー操作が防止されます。「Authenticated SMTP を有効にする」で説明しているように、IMAP クライアントまたは POP クライアントが SMTP AUTH により認証されなかった場合で、Messaging Server の SMTP サーバーを使って外部アドレスにメッセージを送信しようとした場合、その送信は拒否されます。このため、内部システムとリレーを許可するサブネットを認識するように設定を変更した方がよいでしょう。
外部ホストからのリレーを防止するには
ドメイン外にあるホストからドメイン外の別のホストにメッセージがリレーされるのを防ぐには、以下の方法を取ります。
メールボックスフィルタの使用
フィルタは、メッセージに適用される 1 つ以上の条件付きアクションで構成されています。Messaging Server フィルタはサーバーに保存され、サーバーによって評価されます。そのため、それらは SSR (サーバー側ルール) と呼ばれることもあります。
チャネルレベルのフィルタと MTA 全体のフィルタを作成し、不正メールの配信を防止できます。また、フィルタテンプレートを作成し、Messenger Express を使用してそれをエンドユーザーに使わせることもできます。エンドユーザーはテンプレートを使用して個人のメールボックスフィルタを構築し、不要なメールメッセージが自分のメールボックスに配送されないようにすることができます。サーバーは、次の優先順位に従ってフィルタを適用します。詳細は、『Sun Java System Messaging Server 管理ガイド』を参照してください。
- ユーザー単位のフィルタ
ユーザー単位のフィルタは、特定ユーザーのメールボックスに送信されるメッセージに適用されます。フィルタテンプレートを作成し、Messenger Express クライアントを使用してそれをエンドユーザーに使わせることができます。エンドユーザーはテンプレートを使用して個人のサーバーフィルタを構築し、自分のメールボックスへのメールメッセージの配送を管理できます。フィルタにより、不要なメッセージ、リダイレクトメールなどの拒否や、メールボックスフォルダに配信されるメッセージのフィルタリングなどが行われます。
個人用メールボックスフィルタにメッセージの許可あるいは拒否が定義されている場合は、メッセージに対してそのフィルタ処理が行われます。
フィルタテンプレートは、Sieve スクリプトの「ハードコード」された要素をプロンプトと入力フィールドに置き換えます。Java サーブレットは、sieve テンプレートを解析し、ブラウザ内でユーザーインタフェースを生成するのに使用されます。エンドユーザーが入力フィールドに値を入力すると、サーブレットがその値を取得して、ユーザーのディレクトリにあるプロファイルエントリ内の sieve スクリプトに保存します。Messenger Express インタフェースを通じて、プロンプトと入力フィールドがエンドユーザーに提示されます。
しかし、受取人がメールボックスフィルタを設定していない場合、またはユーザーのメールボックスフィルタが明示的に適用されないメッセージの場合、Messaging Server によってチャネルレベルのフィルタが適用されます。
- チャネルレベルのフィルタ
チャネルレベルのフィルタは、チャネルのキューに入った各メッセージに適用されます。この種のフィルタの一般的な用途は、特定のチャネルから入ってくるメッセージをブロックすることです。
チャネルレベルのフィルタを作成するには、SIEVE を使用してフィルタを書く必要があります。SIEVE を使用してフィルタを作成する場合の指示の詳細は、『Sun Java System Messaging Server 管理ガイド』の「メールフィルタリングとアクセス制御」の章を参照してください。
チャネルレベルのフィルタにメッセージの許可あるいは拒否が定義されている場合は、メッセージに対してそのフィルタ処理が行われます。それ以外の場合は、Messaging Server によって MTA 全体のフィルタが適用されます (該当する場合)。
- MTA 全体のフィルタ
MTA 全体のフィルタは、MTA のキューに入るすべてのメッセージに適用されます。この種のフィルタの一般的な用途は、メッセージの宛先とは関係なく、ダイレクトメールや受信したくないメッセージをブロックすることです。
MTA 全体のフィルタを作成するには、SIEVE を使用してフィルタを書く必要があります。SIEVE を使用してフィルタを作成する場合の指示の詳細は、『Sun Java System Messaging Server 管理ガイド』の「メールフィルタリングとアクセス制御」の章を参照してください。
デフォルト設定を使用した場合、それぞれのユーザーはメールボックスフィルタを所有していません。ユーザーが Messenger Express インタフェースにアクセスして 1 つまたは複数のフィルタを作成すると、そのフィルタが LDAP ディレクトリに保存されます。
変換チャネルとサードパーティーのフィルタリングツール
変換チャネルは、MTA を通じて配信されるメッセージを本文部分ごとに変換します。この処理は、サイトで提供されるプログラムかコマンドにより行われます。変換チャネルは、テキストや画像のフォーマット変換、ウィルスのスキャン、言語の変換などを行うことができます。MTA で通信するさまざまなメッセージ形式を変換することができ、特定の処理やプログラムをメッセージの本文部分に指定することができます。変換チャネルをウィルススキャニングプログラムと併用する場合は、ウィルスの除去、メッセージの保留または拒否を選択できます。特別な変換チャネル設定を使用すると、それぞれのメッセージ本文に対する適切な変換を選択できます。詳細については、『Sun Java System Messaging Server 管理ガイド』の「事前定義のチャネルの使用」の章を参照してください。
変換チャネルを使用すると、サードパーティーのスパム防止およびウィルス対策ソフトウェアソリューションを利用できます。また、MTA API を使用してチャネルを作成し、リモートスキャニングエンジンを起動することもできます。MTA API の詳細につては、『Sun Java System Messaging Server Developer's Reference』を参照してください。
一般に、サードパーティーのソリューションは外部サイトから保護して、バックエンドまたは中間のリレーのみで使用するのが最も適した使い方です。
Brightmail ソリューションは、Brightmail サーバーと、リアルタイムのスパム防止およびウィルス対策 (サービスプロバイダ向けのみ) ルールアップデートで構成されており、ルールはメッセージングサーバーにダウンロードされます。Brightmail Logistics and Operations Center (BLOC) が電子メールプローブからスパムを受信すると、オペレータがただちに適切なスパム防止ルールを作成します 次に、これらのルールが Brightmail カスタママシンにダウンロードされます。同様に、Symantec Security Response のリアルタイムのウィルスルールが Brightmail から送信されます。これらのルールは顧客の Brightmail サーバーでスパムやウィルスを検出するために使用されます。
Messaging Server では、SpamAssassin の使用もサポートされています。SpamAssassin はフリーウェアのメールフィルタで、スパムの特定に使用されます。SpamAssassin では、すべてのメッセージのスコアが計算されます。スコアは、メッセージヘッダーや本文の情報に対して一連のテストを実行することによって計算されます。各テストに成功するか失敗するかによってスコアは調整されます。スコアは正または負の実数です。スコアが一定のしきい値を超えると、スパムであるとみなされます。
Brightmail および SpamAssassin for Messaging Server の設定の詳細については、『Sun Java System Messaging Server 管理ガイド』を参照してください。
RBL チェック
Mail Abuse Protection System の Real-time Blackhole List (MAPS RBL) は、スパムの発信やリレーを行ったり、スパムのサポートサービスを提供したりしてホストやネットワークを悪用している者に好意的、あるいは中立的な立場を取っていると判断されたホストとネットワークのリストです。
外部からの MAPS RBL に対する接続の比較を行うように、MTA リレーを設定することができます。また、DNS ベースのデータベースを使用して、不特定多数宛のメールを送る可能性のある受信 SMTP 接続を判別できます。
詳細については、『Sun Java System Messaging Server 管理ガイド』の「メールフィルタリングとアクセス制御」の章を参照してください。
クライアントアクセスの制御
Messaging Server は、POP、IMAP、および HTTP について、サービスごとの高度なアクセス制御機能をサポートしています。Messaging Server のアクセス制御機能は、TCP デーモンと同じポートで待機するプログラムです。アクセス制御機能では、アクセスフィルタによるクライアントの識別情報の検証が行われ、そのクライアントがフィルタリング処理を通過した場合は、デーモンへのアクセスが許可されます。
大企業やサービスプロバイダのメッセージングサービスを管理する場合、これらの機能を使用して、スパム (大量メール送信) や DNS スプーフィングを行うユーザーをシステムから除外したり、ネットワークの全般的なセキュリティを強化したりできます。
Messaging Server の TCP クライアントアクセス制御システムは、必要な場合、その処理の一部として、次のようなソケットの終端アドレスの分析を行います。
システムは、この情報をフィルタと呼ばれるアクセス制御文と比較して、アクセスの許可または拒否を決定します。サービスごとに、個別の許可フィルタと拒否フィルタのセットを使用して、アクセスを制御します。許可フィルタは明示的にアクセスを許可し、拒否フィルタは明示的にアクセスを禁止します。
クライアントがサービスへのアクセスを要求すると、アクセス制御システムは、そのクライアントのアドレスまたは名前情報を、以下の条件を使用して順番に対象のサービスのフィルタと比較します。
ここで説明するフィルタの構文は柔軟性に富んでいるため、わかりやすい簡単な方法で、さまざまなアクセス制御ポリシーを実装できます。許可フィルタと拒否フィルタは自由に組み合わせて使用できますが、大半のアクセスを許可するフィルタまたは大半のアクセスを拒否するフィルタを使用すると、ほとんどのポリシーを実装できます。
クライアントアクセスフィルタは、問題のあるドメインの数が把握できる場合に特に有効です。UBE の場合、Messaging Server はすべてのスパムメッセージを格納し処理しなければなりませんが、クライアントアクセスフィルタの場合はスパムメッセージを処理する必要がありません。クライアントアクセスフィルタはドメイン全体からのメールをブロックするため、この機能は慎重に使用する必要があります。
クライアントアクセスフィルタには、以下の制限があります。
クライアントアクセスフィルタの詳細については、『Sun Java System Messaging Server 管理ガイド』の「セキュリティ設定とアクセス制御」の章を参照してください。
セキュリティ戦略の監視
サーバーの監視は、セキュリティ戦略で重要な位置を占めます。システムに対する攻撃を識別するには、メッセージキューのサイズ、CPU の使用率、ディスクの空き容量、ネットワークの使用率を監視します。メッセージキューのサイズが異常に大きくなったり、サーバーの応答時間が長くなったりするのは、MTA リレーへの攻撃の可能性があります。また、通常とは異なるシステムの負荷パターンや接続についても調査します。ログを毎日チェックして、異常な活動がないか調べます。
メッセージストアの保護
メッセージングサーバーで最も重要なデータは、メッセージストア内のユーザーのメールです。メールメッセージは、暗号化されない個別のファイルとして格納されることに留意してください。したがって、物理的なアクセスや root アクセスからメッセージストアを保護する必要があります。
メッセージストアをセキュリティで保護するには、ストアがインストールされているマシンへのアクセスを制限します。暗号化されないプレーンテキストのパスワードの代わりに、CRAM-MD5 パスワードまたは DIGEST-MD5 パスワードを使用できます。パスワードの詳細については、「ユーザー認証の計画」を参照してください。
ストアマシンの認証にパスワードを作成するだけでなく、VPN アクセス、ssh、または pam のようなツールを使用して、マシンへのログインが許可されている有効なユーザーのリストを作成することもできます。
また、1 階層のアーキテクチャよりも 2 階層のアーキテクチャをお勧めします。メッセージストアは、メッセージングシステムのコンポーネント中で最もディスクに負担をかける作業を行うため、フィルタリング、ウィルススキャニング、およびその他のディスクに負担をかけるセキュリティ処理を同じマシンで行わないようにします。2 階層のアーキテクチャでは、システムに余分な負荷がかかるメッセージストアと同じマシンで UBE フィルタ、リレー防止機能、およびクライアントアクセスフィルタを使用せずにすみます。代わりに、MTA リレーがその処理を行います。さらに、ストアへのユーザーアクセスが 2 階層配備の MMP または MEM (Messenger Express Multiplexor) により制限され、実質的にメッセージストアにセキュリティ層を追加したことになります。
1 階層のアーキテクチャで配備を行う場合は、セキュリティ処理の追加と、SSL やウィルススキャニングなどに必要となる負荷を考慮してください。詳細は、第 6 章「サイズ決定戦略の計画」を参照してください。
メッセージストアにセキュリティ処理を追加する場合は、ユーザーごとにディスク割り当てを行って、ディスクの使用率を制限します。また、空き容量が制限に近づいたときには管理アラームを出すようにします。さらに、MTA の場合と同様に、サーバーの状態、ディスク容量、サービスの応答時間を監視します。詳細については、『Sun Java System Messaging Server 管理ガイド』の「メッセージストアの管理」の章を参照してください。
MMP および Messenger Express Multiplexor (MEM) の保護
MMP はメッセージストアのプロキシとして機能するため、エンドユーザーデータへのアクセスを防ぎ、権限のないアクセスから保護する必要があります。ユーザー ID とパスワードは、基本的な認証機能となります。さらに、クライアントアクセスフィルタを使用すれば、ユーザーが特定のドメインや特定の IP アドレスの範囲にアクセスするのを制限できます。SMTP リレーサーバーのセキュリティを提供する方法としては、SMTP 認証または SMTP Auth (RFC 2554) をお勧めします。SMTP AUTH は、認証済みのユーザーだけに MTA を介したメール送信を許可します。詳細は、「Authenticated SMTP を有効にする」を参照してください。
POP サービスまたは IMAP サービスの前に、MMP を別のマシンまたは別のユーザー ID のもとに配置します。フロントエンドマシンには MMP とMTA のみを配置してから、フロントエンドマシン、メールストア、および LDAP サーバー間で、セキュリティで物理的に保護されたネットワークを構築できます。
ユーザーがインターネットからログインする場合は、Messenger Express からメッセージストアへのアクセスのセキュリティには特に配慮が必要となります。一般的には、ストアはファイアウォールにより外部と分離します。さらに、HTTP アクセスサービスへの単一の接続ポイントとして機能する特別なサーバーとして、Messenger Express Multiplexor (MEM) を使用することも考えられます。MMP と同様に、MEM は、メールクライアントとの間で、暗号化されていない通信と暗号化された (SSL) 通信の両方をサポートしています。MEM は、エンドユーザーデータへのアクセスと権限のないアクセスからの保護も行う必要があります。
ログファイルを定期的に監視することで、権限のないアクセスを防ぐことができます。
ユーザー認証の計画ユーザー認証を行うことで、ユーザーはメールクライアントへのログインとメールメッセージの取得が可能になります。ユーザー認証の方法には以下のものがあります。
プレーンテキストと暗号化されたパスワードによるログイン
ユーザー ID とパスワードは、LDAP ディレクトリに保存されます。「最小の長さ」のようなパスワードのセキュリティ基準は、ディレクトリのポリシー要件で決定されます。パスワードのセキュリティ基準は、Messaging Server 管理の一部ではありません。ディレクトリサーバーのパスワードポリシーを理解するには、『Sun Java System Directory Server 配備計画ガイド』を参照してください。管理者は、メッセージング設定パラメータを設定して、プレーンテキストのパスワードを許可するかどうか、パスワードの暗号化を必須とするかどうかを決めることができます。詳細については、service.xxx.plaintextminciper (xxx は『Sun Java System Messaging Server Administration Reference』の http, pop または imap パラメータ) を参照してください。
プレーンテキストによるログインと暗号化されたパスワードによるログインは、どちらも POP、IMAP、および Messenger Express ユーザーアクセスプロトコルで使用できます。
Simple Authentication and Security Layer (SASL) による認証
SASL (RFC 2222) は、POP、IMAP、および SMTP ユーザーアクセスプロトコルの追加認証メカニズムとして機能します。Messaging Server は、以下の表に一覧されているユーザーアクセスプロトコルの SASL をサポートしています。
表 9-3 SASL 認証のユーザーアクセスプロトコルのサポートマトリックス
プレーン
ログイン
CRAM-MD5
Digest-MD5
証明書
APOP
SMTP AUTH
Yes
Yes
Yes
Yes
-
-
POP
Yes
-
Yes
Yes
-
Yes
IMAP
Yes
-
Yes
Yes
-
-
HTTP (Messenger Express)
Yes
-
-
-
Yes
-
SASL を使用する場合、セッションで SSL を使用しなければ、ユーザー名とパスワードは暗号化されません (SSL の詳細については、「SSL による暗号化」を参照)。SASL メカニズム、CRAM-MD5、DIGEST-MD5、および LOGIN は、認証情報を暗号化しますが、情報が捕捉された場合には容易に解読されてしまいます。この制約にもかかわらず、SASL は SMTP AUTH (「Authenticated SMTP を有効にする」を参照) と組み合わせて、システムで認証されたユーザーにだけシステムをリレーしたメール送信を許可できるため、便利なものとして使用されています。たとえば、正当なユーザーが SMTP サーバーへの認証を受けると、SMTP サーバーで別のチャネルへの切り替えを設定できます。このようにすると、認証されたセッションからのメッセージは、認証されていないユーザーとは別の TCP チャネルから送られてくるメッセージとなります。内部ネットワークのユーザーからのメッセージも、受信接続の IP アドレスに基づいて、その他の発信元からのメッセージとは別のチャネルに切り替えできます。
SASL の詳細については、『Sun Java System Messaging Server 管理ガイド』の「セキュリティ設定とアクセス制御」の章を参照してください。
Authenticated SMTP を有効にする
Authenticated SMTP (SMTP AUTH とも呼ばれる) は、SMTP プロトコルを拡張したものです。Authenticated SMTP を使用すると、サーバーへのクライアント認証が可能になります。認証は、メッセージの送受信時に実行されます。Authenticated SMTP の主な用途は、悪用される可能性のあるオープンリレーを作成することなく、オフィス外のローカルユーザーがメールを送信するのを可能にすることです。クライアントは、AUTH コマンドを使用してサーバーに対する認証を行います。
Authenticated SMTP は、SMTP プロトコルによるメッセージの送信をセキュリティで保護します。Authenticated SMTP を使用する場合に、証明書に基づいたインフラストラクチャを用意する必要はありません (証明書による認証については「Secure Sockets Layer (SSL) による証明書ベースの認証」を参照)。
Authenticated SMTP を使用すると、クライアントは認証メカニズムをサーバーに提示し、認証プロトコルの交換を行うことができます。任意で、後続のプロトコル相互対話で使用するセキュリティ層とネゴシエートを行うこともできます。たとえば、メールクライアントが Authenticated SMTP をサポートしている場合は、メッセージの送信前にエンドユーザーにパスワードの入力を要求できます。
メールの送信に SMTP AUTH の使用を要求している場合は、適切なログを記録してメールが悪用されたケースを追跡できます。
Authenticated SMTP の詳細につては、『Sun Java System Messaging Server 管理ガイド』の「MTA」の章を参照してください。
Secure Sockets Layer (SSL) による証明書ベースの認証
Messaging Server は、SSL プロトコルを使用して、暗号化通信とクライアントおよびサーバーの証明書ベースの認証を行います。この節では、証明書ベースの SSL 認証について説明します。SSL 暗号化の詳細については、「SSL による暗号化」を参照してください。
SSL は公開鍵暗号法の概念に基づいています。TLS (Transport Layer Security) は SSL のスーパーセットとして機能しますが、名前が混同されて使われています。
SSL をサポートしているサーバーには、証明書、公開鍵、非公開鍵、証明書、鍵、およびセキュリティデータベースが高レベルで必要となります。これにより、メッセージの認証、機密、完全性が確保されます。
表 9-4 で、各クライアントアクセスプロトコルによる SSL 認証のサポートについて説明します。
SMTP、POP、IMAP、および HTTP プロトコルは、クライアントとサーバーが SSL なしで通信を開始したあと、"start TLS" コマンドを使用して SSL 通信に切り替える方法を提供します。クライアントとサーバーが "start TLS" を実装していない場合は、SMTP、POP、IMAP、および HTTP サーバーが SSL のみを代替ポートで使用するように設定することもできます。
SSL による認証を行うには、メールクライアントはサーバーとの SSL セッションを確立し、ユーザーの証明書をサーバーに提出します。その後、サーバーが、提出された証明書の信頼性を評価します。証明書の信頼性が確認されると、そのユーザーは認証済みであるとみなされます。
SSL を認証用途で使う場合、Messaging Server 用のサーバー証明書を入手する必要があります。この証明書は、使用するサーバーの識別情報をクライアントや他のサーバーに提供します。サーバーには複数のサーバー証明書を用意しておき、証明書自身を識別することができます。サーバーには、信頼できる認証局 (CA) の証明書を必要な数だけインストールして、クライアントの認証に使用できます。
SSL の詳細については、『Sun Java System Messaging Server 管理ガイド』の「セキュリティとアクセス制御」の章を参照してください。
メッセージ暗号化戦略の計画この節では、暗号化とプライバシーソリューションについて説明します。以下のトピックについて説明しています。
SSL による暗号化
SSL は、IMAP、HTTP、および SMTP のアプリケーションレイヤの下のプロトコルレイヤとして機能します。Messaging Server とそのクライアント間、および Messaging Server と他のサーバー間におけるメッセージの転送が暗号化される場合は、通信が盗聴される危険性はほとんどありません。また、接続しているクライアントとサーバーが認証済みの場合は、侵入者がそれらのクライアントになりすます (スプーフィングする) 危険性もほとんどありません。
メッセージ送信でエンドツーエンドの暗号化を行うには、SSL を SMTP、IMAP、および HTTP プロトコルとともに使用する必要があります。
HTTP/SSL (HTTPS) を使用したクライアントとサーバー間の SSL 接続プロセスは、以下のようになります。
SSL 符号化方式
符号化方式とは、暗号化プロセスでデータの暗号化と解読に使用されるアルゴリズムのことです。各符号化方式によって強度が異なります。つまり、強度の高い符号化方式で暗号化したメッセージほど、承認されていないユーザーによる解読が困難になります。
符号化方式では、キーをデータに適用することによってデータを操作します。一般的に、符号化方式で使用するキーが長いほど、適切な解読キーを使わずにデータを解読することが難しくなります。
クライアントは、Messaging Server と SSL 接続を開始するときに、サーバーに対して、希望する暗号化用の符号化方式とキー長を伝えます。暗号化された通信では、両方の通信者が同じ符号化方式を使用する必要があります。一般的に使用される符号化方式とキーの組み合わせは数多くあります。そのため、サーバーが柔軟な暗号化方式をサポートしている必要があります。符号化方式の詳細については、『Sun Java System Messaging Server 管理ガイド』の「セキュリティ設定とアクセス制御」の章を参照してください。
署名され暗号化された S/MIME
署名され、暗号化されたメッセージは、Secure/Multipurpose Internet Mail Extensions (S/MIME) メッセージと呼ばれます。S/MIME は、クライアント間の通信をセキュリティで保護する手段です
S/MIME を使用すると、送信者は送信する前にメッセージを暗号化できます。受信者は、受信した暗号化されたメッセージを保存し、あとで読むときだけそれを解読することができます。S/MIME を使用するのに Messaging Server で特別な設定やタスクは必要ありません。これは完全にクライアントによる動作となります。これは SSL とは異なり、エンドツーエンドの暗号化機能を提供します。S/MIME の設定の詳細については、クライアントのマニュアルを参照してください。
セキュリティに関する誤解この節では、配備のセキュリティニーズに対して逆効果になる、メッセージングに関する典型的な誤解について説明します。
製品名とバージョン名を隠したとしても、せいぜい通常のアタッカーの邪魔をする程度です。最悪の場合は、管理者にセキュリティに関する誤った感覚を与えることになり、本当のセキュリティ問題の追跡を怠るという結果になりかねません。
事実、製品情報とバージョン番号が削除されると、ソフトウェアの識別ができなくなるため、ベンダーのサポート部門がソフトウェアの問題を検証するのが困難となります。
ハッカーが入念な行動を取ることはほとんどありません。特に、SMTP サーバーの既知の脆弱性を攻撃するときには、あらゆる SMTP サーバーにアクセスを試みます。
製品名やバージョン番号を隠されても、知識があれば、プロトコルの動きに注目して、ベンダー名とバージョンを判断することもできます。
その他のセキュリティリソースセキュリティで保護されたメッセージング配備の詳細については、Computer Emergency Response Team (CERT) Coordination Center のサイトを参照してください。
