Oracle® Fusion Middleware

Oracle Coherenceの保護

12c (12.2.1)

E69905-02(原本部品番号:E55621-02)

2016年2月

様々なレベルのセキュリティを提供するテクノロジを使用して、Oracle Coherenceクラスタ、Oracle Coherence*ExtendクライアントおよびOracle Coherence RESTを保護するための方法について説明する、開発担当者およびシステム管理者向けのドキュメント

Oracle Fusion Middleware Oracle Coherenceの保護, 12c (12.2.1)

E69905-02

Copyright © 2008, 2016, Oracle and/or its affiliates  All rights reserved.

原本著者: Joseph Ruzzi

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- 12c (12.2.1)での新機能と変更された機能

- 12c (12.2.1)に関するこのドキュメントにおけるその他の大きな変更

1 Oracle Coherenceセキュリティの概要

- Oracle Coherenceセキュリティの概念の概要

- Coherenceセキュリティ・クイック・スタート

- セキュリティ構成の概要

2 全般的なセキュリティ対策の有効化

- Javaセキュリティ・マネージャの使用方法

- Javaセキュリティ・マネージャの有効化

- パーミッションの指定

- ローカル・パーミッションのプログラムでの指定

- ホストベースの認可の使用方法

- ホストベースの認可の概要

- クラスタ・メンバーの認可済ホストの指定

- Extendクライアントの認可済ホストの指定

- フィルタ・クラスを使用した認可の決定

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

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

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

- デフォルト・アクセス・コントローラの実装の使用方法

- アクセス・コントローラの有効化

- キーストアの作成

- ログイン・モジュールの組込み

- パーミッション・ファイルの作成

- 認証コールバック・ハンドラの作成

- セキュリティ監査ログの有効化

- カスタム・アクセス・コントローラの実装の使用方法

4 サーバー側操作へのアクセスの許可

- アクセス制御認可の概要

- アクセス制御認可の実装の作成

- アクセス制御認可の実装の宣言

- パーティション化キャッシュ上でのアクセス制御認可の有効化

5 Extendクライアント接続の保護

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

- IDトークンの使用方法の概要

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

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

- カスタム・アイデンティティ・サータの作成

- カスタム・アイデンティティ・サータの有効化

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

- カスタムIDトークンの相互運用性の理解

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

- Extendクライアントの認可の実装

- Extendクライアントの認可の概要

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

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

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

- SSLの概要

- SSLを使用したTCMP通信の保護

- SSLを使用したTCMP通信の保護の概要

- SSLソケット・プロバイダの定義

- 事前定義済SSLソケット・プロバイダの使用方法

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

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

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

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

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

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

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

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

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

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

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

7 Oracle WebLogic ServerにおけるOracle Coherenceの保護

- Oracle WebLogic ServerにおけるOracle Coherenceの保護の概要

- Oracle Coherenceクラスタ・メンバーシップの保護

- Oracle Coherenceセキュリティ・フレームワークの有効化

- セキュリティ・フレームワークで使用するIDの指定

- Oracle Coherenceのキャッシュおよびサービスの認可

- キャッシュ認可の指定

- サービス認可の指定

- IDトークンでのExtendクライアント・アクセスの保護

- Oracle WebLogic Serverで使用するIDトランスフォーマの有効化

- Oracle WebLogic Serverで使用するアイデンティティ・アサータの有効化

8 Oracle Coherence RESTの保護

- Oracle Coherence RESTの保護の概要

- Oracle Coherence RESTでのHTTP Basic認証の使用方法

- ログイン・モジュールの指定

- Oracle Coherence RESTでのSSL認証の使用方法

- HTTPアクセプタ用のSSLソケット・プロバイダの構成

- 保護されたRESTサービスへのアクセス

- Oracle Coherence RESTでのSSLおよびHTTP Basic認証の使用方法

- Oracle Coherence RESTのための認可の実装

はじめに

『Oracle Coherenceの保護』では、主要なセキュリティの概念について説明し、Oracle Coherenceクラスタ、Oracle Coherence RESTおよびOracle Coherence*Extendクライアントに対して様々なレベルのセキュリティを実装する方法を示します。

対象読者

このドキュメントは、次の読者を対象としています。

- 主な対象読者 – Oracle Coherenceクラスタの保護、およびクラスタとのOracle Coherence*Extendクライアント通信の保護を担当するアプリケーション開発者およびオペレータ

- 二次的な対象読者 – Oracle CoherenceクラスタおよびOracle Coherence*Extendクライアントを保護するためのオプションとアーキテクチャを理解する必要のあるシステム・アーキテクト

このガイドを効果的に使用するためには、対象読者は、Oracle Coherence、Oracle Coherence RESTおよびOracle Coherence*Extendに精通している必要があります。さらに、ユーザーは、JavaとSecure Socket Layer (SSL)にも精通している必要があります。このガイドで示す例では、Oracle Coherence*Extendを含むOracle Coherence製品のインストールと使用が求められます。統合開発環境(IDE)の使用は必須ではありませんが、例をより効果的に活用するには、IDEの使用をお薦めします。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

Oracleサポートへのアクセス

サポートを購入したオラクル社のお客様は、My Oracle Supportを介して電子的なサポートにアクセスできます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

関連ドキュメント

詳細は、次のOracle Coherenceドキュメントを参照してください。

- Oracle Coherence*WebでのHTTPセッション・マネージメントの管理

- 『Oracle Coherenceの管理』

- Oracle Coherenceでのアプリケーションの開発

- Oracle Coherenceリモート・クライアントの開発

- 『Oracle Coherenceのインストール』

- 『Oracle Coherenceの統合』

- 『Oracle Coherenceのマネージメント』

- Oracle Coherence Java APIリファレンス

- Oracle Coherence C++ APIリファレンス

- Oracle Coherence .NET APIリファレンス

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

次のトピックでは、Oracle Coherenceの新機能と変更された機能について、およびこのガイドに記載されるその他の重要な変更について紹介し、詳細情報へのリンクを提供します。

12c (12.2.1)での新機能と変更された機能

このドキュメントでのOracle Coherence 12c (12.2.1)に含まれる新機能と変更された機能は次のとおりです。

- プログラム・ローカル・パーミッションにより、パーミッションをローカル(非クラスタ化)のCoherence API操作に設定できます。「ローカル・パーミッションのプログラムでの指定」を参照してください。

- セキュリティ監査ログにより、特定のユーザーが実行しているクラスタ操作をレポートできます。「セキュリティ監査ログの有効化」を参照してください。

- アクセス制御認可により、アプリケーションで独自の認可論理を定義して、クラスタ操作へのアクセスを制限できます。「サーバー側操作へのアクセスの許可」を参照してください。

- SSLプロトコルおよび暗号スイート構成により、どのSSLプロトコルおよび暗号スイートを使用できるか制御できます。「暗号スイートとプロトコル・バージョンの使用の制御」を参照してください。

12c (12.2.1)に関するこのドキュメントにおけるその他の大きな変更

12c (12.2.1)では、このガイドにおける重要な変更はありません。

1 Oracle Coherenceセキュリティの概要

この章では、Oracle Coherenceセキュリティ機能の概要について説明します。Oracle Coherenceセキュリティ機能は、様々なレベルのセキュリティを提供しており、通常は必要に応じて実装されます。セキュリティ機能には、Secure Sockets Layer (SSL)などの業界標準や、Oracle Coherence固有の機能が含まれます。

注意:

このガイドでは、クラスタの設定やOracle Coherence*Extendクライアントの作成に関する詳細な手順については説明しません。クラスタの設定およびOracle Coherence*Extendクライアントの作成の詳細はそれぞれ、『Oracle Coherenceでのアプリケーションの開発』および『Oracle Coherenceリモート・クライアントの開発』を参照してください。

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

- Oracle Coherenceセキュリティの概念の概要

- Coherenceセキュリティ・クイック・スタート

- セキュリティ構成の概要

Oracle Coherenceセキュリティの概念の概要

この項では、Oracle CoherenceおよびOracle Coherence*Extendで使用可能なセキュリティ機能を列挙し、それらについて説明します。セキュリティ機能を評価し、セキュリティ要件、懸念事項および許容範囲に基づいて、どの機能を使用するかを判断してください。この項(およびこのドキュメント全体)の構成では、より高度なセキュリティ対策の前に基本的なセキュリティ対策を示しています。

Javaポリシー・セキュリティ

Oracle Coherenceの実行に必要な最小限のセキュリティ・パーミッションを含むJavaセキュリティ・ポリシー・ファイルが提供されています。このファイルを編集し、アプリケーションの要件に応じてパーミッションを変更します。セキュリティ・ポリシーは、Oracle Coherenceライブラリや構成ファイルの悪質な使用および変更を防ぎます。詳細は、「Javaセキュリティ・マネージャの使用方法」を参照してください。

ホストベースの認可

ホストベースの認可では、クラスタのメンバーになるホストおよびクラスタに接続するExtendクライアントが明示的に指定されます。このタイプのアクセス制御は、ホスト名(またはIPアドレス)が事前にわかっている環境に適しています。ホストベースの認可は、無許可のホストによるクラスタへの参加またはアクセスを防ぎます。詳細は、「ホストベースの認可の使用方法」を参照してください。

クライアント・サスペクト・プロトコル

クライアント・サスペクト・プロトコルは、自動的に、Extendクライアントが悪質な動作を行っているかどうかを判断し、そのクライアントがクラスタに接続するのをブロックします。サスペクト・プロトコルは、サービス拒否攻撃を防ぎます。詳細は、「不正なクライアントの管理」を参照してください。

クライアントIDトークン

クライアントIDトークンは、どのExtendクライアントがクラスタにアクセスするかを制御します。プロキシ・サーバーは、クライアントが有効なトークンを提示した場合のみ接続を許可します。IDトークンは、アプリケーション固有であり、通常は既存のクライアント認証実装を再利用します。IDトークンは、好ましくないクライアントや悪質なクライアントがクラスタにアクセスするのを防ぎます。詳細は、「IDトークンを使用したクライアント接続の制限」を参照してください。

クライアント認可

クライアント認可は、特定のクライアントが実行できるアクションを、そのアクセス制御パーミッションに基づいて制御します。プロキシ・サーバーは、Extendクライアントがリソース(キャッシュ、キャッシュ・サービスまたは起動サービス)にアクセスする前に認可チェックを実行します。クライアント認可は、アプリケーション固有であり、クラスタ・リソースの無許可の使用を防ぎます。詳細は、「Extendクライアントの認可の実装」を参照してください。

アクセス・コントローラのセキュリティ・フレームワーク

アクセス・コントローラは、クラスタ化サービスやクラスタ化キャッシュなどのクラスタ化リソースへのアクセスを管理し、ユーザーがそれらのリソースで実行できる操作を制御します。クラスタ・メンバーは、ログイン・モジュールを使用してIDの証明を提示します。一方、通信の暗号化および復号化は、信頼性の証明としての役割を果たします。フレームワークにより、キーストアの使用が求められ、パーミッション・ファイル内のパーミッションが定義されます。アクセス・コントローラは、悪質なクラスタ化メンバーがクラスタ化リソースにアクセスしたり、クラスタ化リソースを作成したりするのを防ぎます。詳細は、「アクセス・コントローラの使用方法」を参照してください。

SSL

SSLは、クラスタ・ノード間のTangosol Cluster Management Protocol (TCMP)通信を保護します。SSLはまた、Oracle Coherence*Extendクライアントとプロキシ間のTCP通信も保護します。SSLは、デジタル署名を使用して識別と信頼を確立し、キーベースの暗号化を使用してデータが確実に保護されるようにします。SSLは、悪質なクライアントおよびクラスタ・メンバーによる無許可のアクセスやデータの改ざんを防ぐ業界標準です。詳細は、「SSLを使用した通信の保護」を参照してください。

Coherenceセキュリティ・クイック・スタート

Coherenceセキュリティ機能は、デフォルトでは無効であり、特定のセキュリティ要件または懸念事項に対処する必要がある場合に有効化されます。有効化されるセキュリティ機能に基づいて、様々なレベルのセキュリティを実現できます。次のリストは、ファイル・パーミッション、SSLおよび認可を含むCoherence環境でのセキュリティのクイック・スタートおよび結果を示します。

- ファイル・システム・パーミッションおよびJavaポリシー・パーミッションを構成し、Coherenceファイルの読取りおよび書込みに対して保護します。詳細は、「Javaセキュリティ・マネージャの使用方法」を参照してください。

- SSLを構成して有効化し、クラスタ・メンバー間の通信の保護、およびクラスタに参加する無許可のメンバーに対して保護します。「SSLを使用したTCMP通信の保護」を参照してください。

- Coherence*ExtendまたはCoherence RESTを使用する場合、SSLを構成して有効化し、外部クライアントとCoherenceプロキシ・サーバー間の通信を保護します。SSLは、無許可のクライアントによるクラスタ・サービスの使用から保護します。詳細は、それぞれ「SSLを使用したExtendクライアント通信の保護」および「Oracle Coherence RESTでのSSL認証の使用方法」を参照してください。

- 認可ポリシーを実装して、ユーザー・ロールに基づいた特定のCoherence操作へのクライアント・アクセスを制限します。「Extendクライアントの認可の実装」を参照してください。

セキュリティ構成の概要

セキュリティ構成は、オペレーション・オーバーライド・ファイルとキャッシュ構成ファイルの両方で行われます。構成に関する詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

- オペレーション・オーバーライド・ファイル – tangosol-coherence-override.xmlファイルは、オペレーション・デプロイメント・ディスクリプタをオーバーライドします。オペレーション・デプロイメント・ディスクリプタは、クラスタリング・サービス、通信サービスおよびデータ管理サービスを制御する操作設定および実行時設定を指定するものです。このファイルには、クラスタ・メンバー用のセキュリティ設定が含まれます。

- キャッシュ構成ファイル – coherence-cache-config.xmlファイルは、デフォルトのキャッシュ構成ファイルです。これは、クラスタ内の様々なタイプのキャッシュを指定します。この構成ファイルには、Oracle Coherence*Extend用のセキュリティ設定が含まれます。キャッシュ構成ファイルは、Extendクライアント側とクラスタ側の両方で必要です。Oracle Coherence*Extendの設定の詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

2 全般的なセキュリティ対策の有効化

この章では、全般的なセキュリティ対策を有効にする方法について説明します。ここで説明する対策は、Oracle Coherence APIおよびシステム・リソースの無許可の使用を防ぐのに役立ちます。また、クラスタへの無許可の接続も防ぎます。

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

- Javaセキュリティ・マネージャの使用方法

- ホストベースの認可の使用方法

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

Javaセキュリティ・マネージャの使用方法

Javaには、明示的なパーミッションを使用してシステム・リソースへのアクセスを制御するセキュリティ・マネージャがあります。COHERENCE_HOME/lib/security/security.policyポリシー構成ファイルでは、Oracle Coherenceの最小限のパーミッションのセットが指定されています。提供されているファイルを使用するか、追加のパーミッションを設定するようにファイルを変更します。Coherenceには、ローカル(非クラスタ化)・パーミッションのセットも含まれます。

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

- Javaセキュリティ・マネージャの有効化

- パーミッションの指定

- ローカル・パーミッションのプログラムでの指定

Javaセキュリティ・マネージャの有効化

Javaセキュリティ・マネージャを有効にし、COHERENCE_HOME/lib/security/security.policyファイルを使用するには、クラスタ・メンバーで次のプロパティを設定します。

1. java.security.managerプロパティを、Javaセキュリティ・マネージャを有効にするように設定します。次に例を示します。

-Djava.security.manager

2. java.security.policyプロパティをポリシー・ファイルの場所に設定します。次に例を示します。

-Djava.security.manager
-Djava.security.policy=/coherence/lib/security/security.policy

3. coherence.homeシステム・プロパティをCOHERENCE_HOMEに設定します。次に例を示します。

-Djava.security.manager
-Djava.security.policy=/coherence/lib/security/security.policy
-Dcoherence.home=/coherence

注意:

セキュリティ・ポリシー・ファイルでは、デフォルトのJava Runtime Environment (JRE)セキュリティ・パーミッションが付与されていることが想定されています。そのため、java.security.policyシステム・プロパティを設定するときは、2つの等号(==)ではなく、1つの等号(=)を使用するように注意してください。

パーミッションの指定

必要に応じて追加のパーミッションを含むようにCOHERENCE_HOME/lib/security/security.policyファイルを変更します。ファイル形式および構文の詳細は、Java SEセキュリティ・ガイドを参照してください。

http://download.oracle.com/javase/7/docs/technotes/guides/security/permissions.html

security.policyファイルで追加のパーミッションを指定するには:

1. security.policyファイルを編集し、リソースに対するパーミッションを追加します。たとえば、次のパーミッションでは、coherence.jarライブラリへのアクセスが付与されます。

grant codeBase "file:${coherence.home}/lib/coherence.jar"
{
permission java.security.AllPermission;
};

2. バイナリを宣言する場合は、JDK jarsignerツールを使用してバイナリに署名します。次の例では、前の手順で宣言されたcoherence.jarリソースに署名します。

jarsigner -keystore ./keystore.jks -storepass password coherence.jar admin

パーミッション宣言に署名者を追加します。たとえば、元のパーミッションを次のように変更して、admin署名者を追加します。

grant SignedBy "admin" codeBase "file:${coherence.home}/lib/coherence.jar"
{
permission java.security.AllPermission;
};

3. オペレーティング・システム・メカニズムを使用して、関連するすべてのファイルを悪質な変更から保護します。

ローカル・パーミッションのプログラムでの指定

com.tangosol.net.security.LocalPermissionクラスにより、パーミッションをローカル(非クラスタ化)のCoherence API操作に設定できます。クライアントは、宣言された操作(ターゲットを指します)の実行を許可される、または許可されないのいずれかに設定されます。次に例を示します。

LocalPermission lp = new LocalPermission("Cluster.shutdown");

ローカル・パーミッションを使用するには、Javaセキュリティ・マネージャを有効化する必要があります。詳細は、「Javaセキュリティ・マネージャの有効化」を参照してください。

表2-1 に、宣言できるターゲット名の一覧および説明を示します。

表2-1 ローカル・パーミッションのターゲット

ターゲット名

説明

CacheFactory.setCacheFactoryBuilder

カスタム・キャッシュ・ファクトリ・ビルダのプログラムでのインストールを保護します。パーミッションを付与する際には、十分注意する必要があります。このパーミッションを付与すると、コードを使用してキャッシュ・ファクトリ・ビルダーを設定して、任意のキャッシュへのアクセスまたは変更リクエストをインターセプトできるようになり、これらのキャッシュとの間でやりとりされる任意のデータへのアクセスも可能になります。

Cluster.shutdown

すべてのサービスが停止するのを保護します。このパーミッションを付与すると、コードを使用してクラスタ・ノードをプログラムで停止できます。

BackingMapManagerContext.getBackingMap

バッキング・マップへの直接アクセスを保護します。パーミッションを付与する際には、十分注意する必要があります。このパーミッションを付与すると、コードを使用してバッキング・マップへの参照を取得でき、追加のセキュリティ・チェックなしに格納された任意のデータにアクセスできます。

BackingMapManagerContext.setClassLoader

ストレージで使用されるクラス・ローダーへの変更を保護します。クラス・ローダーは、システム・クラス・ローダーに存在しない可能性のあるアプリケーション・クラスをロードするためにキャッシュ・サービスによって使用されます。この権限を付与すると、コードを使用して、特定のサービスで使用するクラス・ローダーを変更できます。

Service.getInternalService

内部サービス、クラスタまたはキャッシュ参照へのアクセスを保護します。このパーミッションを付与すると、コードを使用して基盤となるサービス、クラスタまたはキャッシュ・ストレージ実装への直接アクセスが取得できます。

Service.registerResource

サービス・レジストリを保護します。この権限を付与すると、コードを使用して、サービスに関連付けられたさまざまなリソースを再登録または登録解除できます。

Service.registerEventInterceptor

プログラムでのインストールを保護します。パーミッションを付与する際には、十分注意する必要があります。このパーミッションを付与すると、コードを使用して、キャッシュ・サービスに関連付けられたイベント・インターセプタを変更または削除でき、つまり、基盤となるデータへのアクセス、またはデータの一貫性を保護するために設計されたライブ・イベントの削除のいずれかが可能です。

ホストベースの認可の使用方法

ホストベースの認可は、指定されたホスト(ホスト名またはIPアドレス・ベース)のみがクラスタに接続できるようにするタイプのアクセス制御です。この機能は、クラスタ・メンバー接続とExtendクライアント接続の両方で使用できます。

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

- ホストベースの認可の概要

- クラスタ・メンバーの認可済ホストの指定

- Extendクライアントの認可済ホストの指定

- フィルタ・クラスを使用した認可の決定

ホストベースの認可の概要

ホストベースの認可では、クラスタ・メンバーまたはExtendクライアントのホスト名およびIPアドレスを使用して、クラスタへの接続が許可されるかどうかを決定します。特定のホスト名、アドレスおよびアドレス範囲を定義できます。カスタム処理では、カスタム・フィルタを作成してホストの検証ができます。

ホストベースの認可は、相対的な静的ネットワーク・アドレスを持つ既知のホストがクラスタに参加またはアクセスしている環境に適しています。動的な環境の場合、またはDNSサーバーの更新中の場合は、IPアドレスが変わり、クラスタ・メンバーまたはExtendクライアントが認可に失敗する可能性があります。クラスタ・メンバーまたはExtendクライアントが認可されない場合、キャッシュ操作が完了しないことがあります。Extendクライアントは、一時的な性質が原因となるアクセスの問題が起きる可能性があります。

ホストベースの認可を使用する場合、ネットワーク環境の動的性質を考慮します。認可されるホストのリストを再構成するという要求は、現実的ではない場合があります。可能な場合、特定のホスト名を使用するかわりに、常にIPアドレスの範囲を使用します。または、変更されたアドレスを解決できるカスタム・フィルタを作成します。ホストベースの認可が実行不可能な場合、ExtendクライアントのIDトークン(「IDトークンを使用したクライアント接続の制限」を参照)、またはSSL(「SSLを使用した通信の保護」)の使用を検討します。

クラスタ・メンバーの認可済ホストの指定

クラスタのデフォルトの動作では、いずれのホストもクラスタに接続し、クラスタ・メンバーになることができます。ホストベースの認可は、この動作を変更して、特定のホスト名またはIPアドレスを持つホストのみがクラスタに接続できるようにします。

<cluster-config>要素内の<authorized-hosts>要素を使用して、オペレーション・オーバーライド・ファイルで認可済のホストを構成します。<host-address>要素を使用して特定のアドレスを入力するか、<host-range>要素を使用してアドレスを範囲を入力します。<host-address>要素および<host-range>要素は、複数の要素を一意に識別するid属性をサポートします。

次の例では、IPアドレスが192.168.0.5か192.168.0.6であるか、または192.168.0.10から192.168.0.20および192.168.0.30から192.168.0.40の範囲内であるクラスタ・メンバーのみを受け入れるようにクラスタを構成します。

<?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>
<authorized-hosts>
<host-address id="1">192.168.0.5</host-address>
<host-address id="2">192.168.0.6</host-address>
<host-range id="1">
<from-address>192.168.0.10</from-address>
<to-address>192.168.0.20</to-address>
</host-range>
<host-range id="2">
<from-address>192.168.0.30</from-address>
<to-address>192.168.0.40</to-address>
</host-range>
</authorized-hosts>
</cluster-config>
</coherence>

Extendクライアントの認可済ホストの指定

拡張プロキシ・サーバーのデフォルトの動作では、いずれのExtendクライアントもクラスタに接続できます。ホストベースの認可は、この動作を変更して、特定のホスト名またはIPアドレスを持つホストのみがクラスタに接続できるようにします。

プロキシ・スキーム定義の<tcp-acceptor>要素内の<authorized-hosts>要素を使用して、キャッシュ構成ファイルで認可済のホストを構成します。<host-address>要素を使用して特定のアドレスを入力するか、<host-range>要素を使用してアドレスを範囲を入力します。<host-address>要素および<host-range>要素は、複数の要素を一意に識別するid属性をサポートします。

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

<proxy-scheme>
<service-name>ExtendTcpProxyService</service-name>
<thread-count>5</thread-count>
<acceptor-config>
<tcp-acceptor>
...
<authorized-hosts>
<host-address id="1">192.168.0.5</host-address>
<host-address id="2">192.168.0.6</host-address>
<host-range id="1">
<from-address>192.168.0.10</from-address>
<to-address>192.168.0.20</to-address>
</host-range>
<host-range id="2">
<from-address>192.168.0.30</from-address>
<to-address>192.168.0.40</to-address>
</host-range>
</authorized-hosts>
...
</tcp-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>

フィルタ・クラスを使用した認可の決定

フィルタ・クラスは、特定のホスト接続を受け入れるかどうかを決定します。Extendクライアント接続とクラスタ・メンバー接続の両方とも、フィルタ・クラスの使用をサポートしています。フィルタ・クラスでは、com.tangosol.util.Filterインタフェースを実装する必要があります。インタフェースのevaluate()メソッドに、ホストのjava.net.InetAddressが渡されます。実装は、trueを返して接続を受け入れます。

フィルタ・クラスを有効にするには、<host-filter要素内の<class-name要素を使用して、完全修飾クラス名を入力します。<init-params要素を使用して、初期化パラメータを設定します。Filterインタフェースの詳細は、Oracle Coherence Java APIリファレンスを参照してください。

次の例では、MyFilterという名前のフィルタを構成します。このフィルタは、ホスト接続が許可されるかどうかを決定します。

<authorized-hosts>
<host-address id="1">192.168.0.5</host-address>
<host-address id="2">192.168.0.6</host-address>
<host-range id="1">
<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-hosts>

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

不正なクライアントとは、許容範囲外で動作するExtendクライアントです。不正なクライアントは、応答の遅いクライアントや、サービス拒否攻撃の場合のようにプロキシを過剰に使用しようとする悪質なクライアントです。いずれの場合も、プロキシがメモリーを使い果たし、応答しない状態になる可能性があります。サスペクト・プロトコルは、このような悪用を防ぎます。

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

サスペクト・プロトコルは、プロキシ・スキーム定義の<tcp-acceptor要素内で構成します。<tcp-acceptor要素の使用方法の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。疑いのあるプロトコルはデフォルトで有効です。

次の例は、サスペクト・プロトコルの構成方法を示しており、デフォルト設定に類似しています。クライアントの送信接続バッファ・バックログが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>

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

この章では、クラスタ・リソースの無許可の使用を防ぐためにアクセス・コントローラを有効にする方法について説明します。デフォルト・アクセス・コントローラの実装は、HotSpot JDKの一部であるキー管理インフラストラクチャに基づいています。この実装では、認証にJava Authentication and Authorization Service (JAAS)が使用されます。

注意:

この章では、SSLについては説明しません。SSLの詳細な説明は、「SSLを使用した通信の保護」を参照してください。

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

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

- デフォルト・アクセス・コントローラの実装の使用方法

- カスタム・アクセス・コントローラの実装の使用方法

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

アクセス・コントローラは、クラスタ・リソースおよび操作へのアクセスを保護します。コール元の認証にはローカルのログイン・モジュールが使用され、1つ以上のクラスタ・ノードにあるアクセス・コントローラは、コール元のアクセス権を検証します。ログイン・モジュールの詳細は、JAASリファレンス・ガイドを参照してください。

アクセス・コントローラは、次のことを行います。

- コール元の権限に基づいて、保護されているクラスタ化リソースへのアクセスを付与または拒否します。

- コール元のプライベート資格証明に基づいて送信通信を暗号化します。

- コール元のパブリック資格証明に基づいて受信通信を復号化します。

デフォルト・アクセス・コントローラの実装が提供されています。この実装は、HotSpot JDKの標準コンポーネントとして出荷されるキー管理インフラストラクチャに基づいています。「デフォルト・アクセス・コントローラの実装の使用方法」を参照してください。

図3-1 は、アクセス・コントローラを使用して2つのクラスタ・メンバーを保護する場合の概念を示しています。

図3-1 アクセス・コントローラ・セキュリティの概念

セキュリティ・コンテキストの理解

クラスタ化サービスごとに、上位のサービス・メンバーの概念が維持されており、これが特定のサービスの制御エージェントの役割を果たしています。上位のメンバーは、クラスタ化リソースにアクセスするときに他のメンバーと情報のやり取りをしません。しかし、サービスに参加する下位のメンバーは、上位のメンバーにリクエストして確認を得る必要があります。上位のメンバーは、参加メンバーについて他のすべてのクラスタ・メンバーに通知します。

データはクラスタ・メンバー間に分散されるため、セキュリティ・サブシステムは、ある程度の耐環境性を意図して設計されています。すべてのメンバーは悪意のあるメンバーと見なされます。つまりメンバーは、クラスタ化サービスに参加したり、クラスタ化リソースにアクセスするための十分な資格証明を持っていないと想定されています。

ファイル・システム・メカニズムおよび標準のJavaセキュリティ・ポリシーは、単一ノードの信頼性を保証します。ただし、メンバーの通信について考慮すべき2つのシナリオがあります。

- 悪質なノードがローカル・アクセス・チェックを迂回して、クラスタ化サービスに参加したり、信頼できるノードが管理しているクラスタ化リソースにアクセスしたりしようとします。

- 悪質なノードがクラスタ化サービスまたはクラスタ化リソースを作成し、そのコントローラになります。

セキュリティ・サブシステムは、これら2つのシナリオが発生しないようにするために、双方向の暗号化アルゴリズムを使用します。すべてのクライアント・リクエストは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
// for example:
CacheFactory.getCache().put(key, value);
...
}
};
Security.runAs(subject, action);

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

- ローカルのコール元に、保護されているクラスタ化リソースにアクセスできる権限があるかどうかを確認します(ローカル・アクセス・チェック)。

- 認証フェーズで取得したコール元のプライベート資格証明を使用して、リソースへのアクセスに関する送信通信を暗号化します。

- リクエスタのパブリック資格証明を使用して、リモート・チェックの結果を復号化します。

- レスポンダがアクセス権付与対象としての十分な権限を持っているかどうかを検証します。

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

クライアント認証情報は、次の2つの方法でも提供できます。1つ目の方法は、ユーザー名とパスワードのかわりにCallbackHandlerクラスへの参照を渡すことです。2つ目の方法は、すでに認証済のSubjectを使用することです。後者の方法は、Java EEアプリケーションがOracle Coherenceを使用しており、アプリケーション・コンテナから認証済のSubjectを取得する場合に適しています。

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

信頼性の証明

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

- リモートのコール元のパブリック資格証明を使用して、受信通信を復号化します。

- サービスのプライベート資格証明を使用して、アクセス・チェックのレスポンスを暗号化します。

- リモートのコール元に、保護されているクラスタ化リソースにアクセスできる権限があるかどうかを確認します(リモート・アクセス・チェック)。

デフォルト・アクセス・コントローラの実装の使用方法

標準的なJavaキーストアを使用するデフォルト・アクセス・コントローラの実装が提供されています。実装クラスは、com.tangosol.net.security.DefaultControllerクラスです。これは、オペレーション・デプロイメント・ディスクリプタの<security-config要素内で構成されています。<security-config要素およびそのサブ要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。デフォルト・アクセス・コントローラを使用するには、この項の手順を実行してください。

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

- アクセス・コントローラの有効化

- キーストアの作成

- ログイン・モジュールの組込み

- パーミッション・ファイルの作成

- 認証コールバック・ハンドラの作成

- セキュリティ監査ログの有効化

アクセス・コントローラの有効化

<security-config>要素内でデフォルト・アクセス・コントローラの実装を有効にするには、trueに設定された<enabled>要素を追加します。次に例を示します。

<security-config>
<enabled system-property="coherence.security">true</enabled>
</security-config>

coherence.securityシステム・プロパティもアクセス・コントローラを有効にできます。次に例を示します。

-Dcoherence.security=true

注意:

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

キーストアの作成

アクセス・コントローラは、コントローラとログイン・モジュールの両方で使用されるキーストアを必要とします。Java keytoolユーティリティを使用して、必要なプリンシパルを持つキーストアを作成します。実行時にキーストアがクラスパス上に確実に見つかるようにするか、coherence.security.keystoreシステム・プロパティを使用してキーストアの名前と場所を明示的に入力します。次に例を示します。

-Dcoherence.security.keystore=keystore.jks

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

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

ログイン・モジュールの組込み

Oracle Coherenceには、COHERENCE_HOME/lib/security/coherence-login.jar Javaキーストア(JKS)ログイン・モジュールが組み込まれています。これは、標準的なJavaランタイム・クラスにのみ依存します。JRE lib/ext (標準拡張)ディレクトリにライブラリを配置します。<security-config>要素内の<login-module-name>要素の名前は、COHERENCE_HOME/lib/security/login.configログイン・モジュール・ファイル内でアプリケーション名の役割を果たします。ログイン・モジュール宣言には、キーストアへのパスが含まれています。keyStorePath変数をキーストアの場所に変更します。

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

パーミッション・ファイルの作成

アクセス・コントローラは、プリンシパルのアクセス権を宣言するpermissions.xmlファイルを必要とします。パーミッション・ファイルの構文については、COHERENCE_HOME/lib/security/permissions.xsdスキーマを参照してください。実行時にファイルがクラスパス上に確実に見つかるようにするか、coherence.security.permissionsシステム・プロパティを使用してパーミッション・ファイルの名前と場所を明示的に入力します。次に例を示します。

-Dcoherence.security.permissions=permissions.xml

次の例では、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>

認証コールバック・ハンドラの作成

他のすべての認証方式が成功しなかった場合、アクセス・コントローラは、認証コールバック・ハンドラを使用してクライアントを認証します。コールバック・ハンドラを作成するには、javax.security.auth.callback.CallbackHandlerインタフェースを実装します。

注意:

このハンドラ・アプローチは非常に非効率的です。外部で定義されたコール・スコープがないと、保護されているクラスタ化リソースにアクセスするたびに、認証コールが強制的に繰り返し実行されるためです。

<security-config>要素内でカスタム・コールバック・ハンドラを構成するには、実装クラスの完全修飾名を含む<callback-handler>要素を追加します。次の例では、MyCallbackHandlerという名前のコールバック・ハンドラを構成します。

<security-config>
<callback-handler>
<class-name>package.MyCallbackHandler</class-name>
</callback-handler>
</security-config>

セキュリティ監査ログの有効化

セキュリティ監査ログを使用して、各ユーザーが実行しているクラスタ操作を追跡できます。それぞれの操作は、出力されるログ・メッセージに表示されます。次に例を示します。

"Destroy" action for cache "Accounts" has been permitted for the user "CN=Bob, OU=Accounting".

セキュリティ監査ログは、デフォルトで有効ではありません。監査ログを<security-config>要素内で有効にするには、セキュリティ・ログ初期化パラメータを<access-controller>要素内でオーバーライドし、パラメータ値をtrueに設定します。次に例を示します。

<security-config>
<access-controller>
<init-params>
<init-param id="3">
<param-type>boolean</param-type>
<param-value system-property="coherence.security.log">
true</param-value>
</init-param>
</init-params>
</access-controller>
</security-config>

coherence.security.logシステム・プロパティもセキュリティ監査ログを有効にできます。次に例を示します。

-Dcoherence.security.log=true

カスタム・アクセス・コントローラの実装の使用方法

カスタム・アクセス・コントローラでは、com.tangosol.net.security.AccessControllerインタフェースを実装する必要があります。このAPIの使用方法の詳細は、Oracle Coherence Java APIリファレンスを参照してください。<security-config要素内でカスタム・アクセス・コントローラを構成するには、実装クラスの完全修飾名を含む<access-controller要素を追加します。次の例では、MyAccessControllerというカスタム・アクセス・コントローラを構成します。

<security-config>
<enabled system-property="coherence.security">true</enabled>
<access-controller>
<class-name>package.MyAccessController</class-name>
</access-controller>
</security-config>

<init-params>要素を使用して、必要な初期化パラメータを指定します。次の例には、MyAccessControllerクラスにキーストアとパーミッション・ファイルを渡すパラメータが含まれています。

<security-config>
<enabled system-property="coherence.security">true</enabled>
<access-controller>
<class-name>package.MyAccessController</class-name>
<init-params>
<init-param>
<param-type>java.io.File</param-type>
<param-value>./keystore.jks</param-value>
</init-param>
<init-param>
<param-type>java.io.File</param-type>
<param-value>./permissions.xml</param-value>
</init-param>
</init-params>
</access-controller>
</security-config>

4 サーバー側操作へのアクセスの許可

この章では、認可を使用してCoherence操作へのアクセスをセキュアにする手順を説明します。

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

- アクセス制御認可の概要

- アクセス制御認可の実装の作成

- アクセス制御認可の実装の宣言

- パーティション化キャッシュ上でのアクセス制御認可の有効化

アクセス制御認可の概要

アクセス制御認可により、アプリケーションで独自の認可論理を定義して、クラスタ操作へのアクセスを制限できます。認可は、Subject内のPrincipalとして表される識別情報に基づきます。アプリケーションは、Subjectがコール元スレッドに存在することを確認します。Subjectが存在しない、または取得できない場合、操作は失敗し、SecurityExceptionエラーが発生します。

アプリケーションは、StorageAccessAuthorizerインタフェースを実装して、認可論理を指定します。実装は、オペレーション・オーバーライド構成ファイルで宣言され、また、キャッシュ構成ファイル内の分散スキーマのバッキング・マップを構成して、パーティション化キャッシュ上で有効化する必要があります。アクセス制御認可は、パーティション化キャッシュでのみ使用できます。

StorageAccessAuthorizerインタフェースにより、Read、Write、Read AnyおよびWrite Any認可チェックを実行するために使用するメソッドが提供されます。Coherenceは、StorageAccessAuthorizer実装による認可の決定が、論理的に一貫しているとみなします。特定のSubjectで、Write認可は特定のエントリに対するREAD認可を指し、Read Any認可はすべてのエントリに対するRead認可を指し、Write Any認可はすべてのエントリに対するWriteおよびRead認可を指します。

表4-1 に、NamedCache APIおよびBinaryEntry APIメソッドで発生する認可チェックの一覧を示します。

表4-1 共通メソッドの認可チェック

認可チェック

NamedCache APIメソッド

BinaryEntry APIメソッド

なし

- containsKey

- containsValue

- isEmpty

- size

- lock

- unlock

Read

- get

- getAll

- getValue

- getBinaryValue

- extract

- getOriginalValue

- getOriginalBinaryValue

Write

- invoke

- put

- putAll

- remove

- removeAll

- setValue

- update

- updtaeBinaryValue

- remove

- expire

Read Any

- addMapListener[1]

- aggregate

- entrySet

- keySet

- removeMapListener^1

Write Any

- addIndex

- clear

- invokeAll

- removeIndex

- values

アクセス制御認可の実装の作成

アクセス制御認可実装を作成するには、com.tangosol.net.security.StorageAccessAuthorizerインタフェースを実装するクラスを作成します。実装では、どのコール元(Subjectに基づき)を認可してエントリおよびバッキング・マップ・コンテキスト(それぞれBinaryEntryおよびBackingMapManagerContext)にアクセスするか定義する必要があります。

注意:

BinaryEntryおよびBackingMapManagerContext APIにより、キャッシュ名、サービス名およびサービスおよびクラスタ・レジストリへの完全なアクセスを取得することができます。

例4-1 に、各認可リクエストのログ・メッセージを出力するサンプルのStorageAccessAuthorizer実装を示します。これは、Coherenceで提供されるAuditingAuthorizerクラスに基づき、 デフォルトのアクセス・コントローラ実装で使用されます。

例4-1 StorageAccessAuthorizer実装のサンプル

package com.examples.security;

import com.tangosol.net.BackingMapContext;
import com.tangosol.net.CacheFactory;
import com.tangosol.net.security.StorageAccessAuthorizer;
import com.tangosol.util.BinaryEntry;

import javax.security.auth.Subject;

public class MyLogAuthorizer implements StorageAccessAuthorizer
{
public MyLogAuthorizer()
{
this(false);
}

public MyLogAuthorizer(boolean fStrict)
{
f_fStrict = fStrict;
}

@Override
public void checkRead(BinaryEntry entry, Subject subject, int nReason)
{
logEntryRequest(entry, subject, false, nReason);

if (subject == null && f_fStrict)
{
throw new SecurityException("subject is not provided");
}
}

@Override
public void checkWrite(BinaryEntry entry, Subject subject, int nReason)
{
logEntryRequest(entry, subject, true, nReason);

if (subject == null && f_fStrict)
{
throw new SecurityException("subject is not provided");
}
}

@Override
public void checkReadAny(BackingMapContext context, Subject subject,
int nReason)
{
logMapRequest(context, subject, false, nReason);

if (subject == null && f_fStrict)
{
throw new SecurityException("subject is not provided");
}
}

@Override
public void checkWriteAny(BackingMapContext context, Subject subject,
int nReason)
{
logMapRequest(context, subject, true, nReason);

if (subject == null && f_fStrict)
{
throw new SecurityException("subject is not provided");
}
}

protected void logEntryRequest(BinaryEntry entry, Subject subject,
boolean fWrite, int nReason)
{
CacheFactory.log('"' + (fWrite ? "Write" : "Read")
+ "\" request for key=\""
+ entry.getKey()
+ (subject == null ?
"\" from unidentified user" :
"\" on behalf of " + subject.getPrincipals())
+ " caused by \"" + nReason + "\""
, CacheFactory.LOG_INFO);
}

protected void logMapRequest(BackingMapContext context, Subject subject,
boolean fWrite, int nReason)
{
CacheFactory.log('"' + (fWrite ? "Write-any" : "Read-any")
+ "\" request for cache \""
+ context.getCacheName() + '"'
+ (subject == null ?
" from unidentified user" :
" on behalf of " + subject.getPrincipals())
+ " caused by \"" + nReason + "\""
, CacheFactory.LOG_INFO);
}

private final boolean f_fStrict;
}

アクセス制御認可の実装の宣言

アクセス制御認可実装を宣言するには、オペレーション・オーバーライド・ファイルを編集して、<storage-authorizers要素を<cluster-config要素内に含め、各認可実装を<storage-authorizer要素を使用して宣言します。<storage-auhorizer要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。各宣言には、実装を選択するためにパーティション化キャッシュで使用される一意のid属性が含まれている必要があります。次に例を示します。

<cluster-config>
<storage-authorizers>
<storage-authorizer id="LogAuthorizer">
<class-name>package.MyLogAuthorizer</class-name>
</storage-authorizer>
</storage-authorizers>
</cluster-config>

代替案として、<storage-authorizer>要素では、インスタンスを作成するためのファクトリ・クラスを使用する<class-factory-name>要素、およびオブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドを指定する<method-name>要素の使用がサポートされています。次に例を示します。

<cluster-config>
<storage-authorizers>
<storage-authorizer id="LogAuthorizer">
<class-factory-name>package.MyAuthorizerFactory</class-factory-name>
<method-name>getAuthorizer</method-name>
</storage-authorizer>
</storage-authorizers>
</cluster-config>

実装に必要な初期化パラメータはすべて、<init-params>要素を使用して指定できます。次に例を示します。

<cluster-config>
<storage-authorizers>
<storage-authorizer id="LogAuthorizer">
<class-name>package.MyLogAuthorizer</class-name>
<init-params>
<init-param>
<param-name>f_fStrict</param-name>
<param-value>true</param-value>
</init-param>
</init-params>
</storage-authorizer>
</storage-authorizers>
</cluster-config>

パーティション化キャッシュ上でのアクセス制御認可の有効化

パーティション化キャッシュでアクセス制御認可を有効化するには、キャッシュ構成ファイルを編集して、その値が、オペレーション・オーバーライド・ファイル内で宣言される認可実装のid属性値である分散スキーマの<backing-map-scheme>要素内で<storage-authorizer>要素を追加します。次に例を示します。

<distributed-scheme>
...
<backing-map-scheme>
<storage-authorizer>LogAuthorizer</storage-authorizer>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

[1]
リスナーがMapTriggerListenerの場合、かわりにWrite Any認可チェックが実行されます。

5 Extendクライアント接続の保護

この章では、IDトークンとインターセプタ・クラスを使用してOracle Coherence*Extendクライアントのための認証と認可を提供する方法について説明します。IDトークンは、拡張プロキシへの無許可のアクセスを防ぎます。インターセプタ・クラスは、認証済のクライアントが実行できる操作を制御します。

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

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

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

- Extendクライアントの認可の実装

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

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

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

- IDトークンの使用方法の概要

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

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

- カスタム・アイデンティティ・サータの作成

- カスタム・アイデンティティ・サータの有効化

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

- カスタムIDトークンの相互運用性の理解

IDトークンの使用方法の概要

IDトークン・セキュリティでは、IDトランスフォーマの実装を使用してIDトークンが作成され、アイデンティティ・アサータの実装を使用してIDトークンが検証されます。これらの実装は次のとおりです。

- IDトランスフォーマ – SubjectまたはPrincipalを拡張プロキシに渡されるIDトークンに変換する、クライアント側のコンポーネント。IDトークンは、ID検証に便利なオブジェクトであれば、どんなタイプでもかまいません。既知のセキュリティ・タイプである必要はありません。また、クライアントは、複数のプロキシ・サーバーに接続でき、各プロキシ・サーバーに対して別々に認証を受けます。

- アイデンティティ・アサータ – 拡張プロキシ・サービスをホストしているキャッシュ・サーバー上に存在する、クラスタ側のコンポーネント。アサータでは、Extendクライアント上でIDトランスフォーマによって作成されたIDトークンを検証します。アサータは、各プロキシ・サービス固有のIDトークンを検証して、複数の方法でのトークン検証に対応します。Extendクライアントで接続が開始されると、トークンが渡されます。検証が失敗すると、接続が拒否され、セキュリティ例外がスローされます。トランスフォーマとアサータは、既存の接続内で新しいチャネルが作成されたときにも起動します。

図5-1 は、IDトークンを使用してクライアント・アクセスを制限する場合の概念を示しています。

図5-1 IDトークンの概念

IDトランスフォーマ(DefaultIdentityTransformer)およびアイデンティティ・アサータ(DefaultIdentityAsserter)が用意されており、デフォルトで有効になっています。実装では単に、IDトークンとしてSubject (Java)またはPrincipal (.NET)を使用します。カスタムのIDトランスフォーマおよびアイデンティティ・アサータを実装し、オペレーション・オーバーライド・ファイルで有効にすることにより、デフォルトの動作をオーバーライドできます。

注意:

- 実行時、IDトランスフォーマの実装クラスは、Extendクライアントのクラスパスに存在する必要があり、アイデンティティ・アサータの実装クラスは、拡張プロキシ・サーバーのクラスパスに存在する必要があります。

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

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

渡されたSubjectまたはPrincipalを単に返すデフォルトIDトランスフォーマの実装(DefaultIdentityTransformer)が提供されています。デフォルトの実装を使用しない場合は、独自のカスタム・トランスフォーマの実装を作成できます。

注意:

実行時、IDトークンは、既知のタイプに対して自動的にシリアライズされ、拡張接続リクエストの一部として送信されます。.NETクライアントおよびC++クライアントの場合は、POFタイプを使用する必要があります。事前定義されているPOFタイプ以外のセキュリティ・オブジェクト・タイプの使用方法の詳細は、「カスタム・セキュリティ・タイプの使用方法」を参照してください。

JavaおよびC++の場合、IdentityTransformerインタフェースを実装することで、カスタムIDトランスフォーマを作成します。C#クライアントではIIdentityTransformerインタフェースを実装します。

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

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

import com.tangosol.net.security.IdentityTransformer;
import javax.security.auth.Subject;
import com.tangosol.net.Service;

public class PasswordIdentityTransformer
implements IdentityTransformer
{
public Object transformIdentity(Subject subject, Service service)
throws SecurityException
{
return System.getProperty("mySecretPassword");
}
}

既存のクライアント認証実装に対する可能なソリューションの1つは、Principal名がパスワードとして設定されている新しいPrincipalをSubjectに追加することです。JAAS認証時に、既存のJAASログイン・モジュールを変更するか、またはパスワードPrincipalを追加する必要なログイン・モジュールを追加することによって、パスワードPrincipalをSubjectに追加します。JAAS APIでは複数のログイン・モジュールが許可されており、それぞれがSubjectを変更します。同様に、.NETでもPrincipalにパスワードIDを追加します。クラスタ側のアサータは、PrincipalとパスワードPrincipalの両方を検証します。「カスタム・アイデンティティ・アサータの作成」を参照してください。

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

カスタムIDトランスフォーマの実装を有効にするには、クライアント側のtangosol-coherence-override.xmlファイルを編集し、<security-configノード内に<identity-transformer要素を追加します。この要素には、実装クラスの完全な名前を含める必要があります。次に例を示します。

<?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">
<security-config>
<identity-transformer>
<class-name>com.my.PasswordIdentityTransformer</class-name>
</identity-transformer>
</security-config>
</coherence>

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

IDトークンがSubjectまたはPrincipalであることをアサートするデフォルト・アイデンティティ・アサータの実装(DefaultIdentityAsserter)が提供されています。デフォルトの実装を使用しない場合は、独自のカスタム・アサータの実装を作成できます。

JavaおよびC++の場合、IdentityAsserterインタフェースを実装することで、アイデンティティ・アサータを作成します。C#クライアントではIIdentityAsserterインタフェースを実装します。

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

例5-2アイデンティティ・アサータの実装のサンプル

import com.tangosol.net.security.IdentityAsserter;
import javax.security.auth.Subject;
import com.tangosol.net.Service;

public class PasswordIdentityAsserter
implements IdentityAsserter
{
public Subject assertIdentity(Object oToken, Service service)
throws SecurityException
{
if (oToken instanceof String)
{
if (((String) oToken).equals(System.getProperty("mySecretPassword")))
{
return null;
}
}
throw new SecurityException("Access denied");
}
}

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

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

カスタム・アイデンティティ・サータの実装を有効にするには、クライアント側のtangosol-coherence-override.xmlファイルを編集し、<security-configノード内に<identity-asserter要素を追加します。この要素には、実装クラスの完全な名前を含める必要があります。例:

<?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">
<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でタイプを定義する必要があります。サポートされていないタイプを使用するには、2つの方法があります。

タイプの変換

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

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

POFでのカスタム・タイプの定義

クライアントとプロキシの両方のPOF構成ファイルでカスタム・セキュリティ・タイプを定義できます。JavaでのPOFの使用方法に関する詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。C++およびC#でのPOFの使用方法に関する詳細は、それぞれ、『Oracle Coherenceリモート・クライアントの開発』の統合オブジェクトの構築(C++)に関する項および統合オブジェクトの構築(.NET)に関する項を参照してください。

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

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

Oracle Coherenceのアップグレード

アップグレード・プロセスの間に、相互運用性の問題が発生する場合があります。この場合、複数の異なるバージョンのクライアントが、複数の異なるバージョンのプロキシ・サーバーと相互運用されている可能性があります。カスタム・アイデンティティ・サータが拡張クライアントから送信されたIDトークンを処理できることを確認してください。逆に言えば、カスタムIDトランスフォーマが、拡張プロキシが処理できるトークンを送信していることを確認してください。

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

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

このようなシナリオに対する1つの戦略は、クライアントの更新時に、デフォルトのトークン・タイプを一時的に受け入れるカスタム・アイデンティティ・サータを用意することです。アイデンティティ・アサータは、外部ソースをチェックして、これらのトークンが受け入れられるかどうかを示すポリシーの有無を確認します。すべてのクライアントがカスタム・トークンを使用するように更新されたら、カスタム・トークンを受け入れるようにポリシーを変更します。

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

サブジェクトのスコープを設定すると、クライアントに返されるリモート・キャッシュおよびリモート起動のサービス参照を、現在のセキュリティ・コンテキストのIDと関連付けできます。デフォルトでは、サブジェクトのスコープ設定は無効です。これは、リモート・キャッシュおよびリモート起動サービス参照がグローバルに共有されることを意味します。

サブジェクトのスコープ設定が有効な場合、クライアントは、プラットフォーム固有の認証APIを使用してセキュリティ・コンテキストを確立します。クライアントによってNamedCacheインスタンスおよびInvocationServiceインスタンスが作成されるたびに、SubjectまたはPrincipalが現在のセキュリティ・コンテキストから取得されます。その後、すべてのリクエストが、確立されたSubjectまたはPrincipalに対して実行されます。

注意:

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

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

JavaおよびC++クライアントの場合、<security-configノード内の<subject-scope要素を使用して、クライアント側のtangosol-coherence-override.xmlファイルでサブジェクトのスコープを有効にします。次に例を示します。

<?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">
<security-config>
<subject-scope>true</subject-scope>
</security-config>
</coherence>

.NETクライアントの場合、<security-configノード内の<principal-scope要素を使用して、クライアント側のtangosol-coherence-override.xmlファイルでサブジェクトのスコープを有効にします。次に例を示します。

<?xml version='1.0'?>

<coherence 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/coherence.xsd">
<security-config>
<principal-scope>true</principal-scope>
</security-config>
</coherence>

Extendクライアントの認可の実装

Oracle Coherence*Extendの認可により、Extendクライアントのアクセス権に基づいて、クラスタ上で実行できる操作が制御されます。認可ロジックは実装固有であり、クラスタ・プロキシ上で有効です。

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

- Extendクライアントの認可の概要

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

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

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

Extendクライアントの認可の概要

インターセプタ・クラスにより、クライアント認可の実装が可能になります。拡張プロキシがインターセプタ・クラスをコールしてから、クライアントがプロキシ設定されたリソース(キャッシュ、キャッシュ・サービスまたは起動サービス)にアクセスします。インターセプタ・クラスは実装固有のものであり、必要な認可ロジックを指定してからプロキシ設定されたリソースにリクエストを渡す必要があります。

図5-2 は、Extendクライアントの認可の概念を示しています。

図5-2 Extendクライアントの認可の概念

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

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

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

例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);
}
}

EntitledCacheServiceクラスには、名前付きキャッシュ実装が必要です。WrapperNamedCacheクラスが拡張され、NamedCacheインスタンスの各メソッドをラップします。これにより、様々なキャッシュ操作にアクセス制御を適用できます。

注意:

WrapperNamedCacheクラスで提供される機能の多くは、StorageAccessAuthorizerインタフェースにも含まれ、改良された簡便な方法でクラスタ操作を認可できます。詳細は、「サーバー側操作へのアクセスの許可」を参照してください。

例5-4 は、Oracle Coherenceの例から抜粋されたコードです。この例は、NamedCacheメソッドをオーバーライドし、メソッドの実行を許可する前にアクセス・チェックを適用する方法を示しています。クラスの詳細は、例を参照してください。

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

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

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

この章では、Secure Sockets Layer (SSL)を使用して、クラスタ・ノード間のTCMP通信を保護する方法、およびOracle Coherence*Extendクライアントとプロキシ間のTCP通信を保護する方法について説明します。Oracle Coherenceでは、SSL プロトコルの後継バージョンであるTransport Layer Security (TLS) プロトコルがサポートされています。しかし、SSLの方が広く認識されている用語であるため、このドキュメントではSSLという用語を使用します。

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

- SSLの概要

- SSLを使用したTCMP通信の保護

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

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

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

SSLの概要

この項では、このドキュメントで使用されている一般的なSSLの概念について簡単に説明します。SSLに関する完全なガイドを提供することを意図しているものではありません。完全なドキュメントについては、次のリソースを参照してください。SSLについて精通している場合は、この項を省略できます。

- 正式なSSLおよびTLSの仕様 – http://www.ietf.org

- Java SEセキュリティ –
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.html

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

識別と信頼の確立

エンティティの識別は、デジタル証明書と、公開および秘密の暗号化鍵を使用することで確立されます。デジタル証明には、エンティティに関する一般情報と、それに埋め込まれた公開の暗号化鍵が含まれています。デジタル証明は認証局(CA)によって検証され、CAのデジタル証明を使用して署名されています。CAのデジタル証明により、エンティティが本物であるという信頼が確立されます。

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

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

一方向の認証と双方向の認証の使用

クライアントとサーバー間のSSL通信は、一方向または双方向のいずれかの認証を使用して設定されます。一方向の認証では、サーバーは認証用のデジタル証明を送信して、クライアントに対してそのサーバー自体を識別する必要があります。クライアントはサーバーにデジタル証明を送信する必要はなく、サーバーに対して匿名のままです。双方向の認証では、クライアントとサーバーの両方がそれぞれのデジタル証明を相互の認証のために送信する必要があります。双方向の認証では、通信の各サイドで識別の認識が確認されることによって、より強いセキュリティが提供されます。

Java SSLアーティファクトの生成

JDK_HOME/binディレクトリにあるJava keytoolユーティリティにより、SSLアーティファクトが生成および管理されます。これには、キーストアの作成、一意の公開/秘密鍵ペアの生成、公開鍵を含む自己署名付きデジタル証明書の作成、証明書の秘密鍵への関連付け、キーストアへのこれらのアーティファクトの格納などが含まれます。

次の例では、server.jksという名前のキーストアが/testディレクトリに作成されます。公開鍵と秘密鍵のペアは、-dname値("cn=administrator, ou=Coherence, o=Oracle, c=US")によって識別されるエンティティに対して生成されます。公開鍵と識別情報を含む自己署名付き証明書が作成されます。この証明書は180日間有効で、別名(admin)が参照するキーストア・エントリの秘密鍵と関連付けられています。キーストアと秘密鍵の両方にパスワードが必要です。

keytool -genkeypair -dname "cn=administrator, ou=Coherence, o=Oracle, c=US"
-alias admin -keypass password -keystore /test/server -storepass password
-validity 180

前述のコマンドで生成される証明書は、開発目的を十分に果たしています。しかし、証明書は通常VeriSignなどの信頼されるCAによって検証されます。証明書が検証されるためには、keytoolユーティリティを使用して証明書の署名リクエスト(CSR: Certificate Signing Request)ファイルを生成します。

keytool -certreq -file admin.csr

CSRファイルをCAに送信します。CAは、署名済の証明書を返します。keytoolユーティリティを使用して、キーストア内の自己署名付き証明書に置き換わる返された証明書をインポートします。

keytool -importcert -trustcacerts -file signed_admin.cer

最後に、keytoolユーティリティを使用して、信頼キーストアとして機能する2つ目のキーストアを作成します。信頼キーストアには、信頼できるCAのデジタル証明書が保管されます。CAが検証した証明書は、CAの証明書が信頼キーストアにも格納されている場合にのみ、信頼できると見なされます。たとえば、通常の一方向の認証では、クライアントはサーバーの証明書に署名したCAのデジタル証明書が格納された信頼キーストアを持っている必要があります。開発目的の場合、自己署名付き証明書は識別と信頼の両方に使用できます。さらに、1つのキーストアが識別ストアと信頼キーストアの両方として使用できます。

Windows SSLアーティファクトの生成

次の手順では、Windows上で双方向の認証を設定して、Oracle Coherence*Extend .NETクライアントを保護する方法について説明します。.NETクライアントの構成の詳細は、「.NETクライアント側のストリーム・プロバイダの構成」を参照してください。Windows上でSSLを設定する完全な手順については、Windowsのドキュメントを参照してください。

http://technet.microsoft.com/en-us/library/cc782338%28WS.10%29.aspx

Windows上で双方向の認証を設定するには:

1. Visual Studioコマンド・プロンプトで次のコマンドを実行します。

c:\>makecert -pe -n "CN=Test And Dev Root Authority" -ss my -sr LocalMachine -a sha1 -sky signature -r "Test And Dev Root Authority.cer"

c:\>makecert -pe -n "CN=MyServerName" -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "Test And Dev Root Authority" -is MY -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

c:\>makecert -pe -n "CN=MyClient" -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "Test And Dev Root Authority" -is MY -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

2. 信頼できるルート認証局の証明書を作成します(テスト目的のみ)。

makecert -pe -n "CN=Test And Dev Root Authority" -ss my -sr LocalMachine -a sha1 -sky signature -r "Test And Dev Root Authority.cer"

3. 作成した証明書を、個人ストアから信頼できるルート認証局ストアにコピーします。

4. 信頼できるルート証明書に基づいてサーバー証明書を作成します。

makecert -pe -n "CN=MyServerName" -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "Test And Dev Root Authority" -is MY -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

5. 信頼できるルート認証局(Test And Dev Root Authority)の証明書ストアから、公開鍵なしの証明書ファイル(.cer)をエクスポートします。

6. 信頼できるルート認証局(Test And Dev Root Authority)の証明書ストアから、秘密鍵付きの証明書ファイル(.pfx)をエクスポートします。

7. .cerファイルを各クライアント・コンピュータにコピーします。この場所から、sslstreamクライアント・プログラムにアクセスできる必要があります。

8. .pfxファイルを各クライアント・コンピュータにコピーします。

9. 各クライアント・コンピュータの信頼できるルート認証局の証明書ストアに.pfxファイルをインポートします。

10. 各クライアント・コンピュータで、.pfxファイルを削除します。(この手順により、クライアントが秘密鍵をやり取りしたりエクスポートしたりすることがなくなります。)

SSLを使用したTCMP通信の保護

この項では、クラスタ・メンバー間の通信を保護するようにSSLを構成する方法について説明します。この項の構成例は、すべてのクライアントおよびサーバーの有効なデジタル証明書が必要に応じて作成済であることと、証明書に認証局(CA)の署名が付いていることを前提としています。デジタル証明書はアイデンティティ・ストアに配置する必要があり、信頼キーストアには署名元のCAのデジタル証明書を含める必要があります。開発中は、必要に応じて自己署名付きの証明書を使用します。Oracle Coherence*ExtendでのSSLの使用方法については、「SSLを使用したExtendクライアント通信の保護」を参照してください。

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

- SSLを使用したTCMP通信の保護の概要

- SSLソケット・プロバイダの定義

- 事前定義済SSLソケット・プロバイダの使用方法

SSLを使用したTCMP通信の保護の概要

TCMPでは、一方向と双方向の両方のSSL認証がサポートされています。通常、双方向の認証を使用する方が一方向の認証よりも多く、クラスタ環境では一方向の認証は双方向の認証ほど使用されません。さらに、TCMPではpeer-to-peerプロトコルであることを認識する必要があります。peer-to-peerプロトコルは、通常、多くのクラスタ・ノードを相互に接続したままであることが想定される信頼できる環境で動作します。管理およびパフォーマンスに関するSSLの影響について、慎重に考慮してください。

図6-1 は、双方向のSSLを使用するクラスタ・メンバーの概念を示しています。各クラスタ・メンバーには、相互認証で使用されるデジタル証明書を含む信頼キーストアとJavaキーストア(JKS)があります。

図6-1 TCMPでのSSLのアーキテクチャの概念

SSLソケット・プロバイダの定義

オペレーション・オーバーライド・ファイルで、<unicast-listener要素内の<socket-provider要素をオーバーライドして、TCMP用のSSLを構成します。<socket-provider要素を使用して、<socket-providersノード内で定義されたSSLソケット・プロバイダ構成を参照する方法をお薦めします。ただし、<socket-provider要素は、インラインのSSL構成を含めることもサポートしています。この項では、両方の方法について説明します。<socket-provider要素の詳細なリファレンスは、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

注意:

TCMPでSSLを使用するには、Well Knownアドレス(WKA)を使用する必要があります。WKAの設定の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

例6-1 は、SSLの双方向認証の設定を示しています。この設定では、IDストアと信頼キーストアの両方がクラスタ内の各ノードに存在している必要があります。この例では、<protocol>および<algorithm>要素(それぞれTLSおよびSunX509)にデフォルト値を使用しています。これらは完全を期して示しますが、デフォルト値使用の際には省略できます。例では、SSLソケット・プロバイダが<socket-providers>ノード内で定義され、<unicast-listener>要素内から参照される推奨方法を使用しています。

例6-1 TCMP通信に対するSSLのサンプル構成

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<socket-provider system-property="coherence.socketprovider>
mySSLConfig</socket-provider>
<well-known-addresses>
<socket-address id="1">
<address system-property="coherence.wka">198.168.1.5
</address>
<port system-property="coherence.wka.port">8088</port>
</socket-address>
</well-known-addresses>
</unicast-listener>

<socket-providers>
<socket-provider id="mySSLConfig">
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
<password>password</password>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
</trust-manager>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
</socket-providers>
</cluster-config>
</coherence>

別の方法として、例6-2に示すように、SSLソケット・プロバイダは、<unicast-listener> 要素内での直接のインライン構成をサポートしています。

例6-2 TCMP通信用のインラインSSL構成のサンプル

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<socket-provider system-property="coherence.socketprovider>
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
<password>password</password>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
</trust-manager>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
<well-known-addresses>
<socket-address id="1">
<address system-property="coherence.wka">198.168.1.5
</address>
<port system-property="coherence.wka.port">8088</port>
</socket-address>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>

事前定義済SSLソケット・プロバイダの使用方法

Oracle Coherenceには、双方向のSSL接続の構成を可能にする、事前定義済のSSLソケット・プロバイダが含まれています。事前定義済ソケット・プロバイダは、信頼されているピアがすべて単一のJKSキーストア内に存在するピア信頼に基づいています。専用のピアの信頼アルゴリズム(PeerX509)は、キーストア内にある証明書の信頼(信頼のみ)を前提として機能し、TCMPがピアツーピア・プロトコルであることを活用します。

事前定義済SSLソケット・プロバイダは、オペレーション・デプロイメント・ディスクリプタの<socket-providers>要素内に定義されています。

...
<cluster-config>
<socket-providers>
<socket-provider id="ssl">
<ssl>
<identity-manager>
<key-store>
<url system-property="coherence.security.keystore">
file:keystore.jks
</url>
<password system-property="coherence.security.
password"/>
</key-store>
<password system-property="coherence.security.password"/>
</identity-manager>
<trust-manager>
<algorithm>PeerX509</algorithm>
<key-store>
<url system-property="coherence.security.keystore">
file:keystore.jks
</url>
<password system-property="coherence.security.
password"/>
</key-store>
</trust-manager>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
</socket-providers>
</cluster-config>
...

構成では、事前定義済SSLソケット・プロバイダには、クラスパスにあるkeystore.jksというJavaキーストアが必要です。オペレーション・オーバーライド・ファイルを使用して、必要に応じて任意のソケット・プロバイダの値を変更します。オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.security.keystoreおよびcoherence.security.passwordシステム・プロパティによってキーストアとパスワードをオーバーライドします。次に例を示します。

-Dcoherence.security.keystore=/mykeystore.jks -Dcoherence.security.password=password

注意:

クラスタ内のすべてのノードに対する証明書がキーストアにインポートされていることを確認してください。

事前定義済SSLソケット・プロバイダを使用するには、<unicast-listener>構成の<socket-provider>要素をオーバーライドして、SSLソケット・プロバイダのid属性を使用してSSLソケット・プロバイダを参照します。次の例では、事前定義済SSLソケット・プロバイダを使用するためにユニキャスト・リスナーを構成しています。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<socket-provider
system-property="coherence.socketprovider>ssl
</socket-provider>
<well-known-addresses>
<socket-address id="1">
<address system-property="coherence.wka">198.168.1.5
</address>
<port system-property="coherence.wka.port">8088</port>
</socket-address>
</well-known-addresses>
</unicast-listener>
</cluster-config>
</coherence>

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

この項では、Extendクライアントとクラスタ・プロキシ間の通信を保護するようにSSLを構成する方法について説明します。この項の構成例は、すべてのクライアントおよびサーバーの有効なデジタル証明書が必要に応じて作成済であることと、証明書に認証局(CA)の署名が付いていることを前提としています。デジタル証明書はアイデンティティ・ストアに配置する必要があり、信頼キーストアには署名元のCAのデジタル証明書を含める必要があります。開発中は、必要に応じて自己署名付きの証明書を使用します。クラスタ・メンバー間でのSSLの使用方法の詳細は、「SSLを使用したTCMP通信の保護」を参照してください。

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

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

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

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

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

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

SSLは、Extendクライアントと拡張プロキシ間の通信を保護するために使用されます。SSLには、クライアント側とクラスタ側の両方での構成が必要です。SSLは、Javaクライアントと.NETクライアントではサポートされていますが、C++ではサポートされていません。

図6-2 は、SSLを使用してクラスタ・プロキシと通信するExtendクライアントの概念を示しています。クライアントとプロキシには、認証に使用されるデジタル証明書を含む信頼キーストアとアイデンティティ・キーストアがあります。Extendクライアントは通常、一方向認証を使用します。一方向認証では、プロキシのみがクライアントを認証し、クライアントはプロキシに対して匿名のままです。

図6-2 Oracle Coherence*ExtendでのSSLのアーキテクチャの概念

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

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

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

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

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

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

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

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

注意:

プロキシ・サーバーに信頼マネージャが構成されている場合は、プロキシでデジタル証明書が交換される可能性があるため、クライアントでは双方向SSL認証を使用する必要があります。一方向SSL認証を使用する場合は、信頼マネージャが構成されていないことを確認してください。

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

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

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

注意:

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

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

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

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

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

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<socket-provider>
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
<password>password</password>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
</trust-manager>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
</defaults>
...

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

<defaults>
<socket-provider>ssl</socket-provider>
</defaults>

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

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

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

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

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

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

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

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

注意:

プロキシ・サーバーに信頼マネージャが構成されている場合は、プロキシでデジタル証明書が交換される可能性があるため、クライアントでは双方向SSL認証を使用する必要があります。一方向のSSL認証を使用する場合は、プロキシの信頼マネージャ構成を削除してください。

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

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>dist-extend</cache-name>
<scheme-name>extend-dist</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>ExtendTcpSSLCacheService</service-name>
<initiator-config>
<tcp-initiator>
<socket-provider>
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
<password>password</password>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
</trust-manager>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
<remote-addresses>
<socket-address>
<address>198.168.1.5</address>
<port>9099</port>
</socket-address>
</remote-addresses>
<connect-timeout>10s</connect-timeout>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>5s</request-timeout>
</outgoing-message-handler>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
</cache-config>

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

注意:

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

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>dist-extend</cache-name>
<scheme-name>extend-dist</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>ExtendTcpSSLCacheService</service-name>
<initiator-config>
<tcp-initiator>
<socket-provider>ssl</socket-provider>
<remote-addresses>
<socket-address>
<address>198.168.1.5</address>
<port>9099</port>
</socket-address>
</remote-addresses>
<connect-timeout>10s</connect-timeout>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>5s</request-timeout>
</outgoing-message-handler>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
</cache-config>

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

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

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

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<socket-provider>
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
<password>password</password>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
</trust-manager>
<socket-provider>tcp</socket-provider>
</ssl>
</socket-provider>
</defaults>
...

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

<defaults>
<socket-provider>ssl</socket-provider>
</defaults>

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

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

注意:

証明書は、Windowサーバーでは、オペレーティング・システム・レベルで証明書マネージャを使用して管理します。サンプルの構成は、証明書マネージャに拡張プロキシの証明書およびプロキシの証明書に署名した信頼できるCAの証明書が含まれていることを前提としています。一般的な例については、「Windows SSLアーティファクトの生成」を参照してください。証明書の管理に関する詳細は、次のサイトを参照してください。

http://technet.microsoft.com/en-us/library/cc782338(WS.10).aspx

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

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

<?xml version="1.0"?>

<cache-config xmlns="http://schemas.tangosol.com/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://schemas.tangosol.com/cache
assembly://Coherence/Tangosol.Config/cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>dist-extend</cache-name>
<scheme-name>extend-dist</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

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

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

フェデレーション内のクラスタ参加者間の通信は、SSL通信を使用して保護することが可能で、この通信はフェデレーテッド・サービス・メンバー間で保護され、SSLセキュリティを必要とする各クラスタ参加者にSSL構成を必要とします。この項では、フェデレーテッド・サービスを実行するすべてのサーバーの有効なデジタル証明書が必要に応じて作成済であることと、証明書が認証局(CA)により署名されていることを前提としています。デジタル証明書はアイデンティティ・ストアに配置する必要があり、信頼キーストアには署名元のCAのデジタル証明書を含める必要があります。

次の手順を実行して、SSLを使用してフェデレーション通信を保護します。

1. オペレーション・オーバーライド・ファイルを編集してSSLソケット・プロバイダ定義を含めるか、既存のSSLソケット・プロバイダ定義を使用します。SSLソケット・プロバイダの構成の詳細は、「SSLソケット・プロバイダの定義」を参照してください。

2. フェデレーテッド・キャッシュ・スキーマを各クラスタ上で編集し、SSLソケット・プロバイダ定義を使用します。次に例を示します。

<federated-scheme>
<scheme-name>federated</scheme-name>
<service-name>federated</service-name>
<backing-map-scheme>
<local-scheme />
</backing-map-scheme>
<autostart>true</autostart>
<socket-provider>mySSLConfig</socket-provider>
<topologies>
<topology>
<name>MyTopology</name>
</topology>
</topologies>
</federated-scheme>

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

SSLソケット・プロバイダは、弱い可能性のある暗号や特定のプロトコル・バージョンの使用を制御するように構成することができます。

暗号スイートおよびプロトコル・バージョンの使用を制御するには、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>

7 Oracle WebLogic ServerにおけるOracle Coherenceの保護

この章では、認証と認可を使用してOracle WebLogic ServerドメインにおいてOracle Coherenceを保護する方法について説明します。説明はOracle WebLogic Server管理コンソール固有のものであり、Oracle WebLogic Scripting Tool (WLST)の詳細は含まれていません。Oracle WebLogic Server管理コンソールの使用の詳細は、を参照してください。WLSTの使用の詳細は、を参照してください。

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

- Oracle WebLogic ServerにおけるOracle Coherenceの保護の概要

- Oracle Coherenceクラスタ・メンバーシップの保護

- Oracle Coherenceのキャッシュおよびサービスの認可

- IDトークンでのExtendクライアント・アクセスの保護

Oracle WebLogic ServerにおけるOracle Coherenceの保護の概要

Oracle WebLogic Serverドメイン内でOracle Coherenceをデプロイする場合に使用できるいくつかのセキュリティ機能があります。デフォルトのセキュリティ構成では、いずれのサーバーもクラスタに参加でき、いずれのExtendクライアントもクラスタのリソースにアクセスできます。クラスタの無許可の使用に対して保護するには、次のセキュリティ機能を構成する必要があります。

- Oracle Coherenceアクセス・コントローラ – クラスタ・メンバー間の認可を提供します

- Oracle WebLogic Server認可 – Oracle Coherenceキャッシュおよびサービスへ認可を提供します

- Oracle Coherence IDトークン – Extendクライアントの認証を提供します

Oracle WebLogic ServerドメインにおけるOracle Coherenceのセキュリティの多くは、既存のセキュリティ機能を再利用します。これらの既存のセキュリティ・コンポーネントの知識が前提となっています。可能な場合は、このドキュメント内で既存のコンテンツへの参照が提供されます。

Oracle Coherenceクラスタ・メンバーシップの保護

Oracle Coherenceセキュリティ・フレームワーク(アクセス・コントローラ)をOracle WebLogic Serverドメインで有効化して、クラスタ・リソースおよび操作へのアクセスを保護できます。アクセス・コントローラは認可を提供し、クラスタ・メンバー間の暗号化/復号化を使用して信頼を検証します。アクセス・コントローラの詳細は、「アクセス・コントローラの使用方法の概要」を参照してください。

Oracle WebLogic Serverでは、アクセス・コントローラは、管理対象Coherenceサーバーのキーストアを使用してOracle Coherenceクラスタ・メンバー間のコール元IDを確立します。デモアイデンティティ・キーストアがデフォルトで使用され、それにはデフォルトのSSL ID (DemoIdentity)が含まれています。デフォルトのキーストアおよびIDは、設定の必要がなく、開発およびテストに適しています。特定のキーストアおよびIDを本番環境に作成する必要があります。Oracle WebLogic Serverにおけるキーストア、IDおよび信頼の構成の詳細は、「Oracle WebLogic Serverのセキュリティの管理」を参照してください。

Oracle Coherenceセキュリティ・フレームワークの有効化

Oracle WebLogic Serverドメインでセキュリティ・フレームワークを有効化するには:

1. 「Coherenceクラスタのサマリー」ページから、「Coherenceクラスタ」をクリックして、その設定を構成します。

2. クラスタの設定ページから、「セキュリティ」タブをクリックします。

3. 一般タブから、セキュリティ・フレームワーク有効オプションをクリックし、セキュリティ・フレームワークを有効化します。

4. 「保存」をクリックします。

セキュリティ・フレームワークで使用するIDの指定

Oracle Coherenceセキュリティ・フレームワークでは、認証を実行する際にプリンシパル(ID)が必要です。SSLデモアイデンティティ・キーストアがデフォルトで使用され、それにはデフォルトのSSL ID (DemoIdentity)が含まれています。SSLデモ・キーストアおよびIDは通常、開発中に使用されます。本番環境では、SSLキーストアおよびIDを作成する必要があります。たとえば、Javaのkeytoolユーティリティを使用して、adminIDを含むキーストアを作成します。

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

注意:

SSLキーストアおよびIDを作成する場合、そのSSLキーストアおよびIDを使用するようにOracle WebLogic Serverを構成する必要があります。さらに、クラスタ内のすべての管理対象Coherenceサーバーのキーストアに、同じSSL IDが存在する必要があります。「設定」ページの「キーストア」および「SSL」タブを使用して、管理対象CoherenceサーバーにキーストアおよびIDを構成します。

デフォルトのSSL IDをオーバーライドして、セキュリティ・フレームワークで使用するIDを指定するには:

1. 「Coherenceクラスタのサマリー」ページから、「Coherenceクラスタ」をクリックして、その設定を構成します。

2. クラスタの設定ページから、「セキュリティ」タブをクリックします。

3. セキュリティ・フレームワークがまだ有効でない場合は、一般タブから、セキュリティ・フレームワーク有効オプションをクリックし、有効化します。

4. 「秘密鍵の別名」フィールドに、IDの別名を入力します。

5. 「秘密鍵のパスフレーズ」フィールドに、IDのパスワードを入力します。

6. 「秘密鍵のパスフレーズを確認」フィールドに、パスワードを再入力します。

7. 「保存」をクリックします。

Oracle Coherenceのキャッシュおよびサービスの認可

Oracle WebLogic Server認証を使用して、ドメイン内で実行するOracle Coherenceリソースを保護できます。特に、様々なロールおよびポリシーを作成して、キャッシュおよびサービスへのアクセスを制御できます。デフォルトでは認可が有効であり、デフォルトの認可ポリシーではすべてのユーザーがすべてのOracle Coherenceリソースにアクセスできます。Oracle WebLogic Serverにおけるロールおよびポリシーの作成の詳細は、「Oracle WebLogic Serverロールおよびポリシーによるリソースの保護」を参照してください。

認可ロールおよびポリシーは、キャッシュおよびサービスに明示的に構成されます。保護されることになるキャッシュ名およびサービスを知っておく必要があります。キャッシュ構成ファイルの調査によって、キャッシュ名およびサービス名が提供される場合があります。ただし、Oracle Coherenceのキャッシュ名のワイルドカード・サポートのために、アプリケーションで使用されているキャッシュ名を知っているアプリケーション開発者またはアーキテクトに確認する必要がある場合があります。たとえば、キャッシュ構成ファイル内のキャッシュ・マッピングは、ワイルドカード(*またはdist-*など)を使用する可能性があり、アプリケーションで実際に使用されているキャッシュの名前を示しません。

注意:

サービスまたはキャッシュ・リソースを削除しても、リソースに対して定義されているロールおよびポリシーは削除されません。ロールおよびポリシーは、サービスまたはキャッシュ・リソースを削除する前に、明示的に削除する必要があります。

キャッシュ認可の指定

Oracle WebLogic Server認証を使用して、特定のOracle Coherenceキャッシュへのアクセスを制限できます。キャッシュ認証を指定するには:

1. 「Coherenceクラスタのサマリー」ページから、「Coherenceクラスタ」をクリックして、その設定を構成します。

2. クラスタの設定ページから、「セキュリティ」タブおよび「キャッシュ」サブタブをクリックします。

3. Click 「新規」をクリックして、ロールやポリシーを定義するキャッシュを定義します。Coherenceキャッシュの作成ページが表示されます。

4. 「名前」フィールドにキャッシュの名前を入力します。キャッシュの名前は、アプリケーションで使用されるキャッシュの名前と正確に一致する必要があります。

5. 「終了」をクリックします。Coherenceのキャッシュ・ページに、キャッシュがリストされます。

6. キャッシュをクリックしてその設定ページにアクセスし、「ロール」タブと「ポリシー」タブをそれぞれ使用してスコープ指定ロールとスコープ指定ポリシーを定義できます。たとえば、特定のユーザーにキャッシュへのアクセスを許可するポリシーを作成できます。グローバル・ロールのメンバーシップに基づいてユーザーを選択するか、またはCoherence固有のスコープ指定ロールを作成して、キャッシュにアクセスできるユーザーの定義のために使用できます。スコープ指定ロールおよびポリシーの指定の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

サービス認可の指定

Oracle WebLogic Server認証を使用して、Oracle Coherenceサービスへのアクセスを制限できます。キャッシュ・サービス(たとえば分散キャッシュ・サービス)に認証を指定すると、そのサービスで作成されるすべてのキャッシュへのアクセスに影響します。

サービス認証を指定するには:

1. 「Coherenceクラスタのサマリー」ページから、「Coherenceクラスタ」をクリックして、その設定を構成します。

2. クラスタの設定ページから、「セキュリティ」タブおよび「サービス」サブタブをクリックします。

3. 「新規」をクリックして、ロールやポリシーを定義するサービスを定義します。Coherenceサービスの作成ページが表示されます。

4. 「名前」フィールドにサービスの名前を入力します。サービスの名前は、アプリケーションで使用されるサービスの名前と正確に一致する必要があります。

注意:

正確な名前には、サービス名に接頭辞としてスコープ名を含める必要があります。スコープ名は、キャッシュ構成ファイルに明示的に定義するか、より一般的には開発モジュール名から取ることができます。たとえば、ContactsServiceという名前のサービスを定義するcontacts.garという名前のGARをデプロイする場合、正確なサービス名はcontacts:ContactsServiceとなります。

5. 「終了」をクリックします。Coherenceのサービス・ページに、サービスがリストされます。

6. サービスをクリックしてその設定ページにアクセスし、「ロール」タブと「ポリシー」タブをそれぞれ使用してスコープ指定ロールとスコープ指定ポリシーを定義できます。たとえば、特定のユーザーにサービスのアクセスを許可するポリシーを作成できます。グローバル・ロールのメンバーシップに基づいてユーザーを選択するか、またはCoherence固有のスコープ指定ロールを作成して、サービスにアクセスできるユーザーの定義のために使用できます。スコープ指定ロールおよびポリシーの指定の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

IDトークンでのExtendクライアント・アクセスの保護

IDトークンは、Oracle Coherenceプロキシ・サーバーを介したOracle Coherenceクラスタへの無許可のアクセスに対して保護するために使用されます。IDトークンは、ローカル(WebLogic Server内)のExtendクライアント、およびリモート(WebLogic Server外)のJava、C++、および.NET Extendクライアントによって使用されます。有効なIDトークンを渡すクライアントのみに、クラスタ・サービスへのアクセスが許可されます。null IDトークンが渡される場合(Subjectのスコープ外で接続するクライアント)、クライアントはOracle WebLogic Serverの匿名ユーザーとして処理されます。Extendクライアントは、匿名ユーザーがアクセスできるキャッシュおよびサービスにアクセスできます。

注意:

IDが確立されたら、認可ポリシーを使用してそのIDを特定のキャッシュおよびサービスに制限する必要があります。認可の構成の詳細は、「Oracle Coherenceのキャッシュおよびサービスの認可」を参照してください。

IDトークン・セキュリティでは、IDトークンを作成するIDトランスフォーマの実装、およびIDトークンを検証するアイデンティティ・アサータの実装が必要です。デフォルトのIDトランスフォーマの実装(DefaultIdentityTransformer)およびアイデンティティ・アサータの実装(DefaultIdentityAsserter)が用意されています。デフォルトの実装では、IDトークンとしてSubjectまたはPrincipalを使用します。ただし、いずれのセキュリティ・トークン・タイプもサポートする必要がある場合には(たとえばKerberosトークンのサポート)、カスタム実装を作成できます。トランスフォーマおよびアサータの実装作成の詳細は、「IDトークンを使用したクライアント接続の制限」を参照してください。

Oracle WebLogic Serverで使用するIDトランスフォーマの有効化

IDトランスフォーマはIDトークンとIDとを関連付けます。ローカル(Oracle WebLogic Server内)のExtendクライアントの場合、デフォルトのIDトランスフォーマは置換できません。デフォルトのIDトランスフォーマは、現在のOracle WebLogic Serverユーザーを示すweblogic.security.acl.internal.AuthenticatedSubjectのタイプのトークンを渡します。

リモート(Oracle WebLogic Server外)のExtendクライアントの場合、IDトランスフォーマの実装クラスをアプリケーションのクラスパスの一部として含める必要があり、実装クラスの完全修飾名をクライアントのオペレーション・オーバーライド・ファイルに定義する必要があります。IDトランスフォーマの有効化の詳細は、「カスタムIDトランスフォーマの有効化」を参照してください。次の例では、デフォルトのIDトランスフォーマを有効化します。

...
<security-config>
<identity-transformer>
<class-name>
com.tangosol.net.security.DefaultIdentityTransformer</class-name>
</identity-transformer>
</security-config>
...

リモートのExtendクライアントは、Subject.doASメソッド内のキャッシュ操作を実行する必要があります。次に例を示します。

Principal principal = new WLSUserImpl("user");
Subject subject = new Subject();
subject.getPrincipals().add(principal);

Subject.doAs(subject, new PrivilegedExceptionAction()
{
NamedCache cache = CacheFactory.getCache("mycache");
...

Oracle WebLogic Serverで使用するアイデンティティ・アサータの有効化

アイデンティティ・アサータは、Oracle Coherenceクラスタに対して有効化する必要があり、クライアントのIDトークンをアサート(検証)するために使用されます。ローカル(Oracle WebLogic Server内)のExtendクライアントの場合、アイデンティティ・アサータはweblogic.security.acl.internal.AuthenticatedSubjectのタイプのトークンをアサートするためにすでに有効化されています。

リモート(Oracle WebLogic Server外)のExtendクライアントの場合、カスタム・アイデンティティ・サータの実装クラスがGARにパッケージ化されている必要があります。ただし、リモートのExtendクライアントがトークンとしてnullを渡す場合、アイデンティティ・アサータは必要ありません。プロキシ・サービスがnullでないトークンを受信し、アイデンティティ・アサータの実装クラスが構成されていない場合、SecurityExceptionがスローされ、接続試行が拒否されます。

クラスタに対してアイデンティティ・アサータを有効化するには:

1. 「Coherenceクラスタのサマリー」ページから、「Coherenceクラスタ」をクリックして、その設定を構成します。

2. クラスタの設定ページから、「セキュリティ」タブをクリックします。

3. 一般タブから「IDアサーション」フィールドを使用して、アサータ・クラスの完全修飾名、および必要な場合はクラス・コンストラクタ引数を入力します。たとえば、デフォルトのアイデンティティ・アサータを使用して、次のように入力します。

com.tangosol.net.security.DefaultIdentityAsserter

4. 「保存」をクリックします。

5. 変更を有効にするには、クラスタ・サーバーを再起動するか、GARを再デプロイします。

8 Oracle Coherence RESTの保護

この章では、Oracle Coherence RESTを保護する方法について説明します。Oracle Coherence RESTの使用方法に関する全般的な説明は含まれていません。Oracle Coherence RESTの使用方法の詳細は、を参照してください。

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

- Oracle Coherence RESTの保護の概要

- Oracle Coherence RESTでのHTTP Basic認証の使用方法

- Oracle Coherence RESTでのSSL認証の使用方法

- Oracle Coherence RESTでのSSLおよびHTTP Basic認証の使用方法

- Oracle Coherence RESTのための認可の実装

Oracle Coherence RESTの保護の概要

Oracle Coherence RESTセキュリティは、認証と認可の両方を使用してクラスタ・リソースへのアクセスを制限します。認証では、HTTP Basic、クライアント側のSSL証明書、およびHTTP Basicとクライアント側のSSL証明書の併用がサポートされています。認可は、Oracle Coherence*Extendスタイルの認可を使用して実装されます。これは、キャッシュ・サービスおよび起動サービスの操作に対してきめ細かいアクセス権を提供するインターセプタ・クラスに依存しています。Oracle Coherence RESTの認証と認可は、Oracle Coherenceの既存のセキュリティ機能の多くを再利用します。可能な場合は、既存のコンテンツへの参照が提供されます。

Oracle Coherence RESTのセキュリティは、デフォルトでは無効になっており、必要に応じて有効化されます。認証と認可は、別々に構成されます。認証は、<http-acceptor要素内の<auth-method要素を使用してキャッシュ構成ファイルで構成されます。<auth-method要素の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。認可の実装の詳細は、「Extendクライアントの認可の実装」を参照してください。

Oracle Coherence RESTでのHTTP Basic認証の使用方法

HTTP Basic認証は、HTTP認可リクエスト・ヘッダーにエンコードされて送信される資格証明(ユーザー名とパスワード)を使用して認証を行います。HTTP Basic認証では、この項で説明するJava Authentication and Authorization Service (JAAS)ログイン・モジュールが必要です。

Basic認証を指定するには、http-acceptor要素内に、basicに設定された<auth-method>要素を追加します。

<proxy-scheme>
<service-name>RestHttpProxyService</service-name>
<acceptor-config>
<http-acceptor>
...
<auth-method>basic</auth-method>
</http-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>

ログイン・モジュールの指定

HTTP Basic認証は、HTTP Basic認証ヘッダーから渡されたクライアントの資格証明を認証するJAAS javax.security.auth.spi.LoginModule実装を必要とします。その結果として生成されるSubjectは、必要に応じて、Oracle Coherence*Extendスタイルの認可とOracle Coherenceセキュリティ・フレームワークの認可の両方で使用できます。JAASおよびLoginModule実装の作成に関する説明は、JAASリファレンス・ガイドを参照してください。

http://docs.oracle.com/javase/7/docs/technotes/guides/security/jaas/JAASRefGuide.html

ログイン・モジュールを指定するには、COHERENCE_HOME/lib/security/login.configログイン構成ファイルを変更し、使用するログイン・モジュール実装を含むCoherenceRESTエントリを追加します。次に例を示します。

CoherenceREST {
package.MyLoginModule required debug=true;
};

実行時、コマンド行から(java.security.auth.login.configシステム・プロパティを使用)、またはJavaセキュリティ・プロパティ・ファイルで、使用するlogin.configファイルを指定します。詳細は、次のサイトを参照してください。

http://docs.oracle.com/javase/7/docs/technotes/guides/security/jaas/JAASLMDevGuide.html

便宜を図るため、標準的なJavaランタイム・クラスにのみ依存するJavaキーストア(JKS) LoginModuleの実装が用意されています。このクラスは、COHERENCE_HOME/lib/security/coherence-login.jarファイルにあります。実装を使用するには、このライブラリを、プロキシ・サーバーのクラスパスか、JREのlib/ext (標準拡張)ディレクトリに配置します。

login.config構成ファイルで、次のとおりJKSログイン・モジュール実装を指定します。

CoherenceREST {
com.tangosol.security.KeystoreLogin required
keyStorePath="${user.dir}${/}security${/}keystore.jks";
};

エントリには、キーストアへのパスが含まれています。keyStorePath変数をキーストアの場所に変更します。キーストアの作成手順については、「Java SSLアーティファクトの生成」を参照してください。

Oracle Coherence RESTでのSSL認証の使用方法

SSLは、デジタル証明書および暗号化キーを使用して識別と信頼の両方を確立する認証メカニズムを提供します。SSLアーティファクトの生成など、SSLの概要については、「SSLの概要」を参照してください。

クライアント側のSSL証明書は、クライアントを認証するHTTPアクセプタに渡されます。SSLでは、SSLベースのソケット・プロバイダがHTTPアクセプタ用に構成されている必要があります。次の手順では、SSLを構成し、プロキシでHTTPアクセプタ用のSSLソケット・プロバイダを定義する方法についてのみ説明します。クライアント側でのSSLの設定手順については、RESTのクライアント・ライブラリに関するドキュメントを参照してください。

SSL認証を指定するには、http-acceptor要素内に、certに設定された<auth-method>要素を追加します。

<proxy-scheme>
<service-name>RestHttpProxyService</service-name>
<acceptor-config>
<http-acceptor>
...
<auth-method>cert</auth-method>
</http-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>

HTTPアクセプタ用のSSLソケット・プロバイダの構成

認証にSSLを使用する場合は、HTTPアクセプタ用のSSLソケット・プロバイダを構成します。HTTPアクセプタ用にSSLを構成するには、SSLソケット・プロバイダ定義を明示的に追加するか、オペレーション・オーバーライド・ファイル内のSSLソケット・プロバイダ定義を参照します。

SSLソケット・プロバイダの明示的な定義

HTTPアクセプタ用にSSLソケット・プロバイダを明示的に構成するには、各<proxy-scheme定義の<http-acceptor要素内に<socket-provider要素を追加します。<socket-provider要素の詳細なリファレンスは、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

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

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

例8-1 HTTP Acceptor用のSSL構成のサンプル

<proxy-scheme>
<service-name>RestHttpProxyService</service-name>
<acceptor-config>
<http-acceptor>
...
<socket-provider>
<ssl>
<protocol>TLS</protocol>
<identity-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:server.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
<password>password</password>
</identity-manager>
<trust-manager>
<algorithm>SunX509</algorithm>
<key-store>
<url>file:trust.jks</url>
<password>password</password>
<type>JKS</type>
</key-store>
</trust-manager>
</ssl>
</socket-provider>
...
<auth-method>cert</auth-method>
</http-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>

SSLソケット・プロバイダ定義の参照

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

注意:

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

<proxy-scheme>
<service-name>RestHttpProxyService</service-name>
<acceptor-config>
<http-acceptor>
...
<socket-provider>ssl</socket-provider>
...
<auth-method>cert</auth-method>
</http-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>

保護されたRESTサービスへのアクセス

次の例は、証明書およびHTTP Basic認証を要求するRESTサービスにアクセスするJerseyベースのクライアントを示しています。Jerseyクライアントの作成に関する詳細は、http://jersey.java.net/nonav/documentation/latest/index.htmlを参照してください。

クライアントSSL構成ファイル

クライアントSSL構成ファイル(ssl.xml)では、クライアントのキーストアおよび信頼キーストアを構成します。

<ssl>
<identity-manager>
<key-store>
<url>file:keystore.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>
</ssl>

Jersey SSLクライアントのサンプル

package example;
import com.oracle.common.net.SSLSocketProvider;
import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.ClientResponse;
import com.sun.jersey.api.client.WebResource;
import com.sun.jersey.api.client.config.DefaultClientConfig;
import com.sun.jersey.client.urlconnection.HTTPSProperties;
import com.sun.jersey.api.client.filter.HTTPBasicAuthFilter;
import com.tangosol.internal.net.ssl.LegacyXmlSSLSocketProviderDependencies;
import com.tangosol.run.xml.XmlDocument;
import com.tangosol.run.xml.XmlHelper;
import javax.net.ssl.HostnameVerifier;
import javax.net.ssl.SSLSession;
import javax.ws.rs.core.MediaType;

public class SslExample
{
public static Client createHttpsClient(SSLSocketProvider provider)
{
DefaultClientConfig dcc = new DefaultClientConfig();
HTTPSProperties prop = new HTTPSProperties(new HostnameVerifier()
{
public boolean verify(String s, SSLSession sslSession)
{
return true;
}
}, provider.getDependencies().getSSLContext());
dcc.getProperties().put(HTTPSProperties.PROPERTY_HTTPS_PROPERTIES, prop);
return Client.create(dcc);
}

public static void PUT(String url, MediaType mediaType, String data)
{
process(url, "put", mediaType, data);
}

public static void GET(String url, MediaType mediaType)
{
process(url, "get", mediaType, null);
}

public static void POST(String url, MediaType mediaType, String data)
{
process(url, "post", mediaType, data);
}

public static void DELETE(String url, MediaType mediaType)
{
process(url, "delete", mediaType, null);
}

static void process(String url, String action, MediaType mediaType, String
data)
{
try
{
XmlDocument xml = XmlHelper.loadFileOrResource("/ssl.xml", null);
SSLSocketProvider provider = new SSLSocketProvider(new
LegacyXmlSSLSocketProviderDependencies(xml));
Client client = createHttpsClient(provider);
ClientResponse response = null;
WebResource webResource = client.resource(url);

// If you've specified the "cert+basic" auth-method in your Proxy
// http-acceptor configuration, initialize and add an HTTP basic
// authentication filter by
// uncommenting the following line and changing the username and password
// appropriately.
//client.addFilter(new HTTPBasicAuthFilter("username", "password"));

if (action.equalsIgnoreCase("get"))
{
response = webResource.type(mediaType).get(ClientResponse.class);
}
else if (action.equalsIgnoreCase("post"))
{
response = webResource.type(mediaType).post
(ClientResponse.class, data);
}
else if (action.equalsIgnoreCase("put"))
{
response = webResource.type(mediaType).put
(ClientResponse.class, data);
}
else if (action.equalsIgnoreCase("delete"))
{
response = webResource.type(mediaType).delete
(ClientResponse.class, data);
}
System.out.println("response status:" + response.getStatus());
if (action.equals("get"))
{
System.out.println("Result: " + response.getEntity(String.class));
}
}
catch (Exception e)
{
e.printStackTrace();
}
}

public static void main(String args[])
{
PUT("https://localhost:8080/dist-http-example/1",
MediaType.APPLICATION_JSON_TYPE, "{\"name\":\"chris\",\"age\":32}");
PUT("https://localhost:8080/dist-http-example/2",
MediaType.APPLICATION_XML_TYPE,
"<person><name>admin</name><age>30</age></person>");
DELETE("https://localhost:8080/dist-http-example/1",
MediaType.APPLICATION_XML_TYPE);
GET("https://localhost:8080/dist-http-example/2",
MediaType.APPLICATION_XML_TYPE);
}
}

Oracle Coherence RESTでのSSLおよびHTTP Basic認証の使用方法

HTTP Basic認証の使用は、SSL認証の使用を妨げるものではありません。つまり、HTTP Basic認証とSSLの両方を併用して、保護を強化することが可能です。SSLおよびHTTP Basic認証の両方を設定する方法の詳細は、それぞれ「Oracle Coherence RESTでのHTTP Basic認証の使用方法」および「Oracle Coherence RESTでのSSL認証の使用方法」を参照してください。

HTTP Basic認証とSSLの両方を使用するように指定するには、http-acceptor要素内に、cert+basicに設定された<auth-method>要素を追加します。

<proxy-scheme>
<service-name>RestHttpProxyService</service-name>
<acceptor-config>
<http-acceptor>
...
<socket-provider>
<ssl>
...
</ssl>
</socket-provider>
...
<auth-method>cert+basic</auth-method>
</http-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>

Oracle Coherence RESTのための認可の実装

Oracle Coherence RESTは、Oracle Coherence*Extend認可フレームワークを使用して、RESTクライアントがクラスタで実行できる操作を制限します。Oracle Coherence*Extendスタイルの認可の実装手順の詳細は、「Extendクライアントの認可の実装」を参照してください。

RESTでのOracle Coherence*Extendスタイルの認可は、HTTP Basic認証、またはHTTP Basic認証とSSL認証の併用を必要とします。つまり、認可を実装する際、HTTP Basic認証とSSLを併用して、保護を強化することが可能です。HTTP Basic認証の使用方法の詳細は、「Oracle Coherence RESTでのHTTP Basic認証の使用方法」を参照してください。SSLとHTTP Basic認証の併用方法の詳細は、「Oracle Coherence RESTでのSSLおよびHTTP Basic認証の使用方法」を参照してください。

注意:

SSLとHTTP Basic認証を併用する場合、HTTP Basic認証の設定に加えて、「Oracle Coherence RESTでのSSL認証の使用方法」で示されているようにSSLを設定してください。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。