レベル: 中級 Hitomi Horibe (HITOMIH@jp.ibm.com), IT Specialist, 日本アイ・ビー・エム システムズ・エンジニアリング株式会社
2009年 02月 19日 この記事では、DB2の監査機能に関して、3層Webシステム構成時の監査方法についてご紹介したいと思います。
はじめに
現在では、クライアント/Webアプリケーション･サーバー/データベース・サーバーの3層から構成されるWebシステムが、多くの環境で稼働しています。このようなシステムでは、システム内の取引過程を記録するため、各層で作業ログを取得するといった運用がなされていることが多いかと思います。
このような3層Webシステムにおいて、Webアプリケーション・サーバーからデータベース･サーバーへ接続するユーザーは、データ・ソースのJ2C認証データ(J2EE Connection Authentication Data)に設定し、ここで定義したユーザーでデータベースにアクセスしています。この構成で監査ログを取得しますと、Webアプリケーション・サーバー側では、例えばユーザー管理製品(IBM製品ですと、Tivoli Identity Manager等)や、フォーム認証等で認証したユーザー情報が記録されますが、データベース・サーバー側の監査ログでは、すべてデータソースに定義しているユーザー情報で記録されることとなってしまいます。このため、データベース・サーバー側の監査ログでは、アプリケーションからのアクセスが実際には誰によって行われたのか識別することができません（図1）。
しかしWebSphere Application Server (以降、WASと表記) V6より、ClientInformationAPIの使用が可能となりました。このAPIを使用し、アプリケーションにユーザーの識別情報を埋め込むことで、DB2の監査ログにおいても、ユーザーIDなどクライアント情報を識別することが可能になっています。
今回の記事では、このような3層WebシステムにおけるDB2サーバー上のユーザー識別に有効な機能として、主にClientInformationAPIとDB2 V9.5の監査機能の組み合わせについて、ご紹介したいと思います。
図1 3層Webシステムでの監査ログの不一致
3層Webシステム上における監査ログの課題への解決策
このAPIでは、ユーザーIDやアプリケーション名など、クライアント情報をプロパティーに設定することができます。つまり、このAPIでフォーム認証やユーザー管理製品で認証したユーザー情報を設定すれば、データベース･サーバーの監査ログにも、ClientInformationAPIで設定したユーザー情報で記録され、監査ログの不一致という課題を解決することができます。
ClientInformationAPIで設定できるユーザー情報は、以下のとおりです。
- WSConnection.CLIENT_ACCOUNTING_INFO
- WSConnection.CLIENT_LOCATION
- WSConnection.CLIENT_ID
- WSConnection.CLIENT_APPLICATION_NAME
- WSConnection.CLIENT_OTHER_INFO
- WSConnection.OTHER_CLIENT_TYPE
それでは、実際にClientInfomationAPI使用時のDB2監査ログ取得手順について、図2の手順により、具体的に見ていきましょう。
図2 監査構成と運用のステップ
①APIによるユーザー情報の設定 （WAS側）
WAS側のアプリケーション内でClientInfomationAPIを使用し、以下のとおりユーザー情報を設定します。今回は、CLIENT_ID、CLIENT_LOCATION、CLIENT_APPLICATION_NAME情報を設定します。
②監査ポリシーの設定 （DBサーバー側）
次にDBサーバー側で、今回は監査ポリシーを、実行されたSQLステートメントを監査する場合に有効なEXECUTEカテゴリーで作成します。監査ポリシーの作成・紐付けは、SECADM権限を持つユーザーで実行します。（監査機能の構成／運用方法の詳細については、それぞれ「DB2監査機能の概要と構成方法」、「監査機能使用時の運用方法」の回に手順を掲載していますので、そちらをご参照ください。）
③アプリケーションの実行 （クライアント側）
クライアント側でアプリケーションを実行します。
④監査バッファーのフラッシュ （DBサーバー側）
DBサーバー側監査バッファーのフラッシュを、インスタンス･オーナーで実行します。
⑤監査ログのアーカイブ／抽出 （DBサーバー側）
監査ログをアーカイブし、抽出します。この手順もインスタンス・オーナーで実行します。
⑥監査ログの確認 （DBサーバー側）
抽出された監査ログ･ファイルを確認してみましょう。
ClientInformationAPIで設定したクライアント情報が引き渡され、DBサーバー上で監査された監査ログでも表示されていることが確認できます。このようにして、アプリケーションからユーザーの識別情報を埋め込むことができれば、この情報を用いてユーザーごとに監査イベントを識別することができますね。
ここまで、Webアプリケーション･サーバー上のアプリケーションにAPIを組み込むことにより、データベース･サーバー上にそのクライアント情報を受け渡す、という手順についてお話ししてきましたが、最後にもう1つの解決策として、WLM_SET_CLIENT_INFO ストアード･プロシージャーについてご紹介したいと思います。
WLM_SET_CLIENT_INFO ストアード・プロシージャー
WLM_SET_CLIENT_INFOストアード･プロシージャーは先ほどのClientInformationAPIと同じように、現行接続に関連付けられたクライアント情報を設定するストアード・プロシージャーで、DB2 V9.5より登場しました。ClientInformationAPIがWASから提供されるAPIであり、WASのアプリケーションでしか使用できないのに対し、このストアアード・プロシージャーはSQL（Callステートメント）でクライアント情報を設定できるので、アプリケーションの言語に依存せず、WAS以外のアプリケーションでも、クライアント情報を設定することが可能になります。
また、これらの設定したクライアント情報は、監査レコードにも表示されます。
WLM_SET_CLIENT_INFOストアード･プロシージャーで設定できるユーザー情報は、以下のとおりです。
- client_userid ：クライアントのユーザーIDを指定する
- client_wrkstnname ：クライアントのワークステーション名を指定する
- client_applname ：クライアントのアプリケーション名を指定する
- client_acctstr ：クライアントの会計情報ストリングを指定する
- client_workload ：クライアントのワークロードの割り当てを指定する
WLM_SET_CLIENT_INFO ストアード･プロシージャー
ではこのプロシージャーを使用してクライアント情報を設定して実行したときの、DB2監査ログ（EXECUTEカテゴリーでの例）を以下に示します。この例では、client_userid、client_wrkstnname、client_applname、client-acctstrの情報を設定し、実行しました。
接続ユーザー名はdb2inst5ですが、WLM_SET_CLIENT_INFOストアード･プロシージャーの実行によって設定されたクライアント情報が、監査ログにも記録されていることがわかります。
おわりに
この文書では、3層Webシステム上での監査方法についてお話ししてきました。基本的な内容については、ここで触れた内容でカバーできていると思いますが、さらに詳細な情報を参考文献に挙げたDB2 V9.5 セキュリティー･デザイン･ガイドに載せていますので、こちらにも目を通してみてください。DB2の他のセキュリティー機能（認証・権限やLBACなど）についての説明もありますので、総合的なDB2のセキュリティー･デザインの助けになれば幸いです。
参考文献
著者について  | | | 堀部 ひとみは日本アイ・ビー・エム システムズ・エンジニアリング株式会社のエンジニアで、現在はDB2 for LUW分野におけるフィールドへのテクニカル・サポートを行っています。
仕事では最新技術を追いかける一方、アンティークや古いものには目がなく、週末はアンティークショップ巡りで心を潤しています。 |
記事の評価
| 
