WebLogic Server のセキュリティ
|
 |
 |
|
以下の節では、WebLogic Server の ID と信頼をコンフィグレーションする方法について説明します。
この章の手順を実行する前に、『WebLogic Security について』の「Identity and Trust」を参照してください。
サーバの ID と信頼は、プライベート キー、デジタル証明書、および信頼性のある認証局によって確立され、検証されます。
SSL では、認証用に公開鍵暗号化技術を使用します。公開鍵暗号化では、サーバ用の公開鍵とプライベート キー (秘密鍵) が生成されます。これらのキーは関連付けられているので、公開鍵で暗号化されたデータは、対応するプライベート キーを使用することによってのみ復号化できます (逆も同様)。プライベート キーは注意深く保護されているので、そのオーナーだけが公開鍵で暗号化されたメッセージを解読できます。
公開鍵は、デジタル証明書に組み込まれます。デジタル証明書には、公開鍵のオーナーに関する情報 (名前、番地、電子メール アドレスなど) も組み込まれます。プライベート キーとデジタル証明書によって、サーバに ID が提供されます。
デジタル証明書に組み込まれたデータは認証局によって検証され、その認証局のデジタル証明書でデジタル署名されます。信頼できる認証局には、Verisign や Entrust.net などがあります。信頼性のある認証局 (CA) 証明書によって、証明書の「信頼」が確立されます。
SSL 接続に参加するアプリケーションは、そのアプリケーションのデジタル署名を評価および承認するときに認証を受けます。Web ブラウザ、サーバ、およびその他の SSL 対応アプリケーションは、信頼性のある認証局によって署名され、他の点でも有効なデジタル証明書を真正として承認します。たとえば、デジタル証明書が期限切れの場合や、署名に使用された認証局のデジタル証明書が期限切れの場合、デジタル証明書は無効になります。サーバの証明書は、サーバのデジタル証明書内のホスト名がクライアントによって指定された URL と一致しない場合は無効になります。
サーバ用に ID および信頼を用意するには、次の手順に従います。
keytool ユーティリティ、または、Entrust や Verisign などの信頼できるベンダから、デジタル証明書、プライベート キー、および信頼性のある CA 証明書を取得します。WebLogic Server のキットに用意されているデジタル証明書、プライベート キー、および信頼性のある CA 証明書を使用することもできます。デモ用のデジタル証明書、プライベート キー、および信頼性のある CA 証明書は、開発環境でのみ使用してください。注意 : このリリースの WebLogic Server では、下位互換性を保持するためだけに、ファイルまたは WebLogic キーストア プロバイダに格納されたプライベート キーと信頼性のある CA 証明書がサポートされています。
非推奨のファイルベースのプライベート キー、デジタル証明書、および信頼性のある CA を使用する場合、WebLogic Server では PEM (privacy-enhanced mail) または DER (distinguished encoding rules) フォーマットのデジタル証明書を使用できます。
.pem フォーマット ファイルでは、複数のデジタル証明書がサポートされています。たとえば、証明書チェーンを含むことができます。順序は重要です (信頼順にファイルが含まれます)。サーバのデジタル証明書が、ファイル内の最初のデジタル証明書になる必要があります。そのデジタル証明書の発行元が次のファイルとなり、自己署名のルート認証局証明書にたどり着くまで続くようにします。
.der フォーマットのファイルにはバイナリ データが含まれます。.pem ファイルは複数の証明書に対して使用できますが、.der ファイルは単一の証明書に対してのみ使用できます。
Microsoft は認証局としてよく利用されます。Microsoft は p7b フォーマットで信頼性のある CA 証明書を発行します。この信頼性のある CA 証明書を WebLogic Server で使用する前には、必ず PEM に変換しておく必要があります。詳細については、「Microsoft p7b フォーマットから PEM フォーマットへの変換」を参照してください。
プライベート キー ファイル (キーストアに格納されていないプライベート キー) は、PKCS#5/PKCS#8 PEM フォーマットである必要があります。
WebLogic Server の他のバージョンで使用していたプライベート キーおよびデジタル証明書は、WebLogic Server のこのバージョンでも使用できます。プライベート キーおよびデジタル証明書を PEM (privacy-enhanced mail) 形式から DER (distinguished encoding rules) 形式に変換します。詳細については、『WebLogic Server コマンド リファレンス』の「Using the WebLogic Server Java Utilities」にある der2pem ユーティリティの説明を参照してください。
ファイルの変換後、デジタル証明書ファイルに -----BEGIN CERTIFICATE----- ヘッダと -----END CERTIFICATE----- フッタがあることを確認してください。これらがない場合、デジタル証明書は機能しません。
注意 : OpenSSL は、生成する PEM 証明書にヘッダを追加します。このような証明書を WebLogic Server で使用するには、テキスト エディタを使用して、「-----BEGIN CERTIFICATE-----」の前の部分を証明書から削除します。
サーバでは、プライベート キー、それに一致する公開鍵が含まれているデジタル証明書、および少なくとも 1 つの信頼性のある認証局の証明書が必要です。WebLogic Server では、以下のソースからのプライベート キー、デジタル証明書、信頼性のある CA 証明書をサポートしています。
WL_HOME\server\lib ディレクトリと JAVA_HOME\jre\lib\security ディレクトリにある、デモ用のデジタル証明書、プライベート キー、および信頼性のある CA 証明書。keytool ユーティリティ。このユーティリティを使用すると、プライベート キー、WebLogic Server 用の自己署名デジタル証明書、および CSR (証明書署名リクエスト) を取得できます。 Sun の keytool ユーティリティの詳細については、『keytool - Key and Certificate Management Tool』を参照してください。
注意 : keytool ユーティリティを使用する場合、デフォルトのキー ペア生成アルゴリズムは DSA です。WebLogic Server では、DSA (Digital Signature Algorithm) の使用はサポートされていません。WebLogic Server を使用する場合には、別のキー ペア生成および署名アルゴリズムを指定します。
注意 : Certificate Request Generator サーブレットは、このリリースの WebLogic Server で非推奨になりました。Certificate Request Generator サーブレットの代わりに、Sun Microsystems の keytool ユーティリティを使用してください。詳細については、「一般的な Keytool コマンド」を参照してください。
表 10-1 に、WebLogic Server で JKS キーストアを作成および使用する場合の keytool コマンドを示します。
注意 : keytool ユーティリティは Sun Microsytems の製品です。そのため BEA では、このユーティリティに関する詳細なドキュメントを提供していません。詳細については、『keytool - Key and Certificate Management Tool』を参照してください。
注意 : CertGen ユーティリティで生成されたデジタル証明書とプライベート キーは、プロダクション環境用ではなくデモまたはテスト目的でのみ使用するようにします。
CertGen ユーティリティでは、CA 証明書と、生成された証明書を発行するためのキーを指定する、コマンド ライン オプションを使用できます。このユーティリティでは、デジタル証明書とデモ用の CA 証明書用のプライベート キーが格納された CertGenCA.der および CertGenCAKey.der ファイルがデフォルトで使用されます。CertGen ユーティリティによって生成されたデジタル証明書には、デフォルトではそれらが生成されたマシンのホスト名が共通名フィールド (cn) の値として保持されます。コマンド ライン オプションを使用すると、cn の値と他のサブジェクト ドメイン名 (DN) フィールド (orgunit、organization、locality、state、countrycode など) の値を指定できます。
CertGen ユーティリティでは、公開証明書とプライベート キー ファイルが PEM および DER 形式で生成されます。Windows では、.der ファイルをダブルクリックすると、生成された証明書の詳細を確認できます。.pem ファイルは、WebLogic Server を起動するときやクライアントでデジタル証明書を使用するときに使用できます。
注意 : デフォルトでは、CertGen ユーティリティは現在のディレクトリまたは WL_HOME/server/lib ディレクトリから CertGenCA.der および CertGenCAKey.der ファイルを検索します。これは、weblogic.home システム プロパティまたは CLASSPATH で指定します。
デフォルトの設定を使用する場合、コマンド ラインで CA ファイルを指定する必要はありません。CA ファイルをコマンド ラインで指定する場合は、次のコマンド構文を使用します。
$java utils.CertGen
[-cacert <ca_cert_file-name>] [-cakey <ca_key_filename>]
[-cakeypass <ca_key_password>] [-selfsigned]
[-certfile <certfile>] [-keyfile <privatekeyfile>]
[-keyfilepass <keyfilepassword>] [-strength <keystrength>]
[-cn <commonname>] [-ou <orgunit>] [-o <organization>]
[-l <locality>] [-s <state>] [-c <countrycode>]
[-subjectkeyid <subjectkeyidentifier>]
[-subjectkeyidformat UTF-8|BASE64]
|
|
|
ImportPrivateKey ユーティリティを使用して、デジタル証明書とプライベート キーをキーストアにロードします。『WebLogic Server コマンド リファレンス』の「utils.ImportPrivateKey」を参照してください。-cn オプションでホスト名を明示的に指定しない場合、CertGen ツールは JDK InetAddress.getHostname() メソッドを使用して、サブジェクト共通名に指定するホスト名を取得します。getHostName() メソッドの動作は、プラットフォームによって異なります。Solaris などのプラットフォームでは完全修飾ドメイン名 (FQDN) を返し、Windows NT などでは短いホスト名を返します。WebLogic Server がクライアントとして動作する場合 (およびデフォルトでホスト名検証が有効になっている場合)、URL に指定されるホスト名がサーバの証明書のサブジェクト共通名と一致する必要があります。一致しない場合、接続は失敗します。
Solaris では、InetAddress.getHostname() の結果は、ホスト エントリが /etc/nsswitch.conf ファイルでどのようにコンフィグレーションされているかによって決まります。
多くの企業が独自の認証局として機能しています。それらの信頼性のある CA 証明書を WebLogic Server で使用するには、次の手順に従います。
Microsoft は認証局としてよく利用されます。Microsoft から発行されるデジタル証明書のフォーマット (p7b) は、WebLogic Server では使用できません。p7b フォーマットのデジタル証明書を PEM フォーマットに変換するには、次の手順に従います。
注意 : 証明書チェーンが含まれている p7b 証明書ファイルの場合、発行元の PEM デジタル証明書と証明書ファイルを連結する必要があります。連結されたデジタル証明書は、WebLogic Server で使用できます。
セキュリティ レベルの低いブラウザの証明書は取得が簡単であり、通常は Web ブラウザ内から [オプション] や [環境設定] の [セキュリティ] メニュー項目を選択することで取得できます。[Personal Certificate] ページに移動して、新しいデジタル証明書を申し込みます。自分自身に関する情報を入力します。
受け取るデジタル証明書には、名前や公開鍵などの公開される情報と、電子メール アドレスなど、第三者によって認証される追加情報が含まれます。後で認証が要求された場合に、このデジタル証明書を提示します。
デジタル証明書の取得プロセスの一部として、Web ブラウザは公開鍵/プライベート キーの組み合わせを生成します。プライベート キーは非公開のまま保管する必要があります。デジタル証明書の取得プロセス自体をセキュアなものにするため、プライベート キーはローカル ファイル システムに保管され、Web ブラウザのマシンには残りません。一部のブラウザでは、パスワードを使用してプライベート キーを暗号化できます。パスワードは格納されません。プライベート キーを暗号化すると、セッションごとに少なくとも 1 回は Web ブラウザでパスワードが要求されます。
注意 : Web ブラウザから取得したデジタル証明書は、他のタイプの Web ブラウザや、同じ Web ブラウザの別のバージョンでは機能しません。
注意 : ファイルベースの証明書チェーンの使用は、このリリースの WebLogic Server では非推奨になっています。証明書チェーン全体がキーストアにインポートされるようになりました。次の手順は、下位互換性のみを目的に説明しています。
WebLogic Server で証明書チェーンを使用するには、次の手順に従います。
コード リスト 10-1 に、証明書チェーンのサンプルを示します。
コード リスト 10-1 証明書チェーンを含むファイルのサンプル
-----BEGIN CERTIFICATE-----
MIICyzCCAjSgAwIBAgIBLDANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xFTATBgNVBAoTDEJFQSBXZWJMb2dpYzERMA8GA1UECxMIU2VjdXJpdHkxLzAtBgNVBAMTJkRlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5IENvbnN0cmFpbnRzMR8wHQYJKoZIhvcNAQkBFhBzZWN1cml0eUBiZWEuY29tMB4XDTAyMTEwMTIwMDIxMloXDTA2MTAxNTIwMDIxMlowgZ8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRUwEwYDVQQKEwxCRUEgV2ViTG9naWMxETAPBgNVBAsTCFNlY3VyaXR5MRkwFwYDVQQDExB3ZWJsb2dpYy5iZWEuY29tMR4wHAYJKoZIhvcNAQkBFg9zdXBwb3J0QGJlYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMJX8nKUgsFej8pEu/1IVcHUkwY0c2JbBzOryu3sce4QjX+rGxiCjoPm2MY=yts2BvonuJ6CztdZf8B/LBEWCz+qRrtdFn9mKSZWGvrAkmMPz2RhXEOThpoRo5kZz2FQ9XF/PxIJXTYCM7yooRBwXoKYjquRwiZNtUiU9kYi6Z3prAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAh2eqQGxEMUnNTwEUD
0tBq+7YuAkjecEocGXvi2G4YSoWVLgnVzJoJuds3c35KE6sxBe1luJQuQkE9SzALG/6lDIJ5ctPsHFmZzZxY7scLl6hWj5ON8oN2YTh5Jo/ryqjvnZvqiNIWe/gqr2GLIkajC0mz4un1LiYORPig3fBMH0=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIC+jCCAmOgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xFTATBgNVBAoTDEJFQSBXZWJMb2dpYzERMA8GA1UECxMIU2VjdXJpdHkxLzAtBgNVBAMTJkRlbW8gQ2VydGlmaWNhdGUgQXV0aG9yaXR5IENvbnN0cmFpbnRzMR8wHQYJKoZIhvcNAQkBFhBzZWN1cml0eUBiZWEuY29tMB4XDTAyMTEwMTIwMDIxMVoXDTA2MTAxNjIwMDIxMVowgbYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRUwEwYDVQQKEwxCRUEgV2ViTG9naWMxETAPBgNVBAsTCFNlY3VyaXR5MS8wLQYDVQQDEyZEZW1vIENlcnRpZmljYXRlIEF1dGhvcml0eSBDb25zdHJhaW50czEfMB0GCSqGSIb3DQEJARYQc2VjdXJpdHlAYmVhLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3ynD8l5JfLob4g6d94dNtI0Eep6QNl9bblmswnrjIYz1BVjjRjNVal9fRs+8jvm85kIWlerKzIMJgiNsj50WlXzNX6orszggSsW15pqV0aYE9Re9K
CNNnORlsLjmRhuVxg9rJFEtjHMjrSYr2IDFhcdwPgIt0meWEVnKNObSFYcCAwEAAaMWMBQwEgYDVR0TAQH/BAgwBgEB/wIBATANBgkqhkiG9w0BAQQFAAOBgQBS+0oqWxGyqbZO028zf9tQT2RKojfuwywrDoGW96Un5IqpFnBHIu5atliJo3OUpiH18KkwLN8DVP/3t3K3O3kXdIuLbqAL0i5xyBlAhr7gE5eVhIyeMg7ETBPLyGO2BF13Y24LlsO+MX9jW7fxMraPN608QeJXkZw0E0cGwrw2AQ==
-----END CERTIFICATE-----
プライベート キー、デジタル証明書、および信頼できる認証局 (Certificate Authority : CA) 証明書を取得した後は、それらを格納し、WebLogic Server でそれらを使用して ID を検索および確認できるようにする必要があります。プライベート キー、プライベート キーに関連付けられたデジタル証明書、および信頼できる CA 証明書は、キーストアに格納されます。キーストアは、WebLogic Server Administration Console を使用して、またはコマンドラインから指定することでコンフィグレーションできます。WebLogic Server Administration Console の [コンフィグレーション｜キーストア] ページで、WebLogic Server の ID および信頼キーストアをコンフィグレーションします。Administration Console オンライン ヘルプの「サーバ : コンフィグレーション : キーストア」を参照してください。
下位互換性を保持するために、プライベート キーと信頼性のある CA 証明書をファイル、または WebLogic キーストア プロバイダを介してアクセスされる JKS キーストアに格納できます。さらに、信頼性のある CA 証明書は JKS キーストアにも格納できます。ファイル、または WebLogic キーストア プロバイダを介してアクセスされる JKS キーストアを使用する場合、WebLogic Server Administration Console の [コンフィグレーション｜SSL] ページで ID と信頼について指定できます。
SSL をコンフィグレーションするときに、ID と信頼の格納方法を決定する必要があります。ID と信頼の両方で 1 つのキーストアを使用することはできますが、以下のような理由から、ID と信頼のそれぞれに個別のキーストアを使用することをお勧めします。
ID キーストア (プライベート キーとデジタル証明書のペア) と信頼キーストア (信頼性のある CA 証明書) ではセキュリティ要件が異なる場合があります。以下に例を示します。
信頼の場合は、キーストアに証明書 (非機密データ) を格納するだけですが、ID の場合は、キーストアに証明書とプライベート キー (機密データ) を格納する必要があります。
マシンには、それぞれのサーバ ID が付けられることが多い一方で、ドメイン全体にわたって同じ信頼ルールが備えられる (つまり、信頼性のある CA の同じセットが使用される) ことが多い傾向にあります。ID にはプライベート キーが必要であり、プライベート キーはあるマシンから別のマシンへコピーできません。そのため、マシンごとに別々のキーストアが作成されます。各キーストアにはそのマシンに必要なサーバ ID のみが含まれています。一方、信頼キーストアはマシンからマシンにコピーできるため、信頼ルールの標準化は簡単に行われます。
ID は nCipher などのハードウェア キーストアに格納する場合も多くあります。信頼にはプライベート キーではなく証明書のみが含まれるため、ファイルベースの JDK キーストアに格納してもセキュリティ上の問題はありません。
キーストアは、プライベート キーとデジタル証明書のペアおよび信頼性のある CA 証明書を安全に保存および管理するためのメカニズムです。以下のメカニズムを使用して、キーストアを作成し、プライベート キーと信頼性のある CA 証明書をそのキーストアにロードします。
ImportPrivateKey ユーティリティ。ImportPrivateKey ユーティリティを使用すると、プライベート キーおよびデジタル証明書のファイルを取得してそれらをキーストアにロードできます。詳細については、『WebLogic Server コマンド リファレンス』の「utils.ImportPrivateKey」を参照してください。keytool ユーティリティ。keytool ユーティリティを使用して、プライベート キーとデジタル証明書の組み合わせを生成してから、署名されたプライベート キーをキーストアにインポートします。詳細については、「WebLogic Server が信頼を検索する方法」を参照してください。keytool ユーティリティでは新しいプライベート キーとデジタル証明書を生成してキーストアに追加できますが、既存のプライベート キーをファイルからキーストアにインポートすることはできません。代わりに、WebLogic ImportPrivateKey ユーティリティを使用してください。注意 : keytool ユーティリティでは、ファイル内の信頼性のある CA 証明書をキーストアにインポートできます。
キーストアのすべてのプライベート キー エントリには、固有のエリアスを介して WebLogic Server からアクセスできます。エリアスは、プライベート キーをキーストアにロードするときに指定します。エリアスの大文字/小文字は区別されません。このため、Hugo と hugo は同じキーストア エントリを指します。プライベート キーのエイリアスは、WebLogic Server Administration Console の [コンフィグレーション｜SSL] ページの [プライベート キーのエリアス] フィールドで指定します。
WebLogic Server によって信頼されているものとして識別される、キーストア内の認証局はすべて信頼されます。WebLogic Server では信頼性のある CA 証明書へのアクセスにエリアスは使用されませんが、キーストアでは信頼性のある CA 証明書をキーストアにロードするときにエリアスが要求されます。
WebLogic Server では、信頼性のある CA 証明書をロードするときに次のアルゴリズムが使用されます。
-Dweblogic.security.SSL.trustedCAkeystore コマンドライン引数で指定されている場合は、そのキーストアから信頼性のある CA 証明書がロードされます。config.xml) で指定されている場合は、その指定されたキーストアから信頼性のある CA 証明書がロードされます。サーバで DemoTrust がコンフィグレーションされている場合、信頼性のある CA 証明書は WL_HOME\server\lib\DemoTrust.jks キーストアおよび JDK cacerts キーストアからロードされます。
デフォルトでは、WebLogic Server には以下の 2 種類のキーストアがコンフィグレーションされています。
DemoIdentity.jks - WebLogic Server のデモ用プライベート キーが格納されます。このキーストアには、WebLogic Server の ID が格納されます。DemoTrust.jks - WL_HOME\server\lib\DemoTrust.jks キーストアおよび JDK cacerts キーストアからの信頼性のある認証局が格納されます。このキーストアによって WebLogic Server の信頼が確立されます。これらのキーストアは、WL_HOME\server\lib ディレクトリおよび JAVA_HOME\jre\lib\security ディレクトリにあります。開発目的やテスト目的の場合は、このキーストア コンフィグレーションで十分です。ただし、デモ用キーストアはプロダクション環境では使用しないでください。キーストア内のすべてのデジタル証明書および信頼性のある CA 証明書は、WebLogic Server のデモ用認証局によって署名されます。そのため、インストールされているすべての WebLogic Server は相互に信頼します。この場合、SSL 接続はセキュリティ攻撃に対して無防備な状態のままになります。
キーストアをプロダクション環境で使用するようにコンフィグレーションするには、次の手順に従います。
WebLogic Scripting Tool または Java Management Extensions (JMX) API を使用して新しいセキュリティ コンフィグレーションを作成することもできます。『WebLogic Scripting Tool ガイド』および『JMX によるカスタム管理ユーティリティの開発』を参照してください。
|
|
|