ヘッダーをスキップ
Oracle® Coherenceセキュリティ・ガイド
リリース3.7.1
B71689-01
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

3 アクセス・コントローラの使用方法

CoherenceのAccess Controllerセキュリティ・フレームワークは、クラスタ・アクセス・コントローラの概念に基づいており、構成可能なパラメータまたはコマンドライン属性を使用してオン(アクティブ)にできます。

この章には次の項が含まれます:


注意:

この章は、SSLについては取り扱いません。SSLの使用の詳細は、第5章「SSLを使用した通信の保護」を参照してください。

3.1 アクセス・コントローラの概要

アクセス・コントローラは、クラスタ・サービスやクラスタ・キャッシュなどのクラスタ・リソースへのアクセスを管理し、次のような(ただしこれに限定されない)操作を制御します。

アクセス・コントローラの用途は次のとおりです。

Coherenceでは、ローカルのログイン・モジュール(詳細は、JAASリファレンス・ガイドを参照)を使用して、1つ以上のクラスタ・ノードでコール元およびアクセス・コントローラを認証し、コール元のアクセス権を検証します。

アクセス・コントローラは、Coherenceデプロイメント・ディスクリプタtangosol-coherence.xmlで宣言可能なプラガブル・コンポーネントです。指定されたクラスは、com.tangosol.net.security.AccessControllerインタフェースを実装する必要があります。

Coherenceでは、Sun社のJDKの標準部品として出荷されている、キー管理インフラストラクチャに基づくデフォルトのアクセス・コントローラ実装が提供されています。「デフォルトのアクセス・コントローラ実装の有効化」を参照してください。

Coherenceのクラスタ・サービスごとに、上位のサービス・メンバー(クラスタ・ノード)の概念が維持されており、これが特定のサービスの制御エージェントの役割を果たしています。上位メンバーはクラスタ・リソースにアクセスするときに他のメンバーに連絡する必要はありませんが、下位ノードがそのサービスに参加する場合は、上位メンバーにリクエストして確認を受ける必要があります。上位メンバーはその後、他のすべてのクラスタ・ノードに対して、参加ノードに関する通知を送信します。

Coherenceは、分散されたデータ管理およびコンピューティングを提供するシステムであるため、セキュリティ・サブシステムは、ある程度の耐環境性を意図して設計されています。2つのクラスタ・ノード間でデータが共有されている場合、そのいずれかのノードが悪質である、つまり、クラスタ・サービスに参加したり、クラスタ・リソースにアクセスするのに十分な資格証明がない可能性があると仮定します。

標準以外の方法でクラスタ・リソースに不正にアクセスしようとするクラスタ・ノードを、悪質なノードと呼ぶことにします。このようなアクセスには様々な種類があります。それらの範囲は、保護対象になろうとする試みや、プライベート・クラス・データのうちリフレクションを使用するもの、ディストリビューション(coherence.jarまたは他のアプリケーション・バイナリ)でクラスを置き換えるもの、カスタム・クラス・ローダーを使用して実行中のクラスを変更するものなどに及ぶ可能性があります。一方、標準以外の方法でクラスタ・リソースに不正にアクセスを試みることは決してないクラスタ・ノードを信頼できるノードと呼びます。信頼できるノードでも十分な権限を持たずにリソースへのアクセスを試みることがあることに注意することが重要ですが、それは公開された標準APIを使用する標準の方法で行われています。

ファイル・システム・メカニズム(Javaランタイム・ライブラリの整合性を保護するメカニズムと同じ)および標準のJavaセキュリティ・ポリシーを使用すると、特定の単一ノードの信頼性に関する問題を解決できます。ノード間通信の場合は、次の2つの考慮すべき危険性があります。

これら2つの状況が発生しないように、Coherenceでは双方向の暗号化アルゴリズムを使用します。そうすることで、すべてのクライアント・リクエストにIDの証明が付加され、すべてのサービス・レスポンスには信頼性の証明が付加されます。

IDの証明

アクティブなアクセス・コントローラの場合は、クライアント・コードで次の構造を使用してコール元を認証し、必要なアクションを実行できます。

import com.tangosol.net.security.Security;
import java.security.PrivilegedAction;
import javax.security.auth.Subject;

...

Subject subject = Security.login(sName, acPassword);
PrivilegedAction action = new PrivilegedAction()
    {
    public Object run()
        {
        // all processing here is taking place with access
        // rights assigned to the corresponding Subject
        ...
        }
    };
Security.runAs(subject, action);

loginコール時に、コール元のノードで実行されているJAASを使用してコール元が認証されます。認証に成功すると、ローカル・アクセス・コントローラを使用して次の処理を行います。

前述の暗号化の手順では、レスポンダのIDが証明されます。これにより、悪質なノードがローカル・アクセス・チェック・フェーズをパスしたかのように偽装する事態を防げます。

クライアント認証情報は、次の2つの方法でも提供できます。まず、CallbackHandlerに対する参照を、ユーザー名とパスワードのかわりに渡すことができます。また、以前に認証したサブジェクトを使用できます。これは、認証されたサブジェクトをアプリケーション・コンテナから取得するJava EEアプリケーションでCoherenceが使用される場合に便利です。

コール元のリクエストを認証コンテキストなしで受信した場合、Coherenceオペレーション・ディスクリプタで宣言されているCallbackHandler実装をインスタンス化およびコールして、適切な資格証明を取得します。ただし、この遅延アプローチは非常に非効率的です。外部で定義されたコール・スコープがないと、保護されているクラスタ・リソースにアクセスするたびに、認証コールが強制的に繰り返し実行されるためです。

信頼性の証明

Coherence内のクラスタ・リソースはすべて、明示的なAPIコールによって作成されます。上位のサービス・メンバーは、このコール時に提示されたプライベート資格証明を、信頼性の証明として保持します。上位のサービス・メンバーは、保護されているクラスタ・リソースに対するアクセス・リクエストを受信すると、ローカル・アクセス・コントローラを使用して次の処理を行います。

リクエスタがレスポンスを有効なものとして受け入れるのは復号化後のみであるため、このサイクルの最後の手順では、リクエスタの信頼性が証明されます。これにより、悪質なノードが有効な上位サービスであるかのように偽装する事態を防げます。

3.2 デフォルトのアクセス・コントローラ実装の有効化

Coherenceには、標準的なJavaキーストアを使用するデフォルトのアクセス・コントローラ実装が同梱されています。実装クラスはcom.tangosol.net.security.DefaultControllerクラスで、Coherenceオペレーション・デプロイメント・ディスクリプタで構成されます。

<security-config>
  <enabled system-property="tangosol.coherence.security">false</enabled>
  <login-module-name>Coherence</login-module-name>
  <access-controller>
    <class-name>com.tangosol.net.security.DefaultController</class-name>
    <init-params>
      <init-param id="1">
        <param-type>java.io.File</param-type>
        <param-value>./keystore.jks</param-value>
      </init-param>
      <init-param id="2">
        <param-type>java.io.File</param-type>
        <param-value>./permissions.xml</param-value>
      </init-param>
    </init-params>
  </access-controller>
  <callback-handler>
    <class-name/>
  </callback-handler>
</security-config>

デフォルトのアクセス・コントローラ実装は、デフォルトでは有効になっていません。デフォルトの実装を有効化するには、オペレーション・オーバーライド・ファイルの<security-config>ノード内の<enabled>要素をオーバーライドし、trueに設定します。例:

<security-config>
   <enabled>true</enabled>
</security-config>

デフォルトのアクセス・コントローラ実装は、tangosol.coherence.securityシステム・プロパティをtrueに設定しても有効にできます。


注意:

Coherenceセキュリティが有効になっている場合、CacheFactory.getCache()またはConfigurableCacheFactory.ensureCache() APIへのコールごとにセキュリティの確認が発生します。これらのコールが頻繁に実行されると、これはアプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。ベスト・プラクティスは、アプリケーションがキャッシュ参照を保持し、セキュリティの確認が初期コール時にのみ実行されるようにそれを再使用することです。この方法を使用すると、それらの参照が認可された方法でのみ使用されていることをアプリケーション側で確認されます。

<login-module-name>要素は、ログイン構成ファイル内でアプリケーション名の役割を果たします(詳細は、JAASリファレンス・ガイドを参照)。Coherenceには、coherence-login.jarに含まれている、Javaキーストア(JKS)ベースのログイン・モジュールが同梱されています。これは、標準的なJavaランタイム・クラスにのみ依存しており、JREのlib/ext(標準拡張)ディレクトリに配置できます。対応するログイン・モジュール宣言は次のようになります。

// LoginModule Configuration for Oracle Coherence(TM)
Coherence {
    com.tangosol.security.KeystoreLogin required
      keyStorePath="${user.dir}${/}keystore.jks";
};

<access-controller>要素は、次の2つのインスタンス化パラメータを指定するアクセス・コントローラ実装を定義します。

<callback-handler>は、javax.security.auth.callback.CallbackHandlerインタフェースのカスタム実装を定義するオプションの要素です。他のすべての方法を試した後に、クライアントの認証用にインスタンス化および使用されます。

さらに2つの手順を実行する必要があり、次の手順でアプリケーションでデフォルトのアクセス・コントローラ実装を使用可能にします。

  1. 必要なプリンシパルを持つキーストアを作成します。

  2. 対応するプリンシパルへのアクセス権を宣言するpermissionsファイルを作成します。

次の例では、3つのプリンシパルを作成します。adminはJavaセキュリティ・フレームワークで使用し、managerおよびworkerはCoherenceで使用します。

keytool -genkey -v -keystore ./keystore.jks -storepass password -alias admin
-keypass password -dname CN=Administrator,O=MyCompany,L=MyCity,ST=MyState

keytool -genkey -v -keystore ./keystore.jks -storepass password -alias manager
-keypass password -dname CN=Manager,OU=MyUnit

keytool -genkey -v -keystore ./keystore.jks -storepass password -alias worker
-keypass password -dname CN=Worker,OU=MyUnit

次の例では、Managerプリンシパルにはすべての権限を、名前の先頭にcommonが付いているキャッシュのWorkerプリンシパルにはjoinの権限のみを、invocationという名前の起動サービスのWorkerプリンシパルにはすべての権限を割り当てます。

<?xml version='1.0'?>
<permissions>
  <grant>
    <principal>
      <class>javax.security.auth.x500.X500Principal</class>
      <name>CN=Manager,OU=MyUnit</name>
    </principal>

    <permission>
      <target>*</target>
      <action>all</action>
    </permission>
  </grant>

  <grant>
    <principal>
      <class>javax.security.auth.x500.X500Principal</class>
      <name>CN=Worker,OU=MyUnit</name>
    </principal>

    <permission>
      <target>cache=common*</target>
      <action>join</action>
    </permission>
    <permission>
      <target>service=invocation</target>
      <action>all</action>
    </permission>
  </grant>
</permissions>
  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次