前へ     目次     索引     DocHome     次へ     
iPlanet Messaging Server 5.2 管理者ガイド



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


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

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

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



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

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

サーバのセキュリティはさまざまな方法で攻撃される可能性があるため、さまざまな方法でセキュリティを強化します。この章では、暗号化、認証、およびアクセス制御の設定を中心に、次の Messaging Server のセキュリティに関する項目について説明します。

  • ユーザ ID とパスワードログイン : ユーザは、IMAP、POP、HTTP、または SMTP にログインするためにユーザ ID とパスワードを入力する必要があります。また、メッセージの受取人に差出人の認証情報を送信するには、SMTP パスワードログインを使用する必要があります。

  • 暗号化と認証 : TLS プロトコルおよび SSL プロトコルを使用して通信を暗号化し、クライアントを認証するようにサーバを設定します。

  • 管理者のアクセス制御 : Netscape Console のアクセス制御機能を使って、Messaging Server へのアクセス権や個別のタスクを委任します。

  • TCP クライアントアクセス制御 : フィルタリング技術を使用して、サーバの POP、IMAP、HTTP、および 認証済み SMTP サービスに接続できるクライアントを制御します。

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

  • 物理的なセキュリティ : サーバマシンを物理的に保護しないと、ソフトウェアのセキュリティは意味を持たない場合があります。

  • メッセージの暗号化 (S/MIME) : S/MIME (Secure Multipurpose Internet Mail Extensions) を使用すると、差出人はメッセージを暗号化して送信し、受取人は暗号化されたメッセージを受け取って保存し、メッセージを読む場合にのみ解読することができるようになります。S/MIME は、Messaging Server に関する特別な設定や作業をしなくても利用できます。S/MIME は、クライアントでだけ使用できます。S/MIME の設定方法については、使用するクライアントのマニュアルを参照してください。Messenger Express クライアントインタフェースは、電子メールメッセージの暗号化をサポートしません。

  • メッセージストアへのアクセス : Messaging Server に対して、複数のメッセージストア管理者を定義できます。これらの管理者は、メールボックスの表示と監視を行ったり、メールボックスへのアクセスを制御したりできます。詳細は、第 11 章「メッセージストアを管理する」を参照してください。

  • エンドユーザアカウントの設定 : エンドユーザアカウント情報は、主に Delegated Administrator 製品を使って管理します。詳細は、Delegated Administrator のマニュアルを参照してください。また、コンソールのインタフェースを使ってエンドユーザアカウントを管理することもできます。詳細は、付録 D「メールユーザとメーリングリストを管理する」を参照してください。

  • 不特定多数宛てメール (UBE) のフィルタリング : 第 10 章「メールのフィルタリングとアクセス制御」を参照してください。

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



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


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

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

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

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

  • セッション ID は、特定の IP アドレスにバインドされる

  • 各セッション ID には、タイムアウト値が関連付けられているので、指定時間にわたりセッション ID が使用されないと、そのセッション ID は無効になる

  • 使用中のすべてのセッション ID のデータベースをサーバが管理するため、クライアントは ID を偽造できない

  • セッション ID は、cookie ファイルではなく URL 内に保管される

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



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


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

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

  • PLAIN - このメカニズムは、ユーザのプレーンテキストパスワードをネットワーク経由で渡すので、パスワードが盗まれる可能性があります。

    この問題は、SSL を使用することによって軽減できます。詳細は、「暗号化と証明書に基づく認証を構成する」を参照してください。

  • DIGEST-MD5 - RFC 2831 で定義されているチャレンジ/レスポンス型の認証メカニズム。Messaging Multiplexor では、DIGEST-MD5 はサポートされていません。

  • CRAM-MD5 - APOP に似たチャレンジ/レスポンス型の認証メカニズムですが、他のプロトコルでの使用にも適しています。RFC 2195 に定義されています。

  • APOP - POP3 プロトコルでのみ使用できるチャレンジ/レスポンス型の認証メカニズム。RFC 1939 に定義されています。

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

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



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

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

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

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


パスワードが保存されるように Directory Server を構成するには

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

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

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

  3. 左のペインで「データベース」を開きます。

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

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

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



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 メカニズムを無効にすることができます。

注

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



ユーザを移行するには

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

configutil -o sasl.default.transition_criteria -v value

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

  • CHANGE - ユーザパスワードを変更する場合は、サーバがプレーンテキストを受け入れるように移行します。デフォルトでは、このキーワードが使用されます。

  • CLIENT - クライアントが適切なユーザエントリのないメカニズムを使用しようとしている場合、サーバはプレーンテキストのパスワードを使用して認証するようにクライアントに要求します。その後、サーバは、同じパスワード値を使用してそのメカニズム用の適切なエントリを作成します。

  • PLAIN - クライアントがプレーンテキストパスワードを使用する場合に、サーバがプレーンテキストを受け入れるように移行します。

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

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

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

  3. ユーザ/グループツリーのベース接尾辞を選択します。

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

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

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

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

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



ユーザパスワードログイン

Messaging Server にログインしてメールの送受信を行うには、ユーザがパスワードを入力する必要があります。これは承認されていないアクセスを防ぐための最初の防御手段です。Messaging Server では、IMAP、POP、HTTP、および SMTP の各サービスに対して、パスワードに基づくログインがサポートされています。


IMAP、POP、HTTP のパスワードログイン

デフォルトでは、内部ユーザは、Messaging Server からメッセージを取得するためにパスワードを送信する必要があります。POP、IMAP、HTTP のサービスごとにパスワードログインを有効または無効にできます。POP、IMAP、HTTP サービスのパスワードログインの詳細は、「パスワードに基づくログイン」を参照してください。

ユーザパスワードは、クリアテキストまたは暗号文 (POP を除く) の形式で、ユーザのクライアントソフトウェアからサーバに転送できます。クライアントとサーバの両方が、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 暗号化を使わずに使用することもできます。



暗号化と証明書に基づく認証を構成する


この節には、以下の項があります。

iPlanet Messaging Server では、クライアントとサーバ間で、暗号化された通信および証明書に基づく認証を行うために TLS (Transport Layer Security) プロトコルを使用します。TLS プロトコルは、SSL (Secure Sockets Layer) プロトコルとも呼ばれます。iPlanet Messaging Server は、SSL バージョン 3.0 および 3.1 をサポートしています。TLS には、SSL との完全な互換性があり、必要な SSL 機能がすべて含まれています。

SSL に関する背景情報については、『Managing Servers with Netscape Console』の付録の「Introduction to SSL」を参照してください。SSL は、公開鍵暗号化の概念に基づいています。この概念については、『Managing Servers with Netscape Console』の付録の「Introduction to Public-Key Cryptography」を参照してください。

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

SSL は、IMAP4、HTTP、および SMTP のアプリケーションレイヤの下のプロトコルレイヤとして機能します。SMTP と SMTP/SSL は同じポートを使用しますが、HTTP と HTTP/SSL は異なるポートを必要とします。IMAP と IMAP/SSL は、同じポートを使用することも異なるポートを使用することもできます。図 12-1 に示すように、SSL は、送信メッセージと受信メッセージの両方で、メッセージ通信の特定の段階で作用します。

図 12-1    Messaging Server での暗号化された通信

SSL は、ホップ間の暗号化を提供しますが、中間にある各サーバ上ではメッセージは暗号化されません。終端間の暗号化を実現するには、クライアントが S/MIME をサポートしている必要があります。

注

送信メッセージの暗号化を有効にするには、チャネル定義を変更して、maytls や musttls などの tls チャネルキーワードを追加する必要があります。詳細は、『iPlanet Messaging Server リファンレンスマニュアル』を参照してください。


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


注

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



証明書の入手

SSL の用途が暗号化か認証かにかかわらず、Messaging Server 用のサーバ証明書を入手する必要があります。この証明書は、使用するサーバの識別情報をクライアントや他のサーバに提供します。


内部モジュールと外部モジュールを管理するには

サーバ証明書によって、キーのペアの所有権と有効性が確立されます。キーのペアは、データの暗号化と解読に使用される数値です。サーバの証明書とキーのペアは、そのサーバの識別情報を示します。これらは、サーバ内部または取り外し可能な外部のハードウェアカード (スマートカード) の証明書データベース内に保存されます。

iPlanet サーバは、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 モジュールをインストールします。

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

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


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

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

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

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

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

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


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

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

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

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

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

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



信頼できる CA の証明書をインストールするには

認証局 (CA) の証明書をインストールする場合も、証明書セットアップウィザードを使用します。CA 証明書は、認証局自体の身元を証明します。サーバは、クライアントや他のサーバを認証するプロセスで、これらの CA 証明書を使用します。

たとえば、パスワードに基づく認証 (157 ページの「証明書に基づくログインの設定」を参照) に加え、証明書に基づく認証にも対応するように会社の環境を設定した場合は、クライアントが提示する可能性のある証明書の発行元として信頼できる CA の証明書をすべてインストールする必要があります。これらの CA は、社内組織の場合もあれば、商業機関、政府機関、他の企業などの外部組織の場合もあります。認証用 CA 証明書の使用方法については、『iPlanet Managing Servers with Netscape Console』の「Introduction to Cryptography」を参照してください。

Messaging Server をインストールすると、いくつかの商用認証局の CA 証明書もインストールされます。他の商用認証局の CA 証明書を追加する場合や、社内使用のために (iPlanet Certificate Server を使用して) 独自の認証局を開発する場合は、追加の CA 証明書を入手して、インストールする必要があります。

注

Messaging Server により自動的に提供される CA 証明書は、インストール時にはクライアント証明書用の信頼できる証明書としてマークされていません。これらの CA から発行されるクライアント証明書を信頼できるものにする必要がある場合は、信頼設定を編集する必要があります。この手順については、「証明書と信頼できる CA の管理」を参照してください。


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

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

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

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

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


証明書と信頼できる CA の管理

サーバには、クライアントの認証に使用する、信頼できる CA の証明書を必要な数だけインストールできます。

コンソールでサーバを開き、「コンソール」メニューの「証明書の管理」コマンドを選択すると、Messaging Server にインストールされている証明書の信頼設定の表示や編集、または任意の証明書の削除を行うことができます。この手順については、『iPlanet Managing Servers with Netscape Console』の SSL に関する章を参照してください。


パスワードファイルの作成

任意の iPlanet サーバ上で、証明書セットアップウィザードを使用して証明書を要求すると、ウィザードによってキーのペアが作成されます。このキーのペアは、あとで内部モジュールのデータベースまたはスマートカード内にある外部データベースに格納します。次に、このプライベートキーを暗号化するために使われるパスワードの入力を要求されます。あとでこのキーを解読するには、この同じパスワードを使用する必要があります。ウィザードでは、パスワードはどこにも記録されません。

SSL を有効にしている iPlanet サーバでは、ほとんどの場合、起動時に管理者がキーのペアの解読に必要なパスワードを入力します。ただし、Messaging Server では、パスワードを何度も入力する手間を省き (少なくとも 3 つのサーバプロセスで入力が必要)、さらに無人でサーバを再起動できるように、パスワードファイルからパスワードが読み取られます。

パスワードファイルは、sslpassword.conf という名前が付けられ、ディレクトリ server-instance/config/ に格納されます。ファイル内の各エントリは、次のフォーマットで 1 行ずつ記述されます。

moduleName:password

moduleName は使用される (内部または外部) PKCS #11 モジュールの名前です。password はそのモジュールのキーのペアを暗号化するためのパスワードです。パスワードは、クリアテキスト (暗号化されていないテキスト) として保存されます。

Messaging Server には、デフォルトのパスワードファイルが用意されています。このファイルには、次のような内部モジュールとデフォルトのパスワードのエントリが 1 つだけ含まれています。

Internal (Software) Token:netscape!

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


警告

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



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

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


符号化方式について

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

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

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

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


表 12-1    Messaging Server の SSL 符号化方式 

符号化方式

説明

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

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

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

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

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

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

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

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

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

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

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

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

特定の符号化方式を使わないようにする妥当な理由がないかぎり、すべての符号化方式をサポートする必要があります。ただし、特定の暗号化方式の使用が法律で制限されている国もあります。また、米国の輸出規制法規が緩和される前に開発されたクライアントソフトウェアの中には、強度の高い暗号化を使用できないものもあります。40 ビットの符号化方式では、偶発的な漏洩は防ぐことができますが、セキュリティが確保されないため、意図的な攻撃を防ぐことはできません。

コンソール : コンソールを使用して SSL を有効にし、符号化方式を選択するには、次の手順を実行します。

  1. コンソールで、符号化方式の設定を変更する Messaging Server を開きます。

  2. 左のペインの「環境設定」タブをクリックし、「サービス」フォルダを選択します。

  3. 右のペインの「暗号化」タブをクリックします。

  4. 「SSL の利用」ボックスにチェックマークを付け、サーバの SSL を有効にします。

  5. RSA 符号化方式を使用可能にする場合は、「RSA」ボックスにチェックマークを付けます。

  6. 「トークン」ドロップダウンリストから、使用するトークンを選択します。

  7. 「証明書」ドロップダウンリストから、使用する証明書を選択します。

  8. 「符号化方式のプリファレンス」をクリックして、使用可能な符号化方式のリストを表示します。

  9. ボックスをクリックしてサーバでサポートする 1 つまたは複数の符号化方式を選択します。

SSL を完全に無効にするには、「SSL の利用」ボックスのチェックマークを外します。
注

送信メッセージの暗号化を有効にするには、チャネル定義を変更して、maytls や musttls などの tls チャネルキーワードを追加する必要があります。詳細は、『iPlanet Messaging Server リファンレンスマニュアル』を参照してください。


コマンドライン : 次のように、コマンドラインを使用して 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 は、カンマで区切られた符号化方式のリストです。


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

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

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

  1. 使用しているサーバ用の証明書を入手します (詳細は、「証明書の入手」を参照)。

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

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

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

  4. サーバが提出された証明書の情報に基づいて LDAP ユーザディレクトリを適切に検索するように、サーバの certmap.conf ファイルを編集します (省略可)。

    ユーザの証明書内の電子メールアドレスと、ユーザのディレクトリエントリ内の電子メールアドレスが一致する場合は、certmap.conf ファイルを編集する必要はありません。また、検索を最適化したり、提出された証明書をユーザエントリ内の証明書と照合したりする必要もありません。

    certmap.conf のフォーマットと変更可能な部分の詳細は、『iPlanet Managing Servers with Netscape Console』の SSL に関する章を参照してください。

上記の手順を実行したあとに、ユーザが、IMAP または HTTP にログインできるようにクライアントで SSL セッションを確立すると、Messaging Server からクライアントに対してユーザの証明書が要求されます。サーバによって信頼されている CA から発行された証明書をクライアントが提出し、かつ証明書の識別情報がユーザディレクトリ内のエントリと一致する場合、そのユーザは、認証され、ユーザに適用されるアクセス制御規則に応じたアクセス権が与えられます。

証明書に基づくログインを有効にするためにパスワードに基づくログインを無効する必要はありません。パスワードに基づくログインが許可されている場合 (デフォルトの状態) に、この節で説明した作業を実行すると、パスワードに基づくログインと証明書に基づくログインの両方がサポートされます。その場合は、クライアントが SSL セッションを確立し、証明書を提出すると、証明書に基づくログインが使用されます。クライアントが SSL を使用しない場合、または証明書を提出しない場合は、パスワードを要求されます。

証明書に基づく認証を使用するための iPlanet サーバ全体とクライアントの設定方法については、『Single Sign-On Deployment Guide』を参照してください。


SMTP プロキシを使用した SSL パフォーマンスの最適化方法

SMTP プロキシを使用すると、SMTP プロトコルの待ち時間が増加するため、ほとんどのサイトでは SMTP プロキシを使用しません。ただし、SMTP 接続を保護するために SSL を頻繁に使用する大規模サイトでは、SSL とプロキシ専用の 1 台のサーバ上で、すべてのプロトコルのすべての SSL 操作を実行することで、SSL アクセラレータハードウェアに対する投資効果を最大化する必要があります。SMTP プロキシを使用すると、フロントエンドのプロキシサーバで SSL を処理し、メールキューを別の MTA マシン上に置くことができます。この方法により、各タスクに最適なハードウェアを個別に購入して構成することができます。

SMTP プロキシのインストール方法については、「SMTP プロキシをインストールするには」を参照してください。



Messaging Server への管理者アクセスを構成する


この節には、以下の項があります。

この節では、サーバ管理者による Messaging Server へのアクセスを制御する方法について説明します。特定の Messaging Server および Messaging Server タスクへの管理アクセスは、委任サーバ管理を行うときに発生します。

委任サーバ管理は、ほとんどの iPlanet サーバが持っている機能で、管理者が、他の管理者に対して、個々のサーバやサーバ機能へのアクセス権を選択して提供できる機能を意味します。この章では、委任されたサーバのタスクについて簡単に説明します。詳細は、『iPlanet Managing Servers with Netscape Console』のサーバ管理の委任に関する章を参照してください。さらに、『iPlanet Messaging Server プロビジョニングガイド』の「Provisioning Messaging Server 管理者のプロビジョニング」も参照してください。『プロビジョニングガイド』では、サーバ管理者 (Messaging Server を構成できる管理者)、および iDA 管理者 (システム内のユーザやグループを追加、変更、削除できる管理者) について説明しています。


委任管理の階層

ネットワーク上に最初の iPlanet サーバをインストールすると、インストールプログラムによって、LDAP ユーザディレクトリに構成管理者グループと呼ばれるグループが自動的に作成されます。デフォルトでは、構成管理者グループのメンバーには、ネットワーク上のすべてのホストおよびサーバに対する無制限のアクセス権が与えられます。

構成管理者グループは、次のようなアクセス階層の最上位に位置します。このようなアクセス階層を構築して、Messaging Server の委任管理を実装することができます。

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

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

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

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

  • グループまたは個人に特定の Messaging Server に対するアクセス権を与える。次の節の「サーバ全体に対するアクセス権の提供」を参照

  • そのアクセス権を特定の Messaging Server 上での特定のタスクに制限する。「特定タスクへのアクセスを限定するには」を参照


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

ユーザまたはグループに Messaging Server の特定のインスタンスに対するアクセス権を与えるには、次の手順を実行します。

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

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

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

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

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

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


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

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

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

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

接続しているユーザまたはグループが持つことができるタスクアクセス権を制限するには、次の手順を実行します。

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

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

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

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

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

ACI とその作成方法の詳細は、『iPlanet Managing Servers with Netscape Console』のサーバ管理の委任に関する章を参照してください。



POP、IMAP、および HTTP サービスへのクライアントアクセスを構成する


この節には、以下の項があります。

Messaging Server には、IMAP、POP、HTTP の各サービスを個別に制御できる精巧なアクセス制御機能があります。これにより、クライアントによるサーバへのアクセスを広範囲に細かく制御できます。

大企業やインターネットサービスプロバイダのメッセージングサービスを管理する場合、これらの機能を使用して、スパム (大量メール送信) や DNS スプーフィングを行うユーザをシステムから除外したり、ネットワークの全般的なセキュリティを強化したりできます。不特定多数宛てメールを制御するための具体的な方法については、第 10 章「メールのフィルタリングとアクセス制御」を参照してください。

注

IP アドレスによるアクセス制御が重要な問題ではない場合は、この節で説明しているフィルタを作成する必要はありません。最小限のアクセス制御だけが必要な場合は、その設定手順について、「大半のアクセスを許可」を参照してください。



クライアントアクセスフィルタのしくみ

Messaging Server のアクセス制御機能は、プログラムであり、TCP デーモンと同じポートで応答を待機します。このプログラムは、アクセスフィルタを使用してクライアントの識別情報を確認し、クライアントがフィルタリングプロセスを通過した場合に、そのクライアントに対してデーモンへのアクセス権を与えます。

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

  • 両方の終端の逆引き DNS 検索 (名前に基づくアクセス制御を行うため)

  • 両方の終端の正引き DNS 検索 (DNS スプーフィングを検出するため)

  • Identd コールバック (クライアントエンドのユーザがクライアントホストに認識されていることを調べるため)

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

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

  • 検索は、最初の一致項目が見つかった時点で終了する。許可フィルタは、拒否フィルタより先に処理されるため、許可フィルタが優先される

  • クライアント情報が対象のサービスの許可フィルタに一致した場合は、アクセスが許可される

  • クライアント情報がそのサービスの拒否フィルタに一致した場合は、アクセスが拒否される

  • 許可フィルタと拒否フィルタのどちらにも一致しなかった場合は、アクセスが許可される。ただし、許可フィルタだけがあり、拒否フィルタがない場合は、許可フィルタに一致しないと、アクセスが拒否される

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

以下の節では、フィルタの構文について詳しく説明し、さらに使用例を紹介します。アクセスフィルタの作成手順については、「各サービス用のアクセスフィルタを作成するには」を参照してください。


フィルタの構文

フィルタ文は、サービス情報とクライアント情報の両方を含んでいます。サービス情報には、サービス名、ホスト名、ホストアドレスを含めることができます。クライアント情報には、ホスト名、ホストアドレス、ユーザ名を含めることができます。サービス情報とクライアント情報の両方で、ワイルドカード名やパターンを使用できます。

以下に、非常に単純な形式のフィルタを示します。

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 サービスへのアクセスが許可されます。ドメインやサブネットを指定する場合の先頭に付けるドットや他のパターンの使用方法については、「ワイルドカードのパターン」を参照してください。


ワイルドカード名

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

表 12-2    ワイルドカード名 

ワイルドカード名

説明

ALL  

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

LOCAL  

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

UNKNOWN  

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

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

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

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

KNOWN  

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

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

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

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

DNSSPOOFER  

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


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

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

  • ドット文字 (.) から始まる文字列。ホスト名の最後の部分が指定したパターンに一致する場合、そのホスト名は一致します。たとえば、ワイルドカードパターン .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 のサポートを廃止することが検討されているため、今後もこの機能を使う必要がある場合は iPlanet にお知らせください。

  • ユーザ名の検索は時間がかかるので、すべてのユーザについて検索を実行すると、identd をサポートしていないクライアントのアクセスが遅くなる場合があります。ユーザ名の検索を選択的に実行すると、この問題を緩和することができます。たとえば次のように指定します。

    serviceList: @xyzcorp.com ALL@ALL

    この場合、xyzcorp.com ドメイン内のユーザは、ユーザ名の検索を実行せずに一致します。ただし、他のすべてのシステムについては、ユーザ名の検索が実行されます。

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

コンソール : コンソールを使用してフィルタを作成するには、次の手順を実行します。

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

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

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

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

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

    • 新しいフィルタを追加するには、「追加」をクリックします。「Allow フィルタ」ウィンドウまたは「Deny フィルタ」ウィンドウが表示されます。ウィンドウに新しいフィルタのテキストを入力し、「OK」をクリックします。

    • フィルタを編集する場合は、フィルタを選択して「編集」をクリックします。「Allow フィルタ」ウィンドウまたは「Deny フィルタ」ウィンドウが表示されます。ウィンドウに表示されたフィルタのテキストを編集し、「OK」をクリックします。

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

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

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

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

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

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 の認証用にログインサーバを設定する場合は、iPlanet が提供する Messenger Express 認証 SDK を利用できます。

この節では、許可フィルタを使用し、IP アドレスを基準として、HTTP プロキシ認証を許可する方法について説明します。ログインサーバの設定方法や Messenger Express 認証 SDK の使用方法については説明しません。Messenger Express 用のログインサーバの設定方法や、認証 SDK の使用方法については、iPlanet の担当者に問い合わせてください。

コンソール : HTTP サービスに対するプロキシ認証用のアクセスフィルタを作成するには、次の手順を実行します。

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

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

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

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

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

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

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

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

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

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

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

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

コマンドライン : 次のように、コマンドラインを使用して、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 アドレスを追跡して同期する必要があるためです。

iPlanet 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 プロキシをインストールするには

  1. 『iPlanet Messaging Server インストールガイド』の説明に従って、iPlanet Messaging Multiplexor (MMP) をインストールします。

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

    以下の文字列を

    server_root/bin/msg/mmp/lib/SmtpProxyAService@25|587

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

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

    AService-def.cfg、ImapProxyAService-def.cfg、PopProxyAService-def.cfg、SmtpProxyAService-def.cfg

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


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

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

    例 : PROXY_PASSWORD A_Password

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

    1. server_root/mmp-instance/SmtpProxyAService.cfg 設定ファイルを編集します。

      以下の SMTP プロキシオプションは、IMAP プロキシおよび POP プロキシの同名のオプションとまったく同じように機能します。『iPlanet Messaging Server インストールガイド』の「Installing the Messaging Multiplexor」を参照してください。またこれらのオプションについては、『iPlanet Messaging Serverリファレンスマニュアル』の「暗号化 (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 mothra

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

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

      以下に、使用頻度の少ない「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 before SMTP を機能させるために、IMAP または SMTP のプロキシ設定ファイル内で、AuthServiceTTL を設定する必要はありません。


      これらのオプションは、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 サービスへのクライアントアクセスの構成方法については、第 10 章「メールのフィルタリングとアクセス制御」を参照してください。


前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 2 月 27 日