DB2のセキュリティー: 第2回 DB2監査機能の概要と構成方法

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 中級

岩橋 智宏, IT Specialist, 日本アイ・ビー・エム システムズ・エンジニアリング株式会社

2009年 02月 19日

この記事では、DB2の監査機能とその構成方法を紹介します。

はじめに

昨今、データ・セキュリティー対策に大きな関心が寄せられています。日本国内においても個人情報保護法の施行や、金融商品取引法（J-SOX法）によって内部統制の強化が法制度化されたことにより、企業や政府機関はデータの信頼性を保証し、情報漏洩からデータを守る責任をより一層強く求められています。また、システムの中で大切なデータを保管しているデータベースに対してもセキュリティー対策を実施していく必要性が増しています。この記事では、DB2が提供するセキュリティー機能の中から、特に監査機能を取り上げ、データベース監査の構成方法や運用方法をご紹介します。

上に戻る

データベースに対する脅威

データベースは日々セキュリティー脅威にさらされています。従来、システムのセキュリティー対策というと、ファイアウォールの導入やネットワーク暗号化、パスワード認証の強化など、外部からの侵入を想定したものでした。しかし、これらはデータベース自体というより、その周囲に対するセキュリティー対策であり、現実には、これだけでは十分とは言えません。なぜなら、データを盗もうとしているのは、外からの侵入者だけではなく、実は内部にもデータを狙っている者がいるかもしれないからです。データベースは、データを格納する金庫のようなものだとよく言われます。例えば、家に入るまでのセキュリティーは万全に行っていたとしても(家自体を要塞のようにしたり、厳重な鍵をかけたりしたとしても)、家の中に金庫自体が、鍵もかけずに無防備に置かれているとしたらどうでしょうか？一度家に入ることができた人間は、いつでも勝手に金庫の中身を持ち出すことができてしまいます。つまり情報の金庫であるデータベース自体にしっかりとセキュリティー対策を行い、いつ、だれが金庫に触れたかをチェックする必要があるということになります。

さて、実際にデータベースを取り巻くセキュリティー脅威にはどういったものがあるのでしょう。まず思いつくのは情報漏洩でしょうか。つい最近でも、大規模な情報漏洩事件が次々にニュースに取り上げられ、社会的に大きな関心を集めたことも記憶に新しいかと思います。企業システムのデータベースの中には、例えば顧客のクレジットカード情報や、住所、生年月日などの個人情報のように、機密性の高い情報が格納されていることでしょう。このような重要情報が何者かの手によって持ち出され、悪意を持って利用された場合、顧客に多大な被害が発生し、企業の信頼を失うようなことになりかねません。またデータ改ざんやデータ破壊の恐れもあります。業務プロセスを整備して業務プロセスの統制を行ったとしても、データベースに書き込まれたデータを後から書き換えても誰も気づくことができないような状態では、データの改ざんが簡単にできてしまうということになります。これではデータの信頼性を保証できません。

上に戻る

データベースの監査とは？

データベースの監査機能とは、あらかじめ設定したポリシーに従って、データベースに対して行われた活動を記録することです。例えて言うのであればデータベースという金庫に設置された防犯カメラとでも言えるでしょうか。この監査機能があれば、実際に情報漏洩やデータ改ざんなどのセキュリティー違反行為が発生した場合、その行為がいつ、誰によって実行されたのか特定することができます。また、このようなセキュリティー違反行為の予兆を発見し、セキュリティー違反行為を未然に防ぐことに利用できます。これ以外にも、監査をしていることを組織内に周知することで不正行為を事前に防ぐ効果があるとも言われています。次に実際にDB2の監査機能を使ってデータベース監査を構成する方法についてご紹介していきます。

上に戻る

DB2 9.5の監査機能拡張

以前からDB2ではdb2auditユーティリティーによる監査機能を提供しており、誰が、いつ、何をしたかを特定するために、さまざまなタイプの監査を行うことができました。

さらにDB2 9.5が登場したことによって、これらの監査機能が大幅に機能拡張されています。これらの機能拡張の中でも最も大きな変更点は、監査の対象をより細かいレベルで、より柔軟に設定できるようになった点でしょう。以前のバージョンでは、監査の単位がインスタンス・レベルであっため、インスタンス配下すべてのデータベースおよび、データベースに含まれるすべてのオブジェクトが監査の対象になっていましたが、V9.5からはデータベース単位で、より細かい単位での監査を行うことができるようになりました。さらにデータベースの中の「特定の表へのアクセス」や、「特定のユーザーによる操作」というように、監査対象をオブジェクトのレベルまで絞り込むことができるようになりました。このように監査対象をピンポイントで絞ることによって、監査ログ取得のオーバーヘッドやログ保管に必要になるディスク容量を最小限に抑え、分析運用自体の負荷も削減することができます。

その他にも、V9.5からは監査ログの配置を任意のパスに変更してI/O負荷を分散させるといったことや、アクティブな（書き込み中の）ログと、データ解析用のログを分離する（アーカイブする）ことで監査のパフォーマンスを向上させるといった、より柔軟な監査運用が可能になっています。

上に戻る

V9.5監査構成と運用ステップ

それでは実際にDB2の監査を構成してみましょう。DB2の監査を構成し、運用を行うまでのステップは図3のようになります。以下順番に各ステップを説明していきます。

上に戻る

①　SECADM権限ユーザーの登録

監査の構成は、SECADM権限を持つ特別なユーザーで実施する必要があります。ここでは、SECUSERというユーザーにSECADM権限を与えましょう。これから先の操作はすべてSECADM権限を持ったSECUSERというユーザーで接続して行います。（SECADM権限の付与はSYSADM権限を持つユーザーによって行う必要があります。）

$ db2 grant secadm on database to user secuser

上に戻る

②　監査ポリシーの作成

監査を行う際にはまず、監査ポリシー（AUDIT POLICY）を作成します。これは、どのような種類のオペレーションまたは活動について監査を行うかの方針を決定するものです。作成したAUDIT POLICYを、この後に説明するAUDITコマンドを用いて、実際に監査を行いたいオブジェクトに関連付けることで監査が開始されます。AUDIT　POLICYで選択できる監査カテゴリーには、表1に示されるようにいくつかの種類があります。必要に応じてこれらを組み合わせて選択します。

ここで、V9.5から追加されたEXECUTEカテゴリーについて補足します。EXECUTEカテゴリーはV9.5で導入されたデータベース・レベルの監査(*1)で利用することができます。このカテゴリーを利用して、ユーザーが発行する SQL ステートメントを的確にトラッキングすることが可能です。SQL ステートメントのテキストのほか、後でステートメントを再現するために必要な情報も収集します。またCREATE AUDIT POLICY時にWITH DATAオプションを付けることで入力ホスト変数や、パラメーター・マーカーの値も取得可能です。

(*1)　データベース・レベルの監査：　今回ご紹介している、データベース単位で行う監査方法（V9.5～）のこと。V9.5では今までどおりのインスタンス単位の監査方法も引き続き存在している。

上に戻る

③　監査対象オブジェクトへのマッピング

次にAUDITコマンドを使って、実際に監査を行いたいオブジェクトと先ほど作成した監査ポリシーのマッピングを行います。監査対象としてデータベース全体を指定することもできますが、特定の表、ユーザー、グループ、ロール(*2)、トラステッド・コンテキスト(*3)などを指定し、監査対象を絞り込むことができます。詳細は表2をご覧ください。

(*2) ロール（V9.5～）：　複数の特権やデータベース権限をまとめて名前を付けたものをロールと呼ぶ。ロールをユーザーやグループに対して与えることができる。

(*3)　トラステッド・コンテキスト：　アプリケーションサーバーを経由した3層アプリケーション環境において、トラステッド接続を確立するためのオブジェクト。

それでは、実際にいくつか、監査構成のサンプルを見てみましょう。

• サンプル1．　特定表へのアクセス監査

  特定の表に対するアクセスを監査し、情報漏洩に繋がる不正な情報参照、データの改ざんなどの証跡を取ります。この例では、個人情報を含むEMPLOYEEテーブルに対するアクセスを監査してみます。実行ステートメントを監査するために、EXECUTEカテゴリーでAUDIT POLICYを作成します。次に、AUDITコマンドを使用してEMPLOYEE表にポリシーを関連付けます。AUDITコマンドをCOMMITした後に監査が始まります。（V9.1以前のインスタンス・レベルの監査ではdb2audit startによって監査を開始しましたが、V9.5のデータベース・レベル監査を行う場合は運用が変わっています。）

  
  
  

  CREATE AUDIT POLICY SENSITIVEDATAPOLICY CATEGORIES EXECUTE STATUS BOTH ERROR TYPE AUDIT; COMMIT; AUDIT TABLE EMPLOYEE USING POLICY SENSITIVEDATAPOLICY; COMMIT;

  
  
• サンプル2．　パスワード間違いの監査

  データベースにアクセスするユーザーのパスワードがパスワード・アタックによって悪意のあるユーザーに漏れると、正規のユーザーに成りすまして不正なデータ・アクセスができてしまいます。パスワード・アタックの前兆を察知するためには、接続時のパスワード間違いによる認証の失敗を監査するのが有効です。認証関連の監査はVALIDATEカテゴリーを利用します。認証に失敗したときのみ監査を取得する場合は、STATUS FAILUREを指定して監査ポリシーを作成することで、ログ生成量を抑えることができます。

  
  
  

  CREATE AUDIT POLICY PASSWORDCHECK CATEGORIES VALIDATE STATUS FAILURE ERROR TYPE AUDIT; COMMIT; AUDIT DATABASE USING POLICY PASSWORDCHECK ; C

  
  
• サンプル3．　システム管理ユーザーによるアクションを監査する例

  システム管理ユーザーがどんなときでも信頼できるとは限りません。実際に情報漏洩を含むセキュリティー違反は、内部のシステム権限を持ったユーザーによって行われるケースが多いという報告もあります。SYSADMやDBADM権限を持ったシステム管理ユーザーであれば、データベース構成の変更や、権限の授与など行うことが自由にできてしまいます。この例では、SYSADM または DBADM によるデータベース内でのすべてのアクションを収集するために、EXECUTEカテゴリーと SYSADMINカテゴリーの両方を指定した監査ポリシーを作成します。これによってSYSADM または DBADM 権限を保持しているユーザーについて、監査可能なイベントのログが記録されます。

  
  
  

  CREATE AUDIT POLICY ADMINSPOLICY 　CATEGORIES 　　EXECUTE STATUS BOTH, 　　SYSADMIN　STATUS BOTH 　ERROR TYPE AUDIT; COMMIT; AUDIT SYSADM, DBADM USING POLICY ADMINSPOLICY; COMMIT;

  
  

  AUDITコマンドをCOMMITすると監査ログが取り始められます。デフォルトの監査ログパス（*4） にログが書かれていることがわかります。このとき生成される監査ログはバイナリー・ファイルなので、内容を確認することはできません。次の回では、このファイルをアーカイブしたのち、中身を抽出して監査ログを解析する手順を紹介します。

  (*4) 監査ログのデフォルト・パスは以下。　

  ただし、db2audit configure コマンドによってパス変更可能。

  Windows:

  C:\Documents and Settings\All Users\Application Data\ibm\DB2\DB2コピー名\DB2インスタンス名\security\auditdata

  Linuxおよび UNIX:

  $instance_home/sqllib/security/auditdata

参考文献

• DDB2 9.5技術資料 DB2 V9.5 セキュリティー・デザイン・ガイド
  
  
• (オンライン・マニュアル)DB2 Information Center

著者について

		岩橋 智宏は日本アイ・ビー・エム システムズ・エンジニアリング株式会社のエンジニアです。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）