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