| Oracle Databaseセキュリティ・ガイド 11g リリース1（11.1） E05730-05 |
|
 戻る |
 次へ |
この章の内容は、次のとおりです。
この項の内容は、次のとおりです。
拡張監査機能を提供するOracle Audit Vaultの詳細は、『Oracle Audit Vault管理者ガイド』を参照してください。
監査とは、選択したユーザー・データベース・アクション（データベース・ユーザーおよび非データベース・ユーザー両方からのアクション）を監視して記録する処理のことです。実行されたSQL文のタイプなどの個々のアクション、またはユーザー名、アプリケーション、時間などの様々な要因の組合せをベースとして使用できます。成功したアクティビティと失敗したアクティビティの両方を監査できます。監査を使用するには、監査を使用可能にし、ほとんどの場合は監査設定を作成します。監査対象のアクションは、データ・ディクショナリ表またはオペレーティング・システム・ファイルに記録されます。Windowsシステムでは、監査レコードをWindowsイベントビューアに表示できます。
監査を使用可能にすることをお薦めします。監査は、強固な内部制御を規定する有効な方法であるため、サイトでは米国サーベンス・オクスリー法（Sarbanes-Oxley Act）に定義されている法令順守要件を満たすことができます。監査を使用すると、ビジネス操作を監視でき、企業ポリシーから逸脱する可能性があるアクティビティを検出できます。この結果、データベースおよびアプリケーション・ソフトウェアへのアクセスが厳密に制御されるようになり、パッチが予定どおりに適用され、非定型の変更が防止されます。監査をデフォルトで使用可能にすることで、監査要員および特別監査要員に対する監査レコードを生成できます。選択的に監査を行い、ビジネス・コンプライアンスのニーズを満たしていることを確認してください。
監査は、一般的に次のアクティビティを実行するために使用します。
現行のアクションに対する今後のアカウンタビリティの有効化。特定のスキーマ、表または行に対して実行されるアクション、あるいは特定の内容に影響を与えるアクションなどがあります。
それぞれのアカウンタビリティに基づいた、ユーザー（または侵入者などの他者）による不適切なアクションの防止。
動作が不審なアクティビティの調査。たとえば、あるユーザーが表からデータを削除しようとした場合、セキュリティ管理者は、そのデータベースへのすべての接続と、そのデータベースにあるすべての表からの行の削除（削除が正常に実行されたかに関係なく）をすべて監査できます。
未認可ユーザーのアクションの監査人への通知。たとえば、未認可ユーザーによるデータの変更や削除、あるいは予想以上の権限がユーザーに付与されていることなどが通知されます。この通知は、ユーザー認可の再評価につながる可能性があります。
特定のデータベース・アクティビティに関するデータの監視と収集。たとえば、データベース管理者は、更新された表、実行された論理I/Oの回数、またはピーク時に接続していた同時実行ユーザーの数などに関する統計を収集できます。
認可またはアクセス制御の実装に関する問題の検出。たとえば、データは他の方法で保護されているため、監査レコードは生成されないと予測される監査ポリシーを作成できます。しかし、これらのポリシーで監査レコードが生成された場合は、他のセキュリティ制御が正しく実装されていないことがわかります。
コンプライアンスのための監査要件への対処。次のような法規に、監査に関連する一般的な要件が含まれています。
米国サーベンス・オクスリー法
米国の医療保険の相互運用性と説明責任に関する法律（Health Insurance Portability and Accountability Act、HIPAA）
自己資本の測定と基準に関する国際的統一化: 改訂された枠組（バーゼルII）（International Convergence of Capital Measurement and Capital Standards: a Revised Framework、Basel II）
日本の個人情報保護法
欧州連合のプライバシと電子通信に関する指令（European Union Directive on Privacy and Electronic Communications）
データベース監査が有効かどうかに関係なく、Oracle Databaseは常にデータベースに関連した特定の操作を監査し、オペレーティング・システム監査ファイルに書き込みます。 これは必須監査と呼ばれます。必須監査では、オペレーティング・システム監査証跡を使用可能にする際に使用するのと同じオペレーティング・システム・ディレクトリを使用します。デフォルトでは、UNIXシステムの場合、オペレーティング・システム監査ファイルは$ORACLE_HOME/admin/$ORACLE_SID/adumpディレクトリにあります。Windowsシステムの場合、この情報はOracle DatabaseによりWindowsイベントビューアに書き込まれます。データベース監査証跡のような他のタイプの監査を使用可能にした場合も、Oracle Databaseでは、このオペレーティング・システム・ファイルが必須監査に使用されます。
オペレーティング・システム監査ファイルでは、これらのタイプのアクティビティに対する完全なアーカイブ・メッセージが取得されます。このファイルの場所は、AUDIT_FILE_DEST初期化パラメータを使用して設定できます。詳細は、「オペレーティング・システム監査証跡のディレクトリの指定」を参照してください。
必須監査には、次の操作が含まれます。
データベースの起動。インスタンスを起動したオペレーティング・システム・ユーザー、そのユーザーの端末識別子、日時のタイム・スタンプを記述した監査レコードが生成されます。データベース監査証跡は起動処理が正常に完了するまで使用できないため、この監査レコードはオペレーティング・システム監査証跡に格納されます。
データ操作言語（DML）文。Oracle Databaseでは、SYS.AUD$およびSYS.FGA_LOG$に対するINSERT、UPDATE、MERGE、DELETEなどの文が標準監査証跡表SYS.AUD$に記録されます。このようなアクティビティが発生した表に対して監査が使用可能でない場合でも監査が実行されます。これらのアクティビティを調べるには、DBA_AUDIT_TRAILビューおよびDBA_COMMON_AUDIT_TRAILビューを問い合せます。
データベースの停止。インスタンスを停止したオペレーティング・システム・ユーザー、そのユーザーの端末識別子および日時のタイム・スタンプを記述した監査レコードが生成されます。
AUDIT_SYSLOG_LEVEL初期化パラメータが設定されている場合は、ある種のデータベース関連アクションがUNIXのsyslogに書き込まれます。（syslog監査証跡については、「syslog監査証跡を使用したUNIXシステムのシステム管理者の監査」を参照）。これらのアクティビティは、AUDIT_TRAIL初期化パラメータの設定に関係なくOracle Databaseによりオペレーティング・システム・ファイルに書き込まれます。
|
関連項目: オペレーティング・システムの監査証跡とsyslog監査証跡の詳細は、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。 |
監査はサイト自律型です。インスタンスでは、直接接続しているユーザーによって発行された文のみが監査されます。ローカルのOracle Databaseノードでは、リモート・データベースで発生するアクションを監査できません。
ベスト・プラクティスに関する次のガイドラインに従ってください。
原則として、コンプライアンス要件を満たす必要のある情報量を収集するための監査方針を設計します。ただし、セキュリティ上の最大の懸念の原因となるアクティビティに重点を置きます。たとえば、データベースの各表を監査するのは実際的ではありませんが、給与などの機密データを含んだ表列を監査するのは実際的です。標準監査とファイングレイン監査の両方に、監査対象となる特定のアクティビティに重点を置いた監査ポリシーの設計時に使用できるメカニズムが用意されています。
監査証跡データを定期的にアーカイブして削除します。詳細は、「監査証跡レコードのアーカイブおよび削除」を参照してください。
表9-1に、使用可能な様々な監査オプションを選択して使用するための手引きを示します。
表9-1 監査タイプの選択
| 必要な監査対象 | 監査タイプ |
|---|---|
|
デフォルト、セキュリティ関連のSQL文と権限 |
Oracle Databaseには一連のデフォルト監査設定が用意されており、セキュリティに関連する一般的なSQL文と権限に対して使用可能にすることができます。 監査レコードの場所: Oracle Databaseでは、これらの監査レコードは 実行する必要がある一般手順
|
|
一般的なアクティビティ |
SQL文、権限、スキーマ・オブジェクトおよびネットワーク・アクティビティを監査できます。たとえば、特定のユーザーが 監査レコードの場所: 監査レコードは、データベース監査証跡またはオペレーティング・システム監査証跡にXML形式で書き込むことができます。 実行する必要がある一般手順
|
|
特定、ファイングレイン・アクティビティ |
内容に基づいて、データ・アクセスとアクションを最も細かいレベルで監査できます。 監査レコードの場所: 監査レコードは、データベース監査証跡またはオペレーティング・システム監査証跡に書き込むことができます。 実行する必要がある一般手順
|
|
|
監査レコードの場所: Oracle Databaseでは、これらの監査レコードがオペレーティング・システム・ファイルにのみ書き込まれます。Windowsの場合、SYS監査レコードはデフォルトでWindowsイベント・ログに書き込まれます。UNIXシステムの場合、レコードをsyslogファイルに書き込むことができます。 実行する必要がある一般手順
|
新規データベースの作成時または既存データベースの変更時に、Database Configuration Assistant（DBCA）の「セキュリティ設定」ウィンドウを使用して、デフォルトのセキュリティ設定を使用可能または使用禁止にできます。これらの設定は使用可能にすることをお薦めします。デフォルトのセキュリティ設定を使用可能にした場合は、Oracle Databaseによってセキュリティに関連する最も一般的なSQL文および権限が監査されます。また、AUDIT_TRAIL初期化パラメータがDBに設定されます。別の監査オプション（監査証跡レコードをオペレーティング・システム・ファイルに書き込む場合はOSなど）を使用するように決定した場合は、そのように設定できます。Oracle Databaseでは、デフォルトで監査対象である権限が引き続き監査されます。AUDIT_TRAILパラメータをNONEに設定して監査を使用禁止にすると、監査は実行されません。
Oracle Databaseでは、デフォルトでAUDIT ROLE SQL文が監査されます。デフォルトで監査される権限は、次のとおりです。
ALTER ANY PROCEDURE |
CREATE ANY JOB |
DROP ANY TABLE |
ALTER ANY TABLE |
CREATE ANY LIBRARY |
DROP PROFILE |
ALTER DATABASE |
CREATE ANY PROCEDURE |
DROP USER |
ALTER PROFILE |
CREATE ANY TABLE |
EXEMPT ACCESS POLICY |
AUDIT ROLE BY ACCESS |
CREATE EXTERNAL JOB |
GRANT ANY OBJECT PRIVILEGE |
ALTER SYSTEM |
CREATE PUBLIC DATABASE LINK |
GRANT ANY PRIVILEGE |
ALTER USER |
CREATE SESSION |
GRANT ANY ROLE |
AUDIT SYSTEM |
CREATE USER |
|
AUDIT SYSTEM BY ACCESS |
DROP ANY PROCEDURE |
SQL文および権限の監査を個別に制御するには、AUDIT文とNOAUDIT文を使用します。詳細は、「SQL文の監査」および「権限の監査」を参照してください。
この項の内容は、次のとおりです。
この項の内容は、次のとおりです。
標準監査では、SQL文、権限、スキーマ・オブジェクトおよびネットワーク・アクティビティを監査します。監査を使用可能にするにはAUDIT SQL文を使用し、監査を使用禁止にするにはNOAUDIT文を使用します。監査レコードは、データベース監査証跡またはオペレーティング・システム監査ファイルに書き込むことができます。
ユーザーは、自分自身のスキーマ内のオブジェクトをAUDIT文を使用して監査できます。オブジェクトの監査を使用禁止にするには、NOAUDIT文を使用します。このタスクを実行するために追加権限は必要ありません。ユーザーは、AUDIT_TRAILパラメータの設定に関係なく、AUDIT文を実行して監査オプションを設定できます。監査が使用禁止になっている場合、次回使用可能にしたときに、Oracle Databaseでは、AUDIT文で設定した監査アクティビティが記録されます。標準監査を使用可能にする方法は、「標準監査証跡を使用可能および使用禁止にする方法」を参照してください。
次のことに注意してください。
データベース全体の標準監査は、セキュリティ管理者が使用可能または使用禁止にします。使用禁止の場合、監査レコードは作成されません。
データベース監査を使用可能にすると、個々の監査オプションが有効になります。認可されたデータベース・ユーザーは、自分の所有するデータベース・オブジェクトに対してこれらの監査オプションを設定できます。
データベースの監査機能が使用可能なときに、監査対象に設定されたアクションが発生すると、SQL文の実行フェーズ時または実行フェーズ後に監査レコードが生成されます。PL/SQLプログラム・ユニット内のSQL文は、プログラム・ユニットの実行時に必要に応じて個別に監査されます。
監査証跡レコードの生成と挿入は、ユーザー・トランザクションのコミットからは独立して実行されます。つまり、ユーザー・トランザクションがロールバックされても、監査証跡レコードはコミットされたままになります。
データベース・ユーザーがデータベースに接続した時点で有効になっていた文監査オプションと権限監査オプションは、そのセッションの持続期間中は有効です。セッション中に文監査または権限監査のオプションを設定または変更しても、そのセッション中は有効になりません。修正した文監査オプションまたは権限監査オプションは、カレント・セッションを終了し、新しいセッションを作成した時点で有効になります。
一方、オブジェクト監査オプションについて変更した内容は、カレント・セッションでただちに有効になります。
この項の内容は、次のとおりです。
標準監査証跡を使用可能にするには、AUDIT_TRAIL初期化パラメータを設定します。この設定によって、データベース監査証跡に監査証跡を作成するかどうか、オペレーティング・システム・ファイルに監査アクティビティを書き込むかどうか、監査を使用禁止にするかどうかが判別されます。
標準監査証跡を使用可能または使用禁止にするには、管理権限でSQL*Plusにログインし、ALTER SYSTEM文を使用します。 その後、データベース・インスタンスを再起動する必要があります。
AUDIT_TRAILパラメータの現在の値を調べるには、SQL*PlusでSHOW PARAMETERコマンドを使用します。
例9-1に、AUDIT_TRAILパラメータの設定を調べる方法を示します。
例9-1 AUDIT_TRAIL初期化パラメータの現在の値を調べる方法
SHOW PARAMETER AUDIT_TRAIL NAME TYPE VALUE ------------------------------------ ----------- ------- audit_trail string NONE
例9-2に、SQL*Plusにログインし、標準監査証跡を使用可能にして、データベース・インスタンスを再起動する方法を示します。
例9-2 標準監査証跡を使用可能にする方法
sqlplus "SYS/AS SYSDBA" Enter password: password Connected. SQL> ALTER SYSTEM SET AUDIT_TRAIL=DB, EXTENDED SCOPE=SPFILE; System altered. SQL> CONNECT SYS/AS SYSOPER Enter password: password Connected. SQL> SHUTDOWN Database closed. Database dismounted. ORACLE instance shut down. SQL> STARTUP ORACLE instance started.
この例では、SCOPE句が使用されています。これは、データベース・インスタンスがサーバー・パラメータ・ファイル（SPFILE）を使用して起動されているためです。サーバー・パラメータ・ファイルを使用したデータベースの起動は、データベース・インスタンスを起動する推奨の方法です。サーバー・パラメータ・ファイルを作成および構成する方法については、『Oracle Database管理者ガイド』を参照してください。
表9-2に、AUDIT_TRAIL初期化パラメータに使用できる設定を示します。
表9-2 AUDIT_TRAILパラメータの設定
| AUDIT_TRAILの値 | 説明 |
|---|---|
|
|
常にオペレーティング・システム監査証跡に書き込まれるレコードを除いて、監査レコードをデータベース監査証跡（
「データベース監査証跡の管理」も参照してください。 |
|
ALTER SYSTEM SET AUDIT_TRAIL=DB, EXTENDED SCOPE=SPFILE; ALTER SYSTEM SET AUDIT_TRAIL='DB','EXTENDED' SCOPE=SPFILE; ただし、 ALTER SYSTEM SET AUDIT_TRAIL='DB, EXTENDED' SCOPE=SPFILE; |
|
|
|
すべての監査レコードをオペレーティング・システム・ファイルに書き込みます。特に安全性の非常に高いデータベース構成を使用している場合は、
「オペレーティング・システム監査証跡の管理」も参照してください。 |
|
XML形式でオペレーティング・システム監査レコード・ファイルに書き込みます。 値 |
|
|
ALTER SYSTEM SET AUDIT_TRAIL=XML, EXTENDED SCOPE=SPFILE; ALTER SYSTEM SET AUDIT_TRAIL='XML','EXTENDED' SCOPE=SPFILE; ただし、 ALTER SYSTEM SET AUDIT_TRAIL='XML, EXTENDED' SCOPE=SPFILE; 値 |
|
|
|
標準監査を使用禁止にします。この値は、 |
次のことに注意してください。
オブジェクト監査を変更した場合、データベースの再起動は必要ありません。再起動が必要になるのは、すべての監査を使用禁止にするなど、全体的な変更が行われた場合のみです。
ファイングレイン監査またはSYS監査を使用可能にする場合、AUDIT_TRAILの設定は不要です。ファイングレイン監査の場合は、ファイングレイン監査ポリシーを必要に応じて追加および削除して、監視する特定の操作またはオブジェクトに適用します。AUDIT_SYS_OPERATIONSパラメータを使用すると、SYS監査を使用可能および使用禁止にできます。
標準監査を使用して監査するには、AUDIT SQL文を使用します。
表9-3に、AUDIT文を使用できるカテゴリを示します。
表9-3 標準監査レベルとその影響
| レベル | 影響 |
|---|---|
|
文 |
特定の型のデータベース・オブジェクトに影響を与える特定のSQL文または文のグループを監査します。たとえば、 |
|
権限 |
特定のシステム権限によって許可されるSQL文を監査します。たとえば、 |
|
オブジェクト |
|
|
ネットワーク |
ネットワーク・プロトコルの不測エラーまたはネットワーク・レイヤーの内部エラーを監査します。 |
文、権限およびスキーマ・オブジェクトの監査では、文の正常な実行、異常終了した実行、またはその両方の文実行を選択して監査できます。このため、監査対象の文が正常終了しなかった場合にも、アクションを監視できます。異常終了したSQL文を監視することで、アクセス違反や不当な処理を行っているユーザーを判別できます。ただし、異常終了したSQL文の原因はそのどちらでもない場合がほとんどです。
この監査方法は、監査証跡が減少するため特定のアクションに重点を置きやすくなるという点でも役立ちます。これにより、データベースの良好なパフォーマンスを維持できます。
オプションは、次のとおりです。
WHENEVER SUCCESSFUL句: この句を指定すると、監査対象の文の正常な実行のみが監査されます。
WHENEVER NOT SUCCESSFUL句: この句を指定すると、監査対象の文の異常終了した実行のみが監査されます。
異常終了した文の監査では、有効なSQL文を実行しても適切な認可がないために異常終了した場合や、存在しないスキーマ・オブジェクトを参照したために異常終了した場合にのみレポートが提供されます。有効ではなかったために異常終了した文は監査できません。
たとえば、異常終了した文の実行を監査するように権限監査オプションが設定されている場合は、対象のシステム権限を使用しても他の原因で異常終了した文が監査されます。1つの例として、CREATE TABLE監査条件を設定したが、指定した表領域に対する割当て制限が不十分だったためにCREATE TABLE文が異常終了した場合などがあります。
WHENEVER SUCCESSFULまたはWHENEVER NOT SUCCESSFULを省略した場合: これらの句を省略すると、Oracle Databaseでは監査対象の文の正常な実行と異常終了した実行の両方が監査されます。
次に例を示します。
AUDIT CREATE TABLE WHENEVER NOT SUCCESSFUL;
AUDIT文にACCESSまたはSESSIONオプションを含めると、発生した文の実行数を監査できます。どちらのオプションを指定した場合も、監査対象の文または操作の実行ごとに監査レコードが生成されます。この2つの監査オプションにより、次の情報が取得されます。
DDL文を監査するすべての文監査オプション
DDL文を監査するすべての権限監査オプション
BY ACCESSおよびBY SESSIONに設定すると、カーソル内で監査対象の操作が実行されるたびに、監査証跡に監査レコードが1つ挿入されます。カーソルを再利用させるイベントは、次のとおりです。
カーソルを再利用のためにオープン状態にしておく、Oracle Formsなどのアプリケーション
新しいバインド変数を使用したカーソルの継続実行
1つのカーソルを再利用するためにPL/SQLエンジンにより文が最適化される場合に、PL/SQLループ内で実行される文
監査は、カーソルが共有されているかどうかの影響を受けません。それぞれのユーザーは、カーソルの最初の実行時に自分の監査証跡レコードを作成します。
BY ACCESSとBY SESSIONの違いは、取得されたアクションがDBA_AUDIT_TRAILデータ・ディクショナリ・ビューに記録される方法にあります。
ACCESSオプション: DBA_AUDIT_TRAILビューのACTION列にアクション・コードが表示されます。
SESSIONオプション: DBA_AUDIT_TRAILビューのACTION列にSESSION REC列の内容が表示されます。
これらのオプションのいずれかを使用するには、AUDIT文にオプション名を追加します。次に例を示します。
AUDIT SELECT TABLE BY SESSION;
この使用例は、次のとおりです。
ユーザーjwardでデータベースに接続し、departmentsという表に対して5つのSELECT文を発行した後、そのデータベースとの接続を切断します。
ユーザーswilliamsでデータベースに接続し、departments表に対して3つのSELECT文を発行した後、そのデータベースとの接続を切断します。
1つの監査証跡に、SELECT文ごとに1レコードずつ、8件のレコードが記録されます。
文監査オプションと権限監査オプションでは、任意のユーザーが発行した文を監査するか、特定のユーザー・リストに含まれるユーザーが発行する文を監査するかを選択できます。特定のユーザーに限定すると、生成される監査レコードの数は最小限に抑えられます。
例9-3に、ユーザーscottとblakeが表やビューを問い合せたり更新するときに、ユーザー別に文を監査する方法を示します。
NOAUDIT文は、監査オプションを使用禁止にします。このオプションは、文監査オプション、権限監査オプションおよびオブジェクト監査オプションの設定を解除するために使用します。文監査オプションおよび権限監査オプションを設定するNOAUDIT文では、BY userまたはBY proxyオプションによってユーザーのリストを指定し、各監査オプションの適用範囲を限定できます。
NOAUDIT文では、WHENEVER句を使用して監査オプションを選択的に使用禁止にできます。この句の指定がない場合は、正常終了と異常終了のどちらの場合にも監査オプションは完全に使用禁止となります。
NOAUDIT文では、BY ACCESSまたはBY SESSION句はサポートされていません。このため、監査オプションの設定方法に関係なく、監査オプションの設定は適切なNOAUDIT文によって解除できます。
この項の内容は、次のとおりです。
SQL文監査とは、特定タイプのデータベース構造やスキーマ・オブジェクトに関するSQL文の関連グループに対する選択的な監査のことです。ただし、監査の対象として特定の構造やスキーマ・オブジェクトを指定することはできません。文監査のデフォルトの監査オプションはBY ACCESSです。
監査可能な文は、次のカテゴリに分類されます。
文監査では、監査の対象を拡大してすべてのデータベース・ユーザーのアクティビティを監査したり、対象を限定して特定のアクティビティ・リストのアクティビティのみを監査できます。
SQL文監査を使用可能にするには、AUDIT文を使用します。監査を使用可能にするには、AUDIT SYSTEMシステム権限が必要です。通常、このシステム権限はセキュリティ管理者にのみ付与されています。
例9-4に、SELECT TABLE SQL文の監査方法を示します。
存在しないオブジェクトへのユーザー接続または参照を監査する予定の場合は、次のガイドラインに従ってください。
ログイン時とログオフ時の接続と切断の監査。AUDIT SESSION文では、ログイン・イベントとログオフ・イベントごとに独立した監査レコードが生成されます。これにより、ユーザーに関係なく、データベースとの間で正常終了および異常終了した接続と切断をすべて監査できます。
次に例を示します。
AUDIT SESSION;
次の例に示すように、このオプションはユーザーごとに設定することもできます。
AUDIT SESSION BY jward, swilliams;
オブジェクトがないために異常終了した文の監査。AUDIT文のNOT EXISTSオプションは、ターゲット・オブジェクトがないために異常終了したSQL文すべての監査を指定します。
次に例を示します。
AUDIT NOT EXISTS;
SQL文監査を使用禁止にするには、NOAUDIT SQL文を使用します。監査を使用禁止にするには、AUDIT SYSTEMシステム権限が必要です。
例9-5に、NOAUDIT文を使用して監査を使用禁止にする例を示します。
例9-5 NOAUDITを使用してセッションおよびSQL文監査を使用禁止にする方法
NOAUDIT session;
NOAUDIT session BY preston, sebastian;
NOAUDIT DELETE ANY TABLE;
NOAUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE,
EXECUTE PROCEDURE;
例9-6に、NOAUDIT文を使用してすべての監査を使用禁止にする方法を示します。
この項の内容は、次のとおりです。
権限監査は、SELECT ANY TABLEなどのシステム権限を使用する文を監査します。この種の監査では、正常終了するために監査対象の権限を必要とするSQL文が記録されます。権限監査のデフォルトの監査オプションはBY ACCESSです。
任意のシステム権限の使用を監査できます。文監査と同様に、権限監査では、すべてのデータベース・ユーザーのアクティビティを監査したり、特定のデータベース・ユーザーのアクティビティのみを監査します。
文監査と権限監査の両方について類似の監査オプションを設定しても、生成される監査レコードは1つのみです。たとえば、文の句TABLEとシステム権限のCREATE TABLEの両方を監査すると、表が作成されるたびに監査レコードが1つのみ生成されます。
権限監査は、アクションが既存の所有者およびスキーマ・オブジェクト権限によってすでに許可されている場合は実行されません。権限監査がトリガーされるのは、権限が不十分な場合、つまりアクションを可能にする権限がシステム権限である場合のみです。
権限監査のそれぞれのオプションでは、特定タイプの文のみが監査され、関連する一連の文が監査されるわけではないため、権限監査の対象は文監査よりも限定されます。たとえば、文監査句TABLEでは、CREATE TABLE、ALTER TABLEおよびDROP TABLE文が監査されます。しかし、権限監査オプションCREATE TABLEでは、CREATE TABLE文のみが監査されます。これは、CREATE TABLE権限が必要なのはCREATE TABLE文のみであるためです。
『Oracle Database SQL言語リファレンス』のGRANT SQL文に関する項のシステム権限のリストを参照してください。
権限監査オプションは、対応するシステム権限と同じです。たとえば、DELETE ANY TABLE権限の使用を監査するためのオプションは、DELETE ANY TABLEです。
例9-7に、DELETE ANY TABLE権限の監査方法を示します。
DELETE ANY TABLEシステム権限の正常な使用の場合と異常終了した使用の場合をすべて監査するには、次の文を実行します。
AUDIT DELETE ANY TABLE;
すべての表に対する異常終了したSELECT、INSERTおよびDELETE文、およびEXECUTE PROCEDUREシステム権限の異常終了した使用を、全データベース・ユーザーに対して個々の監査対象文別にすべて監査するには、次の文を実行します。
AUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE
BY ACCESS
WHENEVER NOT SUCCESSFUL;
文監査オプションまたは権限監査オプションを設定するには、AUDIT SYSTEMシステム権限が必要です。通常、このシステム権限はセキュリティ管理者にのみ付与されています。
AUDIT文を使用して、複数層環境のクライアントのアクティビティを監査できます。複数層環境では、クライアントの識別情報をすべての層を通して保持できます。したがって、中間層アプリケーションがクライアントにかわって実行したアクションを監査できます。 これを行うには、AUDIT文にBY PROXY句を使用します。
この句には次のオプションがあります。
代理として指定した特定のプロキシによって発行されたSQL文の監査
指定したユーザーのかわりに実行された文の監査
任意のユーザーのかわりに実行されたすべての文の監査
中間層では、データベース・セッションでユーザーのクライアント識別情報を設定し、中間層アプリケーションでエンド・ユーザーのアクションを監査することもできます。そうすることにより、エンド・ユーザーのクライアント識別情報が監査証跡に記録されます。
例9-8に、クライアントjacksonのかわりに、プロキシ・アプリケーション・サーバーappserveによって発行されたSELECT TABLE文を監査する方法を示します。
この項の内容は、次のとおりです。
スキーマ・オブジェクト監査では、表やビューなど、監査対象のオブジェクトに対して実行されるアクションが監視されます。オブジェクト監査はすべてのユーザーに適用されますが、監査対象のオブジェクトのみに限定されます。ユーザーは、自分のスキーマ内のオブジェクトに対してAUDITおよびNOAUDIT文を使用できます。
You 表、ビュー、順序、スタンドアロンのストアド・プロシージャまたはストアド・ファンクションおよびパッケージを参照する文は監査できますが、パッケージ内の個々のプロシージャを参照する文は監査できません。
クラスタ、データベース・リンク、索引またはシノニムを参照する文は、直接監査できません。ただし、実表に影響を与える操作を監査することによって、これらのスキーマ・オブジェクトへのアクセスを間接的に監査できます。
スキーマ・オブジェクトを監査する場合、監査はデータベースのすべてのユーザーに適用されます。これらのオプションは、特定のユーザーのリストに対しては設定できません。監査対象のすべてのスキーマ・オブジェクトに対して、デフォルトのスキーマ・オブジェクト監査オプションを設定できます。
ビューとプロシージャ（ストアド・ファンクション、パッケージおよびトリガーを含む）の定義は、基礎となるスキーマ・オブジェクトを参照します。この依存性があるために、複数の監査レコードが生成される場合があるなど、ビューとプロシージャの監査には、固有の特性がいくつかあります。
ビューとプロシージャは、デフォルトの監査オプションも含め、ベース・スキーマ・オブジェクトで使用可能な監査オプションに依存します。これらのオプションは、結果のSQL文にも適用されます。
次の一連のSQL文について考えてみます。
AUDIT SELECT ON HR.EMPLOYEES;
CREATE VIEW employees_departments AS
SELECT employee_id, last_name, department_id
FROM employees, departments
WHERE employees.department_id = departments.department_id;
AUDIT SELECT ON employees_departments;
SELECT * FROM employees_departments;
このemployees_departmentsビューに対する問合せの結果、2つの監査レコードが生成されます。1つはemployees_departmentsビューの問合せについての監査レコード、もう1つは実表employeesの問合せ（employees_departmentsビューを介した間接的な問合せ）についての監査レコードです。実表departmentsのSELECT監査オプションは使用可能でないため、この表に対して問合せを実行しても監査レコードは生成されません。すべての監査レコードは、employees_departmentsビューの問合せを発行したユーザーに属します。
ビューやプロシージャの監査オプションは、そのビューまたはプロシージャが最初に使用され、共有プールに配置されたときに決まります。そのビューまたはプロシージャを削除して共有プールに再配置するまで、これらの監査オプションは設定されたままの状態です。スキーマ・オブジェクトを監査すると、キャッシュ内のスキーマ・オブジェクトが無効になるため、スキーマ・オブジェクトがキャッシュに再ロードされます。ベース・スキーマ・オブジェクトの監査オプションに対する変更は、共有プール内のビューとプロシージャには認識されません。
前述の例で、AUDIT SELECT ON HR.EMPLOYEES;文を削除すると、employees_departmentsビューを使用しても、EMPLOYEES表の監査レコードは生成されません。
表9-4に、Oracle Database 11g リリース1（11.1）で使用可能になった監査アクションを示します。
表9-4 Oracle Database 11g リリース1（11.1）で新たに使用可能になった監査アクション
| オブジェクトまたは要素 | 監査可能なアクション |
|---|---|
|
マイニング・モデル |
|
|
OLAP 1次ディメンション |
|
|
OLAPキューブ |
|
|
OLAPメジャー・フォルダ |
|
|
OLAP相互作用 |
|
|
エディション |
|
表9-5に、Oracle Database 11g リリース1（11.1）で使用可能になったシステム監査オプションを示します。
表9-5 Oracle Database 11g リリース1（11.1）で使用可能になったシステム監査オプション
| システム | 監査可能なアクション |
|---|---|
|
エディション |
|
|
1次ディメンション |
|
|
キューブ |
|
|
メジャー・フォルダ |
|
|
相互作用 |
|
AUDIT文を使用すると、オブジェクト監査を使用可能にできます。AUDITに有効なオブジェクト監査オプションと、各オプションが使用できるスキーマ・オブジェクトのタイプの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
ユーザーは、自分のスキーマ内にあるオブジェクトのオブジェクト監査オプションを設定できます。他のユーザーのスキーマ内にあるオブジェクトのオブジェクト監査オプションを設定したり、デフォルトのオブジェクト監査オプションを設定するには、AUDIT ANYシステム権限が必要です。通常、AUDIT ANY権限はセキュリティ管理者にのみ付与されています。
laurel.emp表に対する正常終了および異常終了したDELETE文をすべて監査するには、次の文を実行します。
AUDIT DELETE ON laurel.emp;
ユーザーjwardが所有するdept表に対する正常終了したすべてのSELECT、INSERTおよびDELETE文を監査するには、次の文を実行します。
AUDIT SELECT, INSERT, DELETE
ON jward.dept
WHENEVER SUCCESSFUL;
ON DEFAULT句を使用すると、AUDIT文の設定後に作成された新規オブジェクト（表、ビューおよび順序）に適用できます。次の例では、将来作成される新規オブジェクトが、異常終了したすべてのSELECT文について監査されます。
AUDIT SELECT
ON DEFAULT
WHENEVER NOT SUCCESSFUL;
オブジェクト監査を使用禁止にするには、NOAUDIT文を使用します。対応する監査オプションを使用禁止にするには、次の文を実行します。
NOAUDIT DELETE ON emp; NOAUDIT SELECT, INSERT, DELETE ON jward.dept;
emp表に対するオブジェクト監査オプションをすべて使用禁止にするには、次の文を実行します。
NOAUDIT ALL ON emp;
デフォルトのオブジェクト監査オプションをすべて使用禁止にするには、次の文を入力します。
NOAUDIT ALL ON DEFAULT;
このNOAUDIT文を発行する前に作成されたすべてのスキーマ・オブジェクトは、作成後にNOAUDIT文を使用して明示的に設定を変更しないかぎり、引き続き作成時に指定されたデフォルトのオブジェクト監査オプションが使用されます。
特定のオブジェクトのオブジェクト監査オプションを使用禁止にするには、そのスキーマ・オブジェクトの所有者であることが必要です。他のユーザーのスキーマ内にあるオブジェクトのオブジェクト監査オプションや、デフォルトのオブジェクト監査オプションを使用禁止にするには、AUDIT ANYシステム権限が必要です。オブジェクトのオブジェクト監査オプションを使用禁止にする権限を持っているユーザーは、他のユーザーによって設定されたオプションを変更できます。
作成される表の挿入や削除など、まだ存在しないオブジェクトに対する監査設定を作成できます。これには2つの方法があります。一方の方法は、AUDIT文で文監査オプションを使用することです。たとえば、将来の表に対するすべての挿入を監査するには、次のSQL文を実行します。
AUDIT INSERT TABLE BY ACCESS;
他方の方法は、ON DEFAULT句を使用してAUDIT文を起動することです。次に例を示します。
AUDIT ALL ON DEFAULT;
この文では、デフォルトで以降のすべてのオブジェクト作成文が監査されます。ONキーワードは、オブジェクト監査を指定します。ON DEFAULT句では、以降に作成されて次の文の影響を受けるオブジェクトの監査を構成します。
ALTER |
EXECUTE |
INSERT |
SELECT |
AUDIT |
GRANT |
LOCK |
UPDATE |
COMMENT |
FLASHBACK |
READ |
|
DELETE |
INDEX |
RENAME |
ON DEFAULTを特定のアクションに限定するには、次のような文を入力します。
AUDIT ALTER, DELETE ON DEFAULT;
監査オプションとAUDIT SQL文のON DEFAULT句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。デフォルトで監査対象となるオブジェクトを検索するには、ALL_DEF_AUDIT_OPTSデータ・ディクショナリ・ビューを問い合せます。
この項の内容は、次のとおりです。
AUDIT文を使用すると、ネットワーク・プロトコルの不測エラーまたはネットワーク・レイヤーの内部エラーを監査できます。ネットワーク監査では、ネットワーク上のクライアントとの通信中に発生するエラーが取得されます。これらは、SQL*Netドライバによりスローされたエラーです。ネットワーク・エラーにはいくつかの原因があります。たとえば、データベース・エンジニアがテストのために設定した内部イベントが原因で、ネットワーク・エラーが発生する場合があります。その他の原因には、予測される暗号化を作成または処理するために必要な情報をネットワークが検出できない場合など、暗号化の構成設定の競合があります。ネットワーク監査で検出されるエラー（ACTION 122 Network Errorなど）は、接続障害ではありません。ネットワーク監査では、ネットワーク上で送受信されるデータのみが考慮されます。
ネットワーク監査の監査レコードでは、監査レコードのCOMMENT_TEXTフィールドにクライアント（使用可能な場合）の認証タイプとSQL*Netアドレスが次の形式でリストされます。
Authenticated by: authentication_type; Client Address: SQLNetAddress_of_client
Client Address: SQLNetAddress_of_client部分は、この情報が使用可能な場合にのみ表示されます。
表9-6に、4つの一般的なエラー状況の解決方法を示します。
表9-6 監査可能なネットワーク・エラーの状況
| エラー | 原因 | アクション |
|---|---|---|
|
|
アルゴリズムの選択後、サーバーはアルゴリズムの表でその索引を見つけることができませんでした。アルゴリズムが（間接的に）このリストから選択されているため、処理ができません。 |
詳細を参照するには、トレースを使用可能にして操作を再実行します（通常、このエラーはユーザーには表示されません）。エラーが解消されない場合は、Oracleサポート・サービスまでご連絡ください。 |
|
|
Oracle Advanced Securityのアルゴリズム・リスト・パラメータが空です。 |
インストールされているアルゴリズムのうち、少なくとも1つのアルゴリズム名が含まれるようにリストを変更するか、インストールされているすべてのアルゴリズムが許容できない場合は、リスト全体を削除します。 |
|
|
Oracle Advanced Securityのアルゴリズム・リスト・パラメータに、認識されていないアルゴリズム名が含まれています。 |
アルゴリズム名を削除、スペルが間違っている場合はスペルを修正、あるいは欠落しているアルゴリズムのドライバをインストールします。 |
|
|
クライアントとサーバーには、暗号化またはデータ整合性、あるいはこれら両方についての共通のアルゴリズムがありません。 |
共通のアルゴリズム・セットを選択します。つまり、クライアント・アルゴリズムの選択肢の1つをサーバー・リストに追加するか、サーバー・リストの選択肢の1つをクライアント・アルゴリズムに追加します。 |
この例では、SYS.AUD$表に対して行われた変更の監査方法を示します。
手順は、次のとおりです。
ユーザーSYSとしてSQL*Plusにログインし、AS SYSDBA権限で接続します。
sqlplus "SYS/AS SYSDBA"
Enter password: password
Connected.
次のユーザーを作成します。
GRANT CREATE SESSION TO smith IDENTIFIED BY password;
passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。
ユーザーsmithに次の権限を付与します。
GRANT SELECT, INSERT, UPDATE, DELETE ON AUD$ TO smith; GRANT SELECT ON DBA_AUDIT_TRAIL TO smith;
このプロシージャの後の手順で使用する出力の書式を設定するために次のコマンドを入力します。
col username format a10 col action_name format a13 col owner format a7 col obj_name format a10
SQL*Plusの書式設定コマンドの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。
SYS.AUD$表の監査を使用可能にします。
AUDIT SELECT ON AUD$;
SYS.AUD$表を切り捨てます。
TRUNCATE TABLE AUD$;
TRUNCATE TABLE文を使用すると、SYS.AUD$表からすべてのレコードが削除され、表に割り当てられたエクステントが削除されます。大規模な表の場合は、TRUNCATE TABLEを使用した方が、DELETEを使用して表から行を削除するより処理時間が短縮されます。
情報の消失に備える場合は、監査証跡をアーカイブできます。詳細は、「データベース監査証跡のアーカイブおよび削除」を参照してください。
ユーザーsmithで接続します。
CONNECT smith
Enter password: password
Connected.
次の文を入力します。
SELECT COUNT(*) FROM SYS.AUD$;
COUNT(*)
---------
1
次のSELECT文を入力します。
SELECT USERNAME, ACTION_NAME, OWNER, OBJ_NAME FROM DBA_AUDIT_TRAIL WHERE ACTION NOT IN (100, 101); USERNAME ACTION_NAME OWNER OBJ_NAME ---------- ------------- ------- ---------- SMITH SELECT SYS AUD$
このSELECT文では、SYS.AUD$表の内容をリストするDBA_AUDIT_TRAILビューに、ユーザーsmithが実行したSELECT文が示されます。
SYS.AUD$表に対して次のUPDATE文を実行します。
UPDATE SYS.AUD$ SET USERID = 0; 3 rows updated.
手順3のSELECT文を繰り返し、変更された出力を確認します。
SELECT USERNAME, ACTION_NAME, OWNER, OBJ_NAME FROM DBA_AUDIT_TRAIL WHERE ACTION NOT IN (100, 101); USERNAME ACTION_NAME OWNER OBJ_NAME ---------- ------------- ------- ---------- 0 SELECT SYS AUD$ 0 SELECT SYS AUD$ SMITH UPDATE SYS AUD$
このように、SYS.AUD$表には、ユーザーsmithが実行した各アクションが記録されています。
SYS.AUD$表の行を削除します。
DELETE FROM SYS.AUD$; 4 rows deleted.
手順3のSELECT文を繰り返し、変更された出力を確認します。
SELECT USERNAME, ACTION_NAME, OWNER, OBJ_NAME FROM DBA_AUDIT_TRAIL WHERE ACTION NOT IN (100, 101); USERNAME ACTION_NAME OWNER OBJ_NAME ---------- ------------- ------- ---------- SMITH UPDATE SYS AUD$ SMITH DELETE SYS AUD$
ユーザーSYSとしてAS SYSDBA権限で接続します。
CONNECT SYS/AS SYSDBA
Enter password: password
SYS.AUD$表から監査を削除します。
NOAUDIT SELECT, INSERT, UPDATE, DELETE ON AUD$;
ユーザーsmithを削除します。
DROP USER smith;
この項の内容は、次のとおりです。
ファイングレイン監査を使用すると、特定の条件を定義するポリシーを作成できます。監査が行われるには、この条件が満たされる必要があります。これにより、データ・アクセスを内容に基づいて監視できます。 問合せと、INSERT、UPDATEおよびDELETE操作に対して詳細な監査を提供します。たとえば、中央の税務当局は、所員による権限外の閲覧を防止するために、どのデータがアクセスされたかを判断できる十分な詳細を使用して納税申告書へのアクセスを追跡する必要があります。特定の表に対して特定のユーザーによってSELECT権限が使用されたことを知るのみでは不十分です。ファイングレイン監査は、この詳細な機能を提供します。
通常、ファイングレイン監査ポリシーは、選択的監査の条件である、表オブジェクトに対する単純なユーザー定義SQL述語に基づいています。フェッチ中に行がポリシーの条件を満たすと、その問合せが監査対象となります。
ファイングレイン監査を使用すると、次のタイプのアクションを監査できます。
午後9時から午前6時の間、または土曜日と日曜日に表にアクセスする場合
社内ネットワーク外部のIPアドレスを使用する場合
表の列を選択または更新する場合
表の列の値を変更する場合
ファイングレイン監査では、監査対象の特定のアクションのみを格納するなど、より有効な監査証跡が作成されます。各表アクセスが記録された場合に発生する不要な情報は除外されます。ファイングレイン監査には、標準監査と比較して次の利点があります。
ブール条件のチェックを実行します。指定したブール条件と一致すると（表が土曜日にアクセスされているなど）、監査が行われます。
監査をトリガーしたSQLを取得します。監査が行われたSQL文と関連バインド変数の両方を取得できます。取得できるのは、スカラー列型のデータのみであることに注意してください。オブジェクト列、LOBまたはユーザー定義の列型のデータは取得できません。たとえば、次の問合せを考えてみます。
SELECT NAME FROM EMPLOYEE WHERE SSN = :1
この例で、:1が整数型でSSNの値が987654321の場合は、監査証跡でこの情報を取得できます。ただし、:1がBLOB、CLOB、オブジェクトまたはユーザー定義の型の場合、この情報は取得できません。
この機能を使用できるのは、DBMS_FGA PL/SQLパッケージのaudit_trailパラメータをDB+EXTENDEDまたはXML+EXTENDEDに設定してファイングレイン監査ポリシーを作成する場合です。
機密情報が含まれた列に特別な保護を追加します。給与または社会保障番号など、機密情報が格納されている可能性のある特定の関連列を監査できます。
イベント・ハンドラ機能を提供します。たとえば、夜中に変更されないようにする必要がある監査対象の列が更新された場合に、セキュリティ管理者にアラートを送信する関数を作成できます。
ファイングレイン監査を使用可能にするために初期化パラメータを設定する必要がありません。AUDIT_TRAILなどの初期化パラメータを設定するかわりに、DBMS_FGA PL/SQLパッケージを使用して、監視する特定の操作またはオブジェクトに適用するファイングレイン監査ポリシーを必要に応じて追加および削除します。
ファイングレイン監査のレコードは、SYS.FGA_LOG$表に格納されます。ファイングレイン監査ポリシーに関する情報の検索には、DBA_FGA_AUDIT_TRAILビューを問い合せることができます。DBA_COMMON_AUDIT_TRAILビューは、標準監査とファイングレイン監査の両方のログ・レコードを結合します。また、V$XML_AUDIT_TRAILビューを使用すると、XML形式のファイルに書き込まれたファイングレイン監査レコードを検索できます。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
|
注意:
|
ファイングレイン監査ポリシーを作成するには、DBMS_FGA PL/SQLパッケージに対するEXECUTE権限が必要です。パッケージは、SYSユーザーが所有します。
Oracle Databaseでは、SYS.FGA_LOG$に対するINSERT、UPDATE、MERGE、DELETEなど、データ操作言語（DML）のすべての文が表SYS.AUD$に記録されます。このようなアクティビティが発生した表に対して監査が使用可能になっていない場合でも監査が実行されます。これらのアクティビティを調べるには、DBA_FGA_AUDIT_TRAILビューおよびDBA_COMMON_AUDIT_TRAILビューを実行します。
監査ポリシーの作成時に、DBMS_FGA.ADD_POLICY.audit_trailパラメータ（AUDIT_TRAIL初期化パラメータではなく）を設定して、ファイングレイン監査の監査証跡の形式を指定します。このパラメータをXMLまたはXML+EXTENDEDに設定すると、レコードはXML形式でオペレーティング・システム・ファイルに書き込まれます。ファイングレイン監査レコードをSYS.FGA_LOG$表に書き込む場合は、DBMS_FGA.ADD_POLICY.audit_trailをDBまたはDB+EXTENDEDに設定します。監査レコードをオペレーティング・システム・ファイルに書き込むことが有益な理由のリストは、「オペレーティング・システム監査証跡の利点」を参照してください。
V$XML_AUDIT_TRAILビューを使用すると、DBAはSQL問合せを介してXMLファイルの監査レコードを使用できるため、使いやすさが向上します。このビューを問い合せると、AUDIT_FILE_DESTディレクトリ内のすべてのXMLファイル（.xml格納子を持つすべてのファイル）が解析され、リレーショナル表の形式で表示されます。
DBA_COMMON_AUDIT_TRAILビューには、標準およびファイングレイン監査レコードのV$XML_AUDIT_TRAIL動的ビューの内容が含まれます。
監査XMLファイルは、すべてのプラットフォームで.xml拡張子を持つファイルに格納されるため、動的ビューには、すべてのプラットフォームで監査情報が同じように表示されます。V$XML_AUDIT_TRAILビューの内容の詳細は、『Oracle Databaseリファレンス』を参照してください。
この項の内容は、次のとおりです。
ファイングレイン監査ポリシーを管理するには、DBMS_FGA PL/SQLパッケージを使用します。このパッケージを使用すると、SELECT、INSERT、UPDATEおよびDELETE文のすべての組合せを1つのポリシーに追加できます。 また、基礎となるアクションのINSERTおよびUPDATEを監査することによって、MERGE文も監査できます。MERGE文を監査するには、INSERTおよびUPDATE文に対するファイングレイン・アクセスを構成します。成功したMERGE操作についてポリシーごとにレコードが1つのみ生成されます。ファイングレイン監査ポリシーを管理するには、DBMS_FGAパッケージに対するEXECUTE権限が必要です。
監査ポリシーは、監査ポリシーを作成した表にバインドされます。この結果、ポリシーの変更は、アプリケーションごとにではなくデータベースで1回のみで済むため、監査ポリシーの管理が容易になります。また、データベースへの接続方法（接続元がアプリケーション、Webインタフェース、SQL*PlusやOracle SQL Developerのいずれであるか）に関係なく、ポリシーに影響を与えるアクションがすべて記録されます。
問合せから戻された行が定義した監査条件と一致すると、ファイングレイン監査証跡に監査エントリが挿入されます。このエントリでは、通常の監査証跡でレポートされるすべての情報が除外されます。つまり、TRUEと評価されたすべてのファイングレイン監査ポリシーに対して、1行の監査情報のみが監査証跡に挿入されます。
DBMS_FGAパッケージの構文の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』も参照してください。
ファイングレイン監査ポリシーを作成するには、DBMS_FGA.ADD_POLICYプロシージャを使用します。このプロシージャは、監査条件として提供された述語を使用して、監査ポリシーを作成します。表オブジェクトまたはビュー・オブジェクトに設定可能なファイングレイン・ポリシーの最大数は256です。Oracle Databaseでは、ポリシーはデータ・ディクショナリ表に格納されますが、SYSスキーマ内に存在しない表またはビューに関するポリシーを作成できます。
ファイングレイン監査ポリシーを作成後に変更することはできません。 ポリシーの変更が必要になった場合は、削除してから再作成します。
ADD_POLICYプロシージャの構文は、次のとおりです。
DBMS_FGA.ADD_POLICY( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2, audit_condition VARCHAR2, audit_column VARCHAR2, handler_schema VARCHAR2, handler_module VARCHAR2, enable BOOLEAN, statement_types VARCHAR2, audit_trail BINARY_INTEGER IN DEFAULT, audit_column_opts BINARY_INTEGER IN DEFAULT);
次のように値を指定します。
object_schema: 監査するオブジェクトのスキーマを指定します。
object_name: 監査するオブジェクトの名前を指定します。
policy_name: 作成するポリシーの名前を指定します。
audit_condition: 行のブール条件を指定します。NULLの指定が可能です。詳細は、「特定の列および行の監査」を参照してください。
audit_column: 監査対象の1つ以上の列（非表示列も含む）を指定します。NULLを指定するかまたは省略すると、すべての列が監査されます。
handler_schema: ポリシーに違反した場合の応答のトリガーにアラートが使用される場合は、イベント・ハンドラが含まれているスキーマの名前を指定します。「例: ファイングレイン監査ポリシーへのアラートの追加」も参照してください。
handler_module: イベント・ハンドラの名前を指定します。
enable: TRUEまたはFALSEを使用してポリシーを使用可能または使用禁止にします。省略した場合、ポリシーは使用可能になります。
statement_types: 監査するSQL文を指定します。
audit_trail: ファイングレイン監査レコードの宛先（DBまたはXML）を指定します。LSQLTEXTおよびLSQLBINDをFGA_LOG$に移入するかどうかも指定します。
audit_column_opts: audit_columnパラメータで複数の列が指定されている場合は、すべての列を監査するか特定の列を監査するかを決定します。詳細は、「特定の列および行の監査」を参照してください。
ADD_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
例9-9に、表HR.EMPLOYEESに対する文INSERT、UPDATE、DELETEおよびSELECTを監査する方法を示します。この例では、audit_column_optsパラメータが必須パラメータではないため省略されていることに注意してください。
例9-9 DBMS_FGA.ADD_POLICYを使用してファイングレイン監査ポリシーを作成する方法
BEGIN DBMS_FGA.ADD_POLICY( object_schema => 'hr', object_name => 'employees', policy_name => 'chk_hr_employees', audit_condition => NULL, audit_column => NULL, handler_schema => NULL, handler_module => NULL, enable => TRUE, statement_types => 'INSERT, UPDATE, SELECT, DELETE', audit_trail => DB+EXTENDED); END;
この時点で、DBA_AUDIT_POLICIESビューを問い合せすると、新しいポリシーがリストされることを確認できます。
SELECT POLICY_NAME FROM DBA_AUDIT_POLICIES; POLICY_NAME ------------------------------- CHK_HR_EMPLOYEES
その後、次のようなSQL文を発行すると、監査イベント・レコードが記録されます。
SELECT count(*) FROM hr.employees WHERE commission_pct = 20 and salary > 4500; SELECT salary FROM hr.employees WHERE department_id = 50; DELETE from hr.employees WHERE salary > 1000000;
特定の列および行の監査
条件が一致した場合に特定の列（関連列とも呼ばれます）を監査対象にすることによって、監査の動作を調整できます。これを実行するには、audit_columnパラメータを使用して、機密情報が含まれた列を1つ以上指定します。また、audit_conditionパラメータを使用してブール条件を定義すると、特定の行のデータを監査できます。
例9-9では、部門50に属するユーザーがsalaryおよびcommission_pct列にアクセスしようとした場合に監査が実行されます。
audit_condition => 'department_id = 50', audit_column => 'salary,commission_pct,'
この例からわかるように、この機能は非常に有益です。この機能を使用すると、監査対象の特に重要なタイプのデータを正確に指定できるのみでなく、社会保障番号、給与、病歴などの機密データが含まれる列の保護が強化されます。
audit_columnに複数の列がリストされている場合は、audit_column_optsパラメータを使用すると、文の監査が、audit_columnパラメータで指定されたいずれかの列が問合せで参照されたときに実行されるか、またはすべての列が参照されたときにのみ実行されるかを指定できます。次に例を示します。
audit_column_opts => DBMS_FGA.ANY_COLUMNS, audit_column_opts => DBMS_FGA.ALL_COLUMNS,
関連列を指定しない場合、監査はすべての列に適用されます。
監査条件に対するNULLの使用
指定列（audit_column）に影響を与える指定アクション（statement_types）の監査が確実に行われるようにするには、audit_conditionパラメータにNULLを指定（または指定を省略）します。この指定はTRUEとして解釈されます。NULLを指定するのみで、指定列（audit_column）に影響を与える指定アクション（statement_types）が監査されます。
次のガイドラインに従ってください。
監査条件として1=1は入力しないでください。この機能は使用されなくなったため、必要な結果が生成されません。 NULLを指定すると、行が処理されなかった場合にも監査が実行されるため、ポリシーが設定されたaudit_columnですべてのアクションが監査されます。
NULLの指定に空文字列は使用しないでください。空文字列の使用はNULLと等価ではなく、このポリシーが設定された表のすべてのアクションの監査が確実に行われるとはかぎりません。
監査条件にNULLを指定するか、何も指定しない場合は、そのポリシーが設定された表に対するアクションが行われると、行が戻されるかどうかに関係なく監査レコードが作成されます。
ファイングレイン監査ポリシーを使用禁止にするには、DBMS_FGA.DISABLE_POLICYプロシージャを使用します。DISABLE_POLICYの構文は、次のとおりです。
DBMS_FGA.DISABLE_POLICY( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2 );
例9-10に、例9-9で作成したファイングレイン監査ポリシーを使用禁止にする方法を示します。
例9-10 ファイングレイン監査ポリシーを使用禁止にする方法
DBMS_FGA.DISABLE_POLICY( object_schema => 'hr', object_name => 'employees' policy_name => 'chk_hr_employees');
DISABLE_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
例9-11に、DBMS_FGA.ENABLE_POLICYプロシージャを使用して、chk_hr_employeesポリシーを再度使用可能にする方法を示します。
例9-11 ファイングレイン監査ポリシーを使用可能にする方法
DBMS_FGA.ENABLE_POLICY( object_schema => 'hr', object_name => 'employees', policy_name => 'chk_hr_employees' enable => 'true');
ENABLE_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
例9-12に、DBMS_FGA.DROP_POLICYプロシージャを使用して、ファイングレイン監査ポリシーを削除する方法を示します。
例9-12 ファイングレイン監査ポリシーを削除する方法
DBMS_FGA.DROP_POLICY( object_schema => 'hr', object_name => 'employees', policy_name => 'chk_hr_employees');
DROP_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ユーザー（または侵入者）がポリシーに違反した場合に実施されるアラートをファイングレイン監査ポリシーに追加できます。 最初にアラートを生成するプロシージャを作成し、次のADD_POLICYパラメータを使用して、ユーザーがこのポリシーに違反した場合にこの関数をコールする必要があります。
handler_schema: ハンドラ・イベントが格納されるスキーマ
handler_module: イベント・ハンドラの名前
アラートは、環境に最適な形式（電子メールやページャの通知、特定のファイルまたは表の更新など）で実施できます。アラートを作成すると、California Senate Bill 1386などの特定のコンプライアンス規制を満たすことも可能です。この例では、ユーザーのアクションを別の表に書き込みます。
たとえば、ある社員が高給の同僚の給与を検索しようとしたとします。監査ポリシーをそのまま使用すると、このアクションはすぐに記録されます。社員が過度に詮索好きな行動をとっていることを管理者に通知するには、この情報を記録するプロシージャを作成して、このプロシージャをコールするように監査ポリシーを作成します。
ユーザーSYSでログインし、AS SYSDBA権限を使用して接続します。
sqlplus "SYS/AS SYSDBA""
Enter password: password
sysadmin_fgaアカウントを作成します。このアカウントでファイングレイン監査ポリシーを作成します。
GRANT CREATE SESSION, DBA TO sysadmin_fga IDENTIFIED BY password;
GRANT SELECT ON HR.EMPLOYEES TO sysadmin_fga;
GRANT EXECUTE ON DBMS_FGA TO sysadmin_fga;
passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。
この例ではサンプル・ユーザーHRも使用するため、DBA_USERSデータ・ディクショナリ・ビューを問い合せて、HRがロックされていたり、期限切れになっていないことを確認します。
SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'HR';
DBA_USERSビューに、ユーザーHRがロックされて期限切れになっていると表示された場合は、SYSDBA権限を持つユーザーSYSとしてログインし直してから、次の文を入力して、HRアカウントのロックを解除し、新しいパスワードを作成します。
ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY password;
安全なパスワードを入力します。セキュリティを向上させるため、以前のリリースのOracle Databaseと同じパスワードをHRアカウントに指定しないでください。パスワードを作成するための最低要件は、「パスワードの最低要件」を参照してください。
ユーザーsysadmin_fgaで接続します。
CONNECT sysadmin_fga
Enter password: password
chk_hr_empポリシーに対する違反を記録する表を作成します。
CREATE TABLE emp_violations ( username VARCHAR(20), userhost VARCHAR(20), time TIMESTAMP);
アラートを生成するプロシージャを作成します。
CREATE OR REPLACE PROCEDURE emp_violations_alert (
hr_schema VARCHAR2,
employees_table VARCHAR2,
hr_policy VARCHAR2)
AS
BEGIN
INSERT INTO sysadmin_fga.emp_violations (
username, userhost, time)
SELECT user, sys_context('userenv','terminal'), sysdate FROM DUAL;
END emp_violations_alert;
/
次の構文を使用して、アラート・プロシージャを作成する必要があります。
PROCEDURE fname ( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2 ) AS ...
次のように値を指定します。
fnameは、プロシージャ名です。
object_schemaは、監査される表のスキーマの名前です。
object_nameは、監査される表の名前です。
policy_nameは、規定するポリシーの名前です。
chk_hr_empポリシーをファイングレイン監査ポリシーとして次のように作成します。
BEGIN DBMS_FGA.ADD_POLICY ( object_schema => 'hr', object_name => 'employees', policy_name => 'chk_hr_emp', audit_condition => 'department_id = 50', audit_column => 'salary,commission_pct', handler_schema => 'sysadmin_fga', handler_module => 'emp_violations_alert', enable => TRUE, statement_types => 'INSERT, UPDATE, SELECT, DELETE', audit_trail => DBMS_FGA.XML + DBMS_FGA.EXTENDED, audit_column_opts => DBMS_FGA.ANY_COLUMNS); END; /
ユーザーHRでSQL*Plusに接続し、従業員表に対してSELECT文を実行します。
CONNECT HR
Enter password: password
Connected.
SELECT COUNT(*) FROM EMPLOYEES WHERE SALARY > 4500;
COUNT(*)
----------
60
SYSTEMとして接続し、HRが実行したSELECT文と同じ文を実行します（EMPLOYEES表をHRで修飾する必要がある点を除きます）。
CONNECT SYSTEM
Enter password: password
Connected.
SELECT COUNT(*) FROM HR.EMPLOYEES WHERE SALARY > 4500;
COUNT(*)
----------
60
ユーザーsysadmin_fgaで、emp_violations表を調べます。この表には2つの違反が含まれています。
CONNECT sysadmin_fga
Enter password: password
col username format a10
col userhost format a12
col time format a30
SELECT * FROM emp_violations;
USERNAME USERHOST TIME
---------- ------------ ------------------------------
HR SHOBEEN-PC 17-APR-08 03.30.47.000000 PM
SYSTEM SHOBEEN-PC 17-APR-08 03.53.18.000000 PM
このように、chk_hr_empポリシーに違反するユーザーは、管理権限のあるユーザーも含めてすべてemp_violations表に記録されます。
Oracle Databaseでは、監査関数は自律型トランザクションとして実行され、handler_module設定のアクションのみをコミットし、ユーザー・トランザクションはコミットしません。この関数はユーザーのSQLトランザクションには影響を与えません。
ファイングレイン監査レコードをアーカイブするには、INSERT INTO table SELECT ... FROM SYS.FGA_LOG$ ...などを使用して、関連するレコードを通常のデータベース表にコピーします。また、SYS.FGA_LOG$表をオペレーティング・システム・ファイルにエクスポートすることも可能です。Oracle Data Pump Exportを使用してSYS.FGA_LOG$表をオペレーティング・システム・ファイルにエクスポートする方法は、「データベース監査証跡のアーカイブおよび削除」を参照してください。
ファイングレイン監査レコードを削除するには、そのレコードをSYS.FGA_LOG$表から削除します。たとえば、すべてのファイングレイン監査レコードを削除するには、次の文を入力します。
DELETE FROM SYS.FGA_LOG$;
また、emp表の監査の結果として生成されたすべての監査レコードをファイングレイン監査証跡から削除するには、次の文を実行します。
DELETE FROM SYS.FGA_LOG$
WHERE obj$name='EMP';
次の方法で管理ユーザーを監査できます。
SYSで接続したユーザー（SYSDBAまたはSYSOPER権限を使用して接続したユーザーを含む）のセッションは、完全に監査できます。この機能を使用すると、AUDIT_TRAILパラメータがNONE、DBまたはDB, EXTENDEDに設定されていても、管理者ユーザーによるアクションはオペレーティング・システム・ファイルに書き込まれます。管理者ユーザーによるアクションをオペレーティング・システム監査ファイルに書き込む方が、SYS.AUD$表に書き込むよりも安全です。これは、管理ユーザーはこの表から不正な動作を示す行を削除できるためです。
ユーザーSYSDBAおよびSYSOPERの監査設定を構成する手順は、次のとおりです。
AUDIT_SYS_OPERATIONS初期化パラメータをTRUEに設定します。
TRUEに設定すると、システム管理者のアクティビティが、監査証跡が格納されるオペレーティング・システム・ファイルに記録されます。このパラメータでは、SYSDBAおよびSYSOPERが標準監査対象とは設定されません。かわりに、各文のSQLテキストがオペレーティング・システム監査証跡レコードのACTIONフィールドに書き込まれます。
システム管理者によるアクティビティをXMLファイルに書き込む場合は、AUDIT_TRAIL初期化パラメータをXMLまたはXML, EXTENDEDに構成します。
デフォルトでは、監査レコードはオペレーティング・システム・ファイルに書き込まれます。
これらの設定の詳細は、表9-2「AUDIT_TRAILパラメータの設定」を参照してください。「標準監査証跡を使用可能または使用禁止にする方法」も参照してください。
データベースを再起動します。
例9-13に、AUDIT_SYS_OPERATIONS初期化パラメータをTRUEに設定する方法を示します。この設定では、SYSが監査対象として指定されています。AUDIT_SYS_OPERATIONSのデフォルト設定はFALSEです。
その後、データベースを再起動します。Oracle Databaseでは、ユーザーSYSDBAおよびSYSOPERによって実行されて正常終了したアクションがすべて監査されます。
これらの監査レコードは、SYS.AUD$表ではなく監査証跡を含んだオペレーティング・システム・ファイルに書き込まれます。
WindowsではAUDIT_TRAIL初期化パラメータをOSに設定している場合、監査レコードはイベントビューアのログ・ファイルにイベントとして書き込まれます。どのオペレーティング・システムでも、AUDIT_TRAILをXMLまたはXML,EXTENDEDに設定すると、監査レコードはAUDIT_FILE_DEST初期化パラメータで指定したディレクトリにXMLファイルとして書き込まれます。
AUDIT_FILE_DEST初期化パラメータを指定しない場合、デフォルトの場所は、LinuxとSolarisでは$ORACLE_BASE/admin/$DB_UNIQUE_NAME/adump、Windowsでは$ORACLE_BASE¥admin¥$DB_UNIQUE_NAME¥adumpです。他のオペレーティング・システムについては、監査証跡に関するそれぞれのドキュメントを参照してください。
SYSが発行したすべてのSQL文が、AUDIT_TRAIL初期化パラメータの設定に関係なく無差別に監査されます。
次のSYSセッションを考えてみます。
CONNECT SYS/AS SYSDBA;
Enter password: password
ALTER SYSTEM FLUSH SHARED_POOL;
UPDATE salary SET base=1000 WHERE name='laurel';
SYSの監査が使用可能になっている場合は、ALTER SYSTEM文とUPDATE文の両方がオペレーティング・システム監査ファイルに次のように表示されます。
Thu May 24 12:58:00 2008 LENGTH : '139' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[8] 'laurel' CLIENT TERMINAL:[5] 'pts/5' STATUS:[1] '0'
それぞれの値の長さが各かっこ内に示されていることに注意してください。また、SYSおよび必須監査レコードの場合は、値が一重引用符で囲まれています。
SYSDBAで接続したユーザーはスーパーユーザー権限を使用できるため、データベース管理者にはこの接続を必要な場合にのみ使用することをお薦めします。データベース管理者は通常、日常的なメンテナンス・アクティビティを実行できます。これらのデータベース管理者は、DBAロールを持つ標準のデータベース・ユーザーであるか、または組織でカスタマイズされたDBAロール（mydbaやjr_dbaなど）を持つデータベース・ユーザーです。
UNIXシステムでは、syslog監査証跡を作成してシステム管理者のアクティビティを監査できます。
この項の内容は、次のとおりです。
「UNIXシステムについて監査されるアクティビティ」を参照してください。
オペレーティング・システム監査証跡のセキュリティ上の弱点は、データベース管理者のような権限を持つユーザーがデータベース監査レコードを変更または削除できるということです。このリスクを最低限に抑えるには、syslog監査証跡を使用できます。syslogは、ネットワークの様々なコンポーネントからの情報をログに記録するためのUNIXベース・システムでの標準プロトコルです。アプリケーションは、syslog()関数をコールして情報をsyslogデーモンに記録します。syslogデーモンが情報の記録先を判断します。syslogを構成し、情報の記録先としてファイルsyslog.conf、コンソールまたはリモートのログ専用ホストを指定できます（syslog.confファイルは構成にのみ使用されます）。また、情報が記録されたときに特定のユーザー・セットに警告するようにsyslogを構成することもできます。
Oracleプロセスなどのアプリケーションがsyslog()関数を使用して情報をsyslogデーモンに記録するため、権限を持つユーザーにはsyslogメッセージの記録先ファイル・システムへのアクセス権はありません。このため、syslog監査証跡を使用して格納された監査レコードは、オペレーティング・システムの監査証跡を使用して格納された監査レコードよりも安全に保護されます。権限を持つユーザーに対するファイル・システムへのアクセス権の制限に加えて、syslog監査証跡をセキュリティで保護するために、権限を持つユーザーもOracleプロセスも、監査レコードが書き込まれるシステムへのrootアクセスはできないようにする必要があります。
オペレーティング・システムの監査証跡レコードと同様に、Oracle Databaseでは、セキュリティを強化するためにsyslogレコードがエンコードされます。Oracle Audit Vaultをインストール済の場合は、Syslog Collectorを使用し、syslog監査レコードを抽出して中央のOracle Audit Vaultサーバーに転送できます。
表9-9に、エンコードされている情報とそのデコードされたバージョンの参照場所を示します。
表9-7 監査証跡レコードのエンコードされている情報
AUDIT_TRAIL初期化パラメータに値OSを割り当てます（「標準監査証跡を使用可能および使用禁止にする方法」を参照）。
次に例を示します。
ALTER SYSTEM SET AUDIT_TRAIL=OS SCOPE=SPFILE;
AUDIT_SYSLOG_LEVELパラメータを初期化パラメータ・ファイルinitsid.oraに手動で追加および設定します。
AUDIT_SYSLOG_LEVELパラメータは、AUDIT_SYSLOG_LEVEL=facility.priorityの形式で機能と優先度を指定するように設定します。
facility: メッセージをログに記録するオペレーティング・システムの一部を示します。指定できる値は、user、local0–local7、syslog、daemon、kern、mail、auth、lpr、news、uucpおよびcronです。
local0–local7の値は、syslogメッセージをカテゴリに分類できる事前定義のタグです。これらのカテゴリは、ログ・ファイルまたはsyslogユーティリティでアクセスできる宛先にできます。このようなタイプのタグの詳細は、syslogユーティリティのman pageを参照してください。
priority: メッセージの重大度を定義します。指定できる値は、notice、info、debug、warning、err、crit、alertおよびemergです。
syslogデーモンは、AUDIT_SYSLOG_LEVELパラメータの機能引数に割り当てられた値とsyslog.confファイルを比較し、情報の記録先を決定します。
たとえば、次の文では、機能をlocal1、優先度レベルをwarningとして識別します。
AUDIT_SYSLOG_LEVEL=local1.warning
監査ファイルの宛先をsyslog構成ファイル/etc/syslog.confに追加します。
たとえば、AUDIT_SYSLOG_LEVELをlocal1.warningに設定したとすると、次のように入力します。
local1.warning /var/log/audit.log
この設定では、すべての警告メッセージが/var/log/audit.logファイルに記録されます。
syslogログ出力を再起動します。
$/etc/rc.d/init.d/syslog restart
これで、すべての監査レコードがsyslogデーモンを介してファイル/var/log/audit.logに取得されます。
データベース・インスタンスを再起動します。
CONNECT SYS / AS SYSOPER
Enter password: password
Connected.
SQL> SHUTDOWN;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> STARTUP;
ORACLE instance started.
この項の内容は、次のとおりです。
監査レコードには、監査した操作、その操作を実行したユーザーおよび操作の日時などの情報が記録されます。 Oracle Databaseでは、データベース・ユーザーおよび非データベース・ユーザーの両方のアクションがSYS.AUD$表およびSYS.FGA_LOG$表に記録されます。 これらの表にあるCLIENTID列には、非データベース・ユーザーの名前が記録されます。 SYS.AUD$表のUSERID列とSYS.FGA_LOG$のDBUID列には、データベース・ユーザーのアカウントが保存されます。 非データベース・ユーザーの場合、USERIDおよびDBUID列には、非データベース・ユーザーがデータベースにアクセスできるように作成されたデータベース・ユーザー・アカウントが保存されます。 DBA_AUDIT_TRAIL、DBA_FGA_AUDIT_TRAILおよびDBA_COMMON_AUDIT_TRAILビューでは、この情報がCLIENT_ID、USERNAMEおよびDB_USER列に保存されます。
選択した監査タイプに応じて、監査レコードをデータ・ディクショナリ表（データベース監査証跡）またはオペレーティング・システム・ファイル（オペレーティング・システム監査証跡）に書き込むことができます。
監査レコードをデータベース監査証跡に書き込むように選択すると、デフォルト監査と標準監査の場合はSYS.AUD$表に、ファイングレイン監査の場合はSYS.FGA_LOG$表に、監査レコードが書き込まれます。この2つの表はどちらもSYSTEM表領域にあり、SYSスキーマの所有となっています。これらの表の内容は、次のデータ・ディクショナリ・ビューを問い合せることで確認できます。
SYS.AUD$の内容の場合はDBA_AUDIT_TRAIL
SYS.FGA_LOG$の内容の場合はDBA_FGA_AUDIT_TRAIL
SYS.AUD$とSYS.FGA_LOG$の両方の内容の場合はDBA_COMMON_AUDIT_TRAIL
SYS.AUD$およびSYS.FGA_LOG$表の内容の表示に使用できる他のデータ・ディクショナリ・ビューについては、「監査アクティビティに関する情報の検索」を参照してください。
監査レコードをオペレーティング・システム・ファイルに書き込むように選択した場合は、テキスト・ファイルまたはXMLファイルに書き込むことができます。監査XMLファイルの内容は、V$XML_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることで確認できます。
この項の内容は、次のとおりです。
Oracle Databaseでは、標準監査レコードは、SYS.AUD$表（DBA_AUDIT_TRAILまたはDBA_COMMON_AUDIT_TRAILビューを問い合せてアクセス可能）に書き込まれます。
データ・ディクショナリ内に事前に定義された監査証跡ビュー（DBA_AUDIT_TRAILなど）を使用して、選択した部分の監査証跡を表示できます。
Oracleのツール製品（Oracle Reportsなど）またはサード・パーティ製のツールを使用して、監査レポートを生成できます。
データベース監査証跡は、各Oracle Databaseのデータ・ディクショナリのSYSスキーマにあるAUD$（標準監査用）とFGA_LOG$（ファイングレイン監査用）の1組の表です。標準監査アクティビティとファイングレイン監査アクティビティの両方が記録されます。この表の情報を使用しやすくするため、DBA_AUDIT_TRAILなど、複数の事前定義済のビューが提供されています。監査に関連するすべてのビューについては、「監査アクティビティに関する情報の検索」を参照してください。
監査対象のイベントと設定されている監査オプションに応じて、データベース監査証跡には様々な種類の情報が記録されます。表9-8は、監査証跡に常に記録される列を示す部分的なリストです。これらの列で表すデータが使用可能な場合、データが対応する列に移入されます。特定の列については、監査レコード内の列名がカッコ内に示されています。オペレーティング・システム監査証跡の場合は、対応する列に「あり」と示された列のみに存在します。
表9-8 監査証跡レコードのデータ
| データベース監査証跡に移入されるデータ | オペレーティング・システム監査証跡での有無 |
|---|---|
|
（*）SQL文に使用されたバインド値（ある場合） |
脚注1 |
|
（*）SQLテキスト（監査をトリガーしたSQLテキスト） |
脚注1 |
|
操作の完了コード |
あり |
|
データベース・ユーザー名（ |
あり |
|
UTC（協定世界時）書式による日時のタイムスタンプ |
なし |
|
識別名 |
あり |
|
グローバル・ユーザーの一意ID |
なし |
|
インスタンス番号 |
なし |
|
アクセスされたスキーマ・オブジェクトの名前 |
あり |
|
オペレーティング・システムのログイン・ユーザー名（ |
あり |
|
実行または試行された操作（ |
あり |
|
プロセス番号 |
脚注2 |
|
プロキシ・セッションの監査ID |
なし |
|
SQL文のSCN（システム変更番号） |
なし |
|
セッション識別子 |
あり |
|
使用されたシステム権限（ |
あり |
|
端末識別子 |
あり |
|
トランザクションID |
なし |
脚注1: 表9-8でアスタリスク（*）が付いた列が監査レコードに表示されるのは、AUDIT_TRAIL初期化パラメータをDB, EXTENDEDまたはXML, EXTENDEDに設定した場合のみです。また、配列の場合、記録される値は、最後のバインド値セットのみです。
脚注2: UNIXシステムの場合、プロセス番号はProcessIdとして移入されます。Windowsシステムの場合、ラベルはProcessId:ThreadId（スレッドとして動作していない場合はProcessId）です。
|
注意: AUDIT_TRAIL初期化パラメータがXMLまたはXML, EXTENDEDに設定されている場合、標準監査レコードはXML形式でオペレーティング・システム・ファイルに送信されます。XMLは標準文書形式であるため、XMLデータを解析および分析できる多くのユーティリティがあります。 |
監査レコードのデータベースの宛先がいっぱいか使用できなくなったために新規レコードが入らなくなると、監査対象のアクションは完了できません。かわりにエラー・メッセージが生成され、アクションは監査されません。多くの場合、オペレーティング・システムのログを監査証跡の宛先として使用すると、アクションを完了できます。
監査証跡には、監査対象の文に関連するデータ値の情報は格納されません。たとえば、UPDATE文を監査しているときに、更新された行の新旧のデータ値は格納されません。ただし、ファイングレイン監査方法を使用すれば、この特別なタイプの監査を実行できます。
DBA_COMMON_AUDIT_TRAILビューは、標準監査とファイングレイン監査のログ・レコードを結合します。
フラッシュバック問合せ機能を使用すると、現在有効な監査ポリシーに従って、更新された行の新旧のデータ値を表示できます。フラッシュバックが、最初は別のポリシーに従っていた旧問合せに対する内容の場合でも、現在のポリシーが適用されます。現行のビジネス・アクセス・ルールが常に適用されます。
|
関連項目:
|
データベース監査証跡がいっぱいになり、これ以上監査レコードを挿入できなくなった場合は、監査証跡を削除しないかぎり、監査対象の文を正常に実行できません。Oracle Databaseでは、監査対象の文を発行するすべてのユーザーに対して警告が発行されます。このため、監査証跡の増加とサイズを制御する必要があります。
監査が使用可能で、監査レコードが生成されているときは、次の2つの要因によって監査証跡ファイルが増加します。
使用可能な監査オプションの数
監査対象の文の実行頻度
監査証跡の増加を制御するには、次の方法を使用します。
データベース監査を使用可能および使用禁止にします。使用可能にすると、監査レコードが生成されて監査証跡に格納されます。使用禁止の場合、監査レコードは生成されません。（一部のアクティビティは常に監査されることに注意してください。）
使用可能な監査オプションを選択的に絞り込みます。選択的な監査を実施すると、不要な監査情報が生成されず、監査証跡に格納されません。ファイングレイン監査を使用すると、特定の条件のみを選択的に監査できます。
オブジェクト監査を実行できるかを厳密に制御します。これには次の方法があります。
セキュリティ管理者がすべてのオブジェクトを所有し、AUDIT ANYシステム権限を他のユーザーには付与しない方法。また、すべてのスキーマ・オブジェクトを、対応するユーザーにCREATE SESSION権限がないスキーマに所属させることもできます。
すべてのオブジェクトを、実際のデータベース・ユーザーに対応していない（つまり、対応するユーザーにCREATE SESSION権限が付与されていない）スキーマに格納しておく方法。セキュリティ管理者のみにAUDIT ANYシステム権限を付与します。
どちらの方法でも、セキュリティ管理者がオブジェクト監査を完全に制御できます。
データベース監査証跡表（AUD$およびFGA_LOG$表）の最大サイズは、その表がデフォルトで格納されているSYSTEM表領域のデフォルトの記憶域パラメータによって決まります。データベース監査証跡が大きくなりすぎてSYSTEM表のパフォーマンスに影響することが懸念される場合は、データベース監査証跡表を別の表領域に移動することを検討します。
|
関連項目: 監査レコードをオペレーティング・システムの監査証跡に書き込んでいる場合の、オペレーティング・システム監査証跡の管理方法の詳細は、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。 |
疑わしいデータベース・アクティビティを監査する場合は、監査証跡のレコードの整合性を保護することによって、監査情報が正確かつ完全であることを保証する必要があります。
SYS.AUD$およびSYS.FGA_LOG$表に対してオブジェクト監査オプションを設定した結果として生成された監査レコードを監査証跡から削除できるのは、管理者権限で接続しているユーザーのみです。管理者も不正な使用について監査されることに注意してください。詳細は、「SYS管理ユーザーの監査」を参照してください。
データベース監査証跡を保護するには、次の方法もあります。
O7_DICTIONARY_ACCESSIBILITY初期化パラメータをFALSE（デフォルト）に設定します。これにより、SYSスキーマ内のオブジェクトを監査できるのはSYSDBA権限を持つユーザーのみとなります。デフォルトのインストールでは、O7_DICTIONARY_ACCESSIBILITYはFALSEに設定されています。
Oracle Database Vaultをインストール済の場合は、SYS.AUD$およびSYS.FGA_LOG$表を含むレルムを作成します。Oracle Database Vaultのレルムの詳細は、『Oracle Database Vault管理者ガイド』を参照してください。
アプリケーションで、通常のユーザー（SYSDBA以外のユーザー）にSYS.AUD$へのアクセス権を付与することが必要な場合があります。たとえば、監査レポート生成者は、可能性のある違反に関する日次レポートを生成するために、AUD$表へのアクセスを必要とします。また、多くのインストールでは、業務を分離するために個別の監査人ロールを設けています。
この場合、INSERT、UPDATE、MERGEおよびDELETEなどのDML文は常に監査され、SYS.AUD$表に記録されることに注意してください。これらのアクティビティを調べるには、DBA_AUDIT_TRAILビューおよびDBA_COMMON_AUDIT_TRAILビューを問い合せます。
SYS.AUD$に対するSELECT、UPDATE、INSERTおよびDELETE権限があるユーザーがSELECT操作を実行すると、監査証跡にその操作のレコードが記録されます。つまり、SYS.AUD$には、それ自体に対するSELECTアクションを識別する、row1などの行が記録されます。
ユーザーが後でSYS.AUD$のこの行を削除しようとした場合、このユーザーにはこのアクションを実行する権限があるため、DELETE操作は成功します。ただし、SYS.AUD$に対するこのDELETEアクションも監査証跡に記録されます。このタイプの監査の設定はセーフティ機能の役割を果たし、異常なアクションや不正なアクションを検出できる場合があります。実際のテスト例のログ・ファイルは、「例: SYS.AUD$表に対する変更の監査」を参照してください。
|
注意: SYS.AUD$表に対するDELETE、INSERT、UPDATEおよびMERGE操作は常に監査されており、このような監査レコードは削除できません。 |
この項の内容は、次のとおりです。
標準監査レコードは、DBA_AUDIT_TRAIL（SYS.AUD$表）に作成するかわりに、オペレーティング・システム・ファイルに作成できます。 監査証跡を含むオペレーティング・システム・ファイルには、次のデータが記録されます。
オペレーティング・システムによって生成された監査レコード
データベース監査証跡レコード
常に監査されるデータベース関連のアクション
管理ユーザー（SYS）用の監査レコード
オペレーティング・システム監査レコードは、テキスト・ファイルまたはXMLファイルに書き込むことができます。
オペレーティング・システム監査証跡を使用する利点は、次のとおりです。
監査証跡の保護が容易になります。 監査人がデータベース管理者とは別のユーザーである場合は、OS、XML、またはXML, EXTENDED設定を使用する必要があります。この設定を使用しない場合、データベースに格納される監査情報をデータベース管理者が表示および変更できます。
オペレーティング・システム監査証跡では、監査証跡が特定のユーザーに制限可能な特定の場所へ書き込まれているため、業務分離の概念が規定されます。
監査証跡をオペレーティング・システム・ファイルに書き込むと、データベースのオーバーヘッドが最小になります。 この理由から、大規模なデータベースには最適です。
オペレーティング・システム・ファイルに格納された監査レコードは、データベース管理者にはないファイル権限をアクセス時に必要とするため、データベースに格納された監査レコードよりも安全です。また、オペレーティング・システムでの監査レコードの格納では、データベースが一時的にアクセス不可能な状態でも監査レコードが使用可能であるため、可用性の向上というもう1つの利点があります。
AUDIT_TRAIL初期化パラメータがXML（またはXML, EXTENDED）に設定されている場合、監査レコードはXMLファイルとしてオペレーティング・システムに書き込まれます。V$XML_AUDIT_TRAILビューを使用すると、DBAはSQL問合せを介してこのようなXML監査レコードを使用できるため、使いやすさが向上します。
DBA_COMMON_AUDIT_TRAILビューには、データベース表に書き込まれる標準およびファイングレイン監査証跡、XML形式の監査証跡レコード、およびV$XML_AUDIT_TRAIL動的ビューの内容（標準、ファイングレイン、SYSおよび必須）が含まれます。
オペレーティング・システム監査証跡を使用すると、Oracle Databaseや他のアプリケーションを含む複数のソースからの監査レコードを整理統合できます。そのため、すべての監査レコードが1箇所にまとめられ、システム・アクティビティの調査をより効率的に行うことができます。XML監査レコードを使用すると、任意の標準XML編集ツールを使用して、これらのレコードの情報を確認または抽出できます。
オペレーティング・システム監査証跡では、監査データがオペレーティング・システム・ファイルに書き込まれます。この機能は、AUDIT_TRAILパラメータを次のいずれかの値に設定することで使用可能にすることができます。
OS: 監査証跡レコードは、UNIXシステムの場合はテキスト形式のオペレーティング・システム・ファイルに、Microsoft Windowsの場合はアプリケーションのイベントビューアに書き込まれます。
XML: 監査証跡レコードはXMLファイルに書き込まれます。
XML, EXTENDED: 監査証跡レコードはXMLファイルに書き込まれ、可能な場合はSYS.AUD$表のSQLバインドおよびSQLテキストのCLOB型の列にデータが移入されます。
AUDIT_FILE_DEST初期化パラメータでは、オペレーティング・システム監査ファイルの場所を設定します。データベースにSYSDBAまたはSYSOPER権限でログインするユーザーを監査する場合は、AUDIT_SYS_OPERATIONSパラメータをTRUEに設定します。これらの設定の詳細は、表9-2「AUDIT_TRAILパラメータの設定」を参照してください。
オペレーティング・システム・ファイルに書き込まれるレコードは、SYS.AUD$およびSYS.FGA_LOG$表には記録されません。この場合も、DBA_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せると、オペレーティング・システム監査ファイルの内容を表示できます。このビューを問い合せると、AUDIT_FILE_DESTディレクトリ内のすべてのXMLファイル（.xml拡張子を持つすべてのファイル）が解析され、リレーショナル表の形式で表示されます。XMLは標準文書形式であるため、XMLデータを解析および分析できる多くのユーティリティがあります。使用しているオペレーティング・システムにこの機能が実装されているかどうかは、そのオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。
AUDIT_FILE_DEST初期化パラメータを使用して、AUDIT_TRAIL初期化パラメータがOSまたはXMLに設定されている場合に監査証跡が書き込まれるオペレーティング・システム・ディレクトリを指定します。AUDIT_FILE_DESTは、Oracleソフトウェアの所有者およびDBAグループに権限が制限されている有効なディレクトリに設定する必要があります。AUDIT_SYS_OPERATIONS初期化パラメータを指定した場合、ユーザーSYSの監査レコードの場合と同様、必須監査情報もこのディレクトリに格納されます。AUDIT_FILE_DESTは、次のALTER SYSTEM文を使用して変更する必要があります。この文では、新しい宛先がその後のセッションすべてに対して有効になります。
ALTER SYSTEM SET AUDIT_FILE_DEST = directory_path DEFERRED;
AUDIT_FILE_DESTパラメータを設定しない場合は、次のデフォルトの位置にファイルが格納されます。
LinuxおよびSolarisの場合: $ORACLE_BASE/admin/$DB_UNIQUE_NAME/adump
次に例を示します。
/opt/oracle/app/oracle/admin/orcl/adump
Windowsの場合: %ORACLE_BASE%¥admin¥%DB_UNIQUE_NAME¥adump
次に例を示します。
C:\ORACLE\ADMIN\ORCL\ADUMP
オペレーティング・システムの監査証跡またはファイル・システム（Windowsイベント・ログなど）がいっぱいになることがあり、そのためにオペレーティング・システム宛の監査レコードも含めて、新しいレコードが入らなくなる可能性があることに注意してください。この場合、Oracle Databaseでは、通常は常に監査される操作を含めて、監査対象のトランザクションが取り消されてロールバックされます。（「すべてのプラットフォームについて常に監査されるアクティビティ」を参照してください。）オペレーティング・システム監査証跡がいっぱいになった場合は、データベース監査証跡を使用するようにAUDIT_TRAILパラメータを設定（DBまたはDB, EXTENDEDなど）します。これにより、監査レコードを格納できない場合は監査対象のアクションの完了が防止されます。オペレーティング・システム監査ファイルを定期的にアーカイブして削除する必要があります。
オペレーティング・システム監査を使用する場合は、オペレーティング・システムの監査証跡またはファイル・システムがいっぱいにならないようにしてください。ほとんどのオペレーティング・システムでは、このような状況を回避できるように十分な情報と警告が管理者に提供されています。データベースの監査証跡を使用するように監査を構成すると、監査情報を失う危険性を回避できます。監査証跡が文に関するデータベース監査レコードを受け入れられない場合は、監査されているイベントの発生をOracle Databaseが防止しているためです。
オペレーティング・システム監査証跡の内容を定期的にアーカイブして削除します。詳細は、「オペレーティング・システム監査証跡のアーカイブおよび削除」を参照してください。
Oracle Databaseでは、オペレーティング・システム監査証跡レコードはエンコードされます。この情報は、適切なデータ・ディクショナリ表およびエラー・メッセージを参照することでデコードできます。
表9-9に、エンコードされている情報とそのデコードされたバージョンの参照場所を示します。
表9-9 監査証跡レコードのエンコードされている情報
常に監査されるアクティビティの監査情報をオペレーティング・システム・ファイルで取得する方法については、「すべてのプラットフォームについて常に監査されるアクティビティ」も参照してください。
この項の内容は、次のとおりです。
監査証跡が大きくなりすぎると新しいレコードが入らなくなるため、監査証跡レコードを定期的にアーカイブしてから削除（パージ）する必要があります。この項では、データベース監査証跡とオペレーティング・システム監査証跡をアーカイブしてから削除する方法について説明します。
監査証跡が大きくなりすぎないように、定期的にアーカイブしてから削除する必要があります。アーカイブと削除により、監査証跡の領域が解放され、データベース監査証跡の削除が容易になります。
次のいずれかの方法でデータベース監査証跡のアーカイブを作成できます。
Oracle Audit Vault。Oracle Audit VaultをOracle Databaseとは別にインストールします。詳細は、『Oracle Audit Vault管理者ガイド』を参照してください。
Oracle Data Warehouse。Oracle Data Warehouseは、Oracle Databaseとともに自動的にインストールされます。詳細は、『Oracle Warehouse Builderインストレーションおよび管理ガイド』を参照してください。
Oracle Data Pump Export。データベース監査証跡表（AUD$およびFGA_LOG$）をオペレーティング・システムのダンプ・ファイルにエクスポートしてから、これらのファイルをアーカイブできます。この項では、Oracle Data Pump Exportを使用してデータベース監査証跡表をアーカイブする方法について説明します。
Oracle Data Pumpを使用してデータベース監査証跡をアーカイブする手順は、次のとおりです。
データ・ポンプ・エクスポートがインストールされていることを確認します。
管理権限でSQL*Plusにログインし、次の問合せを実行します。
sqlplus "SYS/AS SYSDBA"
Enter password: password
SELECT ROLE FROM DBA_ROLES WHERE ROLE LIKE '%FULL%'
問合せでEXP_FULL_DATABASEロールおよびIMP_FULL_DATABASEロールが戻されない場合、データ・ポンプ・エクスポートはインストールされていません。データ・ポンプ・エクスポートをインストールするには、catexp.sqlスクリプトまたはcatalog.sqlスクリプトを実行します。
次に例を示します。
@/opt/oracle/app/oracle/admin/catexp.sql;
オペレーティング・システム監査証跡の設定の場所を確認します。
SHOW PARAMETER AUDIT_FILE_DEST
次の出力が表示されます。
NAME TYPE VALUE ------------------- ------- --------------------------------------- audit_file_dest string /opt/oracle/app/oracle/admin/orcl/adump
一般に、監査ファイルは一箇所に保持する必要があります。デフォルトでは、AUDIT_FILE_DESTパラメータはadumpディレクトリを指します。
通常は監査レコードをオペレーティング・システム監査証跡に書き込まない場合にも、デフォルトではOracle DatabaseによりAUDIT_FILE_DESTパラメータがadumpディレクトリを指すように設定されます。
SQL*Plusで、標準またはファイングレイン・アクセス監査証跡を生成するディレクトリ・オブジェクトを作成します。SYSまたはCREATE ANY DIRECTORY権限を持つユーザーとして接続します。
たとえば、標準監査証跡のディレクトリ・オブジェクトを作成する方法は次のとおりです。
CREATE DIRECTORY std_audit_dir AS '/opt/oracle/app/oracle/admin/orcl/adump';
ディレクトリ・パスは二重引用符ではなく一重引用符で囲みます。
SYS以外のユーザーがエクスポートを実行する場合、ディレクトリ・オブジェクトに対するREAD、WRITEおよびEXECUTE権限をこのユーザーに付与します。
たとえば、ユーザー名がsec_mgrの場合は、次のようにします。
GRANT READ, WRITE ON DIRECTORY std_audit_dir TO sec_mgr;
オペレーティング・システムのコマンドラインで次のようなコマンドを入力し、監査表を新規ダンプ・ファイルにエクスポートします。
EXPDP SEC_MGR
Enter password: password
DIRECTORY=std_audit_dir \
TABLES=SYS.AUD$ \
QUERY=SYS.AUD$:"WHERE scn < 4501785"
DUMPFILE=std_audit_051608.dmp
次のように値を指定します。
DIRECTORY: 手順3で作成したディレクトリ・オブジェクトを入力します。SYS以外のユーザーがEXPDPを実行している場合、このユーザーがこのディレクトリ・オブジェクトに対する読取りおよび書込み権限を持っていることを確認します。ディレクトリ・オブジェクトを作成した場合、それに対する読取りおよび書込み権限は自動的に付与されます。
TABLES: 監査証跡表のスキーマおよび名前を入力します。標準監査証跡表にはSYS.AUD$、ファイングレイン監査証跡表にはSYS.FGA_LOG$と入力します。
QUERY: （オプション）この設定により、監査証跡表の内容のサブセットがダンプ・ファイルに書き込まれます。この場合、SCN列の値4501785より少ない標準監査レコードとなります。
DUMPFILE: 作成するダンプ・ファイルの名前を入力します。デフォルトの拡張子は.dmpですが、任意の拡張子を使用できます。指定したファイル名が一意であることを確認してください。
SQL*Plusを終了します。
アーカイブの完了後に、データベース監査証跡表からレコードを手動で削除できます。ただし、パージ・プロセスではREDOログが追加生成される場合があることに注意してください。データベース監査証跡を削除する前に、監査表のパージ・プロセス中に追加生成されるレコードに対応するために、オンラインREDOログとアーカイブREDOログのサイズのチューニングが必要になる場合があります。ログ・ファイルのチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Database管理者ガイド』を参照してください。
データベース監査証跡からは、サブセットまたはすべてのレコードを削除できます。たとえば、2008年2月29日の夜から2008年3月29日までに作成された監査レコードを削除するには、次の文を実行します。
DELETE FROM SYS.AUD$
WHERE NTIMESTAMP# > TO_TIMESTAMP ('29-FEB-08 09.07.59.907000 PM') AND
NTIMESTAMP# < TO_TIMESTAMP ('29-MAR-08 09.07.59.907000 PM');
監査証跡からすべての監査レコードを削除するには、次のいずれかの文を実行します。
DELETE FROM SYS.AUD$; TRUNCATE TABLE SYS.AUD$;
ファイングレイン監査証跡も削除するには、DELETEおよびTRUNCATE TABLE文を使用します。次に例を示します。
DELETE FROM SYS.FGA_LOG$; TRUNCATE TABLE SYS.FGA_LOG$;
データベース監査証跡からレコードを削除できるのは、DELETE ANY TABLE権限があるSYSユーザー、またはSYSによってSYS.AUD$のDELETE権限を付与されているユーザーのみです。
|
注意: 監査証跡がいっぱいになっている場合に、接続が監査されているとき（つまり、 AUDIT SESSION文を設定している場合）は、その接続に対応する監査レコードを監査証跡に挿入できないため、通常のユーザーはデータベースに接続できません。この場合、SYSで接続し（SYSによる操作は監査されないため）、領域を監査証跡で使用可能にします。 |
データベース表の場合と同様に、データベース監査証跡からレコードが削除されても、この表に割り当てられているエクステントはそのまま存在します。
データベース監査証跡に多数のエクステントが割り当てられていても、そのうちの大半が使用されていない場合は、次の手順に従って、データベース監査証跡に割り当てられている領域を縮小できます。
データベース監査証跡に現在格納されている情報を保存（アーカイブ）します。
管理者権限を持つユーザーで接続します。
TRUNCATE TABLE文を使用して、SYS.AUD$を切り捨てます。
次に例を示します。
TRUNCATE TABLE SYS.AUD$;
手順1で作成したアーカイブ済の監査証跡レコードを再ロードします。
SYS.AUD$表には、現在の監査証跡レコードを保持するために必要な数だけエクステントが割り当てられます。
|
注意: 直接変更できる SYSオブジェクトは、SYS.AUD$のみです。 |
オペレーティング・システム監査証跡の内容を定期的にアーカイブして削除する必要があります。プラットフォーム固有のオペレーティング・システム・ツールを使用して、オペレーティング・システム監査ファイルのアーカイブを作成します。
オペレーティング・システム監査ファイルをアーカイブするには、次の方法を使用します。
Oracle Audit Vaultを使用します。Oracle Audit VaultをOracle Databaseとは別にインストールします。詳細は、『Oracle Audit Vault管理者ガイド』を参照してください。
テープまたはディスクにバックアップを作成します。監査ファイルの圧縮ファイルを作成し、それをテープまたはディスクに格納できます。詳細は、使用しているオペレーティング・システムのマニュアルを参照してください。
その後、監査証跡の領域を解放して監査証跡管理を容易にするために、オペレーティング・システム監査レコードをパージ（削除）する必要があります。これらのレコードの場所は、AUDIT_FILE_DEST初期化パラメータを調べて確認します。次に例を示します。
SQL> SHOW PARAMETER AUDIT_FILE_DEST NAME TYPE VALUE ------------------- ------- --------------------------------------- audit_file_dest string /opt/oracle/app/oracle/admin/orcl/adump
この項の内容は、次のとおりです。
表9-10に、監査情報を提供するデータ・ディクショナリ・ビューを示します。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
表9-10 データベース監査証跡に関する情報が表示されるビュー
| ビュー | 説明 |
|---|---|
|
|
現行ユーザーがアクセス可能な表とビューに対するファイングレイン監査ポリシーが表示されます。 |
|
|
現行ユーザーがアクセス可能な表とビューに対するファイングレイン監査ポリシーの列が表示されます。 |
|
オブジェクトの作成時に適用されるデフォルトのオブジェクト監査オプションがリストされます。 |
|
監査証跡のアクション・タイプ・コードが表示されます。 |
|
|
|
システム内にあるすべてのオブジェクトの監査証跡レコードがリストされます。 |
|
|
システム上にあるすべてのファイングレイン監査ポリシーがリストされます。 |
|
|
|
|
データベース全体の表とビューに対するファイングレイン監査ポリシーの列が表示されます。 |
|
|
データベース全体の |
|
|
|
|
|
標準監査とファイングレイン監査のログ・レコードが結合され、XML形式で書き込まれた |
|
|
ファイングレイン監査の監査証跡レコードがリストされます。 |
|
|
すべてのオブジェクトの監査オプションが表示されます。 |
|
監査対象となっている現行のシステム権限がシステム全体およびユーザー別に表示されます。 |
|
現行の文監査オプションがシステム全体およびユーザー別に表示されます。 |
|
|
現行ユーザーがアクセス可能なオブジェクトに関する文の監査証跡レコードがリストされます。 |
|
|
現行ユーザーがアクセス可能な表とビューに対するファイングレイン監査ポリシーの列が表示されます。 |
|
|
現行ユーザーの接続および切断に関する監査証跡レコードがすべてリストされます。 |
|
ユーザーが発行した |
|
|
|
現行ユーザーが所有するすべてのオブジェクトの監査オプションが表示されます。 |
|
監査オプション・タイプ・コードの情報が表示されます。 |
|
|
XML形式のファイルに書き込まれた標準監査、ファイングレイン監査、SYS監査および必須監査のレコードが表示されます。 |
ここでは、監査証跡情報の検討方法と解釈方法の具体例を説明します。次の疑わしいアクティビティについて、データベースを監査するとします。
データベース・ユーザーのパスワード、表領域の設定および割当て制限が許可なく変更されている。
おそらく排他的に表ロックを取得しているユーザーが原因で、デッドロックが頻繁に発生している。
laurelのスキーマ内にあるemp表から行が任意に削除されている。
これらの不正なアクションのいくつかは、ユーザーjwardとswilliamsによって行われた疑いがあります。
調査を行うには、次の文を順序どおりに発行します。
AUDIT ALTER, INDEX, RENAME ON DEFAULT;
CREATE VIEW laurel.employee AS SELECT * FROM laurel.emp;
AUDIT SESSION BY jward, swilliams;
AUDIT ALTER USER;
AUDIT LOCK TABLE
BY ACCESS
WHENEVER SUCCESSFUL;
AUDIT DELETE ON laurel.emp
BY ACCESS
WHENEVER SUCCESSFUL;
その後、ユーザーjwardによって次の文が発行されました。
ALTER USER tsmith QUOTA 0 ON users; DROP USER djones;
その後、ユーザーswilliamsによって次の文が発行されました。
LOCK TABLE laurel.emp IN EXCLUSIVE MODE;
DELETE FROM laurel.emp WHERE mgr = 7698;
ALTER TABLE laurel.emp ALLOCATE EXTENT (SIZE 100K);
CREATE INDEX laurel.ename_index ON laurel.emp (ename);
CREATE PROCEDURE laurel.fire_employee (empid NUMBER) AS
BEGIN
DELETE FROM laurel.emp WHERE empno = empid;
END;
/
EXECUTE laurel.fire_employee(7902);
次の各項では、データ・ディクショナリ内の監査証跡ビューを使用して表示できる情報のうち、この調査に関連するものを示します。
次の問合せを実行すると、設定されている文監査オプションがすべて表示されます。
SELECT * FROM DBA_STMT_AUDIT_OPTS; USER_NAME AUDIT_OPTION SUCCESS FAILURE -------------------- ------------------- ---------- --------- JWARD DROP ANY CLUSTER BY ACCESS BY ACCESS SWILLIAMS DEBUG PROCEDURE BY ACCESS BY ACCESS MSEDLAK ALTER RESOURCE COST BY ACCESS BY ACCESS
次の問合せを実行すると、設定されている権限監査オプションがすべて表示されます。
SELECT * FROM DBA_PRIV_AUDIT_OPTS; USER_NAME PRIVILEGE SUCCESS FAILURE ------------------- -------------------- --------- ---------- ALTER USER BY ACCESS BY ACCESS
次の問合せを実行すると、名前がempという文字で始まり、かつlaurelのスキーマ内に格納されているオブジェクトについて、監査オプションの設定がすべて表示されます。
SELECT * FROM DBA_OBJ_AUDIT_OPTS
WHERE OWNER = 'LAUREL' AND OBJECT_NAME LIKE 'EMP%';
OWNER OBJECT_NAME OBJECT_TY ALT AUD COM DEL GRA IND INS LOC ...
----- ----------- --------- --- --- --- --- --- --- --- --- ...
LAUREL EMP TABLE S/S -/- -/- A/- -/- S/S -/- -/- ...
LAUREL EMPLOYEE VIEW -/- -/- -/- A/- -/- S/S -/- -/- ...
このビューでは、指定したオブジェクトに対するすべての監査オプションの情報が表示されます。このビューの情報は、次のように解釈します。
ハイフン（-）は、監査オプションが何も設定されていないことを示します。
文字Sは、監査オプションがBY SESSIONに設定されていることを示します。
文字Aは、監査オプションがBY ACCESSに設定されていることを示します。
各監査オプションにはWHENEVER SUCCESSFULとWHENEVER NOT SUCCESSFULの2つの設定があり、スラッシュ（/）で区切られています。たとえば、laurel.empに対するDELETE監査オプションは、正常終了したDELETE文に対してBY ACCESSが設定されています。異常終了したDELETE文に対しては何も設定されていません。
次の問合せを実行すると、デフォルトのオブジェクト監査オプションがすべて表示されます。
SELECT * FROM ALL_DEF_AUDIT_OPTS; ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE FBK REA --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- S/S -/- -/- -/- -/- S/S -/- -/- S/S -/- -/- -/- -/- /- -/-
このビューでは、USER_OBJ_AUDIT_OPTSとDBA_OBJ_AUDIT_OPTSの各ビューに類似した情報が表示されます（前出の例を参照）。
次の問合せを実行すると、データベース内のすべてのオブジェクトについて生成された監査レコードがリストされます。
SELECT * FROM DBA_AUDIT_OBJECT;
次の問合せを実行すると、AUDIT SESSION文監査オプションに対応する監査情報がリストされます。
SELECT USERNAME, LOGOFF_TIME, LOGOFF_LREAD, LOGOFF_PREAD,
LOGOFF_LWRITE, LOGOFF_DLOCK
FROM DBA_AUDIT_SESSION;
USERNAME LOGOFF_TI LOGOFF_LRE LOGOFF_PRE LOGOFF_LWR LOGOFF_DLO
---------- --------- ---------- ---------- ---------- ----------
JWARD 02-AUG-91 53 2 24 0
SWILLIAMS 02-AUG-91 3337 256 630 0
