Sun Java System Communications Services 6 2005Q4 配備計画ガイド

第 13 章 Messaging Server セキュリティーの計画

この章では、Messaging Server 配備のさまざまなコンポーネントに対する計画を立案し、それらのコンポーネントを保護する方法について説明します。

この章には、次の節があります。

配備におけるメッセージングコンポーネントの保護

この節では、メッセージング配備でコンポーネントをセキュリティーで保護する方法について説明します。

注 –

それぞれのコンポーネントで、chroot 機能を使用して、各マシンで使用できるコマンドの数を制限します。

MTA の保護

MTA をセキュリティーで保護し、処理リソースやサーバー可用性を保護します。権限を持たないユーザーからメッセージがリレーされた場合、または大量のスパムが配信された場合には、応答速度が遅くなり、ディスク容量が圧迫され、エンドユーザーのための処理リソースが消費されます。スパムはサーバーのリソースを浪費するだけでなく、エンドユーザーを煩わせるものでもあります。

注 –

権限を持たない外部のユーザーから配備を保護するだけでなく、内部ユーザーからシステムを保護する必要もあります。

次の表で、MTA に対する最も一般的な脅威について説明します。

表 13–1 MTA に対する一般的なセキュリティー脅威


脅威	説明
UBE (Unsolicited Bulk Email) またはスパム	多数のユーザーに迷惑メールを送りつける行為のことを言います。
不正なリレー	別の会社の SMTP サーバーを使用してメールをリレーします。スパムの送信者は、証拠を残さないようにするためにこのテクニックを多用します。エンドユーザーは、スパム送信者ではなく、送信したリレーにクレームをつけていることもあります。
メール爆弾	同じメッセージを特定のアドレスに繰り返し送るような行為。大量のメッセージにより、メールボックスの容量を超過させるのが狙いです。
電子メールスプーフィング	別の発信元からの電子メールを、ある発信元からのものにみせかけます。
サービス拒否攻撃	あるサービスの正規ユーザーがそのサービスを利用できないようにします。たとえば、攻撃者がネットワークを占有し、正規のユーザーのトラフィックを妨害します。

MTA リレーに関するこの節では、配備で使用できるセキュリティーオプションについて説明します。

アクセス制御

アクセス制御を使用して、特定のユーザーから (へ) のメッセージをシステムレベルで拒否できます。また、特定のユーザー間でより複雑なメッセージトラフィックの制限を構成することもできます。さらに、ユーザーに独自の受信メッセージのフィルタ設定を許可し、メッセージヘッダの内容に基づいてメッセージを拒否することなどができます。

エンベロープレベルでアクセス制御を行うときは、マッピングテーブルを使用してメールのフィルタリングを行います。ヘッダベースでアクセス制御を行う場合、またはユーザー独自の制御を行う場合は、サーバー側の規則とともに一般的なメールボックスフィルタを使用します。

マッピングテーブルの概要

特定の「マッピングテーブル」を設定することにより、メールサービスへのアクセスを制御できます。MTA の多くのコンポーネントでは、テーブル検索指向の情報を利用しています。この種類のテーブルは、変換、すなわち入力文字列を出力文字列へ「マップ」するのに使用されます。マッピングテーブルは通常、2 つの列として表示されます。1 列目 (左側) には、マッチングの対象となる可能性のある入力文字列 (パターン)、2 列目 (右側) には入力文字列のマッピングの結果である出力文字列 (テンプレート) が表示されます。

次の表で、マッピングテーブルの使用により、だれがメールを送信または受信できるのか、あるいは送受信ともにできるのかを制御する方法を説明します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

表 13–2 アクセス制御マッピングテーブル


マッピングテーブル	説明
`SEND_ACCESS`	エンベロープ `From:` アドレス、エンベロープ `To:` アドレス、ソースおよび送信先チャネルに基づいて、着信接続をブロックする場合に使用します。書き換え、エイリアスの展開などが実行されたあとで `To:` アドレスが調べられます。
`ORIG_SEND_ACCESS`	エンベロープ `From:` アドレス、エンベロープ `To:` アドレス、ソースおよび送信先チャネルに基づいて、着信接続をブロックする場合に使用します。 `To:` アドレスは、書き換えのあとに、しかしエイリアスの展開より先に調べられます。
`MAIL_ACCESS`	`SEND_ACCESS` および `PORT_ACCESS` の各テーブル内の情報の組み合わせに基づいて着信接続をブロックするために使用します。`SEND_ACCESS` 内のチャネルおよびアドレス情報と、`PORT_ACCESS` 内の IP アドレスおよびポート番号情報を組み合わせた情報が基準となります。
`ORIG_MAIL_ACCESS`	`ORIG_SEND_ACCESS` および `PORT_ACCESS` の各テーブル内の情報の組み合わせに基づいて着信接続をブロックするために使用します。`ORIG_SEND_ACCESS` 内のチャネルおよびアドレス情報と、`PORT_ACCESS` 内の IP アドレスおよびポート番号情報を組み合わせた情報が基準となります。
`FROM_ACCESS`	エンベロープ `From:` アドレスに基づいてメールをフィルタリングする場合に使用します。このテーブルは、`To:` アドレスが不適切な場合に使用します。
`PORT_ACCESS`	IP 番号に基づいて着信接続をブロックする場合に使用します。

図 13–1 は、メール受信プロセスの中でマッピングテーブルが使用される場所を示したものです。

図 13–1 マッピングテーブルとメール受信プロセス

この図は、メール受信プロセスの中で pre-SMTP accept フィルタリングがどのように使用されるかを示したものです。

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 リレー操作が防止されます。「認証された SMTP を有効にする」で説明しているように、クライアントが SMTP AUTH を使用して認証せず、Messaging Server の SMTP サーバーを介して外部アドレスにメッセージを送信しようとした場合、その送信は拒否されます。このため、内部システムとリレーを許可するサブネットを認識するように設定を変更した方がよいでしょう。

外部ホストからのリレーを防止するには

ドメイン外にあるホストからドメイン外の別のホストにメッセージがリレーされるのを防ぐには、次の方法を取ります。

手順

受信メールをいくつかのチャネルに分けます。例:
- ドメイン内の IP アドレスは tcp_internal チャネルに送られます。
- 認証されたセッションは tcp_auth チャネルに送られます。
- その他のすべてのメールは、tcp_local チャネルに送られます。

『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の「メールのフィルタリングとアクセス制御」の章で詳しく説明されているように、INTERNAL_IP マッピングテーブルを使用して、POP クライアントと IMAP クライアントからのメールを識別し、処理を許可します。

メールボックスフィルタの使用

フィルタは、メッセージに適用される 1 つ以上の条件付き処理で構成されています。Messaging Server フィルタはサーバーに保存され、サーバーによって評価されます。そのため、それらはサーバー側規則 (SSR) と呼ばれることもあります。

チャネルレベルのフィルタと MTA 全体のフィルタを作成し、不正メールの配信を防止できます。また、フィルタテンプレートを作成し、Messenger Express を使用してそれをエンドユーザーに使わせることもできます。エンドユーザーはテンプレートを使用して個人のメールボックスフィルタを構築し、不要なメールメッセージが自分のメールボックスに配送されないようにすることができます。サーバーは、次の優先順位に従ってフィルタを適用します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

ユーザー単位のフィルタ

ユーザー単位のフィルタは、特定ユーザーのメールボックスに送信されるメッセージに適用されます。フィルタテンプレートを作成し、Messenger Express クライアントを使用してそれをエンドユーザーに使わせることができます。エンドユーザーはテンプレートを使用して個人のサーバーフィルタを構築し、自分のメールボックスへのメールメッセージの配送を管理できます。フィルタにより、不要なメッセージ、リダイレクトメールなどの拒否や、メールボックスフォルダに配信されるメッセージのフィルタリングなどが行われます。

個人用メールボックスフィルタにメッセージの許可あるいは拒否が定義されている場合は、メッセージに対してそのフィルタ処理が行われます。

フィルタテンプレートは、Sieve スクリプトの「ハードコード」された要素をプロンプトと入力フィールドに置き換えることで、Sieve スクリプトを一般化します。Java サーブレットは、Sieve テンプレートを解析し、ブラウザ内でユーザーインタフェースを生成するのに使用されます。エンドユーザーが入力フィールドに値を入力すると、サーブレットがその値を取得して、ユーザーのディレクトリにあるプロファイルエントリ内の Sieve スクリプトに保存します。Messenger Express インタフェースを通じて、プロンプトと入力フィールドがエンドユーザーに提示されます。

しかし、受取人がメールボックスフィルタを設定していない場合、またはユーザーのメールボックスフィルタが明示的に適用されないメッセージの場合、Messaging Server によってチャネルレベルのフィルタが適用されます。
チャネルレベルのフィルタ

 チャネルレベルのフィルタは、チャネルのキューに入った各メッセージに適用されます。この種のフィルタの一般的な用途は、特定のチャネルから入ってくるメッセージをブロックすることです。

チャネルレベルのフィルタを作成するには、Sieve を使用してフィルタを書く必要があります。Sieve を使用してフィルタを作成する場合の指示の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

チャネルレベルのフィルタにメッセージの許可あるいは拒否が定義されている場合は、メッセージに対してそのフィルタ処理が行われます。それ以外の場合は、Messaging Server によって MTA 全体のフィルタが適用されます (該当する場合)。
MTA 全体のフィルタ

 MTA 全体のフィルタは、MTA のキューに入るすべてのメッセージに適用されます。この種のフィルタの一般的な用途は、メッセージの送信先とは関係なく、ダイレクトメールや受信したくないメッセージをブロックすることです。

MTA 全体のフィルタを作成するには、Sieve を使用してフィルタを書く必要があります。Sieve を使用してフィルタを作成する場合の指示の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

デフォルト設定を使用した場合、それぞれのユーザーはメールボックスフィルタを所有していません。ユーザーが Messenger Express インタフェースにアクセスして 1 つまたは複数のフィルタを作成すると、そのフィルタが LDAP ディレクトリに保存されます。

変換チャネルとサードパーティーのフィルタリングツール

変換チャネルは、MTA を通じて配信されるメッセージを本文部分ごとに変換します。この処理は、サイトで提供されるプログラムかコマンドにより行われます。変換チャネルは、テキストや画像のフォーマット変換、ウイルスのスキャン、言語の変換などを行うことができます。MTA で通信するさまざまなメッセージ形式を変換することができ、特定の処理やプログラムをメッセージの本文部分に指定することができます。変換チャネルをウイルススキャニングプログラムと併用する場合は、ウイルスの除去、メッセージの保留または拒否を選択できます。特別な変換チャネル設定を使用すると、それぞれのメッセージ本文に対する適切な変換を選択できます。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 13 章「定義済みチャネルを使用する」を参照してください。

注 –

変換チャネルのような特別な処理を行うと、システムに余分の負荷がかかります。戦略のサイズを検討する場合には、この点を考慮してください。

変換チャネルを使用すると、サードパーティーのスパム防止およびウイルス対策ソフトウェアソリューションを利用できます。また、MTA API を使用してチャネルを作成し、リモートスキャニングエンジンを起動することもできます。MTA API の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

一般に、サードパーティーのソリューションは外部サイトから保護して、バックエンドまたは中間のリレーのみで使用するのが最も適した使い方です。

Brightmail ソリューションは、Brightmail サーバーと、リアルタイムのスパム防止およびウイルス対策 (サービスプロバイダ向けのみ) 規則アップデートで構成されており、規則はメッセージングサーバーにダウンロードされます。Brightmail Logistics and Operations Center (BLOC) が電子メールプローブからスパムを受信すると、オペレータがただちに適切なスパム防止規則を作成します。次に、これらの規則が Brightmail カスタママシンにダウンロードされます。同様に、Symantec Security Response のリアルタイムのウイルス規則が Brightmail から送信されます。これらの規則は顧客の Brightmail サーバーでスパムやウイルスを検出するために使用されます。

Messaging Server では、SpamAssassin の使用もサポートされています。SpamAssassin はフリーウェアのメールフィルタで、スパムの特定に使用されます。SpamAssassin では、すべてのメッセージのスコアが計算されます。スコアは、メッセージヘッダーや本文の情報に対して一連のテストを実行することによって計算されます。各テストに成功するか失敗するかによってスコアは調整されます。スコアは正または負の実数です。スコアが一定のしきい値を超えると、スパムであるとみなされます。

Brightmail および SpamAssassin の Messaging Server に対する設定の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 14 章「スパムとウィルスのフィルタ処理プログラムを Messaging Server に統合する」を参照してください。

RBL チェック

Mail Abuse Protection System の Real-time Blackhole List (MAPS RBL) は、スパムの発信やリレーを行なったり、スパムのサポートサービスを提供したりしてホストやネットワークを悪用している者に好意的、あるいは中立的な立場を取っていると判断されたホストとネットワークのリストです。

外部からの MAPS RBL に対する接続の比較を行うように、MTA を設定することができます。また、DNS ベースのデータベースを使用して、不特定多数宛のメールを送る可能性のある受信 SMTP 接続を判別できます。

詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

クライアントアクセスの制御

Messaging Server は、POP、IMAP、および HTTP について、サービスごとの高度なアクセス制御機能をサポートしています。Messaging Server のアクセス制御機能は、TCP デーモンと同じポートで待機するプログラムです。アクセス制御機能では、アクセスフィルタによるクライアントの識別情報の検証が行われ、そのクライアントがフィルタリング処理を通過した場合は、デーモンへのアクセスが許可されます。

大企業やサービスプロバイダのメッセージングサービスを管理する場合、これらの機能を使用して、スパム (大量メール送信) や DNS スプーフィングを行うユーザーをシステムから除外したり、ネットワークの全般的なセキュリティーを強化したりできます。

Messaging Server の TCP クライアントアクセス制御システムは、必要な場合、その処理の一部として、次のようなソケットの終端アドレスの分析を行います。

両方の終端の逆引き DNS 検索 (名前に基づくアクセス制御を行うため)
両方の終端の正引き DNS 検索 (DNS スプーフィングを検出するため)
Identd コールバック (クライアントエンドのユーザーがクライアントホストに認識されていることを調べるため)

システムは、この情報を「フィルタ」と呼ばれるアクセス制御文と比較して、アクセスの許可または拒否を決定します。サービスごとに、個別の許可フィルタと拒否フィルタのセットを使用して、アクセスを制御します。許可フィルタは明示的にアクセスを許可し、拒否フィルタは明示的にアクセスを禁止します。

クライアントがサービスへのアクセスを要求すると、アクセス制御システムは、そのクライアントのアドレスまたは名前情報を、次の条件を使用して順番に対象のサービスのフィルタと比較します。

検索は、最初の一致項目が見つかった時点で終了する。許可フィルタは、拒否フィルタより先に処理されるため、許可フィルタが優先される。
クライアント情報が対象のサービスの許可フィルタに一致した場合は、アクセスが許可される。
クライアント情報がそのサービスの拒否フィルタに一致した場合は、アクセスが拒否される。
どの許可または拒否フィルタにも一致しなかった場合、アクセスが許可される。例外は、許可フィルタは存在しているが拒否フィルタが存在しない場合で、その場合にはフィルタに一致しなかったアクセスは拒否される。

ここで説明するフィルタの構文は柔軟性に富んでいるため、わかりやすい簡単な方法で、さまざまなアクセス制御ポリシーを実装できます。許可フィルタと拒否フィルタは自由に組み合わせて使用できますが、大半のアクセスを許可するフィルタまたは大半のアクセスを拒否するフィルタを使用すると、ほとんどのポリシーを実装できます。

クライアントアクセスフィルタは、問題のあるドメインの数が把握できる場合に特に有効です。UBE の場合、Messaging Server はすべてのスパムメッセージを格納し処理する必要がありますが、クライアントアクセスフィルタの場合はスパムメッセージを処理する必要がありません。クライアントアクセスフィルタはドメイン全体からのメールをブロックするため、この機能は慎重に使用する必要があります。

クライアントアクセスフィルタには、次の制限があります。

メッセージをリレーする前に、SMTP クライアントがログインする必要があります。
クライアントアクセスフィルタは、大規模な配備には向いていません。

クライアントアクセスフィルタの詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。

セキュリティー戦略の監視

サーバーの監視は、セキュリティー戦略で重要な位置を占めます。システムに対する攻撃を識別するには、メッセージキューのサイズ、CPU の使用率、ディスクの空き容量、ネットワークの使用率を監視します。メッセージキューのサイズが異常に大きくなったり、サーバーの応答時間が長くなったりするのは、MTA リレーへの攻撃の可能性があります。また、通常とは異なるシステムの負荷パターンや接続についても調査します。ログを毎日チェックして、異常な活動がないか調べます。

メッセージストアの保護

メッセージングサーバーで最も重要なデータは、メッセージストア内のユーザーのメールです。メールメッセージは、暗号化されない個別のファイルとして格納されることに留意してください。したがって、物理的なアクセスや root アクセスからメッセージストアを保護する必要があります。

メッセージストアをセキュリティーで保護するには、ストアがインストールされているマシンへのアクセスを制限します。暗号化されないプレーンテキストのパスワードの代わりに、CRAM-MD5 パスワードまたは Digest-MD5 パスワードを使用できます。パスワードの詳細については、「メッセージングユーザー認証の計画」を参照してください。

ストアマシンの認証にパスワードを作成するだけでなく、VPN アクセス、ssh、または pam のような、マシンへのログインが許可された有効なユーザーを一覧表示するツールを使用することもあります。

また、1 層のアーキテクチャーよりも 2 層のアーキテクチャーをお勧めします。メッセージストアは、メッセージングシステムのコンポーネント中で最もディスクに負担をかける作業を行うため、フィルタリング、ウイルススキャニング、およびその他のディスクに負担をかけるセキュリティー処理を同じマシンで行わないようにします。2 層のアーキテクチャーでは、システムに余分な負荷がかかるメッセージストアと同じマシンで UBE フィルタ、リレー防止機能、およびクライアントアクセスフィルタを使用せずにすみます。代わりに、MTA がその処理を行います。さらに、ストアへのユーザーアクセスが 2 階層配備の MMP または MEM により制限され、実質的にメッセージストアにセキュリティー層を追加したことになります。

1 層のアーキテクチャーで配備を行う場合は、セキュリティー処理の追加と、SSL やウイルススキャニングなどに必要となる負荷を考慮してください。詳細については、第 10 章「Messaging Server サイズ決定戦略の計画」を参照してください。

メッセージストアにセキュリティー処理を追加する場合は、ユーザーごとにディスク割り当てを行なって、ディスクの使用率を制限します。また、空き容量が制限に近づいたときには管理アラームを出すようにします。さらに、MTA の場合と同様に、サーバーの状態、ディスク容量、サービスの応答時間を監視します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 18 章「メッセージストアを管理する」を参照してください。

MMP と MEM の保護

MMP はメッセージストアのプロキシとして機能するため、エンドユーザーデータへのアクセスを防ぎ、権限のないアクセスから保護する必要があります。ユーザー ID とパスワードは、基本的な認証機能となります。さらに、クライアントアクセスフィルタを使用すれば、ユーザーが特定のドメインや特定の IP アドレスの範囲にアクセスするのを制限できます。SMTP リレーサーバーのセキュリティーを提供する方法としては、SMTP 認証または SMTP AUTH (RFC 2554) をお勧めします。SMTP AUTH は、認証済みのユーザーだけに MTA を介したメール送信を許可します。詳細については、「認証された SMTP を有効にする」を参照してください。

POP サービスまたは IMAP サービスの前に、MMP を別のマシンまたは別のユーザー ID のもとに配置します。フロントエンドマシンには MMP と MTA のみを配置してから、フロントエンドマシン、メールストア、および LDAP サーバー間で、物理的にセキュリティー保護されたネットワークを構築できます。

ユーザーがインターネットからログインする場合は、Messenger Express からメッセージストアへのアクセスのセキュリティーには特に配慮が必要となります。一般的には、ストアはファイアウォールにより外部と分離します。さらに、HTTP アクセスサービスへの単一の接続ポイントとして機能する特別なサーバーとして、Messenger Express マルチプレクサ (MEM) を使用することも考えられます。MMP と同様に、MEM は、メールクライアントとの間で、暗号化されていない通信と暗号化された (SSL) 通信の両方をサポートしています。MEM は、エンドユーザーデータへのアクセスと権限のないアクセスからの保護も行う必要があります。

ログファイルを定期的に監視することで、権限のないアクセスを防ぐことができます。

メッセージングユーザー認証の計画

ユーザー認証を行うことで、ユーザーはメールクライアントへのログインとメールメッセージの取得が可能になります。ユーザー認証の方法には次のものがあります。

プレーンテキストと暗号化されたパスワードによるログイン

ユーザー ID とパスワードは、LDAP ディレクトリに保存されます。最低限必要な長さなど、パスワードのセキュリティー基準は、ディレクトリポリシー要件によって決定されます。パスワードのセキュリティー基準は、Messaging Server 管理の一部ではありません。ディレクトリサーバーのパスワードポリシーについては、『Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide』を参照してください。

管理者は、メッセージング設定パラメータを設定して、プレーンテキストのパスワードを許可するかどうか、パスワードの暗号化を必須とするかどうかを決めることができます。詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の service.xxx.plaintextminciper パラメータ (xxx は http、pop、imap のいずれか) を参照してください。

プレーンテキストによるログインと暗号化されたパスワードによるログインは、どちらも POP、IMAP、および Messenger Express ユーザーアクセスプロトコルで使用できます。

Simple Authentication and Security Layer (SASL) による認証

SASL (RFC 2222) は、POP、IMAP、および SMTP ユーザーアクセスプロトコルの追加認証メカニズムとして機能します。Messaging Server は、表 13–3 に一覧表示されているユーザーアクセスプロトコルの SASL をサポートしています。

表 13–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	-

注 –

CRAM-MD5 を使用する場合は、パスワードをプレーンテキスト形式で LDAP ディレクトリサーバーに保存する必要があります。
Digest-MD5 は MMP ではまだサポートされていませんが、MMP を使用しないようにすればサポートされます。
POP を使用する場合は、パスワードをプレーンテキストで LDAP ディレクトリサーバーに保存する必要があります。

SASL を使用する場合、セッションで SSL を使用しないと、ユーザー名とパスワードは暗号化されません。SSL の詳細については、「SSL による暗号化」を参照してください。SASL メカニズム、PLAIN および LOGIN は、認証情報を復号化しますが、情報が捕捉された場合には容易に解読されてしまいます。このような限界があるにもかかわらず、SASL は SMTP AUTH (「認証された SMTP を有効にする」を参照) と組み合わせて、システムで認証されたユーザーにだけシステムを経由したメールのリレーを許可できるため、便利です。たとえば、正当なユーザーが SMTP サーバーへの認証を受けると、SMTP サーバーで別のチャネルへの切り替えを設定できます。このようにすると、認証されたセッションからのメッセージは、認証されていないユーザーとは別の TCP チャネルから送られてくるメッセージとなります。内部ネットワークのユーザーからのメッセージも、着信接続の IP アドレスに基づいて、その他の発信元からのメッセージとは別のチャネルに切り替えできます。

SASL の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。

認証された SMTP を有効にする

デフォルトでは、ユーザーは、メッセージ送信時に Messaging Server の SMTP サービスに接続する際に、パスワードを送信する必要はありません。ただし、SMTP へのパスワードログインを有効にすれば、認証された SMTP を使用できるようになります。

認証された SMTP (SMTP AUTH とも呼ばれる) は、SMTP プロトコルを拡張したものです。認証された SMTP を使用すると、サーバーへのクライアント認証が可能になります。認証は、メッセージの送受信時に実行されます。認証された SMTP の主な用途は、悪用される可能性のあるオープンリレーを作成することなく、オフィス外のローカルユーザーがメールを送信するのを可能にすることです。クライアントは、AUTH コマンドを使用してサーバーに対する認証を行います。

認証された SMTP は、SMTP プロトコルによるメッセージの送信をセキュリティーで保護します。認証された SMTP を使用する場合に、証明書に基づいたインフラストラクチャーを用意する必要はありません。証明書による認証については、「Secure Sockets Layer (SSL) による証明書ベースの認証」を参照してください。

認証された SMTP を使用すると、クライアントは認証メカニズムをサーバーに提示し、認証プロトコルの交換を行うことができます。さらに任意で、後続のプロトコル相互対話で使用するセキュリティー層とネゴシエーションを行うこともできます。

メールの送信に SMTP AUTH の使用を要求している場合は、適切なログを記録してメールが悪用されたケースを追跡できます。

認証された SMTP の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の MTA に関する章を参照してください。

Secure Sockets Layer (SSL) による証明書ベースの認証

Messaging Server は、SSL プロトコルを使用して、暗号化通信とクライアントおよびサーバーの証明書ベースの認証を行います。この節では、証明書ベースの SSL 認証について説明します。SSL 暗号化の詳細については、「SSL による暗号化」を参照してください。

SSL は公開鍵暗号法の概念に基づいています。TLS (Transport Layer Security) は SSL のスーパーセットとして機能しますが、名前が混同されて使われています。

SSL をサポートしているサーバーには、証明書、公開鍵、非公開鍵、証明書、鍵、およびセキュリティーデータベースが高レベルで必要となります。これにより、メッセージの認証、機密、完全性が確保されます。

表 13–4 で、各クライアントアクセスプロトコルによる SSL 認証のサポートについて説明します。

表 13–4 SSL 認証のサポートマトリックス


	MMP による SSL	代替ポートでの MMP による SSL	SSL	代替ポートでの SSL
SMTP	Yes	Yes	Yes	Yes
POP	-	Yes	-	Yes
IMAP	Yes	Yes	-	Yes
Messenger Express (HTTP)	Yes (Messenger Express マルチプレクサによる)	Yes (Messenger Express マルチプレクサによる)	-	Yes

SMTP、POP、および IMAP プロトコルは、クライアントとサーバーが SSL なしで通信を開始したあと、"start TLS" と同等のコマンドを使用して SSL 通信に切り替える方法を提供します。"start TLS" を実装していないクライアントの場合は、SMTP、POP、および IMAP サーバーが SSL を代替ポートで使用するように設定することもできます。

SSL による認証を行うには、メールクライアントはサーバーとの SSL セッションを確立し、ユーザーの証明書をサーバーに提出します。サーバーは、提出された証明書が本物であるかどうかを評価します。証明書の信頼性が確認されると、そのユーザーは認証済みであるとみなされます。

SSL を認証用途で使う場合、Messaging Server 用のサーバー証明書を入手する必要があります。この証明書は、クライアントやほかのサーバーに対して、そのユーザーのサーバーを特定します。サーバーは、クライアントの認証に使用する、信頼できる認証局 (CA) の証明書をいくつでも持つことができます。

SSL の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。

メッセージ暗号化戦略の計画

この節では、暗号化とプライバシーソリューションについて説明します。次のトピックについて説明しています。

SSL による暗号化

SSL は、IMAP、HTTP、および SMTP のアプリケーション層の下のプロトコル層として機能します。Messaging Server とそのクライアント間、および Messaging Server とほかのサーバー間におけるメッセージの転送が暗号化される場合は、通信が盗聴される危険性はほとんどありません。また、接続しているクライアントとサーバーが認証済みの場合は、侵入者がそれらのクライアントになりすます (スプーフィングする) 危険性もほとんどありません。

メッセージ送信でエンドツーエンドの暗号化を行うには、S/MIME を使用する必要があります。詳細については、「署名され暗号化された S/MIME」を参照してください。

注 –

SSL 接続の設定によりパフォーマンスのオーバーヘッドが生じると、サーバーへの負担となります。メッセージングシステムの設計とパフォーマンスの分析を行う際には、セキュリティー要件とサーバーの容量のバランスをとる必要があります。

暗号化の用途で SSL を使用する場合は、ハードウェア暗号化アクセラレータをインストールすることでサーバーのパフォーマンスを向上させることができます。一般的に、暗号化アクセラレータは、サーバーマシンに常設されたハードウェアボードとソフトウェアドライバで構成されます。

HTTP/SSL (HTTPS) を使用したクライアントとサーバー間の SSL 接続プロセスは、次のようになります。

クライアントが HTTPS を使用して接続を開始します。クライアントが、使用する秘密鍵アルゴリズムを指定します。
サーバーが認証のための証明書を送り、使用する秘密鍵アルゴリズムを指定します。クライアントと共通の最も強力なアルゴリズムが指定されます。秘密鍵が一致しない場合 (たとえば、クライアントの鍵が 40 ビットのみで、サーバーが 128 ビットの鍵を要求している場合)、その接続は拒否されます。
サーバーがクライアント認証を要求するように設定されている場合、この時点でクライアントに証明書が要求されます。
クライアントは、サーバーの証明書の正当性をチェックし、次の内容を確認します。
- 期限が切れていない
- 既知の署名された認証局
- 有効な署名
- 証明書のホスト名が HTTPS 要求のサーバーのホスト名と一致している

SSL 暗号化方式

暗号化方式とは、暗号化プロセスでデータの暗号化と復号化に使用されるアルゴリズムのことです。各暗号化方式によって強度が異なります。つまり、強度の高い暗号化方式で暗号化されたメッセージほど、承認されていないユーザーによる解読が困難になります。

暗号化方式では、キーをデータに適用することによってデータを操作します。一般的に、暗号化方式で使用するキーが長いほど、適切な解読キーを使わずにデータを解読することが難しくなります。

クライアントは、Messaging Server と SSL 接続を開始するときに、サーバーに対して、希望する暗号化用の暗号化方式とキー長を伝えます。暗号化された通信では、両方の通信者が同じ暗号化方式を使用する必要があります。一般的に使用される暗号化方式とキーの組み合わせは数多くあります。そのため、サーバーが柔軟な暗号化方式をサポートしている必要があります。暗号化方式の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。

署名され暗号化された S/MIME

署名され、暗号化されたメッセージは、Secure/Multipurpose Internet Mail Extensions (S/MIME) メッセージと呼ばれます。S/MIME は、クライアント間の通信をセキュリティーで保護する手段です。

S/MIME を使用すると、送信者は送信する前にメッセージを暗号化できます。受信者は、受信した暗号化されたメッセージを保存し、あとで読むときだけそれを解読することができます。

Communications Express Mail に S/MIME のセキュリティー機能が追加されました。S/MIME を使用するように設定された Communications Express Mail ユーザーは、ほかの Communications Express Mail ユーザーや、Microsoft Outlook メールシステムなどの S/MIME をサポートするメールクライアントのユーザーと、署名または暗号化されたメッセージを交換できます。詳細については、「Communications Express メールで S/MIME を使用するための要件」を参照してください。

S/MIME をサポートするその他のクライアントについては、各クライアントのマニュアルで S/MIME の設定方法を確認してください。