| Oracle® Fusion Middleware Oracle Coherenceの保護 12c (12.2.1) E69905-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
この項では、このドキュメントで使用されている一般的なSSLの概念について簡単に説明します。SSLに関する完全なガイドを提供することを意図しているものではありません。完全なドキュメントについては、次のリソースを参照してください。SSLについて精通している場合は、この項を省略できます。
正式なSSLおよびTLSの仕様 – http://www.ietf.org
Java SEセキュリティ –
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.html
SSLは、ネットワーク上のエンティティ(通常はクライアントとサーバー)間の通信を保護するセキュリティ・プロトコルです。SSLは、クライアントとサーバーをデジタル証明書を使用して認証し、認証済のクライアントとサーバーに関連付けられた一意のキーを使用して通信を暗号化および復号化することにより機能しています。
識別と信頼の確立
エンティティの識別は、デジタル証明書と、公開および秘密の暗号化鍵を使用することで確立されます。デジタル証明には、エンティティに関する一般情報と、それに埋め込まれた公開の暗号化鍵が含まれています。デジタル証明は認証局(CA)によって検証され、CAのデジタル証明を使用して署名されています。CAのデジタル証明により、エンティティが本物であるという信頼が確立されます。
データの暗号化および復号化
エンティティのデジタル証明書には、秘密の暗号化鍵と対になった公開の暗号化鍵が含まれています。証明書は、初期接続の際にエンティティ間で渡されます。そのとき、データは公開鍵を使用して暗号化されます。エンティティの公開鍵を使用して暗号化されたデータは、そのエンティティの秘密鍵を使用してのみ復号化されます。これにより、公開の暗号化鍵を所有するエンティティのみがそのデータを復号化できるのです。
一方向の認証と双方向の認証の使用
クライアントとサーバー間のSSL通信は、一方向または双方向のいずれかの認証を使用して設定されます。一方向の認証では、サーバーは認証用のデジタル証明を送信して、クライアントに対してそのサーバー自体を識別する必要があります。クライアントはサーバーにデジタル証明を送信する必要はなく、サーバーに対して匿名のままです。双方向の認証では、クライアントとサーバーの両方がそれぞれのデジタル証明を相互の認証のために送信する必要があります。双方向の認証では、通信の各サイドで識別の認識が確認されることによって、より強いセキュリティが提供されます。
Java SSLアーティファクトの生成
JDK_HOME/binディレクトリにあるJava keytoolユーティリティにより、SSLアーティファクトが生成および管理されます。これには、キーストアの作成、一意の公開/秘密鍵ペアの生成、公開鍵を含む自己署名付きデジタル証明書の作成、証明書の秘密鍵への関連付け、キーストアへのこれらのアーティファクトの格納などが含まれます。
次の例では、server.jksという名前のキーストアが/testディレクトリに作成されます。公開鍵と秘密鍵のペアは、-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上で双方向の認証を設定して、Oracle Coherence*Extend .NETクライアントを保護する方法について説明します。.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)をエクスポートします。
.cerファイルを各クライアント・コンピュータにコピーします。この場所から、sslstreamクライアント・プログラムにアクセスできる必要があります。
.pfxファイルを各クライアント・コンピュータにコピーします。
各クライアント・コンピュータの信頼できるルート認証局の証明書ストアに.pfxファイルをインポートします。
各クライアント・コンピュータで、.pfxファイルを削除します。(この手順により、クライアントが秘密鍵をやり取りしたりエクスポートしたりすることがなくなります。)
この項では、クラスタ・メンバー間の通信を保護するようにSSLを構成する方法について説明します。この項の構成例は、すべてのクライアントおよびサーバーの有効なデジタル証明書が必要に応じて作成済であることと、証明書に認証局(CA)の署名が付いていることを前提としています。デジタル証明書はアイデンティティ・ストアに配置する必要があり、信頼キーストアには署名元のCAのデジタル証明書を含める必要があります。開発中は、必要に応じて自己署名付きの証明書を使用します。Oracle Coherence*ExtendでのSSLの使用方法については、「SSLを使用したExtendクライアント通信の保護」を参照してください。
この項には次のトピックが含まれます:
TCMPでは、一方向と双方向の両方のSSL認証がサポートされています。通常、双方向の認証を使用する方が一方向の認証よりも多く、クラスタ環境では一方向の認証は双方向の認証ほど使用されません。さらに、TCMPではpeer-to-peerプロトコルであることを認識する必要があります。peer-to-peerプロトコルは、通常、多くのクラスタ・ノードを相互に接続したままであることが想定される信頼できる環境で動作します。管理およびパフォーマンスに関するSSLの影響について、慎重に考慮してください。
図6-1 は、双方向のSSLを使用するクラスタ・メンバーの概念を示しています。各クラスタ・メンバーには、相互認証で使用されるデジタル証明書を含む信頼キーストアとJavaキーストア(JKS)があります。
オペレーション・オーバーライド・ファイルで、<unicast-listener要素内の<socket-provider要素をオーバーライドして、TCMP用のSSLを構成します。<socket-provider要素を使用して、<socket-providersノード内で定義されたSSLソケット・プロバイダ構成を参照する方法をお薦めします。ただし、<socket-provider要素は、インラインのSSL構成を含めることもサポートしています。この項では、両方の方法について説明します。<socket-provider要素の詳細なリファレンスは、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
注意:
TCMPでSSLを使用するには、Well Knownアドレス(WKA)を使用する必要があります。WKAの設定の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
例6-1 は、SSLの双方向認証の設定を示しています。この設定では、IDストアと信頼キーストアの両方がクラスタ内の各ノードに存在している必要があります。この例では、<protocol>および<algorithm>要素(それぞれTLSおよびSunX509)にデフォルト値を使用しています。これらは完全を期して示しますが、デフォルト値使用の際には省略できます。例では、SSLソケット・プロバイダが<socket-providers>ノード内で定義され、<unicast-listener>要素内から参照される推奨方法を使用しています。
例6-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 system-property="coherence.socketprovider>
mySSLConfig</socket-provider>
<well-known-addresses>
<socket-address id="1">
<address system-property="coherence.wka">198.168.1.5
</address>
<port system-property="coherence.wka.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>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
</socket-providers>
</cluster-config>
</coherence>
別の方法として、例6-2に示すように、SSLソケット・プロバイダは、<unicast-listener> 要素内での直接のインライン構成をサポートしています。
例6-2 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 system-property="coherence.socketprovider>
<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>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
<well-known-addresses>
<socket-address id="1">
<address system-property="coherence.wka">198.168.1.5
</address>
<port system-property="coherence.wka.port">8088</port>
</socket-address>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>
Oracle Coherenceには、双方向のSSL接続の構成を可能にする、事前定義済のSSLソケット・プロバイダが含まれています。事前定義済ソケット・プロバイダは、信頼されているピアがすべて単一のJKSキーストア内に存在するピア信頼に基づいています。専用のピアの信頼アルゴリズム(PeerX509)は、キーストア内にある証明書の信頼(信頼のみ)を前提として機能し、TCMPがピアツーピア・プロトコルであることを活用します。
事前定義済SSLソケット・プロバイダは、オペレーション・デプロイメント・ディスクリプタの<socket-providers>要素内に定義されています。
...
<cluster-config>
<socket-providers>
<socket-provider id="ssl">
<ssl>
<identity-manager>
<key-store>
<url system-property="coherence.security.keystore">
file:keystore.jks
</url>
<password system-property="coherence.security.
password"/>
</key-store>
<password system-property="coherence.security.password"/>
</identity-manager>
<trust-manager>
<algorithm>PeerX509</algorithm>
<key-store>
<url system-property="coherence.security.keystore">
file:keystore.jks
</url>
<password system-property="coherence.security.
password"/>
</key-store>
</trust-manager>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
</socket-providers>
</cluster-config>
...
構成では、事前定義済SSLソケット・プロバイダには、クラスパスにあるkeystore.jksというJavaキーストアが必要です。オペレーション・オーバーライド・ファイルを使用して、必要に応じて任意のソケット・プロバイダの値を変更します。オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.security.keystoreおよびcoherence.security.passwordシステム・プロパティによってキーストアとパスワードをオーバーライドします。次に例を示します。
-Dcoherence.security.keystore=/mykeystore.jks -Dcoherence.security.password=password
注意:
クラスタ内のすべてのノードに対する証明書がキーストアにインポートされていることを確認してください。
事前定義済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
system-property="coherence.socketprovider>ssl
</socket-provider>
<well-known-addresses>
<socket-address id="1">
<address system-property="coherence.wka">198.168.1.5
</address>
<port system-property="coherence.wka.port">8088</port>
</socket-address>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>
この項では、Extendクライアントとクラスタ・プロキシ間の通信を保護するようにSSLを構成する方法について説明します。この項の構成例は、すべてのクライアントおよびサーバーの有効なデジタル証明書が必要に応じて作成済であることと、証明書に認証局(CA)の署名が付いていることを前提としています。デジタル証明書はアイデンティティ・ストアに配置する必要があり、信頼キーストアには署名元のCAのデジタル証明書を含める必要があります。開発中は、必要に応じて自己署名付きの証明書を使用します。クラスタ・メンバー間でのSSLの使用方法の詳細は、「SSLを使用したTCMP通信の保護」を参照してください。
この項には次のトピックが含まれます:
SSLは、Extendクライアントと拡張プロキシ間の通信を保護するために使用されます。SSLには、クライアント側とクラスタ側の両方での構成が必要です。SSLは、Javaクライアントと.NETクライアントではサポートされていますが、C++ではサポートされていません。
図6-2 は、SSLを使用してクラスタ・プロキシと通信するExtendクライアントの概念を示しています。クライアントとプロキシには、認証に使用されるデジタル証明書を含む信頼キーストアとアイデンティティ・キーストアがあります。Extendクライアントは通常、一方向認証を使用します。一方向認証では、プロキシのみがクライアントを認証し、クライアントはプロキシに対して匿名のままです。
クラスタ側のキャッシュ構成ファイルで、プロキシ・サービス用のSSLソケット・プロバイダを定義することで、SSLを構成します。SSLソケット・プロバイダの構成には、必要な粒度レベルに応じて、次の2つのオプションがあります。
プロキシ・サービスごと – プロキシ・サービスごとに、SSLソケット・プロバイダの構成を定義するか、オペレーション構成ファイルに含まれている事前定義済の構成を参照します。
すべてのプロキシ・サービス – すべてのプロキシ・サービスで同じグローバルなSSLソケット・プロバイダの構成を使用します。独自の構成を提供するプロキシ・サービスは、グローバル構成をオーバーライドします。グローバル構成では、オペレーション構成ファイルに含まれている事前定義済の構成を参照することもできます。
プロキシ・サービス用にSSLソケット・プロバイダを構成するには、各<proxy-scheme定義の<tcp-acceptor要素内に<socket-provider要素を追加します。<socket-provider要素の詳細なリファレンスは、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
例6-3 は、<protocol>要素および<algorithm>要素にデフォルト値(それぞれ、TLSおよびSunX509)を使用するSSLソケット・プロバイダを構成するプロキシ・スキームを示しています。これらは完全を期して示しますが、デフォルト値使用の際には省略できます。
例6-3 では、アイデンティティ・キーストア(server.jks)と信頼キーストア(trust.jks)の両方を構成します。これは典型的な双方向SSL認証であり、クライアントとプロキシの双方が、デジタル証明書を交換し、互いのIDを確認する必要があります。一方向SSL認証の場合は、プロキシ・サーバーの構成にアイデンティティ・キーストアを含める必要がありますが、信頼キーストアは含める必要がありません。
注意:
プロキシ・サーバーに信頼マネージャが構成されている場合は、プロキシでデジタル証明書が交換される可能性があるため、クライアントでは双方向SSL認証を使用する必要があります。一方向SSL認証を使用する場合は、信頼マネージャが構成されていないことを確認してください。
例6-3 クラスタ側の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>
<socket-provider>tcp</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>
...
次の例では、オペレーション・デプロイメント・ディスクリプタの<socket-providersノードで定義されているSSLソケット・プロバイダの構成を、構成のid属性(ssl)を指定することによって参照します。<socket-providers要素の詳細なリファレンスは、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
注意:
事前定義済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でのアプリケーションの開発』を参照してください。
次の例では、例6-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>
<socket-provider>tcp</socket-provider>
</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でのアプリケーションの開発』を参照してください。
例6-4 は、SSLを使用するソケット・プロバイダを構成するリモート・キャッシュ・スキームを示しています。この例では、<protocol>要素および<algorithm>要素にデフォルト値(それぞれ、TLSおよびSunX509)を使用しています。これらは完全を期して示しますが、デフォルト値使用の際には省略できます。
例6-4 では、アイデンティティ・キーストア(server.jks)と信頼キーストア(trust.jks)の両方を構成します。これは典型的な双方向SSL認証であり、クライアントとプロキシの双方が、デジタル証明書を交換し、互いのIDを確認する必要があります。一方向SSL認証の場合は、クライアントの構成に信頼キーストアを含める必要がありますが、アイデンティティ・キーストアは含める必要がありません。つまり、クライアントは、プロキシに対してデジタル証明書を渡すことはなく、匿名のままということです。クライアントの信頼キーストアには、プロキシのデジタル証明書への署名に使用されたCAのデジタル証明書が含まれている必要があります。
注意:
プロキシ・サーバーに信頼マネージャが構成されている場合は、プロキシでデジタル証明書が交換される可能性があるため、クライアントでは双方向SSL認証を使用する必要があります。一方向のSSL認証を使用する場合は、プロキシの信頼マネージャ構成を削除してください。
例6-4 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>
<socket-provider>tcp</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>
次の例では、オペレーション・デプロイメント・ディスクリプタの<socket-providersノードで定義されているSSLソケット・プロバイダの構成を、構成のid属性(ssl)を指定することによって参照します。<socket-providers要素の詳細なリファレンスは、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
注意:
事前定義済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でのアプリケーションの開発』を参照してください。
次の例では、例6-4 と同じ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>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
</defaults>
...
次の例では、オペレーション・デプロイメント・ディスクリプタで定義されているSSLソケット・プロバイダの構成を参照することによって、グローバルなSSLソケット・プロバイダを構成します。
<defaults> <socket-provider>ssl</socket-provider> </defaults>
.NETクライアント側のキャッシュ構成ファイルで、リモート・サービス用のSSLストリーム・プロバイダを定義することで、SSLを構成します。SSLストリーム・プロバイダは、<tcp-initiator>要素内の<stream-provider>要素を使用して定義します。
注意:
証明書は、Windowサーバーでは、オペレーティング・システム・レベルで証明書マネージャを使用して管理します。サンプルの構成は、証明書マネージャに拡張プロキシの証明書およびプロキシの証明書に署名した信頼できるCAの証明書が含まれていることを前提としています。一般的な例については、「Windows SSLアーティファクトの生成」を参照してください。証明書の管理に関する詳細は、次のサイトを参照してください。
http://technet.microsoft.com/en-us/library/cc782338(WS.10).aspx
例6-5 は、SSLストリーム・プロバイダを構成するリモート・キャッシュ・スキームを示しています。SSLストリーム・プロバイダの構成に使用する要素の詳細は、キャッシュ構成XMLスキーマ(INSTALL_DIR\config\cache-config.xsd)を参照してください。
例6-5 .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>
フェデレーション内のクラスタ参加者間の通信は、SSL通信を使用して保護することが可能で、この通信はフェデレーテッド・サービス・メンバー間で保護され、SSLセキュリティを必要とする各クラスタ参加者にSSL構成を必要とします。この項では、フェデレーテッド・サービスを実行するすべてのサーバーの有効なデジタル証明書が必要に応じて作成済であることと、証明書が認証局(CA)により署名されていることを前提としています。デジタル証明書はアイデンティティ・ストアに配置する必要があり、信頼キーストアには署名元のCAのデジタル証明書を含める必要があります。
次の手順を実行して、SSLを使用してフェデレーション通信を保護します。
SSLソケット・プロバイダは、弱い可能性のある暗号や特定のプロトコル・バージョンの使用を制御するように構成することができます。
暗号スイートおよびプロトコル・バージョンの使用を制御するには、SSLソケット・プロバイダ定義を編集して<cipher-suites>要素および<protocol-versions>要素を含むようにし、それぞれname要素を使用して暗号スイートおよびプロトコル・バージョンのリストを入力します。暗号スイートおよびプロトコル・バージョンが許可される(white-listの値)かまたは許可されない(black-listの値)かを指定するusage属性を含むようにします。usage属性に値を指定しない場合のデフォルトの値はwhite-listです。次に例を示します。
<socket-provider>
<ssl>
...
<cipher-suites usage="black-list">
<name>TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256</name>
</cipher-suites>
<protocol-versions usage="black-list">
<name>SSLv3</name>
</protocol-versions>
...
</ssl>
</socket-provider>
