[WLS] Data Source Security Part 3

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

Part 1では、セキュリティ機能をご紹介し、デフォルトの挙動についてお話しました。Part 2ではセキュリティ資格証明に関する2つの主たるアプローチ
  • 直接データベース資格証明を利用する方法
  • WLSユーザ資格証明をデータベース資格証明にマッピングする方法
を説明しました。今回はいくつかのセキュリティオプション(それぞれがデータベース資格情報またはWLSの資格情報を使用することができます)について取り上げます。

接続にクライアントIDを設定する

データソースで[クライアントIDの設定]を有効にする場合、クライアントプロパティは接続に関連付けられます。基礎となるSQLユーザは接続が生存する間変更されないままですが、クライアントの値は変更できます。この情報はアカウンティング、監査、デバッグに利用できます。クライアントプロパティは、資格証明マップを使いデータベースユーザにマッピングされたWebLogicユーザか、先ほど説明した[データベース資格証明の利用]設定に基づいた、getConnection()メソッドから直接データベースユーザのパラメータのいずれかです。
この機能を有効にするには、WebLogic Server管理コンソールの[接続時にクライアントIDを設定]を選択します。詳細は以下のドキュメントをご覧下さい。
Enable Set Client ID On Connection for a JDBC data source (WebLogic Server管理コンソールのヘルプから)
http://docs.oracle.com/cd/E24329_01/apirefs.1211/e24401/taskhelp/jdbc/jdbc_datasources/EnableCredentialMapping.html
クライアントIDの設定機能は、以下のインターフェースに基づくOracle ThinドライバとIBM DB2ドライバで利用できます。Oracle Database 11gの場合、oracle.jdbc.OracleConnection.setClientIdentifier(client)を使います。この機能を監査やデバッグ目的で利用するための詳細情報は以下のドキュメントをご覧下さい。
Oracle® Database Security Guide 11g Release 1 (11.1)
Using the CLIENT_IDENTIFIER Attribute to Preserve User Identity
http://docs.oracle.com/cd/B28359_01/network.111/b28531/authentication.htm#i1009003
Oracle Databaseセキュリティ・ガイド 11g リリース2(11.2)
CLIENT_IDENTIFIER属性を使用したユーザー識別情報の保持
http://docs.oracle.com/cd/E16338_01/network.112/b56285/authentication.htm#i1009003
JDBCドライバからgetClientIdentifier()を使って値を取得できます。データベースからSQLクエリで値を取り出す場合には、次のようなステートメントを使います。
select sys_context('USERENV','CLIENT_IDENTIFIER') from DUAL;
Oracle Database 12cでは、java.sql.Connection.setClientInfo("OCSID.CLIENTID", client) を使います。これはJDBC標準APIです(プロパティ値はプロプライエタリですが)。setClientIdentifier を使う上での問題は、Oracleテクノロジースタックの一部にこの値を設定したり、この値に依存するものがある、ということです。アプリケーションコードもこの値を設定する場合、問題が発生する可能性があります。この問題に対し、このメソッドを特権オペレーションとすることにより、setClientInfoを使って対応してきました。管理の行き届いたコンテナはJavaセキュリティポリシーを制限し、特定の名前空間やコードベースに権限を付与し、コントロールできないユーザコードからコンテナを守ることができます。Javaセキュリティマネージャを使う場合、Javaセキュリティポリシーファイルに、"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が動的なWHERE句をOracle Virtual Private Databaseセキュリティポリシーが適用されている表、ビュー、シノニムに対して発行されるSQLステートメントに追加します。Oracle Virtual Private Databaseの詳細は以下のドキュメントをご覧下さい。
Oracle® Database Security Guide 11g Release 1 (11.1)
Using Oracle Virtual Private Database to Control Data Access http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm
Oracle Databaseセキュリティ・ガイド 11g リリース2(11.2)
Oracle Virtual Private Databaseを使用したデータ・アクセスの制御
http://docs.oracle.com/cd/E16338_01/network.112/b56285/vpd.htm
このデータソース機能を使うと、WebLogic Serverサイドでこのコンテキストをプログラムで設定する必要がなくなります。つまり、WebLogic Serverのデータソースコードが設定・クリアしてくれます。
IBM DB2ドライバでは、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ドライバ(ver 9.5以上)の場合、java.sql.Connection.setClientInfo(“ClientUser”, client) を使います。(setDB2ClientUser()を設定していていも、)DB2の専用APIではなく、java.sql.Connection.getClientInfo("ClientUser")を使って値を取得できます。

Oracleプロキシセッション

Oracleプロキシ認証を使うと、1つのJDBC接続で、Thinドライバを使ってOracle Databaseへの複数の(シリアル)軽量なユーザ接続のためのプロキシとして振る舞うことができます。WebLogicデータソースを構成し、プロキシユーザとしてアプリケーションサーバを通じてクライアントがデータベースに接続できます。クライアントはアプリケーションサーバで認証し、アプリケーションサーバはOracle Databaseで認証します。これにより、クライアントのユーザ名をデータベースとの接続で維持できます。以下の手順でOracle Databaseへの接続におけるプロキシ認証を構成できます。
  1. (まだ作成していない場合)必要なデータベースユーザを作成します。
  2. Oracle Databaseにて、そのユーザにCONNECT THROUGH権限を付与します。
    SQL> ALTER USER connectionuser GRANT CONNECT THROUGH dbuser;
    ここで、connectionuserは認証されるアプリケーションユーザ名で、dbuserはOracle Databaseのユーザです。
  3. 汎用データソースもしくはGridLinkデータソースを作成し、dbuserの値をユーザとして設定します。
  4. 利用する資格証明により、いずれかの手順を実施します。
    1. WebLogic Serverの資格証明を使う場合、資格証明マップにエントリを作成し、WebLogicユーザとDBユーザをマッピングします。
    2. データベース資格証明を使う場合、[データベース資格証明の利用]を有効にします。
  5. Oracleのプロキシ認証を有効にします。詳細はOracle WebLogic Server管理コンソールヘルプの"Configure Oracle parameters"をご覧下さい。
  6. WebLogic ServerインスタンスにWebLogicユーザもしくはDBユーザでログインします。
  7. getConnection(username, password)を使って接続を取得します。資格証明は、use database credentials設定に基づき、データベースにマップされたWebLogicユーザもしくは直接データベースユーザをベースとします。
以下のクエリで現在のユーザとプロキシユーザを確認できます。
select user, sys_context('USERENV','PROXY_USER') from DUAL
[注意]
[データベース資格証明の使用]を無効にしていて、ユーザ、パスワードの値がWebLogic Serverユーザとして存在しない場合は、getConnectionは失敗します。逆に、 [データベース資格証明の利用]が有効になっていて、ユーザ/パスワードがデータベースに存在しない場合も失敗します。
プールに対して接続要求をするたびにユーザに基づいた接続上でプロキシセッションをオープンし、接続がプールに戻るとプロキシセッションをクローズします。プロキシセッションのオープン・クローズにより、JDBCオブジェクトは以下のような影響を受けます。
  • オリジナルの接続から既存のステートメントをクローズする(結果セットを含む)
  • WebLogic Serverのステートメントキャッシュをクリアする
  • もし設定されている場合は、クライアントIDをクリアする
  • WebLogic Serverの接続確認テストステートメントを全てのプロキシセッションについて再作成する
こうした挙動は、インスタンス間で接続を共有し、接続に関連付けられた状態を期待しているアプリケーションに影響を与えることがあります。
WebLogic Server 10.3.6から、データベース資格証明の利用を有効にして、getConnection(user, password)を呼び出す場合、Oracleのプロキシセッションは暗黙的に有効になります。OracleのThinドライバを使っている場合にのみ機能することを覚えておいて下さい。
まとめると、oracle-proxy-sessionの定義は以下のようになります。
  • プロキシ認証が有効で、IDベースのプーリングが有効な場合はエラーになる
  • ユーザをgetConnection()で指定し、[IDベースの接続プーリングの有効化]を無効にした場合、暗黙のうちにOracleプロキシセッションを使う設定になる(明示的に利用する旨設定も可能)
  • ユーザをgetConnection()で指定し、IDベースの接続プールの有効化を設定すると、Oracleのプロキシセッションを使わない設定になる

    0 件のコメント:

    コメントを投稿