Sun Java System Messaging Server 6 2005Q4 管理ガイド

第 19 章 セキュリティーとアクセス制御を設定する

Messaging Server は、広範囲にわたる柔軟なセキュリティー機能をサポートします。これらの機能を使用して、メッセージが横取りされないようにしたり、侵入者がユーザーや管理者になりすますことを防いだり、メッセージングシステム内の特定部分へのアクセスを特定のユーザーだけに許可したりできます。

Messaging Server のセキュリティーアーキテクチャーは、Sun Java System サーバー全体のセキュリティーアーキテクチャーの一部です。このアーキテクチャーは、最大の相互運用性と一貫性を実現するために業界標準と公開プロトコルに基づいて構築されています。そのため、Messaging Server のセキュリティーポリシーを実装するには、この章だけでなくほかのドキュメントも参照する必要があります。特に Sun ONE Server Console 5.2 Server Management Guide には、Messaging Server のセキュリティーを設定するために必要な情報が記載されています。

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

サーバーのセキュリティーについて

サーバーのセキュリティーには広範囲にわたる説明が含まれます。ほとんどの企業では、承認されたユーザーだけがサーバーにアクセスできること、パスワードや識別情報が安全なこと、ほかのユーザーになりすました通信ができないこと、必要に応じて通信の機密性を確保できることなどがすべてメッセージングシステムの重要な要件になります。

サーバーのセキュリティーはさまざまな方法で攻撃される可能性があるため、さまざまな方法でセキュリティーを強化します。この章では、暗号化、認証、アクセス制御の設定に重点を置きます。この章で説明する Messaging Server のセキュリティー関連の内容は、次のとおりです。

この章では、Messaging Server に関連するすべてのセキュリティーとアクセスの問題について説明するわけではありません。この章で説明していないセキュリティー関連の項目として、次のものがあります。

セキュリティーに関するさまざまな説明を含んだ数多くのマニュアルがあります。この章に記載した内容の背景情報や、その他のセキュリティー関連情報については、文書 Web サイト (http://docs.sun.com) を参照してください。

HTTP のセキュリティーについて

Messaging Server は、ユーザー ID とパスワード認証、クライアント証明書認証、および Access Manager をサポートしています。ただし、クライアントとサーバー間におけるネットワーク接続の処理方法は、この 2 つのプロトコルでいくつか異なります。

POP、IMAP、または SMTP クライアントが Messaging Server にログインすると、接続が確立され、セッションが開始されます。この接続は、セッションの間中、すなわちログインからログアウトまで維持されます。新しい接続を確立する場合は、クライアントが再びサーバーで認証される必要があります。

HTTP クライアントが Messaging Server にログインする場合は、サーバーからクライアントに固有のセッション ID が与えられます。クライアントは、このセッション ID を使って、セッション中に複数の接続を確立できます。HTTP クライアントは接続するたびに再認証を行う必要はありません。ただし、セッションが切断された場合やクライアントが新しいセッションを確率する必要がある場合だけは、クライアントが、再び認証を行う必要があります。指定した時間にわたり HTTP セッションのアイドル状態が続くと、サーバーは自動的に HTTP セッションを切断し、クライアントがログアウトされます。デフォルトの時間は 2 時間です。

HTTP セッションのセキュリティーを向上させるには、次の方法を使用します。

設定パラメータを指定して接続のパフォーマンスを向上させる方法については、第 5 章「POP、IMAP、および HTTP サービスの設定」を参照してください。

Access Manager の詳細については、第 6 章「シングルサインオン (SSO) の有効化」を参照してください。

認証メカニズムを構成する

認証メカニズムは、クライアントが識別情報をサーバーに提示する方法の 1 つです。Messaging Server は SASL (Simple Authentication and Security Layer) プロトコルで定義されている認証方法をサポートし、さらに、証明書に基づく認証もサポートします。この節では、SASL による認証メカニズムについて説明します。証明書に基づく認証の詳細は、「暗号化と証明書に基づく認証を構成する」を参照してください。

Messaging Server は、パスワードに基づく認証の場合、次の SASL 認証方法をサポートします。


注 –

この機能は、推奨されておらず、将来のリリースで削除される予定です。


チャレンジ/応答型の認証メカニズムでは、サーバーからクライアントにチャレンジ文字列が送られます。クライアントは、そのチャレンジのハッシュとユーザーのパスワードを使用して応答します。クライアントの応答がサーバー自体のハッシュと一致すると、ユーザーが認証されます。ハッシュは元のデータに戻すことができないため、ネットワークを介して送信してもユーザーのパスワードが危険にさらされることはありません。


注 –

POP、IMAP、および SMTP サービスは、すべての SASL メカニズムをサポートします。HTTP サービスは、プレーンテキストパスワードによるメカニズムだけをサポートします。


表 19–1 に、SASL および SASL 関連の configutil パラメータの一部を示します。configutil パラメータがもっとも多く挙げられている最新のリストについては、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』「configutil Parameters」を参照してください。

表 19–1 SASL および SASL 関連の configutil パラメータの一部

パラメータ 

説明 

sasl.default.ldap.has_plain_passwords

ブール代数値です。ディレクトリがプレーンテキストパスワードを格納していることを示します。この値により APOP、CRAM-MD5、および DIGEST-MD5 が有効になります。 

デフォルト: False 

sasl.default.transition_criteria

サポートされず使用されません。sasl.default.auto_transition を参照してください。

sasl.default.auto_transition

ブール型です。設定し、ユーザーがプレーンテキストのパスワードを入力した場合、パスワード保存形式がディレクトリサーバーのデフォルトのパスワード保存形式に移行されます。プレーンテキストのパスワードから、APOP、CRAM-MD5 または DIGEST-MD5 への移行に使用することができます。 

デフォルト: False 

service.imap.allowanonymouslogin

IMAP による使用のため、SASL ANONYMOUS メカニズムを有効にします。 

デフォルト: False 

service.{imap|pop|http}.plaintextmincipher

0 より大きな値に設定すると、セキュリティーレイヤー (SSL または TLS) が有効でない限り、プレーンテキストのパスワードの使用を無効にします。これによりユーザーは、ログインする自分のクライアントで SSL または TLS を強制的に有効にすることになり、自分のパスワードがネットワーク上で漏洩することを防ぎます。MMP には同等のオプション「RestrictPlainPasswords」があります。 

注: Messaging Server の 5.2 リリースでは、SSL または TLS が使用する暗号の強度の数値が調べられます。この機能はオプションの簡潔化のため、また一般的な使用法に合わせるため削除されました。 

デフォルト: 0 

sasl.default.mech_list

有効にする SASL メカニズムの、スペース区切りのリストです。空でない場合、この設定は sasl.default.ldap.has_plain_passwords オプションおよび service.imap.allowanonymouslogin オプションよりも優先します。このオプションは、すべてのプロトコル (imap、pop、smtp) に適用されます。

デフォルト: False 

sasl.default.ldap.searchfilter

ユーザーがドメインの inetDomainSearchFilter に指定されていない場合に、ユーザーの検索に使用されるデフォルトの検索フィルタです。構文は inetDomainSearchFilter と同じです (スキーマガイドを参照)。

デフォルト: (&(uid=%U)(objectclass=inetmailuser))

sasl.default.ldap.searchfordomain

デフォルトでは、認証システムは LDAP 内のドメインをドメイン検索のルールに従って検索し (参照は必要)、その後ユーザーを検索します。ただし、このオプションがデフォルトの「1」ではなく「0」に設定されている場合、ドメイン検索は行われず、sasl.default.ldap.searchfilter を使用したユーザーの検索が local.ugldapbasedn で指定した LDAP ツリーの直下で行われます。旧バージョンの単一ドメインスキーマとの互換性のために提供されていますが、小さな企業であっても合併や名称変更により複数ドメインのサポートが必要になる可能性があるため、新しい配備のための使用にはお勧めしません。

プレーンテキストパスワードへのアクセスを構成するには

CRAM-MD5、DIGEST-MD5、または APOP SASL の認証メソッドでは、ユーザーのプレーンテキストパスワードにアクセスする必要があります。次の手順を実行する必要があります。

  1. パスワードがクリアテキストで保存されるように Directory Server を構成します。

  2. Directory Server がクリアテキストのパスワードを使用していることを認識できるように、Messaging Server を構成します。

Procedureパスワードがクリアテキストで保存されるように Directory Server を構成するには

CRAM-MD5、DIGEST-MD5、または APOP メカニズムを有効にするには、次のようにパスワードがクリアテキストで保存されるように Directory Server を構成する必要があります。

手順
  1. コンソールで、構成する Directory Server を開きます。

  2. 「設定」タブをクリックします。

  3. 左のペインで「Data」を開きます。

  4. 右のペインで「パスワード」をクリックします。

  5. 「パスワードの暗号化」ドロップダウンリストで「cleartext」を選択します。


    注 –

    この変更は、将来作成するユーザーにのみ影響を与えます。既存のユーザーは、この変更を加えたあとで移行するか、パスワードを再設定する必要があります。


クリアテキストのパスワード用に Messaging Server を設定するには

次に、Directory Server がクリアテキストのパスワードを使用していることを認識できるように Messaging Server を構成することができます。これにより、Messaging Server で APOP、CRAM-MD5、および DIGEST-MD5 を安全に使用できるようになります。

configutil -o sasl.default.ldap.has_plain_passwords -v 1

値を 0 に設定すると、これらのチャレンジ/応答型の SASL メカニズムを無効にすることができます。


注 –

既存のユーザーは、パスワードを再設定または移行するまで APOP、CRAM-MD5、または DIGEST-MD5 を使用できません (次の「ユーザーを移行するには」を参照)。

MMP には同等のオプション「CRAM」があります。


ユーザーを移行するには

configutil を使用して、移行するユーザーに関する情報を指定できます。たとえば、ユーザーパスワードを変更する場合や、適切なユーザーエントリがないメカニズムを使ってクライアントが認証を試みている場合に、この情報を指定します。

configutil -o sasl.default.auto_transition -v value

value には、次のいずれかを指定できます。

ユーザーを正常に移行するには、Messaging Server がユーザーパスワード属性に書き込みアクセスできるように、Directory Server の ACI を設定する必要があります。そのためには、次の手順を実行します。

Procedureユーザーを移行するには

手順
  1. コンソールで、構成する Directory Server を開きます。

  2. 「ディレクトリ」タブをクリックします。

  3. ユーザー/グループツリーのベースサフィックスを選択します。

  4. 「オブジェクト」メニューから「アクセス権を設定」を選択します。

  5. 「Messaging Server End User Administrator Write Access Rights (Messaging Server エンドユーザー管理者書き込みアクセス権)」に対する ACI を選択 (ダブルクリック) します。

  6. 「ACI 属性」をクリックします。

  7. 既存の属性のリストに userpassword 属性を追加します。

  8. 「了解」をクリックします。

    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 は、ホップ間の暗号化を提供しますが、中間にある各サーバー上ではメッセージは暗号化されません。


注 –

送信メッセージの暗号化を有効にするには、チャネル定義を変更して、maytlsmusttls などの tls チャネルキーワードを追加する必要があります。詳細は、「Transport Layer Security」のマニュアルを参照してください。


SSL 接続を設定する際のオーバーヘッドによって、サーバーのパフォーマンスが低下する可能性があります。メッセージングシステムの設計とパフォーマンスの分析を行う際には、セキュリティー要件とサーバーのパフォーマンスのバランスをとる必要があります。


注 –

SSL はすべての Sun Java System サーバーでサポートされており、SSL の有効化と設定を行うために使用するコンソールインタフェースは多くのサーバーでほとんど同じです。そのため、この章で説明するタスクのいくつかについては、『Managing Servers with iPlanet Console』に詳しい説明が記載されています。それらのタスクについては、この章では要約だけを説明します。


管理コンソールからの証明書の入手

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 モジュールをインストールするには、次の手順を実行します。

  1. カードリーダーハードウェアを Messaging Server ホストマシンに接続し、ドライバをインストールします。

  2. コンソールの「PKCS #11 Management」インタフェースを使用して、インストールしたドライバ用の PKCS #11 モジュールをインストールします。

詳細な手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。

ハードウェア暗号化アクセラレータのインストール暗号化用に SSL を使用する場合は、ハードウェア暗号化アクセラレータをインストールすることによって、メッセージの暗号化と解読のパフォーマンスを向上させることができます。一般的に、暗号化アクセラレータは、サーバーマシンに常設されたハードウェアボードとソフトウェアドライバで構成されます。Messaging Server は、PKCS #11 API に準拠したアクセラレータモジュールをサポートしています。これらは、基本的に独自のキーを格納しないハードウェアトークンで、キーの格納には内部データベースが使用されます。まず、製造元の指示に従ってハードウェアとドライバをインストールすることにより、アクセラレータをインストールします。その後、PKCS #11 モジュールをインストールすることにより、ハードウェア証明書トークンをインストールします。

Procedureサーバー証明書を要求するには

サーバー証明書を要求するには、コンソールでサーバーを開き、「証明書セットアップウィザード」を実行します。このウィザードには、「コンソール」メニューまたは Messaging Server の「暗号化」タブからアクセスできます。このウィザードを使用して、次のタスクを実行します。

手順
  1. 証明書要求を作成します。

  2. 電子メールを使用して、証明書を発行する認証局 (CA) に要求を送信します。

    認証局 (CA) から電子メールによる応答を受け取ったら、メールをテキストファイルとして保存し、証明書セットアップウィザードを使用してそのファイルをインストールします。

    詳細な手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください。

Procedure証明書をインストールするには

インストールは、要求とは別の手順で実行します。認証局 (CA) から証明書要求に対する応答の電子メールを受け取ったら、電子メールをテキストファイルとして保存し、もう一度証明書セットアップウィザードを実行して、次のように証明書としてファイルをインストールします。

手順
  1. 入手済みの証明書をインストールすることを指定します。

  2. 指示に従って、証明書のテキストをフィールド内に貼り付けます。

  3. 証明書のニックネームを server-cert から Server-Cert に変更します。

    証明書のニックネームを変更したくない場合は、configutil パラメータ encryption.rsa.nssslpersonalityssl を設定して、使用したい証明書ニックネームを変更することができます。

    詳細な手順については、『Managing Servers with iPlanet Console』の SSL に関する章を参照してください


    注 –

    CA の証明書 (以下に説明) をインストールする場合にも、この手順を実行する必要があります。サーバーはこの証明書を使用して、クライアントによって提示された証明書の信頼性を判断します。


信頼できる 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 から発行されるクライアント証明書を信頼できるものにする必要がある場合は、信頼設定を編集する必要があります。この手順については、153 ページの「証明書と信頼できる CA の管理」を参照してください。


新しい CA 証明書を要求してインストールするには、次の手順を実行します。

Procedure新しい CA 証明書を要求してインストールするには

手順
  1. Web ページからまたは電子メールを利用して認証局に連絡し、その CA 証明書をダウンロードします。

  2. 受け取った証明書のテキストをテキストファイルとして保存します。

  3. 証明書セットアップウィザードを使用し、前の節で説明した手順に従って証明書をインストールします。

    詳細な手順については、『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!

内部証明書をインストールするときにデフォルト以外のパスワードを指定する場合は、指定するパスワードに合わせてパスワードファイル内の上記の行を編集する必要があります。外部モジュールをインストールする場合は、ファイルに新しい行を追加し、モジュール名とモジュール用に指定するパスワードを記述する必要があります。


注意 – 注意 –

管理者はサーバー起動時にモジュールパスワードの入力を要求されません。そのため、管理者のアクセスが適切に制御されていること、およびサーバーホストマシンとそのバックアップの物理的なセキュリティーが確保されていることの確認が重要になります。


自己署名済み証明書を作成するには

コマンド行モードで自己署名済み証明書を作成する場合は、この節の手順に従います。証明書ウィザードで証明書を作成するには、「管理コンソールからの証明書の入手」を参照してください。

Procedure自己署名済み証明書を作成するには

手順
  1. スーパーユーザー (root) としてログインします。

  2. /opt/SUNWmsgsr/config/sslpasswordcertutil の証明書データベースのパスワードを指定します。例:


    # echo "password" > /opt/SUNWmsgsr/config/sslpassword

    password は、ユーザー固有のパスワードです。

  3. sbin ディレクトリに移動し、証明書データベース (cert8.db) とキーのデータベース (key3.db) を生成します。例:


    # cd /opt/SUNWmsgsr/sbin
    # ./certutil -N -d /opt/SUNWmsgsr/config -f /opt/SUNWmsgsr/config/sslpassword
  4. デフォルトの自己署名済みルート認証局証明書を生成します。次に例を示します。


    # ./certutil -S -n SampleRootCA -x -t "CTu,CTu,CTu"
    -s "CN=My Sample Root CA, O=sesta.com" -m 25000
    -o /opt/SUNWmsgsr/config/SampleRootCA.crt
    -d /opt/SUNWmsgsr/config
    -f /opt/SUNWmsgsr/config/sslpassword   -z /etc/passwd
  5. ホストの証明書を生成します。例:


    ../certutil -S -n Server-Cert -c SampleRootCA -t "u,u,u"
    -s "CN=hostname.sesta.com, o=sesta.com" -m 25001
    -o /opt/SUNWmsgsr/config/SampleSSLServer.crt
    -d /opt/SUNWmsgsr/config -f /opt/SUNWmsgsr/config/sslpassword
    -z /etc/passwd

    hostname.sesta.com は、サーバーホスト名です。

  6. 証明書の妥当性を検査します。例:


    # ./certutil -V -u V -n  SampleRootCA -d /opt/SUNWmsgsr/config
    # ./certutil -V -u V -n  Server-Cert -d /opt/SUNWmsgsr/config
  7. 証明書を列挙します。例:


    # ./certutil -L -d /opt/SUNWmsgsr/config
    # ./certutil -L -n Server-Cert -d /opt/SUNWmsgsr/config
  8. modutil を使って、使用可能なセキュリティーモジュール (secmod.db) を列挙します。例:


    # ./modutil -list -dbdir /opt/SUNWmsgsr/config
  9. 次の例が示すように、証明書データベースファイルの所有者をメールサーバーのユーザーおよびグループに変更します。


    chown mailsrv:mail /opt/SUNWmsgsr/config/cert8.db
    chown mailsrv:mail /opt/SUNWmsgsr/config/key3.db
    
  10. メッセージングサービスを再起動して、SSL を有効にします。


    注 –

    以前は、証明書とキーファイルは常に Messaging Server の設定ディレクトリにありました。現在は、local.ssldbpath (証明書とキーファイルの場所を指定する) および local.ssldbprefix (証明書とキーファイルのプレフィックスを指定する) を使用して、これらのファイルの場所を指定できます。


SSL を有効化し暗号化方式を選択するには

コンソールを使用すると、SSL を有効にし、Messaging Server がクライアントとの暗号通信で使用できる暗号化方式を選択できます。

暗号化方式について

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

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

クライアントは、Messaging Server と SSL 接続を開始するときに、サーバーに対して、希望する暗号化用の暗号化方式とキー長を伝えます。暗号化された通信では、両方の通信者が同じ暗号化方式を使用する必要があります。一般的に使用される暗号化方式とキーの組み合わせは数多くあります。そのため、サーバーは柔軟な暗号化サポートを提供する必要があります。Messaging Server では、最大 6 つの暗号化方式とキー長の組み合わせをサポートできます。

表 19–2 に、Messaging Server が SSL 3.0 を使用する場合にサポートする暗号化方式の一覧を示します。この表には概要を記載しています。詳細は、『 Managing Servers with iPlanet Console』の「Introduction to SSL」を参照してください。

表 19–2 Messaging Server の SSL 暗号化方式

暗号化方式 

説明 

128 ビットの暗号化と MD5 メッセージ認証を使用した RC4 

RSA が提供する暗号化方式で、もっとも高速で、もっとも強度の高い暗号化方式と暗号化キーの組み合わせを提供します。 

168 ビットの暗号化と SHA メッセージ認証を使用した DES 

米国政府の標準となっている暗号化方式で、低速で、強度の高い暗号化方式と暗号化キーの組み合わせを提供します。 

56 ビットの暗号化と SHA メッセージ認証を使用した DES 

米国政府の標準となっている暗号化方式で、低速で、中程度の強度の暗号化方式と暗号化キーの組み合わせを提供します。 

40 ビットの暗号化と MD5 メッセージ認証を使用した RC4 

RSA が提供する暗号化方式で、もっとも高速で、強度の低い暗号化方式と暗号化キーの組み合わせを提供します。 

40 ビットの暗号化と MD5 メッセージ認証を使用した RC2 

RSA が提供する暗号化方式で、低速で、強度の低い暗号化方式と暗号化キーの組み合わせを提供します。 

暗号化なし、MD5 メッセージ認証のみ 

暗号化を使用せず、認証用のメッセージダイジェストのみを使用します。 

特定の暗号化方式を使わないようにする妥当な理由がないかぎり、すべての暗号化方式をサポートする必要があります。ただし、特定の暗号化方式の使用が法律で制限されている国もあります。また、米国の輸出規制法規が緩和される前に開発されたクライアントソフトウェアの中には、強度の高い暗号化を使用できないものもあります。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 は、カンマで区切られた暗号化方式のリストです。


注 –

送信メッセージの暗号化を有効にするには、チャネル定義を変更して、maytlsmusttls などの tls チャネルキーワードを追加する必要があります。詳細は、「Transport Layer Security」のマニュアルを参照してください。


証明書に基づくログインを設定するには

Sun Java System サーバーでは、パスワードに基づくログインに加えて、デジタル証明書の確認によるユーザー認証もサポートしています。証明書に基づく認証では、クライアントはサーバーとの SSL セッションを確立し、ユーザーの証明書をサーバーに提出します。その後、サーバーが、提出された証明書の信頼性を評価します。証明書の信頼性が確認されると、そのユーザーは認証済みであるとみなされます。

証明書に基づくログインを実行できるように Messaging Server を設定するには、次の手順を実行します。

Procedure証明書に基づくログインを設定するには

手順
  1. 使用しているサーバー用の証明書を入手します(詳細は「管理コンソールからの証明書の入手」を参照)。

  2. 証明書セットアップウィザードを実行して、サーバーが認証するユーザーに証明書を発行する、信頼できる認証局の証明書をインストールします (詳細は「信頼できる CA の証明書をインストールするには」を参照)。

    サーバーのデータベース内に信頼できる CA の証明書が 1 つでもあるかぎり、サーバーは接続するクライアントに対してクライアント証明書を要求します。

  3. SSL を有効にします(詳細は「SSL を有効化し暗号化方式を選択するには」を参照)。

  4. サーバーが提出された証明書の情報に基づいて 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 プロキシのインストール方法については、「POP before SMTP を有効にする」を参照してください。

ネットワークセキュリティーサービスツール

ネットワークセキュリティーサービスとは、オープン規格に基づいたインターネットセキュリティーのためのアプリケーションを実装および配備するのに使用するオープンソースのライブラリおよびツールのセットのことです。セキュリティーツールは、診断の実行、証明書、キーおよび暗号化モジュールの管理、また SSL および TLS ベースのアプリケーションのデバッグに役立ちます。これらのツールは、/usr/sfw/bin にあります。

証明書とキーの管理

ここで説明するツールは、暗号化および識別に利用するキーおよび証明書を保存、取得、および保護します。

certutil

証明書データベースツールの certutil は、cert8.db および key3.db データベースファイルを作成および変更できるコマンド行ユーティリティーです。キーおよび証明書管理プロセスは、一般にキーをキーのデータベースに作成することから始まり、それから証明書を証明書データベースに生成して管理します。certutil については、次の URL を参照してください。

http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html

cmsutil

cmsutil コマンド行ユーティリティーは、S/MIME ツールキットを使用して、暗号化メッセージ構文 (Cryptographic Message Syntax、CMS) メッセージに対する暗号化や復号化などの基本的な操作を実行します。このユーティリティーは、メッセージの暗号化、復号化、および署名などの基本的な証明書管理操作を実行します。cmsutil については、次の URL を参照してください。

http://www.mozilla.org/projects/security/pki/nss/tools/cmsutil.html

modutil

セキュリティーモジュールデータベースツールの modutil は、PKCS #11 モジュール (secmod.db ファイル) のデータベースの管理用のコマンド行ユーティリティーです。このツールを使用して、PKCS #11 モジュールを追加および削除し、パスワードを変更し、デフォルトを設定し、モジュールの内容を表示し、スロットを使用可または使用不可にし、FIPS-140-1 準拠を有効または無効にし、暗号化操作にデフォルトのプロバイダを割り当てることができます。modutil については、次の URL を参照してください。

http://www.mozilla.org/projects/security/pki/nss/tools/modutil.html

pk12util

pk12util コマンド行ユーティリティーは、PKCS #12 規格で定義された、キーと証明書の両方を、対応するデータベースに対して、また対応するファイル形式でインポートおよびエクスポートします。pk12util については、次の URL を参照してください。

http://www.mozilla.org/projects/security/pki/nss/tools/pk12util.html

ssltap

SSL デバッグツールの ssltap は、SSL 対応のコマンド行プロキシです。このツールは、SSL サーバーに対して要求を代理処理し、クライアントとサーバー間で交換されるメッセージの内容を表示できます。このツールは、TCP 接続を監視し、通過するデータを表示します。接続が SSL の場合は、表示されるデータには解釈された SSL レコードとハンドシェーキングが含まれます。詳細は、次の URL を参照してください。

http://www.mozilla.org/projects/security/pki/nss/tools/ssltap.html

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 を使用している場合) を実装することができます。

  1. 構成管理者: Sun Java System サーバーネットワークの「スーパーユーザー」。すべてのリソースに対する完全なアクセス権を持ちます。

  2. サーバー管理者: ドメイン管理者は、各タイプのサーバーを管理するためのグループを作成することがあります。たとえば、管理ドメイン内またはネットワーク全体にあるすべての Messaging Server を管理するためにメッセージング管理者グループを作成する場合があります。このグループのメンバーは、その管理ドメイン内のすべての Messaging Server にアクセスできます (ほかのサーバーにはアクセス不可)。

  3. タスク管理者: 上記のすべての管理者は、単一または複数の Messaging Server に対する制限付きアクセス権を持つグループを作成したり、そのようなアクセス権を持つ個別のユーザーを指定したりできます。指定されたタスク管理者は、特定の制限されたサーバータスク (サーバーの起動または停止、特定のサービスのログへのアクセス) だけを実行できます。

管理者は、コンソールが提供する便利なインタフェースを使用して、次のタスクを実行できます。

Procedureサーバー全体に対するアクセス権を与えるには

この章では、ユーザーまたはグループに Messaging Server の特定のインスタンスに対するアクセス権を与える方法について説明します。

手順
  1. アクセス権を与える対象の Messaging Server へのアクセス権を持っている管理者として、コンソールにログインします。

  2. 「コンソール」ウィンドウでそのサーバーを選択します。

    「コンソール」ウィンドウのメニューから「オブジェクト」を選択し、「アクセス権の設定」を選択します。

  3. そのサーバーへのアクセス権を持つユーザーおよびグループのリストに対する追加や編集を行います。

    詳細な手順については、『Managing Servers with iPlanet Console』のサーバー管理の委任に関する章を参照してください。

    特定の Messaging Server へのアクセス権を持つユーザーおよびグループのリストの設定が済んだら、次に説明する ACI を使用して、特定のサーバータスクをリスト内の特定のユーザーまたはグループに委任することができます。

特定タスクへのアクセスを限定するには

一般的に、管理者はサーバーに接続して 1 つ以上の管理タスクを実行します。コンソールの「Messaging Server タスク」フォームには、頻繁に実行される管理タスクが一覧表示されます。

デフォルトでは、特定の Messaging Server にアクセスできると、そのサーバーのすべてのタスクにアクセスできます。ただし、タスクフォーム内の各タスクには、一連のアクセス制御インストラクション (ACI) を関連付けることができます。サーバーは、接続しているユーザー (サーバー全体に対するアクセス権をすでに持っているユーザー) にタスクへのアクセス権を与える前に、これらの ACI を参照します。実際、タスクフォームには、そのユーザーがアクセス権を持っているタスクだけが表示されます。

Messaging Server へのアクセス権がある場合は、アクセスできる任意のタスクに関する ACI を作成または編集して、ほかのユーザーやグループがそのタスクに対して持つことができるアクセス権を制限できます。

Procedureユーザーまたはグループのタスクアクセス権を制限するには

手順
  1. 制限付きアクセス権を与える対象の Messaging Server へのアクセス権を持っている管理者として、コンソールにログインします。

  2. サーバーを開き、そのサーバーのタスクフォームで、タスクのテキストをクリックして、タスクを選択します。

  3. 「編集」メニューの「アクセス権の設定」を選択し、アクセスルールのリストに対する追加や編集を行い、ユーザーまたはグループに必要なアクセス権を与えます。

  4. 必要に応じて、ほかのタスクについて同じ手順を繰り返します。

    詳細な手順については、『Managing Servers with iPlanet Console』のサーバー管理の委任に関する章を参照してください。

    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 には、サービス名 (smtppopimaphttp など) を指定し、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

serviceSpecservice または service@hostSpec のどちらかを示し、clientSpechostSpec または 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 エントリで構成されます。serviceListclientList 内の各エントリは、空白またはカンマで区切ります。

この場合、フィルタが処理されるときに、アクセス要求元のクライアントが、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:*

ワイルドカード名

次のワイルドカード名を使用して、サービス名、ホストの名前やアドレス、またはユーザー名を表すことができます。

表 19–3 サービスフィルタのワイルドカード名

ワイルドカード名 

説明 

ALL, *

汎用のワイルドカードです。すべての名前に一致します。 

LOCAL

すべてのローカルホスト (ドット文字を含まない名前を持つホスト) に一致します。ただし、正規名のみを使用しているシステムの場合は、ローカルホスト名もドットを含むため、このワイルドカードに一致しません。 

UNKNOWN

名前が不明なすべてのユーザー、あるいは名前またはアドレスが不明なすべてのホストに一致します。 

このワイルドカード名は、次のことに注意して使用する必要があります。 

一時的な DNS サーバーの問題により、ホスト名が使用できなくなる場合があります。このような場合、UNKNOWN を使用しているすべてのフィルタはすべてのクライアントホストに一致します。

ソフトウェアが通信相手のネットワークのタイプを識別できない場合は、ネットワークアドレスを使用できません。そのような場合、UNKNOWN を使用しているすべてのフィルタは、そのネットワーク上にあるすべてのクライアントホストに一致します。

KNOWN

名前が認識されているすべてのユーザー、または名前およびアドレスが認識されているすべてのホストに一致します。

このワイルドカード名は、次のことに注意して使用する必要があります。 

一時的な DNS サーバーの問題により、ホスト名が使用できなくなる場合があります。このような場合、KNOWN を使用しているすべてのフィルタはどのクライアントホストにも一致しません。

ソフトウェアが通信相手のネットワークのタイプを識別できない場合は、ネットワークアドレスを使用できません。そのような場合、KNOWN を使用しているすべてのフィルタは、そのネットワーク上にあるどのクライアントホストにも一致しません。

DNSSPOOFER

IP アドレスと DNS 名が一致しないすべてのホストに一致します。 

ワイルドカードのパターン

サービスまたはクライアントアドレスを指定するときは、次のパターンを使用できます。

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 サービスによって返されるユーザー名 (またはワイルドカード名) です。

フィルタ内でクライアントユーザー名を指定すると便利ですが、次のことに注意する必要があります。

ユーザー名検索の機能は、クライアントホスト上の承認されていないユーザーからの攻撃を防ぐために役立つ場合があります。たとえば、一部の 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 セッションにしか適用されないため、あまり価値はありません。第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

Procedureフィルタを作成するには

手順
  1. コンソールで、アクセスフィルタを作成する Messaging Server を開きます。

  2. 「設定」タブをクリックします。

  3. 左のペインで「サービス」フォルダを開き、そのフォルダの下にある「IMAP」、「POP」、または「HTTP」を選択します。

  4. 右のペインの「アクセス」タブをクリックします。

    このタブの「許可」フィールドと「拒否」フィールドに、そのサービスの既存の許可フィルタと拒否フィルタが表示されます。フィールド内の各行がそれぞれ 1 つのフィルタを表します。どちらのフィールドに対しても、次の操作を実行できます。

    1. 新しいフィルタを作成する場合は、「追加」をクリックします。「許可フィルタ」ウィンドウまたは「拒否フィルタ」ウィンドウが表示されます。ウィンドウに新しいフィルタのテキストを入力し、「了解」をクリックします。

    2. フィルタを編集する場合は、フィルタを選択して「編集」をクリックします。「許可フィルタ」ウィンドウまたは「拒否フィルタ」ウィンドウが表示されます。ウィンドウに表示されたフィルタのテキストを編集し、「了解」をクリックします。

    3. フィルタを削除する場合は、フィルタを選択して「削除」をクリックします。

      許可フィルタまたは拒否フィルタの順序を変更する必要がある場合は、フィルタが適切な順序になるまで、削除と追加の操作を繰り返します。

      フィルタの構文の指定方法とさまざまな例については、「フィルタの構文」および 「フィルタの例」を参照してください。

      コマンド行

      次のように、コマンド行を使用して許可フィルタや拒否フィルタを指定することもできます。

      各サービス用のアクセスフィルタを作成または編集するには、次のように入力します。


      configutil -o service.service.domainallowed -v filter
      

      service には popimaphttp のいずれかを指定し、filter「フィルタの構文」で説明した構文ルールに従って指定します。

      各サービス用の拒否フィルタを作成または編集するには、次のように入力します。


      configutil -o service.service.domainnotallowed -v filter
      

      service には popimaphttp のいずれかを指定し、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 の担当者に問い合わせてください。

ProcedureHTTP プロキシ認証用のアクセスフィルタを作成するには

手順
  1. コンソールで、アクセスフィルタを作成する Messaging Server を開きます。

  2. 「設定」タブをクリックします。

  3. 左のペインで「サービス」フォルダを開き、そのフォルダの下にある「HTTP」を選択します。

  4. 右のペインの「プロキシ」タブをクリックします。

    このタブの「許可」フィールドに、既存のプロキシ認証用の許可フィルタが表示されます。

  5. 新しいフィルタを作成する場合は、「追加」をクリックします。

    「許可フィルタ」ウィンドウが表示されます。ウィンドウに新しいフィルタのテキストを入力し、「了解」をクリックします。

  6. 既存のフィルタを編集する場合は、フィルタを選択して、「編集」をクリックします。

    「許可フィルタ」ウィンドウが表示されます。ウィンドウに表示されたフィルタのテキストを編集し、「了解」をクリックします。

  7. 既存のフィルタを削除する場合は、「許可」フィールドからフィルタを選択し、「削除」をクリックします。

  8. 「プロキシ」タブでの変更作業が終了したら、「保存」をクリックします。

    許可フィルタの構文については、「フィルタの構文」を参照してください。

    コマンド行

    次のように、コマンド行を使用して、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 サーバーに通知します。

ProcedureSMTP プロキシをインストールするには

手順
  1. Messaging Multiplexor (MMP) をインストールします。

    手順については、『Sun Java Enterprise System 2005Q4 インストールガイド』を参照してください。

  2. MMP 上で SMTP プロキシを有効にします。

    以下の文字列を

    msg_svr_base/lib/SmtpProxyAService@25|587

    msg_svr_base/config/AService.cfg ファイルの ServiceList オプションに追加します。このオプションは、1 行に記述し、改行を入れないようにします。


    注 –

    MMP をアップグレードすると、MMP 用の既存の 4 つの設定ファイルに対応する 4 つの新しいファイルが作成されます。そのファイルを次に示します。

    AService-def.cfgImapProxyAService-def.cfgPopProxyAService-def.cfgSmtpProxyAService-def.cfg

    これらのファイルは、インストーラによって作成されます。docs 内に記述された 4 つの設定ファイルは、インストールプロセスによって作成されず、また影響も受けません。MMP は、起動時に、通常の設定ファイルを検索します。通常の設定ファイルが見つからない場合、MMP は、それぞれの *AService-def.cfg ファイルをコピーして、対応する *AService.cfg という名前を付けます。


  3. 各 SMTP リレーサーバー上で、SMTP チャネルオプションファイル tcp_local_optionPROXY_PASSWORD オプションを設定します。

    SMTP プロキシは、SMTP サーバーに接続する際に、実際の IP アドレスとその他の接続情報を SMTP サーバーに通知する必要があります。この情報により、SMTP サーバーは、リレーブロッキングやその他のセキュリティーポリシー (POP before SMTP を含む) を適切に適用できるようになります。この操作はセキュリティー上重要な操作であり認証される必要があります。MMP SMTP プロキシと SMTP サーバーの両方で構成されたプロキシパスワードにより、第三者によるこの機能の悪用が確実に防止されます。

    次に例を示します。PROXY_PASSWORD=A_Password

  4. MMP が SMTP サーバーに接続するために使用する IP アドレスが INTERNAL_IP マッピングテーブルによって「internal」として扱われていないことを確認します。

    INTERNAL_IP マッピングテーブルについては、第 17 章「メールのフィルタリングとアクセス制御」「SMTP リレーを追加するには」を参照してください。

  5. POP before SMTP をサポートするように SMTP プロキシを構成します。

    1. msg_svr_base/config/SmtpProxyAService.cfg 設定ファイルを編集します。

      次の SMTP プロキシオプションは、IMAP プロキシおよび POP プロキシの同名のオプションとまったく同じように機能します。第 7 章「マルチプレクササービスの設定および管理」を参照してください。また、これらのオプションについては、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』「Encryption (SSL) Option」を参照してください。

      LdapURLLogDirLogLevelBindDNBindPassTimeoutBannerSSLEnableSSLSecmodFileSSLCertFileSSLKeyFileSSLKeyPasswdFileSSLCipherSpecsSSLCertNicknamesSSLCacheDirSSLPortsCertMapFileCertmapDNConnLimitsTCPAccess

      上記のリストにないその他の MMP オプション (BacksidePort オプションを含む) は、現在のところ SMTP プロキシには適用されません。

      次の 5 つのオプションを追加します。

      SmtpRelays。このオプションは、スペースで区切られた SMTP リレーサーバーホスト名 (およびオプションのポート) のリストで、ラウンドロビンリレー用に使用されます。これらのリレーサーバーは、XPROXYEHLO 拡張キーワードをサポートしている必要があります。このオプションは必須で、デフォルトはありません。

      : default:SmtpRelays manatee:485 gonzo mothra

      SmtpProxyPassword。SMTP リレーサーバー上でソースチャネルの変更を認証するために使用されるパスワードです。このオプションは必須で、デフォルト値はありません。また、SMTP サーバー上の PROXY_PASSWORD オプションと一致している必要があります。

      : default:SmtpProxyPassword A_Password

      EhloKeywords。このオプションは、プロキシがクライアントを通過させるために使用する、EHLO 拡張キーワードのリストを提供します。また、デフォルト値のセットも提供します。MMP は、SMTP リレーから返される EHLO のリストから、認識できない EHLO キーワードをすべて削除します。EhloKeywords は、リストから削除されない追加の EHLO キーワードを指定します。デフォルト値は空白ですが、SMTP プロキシは次のキーワードをサポートするので、これらのキーワードをこのオプションで指定する必要はありません。8BITMIMEPIPELININGDSNENHANCEDSTATUSCODESEXPNHELPXLOOPETRNSIZESTARTTLSAUTH

      次に、使用頻度の少ない「TURN」拡張キーワードを使用するサイトで使用できる指定例を示します。

      : default:EhloKeywords TURN

      PopBeforeSmtpKludgeChannel オプション。POP before SMTP で認証される接続で使用する MTA チャネルの名前に設定されます。デフォルトは空で、POP before SMTP を有効にするユーザーに対する通常の設定は tcp_intranet です。SSL のパフォーマンスを最適化するためにこのオプションを指定する必要はありません (「SMTP プロキシを使用した SSL パフォーマンスの最適化方法」を参照)。

      : default:PopBeforeSmtpKludgeChannel tcp_intranet

      ClientLookup。このオプションはデフォルトで no に設定されます。yes に設定すると、クライアントの IP アドレスに関する DNS 逆引き検索が無条件に実行されるため、SMTP リレーサーバーで検索を行う必要がなくなります。このオプションは、ホストしているドメインごとに設定できます。

      : default:ClientLookup yes

    2. PopProxyAService.cfg 設定ファイルに PreAuth オプションと AuthServiceTTL オプションを設定します。SSL のパフォーマンスを最適化するためにこのオプションを指定する必要はありません (「SMTP プロキシを使用した SSL パフォーマンスの最適化方法」を参照)。

      これらのオプションは、POP 認証後にユーザーがメールの送信を許可される時間を秒単位で指定します。一般的な設定は、900 〜 1800 (15 〜 30 分) です。

      :


      default:PreAuth yes
      default:AuthServiceTTL 900
    3. オプションで、MMP が、SMTP リレーからの応答を待つ時間を秒単位で指定することができます。この時間が経過すると MMP はリスト内の次の SMTP リレーを試行します。

      デフォルトは 10 (秒) です。SMTP リレーへの接続が失敗すると、MMP は、このフェイルオーバータイムアウトと同じ時間 (分単位) が経過するまで、そのリレーへの接続を試行しません。つまり、フェイルオーバータイムアウトが 10 秒のときに、あるリレーへの接続が失敗したとすると、MMP は、10 分間経過するまでそのリレーを再試行しません。

      : default:FailoverTimeout 10

SMTP サービスへのクライアントアクセスを構成する

SMTP サービスへのクライアントアクセスの構成方法については、第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

SSL を使用したユーザーまたはグループディレクトリの検索

MTA、MMP、および IMAP/POP/HTTP の各サービスに対して、SSL によるユーザーディレクトリまたはグループディレクトリの検索を行うことができます。この機能を使用するためには、Messaging Server を SSL モードで構成しておく必要があります。この機能を有効にするには、configutil パラメータのlocal.service.pab.ldapport636 に設定し、local.ugldapport636 に設定し、local.ugldapusessl1 に設定します。