|
| |
| Sun Java System Messaging Server 6 2004Q2 管理ガイド | |
第 19 章
セキュリティとアクセス制御を設定するMessaging Server は、広範囲にわたる柔軟なセキュリティ機能をサポートします。これらの機能を使用して、メッセージが横取りされないようにしたり、侵入者がユーザーや管理者になりすますことを防いだり、メッセージングシステム内の特定部分へのアクセスを特定のユーザーだけに許可したりできます。
Messaging Server のセキュリティアーキテクチャは、Sun Java System サーバーのセキュリティアーキテクチャ全体の一部です。このアーキテクチャは、最大の相互運用性と一貫性を実現するために業界標準と公開プロトコルに基づいて構築されています。そのため、Messaging Server のセキュリティポリシーを実装するには、この章だけでなく他のドキュメントも参照する必要があります。特に、『Sun ONE Server Console 5.2 Server Management Guide』には、Messaging Server のセキュリティを設定するために必要な情報が記載されています。
この章には、以下の節があります。
サーバーのセキュリティについてサーバーのセキュリティには広範囲にわたる説明が含まれます。ほとんどの企業では、承認されたユーザーだけがサーバーにアクセスできること、パスワードや識別情報が安全なこと、他のユーザーになりすました通信ができないこと、必要に応じて通信の機密性を確保できることなどがすべてメッセージングシステムの重要な要件になります。
サーバーのセキュリティはさまざまな方法で攻撃される可能性があるため、さまざまな方法でセキュリティを強化します。この章では、暗号化、認証、アクセス制御の設定に重点を置きます。この章で説明する Messaging Server のセキュリティ関連の内容は、次のとおりです。
- ユーザー ID とパスワードログイン : ユーザーは、IMAP、POP、HTTP、または SMTP にログインするためにユーザー ID とパスワードを入力する必要があります。また、メッセージの受取人に差出人の認証情報を送信するには、SMTP パスワードログインを使用する必要があります。
- 暗号化と認証 : TLS プロトコルおよび SSL プロトコルを使用して通信を暗号化し、クライアントを認証するようにサーバーを設定します。
- 管理者のアクセス制御 : コンソールのアクセス制御機能を使って、Messaging Server へのアクセス権や個別のタスクを委任します。
- TCP クライアントアクセス制御 : フィルタリング技術を使用して、サーバーの POP、IMAP、HTTP、および 認証済み SMTP サービスに接続できるクライアントを制御します。
この章では、Messaging Server に関連するすべてのセキュリティとアクセスの問題について説明するわけではありません。この章で説明していないセキュリティ関連の項目として、以下のものがあります。
- 物理的なセキュリティ : サーバーマシンを物理的に保護しないと、ソフトウェアのセキュリティは意味を持たない場合があります。
- メッセージストアへのアクセス : Messaging Server に対して、複数のメッセージストア管理者を定義できます。これらの管理者は、メールボックスの表示と監視を行ったり、メールボックスへのアクセスを制御したりできます。詳細は、第 18 章「メッセージストアを管理する」を参照してください。
- エンドユーザーアカウントの設定 : エンドユーザーアカウント情報は、主に Delegated Administrator 製品を使って管理できます (Sun LDAP Schema 1 の場合のみ有効)。また、コンソールのインタフェースを使ってエンドユーザーアカウントを管理することもできます。
- 不特定多数宛メール (UBE) のフィルタリング : 第 17 章「メールのフィルタリングとアクセス制御」を参照してください。
セキュリティに関するさまざまな説明を含んだ数多くのマニュアルがあります。この章に記載した内容の背景情報や、その他のセキュリティ関連情報については、文書 Web サイト (http://docs.sun.com) を参照してください。
HTTP のセキュリティについてMessaging Server は、ユーザー ID およびパスワード認証、クライアント証明書認証、および Identity Server をサポートしています。ただし、クライアントとサーバー間におけるネットワーク接続の処理方法は、この 2 つのプロトコルでいくつか異なります。
POP、IMAP、または SMTP クライアントが Messaging Server にログインすると、接続が確立され、セッションが開始されます。この接続は、セッションの間中、すなわちログインからログアウトまで維持されます。新しい接続を確立する場合は、クライアントが再びサーバーで認証される必要があります。
HTTP クライアントが Messaging Server にログインする場合は、サーバーからクライアントに固有のセッション ID が与えられます。クライアントは、このセッション ID を使って、セッション中に複数の接続を確立できます。HTTP クライアントは接続するたびに再認証を行う必要はありません。ただし、セッションが切断された場合やクライアントが新しいセッションを確率する必要がある場合だけは、クライアントが、再び認証を行う必要があります。指定した時間にわたり HTTP セッションのアイドル状態が続くと、サーバーは自動的に HTTP セッションを切断し、クライアントがログアウトされます。デフォルトの時間は 2 時間です。
HTTP セッションのセキュリティを向上させるには、以下の方法を使用します。
設定パラメータを指定して接続のパフォーマンスを向上させる方法については、第 5 章「POP、IMAP、および HTTP サービスの設定」を参照してください。
Identity Server の詳細については、第 6 章「シングルサインオン (SSO) の有効化」を参照してください。
認証メカニズムを構成する認証メカニズムは、クライアントが識別情報をサーバーに提示する方法の 1 つです。Messaging Server は SASL (Simple Authentication and Security Layer) プロトコルで定義されている認証方法をサポートし、さらに、証明書に基づく認証もサポートします。この節では、SASL による認証メカニズムについて説明します。証明書に基づく認証の詳細については、「暗号化と証明書に基づく認証を構成する」を参照してください。
Messaging Server は、パスワードに基づく認証の場合、以下の SASL 認証方法をサポートします。
この問題は、SSL を使用することによって軽減できます。詳細は、「暗号化と証明書に基づく認証を構成する」を参照してください。
- DIGEST-MD5 - RFC 2831 で定義されているチャレンジ / 応答型の認証メカニズム。Messaging Multiplexor では、DIGEST-MD5 はサポートされていません。
- CRAM-MD5 - APOP に似たチャレンジ / 応答型の認証メカニズムですが、他のプロトコルでの使用にも適しています。RFC 2195 に定義されています。
- APOP - POP3 プロトコルでのみ使用できるチャレンジ / 応答型の認証メカニズム。RFC 1939 に定義されています。
- LOGIN - PLAIN と同等。SMTP 認証の標準化前の実装との互換性を保つためにのみ存在します。デフォルトでは、このメカニズムは SMTP で使用される場合にのみ有効になります。
チャレンジ / 応答型の認証メカニズムでは、サーバーからクライアントにチャレンジ文字列が送られます。クライアントは、そのチャレンジのハッシュとユーザーのパスワードを使用して応答します。クライアントの応答がサーバー自体のハッシュと一致すると、ユーザーが認証されます。ハッシュは元のデータに戻すことができないため、ネットワークを介して送信してもユーザーのパスワードが危険にさらされることはありません。
表 19-1 に、SASL および SASL 関連の configutil パラメータの一部を示します。configutil パラメータがもっとも多く挙げられている最新のリストは、『Sun Java System Messaging Server Administration Reference』を参照してください。
プレーンテキストパスワードへのアクセスを構成するには
CRAM-MD5、DIGEST-MD5、または APOP SASL の認証メソッドでは、ユーザーのプレーンテキストパスワードにアクセスする必要があります。次の手順を実行する必要があります。
パスワードが保存されるように Directory Server を構成するには
CRAM-MD5、DIGEST-MD5、または APOP メカニズムを有効にするには、次のようにパスワードがクリアテキストで保存されるように Directory Server を構成する必要があります。
Messaging Server を構成するには
次に、Directory Server がクリアテキストのパスワードを使用していることを認識できるように Messaging Server を構成することができます。これにより、Messaging Server で APOP、CRAM-MD5、および DIGEST-MD5 を安全に使用できるようになります。
configutil -o sasl.default.ldap.has_plain_passwords -v 1
値を 0 または null (" ") に設定すると、これらのチャレンジ / 応答型の SASL メカニズムを無効にすることができます。
MMP には同等のオプション「CRAM」があります。
ユーザーを移行するには
configutil を使用して、移行するユーザーに関する情報を指定できます。たとえば、ユーザーパスワードを変更する場合や、適切なユーザーエントリがないメカニズムを使ってクライアントが認証を試みている場合に、この情報を指定します。
configutil -o sasl.default.auto_transition -v value
value には、次のいずれかを指定できます。
ユーザーを正常に移行するには、Messaging Server がユーザーパスワード属性に書き込みアクセスできるように、Directory Server の ACI を設定する必要があります。そのためには、次の手順を実行します。
- コンソールで、構成する Directory Server を開きます。
- 「ディレクトリ」タブをクリックします。
- ユーザー/グループツリーのベースサフィックスを選択します。
- 「オブジェクト」メニューから「アクセス権を設定」を選択します。
- 「Messaging Server End User Administrator Write Access Rights (Messaging Server エンドユーザー管理者書き込みアクセス権」に対する ACI を選択 (ダブルクリック) します。
- 「ACI 属性」をクリックします。
- 既存の属性のリストに userpassword 属性を追加します。
- 「了解」をクリックします。
sasl.default.mech_list を使用して SASL メカニズムのリストを有効にできます。空でない場合、この設定は sasl.default.ldap.has_plain_passwords オプションおよび service.imap.allowanonymouslogin オプションよりも優先します。このオプションは、すべてのプロトコル (imap、pop、smtp) に適用されます。
ユーザーパスワードログインMessaging Server にログインしてメールの送受信を行うには、ユーザーがパスワードを入力する必要があります。これは承認されていないアクセスを防ぐための最初の防御手段です。Messaging Server では、IMAP、POP、HTTP、および SMTP の各サービスに対して、パスワードに基づくログインがサポートされています。
IMAP、POP、HTTP のパスワードログイン
デフォルトでは、内部ユーザーは、Messaging Server からメッセージを取得するためにパスワードを送信する必要があります。POP、IMAP、HTTP のサービスごとにパスワードログインを有効または無効にできます。POP、IMAP、HTTP サービスのパスワードログインの詳細については、「パスワードに基づくログイン」を参照してください。
ユーザーパスワードは、クリアテキストまたは暗号文の形式で、ユーザーのクライアントソフトウェアからサーバーに転送できます。クライアントとサーバーの両方が、SSL を使用できるように構成され、かつ必要な強度の暗号化 (「SSL を有効化し符号化方式を選択するには」を参照) をサポートする場合に、暗号化が実行されます。
ユーザー ID とパスワードは、LDAP ユーザーディレクトリに保存されます。最小長などのパスワードに関するセキュリティ条件は、ディレクトリポリシーの要件によって決まり、Messaging Server では管理されません。
パスワードに基づくログインの代わりに証明書に基づくログインを使用できます。証明書に基づくログインについては、SSL の説明とともにこの章で後述します。「証明書に基づくログインを設定するには」を参照してください。
プレーンテキストパスワードによるログインの代わりに、チャレンジ / 応答型の SASL メカニズムを使用できます。
SMTP パスワードログイン
デフォルトでは、Messaging Server の SMTP サービスに接続してメッセージを送信する場合に、ユーザーはパスワードを入力する必要がありません。しかし、認証 SMTP を使用可能にするために、SMTP サービスへのパスワードログインを有効にすることができます。
認証 SMTP は、クライアントがサーバーに対して認証を行うことを可能にする、SMTP プロトコルの拡張機能です。認証は、メッセージの送受信時に実行されます。認証 SMTP の主要な用途は、他のユーザーが悪用できるオープンリレーの発生を防ぎながら、ローカルユーザーが移動先から (または自宅用の ISP を使用して) メールを送信 (リレー) できるようにすることです。クライアントは、「AUTH」コマンドを使用してサーバーに対する認証を行います。
SMTP パスワードログイン (すなわち認証 SMTP) を有効にする方法については、「SMTP 認証、SASL、TLS」を参照してください。
認証 SMTP は、SSL 暗号化とともに使用することも、SSL 暗号化を使わずに使用することもできます。
暗号化と証明書に基づく認証を構成するこの節では、以下の項目に分けて説明しています。
Messaging Server では、クライアントとサーバー間で、暗号化された通信および証明書に基づく認証を行うために TLS (Transport Layer Security) プロトコルを使用します。TLS プロトコルは、SSL (Secure Sockets Layer) プロトコルとも呼ばれます。Messaging Server は、SSL バージョン 3.0 および 3.1 をサポートします。TLS には、SSL との完全な互換性があり、必要な SSL 機能がすべて含まれています。
SSL に関する背景情報については、『Managing Servers with iPlanet Console』の付録の「Introduction to SSL」を参照してください。SSL は、公開鍵暗号化の概念に基づいています。この概念については、『Managing Servers with iPlanet Console』の付録の「Introduction to Public-Key Cryptography」を参照してください。
Messaging Server とそのクライアント間、および Messaging Server と他のサーバー間におけるメッセージの転送が暗号化される場合は、通信が盗聴される危険性はほとんどありません。また、接続しているクライアントが認証済みの場合は、侵入者がそれらのクライアントになりすます (スプーフィングする) 危険性もほとんどありません。
SSL は、IMAP4、HTTP、POP3 および SMTP のアプリケーションレイヤの下のプロトコルレイヤとして機能します。SMTP と SMTP/SSL は同じポートを使用しますが、HTTP と HTTP/SSL は異なるポートを必要とします。IMAP と IMAP/SSL、POP と POP/SSL は、同じポートを使用することも異なるポートを使用することもできます。図 19-1 に示すように、SSL は、送信メッセージと受信メッセージの両方で、メッセージ通信の特定の段階で作用します。
図 19-1 Messaging Server での暗号化された通信
SSL は、ホップ間の暗号化を提供しますが、中間にある各サーバー上ではメッセージは暗号化されません。
注
送信メッセージの暗号化を有効にするには、チャネル定義を変更して、maytls や musttls などの tls チャネルキーワードを追加する必要があります。詳細は、「Transport Layer Security」および『Messaging Server Reference Manual』を参照してください。
SSL 接続を設定する際のオーバーヘッドによって、サーバーのパフォーマンスが低下する可能性があります。メッセージングシステムの設計とパフォーマンスの分析を行う際には、セキュリティ要件とサーバーのパフォーマンスのバランスをとる必要があります。
証明書の入手
SSL の用途が暗号化か認証かにかかわらず、Messaging Server 用のサーバー証明書を入手する必要があります。この証明書は、使用するサーバーの識別情報をクライアントや他のサーバーに提供します。
内部モジュールと外部モジュールを管理するには
サーバー証明書によって、キーのペアの所有権と有効性が確立されます。キーのペアは、データの暗号化と解読に使用される数値です。サーバーの証明書とキーのペアは、そのサーバーの識別情報を示します。これらは、サーバー内部または取り外し可能な外部のハードウェアカード (スマートカード) の証明書データベース内に保存されます。
Sun Java System サーバーは、PKCS (Public-Key Cryptography System) #11 API に準拠するモジュールを使用して、キーと証明書のデータベースにアクセスします。通常、特定のハードウェアデバイスの PKCS #11 モジュールは、そのデバイスの供給元から入手できます。Messaging Server でそのデバイスを使用する前に、このモジュールを Messaging Server にインストールする必要があります。Messaging Server にプリインストールされている「Netscape Internal PKCS # 11 Module」は、サーバー内部の証明書データベースを使用する単一の内部ソフトウェアトークンをサポートします。
証明書を使用できるようにサーバーを設定する場合は、証明書とそのキーを格納するためのデータベースを作成し、PKCS #11 モジュールをインストールする必要があります。外部のハードウェアトークンを使用しない場合は、サーバー上に内部データベースを作成し、Messaging Server に含まれるデフォルトの内部モジュールを使用します。外部トークンを使用する場合は、スマートカードリーダーハードウェアを接続し、そのハードウェアの PKCS #11 モジュールをインストールします。
外部モジュールか内部モジュールかにかかわらず、PKCS #11 モジュールは、コンソールを使用して管理できます。PKCS #11 モジュールをインストールするには、次の手順を実行します。
詳細な手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。
ハードウェア暗号化アクセラレータのインストール 暗号化用に SSL を使用する場合は、ハードウェア暗号化アクセラレータをインストールすることによって、メッセージの暗号化と解読のパフォーマンスを向上させることができます。一般的に、暗号化アクセラレータは、サーバーマシンに常設されたハードウェアボードとソフトウェアドライバで構成されます。Messaging Server は、PKCS #11 API に準拠したアクセラレータモジュールをサポートしています。これらは、基本的に独自のキーを格納しないハードウェアトークンで、キーの格納には内部データベースが使用されます。まず、製造元の指示に従ってハードウェアとドライバをインストールすることにより、アクセラレータをインストールします。その後、PKCS #11 モジュールをインストールすることにより、ハードウェア証明書トークンをインストールします。
サーバー証明書を要求するには
サーバー証明書を要求するには、コンソールでサーバーを開き、「証明書セットアップウィザード」を実行します。このウィザードには、「コンソール」メニューまたは Messaging Server の「暗号化」タブからアクセスできます。このウィザードを使用して、次のタスクを実行します。
認証局 (CA) から電子メールによる応答を受け取ったら、メールをテキストファイルとして保存し、証明書セットアップウィザードを使用してそのファイルをインストールします。
詳細な手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。
証明書データベースを作成する
- スーパーユーザー (root) としてログインします。
- /opt/SUNWmsgsr/config/sslPassword に certutil の証明書データベースのパスワードを指定します。
例 :# echo "password" > /opt/SUNWmsgsr/config/sslpassword
password は、ユーザー固有のパスワードです。
- sbin ディレクトリに移動し、証明書データベース (cert7.db) と鍵データベース (key3.db) を生成します。
例 :# cd /opt/SUNWmsg/sbin
# ./certutil -N -d /opt/SUNWmsgsr/config -f /opt/SUNWmsgsr/config/sslpassword- デフォルトの自己署名済みルート認証局証明書を生成します。
例:- ホストの証明書を生成します。
例 :hostname.sesta.com は、サーバーホスト名です。
- 証明書の妥当性を検査します。
例 :# ./certutil -V -u V -n SampleRootCA -d /var/opt/SUNWmsgsr/config
# ./certutil -V -u V -n Server-Cert -d /opt/SUNWmsgsr/config- 証明書を列挙します。
例 :# ./certutil -L -d /opt/SUNWmsgsr/config
# ./certutil -L -n Server-Cert -d /opt/SUNWmsgsr/config- modutil を使って、使用可能なセキュリティモジュール (secmod.db) を列挙します。
例 :# . ./modutil -list -dbdir /opt/SUNWmsgsr/config
- エイリアスファイルの所有者を icsuser および icsgroup (Calendar Server を実行するユーザーおよびグループの ID) に変更します。
例 :find /opt/SUNWmsgsr/config/cert7.db -exec chown mailsrv {} ¥;
find /opt/SUNWmsgsr/config/key3.db -exec chown mailsrv {} ¥;
find /opt/SUNWmsgsr/config/cert7.db -exec chgrp mail {} ¥;
find /opt/SUNWmsgsr/config/key3.db -exec chgrp mail {} ¥;mailsrv はメールサーバー UID で、mail はメールサーバー GID です。
- メッセージングサービスを再起動して、SSL を有効にします。
証明書をインストールするには
インストールは、要求とは別の手順で実行します。認証局 (CA) から証明書要求に対する応答の電子メールを受け取ったら、電子メールをテキストファイルとして保存し、もう一度証明書セットアップウィザードを実行して、次のように証明書としてファイルをインストールします。
詳細な手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。
信頼できる CA の証明書をインストールするには
認証局 (CA) の証明書をインストールする場合も、証明書セットアップウィザードを使用します。CA 証明書は、認証局自体の身元を証明します。サーバーは、クライアントや他のサーバーを認証するプロセスで、これらの CA 証明書を使用します。
たとえば、パスワードに基づく認証 (157 ページの「証明書に基づくログインの設定」を参照) に加え、証明書に基づく認証にも対応するように会社の環境を設定した場合は、クライアントが提示する可能性のある証明書の発行元として信頼できる CA の証明書をすべてインストールする必要があります。これらの CA は、社内組織の場合もあれば、商業機関、政府機関、他の企業などの外部組織の場合もあります。認証用 CA 証明書の使用方法については、『Managing Servers with iPlanet Console』の「Introduction to Public-Key Cryptography」を参照してください。
Messaging Server をインストールすると、いくつかの商用認証局の CA 証明書もインストールされます。他の商用認証局の CA 証明書を追加する場合や、社内使用のために (Sun Java System Certificate Server を使用して) 独自の認証局を開発する場合は、追加の CA 証明書を入手して、インストールする必要があります。
注
Messaging Server により自動的に提供される CA 証明書は、インストール時にはクライアント証明書用の信頼できる証明書としてマークされていません。これらの CA から発行されるクライアント証明書を信頼できるものにする必要がある場合は、信頼設定を編集する必要があります。この手順については、「証明書と信頼できる CA の管理」を参照してください。
新しい CA 証明書を要求してインストールするには、次の手順を実行します。
詳細な手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。
証明書と信頼できる CA の管理
サーバーには、クライアントの認証に使用する、信頼できる CA の証明書を必要な数だけインストールできます。
コンソールでサーバーを開き、「コンソール」メニューの「証明書の管理」コマンドを選択すると、Messaging Server にインストールされている証明書の信頼設定の表示や編集、または任意の証明書の削除を行うことができます。この手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。
パスワードファイルの作成
任意の Sun Java System サーバー上で、証明書セットアップウィザードを使用して証明書を要求すると、ウィザードによってキーのペアが作成されます。このキーのペアは、あとで内部モジュールのデータベースまたはスマートカード内にある外部データベースに格納します。次に、このプライベートキーを暗号化するために使われるパスワードの入力を要求されます。あとでこのキーを解読するには、この同じパスワードを使用する必要があります。ウィザードでは、パスワードはどこにも記録されません。
SSL を有効にしている Sun Java System サーバーでは、ほとんどの場合、起動時に管理者がキーのペアの解読に必要なパスワードを入力します。ただし、Messaging Server では、パスワードを何度も入力する手間を省き (少なくとも 3 つのサーバープロセスで入力が必要)、さらに無人でサーバーを再起動できるように、パスワードファイルからパスワードが読み取られます。
パスワードファイルは、sslpassword.conf という名前で、ディレクトリ msg_svr_base/config/ に保存されています。ファイル内の各エントリは、次のフォーマットで 1 行ずつ記述されます。
moduleName:password
moduleName は使用される (内部または外部) PKCS #11 モジュールの名前です。password はそのモジュールのキーのペアを暗号化するためのパスワードです。パスワードは、クリアテキスト (暗号化されていないテキスト) として保存されます。
Messaging Server には、デフォルトのパスワードファイルが用意されています。このファイルには、次のような内部モジュールとデフォルトのパスワードのエントリが 1 つだけ含まれています。
Internal (Software) Token:netscape!
内部証明書をインストールするときにデフォルト以外のパスワードを指定する場合は、指定するパスワードに合わせてパスワードファイル内の上記の行を編集する必要があります。外部モジュールをインストールする場合は、ファイルに新しい行を追加し、モジュール名とモジュール用に指定するパスワードを記述する必要があります。
警告
管理者はサーバー起動時にモジュールパスワードの入力を要求されません。そのため、管理者のアクセスが適切に制御されていること、およびサーバーホストマシンとそのバックアップの物理的なセキュリティが確保されていることの確認が重要になります。
SSL を有効化し符号化方式を選択するには
コンソールを使用すると、SSL を有効にし、Messaging Server がクライアントとの暗号通信で使用できる符号化方式を選択できます。
符号化方式について
符号化方式とは、暗号化プロセスでデータの暗号化と解読に使用されるアルゴリズムのことです。各符号化方式によって強度が異なります。つまり、強度の高い符号化方式で暗号化したメッセージほど、承認されていないユーザーによる解読が困難になります。
符号化方式では、キー (長い数値) をデータに適用することによってデータを操作します。一般的に、符号化方式で使用するキーが長いほど、適切な解読キーを使わずにデータを解読することが難しくなります。
クライアントは、Messaging Server と SSL 接続を開始するときに、サーバーに対して、希望する暗号化用の符号化方式とキー長を伝えます。暗号化された通信では、両方の通信者が同じ符号化方式を使用する必要があります。一般的に使用される符号化方式とキーの組み合わせは数多くあります。そのため、サーバーは柔軟な暗号化サポートを提供する必要があります。Messaging Server では、最大 6 つの符号化方式とキー長の組み合わせをサポートできます。
表 6.1 に、Messaging Server が SSL 3.0 を使用する場合にサポートする符号化方式の一覧を示します。この表には概要を記載しています。詳細は、『Managing Servers with iPlanet Console』の「Introduction to SSL」を参照してください。
特定の符号化方式を使わないようにする妥当な理由がないかぎり、すべての符号化方式をサポートする必要があります。ただし、特定の暗号化方式の使用が法律で制限されている国もあります。また、米国の輸出規制法規が緩和される前に開発されたクライアントソフトウェアの中には、強度の高い暗号化を使用できないものもあります。40 ビットの符号化方式では、偶発的な漏洩は防ぐことができますが、セキュリティが確保されないため、意図的な攻撃を防ぐことはできません。
SSL を有効にし、符号化方式を選択するには、次のコマンド行を実行します。
SSL を有効化 / 無効化するには、次のように入力します。
configutil -o nsserversecurity -v [ on | off ]
RSA 符号化方式を有効化 / 無効化するには、次のように入力します。
configutil -o encryption.rsa.nssslactivation -v [ on | off ]
トークンを指定するには、次のように入力します。
configutil -o encryption.rsa.nsssltoken -v tokenname
証明書を指定するには、次のように入力します。
configutil -o encryption.rsa.nssslpersonalityssl -v certname
RSA 符号化方式を有効にする場合は、トークンと証明書も指定する必要があります。
優先する符号化方式を選択するには、次のように入力します。
configutil -o encryption.nsssl3ciphers -v cipherlist
cipherlist は、カンマで区切られた符号化方式のリストです。
注
送信メッセージの暗号化を有効にするには、チャネル定義を変更して、maytls や musttls などの tls チャネルキーワードを追加する必要があります。詳細は、「Transport Layer Security」および『Messaging Server Reference Manual』を参照してください。
証明書に基づくログインを設定するには
Sun Java System サーバーでは、パスワードに基づくログインに加えて、デジタル証明書の確認によるユーザー認証もサポートしています。証明書に基づく認証では、クライアントはサーバーとの SSL セッションを確立し、ユーザーの証明書をサーバーに提出します。その後、サーバーが、提出された証明書の信頼性を評価します。証明書の信頼性が確認されると、そのユーザーは認証済みであるとみなされます。
証明書に基づくログインを実行できるように Messaging Server を設定するには、次の手順を実行します。
- 使用しているサーバー用の証明書を入手します (詳細は、「証明書の入手」を参照)。
- 証明書セットアップウィザードを実行して、サーバーが認証するユーザーに証明書を発行する、信頼できる認証局の証明書をインストールします (詳細は、「信頼できる CA の証明書をインストールするには」を参照)。
サーバーのデータベース内に信頼できる CA の証明書が 1 つでもあるかぎり、サーバーは接続するクライアントに対してクライアント証明書を要求します。
- SSL を有効にします (詳細は、「SSL を有効化し符号化方式を選択するには」を参照)。
- サーバーが提出された証明書の情報に基づいて LDAP ユーザーディレクトリを適切に検索するように、サーバーの certmap.conf ファイルを編集します (省略可)。
ユーザーの証明書内の電子メールアドレスと、ユーザーのディレクトリエントリ内の電子メールアドレスが一致する場合は、certmap.conf ファイルを編集する必要はありません。また、検索を最適化したり、提出された証明書をユーザーエントリ内の証明書と照合したりする必要もありません。
certmap.conf のフォーマットと変更可能な部分の詳細については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。
上記の手順を実行したあとに、ユーザーが、IMAP または HTTP にログインできるようにクライアントで SSL セッションを確立すると、Messaging Server からクライアントに対してユーザーの証明書が要求されます。サーバーによって信頼されている CA から発行された証明書をクライアントが提出し、かつ証明書の識別情報がユーザーディレクトリ内のエントリと一致する場合、そのユーザーは、認証され、ユーザーに適用されるアクセス制御ルールに応じたアクセス権が与えられます。
証明書に基づくログインを有効にするためにパスワードに基づくログインを無効する必要はありません。パスワードに基づくログインが許可されている場合 (デフォルトの状態) に、この節で説明した作業を実行すると、パスワードに基づくログインと証明書に基づくログインの両方がサポートされます。その場合は、クライアントが SSL セッションを確立し、証明書を提出すると、証明書に基づくログインが使用されます。クライアントが SSL を使用しない場合、または証明書を提出しない場合は、パスワードを要求されます。
SMTP プロキシを使用した SSL パフォーマンスの最適化方法
SMTP プロキシを使用すると、SMTP プロトコルの待ち時間が増加するため、ほとんどのサイトでは SMTP プロキシを使用しません。ただし、SMTP 接続を保護するために SSL を頻繁に使用する大規模サイトでは、SSL とプロキシ専用の 1 台のサーバー上で、すべてのプロトコルのすべての SSL 操作を実行することで、SSL アクセラレータハードウェアに対する投資効果を最大化する必要があります。SMTP プロキシを使用すると、フロントエンドのプロキシサーバーで SSL を処理し、メールキューを別の MTA マシン上に置くことができます。この方法により、各タスクに最適なハードウェアを個別に購入して構成することができます。
SMTP プロキシのインストール方法については、「SMTP プロキシをインストールするには」を参照してください。
Messaging Server への管理者アクセスを構成するこの節では主に Sun Java System LDAP スキーマ v. 1 について説明します。次の項があります。
この節では、サーバー管理者による Messaging Server へのアクセスを制御する方法について説明します。特定の Messaging Server および Messaging Server タスクへの管理アクセスは、委任サーバー管理を行うときに発生します。
委任サーバー管理は、ほとんどの Sun Java System サーバーが持っている機能で、管理者が、他の管理者に対して、個々のサーバーやサーバー機能へのアクセス権を選択して提供できる機能を意味します。この章では、委任されたサーバーのタスクについて簡単に説明します。詳細は、『Managing Servers with iPlanet Console』のサーバー管理の委任に関する章を参照してください。
委任管理の階層
ネットワーク上に最初の Sun Java System サーバーをインストールすると、インストールプログラムによって、LDAP ユーザーディレクトリに構成管理者グループと呼ばれるグループが自動的に作成されます。デフォルトでは、構成管理者グループのメンバーには、ネットワーク上のすべてのホストおよびサーバーに対する無制限のアクセス権が与えられます。
構成管理者グループは、次のようなアクセス階層の最上位に位置します。このようなアクセス階層を構築して、Messaging Server の委任管理 (Sun Java System LDAP スキーマ v. 1 を使用している場合) を実装することができます。
- 構成管理者 : Sun Java System サーバーネットワークの「スーパーユーザー」。すべてのリソースに対する完全なアクセス権を持ちます。
- サーバー管理者 : ドメイン管理者は、各タイプのサーバーを管理するためのグループを作成することがあります。たとえば、管理ドメイン内またはネットワーク全体にあるすべての Messaging Server を管理するためにメッセージング管理者グループを作成する場合があります。このグループのメンバーは、その管理ドメイン内のすべての Messaging Server にアクセスできます (他のサーバーにはアクセス不可)。
- タスク管理者 : 上記のすべての管理者は、単一または複数の Messaging Server に対する制限付きアクセス権を持つグループを作成したり、そのようなアクセス権を持つ個別のユーザーを指定したりできます。指定されたタスク管理者は、特定の制限されたサーバータスク (サーバーの起動または停止、特定のサービスのログへのアクセス) だけを実行できます。
管理者は、コンソールが提供する便利なインタフェースを使用して、次のタスクを実行できます。
- グループまたは個人に特定の Messaging Server に対するアクセス権を与える。次の節の「サーバー全体に対するアクセス権の提供」を参照
- そのアクセス権を特定の Messaging Server 上での特定のタスクに制限する。「特定タスクへのアクセスを限定するには」を参照
サーバー全体に対するアクセス権を与えるには
ユーザーまたはグループに Messaging Server の特定のインスタンスに対するアクセス権を与えるには、次の手順を実行します。
詳細な手順については、『Managing Servers with iPlanet Console』のサーバー管理の委任に関する章を参照してください。
特定の Messaging Server へのアクセス権を持つユーザーおよびグループのリストの設定が済んだら、次に説明する ACI を使用して、特定のサーバータスクをリスト内の特定のユーザーまたはグループに委任することができます。
特定タスクへのアクセスを限定するには
一般的に、管理者はサーバーに接続して 1 つ以上の管理タスクを実行します。コンソールの「Messaging Server タスク」フォームには、頻繁に実行される管理タスクが一覧表示されます。
デフォルトでは、特定の Messaging Server にアクセスできると、そのサーバーのすべてのタスクにアクセスできます。ただし、タスクフォーム内の各タスクには、一連のアクセス制御インストラクション (ACI) を関連付けることができます。サーバーは、接続しているユーザー (サーバー全体に対するアクセス権をすでに持っているユーザー) にタスクへのアクセス権を与える前に、これらの ACI を参照します。実際、タスクフォームには、そのユーザーがアクセス権を持っているタスクだけが表示されます。
Messaging Server へのアクセス権がある場合は、アクセスできる任意のタスクに関する ACI を作成または編集して、他のユーザーやグループがそのタスクに対して持つことができるアクセス権を制限できます。
接続しているユーザーまたはグループが持つことができるタスクアクセス権を制限するには、次の手順を実行します。
ACI とその作成方法の詳細については、『Managing Servers with iPlanet Console』のサーバー管理の委任に関する章を参照してください。
POP、IMAP、および HTTP サービスへのクライアントアクセスを構成するこの節では、以下の項目に分けて説明しています。
Messaging Server には、IMAP、POP、HTTP の各サービスを個別に制御できる精巧なアクセス制御機能があります。これにより、クライアントによるサーバーへのアクセスを広範囲に細かく制御できます。
大企業やインターネットサービスプロバイダのメッセージングサービスを管理する場合、これらの機能を使用して、スパム (大量メール送信) や DNS スプーフィングを行うユーザーをシステムから除外したり、ネットワークの全般的なセキュリティを強化したりできます。不特定多数宛メールを制御するための具体的な方法については、第 17 章「メールのフィルタリングとアクセス制御」を参照してください。
注
IP アドレスによるアクセス制御が重要な問題ではない場合は、この節で説明しているフィルタを作成する必要はありません。最小限のアクセス制御だけが必要な場合は、その設定手順について、「大半のアクセスを許可」を参照してください。
クライアントアクセスフィルタのしくみ
Messaging Server のアクセス制御機能は、プログラムであり、TCP デーモンと同じポートで応答を待機します。このプログラムは、アクセスフィルタを使用してクライアントの識別情報を確認し、クライアントがフィルタリングプロセスを通過した場合に、そのクライアントに対してデーモンへのアクセス権を与えます。
Messaging Server の TCP クライアントアクセス制御システムは、必要な場合、その処理の一部として、次のようなソケットの終端アドレスの分析を行います。
システムは、この情報をフィルタと呼ばれるアクセス制御文と比較して、アクセスの許可または拒否を決定します。サービスごとに、個別の許可フィルタと拒否フィルタのセットを使用して、アクセスを制御します。許可フィルタは明示的にアクセスを許可し、拒否フィルタは明示的にアクセスを禁止します。
クライアントがサービスへのアクセスを要求すると、アクセス制御システムは、そのクライアントのアドレスまたは名前情報を、以下の条件を使用して順番に対象のサービスのフィルタと比較します。
ここで説明するフィルタの構文は柔軟性に富んでいるため、わかりやすい簡単な方法で、さまざまなアクセス制御ポリシーを実装できます。許可フィルタと拒否フィルタは自由に組み合わせて使用できますが、大半のアクセスを許可するフィルタまたは大半のアクセスを拒否するフィルタを使用すると、ほとんどのポリシーを実装できます。
以下の節では、フィルタの構文について詳しく説明し、さらに使用例を紹介します。アクセスフィルタの作成手順については、「各サービス用のアクセスフィルタを作成するには」を参照してください。
フィルタの構文
フィルタ文は、サービス情報とクライアント情報の両方を含んでいます。サービス情報には、サービス名、ホスト名、ホストアドレスを含めることができます。クライアント情報には、ホスト名、ホストアドレス、ユーザー名を含めることができます。サービス情報とクライアント情報の両方で、ワイルドカード名やパターンを使用できます。
以下に、非常に単純な形式のフィルタを示します。
service:hostSpec
service には、サービス名 (smtp、pop、imap、 http など) を指定し、hostSpec には、ホスト名、IP アドレス、またはアクセス要求元のクライアントを表すワイルドカード名やパターンを指定します。フィルタが処理されるときに、アクセス要求元のクライアントが client に一致すると、service で指定されているサービスへのアクセスが、フィルタのタイプに応じて許可または拒否されます。次に例を示します。
imap: roberts.newyork.siroe.com
pop:ALL
http:ALL
これらが許可フィルタの場合は、最初の行によって roberts.newyork.siroe.com というホストに対して、IMAP サービスへのアクセスが許可されます。さらに 2 行目と 3 行目によって、それぞれ POP サービスと HTTP サービスへのアクセスがすべてのクライアントに許可されます。これらが拒否フィルタの場合は、それらのクライアントによる指定したサービスへのアクセスが拒否されます。ALL などのワイルドカード名の詳細については、「ワイルドカード名」を参照してください。
フィルタ内のサーバー (サービス) 情報やクライアント情報は、これよりも少々複雑になることがあります。次に、その場合の一般的な形式を示します。
serviceSpec: clientSpec
serviceSpec は、service または service@hostSpec のどちらかを示し、clientSpec は、hostSpec または user@hostSpec のどちらかを示します。user はアクセス要求元のクライアントホストに関連付けられたユーザー名 (またはワイルドカード名) です。次にフィルタの例を 2 つ示します。
pop@mailServer1.siroe.com:ALL
imap: srashad@xyz.europe.siroe.com
これらが拒否フィルタの場合、最初のフィルタは、すべてのクライアントに対して、ホスト mailServer1.siroe.com 上の SMTP サービスへのアクセスを拒否します。2 番目のフィルタは、ホスト xyz.europe.siroe.com のユーザー srashad に対して、IMAP サービスへのアクセスを拒否します。これらの詳細なサーバーおよびクライアントに対する指定を使用する状況については、「サーバーホストの指定」および「クライアントのユーザー名の指定」を参照してください。
もっとも一般的なフィルタの形式は次のようになります。
serviceList: clientList
serviceList は、1 つ以上の serviceSpec エントリで構成され、clientList は、1 つ以上の clientSpec エントリで構成されます。serviceList と clientList 内の各エントリは、空白またはカンマで区切ります。
この場合、フィルタが処理されるときに、アクセス要求元のクライアントが、clientList 内の clientSpec エントリのいずれかと一致すると、serviceList で指定されているすべてのサービスへのアクセスが、フィルタのタイプに応じて許可または拒否されます。次に例を示します。
pop、imap、http:.europe.siroe.com .newyork.siroe.com
これが許可フィルタの場合、europe.siroe.com ドメインおよび newyork.siroe.com ドメイン内のすべてのクライアントに対して、POP、IMAP、HTTP サービスへのアクセスが許可されます。ドメインやサブネットを指定する場合の先頭に付けるドットや他のパターンの使用方法については、「ワイルドカードのパターン」を参照してください。
次の構文も使用できます。
「+」 または 「-」 serviceList:*$next_rule
+ (許可フィルタ) は、デーモンリストサービスがクライアントリストに付与されることを意味します。
- (拒否フィルタ) は、クライアントリストに対してサービスが拒否されることを意味します。
* (ワイルドカードフィルタ) は、すべてのクライアントにこれらのサービスの使用を許可します。
$ は、ルールの区切りです。
この例では、すべてのクライアントで複数のサービスを有効にしています。
+imap,pop,http:*
この例では、複数のルールを単純化して各ルールが単一のサーバー名を所有し、クライアントリスト用のワイルドカードを使用するようにします。これは、LDIF ファイルでアクセス制御を指定するためのもっとも一般的なメソッドです。
+imap:ALL$+pop:ALL$+http:ALL
この例では、あるユーザーに対してすべてのサービスを許可しない方法を示します。
-imap:*$-pop:*$-http:*
ワイルドカード名
以下のワイルドカード名を使用して、サービス名、ホストの名前やアドレス、またはユーザー名を表すことができます。
ワイルドカードのパターン
サービスまたはクライアントアドレスを指定するときは、次のパターンを使用できます。
- ドット文字 (.) から始まる文字列。ホスト名の最後の部分が指定したパターンに一致する場合、そのホスト名は一致する。たとえば、ワイルドカードパターン .siroe.com は、ドメイン siroe.com 内のすべてのホストに一致する
- ドット文字 (.) で終わる文字列。ホストアドレスの最初の数値フィールドが指定したパターンに一致する場合、そのホストアドレスは一致する。たとえば、ワイルドカードパターン 123.45. は、サブネット 123.45.0.0 内のすべてのホストのアドレスに一致する
- n.n.n.n/m.m.m.m 形式の文字列。このワイルドカードパターンは、net/mask のペアと解釈される。ホストアドレスのnet が、アドレスと mask のビット単位の論理積と等しい場合、そのホストアドレスは一致する。たとえば、123.45.67.0/255.255.255.128 というパターンは、123.45.67.0 〜 123.45.67.127 の範囲内のすべてのアドレスに一致する
EXCEPT 演算子
アクセス制御システムでは、1 つの演算子がサポートされています。この EXCEPT 演算子を使うと、serviceList または clientList 内に複数のエントリがある場合に、名前やパターンの一致に関する例外を指定することができます。たとえば、次のような式を使用します。
list1 EXCEPT list2
この式では、list1 に一致するもので、list2 に一致しないものが、すべて一致します。
次に例を示します。
ALL: ALL EXCEPT isserver.siroe.com
これが拒否フィルタの場合、ホストマシン isserver.siroe.com 上のクライアントを除くすべてのクライアントに対して、すべてのサービスへのアクセスが拒否されます。
EXCEPT 句は入れ子にすることができます。次に入れ子の式の例を示します。
list1 EXCEPT list2 EXCEPT list3
これは次の式と同様に評価されます。
list1 EXCEPT (list2 EXCEPT list3)
サーバーホストの指定
serviceSpec エントリにサーバーホストの名前またはアドレス情報を含めることで、要求される特定のサービスをフィルタ内で識別することができます。この場合、次の形式でエントリを指定します。
service@hostSpec
この機能は、Messaging Server ホストマシンが、異なるインターネットホスト名を持つ複数のインターネットアドレス用に設定されている場合に有効です。サービスプロバイダの場合、この機能を使用することで、異なるアクセス制御ルールを持つ複数のドメインを 1 つのサーバーインスタンス上でホストできます。
クライアントのユーザー名の指定
RFC 1413 に記載された identd サービスをサポートするクライアントホストマシンの場合は、フィルタの clientSpec エントリ内にクライアントのユーザー名を含めることにより、サービスを要求している特定のクライアントを識別することができます。この場合、次の形式でエントリを指定します。
user@hostSpec
user は、クライアントの identd サービスによって返されるユーザー名 (またはワイルドカード名) です。
フィルタ内でクライアントユーザー名を指定すると便利ですが、次のことに注意する必要があります。
- identd サービスは認証機能ではないため、クライアントシステムが安全性に欠ける場合は、クライアントから返されるクライアントユーザー名を信頼することができません。一般的に、特定のユーザー名を使用せずに、ALL、KNOWN、UNKNOWN などのワイルドカード名だけを使用します。
- identd は最新のクライアントマシンではサポートされていないため、最近の導入ではあまり付加価値がありません。将来のバージョンでは identd のサポートを廃止することが検討されているため、今後もこの機能を使う必要がある場合は Sun Java System にお知らせください。
- ユーザー名の検索は時間がかかるので、すべてのユーザーについて検索を実行すると、identd をサポートしていないクライアントのアクセスが遅くなる場合があります。ユーザー名の検索を選択的に実行すると、この問題を緩和することができます。たとえば次のように指定します。
ユーザー名検索の機能は、クライアントホスト上の承認されていないユーザーからの攻撃を防ぐために役立つ場合があります。たとえば、一部の TCP/IP の実装環境では、侵入者が rsh (リモートシェルサービス) を使用して信頼されているクライアントホストになりすます場合があります。クライアントホストが ident サービスをサポートしている場合は、ユーザー名の検索を使用してそのような攻撃を検出できます。
フィルタの例
この節では、さまざまなアクセス制御方法の例を紹介します。これらの例を参照する際には、許可フィルタが拒否フィルタよりも先に処理されること、一致するものが見つかった時点で検索が終了すること、および一致するものがまったく見つからないとアクセスが許可されることに注意してください。
ここに記載した例では、IP アドレスではなく、ホスト名とドメイン名を使用します。フィルタにアドレス情報やネットマスク情報を含めておくと、ネームサービスに障害が発生した場合の信頼性を向上させることができます。
大半のアクセスを拒否
この例では、デフォルトでアクセスを拒否します。明示的に許可したホストだけにアクセスを許可します。
デフォルトのポリシー (アクセスなし) は、次のような 1 つの単純な拒否フィルタを使用して実装します。
ALL: ALL
このフィルタは、許可フィルタによって明示的にアクセスを許可されていないすべてのクライアントに対して、すべてのサービスへのアクセスを拒否します。この場合の許可フィルタは、たとえば次のようになります。
ALL: LOCAL @netgroup1
ALL: .siroe.com EXCEPT externalserver.siroe.com
最初のルールは、ローカルドメイン内のすべてのホスト (ドットを含まないホスト名を持つすべてのホスト) からのアクセス、および netgroup1 というグループのメンバーからのアクセスを許可します。2 番目のルールでは、先頭にドットが付いたワイルドカードパターンを使用することで、siroe.com ドメイン内のすべてのホストからのアクセスを許可しますが、ホスト externalserver.siroe.com は除外されます。
大半のアクセスを許可
この例では、デフォルトでアクセスを許可します。明示的に拒否したホストだけにアクセスを拒否します。
デフォルトのポリシー (アクセス許可) により、許可フィルタは不要になります。次のように、アクセスを拒否するクライアントのリストを拒否フィルタ内に明示的に指定します。
ALL:externalserver.siroe1.com, .siroe.asia.com
ALL EXCEPT pop: contractor.siroe1.com, .siroe.com
最初のフィルタは、特定のホストおよびドメインに対して、すべてのサービスを拒否します。2 番目のフィルタは、特定のホストおよびドメインからの POP アクセスだけを許可します。
スプーフィングされたドメインのアクセスを拒否
フィルタ内で、DNSSPOOFER を使用すると、ホスト名のスプーフィングを検出できます。DNSSPOOFER を指定すると、アクセス制御システムによって正引きまたは逆引きの DNS 検索が実行され、クライアントが提示したホスト名とホストの実際の IP アドレスが一致するかどうかが調べられます。以下に拒否フィルタの例を示します。
ALL: DNSSPOOFER
このフィルタは、IP アドレスとその DNS ホスト名が一致しないすべてのリモートホストに対して、すべてのサービスを拒否します。
仮想ドメインへのアクセス制御
メッセージングシステムで仮想ドメインを使用し、1 つのサーバーインスタンスが複数の IP アドレスおよびドメイン名に関連付けられている場合は、許可フィルタと拒否フィルタを組み合わせて各仮想ドメインのアクセスを制御できます。たとえば、次のような許可フィルタを使用できます。
ALL@msgServer.siroe1.com: @.siroe1.com
ALL@msgServer.siroe2.com: @.siroe2.com
...
この場合、次のような拒否フィルタと組み合わせることができます。
ALL: ALL
各許可フィルタは、domainN 内のホストだけに、msgServer.siroeN.com に対応する IP アドレスを持つサービスへの接続を許可します。他の接続はすべて拒否されます。
各サービス用のアクセスフィルタを作成するには
IMAP、POP、HTTP の各サービス用の許可フィルタと拒否フィルタを作成できます。SMTP サービス用に作成することもできますが、認証済みの SMTP セッションにしか適用されないため、あまり価値はありません。認証されていない SMTP セッションへのアクセスを制御する方法については、第 17 章「メールのフィルタリングとアクセス制御」を参照してください。
コンソール コンソールを使用してフィルタを作成するには、次の手順を実行します。
許可フィルタまたは拒否フィルタの順序を変更する必要がある場合は、フィルタが適切な順序になるまで、削除と追加の操作を繰り返します。
フィルタの構文の指定方法とさまざまな例については、「フィルタの構文」を参照してください。その他の例については、「フィルタの例」を参照してください。
コマンド行 次のように、コマンド行を使用して許可フィルタや拒否フィルタを指定することもできます。
各サービス用のアクセスフィルタを作成または編集するには、次のように入力します。
configutil -o service.service.domainallowed -v filter
service には pop、imap、http のいずれかを指定し、filter は、「フィルタの構文」で説明した構文ルールに従って指定します。
各サービス用の拒否フィルタを作成または編集するには、次のように入力します。
configutil -o service.service.domainnotallowed -v filter
service には pop、imap、http のいずれかを指定し、filter は、「フィルタの構文」で説明した構文ルールに従って指定します。
HTTP プロキシ認証用のアクセスフィルタを作成するには
すべてのストア管理者は、任意のサービスに対してプロキシ認証を行うことができます (ストア管理者の詳細については、「ストアへの管理者によるアクセスを指定する」を参照)。HTTP サービスの場合にだけ、すべてのエンドユーザーがサービスに対してプロキシ認証を行うことができます。ただし、ユーザーが使用するクライアントホストが、プロキシ認証アクセスフィルタを介してアクセスを許可されている必要があります。
プロキシ認証を使用すると、ポータルサイトなどの他のサービスが、ユーザーを認証して、HTTP ログインサービスに認証資格情報を渡すことができます。たとえば、1 つのポータルサイトが複数のサービスを提供し、そのうちの 1 つが Messenger Express の Web ベースの電子メールだとします。HTTP プロキシ認証機能を使用すると、エンドユーザーはポータルサービスに対する認証を一度行うだけで済み、電子メールにアクセスするために再び認証を行う必要はありません。ただし、ポータルサイトでは、クライアントとサービス間のインタフェースとして機能するログインサーバーを構成する必要があります。Messenger Express の認証用にログインサーバーを設定する場合は、Sun Java System が提供する Messenger Express 認証 SDK を利用できます。
この節では、許可フィルタを使用し、IP アドレスを基準として、HTTP プロキシ認証を許可する方法について説明します。ログインサーバーの設定方法や Messenger Express 認証 SDK の使用方法については説明しません。Messenger Express 用のログインサーバーの設定方法や、認証 SDK の使用方法については、Sun Java System の担当者に問い合わせてください。
コンソール HTTP サービスに対するプロキシ認証用のアクセスフィルタを作成するには、次の手順を実行します。
- コンソールで、アクセスフィルタを作成する Messaging Server を開きます。
- 「設定」タブをクリックします。
- 左のペインで「サービス」フォルダを開き、そのフォルダの下にある「HTTP」を選択します。
- 右のペインの「プロキシ」タブをクリックします。
このタブの「許可」フィールドに、既存のプロキシ認証用の許可フィルタが表示されます。
- 新しいフィルタを作成する場合は、「追加」をクリックします。
「許可フィルタ」ウィンドウが表示されます。ウィンドウに新しいフィルタのテキストを入力し、「了解」をクリックします。
- 既存のフィルタを編集する場合は、フィルタを選択して、「編集」をクリックします。
「許可フィルタ」ウィンドウが表示されます。ウィンドウに表示されたフィルタのテキストを編集し、「了解」をクリックします。
- 既存のフィルタを削除する場合は、「許可」フィールドからフィルタを選択し、「削除」をクリックします。
- 「プロキシ」タブでの変更作業が終了したら、「保存」をクリックします。
許可フィルタの構文については、「フィルタの構文」を参照してください。
コマンド行 次のように、コマンド行を使用して、HTTP サービスに対するプロキシ認証用のアクセスフィルタを指定することもできます。
configutil -o service.service.proxydomainallowed -v filter
filter は、「フィルタの構文」で説明した構文ルールに従って指定します。
POP before SMTP を有効にするSMTP リレーサーバーのセキュリティを提供する方法としては、SMTP 認証または SMTP Auth (RFC 2554) をお勧めします。SMTP Auth は、認証済みのユーザーだけに MTA を介したメール送信を許可します。ただし、一部のレガシークライアントは、POP before SMTP だけをサポートします。この場合には、後述のように、POP before SMTP を有効にすることができます。ただし、可能な場合は、POP before SMTP を使用するのではなく、POP クライアントをアップグレードするようにユーザーに指示します。POP before SMTP をサイトに導入すると、ユーザーがクライアントに依存するようになり、インターネットのセキュリティ標準を守れなくなります。これにより、エンドユーザーがハッキングの危険にさらされ、さらにパフォーマンスが低下して、サイトの処理が遅くなります。これは、最後の正常な POP セッションの IP アドレスを追跡して同期する必要があるためです。
Messaging Server での POP before SMTP の実装は、SIMS や Netscape Messaging Server での実装とはまったく異なっています。POP before SMTP をサポートするには、POP と SMTP プロキシの両方を使用するように Messaging Multiplexor (MMP) を構成します。SMTP クライアントが SMTP プロキシに接続すると、プロキシは、メモリ内キャッシュで最新の POP 認証をチェックします。同じクライアント IP アドレスからの POP 認証が見つかった場合、SMTP プロキシは、ローカルとローカル以外の両方の受取人宛のメッセージを許可する必要があることを SMTP サーバーに通知します。
SMTP プロキシをインストールするには
- 『Sun ONE Messaging Server インストールガイド』の説明に従って、Messaging Multiplexor (MMP) をインストールします。
- MMP 上で SMTP プロキシを有効にします。
以下の文字列を
msg_svr_base/lib/SmtpProxyAService@25|587
msg_svr_base/config/AService.cfg ファイルの ServiceList オプションに追加します。このオプションは、1 行に記述し、改行を入れないようにします。
- 各 SMTP リレーサーバー上で、SMTP チャネルオプションファイル tcp_local_option の PROXY_PASSWORD オプションを設定します。
SMTP プロキシは、SMTP サーバーに接続する際に、実際の IP アドレスとその他の接続情報を SMTP サーバーに通知する必要があります。この情報により、SMTP サーバーは、リレーブロッキングやその他のセキュリティポリシー (POP before SMTP を含む) を適切に適用できるようになります。この操作はセキュリティ上重要な操作であり認証される必要があります。MMP SMTP プロキシと SMTP サーバーの両方で構成されたプロキシパスワードにより、第三者によるこの機能の悪用が確実に防止されます。
例: PROXY_PASSWORD=A_Password
- MMP が SMTP サーバーに接続するために使用する IP アドレスが INTERNAL_IP マッピングテーブルによって「internal」として扱われていないことを確認します。
INTERNAL_IP マッピングファイルについては、第 17 章「メールのフィルタリングとアクセス制御」の「SMTP リレーを追加するには」を参照してください。
- POP before SMTP をサポートするように SMTP プロキシを構成します。
- msg_svr_base/config/SmtpProxyAService.cfg 設定ファイルを編集します。
以下の SMTP プロキシオプションは、IMAP プロキシおよび POP プロキシの同名のオプションとまったく同じように機能します。『Messaging Server インストールガイド』の「Installing Messaging Multiplexor」を参照してください。また、これらのオプションについては、『Messaging Server Reference Manual』の「暗号化 (SSL) オプション」の節を参照してください。
LdapURL、LogDir、LogLevel、BindDN、BindPass、Timeout、Banner、SSLEnable、SSLSecmodFile、SSLCertFile、SSLKeyFile、SSLKeyPasswdFile、SSLCipherSpecs、SSLCertNicknames、SSLCacheDir、SSLPorts、CertMapFile、CertmapDN、ConnLimits、TCPAccess
上記のリストにないその他の MMP オプション (BacksidePort オプションを含む) は、現在のところ SMTP プロキシには適用されません。
次の 5 つのオプションを追加します。
SmtpRelays。このオプションは、スペースで区切られた SMTP リレーサーバーホスト名 (およびオプションのポート) のリストで、ラウンドロビンリレー用に使用されます。これらのリレーサーバーは、XPROXYEHLO 拡張キーワードをサポートしている必要があります。このオプションは必須で、デフォルトはない
例 : default:SmtpRelays manatee:485 gonzo mothraSmtpProxyPassword。SMTP リレーサーバー上でソースチャネルの変更を認証するために使用されるパスワードです。このオプションは必須で、デフォルト値はありません。また、SMTP サーバー上の PROXY_PASSWORD オプションと一致している必要があります。
例: default:SmtpProxyPassword A_PasswordEhloKeywords。このオプションは、プロキシがクライアントを通過させるために使用する、EHLO 拡張キーワードのリストを提供します。また、デフォルト値のセットも提供します。MMP は、SMTP リレーから返される EHLO のリストから、認識できない EHLO キーワードをすべて削除します。EhloKeywords は、リストから削除されない追加の EHLO キーワードを指定します。デフォルト値は空白ですが、SMTP プロキシは以下のキーワードをサポートするので、これらのキーワードをこのオプションで指定する必要はありません。8BITMIME、PIPELINING、DSN、ENHANCEDSTATUSCODES、EXPN、HELP、XLOOP、ETRN、SIZE、STARTTLS、AUTH
以下に、使用頻度の少ない「TURN」拡張キーワードを使用するサイトで使用できる指定例を示します。
例: default:EhloKeywords TURNPopBeforeSmtpKludgeChannel オプション。POP before SMTP で認証される接続で使用する MTA チャネルの名前に設定されます。デフォルトは空で、POP before SMTP を有効にするユーザーに対する通常の設定は tcp_intranet です。SSL のパフォーマンスを最適化するためにこのオプションを指定する必要はありません (「SMTP プロキシを使用した SSL パフォーマンスの最適化方法」を参照)。
例: default:PopBeforeSmtpKludgeChannel tcp_intranetClientLookup。このオプションはデフォルトで no に設定されます。yes に設定すると、クライアントの IP アドレスに関する DNS 逆引き検索が無条件に実行されるため、SMTP リレーサーバーで検索を行う必要がなくなります。このオプションは、ホストしているドメインごとに設定できます。
例: default:ClientLookup yes- PopProxyAService.cfg 設定ファイルに PreAuth オプションと AuthServiceTTL オプションを設定します。SSL のパフォーマンスを最適化するためにこのオプションを指定する必要はありません (「SMTP プロキシを使用した SSL パフォーマンスの最適化方法」を参照)。
これらのオプションは、POP 認証後にユーザーがメールの送信を許可される時間を秒単位で指定します。一般的な設定は、900 〜 1800 (15 〜 30 分) です。
例 :
default:PreAuth yes
default:AuthServiceTTL 900- オプションで、MMP が、SMTP リレーからの応答を待つ時間を秒単位で指定することができます。この時間が経過すると MMP はリスト内の次の SMTP リレーを試行します。
デフォルトは 10 (秒) です。SMTP リレーへの接続が失敗すると、MMP は、このフェイルオーバータイムアウトと同じ時間 (分単位) が経過するまで、そのリレーへの接続を試行しません。つまり、フェイルオーバータイムアウトが 10 秒のときに、あるリレーへの接続が失敗したとすると、MMP は、10 分間経過するまでそのリレーを再試行しません。
例 : default:FailoverTimeout 10
SMTP サービスへのクライアントアクセスを構成するSMTP サービスへのクライアントアクセスの構成方法については、第 17 章「メールのフィルタリングとアクセス制御」を参照してください。
