[WLS] Data Source Security Part 5

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/data_source_security_part_5

---

これまでの4エントリを読んでらっしゃるのであれば、この分野のエキスパートになってるはずですが、このエントリでWebLogicリソースの権限に関するトピックについて触れたいと思います。構成パラメーターを使って、具体的な値でどのような結果になるかを例示します。

WebLogicリソースの権限

これまでの議論はすべて、（最終的に）データベース側で使用されているデータベースの資格証明に関するものでした。WebLogic Serverには、どのWebLogic ServerユーザにJDBCリソースへのアクセスが許可されているかを制御するためのリソースの資格証明があります。これらは、データソースに関連付けられており、［セキュリティ］>［ポリシー］から定義できます。 "reserve（新しい接続を取得）"、 "admin（管理）"、 "shrink"、"reset"、（さらに全てを含む"ALL"）という、4つのアクセス権がありますが、接続の取得に関する話題であるため、今回は"reserve"に注目します。デフォルトでは、JDBCリソースの権限は完全にオープンで、誰でも何でもできる状態にあります。許可のポリシーを追加すると即座に他の全てのユーザーが制限されます。例えば、"weblogic"が接続を予約できるようにポリシーを追加すると、明示的にポリシーを追加しなければ、他の全てのユーザーは接続の予約に失敗します。検証はWebLogic Serverのユーザーの資格情報のみで実施します（データベースのユーザーの資格情報ではありません）。一般にリソースの構成は、以下のリンクに記載されています。

Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help 12c Release 1 (12.1.1)
Create policies for resource instances
http://docs.oracle.com/cd/E24329_01/apirefs.1211/e24401/taskhelp/security/CreatePoliciesForResourceInstances.html

この機能は非常に有用で、コードやユーザーがデータベースに接続することを制限することができます。

API	データベースの資格証明を使用	権限チェックのためのユーザー
getConnection()	True もしくは false	現在のWLSユーザ
getConnection(user,password)	False	APIからのUser/Password
getConnection(user,password)	True	現在のWLSユーザ

シンプルなgetConnection()を使うか、データベース資格証明を有効にしている場合、WebLogic Serverシステムに対して認証される現在のユーザをチェックします。データベース資格証明を有効にしていない場合、ユーザとパスワードはAPIから供給されるものを使います。

例

以下は［IDベースの接続プールの有効化］、［Oracleプロキシ・セッション］、［データベース資格証明の使用］間の作用に関する実例です。
データベース側で、以下のオブジェクトを構成します。

• データベースユーザはscott、jdbcqa、jdbcqa3
• プロキシの権限を設定する
• alter user jdbcqa3 grant connect through jdbcqa;
• alter user jdbcqa grant connect through jdbcqa;

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

• weblogic, wluserのユーザを作成
• "weblogic" を "scott"に資格証明をマッピング
• "wluser"を"jdbcqa3"に資格証明をマッピング
• データソース識別子を"jdbcqa"ユーザで構成
• ［クライアントIDを設定］を有効にした状態で全てのテストを実施する（詳細は下記）
• ［Oracleプロキシ・セッション］を無効にした状態で全てのテストを実施する（詳細は下記）

テストプログラムでは以下を実施します。

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

データベース資格証明の使用	IDベース	getConnection (scott,***)	getConnection (weblogic,***)	getConnection (jdbcqa3,***)	getConnection()
使用する	使用する	ユーザー（scott） クライアント（weblogic） Proxy（なし）	weblogicで失敗（DBユーザーではない）	ユーザー（jdbcqa3） クライアント（weblogic） プロキシ（なし）	デフォルトユーザー(jdbcqa) クライアント（weblogic） プロキシ（なし）
使用しない	使用する	scottで失敗 （WLSユーザーではない）	ユーザー（scott） クライアント（scott） プロキシ（なし）	jdbcqa3で失敗（WLSユーザーではない）	ユーザー（scott） クライアント（scott） プロキシ（なし）
使用する	使用しない	scott用のプロキシで失敗	weblogicで失敗（DBユーザーではない）	ユーザー（jdbcqa3） クライアント（weblogic） プロキシ（jdbcqa）	デフォルトユーザー(jdbcqa) クライアント（weblogic） プロキシ（なし）
使用しない	使用しない	scottで失敗 （WLSユーザーではない）	デフォルトユーザー(jdbcqa) クライアント（scott） プロキシ（なし）	jdbcqa3で失敗（WLSユーザーではない）	デフォルトユーザー(jdbcqa) クライアント（scott） プロキシ（なし）

［クライアントIDの設定］を無効にした場合、全てのケースでクライアントはNULLになります。
Oracle Thinドライバでない場合、上記表で非NULLプロキシを使うと、例外が発生します。プロキシセッションを明示的・暗黙的にサポートしているのはOracle Thinドライバだけだからです。
oracle-proxy-sessionをtrueにすると、（"jdbcqa"のプロキシを使用して）成功するパターンは以下の条件に限られます。

1. ［データベース資格証明の使用］を有効に設定し、getConnection(jdbcqa3,…) もしくは getConnection()を使う場合。
2. ［データベース資格証明の使用］を無効に設定し、getConnection(wluser, …) もしくは getConnection()を使う場合。

まとめ

データソースのセキュリティに関して、選択可能なオプションが多数あります。WLSやデータベースのユーザ数と変動率、データアクセスの粒度、セキュリティIDの深さ（接続ユーザや実際のユーザーに関するプロパティ）、パフォーマンス、ソフトウェアスタック内のさまざまなコンポーネントの調整やドライバの機能を考慮しなければなりません。今、あなたは全体像（パート1の表）を持っているわけですから、より多くの情報に基づいて選択できます。