ヘッダーをスキップ
Oracle® Coherenceクライアント・ガイド
リリース3.6.1
B61370-02
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

5 Coherence*Extendの保護

Coherence*Extendには、Extendクライアントと拡張プロキシの間の通信を保護するために使用する一連の機能が含まれています。各機能のセキュリティ・レベルは様々で、必要に応じて実装できます。Coherenceの一般的なセキュリティについては、『Oracle Coherence開発者ガイド』の「Coherenceの保護」を参照してください。

この章は次の各項で構成されています。

クライアント接続の制限

拡張プロキシのデフォルトの動作では、Extendクライアントの接続がすべて受け入れられます。ホスト名またはIPアドレスに基づいてクライアント接続を許可するように、この動作を変更できます。特定のクライアントを受け入れるかどうかを判断するために、カスタマイズされたフィルタを作成することもできます。このタイプのアクセス制御は、クラスタにアクセスするクライアントが事前にわかっている環境に理想的です。

<authorized-host>要素を使用して、クラスタへのアクセスを許可するクライアントのホスト名またはIPアドレスを入力します。特定のアドレスを入力するには、<host-address>要素を使用します。アドレスの範囲を定義するには、<host-range>要素を使用します。

次の例では、IPアドレスが192.168.0.5か192.168.0.6であるか、または192.168.0.10から192.168.0.20の範囲内であるクライアントからの接続のみを受け入れるように拡張プロキシを構成します。

<proxy-scheme>
   <service-name>ExtendTcpProxyService</service-name>
   <thread-count>5</thread-count>
   <acceptor-config>
      <tcp-acceptor>
         ...
         <authorized-host>
            <host-address>192.168.0.5</host-address>
            <host-address>192.168.0.6</host-address>
            <host-range>
               <from-address>192.168.0.10</from-address>
               <to-address>192.168.0.20</to-address>
            </host-range>
         </authorized-host>
         ...
      </tcp-acceptor>
   </acceptor-config>
   <autostart>true</autostart>
</proxy-scheme>

フィルタ・クラスを使用して、特定のクライアントを受け入れるかどうかを判断することもできます。このクラスでは、com.tangosol.util.Filterインタフェースを実装する必要があります。インタフェースのevaluate()メソッドに、クライアントのjava.net.InetAddressが渡されます。クライアントの接続を許可するには、trueが返される必要があります。フィルタを有効にするには、<host-filter>要素内の<class-name>要素を使用して、完全修飾クラス名を入力します。<init-params>要素を使用して、実装クラスの初期化パラメータを設定することもできます。

次の例では、クライアントがクラスタに接続できるかどうかを判断する、MyFilterというフィルタを構成します。

<proxy-scheme>
   <service-name>ExtendTcpProxyService</service-name>
   <thread-count>5</thread-count>
   <acceptor-config>
      <tcp-acceptor>
         ...
         <authorized-host>
            <host-address>192.168.0.5</host-address>
            <host-address>192.168.0.6</host-address>
            <host-range>
               <from-address>192.168.0.10</from-address>
               <to-address>192.168.0.20</to-address>
            </host-range>
            <host-filter>
               <class-name>package.MyFilter</class-name>
               <init-params>
                  <init-param>
                     <param-name>sPolicy</param-name>
                     <param-value>strict</param-value>
                  </init-param>
               </init-params>
            </host-filter>
         </authorized-host>
         ...
      </tcp-acceptor>
   </acceptor-config>
   <autostart>true</autostart>
</proxy-scheme>

IDトークンを使用したクライアント接続の制限

IDトークンを使用して、クラスタにアクセスしないようにExtendクライアントを制限できます。このトークンは、接続が試行されるたびに、Extendクライアントと拡張プロキシの間で送信されます。有効なIDトークンを渡すExtendクライアントのみに、クラスタへのアクセスが許可されます。

Extendクライアントでは、IDトランスフォーマによってIDトークンが作成され、接続リクエストの一部として送信されます。クラスタ側では、IDアサータを使用してIDトークンを検証してから、接続を受け入れます。Coherence*Extendに含まれるデフォルトのIDトランスフォーマ(DefaultIdentityTransformer)およびIDアサータ(DefaultIdentityAsserter)では、サブジェクト(Java)またはプリンシパル(.NET)をIDトークンに使用します。カスタムのIDトランスフォーマおよびIDアサータを実装し、Coherenceオペレーション・オーバーライド・ファイルで有効にすることにより、デフォルト動作をオーバーライドできます。


注意:

  • IDトランスフォーマおよびIDアサータの実装クラスは、実行時に、Extendクライアントと拡張プロキシ・サーバーの両方のクラスパスに存在する必要があります。

  • POFで事前定義されているもの以外のセキュリティ・オブジェクト・タイプの使用方法の詳細は、「カスタム・セキュリティ・タイプの使用方法」を参照してください。

この項は、次のトピックで構成されています。

カスタムIDトランスフォーマの作成

IDトランスフォーマは、サブジェクトまたはプリンシパルを拡張プロキシに引渡し可能なIDトークンに変換する、クライアント側のコンポーネントです。IDトークンは、ID検証に便利なオブジェクトであれば、どんなタイプでもかまいません。既知のセキュリティ・タイプである必要はありません。実行時に、トークンはシリアライズされ、拡張接続リクエストの一部として送信されます。


注意:

Coherenceでシリアライズ可能なタイプのIDトークンは自動的にシリアライズされます。.NETクライアントおよびC++クライアントの場合は、POFタイプを使用する必要があります。POFで事前定義されているもの以外のセキュリティ・オブジェクト・タイプの使用方法の詳細は、「カスタム・セキュリティ・タイプの使用方法」を参照してください。

JavaおよびC++の場合、IDトランスフォーマではIdentityTransformerインタフェースを実装する必要があります。C#クライアントではIIdentityTransformerインタフェースを実装します。

例5-1は、クライアントからプロキシにアクセスするためのパスワードの入力を要求することによって、クライアント・アクセスを制限するJavaの実装です。IdentityTransformerは、クライアントのシステム・プロパティからパスワードを取得して、それをIDトークンとして返します。

例5-1 IDトランスフォーマの実装のサンプル

import com.tangosol.net.security.IdentityTransformer;
import javax.security.auth.Subject;
 
public class PasswordIdentityTransformer 
        implements IdentityTransformer
    {
    public Object transformIdentity(Subject subject)
            throws SecurityException
        {
        return System.getProperty("mySecretPassword");
        }
    }

クライアント認証がすでに完了している場合は、プリンシパル名をパスワードとして、新しいプリンシパルをサブジェクトに追加できます。Principalというパスワードをサブジェクトに追加するには、JAAS認証時に、既存のJAASログイン・モジュールを変更するか、またはPrincipalというパスワードを追加する必要なログイン・モジュールを追加します。JAASには、それぞれサブジェクトを変更できる複数のログイン・モジュールを含めることができます。同様に、.NETでもパスワードIDをプリンシパルに追加できます。その後、クラスタ側のアサータで、通常のプリンシパルを検証し、さらにPrincipalというパスワードを検証します。「カスタムIDアサータの作成」を参照してください。

カスタムIDトランスフォーマの有効化

IDトランスフォーマの実装をクライアント側のtangosol-coherence-override.xmlファイルで、<security-config>ノード内の<identity-transformer>要素を使用して有効にします。この要素には、実装クラスの完全な名前を含める必要があります。例:

<coherence>
   <security-config>
      <identity-transformer>
        <class-name>com.my.PasswordIdentityTransformer</class-name>
      </identity-transformer>
   </security-config>
</coherence>

カスタムIDアサータの作成

IDアサータは、拡張プロキシ・サービスをホストしているキャッシュ・サーバー上に存在する、クラスタ側のコンポーネントです。アサータでは、Extendクライアント上でIDトランスフォーマによって作成されたIDトークンを検証します。Extendクライアントで接続が開始されると、トークンが渡されます。検証が失敗すると、接続が拒否され、セキュリティ例外がスローされます。トランスフォーマとアサータは、既存の接続内で新しいチャネルが作成されたときにも起動します。JavaおよびC++の場合、IDアサータではIdentityAsserterインタフェースを実装する必要があります。C#クライアントではIIdentityAsserterインタフェースを実装します。

例5-2は、セキュリティ・トークンをチェックして有効なパスワードが指定されたことを確認するJavaの実装です。この場合、パスワードは、キャッシュ・サーバーのシステム・プロパティに対してチェックされます。このアサータの実装は、例5-1のIDトランスフォーマのサンプルで使用されています。

例5-2 IDアサータの実装のサンプル

import com.tangosol.net.security.IdentityAsserter;
import javax.security.auth.Subject;
 
 
public class PasswordIdentityAsserter 
        implements IdentityAsserter
    {
    public Subject assertIdentity(Object oToken)
            throws SecurityException
        {
        if (oToken instanceof String)
            {
            if (((String) oToken).equals(System.getProperty("mySecretPassword")))
                {
                return null;
                }
            }
        throw new SecurityException("Access denied");
        }
    }

IDアサータを作成する際は、多数のバリエーションが考えられます。たとえば、アサータでは、プリンシパルのリストに基づいて接続を拒否する、プリンシパルのロールをチェックする、署名付きのプリンシパル名を検証する、などの処理が可能です。アサータでは、正しいIDであることが確認できない接続試行をすべてブロックできます。

カスタムIDアサータの有効化

IDアサータの実装は、クラスタ側のtangosol-coherence-override.xmlファイルで、<security-config>ノード内の<identity-asserter>要素を使用して有効にします。この要素には、実装クラスの完全な名前を含める必要があります。例:

<coherence>
   <security-config>
      <identity-asserter>
        <class-name>com.my.PasswordIdentityAsserter</class-name>
      </identity-asserter>
   </security-config>
</coherence>

カスタム・セキュリティ・タイプの使用方法

セキュリティ・オブジェクトは、Extendクライアントと拡張プロキシの間で渡されるときに、Portable Object Format(POF)を使用して自動的にシリアライズまたはデシリアライズされます。POFで事前定義されているタイプのセキュリティ・オブジェクトは、構成やプログラムを変更せずに使用できます。POFで事前定義されていないカスタム・タイプのセキュリティ・オブジェクト(Kerberos認証を使用している場合など)は、エラーの原因となります。

カスタム・セキュリティ・タイプに関しては、カスタム・タイプを変換するか、POFでタイプを定義するかを、アプリケーションで選択できます。

タイプを変換する場合

この方法では、カスタムIDトランスフォーマで、カスタム・セキュリティ・オブジェクト・タイプを、文字配列や文字列などPOF用に事前定義されているタイプに変換してから、オブジェクト・トークンとして返します。プロキシ・サーバーでは、カスタムIDアサータによって、検証後にサブジェクトに再度変換されます。

たとえば、あるサブジェクトに、シリアライズされない資格証明が含まれているとします。IDトランスフォーマでは、この資格証明を抽出し、文字配列に変換して、その配列をトークンとして返します。プロキシ・サーバーでは、IDアサータによって文字配列を適切な資格証明タイプに変換し、検証してから、サブジェクトを構成して返します。

POFでカスタム・タイプを定義する場合

この方法では、POF構成ファイルでカスタム・セキュリティ・タイプを定義します。タイプは、クライアントのPOF構成ファイルとプロキシ・サーバー上のPOF構成ファイルの両方で定義する必要があります。

JavaでのPOFの使用方法の詳細は、『Oracle Coherence開発者ガイド』の「Portable Object Formatの使用」を参照してください。C++およびC#でのPOFの使用方法の詳細は、それぞれ、第11章「C++クライアントの統合オブジェクトの構築」および第20章「.NETクライアントの統合オブジェクトの構築」を参照してください。

カスタムIDトークンの相互運用性について

カスタムIDトークンを使用するソリューションでは、Extendクライアントから送信可能なトークンと、拡張プロキシで受信可能なトークンを常に考慮する必要があります。このことは、ローリング・アップグレードの際や、カスタムIDトークンのソリューションをロールアウトする際に、特に重要です。

Coherenceのアップグレード

Coherenceをアップグレードする際に、相互運用性の問題が発生する場合があります。この場合、複数の異なるバージョンのクライアントが、複数の異なるバージョンのプロキシ・サーバーと相互運用されている可能性があります。特に、次のような場合があります。

  • 3.5 Extendクライアントが3.6拡張プロキシに接続する場合、拡張プロキシに実装されているカスタムIDアサータでは、3.5 Extendクライアントから送信されたIDトークンを処理できる必要があります。3.5 Extendクライアントでは、nullトークンまたはSubjectが送信されます。カスタムIDアサータには、これらのトークン・タイプと、3.6 Extendクライアントからのカスタム・トークンの両方を処理する準備が必要です。

  • 逆に、3.6 Extendクライアントが3.5拡張プロキシに接続する場合、クライアントでは、3.5拡張プロキシで処理できないトークンを送信するカスタムIDトランスフォーマを使用しないでください。クライアントはnullトークンかSubjectのいずれかを送信する必要があります。

カスタムIDトークンのロールアウト

カスタムIDトークンのソリューションをロールアウトする際に、Extendクライアントと拡張プロキシの間で相互運用性の問題が発生する場合があります。この場合、カスタムIDアサータを使用するために拡張プロキシが移行されるため、ロールアウトが完了するまで、デフォルトのアサータを引き続き使用するプロキシがあります。同様に、カスタムIDトランスフォーマを使用するためにExtendクライアントが移行されるため、ロールアウトが完了するまで、デフォルトのトランスフォーマを引き続き使用するクライアントがあります。いずれの場合も、Extendクライアントと拡張プロキシでは、ロールアウトが完了するまでの間、nullトークンまたはSubjectを処理できる必要があります。

このようなシナリオに対する方針として、クライアントの更新時に、nullトークンまたはSubjectトークンを一時的に受け入れるカスタムIDアサータを用意することが考えられます。IDアサータでは、外部ソースで、これらのトークンが受け入れられるかどうかを示すポリシーをチェックできます。すべてのクライアントがカスタム・トークンを使用するように更新されたら、ポリシーを変更すれば、IDアサータでこれらのトークンが受け入れられなくなります。

IDと拡張サービスの関連付け

サブジェクトのスコープを設定すると、クライアントに返されるリモート・キャッシュおよびリモート起動のサービス参照を、現在のセキュリティ・コンテキストのIDと関連付けできます。クライアントでは、プラットフォーム固有の認証APIを使用してセキュリティ・コンテキストを確立します。クライアントでNamedCacheインスタンスおよびInvocationServiceインスタンスが作成されるたびに、サブジェクトまたはプリンシパルが、現在のセキュリティ・コンテキストから取得されます。その後は、すべてのリクエストが、確立されたサブジェクトまたはプリンシパルのコンテキストで実行されます。


注意:

POFで事前定義されているもの以外のセキュリティ・オブジェクト・タイプの使用方法の詳細は、「カスタム・セキュリティ・タイプの使用方法」を参照してください。

たとえば、"trader"ユーザーがCacheFactory.getCache("trade-cache")をコールし、"manager"ユーザーがCacheFactory.getCache("trade-cache")をコールする場合、各ユーザーは別々のリモート・キャッシュ参照オブジェクトを取得します。IDはそのリモート・キャッシュ参照に関連付けられるため、認可するかどうかは、コール元のIDに基づいて決定できます。認可の実装の詳細は、次の「認可の実装」を参照してください。

サブジェクトのスコープ設定は、デフォルトでは無効です。この機能は、クライアント側のtangosol-coherence-override.xmlファイルで、<security-config>ノード内の<subject-scope>要素を使用して有効にします。次の例では、サブジェクトのスコープ設定を有効にして、各サブジェクトが一意なリモート・キャッシュおよびリモート起動のサービス参照を取得するように指定します。

<coherence>
   <security-config>
      <subject-scope>true<subject-scope>
   </security-config>
</coherence>

認可の実装

認可は、特定のユーザーが実行可能なアクションを、ユーザーのアクセス制御権限に基づいて制御するために使用します。Coherence*Extendでは、認可はインターセプタ・クラスを使用して実装されます。拡張プロキシがインターセプタ・クラスをコールしてから、クライアントがプロキシ設定されたリソース(キャッシュ、キャッシュ・サービス、起動サービス)にアクセスします。インターセプタ・クラスは実装に固有であり、必要な認可ロジックを指定してからプロキシ設定されたリソースにリクエストを渡す必要があります。

この項は、次のトピックで構成されています。

この項のコード・サンプルは、Javaの認可例に基づいています。これは、ドキュメント・ライブラリの一部であるCoherenceの例に含まれています。この例は、クライアント・リクエストから取得したプリンシパルとロールベースのポリシーを使用して、リクエストされたサービスへの操作を許可するかどうかを決定する、基本的な認可の実装を示しています。完全な実装を確認するには、例をダウンロードしてください。

認可インターセプタ・クラスの作成

CacheServiceインタフェースとInvocationServiceインタフェースを実装することにより、プロキシ設定されたキャッシュ・サービス用とプロキシ設定された起動サービス用の両方のインターセプタ・クラスをそれぞれ作成できます。ただし、一連のラッパー・クラスは、通常は認可を実装するときに拡張されます(com.tangosol.net.WrapperCacheServiceとcom.tangosol.net.cache.WrapperNamedCache、およびcom.tangosol.net.WrapperInvocationService)。ラッパー・クラスは、それぞれのインタフェースに委任します。これにより、ラップされたインタフェース・メソッドにアクセス制御を適用するインターセプタ・クラスを便利な方法で作成できます。

例5-3は、Coherenceの例からの抜粋であり、WrapperCacheServiceを拡張することによってプロキシ設定されたキャッシュ・サービスの認可インターセプタ・クラスを作成する方法を示しています。CacheServiceメソッドはすべてプロキシ上でラップされ、Extendクライアントから渡されたサブジェクトに基づいてアクセス制御が適用されます。この実装では、指定したロールを持つプリンシパルのみが、ラップされたCacheServiceにアクセスできます。

例5-3 認可用WrapperCacheServiceクラスの拡張

public class EntitledCacheService
   extends WrapperCacheService
   {
   public EntitledCacheService(CacheService service)
       {
       super(service);
       }

   public NamedCache ensureCache(String sName, ClassLoader loader)
      {
      SecurityExampleHelper.checkAccess(SecurityExampleHelper.ROLE_READER);
      return new EntitledNamedCache(super.ensureCache(sName, loader));
      }

   public void releaseCache(NamedCache map)
      {
      if (map instanceof EntitledNamedCache)
         {
         EntitledNamedCache cache =  (EntitledNamedCache) map;
         SecurityExampleHelper.checkAccess(SecurityExampleHelper.ROLE_READER);
         map = cache.getNamedCache();
         }
      super.releaseCache(map);
      }

   public void destroyCache(NamedCache map)
      {
      if (map instanceof EntitledNamedCache)
         {
         EntitledNamedCache cache =  (EntitledNamedCache) map;
         SecurityExampleHelper.checkAccess(SecurityExampleHelper.ROLE_ADMIN);
         map = cache.getNamedCache();
         }
      super.destroyCache(map);
      }
}

このクラスには、名前付きキャッシュ実装が必要です。この例では、WrapperNamedCacheクラスが拡張され、NamedCacheインスタンスの各メソッドをラップします。これにより、様々なキャッシュ操作にアクセス制御を適用できます。例5-4は、Coherenceの例から抜粋したコードであり、NamedCacheメソッドをオーバーライドしてアクセス・チェックを適用してからメソッドの実行を許可する方法を示しています。クラスの詳細は、Coherenceの例を参照してください。

例5-4 認可用WrapperNamedCacheクラスの拡張

public class EntitledNamedCache
   extends WrapperNamedCache
   {
   public EntitledNamedCache(NamedCache cache)
      {
       super(cache, cache.getCacheName());
      }

   public Object put(Object oKey, Object oValue, long cMillis)
      {
      SecurityExampleHelper.checkAccess(SecurityExampleHelper.ROLE_WRITER);      return super.put(oKey, oValue, cMillis);
      }

   public Object get(Object oKey)
      {
      SecurityExampleHelper.checkAccess(SecurityExampleHelper.ROLE_READER);
      return super.get(oKey);
      }

   public void destroy()
      {
      SecurityExampleHelper.checkAccess(SecurityExampleHelper.ROLE_ADMIN);
      super.destroy();
      }
...

例5-5は、Coherenceの例からの抜粋であり、WrapperInvocationServiceを拡張することによってプロキシ設定された起動サービスの認可インターセプタ・クラスを作成する方法を示しています。InvocationServiceメソッドはすべてプロキシ上でラップされ、Extendクライアントから渡されたサブジェクトに基づいてアクセス制御が適用されます。この実装では、指定したロール名のプリンシパルのみが、ラップされたInvocationServiceにアクセスできます。

例5-5 認可用WrapperInvocationServiceクラスの拡張

public class EntitledInvocationService
   extends WrapperInvocationService
   {
   public EntitledInvocationService(InvocationService service)
      {
      super(service);
      }

   public void execute(Invocable task, Set setMembers, InvocationObserver 
      observer)
      {
      SecurityExampleHelper.checkAccess(SecurityExampleHelper.ROLE_WRITER)
      super.execute(task, setMembers, observer);
      }

   public Map query(Invocable task, Set setMembers)
      {
      SecurityExampleHelper.checkAccess(SecurityExampleHelper.ROLE_WRITER)
      return super.query(task, setMembers);
      }
}

クライアントでリモート起動サービスを使用しようとすると、プロキシは、プロキシ設定されたInvocationServiceインスタンスではなく、EntitledInvocationServiceクラスでquery()メソッドをコールします。EntitledInvocationServiceクラスによって、コールを許可するか拒否するかが決定されます。コールが許可された場合は、プロキシ設定されたInvocationServiceインスタンスでquery()メソッドをコールします。

認可インターセプタ・クラスの有効化

プロキシ設定されたキャッシュ・サービスおよびプロキシ設定された起動サービスのインターセプタ・クラスは、それぞれ<cache-service-proxy>要素内および<invocation-service-proxy>要素内のプロキシ・スキーム定義で有効にします。<class-name>要素を使用して、インターセプタ・クラスの完全修飾名を入力します。クラスに必要な初期化パラメータは、<init-params>要素を使用して指定できます。これらの要素の使用方法の詳細は、『Oracle Coherence開発者ガイド』のcache-service-proxyおよびinvocation-service-proxyに関する項を参照してください。

次の例は、プロキシ設定されたキャッシュ・サービスとプロキシ設定された起動サービスの両方のインターセプタ・クラスを有効にする方法を示しています。この例では、例5-3と例5-5で作成したインターセプタ・クラスを使用しています。

<proxy-scheme>
   ...
   <proxy-config>
      <cache-service-proxy>
         <class-name>
            com.tangosol.examples.security.EntitledCacheService
         </class-name>
         <init-params>
            <init-param>
               <param-type>com.tangosol.net.CacheService</param-type>
               <param-value>{service}</param-value>
            </init-param>
         </init-params>
      </cache-service-proxy>
      <invocation-service-proxy>
      <class-name>
         com.tangosol.examples.security.EntitledInvocationService
      </class-name>
      <init-params>
         <init-param>
            <param-type>com.tangosol.net.InvocationService</param-type>
            <param-value>{service}</param-value>
         </init-param>
      </init-params>
   </invocation-service-proxy>
</proxy-config>

SSLを使用したクライアント通信の保護

Extendクライアントと拡張プロキシの間の通信は、SSLを使用して保護できます。SSLには、クライアント側とクラスタ側の両方での構成が必要です。SSLは、Javaクライアントと.NETクライアントではサポートされていますが、C++ではサポートされていません。SSLに不慣れな場合は、『Oracle Coherence開発者ガイド』のCoherenceにおけるSSLの使用方法に関する項を参照してください。SSLの一般的な概念の簡単な概要と、より詳細なSSLリソースへのリンクが記載されています。

この項の構成例は、すべてのクライアントおよびサーバーの有効なデジタル証明書が必要に応じて作成済であることと、証明書に認証局(CA)の署名が付いていることを前提としています。デジタル証明書はアイデンティティ・ストアに配置する必要があり、トラスト・ストアには署名元のCAのデジタル証明書を含める必要があります。開発中は、必要に応じて自己署名付きの証明書を使用できます。

この項は、次のトピックで構成されています。

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

SSLをクラスタ側のキャッシュ構成ファイルで構成するには、プロキシ・サービス用のSSLソケット・プロバイダを定義します。SSLソケット・プロバイダの構成には、必要な粒度レベルに応じて、次の2つのオプションがあります。

  • プロキシ・サービスごと – プロキシ・サービスごとに、SSLソケット・プロバイダの構成を定義するか、オペレーション構成ファイルに含まれている事前定義済の構成を参照します。

  • すべてのプロキシ・サービス – すべてのプロキシ・サービスで同じグローバルなSSLソケット・プロバイダの構成を使用します。独自の構成を提供するプロキシ・サービスでは、グローバル構成がオーバーライドされます。グローバル構成では、オペレーション構成ファイルに含まれている事前定義済の構成を参照することもできます。

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

プロキシ・サービス用にSSLソケット・プロバイダを構成するには、各<proxy-scheme>定義の<tcp-acceptor>要素内に<socket-provider>要素を追加します。<socket-provider>要素の詳細は、『Oracle Coherence開発者ガイド』のsocket-providerに関する項を参照してください。

例5-6は、<protocol>要素および<algorithm>要素にデフォルト値(それぞれ、TLSおよびSunX509)を使用するSSLソケット・プロバイダを構成するプロキシ・スキームを示しています。これらは完全を期して示しますが、デフォルト値使用の際には省略できます。

例5-6では、IDキー・ストア(server.jks)とトラスト・キー・ストア(trust.jks)の両方を構成します。これは典型的な双方向SSL認証であり、クライアントとプロキシの双方が、それぞれのデジタル証明書を交換し、互いのIDを確認する必要があります。一方向SSL認証の場合は、プロキシ・サーバーの構成にIDキー・ストアを含める必要がありますが、トラスト・キー・ストアは含める必要がありません。

例5-6 クラスタ側のSSL構成のサンプル

...
<caching-schemes>
   ...
   <proxy-scheme>
      <service-name>ExtendTcpSSLProxyService</service-name>
      <acceptor-config>
         <tcp-acceptor>
            <local-address>
               <address>192.168.1.5</address>
               <port>9099</port>
            </local-address>
            <socket-provider>
               <ssl>
                  <protocol>TLS</protocol>
                  <identity-manager>
                     <algorithm>SunX509</algorithm>
                     <key-store>
                        <url>file:server.jks</url>
                        <password>password</password>
                        <type>JKS</type>
                     </key-store>
                     <password>password</password>
                  </identity-manager>
                  <trust-manager>
                     <algorithm>SunX509</algorithm>
                     <key-store>
                        <url>file:trust.jks</url>
                        <password>password</password>
                        <type>JKS</type>
                     </key-store>
                  </trust-manager>
               </ssl>
            </socket-provider>
         </tcp-acceptor>
      </acceptor-config>
      <autostart>true</autostart>
   </proxy-scheme>
   ...
</caching-schemes>
...

次の例では、オペレーション・デプロイメント・ディスクリプタの<socket-providers>ノードで定義されているSSLソケット・プロバイダの構成を、構成のid属性(ssl)を指定することによって参照します。<socket-providers>要素の詳細は、『Oracle Coherence開発者ガイド』のsocket-providersに関する項を参照してください。


注意:

出荷の際には、事前定義のSSLソケット・プロバイダはオペレーション・デプロイメント・ディスクリプタに含まれており、sslという名前になっています。事前定義済SSLソケット・プロバイダは、双方向SSL接続用に構成されており、信頼されているピアがすべて単一のJKSキー・ストア内に存在するピア信頼に基づいています。事前定義済SSLソケット・プロバイダの使用方法の詳細は、『Oracle Coherence開発者ガイド』の事前定義済SSLソケット・プロバイダの使用方法に関する項を参照してください。別のSSLソケット・プロバイダを構成するには、オペレーション・オーバーライド・ファイルを使用して事前定義済SSLソケット・プロバイダを変更するか、必要に応じて新しいソケット・プロバイダの構成を作成します。		 

...
<caching-schemes>
   ...
   <proxy-scheme>
      <service-name>ExtendTcpSSLProxyService</service-name>
      <acceptor-config>
         <tcp-acceptor>
            <local-address>
               <address>192.168.1.5</address>
               <port>9099</port>
            </local-address>
            <socket-provider>ssl</socket-provider>
         </tcp-acceptor>
      </acceptor-config>
      <autostart>true</autostart>
   </proxy-scheme>
</caching-schemes>
...

すべてのプロキシ・サービス用SSLソケット・プロバイダの構成

すべてのプロキシ・サービスで使用するグローバルなSSLソケット・プロバイダを構成するには、キャッシュ構成ファイルの<defaults>要素内にある<socket-provider>要素を使用します。この方法を使用すると、プロキシ・スキーム定義内での追加の構成は不要です。<default>要素の詳細は、『Oracle Coherence開発者ガイド』のdefaultsに関する項を参照してください。

次の例では、例5-6と同じSSLソケット・プロバイダの構成を使用して、これをすべてのプロキシ・サービス用に構成します。

<cache-config>
   <defaults>
      <socket-provider>
         <ssl>
            <protocol>TLS</protocol>
            <identity-manager>
               <algorithm>SunX509</algorithm>
               <key-store>
                  <url>file:server.jks</url>
                  <password>password</password>
                  <type>JKS</type>
               </key-store>
               <password>password</password>
            </identity-manager>
            <trust-manager>
               <algorithm>SunX509</algorithm>
               <key-store>
                  <url>file:trust.jks</url>
                  <password>password</password>
                  <type>JKS</type>
               </key-store>
            </trust-manager>
         </ssl>
      </socket-provider>
   </defaults>
   ...

次の例では、オペレーション・デプロイメント・ディスクリプタで定義されているSSLソケット・プロバイダの構成を参照することによって、グローバルなSSLソケット・プロバイダを構成します。

<cache-config>
   <defaults>
      <socket-provider>ssl</socket-provider>
   </defaults>
   ...

Javaクライアント側のSSLソケット・プロバイダの構成

SSLをクライアント側のキャッシュ構成ファイルで構成するには、リモート・キャッシュ・スキーム用、また必要に応じてリモート起動スキーム用のSSLソケット・プロバイダを定義します。SSLソケット・プロバイダの構成には、必要な粒度レベルに応じて、次の2つのオプションがあります。

  • リモート・サービスごと – リモート・サービスごとに、SSLソケット・プロバイダの構成を定義するか、オペレーション構成ファイルに含まれている事前定義済の構成を参照します。

  • すべてのリモート・サービス – すべてのリモート・サービスで同じグローバルなSSLソケット・プロバイダの構成を使用します。独自の構成を提供するリモート・サービスでは、グローバル構成がオーバーライドされます。グローバル構成では、オペレーション構成ファイルに含まれている事前定義済の構成を参照することもできます。

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

リモート・サービス用にSSLソケット・プロバイダを構成するには、リモート・スキームの定義の<tcp-initiator>要素内に<socket-provider>要素を追加します。<socket-provider>要素の詳細は、『Oracle Coherence開発者ガイド』のsocket-providerに関する項を参照してください。

例5-7は、SSLを使用するソケット・プロバイダを構成するリモート・キャッシュ・スキームを示しています。この例では、<protocol>要素および<algorithm>要素にデフォルト値(それぞれ、TLSおよびSunX509)を使用しています。これらは完全を期して示しますが、デフォルト値使用の際には省略できます。

例5-7では、IDキー・ストア(server.jks)とトラスト・キー・ストア(trust.jks)の両方を構成します。これは典型的な双方向SSL認証であり、クライアントとプロキシの双方が、それぞれのデジタル証明書を交換し、互いのIDを確認する必要があります。一方向SSL認証の場合は、クライアントの構成にトラスト・キー・ストアを含める必要がありますが、IDキー・ストアは含める必要がありません。つまり、クライアントは、プロキシに対してデジタル証明書を渡すことはなく、匿名のままということです。クライアントのトラスト・キー・ストアには、プロキシのデジタル証明書に署名する際に使用したCAのデジタル証明書を含める必要があります。

例5-7 Javaクライアント側のSSL構成のサンプル

<?xml version="1.0"?>
<!DOCTYPE cache-config SYSTEM "cache-config.dtd">
<cache-config>
   <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>
               <remote-addresses>
                  <socket-address>
                     <address>198.168.1.5</address>
                     <port>9099</port>
                  </socket-address>
               </remote-addresses>
               <socket-provider>
                  <ssl>
                     <protocol>TLS</protocol>
                     <identity-manager>
                        <algorithm>SunX509</algorithm>
                        <key-store>
                           <url>file:server.jks</url>
                           <password>password</password>
                           <type>JKS</type>
                        </key-store>
                        <password>password</password>
                     </identity-manager>
                     <trust-manager>
                        <algorithm>SunX509</algorithm>
                        <key-store>
                           <url>file:trust.jks</url>
                           <password>password</password>
                           <type>JKS</type>
                        </key-store>
                     </trust-manager>
                  </ssl>
               </socket-provider>
               <connect-timeout>10s</connect-timeout>
            </tcp-initiator>
            <outgoing-message-handler>
               <request-timeout>5s</request-timeout>
            </outgoing-message-handler>
         </initiator-config>
      </remote-cache-scheme>
   </caching-schemes>
</cache-config>

次の例では、オペレーション・デプロイメント・ディスクリプタの<socket-providers>ノードで定義されているSSLソケット・プロバイダの構成を、構成のid属性(ssl)を指定することによって参照します。<socket-providers>要素の詳細は、『Oracle Coherence開発者ガイド』のsocket-providersに関する項を参照してください。


注意:

出荷の際には、事前定義のSSLソケット・プロバイダはオペレーション・デプロイメント・ディスクリプタに含まれており、sslという名前になっています。事前定義済SSLソケット・プロバイダは、双方向SSL接続用に構成されており、信頼されているピアがすべて単一のJKSキー・ストア内に存在するピア信頼に基づいています。事前定義済SSLソケット・プロバイダの使用方法の詳細は、『Oracle Coherence開発者ガイド』の事前定義済SSLソケット・プロバイダの使用方法に関する項を参照してください。別のSSLソケット・プロバイダを構成するには、オペレーション・オーバーライド・ファイルを使用して事前定義済SSLソケット・プロバイダを変更するか、必要に応じて新しいソケット・プロバイダの構成を作成します。		 

<?xml version="1.0"?>
<!DOCTYPE cache-config SYSTEM "cache-config.dtd">
<cache-config>
   <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>
               <remote-addresses>
                  <socket-address>
                     <address>198.168.1.5</address>
                     <port>9099</port>
                  </socket-address>
               </remote-addresses>
               <socket-provider>ssl</socket-provider>
               <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>要素を使用します。この方法を使用すると、リモート・スキーム定義内での追加の構成は不要です。<default>要素の詳細は、『Oracle Coherence開発者ガイド』のdefaultsに関する項を参照してください。

次の例では、例5-7と同じSSLソケット・プロバイダの構成を使用して、これをすべてのリモート・サービス用に構成します。

<cache-config>
   <defaults>
      <socket-provider>
         <ssl>
            <protocol>TLS</protocol>
            <identity-manager>
               <algorithm>SunX509</algorithm>
               <key-store>
                  <url>file:server.jks</url>
                  <password>password</password>
                  <type>JKS</type>
               </key-store>
               <password>password</password>
            </identity-manager>
            <trust-manager>
               <algorithm>SunX509</algorithm>
               <key-store>
                  <url>file:trust.jks</url>
                  <password>password</password>
                  <type>JKS</type>
               </key-store>
            </trust-manager>
         </ssl>
      </socket-provider>
   </defaults>
   ...

次の例では、オペレーション・デプロイメント・ディスクリプタで定義されているSSLソケット・プロバイダの構成を参照することによって、グローバルなSSLソケット・プロバイダを構成します。

<cache-config>
   <defaults>
      <socket-provider>ssl</socket-provider>
   </defaults>
   ...

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

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


注意:

証明書は、Windowサーバーでは、OSレベルで証明書マネージャを使用して管理します。サンプルの構成は、拡張プロキシの証明書が証明書マネージャに含まれていること、また、プロキシの証明書に署名する際に使用したCAの証明書が信頼できる認証局として含まれていることを前提としています。証明書の管理の詳細は、http://technet.microsoft.com/en-us/library/cc782338(WS.10).aspxを参照してください。

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

例5-8 .NETクライアント側のSSL構成のサンプル

<?xml version="1.0"?>
<!DOCTYPE cache-config SYSTEM "cache-config.dtd">
<cache-config>
   <caching-scheme-mapping>
      <cache-mapping>
         <cache-name>dist-extend</cache-name>
         <scheme-name>extend-dist</scheme-name>
      </cache-mapping>
   </caching-scheme-mapping>

   <caching-schemes>
      <remote-cache-scheme>
         <scheme-name>extend-dist</scheme-name>
         <service-name>ExtendTcpSSLCacheService</service-name>
         <initiator-config>
            <tcp-initiator>
               <stream-provider>
                  <ssl>
                     <protocol>Tls</protocol>
                     <local-certificates>
                        <certificate>
                           <url>C:\</url>
                           <password>password</password>
                           <flags>DefaultKeySet</flags>
                        </certificate>
                     </local-certificates>
                  </ssl>
               </stream-provider>
               <remote-addresses>
                  <socket-address>
                     <address>198.168.1.5</address>
                     <port>9099</port>
                  </socket-address>
               </remote-addresses>
               <connect-timeout>10s</connect-timeout>
            </tcp-initiator>
            <outgoing-message-handler>
               <request-timeout>5s</request-timeout>
            </outgoing-message-handler>
         </initiator-config>
      </remote-cache-scheme>
   </caching-schemes>
</cache-config>

不正なクライアントの管理

許容範囲外で動作するExtendクライアントは不正なクライアントと見なされます。不正なクライアントには、応答の遅いクライアントや、DoS攻撃の場合のようにプロキシを過剰に使用しようとする悪質なクライアントなどがあります。いずれの場合も、プロキシがメモリー不足になり、応答不能になる可能性があります。

このような悪用を防ぐために、サスペクト・プロトコルが使用されます。サスペクト・アルゴリズムを使用してクライアント接続を監視し、異常に遅い、または悪用されているクライアントを探します。不正なクライアント接続が検出されると、プロキシ・サーバーがメモリー不足になることを防ぐために、アルゴリズムによって接続が閉じられます。プロトコルは、クライアントの送信接続バッファ・バックログのサイズ(バイト数)と長さ(メッセージ数)の両方を監視することによって機能します。クライアントが疑わしいとき、正常に戻ったとき、または不正と見なされるときを判断するために、様々なレベルが設定されています。

サスペクト・プロトコルは、プロキシ・スキーム定義の<tcp-acceptor>要素内で構成します。<tcp-acceptor>要素の使用方法の詳細は、『Oracle Coherence開発者ガイド』のtcp-acceptorに関する項を参照してください。サスペクト・プロトコルはデフォルトで有効になります。

次の例は、サスペクト・プロトコルの構成方法を示しており、デフォルト設定に類似しています。クライアントの送信接続バッファ・バックログが10MBまたはメッセージ数が10000個に達すると、クライアントは疑わしいと見なされ、監視されます。クライアントの接続バッファ・バックログが2MBまたはメッセージ数が2000個まで戻ると、クライアントは安全と見なされ、監視されなくなります。クライアントの接続バッファ・バックログが95MBまたはメッセージ数が60000個に達すると、クライアントは安全でないと見なされ、このクライアントとの接続が閉じられます。

<proxy-scheme>
   <service-name>ExtendTcpProxyService</service-name>
   <thread-count>5</thread-count>
   <acceptor-config>
      <tcp-acceptor>
         ...
         <suspect-protocol-enabled>true</suspect-protocol-enabled>
         <suspect-buffer-size>10M<suspect-buffer-size>
         <suspect-buffer-length>10000<suspect-buffer-length>
         <nominal-buffer-size>2M<nominal-buffer-size>
         <nominal-buffer-length>2000<nominal-buffer-length>
         <limit-buffer-size>95M<limit-buffer-size>
         <limit-buffer-length>60000<limit-buffer-length>
         ...
      </tcp-acceptor>
   </acceptor-config>
   <autostart>true</autostart>
</proxy-scheme>
  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次