SQLインジェクションの脆弱性も、データベースのお粗末な運用に起因する。この問題は、SQLクエリがどのようにデータベースに送信されるかにかかわっている。データベースが、チェックとサニタイジング（無害化）を経ていないユーザー入力データから生成されたSQLクエリを受け取る場合、SQLインジェクション攻撃を受けやすい。例えば、Webベースのフォームから受信されるような入力データを修正することにより、攻撃者は悪質なSQLクエリを送信し、データベースに命令を直接渡すことができる。

　こうした攻撃を防ぐには、ユーザーから提供されるデータはすべて、スクリプトやデータアクセスルーチン、SQLクエリに渡す前に検証することが重要であり、また、パラメータ化されたクエリを使用することが望ましい。ユーザーから受け取るデータを検証、清浄するもう1つの理由は、クロスサイトスクリプティング（XSS）攻撃を防ぐことにある。この攻撃は、Webサーバに接続されたデータベースに侵入するのに用いられる。その手口は、JavaScriptなどのクライアントサイドスクリプトをWebフォーム経由でWebアプリケーションの出力データに注入するというもの。cookieは、ユーザーアカウントのログイン情報を保存するなど不適切に使用されることが多い。

　データベースアプリケーションの構築時に見過ごされがちな問題の1つとして、不注意によるデータ漏えいがある。機密データがうっかり譲渡されたり公開されてしまうというものだ。典型的な不注意ミスは、データベースをバックアップしたテープについて、利用の安全確保や管理を怠ることだ。比較的見えにくいのが、データ推測による漏えいである。正当なデータクエリへの応答から、機密データが推測されてしまうことがしばしばある。例えば、処方薬から病名の推測がつくといった具合だ。一般的な対策は、クエリパターンを監視して、そうした推測が行われているのを発見することだ。

　不注意によるデータ漏えいと密接に関連するのが、データベースでエラーが発生した場合の不適切なエラー処理だ。多くのアプリケーションは詳細なエラーメッセージを表示する。こうしたエラーメッセージがデータベースの構造に関する情報を明かしてしまい、それが攻撃を仕掛けるのに利用されてしまう恐れがある。記録のためにエラーのログを取るのは必須だが、アプリケーションがユーザーに（もちろん攻撃者にも）エラーの詳細を決して返さないようにしなければならない。

　データベースのセキュリティを万全にするには、管理タスクを以下の4つの領域に分割し、総合的に取り組む必要がある。

• サーバセキュリティ
• アプリケーションセキュリティ
• データベース接続
• データベースとテーブルのアクセス制御

　データベースサーバについては、ほかのすべてのサーバの場合と同様に、悪意あるハッカーがOSの脆弱性を突いてデータベースを攻撃できないように、守りを固めなければならない。データベースは、アプリケーション層の専用ファイアウォールで保護することが望ましい。

　データベース接続の保護とアクセス制御の定義を行う上では、アプリケーションにおけるデータの流れを示すデータフロー図の作成が役立つ。次に、別のアプリケーションへの入出力がどこで行われるかを確認し、それらの入出力ポイントに設定されている信頼レベルを調べる。さらに、外部のユーザーやプロセスがシステムにアクセスするのに必要な最低限の権限を定義する。このようにセキュリティに重点を置いてデータベースアプリケーションを構成、構築すれば、データの安全性を確保できるだろう。

本稿筆者のマイケル・コッブ氏は、データセキュリティおよび解析に関するトレーニングやサポートを提供するITコンサルティング会社、コッブウェブアプリケーションズの創業者兼マネージングディレクター。CISSP-ISSAP（公認情報システムセキュリティプロフェッショナル―情報システムセキュリティアーキテクチャプロフェッショナル）の資格を持つ。共著書として「IIS Security」があり、主要なIT出版物に多くの技術記事を寄稿している。