oracle audit vaultベスト・プラクティス...はじめに oracle audit...

ベスト・プラクティス 2007 年 11 月

ベスト・プラクティス

はじめに ...................................................................................................................................................... 3 Oracle Audit Vault のインストール ........................................................................................................... 3

配置計画 ................................................................................................................................................ 4 Oracle Audit Vault Server ................................................................................................................. 4 Oracle Audit Vault Collection Agent................................................................................................. 5 推奨されるエージェント構成 ....................................................................................................... 6 配置するコレクタの種類 ............................................................................................................... 6 推奨されるコレクタとデータベース監査構成 ........................................................................... 8

ニア・リアルタイム・アラ―ト......................................................................................................... 9 ニア・リアルタイム・レポート......................................................................................................... 9

ETL プロセスに関する推奨事項................................................................................................... 9 Oracle データベース監査 ........................................................................................................................ 10

監査証跡の内容と場所 ...................................................................................................................... 11 推奨されるデータベース監査構成 ............................................................................................. 12

監査の設定 - セキュアな構成 ......................................................................................................... 12 推奨されるデータベース監査設定 ............................................................................................. 12 データベース監査のパフォーマンス ......................................................................................... 14 監査と Oracle Audit Vault コレクタ ............................................................................................. 14

ソース上での監査データの管理 ............................................................................................................ 15 データベースからの監査データの削除 ..................................................................................... 15 推奨されるデータベース監査クリーンアップ期間 ................................................................. 16 オペレーティング・システムからの監査データの削除 ......................................................... 16

Oracle Audit Vault の保守 ......................................................................................................................... 18 Oracle Audit Vault Server のログ・ファイル............................................................................... 18 Oracle Audit Vault Collection Agent のログ・ファイル .............................................................. 18 Oracle Audit Vault の障害時リカバリ .......................................................................................... 20 推奨されるリカバリ構成 ............................................................................................................. 20

付録 A. 監査証跡保守用スクリプト ..................................................................................................... 21 付録 B. データベース・ソース監査の設定.......................................................................................... 28

Oracle Audit Vault ベスト・プラクティス 2

Oracle Corporation 発行「Oracle Audit Vault Best Practices」の翻訳版です。

はじめに Oracle Audit Vault は、監査データの統合および分析プロセスを自動化するソリューションです。

Oracle Audit Vault を使用すれば、監査データを、今日のセキュリティおよびコンプライアンス規

制の問題に対処する主要なセキュリティ・リソースとして利用できます。Oracle Audit Vault は、

業界をリードするオラクルのデータベース・セキュリティおよびデータウェアハウス製品を基盤

に構築されています。本書では、Oracle Audit Vault を企業内に配置するためのベスト・プラクティ

スを提示します。配置アーキテクチャと予想されるパフォーマンスに関する情報も含まれていま

す。また、Oracle データベースの監査機能および推奨されるベスト・プラクティスについても説

明します。Oracle Audit Vault では、Oracle9i Database Release 2 以上のデータベースの監査データ

を統合化できます。現在、異機種のデータベースのサポートにも取り組みを進めており、今後の

リリースで実現する予定です。

本書は、開発部門および顧客からのフィードバックに基づいた最新の情報を反映させるために、

定期的に更新されます。最新のベスト・プラクティスについては、Oracle Audit Vault ドキュメン

トの今後のリリースに含められます。

Oracle Audit Vault のインストール Oracle Audit Vault のアーキテクチャは、監査データを格納および保護するために連携して動作す

る次の 2 つの主要コンポーネントで構成されています。

• Oracle Audit Vault Server - カスタマイズされた Oracle Database 10g（10.2.0.3）上に構築さ

れるデータウェアハウスを含むスタンドアロンの上位アプリケーション。Oracle Database Vault によってセキュリティ機能を実現し、Oracle Containers for J2EE（OC4J）コンポー

ネントによって、Oracle Audit Vault Console と Oracle Enterprise Manager のデータベース

制御をサポートします。 • Oracle Audit Vault Collection Agent - コレクタの管理と Oracle Audit Vault ウォレットの保

守をおこないます。 o コレクタ - コレクタは監査ソース固有のコンポーネントで、監査証跡データを

ソースから引き出し、SQL*Net 経由で Oracle Audit Vault Server に送信すること

により、ソースと Oracle Audit Vault Server 間の仲介役として機能します。 o Oracle Audit Vault ウォレット - ソースに接続してデータベースから監査データ

を取り出すときに、コレクタが使用するパスワードを管理します。



図 1 Oracle Audit Vault のアーキテクチャ

配置計画 Oracle Audit Vault は統合化されたセキュアな監査データ用記憶域を実現しますが、インストール

を計画的におこなうことで、インストールに必要な時間が短縮され、規制準拠ソリューションの

実装全体を確実に成功させることができます。次の各セクションでは、Oracle Audit Vault Serverと Oracle Audit Vault Collection Agent のインストール前の考慮事項について説明します。

Oracle Audit Vault Server Oracle Audit Vault Server は、専用のホストまたは Oracle Enterprise Manager Grid Control や Oracle Recovery Manager（Oracle RMAN）などのリポジトリ・データベースが存在するホスト上にイン

ストールする必要があります。Oracle Audit Vault Server をソース・データベース・サーバーとは

別のホストにインストールことによって、次のような利点が得られます。

• 高い可用性 - Oracle Audit Vault Server をソース・データベースとは別のサーバー上に配

置すると、ソース・ホストがダウンしているかどうかに関係なく Oracle Audit Vault Serverが利用可能になるため、稼働中のすべてのソースから監査データが継続的に収集され

ます。 • セキュアな監査証跡 - 監査証跡レコードをソース・データベースから可能な限り速く抽

出することによって、データベース・システムおよびオペレーティング・システムの特

権ユーザーに監査レコードを改ざんする機会を与えないようにします。

Oracle Audit Vault Server をインストールおよび保守するために必要なリソースのタイプは、監査

レコードを Oracle Audit Vault に挿入するときの所要時間と監査データを保管する期間によって

異なります。

6GB 3GHz Intel Xeon×2 を搭載し、Redhat 3.2 が稼働する Linux ホスト上で実施したオラクルの

社内テストで、Oracle Audit Vault Server は、最大で毎秒 17,000 件の監査レコードを挿入しました。



500,000 件の監査証跡レコードを Oracle Audit Vault リポジトリ・データベースに格納するには、

約 300MB のディスク領域が必要です。ORACLE_HOME の各種ファイルを格納するには、さら

に 2GB のディスク領域が必要になります。

Oracle Audit Vault Server では、スケーラビリティと可用性を高めるため、Oracle Real Applications Cluster（Oracle RAC）と障害時リカバリ用の Oracle Data Guard をオプションで実装できます。

Oracle Audit Vault Server をインストールするオペレーティング・システムの要件一覧については、

そのオペレーティング・システムの『Oracle Audit Vault サーバー・インストレーション・ガイド』

を参照してください。

Oracle Audit Vault Collection Agent Oracle データベースは、監査証跡データをデータベース（SYS.AUD$/SYS.FGA_LOG$）または

オペレーティング・システム・ファイル（またはその両方）に書き込むことができます。Oracleデータベースのオンライン・ログ（REDO ログ）には、データ値の変更前後の情報も格納されま

す。Oracle Audit Vault では、Oracle データベースの監査証跡固有のプロセスであるコレクタに

よって、監査データを抽出し、Oracle Audit Vault Server に送信します。コレクタには 3 つのタイ

プがあります。データベース監査用のDBAUD、Oracleデータベースによって出力されるオペレー

ティング・システム・ファイル用の OSAUD、REDO ストリームから監査データを抽出する REDOの 3 つです。

Oracle Audit Vault Collection Agent は、監査データの収集をサポートする機能を提供します。こ

のエージェントは、コレクタをロードし、Oracle Audit Vault Server との接続を確立して、監査デー

タとコレクタの実行時メトリックを送信します。Oracle Audit Vault は、自分の担当エージェント

を介して監査データソースと通信します。

Oracle Audit Vault Collection Agent は、監査対象のデータベースと同じホスト、Oracle Audit Vault Server ホスト、または Oracle Audit Vault Server ホストや監査対象のデータベースが存在している

ホストとは異なるいずれかのホストにインストールできます。

以下、各自の環境において Oracle Audit Vault Collection Agent の最適なインストール場所を決定

するために、それぞれのシナリオについて検討します。

• 監査対象データベースと同一ホスト（推奨） - データベース監査証跡の出力先がオペ

レーティング・システムの場合は、Oracle Audit Vault Collection Agentを、それらのオペ

レーティング・システム・ファイルと同じホスト上にインストールする必要があります。



• Oracle Audit Vault Serverホスト - データベース監査証跡の出力先がデータベース表

（SYS.AUD$/SYS.FGA_LOG$）の場合は、Oracle Audit Vault Collection AgentをOracle Audit Vault Serverホストにインストールできます。その場合、Oracle Audit Vaultが使用するす

べてのソフトウェア・コンポーネントが、単一ホスト上に統合されることになります。

• 監査ホストおよびOracle Audit Vault Serverホストとは異なるホスト - データベース監

査証跡の出力先がデータベース表（SYS.AUD$/SYS.FGA_LOG$）の場合は、Oracle Audit Vault Collection Agentを監査データベースが存在するホストおよびOracle Audit Vault Serverホストとは異なるホストにインストールできます。

推奨されるエージェント構成オラクルでは、Oracle Audit Vault Collection Agent を監査対象データベースと同じサーバー上に

インストールすることを推奨しています。RAC の場合は、Oracle Audit Vault Collection Agent を各インスタンス上にインストールする必要があります。この構成を採用すると、Oracle Audit Vault Collection Agent は、データベース表（SYS.AUD$/SYS.FGA_LOG$）またはオペレーティン

グ・システム・ファイルから監査データを提供できます。

配置するコレクタの種類 Oracle Audit Vault コレクタは、監査データをソースから Oracle Audit Vault Server に転送します。

これらのコレクタを管理しているのは、上述の Oracle Audit Vault Collection Agent です。Oracle Audit Vault Collection Agent は、監査データの出力先がデータベース表であるかオペレーティン

グ・システム・ファイルであるかに応じて、3 つの Oracle Audit Vault コレクタを配置します。オ

ラクルでは一部の重要な監査関連情報を REDO ログに格納する点に注意してください。このた

め、これらの監査情報の収集用に REDO コレクタも用意されています。表 1 は、監査証跡の場

所の特徴についてまとめたものです。この表に基づいて、監査証跡の出力先および監査データを

Oracle Audit Vault に転送するときに配置するコレクタを決定してください。



監査操作 OS ログ DB 監査表 REDO ログ

SELECT

DML

DDL

データ値の変更前と変更後

成功と失敗

SQL テキスト（SYS 用）

SYS 監査

そのほかの統合職務の分離 FGA データすべての値のサプリメンタル・ロギング

表 1 監査証跡の特徴

3 つのタイプのコレクタは、DBAUD、OSAUD、REDO と呼ばれます。表 2 に示されるとおり、

各タイプのコレクタは、それぞれ Oracle ソース・データベース内の異なる場所から監査レコー

ドを取得します。

コレクタ名 Oracle データベースの監査データソース

Oracle データベースの監査初期化設定

利点

DBAUD データベース監査証跡（標準の監査イベントがデータベース・ディクショナリ表SYS.AUD$に出力される）。ファイングレイン監査証跡（監査イベントがデータベース・ディクショナリ表SYS.FGA_LOG$ に出力される）。

初期化パラメータとして audit_trail=db, db_extended を設定する。

DB_EXTENDED 値により、SQL テキストが監査証跡の一部として収集される。DB_ EXTENDED では SYSユーザーのアクティビティを監視しないため、OSAUD コレクタを一緒に配置する必要がある。



コレクタ名 Oracle データベースの監査データソース

Oracle データベースの監査初期化設定

利点

OSAUD オペレーティング・システム・ファイル（OSファイル）。必須監査レコードが出力される。オプションで、データベース監査証跡（標準監査イベント）とファイングレイン監査証跡イベントが OS 監査ログに出力される。オペレーティング・システム固有の監査証跡（システム監査証跡）。データベース監査証跡レコードが、Windows の場合はWindows Event Logに、Linux の場合は syslogに出力される。

初期化パラメータAUDITTRAILに OS を、AUDIT_FILE_DESTパラメータにディレクトリ指定内の目的のファイルを設定する。

初期化パラメータ AUDIT_SYS_OPERATIONS に TRUE を、AUDIT_FILE_DEST パラメータにディレクトリ内の目的のファイルを設定する。

• オペレーティング・システム・ファイルに格納された監査レコードは、DBA が所有しているファイル・アクセス権ではアクセスできないため、データベースに格納された監査レコードよりもセキュアである。

• オペレーティング・システム・ファイルに監査レコードを格納するもう1 つの利点として、高い可用性がある。データベースが一時的にアクセス不能になってもオペレーティング・システム・ファイルは利用可能である。

REDO REDO ログ REDOログはOracleデータベース・インフラストラクチャの一部であり、ソース・データベース設定を必要としない。Oracle Audit Vault Policy（キャプチャ・ルール）によって、REDO ログから抽出されるメタデータが決まる。

• 給与などの機密性の高いデータ列に対する変更前後の値を追跡するために使用する。

表 2 Oracle Audit Vault コレクタのタイプ

生成され、保管する必要がある監査情報のタイプに応じて、ソース・データベースごとに 1 つの

コレクタまたは 3 つすべてのコレクタを配置できます。

推奨されるコレクタとデータベース監査構成オラクルでは、データベースのパフォーマンス・オーバーヘッドを最小限に抑えるために、第一

の監査証跡の場所としてオペレーティング・システム使用し、OSAUD コレクタを配置すること

を推奨しています。監査情報をオペレーティング・システムに出力するためのデータベースの構

成については、本書の Oracle データベース監査のセクションを参照してください。



ニア・リアルタイム・アラ―トセキュリティ・アラートは、企業全体におけるコンプライアンス、プライバシ、インサイダーの

脅威に関する問題を事前に通知するために使用します。Oracle Audit Vault を使用することで、ITセキュリティ担当者は、疑わしいアクティビティ、不正なアクセスの試み、システム・レベルの

権限の濫用などを検出および警告できます。

Oracle Audit Vault は、システムまたはユーザー定義の個々のイベントに対してアラートを生成す

ることで、インサイダーの脅威に対する早期警告システムとして機能し、基本的な構成の変更や

規制に違反する可能性のあるアクティビティを検出します。また、収集した監査データを継続的

に監視して、定義済みのアラート条件に照らしてアクティビティを評価します。

アラートは、1 つの監査レコード内のデータがカスタム定義のアラート・ルール条件に一致する

と生成されます。たとえば、特権ユーザーが、あるユーザーに対して機密データへのアクセス許

可を与えようとするとアラートを生成するというようなルール条件を定義できます。

オラクルで実施した Oracle Audit Vault Server の社内テストでは、6GB 3GHz Intel Xeon×2 を搭載

し、Redhat 3.2 が稼働する Linux x86 マシンを使用して、毎秒 17,000 件の監査証跡レコードの挿

入スループットを達成できました。リアルタイムに近いアラート機能を達成するには、ビジネス

要件に合わせてホストをサイジングする必要があります。

ニア・リアルタイム・レポート監査データがソースから Oracle Audit Vault に転送されると、Oracle DBMS_SCHEDULER ジョブ

が ETL（抽出、変換、ロード）プロセスを起動し、生監査データを正規化してデータウェアハ

ウスに格納します。この ETL ジョブは、6GB 3GHz Intel Xeon×2 を搭載し、Redhat 3.2 が稼働す

る Linux x86 マシン上で実施したオラクルの社内テストで、50 秒強で 50 万件のレコードを処理

しました。標準の設定では、デフォルトの DBMS_SCHEDULER ジョブは 24 時間おきに実行さ

れます。

図 3 に示したとおり、Oracle Audit Vault によって、データウェアハウスを更新する ETL プロセ

スの統計情報が提供されます。この情報を利用して、ジョブの実行頻度を見積もり、データウェ

アハウスのインフラストラクチャを更新できます。データウェアハウスのインフラストラクチャ

については、『Oracle Audit Vault 監査者ガイド』を参照してください。

ETL プロセスに関する推奨事項 ETL プロセスの実行頻度を上げることで、リアルタイムに近いレポート機能を実現できます。

オラクルでは、前の ETL ジョブが完了してから次の ETL を開始することを推奨しています。



図 2 Oracle Audit Vault ウェアハウスのロード結果

Oracle Audit Vault は、監査データの保護、管理、アクセス、分析を簡単におこなえるように監査

データを統合する機能を備えた、柔軟なデータウェアハウス・インフラストラクチャ上に構築さ

れています。Oracle Audit Vault では、Oracle Audit Vault 標準のレポートに加えて、オープンな監

査ウェアハウス・スキーマを用意しています。Oracle BI Publisher、Oracle Application Express、サー

ド・パーティ製のレポート・ツールは、このスキーマを使用して、セキュリティおよび規制準拠

に関するカスタム・レポートを作成できます。

Oracle データベース監査オラクルは、1990 年代初めの Oracle7 のリリース以来、堅牢な監査機能を提供してきました。

Oracle データベースの監査機能は、個々の規制準拠およびプライバシ要件に合わせて柔軟にカス

タマイズできます。

監査レコードには、監査された操作に関する情報、操作を実行したユーザー、および操作の日時

が記録されます。監査レコードは、データベース監査証跡またはオペレーティング・システム・

ファイルに格納できます。一般的な監査には、標準とファイングレインの 2 つのタイプがありま

す。標準監査の対象になるのは、権限、スキーマ、オブジェクト、文に対する操作です。ファイ

ングレイン監査はポリシーに基づいて実行される監査で、Oracle9i Database では選択操作に対し

て強制的に実行されます。Oracle Database 10g ではファイングレイン監査が改良され、挿入、更

新、削除操作に対しても、ポリシーに基づく監査が実行されるようになりました。



監査証跡の内容と場所監査証跡レコードには、監査対象のイベントと監査オプションの設定に応じて、さまざまなタイ

プの情報が格納されます。

以下に挙げる情報はその一部です。

• オペレーティング・システムのログイン・ユーザー名（CLIENT USER） • データベース・ユーザー名（DATABASE USER） • セッション識別子 • 端末識別子 • アクセスされたスキ―マ・オブジェクトの名前 • 実行または試行された操作（ACTION） • UTC（協定世界時）形式のタイムスタンプ • 使用されたシステム権限（PRIVILEGE） • プロキシ・セッション監査 ID • グローバル・ユーザーの一意の ID • インスタンス番号 • プロセス番号 • トランザクション ID • SQL 文の SCN（システム変更番号） • 監査を起動した SQL テキスト（SQLTEXT） • SQL 文に使用されたバインド値（SQLBIND）

Oracle Audit Vault は、データベース表またはオペレーティング・システム・ファイルから監査デー

タを抽出します。データベース監査を有効にするには、初期化パラメータ AUDIT_TRAIL を次

のいずれかの値に設定する必要があります。

パラメータ値意味

データベースデータベース監査を有効にして、すべての監査レコードをデータベース監査証跡（SYS.AUD$）に送信します。ただし、常にオペレーティング・システム監査証跡に出力されるレコードは除きます。

DB_EXTENDED AUDIT_TRAIL=DB と設定したときのすべてのアクションに加えて、SYS.AUD$表の SQL bind 列と SQL text 列に値を設定します。

OS（推奨）データベース監査を有効にして、すべての監査レコードをオペレーティング・システム・ファイルに出力します。



推奨されるデータベース監査構成オラクルでは、監査証跡をオペレーティング・システム・ファイルに出力することを推奨してい

ます。そうすることで、ソース・データベース・システムに対するオーバーヘッドを最小限に抑

えられるためです。

また、次のデータベース・パラメータも設定する必要があります。

• init.ora parameter：AUDIT_FILE_DEST -- オペレーティング・システム監査証跡の

場所を指定する動的パラメータ。デフォルトの場所は、Unix/Linux システムでは

$ORACLE_HOME/admin/$ORACLE_SID/adump、Windows ではイベント・ログです。

最適なパフォーマンスを得るには、Oracle インスタンスの実行ホストに直接接続さ

れたディスク上のディレクトリを指定する必要があります。 • init.ora parameter：AUDIT_SYS_OPERATIONS -- ユーザーSYS や、SYSDBA または

SYSOPER 権限をもつユーザーによって発行された操作の監査を有効にします。監査

証跡データは、オペレーティング・システム監査証跡に出力されます。このパラメー

タは、true に設定する必要があります。

監査の設定 - セキュアな構成 Oracle データベースの監査機能は、並列化の最小単位が細かく、柔軟性と拡張性に優れています。

ほとんどのエンタープライズ環境では、IT 監査人が、基本的なアクティビティ（ログインの成

功と失敗、特権ユーザーのアクティビティ、データベース・スキーマの変更、ユーザー・ポリシー

の変更など）を監査する機能を必要としています。

監査コマンドを発行するときは、追加パラメータとして'by access'または'by session'を指定できま

す。'by access'を指定すると、その操作が実行されるたびに、監査レコードを作成するよう Oracleに指示が出されます。'by session'を指定すると、その操作が現在のセッション内で最初に実行さ

れたとき、監査証跡が作成されます。操作が実行されるたびにその情報を知りたい場合は、'by access'を指定する必要があります。

推奨されるデータベース監査設定オラクルでは、実行された操作に関する情報を収集するために、ソース・データベースに対して

次のような監査設定をおこなうことを推奨しています。付録 B に掲載した SQL スクリプトは、

ご使用のデータベースにコピーして実行できます。このスクリプトは、Oracle Audit Vault のイン

ストール時に、デモ用ディレクトリに Oracle Audit Vault Server $ORACLE_HOME/demo/secconf. sql として格納されます。

監査コマンド監査内容

Audit alter any table by access; Audit create any table by access; Audit drop any table by access; Audit Create any procedure by access; Audit Drop any procedure by access; Audit Alter any procedure by access;

データベースのスキーマと構造の変化



Audit create external job by access; Audit create any job by access; Audit create any library by access; Audit alter database by access; Audit alter system by access;

Audit audit system by access; Audit create public database link by access; Audit exempt access policy by access; Audit alter user by access; Audit create user by access; Audit role by access; Audit create session by access; Audit drop user by access; Audit Grant any privilege by access; Audit grant any object privilege by access; Audit grant any role by access; Audit alter profile by access; Audit drop profile by access;

データベースへのアクセスと権限

表 3 推奨される監査設定

ヒント：SYS.AUD$表と SYS.FGA_LOG$表を監査の対象にしないでください。再帰条件が発生

して処理が終了しなくなります。

Oracle は、条件に基づいて個々の監査ポリシーを作成するファイングレイン監査機能も備えてい

ます。ファイングレイン監査を利用すると、内容または条件に基づいてデータ・アクセスを監視

できます。条件を使用すると、監査を限定し、DML 文のタイプを指定できます。この DML 文

は、接続で指定する列とともに使用されます。また、オプションで、監査イベントの発生時に名

前付きルーチンを呼び出して、エラーや異常を処理することもできます。

図 2 に例を示します。この例のファイングレイン監査ポリシーでは、SH.SALES 表に対して、

APPS 以外のユーザーによって select 文が実行されたときだけ監査証跡レコードを作成しています。

ファイングレイン監査は、ビジネス要件に応じて、監査ニーズが満たされるようカスタマイズで

きます。データベース監査について、詳しくは『Oracle Database セキュリティ・ガイド』を参

照してください。



図 3 Oracle Audit Vault のファイングレイン監査ポリシーの例

データベース監査のパフォーマンスソース・データベース上では、監査プロセスと Oracle Audit Vault Collection Agent によってリソー

スが消費されます。

監査と Oracle Audit Vault コレクタオラクルでは、32GB 3GHz Intel Xeon×4 を搭載した Redhat 3.0 マシン上で動作する Oracle Database 10g Release 2（10.2.0.3）を使用して、前述の表 3 に示した推奨される監査設定を用いて

社内テストを実施しました。次の表から、毎秒作成される監査証跡レコードの数を変化させたと

き、データベース監査機能と Oracle Audit Vault Collection Agent によって、CPU オーバーヘッド

が最大で 6%増えていることがわかります。

表 4 監査処理と Oracle Audit Vault Collection Agent による CPU オーバーヘッド

表 4 は、監査機能を有効にして、表 3 に指定した推奨される監査設定を用いて、TPC-C と同様

の負荷を発生させたときのパフォーマンス・オーバーヘッドを示しています。'Collect'列は、特

定の Oracle Audit Vault Collector によるパフォーマンス・オーバーヘッドを、'Create'列は、毎秒

の監査レコード生成数が 10 または 100 のときのデータベース監査によるパフォーマンス・オー

バーヘッドを、それぞれ示しています。

監査証跡レコードをオペレーティング・システム・ファイルに出力した場合のオーバーヘッドが

もっとも低くなっています。



ソース上での監査データの管理監査レコードには、監査された操作に関する情報、操作を実行したユーザー、および操作の日時

が記録されます。前述のとおり、監査レコードは、データベース内またはオペレーティング・シ

ステム・ファイルのどちらかに格納できます。

監査データをデータベースに出力する場合は、SYS.AUD$および SYS.FGA_LOG$という名前の

表を使用します。これらの表はデータベースの SYS スキーマに格納されています。

Oracle Database では、監査証跡レコードをオペレーティング・システムに出力することもできま

す。出力先ディレクトリはプラットフォームによって異なりますが、UNIX プラットフォーム上

では、通常、$ORACLE_HOME/rdbms/audit となります。Windows では、イベント・ビューアを

介して監査情報にアクセスします。

Oracle Audit Vault では、Oracle9i Database Release 2、Oracle Database 10g Release 1、および Oracle Database 10g Release 2 によって生成された監査データを収集する仕組みが用意されています。

データベース監査データは、データベースとオペレーティング・システム監査対象の両方から収

集できます。Oracle9i Database Release 2 および Oracle Database 10g Release 2 データベースの場合

は、トランザクション前後の値を、REDO コレクタを使用して REDO トランザクション・ログ

から捕捉できます。

データベースからの監査データの削除時間の経過とともに、データベースおよびオペレーティング・システムの新規監査レコードの格

納領域が上限に達する可能性があります。ある程度の期間、監査機能を有効にしたら、セキュリ

ティ管理者は、データベース監査証跡からレコードを削除するようにします。これにより、監査

証跡領域が解放され、監査証跡の管理が容易になります。ただし、まだ Oracle Audit Vault に転

送されていないデータを削除しないことが重要です。

データベースから監査データを削除する前に、Oracle Audit Vault Server に最後に挿入されたレコー

ドを確認してください。それには、Oracle Audit Vaults のアクティビティ概要レポートを使用し

ます。アクティビティ概要を開くと、サマリー・データの日付が表示されます。Oracle Audit Vaultのレポート・データは、最後に完了した ETL ウェアハウス・ジョブに基づいて表示される点に

注意してください。ウェアハウス・ジョブについて、詳しくは『Oracle Audit Vault 管理者ガイ

ド』を参照してください。



図 4 Oracle Audit Vault のアクティビティ概要レポート

アクティビティ概要レポートは、時刻の新しいものから順にデータを返します。したがって、表

示された最初のレコードは、データウェアハウスに挿入される最後のレコードになります。

データが Oracle Audit Vault Server にタイムリーに挿入されることが確認されたら、付録 A にあ

るスクリプトをデータベース・ジョブとして実行することにより、SYS.AUD$および SYS.FGA_ LOG$からレコードを削除できます。

推奨されるデータベース監査クリーンアップ期間オラクルでは、24 時間以上経過したレコードの削除を推奨しています。上の例では、2007 年 5月 3 日の午後 8:02（UTC）よりも古いレコードは削除することになります。Oracle Audit Vaultでは、データベース・ソースが存在するタイムゾーンとは無関係にトランザクションの実行順序

が維持されるように、すべてのデータが UTC 時刻形式で格納されます。

オペレーティング・システムからの監査データの削除データベース監査証跡と同様、Oracle では、Oracle データベース・セッション ID に基づいてオ

ペレーティング・システム・ファイルを作成または追加することによって、監査データをオペレー

ティング・システム上にも格納します。ディスク領域には制限があるため、Oracle Audit Vaultに監査証跡レコードが挿入されたら、オペレーティング・システム監査証跡ファイルを削除する

必要があります。

オペレーティング・システム監査証跡ファイルは、大半の UNIX システム上では、デフォルトで

$ORACLE_HOME/admin/$ORACLE_SID/adump に出力されます。ファイルの拡張子は".aud"です。

また、オプションで Oracle データベース・パラメータ AUDIT_FILE_DEST によって、出力先を

明示的に定義することもできます。



監査証跡レコードを削除する前に、Oracle Audit Vault Server に最後に挿入されたレコードを確認

してください。それには、アクティビティ概要レポートを使用します。アクティビティ概要を開

くと、サマリー・データの日付が表示されます（図 4 参照）。Oracle Audit Vault のレポート・デー

タは、最後に完了した ETL ウェアハウス・ジョブに基づいて表示される点に注意してください。

ウェアハウス・ジョブについて、詳しくは『Oracle Audit Vault 管理者ガイド』を参照してくだ

さい。付録 A には、cron ジョブまたはデータベース・ジョブとして実行可能な、UNIX システム

上の不要になったオペレーティング・システム監査ファイルを削除するためのスクリプトが掲載

されています。

Windows オペレーティング・システムでは、監査証跡レコードは Windows イベント・ログに出

力されます。Windows イベント・ビューアの機能を使用してイベント・ログ・ファイルのサイ

ズを制限するか、X 日より古いレコードを上書きしてください。

図 5 Windows イベント・ビューア

オラクルでは、古くなったレコードを上書きするオプションのご使用を推奨しています。



Oracle Audit Vault の保守 Oracle Audit Vault では、最適なパフォーマンスを維持するために、定期的に保守することが重要

です。Oracle Audit Vault は、通常の毎日の操作時に膨大なログとトレース・ファイルを生成しま

す。以下の各セクションでは、ログ・ファイルの内容、目的、および削除の方法と時期に関する

重要な情報について説明します。

Oracle Audit Vault Server のログ・ファイル Oracle Database と同様、Oracle Audit Vault Server でも、現在の状態と診断情報がログ・ファイル

に出力されます。ログ・ファイルは、その使用ディスク領域を抑制するために、監視して定期的

に削除する必要があります。次の各ログ・ファイルは、<Audit_Vault_Server_Home>/av/log に作

成されます。

サーバー・ログ・ファイル名

説明保守

avorcldb.log avorcldb 機能によって発行されたコマンドを追跡します。Avorcldb 機能は、監査対象ソースと Oracle Audit Vault エージェントおよびコレクタの初期設定時に使用されます。

このファイルはいつ削除しても問題ありません。

avca.log コレクタの作成および Oracle Audit Vaultエージェントとコレクタの起動/停止を追跡します。

このファイルは、Oracle Audit Vault Server がシャットダウンされたあとでないと削除できません。

av_client-%g.log.n Oracle Audit Vault Collection Agent の収集メトリックに関する情報が出力されます。%gは 0 から始まり、ファイル・サイズが上限値の 10MB に到達するとカウントアップされる生成番号です。

拡張子.log.n のファイル（たとえば、av_client-0.log.1）はいつ削除しても問題ありません。

Oracle Enterprise Manager は、<Audit Vault_Server_Home>/<Host_Name>_<SID>/sysman/log ディレ

クトリにログ・ファイルを格納します。このディレクトリの emdb.nohup ファイルには、GUI による対話、avctl ユーティリティからの要求、Oracle Audit Vault の各種コレクション・エージェ

ントとの通信など、Oracle Audit Vault Web アプリケーションのアクティビティに関するログが

出力されます。このログ情報は、サーバーとエージェント間の通信エラーのデバッグに使用され

ます。

Oracle Audit Vault Collection Agent のログ・ファイル Oracle Audit Vault Collection Agent は複数のログ・ファイルを作成します。これらのログ・ファ

イルによって使用されるディスク領域を抑制するために、エージェントを保守する必要がありま

す。次の各ログ・ファイルは、<Audit_Vault_Collection_Agent_Home>/av/log に作成されます。



エージェント・ログ・ファイル名

説明保守

agent.err エージェントの初期化および実行時に発生したすべてのエラーのログです。


agent.out エージェント関連のすべての主要な操作とアクティビティに関するログです。

このファイルは、Oracle Audit Vault Collection Agent がシャットダウンされたあとでないと削除できません。

avca.log 実行されたすべてのAVORCLDB コマンドと各コマンドの実行結果のログです。


avorcldb.log 実行されたすべての AVCA コマンドと各コマンドの実行結果のログです。


<CName><SName><SId>.log

CNmae = Collector_name SName = Source_name SID = Source_ID

DBAUD コレクタおよびOSAUD コレクタによる監査データ収集操作のログです。

このファイルは、Oracle Audit Vault Collection Agent がシャットダウンされたあとでないと削除できません。

av_client-%g.log.n エージェント操作と、それらの操作によって返されたすべてのエラーのログです。%g は0 から始まり、ファイル・サイズが上限値である 10MB に到達するとカウントアップされる生成番号です。このファイルが同時に複数存在している場合は、av_client-%g.log.n のように、ファイル・タイプ名のあとにつけられる.n 接尾辞によって示されます。ここで、nは順次発行の整数です。例：av_client-0.log.1

拡張子.log.nのファイルはいつ削除しても問題ありません。

sqlnet.log SQL*Net 情報のログです。



Oracle Audit Vault Collection Agent OC4J によって生成されたログは、<Audit_Vault_Collection_ Agent_Home>/oc4j/j2ee/home/log ディレクトリに出力されます。このディレクトリの

AVAgent-access.log ファイルには、このエージェントが Oracle Audit Vault Server から受信した要

求のログが格納されています。このログ情報は、サーバーとエージェント間の通信エラーのデ

バッグに使用されます。

Oracle Audit Vault の障害時リカバリデフォルトでは、Oracle Audit Vault データウェアハウスは、アーカイブ・ログ・モードで動作し

ます。これにより、監査データがメディア障害から保護され、より完全なリカバリがおこなえま

す。アーカイブ・ログは、フラッシュ・リカバリ領域に出力されます。

Oracle Recovery Manager（Oracle RMAN）とフラッシュ・リカバリ領域を組み合わせて使用する

と、バックアップ関連ファイルのディスク領域を手動で管理する必要性が最小限に抑えられ、さ

まざまなタイプのファイル間でディスク領域が適切に分配されます。Oracle Audit Vault の基本イ

ンストールでは、Oracle Audit Vault Oracle Home と同じディスク上に、デフォルト・サイズ 2GBでフラッシュ・リカバリ領域が確保されます。高度なインストール方法では、フラッシュ・リカ

バリ領域の場所とサイズ、および Oracle RMAN のバックアップ・ジョブを定義できます。

推奨されるリカバリ構成オラクルでは、フラッシュ・リカバリ領域の設定を確認し、データ保護のニーズに合わせて修正

するよう推奨しています。Oracle RMAN、フラッシュ・リカバリ領域およびアーカイブ・ログに

ついて、詳しくは『Oracle Database バックアップおよびリカバリ』ドキュメントを参照してく

ださい。Oracle Audit Vault Oracle Home は、ほかの Oracle Home 用の現在の手順を使用してバッ

クアップする必要があります。



付録 A. 監査証跡保守用スクリプト Rem Rem $Header: os_aud_cleanup_setup.sql 05-apr-2007.02:42:14 srirasub Exp $ Rem Rem os_aud_cleanup_setup.sql Rem Rem Copyright (c) 2007, Oracle.All rights reserved. Rem Rem NAME Rem os_aud_cleanup_setup.sql - <one-line expansion of the name> Rem Rem DESCRIPTION Rem <short description of component this file declares/defines> Rem Rem NOTES Rem <other useful comments, qualifications, etc.> Rem Rem MODIFIED (MM/DD/YY) Rem srirasub 04/04/07 - Created Rem -- The following arguments are required to run this procedure -- -- 1. Path of directory where temporary files can be written (eg. /tmp) -- 2. Threshold (in no. of days) for deleting old audit files (eg. 7) -- 3. $ORACLE_HOME -- -- SET ECHO ON SET FEEDBACK 1 SET NUMWIDTH 10 SET LINESIZE 80 SET TRIMSPOOL ON SET TAB OFF SET PAGESIZE 100 create or replace procedure source_os_audit_cleanup as output_file utl_file.file_type; cursor c1 is select unique(audsid) from sys.V$SESSION; sessid number; aud_dest varchar2(1000); ver varchar2(100); begin execute immediate 'create or replace directory os_aud_cleanup_dir as ''&1'''; output_file := utl_file.fopen ('OS_AUD_CLEANUP_DIR','session_list.txt', 'W'); open c1; loop fetch c1 into sessid; exit when c1%notfound;



utl_file.put_line (output_file, sessid); end loop;

utl_file.fclose(output_file); select value into aud_dest from v$parameter where name = 'audit_file_dest'; select version into ver from v$instance; if ver like '10%' or ver like '11%' then execute immediate 'BEGIN dbms_scheduler.run_job(''OS_CLEANUP_PERL'',TRUE); END;'; else if ver like '9%' then output_file := utl_file.fopen ('OS_AUD_CLEANUP_DIR','audit_dest.txt', 'W'); utl_file.put_line (output_file, aud_dest); utl_file.fclose(output_file);

end if; end if;

end; / Declare ver varchar2(100); argv3 varchar2(1000); argv2 varchar2(1000); aud_dest varchar2(1000); Begin select version into ver from v$instance; select value into aud_dest from v$parameter where name = 'audit_file_dest'; argv2 := '&1' || '/' || 'session_list.txt'; argv3 := '&3' || '/demo/os_aud_cleanup.pl'; if ver like '10%' or ver like '11%' then execute immediate 'BEGIN DBMS_SCHEDULER.CREATE_JOB (JOB_NAME => ''OS_CLEANUP_PERL'', JOB_TYPE => ''executable'', JOB_ACTION => ''' || argv3 || ''', NUMBER_OF_ARGUMENTS => 3, ENABLED => FALSE); END;'; execute immediate 'BEGIN DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE ( job_name => ''OS_CLEANUP_PERL'', argument_position => 1, argument_value => ''' || aud_dest || '''); END;'; execute immediate 'BEGIN DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE ( job_name => ''OS_CLEANUP_PERL'', argument_position => 2,



argument_value =>''' || argv2 || '''); END;'; execute immediate 'BEGIN DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE ( job_name => ''OS_CLEANUP_PERL'', argument_position => 3, argument_value => ''&2''); END;'; execute immediate 'BEGIN DBMS_SCHEDULER.CREATE_JOB (JOB_NAME => ''AUDIT_OS_CLEANUP'', JOB_TYPE => ''STORED_PROCEDURE'', JOB_ACTION => ''sys.source_os_audit_cleanup'', REPEAT_INTERVAL => ''FREQ=DAILY;INTERVAL=1'', ENABLED => TRUE, COMMENTS => ''Cleaup Job Run Daily''); END;'; end if;

End; / declare ver varchar2(100); begin select version into ver from v$instance; if ver like '9%' then sys.source_os_audit_cleanup; end if;

end; / exit; #!/usr/local/bin/perl # # $Header: os_aud_cleanup.pl 05-apr-2007.01:47:12 srirasub Exp $ # # os_aud_cleanup.pl # # Copyright (c) 2007, Oracle.All rights reserved. # # NAME # os_aud_cleanup.pl - OS AUDit trail CLEANUP # # DESCRIPTION # Perl Script to clean audit trails. # # NOTES # <other useful comments, qualifications, etc.> # # MODIFIED (MM/DD/YY) # srirasub 04/04/07 - Creation #



$aud_dir = $ARGV[0]; %mon2num = qw( jan 1 feb 2 mar 3 apr 4 may 5 jun 6 jul 7 aug 8 sep 9 oct 10 nov 11 dec 12 ); #list of all files in audit dir if(!opendir(DIR, $aud_dir)) { $oh = $ENV{'ORACLE_HOME'}; $aud_dir =~ s/¥?/$oh/g; if(!opendir(DIR, $aud_dir)) { exit -1; } } @files = grep(/ora_.*aud$/,readdir(DIR)); closedir(DIR); #get timestamp to compare $tstamp = time(); $tstamp1 = localtime; #get list of active stession from db $session_list = $ARGV[1]; open(INFO, $session_list); @sessids = <INFO>; close(INFO); #days parameter $day_upper_limit = $ARGV[2]; #go thru all the files in audit destination directory foreach $file (@files) { $flag = 1; $file_name = $aud_dir. '/' . $file; open(INFO, $file_name); @lines = <INFO>; close(INFO); #check each line for matchin session foreach $line (@lines) { foreach $sess (@sessids) { $sessionid = $sess; chop($sessionid); $reg = 'SESSIONID: "' . $sessionid . '"'; if($line =~ $reg) {



#this file cant be deleted as it has a session that #is active $flag = 0; } } $prev = $line; } #since this file doesnt have any active session, it can be deleted if($flag == 1) { $flag2 = 1; foreach $line (@lines) { $reg = 'SESSIONID: "'; if($line =~ $reg) { chop($prev); $days_diff = day_diff($prev, $tstamp1 ); if($days_diff < $day_upper_limit) { #this file cant be deleted as it has a session that #doesnt satisfy the min-days criteria $flag2 = 0; } } $prev = $line; } if($flag2 == 1) { #delete the file unlink("$file_name"); } } } #subroutine to return difference between two dates. sub day_diff { $ts1 = $_[0]; $ts2 = $_[1]; $ts1 =~ s/¥s¥s*/ /g; $ts2 =~ s/¥s¥s*/ /g; ($a1,$a2,$a3,$a4,$a5,$a6,$a7) = split(/[ :]/, $ts1); ($b1,$b2,$b3,$b4,$b5,$b6,$b7) = split(/[ :]/, $ts2); $diff_mon = &month_difference($a2, $b2); $days = (($b7-$a7)*365) + ($diff_mon)*30 + ($b3-$a3); $days; }



#subroutine to return difference between two month sub month_difference { $mon1 = $mon2num{ lc substr($_[0], 0, 3) }; $mon2 = $mon2num{ lc substr($_[1], 0, 3) }; $diff = $mon2-$mon1; $diff; } -- These scripts can be run directly on 9i, 10gR1 and 10gR2 -- scripts should be run as sys -- the jobs run daily -- For DBMS_JOB, -- ALTER SYSTEM SET job_queue_processes=1; -- this may be required to run the jobs automatically -- the value is set to 0 in most systems -- any number in the range [1,1000] is valid. create or replace procedure source_audit_cleanup(days number) as ver varchar2(100); begin select version into ver from v$instance; if ver like '10%' or ver like '11%' then execute immediate 'delete from sys.aud$ where extract(day from sys_extract_utc(systimestamp)-ntimestamp#) > ' || days || ' and sessionid not in (select audsid from sys.V$SESSION)'; execute immediate 'delete from sys.fga_log$ where extract(day from sys_extract_utc(systimestamp)-ntimestamp#) > ' || days || ' and sessionid not in (select audsid from sys.V$SESSION)'; else if ver like '9%' then execute immediate 'delete from sys.aud$ where extract(day from sys_extract_utc(systimestamp)-timestamp#) > ' || days || ' and sessionid not in (select audsid from sys.V$SESSION)'; execute immediate 'delete from sys.fga_log$ where extract(day from sys_extract_utc(systimestamp)-timestamp#) > ' || days || ' and sessionid not in (select audsid from sys.V$SESSION)';

end if; end if;



end; / -- the parameter for no. of days is configurabl -- change the value of "no_of_days" (current value = 7) Declare ver varchar2(100); jobno binary_integer; ------ no_of_days number := 7; ------ begin select version into ver from v$instance; if ver like '10%' or ver like '11%' then execute immediate 'begin DBMS_SCHEDULER.CREATE_JOB ( JOB_NAME => ''AUDIT_CLEANUP'', JOB_TYPE => ''PLSQL_BLOCK'', JOB_ACTION => ''begin sys.source_audit_cleanup(days => ' || no_of_days ||'); end;'', REPEAT_INTERVAL => ''FREQ=DAILY;INTERVAL=1'', ENABLED => TRUE, AUTO_DROP => FALSE, COMMENTS => ''Cleaup Job Run Daily''); end;'; else if ver like '9%' then execute immediate 'begin dbms_job.submit(job => :jobno, what => ''begin sys.source_audit_cleanup('|| no_of_days ||'); end;'', interval => ''SYSDATE + 1''); end ;' using in out jobno; dbms_output.put_line('Job No ' || jobno);

commit; end if;

end if; end; /



付録 B. データベース・ソース監査の設定 Rem Rem Copyright (c) 2007, Oracle.All rights reserved. Rem Rem DESCRIPTION Rem Secure configuration settings for the database include audit REM settings (enabled, with admin actions audited. Rem -- Turn on auditing options Audit alter any table by access; Audit create any table by access; Audit drop any table by access; Audit Create any procedure by access; Audit Drop any procedure by access; Audit Alter any procedure by access; Audit Grant any privilege by access; Audit grant any object privilege by access; Audit grant any role by access; Audit audit system by access; Audit create external job by access; Audit create any job by access; Audit create any library by access; Audit create public database link by access; Audit exempt access policy by access; Audit alter user by access; Audit create user by access; Audit role by access; Audit create session by access; Audit drop user by access; Audit alter database by access; Audit alter system by access; Audit alter profile by access; Audit drop profile by access;



Oracle Audit Vault ベスト・プラクティス 2007 年 11 月著者：Tammy Bednar 寄稿者：Paul Needham, Vipul Shah Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口：電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 oracle.com Copyright © 2007, Oracle. All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに

記載される内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さ

らに、口述による明示または法律による黙示を問わず、特定

の目的に対する商品性もしくは適合性についての黙示的な

保証を含み、いかなる他の保証や条件も提供するものではあ

りません。オラクル社は本文書に関するいかなる法的責任も

明確に否認し、本文書によって直接的または間接的に確立さ

れる契約義務はないものとします。本文書はオラクル社の書

面による許可を前もって得ることなく、いかなる目的のため

にも、電子または印刷を含むいかなる形式や手段によっても

再作成または送信することはできません。 Oracle は米国 Oracle Corporation およびその子会社、関連

会社の登録商標です。その他の名称はそれぞれの会社の商標

です。

Oracle Audit Vault ベスト・プラクティス 29ページ

Oracle Corporation 発行「英語タイトル」の翻訳版です。

oracle audit vaultベスト・プラクティス...はじめに oracle audit...

Documents