13 SQLファイアウォールの使用

Oracle Databaseに含まれるSQLファイアウォールは、すべての受信SQL文を検査し、明示的に認可されたSQLのみが実行されるようにします。

13.1 SQLファイアウォールの概要

SQLファイアウォールの使用を開始する前に、その仕組みおよび使用するための権限を理解する必要があります。

13.1.1 SQLファイアウォールについて

SQLファイアウォールは、指定されたユーザーに対して認可されたSQL文または接続にのみデータベース・アクセスを制限することで、一般的なデータベース攻撃に対するリアルタイムの保護を提供します。

SQLインジェクション攻撃、異常なアクセス、資格証明の盗難または不正使用によるリスクを軽減し、潜在的なSQLインジェクション攻撃を防止または検出します。

SQLファイアウォールを使用すると、一般的なアプリケーション・ユーザーが実行するSQL文の許可リスト(つまり、許可されるアクション)をデータベース・ユーザーごとに作成し、予期しないSQLを検出してブロックし、ログに記録できます。

SQLファイアウォールを使用して、データベースで処理できるSQL文を制御できます。データベース接続およびSQL文に関連付けられた接続パスを制限できます。また、SQLファイアウォールでは、IPアドレスなどのセッション・コンテキスト・データを使用してデータベース接続を制限できます。認可されていないSQLを記録してブロックできます。

SQLファイアウォールは、認可されたSQL文または接続にのみデータベース・ユーザー・アクセスを制限することで、一般的なデータベース攻撃に対するリアルタイムの保護を提供します。SQLインジェクション攻撃、異常なアクセス、資格証明の盗難または不正使用によるリスクを軽減し、潜在的なSQLインジェクション攻撃を防止または検出します。SQLファイアウォールはOracleデータベースに組み込まれているため、バイパスできないようになっています。ローカル・テキストかネットワーク・テキストか、暗号化テキストかクリア・テキストかに関係なく、すべてのSQL文が検査されます。最上位のSQL、ストアド・プロシージャおよび関連するデータベース・オブジェクトが調査されます。

SQLファイアウォール・ポリシーは、アプリケーション・サービス・アカウントであっても、レポート・ユーザーやデータベース管理者などの直接データベース・ユーザーのいずれであっても、データベース・アカウント・レベルで機能します。つまり、データベース・ユーザーHRにSQLファイアウォール・ポリシーが1つ、データベース・ユーザーJOEにSQLファイアウォール・ポリシーが1つある可能性があります。この柔軟性により、データベース管理者またはアプリケーション・サービス・アカウントのいずれかから、データベースの保護レベルを段階的に構築できます。

SQLファイアウォールは、IPアドレス、オペレーティング・システムのユーザー名、オペレーティング・システム・プログラム名などのセッション・コンテキスト・データを使用して、データベース・アカウントがデータベースに接続する方法を制限します。これにより、アプリケーション・サービス・アカウント資格証明の盗難または誤用のリスクを軽減できます。SQLファイアウォールの一般的なユースケースは、アプリケーションのワークロードに関するものです。

SQLファイアウォールは、ルートとプラガブル・データベース(PDB)の両方で使用できます。SQLファイアウォールは、オンプレミス、クラウド、マルチテナント、Oracle Data Guard、Oracle Real Application Clustersなど、すべてのOracle Databaseデプロイメントに対してシンプルで使いやすいファイアウォール・ソリューションです。SQLファイアウォールは、Oracle、Transparent Data Encryption (TDE)、データベース監査、Oracle Database Vaultなどの他のOracle Databaseセキュリティ機能と連携して動作します。

SQLファイアウォールは、トランザクション制御コマンド(SAVEPOINTCOMMITおよびROLLBACK)を除くすべてのSQLコマンド(つまり、取得および強制)をサポートします。また、SQLファイアウォールでは、SQL*PlusコマンドPASSWORDおよびDESCRIBEと、データベース・リンクを介したリモート・プロシージャ・コール(RPC)がサポートされています。

次の図は、SQLファイアウォール・プロセスの仕組みを示しています。

図13-1 SQLファイアウォール・プロセス

図13-1の説明が続きます
「図13-1 SQLファイアウォール・プロセス」の説明
  1. ユーザーがWebアプリケーションを介してOracleデータベースにログインします。
  2. ユーザーはSQL文を実行し、Oracleデータベースへのインバウンド・トラフィックを作成します。
  3. クラウドとオンプレミスの両方のデプロイメントの場合、SQLファイアウォールは、次の文に対して構成されている認可に基づいてSQL文を処理します。
    • その後の実行でSQLを許可します。
    • SQLを許可し、ログに記録します。
    • 認可されないSQLをログに記録し、必要に応じてブロックします。

13.1.2 SQLファイアウォールの使用のための一般的なプロセス

SQLファイアウォールを使用するには、ユーザーのSQLアクティビティを取得し、取得したログを確認し、許可リストを生成してそれを有効化し、あらゆる違反に関する違反ログを監視する必要があります。

次の図は、認可されたSQL文およびデータベース接続を学習し、各アプリケーション・ユーザーの保護を有効にするようにSQLファイアウォールを構成する方法を示しています。

図13-2 SQLファイアウォール・プロセス・フロー

図13-2の説明が続きます
「図13-2 SQLファイアウォール・プロセス・フロー」の説明
  1. ユーザーのSQLアクティビティの取得: 学習ステージでは、アプリケーション・ユーザーが発行するすべての認可SQL文を取得して収集します。
  2. 取得の確認: ユーザーのSQL文を収集した後、SQLファイアウォール固有のデータ・ディクショナリ・ビューを問い合せて、取得したこのデータを確認できます。このステップでは、取得がニーズに適しているかどうかを判断できます。
  3. 許可リストの生成: 取得を確認した後、学習ステージで取得するSQL文およびデータベース接続コンテキストから許可リストを生成できます。許可リスト・ルールは、次の2種類のリストで構成されます。
    • 許可されたSQLリスト: 一定の基準を満たした場合にユーザーに実行を許可するSQL文です。たとえば、hr_managerアプリケーション・ユーザーからHR.EMPLOYEES表への想定されるSQL問合せを、許可されたSQLリストに含めることができます。実行時に、SQLファイアウォールがデータベースで適用されると、現在のSQL文とその実行状態(現行ユーザーIDと、SQLがトップ・レベルである(ユーザーが直接実行している)かどうか)が、許可されたSQLリスト内のSQL文とその実行コンテキストと一致するかどうかチェックされます。SQLファイアウォールは、許可されたSQLリストにない予期しないSQLを検出してブロックし、ログに記録します。
    • 許可されたコンテキスト・リスト: データベース接続を制御します。ユーザーがOracle Databaseに接続すると、SQLファイアウォールは接続を許可する前に、現在のセッション・コンテキスト(クライアントIPアドレス、オペレーティング・システム・ユーザー名またはオペレーティング・システム・プログラム名のいずれか)をチェックし、それが許可されたコンテキスト・リストの値と一致することを確認します。

    許可リストを確認し、DBMS_SQL_FIREWALL.ADD_ALLOWED_CONTEXTDBMS_SQL_FIREWALL.DELETE_ALLOWED_CONTEXT、および DBMS_SQL_FIREWALL.DELETE_ALLOWED_SQLプロシージャを使用して必要な調整を加えます。

  4. 許可リストの有効化: 保護ステージでは、生成後の許可リストをユーザーに対して有効にできます。このステップでは、SQLインジェクション攻撃を検出して保護するために、このユーザーのすべてのデータベース接続に対して許可リストのチェックを実施します。

    SQLファイアウォールが有効になっているユーザーがデータベースと対話すると、許可リストの定義と一致しないアクションはすべてSQLファイアウォール違反とみなされ、違反ログに書き込まれます。SQLファイアウォールでは、アプリケーション・ユーザーによるアクションの実行をログに記録し、場合によってはブロックできます。たとえば、次のアクションが実行されると、SQLファイアウォール違反が発生します。

    • ユーザーの現在のSQL文が、許可されたSQLリストのSQL文と一致しない。
    • ユーザーの現在のセッションIPアドレスが、許可されたコンテキスト・リストのIPアドレスと一致しない。

    次の2つのソースからDBMS_SQL_FIREWALL.APPEND_ALLOW_LISTプロシージャを使用して、いつでも既存の許可リストに追加できます。

    • 違反ログ: DBA_SQL_FIREWALL_VIOLATIONS
    • 取得ログ: DBA_SQL_FIREWALL_CAPTURE_LOGS
  5. 違反の監視: SQLファイアウォールにより、予期しないアクセス・パターンに関する違反が発生します。SQLファイアウォールから、異常なアクセス・パターンや不正なSQLをユーザーが検出するように要求された違反がないか、DBA_SQL_FIREWALL_VIOLATIONSデータ・ディクショナリ・ビューを問い合せます。

次のことに注意してください。

  • Oracle Databaseは、すべてのSQLファイアウォール管理アクションを強制的に監査し、それらを統合監査証跡データ・ディクショナリ・ビューUNIFIED_AUDIT_TRAILに書き込みます。統合監査ポリシーを作成して、SQLファイアウォール違反をモニターすることもできます。SQLファイアウォールをモニターおよびトラブルシューティングするもう1つの方法は、SQL_FIREWALLトレース・ファイル設定を使用することです。
  • 既存の許可リストを含め、SQLファイアウォール・メタデータをエクスポートおよびインポートするには、Oracle Data PumpのEXPDBおよびIMPDBユーティリティを使用します。
  • 通常のSQLファイアウォール管理タスクの一環としてDBMS_SQL_FIREWALL.PURGE_LOGプロシージャを使用して、違反ログを定期的に監視してパージすることをお薦めします。十分にトレーニングされた環境では、違反ログは大量にはならないと考えられます。
  • SQLファイアウォールは、ユーザーが発行するSQL文を直接、またはユーザーがターゲット・ユーザーのセッションで起動するPL/SQLユニットから取得します。
  • SQLファイアウォールは、正常に実行されたSQL文のみを取得します。つまり、SQL文がエラーのために実行に失敗した場合、それに対応する文はSQLファイアウォールでは取得できません。
  • SQLファイアウォールは、内部の問合せ変換(ビューまたはマクロの展開や、Oracle Virtual Private Database (VPD)ポリシーの適用など)が実行される前にSQL文を取得します。
  • SQLファイアウォールは、取得したSQL文を正規化し、リテラル値を特別な記号で置き換えてからログ表に格納します。
  • セッション・コンテキスト属性(クライアントIPアドレス、OSユーザー名およびOSプログラム名)は、セッションの作成時に1回のみチェックされます。
  • 許可リストが有効になる前に作成された既存のセッションの場合、SQLファイアウォールでは許可されたコンテキストもチェックされますが、セッション・コンテキストが一致しない場合でも既存のセッションは終了されません。この場合、SQLファイアウォールは違反のログを記録しません。

13.1.3 SQLファイアウォールを構成および使用するための権限

SQLファイアウォールを管理したり、SQLファイアウォールに関連付けられたビューを問い合せるには、適切なロールが付与されている必要があります。

SQLファイアウォールを管理するには、SQL_FIREWALL_ADMINロールが付与されている必要があります。このロールは、次の権限を提供します。

  • ADMINISTER SQL FIREWALLシステム権限: DBMS_SQL_FIREWALLパッケージのPL/SQLプロシージャを実行するのに必要です
  • EXECUTE権限: DBMS_SQL_FIREWALL PL/SQLパッケージ用
  • READ権限: SQLファイアウォールDBA_SQL_FIREWALL_*データ・ディクショナリ・ビュー用

DBA_SQL_FIREWALL_*データ・ディクショナリ・ビューを問い合せる(ただし、SQLファイアウォールを管理しない)には、ユーザーにSQL_FIREWALL_VIEWERロールが付与されている必要があります。

ノート:

SQLファイアウォールSQL_FIREWALL_ADMINおよびSQL_FIREWALL_VIEWERロールは強力なロールです。これらのロールは、信頼できるユーザーにのみ付与します。

13.1.4 SQLファイアウォールのサンプル・スクリプトおよびビデオ

Oracleでは、SQLファイアウォール使用のサンプル・スクリプトと、SQLファイアウォールの仕組みを説明するビデオを提供しています。

次の資料も参照してください。

13.2 SQLファイアウォールの構成

DBMS_SQL_FIREWALLパッケージを使用してOracleデータベースにSQLファイアウォールを構成することも、Oracle Data Safeに構成することもできます。

13.2.1 SQLファイアウォールの構成について

Oracle Data SafeまたはDBMS_SQL_FIREWALLパッケージを使用してSQLファイアウォールを構成するどちらの方法にも、SQLファイアウォールの使用方法に応じた利点があります。

  • 複数のSQLファイアウォールの一元的な管理: 複数のSQLファイアウォールを一元的に管理する場合は、Data Safeユーザー・インタフェースを使用できます。さらに自動化と統合するために、Data Safe REST API、ソフトウェア開発者キット(SDK)、CLIおよびTerraformを使用できます。また、より広範なOracle Cloud Infrastructure (OCI)エコシステムを使用して、SQLファイアウォール違反をアラートおよび通知と統合することもできます。
  • 個々のOracle Databaseインスタンス内のSQLファイアウォールの管理: 個々のOracle Databaseインスタンス内のSQLファイアウォールを管理するには、DBMS_SQL_FIREWALLパッケージのPL/SQLプロシージャを使用します。

13.2.2 Oracle Data Safeを使用したSQLファイアウォールの構成および管理

Oracle Cloud上のOracle Data Safeを使用すると、複数のSQLファイアウォールを一元的に管理し、Oracleデータベースのフリート全体にわたるSQLファイアウォール違反の包括的なビューを取得できます。

SQLファイアウォール管理者は、Data Safeを使用して、関連するデータベース接続パス(IPアドレス、OSプログラム、OSユーザー)を持つデータベース・ユーザーのSQLアクティビティを収集し、収集の進行状況を監視できます。Data Safeを使用すると、収集されたSQLトラフィックからSQLファイアウォール・ポリシーを生成および有効化できます。Data Safeでは、違反ログが自動的に収集され、コンソールからSQLファイアウォール違反を監視できます。

次の図は、Data Safe内のSQLファイアウォール・ダッシュボードを示しています。

図13-3 Data Safe内のSQLファイアウォール・ダッシュボード

図13-3の説明が続きます
「図13-3 Data Safe内のSQLファイアウォール・ダッシュボード」の説明

ダッシュボードの違反サマリーは、選択した期間にSQLファイアウォールが有効になっているコンパートメント内のすべてのターゲットからのSQLファイアウォール違反の包括的なビューを提供します。ここから、違反にドリルダウンして詳細な分析を実行できます。

13.2.3 DBMS_SQL_FIREWALLパッケージを使用したSQLファイアウォールの構成および管理

ターゲット・ユーザーに対してSQLファイアウォールを構成した後、構成の変更、古いログのパージ、エラーのトラブルシューティングなどのメンテナンス・タスクを実行できます。

13.2.3.1 DBMS_SQL_FIREWALLパッケージを使用したSQLファイアウォールの構成

SQL_FIREWALL_ADMINロールを持っているユーザーは、DBMS_SQL_FIREWALL PL/SQLパッケージを使用して、ルートまたはプラガブル・データベース(PDB)でSQLファイアウォールを構成できます。

  1. SQL_FIREWALL_ADMINロールが付与されているユーザーとしてルートまたはPDBに接続します。
  2. SQLファイアウォールを有効にします。
    EXEC DBMS_SQL_FIREWALL.ENABLE;
  3. 指定されたユーザーのSQLファイアウォール・キャプチャを作成して有効にすることで、SQLファイアウォールをトレーニングします。
    この手順の例では、ユーザーがAPPという名前のPDBユーザーであることを前提としています。次に例を示します。
    BEGIN
      DBMS_SQL_FIREWALL.CREATE_CAPTURE (
        username         => 'APP',
        top_level_only   => TRUE,
        start_capture    => TRUE
      );
    END;
    /

    詳細は、次のとおりです。

    • usernameは、SQLファイアウォールが監視するアプリケーション・ユーザーの名前です。各ユーザーに対して作成できるキャプチャは1つのみです。SQLファイアウォールは、SYSSYSDGSYSBACKUPSYSRACSYSKMDVSYSLBACSYSまたはAUDSYSユーザーを取得するようには作成できません。
    • top_level_onlyは、取得されるSQL文のレベルを制御します。
      • TRUEは、トップレベルのSQL文、つまりユーザーが直接実行する文についてのみ取得ログを生成します。
      • FALSEは、トップレベルのSQL文とPL/SQLユニットから発行されたSQLコマンドの両方について取得ログを生成します。デフォルトはFALSEです。
    • start_captureは、取得が有効になるタイミングを制御します。
      • TRUEを使用すると、SQLファイアウォールでターゲット・ユーザーのアクティビティの取得をすぐに開始できます。デフォルトはTRUEです
      • FALSEは、ユーザーの取得を作成しますが、すぐには取得を開始しません。取得を後で開始する場合は、そのユーザーに対してDBMS_SQL_FIREWALL.START_CAPTUREプロシージャを実行する必要があります。次に例を示します。
        EXEC DBMS_SQL_FIREWALL.START_CAPTURE ('APP');

    この段階で、start_captureTRUEに設定した場合は、信頼できるデータベース接続パスからアプリケーション・アカウントに必要なSQL文を実行します。アプリケーション・ワークロードが変更された場合は、SQLファイアウォールで学習を解除し、最新のSQL文を学習できます。ユーザーがそうでない場合は、取得プロセスを再度開始して、正しいSQL文のみが実行されるようにする必要があります。具体的には、取得プロセスを再起動する場合は、まず、この取得を停止し(開始されている場合)、取得ログをパージしてこの取得を再度開始するか、この取得を削除して取得を再度作成(および開始)する必要があります。

  4. 取得ログおよびセッション・ログを確認して、取得の妥当性を判断します。
    次に例を示します。
    SELECT SQL_TEXT FROM DBA_SQL_FIREWALL_CAPTURE_LOGS WHERE USERNAME = 'APP';
  5. 取得を停止します。
    次に例を示します。
    EXEC DBMS_SQL_FIREWALL.STOP_CAPTURE ('APP');
  6. ユーザーの許可リストを生成します。
    許可リストは、ユーザーに実行を許可するSQL文を定義します。SQLファイアウォールでは、ユーザーの既存の取得ログから収集されたデータに基づいて許可リストが作成されます。

    次に例を示します。

    EXEC DBMS_SQL_FIREWALL.GENERATE_ALLOW_LIST ('APP');
  7. ユーザーが実行できるアクティビティに関する情報を確認するには、DBA_SQL_FIREWALL_ALLOWED_*データ・ディクショナリ・ビューを問い合せます。
    次に例を示します。
    SELECT SQL_TEXT FROM DBA_SQL_FIREWALL_ALLOWED_SQL WHERE USERNAME = 'APP';

    また、ユーザーが使用を許可されているオペレーティング・システム・プログラムの場合は、次のとおりです。

    SELECT OS_PROGRAM FROM DBA_SQL_FIREWALL_ALLOWED_OS_PROG WHERE USERNAME = 'APP';
  8. 必要に応じて、DBMS_SQL_FIREWALL.ADD_ALLOWED_CONTEXTおよびDBMS_SQL_FIREWALL.DELETE_ALLOWED_CONTEXTプロシージャを実行して、許可されたコンテキストのエントリを追加または変更します。
    コンテキストを追加できるのは、許可リストを生成した後のみです。コンテキストでは、クライアントIPアドレス、オペレーティング・システム・ユーザーの名前、またはデータベース接続に使用できるオペレーティング・システム・プログラムを指定できます。コンテキスト値は必要な数だけ追加できます。たとえば、ユーザーの許可されたコンテキスト・リストにIPアドレス192.0.2.1が含まれていないが、許可リストの有効化後に、このIPからユーザーが接続できるようにする場合の例を示します。
    BEGIN
      DBMS_SQL_FIREWALL.ADD_ALLOWED_CONTEXT (
        username       => 'APP',
        context_type   => DBMS_SQL_FIREWALL.IP_ADDRESS,
        value          => '192.0.2.1'
       );
    END;
    /

    特定のcontext_typeについてあらゆる可能性を指定するには、%ワイルドカードを入力します。

    次の3つのタイプのcontext_type設定が有効です。

    • DBMS_SQL_FIREWALL.IP_ADDRESSは、CIDR表記法のIPv4およびIPv6アドレスとサブネットを受け入れます。IPアドレスが使用できない場合は、ローカル接続のための値Local (大/小文字を区別)を受け入れます。
    • DBMS_SQL_FIREWALL.OS_USERNAMEは、oracleなどの有効なオペレーティング・システム・ユーザー名を受け入れます。
    • DBMS_SQL_FIREWALL.OS_PROGRAMは、ユーザーがSQL文の実行に使用する有効なオペレーティング・システム・プログラム名(sqlplusSQL Developerなど)を受け入れます。

    次のデータ・ディクショナリ・ビューを問い合せて、コンテキストを確認できます。

    • DBA_SQL_FIREWALL_ALLOWED_IP_ADDR
    • DBA_SQL_FIREWALL_ALLOWED_OS_USER
    • DBA_SQL_FIREWALL_ALLOWED_OS_PROG
  9. ユーザーに対して生成された許可リストを有効にして、SQLファイアウォールの保護を適用します。
    この有効化は、ターゲット・ユーザーの既存のセッションでもすぐに有効になります。

    次に例を示します。

    BEGIN
      DBMS_SQL_FIREWALL.ENABLE_ALLOW_LIST (
        username       => 'APP',
        enforce        => DBMS_SQL_FIREWALL.ENFORCE_SQL,
        block          => TRUE
       );
    END;
    /

    詳細は、次のとおりです。

    • usernameには、許可リストが生成されている特定のユーザーを指定できます。それ以外の場合は、許可リストが現在有効になっていないすべてのユーザーを指定できます。すべてのユーザーを指定する場合は、値としてNULLを使用します。
    • enforceは、次の強制タイプのいずれかを指定します。
      • DBMS_SQL_FIREWALL.ENFORCE_CONTEXTは、構成済の許可されたコンテキストを強制します。
      • DBMS_SQL_FIREWALL.ENFORCE_SQLは、構成済の許可されたSQLを強制します。
      • DBMS_SQL_FIREWALL.ENFORCE_ALLは、許可されたコンテキストと許可されたSQLの両方を強制します。これはデフォルト設定です。
    • blockは、次のことを指定します。
      • TRUEの場合、ユーザーが許可リスト定義に違反するたびに、ユーザーのデータベース接続またはユーザーのSQL実行をブロックします。
      • FALSEの場合、一致しないユーザー・データベース接続またはSQLコマンドを続行できます。これはデフォルト設定です。

      SQLファイアウォールでは、強制オプションに関係なく、一致しないユーザー・データベース接続またはSQL文について違反ログが常に生成されます。

      この段階で、ユーザーが許可リストに違反するSQL問合せを実行しようとして、このSQLをブロックするようにSQLファイアウォールを指定していた場合は、ORA-47605: SQLファイアウォール違反というエラーが表示されます。

  10. 違反ログで、異常なSQL接続の試行または許可リストにない場合にレポートされるSQL問合せをモニターします。
    次に例を示します。
    SELECT SQL_TEXT, FIREWALL_ACTION, IP_ADDRESS, CAUSE, OCCURRED_AT
    FROM DBA_SQL_FIREWALL_VIOLATIONS WHERE USERNAME = 'APP';

    次のような出力が表示されます。

    SQL_TEXT                                                  FIREWALL_ACTION  IP_ADDRESS   CAUSE            OCCURRED_AT
    –-------------------------------------------------------- –--------------- –----------  –---------------- –----------------------------------
    
    SELECT SALARY FROM HR.EMPLOYEES WHERE SALARY >:"SYS_B_0"  BLOCKED          192.0.2.146  Context violation 12-MAY-23 11.12.39.626053 PM +00:00
13.2.3.2 SQLファイアウォール構成への変更

ユーザーのSQLファイアウォール構成を作成した後は、必要に応じて構成を変更できます。

SQLファイアウォール構成に関する情報を確認するには、DBA_SQL_FIREWALL_*データ・ディクショナリ・ビューを問い合せることができます。

表13-1に、SQLファイアウォールの構成後に実行できる操作を示します。

表13-1 SQLファイアウォールの変更手順

操作 プロシージャ

SQLファイアウォールの有効化

  • データベースでSQLファイアウォールを有効にするには、DBMS_SQL_FIREWALL.ENABLEを使用します。
取得の管理
  • 取得を作成するには、DBMS_SQL_FIREWALL.CREATE_CAPTUREを使用します。
  • キャプチャを開始するには、DBMS_SQL_FIREWALL.START_CAPTUREを使用します。
  • キャプチャを変更するには、DBMS_SQL_FIREWALL.DROP_CAPTUREを使用して現在のものを削除し、DBMS_SQL_FIREWALL.CREATE_CAPTUREを使用して新しいものを作成します。
  • 指定されたユーザーのSQLファイアウォール取得プロセスを停止するには、DBMS_SQL_FIREWALL.STOP_CAPTUREを使用します。
  • 指定されたユーザーのSQLファイアウォール・キャプチャを削除し、このユーザーの既存のすべての取得ログを削除するには、次のようにします。
    1. DBMS_SQL_FIREWALL.STOP_CAPTUREを使用して、取得プロセスを停止します。
    2. DBMS_SQL_FIREWALL.DROP_CAPTUREを使用して、キャプチャを削除します。
許可リストの管理
  • 特定のユーザーの許可リストを生成するには、DBMS_SQL_FIREWALL.GENERATE_ALLOW_LISTを使用します。
  • 特定のユーザーの許可リストを有効にするには、DBMS_SQL_FIREWALL.ENABLE_ALLOW_LISTを使用します。
  • 許可リストの適用を更新するには、DBMS_SQL_FIREWALL.UPDATE_ALLOW_LIST_ENFORCEMENTを使用します。
  • Oracle Schedulerジョブで、SQLファイアウォールがデータベース接続およびSQL実行の許可リストを取得および適用しないようにするには、DBMS_SQL_FIREWALL.EXCLUDEを使用します。
  • ユーザーの既存の取得ログまたは違反ログ(あるいはその両方)を使用して許可リストにコンテンツを追加するには、DBMS_SQL_FIREWALL.APPEND_ALLOW_LISTを使用します。このプロシージャは、許可リストが有効でも無効でも実行でき、変更はただちに反映されます。
  • 特定のユーザーの許可リストをJSON形式に指定したCLOBにエクスポートするには、DBMS_SQL_FIREWALL.EXPORT_ALLOW_LISTを使用します。
  • 特定のユーザーの許可リストをターゲット・データベースにインポートするには、DBMS_SQL_FIREWALL.IMPORT_ALLOW_LISTを使用します。
  • 特定のユーザーの許可リストを無効にするには、DBMS_SQL_FIREWALL.DISABLE_ALLOW_LISTを使用します。
  • 許可されたコンテキスト・リストからコンテキスト値を追加または削除するには、それぞれDBMS_SQL_FIREWALL.ADD_ALLOWED_CONTEXTDBMS_SQL_FIREWALL.DELETE_ALLOWED_CONTEXTを使用します。
  • 許可されたSQLリストからSQL文を削除するには、DBMS_SQL_FIREWALL.DELETE_ALLOWED_SQLを使用します。
  • 指定されたユーザーの許可リストを削除するには、次のようにします。
    1. DBMS_SQL_FIREWALL.DISABLE_ALLOW_LISTを使用して許可リストを無効にします。
    2. DBMS_SQL_FIREWALL.DROP_ALLOW_LISTを使用します。
許可されたコンテキストの管理
  • 指定されたコンテキスト・タイプについて、指定されたユーザーの許可されたコンテキストに特定の値を追加するには、DBMS_SQL_FIREWALL.ADD_ALLOWED_CONTEXTを使用します。
  • 許可されたコンテキストを変更するには、DBMS_SQL_FIREWALL.DELETE_ALLOWED_CONTEXTを使用して現在のものを削除してから、DBMS_SQL_FIREWALL.ADD_ALLOWED_CONTEXTを使用して新しいものを作成します。
  • 指定されたコンテキスト・タイプについて、指定されたユーザーの許可されたコンテキストから指定の値を削除するには、DBMS_SQL_FIREWALL.DELETE_ALLOWED_CONTEXTを使用します。
許可されたSQLの管理
  • 指定されたユーザーの許可されたSQLから指定のエントリを削除するには、DBMS_SQL_FIREWALL.DELETE_ALLOWED_SQLを使用します。このプロシージャは、許可リストが有効でも無効でも実行でき、変更はただちに反映されます。

SQLファイアウォール・ログ表の管理

  • SQLファイアウォールのログ表をデフォルト表領域SYSAUX以外の別のユーザー定義表領域に移動するには、次のようにします。
    1. DBMS_SQL_FIREWALL.DISABLEを使用してSQLファイアウォールを無効にします。
    2. ALTER TABLE文のMOVE句を使用して、移動操作を実行します。
  • あるユーザーまたはすべてのユーザーの取得ログまたは違反ログをパージするには、DBMS_SQL_FIREWALL.PURGE_LOGを使用します。
  • メモリーに存在するすべてのSQLファイアウォール・ログをログ表にフラッシュするには、DBMS_SQL_FIREWALL.FLUSH_LOGSを使用します。

SQLファイアウォールの無効化

  • データベースでSQLファイアウォールを無効にし、有効になっている既存のキャプチャおよび許可リストをすべて停止するには、DBMS_SQL_FIREWALL.DISABLEを使用します。
13.2.3.3 取得ログのパフォーマンスの管理

アプリケーションのワークロードによっては、SQLファイアウォールが大量の取得ログを生成する場合があります。

データベース・パフォーマンスに対する悪影響を最小限に抑えるために、SQLファイアウォールは内部的に高速収集に依存することで、十分なメモリーが使用可能な場合に書込みパフォーマンスを向上させます。SQLファイアウォールを完全に利用するために、次のことを実行するようにお薦めします。
  • 既存のLARGE_POOL_SIZE要件に加えて、少なくとも追加の2GをLARGE_POOL_SIZEパラメータ設定に割り当てます。
  • この追加要件を含めるために、SGA_TARGETパラメータ設定のサイズを変更します。最終的なサイズが8G以上であることを確認します。
13.2.3.4 SQLファイアウォール・ログのパージ

DBMS_SQL_FIREWALL.PURGE_LOGプロシージャを使用して、SQLファイアウォールが生成するログを定期的にパージする必要があります。

SQLファイアウォールでは、違反ログはログ表に生成および格納されます。理想的なSQLファイアウォールのトレーニングされた環境では、違反ログは大規模にはならないと考えられます。このようなログは定期的にパージすることをお薦めします。生成された許可リストが有効であることを確認したら、不要なログをパージして、ログが使用しているディスク領域を再利用する必要があります。
  1. SQL_FIREWALL_ADMINロールを付与されたユーザーとして、SQLファイアウォールが構成されているルートまたはプラガブル・データベース(PDB)にログインします。
  2. オプションで、SELECT ANY DICTIONARYシステム権限を持つユーザーとして、次のデータ・ディクショナリ・ビューを問い合せて、パージする予定のログを確認します。
    • DBA_SQL_FIREWALL_CAPTURE_LOGS
    • DBA_SQL_FIREWALL_VIOLATIONS
  3. SQL_FIREWALL_ADMINロールを付与されているユーザーとしてPDBに接続します。
  4. DBMS_SQL_FIREWALL.PURGE_LOGプロシージャを実行します。
    次に例を示します。
    BEGIN
      DBMS_SQL_FIREWALL.PURGE_LOG (
        username    => 'APP',
        purge_time  => '2023-02-01 00:00:00.00 -08:00',
        log_type    => 'DBMS_SQL_FIREWALL.ALL_LOGS'
       );
     END;
    /

    詳細は、次のとおりです。

    • usernameは、このSQLファイアウォール構成が作成されたターゲット・ユーザーです。この値を省略すると、Oracle Databaseではpurge_timeおよびlog_type設定に一致するすべてのログがパージされます。
    • purge_timeは、特定の時間より前に生成されたログのみをパージするように指定できるタイムスタンプです(TIMESTAMP形式)。この値を省略すると、Oracle Databaseでは生成された時間に関係なくすべてのログがパージされます。
    • log_typeは、パージされるログのタイプです。値を指定しない場合、デフォルトはDBMS_SQL_FIREWALL.ALL_LOGSになります。次の定数のいずれかを指定します。
      • DBMS_SQL_FIREWALL.CAPTURE_LOG
      • DBMS_SQL_FIREWALL.VIOLATION_LOG
      • DBMS_SQL_FIREWALL.ALL_LOGS (デフォルト)
13.2.3.5 SQLファイアウォールのトラブルシューティングとモニター

トレース・ファイルを使用し、SQLファイアウォール違反をモニターするために統合監査ポリシーを作成することで、SQLファイアウォールをトラブルシューティングできます。

13.2.3.5.1 SQLファイアウォール・トレース・ファイルの有効化または無効化

ALTER SESSIONまたはALTER SYSTEMシステム権限が付与されたユーザーとして、SQLファイアウォールを使用しているPDB内にトレース・ファイルを生成できます。

  • SQLファイアウォールに対してトレースを有効にするには、次のいずれかの文を使用します。
    ALTER SESSION SET EVENTS 'TRACE SQL_FIREWALL DISK=trace_level
    ALTER SYSTEM SET EVENTS 'TRACE SQL_FIREWALL DISK=trace_level

    この指定では、trace_levelを次のいずれかの値に置き換えます。

    • LOWは、最小のトレース情報を示します。
    • HIGHは、より詳細なトレース情報と、LOWによって戻される情報を示します。
    • HIGHESTは、最も詳細なトレース情報と、HIGHおよびLOWによって戻される情報を示します。
  • SQLファイアウォールに対してトラッキングを無効にするには、次のいずれかの文を使用します。
    ALTER SESSION SET EVENTS 'TRACE SQL_FIREWALL OFF
    ALTER SYSTEM SET EVENTS 'TRACE SQL_FIREWALL OFF
13.2.3.5.2 統合監査ポリシーを使用したSQLファイアウォール違反の監査

統合監査ポリシーは、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることで表示可能な統合監査証跡に様々なアクティビティを書き込みます。

統合監査ポリシーの作成時にSQL_FIREWALLコンポーネントを指定することで、SQLファイアウォール固有の統合監査ポリシーを作成できます。UNIFIED_AUDIT_TRAILを問い合せると、FW_ACTION_NAME列およびFW_RETURN_CODE列を問い合せることができます。

ノート:

Oracle Databaseは、SQLファイアウォールDBMS_SQL_FIREWALL PL/SQL PL/SQLパッケージの管理プロシージャのすべての起動を強制的に監査します。

13.3 SQLファイアウォールと他のOracle機能との連携

SQLファイアウォールを他のOracle機能と併用することの影響を理解しておく必要があります。

13.3.1 SQLファイアウォール・メタデータでのOracle Data Pumpのエクスポートおよびインポート操作

Oracle Data Pumpを使用して、SQLファイアウォールの取得および許可リストのメタデータをエクスポートおよびインポートできます。

13.3.1.1 SQLファイアウォール・メタデータでのOracle Data Pumpのエクスポートおよびインポート操作について

SQLファイアウォールはOracle Data Pumpと統合され、キャプチャおよび許可リストのメタデータを含め、SQLファイアウォール・メタデータのエクスポートおよびインポートをサポートします。

SQLファイアウォールはOracle Data Pumpと統合され、キャプチャおよび許可リストのメタデータを含め、SQLファイアウォール・メタデータのエクスポートおよびインポートをサポートします。これは通常、非本番データベースでトレーニングを1回実行でき、非本番トレーニング・ステージ中に生成された許可リストを使用して、複数の本番データベースでSQLファイアウォールを有効にできるシナリオで必要です。

Oracle Databaseでは、ソース・データベースの許可リストをターゲット・データベースの既存の許可リストにマージしないかぎり、エクスポートおよびインポート操作中でも取得および許可リストのステータスが保持されます。たとえば、エクスポート時にソース・データベースで取得が有効になっている場合、インポート操作の完了後はターゲット・データベースでも取得が有効になります。これは、インポート操作の前にターゲット・データベースに同じユーザーの許可リストがない場合に許可リストをインポートする場合と同様です。

ソース・データベースの許可リストをターゲット・データベースの既存の許可リストにマージする場合、ターゲット・データベースの許可リストの設定(statustop_level_onlyenforceblockなど)は、インポート操作前と同じままになります。許可されたSQLおよびコンテキストのみがマージされます。

Oracle Data Pumpの場合、Oracleは、既存のすべてのSQLファイアウォール・メタデータ(取得および許可リスト)全体のエクスポートまたはインポートをサポートしています。Oracleでは、Oracle Data Pumpを介した特定の取得または特定の許可リストのエクスポートまたはインポートはサポートされていません。

あるユーザーの許可リストのみを特定のデータベースから別のユーザーにエクスポートまたはインポートする場合は、DBMS_SQL_FIREWALL.EXPORT_ALLOW_LISTまたはDBMS_SQL_FIREWALL.IMPORT_ALLOW_LISTプロシージャを使用します。(この2つのプロシージャはOracle Data Pumpに依存せず、独立して使用できます。)Oracleでは、SQLファイアウォール・ログ(取得および違反ログ)のエクスポートおよびインポートはサポートされていません。

13.3.1.2 Oracle Data PumpがSQLファイアウォールの取得または許可リストのインポートをスキップする場合

特定のケースでは、Oracle Data Pumpはインポート操作中に特定のSQLファイアウォールの取得または許可リストをスキップし、他の取得または許可リストのインポートを続行します。

これらのケースを次に示します。

  • ターゲット・ユーザーがターゲット・データベースに存在しない場合、存在しないユーザーの取得および許可リストはインポートされません。

  • 許可リストがターゲット・データベースに存在しない現行ユーザーを参照している場合、この許可リストはインポートされません。

  • 許可リストをインポートする場合に、同じユーザーの許可リストがターゲット・データベースにすでに存在し、そのtop_level_only設定がインポート対象の許可リストと異なる場合、許可リストはインポートされません。

  • 許可リストをインポートする場合に、同じユーザーの取得がターゲット・データベースにすでに存在し、そのtop_level_only設定がインポート対象の許可リストと異なる場合、その許可リストはインポートされません。

  • インポート対象の許可リストが有効になっており、ターゲット・データベースで同じユーザーに対して取得が有効になっているが、許可リストが無効になっていない場合、同じユーザーに対して有効な取得と有効な許可リストを同時に存在させないために、その許可リストはインポートされません。

  • 同じユーザーに対してインポート対象の取得がターゲット・データベースにすでに存在する場合、その取得はインポートされません。

  • インポート対象の取得が有効になっており、ターゲット・データベースで同じユーザーに対して許可リストが有効になっている場合、同じユーザーに対して有効な取得と有効な許可リストを同時に存在させないために、その取得はインポートされません。

  • 取得をインポートする場合に、同じユーザーの許可リストがターゲット・データベースにすでに存在し、そのtop_level_only設定がインポート対象の取得と異なる場合、その取得はインポートされません。

13.3.1.3 Oracle Data Pumpを使用したSQLファイアウォール・メタデータのエクスポートおよびインポート

expdpおよびimpdpコマンドを使用して、SQLファイアウォールの取得および許可リストのメタデータをエクスポートおよびインポートできます。

  1. SQLファイアウォールが使用されているサーバーにログインします。
  2. コマンドラインで、Oracle Data Pumpのエクスポートまたはインポート操作を実行します。
    • SQLファイアウォール・メタデータをエクスポートするには、次の構文を使用します。
      expdp user_name@pdb_name FULL=Y DIRECTORY=dumpfile_dir INCLUDE=SQL_FIREWALL dumpfile=dumpfile_name.dmp LOGFILE=filename.log

      詳細は、次のとおりです。

      • FULL=Yは全体エクスポート・モードを有効にします。SQLファイアウォールのメタデータは、全体エクスポート・モードでのみエクスポートされます。
      • INCLUDE=SQL_FIREWALLは、INCLUDEまたはEXCLUDEフィルタで使用できます。このタグはオプションです。これにより、あるデータベースから別のデータベースにSQLファイアウォール・メタデータのみをエクスポートおよびインポートできます。

      次に例を示します。

      expdp "hr@hr_pdb" FULL=Y DIRECTORY=sql_fw_dumpfiles INCLUDE=SQL_FIREWALL DUMPFILE=sql_fw_app.dmp LOGFILE=sql_fw_app.log
      Enter password: password
    • SQLファイアウォール・メタデータをインポートするには、次のようにします。
      impdp user_name@pdb_name FULL=Y DIRECTORY=dumpfile_dir INCLUDE=SQL_FIREWALL dumpfile=dumpfile_name.dmp LOGFILE=filename.log 

      次に例を示します。

      impdp "hr@hr_pdb" FULL=Y DIRECTORY=dumpfile_dir INCLUDE=SQL_FIREWALL dumpfile=sql_fw_app.dmp LOGFILE=sql_fw_app.log
      Enter password: password

13.3.2 SQLファイアウォールの適用からのOracle Scheduling操作の除外

ほとんどのシナリオでは、Oracle Schedulerジョブは、通常、ユーザーによって実行されないため、SQLファイアウォールの適用から除外できます。

デフォルトでは、Oracle Schedulerジョブは除外されます。次の手順を使用して、FEATUREパラメータをDBMS_SQL_FIREWALL.SCHEDULER_JOB定数に設定することで、Oracle Schedulerの操作中にSQLファイアウォールの実行を有効または無効にできます。

  • DBMS_SQL_FIREWALL.INCLUDEを使用すると、SQLファイアウォールは、Oracle Schedulerの操作中にSQLを取得したり、許可リストを適用できます。
  • DBMS_SQL_FIREWALL_EXCLUDEを使用すると、SQLファイアウォールは、Oracle Schedulerの操作中にSQLを取得したり、許可リストを適用することができなくなります。

次に例を示します。

EXEC DBMS_SQL_FIREWALL.EXCLUDE (DBMS_SQL_FIREWALL.SCHEDULER_JOB);

13.3.3 SQLファイアウォールとOracle Database Vault

TBA

13.3.3.1 Oracle Database VaultとSQLファイアウォールの機能の比較

構成する保護のタイプに応じて、Oracle Database VaultとSQLファイアウォールのいずれかまたは両方を使用できます。

Database Vaultを使用すると、レルムおよびコマンド・ルールを使用して、機密オブジェクトへのアクセス、クリティカル・コマンドの実行、およびユーザーに関連付けられている任意の数の識別可能な属性(時刻、IPアドレス、ホスト名、プログラム名など)などの信頼できない要因からのSQL接続をブロックできます。Database Vault環境では、SQLファイアウォールを使用して、データベース・アカウントの信頼できるデータベース接続パスが関連付けられているSQLコマンドの許可リストを取得することで、この保護を拡張できます。その後、見えないSQLトラフィックをログに記録(およびオプションでブロック)できます。SQLファイルウォールの強制では、承認されたSQL文および接続を、認可されていないSQLトラフィックと区別できます。認可されていないSQLトラフィックは、レルムおよびコマンド・ルールが機密オブジェクトへのアクセスを明示的に認可されていないかぎり防ぐために提供する保護レイヤーに追加されます。

次の表に、Database Vaultレルムとコマンド・ルールおよびSQLファイルウォールを使用して保護を適用する方法の比較を示します。

表13-2 Oracle Database VaultとSQLファイルウォールの保護の比較

ユースケース レルム コマンド・ルール SQLファイアウォール

データベース・スキーマの保護

はい、従来のレルムまたは必須レルムでは、データへのアクセスを制限できます。

  • スキーマまたはスキーマ全体
  • オブジェクト型
  • 名前別の特定のオブジェクト

はい、スキーマ・オブジェクトに対するDML文またはDDL文

いいえ

データベース・ロールの保護

はい、従来のレルムまたは必須レルムがロールを保護できます。

はい、特定のロールに対してGRANTまたはREVOKE文を使用してコマンド・ルールを作成します。

いいえ

データベース・オブジェクトの保護

はい、従来のレルムまたは必須レルムでは、データへのアクセスを制限できます。

  • スキーマ全体またはスキーマ
  • オブジェクト型
  • 名前別の特定のオブジェクト

はい、スキーマ・オブジェクトに対するDML文またはDDL文

  • スキーマまたはスキーマ全体
  • オブジェクト型
  • 名前別の特定のオブジェクト

いいえ

個々のSQL文の保護

いいえ

はい。スキーマまたは個々のスキーマ・オブジェクトに対する制御文です。

はい。明示的に許可されているSQL文を除くすべてのSQL文をブロックします。

許可リストおよびアプリケーションSQLトラフィックの保護

いいえ

いいえ

はい。明示的に許可されているSQL文を除くすべてのSQL文をブロックします。

安全性の低いアカウントのリスクから保護

はい、プログラムでチェックできる要素に基づいて、信頼できるパス条件を確立します。

はい、CONNECTコマンドの使用を保護します。

はい、信頼できないクライアントIP、プログラムおよびOSユーザー名からのセッションをブロックします

SQLインジェクション・リスクからデータベース・ユーザーを保護

いいえ

いいえ

はい、データベース・ユーザーごとに許可リストSQLファイアウォール・ポリシーを作成し、適用します。

13.3.3.2 Oracle Database Vault環境でSQLファイアウォールを使用するための認可

Oracle Database Vault環境では、SQLファイアウォールを構成するユーザーは、Oracle Database Vault固有の認可を受ける必要があります。

Database Vaultが有効な場合、SQLファイアウォールの管理(つまり、DBMS_SQL_FIREWALLパッケージの起動)には、SQLファイアウォール管理者がADMINISTER SQL FIREWALLシステム権限に加えてDatabase Vault固有の認可を持っている必要があります。この要件は、信頼できるユーザーのみがDatabase Vault環境でSQLファイアウォールを管理できるようにするためです。

SQLファイアウォール管理者は、Database Vault環境でDV_OWNERDV_ADMINまたはDV_ACCTMGRロールを持つユーザーに対して取得を許可または許可しないようにできます。Database Vault操作制御が有効な場合、共通ユーザーが例外リストに含まれている場合を除き、共通ユーザーはローカル・ユーザーでのSQLファイアウォール(つまり、取得および許可リストを管理するためのDBMS_SQL_FIREWALLプロシージャ)の使用をブロックされます。

13.3.4 SQLファイアウォールとOracle Real Application Security

SQLファイアウォールをOracle Real Application Security (Oracle RAS)とともに使用すると、XS$NULLユーザーのOracle RASアプリケーションからのSQL文を取得できます。

SQLファイアウォール取得操作の完了後に、XS$NULLユーザーの許可リストを生成および強制できます。ただし、SQLファイアウォールでは、Oracle RASエンド・ユーザー・アイデンティティの取得および強制操作は実行されません。

13.3.5 SQLファイアウォールとOracle Database集中管理ユーザーおよびエンタープライズ・ユーザー

SQLファイアウォール取得が有効な場合、SQLファイアウォールはグローバル・ユーザーのアクティビティを取得します。

ただし、SQLファイアウォールでは、エンタープライズ・ユーザー・アイデンティティ(たとえば、Active Directory (CMU-AD)ユーザー、Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM)ユーザー、Oracle Internet Directory (OID)ユーザー、Microsoft Azure Active Directoryユーザー)は区別されません。

13.3.6 SQLファイアウォールとOracle Virtual Private Database

Oracle Virtual Private Databaseポリシーが実行されると、SQLファイアウォールは実行直後にSQLコマンドを取得します。

ただし、SQLファイアウォールでは、データベース・カーネルによる変更または変換(ビュー、シノニム、SQLマクロ拡張、仮想プライベート・データベースの強制など)は考慮されません。許可リストを策定するために、予想されるすべての受信SQL文を取得するようにSQLファイアウォールをトレーニングする必要があります。

13.3.7 マルチテナント環境でのSQLファイアウォール

SQLファイアウォールは、CDBルート・レベルと個々のPDBレベルの両方で影響を受けます。

CDBルートで:

  • CDBルート・コンテナでSQLファイアウォールを有効にしてから、SQLファイアウォール・ポリシーの作成、SQLファイアウォールの有効化または無効化、取得の開始または停止、許可リストの有効化または無効化を行うことができます。これらの設定は、CDBルートにのみ適用されます。
  • Oracle Database Vault操作制御環境では、SQLファイアウォールの使用に制限はありません。

個々のPDB:

  • 個々のPDBでSQLファイアウォールを有効にしてから、SQLファイアウォール・ポリシーの作成、SQLファイアウォールの有効化または無効化、取得の開始または停止、許可リストの有効化または無効化を行うことができます。これらの設定は現在のPDBにのみ適用されます。
  • Database Vault操作制御環境では、共通ユーザーはローカル・ユーザーの取得を開始または停止したり、ローカル・ユーザーの許可リストを有効または無効にすることはできません。

13.4 SQLファイアウォールのデータ・ディクショナリ・ビューおよびサンプル問合せ

Oracleには、構成したSQLファイアウォール保護に関する様々な種類の情報を検索できる一連のデータ・ディクショナリ・ビューが用意されています。

13.4.1 SQLファイアウォールのデータ・ディクショナリ・ビュー

Oracle Databaseには、SQLファイアウォール構成に関する情報を提供する一連のデータ・ディクショナリ・ビューが用意されています。

表13-3に、これらのデータ・ディクショナリ・ビューを示します。

表13-3 SQLファイアウォール情報を表示するデータ・ディクショナリ・ビュー

ビュー 説明

DBA_SQL_FIREWALL_ALLOW_LISTS

ユーザーの許可リストのステータスおよび生成日を示します

DBA_SQL_FIREWALL_ALLOWED_IP_ADDR

ユーザーに対して許可されているIPアドレスをリストします

DBA_SQL_FIREWALL_ALLOWED_OS_PROG

ユーザーに対して許可されているオペレーティング・システム・プログラムをリストします

DBA_SQL_FIREWALL_ALLOWED_OS_USER

ユーザーに対して許可されているオペレーティング・システム・ユーザーをリストします

DBA_SQL_FIREWALL_ALLOWED_SQL

ユーザーの許可されたSQL文、許可されたSQLのSQL ID、および許可リスト・バージョンに関する情報をリストします

DBA_SQL_FIREWALL_CAPTURE_LOGS

ユーザーのSQLファイアウォール構成のログ情報(データベース・ユーザー名、SQLテキスト、アクセスされたオブジェクト、SQLファイアウォール・セッションIDなど)を示します

DBA_SQL_FIREWALL_CAPTURES

SQLファイアウォール・キャプチャのステータス(有効かどうかなど)を示します

DBA_SQL_FIREWALL_SESSION_LOGS

SQLファイアウォール・セッションに関する情報(セッションID、データベース・ユーザー名、クライアント・プログラムなど)を示します

DBA_SQL_FIREWALL_SQL_LOGS

SQLテキスト、コマンド・タイプ、SQL署名、アクセスされたオブジェクト、文字セットなどのSQLログに関する情報をリストします

DBA_SQL_FIREWALL_STATUS

SQLファイアウォール構成のステータス(有効かどうか、タイムスタンプなど)を示します

DBA_SQL_FIREWALL_VIOLATIONS

SQLファイアウォール違反に関する詳細レポート(アクセスされたオブジェクト、SQLが実行されたユーザー、アクションがブロックされたか許可されたかなどの情報を含む)を示します

13.4.2 ユーザーの許可されたSQLおよびアクセスされたオブジェクトを検索する問合せ

DBA_SQL_FIREWALL_ALLOWED_SQLデータ・ディクショナリ・ビューには、ユーザーが使用できるSQLが表示されます。

次に例を示します。

SELECT SQL_TEXT, ACCESSED_OBJECTS FROM DBA_SQL_FIREWALL_ALLOWED_SQL WHERE USERNAME = 'HR';
 
SQL_TEXT                            ACCESSED_OBJECTS  
----------------------------------- ------------------
SELECT COUNT(*) FROM HR.EMPLOYEES   "HR"."EMPLOYEES'        

13.4.3 ユーザーの許可されたIPアドレスを検索する問合せ

DBA_SQL_FIREWALL_ALLOWED_IP_ADDRデータ・ディクショナリ・ビューには、ユーザーが使用できるIPアドレスが表示されます。

次に例を示します。

SELECT IP_ADDRESS FROM DBA_SQL_FIREWALL_ALLOWED_IP_ADDR WHERE USERNAME = 'HR';
 
IP_ADDRESS
------------
192.0.2.1

13.4.4 ユーザーのSQLファイアウォール違反を検索する問合せ

DBA_SQL_FIREWALL_VIOLATIONSデータ・ディクショナリ・ビューには、ユーザーが犯したファイアウォール違反が表示されます。

次に例を示します。

SELECT SQL_TEXT, OCCURRED_AT, FIREWALL_ACTION FROM DBA_SQL_FIREWALL_VIOLATIONS WHERE USERNAME = 'HR';
 
SQL_TEXT                           OCCURRED_AT                         FIREWALL_ACTION
---------------------------------- ----------------------------------  –--------------
SELECT COUNT(*) FROM HR.EMPLOYEES  12-OCT-23 10.30.02.238383 AM +00:00 BLOCKED