| Oracle® Coherenceセキュリティ・ガイド リリース3.7.1 B71689-01 |
|
 前 |
Coherenceには、Coherence*Extendクライアントとプロキシ間のTCP通信と同様、クラスタ・ノード間のTCMP通信を保護するSecure Socket Layer (SSL)実装が用意されています。Coherenceでは、SSL 3.0プロトコルの次のバージョンのTransport Layer Security (TLS) 1.0プロトコルがサポートされています。しかし、SSLの方が広く認識されている用語であるため、このドキュメントではSSLという用語を使用します。
この章には次の項が含まれます:
この項では、このドキュメントで使用されている一般的なSSLの概念について概要を簡単に説明します。SSLの詳細については述べません。SSLに慣れていない方は、http://www.ietf.orgで入手できる正式な仕様、およびhttp://java.sun.com/javase/technologies/security/index.jspにあるJava SEセキュリティのリソースを参照してください。SSLについて精通している場合は、この項を省略できます。
SSLは、ネットワーク上のエンティティ(通常はクライアントとサーバー)間の通信を保護するセキュリティ・プロトコルです。SSLは、クライアントとサーバーをデジタル証明書を使用して認証し、認証済のクライアントとサーバーに関連付けられた一意のキーを使用して通信を暗号化/復号化することにより機能してます。
識別と信頼の確立
エンティティの識別は、デジタル証明書と公開暗号鍵および秘密暗号鍵を使用して確立されます。デジタル証明には、エンティティに関する一般情報と、それに埋め込まれた公開の暗号化鍵が含まれています。デジタル証明は認証局(CA)によって検証され、CAのデジタル証明を使用して署名されています。CAのデジタル証明により、エンティティが本物であるという信頼が確立されます。
データの暗号化および復号化
エンティティのデジタル証明には、エンティティの秘密の暗号化鍵と対になった公開の暗号化鍵が含まれています。証明書は、初期接続の際にエンティティ間で渡されます。そのとき、データは公開鍵を使用して暗号化されます。エンティティの公開鍵を使用して暗号化されたデータは、そのエンティティの秘密鍵でのみ復号化されます。これにより、公開の暗号化鍵を所有するエンティティのみがそのデータを復号化できるのです。
一方向の認証と双方向の認証の使用
クライアントとサーバー間のSSL通信は、一方向または双方向のいずれの認証を使用しても設定できます。一方向の認証では、サーバーは認証用のデジタル証明を送信して、クライアントに対してそのサーバー自体を識別する必要があります。クライアントはサーバーにデジタル証明を送信する必要はなく、サーバーに対して匿名のままです。双方向の認証では、クライアントとサーバーの両方がそれぞれのデジタル証明を相互の認証のために送信する必要があります。双方向の認証では、通信の両サイドで識別の認識が確認されることによって、より強いセキュリティが提供されます。
Java SSLアーティファクトの生成
JDK_HOME/binディレクトリに置かれたJava keytoolユーティリティは、SSLアーティファクトの生成および管理に使用されます。これには、キー・ストアの作成、一意の公開/秘密鍵ペアの生成、公開鍵を含む自己署名付きデジタル証明書の作成、証明書の秘密鍵への関連付け、キー・ストアへのこれらのアーティファクトの格納などが含まれます。
次の例では、/testディレクトリに置かれているserver.jksという名前のキー・ストアを作成します。公開鍵と秘密鍵のペアは、-dname値("cn=administrator, ou=Coherence, o=Oracle, c=US")によって識別されるエンティティに対して生成されます。公開鍵と識別情報を含む自己署名付き証明書が作成されます。この証明書は180日間有効で、別名(admin)が参照するキー・ストア・エントリの秘密鍵と関連付けられています。パスワードは、キー・ストアと秘密鍵の両方に対して入力する必要があります。
keytool -genkeypair -dname "cn=administrator, ou=Coherence, o=Oracle, c=US" -alias admin -keypass password -keystore /test/server -storepass password -validity 180
このコマンドで生成される証明書は、開発目的を十分に果たしています。しかし、証明書は通常VeriSignなどの信頼されるCAによって検証されます。証明書が検証されるためには、keytoolユーティリティを使用して証明書の署名リクエスト(CSR: Certificate Signing Request)ファイルを生成します。
keytool -certreq -file admin.csr
このCSRファイルをCAに送信する必要があり、CAからは署名付きの証明書が返されます。keytoolユーティリティを使用して、キー・ストア内の自己署名付き証明書に置き換わる返された証明書をインポートします。
keytool -importcert -trustcacerts -file signed_admin.cer
最後に、keytoolを使用して、信頼ストアとして機能する2つ目のキー・ストアを作成します。信頼ストアには信頼できるCAのデジタル証明書が保管されます。CAが検証した証明書は、CAの証明書が信頼ストアにも格納されている場合にのみ、信頼できると見なされます。たとえば、通常の一方向の認証では、クライアントはサーバーの証明書に署名したCAのデジタル証明書が格納された信頼ストアを持っている必要があります。開発目的の場合、自己署名付き証明書は識別と信頼の両方に使用できます。さらに、1つのキーストアが識別ストアと信頼ストアの両方として使用できます。
Windows SSLアーティファクトの生成
次の手順では、Windows上でCoherence*Extend .NETクライアントを保護する際に必要な双方向認証の設定方法について説明します。「.NETクライアント側のストリーム・プロバイダの構成」を参照してください。Windows上でSSLを設定する完全な手順については、Windowsのドキュメントを参照してください。
http://technet.microsoft.com/en-us/library/cc782338%28WS.10%29.aspx
Windows上で双方向認証を設定するには:
Visual Studioコマンド・プロンプトで次のコマンドを実行します。
c:\>makecert -pe -n "CN=Test And Dev Root Authority" -ss my -sr LocalMachine -a sha1 -sky signature -r "Test And Dev Root Authority.cer" c:\>makecert -pe -n "CN=MyServerName" -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "Test And Dev Root Authority" -is MY -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 c:\>makecert -pe -n "CN=MyClient" -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "Test And Dev Root Authority" -is MY -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12
信頼できるルート認証局の証明書を作成します(テスト目的のみ)。
makecert -pe -n "CN=Test And Dev Root Authority" -ss my -sr LocalMachine -a sha1 -sky signature -r "Test And Dev Root Authority.cer"
作成した証明書を、個人ストアから信頼できるルート認証局ストアにコピーします。
信頼できるルート証明書に基づいてサーバー証明書を作成します。
makecert -pe -n "CN=MyServerName" -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "Test And Dev Root Authority" -is MY -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12
信頼できるルート認証局(Test And Dev Root Authority)の証明書ストアから、公開鍵なしの証明書ファイル(.cer)をエクスポートします。
信頼できるルート認証局(Test And Dev Root Authority)の証明書ストアから、秘密鍵付きの証明書ファイル(.pfx)をエクスポートします。
各クライアント・マシンで、sslstreamクライアント・プログラムがアクセスできる場所に.cerファイルをコピーします。
各クライアント・マシンで、.pfxファイルをコピーします。
各クライアント・マシンで、信頼できるルート認証局の証明書ストアに.pfxファイルをインポートします。
各クライアント・マシンで、.pfxファイルを削除します(この手順により、クライアントによる秘密鍵のやり取りまたはエクスポートができなくなります)。
Coherenceクラスタは、TCMPでSSLを使用するように構成できます。一方向と双方向の認証がサポートされています。通常、双方向の認証を使用する方が一方向の認証よりも多く、クラスタ環境では一方向の認証は双方向の認証ほど使用されません。さらに、TCMPではpeer-to-peerプロトコルであることを認識する必要があります。peer-to-peerプロトコルは、通常、多くのクラスタ・ノードを相互に接続したままであることが想定される信頼できる環境で動作します。管理およびパフォーマンスに関してSSLが受ける可能性のある影響について、慎重に考慮する必要があります。
この項の内容は次のとおりです。
TCMP用のSSLは、オペレーション・オーバーライド・ファイルで<unicast-listener要素内の<socket-provider要素をオーバーライドして構成します。<socket-provider要素を使用して、<socket-providersノード内で定義されたSSLソケット・プロバイダ構成を参照する方法をお薦めします。<socket-provider要素は、<unicast-listener要素内の完全な構成の定義にも使用できます。次に両方の方法を示します。<socket-provider要素の詳細は、『Oracle Coherence開発者ガイド』を参照してください。
|
注意: クラスタは、TCMPでSSLを使用できるように既知のアドレスを使用して構成する必要があります。既知のアドレスの設定の詳細は、『Oracle Coherence開発者ガイド』を参照してください。 |
例5-1は、SSL双方向の認証設定を示しています。これには、識別ストアと信頼ストアの両方をクラスタの各ノード上に配置する必要があります。この例では、<protocol>および<algorithm>要素(それぞれTLSおよびSunX509)にデフォルト値を使用しています。これらは完全を期して示しますが、デフォルト値使用の際には省略されることがあります。例では、SSLソケット・プロバイダが<socket-providers>ノード内で定義され、<unicast-listener>要素内から参照される推奨方法を使用しています。
例5-1 TCMP通信に対するSSLのサンプル構成
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<socket-provider>mySSLConfig</socket-provider>
<well-known-addresses>
<socket-address id="1">
<address>198.168.1.5</address>
<port>8088</port>
</socket-address>
</well-known-addresses>
</unicast-listener>
<socket-providers>
<socket-provider id="mySSLConfig">
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
<password>password</password>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
</trust-manager>
</ssl>
</socket-provider>
</socket-providers>
</cluster-config>
</coherence>
代替案としては次に示すように、SSLソケット・プロバイダを<unicast-listener>要素内で直接定義することも可能です。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<socket-provider>
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
<password>password</password>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
</trust-manager>
</ssl>
</socket-provider>
<well-known-addresses>
<socket-address id="1">
<address>198.168.1.5</address>
<port>8088</port>
</socket-address>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>
出荷の際には事前定義済SSLソケット・プロバイダが組み込まれており、信頼できるピアが単一JKSキー・ストア内に存在するピアの信頼に基づいて、双方向のSSL接続を構成できます。専用のピアの信頼アルゴリズム(PeerX509)は、キー・ストア内にある証明書の信頼(信頼のみ)を前提として機能します。TCMPがpeer-to-peerプロトコルであるという事実を活用すると、ピア・アルゴリズムによりSSLのパフォーマンスを向上できます。
事前定義済SSLソケット・プロバイダは、オペレーション・デプロイメント・ディスクリプタの<socket-providers>要素内に配置されています。
...
<cluster-config>
<socket-providers>
<socket-provider id="ssl">
<ssl>
<identity-manager>
<key-store>
<url system-property="tangosol.coherence.security.keystore">
file:keystore.jks
</url>
<password system-property="tangosol.coherence.security.
password"/>
</key-store>
<password system-property="tangosol.coherence.security.password"/>
</identity-manager>
<trust-manager>
<algorithm>PeerX509</algorithm>
<key-store>
<url system-property="tangosol.coherence.security.keystore">
file:keystore.jks
</url>
<password system-property="tangosol.coherence.security.
password"/>
</key-store>
</trust-manager>
</ssl>
</socket-provider>
</socket-providers>
</cluster-config>
...
構成では、事前定義済SSLソケット・プロバイダには、クラスパスにあるkeystore.jksというJavaキー・ストアが必要です。この名前は、違うキー・ストアを指定する際に、tangosol.coherence.security.keystoreシステム・プロパティを使用してオーバーライドできます。さらに、tangosol.coherence.security.passwordシステム・プロパティを使用して、そのキー・ストアと証明書に必要なパスワードを指定できます。代替案として、オペレーション・オーバーライド・ファイルを使用して、必要に応じて事前定義済SSLソケット・プロバイダを変更できます。
|
注意: クラスタ内のすべてのノードに対する証明書がキー・ストアにインポートされていることを確認してください。 |
事前定義済SSLソケット・プロバイダを使用するには、<unicast-listener>構成の<socket-provider>要素をオーバーライドして、SSLソケット・プロバイダのid属性を使用してSSLソケット・プロバイダを参照します。次の例では、事前定義済SSLソケット・プロバイダを使用するためにユニキャスト・リスナーを構成しています。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<socket-provider>ssl</socket-provider>
<well-known-addresses>
<socket-address id="1">
<address>198.168.1.5</address>
<port>8088</port>
</socket-address>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>
Extendクライアントと拡張プロキシの間の通信は、SSLを使用して保護できます。SSLには、クライアント側とクラスタ側の両方での構成が必要です。SSLは、Javaクライアントと.NETクライアントではサポートされていますが、C++ではサポートされていません。
この項の構成例は、すべてのクライアントおよびサーバーの有効なデジタル証明書が必要に応じて作成済であることと、証明書に認証局(CA)の署名が付いていることを前提としています。デジタル証明書はアイデンティティ・ストアに配置する必要があり、信頼ストアには署名元のCAのデジタル証明書を含める必要があります。開発中は、必要に応じて自己署名付きの証明書を使用できます。
この項には、次のトピックが含まれます:
SSLをクラスタ側のキャッシュ構成ファイルで構成するには、プロキシ・サービス用のSSLソケット・プロバイダを定義します。SSLソケット・プロバイダの構成には、必要な粒度レベルに応じて、次の2つのオプションがあります。
プロキシ・サービスごと – プロキシ・サービスごとに、SSLソケット・プロバイダの構成を定義するか、オペレーション構成ファイルに含まれている事前定義済の構成を参照します。
すべてのプロキシ・サービス – すべてのプロキシ・サービスで同じグローバルなSSLソケット・プロバイダの構成を使用します。独自の構成を提供するプロキシ・サービスでは、グローバル構成がオーバーライドされます。グローバル構成では、オペレーション構成ファイルに含まれている事前定義済の構成を参照することもできます。
プロキシ・サービス用にSSLソケット・プロバイダを構成するには、各<proxy-scheme定義の<tcp-acceptor要素内に<socket-provider要素を追加します。<socket-provider要素の詳細は、『Oracle Coherence開発者ガイド』のsocket-providerに関する項を参照してください。
例5-2は、<protocol>要素および<algorithm>要素にデフォルト値(それぞれ、TLSおよびSunX509)を使用するSSLソケット・プロバイダを構成するプロキシ・スキームを示しています。これらは完全を期して示しますが、デフォルト値使用の際には省略されることがあります。
例5-2では、IDキー・ストア(server.jks)と信頼キー・ストア(trust.jks)の両方を構成します。これは典型的な双方向SSL認証であり、クライアントとプロキシの双方が、それぞれのデジタル証明書を交換し、互いのIDを確認する必要があります。一方向SSL認証の場合は、プロキシ・サーバーの構成にIDキー・ストアを含める必要がありますが、信頼キー・ストアは含める必要がありません。
例5-2 クラスタ側のSSL構成のサンプル
...
<proxy-scheme>
<service-name>ExtendTcpSSLProxyService</service-name>
<acceptor-config>
<tcp-acceptor>
<socket-provider>
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
<password>password</password>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
</trust-manager>
</ssl>
</socket-provider>
<local-address>
<address>192.168.1.5</address>
<port>9099</port>
</local-address>
</tcp-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
...
次の例では、オペレーション・デプロイメント・ディスクリプタの<socket-providersノードで定義されているSSLソケット・プロバイダの構成を、構成のid属性(ssl)を指定することによって参照します。<socket-providers要素の詳細は、『Oracle Coherence開発者ガイド』のsocket-providersに関する項を参照してください。
|
注意: 出荷の際には、事前定義のSSLソケット・プロバイダはオペレーション・デプロイメント・ディスクリプタに含まれており、sslという名前になっています。事前定義済SSLソケット・プロバイダは、双方向SSL接続用に構成されており、信頼されているピアがすべて単一のJKSキー・ストア内に存在するピア信頼に基づいています。詳細は、「事前定義済SSLソケット・プロバイダの使用方法」を参照してください。別のSSLソケット・プロバイダを構成するには、オペレーション・オーバーライド・ファイルを使用して事前定義済SSLソケット・プロバイダを変更するか、必要に応じてソケット・プロバイダの構成を作成します。 |
...
<proxy-scheme>
<service-name>ExtendTcpSSLProxyService</service-name>
<acceptor-config>
<tcp-acceptor>
<socket-provider>ssl</socket-provider>
<local-address>
<address>192.168.1.5</address>
<port>9099</port>
</local-address>
</tcp-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
...
すべてのプロキシ・サービスで使用するグローバルなSSLソケット・プロバイダを構成するには、キャッシュ構成ファイルの<defaults要素内にある<socket-provider要素を使用します。この方法を使用すると、プロキシ・スキーム定義内での追加の構成は不要です。<default要素の詳細は、『Oracle Coherence開発者ガイド』のdefaultsに関する項を参照してください。
次の例では、例5-2と同じSSLソケット・プロバイダの構成を使用して、これをすべてのプロキシ・サービス用に構成します。
<?xml version='1.0'?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<socket-provider>
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
<password>password</password>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
</trust-manager>
</ssl>
</socket-provider>
</defaults>
...
次の例では、オペレーション・デプロイメント・ディスクリプタで定義されているSSLソケット・プロバイダの構成を参照することによって、グローバルなSSLソケット・プロバイダを構成します。
<defaults> <socket-provider>ssl</socket-provider> </defaults>
SSLをクライアント側のキャッシュ構成ファイルで構成するには、リモート・キャッシュ・スキーム用、また必要に応じてリモート起動スキーム用のSSLソケット・プロバイダを定義します。SSLソケット・プロバイダの構成には、必要な粒度レベルに応じて、次の2つのオプションがあります。
リモート・サービスごと – リモート・サービスごとに、SSLソケット・プロバイダの構成を定義するか、オペレーション構成ファイルに含まれている事前定義済の構成を参照します。
すべてのリモート・サービス – すべてのリモート・サービスで同じグローバルなSSLソケット・プロバイダの構成を使用します。独自の構成を提供するリモート・サービスでは、グローバル構成がオーバーライドされます。グローバル構成では、オペレーション構成ファイルに含まれている事前定義済の構成を参照することもできます。
リモート・サービス用にSSLソケット・プロバイダを構成するには、リモート・スキームの定義の<tcp-initiator要素内に<socket-provider要素を追加します。<socket-provider要素の詳細は、『Oracle Coherence開発者ガイド』のsocket-providerに関する項を参照してください。
例5-3は、SSLを使用するソケット・プロバイダを構成するリモート・キャッシュ・スキームを示しています。この例では、<protocol>および<algorithm>要素(それぞれTLSおよびSunX509)にデフォルト値を使用しています。これらは完全を期して示しますが、デフォルト値使用の際には省略されることがあります。
例5-3では、IDキー・ストア(server.jks)と信頼キー・ストア(trust.jks)の両方を構成します。これは典型的な双方向SSL認証であり、クライアントとプロキシの双方が、それぞれのデジタル証明書を交換し、互いのIDを確認する必要があります。一方向SSL認証の場合は、クライアントの構成に信頼キー・ストアを含める必要がありますが、IDキー・ストアは含める必要がありません。つまり、クライアントは、プロキシに対してデジタル証明書を渡すことはなく、匿名のままということです。クライアントの信頼キー・ストアには、プロキシのデジタル証明書に署名する際に使用したCAのデジタル証明書を含める必要があります。
例5-3 Javaクライアント側のSSL構成のサンプル
<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>dist-extend</cache-name>
<scheme-name>extend-dist</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>ExtendTcpSSLCacheService</service-name>
<initiator-config>
<tcp-initiator>
<socket-provider>
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
<password>password</password>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
</trust-manager>
</ssl>
</socket-provider>
<remote-addresses>
<socket-address>
<address>198.168.1.5</address>
<port>9099</port>
</socket-address>
</remote-addresses>
<connect-timeout>10s</connect-timeout>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>5s</request-timeout>
</outgoing-message-handler>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
</cache-config>
次の例では、オペレーション・デプロイメント・ディスクリプタの<socket-providersノードで定義されているSSLソケット・プロバイダの構成を、構成のid属性(ssl)を指定することによって参照します。<socket-providers要素の詳細は、『Oracle Coherence開発者ガイド』のsocket-providersに関する項を参照してください。
|
注意: 出荷の際には、事前定義のSSLソケット・プロバイダはオペレーション・デプロイメント・ディスクリプタに含まれており、sslという名前になっています。事前定義済SSLソケット・プロバイダは、双方向SSL接続用に構成されており、信頼されているピアがすべて単一のJKSキー・ストア内に存在するピア信頼に基づいています。詳細は、「事前定義済SSLソケット・プロバイダの使用方法」を参照してください。別のSSLソケット・プロバイダを構成するには、オペレーション・オーバーライド・ファイルを使用して事前定義済SSLソケット・プロバイダを変更するか、必要に応じてソケット・プロバイダの構成を作成します。 |
<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>dist-extend</cache-name>
<scheme-name>extend-dist</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>ExtendTcpSSLCacheService</service-name>
<initiator-config>
<tcp-initiator>
<socket-provider>ssl</socket-provider>
<remote-addresses>
<socket-address>
<address>198.168.1.5</address>
<port>9099</port>
</socket-address>
</remote-addresses>
<connect-timeout>10s</connect-timeout>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>5s</request-timeout>
</outgoing-message-handler>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
</cache-config>
すべてのリモート・サービスで使用するグローバルなSSLソケット・プロバイダを構成するには、キャッシュ構成ファイルの<defaults要素内にある<socket-provider要素を使用します。この方法を使用すると、リモート・スキーム定義内での追加の構成は不要です。<default要素の詳細は、『Oracle Coherence開発者ガイド』のdefaultsに関する項を参照してください。
次の例では、例5-3と同じSSLソケット・プロバイダの構成を使用して、これをすべてのリモート・サービス用に構成します。
<?xml version='1.0'?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<socket-provider>
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
<password>password</password>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
</trust-manager>
</ssl>
</socket-provider>
</defaults>
...
次の例では、オペレーション・デプロイメント・ディスクリプタで定義されているSSLソケット・プロバイダの構成を参照することによって、グローバルなSSLソケット・プロバイダを構成します。
<defaults> <socket-provider>ssl</socket-provider> </defaults>
SSLを.NETクライアント側のキャッシュ構成ファイルで構成するには、リモート・サービス用のSSLストリーム・プロバイダを定義します。SSLストリーム・プロバイダは、<tcp-initiator>要素内の<stream-provider>要素を使用して定義します。
|
注意: 証明書は、Windowサーバーでは、オペレーティング・システム・レベルで証明書マネージャを使用して管理します。サンプルの構成は、拡張プロキシの証明書が証明書マネージャに含まれていること、また、プロキシの証明書に署名する際に使用したCAの証明書が信頼できる認証局として含まれていることを前提としています。一般的な例については、「Windows SSLアーティファクトの生成」を参照してください。証明書の管理に関する詳細は、次のサイトを参照してください。
|
例5-4は、SSLストリーム・プロバイダを構成するリモート・キャッシュ・スキームを示しています。SSLストリーム・プロバイダの構成に使用する要素の詳細は、キャッシュ構成XMLスキーマ(INSTALL_DIR\config\cache-config.xsd)を参照してください。
例5-4 .NETクライアント側のSSL構成のサンプル
<?xml version="1.0"?>
<cache-config xmlns="http://schemas.tangosol.com/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://schemas.tangosol.com/cache
assembly://Coherence/Tangosol.Config/cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>dist-extend</cache-name>
<scheme-name>extend-dist</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>ExtendTcpSSLCacheService</service-name>
<initiator-config>
<tcp-initiator>
<stream-provider>
<ssl>
<protocol>Tls</protocol>
<local-certificates>
<certificate>
<url>C:\</url>
<password>password</password>
<flags>DefaultKeySet</flags>
</certificate>
</local-certificates>
</ssl>
</stream-provider>
<remote-addresses>
<socket-address>
<address>198.168.1.5</address>
<port>9099</port>
</socket-address>
</remote-addresses>
<connect-timeout>10s</connect-timeout>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>5s</request-timeout>
</outgoing-message-handler>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
</cache-config>
