6 SSLを使用した通信の保護
この章の内容は次のとおりです。
SSLの概要
SSLを初めて使用する場合、SSLを構成する前にこの項を確認してください。この項の目的はSSLの完全なガイドではないため、このドキュメントで使用されている概念についてのみ説明します。SSLについてさらに学習するには、次を参照してください
識別と信頼の確立
エンティティの識別は、デジタル証明書と、公開および秘密の暗号化キーを使用することで確立されます。デジタル証明には、エンティティに関する一般情報と、それに埋め込まれた公開の暗号化キーが含まれています。デジタル証明は認証局(CA)によって検証され、CAのデジタル証明を使用して署名されています。CAのデジタル証明により、エンティティが本物であるという信頼が確立されます。
データの暗号化および復号化
エンティティのデジタル証明書には、秘密の暗号化キーと対になった公開の暗号化キーが含まれています。証明書は、初期接続の際にエンティティ間で渡されます。そのとき、データは公開キーを使用して暗号化されます。エンティティの公開キーを使用して暗号化されたデータは、そのエンティティの秘密キーを使用してのみ復号化されます。これにより、公開の暗号化キーを所有するエンティティのみがそのデータを復号化できるのです。
一方向の認証と双方向の認証の使用
クライアントとサーバー間のSSL通信は、一方向または双方向のいずれかの認証を使用して設定されます。一方向の認証では、サーバーは認証用のデジタル証明を送信して、クライアントに対してそのサーバー自体を識別する必要があります。クライアントはサーバーにデジタル証明を送信する必要はなく、サーバーに対して匿名のままです。双方向の認証では、クライアントとサーバーの両方がそれぞれのデジタル証明を相互の認証のために送信する必要があります。双方向の認証では、通信の各サイドで識別の認識が確認されることによって、より強いセキュリティが提供されます。
Java SSLアーティファクトの生成
ノート:
拡張キーの用途を含む証明書を作成する場合は、それらが正しい用途で構成されていることを確認する必要があります。Coherenceクラスタ・トラフィックを保護するためにキーと証明書を使用する予定の場合、Coherenceクラスタ・メンバーは互いにクライアントとサーバーの両方であるため、拡張キーの用途にはserverAuthとclientAuthの両方を含める必要があります。
拡張プロキシ、gRPCプロキシ、メトリックまたは管理HTTPサービスを保護する場合、これらのサービスはすべてサーバーのみであるため、拡張キーの用途にはserverAuthを含める必要があります。
Coherence ExtendまたはgRPCクライアントを保護する場合、拡張キーの用途にはclientAuthを含める必要があります。
JDK_HOME/binディレクトリにあるJava keytoolユーティリティにより、SSLアーティファクトが生成および管理されます。これには、キーストアの作成、一意の公開/秘密キー・ペアの生成、公開キーを含む自己署名付きデジタル証明書の作成、証明書の秘密キーへの関連付け、キーストアへのこれらのアーティファクトの格納などが含まれます。
次の例では、server.jksという名前のキーストアが/testディレクトリに作成されます。公開キーと秘密キーのペアは、-dname値("cn=administrator, ou=Coherence, o=Oracle, c=US")によって識別されるエンティティに対して生成されます。公開キーと識別情報を含む自己署名付き証明書が作成されます。この証明書は180日間有効で、別名(admin)が参照するキーストア・エントリの秘密キーと関連付けられています。キーストアと秘密キーの両方にパスワードが必要です。
keytool -genkeypair -keyalg RSA -keysize 2048 -dname "cn=administrator, ou=Coherence, o=Oracle, c=US" -alias admin -keypass password -keystore /test/server.jks -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のドキュメントを参照してください。
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を使用したTCMP通信の保護
この項には次のトピックが含まれます:
SSLを使用したTCMP通信の保護の概要
TCMPでは、一方向と双方向の両方のSSL認証がサポートされています。通常、双方向の認証を使用する方が一方向の認証よりも多く、クラスタ環境では一方向の認証は双方向の認証ほど使用されません。さらに、TCMPではpeer-to-peerプロトコルであることを認識する必要があります。peer-to-peerプロトコルは、通常、多くのクラスタ・ノードを相互に接続したままであることが想定される信頼できる環境で動作します。管理およびパフォーマンスに関するSSLの影響について、慎重に考慮してください。
図6-1は、双方向のSSLを使用するクラスタ・メンバーの概念を示しています。各クラスタ・メンバーには、相互認証で使用されるデジタル証明書を含む信頼キーストアとJavaキーストア(JKS)があります。
SSLソケット・プロバイダの定義
オペレーション・オーバーライド・ファイルで、<unicast-listener>要素内の<socket-provider>要素をオーバーライドして、TCMP用のSSLを構成します。<socket-provider>要素を使用して、<socket-providers>ノード内で定義されたSSLソケット・プロバイダ構成を参照する方法をお薦めします。ただし、<socket-provider>要素は、インラインのSSL構成を含めることもサポートしています。この項では、両方の方法について説明します。Oracle Coherenceでのアプリケーションの開発のsocket-providerを参照してください。
ノート:
TCMPでSSLを使用するには、Well Knownアドレス(WKA)を使用する必要があります。Oracle Coherenceでのアプリケーションの開発のウェル・ノウン・アドレスの使用を参照してください。
例6-1は、SSLの双方向認証の設定を示しています。この設定では、IDストアと信頼キーストアの両方がクラスタ内の各ノードに存在している必要があります。この例では、<protocol>および<algorithm>要素(それぞれTLSおよびSunX509)にデフォルト値を使用しています。これらは完全を期して示しますが、デフォルト値使用の際には省略できます。例では、SSLソケット・プロバイダが<socket-providers>ノード内で定義され、<unicast-listener>要素内から参照される推奨方法を使用しています。
ノート:
この例には、クリア・テキストとして入力されるパスワードが含まれています。パスワードは、パスワード・プロバイダを使用して暗号化できます。「SSLパスワードの暗号化」を参照してください。
例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>
事前定義済SSLソケット・プロバイダの使用方法
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>
ソケット・プロバイダURLの解決
ソケット・プロバイダの構成要素の中にはURLがいくつかあります。たとえば、<key-store>要素の<url>要素です。次に、これらの要素の値がどのように処理されて、参照するリソースが特定されるかについて説明します:
- XML要素の値は、まずJava URIに変換されます。
- 値が有効なURIで、URIスキーム(
file:やhttp:など)がある場合は有効なURIとみなされ、Coherenceでは、このURIへのストリームを開いてデータの読取りが試行されます。 - 値にスキームがない場合、Coherenceでは、ファイル・システムまたはクラス・パス上のファイルとして処理されます。Coherenceでは、まず、値がファイル名(完全修飾または作業ディレクトリに対する相対)であると想定され、そのファイルが検索されます。これが失敗すると、Coherenceでは、クラス・パスのリソースと同じファイルの検索が試行されます。
SSLを使用した拡張クライアント通信の保護
この項には次のトピックが含まれます:
SSLを使用したExtendクライアント通信の保護の概要
SSLは、Extendクライアントと拡張プロキシ間の通信を保護するために使用されます。SSLには、クライアント側とクラスタ側の両方での構成が必要です。SSLは、Javaクライアントと.NETクライアントの両方でサポートされていますが、C++ではサポートされていません(「SSL/TLSを使用したC++クライアントの保護」で説明されているように、追加の構成はありません)。
図6-2は、SSLを使用してクラスタ・プロキシと通信するExtendクライアントの概念を示しています。クライアントとプロキシには、認証に使用されるデジタル証明書を含む信頼キーストアとアイデンティティ・キーストアがあります。Extendクライアントは通常、一方向認証を使用します。一方向認証では、プロキシのみがクライアントを認証し、クライアントはプロキシに対して匿名のままです。
クラスタ側のSSLソケット・プロバイダの構成
クラスタ側のキャッシュ構成ファイルで、プロキシ・サービス用のSSLソケット・プロバイダを定義することで、SSLを構成します。SSLソケット・プロバイダの構成には、必要な粒度レベルに応じて、次の2つのオプションがあります。ソケット・プロバイダはプロキシ・サービスごとにSSLソケット・プロバイダの構成を定義するようにプロキシ・サービスごとに構成されるか、オペレーション構成ファイルに含まれている事前定義済の構成を参照します。2番目のオプションでは、すべてのプロキシ・サービスを構成し、同じグローバルのSSLソケット・プロバイダの構成を使用します。独自の構成を提供するプロキシ・サービスは、グローバル構成をオーバーライドします。グローバル構成では、オペレーション構成ファイルに含まれている事前定義済の構成を参照することもできます。
この項には次のトピックが含まれます:
プロキシ・サービスごとのSSLソケット・プロバイダの構成
プロキシ・サービス用にSSLソケット・プロバイダを構成するには、各<proxy-scheme>定義の<tcp-acceptor>要素内に<socket-provider>要素を追加します。Oracle Coherenceでのアプリケーションの開発のsocket-providerを参照してください。
例6-3は、<protocol>要素および<algorithm>要素にデフォルト値(それぞれ、TLSおよびSunX509)を使用するSSLソケット・プロバイダを構成するプロキシ・スキームを示しています。これらは完全を期して示しますが、デフォルト値使用の際には省略できます。
例6-3では、アイデンティティ・キーストア(server.jks)と信頼キーストア(trust.jks)の両方を構成します。これは典型的な双方向SSL認証であり、クライアントとプロキシの双方が、デジタル証明書を交換し、互いのIDを確認する必要があります。一方向SSL認証の場合は、プロキシ・サーバーの構成にアイデンティティ・キーストアを含める必要がありますが、信頼キーストアは含める必要がありません。
ノート:
-
プロキシ・サーバーに信頼マネージャが構成されている場合は、プロキシでデジタル証明書が交換される可能性があるため、クライアントでは双方向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-provider>
<class-name>com.oracle.coherence.guides.ssl.CustomPasswordProvider</class-name>
<init-params>
<init-param>
<param-name>type</param-name>
<param-value>identity-keystore</param-value>
</init-param>
</init-params>
</password-provider>
<type>JKS</type>
</key-store>
<password-provider>
<class-name>com.oracle.coherence.guides.ssl.CustomPasswordProvider</class-name>
<init-params>
<init-param>
<param-name>type</param-name>
<param-value>identity-key</param-value>
</init-param>
</init-params>
</password-provider>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password-provider>
<class-name>com.oracle.coherence.guides.ssl.CustomPasswordProvider</class-name>
<init-params>
<init-param>
<param-name>type</param-name>
<param-value>trust-keystore</param-value>
</init-param>
</init-params>
</password-provider>
<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)を指定することによって参照します。『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ソケット・プロバイダの構成
すべてのプロキシ・サービスで使用するグローバルなSSLソケット・プロバイダを構成するには、キャッシュ構成ファイルの<defaults>要素内にある<socket-provider>要素を使用します。この方法を使用すると、プロキシ・スキーム定義内での追加の構成は不要です。『Oracle Coherenceでのアプリケーションの開発』のdefaultsに関する項を参照してください。
次の例では、例6-3と同じ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">
<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>
Javaクライアント側のSSLソケット・プロバイダの構成
クライアント側のキャッシュ構成ファイルで、リモート・キャッシュ・スキーム用、また必要に応じてリモート起動スキーム用のSSLソケット・プロバイダを定義することで、SSLを構成します。SSLソケット・プロバイダの構成には、必要な粒度レベルに応じて、次の2つのオプションがあります。ソケット・プロバイダはリモート・サービスごとにSSLソケット・プロバイダの構成を定義するようにリモート・サービスごとに構成されるか、オペレーション構成ファイルに含まれている事前定義済の構成を参照します。2番目のオプションでは、すべてのリモート・サービスを構成し、同じグローバルのSSLソケット・プロバイダの構成を使用します。独自の構成を提供するリモート・サービスは、グローバル構成をオーバーライドします。グローバル構成では、オペレーション構成ファイルに含まれている事前定義済の構成を参照することもできます。
この項には次のトピックが含まれます:
リモート・サービスごとのSSLソケット・プロバイダの構成
リモート・サービス用にSSLソケット・プロバイダを構成するには、リモート・スキームの定義の<tcp-initiator>要素内に<socket-provider>要素を追加します。Oracle Coherenceでのアプリケーションの開発のsocket-providerを参照してください。
例6-4は、SSLを使用するソケット・プロバイダを構成するリモート・キャッシュ・スキームを示しています。この例では、<protocol>要素および<algorithm>要素にデフォルト値(それぞれ、TLSおよびSunX509)を使用しています。これらは完全を期して示しますが、デフォルト値使用の際には省略できます。
例6-4では、アイデンティティ・キーストア(server.jks)と信頼キーストア(trust.jks)の両方を構成します。これは典型的な双方向SSL認証であり、クライアントとプロキシの双方が、デジタル証明書を交換し、互いのIDを確認する必要があります。一方向SSL認証の場合は、クライアントの構成に信頼キーストアを含める必要がありますが、アイデンティティ・キーストアは含める必要がありません。つまり、クライアントは、プロキシに対してデジタル証明書を渡すことはなく、匿名のままということです。クライアントの信頼キーストアには、プロキシのデジタル証明書への署名に使用されたCAのデジタル証明書が含まれている必要があります。
ノート:
-
プロキシ・サーバーに信頼マネージャが構成されている場合は、プロキシでデジタル証明書が交換される可能性があるため、クライアントでは双方向SSL認証を使用する必要があります。一方向の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)を指定することによって参照します。『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ソケット・プロバイダの構成
すべてのリモート・サービスで使用するグローバルなSSLソケット・プロバイダを構成するには、キャッシュ構成ファイルの<defaults>要素内にある<socket-provider>要素を使用します。この方法を使用すると、リモート・スキーム定義内での追加の構成は不要です。『Oracle Coherenceでのアプリケーションの開発』のdefaultsに関する項を参照してください。
次の例では、例6-4と同じ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">
<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クライアント側のストリーム・プロバイダの構成
.NETクライアント側のキャッシュ構成ファイルで、リモート・サービス用のSSLストリーム・プロバイダを定義することで、SSLを構成します。SSLストリーム・プロバイダは、<tcp-initiator>要素内の<stream-provider>要素を使用して定義します。
ノート:
証明書は、Windowサーバーでは、オペレーティング・システム・レベルで証明書マネージャを使用して管理します。サンプルの構成は、証明書マネージャに拡張プロキシの証明書およびプロキシの証明書に署名した信頼できるCAの証明書が含まれていることを前提としています。「Windows SSLアーティファクトの生成」を参照してください。
例6-5は、SSLストリーム・プロバイダを構成するリモート・キャッシュ・スキームを示しています。SSLストリーム・プロバイダの構成に使用する要素の詳細は、キャッシュ構成XMLスキーマ(INSTALL_DIR\config\cache-config.xsd)を参照してください。
ノート:
<protocol>要素は、使用可能なSslProtocols列挙値およびプロトコル値のカンマ区切りリストをサポートします。たとえば:
<protocol>Tls11,Tls12</protocol>プロトコルが、クライアント側とサーバー側の両方の構成で指定されていることを確認してください。
例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>Tls12</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/TLSを使用したC++クライアントの保護
Coherence C++ Extendクライアントは、SSL/TLSを正式にサポートしていません。ただし、次のオプションのいずれかを使用して、この制限を回避し、SSL/TLSが有効なCoherenceプロキシ・サーバーに対してC++ Extendクライアントを安全に実行できます。
ロード・バランサを使用したC++クライアントの保護
F5などのロード・バランサは、C++クライアントのかわりに暗号化を実行し、ロード・バランサの背後にあるSSL/TLSプロキシ・サーバーと通信するように構成できます。データ保護を提供するようにロード・バランサ・サービスを構成する方法の詳細は、そのドキュメントを参照してください。
SSHトンネリングを使用したC++クライアントの保護
SSHトンネリングが有効な場合、C++クライアントはSSHクライアントがリスニングするローカルホスト上のポートに接続します。次に、SSHクライアントは、暗号化されたトンネルを介してリクエストをサーバーに転送します。サーバーは、SSL/TLSが有効なCoherenceプロキシ・サーバー(通常はSSHサーバーと同じマシン上または同じデータ・センター内)に接続します。SSHトンネルの構成方法の例を簡単に見つけることができます。Coherenceプロキシ・サーバーは、SSHサーバーの背後にあります。
クラウドでのC++クライアントの保護
Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)などのクラウド環境にいる場合は、Coherence SSL/TLSプロキシ・サーバーと通信するためのSSL/TLSプロキシとして機能するように、C++クライアントと同じポッドにNGINXコンテナを構成できます。Istioサイドカー・プロキシまたはエグレス・ゲートウェイを使用して、C++クライアントのかわりに暗号化を実行することもできます。アップストリーム・サーバーへのデータを保護する手順については、クラウド環境の対応するドキュメントを参照してください。
SSLを使用したフェデレーション通信の保護
Oracle Coherenceでは、フェデレーションのクラスタ参加者間の通信を保護するようにSSLがサポートされています。フェデレーテッドサービス・メンバー間で通信が保護され、SSLセキュリティを必要とする各クラスタ参加者でSSL構成が必要です。
SSLを使用してフェデレーション通信を保護するには:
たとえば:
<federated-scheme>
<scheme-name>federated</scheme-name>
<service-name>federated</service-name>
<backing-map-scheme>
<local-scheme />
</backing-map-scheme>
<autostart>true</autostart>
<socket-provider>mySSLConfig</socket-provider>
<topologies>
<topology>
<name>MyTopology</name>
</topology>
</topologies>
</federated-scheme>
SSLパスワードの暗号化
オペレーション・オーバーライド・ファイルにパスワードをクリア・テキストとして入力することは、簡単な開発およびテストのシナリオ以外にはお薦めしません。公開されたパスワードはセキュリティ上のリスクであり、機密データへの不要なアクセスを引き起こす可能性があります。
Coherenceには、ハードコードされたパスワードを使わない2つの方法があります:
URLからのパスワードの読取り
ファイル・システム上のファイルなど、URLからパスワードをロードするには、<password>要素のかわりに<password-URL>要素を使用します。
例6-6は、ファイル・システム上のファイルからキーストアおよび秘密キーのパスワードを読み取るSSLソケット・プロバイダ構成を示しています。
このXML例では、アイデンティティ・マネージャのキーストア・パスワードが/coherence/security/server-pass.txtファイルから読み取られます。アイデンティティ・マネージャによって使用される秘密キーは、/coherence/security/key-pass.txtファイルから読み取られます。信頼マネージャによって使用されるキーストア・パスワードは、/coherence/security/trust-pass.txtファイルから読み取られます。
例6-6 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>
<socket-providers>
<socket-provider id="mySSLConfig">
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password-url>file:/coherence/security/server-pass.txt</password-url>
<type>JKS</type>
</key-store>
<password-url>file:/coherence/security/key-pass.txt</password-url>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password-url>file:/coherence/security/trust-pass.txt</password-url>
<type>JKS</type>
</key-store>
</trust-manager>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
</socket-providers>
</cluster-config>
</coherence>デフォルトでは、<password-URL>構成は、URLからパスワードとして返されたすべてのデータを使用します。この動作を、パスワードとして返されたデータの最初の行のみを使用するように変更する場合は、<password-url>要素のfirst-line-only属性をtrueに設定します。
/secret.txtにパスワードとその後の行に追加データが含まれている場合は、次に示すように<password-url>要素を構成できます:<password-url first-line-only="true">file:/secret.txt</password-url>カスタム・パスワード・プロバイダの使用
パスワード・プロバイダを使用すると、暗号化の使用を含め、任意のソースからSSLパスワードを取得できます。
パスワード・プロバイダは、com.tangosol.net.PasswordProviderインタフェースを実装します。このクラスには、SSL構成で使用するパスワードを返すgetメソッドがあります。独自のパスワード・プロバイダを作成することも、事前定義済のcom.tangosol.coherence.config.xml.processor.PasswordProviderBuilderProcessor$DefaultPasswordProviderクラスを使用することもできます。事前定義されたパスワード・プロバイダは、string型のパスワードを取得し、char[]型のパスワードを返します。
オペレーション・オーバーライド・ファイルでパスワード・プロバイダを定義するには、<cluster-config>要素内の<password-providers>要素をオーバーライドします。SSL構成の<password-provider>要素を使用して、<password-providers>ノード内で定義されているパスワード・プロバイダを参照する方法をお薦めします。ただし、SSLソケット・プロバイダのパスワードを構成するときに、<password-provider>要素をインラインで定義することもできます。この項では、両方の方法について説明します。『Oracle Coherenceでのアプリケーションの開発』のpassword-providerに関する項を参照してください。
例6-7は、MyPasswordProviderという名前で<password-providers>要素内で定義されているパスワード・プロバイダを参照するSSLソケット・プロバイダ構成を示しています。パスワード・プロバイダは、アイデンティティ・マネージャのプライベート・キーとそのキーストアおよび信頼マネージャ・キーストアへのアクセスに使用されます。
例6-7 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>
<socket-providers>
<socket-provider id="mySSLConfig">
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password-provider>
<name>MyPasswordProvider</name>
<init-params>
<init-param>
<param-name>param_1</param-name>
<param-value>private</param-value>
</init-param>
</init-params>
</password-provider>
<type>JKS</type>
</key-store>
<password-provider>
<name>MyPasswordProvider</name>
<init-params>
<init-param>
<param-name>param_1</param-name>
<param-value>private</param-value>
</init-param>
</init-params>
</password-provider>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password-provider>
<name>MyPasswordProvider</name>
<init-params>
<init-param>
<param-name>param_1</param-name>
<param-value>private</param-value>
</init-param>
</init-params>
</password-provider>
<type>JKS</type>
</key-store>
</trust-manager>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
</socket-providers>
<password-providers>
<password-provider id="MyPasswordProvider">
<class-name>package.MyPasswordProvider</class-name>
<init-params>
<init-param>
<param-name>param_1</param-name>
<param-value>password</param-value>
</init-param>
</init-params>
</password-provider>
<password-providers>
</cluster-config>
</coherence>例6-8は、SSLソケット・プロバイダ構成内にパスワード・プロバイダをインラインで定義する代替方法を示しています。
例6-8 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>
<socket-providers>
<socket-provider id="mySSLConfig">
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password-provider>
<class-name>package.MyPasswordProvider</class-name>
<init-params>
<init-param>
<param-name>param_1</param-name>
<param-value>password</param-value>
</init-param>
</init-params>
</password-provider>
<type>JKS</type>
</key-store>
<password-provider>
<class-name>package.MyPasswordProvider</class-name>
<init-params>
<init-param>
<param-name>param_1</param-name>
<param-value>password</param-value>
</init-param>
</init-params>
</password-provider>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password-provider>
<class-name>package.MyPasswordProvider</class-name>
<init-params>
<init-param>
<param-name>param_1</param-name>
<param-value>password</param-value>
</init-param>
</init-params>
</password-provider>
<type>JKS</type>
</key-store>
</trust-manager>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
</socket-providers>
</cluster-config>
</coherence>暗号スイートとプロトコル・バージョンの使用の制御
<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>
ホスト名検証の使い方
ホスト名検証は、SSLクライアント(SSLクライアントとして機能しているCoherenceなど)がリモート・ホスト上のキャッシュ・サーバーに接続する場合に役立ちます。また、中間者攻撃を防ぐのに役立ちます。
Coherenceにはデフォルトのホスト名検証機能があります。また、カスタム・ホスト名検証を作成して使用することもできます。
この章の内容は次のとおりです。
デフォルトのCoherenceホスト名検証の使用
デフォルトのCoherenceホスト名検証を使用する場合、証明書のホスト名がクライアントが接続しようとするホスト名と一致すると、ホスト名検証は合格します。
- ワイルドカードを使用した検証。
- ワイルドカードを使用しない検証(ワイルドカードを使用した検証が失敗した場合)。
デフォルトでは、ホスト名検証は下位互換性のために有効になっていません。デフォルトのホスト名検証を有効にするには、sslの<hostname-verifier>要素の説明を参照してください。
ワイルドカードを使用した検証
- ドット('.')文字を2文字以上使用します。
- "*"で始める必要があります。
- "*"文字は1つのみ使用できます。
また、大/小文字を区別する文字列比較で、CommonName属性のワイルドカードを使用しない部分はurlhostnameパラメータのドメイン部分と同じである必要があります。urlhostname文字列のドメイン部分は、hostname部分文字列を除いた後に残るurlhostname部分文字列です。urlhostnameのhostname部分は、urlhostnameパラメータ文字列の最初の'.'(ドット)までの部分文字列です(ドットは含みません)。
たとえば:
urlhostname: mymachine.oracle.com
CommonName: *.oracle.com
.oracle.comと.oracle.comの比較は成功となります。
urlhostname: mymachine.uk.oracle.com
CommonName: *.oracle.com
.uk.oracle.comと.oracle.comの比較は成功となりません
サーバー証明書のSubjectAlternativeNames拡張から取得されたDNSNamesには、ワイルドカードを使用できます。
ワイルドカードを使用しない検証
ワイルドカードを使用したホスト名検証が失敗した場合、デフォルトのホスト名検証はワイルドカードを使用しない検証を実行します。サーバー証明書のSubjectDNのCommonName属性またはサーバー証明書のSubjectAlternativeNames拡張のDNSNamesを、クライアントURLのホスト名(urlhostname)と照合して検証します。certificate属性は、urlhostnameパラメータと一致する(大/小文字を区別しない)必要があります。SubjectDN CommonName属性が最初に検証され、成功した場合、SubjectAlternativeNames属性は検証されません。
サーバー証明書にSubjectDNがない場合、またはSubjectDNにCommonName属性がない場合は、DNSNamesタイプのSubjectAlternativeName属性がurlhostnameパラメータと比較されます。検証は、DNSNameとの比較で最初に成功した時点で合格です。検証を成功させるには、urlhostnameが比較対象のcertificate属性と等しい必要があります。
urlhostnameがlocalhostの場合、coherence.security.ssl.allowLocalhostシステム・プロパティをtrueに設定すると、127.0.0.1またはローカル・マシンのデフォルトのIPアドレスは合格します。
カスタム・ホスト名検証の使用
カスタム・ホスト名検証を使用する場合は、カスタム・ホスト名検証を実装するクラスを、Coherence (SSLクライアントとして機能する場合)またはスタンドアロンのSSLクライアントのCLASSPATHに指定する必要があります。
カスタム・ホスト名検証の使用の詳細は、sslの<hostname-verifier>要素の説明を参照してください。
秘密キーおよび証明書ファイルの使用
ノート:
デフォルトでは、CoherenceはJDKでサポートされているファイル形式のみをサポートしています。これらは、PEM形式の秘密キー・ファイル(ヘッダーが-----BEGIN RSA PRIVATE KEY-----または-----BEGIN ENCRYPTED PRIVATE KEY-----のファイル)およびX509証明書ファイル(ヘッダーが-----BEGIN CERTIFICATE-----のファイル)です。カスタム・ローダーを使用して別の形式を読み取ることができます。「カスタム・キーストア、秘密キーおよび証明書ローダーの使用」を参照してください。
アイデンティティ・マネージャの構成
ソケット・プロバイダの<identity-manager>要素を構成するときに、<keystore>要素のかわりに<key>要素と<cert>要素を使用して、秘密キーに証明書ファイルの場所を指定できます。<key>要素と<cert>要素両方の値はURLで、ここからキーまたは証明書データがロードされます。
例6-9は、/coherence/security/client.pemファイルからロードされた秘密キーと/coherence/security/client.certファイルからロードされた証明書を使用する<identity-manager>構成を示しています。
例6-9 秘密キーおよび証明書ファイルを使用するアイデンティティ・マネージャの例
<socket-provider>
<ssl>
<identity-manager>
<key>file:/coherence/security/client.pem</key>
<cert>file:/coherence/security/client.cert</cert>
</identity-manager>
</ssl>
</socket-provider><identity-manager>要素を構成するとき、<keystore>要素、および<key>要素と<cert>要素は、キーストアを構成するか、キーと証明書を構成するため、相互に排他的です。Coherenceオペレーション構成のXSD検証では、両方は許可されません。
信頼マネージャの構成
ソケット・プロバイダの<trust-manager>要素を構成するときに、<keystore>要素のかわりに1つ以上の<cert>要素を使用して、証明書ファイルの場所を指定できます。<cert>要素の値は、証明書データのロード元となるURLです。
例6-10は、/coherence/security/server-ca.certファイルからロードされた証明書を使用する<trust-manager>構成を示しています。
例6-10 証明書ファイルを使用する信頼マネージャの例
<socket-provider>
<ssl>
<trust-manager>
<cert>file:/coherence/security/server-ca.cert</cert>
</trust-manager>
</ssl>
</socket-provider><trust-manager>要素を構成するとき、<keystore>要素および<cert>要素は、キーストアを構成するか、1つ以上の証明書を構成するため、相互に排他的です。Coherenceオペレーション構成のXSD検証では、両方は許可されません。
カスタム・キーストア、秘密キーおよび証明書ローダーの使用
この項には次のトピックが含まれます:
カスタム・キーストア・ローダーの使用
Javaキーストアを使用している場合は、アプリケーション・コードにcom.tangosol.net.ssl.KeyStoreLoaderのインスタンスを実装し、<key-store>要素の子である<key-store-loader>要素内でそれを構成できます。このクラスは、必要な場所からJavaキーストアのコンテンツをロードできます。
例6-11は、KeyStoreLoaderインタフェースのカスタム実装を示しています。
例6-11 カスタム・キーストア・ローダー・クラス
package com.acme.coherence;
import com.tangosol.net.ssl.KeyStoreLoader;
import java.io.IOException;
import java.security.GeneralSecurityException;
import java.security.KeyStore;
public class CustomKeyStoreLoader
implements KeyStoreLoader
{
@Override
public KeyStore load(String sType, PasswordProvider password)
throws GeneralSecurityException, IOException
{
// return a KeyStore of the required type
}
}例6-12は、<identity-manager>構成でCustomKeyStoreLoaderクラスを使用する方法を示しています。
例6-12 カスタム・キーストア・ローダー・クラスを使用したアイデンティティ・マネージャの構成
<socket-provider>
<ssl>
<identity-manager>
<key-store>
<key-store-loader>
<class-name>com.acme.coherence.CustomKeyStoreLoader</class-name>
</key-store-loader>
</key-store>
</identity-manager>
</ssl>
</socket-provider>例6-13は、<trust-manager>構成でCustomKeyStoreLoaderクラスを使用する方法を示しています。
例6-13 カスタム・キーストア・ローダー・クラスを使用した信頼マネージャの構成
<socket-provider>
<ssl>
<trust-manager>
<key-store>
<key-store-loader>
<class-name>com.acme.coherence.CustomKeyStoreLoader</class-name>
</key-store-loader>
</key-store>
</trust-manager>
</ssl>
</socket-provider>Coherenceの他の拡張ポイントと同様に、<key-store-loader>は、class-nameまたはclass-factory-nameとmethod-nameパラメータをとるインスタンス構成です。オプションで、<init-params>を使用して、classコンストラクタまたはfactoryメソッドにパラメータを渡す構成にすることもできます。
例6-14は、CustomKeyStoreLoaderクラスをリファクタしてコンストラクタ引数を追加する方法を示しています。
例6-14 パラメータを使用したカスタム・キーストア・ローダー
package com.acme.coherence;
import com.tangosol.net.ssl.KeyStoreLoader;
import java.io.IOException;
import java.security.GeneralSecurityException;
import java.security.KeyStore;
public class CustomKeyStoreLoader
implements KeyStoreLoader
{
private final String param1;
private final String param2;
public CustomKeyStoreLoader(String param1, String param2)
{
this.param1 = param1;
this.param2 = param2;
}
@Override
public KeyStore load(String sType, PasswordProvider password)
throws GeneralSecurityException, IOException
{
// return a KeyStore of the required type
}
}例6-15は、パラメータ化されたCustomKeyStoreLoaderクラスを構成する方法を示しています。構成の例では、パラメータfooおよびbarを使用してCustomKeyStoreLoaderコンストラクタがコールされます。
例6-15 パラメータを使用したカスタム・キーストア・ローダーの構成
<socket-provider>
<ssl>
<identity-manager>
<key-store>
<key-store-loader>
<class-name>com.acme.coherence.CustomKeyStoreLoader</class-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value>foo</param-value>
</init-param>
<init-param>
<param-type>string</param-type>
<param-value>bar</param-value>
</init-param>
</init-params>
</key-store-loader>
</key-store>
</trust-manager>
</ssl>
</socket-provider>実行時に、CustomKeyStoreLoaderクラスのloadメソッドがコールされて、キーストアがロードされます。前述の構成では、loadメソッドに渡されるtypeパラメータは、デフォルトのキーストア・タイプ(JKS)です。loadメソッドに渡されるPasswordProviderは、空のパスワードを返すデフォルトのnull実装です。
例6-16は、カスタムKeyStoreLoader.loadにパラメータとして渡されるキーストア・タイプおよびパスワードを構成する方法を示しています。この例は<password>要素の使用を示していますが、<password-url>要素または<password-provider>要素を使用してローダーにパスワードを渡すこともできます。
例6-16 キーストア・タイプおよびパスワードをカスタム・キーストア・ローダーに渡す
<socket-provider>
<ssl>
<identity-manager>
<key-store>
<key-store-loader>
<class-name>com.acme.coherence.CustomKeyStoreLoader</class-name>
</key-store-loader>
<password>secret</password>
<type>PKCS12</type>
</key-store>
</identity-manager>
</ssl>
</socket-provider>カスタム秘密キー・ローダーの使用
キーストアのかわりに秘密キーを使用している場合は、アプリケーション・コードにcom.tangosol.net.ssl.PrivateKeyLoaderのインスタンスを実装し、<key-loader>要素内でそれを構成できます。これにより、カスタム・ローダーは必要な場所から必要な形式でPrivateKeyをロードできます。
Coherenceの他の拡張ポイントと同様に、<key-loader>は、class-nameまたはclass-factory-nameとmethod-nameパラメータをとるインスタンス構成です。オプションで、<init-params>を使用して、classコンストラクタまたはfactoryメソッドにパラメータを渡す構成にすることもできます。
例6-17は、カスタムPrivateKeyLoaderクラスを示しています。
例6-17 カスタム秘密キー・ローダー
package com.acme.coherence;
import com.tangosol.net.PasswordProvider;
import com.tangosol.net.ssl.PrivateKeyLoader;
import java.io.IOException;
import java.security.GeneralSecurityException;
import java.security.KeyStore;
public class CustomPrivateKeyLoader
implements PrivateKeyLoader
{
@Override
public PrivateKey load(PasswordProvider password)
throws GeneralSecurityException, IOException
{
// return a PrivateKey (optionally encrypted with a password)
}
}例6-18は、<identity-manager>要素でCustomPrivateKeyLoaderクラスを構成する方法を示しています。
例6-18 カスタム秘密キー・ローダーの構成
<socket-provider>
<ssl>
<identity-manager>
<key-loader>
<class-name>com.acme.coherence.CustomPrivateKeyLoader</class-name>
</key-loader>
</identity-manager>
</ssl>
</socket-provider>実行時に、CustomPrivateKeyLoaderクラスのloadメソッドがコールされて、PrivateKeyインスタンスが作成されます。前述の例では、キーにパスワードが構成されていないため、loadメソッドに渡されるPasswordProviderは空のパスワード(new char[0])を返します。<identity-manager>要素で許可されているパスワード要素のいずれかを使用して、パスワードを追加できます。
例6-19は、パスワードを使用した構成を示しています。この例では、PasswordProviderはURL file: /coherence/security/key-pass.txtからフェッチされたコンテンツをキー・パスワードとして返します。
例6-19 カスタム秘密キー・ローダーのパスワードの構成
<socket-provider>
<ssl>
<identity-manager>
<key-loader>
<class-name>com.acme.coherence.CustomPrivateKeyLoader</class-name>
</key-loader>
<password-url>file:/coherence/security/key-pass.txt</password-url>
</identity-manager>
</ssl>
</socket-provider>カスタム証明書ローダーの使用
アイデンティティ・マネージャまたは信頼マネージャで証明書ファイルを使用している場合は、アプリケーション・コードにcom.tangosol.net.ssl.CertificateLoaderのインスタンスを実装し、<cert-loader>要素内でそれを構成できます。このクラスは、必要な場所から必要な形式でCertificateインスタンスの配列をロードできます。
Coherenceの他の拡張ポイントと同様に、<cert-loader>は、class-nameまたはclass-factory-nameとmethod-nameパラメータをとるインスタンス構成です。オプションで、<init-params>を使用して、classコンストラクタまたはfactoryメソッドにパラメータを渡す構成にすることもできます。
例6-20は、カスタムCertificateLoaderクラスの例を示しています。証明書をロードするためにloadメソッドがコールされます。
例6-20 カスタム証明書ローダー
package com.acme.coherence;
public class CustomCertificateLoader
implements CertificateLoader
{
@Override
public Certificate[] load()
throws GeneralSecurityException, IOException
{
// return a Certificate array
}
}例6-21は、アイデンティティ・マネージャでCustomCertificateLoaderクラスを構成する方法を示しています。
例6-21 アイデンティティ・マネージャでのカスタム証明書ローダーの構成
<socket-provider>
<ssl>
<identity-manager>
<key>server.pem</key>
<cert-loader>
<class-name>com.acme.coherence.CustomCertificateLoader</class-name>
</cert-loader>
</identity-manager>
</ssl>
</socket-provider>例6-22は、信頼マネージャでCustomCertificateLoaderクラスを構成する方法を示しています。
例6-22 信頼マネージャでのカスタム証明書ローダーの構成
<socket-provider>
<ssl>
<trust-manager>
<cert-loader>
<class-name>com.acme.coherence.CustomCertificateLoader</class-name>
</cert-loader>
</trust-manager>
</ssl>
</socket-provider>CertificateLoaderクラスのload()メソッドは、複数の証明書をロードできるように、証明書の配列を返します。また、複数のカスタム・ローダーを使用するように複数の<cert-loader>要素を構成することもできます。すべての<cert>要素または<cert-loader>要素によって提供されたすべての証明書が結合されて、SSLコンテキストで使用される1つの証明書セットになります。
例6-23は、信頼マネージャで複数の<cert>ローダーおよびカスタム・ローダーを構成する方法を示しています。
例6-23 信頼マネージャでの複数の証明書およびローダーの構成
<socket-provider>
<ssl>
<trust-manager>
<cert>server-ca.cert</cert>
<cert-loader>
<class-name>com.acme.coherence.CustomCertificateLoader</class-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value>foo</param-value>
</init-param>
</init-params>
</cert-loader>
<cert-loader>
<class-name>com.acme.coherence.CustomCertificateLoader</class-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value>bar</param-value>
</init-param>
</init-params>
</cert-loader>
</trust-manager>
</ssl>
</socket-provider>リフレッシュ可能なキーストア、秘密キーおよび証明書の使用
リフレッシュ時間の構成には、<refresh-period>要素が使用されます。これはssl要素の子要素です。つまり、この設定はアイデンティティ・マネージャと信頼マネージャの両方に適用されます。
例6-24では、キーおよび証明書が24時間ごとにリフレッシュされるように、<refresh-period>要素を値24hで構成しています。
例6-24 リフレッシュ期間の構成
<socket-provider>
<ssl>
<identity-manager>
<key>server.pem</key>
<cert>server.cert</cert>
</identity-manager>
<refresh-period>24h</refresh-period>
</ssl>
</socket-provider>必要なSSLアーティファクトの新しいバージョンを外部ソースからプルできるように、リフレッシュ可能なキーストア、キーおよび証明書を、カスタム・キーストア・ローダー、秘密キー・ローダーおよび証明書ローダーと簡単に組み合せることができます。
リフレッシュ・ポリシーの構成
リフレッシュ可能なキーおよび証明書を使用している場合、リフレッシュを行う必要があるかどうか判断するための追加のチェックを行うと役立つことがあります。このチェックを実行するには、<refresh-policy>および<refresh-period>を構成します。
<refresh-policy>要素は標準のCoherenceインスタンス構成であるため、com.tangosol.net.ssl.RefreshPolicyのインスタンスに解決する必要があります。スケジュールされたリフレッシュ時間に達すると、リフレッシュを先に進めるかどうかを決定するために、まず(RefreshPolicy.shouldRefresh()メソッドをコールして)ポリシーがチェックされます。
例6-25は、カスタムRefreshPolicy実装を示しています。
例6-25 カスタム・リフレッシュ・ポリシー・クラス
package com.acme.coherence;
public class CustomRefreshPolicy
implements RefreshPolicy
{
@Override
public boolean shouldRefresh(Dependencies deps, ManagerDependencies depsIdMgr, ManagerDependencies depsTrustMgr)
{
// perform some custom logic to determine whether it is time to refresh
return true;
}
}例6-26は、<refresh-period>とともに<ssl>要素の一部としてカスタム・リフレッシュ・ポリシーを構成する方法を示しています。
例6-26 カスタム・リフレッシュ・ポリシーの構成
<socket-provider>
<ssl>
<identity-manager>
<key>server.pem</key>
<cert>server.cert</cert>
</identity-manager>
<refresh-period>24h</refresh-period>
<refresh-policy>
<class-name>com.acme.coherence.CustomRefreshPolicy</class-name>
</refresh-policy>
</ssl>
</socket-provider>一部のポリシーでは、リフレッシュする必要があるかどうかを判断するために、現在どのキーストア、キーまたは証明書が使用されているかを把握しておくと役立ちます。RefreshPolicyには、この目的でオーバーライドできる多くのデフォルト・メソッドがあります。
例6-27は、トラスト・ストア構成で使用される証明書を取得してから、証明書を使用して失効が近いかどうかを確認する方法を示しています。この例では、トラスト・ストアが作成されるときにtrustStoreLoadedメソッドがコールされ、トラスト・ストアで使用される証明書がポリシーに通知されます。次に、shouldRefreshメソッドで証明書をチェックして、次のリフレッシュ間隔でもまだ有効かどうかを判断できます。
例6-27 詳細なカスタム証明書リフレッシュ・ポリシー
import com.oracle.coherence.common.net.SSLSocketProvider.Dependencies;
import com.oracle.coherence.common.util.Duration;
import com.tangosol.coherence.config.builder.SSLSocketProviderDependenciesBuilder.ManagerDependencies;
import com.tangosol.coherence.config.unit.Seconds;
import com.tangosol.net.ssl.RefreshPolicy;
import java.security.cert.Certificate;
import java.security.cert.CertificateExpiredException;
import java.security.cert.CertificateNotYetValidException;
import java.security.cert.X509Certificate;
import java.util.Date;
public class CustomRefreshPolicy
implements RefreshPolicy
{
private Certificate[] certs;
@Override
public void trustStoreLoaded(Certificate[] certs)
{
this.certs = certs;
}
@Override
public boolean shouldRefresh(Dependencies deps, ManagerDependencies depsIdMgr, ManagerDependencies depsTrustMgr)
{
if (certs == null)
{
return true;
}
// get the refresh period from the dependencies
Seconds secs = deps.getRefreshPeriod();
// calculate the next refresh time as a Date
Date nextRefresh = new Date(System.currentTimeMillis() + secs.as(Duration.Magnitude.MILLI));
for (Certificate certificate : certs)
{
try
{
// The certs are all X509 certs, so check their validity on the next refresh date
((X509Certificate) certificate).checkValidity(nextRefresh);
}
catch (CertificateExpiredException | CertificateNotYetValidException e)
{
// a cert will have expired, so we need to update now
return true;
}
}
// no certs should have expired at the next refresh check
return false;
}
}例6-28は、<ssl>構成でCustomRefreshPolicyクラスを構成する方法を示しています。
例6-28 カスタム証明書リフレッシュ・ポリシーの構成
<socket-provider>
<ssl>
<trust-manager>
<ca-cert>server-ca.cert</ca-cert>
<ca-cert>client-ca.cert</ca-cert>
</trust-manager>
<refresh-period>24h</refresh-period>
<refresh-policy>
<class-name>com.acme.coherence.CustomRefreshPolicy</class-name>
</refresh-policy>
</ssl>
</socket-provider>