| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの管理 12c (12.2.1.3.0) E90347-06 |
|
 前 |
 次 |
SSLでは、ネットワーク接続している2つのアプリケーションが互いのアイデンティティを認証できるようにするとともに、アプリケーション間でやりとりされるデータを暗号化することで、セキュアな接続を実現します。
認証を使用すると、サーバーは(場合によってはクライアントも)ネットワーク接続の相手側アプリケーションのIDを検証できます。ネットワーク経由で送信されるデータは暗号化されるので、予定されている宛先以外には解釈できません。
WebLogic ServerのSSLは、SSLおよびTLS (Transport Layer Security)仕様の実装です。
ノート:
サポートされるTLSとSSLのバージョンは表3-1を参照してください。
WebLogic Serverは、専用のリスニング・ポート(デフォルトは7002)でSSLをサポートします。HTTPでSSL接続を確立するには、接続URLにSSLリスニング・ポートとHTTPSプロトコルを指定して(https://myserver:7002など)、WebブラウザからWebLogic Serverに接続します。
SSLを使用すると、計算処理による負荷が大きくなり、接続のオーバーヘッドが増大します。必要なとき以外は開発環境でSSLを使用しないでください。ただし、本番環境では常にSSLを使用してください。
この項には次のトピックが含まれます:
SSLは、一方向または双方向として構成できます。
一方向SSLでは、サーバーはクライアントに対して証明書を提示する必要がありますが、クライアントはサーバーに対して証明書を提示する必要がありません。クライアントはサーバーを認証する必要がありますが、サーバーはどのクライアントからの接続も受け入れます。一方向SSLは、インターネット上で顧客が個人データを共有する前にセキュアな接続を実現したい場合によく使用されます。クライアントがログインするときにも、サーバーが認証できるようにSSLを使用することがよくあります。
双方向SSL (SSLとクライアント認証)の場合、サーバーはクライアントに証明書を提示し、クライアントはサーバーに証明書を提示します。クライアントが有効で信頼性のある証明書を発行しなければSSL接続を確立できないようにWebLogic Serverを構成できます。
このリリースのWebLogic Serverでは、Java Secure Socket Extension (JSSE)に基づくSSL実装を使用します。JSSEは、SSLおよびTLS用のJava標準フレームワークで、ブロッキングIO API、ノンブロッキングIO API、および複数の信頼性のあるCAを含む参照実装が含まれています。
JSSEベースSSL実装は、Certicom SSL実装を使用するWeblogic Serverバージョン8.1以上のインスタンスとSSLを介して相互運用します。つまり、JSSE SSLのWebLogic ServerがSSLクライアントまたはSSLサーバーのいずれかとして使用される場合、Certicom SSL実装を使用するWebLogic Server(バージョン8.1以上)のインスタンスとSSLで通信できます。
JSSEの使用については、「JSSEベースSSL実装の使用」を参照してください。
JSSEの詳細は、Java Secure Socket Extension (JSSE)リファレンス・ガイド(http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html)を参照してください。
ノート:
WebLogic Serverバージョン12.1.1以降では、サポートされるSSL実装はJSSEのみになります。CerticomベースのSSL実装はなくなり、WebLogic Serverでサポートされなくなりました。
SSLを設定するには、まずWeblogic Serverのアイデンティティおよび信頼を取得し、次にそれらをキーストアを使用して格納する必要があります。その後、アイデンティティ・ストアおよび信頼ストアを構成し、続いてWebLogic Server管理コンソールを使用して秘密キーの別名およびパスワードに関するSSL構成オプションを設定できます。
SSLを設定するには、次のステップを実行します。
WebLogic ServerのIDと信頼の構成に関する詳細は、次の項を参照してください。
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セッションは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つ(または複数の)スレッドで使用および共有できます。
weblogic.security.SSL.sessionCache.ttlコマンドライン引数を使用して、SSLセッション・キャッシングのデフォルトのサーバー・セッション存続時間を変更できます。『Oracle WebLogic Serverコマンド・リファレンス』のSSLに関する項を参照してください。weblogic.security.SSL.sessionCache.sizeコマンドライン引数は無視されます。
