【全】ヘッダーリンク
【全】お問い合わせ
サイト内検索 検索
【全】メガメニュー
H1

コラム掲載

【お知らせ一覧・詳細】コラム掲載
ログ管理・証跡管理の掟

第6回:データベースのログ管理・証跡管理

ET通信連動コラム第2弾「ログ管理・証跡管理の掟」。第4回からは、Windows、UNIX系と各システム固有のログ管理・証跡管理のポイントや留意点を解説してきましたが、第6回となる今回はデータベースのログ管理・証跡管理のポイントについてご紹介します。

セキュリティ上 重要性が高いデータベースのログ管理・証跡管理

データベース企業のシステムにおけるデータベースの役割は、整形された情報を安全に保管し、必要に応じて効率的に抽出することです。そのため、多くの業務システムではデータの格納場所としてデータベースを採用しており、業務に関連する膨大な情報がデータベース内に格納されています。したがって、データベース内の情報の機密性、完全性、可用性などが損なわれるようなセキュリティ侵害は、企業の重要なデータの漏洩や逸失につながる恐れが高く、データベースへのアクセスに関するログ・証跡管理は、その早期発見のために重要な取り組みです。

データベースのログ固有のポイント

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

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

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

多くのシステムでは、アプリケーションが動作する場合に、OSに対して人がログオンして行うような方法でコンピューターリソースを利用することはありません。
 

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

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

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

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

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

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

 

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

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

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

このような複雑なデータベースのログ管理・証跡管理のポイントは、何を目的としてログを集めるのかという点を明確にすることです。目的を定めずにただ漫然とログを集めているだけでは、増大するログの保管場所を持て余すだけでなく、いざ調査を行う必要が発生した場合に、目的の情報が見つからないといった事態に陥りがちです。

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

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

アプリケーションを使用した業務上の監査ログはアプリケーション側で実装した方が良い

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

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

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

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

不正なデータベースアクセスを早期発見するためのポイント①

不正なデータベースアクセス
外部の攻撃者による不正アクセスについては、そもそもログ管理の以前に、データベースそのものに備わっているアクセス元の制御を適切に行うことでデータベースのアカウントだけが詐取され、データベースサーバー自体に侵入されない状態でリモートからアクセスされる可能性は極めて低いことを前提に考えます。

例えば、Web系など3層のアプリケーションの場合は、データベースにアクセスするのはアプリケーションサーバーのみでであることから、データベースのアクセス元制御でアプリケーションサーバーからのみ接続を許可するように設定しておけば、アプリケーションサーバーが乗っ取られない限りデータベースには不正にアクセスされないということになります。
クライアントから直接データベースにアクセスするような2層構造のアプリケーションでは、アクセス元は一定範囲広げざるを得ないため、クライアイント端末が踏み台にされてアクセスされるケースも想定して、ログ取得の必要性が高いと言えます。

不正なデータベースアクセスの早期発見するためのポイント②

データベースに対する内部者の不正なアクセスについては、データベースの管理者アカウントを使って本来の作業以外の操作を行うことによって発生します。そのため、アクセスされること自体は異常ではないため、そのアクセス内容に異常な点がないかを確認することが重要です。

しかし、この場合も実際の運用に落とし込むのはかなり困難です。冒頭に記載した通り、データベースの場合は、人の操作による処理と、アプリケーションによる処理がOSのように構造的に異なるような形になっておらず、判別が困難だからです。

利用するアカウント、アクセス元などでログをフィルタリングし、発行された処理文の妥当性をチェックするなどの方法が考えられますが、データベースサーバーに直接ログインし、アプリケーションが使用するアカウントを利用した場合には、人の操作による処理が埋もれてしまう可能性があります。

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

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

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

弊社の多くのお客様が、このような方法で、データベース管理者によるマニュアル操作によって発生しかねないデータベースに格納された情報の不正な取り扱いを抑止・早期発見しています。

ESS RECについての詳細はこちらから

 

次回は、様々な企業で利用が加速している仮想環境のログ管理の留意点やログ管理について解説します。

 

<<前へ    コラム一覧    次へ>>