| Oracle® Fusion Middleware Oracle Fusion Middlewareの管理 12c (12.1.3) E56229-02 |
|
 前 |
 次 |
この章では、Secure Sockets Layer (SSL)を使用して、Web層、中間層およびデータ層においてOracle Fusion Middlewareコンポーネント間の通信を保護するための手順について説明します。また、基本的なトポロジよりさらに高度なシナリオおよびベスト・プラクティスについても説明します。
SSLハンドシェーク時にクライアントが使用できるSSL暗号スイートの詳細は、コンポーネント固有のドキュメントを参照してください。
この章の内容は次のとおりです。
|
注意: Oracle WebLogic Server内でSSL接続を構成する場合、ここでの手順を実行するかわりに、この章で紹介しているOracle WebLogic Serverの関連ドキュメントを参照してください。 |
この項では、基本的なSSLの概念について説明します。内容は次のとおりです。
SSLは、メッセージの暗号化、整合性および認証を提供することで、通信を保護します。SSL標準により、関係するコンポーネント(ブラウザやHTTPサーバーなど)は、どの暗号化、認証および整合性メカニズムを使用するかのネゴシエーションができます。
暗号化を行うと、正当な受信者のみがメッセージを読むことができ機密が保持されます。SSLでは、様々な暗号化アルゴリズムを使用してメッセージを暗号化できます。各SSLセッションの開始時に行われるSSLハンドシェイク中、クライアントとサーバーは、どのアルゴリズムを使用するかのネゴシエーションを行います。SSLがサポートしている暗号化アルゴリズムには、AES、RC4、3DESなどがあります。
整合性により、クライアントが送信したメッセージが改ざんされずに正当なサーバーに届きます。メッセージの整合性を確保するために、クライアントはハッシュ機能を使用してメッセージをダイジェストにハッシュし、このメッセージ・ダイジェストをサーバーに送信します。サーバーは、さらにこのメッセージをダイジェストにハッシュし、これらのダイジェストを比較します。SSLでは、2つの異なるメッセージから同じダイジェストをコンピュータで生成するのが不可能なハッシュ機能を使用しているため、サーバーでは2つのダイジェストが一致しない場合には、何者かによりメッセージが改ざんされたとみなすことができます。SSLがサポートしているハッシュ機能の1つに、SHA2があります。
認証を使用すると、サーバーとクライアントは互いに相手の身元を確認できます。クライアントがSSLセッションを開始すると、サーバーは通常、サーバー自身の証明書をクライアントに送信します。証明書とは、VeriSignなどの信頼できる認証局によって発行されるデジタルIDです。第7章「キーストア、ウォレットおよび証明書の管理」では、証明書について詳細に説明しています。
クライアントは、サーバー証明書内の証明連鎖を検証することで、サーバーが本物であることを確認します。サーバー証明書は、サーバー証明書に署名した認証局(CA)により保証されています。
また、サーバーがクライアントの識別を認証する必要がある場合には、サーバーがクライアントに証明書の所持を要求することもできます。
メッセージの整合性、認証および暗号化を提供するために、SSLでは秘密鍵と公開鍵の両方の暗号化を使用します。
秘密鍵の暗号化
対称鍵の暗号化では、通信を保護する目的で2者以上が共有する1つの秘密鍵が必要です。この鍵は、当事者間で送信された安全なメッセージを暗号化および復号化するために使用します。これを行うには、安全な方法で各当事者に鍵を事前に配布しておく必要があります。この方法における問題点は、鍵を安全に転送し、格納することが困難なことです。
SSLでは、各当事者は互いに認識している乱数を使用して秘密鍵を個別に計算します。次に、その秘密鍵を使用して暗号化したメッセージを送信します。
公開鍵の暗号化
公開鍵の暗号化による公開鍵/秘密鍵のペアおよび鍵配布のための安全な方法を採用することで、この問題は解決します。対応する秘密鍵の所有者のみが復号化できるメッセージは、自由に使用できる公開鍵によって暗号化できます。秘密鍵は、その他のセキュリティ資格証明とともに、Oracleウォレットなどの暗号化されたコンテナに安全に格納されます。
公開鍵アルゴリズムでは、メッセージの秘密が保証されます。しかし通信者間の識別が検証されないため、安全な通信は必ずしも保証されません。安全な通信を確立するには、メッセージの暗号化に使用される公開鍵が相手の受信者に実際に属していることを確認することが重要です。そうしないと、第三者が通信を傍受し、公開鍵のリクエストに割り込み、正当な鍵を独自の公開鍵に置き換えることが可能になります(介在者攻撃)。
そうした攻撃を避けるには、認証と呼ばれるプロセスにより、公開鍵の所有者を検証することが必要です。その際に、通信の両当事者により信頼された、認証局(CA)と呼ばれる第三者機関が、この認証プロセスを実行できます。
CAは、エンティティの名前、公開鍵および他のセキュリティ資格証明を含む公開鍵証明書を発行します。通常、このような資格証明には、CA名、CAの署名および証明書の有効日(開始日、終了日)が含まれています。
CAでは独自の秘密鍵を使用してメッセージを暗号化します。一方、そのメッセージの復号化には公開鍵が使用されるため、メッセージがCAによって暗号化されたものであるかどうかが確認されます。CA公開鍵は広く一般に知られているため、アクセスするたびに認証する必要はありません。このようなCA公開鍵はウォレットに格納されます。
Oracle Fusion Middlewareでは、Oracle HTTP Serverなどのコンポーネントにおいて、記憶域メカニズムとしてOracleウォレットが使用されます。Oracleウォレットは、証明書、信頼できる証明書、証明書リクエスト、秘密鍵などの資格証明を格納するコンテナです。Oracle Internet DirectoryなどのLDAPディレクトリやファイル・システムにOracleウォレットを格納できます。Oracleウォレットは、パスワードで保護することも自動ログインにもできます。
Oracle HTTP ServerではOracleウォレットが使用されます。Oracle HTTP ServerでのSSLの構成では、Oracleウォレットを設定および使用する必要があります。
|
注意: Oracle Fusion Middleware 12c (12.1.3)の時点では、キーストア・サービスで使用できる中央記憶域および統合管理を利用して、該当するサービスのエクスポート、インポートおよび同期化機能により、ウォレットとその内容を管理できます。 |
他のコンポーネントはJKSキーストアまたはKSSキーストアを使用して鍵と証明書を保管するので、これらのコンポーネントのSSLの構成では、適切なキーストアを使用して設定する必要があります。
キーストアおよびウォレットの構成の詳細は、次を参照してください。
Oracle Fusion Middlewareでのキーストアおよびウォレットの詳細は、第6.2項「Oracle Fusion MiddlewareにおけるSSLについて」を参照してください。
それらの用語および管理作業の詳細は、第7章「キーストア、ウォレットおよび証明書の管理」を参照してください。
SSLプロトコルには、ハンドシェイク・フェーズとデータ転送フェーズという2つのフェーズがあります。ハンドシェイク・フェーズでは、サーバーおよびオプションでクライアントを認証し、データ転送フェーズで転送されるデータを保護するための暗号化鍵を設定します。
クライアントがサーバーへのSSL接続を要求すると、クライアントとサーバーはまずハンドシェイク・フェーズでメッセージを交換します。(一般的なシナリオとしては、http://ではなくhttps://プロトコルを使用して、サーバーからページを要求するブラウザがあります。HTTPSプロトコルは、HTTPでSSLを使用することを示します。)
図6-1に、Webサーバーとブラウザ間の一般的なSSL接続用ハンドシェイク・メッセージを示します。この図では次の手順を示しています。
クライアントは、サーバーにハロー・メッセージを送信します。
メッセージには、クライアントがサポートしているアルゴリズムの一覧および鍵を生成するための乱数が含まれています。
サーバーは、クライアントにハロー・メッセージを送信してレスポンスを返します。このメッセージには、次の内容が含まれています。
使用するアルゴリズム。これは、クライアントが送信した一覧から、サーバーによって選択されます。
鍵の生成に使用する乱数。
サーバーは、クライアントに証明書を送信します。
クライアントは、サーバーの証明書の妥当性、発行者CAおよびオプションでサーバーのホスト名がサブジェクトDNと一致するかどうかをチェックして、サーバーを認証します。クライアントはセッション・キャッシュのセッションIDを送信します。
クライアントが乱数(プリマスタ・シークレット)を生成し、サーバーの公開鍵を使用して暗号化し、サーバーに送信します。
サーバーは、秘密鍵を使用してメッセージを復号化し、プリマスタ・シークレットを取得します。
クライアントとサーバーは、SSLセッションで使用される鍵を個別に計算します。
これらの鍵は、互いに認識しているプリマスタ・シークレットと乱数に基づいて計算されるため、それぞれの相手には送信されません。鍵には次の内容が含まれています。
クライアントがサーバーへの送信前にデータを暗号化するために使用する暗号化鍵
サーバーがクライアントへの送信前にデータを暗号化するために使用する暗号化鍵
クライアントがデータのメッセージ・ダイジェストを作成するために使用する鍵
サーバーがデータのメッセージ・ダイジェストを作成するために使用する鍵
暗号化鍵は、対称的です。つまり、データの暗号化と復号化には同じ鍵が使用されます。
クライアントとサーバーは、相互にFinishedメッセージを送信します。これらは前の手順で生成した鍵を使用して送信される最初のメッセージ(最初の安全なメッセージ)です。
Finishedメッセージには、各当事者が送信した以前のハンドシェイク・メッセージがすべて含まれています。各当事者は、受信した以前のメッセージが、Finishedメッセージに含まれているメッセージに一致するかどうかを確認します。これは、ハンドシェイク・メッセージが改ざんされていないことを確認するためです。
クライアントとサーバーは、暗号化鍵とハッシュ鍵およびアルゴリズムを使用してデータを転送します。
この項では、Oracle Fusion MiddlewareにおけるSSLについて説明します。内容は次のとおりです。
|
注意:
|
図6-2で示されるOracle Fusion Middlewareアーキテクチャにおいて、丸はSSLを有効にできるエンドポイントを表します。それぞれのエンドポイントの構成の詳細は、次の項目を参照してください。
第6.4.2.1項「Fusion Middleware Controlを使用したOracle HTTP Server仮想ホストへのインバウンド・リクエストでのSSLの有効化」および第6.4.2.2項「WLSTを使用したOracle HTTP Server仮想ホストへのインバウンド・リクエストでのSSLの有効化」
LDAPサーバーへのアウトバウンド接続は、Oracle Platform Security ServicesまたはOracle WebLogic Serverから発生します。
キーストアおよびウォレット
キーストアおよびウォレットはSSL構成の中心となり、これらを使用して証明書および鍵を保存します。
詳細は、第6.2.2項「キーストアおよびOracleウォレット」を参照してください。
Oracle Fusion Middleware 12c (12.1.3)では、鍵と証明書のために様々なタイプのキーストアをサポートしています。
JKSベースのキーストアとトラストストア
Oracle WebLogic Serverは、アップグレードした環境でJKSキーストアを使用します。
JDKのkeytoolユーティリティでJKSキーストアおよび証明書を管理します。
Oracleウォレット
Oracle HTTP Serverなどのシステム・コンポーネントではOracleウォレットを使用します。
システム・コンポーネントのウォレットとその証明書を管理するには、Fusion Middleware Controlまたはコマンド行WLSTとorapkiインタフェースを使用します。Fusion Middleware ControlまたはWLSTのいずれかを使用して、これらのコンポーネントのリスナーでSSLを有効化できます。
OPSSキーストア・サービス(KSS)のキーストアおよびトラストストア
キーストア・サービスでは、鍵と証明書を管理するために、かわりのメカニズムが用意されています。12c (12.1.3)を新しくインストールした場合、Oracle WebLogic Serverは最初からKSSキーストアを使用します。
KSSキーストアおよびその証明書を管理するには、Fusion Middleware ControlまたはWLSTを使用します。WebLogicサーバーのリスナーでSSLを有効化するには、WebLogicコンソールを使用します。
これらのストアのタイプ、およびどのストアのタイプをいつ使用するかについては、第6.1.3項「キーストアおよびウォレット」を参照してください。
JDK7ではkeyCertSignを持つkeyUsageが必要
JDK7では、SSL構成で使用する自己署名付きCA証明書に、keyCertSignがアサートされたkeyUsage拡張機能が存在している必要があります。詳細は、第H.3.3項を参照してください。
サポートされている認証モードは、次のとおりです。
認証なしモードでは、サーバーもクライアントも認証は不要です。
このモードは、匿名SSL/認証なし/Diffie-Hellmanなどと呼ばれています。このモードはセキュアではないと見なされます。
サーバー認証モードでは、クライアントに対してサーバー自身の認証が行われます。
このモードは、一方向SSL/サーバー認証とも呼ばれています。
相互認証モードでは、サーバーに対してクライアント自身の認証が行われ、クライアントに対してサーバー自身の認証が行われます。
このモードは、双方向SSL/クライアント認証とも呼ばれています。
オプションのクライアント認証モードでは、クライアントに対してサーバー自身の認証が行われますが、サーバーに対してはクライアント自身の認証を行うことも行わないこともできます。クライアント自身の認証を行わなくても、SSLセッションは機能します。
Oracle Fusion Middlewareでは、一般的なツールと拡張ツールの2種類の構成ツールを使用します。
一般的なツール
Fusion Middleware Control
WLSTコマンド行インタフェース
Oracle WebLogic Server管理コンソール
keytoolコマンド行ツール
これらのツールを使用して、Oracle Fusion Middlewareの任意のリスナーまたはコンポーネントでSSLを構成したり、Oracle WalletやJKSキーストアを管理できます。
このリストの最初の3つのツールは、コンポーネントがアプリケーション・サーバー・ドメインに関連付けられている場合(コンポーネントがスタンドアロン・インストールではない場合)に使用できます。
拡張ツール
orapkiコマンド行ツールは、特定のスタンドアロン・インストールでウォレットを管理するために必要です。
Oracle Fusion Middleware構成ではいくつかのツールを使用できます。この項では、これらのツールでSSLを構成して、それをSSLが有効なOracle WebLogic Serverに接続できるようにする方法について説明します。
すべての構成ツールの一覧は、第6.2.4項「SSL構成用ツール」を参照してください。
この項の項目は次のとおりです。
次の手順に従います。
Fusion Middleware ControlがデプロイされているOracle WebLogic ServerインスタンスでSSLポートが有効なことを確認し、(Fusion Middleware Controlを起動する)ブラウザがサーバー証明書を信頼していることを確認します。
詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』を参照してください。
ここで、「https://host:port」形式でSSLベースのURLを使用してFusion Middleware Controlを起動します。
Oracle WebLogic ServerインスタンスでSSLポートが有効なことを確認します。ここで、URLにSSLポートを指定して管理コンソールを起動します。証明書が信頼できないという警告が表示される場合がありますが、この証明書を受け入れて続行します。
詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』を参照してください。
WLSTでのSSLの構成の詳細は、次の手順を実行します。
WLSTシェルを起動します。
WLSTコマンドを実行します。
help('connect')
ヘルプ・テキストの説明にある手順に従って、SSLモードでWLSTシェルを設定します。
この項では、Web層に存在するOracle HTTP Server用のSSLについて説明しますが、各項目は次のとおりです。
|
注意:
|
この章は、すべてのOracle HTTP Server構成オプションについて説明しているわけではありません。追加のシナリオについては、『Oracle HTTP Serverのインストールと構成』を参照してください。
ロード・バランシング・デバイスに固有の手順を使用して、Oracle Fusion Middleware環境のロード・バランサを構成します。
この項では、Oracle WebLogic Server環境で動作しているOracle HTTP Server仮想ホストのSSL構成の管理方法について説明します。
|
注意: スタンドアロン・モードのOracle HTTP Serverについては、『Oracle HTTP Serverの管理』を参照してください。 |
インバウンド・トラフィックの場合は、次を参照してください。
アウトバウンド・トラフィックの場合は、次を参照してください。
第6.4.2.3項(Fusion Middleware ControlまたはWLSTを使用)
次の手順を実行して、Oracle HTTP Server仮想ホストへのインバウンド・トラフィックでSSLを有効にすることができます。
左側のナビゲーション・ペインでOracle HTTP Serverインスタンスを選択します。
必要に応じて、「Oracle HTTP Server」→「セキュリティ」→「ウォレット」にナビゲートします。
ウォレットの作成とメンテナンスは、第7章「キーストア、ウォレットおよび証明書の管理」を参照してください。
「HTTP Server」→「管理」→「仮想ホスト」にナビゲートします。
このページには、現在構成されているホスト、およびそれらがhttpまたはhttpsに構成されているかが表示されます。
更新する仮想ホストを選択して、「構成」→「SSL構成」をクリックします。(注意: 新規仮想ホストを作成する場合は、 『Oracle HTTP Serverの管理』を参照。)
「SSL構成」ページが表示されます。
「SSLの有効化」の選択を解除すると、httpsポートをhttpポートに変換できます。
現在httpを使用している仮想ホストでSSLを構成するには:
「SSLの有効化」ボックスを選択します。
ドロップダウン・リストからウォレットを選択します。
「サーバーSSLプロパティ」から、SSL認証タイプ、使用する暗号スイートおよびSSLプロトコル・バージョンを選択します。
|
注意: ほとんどの状況ではデフォルト値が最適です。 |
|
注意:
|
「OK」をクリックして変更内容を適用します。
Windowsプラットフォームの場合にのみ、Windowsエクスプローラを開いて、cwallet.ssoファイルの場所に移動します。「プロパティ」→「セキュリティ」で、「グループ名またはユーザー名」にSYSTEMを追加します。
「Oracle HTTP Server」→「コントロール」→「再起動」にナビゲートして、Oracle HTTP Serverインスタンスを再起動します。
ブラウザ・セッションを開き、SSLを有効にしたポート番号に接続します。
第7.2.1項の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。
次の手順に従います。
次のコマンドを実行して、このOracle HTTP Serverインスタンスの仮想ホストを確認します。
listListeners('OHS_instance','OHS_instance' )
このコマンドは、このインスタンスのすべての仮想ホストをリストします。SSLを構成する必要がある仮想ホストを1つ選択します。たとえば、「vhost1」を選択できます。このコマンドの詳細は、『WebLogic Server WLSTコマンド・リファレンス』を参照してください。
SSLプロパティで仮想ホストを構成します。
configureSSL('OHS_instance',
'OHS_instance',
'ohs',
'vhost1')
|
注意:
|
Windowsプラットフォームの場合にのみ、Windowsエクスプローラを開いて、cwallet.ssoファイルの場所に移動します。「プロパティ」→「セキュリティ」で、「グループ名またはユーザー名」にSYSTEMを追加します。
mod_wl_ohsを構成してOracle HTTP Serverからのアウトバウンド・リクエストでのSSLを有効化します。
手順は次のとおりです。
証明書を含むOracle WebLogic Serverのカスタム・キーストアを生成します(第6.5.1項を参照してください)。
Oracle WebLogic Serverで使用される信頼できるCA証明書を、Oracle HTTP Serverウォレットに信頼できる証明書としてインポートします。このタスクには、WLSTやFusion Middleware Controlなどの使用可能なユーティリティを使用できます。(注意: ここで説明するウォレットは、Oracle HTTP Serverリスニング・ポートがSSL用に使用するウォレットです。Oracle WebLogic Server証明書に署名した信頼性できる(ルート)CA証明書は、このウォレットに格納されている必要があります。信頼性できる証明書のインポートの詳細は、第7.4.7.3.1項を参照してください。)
Oracle WebLogic Serverインスタンスを停止し、Oracle HTTP Server構成ファイル(DOMAIN_HOME/config/fmwconfig/components/OHS/instance_name/ssl.conf)を編集して、mod_weblogicの下のSSL構成に次の行を追加します。
WlSSLWallet "$(DOMAIN_HOME}/config/fmwconfig/components/COMPONENT_TYPE/COMPONENT_NAME/keystores/default"
このdefaultは、ステップ2のOracle HTTP Serverウォレットの名前です。
次にその構成の例を示します。
<IfModule mod_weblogic.c> WebLogicHost myweblogic.server.com WebLogicPort 7002 MatchExpression *.jsp SecureProxy On WlSSLWallet "$(DOMAIN_HOME}/config/fmwconfig/components/OHS/ohs1/keystores/default" </IfModule>
ファイルを保存して終了します。
Windowsプラットフォームの場合にのみ、Windowsエクスプローラを開いて、cwallet.ssoファイルの場所に移動します。「プロパティ」→「セキュリティ」で、「グループ名またはユーザー名」にSYSTEMを追加します。
Oracle HTTP Serverを再起動して変更を有効にします。詳細は、『Oracle HTTP Serverの管理』を参照してください。
ステップ1で生成されたカスタム・キーストアを使用するようにOracle WebLogic Serverインスタンスが構成され、別名が証明書の生成に使用される別名値を指していることを確認します。Oracle WebLogic Serverインスタンスを再起動します。詳細は、6.5.1.1項を参照してください。
mod_wl_ohsでは、双方向SSL通信もサポートします。双方向SSLを構成する手順は次のとおりです。
前の一方向SSLのステップ1から4を実行します。
Oracle WebLogic Serverのトラストストアtrust.jksを生成します。
(前の手順のステップ1で)一方向SSL用に作成されたキーストアは、信頼できる証明書を保存するために使用できますが、この手順で個別のトラストストアを作成することをお薦めします。
Oracle HTTP Serverウォレットからユーザー証明書をエクスポートして、それをステップ2で作成したトラストストアにインポートします。
エクスポートには、WLSTやFusion Middleware Controlなどの使用可能なユーティリティを使用できます。インポートにはkeytoolユーティリティを使用できます。詳細は、7.4.5項を参照してください。
Oracle WebLogic Server管理コンソールから、構成するサーバーの「キーストア」タブを選択します。
ステップ2で作成したトラストストアのtrust.jksファイルの場所によりカスタム・トラストストアを設定します(完全な名前を使用します)。
キーストア・タイプをJKSに設定し、キーストアの作成に使用されるパスフレーズを設定します。
「SSL」タブで、「信頼性のある認証局」が「カスタム信頼キーストアから」に設定されていることを確認します。
Oracle WebLogic Serverが双方向SSL用に構成されていることを確認します。詳細は、『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項を参照してください。
中間層では、次のようにSSLを使用します。
アプリケーション・サーバーでのSSLの有効化
アプリケーション・サーバー上で稼働するコンポーネントおよびアプリケーションでのSSLの有効化
この項では、中間層でのSSLの構成について説明します。この項の項目は次のとおりです。
この項では、アプリケーション・サーバーの構成について説明します。
SSLを実装してOracle WebLogic Serverを保護する方法の詳細は、『Oracle WebLogic Serverセキュリティの管理』の次のトピックを参照してください。
「Oracle OPSSキーストア・サービスの構成」
「WebLogic ServerでのSSLの構成の概要」
この項では、Oracle WebLogic Serverからのアウトバウンド接続でSSLを有効にする方法について説明します。
この項では、LDAPディレクトリへのポリシー・ストア接続および資格証明ストア接続用にSSLを構成する方法について説明します(サーバー側とクライアント側が必要)。匿名SSLおよび一方向SSLがサポートされています。
この項で参照されるjps-config.xmlの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。
匿名SSL(サーバー側)
匿名認証モードでLDAPサーバーを起動します。
このタスクの詳細は、LDAPサーバーのドキュメントを参照してください。
匿名SSL(クライアント側)
jps-config.xmlファイルでは、プロトコルをldapsに設定し、プロパティldap.urlに適切なポートを指定する必要があります。この情報は、ポリシー・ストア、資格証明ストア、キーストア、およびldap.urlを使用するその他のサービスに対して更新する必要があります。
一方向SSL(クライアント側)
クライアント側の構成が次のようになっている必要があります。
LDAPの証明書を信頼するには、使用するトラスト・ストアを検索する場所をJVMが認識している必要があります。これを行うには、次のように設定します。
-Djavax.net.ssl.trustStore=path_to_jks_file
このプロパティは、JavaSEプログラム、またはJavaEE環境のサーバー起動プロパティに追加されます。
jps-config.xmlファイルでは、プロトコルをldapsに設定し、プロパティldap.urlに適切なポートを指定する必要があります。この情報は、ポリシー・ストア、資格証明ストア、キーストア、およびldap.urlを使用するその他のサービスに対して更新する必要があります。
keytoolを使用して、LDAPサーバーの証明書をステップ1で指定したトラスト・ストアにインポートします。
一方向または双方向のSSL接続をデータベース・ベースのOPSSセキュリティ・ストアに設定できます。
データベースのサーバーおよびクライアントの構成の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。
LDAPディレクトリへのアウトバウンドSSLの詳細は、『Oracle WebLogic Serverセキュリティの管理』のWebLogic ServerでのSSL証明書の検証方法に関する項を参照してください。
データベース・リスナー用のSSLの構成の詳細は、Oracle Advanced Security管理者ガイドのSSL認証の構成に関する項(http://docs.oracle.com/cd/E11882_01/network.112/e10746/asossl.htm)を参照してください。
SSLを有効にしたアプリケーションの作成方法の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJavaクライアントでのSSL認証の使用に関する項を参照してください。
ベスト・プラクティスは、第6.8.2項「アプリケーション開発者のベスト・プラクティス」を参照してください。
この項では、次の項目について説明します。
この項の項目は次のとおりです。
次の手順を実行して、OracleデータベースでSSLを有効にします。
ルートCAとDBの証明書を作成します。次に例を示します。
mkdir root mkdir server # Create root wallet, add self-signed certificate and export orapki wallet create -wallet ./root -pwd password orapki wallet add -wallet ./root -dn CN=root_test,C=US -keysize 2048 -self_signed -validity 3650 -pwd password orapki wallet display -wallet ./root -pwd password orapki wallet export -wallet ./root -dn CN=root_test,C=US -cert ./root/b64certificate.txt -pwd password #Create server wallet, add self-signed certificate and export orapki wallet create -wallet ./server -pwd password orapki wallet add -wallet ./server -dn CN=server_test,C=US -keysize 2048 -pwd password orapki wallet display -wallet ./server -pwd password orapki wallet export -wallet ./server -dn CN=server_test,C=US -request ./server/creq.txt -pwd password # Import trusted certificates orapki cert create -wallet ./root -request ./server/creq.txt -cert ./server/cert.txt -validity 3650 -pwd password orapki cert display -cert ./server/cert.txt -complete orapki wallet add -wallet ./server -trusted_cert -cert ./root/b64certificate.txt -pwd password orapki wallet add -wallet ./server -user_cert -cert ./server/cert.txt -pwd password orapki wallet create -wallet ./server -auto_login -pwd password}}
データベースのlistener.ora、sqlnet.oraおよびtnsnames.oraを更新します。
次の例は、デフォルトのlistener.oraを示します。
SID_LIST_LISTENER = (SID_LIST =(SID_DESC =(SID_NAME = PLSExtProc)(ORACLE_HOME = /path_to_O_H)(PROGRAM = extproc))) LISTENER =(DESCRIPTION_LIST =(DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1)) (ADDRESS = (PROTOCOL = TCP)(HOST = mynode.mycorp.com)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCPS)(HOST = mynode.mycorp.com)(PORT = 2490)) )) WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/wallet_location))) SSL_CLIENT_AUTHENTICATION=FALSE}}
次に、更新されたlistener.oraファイルを示します。このシナリオではクライアント認証なしに指定しています。
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = dbname)
(ORACLE_HOME = /path_to_O_H)
(SID_NAME = sid)
)
)
SSL_CLIENT_AUTHENTICATION = FALSE
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /wallet_path)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mynode.mycorp.com)(PORT = 1521))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCPS)(HOST = mycorp.com)(PORT = 2490))
)
)
SSLポートが追加されています。
同様に、変更されたsqlnet.oraファイルは次のようになります。
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT) SQLNET.AUTHENTICATION_SERVICES=(BEQ,TCPS,NTS) WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/directory))) SSL_CLIENT_AUTHENTICATION=FALSE
変更されたtnsnames.oraファイルは次のようになります。
OID =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mynode.mycorp.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = mynode.mycorp.com)
)
)
SSL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCPS)(HOST = mynode.mycorp.com)(PORT = 2490))
)
(CONNECT_DATA =
(SERVICE_NAME = mynode.mycorp.com)
or
(SID = mynode.mycorp.com)
)
(SECURITY=(SSL_SERVER_CERT_DN=\"CN=server_test,C=US\"))
)
新しい接続文字列を使用してデータベースへの接続をテストします。次に例を示します。
$ tnsping ssl
$ sqlplus username/password@ssl
|
関連項目: 『Oracle Database Advanced Security管理者ガイド』のSecure Sockets Layer認証の構成に関する項を参照してください。 |
次の手順を実行して、SSLを使用するようにOracle WebLogic Server上のデータ・ソースを構成します。
トラストストアを作成して、(データベースでSSLを有効にしたときに作成した)ルート証明書を、信頼できる証明書としてトラストストアに追加します。
Oracle WebLogic Server管理コンソールで、使用しているデータ・ソースの「接続プール」タブにナビゲートします。
|
注意: Oracle WebCenter Portalデータ・ソースなどの既存ソースや新しいデータ・ソースをデータ・ソースにできます。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの作成に関する項を参照してください。 |
「JDBCプロパティ」テキスト・ボックスで指定する必要があるプロパティは、構成する認証のタイプにより異なります。
クライアント認証(双方向認証)が必要な場合:
javax.net.ssl.keyStore=..(password of the keystore)
javax.net.ssl.keyStoreType=JKS
javax.net.ssl.keyStorePassword=...(password of the keystore)
javax.net.ssl.trustStore=...(the truststore location on the disk)
javax.net.ssl.trustStoreType=JKS
javax.net.ssl.trustStorePassword=...(password of the truststore)
クライアント認証が不要な場合:
javax.net.ssl.trustStore=...(the truststore location on the disk)
javax.net.ssl.trustStoreType=JKS
javax.net.ssl.trustStorePassword=...(password of the truststore)
「URL」テキスト・ボックスにJDBC接続文字列を入力します。プロトコルがTCPSで、SSL_SERVER_CERT_DNにデータベース証明書の完全なDNが含まれていることを確認します。
tnsnames.oraが「SERVICE_NAME」を使用する場合は、次の構文を使用します。
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCPS)(HOST=host-name)(PORT=port-number)))(CONNECT_DATA=(SERVICE_NAME=service))(SECURITY=(SSL_SERVER_CERT_DN="CN=server_test,C=US")))
tnsnames.oraが「SID」を使用する場合は、次の構文を使用します。
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCPS)(HOST=host-name)(PORT=port-number)))(CONNECT_DATA=(SID=service))(SECURITY=(SSL_SERVER_CERT_DN="CN=server_test,C=US")))
接続をテストおよび検証します。この時点で、データ・ソースはSSLを使用するように構成されています。
この項では、前述の基本的なトポロジを超えた高度なSSL構成のシナリオを処理する方法について説明します。
この項で使用されているコマンドの詳細および例は、第6.9項を参照してください。
ハードウェア・セキュリティ・モジュール(HSM)は、コンピュータに組み込むことができる物理的なプラグイン・カードまたは外部セキュリティ・デバイスで、セキュアなストレージ環境を提供し機密コンテンツを扱うことができます。
|
注意: この項の内容は、HSMをサポートしているシステム・コンポーネントであるOracle HTTP Serverにのみ適用されます。 |
Oracle Fusion Middlewareでは、PKCS#11規格に準拠したHSMデバイスをサポートし、秘密鍵を使用したセキュアなストレージ環境を提供します。
次の手順を実行し、PKCS#11ウォレットを使用してコンポーネントでSSLを実装します。
コンポーネントが稼働しているマシンにHSMライブラリをインストールします。これは、1回かぎりのタスクでデバイスに依存します。
次に、orapkiコマンド行ツールを使用してウォレットを作成します。次の点に注意してください。
ウォレット・タイプとしてPKCS11を選択します。
デバイスとの通信に使用されるデバイス固有のPKCS#11ライブラリを指定します。このライブラリは、HSMソフトウェアの一部です。
Linuxでは、ライブラリは次の場所にあります。
For LunaSA (Safenet): /usr/lunasa/lib/libCryptoki2.so For nCipher: /opt/nfast/toolkits/pkcs11/libcknfast.so
Windowsでは、ライブラリは次の場所にあります。
For LunaSA (Safenet): C:\Program Files\LunaSA\cryptoki.dll
ここで、第三者の証明書を取得するための標準的な手順を実行します。証明書リクエストを作成し、認証局(CA)で承認されたリクエストを取得して、そのCAで署名された証明書をインストールします。
設定したウォレットは、他のウォレットと同様に使用されます。
orapkiユーティリティでウォレットを確認します。次のコマンド構文を使用します。
orapki wallet p11_verify [-wallet [wallet]] [-pwd password]
configureSSL WLSTコマンドを使用して、コンポーネントのリスナーでSSLを構成します。このコマンドは入力にプロパティ・ファイルを指定します。プロパティ・ファイルでは、コンポーネントが稼働しているマシンのPKCS#11ウォレット・ディレクトリのフルパスを指定する必要があります。(注意: PKCS#11ウォレットをインスタンス・ホーム・ディレクトリに保存しないでください。Fusion Middleware ControlまたはWLSTを介して作成および管理されるウォレットのみがインスタンス・ホームに存在する必要があります。)
サンプルのプロパティ・ファイルは、次のようになります。
SSLEnabled=true AuthenticationType=Server PKCS11Wallet=/tmp/lunasa/wallet
|
注意: WLSTコマンドの |
|
注意:
|
SSLを使用するコンポーネントは、オプションで証明書失効リスト(CRL)を使用した証明書の検証を有効にできます。これによりそのコンポーネントでは、SSLハンドシェイクでピア証明書を検証して、認証局(CA)で発行された失効済証明書のリストにそれがないか確認できます。
この項では、CRLベースの検証を使用するようにコンポーネントを構成する方法、およびファイル・システム上にCRLを作成および設定する方法を説明します。
configureSSL WLSTコマンドを使用して、コンポーネントのリスナーでSSLを構成します。このコマンドは入力にプロパティ・ファイルを指定します。
プロパティ・ファイルは、次のように設定する必要があります。
「CertValidation」属性はurlに設定する必要があります。
「CertValidationPath」属性は、「file://file_path」または「dir://directory_path」という形式にする必要があります。
証明書の検証に単一のCRLファイルを使用している場合、最初の形式を使用します。このCRLファイルは、すべてのCRLファイルを結合する必要があります。
複数のCRLファイルがハッシュ形式で格納されているディレクトリ・パスを指定する場合、2番目の形式を使用します。
ハッシュ形式でCRLを作成する方法の詳細は、第6.7.2.2項「ファイル・システムでのCRLの管理」を参照してください。
次の例では、プロパティ・ファイルは単一のCRLファイルを指定します。
SSLEnabled=true AuthenticationType=Server CertValidation=crl KeyStore=ohs1 CertValidationPath=file:///tmp/file.crl
次の例では、プロパティ・ファイルは複数のCRLファイルへのディレクトリ・パスを指定しています。
SSLEnabled=true AuthenticationType=Server KeyStore=ohs1 CertValidation=crl CertValidationPath=dir:///tmp
|
注意: LDAPベースのCRLまたはCRL配布ポイントはサポートされません。 |
orapkiコマンド行ツールを使用して、ファイル・システム上でCRLを管理します。このトピックの詳細は、第G.1.5項「orapkiユーティリティを使用した証明書失効リスト(CRL)の管理」を参照してください。
ハッシュ形式へのCRLの名前変更
CRL格納場所を指定する場合は、CRLの名前を変更する必要があります。これにより、実行時に効率的にCRLをロードできます。この操作では、実際のCRLファイルへのシンボリック・リンクを作成します。Windowsでは、新しい名前を付けたファイルにCRLをコピーします。
CRLの名前を変更するには:
orapki crl hash [-crl [url|filename]] [-walletwallet] [-symlink directory] [-copy directory] [-summary] [-pwdpassword]
次に例を示します。
orapki crl hash -crl nzcrl.txt -symlink wltdir -pwd password
CRLファイル名を実行時に指定すると、複数のCRLをそのファイルに結合できます。この例で作成されるCRLはBase64形式なので、テキスト・エディタを使用してCRLを結合できます。
CRLの作成
|
注意: CRLの作成および証明書の失効はテスト目的で行い、必ず自己署名証明書とともに使用します。本番で使用する場合、本番の証明書を有名なCAから取得して、CRLをそれらの認証局から取得します。 |
CRLを作成するには:
orapki crl create
[-crl [url|filename]] [-wallet [cawallet]] [-nextupdate [days]] [-pwd password]
次に例を示します。
orapki crl create
-crl nzcrl.crl -wallet rootwlt -nextupdate 3650 -pwd password
証明書の失効
証明書が失効すると、証明書のシリアル番号がCRLに追加されます。
証明書を失効させるには:
orapki crl revoke
[-crl [url|filename]] [-wallet [cawallet]] [-cert [revokecert]] [-pwd password]
次に例を示します。
orapki crl revoke
-crl nzcrl.txt -wallet rootwlt -cert cert.txt -pwd password
コンポーネントでCRL検証が正しく構成されていることをテストするには、次の手順を実行します。
コンポーネントで使用される証明書をウォレットに設定します。
この証明書を含むCRLを失効済証明書リストの中に生成します。第6.7.2.2項「ファイル・システムでのCRLの管理」で説明されている手順を実行します。
このCRLを使用するようにコンポーネントを構成します。第6.7.2.1項「コンポーネントのCRL検証の構成」で説明されている手順を実行します。
この失効済証明書を使用すると、SSLハンドシェイクは失敗します。
Oracle Fusion MiddlewareでのFIPS 140のサポートの詳細は、第8章を参照してください。
この項では、Oracle Fusion Middlewareコンポーネント管理者およびアプリケーション開発者のいくつかのベスト・プラクティスの概要を説明します。内容は次のとおりです。
システム管理者のベスト・プラクティスには、次のようなものがあります。
自己署名付きウォレットはテスト環境でのみ使用します。本番環境に移行する前にウォレットにCAで署名された証明書を取得する必要があります。詳細は、第7章「キーストア、ウォレットおよび証明書の管理」を参照してください。
(少なくともWeb層の)コンポーネントでは、DNとしてシステム・ホスト名あるいは仮想ホストまたはサイト名を持つ証明書を使用することをお薦めします。そうすることにより、混乱させる警告メッセージが表示されることなく、ブラウザはSSLモードで接続できます。
SSLで使用される証明書では、最小キー・サイズの1024ビットを使用することをお薦めします。キー・サイズを大きくすると、セキュリティは高くなりますが、パフォーマンスが低下します。セキュリティおよびパフォーマンス要件に応じて、適切なキー・サイズ値を選択します。
SSLハンドシェイクが失敗する主な原因の1つに信頼性が欠落していることがあります。SSLハンドシェイクを開始する前に、(サーバーCA証明書をクライアント・キーストアにインポートして)クライアントがサーバーを信頼していることを確認してください。クライアント認証も必要な場合は、その逆も確認する必要があります。
次のプラクティスをお薦めします。
Javaキーストア(JKS)を使用してJava EEアプリケーションの証明書を保存します。
キーストア・パス、トラストストア・パス、構成ファイルの認証タイプなどのSSL構成パラメータは、アプリケーション・コードのそれぞれの値に埋め込まず、外部に配置します。そうすることで、アプリケーション自体を変更せずに柔軟にSSL構成を変更できます。
Oracleウォレットを管理し、Oracle Fusion Middlewareコンポーネント用のSSLを構成するために、WLSTコマンドが使用できます。
これらのWLSTコマンドの詳細は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』の次の章を参照してください。
「SSL構成WLSTコマンド」
「ウォレット構成WLSTコマンド」
|
関連項目: WLSTシェルを起動してSSL関連コマンドを実行する方法の詳細は、第7.2項「キーストアおよびウォレット用コマンド行インタフェース」を参照してください。その他の場所からはWLSTインタフェースを起動しないでください。 |
|
注意: SSL構成用のすべてのWLSTコマンドは、オンライン・モードで実行する必要があります。 |
|
注意:
|
