| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1.3.0) E90329-05 |
|
 前 |
 次 |
この章の内容は次のとおりです。
デフォルトでは、データ・ソースに対し単一のデータベース・ユーザーおよびパスワードを定義します。それは、データ・ソース記述子に格納するか、ウォレットを使用できます。
ウォレットの使用方法については、「Oracleウォレットの作成および管理」を参照してください)。これは、非常に簡単で効率的なセキュリティへのアプローチです。接続プール内のすべての接続をこのユーザーが所有し、接続が不足しても特別な処理は行われません。つまり、この接続プールは同種接続プールであり、リクエストによりセキュリティの観点から接続を取得できます(アフィニティなど、その他の観点もあります)。アプリケーションのエンド・ユーザーに関係なく、プール内のすべての接続では、DBMSにアクセスするために同じセキュリティ資格証明が使用されます。接続を取得するとき、情報はすべてデータソース・ディスクリプタまたはウォレットから入手できるため追加情報は不要です。たとえば:
java.sql.Connection conn = mydatasource.getConnection();
ノート:
「プロパティ」フィールドに、名前と値のペアとしてパスワードを入力すること(これは、本番環境では許可されません)、または「パスワード」フィールドにこれを入力することができます。物理データベース接続作成時にJDBCドライバに渡される「プロパティ」で定義されているパスワード値は、「パスワード」フィールドの値によりオーバーライドされます。
プロパティ文字列のパスワード・プロパティのかわりにPassword属性を使用することをお薦めします。Password値は構成ファイルで暗号化され(モジュール・ファイル内のjdbc-driver-paramsタグでパスワードで暗号化された属性として格納されます)、WebLogic Server管理コンソールで表示されないためです。「プロパティ」および「パスワード」フィールドは、管理コンソールのデータ・ソース作成ウィザードやデータ・ソース構成ページにあります。また、JDBCDriverParamsBean.Password属性は現在は動的になっており、データ・ソースの再起動は必要ありません。 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 JDBCデータ・ソースで使用できるセキュリティ・オプションについて学習します。
表15-1 セキュリティ資格証明のためのWebLogicデータ・ソース構成オプション
| 機能 | 説明 | 次で使用可能 | 次では使用不可 |
|---|---|---|---|
ユーザー認証 (デフォルト) |
デフォルトの |
プロキシ・セッション、クライアント識別子の設定 |
IDプール、データベース資格証明の使用 |
データベース資格証明の使用 |
資格証明マッピングを使用するかわりに、指定されたユーザーおよびパスワードを直接使用します。 |
クライアント識別子の設定、プロキシ・セッション、IDプール |
ユーザー認証 |
クライアント識別子の設定 |
接続に関連するクライアント識別子プロパティの設定(OracleおよびDB2のみ)。 |
すべて |
N/A |
プロキシ・セッション |
接続に関連する軽量プロキシ・ユーザーの設定(Oracleのみ)。 |
ユーザー認証、クライアント識別子の設定、データベース資格証明の使用 |
IDプール |
IDプール |
指定ユーザーが所有する接続の異種プール |
クライアント識別子の設定、データベース資格証明の使用 |
プロキシ・セッション、ユーザー認証、ラベリング、Active GridLink |
ノート:
これらの機能はすべて、XAドライバと非XAドライバの両方で使用できます。これらの機能はすべて、WebLogic Server管理コンソールのデータ・ソース構成タブの「ID」タブで構成できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 構成: IDオプションを参照してください。
ノート:
WebLogic Serverリリース12.1.2よりも前では、プロキシ・セッションおよび「データベース資格証明の使用」オプションは、「Oracle」タブにのみ存在しました。次の項でこれらの機能について詳しく説明します。
各WebLogicデータ・ソースには、資格証明マップがあります。これは、WebLogicユーザーの場合は、セキュリティ資格証明(ユーザーおよびパスワード)にキーをマップするために使用されるメカニズムです。デフォルトでは、接続取得時にユーザーおよびパスワードが指定されると、それらはWebLogicユーザーの資格証明として扱われ、検証され、データ・ソースに関連付けられている資格証明マップを使用してデータベース・ユーザーおよびパスワードに変換されます。データ・ソースの資格証明マップで一致するエントリが見つからない場合、データ・ソース定義に関連付けられているユーザーおよびパスワードが使用されます。このデフォルト設定メカニズムのために、どのパーミッションをデフォルト・ユーザーに付与するか注意する必要があります。または、無効なデフォルト・ユーザーを定義して、どのユーザーにも誤って許可が付与されないようにすることもできます(この場合、プールの初期容量をゼロに設定して、プールに有効なユーザーのみが追加されるようにする必要があります)。
資格証明マップにエントリを作成するには:
WebLogicユーザーを作成します。WebLogic Server管理コンソールで、「セキュリティ・レルム」に移動し、レルムを選択し(たとえば、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()メソッドのデータベース・ユーザー・パラメータに直接基づきます。
この機能を有効化するには、WebLogic Server管理コンソールで「接続時にクライアントIDを設定」を選択します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの接続へのクライアントIDの設定の有効化を参照してください。
クライアント識別子の設定機能は、次のインタフェースに基づき、Oracle ThinドライバおよびIBM DB2ドライバを使用した場合にのみ利用できます。
Oracle 12cよりも前では、oracle.jdbc.driver.OracleConnection.setClientIdentifier(client)が使用されます。監査およびデバッグにこれを使用する方法の詳細は、Oracle Databaseセキュリティ・ガイドのCLIENT_IDENTIFIER属性を使用したユーザー識別情報の保持を参照してください。ojdbcN.jarファイルまたはojdbcN_g.jarファイルを使用し、ドライバからgetClientIdentifier()を使用して値を取得できます。
ノート:
Oracle Fusion MiddleWareおよびOracle Fusion ApplicationsのデフォルトJARファイルであるojdbcNdms.jarを使用している場合、Oracleドライバを使用したクライアント識別子の設定は無効になります。この場合、クライアント識別子の設定機能はサポートされません。
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プロキシ認証により、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ベースのプールでは、接続の異種プールが作成されます。これにより、アプリケーションは、各種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データ・ソース・リソースを割り当てるまで、このリソースは保護されません。パーミッションのポリシーを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管理者メソッド使用時のパーミッション・チェック対象のユーザーについて情報を提供します。
表15-2 reserve管理者メソッド使用時のユーザーの決定
| API | Use-database-credential | パーミッション・チェック対象のユーザー |
|---|---|---|
|
|
現在のWebLogicユーザー |
|
|
APIからのユーザー/パスワード |
|
|
現在のWebLogicユーザー |
要約すると、getConnection()が使用される場合、またはデータベース資格証明が有効化されている場合、WebLogicシステムに対して認証される現在のユーザーがチェックされます。データベース資格証明が有効化されていない場合、APIのユーザーおよびパスワードが使用されます。この機能は、データベースにアクセスできるコードおよびユーザーを制限する場合に非常に便利です。
すべてのWebLogic Serverリソースに対してセキュリティを設定する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのロールおよびポリシーを使用したリソースの保護を参照してください。サーバー・リソースの保護の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
データ・ソースのセキュリティの例を使用して、ID、プロキシおよびデータベースの資格証明の相互作用と相違点について学習します。
次は、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に対して認証
表15-3 ID、プロキシおよびデータベース資格証明の比較
| DB資格証明の使用 | IDベース | getConnection (scott,***) | getConnection (weblogic,***) | getConnection (jdbcqa3,***) | getConnection() |
|---|---|---|---|---|---|
|
|
ID クライアント プロキシ |
|
ユーザー クライアント プロキシ |
デフォルト クライアント プロキシ |
|
|
|
ユーザー クライアント プロキシ |
|
ユーザー クライアント プロキシ |
|
|
|
|
ユーザー クライアント プロキシ |
デフォルト クライアント プロキシ |
|
|
|
ユーザー クライアント プロキシ |
|
デフォルト クライアント プロキシ |
次が行われます。
クライアント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()を使用する場合。
Encrypted Properties属性を使用して追加できます。 Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続プロパティの暗号化を参照してください。
ノート:
WebLogic Server管理コンソールでデータ・ソースを作成するとき、接続プロパティは暗号化できません。暗号化できるのは、既存のデータ・ソース構成を更新する場合のみです。
次の項では、WebLogic Server管理コンソールで接続プロパティを暗号化するときのベスト・プラクティスとヒントについて説明します。
データ・ソースの作成時:
暗号化されたプロパティなしで作成し、データ・ソースをターゲットに指定しないでください。
暗号化されたプロパティなしでは接続をテストできない可能性があります。一時的にクリア・テキスト・プロパティでテストして、後でそのクリア・テキスト・プロパティを暗号化されたプロパティに置き換えることをお薦めします。
「JDBCデータ・ソースのサマリー」ページに移動してデータ・ソースを編集し、「データ・ソース」を選択して、「構成」タブに移動し、「接続プール」タブを選択します。
クリア・テキスト値を画面に表示せずに値を入力するには:
このページに対する他のすべての変更を保存して、「暗号化されたプロパティ」テキスト・ボックスの横の安全に追加ボタンをクリックします。
暗号化されたプロパティの新規追加ページで、プロパティ名とマスクされた値を入力して、「OK」をクリックします。
その他の暗号化されたプロパティ値に対して手順を繰り返します。
暗号化されたプロパティの入力が終了したら、「保存」をクリックします。
ご使用の環境で変更を保存するまで暗号化された値を画面に表示することが適している場合は、複数の値を一度に入力できます。
「暗号化されたプロパティ」フィールドに、各property=valueのペアを別の行にしてリストします。
「保存」をクリックして値を暗号化します。
次のように変更をアクティブ化します。
データ・ソースがターゲット指定されていない場合: 「ターゲット」タブに移動して、データ・ソースをターゲット指定し、「保存」をクリックします。
暗号化されたプロパティ値が追加されたときに、データ・ソースがすでにアクティブ化されていた場合: 「ターゲット」タブに移動し、データ・ソースのターゲット指定を解除して「保存」をクリックし、データ・ソースを再度ターゲット指定して、「保存」をクリックします。
次の各項では、接続プロパティを暗号化するWLSTスクリプトの例を示します。
次のオンラインWLSTスクリプトは、genericdsという名前の既存のデータ・ソースに暗号化されたプロパティを追加する方法を示しています。
connect('admin','password','t3://localhost:7001')
edit()
startEdit()
cd('JDBCSystemResources/genericds/JDBCResource/genericds/JDBCDriverParams/genericds/Properties/genericds/Properties')
create('encryptedprop','Property')
cd('encryptedprop')
cmo. setEncryptedValueEncrypted(encrypt('foo'))
save()
activate()
次のWLSTスクリプトでは、暗号化されたプロパティを作成しています。
. . .
create('myProps','Properties')
cd('Properties/NO_NAME_0')
. . .
# Create other properties
. . .
p=create('javax.net.ssl.trustStoreType', 'Property')
p.setValue('JKS')
p=create('javax.net.ssl.trustStorePassword', 'Property')
p.setEncryptedValueEncrypted(encrypt('securityCommonTrustKeyStorePassPhrase'))
. . .
SSLを使用して、データベースの暗号化および強力な認証の両方をデータベース・サーバーへのネットワーク接続に提供します。
次の各項では、WebLogic Serverでこれらの機能を使用する方法の詳細を説明します。
『Oracle® Database JDBC開発者ガイド』のJDBCクライアント側のセキュリティ機能に関する項を参照してください。
この項では、データ・ソースおよびOracleドライバでSSLを使用する各種オプションの追加情報について説明します。
SSL使用時の一般要件は、オプションに関係なく、urlでプロトコルとしてtcpsを指定する必要があることです。
OracleドライバでのSSLの構成方法および使用方法の詳細は、次を参照してください。
http://www.oracle.com/technetwork/middleware/weblogic/index-087556.html
http://www.oracle.com/technetwork/database/enterprise-edition/wp-oracle-jdbc-thin-ssl-130128.pdf.
javax.net.ssl.trustStorePassword、javax.net.ssl.keyStorePasswordなどのパスワードを必要とするプロバイダを使用している場合は、この値を暗号化されたプロパティとして保存する必要があります。「暗号化された接続プロパティの使用」を参照してください
SSLでOracleウォレットを使用することもできます。これを正しく使用することで、パスワードをJDBC構成から排除でき、ウォレットを構成することでクライアント/サーバー構成を簡素化できます。次は、OracleウォレットでSSLを使用するための基本要件のリストです。
ウォレットの場所についてsqlnet.oraおよびlistener.oraファイルを更新します。これらのファイルは、SSL_CLIENT_AUTHENTICATIONが使用されるかどうかも示します。
自動ログイン・ウォレット・タイプを使用する場合、ウォレットを開くためのデータ・ソース構成にパスワードは必要ありません。自動ログイン・ウォレットのストア・タイプはSSO (JKSまたはPKCS12ではない)で、ファイル名はcwallet.ssoです。別のプロバイダ・タイプを使用する場合は、暗号化されたプロパティ・タイプを使用して、パスワードを暗号化された値としてデータ・ソース構成に保存します。
次を使用して、WLS起動クラスでOracle PKIプロバイダを有効化します。
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を使用して作成します。ウォレットは、使用方法(暗号化または認証)に基づいて作成する必要があります。
一般的な使用例を次に示します。
信頼ストアを必要とする、暗号化およびサーバー認証。
信頼ストアおよびキー・ストアを必要とする、両方の層(クライアントおよびサーバー)の暗号化および認証。
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
データベース・サーバー側:
ファイル$CRS_HOME/opmn/conf/ons.configでウォレット・ファイル・ディレクトリを定義します。
onsctl stop/startを実行します。
AGLデータ・ソースを構成する場合、ONSへの接続を定義する必要があります。ホストおよびポートに加えて、ウォレット・ファイル・ディレクトリを指定する必要があります。パスワードを指定しない場合、SSOウォレットと見なされます。
Oracle Thinドライバでデータ暗号化を使用するには、複数の接続プロパティを指定する必要があります。Oracle® Database Advanced Security管理者ガイドの構成パラメータを参照してください。次の表は、暗号化およびチェックサムの構成パラメータと、管理コンソールまたはWLSTを使用してデータ・ソース・ディスクリプタを構成するときに必要とされる文字定数とのマッピングを示しています。
表15-4 接続の暗号化パラメータとWebLogic構成の定数
| クライアント構成パラメータ | WebLogic Server構成の文字定数 |
|---|---|
|
|
|
|
|
|
|
|
