やるなら今！ DBセキュリティ対策脆弱性診断ツールだけでは見つけられないDBセキュリティの脅威

Webサイトと連動するデータベースが今、狙われている。SQLインジェクション攻撃によるデータ詐取やサイト改ざんが再燃し始めた。大切なデータを不正攻撃から守る手段をツール、サービス、運用で見ていく。

[大野祐一，ラック]

攻撃者の関心は金目のデータにあり

　今、インターネットからSQLインジェクション（※1）という攻撃を通じて、データベース（DB）内に格納された個人情報（特に電子メールアドレス）に始まり、クレジットカード情報、さらにはオンラインゲームのアカウント情報までもが狙われている（表1）。

※1　第三者がWebアプリケーションなどのセキュリティ上の脆弱性を悪用してデータベースの不正な操作を可能とする攻撃手法。

　個人情報やメールアドレスは通常、攻撃者と名簿業者やスパムメール業者などの間で売買されている。またオンラインゲームのアカウントは、普通に取引サイトで売買されている。表向きはゲームをする時間がない人が時間を金で買うために、「アカウント＋レアなアイテムや経験値」という形で売られている。一方、クレジットカード情報の場合は、売買取引ではなく、カード番号、有効期限に加えて当該サイトにログインするためのパスワードを詐取することで、通販サイトで換金しやすい航空券やイベントの入場券などのチケットや商品を購入し、それらを金券ショップや再販売などで現金化しているようだ。

表1●SQLインジェクション攻撃の目的別分類。最終的にはお金目当て

　少し毛色が違うように感じるが、ほかの脆弱サイトを検出、攻撃するための攻撃拠点を増やすためにDBのデータを狙うケースもある。最近はHTMLの一部を動的に変化させるために、DBに項目を入れておくような作りが多い。攻撃者はそこに目を付け、そのHTMLに使われているDBの項目を改変することでページを改ざんし、結果的にアクセスしてきた利用者のPCにダウンローダ、キーロガーおよびトロイの木馬などのマルウェアを強制的にダウンロードさせる。そして、感染したPCから直接クライアント情報を抜き出したり、次の攻撃時に攻撃拠点の一部にするなどの形で悪用するのだ。

Webアプリの対策に加えてDBセキュリティ対策も重要

　外部からのDBへの攻撃（SQLインジェクション）を防ぐにはインフラとWebアプリがセキュアでなくてはならない。その対策については、筆者の記事「Webサイト防御のためにできること」を参照してほしい。

　1つ付け加えたいのは、攻撃者がDBを狙っているのなら、DB側でも何らかの対策を行っておく必要があるということだ。実際には「データレベルのアクセス制御」「重要操作のロギングと不正アクセス検知」「重要データの暗号化」などである。

注意すべきは内部関係者による不正アクセス

　攻撃者はいつもインターネットからやってくるとは限らない。内部関係者による機密データへの不正アクセス事件が毎月1回程度は新聞記事などで取り上げられている。しかし、これは推測だが、記事になっているのは氷山の一角にすぎないだろう。なぜなら、現在のDBは内部関係者が不正アクセスをしてこっそりデータを流出させても、それに気付く仕組みができている場合が少ないからだ。特に電子メール、住所、電話番号＋氏名のような個人情報だけだと、どこから流出したのかを特定しづらいのだ。それでも記事になっているケースは、攻撃者が経営者や管理責任者を恐喝した例がほとんどである。

　「2007年度情報セキュリティインシデントに関する調査報告書」に掲載されている図（4〜6）によると、内部関係者による不正アクセス（報告書内では、「内部犯罪・内部不正行為」）は、漏えい原因となっている件数、比率こそ少ないが、1回に取り出す件数が大量だ。

　内部関係者には業務上必要な権限を付与しなければ本来の業務が遂行できないので、不正アクセスそのものを完全に予防することは難しい。従って、技術的な対策に加えて運用的な対策が必要になってくる。

DBセキュリティのあるべき姿

　では、DBセキュリティとしては、どのような対策が必要か。DBセキュリティを推進する業界団体であるデータベース・セキュリティ・コンソーシアムが公開している「データベースセキュリティガイドライン」や、ラックの「セキュアDBマトリクス」に書いてあるような対策が望ましい。本来は自組織でリスクアセスメントを行い、受容できないリスクに対して対応をするわけだが、いずれの資料も各対策の実施可否を検討する際の基準があるので、それらを目安に対策を検討してほしい。

　筆者は、現在のセキュリティ対策は外部からの脅威に特化し過ぎており、内部関係者がその気になれば不正アクセスを行いやすく、またそれを検知できない状況になっていると感じている。先述した内部関係者による不正アクセスのケースでは、ISMSやPマークの認証を取得している組織が被害に遭っている場合もある。そうしたケースのすべてとは言わないが、ほとんどは内部関係者を過信している設定や運用状態だったのではないだろうか。

まずチェックしてみよう

　これまでの解説で少々不安にさせてしまっただろうか。一度皆さんの担当しているシステムのDBを、先に紹介したガイドラインやセキュアDBマトリクスを使って簡単にチェックしてみてはいかがだろうか。できていそうか否かをセルフチェックするだけでよいのだ。

　また、もっと楽にチェックしてみたい、あるいはガイドに書かれていることの具体的な対策イメージが分からないということであれば、表2のツールを検討してもよいだろう。いずれの製品も評価版があるので、購入費用を掛けずに実施できる。

表2●DBの脆弱性スキャナ一覧

ツール名	提供元	URL
AppDetective	米Application Security	http://www.lac.co.jp/appsec/index.html
NGSSquirreL	英Next Generation Security Software	http://www.ngssoftware.com/
Scuba by Imperva	米Imperva	http://www.imperva.com/products/scuba.html

AppDetective（ラックなどが販売）はDBの脆弱性診断を実施し、脆弱性の要約リポートや適切な対策を提供する《クリックで拡大》

　しかし、内部システム監査や委託先に対するチェックを、表2のツールだけで対応するのは難しいだろう。先にも説明した通り、DBは技術的な対策だけでは不十分であり、運用的な対策が必要だからだ。ツールの利用は効率的なのだが、DB内の情報の重要度を考慮していないし、運用形態に関してはチェックすることができない。

　セキュリティチェックをしっかりとやるなら、業者による診断サービスがよいだろう（表3）。ただし、DBの設定だけしか診断しないサービスは、先述の理由からあまりお勧めしない。設定だけではなく、周辺を含めた運用形態をチェックしてくれるサービスでなければ、費用対効果が低いのではないだろうか。

表3●DBセキュリティ診断サービス一覧

サービス名	提供元	URL
データベースセキュリティアセスメントサービス	アイアイジェイ テクノロジー	http://www.iij-tech.co.jp/solution_service/solution/sec_sol/sc_as.html
データベースセキュリティ診断	インフォセック	http://www.infosec.co.jp/service/system/03/database.html
データベース診断	エヌ・アール・アイ・セキュアテクノロジーズ	http://www.nri-secure.co.jp/service/assessment/database.html
データベース診断サービス	三菱総研DCS	http://www.dcs.co.jp/security/diagnostic/database.html
データベース診断	ラック	http://www.lac.co.jp/jsoc/pentest/database.html

　ちなみに、表3に挙げたのは国内でサービスを提供しているものの一部であり、すべてが運用までをチェックしているわけではないと思われるので、検討する際は各社の営業担当者から説明を聞いた上で、自己責任で判断してほしい。

やはり必要なDB操作ログ

　繰り返すようだが、残念ながらDB管理者によるデータの不正参照は、現時点では一部のDBMS製品を除いては防げない。しかし、適切に操作ログを取得し、そのログを監視することで怪しい操作を早期の段階で検知したり、ログ分析をすることで怪しい操作の傾向を検出したりすることは可能だ。ログを取得して適切に運用すれば抑止効果が働き、大抵は筋金入りの悪人以外は悪事を働く気をなくすだろう。

　DBでログを取得することによる効果はまだある。不幸にもPOSTによるSQLインジェクション攻撃を受けた場合や、内部からの不正アクセスが発生した場合でも、ログから被害範囲（対象情報の種類、件数など）や攻撃手段が特定できる場合があるのだ。

　しかし、DBは第一に可用性とパフォーマンスが求められるため、これ以上DBサーバに負荷を掛けたくないという管理者や、DBサーバにエージェントをインストールしたがらない管理者は多い。簡単ではあるが、ログの取得方法別の特徴を表4、サードパーティによるログ取得・管理製品の一覧を表5にまとめた。

表4●DBにおける操作ログ取得方法一覧

	DB標準	メモリのSQL文監視	DBMS監査ログの監視	ネットワークモニタリング
エージェントの有無	追加は不要	必要	必要	不要
DBMS監査機能の実行	必須	△（セッション監査を行う場合は起動）	必須	不要（機能により必要）
DBサーバローカル操作の監査	○	○	○	×
ネットワーク暗号化対応	○	○	○	×
SQL文の取得	△（DB設定による）	○	△（DB設定による）	○
取りこぼし	なし	△（アクセス頻度によってはあり）	なし	なし
DBMS負荷	低〜中	低	低〜中	なし
アラート	別途プログラムが必要	メール、SNMP、プログラム起動などで通知可能

表5●ログ取得・管理製品一覧

ツール名	販売元	対応DBMS	URL
Audit Master	アクアシステムズ	Oracle	http://www.aqua-systems.co.jp/products/auditmaster/
Chakra	ニューシステムテクノロジー	DB2、Informix、MySQL、Oracle、SQL Server、Sybase、Symfoware	http://www.kknst.com/products/chakra/index.html
IPLocks	アイピーロックス ジャパン	DB2、Oracle、SQL Server	http://www.iplocks.co.jp/products/feature.html
PISO	インサイトテクノロジー	Oracle、SQL Server、Symfoware	http://www.insight-tec.com/products/service_piso.html
SecureSphere	アークン、NTTデータ・セキュリティ、日立システムアンドサービス、ネットワークバリューコンポネンツ、三菱総研DCSなど	DB2、Informix、Oracle、SQL Server、Sybase	http://www.imperva.com/products/gateway.html
SQL Guard	エアー	DB2、Informix、Oracle、SQL Server、Sybase	http://www.air.co.jp/products/sql_guard/sql.html
SSDB監査	システムエグゼ	SQL Server 2000／2005	http://www.system-exe.com/ssdb/ssdb.html

DB監査ツール「IPLocks」のユーザービヘイビア監査機能。DBへのアクセス記録から違反アクセスを検出、監査時の証左として活用できる《クリックで拡大》

されどログは万能にあらず

　とはいえ、DBに脆弱性が存在した場合、ログを取得しても攻撃自体を防げるものではないということを忘れてはいけない。また、アカウントが複数の担当者間で共有されていたら攻撃者を特定することは不可能だ。従って、ログを取得するからには、DB管理者や運用担当者を識別できるようなDBアカウントを用意し、各アカウントの権限最小化を図るのは必須である。

最後の“とりで”、データ暗号化

　一部のDBMS製品を除いて、DB管理者に対して、DB内部のデータを権限上参照できなくしてしまうことは不可能である。ただし、通常の管理業務ではデータの中身を参照することはほとんどないといってもよいはずだ。従って、管理者や運用担当者、あるいは不意にDBに不正アクセスをしてきたものがデータに対する権限を何らかの形で得た場合に、最後の防御手段となるのが「データの暗号化」だ。

　1つ気を付けておかなければならないのは、データ暗号化といっても、透過的暗号化（※2）の機能では、先に説明したようなケースには一切役立たないということ。まさに透過的に攻撃者にデータを復号されて閲覧されてしまうからだ。透過的暗号化の機能そのものを否定しているわけではないが、この機能を実装することで低減できるリスクはデータファイルやバックアップファイルの盗難などであり、DBにログインされるたぐいの攻撃には効果がないことを忘れないでほしい。

※2　DB上でクレジットカード番号などの機密データの暗号化や暗号化鍵の管理を可能にする技術

　データの暗号化は、攻撃者が暗号鍵に触れられない場所で管理する方式で実施しないと意味がない。となると、アプリケーションかミドルウェアによる暗号化となるだろう。アプリケーションによって、データを格納する際に暗号化し、取り出してきたデータを画面に表示する直前に復号するのが一般的であり、大抵のDBMSやプログラム言語には暗号ライブラリが存在する。

　ここでも、ログ取得の項で述べたように、まずはデータに対する十分なアクセス制御を実施しておくことが肝要だ。データの暗号化はDBサーバへの負荷も掛かるし、場合によってはインデックスを作成できずシステムのパフォーマンスを下げる要因にもなる。また、既に動作中のシステムに適用するとなると、アプリケーションの改修も必要になるだろう。

　SQLインジェクションにより侵入してくる攻撃者あるいは内部関係者は、現状の無防備なままのDBなら、その気になればデータ破壊やシステム破壊などで、完全性、可用性に大きな影響を与えることができてしまう。攻撃者の関心がデータそのものにあるうちに、最悪の事態を招くことのないよう、きちんと手を打っておこう。

＜筆者紹介＞

大野祐一

ラック サイバーリスク総合研究所 データベースセキュリティ研究所 所長、CISSP

約10年間にわたり、情報系システム開発部門にてクライアント／サーバシステム、Webアプリケーション開発業務を経て、2004年からデータベースに対する脅威・脆弱性およびそれらに対する防御手法の研究、啓発活動に従事。著書に『最新!!データベース不正アクセスレポート』（SRC出版）がある。

関連ホワイトペーパー

不正アクセス | データベース | SQL | セキュリティ対策 | 脆弱性