SSL/TLSを使用した通信の保護

6 SSL/TLSを使用した通信の保護

Oracle Coherenceでは、Transport Layer Security (TLS)プロトコルを使用して、ネットワークを介したエンティティ(通常はクライアントとサーバー)間の通信を保護できます。TLSは、現在では非推奨となっているSecure Sockets Layer (SSL)プロトコルの代わりとなるものです。

Coherenceでは、TLSはソケット・プロバイダを使用して構成され、特定のセキュリティ・シナリオに合せて変更できます。これらの構成オプションの例については、この章で説明します。

ノート:

TLS、SSLおよびSSL/TLSという用語はCoherenceドキュメント全体で同じ意味で使用されていますが、Coherenceでの通信を保護するために、SSLではなく、現在サポートされているバージョンのTLSを使用することをお薦めします。

この章の内容は次のとおりです。

SSL/TLSの概要
SSL/TLSは、ネットワーク上のエンティティ(通常はクライアントとサーバー)間の通信を保護するセキュリティ・プロトコルです。SSL/TLSは、クライアントとサーバーをデジタル証明書を使用して認証し、認証済のクライアントとサーバーに関連付けられた一意のキーを使用して通信を暗号化および復号化することにより機能しています。
Coherenceソケット・プロバイダ
Coherence通信は、ソケット・プロバイダを使用して構成されます。オペレーション構成ファイルの<socket-providers>セクションには、名前付き<socket-provider>要素が0個以上含まれています。
ソケット・プロバイダURLの解決
ソケット・プロバイダの構成の一部の要素はURLです。たとえば、<key-store>要素内の<url>要素です。
構成でのソケット・プロバイダの使用
<socket-provider>を使用して、Coherence構成ファイル内の様々な場所を構成できます。<socket-provider>は、オペレーション構成ファイル内の名前付きソケット・プロバイダへの名前付き参照、またはインライン・ソケット・プロバイダ構成のいずれかの2つの方法で構成できます。
SSLを使用したクラスタ通信の保護
Coherenceクラスタでは、すべてのクラスタ・メンバーが、ピアツーピア・ネットワークでTCPを介して相互に通信します。各JVMは、他のクラスタ・メンバーから接続を受信するサーバーと、他のクラスタ・メンバーに接続するクライアントの両方です。
SSLを使用したExtendおよびgRPCクライアント通信の保護
Oracle Coherenceでは、Coherence ExtendおよびgRPCクライアントとクラスタ側のExtendまたはgRPCプロキシの間の通信を保護するためにSSLがサポートされています。
キャッシュ構成ファイルのデフォルト・ソケット・プロバイダの構成
ソケット・プロバイダは、キャッシュ構成ファイルの<defaults>セクションで構成できます。このソケット・プロバイダは、リモート・キャッシュ・サービス、リモート呼出しサービス、プロキシ・サービス、gRPCサービスなど、独自のソケット・プロバイダを具体的に構成しない、その構成ファイル内のすべてのスキームに適用されます。
.NETクライアント側のストリーム・プロバイダの構成
SSL/TLSを使用したC++クライアントの保護
Coherence C++ Extendクライアントは、SSL/TLSを公式にはサポートしていません。ただし、次のオプションのいずれかを使用して、この制限を回避し、SSL/TLSが有効なCoherenceプロキシ・サーバーに対してC++ Extendクライアントを安全に実行できます。
SSLを使用したフェデレーション通信の保護
Oracle Coherenceでは、フェデレーテッド・クラスタ内のクラスタ参加者間の通信を保護するためのSSLの使用がサポートされています。フェデレーテッド・サービス・メンバー間で通信が保護され、各クラスタ参加者でSSLを構成する必要があります。
Coherence PeerX509アルゴリズム
Oracle Coherenceには、独自のピア信頼アルゴリズムであるPeerX509が含まれています。このアルゴリズムは、信頼マネージャ・キーストア内にある証明書の信頼(信頼のみ)を前提として機能します。また、TCMPのピアツーピア・プロトコル機能も利用します。具体的には、SSLネゴシエーションを成功させるには、受信した証明書が信頼マネージャによって保持されている証明書のいずれかと同じである必要があります。
グローバル・ソケット・プロバイダの指定
Coherenceオペレーション構成ファイルでグローバル・ソケット・プロバイダを構成できます。設定すると、Coherenceが作成するすべてのサーバーまたはクライアント・ソケットは、独自の特定のソケット・プロバイダでオーバーライドされていないかぎり、この構成を使用します。
ソケット・プロバイダ構成でのパスワードの指定
Javaキーストアおよび秘密キーは、資格証明(通常はパスワード)で保護できます。ソケット・プロバイダ構成には、パスワードを指定するためのいくつかの方法があります。アプリケーション開発者は、必要なセキュリティのレベルと構成のシンプルさに基づいて、最適なアプローチを選択します。
暗号スイートとプロトコル・バージョンの使用の制御
SSLソケット・プロバイダは、弱い可能性のある暗号や特定のプロトコル・バージョンの使用を制御するように構成することができます。
ホスト名検証の使い方
Oracle Coherenceでのホスト名検証の構成方法について学びます。ホスト名検証では、クライアントの接続先URLのホスト名と、SSL接続の一部としてサーバーが返送するデジタル証明書のホスト名が一致していることを確認します。
クライアント認証の構成
<client-auth>要素を使用して、SSL/TLSソケット・プロバイダで一方向SSL/TLS認証を使用するか双方向SSL/TLS認証を使用するかを指定できます。
秘密キーおよび証明書ファイルの使用
Coherenceでは、秘密キーおよび証明書ファイルをキーストアにロードせずに直接使用することもサポートしています。
カスタム・キーストア、秘密キーおよび証明書ローダーの使用
Coherenceでは、キーストア、秘密キーおよび証明書を単純なURLまたはファイル以外のソースからロードすることをサポートし、様々なデータ形式を読み取るために、必要な外部ソースから必要なデータを読み取るようにカスタム・ローダーを構成する方法が提供されています。
リフレッシュ可能なキーストア、秘密キーおよび証明書の使用
一部の環境では、キーや、TLSに使用される証明書は、比較的短い存続期間で作成されます。つまり、JVMを再起動しなくてもCoherenceアプリケーションでキーおよび証明書を更新できるのが理想的だということです。

SSL/TLSの概要

SSL/TLSは、ネットワーク上のエンティティ(通常はクライアントとサーバー)間の通信を保護するセキュリティ・プロトコルです。SSL/TLSは、クライアントとサーバーをデジタル証明書を使用して認証し、認証済のクライアントとサーバーに関連付けられた一意のキーを使用して通信を暗号化および復号化することにより機能しています。

この項では、SSL/TLSの簡単な説明と、この章の残りの部分で使用される用語について説明します。

アイデンティティの確立

エンティティの識別は、デジタル証明書と、公開および秘密の暗号化キーを使用することで確立されます。デジタル証明書には、エンティティに関する一般情報と、それに埋め込まれた公開の暗号化キーが含まれています。

Coherenceでは、アイデンティティは、Java SSLコンテキストのアイデンティティ・マネージャに対応するアイデンティティ・マネージャによって制御されます。

信頼の確立

デジタル証明は認証局(CA)によって検証され、CAのデジタル証明を使用して署名されています。CAのデジタル証明により、エンティティが本物であるという信頼が確立されます。接続が行われると、受信した証明書は、CA証明書の構成済トラスト・ストアまたはJVMのデフォルト・トラスト・ストアに対して検証されます。

Coherenceでは、信頼は、Java SSLコンテキストの信頼マネージャに対応する信頼マネージャ構成によって制御されます。

データの暗号化および復号化

エンティティのデジタル証明書には、秘密の暗号化キーと対になった公開の暗号化キーが含まれています。証明書は、初期接続の際にエンティティ間で渡されます。そのとき、データは公開キーを使用して暗号化されます。エンティティの公開キーを使用して暗号化されたデータは、そのエンティティの秘密キーを使用してのみ復号化されます。これにより、公開の暗号化キーを所有するエンティティのみがそのデータを復号化できるのです。

一方向認証および双方向認証

クライアントとサーバー間のSSL通信は、一方向または双方向のいずれかの認証を使用して設定されます。

一方向認証では、サーバーは認証用のデジタル証明書を送信して、クライアントに自身を識別させる必要があります。クライアントはサーバーにデジタル証明を送信する必要はなく、サーバーに対して匿名のままです。

双方向認証では、クライアントとサーバーの両方が相互認証のためにそれぞれのデジタル証明書を互いに送信する必要があります。双方向認証では、通信の両側で身元が確認されていることを保証することで、より強固なセキュリティが提供されます。双方向TLSは、相互TLS (mTLS)とも呼ばれます。

Oracle Coherenceでは、一方向のSSLと双方向のSSLがサポートされています。構成は、クラスタ・メンバーシップ、Extendプロキシ、gRPCプロキシ、Extendクライアント、gRPCクライアントなど、様々な要因によって異なります。

拡張使用証明書

拡張使用フィールドを追加して、証明書の使用を制限できます。拡張使用は、通常、1つ以上の値です。Coherence通信を保護する場合、拡張使用には正しい使用方法(通常はserverAuthまたはclientAuth)を含める必要があります。

拡張使用の値は、Coherence通信のタイプおよび特定のSSLシナリオによって異なります。アプリケーションが単一の使用(つまり、serverAuthのみまたはclientAuthのみ)の証明書のみにアクセスできる場合、これによって、使用可能なSSL構成と、mTLSまたは一方向TLSのどちらを使用できるかが制限されます。

次に、Coherenceの様々な部分を保護するために使用される証明書に必要な拡張使用を示します。

mTLSを使用するクラスタ・メンバーシップには、serverAuthとclientAuthの両方が必要です
一方向SSLを使用するクラスタ・メンバーシップにはserverAuthが必要です
ExtendプロキシまたはgRPCプロキシにはserverAuthが必要です
ExtendクライアントまたはgRPCクライアントにはclientAuthが必要です
mTLSを使用するフェデレーションには、serverAuthとclientAuthの両方が必要です
一方向SSLを使用するフェデレーションには、serverAuthが必要です
REST HTTPエンドポイントを介した管理には、serverAuthが必要です
メトリックHTTPエンドポイントにはserverAuthが必要です
Coherence REST HTTPプロキシにはserverAuthが必要です

Coherenceには、mTLSに似ていますが、拡張使用を検証しないPeerX509というカスタム信頼プロトコルがあります。このアルゴリズムで構成されたソケット・プロバイダは、任意の拡張使用証明書で動作します。「Coherence PeerX509アルゴリズム」を参照してください。

親トピック: SSL/TLSを使用した通信の保護

Coherenceソケット・プロバイダ

Coherence通信は、ソケット・プロバイダを使用して構成されます。オペレーション構成ファイルの<socket-providers>セクションには、名前付き<socket-provider>要素が0個以上含まれています。

<socket-providers>要素に名前を付けるには、そのid属性を設定します。たとえば、<socket-providers id="ssl-config">と指定すると、ソケット・プロバイダ構成はssl-configという名前になり、Coherence操作構成ファイルまたはキャッシュ構成ファイルの他の部分から参照できます。

Coherenceには様々なタイプのソケット・プロバイダがあり、SSLを使用するには、<ssl>ソケット・プロバイダを構成する必要があります。必要なセキュリティ・シナリオに応じて、<ssl>要素に追加できるXML要素がいくつかあります。最も一般的なのは、<identity-manager>および<trust-manager>です。

例6-1に、このJVMのアイデンティティを確立するための秘密キーと証明書を保持するserver.jksという名前の<identity-manager>キーストア、およびクライアント接続の証明書を検証するためのCA証明書を保持するtrust.jksという名前の<trust-manager>キーストアで構成された基本的なmTLS <ssl>ソケット・プロバイダを示します。

例6-1 基本的なmTLSソケット・プロバイダ構成

<socket-provider id="ssl-config">
    <ssl>
        <identity-manager>
            <key-store>
                <url>file:server.jks</url>
            </key-store>
        </identity-manager>
        <trust-manager>
            <key-store>
                <url>file:trust.jks</url>
            </key-store>
        </trust-manager>
    </ssl>
</socket-provider>

例6-1ではJavaキーストアを使用していますが、秘密キーおよび証明書ファイルを直接使用するようにソケット・プロバイダを構成したり、キーストア、キーまたは証明書を任意の場所から取得できるカスタム・プロバイダをプラグインすることもできます。「秘密キーおよび証明書ファイルの使用」を参照してください。

また、例6-1では、キーストアまたはキーのパスワードは構成されません。パスワードの構成については、「ソケット・プロバイダ構成でのパスワードの指定」を参照してください。

アイデンティティ・マネージャの構成
ソケット・プロバイダの<identity-manager>セクションを使用して、ソケットのアイデンティティを構成します。アイデンティティ・マネージャには、秘密キーと対応する証明書が必要です。これらは、Javaキーストアで提供することも、個別のキー・ファイルおよび証明書ファイルとして個別に提供することもできます。
信頼マネージャの構成
ソケット・プロバイダを構成する場合、信頼マネージャでは、信頼を検証するために1つ以上のCA証明書が必要です。これらは、Javaキーストアで提供することも、個別の証明書ファイルとして個別に提供することもできます。

親トピック: SSL/TLSを使用した通信の保護

アイデンティティ・マネージャの構成

ソケット・プロバイダの<identity-manager>セクションを使用して、ソケットのアイデンティティを構成します。アイデンティティ・マネージャには、秘密キーと対応する証明書が必要です。これらは、Javaキーストアで提供することも、個別のキー・ファイルおよび証明書ファイルとして個別に提供することもできます。

ノート:

次の例には、ハードコードされたパスワード値が含まれているものがあります。本番環境では、安全ではないため、ハードコードされたパスワードを使用しないでください。Coherenceには、パスワードの提供方法がいくつか用意されています。「ソケット・プロバイダ構成でのパスワードの指定」を参照してください。

Javaキーストアの使用

キーと証明書のペアを含むJavaキーストアを使用するには、<identity-manager>要素内に<key-store>要素を構成します。

例6-2では、<identity-manager>は、server.jksという名前のキーストア・ファイルからキーと証明書をロードします。

例6-2 <identity-manager>構成

<identity-manager>
   <key-store>
       <url>file:server.jks</url>
   </key-store>
</identity-manager>

パスワード保護キーストア

キーストアがパスワードで保護されている場合は、<key-store>要素でパスワード構成オプションのいずれかを使用してパスワードを指定します。

例6-3の構成では、<key-store>内の<password>要素を使用してパスワードをfooに設定します。

例6-3 キーストアがパスワードで保護されている<identity-manager>構成

<identity-manager>
   <key-store>
       <url>file:server.jks</url>
       <password>foo</password>
   </key-store>
</identity-manager>

秘密キーおよび証明書ファイルの使用

キー・ファイルおよび証明書ファイルを直接使用するには、<identity-manager>要素内に<key>および<cert>要素を構成します。

例6-4では、<identity-manager>はserver.keyという名前のファイルから秘密キーをロードし、server.certという名前のファイルから証明書をロードします。

例6-4 秘密キーおよび証明書ファイルをロードする<identity-manager>構成

<identity-manager>
    <key>server.key</key>
    <cert>server.cert</cert>
</identity-manager>

パスワード保護秘密キー

秘密キーが暗号化され、パスワードで保護されている場合、サポートされているパスワード・オプションのいずれかを使用して、資格証明を<identity-manager>構成で構成する必要があります。

例6-5では、アイデンティティ・マネージャは、server.jksという名前のJavaキーストアから秘密キーを読み取るように構成されています。秘密キーは、パスワードfooで保護されます。このパスワードは、<identity-manager>要素内の<password>要素を使用して指定されます。

例6-5 パスワードで保護された秘密キーを使用した<identity-manager>構成

<identity-manager>
   <key-store>
       <url>file:server.jks</url>
  </key-store>
  <password>foo</password>
</identity-manager>

ノート:

キーストアと秘密キーの両方にパスワードが必要なJavaキーストアを使用する場合、構成で2つのパスワードが混同されないようにすることが重要です。キーストア・パスワードは、<key-store>要素内にあります。秘密キー・パスワードは、<identity-manager>要素内の上位レベルにあります。

例6-6では、アイデンティティ・マネージャがserver.keyという名前のファイルから秘密キーを読み取るように構成されています。秘密キーは、パスワードfooで保護されています。パスワードは、<identity-manager>要素内の<password>要素を使用して指定されます。

例6-6 秘密キーを使用した<identity-manager>構成

<identity-manager>
    <key>server.key</key>
    <cert>server.cert</cert>
    <password>foo</password>
</identity-manager>

親トピック: Coherenceソケット・プロバイダ

信頼マネージャの構成

ソケット・プロバイダを構成する場合、信頼マネージャでは、信頼を検証するために1つ以上のCA証明書が必要です。これらは、Javaキーストアで提供することも、個別の証明書ファイルとして個別に提供することもできます。

ノート:

次の例には、ハードコードされたパスワード値を使用するものもあります。本番環境では、安全ではないため、ハードコードされたパスワードを使用しないでください。Coherenceには、パスワードを提供するためのいくつかの代替方法があります。「ソケット・プロバイダ構成でのパスワードの指定」を参照してください。

Javaキーストアの使用

CA証明書を含むJavaキーストアを使用するには、<trust-manager>要素内に<key-store>要素を構成します。

例6-7では、<trust-manager>要素は、trust.jksという名前のキーストア・ファイルからCA証明書をロードします。

例6-7 <trust-manager>構成

<identity-manager>
   <key-store>
       <url>file:trust.jks</url>
   </key-store>
</identity-manager>

パスワード保護キーストア

キーストアがパスワードで保護されている場合は、<key-store>要素でパスワード構成オプションのいずれかを使用してパスワードを指定します。

例6-8の構成では、<key-store>内の<password>要素を使用してパスワードをfooに設定します。

例6-8 キーストアがパスワードで保護されている<trust-manager>構成

<trust-manager>
   <key-store>
       <url>file:server.jks</url>
       <password>foo</password>
   </key-store>
</trust-manager>

証明書ファイルの使用

証明書ファイルを直接使用するには、<trust-manager>要素内に<cert>要素を構成します。<trust-manager>要素には、複数の<cert>要素を含めることができます。

例6-9では、<trust-manager>によって、ca-one.certおよびca-two.certという名前のファイルから証明書がロードされます。

例6-9 証明書ファイルを使用した<trust-manager>構成

<trust-manager>
    <cert>ca-one.cert</cert>
    <cert>ca-two.cert</cert>
</trust-manager>

親トピック: Coherenceソケット・プロバイダ

ソケット・プロバイダURLの解決

ソケット・プロバイダの構成要素の中にはURLがいくつかあります。たとえば、<key-store>要素内の<url>要素です。

次に、これらの要素の値がどのように処理されて、参照するリソースが特定されるかについて説明します:

XML要素の値はJava URIに変換されます。
値が有効なURIで、URIスキーム(file:やhttp:など)がある場合は有効なURIとみなされ、Coherenceでは、このURIへのストリームを開いてデータの読取りが試行されます。
値にスキームがない場合、Coherenceでは、ファイル・システムまたはクラス・パス上のファイルとして処理されます。Coherenceでは、まず、値がファイル名(完全修飾または作業ディレクトリに対する相対)であると想定され、そのファイルが検索されます。これが失敗すると、Coherenceは同じファイルをクラスパス上のリソースとして見つけようと試みます。

親トピック: SSL/TLSを使用した通信の保護

構成でのソケット・プロバイダの使用

<socket-provider>を使用して、Coherence構成ファイル内の様々な場所を構成できます。<socket-provider>は、オペレーション構成ファイル内の名前付きソケット・プロバイダへの名前付き参照、またはインライン・ソケット・プロバイダ構成のいずれかの2つの方法で構成できます。

例6-10に、キャッシュ構成ファイル内のExtendプロキシ・サービスを示します。プロキシ・スキームは、オペレーション構成ファイルでmtlsという名前のソケット・プロバイダを参照するmtlsという値を持つ<socket-provider>要素で構成されます。

例6-10 mtlsソケット・プロバイダを参照するExtendプロキシ・サービス

<proxy-scheme>
    <scheme-name>proxy</scheme-name>
    <service-name>Proxy</service-name>
    <acceptor-config>
        <tcp-acceptor>
            <socket-provider>mtls</socket-provider>
        </tcp-acceptor>
    </acceptor-config>
</proxy-scheme>

例6-11に、キャッシュ構成ファイル内のExtendプロキシ・サービスを示します。プロキシ・スキームは、ソケット・プロバイダのフル構成を含む<socket-provider>要素で構成されます。

例6-11 インライン・ソケット・プロバイダ構成を使用したExtendプロキシ・サービス

<proxy-scheme>
    <scheme-name>proxy</scheme-name>
    <service-name>Proxy</service-name>
    <acceptor-config>
        <tcp-acceptor>
            <socket-provider>
                <identity-manager>
                    <key-store>
                        <url>file:server.jks</url>
                    </key-store>
                </identity-manager>
                <trust-manager>
                    <key-store>
                        <url>file:trust.jks</url>
                    </key-store>
                </trust-manager>
            </socket-provider>
        </tcp-acceptor>
    </acceptor-config>
</proxy-scheme>

実行時のソケット・プロバイダの構成
オペレーション構成ファイルで構成された名前付きソケット・プロバイダを使用する場合、Javaシステム・プロパティに基づいて、実行時に構成で使用されるソケット・プロバイダを変更できます。

親トピック: SSL/TLSを使用した通信の保護

実行時のソケット・プロバイダの構成

オペレーション構成ファイルで構成された名前付きソケット・プロバイダを使用する場合、Javaシステム・プロパティに基づいて、実行時に構成で使用されるソケット・プロバイダを変更できます。

<socket-provider>要素のオプションのsystem-property属性は、実行時にソケット・プロバイダ名を取得するために使用されるシステム・プロパティの名前を指定します。これにより、どの種類のソケットを使用するかを実行時に柔軟に選択できます。たとえば、開発者は、キーや証明書の作成を気にすることなく、開発テストでプレーンTCPを使用できます。その後、システムのテストおよび本番環境では、SSLソケット・プロバイダ名を指定できます。

例6-12に、キャッシュ構成ファイル内のExtendプロキシ・サービスを示します。プロキシ・スキームは、system-property属性がproxy.socket.providerに設定された、値のない<socket-provider>要素で構成されます。デフォルトでは、<socket-provider>要素に値がないため、プロバイダは設定されず、プロキシはプレーンTCPソケットを使用します。

例6-12 プレーンTCPソケットを使用するように構成されたExtendプロキシ・サービスの構成

<proxy-scheme>
    <scheme-name>proxy</scheme-name>
    <service-name>Proxy</service-name>
    <acceptor-config>
        <tcp-acceptor>
            <socket-provider system-property="proxy.socket.provider"/>
        </tcp-acceptor>
    </acceptor-config>
</proxy-scheme>

JVMがシステム・プロパティを設定して起動された場合、そのプロパティ値がソケット・プロバイダ名として使用されます。たとえば、-Dproxy.socket.provider=mtlsを指定してCoherenceを起動すると、ソケット・プロバイダ名としてmtlsが使用されます(オペレーション構成ファイル内にmtlsという名前のソケット・プロバイダが構成されている場合)。

例6-13に、キャッシュ構成ファイル内のExtendプロキシ・サービスを示します。プロキシ・スキームは、値がmtlsで、system-property属性がproxy.socket.providerに設定された<socket-provider>要素で構成されます。デフォルトでは、オペレーション構成からmtlsという名前のソケット・プロバイダが使用されます。proxy.socket.providerシステム・プロパティが設定されている場合は、そのプロパティ値がソケット・プロバイダ名として使用されます。

例6-13 参照ソケット・プロバイダを使用するように構成されたExtendプロキシ・サービスの構成

<proxy-scheme>
    <scheme-name>proxy</scheme-name>
    <service-name>Proxy</service-name>
    <acceptor-config>
        <tcp-acceptor>
            <socket-provider system-property="proxy.socket.provider">
                mtls
            </socket-provider>
        </tcp-acceptor>
    </acceptor-config>
</proxy-scheme>

親トピック: 構成でのソケット・プロバイダの使用

SSLを使用したクラスタ通信の保護

Coherenceクラスタでは、すべてのクラスタ・メンバーが、ピアツーピア・ネットワークでTCPを介して相互に通信します。各JVMは、他のクラスタ・メンバーから接続を受信するサーバーと、他のクラスタ・メンバーに接続するクライアントの両方です。

さらに、TCMPではpeer-to-peerプロトコルであることを認識する必要があります。peer-to-peerプロトコルは、通常、多くのクラスタ・ノードを相互に接続したままであることが想定される信頼できる環境で動作します。接続時にSSLネゴシエーションが1回実行され、関係する2つのクラスタ・メンバーJVMの存続期間中、接続が維持されます。SSLを構成する場合は、キーと証明書の管理およびパフォーマンスへの影響について、慎重に考慮してください。

クラスタ・トラフィックの制御に使用されるソケット・プロバイダは、オペレーション構成ファイルのクラスタ構成の<unicast-listener>要素内に<socket-provider>要素を設定することによって構成されます。

例6-14では、XMLオペレーション構成ファイルによって、ユニキャスト・ソケット・プロバイダ名がssl-configに設定されます。これは、<socket-providers>セクションのssl-configという名前のソケット・プロバイダへの参照です。

実際のソケット・プロバイダの構成は、アプリケーションのセキュリティ要件によって異なります。

例6-14 クラスタがソケット・プロバイダを使用してSSL/TLSを構成する構成

<?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-config</socket-provider>
        </unicast-listener>

        <socket-providers>
            <socket-provider id=ssl-config">
                <ssl>
                <!-- Actual config omitted for brevity -->
                </ssl>
            </socket-provider>
        </socket-providers>
    </cluster-config>
</coherence>

mTLSを使用したクラスタ通信
SSLを使用してクラスタ通信を保護するための最も一般的な推奨構成は、mTLS(双方向TLS)です。<ssl>ソケット・プロバイダをmTLS用に構成するには、アイデンティティと信頼の両方を構成する必要があります。
一方向SSLを使用したクラスタ通信
クラスタ・メンバーに対して一方向SSLを構成して、クラスタ・メンバーが別のクラスタ・メンバーへの接続時に受信するサーバー証明書の信頼性を検証するようにできます。クラスタ・メンバーは、接続するメンバーの信頼性を検証しません。

親トピック: SSL/TLSを使用した通信の保護

mTLSを使用したクラスタ通信

SSLを使用してクラスタ通信を保護するための最も一般的な推奨構成は、mTLS(双方向TLS)です。<ssl>ソケット・プロバイダをmTLS用に構成するには、アイデンティティと信頼の両方を構成する必要があります。

例6-15では、ソケット・プロバイダmtls-configは、server.jksという名前のキーストアを含む<identity-manager>要素と、trust.jksという名前のキーストアを含む<trust-manager>要素で構成されます。次に、<unicast-listener> <socket-provider>要素がmtls-configに設定され、SSLソケット・プロバイダが参照されます。

例6-15 mTLS経由で通信するクラスタの構成

<?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>mtls-config</socket-provider>
     </unicast-listener>

      <socket-providers>
         <socket-provider id=mtls-config">
           <ssl>
              <identity-manager>
                 <key-store>
                     <url>file:server.jks</url>
                 </key-store>
              </identity-manager>
               <trust-manager>
                 <key-store>
                     <url>file:trust.jks</url>
                 </key-store>
               </trust-manager>
           </ssl>
        </socket-provider>
      </socket-providers>
   </cluster-config>
</coherence>

デフォルトでは、<ssl>ソケット・プロバイダがアイデンティティと信頼の両方で構成されている場合、CoherenceはmTLS用に構成されたJava SSLコンテキストを作成します。

ノート:

この構成で拡張使用が設定された証明書を使用する場合、拡張使用にはserverAuthとclientAuthの両方を含める必要があります。ソケット・プロバイダ構成は、クラスタ・メンバーのサーバー・ソケット(他のクラスタ・メンバーからの接続の受信に使用)とそのクライアント・ソケット(他のクラスタ・メンバーへの接続に使用)の両方で使用される単一のJava SSLコンテキストを構成するために使用されます。

親トピック: SSLを使用したクラスタ通信の保護

一方向SSLを使用したクラスタ通信

クラスタ・メンバーに対して一方向SSLを構成して、クラスタ・メンバーが別のクラスタ・メンバーへの接続時に受信するサーバー証明書の信頼性を検証するようにできます。クラスタ・メンバーは、接続するメンバーの信頼性を検証しません。

ユニキャスト・リスナーに対して構成できるソケット・プロバイダは1つのみであるため、<ssl>ソケット・プロバイダは、mTLSと同じアイデンティティと信頼の両方で構成する必要があります。一方向SSLを指定するには、<client-auth>要素を追加し、その値をnoneに設定します。

<client-auth>要素は、クライアントが証明書を送信する必要があるかどうかを決定するJava SSLコンテキストの対応する設定を構成します。次の3つの値を指定できます:

none - クライアントは証明書を送信しません(アイデンティティ・キーおよび証明書で構成されている場合でも)

クラスタが一方向SSLで通信する場合は、<client-auth>をnoneに設定します。
wanted - クライアントが証明書を持っている場合、その証明書を送信できます
required - クライアントは証明書を送信する必要があります。

クラスタがmTLSで通信する場合は、<client-auth>をrequiredに設定します。

例6-16に、一方向SSLのユニキャスト・リスナー構成を示します。

例6-16 一方向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>one-way-config</socket-provider>
     </unicast-listener>

      <socket-providers>
         <socket-provider id=one-way-config>
           <ssl>
              <identity-manager>
                 <key-store>
                     <url>file:server.jks</url>
                 </key-store>
              </identity-manager>
               <trust-manager>
                 <key-store>
                     <url>file:trust.jks</url>
                 </key-store>
               </trust-manager>
<!-- This element changes the configuration to one-way SSL -->
               <client-auth>none<client-auth>
           </ssl>
         </socket-provider>
     </socket-providers>
   </cluster-config>
</coherence>

ノート:

この構成で拡張使用が設定された証明書を使用する場合、拡張使用にはserverAuthが含まれている必要があります。一方向SSLでは、サーバーのみがクライアントに証明書を送信するため、証明書はサーバー証明書として使用するために有効である必要があります。

親トピック: SSLを使用したクラスタ通信の保護

SSLを使用したExtendおよびgRPCクライアント通信の保護

Oracle Coherenceでは、Coherence ExtendおよびgRPCクライアントとクラスタ側のExtendまたはgRPCプロキシの間の通信を保護するためにSSLがサポートされています。

クライアントとプロキシの間の通信を保護するためにSSLを使用する場合、クライアント側とクラスタ側の両方での構成が必要です。SSLは、Javaおよび.NET Extendクライアントの両方でサポートされていますが、C++ Extendクライアントではサポートされていません(「SSL/TLSを使用したC++クライアントの保護」で説明された追加の構成がない場合)。SSLは、すべてのタイプのgRPCクライアントでサポートされています。

クライアントおよびプロキシに対してmTLSと一方向SSLの両方を構成できます。

クラスタ側のExtendプロキシSSLソケット・プロバイダの構成
クラスタ側のキャッシュ構成ファイルで、プロキシ・サービス用のSSLソケット・プロバイダを定義することで、SSLを構成できます。
クラスタ側のgRPCプロキシSSLソケット・プロバイダの構成
Coherence gRPCプロキシは、内部プロキシ・キャッシュ構成ファイルを使用して構成されます。
Java ExtendまたはgRPCクライアントSSLソケット・プロバイダの構成
ExtendまたはgRPCクライアント・キャッシュ構成ファイルでSSLを構成するには、リモート・スキームのSSLソケット・プロバイダを定義します。

親トピック: SSL/TLSを使用した通信の保護

クラスタ側のExtendプロキシSSLソケット・プロバイダの構成

クラスタ側のキャッシュ構成ファイルでSSLを設定するには、プロキシ・サービス用のSSLソケット・プロバイダを定義します。

SSLソケット・プロバイダの構成には、必要な粒度レベルに応じて、次の2つのオプションがあります。

プロキシ・サービスごとにソケット・プロバイダを構成します。各プロキシ・サービスは、SSLソケット・プロバイダの構成を定義するか、オペレーション構成ファイルに含まれている事前定義済の構成を参照します。
キャッシュ構成の<defaults>セクションでソケット・プロバイダを構成して、同じSSLソケット・プロバイダ構成を使用するようにすべてのプロキシ・サービスを構成します。

独自の構成を提供するプロキシ・サービスは、<defaults>セクションの構成をオーバーライドします。<defaults>セクションのソケット・プロバイダ構成は、オペレーション構成ファイルに含まれる名前付きソケット・プロバイダ構成、またはインライン・ソケット・プロバイダのフル構成を参照できます。

ノート:

クラスタ側プロキシ・ソケット・プロバイダ構成で拡張使用が設定された証明書を使用する場合、拡張使用にはserverAuthを含める必要があります。プロキシは、サーバー・ソケットを開いてクライアント接続を受信するため、証明書はサーバーで使用するために有効である必要があります。

Extendプロキシ・サービスごとのSSLソケット・プロバイダの構成

Extendプロキシ・サービス用にSSLソケット・プロバイダを構成するには、各<proxy-scheme>定義の<tcp-acceptor>要素内に<socket-provider>要素を追加します。

例6-17は、キャッシュ構成ファイルのプロキシ構成でSSLソケット・プロバイダを直接構成するプロキシ・スキームを示しています。

例6-17 Extendプロキシ・サービスごとのSSL/TLSソケット・プロバイダの構成

<proxy-scheme>
   <service-name>ProxyService</service-name>
   <acceptor-config>
      <tcp-acceptor>
         <socket-provider>
            <ssl>
              <identity-manager>
                 <key-store>
                     <url>file:server.jks</url>
                </key-store>
              </identity-manager>
               <trust-manager>
                 <key-store>
                     <url>file:trust.jks</url>
                 </key-store>
               </trust-manager>
           </ssl>
         </socket-provider>
     </tcp-acceptor>
   </acceptor-config>
   <autostart>true</autostart>
</proxy-scheme>

例6-18は、オペレーション構成ファイルで名前付きソケット・プロバイダを参照するようにキャッシュ構成でプロキシを構成する方法を示しています。ここでは、プロキシはssl-configという名前のソケット・プロバイダを使用します。

例6-18 すべてのExtendプロキシ・サービスに対する単一のSSL/TLSソケット・プロバイダの構成

<proxy-scheme>
   <service-name>ProxyService</service-name>
   <acceptor-config>
      <tcp-acceptor>
         <socket-provider>ssl-config</socket-provider>
     </tcp-acceptor>
   </acceptor-config>
   <autostart>true</autostart>
</proxy-scheme>

mTLSを使用したExtendまたはgRPCプロキシ

アイデンティティと信頼の両方を指定して構成された<ssl>ソケット・プロバイダを使用して、mTLSのプロキシを構成できます。

例6-19に、mTLS用に構成されたソケット・プロバイダを示します。デフォルトでは、ソケット・プロバイダにアイデンティティと信頼の両方が構成されている場合、双方向SSLを使用するようにSSLコンテキストを構成します。

ノート:

プロキシがmTLS用に構成されている場合、クライアントもmTLS用に構成する必要があります。

例6-19 mTLSを使用したExtendまたはgRPCプロキシの構成

<socket-provider id="mtls-config">
  <ssl>
     <identity-manager>
        <key-store>
            <url>file:server.jks</url>
        </key-store>
     </identity-manager>
      <trust-manager>
        <key-store>
            <url>file:trust.jks</url>
        </key-store>
      </trust-manager>
  </ssl>
</socket-provider>

一方向SSLを使用したExtendプロキシまたはgRPCプロキシ

プロキシは、アイデンティティのみを指定して構成された<ssl>ソケット・プロバイダを使用して一方向SSL用に構成できます。一方向SSLでは、サーバーはクライアントに証明書を送信します。この証明書は、クライアントがトラスト・ストアに対して検証します。一方向SSLを構成する場合、ソケット・プロバイダ構成を正しく設定することが重要です。つまり、サーバーには <identity-manager>のみを構成し、クライアントには<trust-manager>を構成します。

例6-20に、一方向SSL用に構成されたクラスタ側プロキシ・ソケット・プロバイダを示します。

例6-20 一方向SSL/TLSを使用したExtendまたはgRPCプロキシの構成

<socket-provider id="oneway-proxy-config">
  <ssl>
     <identity-manager>
        <key-store>
            <url>file:server.jks</url>
        </key-store>
     </identity-manager>
 </ssl>
</socket-provider>

<identity-manager>と<trust-manager>の両方を指定して構成されたソケット・プロバイダで一方向SSLを使用するようにクラスタ側プロキシを構成する別の方法は、<client-auth>要素をnoneに設定することです。

例6-21に、アイデンティティと信頼の両方を指定して構成されたクラスタ側ソケット・プロバイダを示します。両方を指定すると、通常はmTLSですが、<client-auth>要素をnoneに設定しているため、一方向になり、クライアントが証明書を送信する必要はありません。

プロキシが一方向SSL用に構成されている場合、クライアントはmTLSまたは一方向構成で構成できます。クライアントが双方向(つまり、アイデンティティと信頼を指定)として構成されている場合、接続してサーバー証明書を検証しますが、自身の証明書は送信しません。

例6-21 <client-auth>をnoneに設定して一方向SSL/TLSを使用するExtendまたはgRPCプロキシの構成

<socket-provider id="one-way-config">
  <ssl>
     <identity-manager>
        <key-store>
            <url>file:server.jks</url>
        </key-store>
     </identity-manager>
      <trust-manager>
        <key-store>
            <url>file:trust.jks</url>
        </key-store>
      </trust-manager>
      <!-- This element changes the configuration to one-way SSL -->
      <client-auth>none<client-auth>
  </ssl>
</socket-provider>

親トピック: SSLを使用したExtendおよびgRPCクライアント通信の保護

クラスタ側のgRPCプロキシSSLソケット・プロバイダの構成

Coherence gRPCプロキシは、内部プロキシ・キャッシュ構成ファイルを使用して構成されます。

gRPCプロキシにSSLを構成するには、オペレーション構成ファイルで名前付きソケット・プロバイダを構成し、 coherence.grpc.server.socketproviderシステム・プロパティ(または環境変数)をそのソケット・プロバイダの名前に設定します。

Coherenceオペレーション構成には、grpc-insecureという名前の特別なgRPCソケット・プロバイダ構成が含まれます。これにより、プロキシまたはクライアントが使用するデフォルトのgRPC Javaのセキュアでない資格証明が構成されます。

親トピック: SSLを使用したExtendおよびgRPCクライアント通信の保護

Java ExtendまたはgRPCクライアントSSLソケット・プロバイダの構成

ExtendまたはgRPCクライアント・キャッシュ構成ファイルでSSLを構成するには、リモート・スキームのSSLソケット・プロバイダを定義します。

SSLソケット・プロバイダの構成には、必要な粒度レベルに応じて、次の2つのオプションがあります。

リモート・スキームごとにソケット・プロバイダを構成します。各リモート・スキームは、SSLソケット・プロバイダの構成を定義するか、オペレーション構成ファイルに含まれている事前定義済の構成を参照します。
キャッシュ構成の<defaults>セクションでソケット・プロバイダを構成して、同じSSLソケット・プロバイダ構成を使用するようにすべてのリモート・スキームを構成します。

独自の構成を提供するリモート・サービスは、<defaults>セクションの構成をオーバーライドします。<defaults>セクションのソケット・プロバイダ構成は、オペレーション構成ファイルに含まれる名前付きソケット・プロバイダ構成、またはインライン・ソケット・プロバイダのフル構成を参照できます。

ノート:

ExtendまたはgRPCクライアント・ソケット・プロバイダ構成で拡張使用が設定された証明書を使用する場合、拡張使用にはclientAuthを含める必要があります。
クラスタ側プロキシがmTLSを使用するように構成されている場合、クライアントもmTLS用に構成する必要があります。クラスタ側プロキシが一方向SSLを使用するように構成されている場合、クライアントは一方向またはmTLSとして構成できます。これは、接続が双方向であるか一方向であるか(つまり、クライアントがアイデンティティ証明書を送信する必要があるかどうか)を決定するのはサーバーであるためです。

リモート・サービスごとのSSLソケット・プロバイダの構成

Extendリモート・サービス用にSSLソケット・プロバイダを構成するには、<remote-cache-scheme>定義または<remove-invocation-scheme>の<tcp-initiator>要素内に<socket-provider>要素を追加します。

gRPCリモート・サービス用にSSLソケット・プロバイダを構成するには、<remote-grpc-cache-scheme>定義の<grpc-channel>要素内に<socket-provider>要素を追加します。

例6-22は、SSLを使用するソケット・プロバイダを構成するExtendリモート・キャッシュ・スキームを示しています。この例では、アイデンティティ・キーストア(server.jks)と信頼キーストア(trust.jks)の両方を構成します。これは典型的な双方向SSL認証であり、クライアントとプロキシの双方が、デジタル証明書を交換し、互いのIDを確認する必要があります。

例6-22 リモート・スキームごとのSSL/TLSソケット・プロバイダの構成

<?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>*</cache-name>
         <scheme-name>remote-cache</scheme-name>
      </cache-mapping>
   </caching-scheme-mapping>

   <caching-schemes>
      <remote-cache-scheme>
         <scheme-name>remote-cache</scheme-name>
         <service-name>RemoteService</service-name>
         <initiator-config>
            <tcp-initiator>
               <socket-provider>
                  <ssl>
                    <identity-manager>
                       <key-store>
                           <url>file:server.jks</url>
                       </key-store>
                    </identity-manager>
                     <trust-manager>
                       <key-store>
                           <url>file:trust.jks</url>
                       </key-store>
                     </trust-manager>
                 </ssl>
               </socket-provider>
           </tcp-initiator>
        </initiator-config>
      </remote-cache-scheme>
   </caching-schemes>
</cache-config>

例6-23は、SSLを使用するソケット・プロバイダを構成するgRPCリモート・キャッシュ・スキームを示しています。この例では、アイデンティティ・キーストア(server.jks)と信頼キーストア(trust.jks)の両方を構成します。これは典型的な双方向SSL認証であり、クライアントとプロキシの双方が、デジタル証明書を交換し、互いのIDを確認する必要があります。

例6-23 SSL/TLSを使用するようにソケット・プロバイダを構成するgRPCリモート・キャッシュ・スキームの構成

<?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>*</cache-name>
         <scheme-name>remote-cache</scheme-name>
      </cache-mapping>
   </caching-scheme-mapping>

   <caching-schemes>
      <remote-grpc-cache-scheme>
         <scheme-name>remote-cache</scheme-name>
         <service-name>RemoteService</service-name>
         <grpc-channel>
              <socket-provider>
                  <ssl>
                    <identity-manager>
                       <key-store>
                           <url>file:server.jks</url>
                       </key-store>
                    </identity-manager>
                     <trust-manager>
                       <key-store>
                           <url>file:trust.jks</url>
                       </key-store>
                     </trust-manager>
                 </ssl>
               </socket-provider>
           </grpc-channel>
     </remote-grpc-cache-scheme>
   </caching-schemes>
</cache-config>

例6-24では、オペレーション構成ファイルの<socket-providers>要素で定義されているssl-clientという名前のSSLソケット・プロバイダ構成を参照するリモート・スキームを構成します。

例6-24 ソケット・プロバイダを参照するリモート・キャッシュ・スキームの構成

<?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>extend-*</cache-name>
         <scheme-name>remote-cache</scheme-name>
      </cache-mapping>

      <cache-mapping>
         <cache-name>grpc-*</cache-name>
         <scheme-name>grpc-cache</scheme-name>
      </cache-mapping>
   </caching-scheme-mapping>

   <caching-schemes>
      <remote-cache-scheme>
         <scheme-name>remote-cache</scheme-name>
         <service-name>RemoteCache</service-name>
         <initiator-config>
            <tcp-initiator>
               <socket-provider>ssl-client</socket-provider>
           </tcp-initiator>
     </remote-cache-scheme>

      <remote-grpc-cache-scheme>
         <scheme-name>grpc-cache</scheme-name>
         <service-name>RemoteGrpcCache</service-name>
        <grpc-channel>
            <socket-provider>ssl-client</socket-provider>
         </grpc-channel>
     </remote-grpc-cache-scheme>
   </caching-schemes>
</cache-config>

mTLSを使用したExtendまたはgRPCクライアント

クライアントは、アイデンティティと信頼の両方を指定して構成された<ssl>ソケット・プロバイダを使用して、mTLS用に構成できます。

例6-25に、mTLS用に構成されたソケット・プロバイダを示します。クラスタ側プロキシがmTLSを使用するように構成されている場合、アイデンティティからのクライアント証明書がサーバーに送信されます。双方向SSLと一方向SSLの両方で、トラスト・ストア内のCA証明書がプロキシ・サーバー・アイデンティティの検証に使用されます。

例6-25 mTLSを使用したExtendまたはgRPCクライアントの構成

<socket-provider id=mtls-config">
  <ssl>
     <identity-manager>
        <key-store>
            <url>file:server.jks</url>
        </key-store>
     </identity-manager>
      <trust-manager>
        <key-store>
            <url>file:trust.jks</url>
        </key-store>
      </trust-manager>
  </ssl>
</socket-provider>

一方向SSLを使用したExtendまたはgRPCクライアント

トラスト・ストアのみを指定して構成された<ssl>ソケット・プロバイダを使用して、一方向SSL用にクライアントを構成できます。プロキシ・サーバーも一方向SSL用に構成する必要があります。

例6-26に、一方向SSL用に構成されたソケット・プロバイダを示します。トラスト・ストア内のCA証明書は、サーバー証明書のアイデンティティの検証に使用されます。

例6-26 一方向SSL/TLSを使用したExtendまたはgRPCクライアントの構成

<socket-provider id=one-way-config>
  <ssl>
     <trust-manager>
        <key-store>
            <url>file:trust.jks</url>
        </key-store>
      </trust-manager>
  </ssl>
</socket-provider>

親トピック: SSLを使用したExtendおよびgRPCクライアント通信の保護

キャッシュ構成ファイルのデフォルト・ソケット・プロバイダの構成

ソケット・プロバイダは、キャッシュ構成ファイルの<defaults>セクションで構成できます。このソケット・プロバイダは、リモート・キャッシュ・サービス、リモート呼出しサービス、プロキシ・サービス、gRPCサービスなど、独自のソケット・プロバイダを具体的に構成しない、その構成ファイル内のすべてのスキームに適用されます。

例6-27では、キャッシュ構成ファイルの<defaults>セクションに、オペレーション構成ファイルのmtlsという名前のプロバイダを参照するソケット・プロバイダがあります。キャッシュ構成ファイルには3つのリモート・スキームが含まれており、いずれにもソケット・プロバイダが構成されていないため、すべてmtlsソケット・プロバイダが使用されます。

例6-27 キャッシュ構成の<defaults>セクションでソケット・プロバイダを参照するための構成

<?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>mtls</socket-provider>
    </defaults>

    <caching-scheme-mapping>
        <cache-mapping>
            <cache-name>*</cache-name>
            <scheme-name>remote</scheme-name>
        </cache-mapping>

        <cache-mapping>
            <cache-name>grpc-cache</cache-name>
            <scheme-name>remote-grpc</scheme-name>
        </cache-mapping>
    </caching-scheme-mapping>

    <caching-schemes>
        <remote-cache-scheme>
            <scheme-name>remote</scheme-name>
            <service-name>RemoteService</service-name>
        </remote-cache-scheme>

        <remote-invocation-scheme>
            <scheme-name>invocation</scheme-name>
            <service-name>RemoteInvocation</service-name>
        </remote-invocation-scheme>

        <remote-grpc-cache-scheme>
            <scheme-name>remote-grpc</scheme-name>
            <service-name>RemoteGrpcCache</service-name>
        </remote-grpc-cache-scheme>
    </caching-schemes>
</cache-config>

例6-28では、キャッシュ構成ファイルの<defaults>セクションに、オペレーション構成ファイルのmtlsという名前のプロバイダを参照するソケット・プロバイダがあります。キャッシュ構成ファイルには、3つのリモート・スキーム(リモート・キャッシュ・スキーム、リモート起動スキームおよびリモートgRPCキャッシュ・スキーム)が含まれています。リモート・キャッシュ・スキームおよびリモート起動スキームでは、ソケット・プロバイダが指定されないため、mtlsソケット・プロバイダが使用されます。ただし、リモートgRPCスキームはソケット・プロバイダを構成しているため、オペレーション構成ファイルのone-wayという名前のソケット・プロバイダを参照します。

例6-28

<?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"
    xml-override="{coherence.cacheconfig.override}">

    <defaults>
        <socket-provider>mtls-config</socket-provider>
    </defaults>

    <caching-scheme-mapping>
        <cache-mapping>
            <cache-name>*</cache-name>
            <scheme-name>remote</scheme-name>
        </cache-mapping>

        <cache-mapping>
            <cache-name>grpc-cache</cache-name>
            <scheme-name>remote-grpc</scheme-name>
        </cache-mapping>
    </caching-scheme-mapping>

    <caching-schemes>
        <remote-cache-scheme>
            <scheme-name>remote</scheme-name>
            <service-name>RemoteService</service-name>
        </remote-cache-scheme>

        <remote-invocation-scheme>
            <scheme-name>invocation</scheme-name>
            <service-name>RemoteInvocation</service-name>
        </remote-invocation-scheme>

        <remote-grpc-cache-scheme>
            <scheme-name>remote-grpc</scheme-name>
            <service-name>RemoteGrpcCache</service-name>
            <grpc-channel>
                <socket-provider>one-way</socket-provider>
            </grpc-channel>
        </remote-grpc-cache-scheme>
    </caching-schemes>
</cache-config>

親トピック: SSL/TLSを使用した通信の保護

.NETクライアント側のストリーム・プロバイダの構成

.NETクライアント側のキャッシュ構成ファイルで、リモート・サービス用のSSLストリーム・プロバイダを定義することで、SSLを構成します。SSLストリーム・プロバイダは、<tcp-initiator>要素内の<stream-provider>要素を使用して定義します。

ノート:

証明書は、Windowサーバーでは、オペレーティング・システム・レベルで証明書マネージャを使用して管理します。サンプルの構成は、証明書マネージャに拡張プロキシの証明書およびプロキシの証明書に署名した信頼できるCAの証明書が含まれていることを前提としています。

例6-29は、SSLストリーム・プロバイダを構成するリモート・キャッシュ・スキームを示しています。SSLストリーム・プロバイダの構成に使用する要素の詳細は、キャッシュ構成XMLスキーマ(INSTALL_DIR\config\cache-config.xsd)を参照してください。

ノート:

<protocol>要素は、使用可能なSslProtocols列挙値およびプロトコル値のカンマ区切りリストをサポートします。たとえば:

<protocol>Tls11,Tls12</protocol>

プロトコルが、クライアント側とサーバー側の両方の構成で指定されていることを確認してください。

例6-29 .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を使用した通信の保護

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/TLSを使用した通信の保護

SSLを使用したフェデレーション通信の保護

Oracle Coherenceでは、フェデレーテッド・クラスタ内のクラスタ参加者間の通信を保護するためのSSLの使用がサポートされています。フェデレーテッド・サービス・メンバー間で通信が保護され、各クラスタ参加者でSSLを構成する必要があります。

SSLを使用してフェデレーション通信を保護するには、<federated-scheme>で<socket-provider>要素を構成します。

フェデレーションのソケット・プロバイダは、クラスタ・ユニキャスト・ソケットに使用されるソケット・プロバイダに似ています。つまり、ソケット・プロバイダはサーバー・ソケットとクライアント・ソケットの両方を構成します。これにより、サポートされる構成のタイプが制限されます。

例6-30は、スキーム定義内に<socket-provider>が構成された<federated-scheme>を示しています。

例6-30 インライン <socket-provider>を使用して、フェデレーテッド・クラスタ内のクラスタ参加者間にSSL/TLSを構成するための構成

<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>
     <ssl>
         <identity-manager>
            <key-store>
                <url>file:server.jks</url>
            </key-store>
         </identity-manager>
          <trust-manager>
            <key-store>
                <url>file:trust.jks</url>
            </key-store>
          </trust-manager>
      </ssl>
   </socket-provider>
  <topologies>
      <topology>
         <name>MyTopology</name>
      </topology>
   </topologies>
</federated-scheme>

例6-31は、ssl-federationという名前のソケット・プロバイダ(オペレーション構成ファイルの<socket-providers>セクションで構成されている)を参照する<socket-provider>を含む<federated-scheme>を示しています。

例6-31 参照<socket-provider>を使用して、フェデレーテッド・クラスタ内のクラスタ参加者間にSSL/TLSを構成するための構成

<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>ssl-federation</socket-provider>
  <topologies>
      <topology>
         <name>MyTopology</name>
      </topology>
   </topologies>
</federated-scheme>

mTLSを使用したフェデレーション
SSLを使用してフェデレーションを保護するための最も一般的で推奨される構成はmTLSです。<ssl>ソケット・プロバイダをmTLS用に構成するには、アイデンティティと信頼の両方を構成する必要があります。
一方向SSLを使用したフェデレーション
フェデレーション参加者に一方向SSLを構成して、参加者が別の参加者に接続する際に受信するサーバー証明書の信頼性を検証できるようにします。フェデレーション参加者は、接続してくるメンバーの信頼性を検証しません。

親トピック: SSL/TLSを使用した通信の保護

mTLSを使用したフェデレーション

SSLを使用してフェデレーションを保護するための最も一般的で推奨される構成はmTLSです。<ssl>ソケット・プロバイダをmTLS用に構成するには、アイデンティティと信頼の両方を構成する必要があります。

例6-32では、ソケット・プロバイダは、server.jksという名前のキーストアを含む<identity-manager>要素と、trust.jksという名前のキーストアを含む<trust-manager>要素で構成されます。デフォルトでは、<ssl>ソケット・プロバイダがアイデンティティと信頼の両方を指定して構成されている場合、CoherenceはmTLS用に構成されたJava SSLコンテキストを作成します。

ノート:

この構成で拡張使用が設定された証明書を使用する場合、拡張使用にはserverAuthとclientAuthの両方を含める必要があります。ソケット・プロバイダ構成は、フェデレーテッド・スキーム・サーバー・ソケット(他のフェデレーション参加者からの接続の受信に使用)とそのクライアント・ソケット(他のフェデレーション参加者への接続に使用)の両方で使用される単一のJava SSLコンテキストを構成するために使用されます。

例6-32 mTLSを介したフェデレーテッド・クラスタ通信を保護するための構成

<socket-provider>
   <ssl>
      <identity-manager>
         <key-store>
             <url>file:server.jks</url>
         </key-store>
      </identity-manager>
       <trust-manager>
         <key-store>
             <url>file:trust.jks</url>
         </key-store>
       </trust-manager>
   </ssl>
</socket-provider>

親トピック: SSLを使用したフェデレーション通信の保護

一方向SSLを使用したフェデレーション

フェデレーション参加者に一方向SSLを構成して、参加者が別の参加者に接続する際に受信するサーバー証明書の信頼性を検証できるようにします。フェデレーション参加者は、接続してくるメンバーの信頼性を検証しません。

フェデレーテッド・スキームに対して構成できるソケット・プロバイダは1つのみであるため、<ssl>ソケット・プロバイダは、mTLSの例と同じように、アイデンティティと信頼の両方を指定して構成する必要があります。一方向SSLを指定するには、<client-auth>要素を追加し、その値をnoneに設定します。

<client-auth>要素は、クライアントが証明書を送信する必要があるかどうかを決定するJava SSLコンテキストの対応する設定を構成するために使用されます。noneに設定すると、クライアントは証明書を送信しません(アイデンティティ・キーと証明書で構成されている場合でも)。

例6-33に、一方向SSL用のフェデレーテッド・スキーム・ソケット・プロバイダ構成を示します。

ノート:

例6-33 一方向SSL/TLSを介したフェデレーテッド・クラスタ通信を保護するための構成

<socket-provider>
   <ssl>
      <identity-manager>
         <key-store>
             <url>file:server.jks</url>
         </key-store>
      </identity-manager>
       <trust-manager>
         <key-store>
             <url>file:trust.jks</url>
         </key-store>
       </trust-manager>
<!-- This element changes the configuration to one-way SSL -->
       <client-auth>none<client-auth>
   </ssl>
 </socket-provider>

親トピック: SSLを使用したフェデレーション通信の保護

Coherence PeerX509アルゴリズム

Oracle Coherenceには、独自のピア信頼アルゴリズムであるPeerX509が含まれています。このアルゴリズムは、信頼マネージャ・キーストア内にある証明書の信頼(信頼のみ)を前提として機能します。また、TCMPのピアツーピア・プロトコル機能も利用します。具体的には、SSLネゴシエーションを成功させるには、受信した証明書が信頼マネージャによって保持されている証明書のいずれかと同じである必要があります。

PeerX509を構成するには、<trust-manager>要素に<algorithm>要素を設定します。

例6-34では、信頼マネージャはPeerX509アルゴリズムを使用します。アイデンティティ・マネージャと信頼マネージャの両方が、同じキーストアを使用するように構成されています。これは、すべてのクラスタ・メンバーが同じ構成を使用し、クライアントまたはサーバー・ソケットによって送信された証明書がトラスト・ストア内にあることが保証されるため、クラスタ・メンバーシップの保護に使用される場合のPeerX509の一般的なアプローチです。

ノート:

PeerX509はCoherence独自のアルゴリズムであり、Federal Information Processing Standards (FIPS)などの標準に準拠していません。制限の厳しい環境では使用できない場合があります。
信頼は、受信した証明書がトラスト・ストア内の証明書のいずれかに一致する場合に検証されます。拡張使用や証明書が署名されているかどうかなど、追加の証明書データのチェックはありません。

例6-34 信頼マネージャがPeerX509アルゴリズムを使用する構成

<socket-provider>
    <ssl>
        <identity-manager>
            <key-store>
                <url>file:server.jks</url>
            </key-store>
        </identity-manager>
        <trust-manager>
            <algorithm>PeerX509</algorithm>
            <key-store>
                <url>file:server.jks</url>
            </key-store>
        </trust-manager>
    </ssl>
</socket-provider>

親トピック: SSL/TLSを使用した通信の保護

グローバル・ソケット・プロバイダの指定

Coherenceオペレーション構成ファイルでグローバル・ソケット・プロバイダを構成できます。設定すると、Coherenceが作成するすべてのサーバーまたはクライアント・ソケットは、独自の特定のソケット・プロバイダでオーバーライドされていないかぎり、この構成を使用します。

Coherenceオペレーション構成ファイルで、<cluster-config>要素内に<global-socket-provider>要素を指定します。

例6-35では、オペレーション構成ファイルによって、mTLS用に構成されたmtls-configという名前のソケット・プロバイダが構成されます。その後、<global-socket-provider>要素がmtls-configに設定され、このソケット・プロバイダがどこでも使用されるようになります。

例6-35 グローバル・ソケット・プロバイダを指定するための構成

<?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>

      <global-socket-provider>mtls-config</global-socket-provider>

      <socket-providers>
         <socket-provider id=mtls-config">
           <ssl>
              <identity-manager>
                 <key-store>
                     <url>file:server.jks</url>
                 </key-store>
              </identity-manager>
               <trust-manager>
                 <key-store>
                     <url>file:trust.jks</url>
                 </key-store>
               </trust-manager>
           </ssl>
        </socket-provider>
      </socket-providers>
   </cluster-config>
</coherence>

デフォルトのオペレーション構成ファイルでは、システム・プロパティcoherence.global.socketprovider(または環境変数COHERENCE_GLOBAL_SOCKET_PROVIDER)を使用してグローバル・ソケット・プロバイダを設定できます。

例6-36のオペレーション構成では、双方向SSL用にmtls-configという名前のソケット・プロバイダが構成されますが、グローバル・ソケット・プロバイダ要素は設定されません。

例6-36 グローバル・ソケット・プロバイダを含まないソケット・プロバイダの構成

<?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=mtls-config">
           <ssl>
              <identity-manager>
                 <key-store>
                     <url>file:server.jks</url>
                 </key-store>
              </identity-manager>
               <trust-manager>
                 <key-store>
                     <url>file:trust.jks</url>
                 </key-store>
               </trust-manager>
           </ssl>
        </socket-provider>
      </socket-providers>
   </cluster-config>
</coherence>

Coherenceがシステム・プロパティ-Dcoherence.global.socketprovider=mtls-configを使用して起動された場合は、mtls-configソケット・プロバイダがグローバル・ソケット・プロバイダとして使用されます。

ノート:

グローバル・ソケット・プロバイダは、すべてのサーバーおよびクライアント・ソケットに使用されます。したがって、構成されるソケット・プロバイダは、サーバー・ソケットとクライアント・ソケットの両方に使用可能である必要があります。通常、これは、グローバル・ソケット・プロバイダをmTLS用に構成するか、または「一方向SSLを使用したクラスタ通信」で説明されているように一方向SSL用に構成することを意味します。

親トピック: SSL/TLSを使用した通信の保護

ソケット・プロバイダ構成でのパスワードの指定

Javaキーストアおよび秘密キーは、資格証明(通常はパスワード)で保護できます。ソケット・プロバイダ構成には、パスワードを指定するためのいくつかの方法があります。アプリケーション開発者は、必要なセキュリティのレベルと構成のシンプルさに基づいて、最適なアプローチを選択します。

プレーン・テキスト・パスワードの指定
<password>要素を使用して、XML構成でプレーン・テキスト・パスワードを直接指定できます。
Javaシステム・プロパティからのパスワード
Coherence構成システム・プロパティ置換機能を使用し、システム・プロパティを使用してパスワードを指定できます。<password>要素には、XML要素の値を取得するために使用するJavaシステム・プロパティを指定するオプションのsystem-property属性があります。
URLからのパスワードの読取り
<password-url要素を使用して、ファイル・システム上のファイルなどのURLからパスワードをロードできます。
カスタム・パスワード・プロバイダ
パスワード・プロバイダを使用すると、暗号化を使用するものを含め、任意のソースからSSLパスワードを取得できます。パスワード・プロバイダは、com.tangosol.net.PasswordProviderinterfaceを実装します。このクラスには、Java char配列としてパスワードを返すgetメソッドがあります。

親トピック: SSL/TLSを使用した通信の保護

プレーン・テキスト・パスワードの指定

<password>要素を使用して、XML構成でプレーン・テキスト・パスワードを直接指定できます。

XMLにプレーン・テキストのパスワードを直接構成することは、パスワードを指定する最も安全でない方法ですが、使いやすく、本番データにアクセスしない統合テストなどの場合によく使用されます。ただし、パスワードのハードコーディングは柔軟性にも欠けます。パスワードが変更されるたびに、構成ファイルを更新する必要があります。

例6-37では、<password>要素は、<identity-manager>要素内のキー・ストアのプレーン・テキスト・パスワードを指定します。

例6-37 プレーン・テキスト・パスワードを使用した構成

<identity-manager>
   <key-store>
       <url>file:server.jks</url>
   </key-store>
   <password>secret</password>
</identity-manager>

親トピック: ソケット・プロバイダ構成でのパスワードの指定

Javaシステム・プロパティからのパスワード

Coherence構成システム・プロパティ置換機能を使用し、システム・プロパティを使用してパスワードを指定できます。<password>要素には、XML要素の値を取得するために使用するJavaシステム・プロパティを指定するオプションのsystem-property属性があります。

例6-38では、<password>要素が暗号化された秘密キーを読み取るように構成されています。system-property属性はkey.credentialsに設定されているため、実行時にXML構成が解析されると、<password>システム・プロパティの値がパスワードとして使用されます。

システム・プロパティの使用は、プレーン・テキストやハードコードされたパスワードよりも柔軟性がありますが、特に安全というわけではありません。パスワードは、XMLがロードされてメモリー内のCoherence構成クラスにプレーン・テキストで格納された後、XMLに注入されます。

例6-38 Javaシステム・プロパティを使用してパスワードを指定するための構成

<identity-manager>
   <key>server.key</key>
   <cert>server.cert</cert>
   <password system-property=key.credentials/>
</identity-manager>

親トピック: ソケット・プロバイダ構成でのパスワードの指定

URLからのパスワードの読取り

<password-url要素を使用して、ファイル・システム上のファイルなどのURLからパスワードをロードできます。

例6-39は、ファイル・システム上のファイルからキーストアおよび秘密キーのパスワードを読み取るSSLソケット・プロバイダ構成を示しています。

アイデンティティ・マネージャのキーストア・パスワードは、/coherence/security/server-pass.txtfileから読み取られます。
アイデンティティ・マネージャによって使用される秘密キーは、/coherence/security/key-pass.txtfileから読み取られます。
信頼マネージャで使用されるキーストア・パスワードは、/coherence/security/trust-pass.txtfileから読み取られます。

例6-39ではファイルを使用していますが、読取り可能な任意の有効なURLを使用できます。たとえば、単純なHTTP URLを使用してWebサーバーからパスワードを取得できます。

例6-39 URLからパスワードを取得するための構成

<socket-provider>
   <ssl>
      <identity-manager>
         <key-store>
            <url>file:server.jks</url>
            <password-url>
              file:/coherence/security/server-pass.txt
            </password-url>
         </key-store>
         <password-url>
           file:/coherence/security/key-pass.txt
         </password-url>
      </identity-manager>
      <trust-manager>
         <key-store>
            <url>file:trust.jks</url>
            <password-url>
              file:/coherence/security/trust-pass.txt
            </password-url>
         </key-store>
      </trust-manager>
   </ssl>
</socket-provider>

親トピック: ソケット・プロバイダ構成でのパスワードの指定

カスタム・パスワード・プロバイダ

パスワード・プロバイダを使用すると、暗号化を使用するものを含め、任意のソースからSSLパスワードを取得できます。パスワード・プロバイダは、com.tangosol.net.PasswordProviderinterfaceを実装します。このクラスには、Java char配列としてパスワードを返すgetメソッドがあります。

例6-40に、パスワードchar配列を提供する単純なパスワード・プロバイダの実装を示します。実際のパスワード・プロバイダは、ハードコードされたchar配列よりも安全な場所からパスワードを取得します。

例6-40 パスワードchar配列を使用したカスタム・パスワード・プロバイダの実装

package com.example.security;

import com.tangosol.net.PasswordProvider;

public class GetPassword implements PasswordProvider {

    public GetPassword() {
    }

    @Override
    public char[] get()
        {
        return new char[]{'s', 'e', 'c', 'r', 'e', 't'};
        }
    }

<password-provider>要素を使用して、ソケット・プロバイダ構成でカスタム・パスワード・プロバイダを指定できます。<password-provider>要素内に完全な構成を指定するか、<password-provider>要素の値を、オペレーション構成ファイルの<password-providers>セクションで構成されているパスワード・プロバイダの名前に設定します。

例6-41では、例6-40のパスワード・プロバイダを使用して、アイデンティティ・マネージャ構成で秘密キーのパスワードを取得します。

例6-41 カスタム・パスワード・プロバイダを使用してパスワードを取得するための構成

<socket-provider>
   <ssl>
      <identity-manager>
         <key>server.key</key>
         <cert>server.cert</cert>
         <password-provider>
             <class-name>com.example.security.GetPassword</class-name>
         </password-provider>
      </identity-manager>
      <trust-manager>
         <key-store>
            <url>file:trust.jks</url>
         </key-store>
      </trust-manager>
   </ssl>
</socket-provider>

名前付きパスワード・プロバイダ参照

共通パスワード・プロバイダ構成を複数回使用する場合は、オペレーション構成ファイルの<password-providers>セクションで構成を1回指定し、ソケット・プロバイダ構成から名前付きプロバイダを参照する方が簡単です。

例6-42に、オペレーション構成ファイルの<password-providers>セクションに指定されたパスワード・プロバイダを示します。パスワード・プロバイダの名前はMyPasswordProviderです。

ソケット・プロバイダから名前付きパスワード・プロバイダを参照できるようになりました。

例6-42 ソケット・プロバイダからの参照用にパスワード・プロバイダに名前を付けるための構成

<?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>
      <password-providers>
          <password-provider id="MyPasswordProvider">
              <class-name>com.example.security.GetPassword</class-name>
          </password-provider>
      <password-providers>
   </cluster-config>
</coherence>

例6-43では、ソケット・プロバイダはMyPasswordProviderを使用して暗号化された秘密キー・ファイルの資格証明を指定します。

これにより、パスワードを柔軟に提供できます。ソケット・プロバイダ構成は、ハードコードされた値ではなく、名前付きパスワード・プロバイダを参照します。実行時に、異なるオペレーション構成ファイルを使用して、その名前付きプロバイダの異なる構成または実装を提供できます。

例6-43 カスタム・パスワード・プロバイダを使用して資格証明を提供するソケット・プロバイダの構成

<socket-provider>
    <ssl>
        <identity-manager>
            <key>server.key</key>
            <cert>server.cert</cert>
            <password-provider>
                <name>MyPasswordProvider</name>
            </password-provider>
        </identity-manager>
        <trust-manager>
            <key-store>
                <url>file:trust.jks</url>
            </key-store>
        </trust-manager>
    </ssl>
</socket-provider>

パラメータ化されたパスワード・プロバイダ

PasswordProvider実装は、コンストラクタ引数を使用するか、引数とともに静的ファクトリ・メソッドを使用してパラメータ化できます。

例6-44では、単純なPasswordProviderに単一のintパラメータを持つコンストラクタがあります。パラメータの値によって、返されるパスワードが決まります。実際のパスワード・プロバイダは、ハードコードされたchar配列よりも安全な場所からパスワードを取得します。

パスワード・プロバイダは、オペレーション構成ファイルの<password-providers>セクションで定義できます。

例6-44 パスワードを取得するためのパラメータ化されたパスワード・プロバイダの実装

package com.oracle.coherence.examples;

import com.tangosol.net.PasswordProvider;

public class GetPassword implements PasswordProvider {

    private final int param;

    public GetPassword(int param) {
        this.param = param;
    }

    @Override
    public char[] get()
        {
        if (param == 0) {
            return new char[]{'s', 'e', 'c', 'r', 'e', 't'};
        }
        return new char[]{'p', 'a', 's', 's', 'w', 'o', 'r', 'd'};
    }
}

例6-45では、例6-44のパスワード・プロバイダがMyPasswordProviderという名前で構成されています。<init-params>要素は、コンストラクタ・パラメータの指定に使用されます。ここでは、値が0(ゼロ)のpassword-idという名前の単一のintパラメータです。

ソケット・プロバイダから名前付きパスワード・プロバイダを参照できるようになりました。

例6-45 コンストラクタ・パラメータを指定するための構成

<?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>
      <password-providers>
          <password-provider id="MyPasswordProvider">
              <class-name>com.example.security.GetPassword</class-name>
              <init-params>
                  <init-param>
                      <param-name>password-id</param-type>
                      <param-value>0</param-value>
                  </init-param>
              </init-params>
          </password-provider>
      <password-providers>
   </cluster-config>
</coherence>

例6-46では、ソケット・プロバイダはMyPasswordProviderを使用して暗号化された秘密キー・ファイルの資格証明を提供します。ここでは、パスワード・プロバイダはパラメータ0(ゼロ)で構成されているため、int値0がコンストラクタに渡されます。

例6-46 パラメータ化されたパスワード・プロバイダを使用してパスワードを取得するための構成

<socket-provider>
    <ssl>
        <identity-manager>
            <key>server.key</key>
            <cert>server.cert</cert>
            <password-provider>
                <name>MyPasswordProvider</name>
            </password-provider>
        </identity-manager>
        <trust-manager>
            <key-store>
                <url>file:trust.jks</url>
            </key-store>
        </trust-manager>
    </ssl>
</socket-provider>

例6-47では、MyPasswordProviderが再度使用されますが、今回はpassword-idパラメータが1にオーバーライドされるため、int値1がパスワード・プロバイダ・コンストラクタに渡されます。

例6-47 パラメータ化されたパスワード・プロバイダを使用して、インライン・パラメータ・オーバーライドでパスワードを取得するための構成

<socket-provider>
    <ssl>
        <identity-manager>
            <key>server.key</key>
            <cert>server.cert</cert>
            <password-provider>
                <name>MyPasswordProvider</name>
                <init-params>
                    <init-param>
                        <param-name>password-id</param-name>
                        <param-value>1</param-value>
                    </init-param>
                </init-params>
            </password-provider>
        </identity-manager>
        <trust-manager>
            <key-store>
                <url>file:trust.jks</url>
            </key-store>
        </trust-manager>
    </ssl>
</socket-provider>

親トピック: ソケット・プロバイダ構成でのパスワードの指定

暗号スイートとプロトコル・バージョンの使用の制御

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>

親トピック: SSL/TLSを使用した通信の保護

ホスト名検証の使い方

Oracle Coherenceでのホスト名検証の構成方法について学びます。ホスト名検証では、クライアントの接続先URLのホスト名と、SSL接続の一部としてサーバーが返送するデジタル証明書のホスト名が一致していることを確認します。

ホスト名検証は、SSLクライアント(SSLクライアントとして機能しているCoherenceなど)がリモート・ホスト上のキャッシュ・サーバーに接続する場合に役立ちます。また、中間者攻撃を防ぐのに役立ちます。

Coherenceにはデフォルトのホスト名検証機能があります。また、カスタム・ホスト名検証を作成して使用することもできます。

この項には次のトピックが含まれます:

デフォルトのCoherenceホスト名検証の使用
デフォルトのCoherenceホスト名検証を使用する場合、証明書のホスト名がクライアントが接続しようとするホスト名と一致すると、ホスト名検証は合格します。
カスタム・ホスト名検証の使用
カスタム・ホスト名検証を使用する場合は、カスタム・ホスト名検証を実装するクラスを、Coherence (SSLクライアントとして機能する場合)またはスタンドアロンのSSLクライアントのCLASSPATHに指定する必要があります。

親トピック: SSL/TLSを使用した通信の保護

デフォルトのCoherenceホスト名検証の使用

デフォルトのCoherenceホスト名検証を使用する場合、証明書のホスト名がクライアントが接続しようとするホスト名と一致すると、ホスト名検証は合格します。

デフォルトのホスト名検証では、次の2つのフェーズでホスト名が検証されます:

ワイルドカードを使用した検証。
ワイルドカードを使用しない検証(ワイルドカードを使用した検証が失敗した場合)。

デフォルトでは、ホスト名検証は下位互換性のために有効になっていません。ただし、保護された本番モードではデフォルトで有効になっています。デフォルトのホスト名検証を有効または無効にするには、sslの<hostname-verifier>要素の説明を参照してください。

ワイルドカードを使用した検証

SSLセッションのサーバー証明書のホスト名でワイルドカードがサポートされている場合、CommonName属性は次の基準を満たす必要があります:

ドット('.')文字を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>要素の説明を参照してください。

親トピック: ホスト名検証の使い方

クライアント認証の構成

<client-auth>要素を使用して、SSL/TLSソケット・プロバイダで一方向SSL/TLS認証を使用するか双方向SSL/TLS認証を使用するかを指定できます。

<client-auth>を適用するには、XML構成で<identity-manager>と<trust-manager>要素の両方を使用してソケット・プロバイダを構成する必要があります。<trust-manager>が構成されていない場合は、一方向認証のみを使用できます。<trust-manager>が構成されている場合、Coherenceはデフォルトで双方向認証を使用します。

<client-auth> は、3つの有効な値を含む列挙です。

値	説明
`none`	ソケット・プロバイダはクライアントに認証証明書をリクエストしません。
`wanted`	ソケット・プロバイダがクライアントに認証証明書をリクエストしますが、クライアントが認証証明書を送信する必要はありません。 SSL/TLSソケットを管理するために、Coherenceによって作成されるJava SSL/TLSエンジンの`want client auth`設定に対応します。
`required`	クライアントが認証証明書を送信することがソケット・プロバイダにとって必要です。 SSL/TLSソケットを管理するために、Coherenceによって作成されるJava SSL/TLSエンジンの`need client auth`設定に対応します。

例6-48 一方向SSL/TLS認証のサンプル

<client-auth>要素がnoneに設定されているため、信頼マネージャが構成されている場合でも、Coherenceは一方向SSL/TLS認証を使用します。

この場合、SSL/TLSエンジンでは、want client authとneed client authの両方がfalseに設定されます。

...
<cluster-config>
   <socket-providers>
      <socket-provider id="mySSLConfig">
         <ssl>
            <protocol>TLS</protocol>
            <identity-manager>
               <key-store>
                  <url>file:server.jks</url>
                  <password>password</password>
               </key-store>
               <password>password</password>
            </identity-manager>
            <trust-manager>
               <key-store>
                  <url>file:trust.jks</url>
                  <password>password</password>
               </key-store>
            </trust-manager>
            <client-auth>none</client-auth>
         </ssl>
      </socket-provider>
   </socket-providers>
</cluster-config>

例6-49 オプションのクライアント認証のサンプル

<client-auth>要素がwantedに設定されているため、クライアントは証明書を送信できますが、送信する必要はありません。

この場合、SSL/TLSエンジンでは、want client authがtrueに設定され、need client authがfalseに設定されます。

...
<cluster-config>
   <socket-providers>
      <socket-provider id="mySSLConfig">
         <ssl>
            <protocol>TLS</protocol>
            <identity-manager>
               <key-store>
                  <url>file:server.jks</url>
                  <password>password</password>
               </key-store>
               <password>password</password>
            </identity-manager>
            <trust-manager>
               <key-store>
                  <url>file:trust.jks</url>
                  <password>password</password>
               </key-store>
            </trust-manager>
            <client-auth>wanted</client-auth>
         </ssl>
      </socket-provider>
   </socket-providers>
</cluster-config>

親トピック: SSL/TLSを使用した通信の保護

秘密キーおよび証明書ファイルの使用

Coherenceでは、秘密キーおよび証明書ファイルをキーストアにロードせずに直接使用することもサポートしています。「ソケット・プロバイダ構成でのパスワードの指定」の例では、Javaキーストア・ファイルを使用して、Coherence SSLで信頼およびアイデンティティの確立に使用される秘密キーおよび証明書を格納しました。

ノート:

デフォルトでは、CoherenceはJDKでサポートされているファイル形式のみをサポートしています。これらは、PEM形式の秘密キー・ファイル(ヘッダーが-----BEGIN RSA PRIVATE KEY-----または-----BEGIN ENCRYPTED PRIVATE KEY-----のファイル)およびX509証明書ファイル(ヘッダーが-----BEGIN CERTIFICATE-----のファイル)です。

親トピック: SSL/TLSを使用した通信の保護

アイデンティティ・マネージャの構成

ソケット・プロバイダの<identity-manager>要素を構成するときに、<keystore>要素のかわりに<key>要素と<cert>要素を使用して、秘密キーに証明書ファイルの場所を指定できます。<key>要素と<cert>要素両方の値はURLで、ここからキーまたは証明書データがロードされます。

例6-50は、/coherence/security/client.pemファイルからロードされた秘密キーと/coherence/security/client.certファイルからロードされた証明書を使用する<identity-manager>構成を示しています。

例6-50 秘密キーおよび証明書ファイルを使用するアイデンティティ・マネージャの例

<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-51は、/coherence/security/server-ca.certファイルからロードされた証明書を使用する<trust-manager>構成を示しています。

例6-51 証明書ファイルを使用する信頼マネージャの例

<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検証では、両方は許可されません。

親トピック: 秘密キーおよび証明書ファイルの使用

カスタム・キーストア、秘密キーおよび証明書ローダーの使用

Coherenceでは、キーストア、秘密キーおよび証明書を単純なURLまたはファイル以外のソースからロードすることをサポートし、様々なデータ形式を読み取るために、必要な外部ソースから必要なデータを読み取るようにカスタム・ローダーを構成する方法が提供されています。たとえば、クラウドでは、キーおよび証明書をシークレット・サービスに格納して、ファイルからロードせずにシークレットから直接ロードできます。GitHubのCoherence OCIプロジェクトには、Oracle Cloud (OCI) Secrets Serviceのシークレットからデータを読み取ることができるカスタム・キーストア、キーおよび証明書ローダーが含まれます。Coherence OCIを参照してください。

この項には次のトピックが含まれます:

親トピック: SSL/TLSを使用した通信の保護

カスタム・キーストア・ローダーの使用

Javaキーストアを使用している場合は、アプリケーション・コードにcom.tangosol.net.ssl.KeyStoreLoaderのインスタンスを実装し、<key-store>要素の子である<key-store-loader>要素内でそれを構成できます。このクラスは、必要な場所からJavaキーストアのコンテンツをロードできます。

例6-52は、KeyStoreLoaderインタフェースのカスタム実装を示しています。

例6-52 カスタム・キーストア・ローダー・クラス

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-53は、<trust-manager>構成でCustomKeyStoreLoaderクラスを使用する方法を示しています。

例6-53 カスタム・キーストア・ローダー・クラスを使用したアイデンティティ・マネージャの構成

<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-54は、<trust-manager>構成でCustomKeyStoreLoaderクラスを使用する方法を示しています。

例6-54 カスタム・キーストア・ローダー・クラスを使用した信頼マネージャの構成

<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-55は、CustomKeyStoreLoaderクラスをリファクタしてコンストラクタ引数を追加する方法を示しています。

例6-55 パラメータを使用したカスタム・キーストア・ローダー

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-56は、パラメータ化されたCustomKeyStoreLoaderクラスを構成する方法を示しています。構成の例では、パラメータfooおよびbarを使用してCustomKeyStoreLoaderコンストラクタがコールされます。

例6-56 パラメータを使用したカスタム・キーストア・ローダーの構成

<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-57は、カスタムKeyStoreLoader.loadにパラメータとして渡されるキーストア・タイプおよびパスワードを構成する方法を示しています。この例は<password>要素の使用を示していますが、<password-url>要素または<password-provider>要素を使用してローダーにパスワードを渡すこともできます。

例6-57 キーストア・タイプおよびパスワードをカスタム・キーストア・ローダーに渡す

<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-58は、カスタムPrivateKeyLoaderクラスを示しています。

例6-58 カスタム秘密キー・ローダー

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-59は、<identity-manager>要素でCustomPrivateKeyLoaderクラスを構成する方法を示しています。

例6-59 カスタム秘密キー・ローダーの構成

<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-60は、パスワードを使用した構成を示しています。この例では、PasswordProviderはURL file: /coherence/security/key-pass.txtからフェッチされたコンテンツをキー・パスワードとして返します。

例6-60 カスタム秘密キー・ローダーのパスワードの構成

<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-61は、カスタムCertificateLoaderクラスの例を示しています。証明書をロードするためにloadメソッドがコールされます。

例6-61 カスタム証明書ローダー

package com.acme.coherence;

public class CustomCertificateLoader
        implements CertificateLoader
    {
    @Override
    public Certificate[] load()
            throws GeneralSecurityException, IOException
        {
        // return a Certificate array
        }
    }

例6-62は、アイデンティティ・マネージャでCustomCertificateLoaderクラスを構成する方法を示しています。

例6-62 アイデンティティ・マネージャでのカスタム証明書ローダーの構成

<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-63は、信頼マネージャでCustomCertificateLoaderクラスを構成する方法を示しています。

例6-63 信頼マネージャでのカスタム証明書ローダーの構成

<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-64は、信頼マネージャで複数の<cert>ローダーおよびカスタム・ローダーを構成する方法を示しています。

例6-64 信頼マネージャでの複数の証明書およびローダーの構成

<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>

親トピック: カスタム・キーストア、秘密キーおよび証明書ローダーの使用

リフレッシュ可能なキーストア、秘密キーおよび証明書の使用

一部の環境では、キーや、TLSに使用される証明書は、比較的短い存続期間で作成されます。つまり、JVMを再起動しなくてもCoherenceアプリケーションでキーおよび証明書を更新できるのが理想的だということです。14.1.1.2206より前のCoherenceリリースでは、ソケット・プロバイダがインスタンス化されたときにキーストアが1回ロードされているため、この機能は使用できませんでした。Coherenceリリース14.1.1.2206以降では、リフレッシュ期間の指定が可能で、これにより、構成済のキーストア、秘密キーおよび証明書を再ロードするSSLコンテキストのリフレッシュがスケジュールされます。

リフレッシュ時間の構成には、<refresh-period>要素が使用されます。これはssl要素の子要素です。つまり、この設定はアイデンティティ・マネージャと信頼マネージャの両方に適用されます。

例6-65では、キーおよび証明書が24時間ごとにリフレッシュされるように、<refresh-period>要素を値24hで構成しています。

例6-65 リフレッシュ期間の構成

<socket-provider>
  <ssl>
    <identity-manager>
      <key>server.pem</key>
      <cert>server.cert</cert>
    </identity-manager>
    <refresh-period>24h</refresh-period>
  </ssl>
</socket-provider>

必要なSSLアーティファクトの新しいバージョンを外部ソースからプルできるように、リフレッシュ可能なキーストア、キーおよび証明書を、カスタム・キーストア・ローダー、秘密キー・ローダーおよび証明書ローダーと簡単に組み合せることができます。

リフレッシュ・ポリシーの構成

親トピック: SSL/TLSを使用した通信の保護

リフレッシュ・ポリシーの構成

リフレッシュ可能なキーおよび証明書を使用している場合、リフレッシュを行う必要があるかどうか判断するための追加のチェックを行うと役立つことがあります。このチェックを実行するには、<refresh-policy>および<refresh-period>を構成します。

<refresh-policy>要素は標準のCoherenceインスタンス構成であるため、com.tangosol.net.ssl.RefreshPolicyのインスタンスに解決する必要があります。スケジュールされたリフレッシュ時間に達すると、リフレッシュを先に進めるかどうかを決定するために、まず(RefreshPolicy.shouldRefresh()メソッドをコールして)ポリシーがチェックされます。

例6-66は、カスタムRefreshPolicy実装を示しています。

例6-66 カスタム・リフレッシュ・ポリシー・クラス

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-67は、<refresh-period>とともに<ssl>要素の一部としてカスタム・リフレッシュ・ポリシーを構成する方法を示しています。

例6-67 カスタム・リフレッシュ・ポリシーの構成

<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-68は、トラスト・ストア構成で使用される証明書を取得してから、証明書を使用して失効が近いかどうかを確認する方法を示しています。この例では、トラスト・ストアが作成されるときにtrustStoreLoadedメソッドがコールされ、トラスト・ストアで使用される証明書がポリシーに通知されます。次に、shouldRefreshメソッドで証明書をチェックして、次のリフレッシュ間隔でもまだ有効かどうかを判断できます。

例6-68 詳細なカスタム証明書リフレッシュ・ポリシー

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-69は、<ssl>構成でCustomRefreshPolicyクラスを構成する方法を示しています。

例6-69 カスタム証明書リフレッシュ・ポリシーの構成

<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>

親トピック: リフレッシュ可能なキーストア、秘密キーおよび証明書の使用