【要約】Oracle Autonomous Database の SQL Firewall を試してみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
アプリケーションサーバーが攻撃者に乗っ取られた際、正規の接続情報を悪用してデータベースへ不正な操作を行うリスクがある。これにより、本来の業務範囲を超えたデータ窃取や権限昇格が行われる懸念がある。
- ・
SELECT *による機微なテーブルの全件取得。 - ・データ辞書の探索によるデータベース構造の特定。
- ・
UNIONを用いたクエリの改変や、GRANT文による権限昇格の試行。
// Approach
筆者は、Oracle Autonomous Database 26ai の SQL Firewall を用い、防御能力を検証した。Data Safe を管理経路として使用し、以下の手順で検証を行った。
- ・Data Safe で SQL Firewall を有効化し、正規の業務クエリを学習させる。
- ・SQL 署名（構造）と接続コンテキスト（IP、プログラム名等）の 2 軸でポリシーを生成する。
- ・許可リストに対し、不正な SQL や別プログラムからの接続を試行し、遮断の成否を確認する。
// Result
検証の結果、SQL Firewall は構造の異なる操作を効果的に遮断できることが判明した。
- ・
SELECT *やUNIONを用いた改変、GRANT文などはORA-47605でブロックされた。 - ・許可外のプログラムからの接続は、SQL 実行前の接続時点で遮断された。
- ・一方で、許可済みクエリの bind 値を変更してデータを順次取得する操作は防げない。
Senior Engineer Insight
> 本機能は「完全防御」ではなく「被害範囲（blast radius）の限定」と捉えるべきだ。SQL 構造は守れるが、bind 値による値レベルの持ち出しは防げない。実戦投入時は、最小権限、VPD、Data Redaction と組み合わせた多層防御の設計が不可欠である。また、学習時のノイズ管理と、可用性を考慮した「監視モード」から「ブロックモード」への段階的な移行プロセスが運用の鍵となる。