レベル: 中級 Hitomi Horibe (HITOMIH@jp.ibm.com), IT Specialist, 日本アイ・ビー・エム システムズ・エンジニアリング株式会社
2009年 02月 19日 この記事では、DB2の監査機能に関して、運用方法についてご紹介したいと思います。
はじめに
前回の記事では、DB2の監査機能を利用してデータベースの監査を行うところまでのステップについてお話ししました(図Aの①~③)。今回は、監査を行うことによって生成された監査ログ・ファイルから、監査された情報をどのように参照・分析するか、という運用方法のステップ(図Aの④~⑥)をご紹介したいと思います。
図A. 監査構成と運用のステップ
④監査ログのアーカイブ
前回の記事の最後では、監査ログ・ファイルが生成されたところまでご説明しました。この監査ログ・ファイルは監査イベントが起こるたびに情報が蓄積されていく、アクティブなログ・ファイルです。DB2 V9.1まではこのアクティブな監査ログから直接データを抽出する必要がありましたが、V9.5では、アクティブな監査ログをまずアーカイブ監査ログへと移動させ、アーカイブされた監査ログからデータを抽出する、という手順に変更されました。監査ログのアーカイブを行うことで、アクティブなログに対して影響を与えることなく、アーカイブされた監査ログからデータを抽出することができるようになりました。また、アーカイブされたログを他の環境に移してから抽出することができるようになったことも、メリットの一つです。
監査ログのアーカイブは、db2audit archiveコマンドで行います。アーカイブ先のパスはデフォルトの監査ログ・ディレクトリー、またはdb2audit configure archivepathで指定されたアーカイブ監査ログ・パスに作成されます。db2audit archiveコマンド実行時にtoオプションで出力パスを指定することも可能です。
データベース・レベルの監査ログのアーカイブでは、データベース名を指定して実行します。以下に例を示します。
まず、アーカイブ前の、アクティブ監査ログ・パスとアーカイブ監査ログ・パスの状態です。この例では、アクティブ監査ログ・パスを/home/db2inst1/audit/log/active、アーカイブ監査ログ・パスを/home/db2inst1/audit/log/archiveと設定しています。
次に、db2audit archive database <DB NAME>コマンドを実行し、監査ログをアーカイブします。ここでは、データベース名としてsecurityを指定しています。
アーカイブ監査ログ・パスを確認すると、アーカイブされた監査ログが移動されていることが確認できます。
これで、アーカイブ処理が完了です。
⑤監査ログの抽出
今度はこのアーカイブされた監査ログから、監査ファイルを抽出します。抽出には、db2audit extractコマンドを使用します。データの抽出方式には、TEXT形式とDEL形式の2つの方法があり、TEXT形式は通常のテキスト・ファイルとして抽出する場合に使用します。一方、DEL形式は区切り文字のテキストとして抽出されるので、DB2に表を作成してそこへ格納したり、またExcelファイルで監査ログを管理したりする場合に使用できます。それぞれの方式での抽出例をご紹介します。
まずは、TEXT形式での監査ファイルの抽出例です。④のステップでアーカイブした監査ログから、ここではaudit.fileという出力ファイル名を指定し、抽出しています。
抽出されたaudit.fileの中身を見てみましょう。ここでは、EXECUTEカテゴリーでSTAFF表に対して監査を行った場合の例となっています。STATEMENTという監査イベントとして、SQL実行時の情報が記録されています。
ユーザーIDやアプリケーションIDの出力から、どのサーバーのどのアプリケーションで、どのユーザーがステートメントを実行しているかを確認することが可能です。実行されたステートメントや分離レベルも確認でき、パラメーター・マーカー使用時には、パラメーター・マーカーに実際に入力された値の情報も出力されます(WITH DATAオプションで監査ポリシーを作成した場合)。
次に、DEL形式での監査レコードの抽出方法です。DEL形式でもTEXT形式と同様、db2audit extractコマンドでアーカイブ監査ログを指定し、監査レコードを抽出しますが、ここではDB2監査データ格納表を作成し、抽出した監査レコードを格納するところまでの手順を追ってみましょう。
まず、監査レコードを抽出します。
カテゴリーごとの監査レコードファイルがDEL形式で作成されます。デフォルトでは、アーカイブ監査ログ・パスに作成されます。
では、抽出した監査データを格納するための表を作成しましょう。
表の作成前に、セキュリティーの観点から、監査データ格納表は他の表とスキーマを分け、SYSADM、SECADMのみにアクセス権限を与えることが推奨されています。ここでは、スキーマAUDITを作成し、監査データ格納表を作成しています。監査データ格納表は、インスタンス・ホーム以下のsqllib/miscディレクトリーに用意されている、db2audit.ddlスクリプトの実行で作成することができます(このスクリプトの実行は、データベースへの接続が存在しており、8KBの表スペースが使用可能であることを前提としています)。
監査データを格納する表の作成ができましたので、次にロード・ユーティリティーを使用して監査データをこれらの表にロードします。それぞれの表ごとにロード・コマンドを発行しますが、DELPRIORITYCHAR修飾子を指定し、バイナリー・データが適切に区切られて正しく構文解析されるようにします。また、V9.5ではLOBデータが別ファイルとして出力されますので、LOBSINFILEオプションを指定する必要があります。
また、ここでは、表にあらかじめデータが入っていて既存の表データに新しい表データを追加する場合を想定し、 INSERT オプションを使用していますが、既存の監査レコードを表から除去する場合には、 REPLACE オプションを使って表をロードします。
これで監査データが表に格納され、分析するための準備ができました。
⑥抽出した監査ログの分析
さて、格納された監査データを分析してみましょう。ここでは、表に対してEXECUTEカテゴリーで監査ポリシーを設定した場合と、データベースに対してVALIDATEの監査ポリシーを設定した場合の監査データ分析例を示します。
EXECUTEカテゴリーでの監査データ分析例
EXECUTEカテゴリーは、DB2 V9.5から導入された、実行SQLステートメントをトラッキングするのに有効なカテゴリーですが、以下のようなSELECT文で監査データを取り出すことで、いつ、どのユーザーが、どのようなSQLステートメントによって表にどのような操作を加えたのかを、簡潔に確認することができます。不正なデータベース操作を発見することに役立ちます。
上記はSELECT文実行での参照結果から、一部のレコードを抜き出したものです。この例では1行のみで結果が返されていますが、パラメーター・マーカーやホスト変数を使用した場合は、2行目以降、パラメーター・マーカーやホスト変数のパラメーターごとに 1 行を使用して、実際に入力された数値が出力されます(WITH DATAオプション指定で監査ポリシーを作成している場合)。ですので、パラメーター・マーカーが多く含まれたステートメントが多く実行される際には、出力量に注意が必要です。
VALIDATEカテゴリーでの監査データ分析例
VALIDATEカテゴリーでは、データベースに対する認証操作が行われた際に監査レコードが記録されますが、認証成功時と失敗時に記録される、それぞれの監査レコードを抜粋したものを以下に示します(成功と失敗の両方を記録するためには、監査ポリシー作成時にSTATUS BOTHを指定します)。
認証が成功した場合はSTATUS列に値0が返されます。これに対して、不正な接続要求、例えば接続時にユーザーID/パスワードの間違いがあった場合には、SQL30082Nがクライアントに返されますが、これがSTATUS列に値-30082として記録されます。認証も失敗しているので、AUTHID列はブランクとなります。また、認証に成功したクライアントのIPアドレスは10進数で記録されますが、失敗したクライアントのIPアドレスは16進数で記録されます。これらの情報から、不正な接続を発見することができます。
また、この例では監査ポリシー作成時にSTATUS BOTHを指定し、認証の成功と失敗の両方を記録する設定としていますが、認証失敗時のみ記録すればよいという要件であれば、STATUS FAILUREを指定することで、監査ログ量を減らすことができます。
おわりに
この文書では、DB2の監査機能の運用方法についてお話ししてきました。基本的な内容については、ここで触れた内容でカバーできていると思いますが、さらに詳細な情報を参考文献に挙げたDB2 V9.5 セキュリティー・デザイン・ガイドに載せていますので、こちらにも目を通してみてください。DB2の他のセキュリティー機能(認証・権限やLBACなど)についての説明もありますので、総合的なDB2のセキュリティー・デザインの助けになれば幸いです。
参考文献
著者について  | |  | 堀部 ひとみは日本アイ・ビー・エム システムズ・エンジニアリング株式会社のエンジニアで、現在はDB2 for LUW分野におけるフィールドへのテクニカル・サポートを行っています。
仕事では最新技術を追いかける一方、アンティークや古いものには目がなく、週末はアンティークショップ巡りで心を潤しています。 |
記事の評価
|