個人情報保護法が全面施行されておよそ半年が過ぎた。ご存じのように，この半年間にも情報漏洩事故／事件が相次いでいる。カカクコムやアデコなどのWebサイトからは不正アクセスによりメール・アドレスや顧客の情報が流出した。楽天に出店している店舗からはクレジットカードを含む顧客情報が漏洩している。米国でもクレジットカード情報の大規模な漏洩事件が起きている。個人情報を扱っている企業にとっては人ごとではない。

　情報漏洩を防ぐための対策には，PCのハードディスクの暗号化や指紋によるユーザー認証，ファイアウォールやIDS（侵入検知システム）による不正アクセス防御など，ネットワーク・レベルからアプリケーション・レベルまで様々ある。その中でも日経システム構築の9月号の特集では“データ”に着目し，データベースをどのように情報漏洩の脅威から守れば良いのかを取り上げた。

　この「データベース・セキュリティ（DBセキュリティ）」についての取材を進める上で，まずは複数の専門家に話を聞いた。すると，「まだこれからの分野で，どう対策を進めれば良いのかというセオリーは確立されていない」と口をそろえる。なかなか難しいテーマなのかと最初はたじろいだものの，ユーザー企業やシステム・インテグレータへの取材を進めるうちに，ユーザー企業が情報漏洩を防ぐためにやっておきたいDBセキュリティの対策が見えてきた。

やっておきたい対策は大きく5つ

　やっておきたい対策は，（1）データベースの監査ログを取得する，（2）監査ログを分析し，不正なユーザーの行為を早めに察知する，（3）許可されていないユーザーにデータベースを使わせない，（4）データベースの認証を強固にする，（5）DBアプリケーションの脆弱性をふさぐ---の5つ。

　それぞれについて，かいつまんで紹介する。まず（1）は，データベースへの操作をログに保存することである。不正が見つかった際に，証拠として犯人を特定するのに役立つ。（2）は，（1）で取得したログから，極力早い段階で不正を見つけること。例えば，「深夜に個人情報にアクセスしている」という怪しい行為をログから察知するのだ。

　（3）～（5）については基本的な対策なので，IT Pro読者にとっては目新しくないだろう。しかし，いずれも重要である。（3）は，データベースに接続できるマシンを制限すること。例えば，アプリケーション・サーバーからの接続だけを許可する。ファイアウォールやRDBMSの機能で実現できる。

　（4）は，データベースを操作するユーザーをきちんと認証し，（3）と同様にデータベースを利用できるユーザーを絞ること。強固なユーザー認証は，データベースに対してだけではなく，データベースを操作するDBアプリケーションに対しても必要だ。

　（3）や（4）を実施していても，アプリケーションに脆弱性があると認証機構などを回避されて，担当者の意図しない操作を許す可能性がある。例えば「SQLインジェクション」の脆弱性を悪用されて，メール・アドレスなどの個人情報が漏洩した事件が多数確認されている。こうした事件を防ぐために，（5）が不可欠となる。

ログから不正操作を早めに察知

　これら5つの対策の中で，（2）をいかに進めるかが重要だと取材を通じて感じた。（2）の前提となる（1）の「ログ取得」を実施している企業は増えているというのが，システム・インテグレータなどの共通認識である。保存しておけば，万一情報が漏洩した際に，犯人を特定する証拠になるからである（とはいえ，「個人情報保護法に対応するためだけに取っているというところも少なくない」と，あるインテグレータの担当者は打ち明ける。法律対応だけが目的というのはちょっと考えものだ）。

　ログを保存していることをユーザーに伝えれば，情報漏洩の抑止効果も期待できる。しかしながら多くの企業では，ログ保存の主目的を，犯人特定などの事後対策のためと考えているのが実情のようだ。

　情報漏洩は可能な限り水際で防ぐ方が望ましい。せっかくログを保存しているのだから，（2）の対策を併せて実施して漏洩防止に役立てるべきだ。「大量に個人情報を検索しているユーザーがいる」「高い頻度で個人情報を検索している」「個人情報テーブルのデータをエクスポートした」といった不正行為の前兆（あるいは不正行為を実施している最中）と考えられる操作はログから分かる。これら怪しい行為を逐次チェックしてユーザーに注意すれば，情報漏洩を未然に防げる可能性は高い。

運用中のDBをどうセキュアにするか

　このように，（1）から（5）の対策を実施すればデータベースのセキュリティ・レベルを引き上げられることは分かった。しかし，「言うはやすし行うは難し」なのがセキュリティ対策。ある企業のシステムでは，これら（1）から（5）の対策をほとんど網羅していた。ただし，「一から作ったシステムだからこそ，考えられるDBセキュリティをシステムに実装できた」（システムを設計した担当者）という前置きがある。既に稼働しているシステムに対しては，施せる対策が限定される。

　こうしたことから筆者は，冒頭の専門家によるコメントにある「セオリーが確立されていない」のは「データベースを含むシステムの多くが稼働中だから」だと理解した。運用中のシステムの状況によって，採れる対策は変わってくる。すべての運用中システムに適用可能かつ効果的な“解”は存在しない。

　特にデータベースは，システム全体の性能を左右する重要なものである。現場の担当者からすれば，安定運用を優先したいし，性能の大幅な低下は避けなければならない。既存システムへの影響を最小限に抑えつつセキュリティ対策を進めなければならない。

　しかし，DBセキュリティの対策を既存システムに適用すると，性能に影響を及ぼしかねない。例えば，データベースの監査ログをRDBMSの機能を使って取得しようとすると，データベース・サーバーに負荷をかける可能性がある。最悪の場合には，データベースが止まってしまう危険性がある。RDBMSのバージョンによっては取得できるログの種類が若干異なる。

　また，アプリケーション・サーバーを利用しているシステムでユーザー情報をデータベースの監査ログに保存しようとすると，アプリケーションの修正が必要になる場合があるだろう。

　運用中のデータベースにセキュリティ対策を実施するには，このように様々な壁がある。だからといって立ち止まっているわけにはいかないのが実情だ。5つの対策のうち，できることから対策を進めてはいかがだろうか。