プライマリ・コンテンツに移動
Oracle® Audit Vault and Database Firewall開発者ガイド
リリース12.1.2
B71714-05
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

1 概要

この章では、Audit Vault and Database Firewallの監査収集プラグインについて説明します。章の最初にOracle Audit Vault and Database Firewallソフトウェア(AVDF)を簡単に説明してから、収集プラグインを説明します。後続の章では、カスタム収集プラグインを作成してデータベース表、XMLファイルまたは他の場所に書き込まれた監査情報を収集する方法について説明します。

この章の内容は次のとおりです。

1.1 Oracle Audit Vault and Database Firewallの概要

Oracle Audit Vault and Database Firewallは、複数の分散された異機種システムの監査データを収集、統合、保護および分析するソフトウェア・システムです。次のコンポーネントで構成されます。

  • Oracle Audit Vault Server: Oracle Audit Vault and Database Firewallのアクティビティを管理する組込みのOracleデータベースおよび他のソフトウェア・コンポーネントを含むサーバー。

  • Oracle Audit Vault Agent: リモート・ホストで実行され、Audit Vaultサーバーのコマンドに基づいて監査情報の収集を管理するJavaコンポーネント。エージェントは制御下の収集プラグインとやりとりして監査レコードを収集し、Audit Vault Serverに送信します。

  • Oracle Database Firewall: Database Firewallは、Database Firewallソフトウェアを実行する専用サーバーです。各Database Firewallは、データベース・クライアントからセキュア・ターゲット・データベースへのネットワーク上のSQLトラフィックを監視します。次に、Database Firewallは、各種レポートで分析するために、SQLデータをAudit Vault Serverに送信します。

Oracle Audit Vault and Database Firewallは事前にパッケージ化された複数の収集プラグインとともに出荷されます。収集プラグインは、様々なタイプのセキュア・ターゲット・システムの監査データにアクセスして解釈する方法を認識するソフトウェア・プログラムです。収集プラグインは、セキュア・ターゲット・システムで生成された監査証跡の監査データを収集し、Audit Vault Serverリポジトリに格納します。各収集プラグインは、特定タイプのセキュア・ターゲットの特定タイプの証跡に固有です。これらの収集プラグインは、『Oracle Audit Vault and Database Firewall管理者ガイド』の説明に従って、Oracle、SQL Server、Sybase ASE、DB2などのデータベースからデータを収集します。

1.1.1 Oracle Audit Vault Serverおよびエージェントの動作方法

監査収集プラグインは、連続した監査レコードである監査証跡の形式で監査データを取得します。監査証跡は、データベース表やXML監査レコードなどの異なるセキュア・ターゲット・タイプごとに生成されます。

セキュア・ターゲットは、1つ以上の監査証跡を書き込むことができます。各監査証跡は個別の場所に格納され、固有の書式を持つことができます。

次の用語について補足します。

  • セキュア・ターゲット

    セキュア・ターゲットは、特定の機能を実行するソフトウェアまたはハードウェア・システムです。この機能の実行の一部として、セキュア・ターゲット・システムは監査証跡を生成します。セキュア・ターゲットは、セキュア・ターゲット・タイプのインスタンスで、接続資格証明や証跡タイプなどの特定のプロパティを持ちます。

  • セキュア・ターゲット・タイプ

    セキュア・ターゲット・タイプは、同じタイプの監査データを生成する、特定タイプのセキュア・ターゲットのコレクションを表します。たとえば、Oracle Databaseは、多数のインスタンスを持つことができるセキュア・ターゲット・タイプです。ただし、すべてのOracle Databaseは、同じ監査データを生成し、同じフィールドを記録します。

  • 監査証跡

    監査証跡は、監査データが存在する場所および書式を識別します。各監査証跡は、それぞれ1つのセキュア・ターゲットのみによって生成されます。監査証跡の例は次のとおりです。

    • データをファイルに書き込むセキュア・ターゲットの場合、その証跡はディレクトリ・パスとファイル・マスクです。

    • 監査データをデータベース表に書き込むセキュア・ターゲットの場合、セキュア・ターゲットの証跡は表の名前です。SYS.AUD$は、Oracleデータベースのデータベース表の監査証跡の例です。

1.2 監査収集プラグインの概要

収集プラグインは、監査証跡に格納される監査データを取得することで、Oracle Audit Vault and Database Firewallとともに出荷される事前にパッケージ化された各種収集プラグインと同様の機能を提供します。「Oracle Audit Vault and Database Firewallの概要」を参照してください。

Oracle Audit Vault and Database Firewallリリース12.1.1以降、開発者およびサードパーティ・ベンダーは、カスタム収集プラグインを作成できます。これらの収集プラグインは、新しいセキュア・ターゲット・タイプの監査データを収集したり、AVDFがすでに認識しているセキュア・ターゲット・タイプによって書き込まれた新しい監査証跡をサポートしてユーザーが使用できるようにします。

データベース表およびXMLファイルに格納された監査証跡を収集するか、別の方法でアクセスできる収集プラグインを書き込むことができます。

リレーショナル・データベース、オペレーティング・システム、中間層システム、エンタープライズ・アプリケーションなどのセキュア・ターゲットをサポートできます。

このガイドでは、これらのカスタム収集プラグインを作成して既存のOracle Audit Vault and Database Firewallインストール環境にデプロイする方法について説明します。

1.2.1 監査収集プラグインのタイプ

2つのタイプの収集プラグインを作成できます。作成する必要がある実際のタイプは、収集する監査証跡のプロパティによって異なります。

収集プラグインは、作成するマッパー・ファイルと呼ばれるXMLファイルを使用して、収集する監査データを指定します。Audit Vault Serverは、このファイルを使用して、収集する監査レコードにアクセスして解釈します。このためにコードを記述する必要はありません。

1.2.1.1 作成する監査収集プラグイン・タイプの判断

この項では、2つのタイプの収集プラグインと、各タイプを使用するために必要なプロパティについて説明します。

収集する監査証跡が次のいずれかに格納される場合、マッパー・ファイル(テンプレート)および収集プラグインを簡単に定義できます。

  • データベース表: 特定の制約に準拠するデータベース表に格納されます

  • XMLファイル: Audit Vault XML監査ファイル形式に基づいたXMLファイルに格納されます

1.3 Audit Vaultイベントおよびフィールド

セキュア・ターゲット・システムで発生するアクティビティのイベントの動向の監視は、Oracle Audit Vault and Database Firewallで最も重要な点です。これらのイベントは、フィールドで説明されます。セキュア・ターゲット・システムで発生した1つのイベントを説明するフィールドのコレクションが、監査レコードです。

Oracle Audit Vault and Database Firewallリリース12.1.1では、Audit Vault 10.3と比べてイベントおよびイベント構造の表現が大幅に簡素化されています。

Oracle Audit Vault and Database Firewallリリース12.1.1では、次の内容が適用されます。

  • 各セキュア・ターゲットは、そのセキュア・ターゲットで発生する監査イベントとしてイベントを記録します。監査レコードは監査イベントの情報を取得します。

  • 通常、監査レコードは、対象となるオブジェクト・タイプに発生した内容を説明するセキュア・ターゲット・タイプのイベント名を持ちます。発生したアクションのターゲットも含まれます。また、アクションが発生した時間、件名またはアクションを発生させた実行者は必ず含まれますが、その他のデータも含まれる場合があります。

    Audit Vault Serverでは、監査レコードのフィールドは、コア・フィールド、拡張フィールド、ラージ・フィールドおよびマーカー・フィールドのグループに分類されます。

1.3.1 コア・フィールド

コア・フィールドはイベントを説明する基本フィールドで、ほとんどの監査レコードはこのフィールドの一部またはすべてを含みます。ただし、すべてのコア・フィールドが各監査レコードで必要なわけではありません。

Oracle Audit Vault and Database Firewallリリース12.1.1で、発生したアクションを説明するコア・フィールドは次のとおりです。

  • CommandClassフィールド: 監査レコードの生成の原因となったアクション。

  • UserNameおよびOsUserNameフィールド: 件名またはアクションを実行したユーザー。

  • EventTimeフィールド: アクションが発生した時間。

  • ClientHostNameClientIpおよび他の関連フィールド: アクションの発生場所。

  • TargetTypeTargetOwnerおよびTargetObjectフィールド: アクションのオブジェクト・タイプ、オブジェクト所有者またはターゲット。

コア・フィールドの完全なリストは、付録A第A.1.1項「コア・フィールド」にリストされているコア・フィールドを参照してください。

1.3.1.1 CommandClassおよびターゲット・タイプ

CommandClassおよびTargetTypeフィールドには、データベースやオペレーティング・システムなどの様々なドメインに属するセキュア・ターゲットで発生する一連の汎用イベントを示す周知の値が含まれます。

CommandClassの例としては、LogonSelectUpdateおよびShutdownなどがあります。

これらは付録A第A.2項「アクションおよびターゲット・タイプ」にリストされています。

1.3.2 他のAudit Vaultフィールド

コア・フィールド以外に、Audit Vault Serverは次のカテゴリを認識します。

1.3.2.1 ラージ・フィールド

ラージ・フィールドは、大量のデータを任意で含むことができるフィールドです。詳細は、第A.1.2項「ラージ・フィールド」を参照してください。

1.3.2.2 拡張フィールド

拡張フィールドは、意味的に等しいAudit Vaultフィールドがなく、コアまたはラージ・フィールドにマップされないセキュア・ターゲット・フィールドを使用可能にする方法を提供します。

開発者は、フィールドの格納に使用される書式を判断します。

詳細は、第A.1.4項「拡張フィールド」を参照してください。

1.3.2.3 マーカー・フィールド

マーカー・フィールドは、証跡のレコードの一意識別子です。監査レコードの1つ以上のフィールドから作成されます。

詳細は、第A.1.3項「マーカー・フィールド」を参照してください。

1.3.3 Audit Vaultにおける監査レコードの格納

プラグイン開発者として、セキュア・ターゲット内で発生する様々なイベントをAudit Vaultで許可された様々なフィールドにマップする必要があります。

監査レコードのフィールドをAudit Vaultの名前付きフィールドのいずれか(コア、ラージまたはマーカー・フィールド)にマップする場合は、そのままマップしてください。

監査レコードのフィールドを名前付きフィールドのいずれかにマップしない場合は、選択した拡張フィールドにマップできます。

ActionおよびTargetType Audit Vault Serverフィールドについては、「アクションおよびターゲット・タイプ」のフィールド値のリストを参照してください。監査レコードをこれらの値のいずれかに意味的にマップする場合、その該当する値を使用することを強くお薦めします。付録にリストされていない値も使用できます。

Audit Vaultに値を格納する場合、次の基本ガイドラインに従うことを強くお薦めします。

  • セキュア・ターゲット・データベースのオブジェクトを参照するIDを格納しないでください。Audit Vaultはこれらのオブジェクトにアクセスできませんが、格納された値は意味がありません。監査者が認識できるように、かわりにオブジェクトのリテラル名を格納してください。

  • 定義されたAudit Vault表記規則に従ってください。たとえば、Audit VaultのすべてのACTIONフィールドおよびTARGET TYPEフィールドは大文字の値を使用します。使用するセキュア・ターゲット・タイプに適用できず、Audit Vaultに格納されたデータが正しく解釈されない場合を除いて、この表記規則に従ってください。

  • 可能な場合、「アクションおよびターゲット・タイプ」に記載されている値にマップしてください。たとえば、TABLETargetTypeとしてリストに存在する場合、DATABASE TABLETargetTypeを使用して監査レコードを追加しないでください。

最後に、セキュア・ターゲットの監査レコードのフィールドをコア・フィールドにする利点がある場合、モデルに適切に追加できるようOracleに連絡してください。

1.4 収集プロセス

この項の内容は次のとおりです。

1.4.1 収集のフロー: ユーザー

  1. 開発者は、収集プラグインを作成して、ユーザーに提供します。

  2. ユーザーはプラグインをAudit Vault Serverにデプロイします。プラグインをサーバーにデプロイすると、新しいバージョンのAudit Vault Agentが作成されます。この新しいエージェントには、収集プラグインのコレクタ・コードが含まれます。

  3. 次に、ユーザーは、実行する必要があるホストに新しいエージェントをデプロイします。

  4. これでユーザーは、コレクタ・コードによってサポートされる監査証跡の収集を開始できます。

  5. ユーザーは、コレクタ・コードによってサポートされる監査証跡の収集を開始します。

次の項では、ユーザーが収集を開始した後に収集プラグイン内で発生する内容について説明します。

図1-1 収集のフロー

図1-1の説明が続きます
「図1-1 収集のフロー」の説明

1.4.2 監査収集プラグイン内の制御のフロー

収集プラグインは監査証跡にアクセスし、監査証跡から監査レコードおよび関連フィールドを抽出したら、その監査レコードをAudit Vaultイベントにマップし、すべてのフィールドをAudit Vaultフィールドにマップします。次に、収集プラグインは、Audit VaultイベントとフィールドをAudit Vault Agentに渡して、情報をAudit Vault Serverに送信します。

この項では、このプロセスを詳細に説明します。

  1. Audit Vault Serverは、エージェント・フレームワークに指示してスレッドを作成し、特定の監査証跡を収集します。「収集スレッド」を参照してください。

  2. エージェントで作成された新しいスレッドは、特定の監査証跡を収集します。

    この時点で、制御は収集フレームワークに渡されます。「収集フェーズ」を参照してください。

  3. スレッド内で、収集フレームワークはAudit Vault Serverに接続し、収集する監査証跡の構成情報を問い合せます。

    また、その証跡に設定された最後のチェックポイントの情報をリクエストします。「証跡のチェックポイント」を参照してください。

  4. 現在の情報を使用して、収集フレームワークは、プラグイン・マニフェスト・ファイルを通じて、正しい収集プラグイン内で起動する正しいJavaクラスを判断します。構成情報をこのクラスに渡して、自身の初期化を要求します。

  5. コレクタが自身を初期化したら、収集フレームワークは繰り返しループします。各ループ内で、収集フレームワークは次の処理を実行します。

    • コレクタに監査証跡の追加の監査レコードを要求します。

      コレクタは、追加の監査レコードをAudit Vault Serverが予期する監査レコードの形式に変換(マップ)し、収集APIを通じて収集フレームワークに渡します。「マッピング」を参照してください。

    • 収集プラグインから受け取ったチェックポイント情報および他のメトリック・データをAudit Vault Serverに送信します。

  6. Audit Vault Serverが停止コマンドなどのコマンドを収集フレームワークに送信すると、収集フレームワークはそれを動作するコレクタに渡します。収集フレームワークがAudit Vault ServerからSTOPコマンドを受け取ると、コレクタにレコードの送信の停止を通知して収集スレッドを終了し、自身を停止します。

1.4.3 収集の概念

この項では、収集プロセスに関連する概念の一部について説明します。

1.4.3.1 収集スレッド

エージェントは収集のスレッドを開始します。各スレッド内で、Audit Vault収集フレームワークは、収集プラグインで指定されたコードを実行します。収集フレームワークは、収集プラグインがやりとりする収集APIを公開するランタイム・インフラストラクチャです。収集プラグインは、必要に応じてユーティリティAPIS(非表示)も使用します。

1.4.3.2 収集フェーズ

収集フェーズ中に、収集プラグインは、監査証跡にアクセスして新しいレコードを抽出します。監査証跡へのアクセス方法の正確なメカニズムは、監査証跡によって異なります。セキュア・ターゲットの監査レコードが証跡から取得された後、収集プラグインはAudit Vault Serverに送信可能な監査レコードに変換(マップ)できる必要があります。「マッピング」を参照してください。

収集プラグインは、セキュア・ターゲット・レコードのキャラクタ・セット、使用されるエンコーディングおよびタイム・スタンプに関連する問題の情報も取得して、Audit Vault Serverサーバー要件と一致させる必要があります。

1.4.3.3 マッピング

必要なマッピングは、セキュア・ターゲット・レコードによって異なります。

次のタイプのマッピングが必要です。

  • イベント・マッピング: セキュア・ターゲット固有のイベントをAudit Vaultイベントにマップします。

  • フィールド・マッピング: セキュア・ターゲット・レコードの様々なフィールドをAudit Vaultフィールドにマップします。

  • 値マッピング: 収集された様々なフィールド値を各フィールドの一連の正規化された値にマップします(たとえば、0および1は特定のフィールドのFALSEおよびTRUEにマップされる可能性があります)。

  • 複雑なマッピング: セキュア・ターゲット・フィールドからAudit Vaultフィールド、またはセキュア・ターゲット監査イベントからAudit Vaultイベントへのマッピングが単純ではない場合、複雑なマッピングが使用されます。

1.4.3.4 証跡のチェックポイント

チェックポイントまたは証跡のチェックポイントは、監査レコードがAudit Vault Serverにコミットされたポイント(タイムスタンプ)です。収集プラグインは、再起動時に最後のチェックポイントから再開できるようにチェックポイントを定期的に設定します。

1.4.3.5 データ収集のリカバリ・フェーズ

Audit Vaultは、各監査レコードがAudit Vault Serverで1回のみアーカイブされることを示す、1回のみの保証をユーザーに提供します。このため、チェックポイントとリカバリのメカニズムを実装しています。

データ収集のリカバリ・フェーズでは、収集プラグインが停止および再起動して、収集を再開します。収集プラグインは、以前に停止したチェックポイントから収集を再開します。

収集プラグインが監査証跡からレコードを収集していない場合、チェックポイントは最初のレコードの前になります。収集プラグインがレコードの収集を開始して停止した場合、チェックポイントは収集した最後のレコードの直後になります。

チェックポイントの直後で収集を再開すると、収集プラグインが任意のレコードを確実に検出します。リカバリ中に重複するレコードの収集を回避するため、収集プラグインは各レコードのマーカー・フィールドを確認します。

収集プラグインは、最後のチェックポイントの前に発生したレコードを収集してエージェントに渡しません。ただし、エージェントは、最後のチェックポイントのにコミットされ、収集プラグインの再起動時に再収集されたレコードを自動的にフィルタ処理します。実際に、このSDKを使用して作成された収集プラグイン(第3章を参照)は、EventTimeUTCフィールドを拡張子.atcのファイルに書き込みます。スクリプトでこのファイルを後で読み取り、必要に応じて監査レコードを削除できます。

1.4.3.6 監査証跡のクリーンアップ

監査証跡のクリーンアップは、アーカイブされた後に監査レコードをクリーンアップするために一部のセキュア・ターゲットが提供する機能です。このタイプの機能がセキュア・ターゲットに存在する場合、Audit Vault収集プラグインが統合して、セキュア・ターゲットに監査証跡がアーカイブされた範囲を通知できます。これにより、セキュア・ターゲットはそのポイントまでの監査証跡をクリーンアップ(元の監査データを削除)でき、これを認識しているとデータを損失しません。収集プラグインは、データが収集された最後のポイントのチェックポイントに関するクリーンアップ・ユーティリティ情報を提供します。

収集プラグインは、機能の適切なインタフェースを起動して、セキュア・ターゲット・システムのクリーンアップ機能を通知できます。たとえば、システムは、ファイルシステムのファイルのタイムスタンプを読み取り、そのタイムスタンプまでの監査証跡をクリーンアップする場合があります。その場合、プラグインはそのファイルを定期的に書き込むことができます。

たとえば、Oracle Databaseセキュア・ターゲットではDMBS_AUDIT_MGMTパッケージでこのタイプのユーティリティが提供され、Oracle Databaseに事前にパッケージ化された収集プラグインがそれを統合します。

1.5 監査収集プラグインを書き込む一般的な手順

収集プラグインを書き込む一般的な手順は、次のとおりです。

  1. Oracle Audit Vault and Database Firewallに追加する機能、新しいセキュア・ターゲット・タイプまたは既存のセキュア・ターゲット・タイプの新しい監査証跡を把握します。

  2. 『Oracle Audit Vault and Database Firewall管理者ガイド』を参照して、必要な処理を実行するプラグインが提供されているかどうかを確認してください。存在する場合はそれを使用し、開発しなおすことはしないでください。

    必要なプラグインが存在しない場合のみ続行します。


    注意:

    バージョン依存のセキュア・ターゲット・タイプ、つまり同じソフトウェアの異なるバージョンのセキュア・ターゲット・タイプを作成しないでください。実行すると、AVDFは、異なるバージョンにアップグレードされるとセキュア・ターゲットから収集できません。

    たとえば、バージョン依存のセキュア・ターゲット・タイプSQL Server 2000およびSQL Server 2005と、SQL Server 2000セキュア・ターゲットから監査証跡を収集する収集プラグインを作成するとします。このセキュア・ターゲットをSQL Server 2005にアップグレードすると、Oracle Audit Vaultエージェントは監査証跡を収集できません。


  3. セキュア・ターゲット・タイプが書き込むイベントおよびフィールドを確認します。

    プラグインを書き込む際に、適切な既存のイベントおよびフィールドを使用します(付録A「Audit Vault Serverフィールド」を参照してください)。必要なイベントまたはフィールドを使用できない場合、拡張フィールドを使用できます(「拡張フィールド」を参照してください)。Audit Vaultがサポートするフィールドのセットが評価され、幅広いセキュア・ターゲット・タイプに適用される場合に新しいフィールドが追加されることがあります。使用しているフィールドがこの基準を満たす場合、Oracleサポートに連絡してください。

  4. 「監査収集プラグインのタイプ」の説明に従って、書き込む収集プラグインのタイプを決定します。

  5. 開発環境を設定します。第2章「開発環境の設定」を参照してください。

  6. 作成しているプラグインのタイプの詳細は、第3章「監査収集プラグイン」を参照してください。

  7. 収集プラグインの次の内容を判断します。

    • セキュア・ターゲットへの接続方法。

    • セキュア・ターゲットに問い合せて認識する必要がある内容を習得する方法。

    • プラグインがサポートするプラットフォーム。

  8. 「監査証跡のクリーンアップ」の説明にあるように監査証跡のクリーンアップをプラグインでサポートするかどうかを決定します。

  9. 収集プラグイン・パラメータを設定します。

  10. プラグイン・マニフェスト・ファイルを作成して、収集プラグインを示します。第4章「監査収集プラグインのパッケージ化」を参照してください。

  11. avpackユーティリティを実行して、プラグインをパッケージ化します(第4章「監査収集プラグインのパッケージ化」を参照してください)。

  12. ステージング環境のプラグインをテストします(第5章「監査収集プラグインのテスト」を参照してください)。

  13. プラグインが動作する場合、『Oracle Audit Vault and Database Firewall管理者ガイド』で説明されているコマンドライン・コマンドを使用して、開発環境にデプロイするためにAudit Vault管理者がプラグインを使用できるようにします。