10 データ・ソースのセキュリティの理解

この章では、アプリケーション環境でデータ・ソースのセキュリティを構成および使用する方法について説明します。考慮事項として、WebLogic Serverおよびデータベースのユーザーの数とその増減、データ・アクセスの粒度、セキュリティ識別の深度(接続または実際のユーザーのプロパティ)、ソフトウェア・スタック内の各種コンポーネントの調整、ドライバ機能などがあります。

次の項で、データベース・セキュリティのオプションについて説明します。

WebLogicデータ・ソース・セキュリティのオプションの概要
WebLogicデータ・ソース・セキュリティのオプション
トランザクション内の接続
WebLogicデータ・ソース・リソースのパーミッション
データ・ソース・セキュリティの例

WebLogicデータ・ソース・セキュリティのオプションの概要

デフォルトでは、データソースに対し単一のデータベース・ユーザーおよびパスワードを定義します。これをデータソース・ディスクリプタに格納することや、Oracleウォレットを利用することができます(「Oracleウォレットの作成および管理」を参照)。これは、非常に簡単で効率的なセキュリティへのアプローチです。接続プール内のすべての接続をこのユーザーが所有し、接続が不足しても特別な処理は行われません。つまり、この接続プールは同種接続プールであり、リクエストによりセキュリティの観点から接続を取得できます(アフィニティなど、その他の観点もあります)。アプリケーションのエンド・ユーザーに関係なく、プール内のすべての接続では、DBMSにアクセスするために同じセキュリティ資格証明が使用されます。接続を取得するとき、情報はすべてデータソース・ディスクリプタまたはウォレットから入手できるため追加情報は不要です。次に例を示します。

java.sql.Connection conn =  mydatasource.getConnection();

注意:

「プロパティ」フィールドに、名前と値のペアとしてパスワードを入力すること(これは、本番環境では許可されません)、または「パスワード」フィールドにこれを入力することができます。物理データベース接続作成時にJDBCドライバに渡される「プロパティ」で定義されているパスワード値は、「パスワード」フィールドの値によりオーバーライドされます。

プロパティ文字列のパスワード・プロパティのかわりにPassword属性を使用することをお薦めします。Password値は構成ファイルで暗号化され(モジュール・ファイル内のjdbc-driver-paramsタグでパスワードで暗号化された属性として格納されます)、管理コンソールで表示されないためです。「プロパティ」および「パスワード」フィールドは、管理コンソールのデータ・ソース作成ウィザードやデータ・ソース構成ページにあります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」を参照してください。

次に示すように、JDBC APIを使用して、プログラムによりデータベース・ユーザー名およびパスワードを指定することもできます。

java.sql.Connection conn = mydatasource.getConnection(”user”, ”password”);

JDBCの仕様により、getConnection(”user”, ”password”)メソッドにはデータベース・ユーザーと関連するパスワードを渡す必要がありますが、ソフトウェア・ベンダーは、この仕様を独自に解釈して実装を開発してきました。Oracle WebLogic Serverでは、デフォルトでは、これはアプリケーション・サーバー・ユーザーおよびパスワードとして扱われます。

このペアは、有効なユーザーかどうか確認するために認証され、このユーザーがWebLogicセキュリティ・パーミッション・チェックに使用されます。
次にこのユーザーは、データ・ソース資格証明マッパーを使用してデータベース・ユーザーおよびパスワードにマップされます。

WebLogic Serverの実装は、一般的にはこの仕様に従っていますが、データベース資格証明はアプリケーション・コードからワンステップで削除されます。

デフォルトのアプローチはシンプルであり、1人のユーザーのみがすべての処理を行うことになります。誰が更新を実際に行ったか特定できず、また、少なくともデータベース・レベルでは、SQL操作を実行するユーザー別にSQL操作を制限できません。任意のタイプのユーザー別ロジックを、データベースに依存するのではなく、アプリケーション・コードに組み込む必要があります。操作に関するユーザー別情報を提供するために構成できる各種WebLogicデータソース機能があります。

WebLogicデータ・ソース・セキュリティのオプション

次の表で、WebLogicデータ・ソースでデータベース・セキュリティ資格証明を構成するために使用できる各種機能について説明します。

表10-1 セキュリティ資格証明のためのWebLogicデータ・ソース構成オプション

機能	説明	次で使用可能	次では使用不可
ユーザー認証 (デフォルト)	デフォルトの`getConnection(user, password)`動作: WebLogicにより入力が検証され、ディスクリプタのユーザー/パスワードが使用されます。	クライアント識別子の設定	IDプール、データベース資格証明の使用
データベース資格証明の使用	資格証明マッピングを使用するかわりに、指定されたユーザーおよびパスワードを直接使用します。	クライアント識別子の設定、プロキシ・セッション、IDプール	ユーザー認証
クライアント識別子の設定	接続に関連するクライアント識別子プロパティの設定(OracleおよびDB2のみ)。	すべて	N/A
プロキシ・セッション	接続に関連する軽量プロキシ・ユーザーの設定(Oracleのみ)。	クライアント識別子の設定、データベース資格証明の使用	IDプール
IDプール	指定ユーザーが所有する接続の異種プール	クライアント識別子の設定、データベース資格証明の使用	プロキシ・セッション、ユーザー認証、ラベリング、Active GridLink

注意:

これらの機能はすべて、XAドライバと非XAドライバの両方で使用できます。

これらの機能はすべて、管理コンソールのデータ・ソース構成タブの「ID」タブで構成できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 構成: IDオプションに関する項を参照してください。

注意:

WebLogic Serverリリース12.1.2よりも前では、プロキシ・セッションおよび「データベース資格証明の使用」オプションは、「Oracle」タブにのみ存在しました。

次の項でこれらの機能について詳しく説明します。

資格証明マッピングとデータベース資格証明
接続へのクライアント識別子の設定
Oracleプロキシ・セッション
IDベースの接続プール

資格証明マッピングとデータベース資格証明

各WebLogicデータ・ソースには、資格証明マップがあります。これは、WebLogicユーザーの場合は、セキュリティ資格証明(ユーザーおよびパスワード)にキーをマップするために使用されるメカニズムです。デフォルトでは、接続取得時にユーザーおよびパスワードが指定されると、それらはWebLogicユーザーの資格証明として扱われ、検証され、データ・ソースに関連付けられている資格証明マップを使用してデータベース・ユーザーおよびパスワードに変換されます。データ・ソースの資格証明マップで一致するエントリが見つからない場合、データ・ソース定義に関連付けられているユーザーおよびパスワードが使用されます。このデフォルト設定メカニズムのために、どのパーミッションをデフォルト・ユーザーに付与するか注意する必要があります。または、無効なデフォルト・ユーザーを定義して、どのユーザーにも誤って許可が付与されないようにすることもできます(この場合、プールの初期容量をゼロに設定して、プールに有効なユーザーのみが追加されるようにする必要があります)。

資格証明マップにエントリを作成する手順:

WebLogicユーザーを作成します。管理コンソールで、「セキュリティ・レルム」に移動し、レルムを選択し(たとえば、myrealm)、「ユーザー」を選択し、「新規」を選択します。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの資格証明マッピングの構成に関する項の説明に従い、マッピングを作成します。

資格証明マッピングを使用した場合の利点を次に示します。

データベース・ユーザー/パスワードをプログラムにハードコーディングしません。また、WebLogicユーザー/パスワードに加えて、これを要求する必要はありません。
WebLogicセキュリティ設定とデータベース設定の間には抽象層があり、多数のWebLogic IDをDB IDの小規模なセットにマップできます。これにより、WebLogicユーザーが追加/削除されると、必要な中間層の構成のみ更新されます。

データ・ソースへのアクセス権を持つユーザーの数を削減することで、ユーザー・メンテナンスのオーバーヘッドを軽減できます。たとえば、サーブレットに、データ・ソース・アクセスのために事前定義されたWebLogicユーザー/パスワードが1つあり、それがgetConnection(user, password)コールを使用してそのコードに組み込まれているとします。すべてのWebLogicユーザーは、サーブレットにコーディングされている特定のDBMSアクセスにリープできますが、どのユーザーもデータ・ソースへの一般アクセス権を所有する必要はありません。たとえば、売上DBMSがあり、このDBMSを非認証アクセスから保護する必要がある一方で、このDBMSにすべてのユーザーが必要とする日ごとのデータが含まれる場合があります。売上データ・ソースには制限アクセスを構成し、サーブレットを作成して、その接続リクエストに特定のデータ・ソース・アクセス資格証明を組み込みます。この接続を使用して、通常必要となる日ごとの情報のみコール元に配信します。サーブレットはその他のデータを公開できず、WebLogicユーザーはデータ・ソースへの他のアクセスを取得できません。これは、多数の大規模アプリケーションが使用するアプローチであり、WebLogic Serverのデフォルト・マッピング動作の背後にあるロジックです。

資格証明マップを使用した場合のデメリットを次に示します。

多数のユーザーの管理(作成、更新、削除)は困難です。WLSTスクリプトまたはカスタムJMXクライアント・ユーティリティを使用して、資格証明マップ・エントリを管理できます。
データ・ソース間で資格証明マップを共有できないため、複製する必要があります。

一部のアプリケーションでは、資格証明マップを使用しない方が適切です。かわりに、getConnection(user, password)に渡す資格証明をデータベース資格証明として扱う必要があり、接続のためにデータベースでの認証に使用する必要があります。これにより、資格証明マップの使用が回避されます。これは、use-database-credentialsをtrueに設定することで有効化されます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「Oracleパラメータの構成」を参照してください。

use-database-credentialsを有効化すると、次の属性の資格証明マッピングが無効化されます。

identity-based-connection-pooling-enabled
oracle-proxy-session
set client identifier

注意:

データ・ソース・スキーマでは、クライアント識別子の設定機能はcredential-mapping-enabledという名前です。ドキュメントおよびコンソールでは、これがクライアント識別子の設定として参照されます。

資格証明マッピングの動作とデータベース資格証明の使用の確認

資格証明マップを使用する場合、データベースへのアクセス権を持つユーザーのために、データベース・ユーザーへの各WebLogicユーザーのマッピングが必要です。マッピングを行わないと、データ・ソースのデフォルト・ユーザーが使用されます。接続取得時に常にユーザー/パスワードを指定する場合、それらの特定ユーザーの資格証明マップ・エントリのみ必要です。
ユーザー/パスワードを指定せずにデータベース資格証明を使用する場合、データ・ソース・ディスクリプタのデフォルト・ユーザーおよびパスワードが常に使用されます。接続取得時にユーザー/パスワードを指定する場合、そのユーザーが資格証明に対し使用されます。WebLogicユーザーは、データ・ソース接続プロセスにまったく関係しません。

接続へのクライアント識別子の設定

データ・ソースでこの機能を有効化すると、クライアント・プロパティが接続に関連付けられます。基礎となるSQLユーザーは、接続の存続中、未変更のままですが、クライアント値は変更できます。この情報は、アカウント、監査またはデバッグに使用できます。クライアント・プロパティは、先に説明した「データベース資格証明の使用」の設定に基づき、資格証明マップに基づきデータベース・ユーザーにマップされたWebLogicユーザーに基づくか、getConnection()メソッドのデータベース・ユーザー・パラメータに直接基づきます。

この機能を有効化するには、管理コンソールで「接続時にクライアントIDを設定」を選択します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの接続へのクライアントIDの設定の有効化に関する項を参照してください。

クライアント識別子の設定機能は、次のインタフェースに基づき、Oracle ThinドライバおよびIBM DB2ドライバを使用した場合にのみ利用できます。

Oracle 12cよりも前では、oracle.jdbc.OracleConnection.setClientIdentifier(client)が使用されます。監査およびデバッグにこれを使用する方法の詳細は、『Oracle Databaseセキュリティ・ガイド』の「CLIENT_IDENTIFIER属性を使用したユーザー識別情報の保持」を参照してください。getClientIdentifier()を使用してドライバから値を取得できます。SQL問合せの一部としてデータベースから値を取得するには、次のような文を使用します。
```
select sys_context('USERENV','CLIENT_IDENTIFIER') from DUAL
```
Oracle 12c以降では、java.sql.Connection.setClientInfo(”OCSID.CLIENTID", client)が使用されます。プロパティ値は独自ですが、これはJDBC標準APIです。setClientIdentifierの使用に関する問題は、この値を設定し、依存するOracleテクノロジ・スタックがあることです。アプリケーション・コードでもこの値を設定すると、問題が発生する場合があります。これは、setClientInfoメソッドを権限が付与された操作で使用することで解決します。適切に管理されたコンテナで、Javaセキュリティ・ポリシー付与を特定のネームスペースおよびコード・ベースに制限すること、および制御不能のユーザー・コードからコンテナを保護することができます。Javaセキュリティ・マネージャでの実行時に、次についてJavaセキュリティ・ポリシー・ファイルでパーミッションを付与する必要があります。
```
permission "oracle.jdbc.OracleSQLPermission" "clientInfo.OCSID.CLIENTID";
```
OCSID.CLIENTIDという名前を使用すると、値を取得するために、上位互換性のあるselect sys_context('USERENV','CLIENT_IDENTIFIER') from DUALの使用、またはJDBC標準APIのjava.sql.getClientInfo(”OCSID.CLIENTID")の使用が可能になります。
Oracle USERENVコンテキストでのこの値の設定を使用して、Oracle Virtual Private Database (VPD)機能を実行できます。これにより、行および列レベルでデータベース・アクセスを制御するセキュリティ・ポリシーを作成できます。基本的には、Oracle Virtual Private Databaseのセキュリティ・ポリシーが適用された表、ビューまたはシノニムに対して発行されるSQL文に、動的なWHERE句が追加されます。『Oracle Databaseセキュリティ・ガイド』のOracle Virtual Private Databaseを使用したデータ・アクセスの制御に関する項を参照してください。このデータ・ソース機能を使用すると、このコンテキストを設定するために、WebLogic側ではプログラミングは必要ありません。このコンテキストは、WebLogicデータ・ソース・コードにより設定およびクリアされます。
IBM DB2ドライバでは、古いリリース(バージョン9.5よりも前)についてはcom.ibm.db2.jcc.DB2Connection.setDB2ClientUser(client)が使用されます。これにより、接続に対し現在のクライアント・ユーザー名が指定されます。現在のクライアント・ユーザー名は接続中に変更できるので注意してください(ユーザーとは異なります)。この値は、CURRENT CLIENT_USERID特殊レジスタでも使用可能です。select CURRENT CLIENT_USERID from SYSIBM.SYSTABLESなどの文を使用して、これを選択できます。
JDBC 4.0でIBM DB2ドライバ(バージョン9.5以降)を実行する場合、java.sql.Connection.setClientInfo(”ClientUser”, client)が使用されます。DB2独自のAPIのかわりに、java.sql.Connection.getClientInfo(”ClientUser”)を使用して値を取得できます(setDB2ClientUser()を使用する場合でも)。

Oracleプロキシ・セッション

Oracleプロキシ認証により、1つのJDBC接続が、Thinドライバを使用するOracleデータベースへの複数の(シリアル)軽量ユーザー接続のプロキシとして機能できます。クライアントがプロキシ・ユーザーとしてアプリケーション・サーバーを通じてデータベースに接続できるようにWebLogicデータ・ソースを構成できます。クライアントはアプリケーション・サーバーで認証され、アプリケーション・サーバーはOracleデータベースで認証されます。これにより、クライアントのユーザー名を、データベースとの接続で保持できます。

注意:

この機能は、Oracle ThinドライバおよびサポートされるOracleデータベースを使用した場合にのみサポートされます(データベースurlにoracleを含める必要があります)。

Oracleデータベースへの接続でプロキシ認証を構成するには、次の手順を使用します。

必要なデータベース・ユーザーを作成していない場合は作成します。
Oracleデータベースで、CONNECT THROUGH権限を用意します。次に例を示します。
```
SQL> ALTER USER connectionuser GRANT CONNECT THROUGH dbuser;
```
ここで、connectionuserは認証を受けるアプリケーション・ユーザーの名前で、dbuserはOracleデータベース・ユーザーです。
汎用またはActive GridLinkデータ・ソースを作成し、ユーザーをdbuserの値に設定します。
次を行います。
- WebLogic資格証明を使用するには、前の説明に従い、wlsuserの値をdbuserの値にマップする資格証明マップにエントリを作成します。
- データベース資格証明を使用するには、前の説明に従い、「データベース資格証明の使用」を有効化します。
Oracleプロキシ認証を有効化します。Oracle WebLogic Server管理コンソール・ヘルプの「Oracleパラメータの構成」を参照してください。
wlsuserまたはdbuserの値を使用して、WebLogic Serverインスタンスにログオンします。
getConnection(username, password)を使用して接続を取得します。資格証明は、「データベース資格証明の使用」の設定に基づき、データベース・ユーザーにマップされたWebLogicユーザーに基づくか、データベース・ユーザーに直接基づきます。

次を実行することで、現在のユーザーおよびプロキシ・ユーザーを確認できます。

select user, sys_context('USERENV','PROXY_USER') from DUAL

注意:

「データベース資格証明の使用」が有効化されておらず、WebLogicユーザーのユーザー/パスワードの値が有効ではない場合、getConnectionは失敗します。反対に、「データベース資格証明の使用」が有効化されていて、データベース・ユーザーのユーザー/パスワードの値が有効ではない場合も失敗します。

プールに対し接続リクエストが実行されるたびに、ユーザーに基づき接続でプロキシ・セッションがオープンします。接続がプールに戻されると、プロキシ・セッションはクローズされます。プロキシ・セッションのオープンまたはクローズは、JDBCオブジェクトに次の影響を与えます。

元の接続からの既存の文(結果セットを含む)がクローズされます。
WebLogic Server文キャッシュがクリアされます。
クライアント識別子が設定されている場合はクリアされます。
すべてのプロキシ・セッションに対し、接続用のWebLogic Serverテスト文が再作成されます。

これらの動作は、インスタンス間で接続を共有するアプリケーションに影響を与える場合があり、接続に関連する一部の状態が予期されます。

use-database-credentialsが有効化され、getConnection(user, password)がコールされると、Oracleプロキシ・セッションも暗黙的に有効化されます。

oracle-proxy-sessionの正確な定義は次のようになります。

プロキシ認証が有効化され、IDベースのプールも有効化されると、エラーが発生します。
getConnection()でユーザーが指定され、identity-based-connection-pooling-enabledがfalseの場合、oracle-proxy-sessionは暗黙的にtrueとして扱われます(明示的にtrueにすることもできます)。
getConnection()でユーザーが指定され、identity-based-connection-pooling-enabledがtrueの場合、oracle-proxy-sessionはfalseとして扱われます。

IDベースの接続プール

IDベースのプールでは、接続の異種プールが作成されます。これにより、アプリケーションは、各種DBMS資格証明を持つ物理接続をプールすることで、特定のDBMS資格証明でJDBC接続を使用できます。DBMS資格証明は、use-database-credentialsに基づき、データベース・ユーザーにマップされたWebLogicユーザーに基づくか、データベース・ユーザーに直接基づきます。use-database-credentials=trueにより、一部の実装で、getConnection(user,password)で指定されたユーザーにおいて、JDBC標準に基づく異種プールを解釈する方法が決まります。

データ・ソースで「IDベースの接続プールを有効化」属性が有効化されている場合、接続の割当てはさらに複雑になります。アプリケーションがデータベース接続をリクエストすると、WebLogic Serverインスタンスは既存の物理接続を選択するか、リクエストしたDBMSアイデンティティとの新規物理接続を作成します。

次の項で、異種接続の作成方法について説明します。

接続プールの初期化時に、データ・ソースの構成済デフォルトDBMS資格証明を使用して、構成済またはデフォルトの初期容量に基づく物理JDBC接続が作成されます。
アプリケーションがデータ・ソースから接続を取得しようとします。
次が行われます。
- use-database-credentialsが有効化されていない場合、先に説明したように、getConnectionで指定されているユーザーがDBMS資格証明にマップされます。資格証明マップに一致するユーザーがない場合、データ・ソース・ディスクリプタからデフォルトのDBMS資格証明が使用されます。
- use-database-credentialsが有効化されている場合、getConnectionで指定されているユーザーおよびパスワードが直接使用されます。
接続プールが検索され、一致するDBMS資格証明を持つ接続が検出されます。
一致が見つかった場合、接続が予約され、アプリケーションに返されます。
一致が見つからない場合、プールの最大容量に基づき、接続が作成されるか、再使用されます。
- 最大容量に到達していない場合、DBMS資格証明を使用して新しい接続が作成され、予約され、アプリケーションに返されます。
- プールが最大容量に到達している場合、最低使用頻度(LRU)アルゴリズムに基づき、プールから物理接続が選択され、破棄されます。DBMS資格証明を使用して新しい接続が作成され、予約され、アプリケーションに返されます。

一致する接続の検出に、同種プールよりもコストがかかることは明白です。接続の破棄と新しい接続の取得には、非常にコストがかかります。可能な場合は、通常の同種プールまたはいずれかの軽量オプション(クライアントIDまたはOracleプロキシ接続)を使用してください。これらは、IDベースのプールよりも効率的であるためです。

物理接続の作成方法に関係なく、プール内の各物理接続には、プールにより保持されている専用のDBMS資格証明情報があります。プールにより物理接続が予約された後では、現在のスレッドによりそのWebLogicユーザー資格証明が変更され、同じ接続を継続して使用する場合でも、そのDBMS資格証明は変更されません。

この機能を構成するには、「IDベースの接続プールを有効化」を選択します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソースのIDベースの接続プールの有効化」を参照してください。

関連するトランザクション表に複数のユーザーがアクセスする問題に対処するために、次の変更を行って、IDベースのプールでロギング・ラスト・リソース(LLR)トランザクションの最適化を使用する必要があります。

完全修飾したLLR表名を使用して、LLRのカスタム・スキーマを構成する必要があります。これにより、LLRトランザクション表へのアクセス時に、すべてのLLR接続で、デフォルトのスキーマではなく、名前を付けたスキーマが使用されます。
データベース固有の管理ツールを使用して、名前を付けたLLR表にアクセスするためのパーミッションを、グローバル・トランザクションを通じてこの表にアクセスできるようにするすべてのユーザーに付与します。デフォルトでは、LLR表は、データ・ソース内の接続に対し構成されているユーザーにより、ブート中に作成されます。ほとんどの場合、データベースにより、このユーザーへのアクセスのみ許可され、マップされたユーザーへのアクセスは許可されません。

トランザクション内の接続

特定のWebLogic Serverインスタンスのトランザクション・コンテキストに関連付けられている接続は、次のように動作します。

グローバル・トランザクションで非XA LLRまたは1PC (JTSドライバ)が構成されたデータ・ソースとの接続を取得すると、指定されたユーザー名/パスワードの値に関係なく、および関連するプロキシ・ユーザー・セッション(ある場合)から独立して、トランザクション内で取得された最初の接続が、後続の接続リクエストで返されます。LLRまたは1PCを使用する場合、接続を接続のすべてのユーザー間で共有する必要があります。
XAデータ・ソースでは、指定されたユーザー名/パスワードの値に関係なく、および関連するプロキシ・ユーザー・セッション(ある場合)から独立して、グローバル・トランザクション内で取得された最初の接続が、アプリケーション・サーバー内の後続の接続リクエストで返されます。アプリケーション・サーバー/JVM内のグローバル・トランザクション内において、接続を接続のすべてのユーザー間で共有する必要があります。

要約すると、トランザクション内で接続を取得すると、その接続は、特定のWebLogic Serverインスタンスのトランザクション・コンテキストに関連付けられます。

WebLogicデータ・ソース・リソースのパーミッション

オプションで、JDBCデータ・ソースへのアクセスを制限できます。WebLogic Serverでは、WebLogicデータ・ソース・リソースへのアクセス権を誰が持っていますか、という質問に対して、セキュリティ・ポリシーが解答を出します。WebLogicデータ・ソース・リソースとユーザー、グループまたはロール間の関係を定義すると、セキュリティ・ポリシーが作成されます。セキュリティ・ポリシーにWebLogicデータ・ソース・リソースを割り当てるまで、このリソースは保護されません。パーミッションのポリシーを1つ追加すると、他のすべてのユーザーがただちに制限を受けます。たとえば、weblogicが接続を予約できるというポリシーを追加すると、他のすべてのユーザーは、明示的に追加されるまで、接続を予約しようとしても失敗します。検証は、データベース・ユーザー資格証明ではなく、WebLogicユーザー資格証明に対して実行されます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「リソース・インスタンスのポリシーの作成」を参照してください。

管理者がJDBCデータ・ソースに対して実行できるアクションを制限できる管理者用メソッドを割り当てることで、JDBCリソース操作を保護できます。これらのリソースは、データ・ソースに関連する「セキュリティ」タブの「ポリシー」タブで定義できます。個々のデータ・ソースを保護する場合、次の1つ以上の管理者メソッドを使用して、JDBC操作を保護するかどうか選択できます。

admin: JDBCDataSourceRuntimeMBeanの次のメソッドは、admin操作として呼び出されます: clearStatementCache、suspend、forceSuspend、resume、shutdown、forceShutdown、start、getPropertiesおよびpoolExists。
reserve: アプリケーションは、データ・ソースをルックアップし、getConnectionをコールすることで、データ・ソース内の接続を予約します。ユーザーにreserveパーミッションを付与すると、ユーザーはベンダー固有の操作を実行できます。データベース・ベンダーによっては、これらの一部の操作でデータベースのセキュリティが影響を受ける場合があります。「WebLogicデータ・ソース・セキュリティのオプション」を参照してください。

shrink: データ・ソース内の接続の数を、現在予約されている接続の最大数、または初期サイズまで削減します。
reset: すべての物理データベース接続をシャットダウンして再確立することで、データ・ソース接続をリセットします。これにより、各接続の文キャッシュもクリアされます。正常に実行されているデータ・ソース接続のみリセットできます。

All: 個々のデータ・ソースが、Admin、reserve、shrinkおよびreset管理者メソッドの組合せにより保護されます。

注意:

次のことに注意してください。

セキュリティ・ポリシーにより、マルチ・データ・ソース内の接続へのアクセスが制御される場合、JDBCリソース階層の両方のレベル(マルチ・データ・ソース・レベルおよび個々のデータ・ソース・レベル)でアクセス・チェックが実行されます。すべてのタイプのWebLogicリソースに関して、この2重チェックにより、ほとんどの特定セキュリティ・ポリシーでアクセスが確実に制御されます。

『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のJava DataBase Connectivity (JDBC)リソースに関する項を参照してください。

次の表では、reserve管理者メソッド使用時のパーミッション・チェック対象のユーザーについて情報を提供します。

表10-2 reserve管理者メソッド使用時のユーザーの決定

API	Use-database-credential	パーミッション・チェック対象のユーザー
`getConnection()`	`True`または`False`	現在のWebLogicユーザー
`getConnection(`user`,`password`)`	`False`	APIからのユーザー/パスワード
`getConnection(`user`,`password`)`	`True`	現在のWebLogicユーザー

要約すると、getConnection()が使用される場合、またはデータベース資格証明が有効化されている場合、WebLogicシステムに対して認証される現在のユーザーがチェックされます。データベース資格証明が有効化されていない場合、APIのユーザーおよびパスワードが使用されます。この機能は、データベースにアクセスできるコードおよびユーザーを制限する場合に非常に便利です。

すべてのWebLogic Serverリソースに対してセキュリティを設定する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのロールおよびポリシーを使用したリソースの保護に関する項を参照してください。サーバー・リソースの保護の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』に関する項を参照してください。

データ・ソース・セキュリティの例

次は、identity-based-connection-pooling-enabled、oracle-proxy-sessionおよびuse-database-credentialsの間の相互作用の実例です。

データベース側で、次のオブジェクトを構成します。

ユーザー: scott、jdbcqa、jdbcqa3
alter user jdbcqa3 grant connect through jdbcqa;
alter user jdbcqa grant connect through jdbcqa;

次のWebLogicユーザーを構成します。

weblogic
wluser

次のWebLogicデータ・ソース・オブジェクトを構成します。

weblogicからscottへの資格証明マッピング
wluserからjdbcqa3への資格証明マッピング
ユーザーjdbcqaが構成されたデータ・ソース
クライアントIDの設定をtrueに設定してすべてのテストを実行します。
oracle-proxy-sessionをfalseに設定してすべてのテストを実行します。

テスト・プログラム:

サーブレットで実行
ユーザーweblogicとしてWebLogicに対して認証

表10-3 ID、プロキシおよびデータベース資格証明の比較

DB資格証明の使用	IDベース	getConnection (scott,***)	getConnection (weblogic,***)	getConnection (jdbcqa3,***)	getConnection()
`true`	`true`	ID `scott` クライアント`weblogic` プロキシ`null`	`weblogic`は失敗: dbユーザーではない	ユーザー`jdbcqa3` クライアント`weblogic` プロキシ`null`	デフォルト`jdbcqa` クライアント`weblogic` プロキシ`null`
`false`	`true`	`scott`は失敗: WebLogicユーザーではない	ユーザー`scott` クライアント`scott` プロキシ`null`	`jdbcqa3`は失敗: WebLogicユーザーではない	ユーザー`scott` クライアント`scott` プロキシ`null`
`true`	`false`	`scott`のプロキシは失敗	`weblogic`は失敗: dbユーザーではない	ユーザー`jdbcqa3` クライアント`weblogic` プロキシ`jdbcqa`	デフォルト`jdbcqa` クライアント`weblogic` プロキシ`null`
`false`	`false`	`scott`は失敗: WebLogicユーザーではない	ユーザー`jdbcqa` クライアント`scott` プロキシ`null`	`jdbcqa3`は失敗: WebLogicユーザーではない	デフォルト`jdbcqa` クライアント`scott` プロキシ`null`

次が行われます。

クライアントIDの設定がfalseに設定されている場合、すべてのケースでクライアントはnullに設定されます。
Oracle Thinドライバが使用されない場合、非nullプロキシを使用する1つのケースでは、例外がスローされます。これは、Oracle Thinドライバでのみプロキシ・セッションがサポートされるためです。

oracle-proxy-sessionがtrueに設定されている場合、成功するケースは次のみです(jdbcqaのプロキシを使用)。

use-database-credentialsがtrueに設定されていて、getConnection(jdbcqa3,…)またはgetConnection()を使用する場合。
use-database-credentialsがfalseに設定されていて、getConnection(wluser, …)またはgetConnection()を使用する場合。

データ・ソースおよびOracleドライバでのSSLの使用

この項では、データ・ソースおよびOracleドライバでSSLを使用する各種オプションの追加情報について説明します。

SSL使用時の一般要件は、オプションに関係なく、urlでプロトコルとしてtcpsを指定する必要があることです。

OracleドライバでのSSLの構成方法および使用方法の詳細は、次を参照してください。

OracleウォレットでのSSLの使用

SSLでOracleウォレットを使用することもできます。これを正しく使用することで、クリア・テキスト・パスワードをJDBC構成から排除でき、ウォレットを構成することでクライアント/サーバー構成を簡素化できます。次は、OracleウォレットでSSLを使用するための基本要件のリストです。

ウォレットの場所についてsqlnet.oraおよびlistener.oraファイルを更新します。これらのファイルは、SSL_CLIENT_AUTHENTICATIONが使用されるかどうかも示します。
自動ログイン・ウォレット・タイプを使用することをお薦めします。これは、ウォレットを開くデータ・ソース構成で、クリア・テキスト・パスワードが必要ないためです。自動ログイン・ウォレットのストア・タイプはSSO (JKSまたはPKCS12ではない)で、ファイル名はcwallet.ssoです。
Oracle PKIプロバイダを有効化する必要があります。これは、JRE下のjava.securityファイルを更新することで、または次を使用してWLS起動クラスで設定を行うことで、静的に実行できます。
```
Security.insertProviderAt(new oracle.security.pki.OraclePKIProvider (), 3);
```
暗号化およびサーバー認証のために、次のデータ・ソース接続プロパティを使用します。
```
javax.net.ssl.trustStore=location of wallet 
javax.net.ssl.trustStoreType=”SSO”
```
クライアント認証のために、次のデータ・ソース接続プロパティを使用します。
```
javax.net.ssl.keyStore=location of wallet
javax.net.ssl.keyStoreType=”SSO”
```
ウォレットはorapkiを使用して作成します。ウォレットは、使用方法(暗号化または認証)に基づいて作成する必要があります。

一般的な使用例を次に示します。

信頼ストアを必要とする、暗号化およびサーバー認証。
信頼ストアおよび鍵ストアを必要とする、両方の層(クライアントおよびサーバー)の暗号化および認証。

Active GridLink ONS over SSL

SSLを使用して、Active GridLink (AGL)データ・ソースとOracle Notification Service (ONS)の間の通信を保護できます。ONSは、ロード・バランシング情報およびノードのアップ/ダウン・イベントの通知を提供するために使用されます。

次の基本手順を使用します。

自動ログイン・ウォレットを作成し、クライアントおよびサーバーでウォレットを使用します。次は、ONSで使用するテスト・ウォレットを作成するためのサンプル・シーケンスです。
```
orapki wallet create -wallet ons -auto_login -pwd ONS_Wallet
orapki wallet export -wallet ons -dn "CN=ons_test,C=US" -cert ons/cert.txt -pwd ONS_Wallet
orapki wallet export -wallet ons -dn "CN=ons_test,C=US" -cert ons/cert.txt -pwd ONS_Wallet
```
データベース・サーバー側:
1. ファイル$CRS_HOME/opmn/conf/ons.configでウォレット・ファイル・ディレクトリを定義します。
2. onsctl stop/startを実行します。
AGLデータ・ソースを構成する場合、ONSへの接続を定義する必要があります。ホストおよびポートに加えて、ウォレット・ファイル・ディレクトリを指定する必要があります。パスワードを指定しない場合、SSOウォレットと見なされます。