製品ハイライト｜Anweisi データベース監査 - バインディング変数監査

機能紹介データセキュリティ管理エキスパート - コアデータを保護し、ネットワークセキュリティを防御します。頑張っております！こちらでは、最新の安全情報、安全知識、解決策などを提供していきますので、お楽しみに！

近年、関連法規の改善、国家の段階的保護要求、業界リスク管理および内部統制指標の導入に伴い、セキュリティ監査製品は徐々に一般に知られるようになりました。近年、データ盗難やデータ漏洩といったリスクの高いインシデントが多発しており、大手企業や団体ではデータセキュリティへの注目が高まっています。データベース監査は、ユーザーデータのセキュリティを保護する製品です。

前回のデータベース監査機能では、双方向監査について詳しく説明しました。今日は、バインド変数の監査についてお話します。

では、バインド変数とは何でしょうか?

まず、次の図に示すように、SQL ステートメントの解析プロセスを見てみましょう。

サーバー プロセスは、SQL ステートメントを受信すると、まず共有プール内に以前に解析された同一の SQL ステートメントがあるかどうかを確認します。そうであれば、共有プールのキャッシュライブラリから前回の解析で生成された実行プランを見つけて、直接実行します。 SQL ステートメントを再度解析する必要がなく、実行段階に直接ジャンプします。この種の解析はソフト解析と呼ばれます。

対応する実行プランが共有プールのライブラリ キャッシュに見つからない場合は、SQL を解析して実行プランを生成する必要があります。このタイプの解析はハード解析と呼ばれます。

解析プロセスをさらに簡略化すると、次の図が得られます。

ハード解析には多くのデータ操作が含まれ、多くの CPU リソースが消費されます。たとえば、次の 2 つのステートメントでは、2 つの完全なハード解析を個別に実行する必要があります。

userid = 'N0001' の場合、userinfo から * を選択します。

userid = 'N0002' の場合、userinfo から * を選択します。

しかし、バインド変数を使用して実行する場合は、

id= :1 の userinfo から * を選択します。

:1 をそれぞれ 100 と 200 にするために、データベースは解析時にプレースホルダーを使用し、実行のために値を渡します。この方法では、必要なハード解析は 1 回のみで、2 つの SQL ステートメントは同じ実行プランを再利用するため、ハード解析のリソース オーバーヘッドが節約されます。

ステートメントが何度も繰り返し実行されると仮定すると、バインド変数を使用する利点は非常に大きくなります。リソースを大幅に節約し、速度を向上させることができます。そのため、これは重要なパフォーマンス最適化手法であり、パフォーマンス要件のあるシステムで広く使用されています。

データベース監査への影響

バインド変数を使用しているため、従来の監査では、特定の値ではなく変数文字を含む SQL のみを監査できるため、情報の損失が発生します。

たとえば、次のステートメントを実行します。

userid=:1 の userinfo から * を選択します。 1:='N0006';

従来の監査ログには、次のステートメントのみが記録されます。

name=:1 の userinfo から * を選択します。

これにより、次のような結果が生じます。

（１）監査ログ内のクエリ条件の特定の値を検索すると、不正確な検索結果が返されます。

（２）正しいSQL文を監査できない。

完全復元

漏れがないことは、データベース監査システムをテストするための基本的な標準です。包括的かつ正確な監査を取得したい場合は、バインドされた変数を監査する機能が不可欠です。私たちはこの小さな詳細を無視していません。当社の監査機能は、バインドされた変数の特定の値を非常に早い段階で監査し、SQL を欠落させることなく完全なステートメントに復元できます。

データベースは、さまざまなソフトウェア アプリケーション システムのインフラストラクチャです。システムがデータベースにアクセスするために使用する SQL は常に変化しています。包括的かつ正確な監査を実現するには、監査の触手がデータベース アクセスの隅々まで確実に届くように、分析と研究開発を継続的にフォローアップする必要があります。