サーバーをセキュリティー保護するためのすべての手順が終了したあと、クライアントに関するその他のセキュリティー要件を設定できます。
クライアント認証は、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) とも一致しなければならないように、クライアント証明書をアクセス制御と組み合わせることができます。詳細は、「アクセス制御ファイルの使用」を参照してください。
管理サーバーまたはサーバーマネージャーにアクセスし、「Preferences」タブをクリックします。
「Edit Listen Sockets」リンクをクリックします。
クライアント認証を要求している待機ソケットのリンクをクリックします。
「Client Authentication」ドロップダウンリストを使用し、待機ソケットのクライアント認証を要求して、「了解」をクリックします。
逆プロキシでは、次のいずれかのシナリオに応じて、クライアント認証を設定できます。
「プロキシがクライアントを認証」:このシナリオでは、受け入れ可能な証明書を持つクライアントすべてにアクセスを許可するか、または受け入れ可能な証明書があり、かつ Proxy Server のアクセス制御リスト上で認識されたユーザーであるクライアントだけにアクセスを許可することができます。
プロキシには、CA またはユーザー証明書に署名した自己署名アプリケーションのユーザールート鍵が必要です。ユーザーは、CA または Proxy Server 証明書に署名した自己署名アプリケーションの Proxy Server ルート鍵をロードしている必要があります。
「コンテンツサーバーがプロキシを認証」:このシナリオでは、コンテンツサーバーが Proxy Server に実際に接続していて、その他のサーバーには接続していないことを確認することができます。
プロキシには、CA またはコンテンツサーバー証明書に署名した自己署名アプリケーションのコンテンツサーバールート鍵が必要です。コンテンツサーバーには、CA または Proxy Server 証明書に署名した自己署名アプリケーションの Proxy Server ルート鍵が必要です。
「プロキシがクライアントを認証、かつコンテンツサーバーがプロキシを認証」:このシナリオでは、逆プロキシでのセキュリティーと認証を最大限にします。
これらのシナリオの設定方法については、「逆プロキシでのクライアント認証の設定」を参照してください。
セキュリティー保護された逆プロキシでクライアント認証を実行すると、接続のセキュリティー性がさらに保証されます。次の手順では、ユーザーが選択するシナリオに応じたクライアント認証の設定方法について説明します。
各シナリオでは、セキュリティー保護されたクライアント - プロキシ間接続と、セキュリティー保護されたプロキシ - コンテンツサーバー間接続の両方がなされていることを前提としています。
第 14 章逆プロキシの使用の「逆プロキシの設定」での指示に従って、セキュリティー保護されたクライアント - プロキシと、セキュリティー保護されたプロキシ - コンテンツサーバーのシナリオを設定します。
サーバーマネージャーにアクセスしてサーバーインスタンスを選択し、「Preferences」タブをクリックします。
「Edit Listen Sockets」リンクをクリックして、表示される表内にある目的の待機ソケットのリンクをクリックします。
「Add Listen Socket」リンクを使用して、待機ソケットを設定および追加します。
次のようにして、クライアント認証要件を指定します。
有効な証明書を持つすべてのユーザーにアクセスを許可するには、次の手順に従います。
「Security」セクションで、「Client Authentication」設定を使用して、この待機ソケットのクライアント認証を要求します。サーバー証明書がインストールされていない場合は、この設定は表示されません。
両方の有効な証明書を持ち、アクセス制御で受け入れ可能なユーザーとして指定されているユーザーだけにアクセスを許可するには、次の手順に従います。
「Security」セクションで、「Client Authentication」設定をオフのままにします。サーバー証明書がインストールされていない場合は、この設定は表示されません。
このサーバーインスタンスのサーバーマネージャーの「Preferences」タブで、「Administer Access Control」リンクをクリックします。
ACL を選択し、「Edit」ボタンをクリックします。
「Access Control Rules For」ページが表示されます。プロンプトが表示された場合は、先に認証を行ってください。
アクセス制御を有効にします。「Access control Is On」チェックボックスが選択されていない場合は選択します。
Proxy Server を逆プロキシとして認証するように設定します。
詳細は、「逆プロキシの設定」を参照してください。
希望するアクセス制御ルールの「Rights」リンクをクリックして、下のフレームでアクセス権を指定し、「Update」をクリックしてこのエントリを更新します。
「Users/Groups」リンクをクリックします。下のフレームで、ユーザーとグループを指定し、認証方法として SSL を選択し、「Update」をクリックしてこのエントリを更新します。
上のフレームで「Submit」をクリックして、エントリを保存します。
アクセス制御の設定については、第 8 章サーバーへのアクセス制御を参照してください。
「逆プロキシの設定」の指示に従って、セキュリティー保護されたクライアント - プロキシと、セキュリティー保護されたプロキシ - コンテンツサーバーのシナリオを設定します。
コンテンツサーバーで、クライアント認証を有効にします。
このシナリオを変更して、Proxy Server に対してはセキュリティー保護されていないクライアント接続、コンテンツサーバーに対してはセキュリティー保護された接続を設定し、かつコンテンツサーバーが Proxy Server を認証するようにすることができます。これを行うには、次の手順で説明しているように、暗号化を無効にして、プロキシに証明書のみの初期化を指示する必要があります。
「「プロキシがクライアントを認証」シナリオを設定するには」での指示に従って、「プロキシがクライアントを認証」シナリオを設定します。
コンテンツサーバーで、クライアント認証を有効にします。
この節では、Proxy Server がクライアント証明書を LDAP ディレクトリ内のエントリにマップするために使用するプロセスについて説明します。LDAP にクライアント証明書をマッピングする前に、必要な ACL も設定しておく必要があります。詳細は、第 8 章サーバーへのアクセス制御を参照してください。
サーバーがクライアントから要求を受信すると、処理を進める前にサーバーはクライアントの証明書を求めます。一部のクライアントは、要求と一緒にクライアント証明書をサーバーに送信します。
サーバーは、管理サーバーの信頼された CA リストとその証明書の発行元である CA を照合します。一致しない場合、Proxy Server は接続を終了します。一致した場合、サーバーは要求の処理を続行します。
証明書が信頼された CA からのものであることを確認したあと、サーバーは、次の方法で LDAP エントリにその証明書をマップします。
クライアント証明書の発行者とサブジェクト DN を LDAP ディレクトリ内の分岐点にマップします。
クライアント証明書のサブジェクト (エンドユーザー) に関する情報と一致するエントリがないか LDAP ディレクトリを検索します。
(オプション) DN に対応する LDAP エントリ内のクライアント証明書とそのクライアント証明書を検証します。
サーバーは、certmap.conf と呼ばれる証明書マッピングファイルを使用して LDAP 検索の実行方法を決定します。このマッピングファイルは、クライアント証明書から取得する値 (エンドユーザー名、電子メールアドレスなど) をサーバーに指示します。サーバーは、これらの値を使用して LDAP ディレクトリ内にユーザーエントリがないか検索しますが、はじめに、LDAP ディレクトリ内のどこから検索を開始するかを決定する必要があります。証明書マッピングファイルは、開始する場所もサーバーに指示します。
サーバーに、検索を開始する場所および検索する内容が通知されると、LDAP ディレクトリ内で検索を実行します (2 つ目の項目)。一致するエントリがない、または一致するエントリがあってもマッピングが証明書を検証するように設定されていない場合、検索は失敗します。
次の表は、予期される検索結果の動作を示しています。予期される動作は、ACL で指定できます。たとえば、証明書の照合に失敗した場合、自分だけは Proxy Server に受け入れられるように指定できます。ACL の詳細設定については、「アクセス制御ファイルの使用」を参照してください。
表 5–1 LDAP 検索結果
LDAP 検索結果 |
証明書の検証がオン |
証明書の検証がオフ |
---|---|---|
検出されたエントリなし |
認証失敗 |
認証失敗 |
検出されたエントリが 1 つのみ |
認証失敗 |
認証成功 |
検出されたエントリが複数 |
認証失敗 |
認証失敗 |
サーバーが LDAP ディレクトリ内で一致するエントリと証明書を検出したあと、サーバーはその情報を使用してトランザクションを処理できます。たとえば、一部のサーバーでは、サーバーへのアクセスを判断するのに証明書 - LDAP 間マップを使用します。
証明書のマッピングは、LDAP ディレクトリ内のユーザーエントリをサーバーがどのように検索するかを決定します。certmap.conf ファイルを使用して、名前で指定された証明書を LDAP エントリにマップする方法を設定できます。このファイルを編集し、LDAP ディレクトリの組織と照合されるようにエントリを追加し、ユーザーに持たせる証明書のリストを表示するようにします。subjectDN 内で使用されているユーザー ID、電子メール、またはその他の値に基づいてユーザーを認証することができます。特に、マッピングファイルでは、次の情報を定義します。
LDAP ツリー内でサーバーが検索を開始する場所
LDAP ディレクトリ内のエントリを検索するときにサーバーが検索条件として使用する証明書の属性
サーバーが追加の検証プロセスを実施するかどうか
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 を使用すると、ユーザー独自のプロパティーをカスタマイズできます。デフォルトのプロパティーは次のとおりです。
DNComps はコンマで区切った属性のリストで、ユーザーの情報、つまりクライアント証明書の所有者と一致するエントリの検索を、サーバーが LDAP ディレクトリ内のどこから開始するかを判断するために使用されます。サーバーは、クライアント証明書からこれらの属性の値を収集し、LDAP DN を設定するためにその値を使用します。これが、LDAP ディレクトリ内でサーバーが検索を開始する場所を決定します。たとえば、DN の o 属性と c 属性を使用するよう DNComps を設定した場合、サーバーは、LDAP ディレクトリ内の o=org、c= country エントリから検索を開始します。ここで org と country は、証明書内の DN に記載されている値に置き換えられます。
次のような場合には注意が必要です。
マッピング内に DNComps エントリがない場合、サーバーは CmapLdapAttr の設定、またはクライアント証明書内のサブジェクト DN 全体 (つまりエンドユーザーの情報) のいずれかを使用します。
DNComps エントリはあるが値がないという場合、サーバーは LDAP ツリー全体を検索してフィルタに一致するエントリを探します。
FilterComps は、コンマで区切った属性のリストで、クライアント証明書内のユーザーの DN から情報を収集してフィルタを作成するために使用されます。サーバーは、これらの属性の値を使用して、LDAP ディレクトリ内でエントリを照合するために使用する検索条件を作成します。サーバーが LDAP ディレクトリ内で、証明書から収集したユーザー情報に一致する 1 つまたは複数のエントリを検出した場合、検索は成功し、オプションでサーバーが検証を行います。
たとえば、電子メール属性とユーザー ID 属性を使用するよう FilterComps を設定すると (FilterComps=e,uid)、サーバーは、電子メールとユーザー ID の値がクライアント証明書から収集したエンドユーザーの情報と一致するエントリをディレクトリから検索します。電子メールアドレスとユーザー ID は、通常、ディレクトリ内で一意のエントリであるため、フィルタとして適切です。フィルタは、LDAP データベース内で 1 つだけのエントリと一致するような特有のものである必要があります。
フィルタのための属性名は、LDAP ディレクトリではなく、証明書から取得した属性名である必要があります。たとえば、一部の証明書にはユーザーの電子メールアドレスの e 属性がありますが、LDAP では、この属性を mail と呼んでいます。
次の表は、x509v3 証明書の属性を示しています。
属性 |
説明 |
---|---|
国 |
|
組織 |
|
共通名 |
|
保存場所 |
|
状態 |
|
組織単位 |
|
UNIX/Linux ユーザー ID |
|
電子メール アドレス |
verifycert は、クライアントの証明書と LDAP ディレクトリ内で見つかった証明書とを比較するかどうかサーバーに指示します。プロパティーは次の 2 つの値を取ります。「on」と「off」です。ただし、このプロパティーは、LDAP ディレクトリに証明書があるときだけ使用してください。この機能は、エンドユーザーが、有効で、取り消されていない証明書を所有していることを確認するのに便利です。
CmapLdapAttr は、LDAP ディレクトリ内の属性の名前で、対象のユーザーに属しているすべての証明書に記載されているサブジェクト DN が含まれています。このプロパティーのデフォルトは、certSubjectDN です。この属性は標準の LDAP 属性ではないため、このプロパティーを使用するには、LDAP スキーマを拡張する必要があります。詳細は、「Introduction to SSL」を参照してください。
このプロパティーが certmap.conf ファイル内に存在する場合、サーバーは、このプロパティーの名前の付いた属性が、証明書から取得されたサブジェクトの完全な DN に一致しているエントリを LDAP ディレクトリ全体から検索します。エントリが検出されなかった場合、サーバーは DNComps マッピングと FilterComps マッピングを使用して、検索を再試行します。
LDAP エントリと証明書を照合するためのこの方法は、DNComps と FilterComps を使用してエントリを照合することが難しい場合に便利です。
Library は、共用ライブラリまたは DLL へのパス名です。証明書 API を使用して独自のプロパティーを作成する場合のみ、このプロパティーを使用してください。
InitFn は、カスタムライブラリの init 関数の名前です。証明書 API を使用して独自のプロパティーを作成する場合のみ、このプロパティーを使用してください。
これらのプロパティーについては、「マッピング例」に記載されている 例を参照してください。
クライアント証明書 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 ファイルを使用できるいくつかの方法を示しています。
certmap default defaultdefault:DNComps ou, o, cdefault:FilterComps e, uiddefault:verifycert on
この例でサーバーは、ou=orgunit、 o=org、c=country エントリを格納している LDAP 分岐点から検索を開始します。ここで斜体のテキストは、クライアント証明書内のサブジェクト DN に記載されている値に置き換えられます。
次に、サーバーが証明書に記載されている電子メールアドレスとユーザー ID の値を使用して、LDAP ディレクトリ内で一致するエントリを検索します。エントリが検出されると、サーバーは、クライアントにより送信されたエントリをディレクトリ内に格納されているエントリと比較して、証明書を検証します。
次のファイル例には、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 属性の間に空白文字がないため一致しません。
次の例では、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 を検索します。