WebLogic Server のセキュリティ
|
 |
 |
|
SSL のコンフィグレーションは省略可能ですが、プロダクション環境では SSL を使用することをお勧めします。以下の節では、WebLogic Server に対して SSL をコンフィグレーションする方法について説明します。
注意 : この章は、このリリースの WebLogic Server のセキュリティ機能を使用する WebLogic Server デプロイメントと互換性セキュリティを使用するデプロイメントに適用されます。
すべてのマシンに対して、オペレーティング システム ベンダの最新の推奨パッチを適用しておく必要があります。
セキュア ソケット レイヤ (Secure Sockets Layer: SSL) では、ネットワーク接続している 2 つのアプリケーションが互いの ID を認証できるようにするとともに、アプリケーション間でやりとりされるデータを暗号化することで、セキュアな接続を実現します。認証を使用すると、サーバとクライアント (省略可能) はネットワーク接続の相手側アプリケーションの ID を検証できます。ネットワーク経由で送信されるデータは暗号化されるので、予定されている宛先以外には解釈できません。
WebLogic Server の SSL は、SSL 3.0 および TLS (Transport Layer Security) 1.0 仕様の実装です。
WebLogic Server は、専用のリスン ポート (デフォルトは 7002) で SSL をサポートします。SSL 接続を確立するには、接続 URL に SSL リスン ポートと HTTPS プロトコルを指定して (https://myserver:7002 など)、Web ブラウザから WebLogic Server に接続します。
SSL を使用すると、計算処理による負荷が大きくなり、接続のオーバーヘッドが増大します。必要なとき以外は開発環境で SSL を使用しないでください。ただし、プロダクション環境では常に SSL を使用してください。
SSL は、一方向または双方向としてコンフィグレーションできます。
keytool ユーティリティ、または Verisign や Entrust などの信頼できるベンダを使用します。 注意 : このリリースの WebLogic Server では、下位互換性を保持するためだけに、ファイルまたは WebLogic キーストア プロバイダに格納されたプライベート キーと信頼性のある CA 証明書がサポートされています。
注意 : WebLogic Server インスタンスの起動時に、コマンド ライン引数 -Dweblogic.security.ssl.nojce=true を指定して FIPS 準拠の (FIPS 140-2) 暗号モジュールを使用できます。
WebLogic Server 用の ID と信頼のコンフィグレーションについては、「プライベート キー、デジタル証明書、信頼性のある認証局の取得」と「プライベート キー、デジタル証明書、信頼性のある認証局の格納」を参照してください。
ホスト名検証では、クライアントの接続先 URL のホスト名と、SSL 接続の一部としてサーバが返送するデジタル証明書のホスト名が一致していることを確認します。ホスト名検証は、SSL クライアント (または SSL クライアントとして機能している WebLogic Server) がリモート ホスト上のアプリケーション サーバに接続する場合に役立ちます。また、介在者の攻撃 (man-in-the-middle attack) を防ぐのに役立ちます。
WebLogic Server ではデフォルトでホスト名検証が有効になっています。WebLogic Server の SSL ハンドシェーク機能としての動作は、SSL サーバのデジタル証明書の SubjectDN にある共通名と、SSL 接続の開始に使用する SSL サーバのホスト名を比較することです。これらの名前が一致しない場合は SSL 接続が中断されます。名前が一致しない場合は SSL クライアントが実際に SSL 接続を中断します。
デフォルト以外の動作が必要な場合は、ホスト名検証を無効にするか、カスタム ホスト名検証をコンフィグレーションします。ホスト名検証を無効にすると、WebLogic Server は介在者の攻撃に対して無防備な状態になります。プロダクション環境では、ホスト名検証を有効にしておくことをお勧めします。
このリリースの WebLogic Server ではホスト名検証機能が更新されており、証明書のホスト名がローカル マシンのホスト名と一致する場合、ホスト名検証は URL で localhost、127.0.01、またはローカル マシンのデフォルト IP アドレスが指定されている場合にパスします。
詳細については、Administration Console オンライン ヘルプの以下のトピックを参照してください。
SSL デバッグは、SSL ハンドシェーク中に発生した SSL イベントに関する詳細な情報を提供します。SSL デバッグのトレースには、以下のものに関する情報が記載されます。
次のコマンドライン プロパティを使用して SSL デバッグを有効にします。
-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
SSL デバッグ プロパティは、SSL サーバ、SSL クライアント、およびノード マネージャの起動スクリプトに含めることができます。ノード マネージャによって起動される管理対象サーバに対しては、管理対象サーバの [サーバの起動] ページでこのコマンドライン引数を指定します。
SSL デバッグは、SSL プロセスで ALERT が作成されるとスタック トレースをダンプします。ALERT のタイプと重大度は、TLS 仕様で定義されています。
スタック トレースは、情報を ALERT が発生した場所のログ ファイルにダンプします。そのため、SSL の問題を追跡する場合は、SSL 接続の両側 (SSL クライアントと SSL サーバの両方で) でデバッグを有効にしておく必要があります。ログ ファイルには、障害が発生した場所に関する詳細な情報が記録されます。ALERT が発生した場所を判別するには、ALERT の後にトレース メッセージがあるかどうかを確認します。トレース メッセージの後に受信された ALERT によって、そのピアで障害が発生したことがわかります。問題を判別するには、SSL 接続のそのピアで SSL デバッグを有効にしておく必要があります。
SSL の問題を追跡する場合は、ログ ファイルの情報を調べて以下のことを確認します。
config.xml ファイルがロードされたこと。注意 : Sev 1 type 0 は、正常なクローズ ALERT であり、問題ではありません。
WebLogic Server SSL には、証明書検証が組み込まれています。証明書検証では、信頼性のある CA のセットに対して、以下のことを行います。
証明書検索および検証 (CLV) プロバイダを使用すると、証明書チェーンに対してさらに検証を行うことができます。このリリースでは、WebLogic Server に以下の 2 種類の CLV プロバイダが追加されました。
また、カスタム証明書パス検証プロバイダを作成して、証明書チェーンに対してさらに検証を行うこともできます。詳細については、「WebLogic セキュリティ プロバイダのコンフィグレーション」を参照してください。
WebLogic Server インスタンスの発信 SSL と双方向着信 SSL は、検証が必要な証明書チェーンを SSL ハンドシェーク中に受け取ります。双方向着信 SSL の例は、HTTPS で Web アプリケーションに接続するブラウザです。この場合、ブラウザはクライアントの証明書チェーンを Web アプリケーションに送信します。着信証明書検証の設定は、サーバでのすべての双方向クライアント証明書検証のために使用されます。
発信 SSL を使用する (SSL クライアントとして動作する) WebLogic Server の例は以下のとおりです。
Administration Console または WLST を使用すると、SSLMBean 属性の InboundCertificateValidation と OutboundCertificateValidation で着信および発信 SSL 証明書検証を別個にコンフィグレーションできます。
BUILTIN_SSL_VALIDATION - 組み込み SSL 証明書検証コードを使用して証明書チェーンを完成および検証します。つまり、SSL は旧リリースと同じように動作します。これはデフォルトの動作です。BUILTIN_SSL_VALIDATION_AND_CERT_PATH_VALIDATORS - 組み込みの信頼性のある CA に基づいた検証と、コンフィグレーション済みの証明書パス検証プロバイダを使用して追加の検証を実行します。つまり、SSL は旧リリースの動作に加えて、追加の検証を行います。
WebLogic Server では、SSL セッションをキャッシュできます。これらのセッションは、サーバの稼働時間にわたって存続します。
SSL ソケットを直接使用するクライアントは、SSL セッション キャッシュの動作を制御できます。SSL セッション キャッシュは、各 SSL コンテキストに固有のものです。特定の SSL コンテキストによって返された SSL ソケット ファクトリ インスタンスによって作成されたすべての SSL ソケットは、SSL セッションを共有します。
クライアントは、デフォルトによって同じ IP アドレスとポートでセッションを再開します。デフォルトでは、複数の SSL ソケットが同じホストとポートを使用して SSL セッションを共有し、SSL ソケットが共通の SSL コンテキストを使用していると見なします。
SSL セッションを使用しないクライアントは、SSL ソケットで setEnableSessionCreation(false) を呼び出して SSL セッションがキャッシュされないようにする必要があります。この設定は、SSL セッションがキャッシュに追加されるかどうかだけを制御するもので、SSL ソケットがキャッシュ済みの SSL セッションを検索することを停止するものではありません。たとえば、SSL ソケット 1 がセッションをキャッシュし、SSL ソケット 2 が setEnableSessionCreation を false に設定した場合でも、SSL ソケット 1 の SSL セッションはキャッシュに存在するので、SSL ソケット 2 はそのセッションを再利用できます。
SSL セッションは SSL コンテキストの存続期間にわたって存在し、SSL ソケットの存続期間によって制御されません。このため、新しい SSL ソケットを作成し、同じホストとポートに接続した場合、その SSL ソケットがキャッシュ内に前の SSL セッションを持つ SSL コンテキストの SSL ソケット ファクトリを使用して作成される限り、前のセッションを再開できます。
デフォルトでは、HTTPS URL を使用するクライアントは、URL ごとに新しい SSL セッションを取得します。これは、各 URL が異なる SSL コンテキストを使用するため、SSL セッションを共有または再利用できないからです。SSL セッションを取得するには、weblogic.net.http.HttpsClient クラスまたは weblogic.net.http.HttpsURLConnection クラスを使用します。クライアント間で SSL ソケット ファクトリを共有することにより、クライアントで URL を再開することもできます。
セッション キャッシングはスレッドによって共有可能な SSL コンテキストによって維持されます。1 つのスレッドは 1 つの SSL セッションではなくセッション キャッシュ全体にアクセスできるので、複数の SSL セッションを 1 つ (または複数の) スレッドで使用および共有できます。
SSL を使用すると、RMI (Remote Method Invocation) リモート オブジェクトへの IIOP (Internet Interop-Orb-Protocol) 接続を保護できます。SSL は、認証を通じて接続を保護し、オブジェクト間のデータ交換を暗号化します。
SSL を使用して RMI over IIOP 接続を保護するには、次の手順に従います。
RMI over IIOP の使い方の詳細については、『WebLogic RMI プログラマーズ ガイド』を参照してください。
WebLogic Server は証明書チェーンの各証明書が認証局によって発行されたことを保証します。WebLogic Server で使用するすべての X509 V3 CA 証明書は CA として定義される基本制御拡張を備えている必要があります。このため、証明書チェーンのすべての証明書が認証局によって発行されたことが確認されます。デフォルトでは、この条件を満たしていない認証局の証明書は拒否されます。この節では、証明書の検証レベルを制御するコマンドライン引数について説明します。
注意 : 証明書検証に合格しない証明書チェーンを持つ WebLogic Server が起動された場合、クライアントでそれを拒否できることを示す情報メッセージがログに記録されます。
デフォルトでは、WebLogic Server は CA として定義される基本制御拡張を持たない証明書チェーンの証明書はすべて拒否します。ただし、この要件を満たさない証明書を使用したり、IETF RFC 2459 標準に準拠するようにセキュリティ レベルを強化したりすることもできます。次のコマンドライン引数を使用して、WebLogic Server で実行される証明書検証のレベルを制御できます。
-Dweblogic.security.SSL.enforceConstraints=option
表 11-1 に、コマンドライン引数のオプションの説明を示します。
WebLogic Server には、既存の証明書チェーンが WebLogic Server によって拒否されるかどうかをチェックするための ValidateCertChain コマンドライン ユーティリティが用意されています。このユーティリティは、PEM ファイル、PKCS-12 ファイル、PKCS-12 キーストア、および JKS キーストアの証明書チェーンを使用します。このユーティリティでは、証明書チェーン全体が使用される必要があります。以下は、ValidateCertChain コマンドライン ユーティリティの構文です。
java utils.ValidateCertChain -filepemcertificatefilenamejava utils.ValidateCertChain -pempemcertificatefilenamejava utils.ValidateCertChain -pkcs12storepkcs12storefilenamejava utils.ValidateCertChain -pkcs12filepkcs12filenamepasswordjava utils.ValidateCertChain -jksaliasstorefilename[storePass]
java utils.ValidateCertChain -pem zippychain.pem
Cert[0]: CN=zippy,OU=FOR TESTING
ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US
Cert[1]: CN=CertGenCAB,OU=FOR TESTING
ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US
Certificate chain appears valid
java utils.ValidateCertChain -jks mykey mykeystore
Cert[0]: CN=corba1,OU=FOR TESTING ONLY, O=MyOrganization,L=MyTown,ST=MyState,C=US
CA cert not marked with critical BasicConstraint indicating it is a CA
Cert[1]: CN=CACERT,OU=FOR TESTING ONLY, O=MyOrganization,L=MyTown,ST=MyState,C=US
Certificate chain is invalid
以前のリリースの WebLogic Server では正常に機能していた SSL 通信で予期しないエラーが発生するようになった場合は、WebLogic Server が使用する証明書チェーンが検証に合格しないことが原因になっている可能性があります。
証明書チェーンが拒否された場所を特定し、受け入れ可能なもので証明書チェーンを更新するか、または -Dweblogic.security.SSL.enforceConstraints コマンドライン引数の設定を変更するかを決定してください。
証明書の問題に対処するには、次のいずれかの解決策を使用します。
-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
次のメッセージは、SSL エラーの原因が証明書チェーンにあることを示します。
<CA certificate rejected.The basic constraints for a CA certificate were not marked for being a CA, or were not marked as critical>
一方向 SSL を使用している場合は、クライアント ログでこのエラーを探してください。双方向 SSL を使用している場合は、クライアント ログとサーバ ログでこのエラーを探してください。
注意 : Java Cryptography Extension (JCE) プロバイダは、JDK 5.0 で入手可能な JCE のアプリケーション プログラミング インタフェース (API) を使用して記述されます。このタイプのプロバイダは、WebLogic セキュリティ サービス プロバイダ インタフェース (SSPI) を使用して記述されたプロバイダとは異なります。デフォルトでは WebLogic Server には JCE プロバイダが用意されていません。
SSL は、Web サーバで使用できるリソースの保護における重要なコンポーネントです。しかし、大量の SSL トラフィックによって、Web サーバのパフォーマンスを低下させるボトルネックが発生することがあります。JCE プロバイダは、暗号化用ハードウェア カードを使用する nCipher と同じように、Web サーバの SSL プロセスの負荷を軽減し、サーバがより多くのトランザクションを処理できるようにします。また、キーの整合性と機密性を保持するための強力な暗号化プロセスも提供します。
WebLogic Server では、以下の JCE プロバイダの使用がサポートされています。
SunJCE)。JDK JCE プロバイダの機能の詳細については、http://java.sun.com/products/jce を参照してください。 デフォルトでは、JDK 5.0 の JCE プロバイダには輸出向け強度の管轄ポリシー ファイルがあります。適切なフォームに入力すれば、国内向け強度の管轄ポリシー ファイルを Sun Microsystems (http://java.sun.com/products/jce/javase.html#UnlimitedDownload) からダウンロードできます。
WebLogic Server アプリケーション プログラミング インタフェース (API) で使用される暗号化の強度は、引き続き BEA ライセンスによって制御されます。クライアント コードに適切な国内向け強度の暗号化ライセンスがない場合は、デフォルトの J2SE 輸出向け強度の暗号化しか使用できません。サーバには常に、輸出向け強度または国内向け強度の暗号化を有効にする BEA ライセンスがあります。
nCipher JCE プロバイダをインストールするには、次の手順に従います。
注意 : この手順は、nCipher JCE プロバイダのハードウェアの設置作業の一部として実行済みになっている場合もあります。その場合は、ファイルが適切にインストールされていることを確認してください。
java.security) を編集して、WebLogic Server で承認されている JCE プロバイダのリストに nCipher JCE プロバイダを追加します。Java セキュリティ プロパティ ファイルは、以下の場所にあります。JAVA_HOME/jre/lib/security/java.security
次のように nCipher JCE プロバイダを指定します。
security.provider.n=com.ncipher.provider.km.mCipherKM
n は、特定のプロバイダが指定されていない場合に、要求されたアルゴリズムに対してプロバイダが検索される順序を決定する優先順序です。順序は 1 が基準になり、1 が最も優先されます。その後、2、3、... と続きます。
nCipher JCE プロバイダは、セキュリティ プロパティ ファイルで RSA JCA プロバイダの次に来る必要があります。次に例を示します。
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.rsajca.Provider
WebLogic Server では、SSL V3.0 と TLS V1.0 の両方のプロトコルがサポートされています。WebLogic Server が SSL サーバとして動作する場合、WebLogic Server はクライアントのハロー メッセージで指定されたほうのプロトコルを使用することに同意します。WebLogic Server が SSL クライアントとして動作する場合、WebLogic Server はその SSL V2.0 のハロー メッセージで TLS1.0 を対象プロトコルとして指定しますが、SSL サーバがサポートする最上位バージョンが SSL V3.0 である場合は SSL V3.0 にも同意します。ピアは SSL V3.0 または TLS V1.0 メッセージで応答する必要があり、応答しなければ SSL 接続は中断されます。
ほとんどの場合は SSL V3.0 プロトコルで問題ありませんが、TLS V1.0 プロトコルが必要とされる場面 (互換性、SSL のパフォーマンス、およびセキュリティ要件が最大の環境) もあります。weblogic.security.SSL.protocolVersion コマンドライン引数を使用すると、SSL 接続で使用するプロトコルを指定できます。
注意 : SSL V3.0 プロトコルと TLS V1.0 プロトコルは入れ替えできません。TLS V1.0 プロトコルは、すべての必要な SSL クライアントがそのプロトコルを使用できることが確かである場合にのみ使用します。
次のコマンドライン引数を指定すると、WebLogic Server は SSL V3.0 または TLS V1.0 接続のみをサポートします。
|
|
|