iPlanet Messaging Server には、広範囲にわたる柔軟なセキュリティ機能があります。これらの機能により、メッセージが中断されないようにしたり、不正侵入者がユーザや管理者を装ってシステムにアクセスすることを防ぐことができます。また、指定したユーザだけがメッセージシステム内の特定部分にアクセスできるように設定することも可能です。
Messaging Server のセキュリティアーキテクチャは iPlanet サーバのセキュリティアーキテクチャの一部であり、最大限の共同利用性および整合性が得られるように業界規格と公開プロトコルに基づいて構築されています。したがって、Messaging Server のセキュリティポリシーを実施するためには、本章だけでなく、他のマニュアルも参照して理解を深めておく必要があります。特に、『Netscape Console によるサーバの管理』に記載されている情報は、Messaging Server のセキュリティを設定するために必要な情報が記載されています。
サーバのセキュリティについて
サーバのセキュリティは、広範囲に及ぶさまざまな観点から考慮することができます。通常、企業のメッセージングシステムに欠かせない重要な条件として、承認されたユーザだけがサーバにアクセスできること、パスワードや個人情報が安全であること、ユーザが他のユーザを装って通信を行わないこと、必要に応じて通信の機密性が保たれることが挙げられます。
サーバのセキュリティはさまざまな方法によって危険にさらされる可能性があるため、それらに対するアプローチも多種多様です。この章では、暗号化、認証、およびアクセス制御に注目し、以下に挙げる Messaging Server のセキュリティ関連トピックについて説明します。
-
ユーザ ID とパスワードログイン : ユーザは、IMAP、POP、HTTP、または SMTP にログインするためにユーザ ID とパスワードを入力する必要があります。また、メッセージの受信者に送信者認証を送る場合は、SMTP パスワードログインを使用します。
暗号化と認証 : TLS および SSL プロトコルを使って通信を暗号化し、クライアントを認証できるようにサーバをセットアップします。
管理者アクセス制御 : Netscape Console のアクセス制御機能を使って、Messaging Server や個々のタスクへのアクセスを委託します。
TCP クライアントアクセス制御 : フィルタリング技術を使って、どのクライアントがサーバの POP、IMAP、HTTP、および SMTP サービスに接続できるかを制御します。
-
物理的なセキュリティ : サーバマシンを物理的に保護する設備がなければ、ソフトウェアのセキュリティも無意味になります。
メッセージの暗号化(S/MIME): Secure Multipurpose Internet Mail Extensions (S/MIME) があると、送信者はメッセージを暗号化してから送信することができ、また、受信者は受け取った暗号化メッセージを保存することができます。暗号化メッセージは、受信者がそれらを読むときに復号化されます。S/MIME を使用するのに、Messaging Server に関する特別な設定や作業は必要ありません。S/MIME はクライアントに依存するからです。S/MIME の設定方法については、お使いのクライアントに付属のマニュアルを参照してください。注意 : Messenger Express クライアントのインターフェースは、電子メールメッセージの暗号化をサポートしていません。
メッセージストアへのアクセス : Messaging Server では、複数のメッセージストア管理者を定義することができます。これらの管理者は、メールボックスを表示および監視したり、メールボックスへのアクセスを制御することができます。詳細については、第 10 章「メッセージストアを管理する」を参照してください。
エンドユーザアカウントの設定 : エンドユーザアカウント情報は、主に Delegated Administrator 製品を使って管理されます。詳細については、Delegated Administrator のマニュアルを参照してください。また、エンドユーザアカウントは、コンソールのインターフェースを使って管理することもできます。詳細については、第 3 章「メールユーザとメーリングリストを管理する」を参照してください。
UBE (unsolicited bulk email) のフィルタリング : 第 9 章「メールのフィルタリングとアクセス制御」を参照してください。
HTTP のセキュリティについて
Messaging Server でサポートされている HTTP プロトコル用のセキュリティ機能は、IMAP プロトコル用のセキュリティ機能と同じものです。つまり、ユーザ ID/パスワードによる認証とクライアント証明書による認証の両方がサポートされています。ただし、HTTP プロトコルと IMAP プロトコルとでは、クライアントとサーバ間におけるネットワーク接続の処理方法にいくつかの相違点があります。
POP、IMAP、または SMTP クライアントが Messaging Server にログインすると、接続が確立され、セッションが開始されます。この接続は、セッション間、すなわちログインしてからログアウトするまで維持されます。新しい接続を確立すると、クライアントはサーバに対して再び認証を行う必要があります。
HTTP クライアントが Messaging Server にログインすると、サーバからクライアントに固有のセッション ID が与えられます。クライアントは、このセッション ID を使って、同一セッション中に複数の接続を確立することができます。HTTP クライアントは接続を確立するたびに認証を行う必要はありません。クライアントが再び認証を行わなければならないのは、セッションが切断された場合とクライアントが新規のセッションを開始する場合だけです。ただし、HTTP セッションが指定された時間以上アイドル状態になると、サーバは自動的に HTTP セッションを切断し、クライアントは強制的にログアウトされます (デフォルトは 2 時間)。
HTTP セッションの接続は安全です。以下に、その理由を挙げます。
-
セッション ID は、特定の IP アドレスにバインドされています。したがって、セッション ID が他のホストによって使用されることはありません。
各セッション ID には、タイムアウト値が関連付けられています。つまり、セッション ID が指定された時間を超えて使用されなかった場合、そのセッション ID は無効になります。
開いているすべてのセッションに対するセッション ID のデータベースがサーバに保管されます。そのため、クライアントが ID を偽造することは不可能です。
認証機構を設定する
認証機構は、クライアントが不正なものでないことをサーバに証明するための一手段です。Messaging Server は SASL (Simple Authentication and Security Layer) プロトコルにより定義されている認証メソッドをサポートしており、また、証明書に基づく認証も使用できます。SASL による認証機構については、本章で説明しています。証明書に基づく認証については、「暗号化と証明書に基づく認証を設定する」を参照してください。
Messaging Server では、パスワードに基づく認証を実施するにあたり、以下の SASL 認証メソッドがサポートされています。
-
PLAIN - ユーザのテキスト形式 パスワードがネットワークを介して渡されます。そのため、パスワードが盗まれる可能性があります。
-
この問題は、SSL を使用することにより解消できます。詳細については、「暗号化と証明書に基づく認証を設定する」を参照してください。
CRAM-MD5 - APOP と同様のチャレンジ/レスポンス型認証機構。ただし、この機構は、APOP とは異なり、他のプロトコルにも使用できます。RFC 2195 で定義されています。
| 注 |
POP、IMAP、および SMTP サービスでは、すべての SASL 機構がサポートされています。HTTP サービスでは、プレーンパスワードによる機構しかサポートされていません。
|
プレーンテキストパスワードへのアクセスを設定する
CRAM-MD5、DIGEST-MD5、または APOP SASL 認証メソッドでは、ユーザのプレーンテキストパスワードに対するアクセスが要求されます。そのため、以下の操作を行う必要があります。
-
パスワードが平文で保存されるように Directory Server を設定します。
Messaging Server を設定して Directory Server が平文のパスワードを使用していることを伝えます。
Directory Server を設定する
CRAM-MD5、DIGEST-MD5、または APOP 機構を使用するには、パスワードが平文で保存されるように Directory Server を設定する必要があります。以下の手順に従います。
-
コンソールで、設定対象の Directory Server を開きます。
Messaging Server を設定する
次に、Messaging Server の設定を変更して、Directory Server が平文のパスワードを取り込めることを Messaging Server に知らせます。これにより、Messaging Server で APOP、CRAM-MD5、および DIGEST-MD5 を使用できるようになります。
configutil -o sasl.default.ldap.has_plain_passwords -v 1
SASL 機構を無効にする場合は、値を 0 または空白 (" ") に設定します。
注
既存のユーザは、パスワードを再設定または移行するまで APOP、CRAM-MD5、または DIGESt-MD5 を使用できません (次の「ユーザを移行する」の項を参照)。
ユーザを移行する
ユーザの移行に関する情報を指定するには、configutil を使用します。たとえば、ユーザパスワードが変わる場合や、適切なエントリがない機構を使ってクライアントが認証を試みようとする場合です。
configutil -o sasl.default.transition_criteria -v 値
-
CHANGE - ユーザ パスワードが変わると、サーバはテキスト形式のパスワードを受け入れるように移行します (デフォルト)。
CLIENT - クライアントが適切なエントリのない機構を使用しようとすると、サーバはテキスト形式のパスワードを使って認証を行うようクライアントに指示を出します。その後、サーバは、同じパスワード値を使って目的のエントリを作成します。
PLAIN - ユーザがテキスト形式のパスワードを使用すると、サーバはテキスト形式のパスワードを受け入れるように移行します。
-
コンソールで、設定対象の Directory Server を開きます。
[オブジェクト] メニューの [アクセス権限] を選択します。
「Messaging Server エンドユーザ管理者書き込みアクセス権」に対する ACI を選択 (ダブルクリック) します。
ユーザパスワードログイン
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」を参照してください。
認証 SMTP は、SSL 暗号化機能といっしょに (または SSL 暗号化機能を使わずに) 使用することができます。
暗号化と証明書に基づく認証を設定する
iPlanet Messaging Server は、暗号化通信およびクライアント/サーバ間の証明書に基づく認証を行うために TLS (Transport Layer Security) プロトコルを使用します。このプロトコルは、SSL (Secure Sockets Layer) を標準化したものとして知られています。iPlanet Messaging Server では、SSL バージョン 3.0 および 3.1 がサポートされています。TLS には、SSL との完全な互換性があり、必要な SSL 機能がすべて含まれています。
SSL に関する背景情報については、「Introduction to SSL」(『Netscape Console によるサーバの管理』の付録) を参照してください。SSL は、公開鍵暗号方式の概念に基づいています。この概念は、「Introduction to Public-Key Cryptography」(『Netscape Console によるサーバの管理』の付録) で説明されています。
Messaging Server とクライアント間、およびそのサーバと他のサーバ間におけるメッセージ送信が暗号化されるのであれば、通信上のプライバシーが朗詠する危険性はまずありません。また、接続しているクライアントが認証されたものである場合には、それらのクライアントを装って (スプーフして) 侵入者が介入してくる危険性もありません。
SSL は、IMAP4、HTTP、および SMTP のアプリケーション層の下で、プロトコル層の役割を果たします。SMTP と SMTP/SSL は同一のポートを使用しますが、HTTP と HTTP/SSL にはそれぞれ別のポートが必要です。IMAP と IMAP/SSL の場合は、同一のポートを使用することも別のポートを使用することも可能です。図 11-1 に示すように、SSL は、送信メッセージと受信メッセージの両方においてメッセージ通信の特定の段階で動作します。
図 11-1 Messaging Server の暗号化通信
SSL はホップ間 (hop-to-hop) の暗号化を提供しますが、各中間サーバではメッセージが暗号化されません。クライアントが S/MIME をサポートするためには、エンド間 (end-to-end) の暗号化が必要です。
注
通信メッセージに対して暗号化を有効にするには、チャネル定義に maytls や musttls などの tls チャネルキーワードを含める必要があります。詳細については、『Messaging Server リファレンスマニュアル』を参照してください。
SSL 接続を設定する際にオーバーヘッドが大きくなると、サーバのパフォーマンスが下がる可能性があります。メッセージングシステムの設計およびパフォーマンス分析の段階で、セキュリティニーズとパフォーマンスのバランスをとる必要があります。
注
SSL はすべての iPlanet サーバでサポートされており、SSL を設定するための コンソールインターフェースはどのサーバの場合でもほとんど同じです。そのため、本章で説明しているタスクの一部は、『Netscape Console によるサーバの管理』の SSL に関する章でより詳しく説明されています。本章では、これらのタスクについて、その要約だけを説明します。
証明書を入手する
SSL を使用する目的が暗号化または認証のいずれであっても、お使いの Messaging Server のサーバ証明書を入手する必要があります。この証明書は、お使いのサーバをクライアントや他のサーバと区別するために使用されます。
内部モジュールと外部モジュールを管理する
サーバ証明書によって、キーペアの所有権および有効性が確立されます。キーペアとは、データの暗号化および暗号解除に使用される数値のことです。お使いのサーバの証明書とキーペアは、そのサーバのアイデンティティを表すもので、サーバ内部または取り外し可能な外部ハードウェアカード (スマートカード) の証明書データベース内に保管されます。
iPlanet サーバは、PKCS (Public-Key Cryptography System) #11 API に準拠するモジュールを使って、キーと証明書のデータベースにアクセスします。通常、ハードウェアデバイスの PKCS #11 モジュールは、そのデバイスの販売元から入手することができます。このモジュールを Messaging Server にインストールしないと、Messaging Server はそのデバイスを使用することができません。システムには「Netscape Internal PKCS # 11 Module」が既にインストールされていますが、これはサーバ内部の証明書データベースを使用する単一の内部ソフトウェアトークンです。
サーバの証明書設定には、証明書とそのキーを格納するためのデータベースを作成する作業と PKCS #11 モジュールをインストールする作業とが関与します。外部のハードウェア トークンを使用しない場合は、サーバ上に内部データベースを作成し、デフォルトの内部モジュール (Messaging Server の一部) を使用します。外部トークンを使用する場合は、ハードウェアスマートカードリーダーを接続し、その PKCS #11 モジュールをインストールします。
PKCS #11 モジュールは、それが外部モジュールまたは内部モジュールのいずれであっても、コンソールを使って管理できます。PKCS #11 モジュールをインストールするには :
-
カードウェアカードリーダーを Messaging Server ホストマシンに接続し、ドライバをインストールします。
コンソールの [PKCS #11 の管理] インターフェースを使って、インストールしたドライバに対する PKCS #11 モジュールをインストールします。
ハードウェア暗号化アクセラレータをインストールする 暗号化用に SSL を使用する場合は、ハードウェア暗号化アクセラレータをインストールすることにより、メッセージの暗号化および復号化におけるパフォーマンスを上げることができます。一般に、暗号化アクセラレータは、サーバマシンに常設されたハードウェアボードとソフトウェアドライバから成ります。iPlanet Messaging Server では、PKCS #11 API に従うアクセラレータモジュールがサポートされています (これらは独自のキーを持たないハードウェアトークンです。つまり、キーの保管には内部データベースが使用されます)。提供された指示に従って、まず、ハードウェアとドライバをインストールして、アクセラレータをインストールします。その後、PKCS #11 モジュールをインストールして、ハードウェア証明書トークンのインストールを完了します。
サーバ証明書を要求する
サーバ証明書を要求するには、iPlanet Console でサーバ証明書を要求し、[証明書セットアップウィザード] を実行します。このウィザードは、[コンソール] メニューまたは Messaging Server の [暗号化] タブからアクセスすることができます。証明書セットアップウィザードを使って、以下のタスクを実行します。
認証局 (CA) から電子メールによる応答を受け取ったら、その内容をテキスト形式でファイルに保存し、証明書セットアップウィザードを使って証明書をインストールします。
詳細については、『Netscape Console によるサーバの管理』の SSL に関する章を参照してください。
証明書をインストールする
証明書の要求とインストールは、それぞれ別のプロセスを意味します。証明書の要求に対して認証局 (CA) から電子メールによる応答を受け取ったら、その内容をテキスト形式でファイルに保存し、証明書セットアップウィザードを使って証明書をインストールします。
詳細については、『Netscape Console によるサーバの管理』の SSL に関する章を参照してください。
| 注 |
CA 証明書 (以下に説明) をインストールするには、このプロセスを実行する必要があります。クライアントによって提示された証明書が信頼できるものであるかどうかをサーバがCA 証明書を使用して判断します。
|
認証済み認証局の証明書をインストールする
証明書セットアップウィザードを使って、認証局の証明書 (CA 証明書) もインストールします。CA 証明書とは、認証局自体のアイデンティティを確証するためのものです。サーバは、クライアントや他のサーバを認証する過程でこれらの CA 証明書を使用します。
たとえば、パスワードに基づく認証 (「証明書に基づくログインを設定する」) に加え、証明書に基づく認証も使用するように設定した場合は、クライアントによって提示される可能性のある証明書の発行元認証局のうち、信頼できるすべての認証局の CA 証明書をインストールする必要があります。これらの認証局は、自社の内部組織であったり、または民間機関、政府機関、他の企業などの外部組織である場合があります (CA 証明書の使用については、『Netscape Console によるサーバの管理』の「Introduction to Cryptography」を参照してください)。
Messaging Server には、いくつかの民間認証局に対する CA 証明書が既に備わっています。他の民間認証局の CA 証明書を追加する場合や、自分の所属する企業が (iPlanet Certificate Server を使って) 社内で使用するための独自の認証局を開発している場合には、さらに CA 証明書を入手し、インストールする必要があります。
注
Messaging Server により自動的に提供される CA 証明書は、最初はクライアント証明書に対し「認証済み (信頼できる)」になっていません。したがって、これらの認証局から発行されるクライアント証明書を「認証済み」として扱いたい場合には、信頼設定を編集する必要があります。詳細については、「証明書と認証済み CA を管理する」を参照してください。
新しい CA 証明書を要求してインストールするには、以下の操作を行います。
詳細については、『Netscape Console によるサーバの管理』の SSL に関する章を参照してください。
証明書と認証済み CA を管理する
サーバには、信頼できる認証局の証明書を必要な数だけインストールすることができます。これらの証明書は、クライアント認証を行うために使用されることになります
コンソールでサーバを選択してから [コンソール] メニューの [証明書の管理] コマンドを選択すると、Messaging Server にインストールされている証明書の信頼設定を表示または編集したり、任意の証明書を削除することができます。詳細については、『Netscape Console によるサーバの管理』の SSL に関する章を参照してください。
パスワードファイルを作成する
どの iPlanet サーバの場合でも、証明書セットアップウィザードを使って証明書を要求すると、キーペアが作成されます (このキーペアは、後で内部モジュールのデータベースまたはスマートカード内にある外部データベースのいずれかに保存されることになります)。その後、このプライベートキーを暗号化するために使われるパスワードを入力するよう求められます。後でキーを復号化するときには、同じパスワードを使用しなければなりません。パスワードはどこにも記録されないので忘れないようにしてください。
一般に、SSL を使用している iPlanet サーバの場合は、起動時に管理者がキーペアの復号化用パスワードを入力するようになっています。ただし、Messaging Server の場合は、何度もパスワードを入力しなくても済むように (少なくとも 3 つのサーバプロセスで必要とされます)、また、重要度の低いサーバの再起動を簡素化するために、パスワードはパスワードファイルから読み取られます。
パスワードファイルの名前は sslpassword.conf で、このファイルはサーバ-インスタンス/config/ ディレクトリに保存されています。ファイル内の各エントリは、次のフォーマットで 1 行ずつ記述されています。
ここで、moduleName は使用される (内部または外部) PKCS #11 モジュールの名前で、password はそのモジュールのキーペアを暗号化するためのパスワードです。パスワードは、平文 (暗号化されない) で保存されます。
Messaging Server には、デフォルトのパスワードファイルがあります。このファイルには、以下に示すエントリが 1 つだけ含まれています (内部モジュールおよびデフォルトのパスワード用)。
Internal (Software) Token:netscape!
内部証明書をインストールするときにデフォルト以外のパスワードを指定した場合は、パスワードファイル内の行 (上記参照) を編集して、指定したパスワードを反映させる必要があります。外部モジュールをインストールした場合は、ファイルに新しい行を追加し、そこにモジュール名とそのパスワードを記述する必要があります。
管理者はサーバの起動時にモジュールのパスワードを入力するように求められません。そのため、管理者によるアクセスが適切に制御されていること、およびサーバホスト マシンおよびそのバックアップの物理的なセキュリティが確保されていることが重要なポイントとなります。
SSL を有効にする符号化方式を選択する
SSL を有効にし、Messaging Server がクライアントとの暗号化通信に使用する符号化方式を選択するには、コンソールを使用します。
符号化方式の概要
「符号化方式」とは、暗号化プロセスでデータを暗号化および復号化するためのアルゴリズムのことです。符号化方式の中には、強度の高低があります。つまり、承認されていない人が符号を解読しようとした場合、強度が高いほど解読が困難であることを意味します。
符号化方式は、キー (長い数値) をデータに適用することによって動作します。一般に、暗号化に使用するキーが長いほど、適切な復号キーなしで、データを復号することは難しくなります。
クライアントが Messaging Server と SSL 接続を開始するとき、クライアントはサーバに対して、暗号化に使用したい符号化方式とキー長を伝えます。暗号化通信では、両者が同じ符号化方式を使用していなければなりません。一般に使用される符号化方式とキーの組み合わせには数多くのタイプがあります。そのため、サーバは暗号化のサポートに対して柔軟でなければなりません。iPlanet Messaging Server では、符号化方式とキー長の組み合わせとして6つまでのタイプをサポートしています。
表 11.1 に、Messaging Server が SSL 3.0 を使ってサポートできる符号化方式の一覧を示します。この表は、各タイプについて簡単に説明したものです。詳細については、『Netscape Console によるサーバの管理』の「Introduction to SSL」を参照してください。
表 11-1 Messaging Server の SSL 符号化方式
符号化方式
説明
特定の符号化方式を使わないようにする特別な理由がない限り、上記すべての符号化方式をサポートするようにしてください。ただし、特定の暗号化方式の使用が制限されている国もあるので注意が必要です。また、米国輸出規制が緩和される前に開発されたクライアントソフトウェアの中には、強度の高い暗号化を使用できないものもあります。40 ビットの符号化方式を使った場合、軽い攻撃を防ぐことはできるかもしれませんが、あまり安全だとは言えません。意図的な攻撃は防ぐことができません。
コンソール- コンソールを使って SSL を有効にし、符号化方式を選択するには、以下の手順で操作します。
-
コンソールで、符号化方式の設定を変更する Messaging Server を開きます。
左側のパネルの [環境設定] タブをクリックし、[サービス] フォルダを開きます。
[SSL の利用] チェックボックスをオンにして、サーバの SSL を有効にします。
RSA による符号化方式を使用可能にする場合は、[RSA] チェックボックスをオンにします。
[トークン] ドロップダウンリストで、使用するトークンを選択します。
[証明書] ドロップダウンリストで、使用する証明書を選択します。
注
送信メッセージに対して SSL 暗号化を有効にするには、チャネル定義に maytls や musttls などの tls チャネルキーワードを含める必要があります。詳細については、『Messaging Server リファレンスマニュアル』を参照してください。
コマンドライン- コマンドラインを使って SSL を有効にし、符号化方式を選択することもできます。
configutil -o nsserversecurity -v [ on | off ]
configutil -o encryption.rsa.nssslactivation -v [ on | off ]
configutil -o encryption.rsa.nsssltoken -v トークン名
configutil -o encryption.rsa.nssslpersonalityssl -v 証明書名
RSA 符号化方式を有効にした場合は、トークンと証明書を指定する必要があります。
configutil -o encryption.nsssl3ciphers -v cipherlist
ここで、cipherlist はコンマで区切られた符号化方式リストを指します。
証明書に基づくログインを設定する
パスワードに基づくログインに加え、iPlanet サーバでは、デジタル証明書の確認によるユーザ認証をサポートしています。証明書に基づく認証の場合、クライアントはサーバとの SSL セッションを確立し、ユーザの証明書をサーバに提出します。その後、サーバによって、提出された証明書が信頼できるものであるかどうかを評価します。証明書の信頼性が確認されると、そのユーザは本人であると見なされます。
証明書に基づくログインを行えるように Messaging Server を設定するには、以下の手順に従います。
-
お使いのサーバに対するサーバ証明書を入手します (詳細については、「証明書を入手する」を参照してください)。
-
サーバのデータベース内に信頼できる認証局が少なくとも 1 つある場合、そのサーバは接続した各クライアントに対してクライアント証明書を要求するようになります。
-
ユーザの証明書の電子メールアドレスがユーザのディレクトリエントリ内にある電子メールアドレスに一致する場合、certmap.conf ファイルを編集する必要はありません。また、検索を最適化したり、提出された証明書をユーザエントリ内の証明書と照合する必要もありません。
- certmap.conf のフォーマットおよび可能な変更については、『Netscape Console によるサーバの管理』の SSL に関する章を参照してください。
- certmap.conf のフォーマットおよび可能な変更については、『Netscape Console によるサーバの管理』の SSL に関する章を参照してください。
証明書セットアップウィザードを実行して、信頼できる認証局の証明書をインストールします。これにより、サーバは、これらの認証局から証明書を発行されたユーザを認証できるようになります (詳細については、「認証済み認証局の証明書をインストールする」を参照してください)。
(オプション) サーバが提出された証明書の情報に基づいて LDAP ユーザディレクトリを適切に検索するように、サーバの certmap.conf ファイルを編集します。
証明書に基づくログインを有効にするためにパスワードに基づくログインを無効する必要はありません。パスワードに基づくログインが許可されている場合 (デフォルトの状態) に、この節で説明しているタスクを実行すると、パスワードに基づくログインと証明書に基づくログインの両方がサポートされます。その場合、クライアントが SSL セッションを確立し、証明書を提示すると、証明書に基づくログインが使用されます。クライアントが SSL を使用しない場合、または証明書を提示しなかった場合は、パスワードが要求されます。
証明書に基づく認証を利用できるように iPlanet サーバおよびクライアントを設定する方法については、『Single Sign-On Deployment Guide』を参照してください。
Messaging Server への管理者アクセスを設定する
この節では、サーバ管理者による Messaging Server へのアクセスを制御する方法について説明します。特定の Messaging Server および Messaging Server タスクへの管理上のアクセスは、委託サーバ管理に関連して起こります。
「委託サーバ管理」とは、ある管理者が他の管理者に対し個々のサーバおよびサーバ機能へのアクセスを提供することができる機能を意味する用語で、この機能はほとんどの iPlanet サーバに備わっています。この章では、委託サーバ管理のタスクについて簡単に説明します。詳細については、『Netscape Console によるサーバの管理』の委託サーバ管理に関する章、および『Messaging Server Provisioning Guide』の「Provisioning Messaging Server Administrators」を参照してください。『Provisioning Guide』では、サーバ管理者 (Messaging Server を設定できる管理者)、および iDA 管理者 (システム内のユーザおよびグループを追加、変更、削除できる管理者) について説明しています。
委託管理の階層
ネットワーク上に最初の iPlanet サーバをインストールすると、LDAP ユーザディレクトリに「設定管理者グループ」と呼ばれるグループが、インストールプログラムによって自動的に作成されます。特に設定を変更しない限り、設定管理者グループのメンバーには、ネットワーク上のすべてのホストおよびサーバに対する無制限のアクセスが与えられます。
設定管理者グループは、以下に説明するようなアクセス階層の最上位に位置します。このアクセス階層は、Messaging Server の委託管理を実行するうえで利用されます。
-
設定管理者 : iPlanet サーバのネットワークにおける「スーパーユーザ」。すべてのリソースに対する完全なアクセス権があります。
サーバ管理者 : ドメイン管理者は、各タイプのサーバを管理するためのグループを作成することがあります。たとえば、管理ドメイン内またはネットワーク全体にあるすべての Messaging Server を管理するために「メッセージング管理者」グループを作成したりします。このグループのメンバーには、その管理ドメイン内のすべての Messaging Server に対するアクセス権があります (他のサーバに対するアクセス権はありません)。
タスク管理者 : 上記の管理者はいずれも、単一または複数の Messaging Server に対する制限付きアクセス権を持つグループを作成したり、またはそのようなアクセス権を持つ個人ユーザを指定することができます。このようなタスク管理者は、特定の制限されたサーバタスク (サーバの起動や停止、特定のサービスのログへのアクセス) だけを実行することが許可されます。
-
グループまたは個人に特定の Messaging Server に対するアクセス権を与えます。次項の「サーバ全体に対するアクセスを与える」を参照してください。
そのアクセスを特定の Messaging Server における特定のタスクに制限します。「アクセスを特定のタスクに制限する」を参照してください。
サーバ全体に対するアクセスを与える
ユーザまたはグループに特定の Messaging Server に対するアクセス権を与えるには、以下の手順に従います。
-
対象となる Messaging Server へのアクセス権を持つ管理者としてコンソールにログインします。
-
[コンソール] メニューから [オブジェクト]―[アクセス権の設定] を選択します。
特定の Messaging Server へのアクセス権を持つユーザおよびグループのリストを設定したら、以下で説明する ACI を使って、そのリスト内の特定の人物またはグループに特定のサーバタスクを委託することができます。
アクセスを特定のタスクに制限する
一般に、管理者はサーバに接続して 1 つ以上の管理タスクを実行します。コンソールの Messaging Server タスクフォームには、通常行われる管理タスクがリストされています。
デフォルト設定を使用する場合、「特定の Messaging Server へのアクセス」とは、そのサーバのすべてのタスクにアクセスできることを意味します。ただし、タスクフォーム内の各タスクには、一連のアクセス制御インストラクション (ACI) をつけることができます。サーバは、接続しているユーザ (サーバ全体に対するアクセス権を既に持っているユーザ) にタスクへのアクセス権を与える前に、これらの ACI を調べます。実際、タスクフォームには、そのユーザがアクセス権を持っているタスクのみが表示されます。
Messaging Server へのアクセス権がある場合は、アクセス権を持っている任意のタスクに関する ACI を作成または編集することで、そのタスクに対して他のユーザやグループが持っているアクセス権を制限することができます。
接続しているユーザまたはグループに対し、タスクへのアクセス権を制限するには :
-
対象となる Messaging Server へのアクセス権を持っている管理者として コンソールにログインします。
-
詳細については、『Netscape Console によるサーバの管理』の委託サーバ管理に関する章を参照してください。
サーバを開き、そのサーバのタスクフォームからタスクを選択します。タスクを選択するには、「タスク」テキストをクリックします。
[編集] メニューの [アクセス権の設定] を選択し、ユーザまたはグループにアクセスを与えるためのアクセス規則のリストを編集します。
POP、IMAP、および HTTP サービスへのクライアントアクセスを設定する
Messaging Server には、IMAP、POP、および HTTP の各サービスに対して高性能なアクセス制御機能があります。これにより、クライアントによるサーバへのアクセスを広範囲に細かく制御することができます。
大企業またはインターネット サービスプロバイダ用にメッセージングサービスを管理する場合は、これらの機能が、システムからスパム (大量メール送信) や DNS スプーフを除外したり、ネットワークの一般的なセキュリティを強化するのに役立ちます。一方的に送られてくる大量の不要電子メールを制御する方法については、第 9 章「メールのフィルタリングとアクセス制御」を参照してください。
注
システムにとって、IP アドレスによるアクセス制御がそれほど重要でない場合は、この項で説明しているフィルタを作成する必要はありません。最小限のアクセス制御だけを設定する方法については、「大部分のアクセスを許可」を参照してください。
クライアントアクセスフィルタのしくみ
Messaging Server のアクセス制御機能は、TCP デーモンと同じポートで応答をリッスンするプログラムです。つまり、アクセスフィルタを使用してクライアントのアイデンティティを確認し、クライアントがフィルタリングプロセスを通過した場合には、そのデーモンへのアクセスがクライアントに与えられます。
そのプロセスの一部として、Messaging Server の TCP クライアントアクセス制御システムは、必要に応じて、以下のようなソケットのエンドポイントアドレスの解析を行います。
-
両エンドポイントのリバース DNS 検索 (名前に基づくアクセス制御を行うため)
両エンドポイントのフォワード DNS 検索 (DNS スプーフィングを検出するため)
Identd コールバック (クライアントエンドのユーザがクライアントホストに対して認識されているかどうかを調べるため)
クライアントがサービスへのアクセスを要求すると、アクセス制御システムは、そのクライアントのアドレスまたは名前情報をそのサービスのフィルタと比較します。その際、以下の条件を使って、順番に比較作業が行われます。
-
検索は、最初の一致項目が見つかった時点で終了します。ALLOW フィルタは DENY フィルタより先に処理されるため、ALLOW フィルタが優先されることになります。
クライアント情報がそのサービスの ALLOW フィルタに一致した場合は、アクセスが許可されます。
クライアント情報がそのサービスの DENY フィルタに一致した場合は、アクセスが拒否されます。
ALLOW フィルタと DENY フィルタのどちらにも一致しなかった場合は、アクセスが許可されます。ただし、DENY フィルタがなく、ALLOW フィルタだけしかない場合は、その ALLOW フィルタに一致しない限り、アクセスは許可されません。
以下の節では、フィルタの構文について詳しく説明するほか、いくつかの使用例も紹介します。アクセスフィルタの作成手順については、「各サービスのアクセスフィルタを作成する」を参照してください。
フィルタの構文
フィルタ文は、サービス情報とクライアント情報から構成されます。サービス情報には、サービスの名前、ホストの名前、ホストアドレスなど含めることができます。一方、クライアント情報には、ホスト名、ホストアドレス、ユーザ名などを含めることができます。サービス情報およびクライアント情報では、共にワイルドカード名やパターンを使用できます。
ここで、service はサービスの名前 (smtp、pop、imap、または http など)、hostSpec はアクセスを要求しているクライアントを表すホスト名、IP アドレス、またはワイルドカード名/パターンです。フィルタが処理されるときに、アクセスを要求しているクライアントは hostSpec に一致すると、service で指定されているサービスへのアクセスが (フィルタのタイプに応じて) 許可または拒否されます。以下の例を見てください。
imap: roberts.newyork.siroe.com
これらが ALLOW フィルタとして使われる場合は、最初の文によって roberts.newyork.siroe.com というホストに IMAP サービスへのアクセスが許可されます。また、次の 2 つの文によって、すべてのクライアントにそれぞれ POP サービスおよび HTTP サービスへのアクセスが許可されます。これらが DENY フィルタとして使われる場合は、同様のクライアントに対し、上記サービスへのアクセスが拒否されることになります。ALL などのワイルドカード名の詳細については、「ワイルドカード名」を参照してください。
フィルタのサービス情報およびクライアント情報は、場合によってさらに複雑になることがあります。以下に、より一般的な形式を示します。
ここで、serviceSpec はserviceまたはservice@hostSpec のどちらかとなり、clientSpec はホスト仕様またはuser@ hostSpec のどちらかとなります。この「 user」はアクセスを要求しているクライアントに関連付けられたユーザ名 (またはワイルドカード名) です。以下に、2 つの例を挙げます。
pop@mailServer1.siroe.com: ALL
imap: srashad@xyz.europe.siroe.com
これらを DENY フィルタとして考えてみましょう。最初のフィルタでは、すべてのクライアントに対し、mailServer1.siroe.com というホスト上の SMTP サービスへのアクセスが拒否されます。また、2 番目のフィルタでは、xyz.europe.siroe.com というホストの srashad というユーザに対し、IMAP サービスへのアクセスが拒否されます。サーバおよびクライアントの拡張設定の使い方については、「サーバホスト仕様」および「クライアントのユーザ名仕様」を参照してください。
ここで、serviceList は 1 つ以上の serviceSpec エントリから成り、clientList は 1 つ以上の clientSpec エントリから成ります。また、serviceList および clientList の各エントリは、空白やカンマで区切ります。
この場合、フィルタが処理されているときに、アクセスを要求しているクライアントが clientList 内の任意の clientSpec エントリに一致すると、serviceList で指定されているすべてのサービスに対するアクセスが (フィルタのタイプの応じて) 許可または拒否されます。以下に、その例を挙げます。
pop, imap, http: .europe.siroe.com .newyork.siroe.com
これが ALLOW フィルタであるとすると、europe.siroe.com ドメインまたは newyork.siroe.com ドメイン内のすべてのクライアントに POP、IMAP、および HTTP サービスへのアクセスが許可されます。ドメインやサブネットを指定するための先行ドットや他のパターンの使い方については、「ワイルドカードパターン」を参照してください。
ワイルドカード名
以下のワイルドカード名を使って、サービス名、ホストの名前やアドレス、またはユーザ名を表すことができます。
ワイルドカードパターン
サービスまたはクライアントアドレスには、以下のパターンを使用できます。
-
ドット文字 (.) から始まる文字列。ホスト名の末尾部分が指定したパターンに一致する場合、そのホスト名は一致します。たとえば、.siroe.com というワイルドカードパターンは、siroe.com というドメイン内のすべてのホストに一致します。
ドット文字 (.) で終わる文字列。ホストアドレスの先頭の数値フィールドが指定したパターンに一致する場合、そのホストアドレスは一致します。たとえば、123.45. というワイルドカード パターンは、123.45.0.0 サブネット内にある任意のホストのアドレスに一致します。
n.n.n.n/m.m.m.m 形式の文字列。このワイルドカードパターンは「ネット/マスク」のペアと解釈されます。ネットがアドレスとマスクのビット AND に等しい場合、そのホストアドレスは一致します。たとえば、123.45.67.0/255.255.255.128 というパターンは 123.45.67.0 ～ 123.45.67.127 の範囲に含まれるすべてのアドレスに一致します。
EXCEPT 演算子
アクセス制御システムでは、1 つの演算子がサポートされています。EXCEPT 演算子を使うと、serviceList または clientList のいずれかに複数のエントリがある場合に、名前やパターンの一致に関する例外を指定することができます。以下に、その形式を示します。
この文では、list1 に当てはまるものがすべて一致します。ただし、そのうち list2 に当てはまるものは除外されます。
ALL: ALL EXCEPT isserver.siroe.com
これを DENY フィルタとして使うと、isserver.siroe.com というホストマシン上のクライアントを除くすべてのクライアントに対し、すべてのサービスへのアクセスが拒否されます。
EXCEPT 句はネスティングすることも可能です。次の形式を見てください。
list1 EXCEPT list2 EXCEPT list3
list1 EXCEPT (list2 EXCEPT list3)
サーバホスト仕様
serviceSpec エントリにサーバホストの名前またはアドレス情報を含めることにより、要求されている特定のサービスをさらに識別することができます。この場合、エントリは以下の形式で表します。
この機能は、Messaging Server ホストマシンが異なるインターネットホスト名を持つ複数のインターネットアドレス用に設定されている場合に便利です。サービスプロバイダは、この機能を使うことによって、異なるアクセス制御規則を持つ複数のドメインを 1 個のサーバ インスタンスでホストすることができます。
クライアントのユーザ名仕様
RFC 1413 で定義されている identd サービスをサポートするクライアントホストマシンの場合は、フィルタの clientSpec エントリ内にクライアントのユーザ名を含めることにより、サービスを要求している特定のクライアントを識別することができます。この場合、エントリは次の形式で表します。
ここで、「user」_はクライアントの identd サービス (またはワイルドカード名) によって返されるユーザ名です。
フィルタにクライアントユーザ名を指定すると、場合によっては効果がありますが、以下の事項に注意してください。
-
identd サービスは認証ではありません。したがって、クライアントシステムが安全なものでない場合、そこから返されるクライアントユーザ名を信頼することはできません。一般には、特定のユーザ名を使用せずに、ALL、KNOWN、または UNKNOWN などのワイルドカードだけを使用するようにします。
-
serviceList: @xyzcorp.com ALL@ALL
- このフィルタを使うと、ユーザ検索を実行することなく、xyzcorp.com ドメイン内のユーザが一致します。そして、その他のすべてのシステムについては、ユーザ名検索が実行されます。
- このフィルタを使うと、ユーザ検索を実行することなく、xyzcorp.com ドメイン内のユーザが一致します。そして、その他のすべてのシステムについては、ユーザ名検索が実行されます。
ユーザ名検索には時間がかかります。すべてのユーザについて検索を実行すると、identd をサポートしていないクライアントによるアクセスが遅くなることがあります。この問題は、ユーザ名検索を選択的に行うことにより解消できます。たとえば、次の例を見てください。
フィルタの例
この節では、さまざまなアクセス制御のアプローチ例を紹介します。これらの例を参照するにあたり、ALLOW フィルタが DENY フィルタより先に処理されること、一致する項目が見つかった時点で検索が終了すること、および一致する項目が見つからなかった場合にはアクセスが許可されることに留意してください。
これらの例では、IP アドレスではなく、ホスト名とドメイン名を使用しています。フィルタにアドレス情報やネットマスク情報を含めておくと、ネームサービスにエラーが発生した場合の信頼性を高めることができます。
大部分のアクセスを拒否する
この例では、デフォルトでアクセスが拒否されます。そのため、明示的に認可されたホストだけがアクセスを許可されます。
デフォルトのポリシー (アクセスなし) は、次に示す 1 つの単純な DENY フィルタを使って実装されます。
このフィルタは、ALLOW フィルタによって明示的にアクセスを許可されていないすべてのクライアントに対し、すべてのサービスを拒否するものです。この場合の ALLOW フィルタは、たとえば次のようなものです。
ALL: .siroe.com EXCEPT externalserver.siroe.com
最初の規則では、ローカルドメイン内のすべてのホスト (すなわち、ホスト名にドットがないすべてのホスト) からのアクセス、および netgroup1 というグループのメンバーからのアクセスを許可しています。2 番目の規則では、externalserver.siroe.com ホストを除く siroe.com ドメイン内のすべてのホストからのアクセスを許可するために、先行ドットのワイルドカードパターンを使用しています。
大部分のアクセスを許可
この例では、デフォルトでアクセスが許可されます。そのため、明示的に指定されたホストだけがアクセスを拒否されます。
デフォルトのポリシー (アクセス許可) により、ALLOW フィルタは特に必要ありません。つまり、DENY フィルタ内にアクセスを拒否するクライアントを明示的に指定すればよいのです。以下に、その例を示します。
ALL: externalserver.siroe1.com, .siroe.asia.com
ALL EXCEPT pop: contractor.siroe1.com, .siroe.com
最初のフィルタでは、特定のホストおよびドメインに対するすべてのサービスを拒否しています。2 番目のフィルタでは、特定のホストおよびドメインからのアクセスを POP だけに限定しています。
指定ユーザだけにアクセスを許可する
以下に示す DENY フィルタを使うと、クライアントホストの identd サービスで既に認識されているユーザをすべて除外することができます。
つまり、このフィルタを使うと、すべてのドメインにおける不明なユーザ全員に対し、すべてのサービスが拒否されます。
「UNKNOWN@host」の「clientSpec」エントリを使うと、さらに特定化した DENY フィルタを作成できます。アクセス制御システムは、「host」からの要求を受け取ると、「host」上の ident サービスを使ってそのホストが実際に要求を送ったかどうか、およびその要求を送ったユーザの名前を調べます。要求を送ったユーザが不明な場合、そのユーザは不正侵入者である可能性があります (ただし、クライアントのホストが identd サービスをサポートしていない場合は、すべての要求者が UNKNOWN@host フィルタに一致してしまうので注意してください)。
ALLOW フィルタで使用するユーザ名検索は、あまり当てになりません。たとえば、「KNOWN@host」の「clientSpec」エントリを使って ALLOW フィルタを作成したとします。しかし、不正侵入者はクライアント接続と ident 検索の両方をスプーフィングできるため、「KNOWN@host」フィルタの一致がスプーフィングのないことの確実な証拠にはなりません。さらに、クライアントシステムが信頼できるものでない場合には、ident によって偽の情報が返されることもあります。
詳細については、「クライアントのユーザ名仕様」を参照してください。
スプーフィングされたドメインへのアクセスを拒否する
フィルタに DNSSPOOFER ワイルドカード名を使用することにより、ホスト名スプーフィングを検出することができます。DNSSPOOFER を指定すると、アクセス制御システムによって正方向または逆方向の DNS 検索が実行され、クライアントにより提示されたホスト名がその実際の IP アドレスと一致するかどうかが調べられます。以下に、DENY フィルタの例を示します。
このフィルタでは、IP アドレスがその DNS ホスト名に一致しないすべてのリモート ホストに対し、すべてのサービスを拒否しています。
仮想ドメインへのアクセスを制御する
メッセージングシステムで仮想ドメインを使用しており、1 つのサーバインスタンスが複数の IP アドレスおよびドメイン名に関連付けられている場合は、ALLOW フィルタと DENY フィルタを組み合わせて使って各仮想ドメインへのアクセスを制御することができます。たとえば、以下に示すような ALLOW フィルタを使用できます。
ALL@msgServer.siroe1.com: @.siroe1.com
ALL@msgServer.siroe2.com: @.siroe2.com
この場合、たとえば次のような DENY フィルタを使用できます。
各 ALLOW フィルタでは、domainN 内のホストだけが msgServer.siroeN.com に対応する IP アドレスを持つサービスに接続できるように指定されています。他の接続はすべて拒否されます。
特定のユーザを拒否する
1 人のユーザに対し、特別にアクセスを拒否する場合は、以下のような DENY フィルタを使用します。
もちろん、このフィルタを使った場合でも、そのユーザが別のユーザ名を使ってアクセスすることを防ぐことはできません。
各サービスのアクセスフィルタを作成する
IMAP、POP、HTTP の各サービスに対して、ALLOW フィルタおよび DENY フィルタを作成することができます。
コンソール- コンソールを使ってフィルタを作成するには、以下の手順に従います。
-
コンソールで、アクセスフィルタを作成する対象となる Messaging Server を開きます。
-
[許可] フィールドおよび [拒否] フィールドにそれぞれ、そのサービスの既存の ALLOW フィルタおよび DENY フィルタが表示されます。フィールドの各行がそれぞれ 1 つのフィルタに相当します。どちらか一方のフィールドに対し、以下の操作を実行できます。
左側のパネルで [サービス] フォルダを開き、そのフォルダの下にある IMAP、POP、または HTTP を選択します。
フィルタの構文とその例については、「フィルタの構文」を参照してください。また、その他の例については、「フィルタの例」を参照してください。
コマンドライン- コマンドラインを使って ALLOW フィルタや DENY フィルタを指定することもできます。以下に、その例を示します。
各サービスに対して ALLOW フィルタを作成または編集するには :
configutil -o service.service.domainallowed -v filter
ここで、service は pop、imap、または http のいずれかであり、filter は 「フィルタの構文」で説明している構文の規則に従います。
各サービスに対して DENY フィルタを作成または編集するには:
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 を利用できます。
この節では、ALLOW フィルタを使って IP アドレスによる HTTP プロキシ認証を許可する方法について説明します。ログインサーバの設定方法や Messenger Express 認証 SDK の使い方については、iPlanet までご連絡ください。
コンソール- HTTP サービスに対するプロキシ認証用の ALLOW フィルタを作成するには :
[許可] フィールドには、プロキシ認証用の既存 ALLOW フィルタが表示されています。
-
新規のフィルタを作成する場合は、[追加] をクリックします。
-
[ALLOW フィルタ]ウィンドウが開きます。ウィンドウに新しいフィルタのテキストを入力し、[OK] をクリックします。
-
[ALLOW フィルタ]ウィンドウが開きます。ウィンドウに表示されているフィルタのテキストを編集し、[OK] をクリックします。
コマンドライン- コマンドラインを使って、HTTP サービスに対するプロキシ認証用の ALLOW フィルタを指定することもできます。以下に、その例を示します。
configutil -o service.service.proxydomainallowed -v filter
ここで、filter は「フィルタの構文」で説明している構文の規則に従います。
SMTP サービスへのクライアントアクセスを設定する
SMTP サービスへのクライアントアクセスの設定については、第 9 章「メールのフィルタリングとアクセス制御」を参照してください。