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

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

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

クライアント認証は、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=orgc=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 を検索します。