企業のシステムにおけるデータベースの役割は、成形された情報を安全に保管し、必要に応じて効率的に抽出することです。そのため、多くの業務システムではデータの格納場所としてデータベースを採用しており、業務に関連する膨大な情報がデータベース内に格納されています。

したがって、データベース内の情報の機密性、完全性、可用性などが損なわれるようなセキュリティ侵害は、企業の重要なデータの漏洩や逸失につながる恐れが高く、データベースへのアクセスに関するログ・証跡管理はその早期発見のために重要です。

そこで本記事では、データベースのログ管理・証跡管理の具体的な対策や留意点をご紹介します。

データベースのログ管理・証跡管理の留意点

前回の記事では、Windows、UNIXといったオペレーティングシステム（OS）のログ管理の固有の留意点やポイントを解説していますが、データベースはこれらOSとは異なる固有の留意点が存在します。

アプリケーションがアクセスすることで発生する大量ログ

データベースのログ管理は、アプリケーションによるアクセスと、人によるアクセスの識別が困難である点がOSと決定的に異なる点です。業務システムで利用しているような本番環境のデータベースはアプリケーションによって頻繁にアクセスされますが、これらのアクセスと、人が何らかの意図をもってアクセスした情報との識別が困難なわけです。

多くのシステムでは、アプリケーションが動作する場合に、OSに対して人がログオンして行うような方法でコンピューターリソースを利用することはありません。
例えば、Windowsシステムであれば、人の操作時はID・パスワードを用いてログインし、デスクトップを介して操作をします。一方、アプリケーションの場合、このような「対話側ログオン」を伴わない「サービス」としてOSリソースを利用します。
そのため、出力されるログの内容から、人が明示的にログオンをして行った内容とアプリケーションがOSリソースを使用した内容は識別が容易です。

しかし、データベースの場合は、処理命令がアプリケーション・人のいずれであっても同じログインプロセスを経て、SQL文と呼ばれる同じ言語で処理されています。しかも、本番環境で動作しているような環境では、大量のトランザクションを処理することで大量のログを出力しますので、重要な情報が埋もれてしまう可能性があります。

デフォルトでは設定されていない場合が現在でも多数

OSの場合、現在流通しているような比較的新しいバージョンであれば、商用・OSSを含めほとんど標準で監査ログを取得する設定になっています。しかし、データベースでは最新のバージョンであっても標準で監査設定が有効になっていなかったり、最小限のログのみが取得される状態だったりしています。
そのため、導入時に要件として、どのようなログを取得しておくべきかを決めて、それを満たすデータベースの選定や導入時の設定を行わないと、あとから設定変更が必要になる場合があります。

多様な監査設定とデータベースのパフォーマンスへの影響

これらの設定によっては、データベース自体のパフォーマンスに影響を及ぼすことから、システム全体のキャパシティープランの見直しが必要になってくることも想定されます。

データベースの種類・バージョンによって異なるログ

データベースの監査機能はデータベースエンジンと比較し、その歴史が比較的浅いため、各社のデータベースの監査機能は、旧バージョンと新バージョンで大きく異なる場合があります。開発メーカーによっても監査機能は大きく異なるため、その出力内容・出力形式にも相違があります。

目的を定めてログ管理・証跡管理を行うことの重要性

このような複雑なデータベースのログ管理・証跡管理のポイントは、何を目的としてログを集めるのかという点を明確にすることです。

目的を定めずにただ漫然とログを集めているだけでは、増大するログの保管場所を持て余すだけでなく、いざ調査を行う必要が発生した場合に、目的の情報が見つからないといった事態に陥りがちです。

デバッグ目的であれば解析時だけログ取得

アプリケーションのデバックを行うことが目的であれば、常にログを取得する必要はありません。テスト環境で監査設定を有効にしておき、処理に応じて発行されるSQL文を解析することで多くのケースは問題解決が可能です。

業務上の監査ログの取得はアプリケーション側で実装

ユーザーが業務処理を正しく行っているかどうかを監査するためのログを取得するのであれば、アプリケーション側で実装することが望ましいと言えます。その理由は2つ挙げられます。

• アプリケーションの構造上、アプリケーションからデータベースにアクセスするユーザーは業務システムを利用するユーザーではなく、常に同じユーザーアカウントでアクセスするようなロジックになっている場合が圧倒的に多いです。よって、データベース側のログを見ても誰が業務システムを操作したのかは判別できません。
• 業務上の監査では主に、変更前の値と変更後の値を参照できることが望ましいが、データベースのログでは、そのような参照の仕方が技術的に困難です。

セキュリティ対策を目的としたデータベースのログ管理・証跡管理のポイント

前述の通り、セキュリティを担保するためのログ管理については、①外部の攻撃者による不正アクセスの発見、②内部者の不正アクセスの発見 の2つのリスク要因に分けて整理してみましょう。

1. 外部の攻撃者による不正アクセスの発見
   外部の攻撃者による不正アクセスについては、そもそもログ管理の以前に、データベースそのものに備わっているアクセス元の制御を適切に行うことが重要です。アクセス元制御が行われている場合、データベースのアカウントが詐取されてもデータベースサーバー自体に侵入されない状態で、リモートからアクセスされる可能性は極めて低いことになります。
   例えば、Web系など3層のアプリケーションの場合は、データベースにアクセスするのはアプリケーションサーバーのみです。そのため、データベースのアクセス元制御でアプリケーションサーバーからのみ接続を許可するように設定することで、アプリケーションサーバーが乗っ取られない限りデータベースには不正にアクセスされないということになります。
   クライアントから直接データベースにアクセスするような2層構造のアプリケーションでは、アクセス元は一定範囲広げざるを得ません。クライアイント端末が踏み台にされてアクセスされるケースも想定して、ログ取得の必要性が高いと言えます。
2. 内部者の不正アクセスの発見
   データベースに対する内部者の不正なアクセスは、データベースの管理者アカウントを使って本来の作業以外の操作を行うことによって発生します。アクセスされること自体は異常ではないため、そのアクセス内容に異常な点がないかを確認することが重要です。
   しかし、この場合も実際の運用に落とし込むのはかなり困難です。冒頭に記載した通り、データベースの場合は、人の操作による処理とアプリケーションによる処理がOSのように構造的に異なる形になっておらず、判別が困難だからです。
   利用するアカウント、アクセス元などでログをフィルタリングし、発行された処理文の妥当性をチェックするなどの方法が考えられますが、データベースサーバーに直接ログインし、アプリケーションが使用するアカウントを利用した場合には、人の操作による処理が埋もれてしまう可能性があります。

人の視点で操作を記録するという選択肢も

データベース側で受けた処理をログとして残す方法では、上記の通り、あらゆる処理に対して残すことになるため、社内のデータベース管理者の操作を記録しチェックするという目的の場合には、操作側の視点で記録を残すという選択もあります。

例えば、弊社の証跡監査ツールESS RECを利用すると、データベースの管理作業を行っているデスクトップ自体を録画します。また、データベース管理画面に表示されるSQL発行文もツールによっては検索対象として記録することが可能です。

このようにデータベース管理者によるマニュアル操作によって発生しかねないデータベースに格納された情報の不正な取り扱いを抑止・早期発見することは重要です。