内部統制に効く! データベースセキュリティ

第4回データベース監視のススメ[DB監査ログ取得編]

前回までで、データベースの導入・設定、およびその周辺のデータベースセキュリティ対策を解説しました。今回からは「DB監査ログ」⁠データベース監視」をキーワードに、さらに一歩踏み込んだデータベースセキュリティ対策を解説していきます。少々テクニカルな話題から外れているかもしれませんが、データベースセキュリティの常識として、おつきあいいただければと思います。

なぜデータベース監視なのか

「データベース監視」を一言で表すとすると「データベースへのアクセスを監視し(含むDB監査ログ取得⁠⁠、不審なアクセスを早期に発見・管理する仕組み」になります。ではなぜ必要なのでしょう?

情報漏洩事件の多くが内部犯行である
昨今、いくつかの情報漏洩事件の原因として、関係者による犯行という報道が多くなされています。データベースは、重要情報へアクセスする権限を持つ者に対して無防備です。つまり、システム運用者、DB管理者が悪意持って重要情報を取得しようとした場合は、防ぐことができません。そのようなことを考えるのはごく一部の人間でしょうが、脅威として考えられる以上、対策を立てる必要があります。つまり、悪意のある第三者に加え、システム運用者やDB管理者も監視対象とするべきなのです。
内部統制でも求められるデータベース監視
企業で業務プロセスが行われるためには、ほとんど何らかのアプリケーションシステムが利用されており、そのIT基盤として必ずと言っていいほどデータベースが存在します。そのデータベースには、会計報告に利用するデータや、業務上重要な情報が収められています。データベース監視を行うことは、データベースに保管される情報の正当性と安全性を担保し、内部統制されている証明の一部となります。情報が第三者に漏れてから発覚することのないよう、可能な限り対策を行う必要があります。

以上のことからも、情報漏洩の積極的対策であるデータベース監視を行うことは必然と言えます。

まずはDB監査ログの取得方針を決める

データベース監視を行うためには、データベースに対するアクセスを確認する必要があります。そのためには、いわゆるアクセスログに当たる「DB監査ログ」を使用します。DB監査ログを取得する手段は、各DBMSの標準機能の使用や、市販されているDB監査ソフトウェアを利用することになります(DB監査ソフトウェアについては次回で触れます)が、その前にどのようなログを取得するべきか目的を明確にして方針(ポリシー)を決定しておきます。方針化することで、運用するデータベースごとに異なったログ取得や、運用となってしまうことを防ぐことができます。DB監査ログ取得方針で明確にしてきたい点は、おおよそ下記の通りになります。

  • 取得する項目(いつ、だれが)
  • 取得する目的(何を監視するためのログか)
  • 取得する操作(なにを、どうした)
  • DB監査ログ管理方針

このDB監査ログ取得方針は、DB監査ログを取得する手段にも影響する(される)ので、DB監査ログ取得、データベース監視パフォーマンスを含めた全体とのトレードオフとなります。

取得しておきたい項目とは

DB監査ログの取得項目は、不審なアクセスの検知、最悪は情報漏洩が発生した場合の被害範囲追跡のために利用します。具体的には以下の項目になります。

  • 実行日時
  • 接続クライアントIPアドレス
  • DBアカウント名
  • OSアカウント名
  • 対象オブジェクト名
  • コマンド種類(SELECT/UPDATE/CREATE/CONNECT等)
  • SQL文[1]
  • バインド値[1]
  • アプリケーションアカウント[2]
  • 実行結果(成功/失敗のコード、件数[1]⁠)等

アカウント分離の必要性

  • DB監査ログに記録される「誰が」にあたる「DBアカウント名」⁠OSアカウント名」ですが、運用者によっては強力な権限を付与した共有アカウントを使ってアクセスしている場合が多々あります。せっかく取得したDB監査ログの証拠力を高める意味でも、可能な限りアカウント分離を実施して、個人ごとの専用アカウントでアクセスさせる必要があります

監視しておきたい操作とは

システム運用者やDB管理者のような強力な権限を持つ者を監視対象とした場合、データベースに対する脅威として、以下のような行為などが考えられます。

  • データベースを強制的に停止する
  • データベースへ不正に接続し、重要情報を参照する、または改ざんする
  • 不正なプログラムを実行する

その対策として、下記のようなDB監査ログを取得し、不審なアクセスの検知および追跡を行えるようにします。

  • データベース起動、停止
  • データベースへの接続
  • データベースの設定変更
  • DB管理者アカウントによる操作
  • プロシージャの実行
  • エクスポート(大量データ抽出)

また、重要な情報を保管するテーブルへのアクセスについて、参照、更新などのDB監査ログを取得しておく必要があります。しかし、すべてのテーブルへのDB監査ログを取得するためには、多くのログ領域が必要となります。そのため保管する情報にランク付けを行うなどして、取得する対象や操作を限定し、必要なログ領域を減らすことも検討します表1⁠。

表1 情報ランク付けの例
ランク ログ取得方針 不正アクセス発生時のリスク
参照 更新
A 参照されても改ざんされても、不正アクセスされた場合は問題となる。
B × 個人や企業がコード管理されていて、参照は問題ないが、改ざんされた場合は問題となる。
C × 重要情報ではないがマスタであるため、改ざんされると可用性が問題となる。
D × × リスクはなし。

DB監査ログの管理

DB監査ログは、不正アクセスを検知する場合の情報となり、また図らずも不正アクセスが発生した場合の証拠となるものであり、管理には万全を期す必要があります。DB監査ログの管理で定義しておく項目の例として、以下のものが挙げられます。

  • 保管場所・方法
  • 保管期間
  • 改ざん対策等

また、DBMSの標準機能を利用してDB監査ログを取得しようとした場合、その設定をDB管理者しかできない場合があります。当然、DB管理者もログにアクセス可能となることからも対策が必要になります。その点、DB監査ソフトウェアは、収集したログを別の場所へ保管するので、その機能で担保することも考えられます。

DB監査ログは、取得しているだけでは使い道が限られますが、データベース監視を行う上で大変重要です。DB監査ログ取得方針により統一的なログ取得を行うことで、無駄なDB監査ログを取得することや、逆に取得漏れがないようにしましょう。

次回は、今回決定した方針に基づき取得されたDB監査ログを利用して、データベース監視を行う場合の監視運用に焦点を当てて解説します。

おすすめ記事

記事・ニュース一覧