データベース・セキュリティの実装　第4回　最前線の防御を可能にするOracle Database Firewall

最終回は、今年に新たにデータベース・セキュリティ製品に加わったOracle Database Firewallについて取り上げよう。Firewallという名がつくことから、何となく機能のイメージはできるかもしれないが、このOracle Database Firewallは、今までのデータベース関連の製品とは毛色の違う、非常に面白い製品である。しかしながら、その中身は質実剛健のごとく的を射たものであり、その代表的な機能について触れていきたい。

■SQLインジェクション
　その前に、やはりSQLインジェクションについて説明が必要かもしれない。SQLインジェクション攻撃は以前から存在してはいたが、特に2005年頃から猛威を振いはじめ、2010年もその衰えは見せてはいない。Gumblar（ガンブラー）と並ぶウェブサイトを経由した攻撃の2大トレンドといってもよいだろう。「SQLインジェクション」と検索すれば、もっと詳細な情報のサイトにたどり着くことはできると思うが、念のためこのSQLインジェクションの仕組みを簡単に説明すると、

　商品検索のWEBサイトがあったとしよう。アプリケーションは、製品を検索する画面なので当然、商品名や商品コードなどの文字が入ってくるものだという前提で作成されている。そこで、上記のようなSQLを入れてみて検索したらどうだろう。すると、本来実行されるべきSQLを強制的に書き換え、顧客情報を検索するSQLを注入(インジェクト)されてしまった。これが、SQLインジェクションである。通常のWEBサイトへのHTTPアクセスからSQLを操作し、任意のSQLを実行し、データの搾取や改ざんを行うことができてしまうのだ。実際にサイト改ざんやクレジットカード情報を含む個人情報を抜き取られてしまった事件が多く発生している。
　このSQLインジェクション攻撃が成功するには、以下の二つの条件を満たす必要がある。

　上記の例の場合、アプリケーションには致命的な脆弱性がある。SQLの組み立て方に問題があるのだ。最も基本的な例を見てみよう。

　SELECT 列1, 列2, 列3 FROM 製品情報 WHERE NAME = ' + 検索フォーム文字 + "'"
　というように単純にユーザーの入力した値を文字列連結してSQLを組み立てている。

　ユーザーは必ずしも期待した文字列を入力してくれるわけでないので、この検索フォーム文字に' UNION SELECT列1, 列2, 列3 FROM 顧客情報 - と入力されたとすると、

　SELECT列1, 列2, 列3 FROM 製品情報 WHERE NAME = '' UNION SELECT列1, 列2, 列3 from 顧客情報 -- '

　製品情報表を検索しているSELECT分に、顧客情報表を検索するSQLがUNION ALLによってくっつけられてしまい、SQLが成立し実行されてしまうのである。(※データベースの種類によって攻撃が成功するSQLは異なる)。これは、あくまでも一例であって攻撃方法は多種多様に存在する。WEBサイトにインジェクション可能な入口が見つかれば、そこから様々なSQLを注入しながらデータ・ディクショナリの情報を検索し、クレジットカード情報や個人情報などの換金性の高い情報が入っている表を探り当てられてしまうかもしれない。また、攻撃者はWEBサイトを一つ一つ攻撃をしているわけでなく、自動化されたツールを使って世界中のWEBサイトをランダムにアクセスし、攻撃可能なWEBサイトの目星をつけてからより詳細な攻撃が行われる。ツールさえ手に入れば、だれにでも実現できてしまうことが被害の増加を招いていると言えよう。

　このようなSQLインジェクションの対策は、アプリケーションの脆弱性をなくすことである。

　SQLにとって特別な意味を持つ記号(メタ文字)が含まれていないかをチェックすること、これは、ユーザーが入力した値を判別して排除するようにするエスケープ処理が当てはまる。(※Oracle Databaseには入力値を検証するDBMS_ASSERTパッケージが用意されている)。しかし、メタ文字はデータベースによって異なる場合があり、チェックが漏れる可能性は否定できない。

　抜本的な対策としては、静的プレースホルダ(prepared Statement)を使用することである。バインド変数を使うといったほうが分かりやすいかもしれない。

　例えば、SELECT * FROM PRODUCTS WHERE NAME = ' + バインﾄﾞ値 + "'"

　バインド変数とは、上記のようなSQLを予めデータベース側に用意をしておき、SQLの実行する段階でバインド値を送信することである。

　仮に、上記のSQLインジェクションを目的とした不正なSQLをバインド値に入れたとしても、SQLの文法上正しくないので、攻撃として成立しない。バインド変数はSQLの解析が最小化されることからSQLの再利用性が高くなりパフォーマンス向上のメリットが大きくなることが良く知られているが、セキュリティの面からも大きな恩恵を受けることができる。IPAに「安全なSQLの呼び出し方」として公開されている資料があるので、是非参照して欲しい。

■なぜ、SQLインジェクションの対応が遅れるのか？
　SQLインジェクション攻撃に利用されるWEBサイトの脆弱性と対策方法が明らかになっているにも関わらず、なぜいまだその攻撃が主流となっているのか？攻撃方法が進化し複雑になっているというのも理由に挙げられるが、多くのケースはWEBサイトを運営する側の対応が間に合っていないということがいえる。ほとんどの企業ではB to B、B to C向けのWEBサイトを持っており、そのサイトのページ数は数千から数万ページに上っている。そのサイトは最近構築したものもあれば、数年前に構築したものもある。日々、WEBサイトが構築、更新されている中で、すべてのWEBサイトを等しいレベルでセキュアに管理、維持できているかというと疑問が残るのは事実だろう。それら全てのページを確実にチェックし、セキュアな状態を維持するためには相当のコストがかかるのである。

　そして対策が漏れてしまった脆弱なWEBサイトを日々、SQLインジェクションのツールが虎視眈々と探し回っているのだ。

■Oracle Database Firewallの登場
　SQLインジェクション攻撃はアプリケーションのコーディングの問題であり、今までオラクルでは、データベース側で対策としてできることは非常に限られていた。バインド変数やDBMS_ASSERTの使用を進めることぐらいしかできなかった。

　しかし、2011年Oracle Database Firewallというデータベース・セキュリティに新しい製品が加わったことにより、新たな対策の手段が増えたのである。このOracle Database Firewallはその名の通り、Firewallである。アプリケーションとデータベース間は、SQLを使用してデータのやり取りを行うが、このSQLに対して通過の許可・不許可のポリシーを設定することができる。

　Oracle Database Firewallは、アプリケーションとデータベース間のネットワーク上に配置し、ネットワークトラフィックをキャプチャし、その中に含まれるSQLに対してポリシーを設定することができる。機能としては、ブロッキング、モニタリングの2つの機能に大別される。ブロッキングは、SQL単位にPass、Blockの設定を行うことができ、SQLインジェクションのような外部からの不正アクセス、開発者や管理者といった内部からの不必要なアクセスを遮断することができる。モニタリングは、データベースへのすべてのSQLをキャプチャして記録し、ログ分析やレポーティング、不正なアクセスがあった場合のリアルタイムアラートなどを実現する。そして、この二つの機能が両輪となって、SQLインジェクションからの攻撃を防ぐ。つまり、脆弱なアプリケーションから組み立てられたSQLをOracle Database Firewallで的確にブロックすればデータベースへはSQLが届かない。脆弱なWEBサイトのパッチとしてOracle Database Firewallがデータベースを保護するのである。対象となるデータベースは、Oracle Databaseだけでなく、SQL Server、DB2、Sybase等に対応している。
　では、どういった仕組みで動作するのか、そのアーキテクチャをご紹介しよう。

■ソフトウェア・ブリッジ
　Oracle Database Firewallをインストールするサーバには、最低3つのポートが必要だ。1つは管理用のポートとして使用するが、残り2つのポートで1つのネットワーク・ブリッジを構成する。ブリッジの設定はインストールの際に自動的に構成されるが、このブリッジ上が流れるすべてのネットワークトラフィックがOracle Database Firewallによって監視され、ポリシーの設定に応じてブロックされる。これはインライン方式という構成になる。アプリケーションとデータベース間に直列に配置されるイメージとなり2つのポートは、アプリケーション、データベースのそれぞれに接続される。

　ブロッキングを行う際には、必ずインラインの方式が必要になるが、モニタリングのみの使用も可能である。その場合は、以下のようスイッチと並列に配置する。

　この場合は、スイッチのSPANポート(ミラーリングポート)に接続し、そのポート経由でネットワークトラフィックに流れるすべてのSQLを受信し記録する。1つのブリッジでは1つのサブネットに対応しており、Oracle Database Firewallでは最大8ポートまでサポートしているので、複数の異なるサブネットを1台で対応することが可能である。

　さて、気になるOracle Database Firewallのトランザクションへの影響だが、ブロッキング用途であるインライン方式で1SQLあたりマイクロ秒の値程度のオーバーヘッド、モニタリング用途であるアウトオブバンド方式だとオーバーヘッドはない。ブロッキング、モニタリングを両立しても20万SQL/秒というハイパフォーマンスを実現している。

■正確な検知の重要性
　SQLをBlockする、Passさせるという処理を行うには当然正確に検知して判断する必要がある。IDSやIPSといったネットワークの侵入検知システム、WAF (Web Application Firewall)等 検知して動作するシステムは、その検知の精度がもっとも重要であるが、Database Firewallについても同様である。

　例えば、1秒あたり3000SQL発生した場合、1日 260万SQLが生成される。
　0.001%をフォールスポジティブ(誤検知)すると、7,800件/月のアラートが発生することになり、0.00001%をフォールスネガティブ(検出漏れ)すると、26件/月の不正アクセスの可能性がある。

　誤検知のアラートが月 7,800件ではとても運用が回らず、人為的なミスから本当のアラートが見逃されてしまう可能性が出てくる。つまり、いかにこのフォールスポジティブとフォールスネガティブの比率を下げるか、検知の正確性が使い勝手の差となることは周知の事実である。

■パターンマッチングの限界
　Oracle Database Firewall以外でも、SQLをブロックすることができる機能をもっている製品がある。ただこれらの製品はSQLを判別するのにパターンマッチングを使用している。このパターンマッチングは、検知の正確性という点は、大きな欠点がある。

　パターンマッチングは、正規表現などで特定の文字列を見つけることだが、SQLインジェクションでは、よくTRUEとなる条件やUNIONを使ったSQLが使われることが多い。

　例えば、TRUEが成り立つ条件として、簡単に思いつくのは1=1だが、20000=(1000+19000), 'dog'='dog', LEFT('catastrophe', 3)='cat', SIN(45) = COS(45) , CAST(123) as STR <> 123、これらもすべてTRUEとなる条件である。uni/* */on, char(117,110,105,111,110)、これらはUNIONの文字を別な表記で表している。このように、パターンマッチングで検知させるすべての文字列を漏れなく網羅することは不可能に近い。つまり、これは検知の精度が低下し、フォールスポジティブやフォールスネガティブが増加することを意味しているのである。

■SQL文法を理解した正確な検知
　そもそもSQLには、約400のキーワードや厳格な文法のルール(ISO/IEC 9075)が定義されている。Oracle Database Firewallは、パターンマッチングではなくそれらの定義されているSQL文法を理解した上での検知を行っている。

　上記のSQLを見てみると、UPDATEやWHEREというキーワード、スキーマ、データ、演算子といくつかのカテゴリに分離することができる。この例では、DATAの中に文字列としてselect や演算子等が含まれているが、これらは文法上のDATAに入っておりSQLインジェクションとして成立するSQLにはなりえない。パターンマッチングだと誤検知してしまう可能性があるSQLでも、Oracle Database Firewallは、Oracle Database, SQL Server, DB2といったそれぞれのデータベースごとの高精度のSQL文法解析エンジンを搭載しており、正確にSQL文法構造を理解し、検知することを可能なのである。

■Oracle Database FirewallによるSQLブロック
　では実際にOracle Database FirewallによってSQLインジェクションのSQLをブロックするとどうなるのか見ていきたい。実際に良く使用されるUnion Selectで組み立てたSQLを実行する。詳しい解説は控えるが、これはOracle DatabaseのサンプルスキーマであるSHユーザーのPRODUCTS表を検索しているSQLに、user_tables表が検索するSQLを注入したものである。

　SELECT null,null,null,null,null,prod_name FROM PRODUCTS WHERE 1=2 union select null,table_name,null,null,null,null from user_tables

　Oracle Database Firewallのポリシーの設定は、ホワイトリスト方式。これはデフォルトブロックを意味しており、Passの登録されていないSQLはすべてブロックされる。当然上記のSQLインジェクションのSQLは許可されていないのでBlockされる。

　右側にAction codeとあるが、緑色がPassしたSQL、赤色がBlockしたSQLである。SQLが実行された時間、クライアント情報、ユーザー名、データベースの情報等、ログとして必要な情報はすべて記録される。Blockした情報をリアルタイムアラートとしてメール送信することや、ネットワーク機器の監視サーバがある場合にそのサーバへのsyslog配信など随時、管理者へ情報発信をすることができる。

■Oracle Database Analyzerによるポリシーの作成
　実際にポリシーを作成するとなると、大変なイメージを持たれるかもしれないが、意外にそれほどでもない。ポリシーの設定は、Oracle Database Analyzerによって設定する。これは、Windowsにインストールするクライアントアプリケーションである。

　通常、Oracle Database Firewallを使用する際には、一定の学習期間が必要である。これは通常流れているSQLをキャプチャし続けることで、ポリシーを設定するための基礎となるSQLを一括して取得することが目的である。学習期間後は、SQL個々にPass, Block, Warnといったブロッキングのポリシーと、ロギングの設定を行う。構文が同じSQLはクラスタというグループにまとめられるので、クラスタ単位での一括した定義も行うことができる。

　例えば、単純にホワイトリストのポリシーを作成する場合は、デフォルトをBlock、通過させたいSQLをPassにするのだが、そのSQLは学習期間で取得したSQLから選べば良い。または、テキストファイルから一括してローディングすることも可能だ。ポリシーは、ユーザやIPアドレス、プログラム名といった単位でプロファイル化して、いくつかのパターンで切り替わるようにすることもできる。画一的なポリシーの設定ではなく、SQL以外の要素も組み合わせた自由度の高いポリシー設計を行う柔軟性も持っている。

■Oracle Database FirewallによるSQLモニタリング
　ブロッキングについて話を進めてきたが、Oracle Database Firewallをモニタリング用途としての使用も有効である。データベースのセキュリティ要件として、「監査ログを取得すること」と記載のないRFPのほうが珍しいだろう。監査ログはセキュリティの必須要件のひとつだ。第二回で、Oracle Databaseでの監査機能や設計のポイントを述べたが、すでに稼働しているデータベースに対して、新たに監査設定をするというのはパフォーマンスの懸念を考えると躊躇してしまうのは致し方のないことかもしれない。Oracle Databaseでは、10gR2からXML監査という監査設定やファイングレイン監査といった監査の絞り込みによって性能への影響は極小化できる。しかし、それ以前のバージョンのOracle Databaseの監査ログを取得しなければならない時やOracle Database以外のデータベースではまともに監査ログを取ることができないデータベースもある。そのような場合には、Oracle Database Firewallのモニタリング機能が非常に有効になる。

　事例のひとつとして、投資銀行系のデータベースの全トラフィックの監査ログを取得するという要件でOracle Database Firewallが使われている。このシステムでは、1日 1.7億件発生するトランザクションを24時間×365日漏れなく保存するという厳しい要件が定められているが、それらを見事にクリアしている。

　前述に紹介したアウトオブバンド方式の構成であれば、既存のトランザクションへの影響はなく、パフォーマンスを気にする必要はない。さらに、Oracle Database Firewallはログを圧縮して保存している。その圧縮の効果は高く、例えば、Oracle DatabaseのXML監査ログと比較した場合、1,200万レコードの監査ログのサイズは、Oracle DatabaseのXML監ファイルだと8.4GB、Oracle Database Firewallでは172MBと約50分の1のサイズになる。監査ログはどうしても膨大になりがちだが、Oracle Database Firewallではログを保存しておくのに必要となるストレージサイズを縮小することを可能にする。

　また、ネットワークを経由しないサーバに直接ログインした場合もモニタリングを可能にするローカルモニター、サブネットを跨いだモニタリングを可能にするリモートモニター、Oracle Database Firewallの高可用性の構成など、特筆すべき機能がまだまだあるが文字数の都合上ここまでとしよう。より詳しい情報については、以下を参照頂きたい。

• 【セミナー動画/資料】Oracle Database Firewallの全貌をご紹介

　全4回にわたりデータベース・セキュリティの実装ということで、エンジニアの方々が使える情報となるように心掛けて連載を続けてきた。データベースに限らずセキュリティは多層防御が基本的な考え方である。今回、紹介したOracle Database Firewallは最も最前線でデータベースを保護し、アクセス制御、監査、そして最後の砦として暗号化やマスキングが保険的な役割を果たす。是非、これらの要素をうまく組み合わせてシステムに合わせた最適なセキュリティを構築して頂きたい。

　今回の取り上げた内容が少しでもデータベース・セキュリティを実装する際のヒントになることを願い、本連載を終了することにする。