test

Sun Java System Web Proxy Server 4.0.4 管理ガイド

第 5 章 証明書と鍵の使用

この章では、証明書と鍵の認証を使用した、Sun Java System Web Proxy Server のセキュリティー保護について説明します。Proxy Server には、すべての Sun Java System サーバーのセキュリティーアーキテクチャーが統合されています。Proxy Server は、相互運用性と整合性を最大限確保するため、業界標準および標準プロトコルに基づいて構築されています。

この章では、暗号化と復号化、公開鍵と非公開鍵、デジタル証明書、暗号化プロトコルなど、公開鍵暗号方式に関する基本概念を理解していることを前提としています。

この章の内容は次のとおりです。

管理サーバーアクセスのセキュリティー確保

管理サーバーは Web ベースのユーザーインタフェースで、サーバーを管理、追加、削除、および移行するために使用し、セキュリティーを確保する必要があります。

デフォルトの「Administration Server」ページは HTTP モードで起動します。使用可能な Proxy Server インスタンスは、「Manage Servers」の見出しの下にリストとして表示されます。Proxy Server インスタンスを管理するには、リストの名前をクリックします。Proxy Server インスタンスの名前をクリックすると、そのインスタンスの「Server Manager」ページが表示されます。

「Server Manager」ページから、「Server Manager」ページの左上にある「Manage Servers」リンクをクリックして「Administration Server」ページに戻ることができます。

証明書ベースの認証、信頼データベースの作成、SSL の設定、証明書の要求およびインストール、セキュリティーに関する詳細設定などの、セキュリティー機能は、管理サーバーと個別の Proxy Server インスタンスの両方に適用されます。管理サーバーのセキュリティー関連の設定の場合、「Administration Server」ページに表示される「Preferences」タブと「Security」を使用します。Proxy Server インスタンスに関するセキュリティー設定の場合は、その Proxy インスタンスの「Server Manager」ページに表示される「Preferences」タブと「Security」を使用します。

セキュリティーモードで管理サーバーを起動するには、デフォルトの HTTP の代わりに HTTPS を使用してアクセスする必要があります。

セキュリティー機能については、次の節を参照してください。

証明書に基づく認証

認証とは、識別情報を確認するためのプロセスのことです。ネットワークを介した対話では、認証は、特定の対象を他と区別するための確実な手段です。証明書は、認証をサポートする方法の 1 つです。

証明書は、個人、企業、またはその他のエンティティーの名前を指定するデジタルデータで構成され、その証明書に含まれている公開鍵が、そのエンティティーに属していることを証明します。

クライアントとサーバーの両方が証明書を持つことができます。サーバー認証とは、クライアントによる、サーバーの確実な識別です。組織の識別は、特定のネットワークアドレスにあるサーバーに対して責任を持つとされています。クライアント認証とは、サーバーによる、クライアントの確実な識別、またはクライアントソフトウェアを使用していると見なされる人の識別です。クライアントは、複数の証明書を所有できます。これは、1 人の人が数種類の ID を所有しているのと同じことです。

証明書は、認証局 (Certificate Authority、CA) によって発行され、デジタル署名がなされます。CA は、証明書を販売する企業の場合も、企業で、イントラネットやエクストラネットの証明書の発行を担当する部門の場合もあります。他のユーザーの識別情報の検証手段としてどの CA を信頼するかは、ユーザー自身が決定します。

証明書には、次の情報が含まれます。

注 –

暗号化機能を有効にするには、事前にサーバー証明書をインストールしておく必要があります。

信頼データベースの作成

サーバー証明書を要求する前に、信頼データベースを作成しておく必要があります。Proxy Server では、管理サーバーと各サーバーのインスタンスが、独自の信頼データベースを所有できます。信頼データベースは、ローカルコンピューター上にだけ作成できます。

信頼データベースを作成するときには、鍵ペアファイルに使用されるパスワードを指定します。このパスワードは、暗号化された通信を使用してサーバーを起動させるときにも必要です。パスワードを選択するときに考慮する必要のあるガイドラインについては、「強固なパスワードの選択」を参照してください。

信頼データベースでは、鍵ペアファイルと呼ばれる公開鍵と非公開鍵を作成し、保存します。鍵ペアファイルは、SSL 暗号化に使用されます。サーバー証明書を要求し、インストールするときには、鍵ペアファイルを使用します。証明書は、インストールしたあとに信頼データベースに格納されます。

鍵ペアファイルは、次のディレクトリ内に暗号化されて保存されます。

server-root/alias/proxy-serverid-key3.db

管理サーバーは、信頼データベースを 1 つだけ所有できます。また、サーバーに含まれる各インスタンスは、それぞれ専用の信頼データベースを所有できます。

Procedure信頼データベースを作成するには

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Security」タブを選択します。

  2. 「データベースを作成」リンクをクリックします。

  3. 信頼データベースのパスワードを入力します。

  4. もう一度パスワードを入力し、「了解」をクリックします。

password.conf の使用

デフォルトでは、Proxy Server を起動する前に、管理者に鍵データベースのパスワードを入力するよう求めるプロンプトが表示されます。Proxy Server を無人で再起動するには、password.conf ファイルにパスワードを保存する必要があります。このファイルと鍵データベースが危険にさらされないようにするために、これを行うのはシステムが充分にセキュリティー保護されている場合だけにしてください。

通常、サーバーは起動する前にパスワードを要求するため、/etc/ rc.local ファイルまたは /etc/inittab ファイルで、UNIX の SSL が有効なサーバーを起動することはできません。ファイル内にプレーンテキストでパスワードを保存しておくと SSL が有効なサーバーを自動的に起動することができますが、この方法は安全ではありません。サーバーの password.conf ファイルは、root またはサーバーをインストールしたユーザーが所有し、所有者だけが読み取りと書き込みのアクセス権を持つようにしてください。

UNIX で、password.conf ファイル内に SSL が有効なサーバーのパスワードを保存しておくと、セキュリティー上のリスクが大きくなります。ファイルにアクセス可能なユーザーは、SSL が有効なサーバーのパスワードにもアクセスできます。SSL が有効なサーバーのパスワードを password.conf ファイルに保存する前に、セキュリティー面のリスクを考慮してください。

Windows で、NTFS ファイルシステムを使用する場合は、password.conf ファイルを使用しなくても、アクセス制限によってこのファイルの保存されているディレクトリのセキュリティーを保護してください。ただしこのディレクトリには、管理サーバーのユーザーと Proxy Server のユーザーに対して読み取りおよび書き込み許可を持たせる必要があります。ディレクトリのセキュリティーを保護しておくと、他者が偽の password.conf ファイルを作成することを防げます。FAT ファイルシステム上では、ディレクトリやファイルへのアクセスを制限しても、ディレクトリやファイルのセキュリティーを保護することはできません。

SSL が有効なサーバーを自動的に起動

ProcedureSSL が有効なサーバーを自動的に起動するには

  1. SSL が有効になっていることを確認します。

  2. Proxy Server インスタンスの config サブディレクトリ内に、新規の password.conf ファイルを作成します。

    • Proxy Server に含まれている内部 PKCS #11 ソフトウェア暗号化モジュールを使用している場合には、次の情報を入力します。internal: your-password

      • 別の PKCS #11 モジュール (ハードウェアの暗号化またはハードウェアアクセラレータ用) を使用している場合は、PKCS #11 モジュールの名前を指定し、その後ろにパスワードを入力します。その例を次に示します。nFast:your-password

        password.conf ファイルを作成した後でも、Proxy Server を起動させるときには、毎回パスワードを入力するよう求めるプロンプトが表示されます。

VeriSign 証明書の要求およびインストール

VeriSign は、Proxy Server の推奨する認証局です。VeriSign のテクノロジによって、証明書リクエストプロセスはシンプルになります。VeriSign は、直接サーバーに対して証明書を返せるという利点があります。

サーバーに証明書信頼データベースを作成後、証明書を要求し、認証局 (CA) にこれを提出できます。会社に独自の内部 CA がある場合には、その部門から発行される証明書を要求します。商用 CA からの証明書購入を予定している場合には、CA を選定し、CA が必要とする情報の特定のフォーマットを入手してください。

管理サーバーは、サーバー証明書を 1 つしか所有できません。各サーバーのインスタンスは、専用のサーバー証明書を所有できます。

ProcedureVeriSign 証明書を要求するには

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Security」タブを選択します。

  2. 「Request VeriSign Certificate」リンクをクリックします。

  3. 表示されるページに記載されている手順を確認し、「了解」をクリックします。

    「VeriSign Enrollment Wizard」が表示され、手順が順番に指示されます。

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

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Security」タブを選択します。

  2. 「Install VeriSign Certificate」リンクをクリックします。

  3. 外部の暗号化モジュールを使用する場合以外は、「Cryptographic Module」ドロップダウンリストから「Internal」を選択します。

  4. 鍵ペアファイルパスワードまたは PIN を入力します。

  5. ドロップダウンリストから取得する「Transaction ID」を選択し、「了解」をクリックします。

ほかのサーバー証明書の要求およびインストール

VeriSign のほかに、他の認証局からの証明書を要求し、インストールすることができます。会社または組織が独自の内部証明書を提供している場合もあります。この節では、ほかの種類のサーバー証明書を要求およびインストールする方法について説明します。

ここでは、次の内容について説明します。

必要な CA 情報

要求処理を始める前に、CA が必要とする情報を確認しておく必要があります。必要な情報のフォーマットは CA によって異なりますが、通常は、次に示される情報を設定するように指定されます。これらの情報のほとんどは、証明書の更新の場合には、通常必要ありません。

すべての情報は、識別名 (DN) と呼ばれる、一連の属性と属性値のペアとして結合されており、これにより証明書の項目を一意に識別することができます。

商用の CA から証明書を購入する場合は、証明書が発行される前に、上記のほかにどんな情報が必要とされているのか知るために、事前に CA に確認しておく必要があります。ほとんどの CA では、識別情報の証明を要求します。たとえば、会社名や、会社によってサーバー管理者権限を与えられている人の名前を確認します。そして、場合によっては、提供した情報を使用する法的権利をユーザーが持っているかどうかを尋ねられることもあります。

一部の商用 CA では、さらに徹底した識別情報を提供した組織や個人に対して、さらに詳細で正確性の高い証明書を発行します。たとえば、個人が www.example.com というサイトのコンピュータの正当な管理者であるということを確認したことに加えて、企業が過去 3 年間にわたって運営されており、現在顧客と係争中の訴訟がないことを CA が確認したことが記述された証明書を購入することもできます。

ほかのサーバー証明書の要求

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

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Security」タブを選択します。

  2. 「Request Certificate」リンクをクリックします。

  3. 新しい証明書か証明書の更新かを選択します。

    多くの証明書は、6 か月や 1 年などの一定期間が経過すると、有効期限が切れます。自動的に更新した証明書を送信してくる CA もあります。

  4. 証明書の要求を送信する方法を指定します。

    • 電子メールで要求を送信するには、「CA Email Address」を選択して、その要求に使用する適切な電子メールアドレスを入力します。

      • CA の Web サイトから要求を送信するには、「CA URL」を選択して、その要求に使用する適切な URL を入力します。

  5. 「Cryptographic Module」ドロップダウンリストから、証明書を要求するときに使用する鍵ペアファイルの暗号化モジュールを選択します。

  6. 鍵ペアファイルのパスワードを入力します。

    このパスワードは、「Internal」以外の暗号化モジュールを選択していないかぎり、信頼データベースを作成したときに指定したパスワードと同一です。サーバーは、このパスワードを使用して、ユーザーの非公開鍵を取得したり、CA に対するメッセージを暗号化したりします。そして、ユーザーの公開鍵と暗号化されたメッセージの両方を CA に送信します。CA は、公開鍵を使用してメッセージを復号化します。

  7. 名前や電話番号などの識別情報を入力します。

    この情報のフォーマットは、CA によって異なります。これらの情報のほとんどは、証明書の更新の場合には、通常必要ありません。

  8. 正確に行うため、入力内容を見直して、「了解」をクリックします。

    情報が正確であれば、証明書も早く承認されます。要求を証明書サーバーに送るとき、送信する前に、フォーム情報を確認するよう求めるプロンプトが表示されます。

    サーバーは、入力した情報を含む証明書リクエストを作成します。要求には、ユーザーの非公開鍵を使用して作成されたデジタル署名が含まれます。CA は、デジタル署名を使用して、サーバーコンピュータから CA に送付されている間、その要求が不正に変更されていないことを確認します。まれに要求が不正に変更されたような場合には、通常 CA から電話で連絡があります。

    要求を電子メールで送信する場合には、サーバーがその要求を含んだ電子メールメッセージを CA に送信します。通常、電子メールにより証明書が返されます。証明書サーバーに URL を指定した場合は、サーバーがその URL を使用して証明書サーバーにその要求を送信します。CA によって、電子メールで返信を受けるか、その他の手段になるかは異なります。

    CA は、証明書を発行することに同意するかどうかを通知します。ほとんどの場合、CA は、電子メールで証明書を送信します。所属している組織が証明書サーバーを使用している場合には、証明書サーバーのフォームを使用して証明書を検索できます。

    注 –

    商用 CA に証明書を要求しても、必ず証明書が発行されるとは限りません。多くの CA では、証明書の発行前に、ユーザーの識別情報の証明を要求します。また、承認されるまでには、1 日〜数週間かかることがあります。必要な情報をすべて迅速に CA に提供することが重要です。

    証明書を受け取ったら、それをインストールします。それまでの間は、SSL を使用せずに Proxy Server を使用できます。

ほかのサーバー証明書のインストール

CA からの証明書は、ユーザーだけがこれを復号化できるように、公開鍵で暗号化されています。信頼データベースの正しいパスワードを入力しないと、証明書を復号化し、インストールすることはできません。

証明書には、次の 3 種類があります。

証明書チェーンは、連続した認証局によって署名された、一連の階層的証明書です。CA 証明書は、認証局を識別し、その認証局によって発行される証明書に署名するために使用されます。認証局証明書は同様に、親 CA の認証局証明書によって署名されます。このプロセスは、ルート認証局までさかのぼって行われます。

注 –

CA が CA の証明書を自動的にユーザーに送信しない場合には、証明書を要求してください。多くの CA は、ユーザーの証明書を電子メールで送信する際に CA 証明書も同時に送信してくるため、ユーザーのサーバーでは、両方の証明書が同時にインストールされます。

CA からの証明書は、ユーザーだけがこれを復号化できるように、公開鍵で暗号化されています。Proxy Server は、証明書をインストールする際、その証明書を復号するのに指定した鍵ペアファイルパスワードを使用します。サーバーがアクセス可能な場所にその電子メールを保存するか、またはその電子メールのテキストをコピーし、次の手順に説明する「Install Certificate」フォームにペーストできるようにします。

Procedure他のサーバー証明書をインストールするには

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Security」タブを選択します。

  2. 「Install Certificate」リンクをクリックします。

  3. 「Certificate」の横のインストールする証明書の種類を選択します。

    • This Server

      • Server Certificate Chain

      • Certification Authority

        特定の設定については、オンラインヘルプを参照してください。

  4. ドロップダウンリストから、暗号化モジュールを選択します。

  5. 鍵ペアファイルパスワードを入力します。

  6. 手順 3 で「Server Certificate Chain」または「Certification Authority」を選択した場合だけ、証明書の名前を入力します。

  7. 次のいずれかの方法で、証明書の情報を指定します。

    • 「Message Is In This File」を選択して、CA 証明書を含むファイルのフルパス名を入力します。

      • 「Message Text (with headers)」を選択して、CA 証明書の内容をコピーしてペーストします。Begin Certificate および End Certificate ヘッダーを含むようにしてください。また、先頭と末尾のハイフンを忘れないでください。

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

  9. 新しい証明書を追加するのか、既存の証明書を更新するのかを示します。

    • 新しい証明書をインストールする場合は、「Add Certificate」。

      • 更新された証明書をインストールする場合は、「Replace Certificate」

        証明書は、サーバーの証明書データベースに保管されます。次に例を示します。

        server-root/alias/ proxy-serverid-cert8.db

以前のバージョンからの証明書の移行

Sun ONE Web Proxy Server 3.6 (iPlanet Web Proxy Server とも呼ばれる) から Sun Java System Web Proxy Server 4 へ移行するときは、信頼データベースや証明書データベースを始めとするファイルが自動的に更新されます。

Proxy Server 4 管理サーバーに、以前の 3.x データベースファイルに対する読み取り許可があることを確認します。これらのファイルは、alias-cert.db と alias-key.db で、3.x-server-root/alias ディレクトリにあります。

サーバーでセキュリティーが有効になっている場合だけ、鍵ペアファイルと証明書が移行されます。管理サーバーとサーバーマネージャーの「Security」タブにある「Migrate 3.x Certificates」オプションを使用して、鍵と証明書だけを移行させることもできます。特定の設定については、オンラインヘルプを参照してください。

以前のバージョンでは、証明書と鍵ペアファイルは、複数のサーバーインスタンスによって使用される可能性のあるエイリアスによって参照されていました。管理サーバーは、すべてのエイリアスとそれらの構成要素である証明書を管理していました。Sun Java System Web Proxy Server 4 では、管理サーバーと各サーバーインスタンスに独自の証明書と鍵ペアファイルがあり、エイリアスではなく信頼データベースとして参照されます。

管理サーバー自体については、信頼データベースとその構成要素である証明書の管理は管理サーバーで行い、サーバーインスタンスについては、サーバーマネージャーで行います。証明書および鍵ぺアデータベースファイルは、それらを使用するサーバーインスタンス名をとって、名付けられます。以前のバージョンで複数のサーバーインスタンスが同じエイリアスを共用していた場合は、移行されると、証明書と鍵ペアファイルは新しいサーバーインスタンスの名前をとって名前変更されます。

サーバーインスタンスに関連のある信頼データベース全体が移行されます。以前のデータベースにリストされている CA はすべて、Proxy Server 4 データベースに移行されます。CA が重複している場合には、有効期限が切れるまで以前の CA を使用します。重複している CA は削除しないでください。

Proxy Server 3.x 証明書は、サポートされている Network Security Services (NSS) のフォーマットに移行されます。証明書は、アクセス元 、つまり、管理サーバーの「Security」タブか、サーバーマネージャーの「Security」タブの「Proxy Server」ページに応じて名前が付けられます。

Procedure証明書を移行するには

  1. ローカルコンピュータから管理サーバーまたはサーバーマネージャーにアクセスし、「Security」タブを選択します。

  2. 「Migrate 3.x Certificates」リンクをクリックします。

  3. 3.6 サーバーがインストールされているルートディレクトリを指定します。

  4. このコンピュータのエイリアスを指定します。

  5. 管理者のパスワードを入力し、「了解」をクリックします。

組み込みルート証明書モジュールの使用

動的に読み込み可能なルート証明書モジュールが、Proxy Server に含まれており、VeriSign を含む多数の CA のルート証明書が格納されています。ルート証明書モジュールを使用すると、より簡単な方法でルート証明書を新しいバージョンにアップグレードできます。以前のバージョンでは、古いルート証明書を 1 つずつ削除し、その後新しいルート証明書を 1 つずつインストールする必要がありました。現在は、ルート証明書モジュールファイルを Proxy Server の新しいバージョンへ更新するだけで、一般的な CA 証明書をインストールできます。この証明書モジュールファイルは将来の Proxy Server のバージョンでも継続して使用できます。

ルート証明書は PKCS #11 暗号化モジュールとして実装されているため、モジュールに含まれているルート証明書を削除することはできません。削除のオプションは、ルート証明書を管理するときには表示されません。サーバーインスタンスからルート証明書を削除する場合は、サーバーの alias ディレクトリ内で次のエントリを削除すれば、ルート証明書モジュールを無効にできます。

ルート証明書モジュールを復元する場合は、server-root/bin/proxy/lib (UNIX) または server-root\\ bin\\proxy\\bin (Windows) から、該当する拡張子を持つファイルを alias サブディレクトリにコピーできます。

ルート証明書の信頼情報は変更できます。信頼情報は、編集されるサーバーインスタンスの証明書データベースに書き込まれ、ルート証明書モジュールそのものには戻されません。

証明書の管理

ユーザーのサーバーにインストールされた CA からの証明書の信頼の設定値を表示、削除または編集できます。

Procedure証明書を管理するには

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Security」タブを選択します。

  2. 「Manage Certificates」リンクをクリックします。

    • 内部暗号化モジュールを使用して、デフォルト設定の証明書を管理する場合には、インストールされているすべての証明書のリストがその種別および有効期限とともに表示されます。証明書はすべて、ディレクトリ server-root/alias に格納されます。

      • ハードウェアアクセラレータなどの外部の暗号化モジュールを使用している場合には、各モジュールのパスワードを最初に入力し、「了解」をクリックします。モジュール内に証明書が組み込まれ、証明書リストが更新されます。

  3. 管理する証明書の名前をクリックします。

    その種類の証明書に関する管理オプションのあるページが表示されます。クライアントの信頼情報を設定または設定解除できるのは、CA 証明書だけです。外部の暗号化モジュールの中には、証明書を削除できないものもあります。

  4. 必要な操作を行います。

    有効なオプションは次のとおりです。

    • 内部的に取得した証明書については、「Delete certificate」または「Quit」

      • CA から発行された証明書については、「Set client trust」、「Unset server trust」、または「Quit」

        証明書情報には、所有者と発行者が含まれます。信頼の設定では、クライアントの信頼情報を設定したり、サーバーの信頼情報の設定を解除したりできます。LDAP サーバー証明書の場合は、サーバーが信頼されている必要があります。

CRL と CKL のインストールと管理

証明書の失効リスト (Certificate Revocation List、CRL) および危殆化鍵リスト (Compromised Key List、CKL) は、クライアントまたはサーバーのユーザーが信頼すべきでない証明書および鍵を知らせます。証明書の有効期限が切れる前にユーザーが事務所を変更したり、その組織を離れるような場合など、証明書のデータが変わった場合には、その証明書は無効になり、そのデータが CRL に表示されます。鍵が不正に変更されたり、その他不正に使用されたりした場合には、その鍵とそのデータが CKL に表示されます。CRL と CKL は、両方とも CA によって作成され、定期的に更新されます。これらのリストの取得については、特定の CA にお問い合わせください。

この節では、CRL と CKL のインストールと管理の方法について説明します。

ProcedureCRL または CKL をインストールするには

  1. CA から CRL または CKL を取得して、ローカルディレクトリにダウンロードします。

  2. 管理サーバーまたはサーバーマネージャーにアクセスし、「Security」タブを選択します。

  3. 「Install CRL/CKL」リンクをクリックします。

  4. 次のいずれかを選択します。

    • Certificate Revocation List

      • Compromised Key List

  5. インストールするファイルへのフルパス名を入力して、「了解」をクリックします。

    「Add Certificate Revocation List」ページまたは「Add Compromised Key List」ページが表示され、CRL または CKL の情報が一覧表示されます。データベースに CRL または CKL がすでにある場合には、「Replace Certificate Revocation List」ページまたは「Replace Compromised Key List」ページが表示されます。

  6. CRL または CKL を追加または置換します。

ProcedureCRL と CKL を管理するには

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Security」タブを選択します。

  2. 「Manage CRL/CKL」リンクをクリックします。

    「Manage Certificate Revocation Lists/Compromised Key Lists」ページが表示されます。インストールされているすべての CRL と CKL が、有効期限とともに一覧表示されます。

  3. 「Server CRLs」または「Server CKLs」リストのどちらかから証明書を選択します。

  4. 「Delete CRL」または「Delete CKL」を選択して CRL または CKL を削除します。

  5. 「Quit」を選択して管理ページに戻ります。

セキュリティーに関する詳細設定

証明書を取得すると、サーバーのセキュリティー保護を開始できます。Sun Java System Web Proxy Server には、この節で説明するような、多くのセキュリティー機能が用意されています。

暗号化とは、情報を対象とした受信者以外の人が読めないような内容にするための、変換プロセスのことです。復号化とは、暗号化された情報を判読可能な状態に戻すための、変換プロセスのことです。Proxy Server は、SSL (Secure Sockets Layer) および TLS (Transport Layer Security) 暗号化プロトコルをサポートしています。

暗号化方式とは、暗号化または復号化に使用する暗号アルゴリズム (数学関数) のことです。SSL と TLS プロトコルには、多数の暗号化方式のセットが含まれています。安全度は、暗号化方式によって異なります。一般的に、暗号化方式で使用するビット数が多いほど、データの復号化は難しくなります。

双方向の暗号化プロセスでは、必ず、送信側と受信側の両方が同じ暗号化方式を使用する必要があります。多数の暗号化方式があるため、最も一般的に使用されている方式に対してサーバーを有効にしておく必要があります。

セキュリティー保護された接続時には、クライアントとサーバーは、通信に、その双方が持てる最も強力な暗号化方式を使用します。SSL 2.0、SSL 3.0、および TLS プロトコルから暗号化方式を選択できます。

注 –

SSL 2.0 よりあとのバージョンで、セキュリティーとパフォーマンスが向上しています。システムに SSL 3.0 を使用できないクライアントが存在する場合を除き、SSL 2.0 を使用しないでください。クライアント証明書は、SSL 2.0 暗号化方式での動作が保証されていません。

暗号化プロセスだけでは、サーバーの機密情報のセキュリティー保護には十分ではありません。実際に暗号化結果を生成したり、すでに暗号化された情報を復号化するためには、暗号化方式と一緒に鍵を使用する必要があります。暗号化プロセスでは、この結果を出すために 2 つの鍵を使用します。これが、公開鍵と非公開鍵です。公開鍵を使用して暗号化された情報は、対応する非公開鍵を使用した場合にのみ復号化できます。公開鍵は、証明書の一部として発行されます。対応する非公開鍵だけがセキュリティー保護されます。

各種暗号化方式のセットについての説明と、鍵および証明書については、「Introduction to SSL」を参照してください。

サーバーが使用できる暗号化方式は指定できます。特定の暗号化方式を使わないようにする妥当な理由がないかぎり、すべての暗号化方式を選択する必要があります。ただし、最適でないと思われる暗号化方式を有効にする必要はありません。

注意 – 注意 –

「Enable No Encryption, Only MD5 Authentication」は選択しないでください。クライアント側でその他の暗号化方式を利用できない場合には、サーバーがデフォルトによりこの設定を使用し、暗号化は行われません。

ここでは、次の内容について説明します。

SSL と TLS プロトコル

Proxy Server では、暗号化通信として SSL と TLS プロトコルをサポートしています。SSL と TLS はアプリケーションには依存せず、ユーザーに意識させずに、より高レベルのプロトコルをこれらの上に階層化することができます。

SSL および TLS プロトコルは、サーバーとクライアントでお互いを認証するために使用される多くの暗号化方式のサポート、証明書の送信、およびセッション鍵の確立を行います。クライアントとサーバーは、サポートしているプロトコルや、暗号化の強度についての会社の方針および暗号化されたソフトウェアの輸出に対する行政上の制約条件などの要因に基づいて、別の暗号化方式セットをサポートすることができます。他の機能の中でも特に、SSL と TLS ハンドシェイクプロトコルは、どの暗号化方式のセットを通信に使用するかをサーバーとクライアントが交渉する方法を決定します。

SSL を使用した LDAP との通信

管理サーバーは SSL を使用して LDAP と通信するようにする必要があります。

注 –

ここでは、Proxy Server は SSL クライアントとして動作し、SSL サーバー LDAP 証明書に署名したルート CA 証明書をインポートしている必要があります。LDAP の SSL 証明書が一般的な CA が発行したものでない場合、使用する CA ルート鍵を Proxy Server 鍵ストアにインポートする必要があります。

Procedure管理サーバーで SSL 接続を使用して LDAP を有効にするには

  1. 管理サーバーにアクセスして、「Global Settings」タブをクリックします。

  2. 「Configure Directory Service」リンクをクリックします。

  3. 表示される表で、ディレクトリサービスのリンクをクリックします。

    「Configure Directory Service」ページが表示されます。LDAP ベースのディレクトリサービスが作成されていない場合は、「Create New Service of Type」ドロップダウンリストから、「LDAP Server」を選択し、「New」をクリックしてディレクトリサービスを設定します。LDAP ベースのディレクトリサービスで表示される特定のフィールドについては、オンラインヘルプを参照してください。

  4. 接続に SSL を使用する場合は、「Yes」を選択して、「Save Changes」をクリックします。

Proxy Server を介した SSL のトンネリング

Proxy Server (プロキシ) を順方向に実行していて、クライアントがセキュリティー保護されたサーバーに対してプロキシ経由の SSL 接続を要求した場合、プロキシは、セキュリティー保護されたサーバーへの接続を開き、セキュリティー保護されたトランザクションには介入せず、データを双方向にコピーします。このプロセスは、SSL トンネリングとして知られています。概要を次の図に示します。

図 5–1 SSL 接続

クライアントからセキュリティー保護されたサーバーに対するプロキシサーバー経由の SSL 接続を示す図

HTTPS URL で SSL トンネリングを使用するには、クライアントが SSL と HTTPS の両方をサポートしている必要があります。HTTPS は、SSL と通常の HTTP を使用して実装されます。HTTPS をサポートしないクライアントでも、Proxy Server の HTTPS プロキシ機能を使用して、HTTPS ドキュメントにアクセスできます。

SSL トンネリングは、アプリケーションレベル (HTTPS) には影響を及ぼさない、下位レベルのアクティビティーです。SSL トンネリングは、プロキシ機能のない SSL と同じぐらいセキュリティー保護されています。間に Proxy Server が存在することで、セキュリティーが危険にさらされたり、SSL の機能が低下したりすることはありません。

データストリームは SSL を使用して暗号化されるため、プロキシは、実際のトランザクションにはアクセスできません。そのため、アクセスログでは、リモートサーバーから受け取った状態コードや、ヘッダー長を表示することができません。また、このプロセスにより、プロキシやサードパーティーのプロキシは、トランザクションを傍受できません。

プロキシがデータを見ることはないため、クライアントとリモートサーバーの間で使用されているプロトコルが SSL であることは確認できません。つまり、プロキシは、その他のプロトコルでやり取りされることを防ぐことができない、ということでもあります。Internet Assigned Numbers Authority (IANA) によって割り当てられている一般的な SSL ポートだけ、つまり、HTTPS の場合はポート 443、SNEWS の場合はポート 563 だけに SSL 接続を制限することをお勧めします。セキュリティー保護されたサーバーがその他のポートで稼働しているサイトがある場合は、 connect://.* リソースを使用して、特定ホストのその他のポートに接続できるように、明示的な例外を設定できます。

SSL トンネリング機能は、SOCKS に似た汎用の機能で、プロトコルから独立しています。そのため、この機能をその他のサービスにも利用できます。Proxy Server は、HTTPS や SNEWS プロトコルだけでなく、SSL に対応した任意のアプリケーションの SSL トンネリングに対応できます。

SSL トンネリングの設定

次の手順では、SSL をトンネリングするように Proxy Server を設定する方法について説明します。

ProcedureSSL トンネリングを設定するには

  1. サーバーマネージャーにアクセスしてサーバーインスタンスを選択し、「Routing」タブをクリックします。

  2. 「Enable/Disable Proxying」リンクをクリックします。

  3. ドロップダウンリストから connect://.*.443 リソースを選択します。

    connect:// 方式は、内部プロキシ表記であり、プロキシの外部には存在しません。connect については、「SSL トンネリングの技術的詳細」を参照してください。

    その他のポートに接続を許可するには、テンプレートで類似の URL パターンを使用することができます。テンプレートについては、第 16 章「テンプレートとリソースの管理」を参照してください。

  4. 「Enable Proxying Of This Resource」を選択して、「了解」をクリックします。

    注意 – 注意 –

    プロキシの設定が正しくない場合は、ほかのユーザーがプロキシを利用して、実際に接続しているホストからではなく、プロキシホストから telnet 接続が行われているかのように見せることができます。このため、本当に必要なポート以外は決して許可しないでください。また、クライアントホストを制限するために、プロキシでアクセス制御を使用してください。

SSL トンネリングの技術的詳細

内部的には、SSL トンネリングでは、次のように CONNECT 方式を宛先ホスト名およびポート番号とともにパラメータとして使用し、空行を続けます。

CONNECT energy.example.com:443 HTTP/1.0

Proxy Server からの正常な応答は次のようになり、その後に空行が続きます。

HTTP/1.0 200 Connection establishedProxy-agent: Sun-Java-System-Web-Proxy-Server/4.0

その後、クライアントとリモートサーバーの間で接続が確立されます。どちらかが接続を閉じるまで、データを双方向に転送できます。

内部的には、URL パターンに基づいた典型的な設定機構を利用するために、ホスト名とポート番号は、自動的に次のような URL にマップされます。

connect://energy.example.com:443

connect:// は、Proxy Server で使用される内部表記であり、設定を容易にし、ほかの URL パターンと統一するために使用されます。Proxy Server の外部では connect URL は存在しません。Proxy Server がこのような URL をネットワークから受け取ると、無効としてマークし、要求の処理を拒否します。

待機ソケットのセキュリティーの有効化

次の方法で、サーバーの待機ソケットをセキュリティー保護できます。

注 –

セキュリティーは、転送プロキシモードではなく、逆プロキシモードでのみ有効にできます。

セキュリティー機能の有効化

待機ソケット用に他のセキュリティー設定を行うには、セキュリティー機能を有効にしておく必要があります。新しい待機ソケットを作成したり、既存の待機ソケットを編集したりするときに、セキュリティー機能を有効にできます。

Procedure待機ソケットの作成時にセキュリティー機能を有効にするには

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Preferences」タブをクリックします。

  2. 「Add Listen Socket」リンクをクリックします。

  3. 必要な情報を入力します。

    注 –

    待機ソケットを作成したあとでセキュリティーの設定を行うには、「Edit Listen Sockets」リンクを使用します。

  4. セキュリティーをオンにするには、「Security」ドロップダウンリストから「Enabled」を選択して、「了解」をクリックします。

    サーバー証明書がインストールされていない場合は、「Disabled」だけが選択できます。特定の設定については、オンラインヘルプを参照してください。

Procedure待機ソケットの編集時にセキュリティー機能をオンにするには

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Preferences」タブをクリックします。

  2. 「Edit Listen Sockets」リンクをクリックします。

  3. 編集する待機ソケットのリンクをクリックします。

  4. 「Security」ドロップダウンリストから「Enabled」を選択して、「了解」をクリックします。

    サーバー証明書がインストールされていない場合は、「Disabled」だけが選択できます。

待機ソケットのサーバー証明書の選択

管理サーバーまたはサーバーマネージャーのどちらかで、ユーザーが要求し、インストールしたサーバー証明書を使用するように待機ソケットを設定できます。

注 –

少なくとも 1 つの証明書をインストールしておく必要があります。

Procedure待機ソケットのサーバー証明書を選択するには

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Preferences」タブをクリックします。

  2. 「Edit Listen Sockets」リンクをクリックします。

  3. 編集する待機ソケットのリンクをクリックします。

  4. 「Security」ドロップダウンリストから「Enabled」を選択して、「了解」をクリックします。

    サーバー証明書がインストールされていない場合は、「Disabled」だけが選択できます。

  5. 「Server Certificate Name」ドロップダウンリストから待機ソケットのサーバー証明書を選択して、「了解」をクリックします。

暗号化方式の選択

Proxy Server のセキュリティーを保護するには、SSL を有効にすることをお勧めします。SSL 2.0、SSL 3.0 および TLS 暗号化プロトコルを有効にして、各種の暗号化方式セットを選択することができます。管理サーバーの待機ソケットで、SSL および TLS プロトコルを有効にできます。サーバーマネージャーの待機ソケットで SSL と TLS を有効にすると、特定のサーバーインスタンスに対して、これらのセキュリティーの詳細が設定されます。少なくとも 1 つの証明書をインストールしておく必要があります。

注 –

待機ソケットでの SSL 有効化は、Proxy Server が逆プロキシを実行するように設定されている場合のみ適用されます。

デフォルトの設定では、最も一般的に使用されている暗号化方式が使用できます。特定の暗号化方式を使用してはならない理由がある場合を除き、すべてを選択するようにします。

「TLS Rollback」の、デフォルトで推奨される設定は「Enabled」です。「Enabled」に設定すると、「人が介在するバージョンロールバック」攻撃を検出するようにサーバーが設定されます 。TLS 仕様を正しく実装できない一部のクライアントとの相互運用性を確保するために、「TLS Rollback」を「Disabled」に設定しなければならない場合があります。

「TLS Rollback」を無効にすると、通信がバージョンロールバック攻撃を受けやすくなります。バージョンロールバック攻撃は、第三者がクライアントおよびサーバーで SSL 2.0 などの古くてセキュリティー保護機能が低いプロトコルを使用して通信を行うようにするメカニズムです。SSL 2.0 プロトコルには既知の脆弱性があるため、「バージョンロールバック」攻撃を検出できない場合、第三者による暗号化された通信の傍受と復号化が容易になってしまいます。

ProcedureSSL や TLS を有効にするには

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Preferences」タブをクリックします。

  2. 「Edit Listen Sockets」リンクをクリックして、編集する待機ソケットのリンクをクリックします。

    セキュリティー保護された待機ソケットの場合、利用できる暗号化方式の設定が表示されます。

    待機ソケットのセキュリティー機能が有効になっていない場合は、SSL と TLS の情報は一覧表示されません。暗号化方式を使用するには、選択している待機ソケットでセキュリティー機能が有効になっている必要があります。詳細は、「待機ソケットのセキュリティーの有効化」を参照してください。

  3. 必要な暗号化方式セットに対応するチェックボックスを選択して、「了解」をクリックします。

  4. Netscape Navigator 6.0 では、TLS と SSL 3.0 の両方を選択します。「TLS Rollback」の場合にも、TLS を選択して、SSL 3.0 と SSL 2.0 の両方が無効になっていることを確認してください。

    サーバーで SSL が有効になったら、そのURL には http の代わりに https が使用されます。SSL 有効サーバー上のドキュメントを示す URL の書式は次のとおりです。 https://servername.domain .dom: port、例、https://admin.example.com:443

    デフォルトのセキュリティー保護された HTTP ポート番号 (443) を使用する場合には、URL にポート番号を入力する必要はありません。

セキュリティーのグローバルな設定

SSL が有効なサーバーをインストールすると、グローバルセキュリティーパラメータのサーバーのメイン設定ファイルである magnus.conf ファイル内に指令エントリが作成されます。

SSLSessionTimeout

SSLSessionTimeout 指令は、SSL 2.0 セッションのキャッシュを制御します。構文は次のとおりです。

SSLSessionTimeout seconds

ここで seconds は、キャッシュされた SSL セッションが無効になるまでの秒数です。デフォルト値は 100 です。SSLSessionTimeout 指令が指定された場合には、秒数値は暗黙的に 5 〜 100 秒の間に制限されます。

SSLCacheEntries

キャッシュ可能な SSL セッションの数を指定します。

SSL3SessionTimeout

SSL3SessionTimeout 指令は、SSL 3.0 および TLS セッションのキャッシュを制御します。構文を次に示します。

SSL3SessionTimeout seconds

ここで seconds は、キャッシュされた SSL 3.0 セッションが無効になるまでの秒数です。デフォルト値は 86400 (24 時間) です。SSL3SessionTimeout 指令が指定された場合には、秒数値は暗黙的に 5 〜 86400 秒の間に制限されます。

ProcedureSSL 設定ファイル指令の値を設定するには

  1. サーバーマネージャーから、サーバーインスタンスを選択します。

  2. 設定する待機ソケットでセキュリティーが有効になっていることを確認してください。

    詳細は、「待機ソケットのセキュリティーの有効化」を参照してください。

  3. magnus.conf ファイルを手動で編集し、次の設定の値を入力します。

    • SSLSessionTimeout

    • SSLCacheEntries

    • SSL3SessionTimeout

    magnus.conf の詳細については、『Sun Java System Web Proxy Server 4.0.4 Configuration File Reference 』を参照してください。

外部暗号化モジュールの使用

Proxy Server は、スマートカードやトークンリングなどの外部の暗号化モジュールとして、次の方法をサポートしています。

FIPS-140 暗号化標準を有効化する前に、PKCS #11 モジュールを追加しておく必要があります。

ここでは、次の内容について説明します。

PKCS #11 モジュールのインストール

Proxy Server は、Public Key Cryptography Standard (PKCS) #11 をサポートします。この標準は、SSL と PKCS #11 モジュール間の通信に使用されるインタフェースを定 義します。PKCS #11 モジュールは、SSL ハードウェアアクセラレータへの標準ベースの接続に使用されます。外部のハードウェアアクセラレータにインポートされた証明書と鍵は、secmod.db ファイルに格納されます。このファイルは、PKCS #11 モジュー ルをインストールしたときに生成されます。このファイルは、server-root/alias ディレクトリに置かれます。

ツール modutil による PKCS #11 モジュールのインストール

PKCS #11 モジュールを、modutil ツールを使用して .jar ファイルまたはオブジェクトファイルの形式でインストールできます。

Procedureツール modutil を使用して PKCS #11 モジュールをインストールするには

  1. 管理サーバーを含むすべてのサーバーが停止していることを確認します。

  2. データベースが置かれている server-root/alias ディレクトリに移動します。

  3. PATH に server-root/bin/proxy/admin/bin を追加します。

  4. server-root /bin/proxy/admin/bin で modutil を見つけます。

  5. 環境を設定します。

    • UNIX の場合: setenv

      LD_LIBRARY_PATH server-root/bin/proxy/lib:${LD_LIBRARY_PATH}

    • Windows の場合: PATH に次を追加します

      LD_LIBRARY_PATH server-root/bin/proxy/bin

      使用しているコンピュータの PATH は、次で確認できます。server-root/proxy-admserv/start

  6. 端末ウィンドウに「modutil」と入力します。

    オプションの一覧が表示されます。

  7. 必要な操作を行います。

    たとえば、UNIX に PCKS #11 モジュールを追加する場合には、次のように入力します。

    modutil -add (PKCS#11 ファイルの名前) -libfile (PKCS #11 用の libfile) -nocertdb -dbdir (db ディレクトリ)

ツール pk12util によるエクスポート

pk12util を使用して、内部データベースから証明書と鍵をエクスポートしたり、内部または外部の PKCS #11 モジュールにこれらをインポートしたりすることができます。証明書と鍵は内部データベースにいつでもエクスポートできますが、ほとんどの外部トークンでは証明書と鍵のエクスポートは許可されません。デフォルトでは、pk12util は、cert8.db と key3.db という名前の証明書と鍵データベースを使用します。

Procedure内部データベースから証明書と鍵をエクスポートするには

  1. データベースが置かれている server-root/alias ディレクトリに移動します。

  2. PATH に server-root/bin/proxy/admin/bin を追加します。

  3. server-root /bin/proxy/admin/bin で pk12util を見つけます。

  4. 環境を設定します。

    • UNIX の場合:

      setenv LD_LIBRARY_PATH/ server-root/bin/proxy/lib:${LD_LIBRARY_PATH}

    • Windows の場合: PATH に次を追加します

      LD_LIBRARY_PATH server-root/bin/proxy/bin

      使用しているコンピュータの PATH は、次で確認できます。 server-root/proxy-admserv/start

  5. 端末ウィンドウに「pk12util」と入力します。

    オプションの一覧が表示されます。

  6. 必要な操作を行います。

    たとえば、UNIX では次のように入力します。

    pk12util -o certpk12 -n Server-Cert [-d /server/alias] [-P https-test-host]

  7. データベースパスワードを入力します。

  8. pkcs12 パスワードを入力します。

Procedure内部または外部の PKCS #11 モジュールに証明書と鍵をインポートするには

  1. データベースが置かれている server-root/alias ディレクトリに移動します。

  2. PATH に server-root/bin/proxy/admin/bin を追加します。

  3. server-root /bin/proxy/admin/bin で pk12util を見つけます。

  4. 環境を設定します。

    次に例を示します。

    • UNIX の場合:

      setenv LD_LIBRARY_PATH/ server-root/bin/proxy/lib:${LD_LIBRARY_PATH}

      • Windows の場合: PATH に次を追加します。

        LD_LIBRARY_PATH server-root/bin/proxy/bin

        使用しているコンピュータの PATH は、次で確認できます。server-root/proxy-admserv/start

  5. 端末ウィンドウに「pk12util」と入力します。

    オプションの一覧が表示されます。

  6. 必要な操作を行います。

    たとえば、UNIX では次のように入力します。

    pk12util -i pk12_sunspot [-d certdir][-h “nCipher”][-P https-jones.redplanet.com-jones-]

    -P は -h のあとに、最後の引数として使用します。

    引用符記号の中の大文字と空白文字を含む、正確なトークン名を入力します。

  7. データベースパスワードを入力します。

  8. pkcs12 パスワードを入力します。

外部証明書を使用したサーバーの起動

たとえば、ハードウェアアクセラレータなど、外部 PKCS #11 モジュールにサーバーの証明書をインストールする場合には、server.xml ファイルを編集するか、または次に説明するように、証明書名を指定するまで、サーバーはその証明書の使用を開始できません。

サーバーは常に、Server-Cert という名前の証明書を使用して起動しようとします。しかし、外部 PKCS #11 モジュール内の証明書には、識別子内にモジュールのトークン名のうちの 1 つが含まれています。たとえば、smartcard0 と呼ばれる外部スマートカードリーダー上にインストールされているサーバー証明書の名前が、smartcard0:Server-Cert となるなどです。

外部モジュールにインストールされている証明書を使用してサーバーを起動するには、稼動する待機ソケットの証明書名を指定する必要があります。

Procedure待機ソケットの証明書を選択するには

待機ソケットのセキュリティー機能が有効になっていない場合は、証明書情報は表示されません。待機ソケットの証明書名を選択するには、まず、その待機ソケットでセキュリティー機能が有効になっていることを確認する必要があります。詳細は、「待機ソケットのセキュリティーの有効化」を参照してください。

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Preferences」タブをクリックします。

  2. 「Edit Listen Sockets」リンクをクリックします。

  3. 証明書と関連付ける待機ソケットのリンクをクリックします。

  4. 「Server Certificate Name」ドロップダウンリストから待機ソケットのサーバー証明書を選択して、「了解」をクリックします。

    このリストには、インストールされているすべての内部および外部の証明書が記載されています。

    手動で server.xml ファイルを編集することにより、代わりにそのサーバー証明書を使用して起動することをサーバーに指示することもできます。SSLPARAMS の servercertnickname 属性を次のように変更します。

    $TOKENNAME:Server-Cert

    $TOKENNAME に使用する値を知るには、サーバーの「Security」タブに移動して、「Manage Certificates」リンクを選択します。Server-Cert の格納されている外部モジュールにログインすると、$TOKENNAME:$NICKNAME フォームのリストにその証明書が表示されます。

    信頼データベースを作成していない場合には、外部 PKCS #11 モジュールの証明書を要求するかまたはインストールすると、信頼データベースが 1 つ作成されます。作成されるデフォルトのデータベースには、パスワードがないためアクセスできません。外部モジュールは動作しますが、サーバー証明書を要求してインストールすることはできません。パスワードのないデフォルトのデータベースが作成された場合には、「Security」タブの「Create Database」ページを使用してパスワードを設定してください。

FIPS-140 標準

PKCS #11 API を使用すれば、暗号化操作を実行するソフトウェアまたはハードウェアモジュールとの通信が可能です。PKCS #11 を Proxy Server にインストールすると、 FIPS-140 に準拠するよう、Proxy Server を設定できます。FIPS は Federal Information Processing Standards の略です。これらのライブラリは、SSL 3.0 にのみ含まれています。

ProcedureFIPS-140 を有効にするには

  1. FIPS-140 の指示に従ってプラグインをインストールします。

  2. 管理サーバーまたはサーバーマネージャーにアクセスし、「Preferences」タブをクリックします。

  3. 「Edit Listen Sockets」リンクをクリックします。

    待機ソケットがセキュリティー保護されている場合は、「Edit Listen Sockets」ページに使用可能なセキュリティー設定が表示されます。

    FIPS-140 を使用するには、選択している待機ソケットでセキュリティーが有効になっている必要があります。詳細は、「待機ソケットのセキュリティーの有効化」を参照してください。

  4. 「Enabled」が選択されていない場合は、「SSL Version 3」ドロップダウンリストから選択します。

  5. 次のうち、適切な FIPS-140 暗号化方式のセットを選択して、「了解」をクリックします。

    • Enable Triple DES with 168–bit encryption and SHA authentication (FIPS)

      • Enable DES with 56–bit encryption and SHA authentication (FIPS)

クライアントセキュリティー要件の設定

サーバーをセキュリティー保護するためのすべての手順が終了したあと、クライアントに関するその他のセキュリティー要件を設定できます。

クライアント認証は、SSL 接続に必須ではありませんが、使用すると、暗号化された情報がさらに確実に適切な相手に送信されます。クライアント認証を逆プロキシで使用して、コンテンツサーバーが、承認されていないプロキシやクライアントと情報を共有しないようにすることができます。

ここでは、次の内容について説明します。

クライアント認証の要求

管理サーバーと各サーバーインスタンスの待機ソケットが、クライアント認証を要求できるようになります。クライアント認証を有効にすると、クエリーに対してサーバーが応答を送信する前に、クライアントの証明書が必要となります。

Proxy Server は、クライアント証明書に含まれる CA と、署名済みクライアント証明書の信頼された CA を照合することによってクライアント証明書の認証をサポートします。「Security」タブにある「Manage Certificates」ページで、署名済みクライアント証明書の信頼された CA のリストを表示できます。

信頼された CA からのクライアント証明書を持っていないクライアントを拒否するように Proxy Server を設定できます。信頼された CA を受け入れ、または拒否するには、その CA についてクライアントの信頼を設定する必要があります。詳細は、「証明書の管理」を参照してください。

Proxy Server は、エラーの記録、証明書の拒否、および証明書が期限切れの場合にはクライアントに対してメッセージの返送を行います。また、「Manage Certificates」ページで、有効期限切れの証明書を表示できます。

クライアントの証明書から情報を収集し、これを LDAP ディレクトリ内のユーザーエントリと照合するようにサーバーを設定できます。このようにすると、確実に LDAP ディレクトリ内で有効な証明書とエントリをクライアントが持つようにできます。また、クライアント証明書が LDAP ディレクトリ内の証明書と確実に一致するようにできます。これを実行する方法については、「LDAP へのクライアント証明書のマッピング」を参照してください。

証明書のあるユーザーは、信頼された CA だけでなく、アクセス制御の規則 (Access Control Rule、ACL) とも一致しなければならないように、クライアント証明書をアクセス制御と組み合わせることができます。詳細は、「アクセス制御ファイルの使用」を参照してください。

Procedureクライアントの認証を要求するには

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Preferences」タブをクリックします。

  2. 「Edit Listen Sockets」リンクをクリックします。

  3. クライアント認証を要求している待機ソケットのリンクをクリックします。

  4. 「Client Authentication」ドロップダウンリストを使用し、待機ソケットのクライアント認証を要求して、「了解」をクリックします。

逆プロキシでのクライアント認証

逆プロキシでは、次のいずれかのシナリオに応じて、クライアント認証を設定できます。

これらのシナリオの設定方法については、「逆プロキシでのクライアント認証の設定」を参照してください。

逆プロキシでのクライアント認証の設定

セキュリティー保護された逆プロキシでクライアント認証を実行すると、接続のセキュリティー性がさらに保証されます。次の手順では、ユーザーが選択するシナリオに応じたクライアント認証の設定方法について説明します。

注 –

各シナリオでは、セキュリティー保護されたクライアント - プロキシ間接続と、セキュリティー保護されたプロキシ - コンテンツサーバー間接続の両方がなされていることを前提としています。

Procedure「プロキシがクライアントを認証」シナリオを設定するには

  1. 第 14 章「逆プロキシの使用」の「逆プロキシの設定」での指示に従って、セキュリティー保護されたクライアント - プロキシと、セキュリティー保護されたプロキシ - コンテンツサーバーのシナリオを設定します。

  2. サーバーマネージャーにアクセスしてサーバーインスタンスを選択し、「Preferences」タブをクリックします。

  3. 「Edit Listen Sockets」リンクをクリックして、表示される表内にある目的の待機ソケットのリンクをクリックします。

    「Add Listen Socket」リンクを使用して、待機ソケットを設定および追加します。

  4. 次のようにして、クライアント認証要件を指定します。

    1. 有効な証明書を持つすべてのユーザーにアクセスを許可するには、次の手順に従います。

      「Security」セクションで、「Client Authentication」設定を使用して、この待機ソケットのクライアント認証を要求します。サーバー証明書がインストールされていない場合は、この設定は表示されません。

    2. 両方の有効な証明書を持ち、アクセス制御で受け入れ可能なユーザーとして指定されているユーザーだけにアクセスを許可するには、次の手順に従います。

      1. 「Security」セクションで、「Client Authentication」設定をオフのままにします。サーバー証明書がインストールされていない場合は、この設定は表示されません。

      2. このサーバーインスタンスのサーバーマネージャーの「Preferences」タブで、「Administer Access Control」リンクをクリックします。

      3. ACL を選択し、「Edit」ボタンをクリックします。

        「Access Control Rules For」ページが表示されます。プロンプトが表示された場合は、先に認証を行ってください。

      4. アクセス制御を有効にします。「Access control Is On」チェックボックスが選択されていない場合は選択します。

      5. Proxy Server を逆プロキシとして認証するように設定します。

        詳細は、「逆プロキシの設定」を参照してください。

      6. 希望するアクセス制御ルールの「Rights」リンクをクリックして、下のフレームでアクセス権を指定し、「Update」をクリックしてこのエントリを更新します。

      7. 「Users/Groups」リンクをクリックします。下のフレームで、ユーザーとグループを指定し、認証方法として SSL を選択し、「Update」をクリックしてこのエントリを更新します。

      8. 上のフレームで「Submit」をクリックして、エントリを保存します。

        アクセス制御の設定については、第 8 章「サーバーへのアクセス制御」を参照してください。

Procedure「コンテンツサーバーがプロキシを認証」シナリオを設定するには

  1. 「逆プロキシの設定」の指示に従って、セキュリティー保護されたクライアント - プロキシと、セキュリティー保護されたプロキシ - コンテンツサーバーのシナリオを設定します。

  2. コンテンツサーバーで、クライアント認証を有効にします。

    このシナリオを変更して、Proxy Server に対してはセキュリティー保護されていないクライアント接続、コンテンツサーバーに対してはセキュリティー保護された接続を設定し、かつコンテンツサーバーが Proxy Server を認証するようにすることができます。これを行うには、次の手順で説明しているように、暗号化を無効にして、プロキシに証明書のみの初期化を指示する必要があります。

Procedure「プロキシがクライアントを認証、かつコンテンツサーバーがプロキシを認証」シナリオを設定するには

  1. 「「プロキシがクライアントを認証」シナリオを設定するには」での指示に従って、「プロキシがクライアントを認証」シナリオを設定します。

  2. コンテンツサーバーで、クライアント認証を有効にします。

LDAP へのクライアント証明書のマッピング

この節では、Proxy Server がクライアント証明書を LDAP ディレクトリ内のエントリにマップするために使用するプロセスについて説明します。LDAP にクライアント証明書をマッピングする前に、必要な ACL も設定しておく必要があります。詳細は、第 8 章「サーバーへのアクセス制御」を参照してください。

サーバーがクライアントから要求を受信すると、処理を進める前にサーバーはクライアントの証明書を求めます。一部のクライアントは、要求と一緒にクライアント証明書をサーバーに送信します。

サーバーは、管理サーバーの信頼された CA リストとその証明書の発行元である CA を照合します。一致しない場合、Proxy Server は接続を終了します。一致した場合、サーバーは要求の処理を続行します。

証明書が信頼された CA からのものであることを確認したあと、サーバーは、次の方法で LDAP エントリにその証明書をマップします。

サーバーは、certmap.conf と呼ばれる証明書マッピングファイルを使用して LDAP 検索の実行方法を決定します。このマッピングファイルは、クライアント証明書から取得する値 (エンドユーザー名、電子メールアドレスなど) をサーバーに指示します。サーバーは、これらの値を使用して LDAP ディレクトリ内にユーザーエントリがないか検索しますが、はじめに、LDAP ディレクトリ内のどこから検索を開始するかを決定する必要があります。証明書マッピングファイルは、開始する場所もサーバーに指示します。

サーバーに、検索を開始する場所および検索する内容が通知されると、LDAP ディレクトリ内で検索を実行します (2 つ目の項目)。一致するエントリがない、または一致するエントリがあってもマッピングが証明書を検証するように設定されていない場合、検索は失敗します。

次の表は、予期される検索結果の動作を示しています。予期される動作は、ACL で指定できます。たとえば、証明書の照合に失敗した場合、自分だけは Proxy Server に受け入れられるように指定できます。ACL の詳細設定については、「アクセス制御ファイルの使用」を参照してください。

表 5–1 LDAP 検索結果

LDAP 検索結果 

証明書の検証がオン 

証明書の検証がオフ 

検出されたエントリなし 

認証失敗 

認証失敗 

検出されたエントリが 1 つのみ 

認証失敗 

認証成功 

検出されたエントリが複数 

認証失敗 

認証失敗 

サーバーが LDAP ディレクトリ内で一致するエントリと証明書を検出したあと、サーバーはその情報を使用してトランザクションを処理できます。たとえば、一部のサーバーでは、サーバーへのアクセスを判断するのに証明書 - LDAP 間マップを使用します。

certmap.conf ファイルの使用

証明書のマッピングは、LDAP ディレクトリ内のユーザーエントリをサーバーがどのように検索するかを決定します。certmap.conf ファイルを使用して、名前で指定された証明書を LDAP エントリにマップする方法を設定できます。このファイルを編集し、LDAP ディレクトリの組織と照合されるようにエントリを追加し、ユーザーに持たせる証明書のリストを表示するようにします。subjectDN 内で使用されているユーザー ID、電子メール、またはその他の値に基づいてユーザーを認証することができます。特に、マッピングファイルでは、次の情報を定義します。

証明書マッピングファイルは、次の場所にあります。

server-root/userdb/certmap.conf

このファイルには、それぞれが異なる CA に適用される、1 つ以上の名前付きマッピングが含まれています。マッピングの構文は、次のとおりです。

certmap name issuerDNname :property [ value]

最初の行にはエントリの名前と、CA 証明書内に記載されている識別名を設定する属性を指定します。name は任意です。好きな名前に定義できます。ただし、issuerDN は、そのクライアント証明書を発行した CA の発行者 DN と完全に一致している必要があります。たとえば、次の 2 つの発行者 DN 行は、属性間に空白文字があるかどうかという点が異なるだけですが、サーバーは、これら 2 つのエントリを別のものとして取り扱います。

certmap sun1 ou=Sun Certificate Authority,o=Sun,c=UScertmap sun2 ou=Sun Certificate Authority, o=Sun, c=US

注 –

Sun Java System Directory Server を使用しているときに issuerDN の照合で問題があった場合は、Directory Server のエラーログを調べて有用な情報を探します。

名前付きマッピングの 2 行目以降の行は、プロパティーが値と照合されます。certmap.conf ファイルには、次に示す 6 つのデフォルトのプロパティーがあります。証明書 API を使用すると、ユーザー独自のプロパティーをカスタマイズできます。デフォルトのプロパティーは次のとおりです。

表 5–2 x509v3 証明書の属性

属性 

説明 

c

国 

o

内容の紹介 

cn

共通名 

l

保存場所 

st

状態 

ou

組織単位 

uid

UNIX/Linux ユーザー ID 

email

電子メール アドレス 

これらのプロパティーについては、「マッピング例」に記載されている 例を参照してください。

カスタムプロパティーの作成

クライアント証明書 API を使用して、独自のプロパティーを作成できます。カスタムマッピングを行ったら、次のようにマッピングを参照します。

name:library path_to_shared_libraryname :InitFN name_of_ init_function

次に例を示します。

certmap default1 o=Sun Microsystems, c=US default1:library /usr/sun/userdb/plugin.so default1:InitFn plugin_init_fn default1:DNComps ou o c default1:FilterComps l default1:verifycert on

マッピング例

certmap.conf ファイルには、少なくとも 1 つのエントリが必要です。次の例では、certmap.conf ファイルを使用できるいくつかの方法を示しています。

例 1 デフォルトのマッピングが 1 つだけある certmap.conf ファイル

certmap default defaultdefault:DNComps ou, o, cdefault:FilterComps e, uiddefault:verifycert on

この例でサーバーは、ou=orgunit、 o=org、c=country エントリを格納している LDAP 分岐点から検索を開始します。ここで斜体のテキストは、クライアント証明書内のサブジェクト DN に記載されている値に置き換えられます。

次に、サーバーが証明書に記載されている電子メールアドレスとユーザー ID の値を使用して、LDAP ディレクトリ内で一致するエントリを検索します。エントリが検出されると、サーバーは、クライアントにより送信されたエントリをディレクトリ内に格納されているエントリと比較して、証明書を検証します。

例 2 2 つのマッピングが記述された certmap.conf ファイル

次のファイル例には、2 つのマッピングが記述されています。1 つはデフォルト用で、もう 1 つは US Postal Service 用です。

certmap default defaultdefault:DNCompsdefault:FilterComps e, uid

certmap usps ou=United States Postal Service, o=usps, c=USusps:DNComps ou,o,cusps:FilterComps eusps:verifycert on

サーバーが US Postal Service 以外から証明書を取得する場合、サーバーはデフォルトのマッピングを使用します。これは、LDAP ツリーの最上部から、クライアントの電子メールアドレスとユーザー ID に一致するエントリの検索を開始します。証明書が US Postal Service からのものである場合、サーバーは、組織単位を格納している LDAP 分岐から検索を開始し、一致する電子メールアドレスを探します。サーバーは証明書の検証も行います。それ以外の証明書は検証されません。

注意 – 注意 –

証明書内の発行者 DN (つまり CA の情報) は、マッピングの最初の行に記述されている発行者 DN と同じでなくてはなりません。前述の例では、o=United States Postal Service,c=US という発行者 DN からの証明書は、o 属性と c 属性の間に空白文字がないため一致しません。

例 3 LDAP データベースの検索

次の例では、CmapLdapAttr プロパティーを使用して、クライアント証明書から取得したサブジェクト DN 全体とぴったり一致する値を持つ certSubjectDN という属性を、LDAP データベースから検索します。この例では、LDAP ディレクトリに certSubjectDN 属性を持つエントリがあることを前提としています。

certmap myco ou=My Company Inc, o=myco, c=USmyco:CmapLdapAttr certSubjectDNmyco:DNComps o, c myco:FilterComps mail, uid myco:verifycert on

次のようなクライアント証明書のサブジェクトを考えます。

uid=Walt Whitman, o=LeavesOfGrass Inc, c=US

サーバーは、はじめに次の情報を格納しているエントリを検索します。

certSubjectDN=uid=Walt Whitman, o=LeavesOfGrass Inc, c=US

1 つまたは複数の一致したエントリが検出された場合、サーバーはそのエントリの検証処理を進めます。一致するエントリが検出されなかった場合には、サーバーは、DNComps と FilterComps を使用して、一致するエントリを検索します。この例では、サーバーは、o=LeavesOfGrass Inc, c=US の下にあるすべてのエントリから uid=Walt Whitman を検索します。

強固な暗号化方式の設定

サーバーマネージャーの「Preferences」タブにある「Set Cipher Size」オプションでは、アクセスするための非公開鍵のサイズに 168、128、または 56 ビットのいずれか、または制限なしを選択できます。制限に適合しない場合に使用するファイルを指定することができます。ファイルが指定されていない場合、Proxy Server が、「Forbidden」ステータスを返します。

アクセスするための鍵サイズとして、「Security Preferences」での現在の暗号化方式の設定と整合しないサイズを選択すると、Proxy Server から、暗号化方式でより大きいサイズの非公開鍵を有効にする必要があることを知らせる警告が表示されます。

現在、鍵サイズ制限の実装は、Service fn=key-toosmall ではなく、obj.conf にある NSAPI PathCheck 指令に基づいています。この指令は次のとおりです。

PathCheck fn="ssl-check" [secret-keysize=nbits ] [bong-file=filename ]

ここで nbits は、非公開鍵で必要とされる最小ビット数で、filename は、制限に適合しない場合に使用されるファイルの名前です。

SSL が有効ではない場合、または secret-keysize パラメータが指定されていない場合、PathCheck は REQ_NOACTION を返します。現在のセッションの非公開鍵サイズが指定された secret-keysize より小さいとき、関数は、bong-file が指定されていない場合には PROTOCOL_FORBIDDEN のステータスとともに REQ_ABORTED を返します。bong-file が指定されている場合、関数は REQ_PROCEED を返して、path 変数が bong-file filename に設定されます。また、鍵のサイズ制限に適合しない場合は、現在のセッションの SSL セッションキャッシュエントリが無効になるため、次回、同じクライアントがサーバーに接続するとき完全な SSL ハンドシェイクが行われます。

注 –

「Set Cipher Size」フォームは、PathCheck fn=ssl-check を追加するときにオブジェクト内で検出された Service fn=key-toosmall 指令を削除します。

Procedure強固な暗号化方式を設定するには

  1. サーバーマネージャーにアクセスしてサーバーインスタンスを選択し、「Preferences」タブをクリックします。

  2. 「Set Cipher Size」リンクをクリックします。

  3. ドロップダウンリストから、強固な暗号化方式を適用するリソースを選択して、「Select」をクリックします。正規表現を指定することもできます。

    詳細は、第 16 章「テンプレートとリソースの管理」を参照してください。

  4. 非公開鍵サイズの制限を選択します。

    • 「168 bits or larger」

      • 「128 bits or larger」

      • 「56 bits or larger」

      • 「No restrictions」

  5. アクセスを拒否するメッセージのファイルの場所を入力して、「了解」をクリックします。

    暗号化方式については、「Introduction to SSL」を参照してください。

その他のセキュリティーに関する注意事項

第三者が暗号を解読しようとする以外にも、セキュリティーに関するリスクがあります。ネットワークは常に、内側と外側から、ハッカーのリスクにさらされています。ハッカーはさまざまな手口を使って、サーバーやサーバーに格納されている情報にアクセスしようとしています。サーバーで暗号化を有効にするだけでなく、別のセキュリティー対策を立てる必要があります。たとえば、セキュリティー保護された部屋にサーバーコンピュータを設置し、信頼できない個人にサーバーへのプログラムのアップロードを許可しないようにするなどです。この節では、サーバーのセキュリティーをさらに強化するのに必要な、重要な事項についていくつか説明します。

ここでは、次の内容について説明します。

物理的アクセスの制限

このシンプルなセキュリティー手段が、意外と見落とされがちです。承認された人だけが入室できる鍵の掛かった部屋にサーバーコンピュータを設置してください。このようにすると、サーバーコンピュータ自体へのハッキングを防げます。また、コンピュータの管理 (root) パスワードを所有している場合には、パスワードを保護しておく必要があります。

管理アクセスの制限

リモート構成を使用している場合、必ず、数人のユーザーと数台のコンピュータだけが管理作業を実行できるように、アクセス制御を設定します。管理サーバーからエンドユーザーの権限で LDAP サーバーやローカルディレクトリ情報へのアクセスを許可 する場合、2 台の管理サーバーを維持し、クラスタ管理を使用することを検討してください。1 台を SSL を有効にしてマスターとなる管理サーバーにし、もう 1 台の管理サーバーをエンドユーザーからアクセスできるようにします。クラスタについては、第 6 章「サーバークラスタの管理」を参照してください。

管理サーバーの暗号化機能もオンにすることをお勧めします。管理に SSL 接続を使用しない場合、リモートサーバーの管理がセキュリティー保護されていないネットワークを介して行われるという点に注意してください。管理パスワードの傍受や、サーバーの再設定がだれにでも可能になってしまいます。

強固なパスワードの選択

サーバーでは多数のパスワードが使用されています。管理パスワード、非公開鍵パスワード、データベースパスワードなどです。この中でもっとも重要なパスワードは管理パスワードです。このパスワードを使えば、誰もがコンピュータ上のどのサーバーの設定でも行えるからです。次に重要なのは、非公開鍵パスワードです。非公開鍵と非公開鍵パスワードを持っていれば誰でも、ユーザーのサーバーであるように見せかけた偽のサーバーを作成したり、サーバーの通信を傍受して改ざんしたりすることができます。

優れたパスワードは、ユーザー自身が覚えやすく、第三者には推測できないようなパスワードです。たとえば、MCi12!mo は「My Child is 12 months old!」として覚えることができます。悪いパスワードの例としては、子供の名前や誕生日などが挙げられます。

推測しにくいパスワードの作成

これらのガイドラインに従って、安全性の高いパスワードを作成できます。1 つのパスワードに次の規則のすべてを取り入れる必要はありませんが、使用する規則が多ければ多いほど、パスワードは推測されにくくなります。いくつかヒントを示します。

パスワードまたは PIN の変更

信頼データベースおよび鍵ペアファイルのパスワードまたは PIN は定期的に変更するようにしてください。管理サーバーで SSL を有効にしている場合、サーバーを起動するときにこのパスワードが必要です。パスワードを定期的に変更すると、サーバーのセキュリティー保護が強化されます。

このパスワードは、ローカルコンピュータでのみ変更することをお勧めします。パスワードを変更するときに考慮する必要のあるガイドラインについては、「推測しにくいパスワードの作成」を参照してください。

Procedure信頼データベース/鍵ペアファイルのパスワードを変更するには

  1. 管理サーバーまたはサーバーマネージャーにアクセスし、「Security」タブを選択します。

  2. 「Change Key Pair File Password」リンクをクリックします。

  3. 「Cryptographic Module」ドロップダウンリストから、パスワードを変更するセキュリティートークンを選択します。

    デフォルトでは、このトークンは内部鍵データベースの「Internal」になっています。PKCS #11 モジュールがインストールされている場合は、すべてのセキュリティートークンが一覧表示されます。

  4. 現在のパスワードを入力します。

  5. 新しいパスワードを入力します。

  6. もう一度新しいパスワードを入力し、「了解」をクリックします。

    鍵ペアファイルは必ずセキュリティー保護するようにします。管理サーバーは、server-root/alias ディレクトリ内に鍵ペアファイルを格納します。

    このファイルがバックアップテープに格納されるのかどうか、または第三者が傍受できるような状態かどうかを知っておくことも大切です。その場合には、バックアップをサーバーと同じように、完全にセキュリティー保護する必要があります。

サーバー上でのほかのアプリケーションの制限

サーバーと同じコンピュータで実行するすべてのアプリケーションを十分に検討します。サーバー上で実行するほかのアプリケーションのセキュリティーホールを利用して、サーバーのセキュリティーが危険にさらされる可能性があります。不必要なプログラムやサービスはすべて無効にしてください。たとえば、UNIX sendmail デーモンは、安全に設定することが難しく、悪影響を及ぼす可能性のあるほかのプログラムをサーバーコンピュータ上で実行するようにプログラムされる可能性があります。

UNIX と Linux

inittab スクリプトと rc スクリプトから開始するプロセスを注意して選択します。telnet または rlogin をサーバーコンピュータから実行しないでください。また、サーバーコンピュータに rdist を置かないでください。このプログラムを使用すると、ファイルを配布できますが、サーバーコンピュータ上のファイルの更新にも使用される可能性があります。

Windows

他のコンピュータと共有するドライブやディレクトリについて、十分に検討してください。また、どのユーザーがアカウントやゲストの特権を所有しているかについても検討してください。サーバー上に置いているプログラムや、ほかのユーザーにインストールを許可するプログラムについても注意してください。ほかのユーザーのプログラムにセキュリティーホールがある可能性もあります。最悪の場合、セキュリティーを侵害するために設計した悪意のあるプログラムを何者かがアップロードする可能性もあります。したがって、サーバー上にプログラムを置くことを許可する前に、そのプログラムを良く調べてください。

クライアントによる SSL ファイルキャッシングの防止

HTML ファイルの <HEAD> セクション内に次の行を追加することで、暗号化されているファイルがクライアントによりキャッシュに書き込まれるのを事前に防止することができます。

<meta http-equiv="pragma" content="no-cache">

ポートの制限

コンピュータ上で使用していないポートは、すべて無効にします。ルーターやファイアウォールの設定を使用して、最低限のポートセット以外には着信接続ができないように設定します。この保護は、すでに制限された領域内にあるサーバーコンピュータを物理的に使用することによってのみ、コンピュータ上でシェルを取得することができるということを意味します。

サーバーの限界の把握

サーバーは、サーバーとクライアントの間でセキュリティー保護された接続ができるようにします。サーバーは、情報がいったんクライアントに取得されると、情報のセキュリティーを制御することはできず、サーバーコンピュータ自体およびそのディレクトリやファイルに対するアクセスも制御できません。

このような限界を認識しておくことは、避けるべき状況を理解するのに役立ちます。たとえば、SSL 接続を介してクレジットカードの番号を取得するとします。しかしそれらの番号はサーバーコンピュータ上のセキュリティー保護されたファイルに格納されるでしょうか。SSL 接続が終了したあとでこれらの番号はどうなるのでしょうか。SSL を介してクライアントから送信されたすべての情報に対して、必ずセキュリティー保護するようにしてください。