PR

 昨今,個人情報保護法や日本版SOX法などの法整備によりデータベースのセキュリティ,特にアクセス・ログの取得が注目を集めている。商用データベースであれば,アクセス・ログを取得するための監査機能が実装されている。標準機能として提供しているのだから,監査機能を使用すればセキュリティは大丈夫,と勘違いをしている方はいないだろうか。不正アクセスなどのセキュリティをきちんと考えるのであれば,この監査機能に頼ってはいけない。

キャパシティ・プランニングが困難に

 DBMSに備わる監査機能は,あくまでも最低限の基本機能である。また,その導入は従来考えられていたデータベース設計の考え方(キャパシティ・プランニング,パフォーマンス,運用など)を一変させるだけの大きなインパクトを持っている()。

図●監査機能を使うことによる影響
図●監査機能を使うことによる影響
[画像のクリックで拡大表示]

 以下に,簡単な例を示してみよう。

 「データベースのアクセス・ログを取得する」という要件に対して「データベースの持つ監査機能を使って,すべてのテーブルに対するすべてのアクセス・ログ(SQL文など)を取得する」という設計にしたとする。

 そうすると,データベースのキャパシティ・プランニングの際に,

 - データベースに対して,単位当たり(例えば1日当たり)どの程度(何回)のSQL文が発行されるのか?
 - そのSQL文の平均的な長さ(バイト長)はどのくらいなのか?
 - さらに,これら監査ログの成長率(つまり,アプリケーションの改修の予定)はどの程度か?

 といった雲をつかむような不確定要素に頭を悩ますことになるだろう。監査ログなど,たかが知れていると侮ってはいけない。放っておくと簡単に数百G~数Tバイトになるのは当たり前の世界だ。

 上記の値を算出できたとしても,取得された監査ログをどう扱うのか,監査ログを出力することによるパフォーマンスへの影響はどの程度か,など考慮すべき点は山積みである。

 一般的に,監査機能によるデータベースへのオーバーヘッドを考慮していない既存システムであれば,その影響はさらに深刻となる。

重要なテーブルを特定するのが基本

 では,どのような解決策があるのだろうか?

 先ほどの例だと,アクセス・ログを取得すべき重要なテーブルを特定する。全テーブルのアクセス・ログを取得するのと比べれば,出力する監査ログはだいぶ少なくなる。

 どうしても全テーブルを対象としなければならない場合は,データベースの持つ監査機能以外での実装を検討する。サードベンダー製品の中には,データベースのもつ監査機能を使用せずアクセス・ログを取得する製品がいくつか存在する。製品によっては,新規,既存のデータベースを問わず,アクセス・ログによるキャパシティ・プランニングや,パフォーマンスに対する考慮といった問題が回避できる。

 今後のデータベースの設計では,厳密なセキュリティを要件に入れるのは当たり前の世界になる。いざ,設計する段階で困らないように,今のうちにデータベース・セキュリティの勘所を押さえておきたい。


新久保 浩二
インサイトテクノロジー 製品開発本部
 データベースに関する高度な技術力に惹かれ,2003年にインサイトテクノロジーに入社。現在,データベースのパフォーマンス,セキュリティ関連の製品「Performance Insight」「PISO」の開発に従事する。