| Oracle® Databaseセキュリティ・ガイド 11gリリース2 (11.2) B56285-13 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
この項の内容は、次のとおりです。
|
関連項目: 高度な監査機能を提供するOracle Audit Vault and Database Firewallの詳細は、『Oracle Audit Vault and Database Firewall管理者ガイド』を参照してください。 |
監査とは、選択したユーザー・データベース・アクション(データベース・ユーザーおよび非データベース・ユーザーの両方からのアクション)を監視して記録する処理のことです脚注 1 。実行されたSQL文のタイプなどの個々のアクション、またはユーザー名、アプリケーション、時間などの様々なデータの組合せをベースとして使用できます。成功したアクティビティと失敗したアクティビティの両方を監査できます。監査を使用するには、監査を使用可能にした後、監査対象を構成します。監査対象のアクションは、データ・ディクショナリ表またはオペレーティング・システム・ファイルに記録されます。
監査を使用可能にして構成することをお薦めします。監査は、強固な内部制御を規定する有効な方法であるため、サイトでは米国サーベンス・オクスリー法(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)
疑わしいデータベース・アクティビティを監査する場合は、監査証跡のレコードの整合性を保護することによって、監査情報が正確かつ完全であることを保証する必要があります。
データベース監査証跡は、SYS.AUD$およびSYS.FGA_LOG$表に書き込まれます。SYS.AUD$およびSYS.FGA_LOG$表に対してオブジェクト監査オプションを設定した結果として生成された監査レコードを監査証跡から削除できるのは、管理者権限で接続しているユーザーのみです。管理者も不正な使用について監査されることに注意してください。詳細は、「SYS管理ユーザーの監査」を参照してください。
データベース監査証跡を保護するには、次の方法もあります。
O7_DICTIONARY_ACCESSIBILITY初期化パラメータをFALSE(デフォルト)に設定します。これにより、SYS.AUD$およびSYS.FGA_LOG$表内の監査データに対してDMLアクションを実行できるのは、SYSDBA権限を持つユーザーのみとなります。デフォルトのインストールでは、O7_DICTIONARY_ACCESSIBILITYはFALSEに設定されています。
Oracle Database Vaultをインストール済の場合は、SYSTEM.AUD$表を含むレルムを作成します。デフォルトでは、AUD$表はSYSTEMスキーマにあります。(シノニムSYS.AUD$は、SYSTEM.AUD$表を参照します。)Oracle Database Vaultのレルムの詳細は、『Oracle Database Vault管理者ガイド』を参照してください。
標準監査が使用可能になっている場合(つまり、AUDIT_TRAILをDBまたはDB,EXTENDEDに設定している場合)、SYS.AUD$およびSYS.FGA_LOG$表に対するINSERT、UPDATE、MERGEおよびDELETEなど、非SYSユーザーによるすべてのデータ操作言語(DML)操作が監査されます。(この監査は、AUD$表とFGA_LOGS$表の監査オプションを設定していない場合にも行われます。)通常、非SYSユーザーは、明示的にアクセス権が付与されている場合を除き、これらの表にアクセスできません。非SYSユーザーがSYS.FGA_LOG$およびSYS.AUD$表内のデータを改ざんすると、各アクションに関して監査レコードが書き込まれます。
AUDIT_SYS_OPERATIONS初期化パラメータをTRUEに設定した場合、Oracle DatabaseはSYS.FGA_LOG$表およびSYS.AUD$表に対するSYSユーザーのDELETE、INSERT、UPDATE、およびMERGE操作を監査します。この場合、すべてのSYS操作の監査レコードは、AUDIT_FILE_DEST初期化パラメータが指しているディレクトリに書き込まれます。AUDIT_FILE_DESTが設定されていない場合、レコードが書き込まれる場所はオペレーティング・システムによって異なります。
Oracle Databaseは常に特定のデータベース関連操作を監査して、それらをオペレーティング・システムの監査ファイルに書き込みます。中には、SYSDBA権限やSYSOPER権限でログインしたユーザーのアクションが含まれます。これは、必須監査と呼ばれます。データベース監査証跡を有効にした場合(AUDIT_TRAILパラメータをDBに設定した場合)でも、Oracle Databaseは必須レコードをオペレーティング・システム・ファイルに書き込みます。
デフォルトでは、オペレーティング・システムはUNIXシステムとWindowsシステムのどちらの場合も$ORACLE_BASE/admin/$ORACLE_SID/adumpディレクトリの中にあります。Windowsシステムでは、Oracle Databaseがこの情報をWindowsイベントビューアにも書き込みます。このディレクトリの場所はAUDIT_FILE_DEST初期化パラメータを設定することで変更できます。これは「オペレーティング・システム監査証跡のディレクトリの指定」で説明しています。
必須監査には、次の操作が含まれます。
データベースの起動。インスタンスを起動したオペレーティング・システム・ユーザー、そのユーザーの端末識別子、日時のタイム・スタンプを記述した監査レコードが生成されます。データベース監査証跡は起動処理が正常に完了するまで使用できないため、この監査レコードはオペレーティング・システム監査証跡に格納されます。
データベースの停止。インスタンスを停止したオペレーティング・システム・ユーザー、そのユーザーの端末識別子および日時のタイム・スタンプを記述した監査レコードが生成されます。
|
注意: |
監査はサイト自律型です。インスタンスでは、直接接続しているユーザーによって発行された文のみが監査されます。ローカルのOracle Databaseノードでは、リモート・データベースで発生するアクションを監査できません。
ベスト・プラクティスに関する次のガイドラインに従ってください。
原則として、法令順守要件を満たすために必要な量の情報を収集するように監査方針を策定しますが、必ず大きいセキュリティ問題の原因となるアクティビティに焦点を合わせてください。たとえば、データベース内のすべての表を監査するのではなく、給与など機密性の高いデータが入った表列を監査するのが実用的です。標準監査とファイングレイン監査の両方により、監査対象の特定のアクティビティに焦点を合わせた監査ポリシーの策定に使用できるメカニズムがあります。
監査証跡データを定期的にアーカイブして削除します。詳細は、「監査証跡レコードの削除」を参照してください。
実行する監査のタイプ、つまり一般アクティビティ(SQL文のアクションなど)、一般的に使用される監査アクティビティまたはファイングレイン監査に応じて、特定の手順を実行する必要があります。
これらのタイプの監査に加えて、Oracle Databaseではいくつかのアクティビティを強制的に監査します。詳細は、強制的に監査されるアクティビティを参照してください。
Oracle Databaseには一連のデフォルト監査設定が用意されており、セキュリティに関連する一般的なSQL文と権限に対して使用可能にすることができます。
監査レコードの場所: Oracle Databaseでは、これらの監査レコードはAUDIT_TRAIL初期化パラメータに基づく場所に書き込まれます。「監査レコードの概要」も参照してください。
一般手順
「セキュリティに関連するSQL文および権限に対するデフォルト監査の使用」の指示に従って、デフォルト監査を使用可能にします。
データベース監査証跡の詳細は、「監査証跡レコードの管理」を参照してください。
監査アクティビティを監視するために、データベース監査証跡データ・ディクショナリ・ビューを定期的に問い合せます。「監査アクティビティに関する情報の検索」を参照してください。
データベース監査証跡のメンテナンスを実行します。「データベース監査証跡の管理」を参照してください。
監査証跡の内容を定期的にアーカイブして削除します。「監査証跡レコードの削除」を参照してください。
内容に基づいて、データ・アクセスとアクションを最も細かいレベルで監査できます。value > 7800などのブール基準、またはアクションが発生したIPアドレスを使用します。
監査レコードの場所: 監査レコードは、データベース監査証跡またはオペレーティング・システム監査証跡にXML形式で書き込むことができます。「監査レコードの概要」も参照してください。
一般手順
「ファイングレイン監査を使用した特定のアクティビティの監査」を参照し、特定のアクティビティの監査の詳細を把握します。
監査レコードをデータベース監査証跡とオペレーティング・システム・ファイルのどちらに書き込むかを決定します。「データベース監査証跡の管理」を参照してください。
DBMS_FGA PL/SQLパッケージを使用して、ファイングレイン監査ポリシーを構成します。DBMS_FGA.ADD_POLICYプロシージャには、監査証跡タイプの選択に使用するaudit_trailパラメータが用意されています。XMLファイルを使用して、データベース監査証跡またはオペレーティング・システム監査証跡を選択できます。次の各項を参照してください。
監査アクティビティを監視するために、構成したオペレーティング・システム・レコードを定期的にチェックするか、または監査証跡データ・ディクショナリ・ビューを問い合せます。「監査アクティビティに関する情報の検索」を参照してください。
監査証跡のメンテナンスを実行します。「監査証跡レコードの管理」を参照してください。
監査証跡の内容を定期的にアーカイブして削除します。「監査証跡レコードの削除」を参照してください。
SYSDBAまたはSYSOPER権限を使用して接続したユーザーが発行したトップレベルのSQL文を監査できます。(トップレベルとは、ユーザーによって直接発行された文のことです。PL/SQLプロシージャまたはファンクションから実行される文は、トップレベルとはみなされません。)
監査レコードの場所: Oracle Databaseでは、これらの監査レコードはオペレーティング・システム監査証跡にのみ書き込まれます。Windowsの場合、SYS監査レコードはデフォルトでWindowsイベント・ログに書き込まれます。UNIXシステムの場合、レコードをsyslogファイルに書き込むことができます。「監査レコードの概要」も参照してください。
一般手順
「SYS管理ユーザーの監査」を参照して、管理監査を構成します。
オペレーティング・システム監査証跡の詳細は、「オペレーティング・システム監査証跡の管理」を参照してください。
監査アクティビティを監視するために、構成したオペレーティング・システム・レコードまたはsyslogレコードを定期的にチェックします。XMLファイルに書き込んでいる場合は、V$XML_AUDIT_TRAILおよびDBA_COMMON_AUDIT_TRAILビューを問合せできます。「監査アクティビティに関する情報の検索」を参照してください。
監査証跡のメンテナンスを実行します。「監査証跡レコードの管理」を参照してください。
監査証跡の内容を定期的にアーカイブして削除します。「監査証跡レコードの削除」を参照してください。
この項の内容は、次のとおりです。
|
関連項目:
|
この項の内容は、次のとおりです。
標準監査では、SQL文、権限、スキーマ・オブジェクトおよびネットワーク・アクティビティを監査します。AUDIT SQL文を使用して標準監査を構成し、NOAUDITを使用してこの構成を解除します。監査レコードは、データベース監査証跡またはオペレーティング・システム監査ファイルに書き込むことができます。
どのユーザーでも、AUDIT文を使用して、独自のスキーマ内のオブジェクトに対して監査を構成できます。また、NOAUDIT文を使用して、対象のオブジェクトに対する監査構成を元に戻すことができます。このタスクを実行するために追加権限は必要ありません。ユーザーは、AUDIT_TRAILパラメータの設定に関係なく、AUDIT文を実行して監査オプションを設定できます。監査が使用禁止になっている場合、次回使用可能にしたときに、Oracle Databaseでは、AUDIT文で設定した監査アクティビティが記録されます。標準監査を使用可能にする方法は、「標準監査証跡を使用可能および使用禁止にする方法」を参照してください。
次のことに注意してください。
別のスキーマ内のオブジェクトを監査するには、ユーザーにAUDIT ANYシステム権限が必要です。
システム権限を監査するには、ユーザーにAUDIT SYSTEM権限が必要です。
O7_DICTIONARY_ACCESSIBILITY初期化パラメータがFALSE(デフォルト)に設定されている場合、SYS.AUD$およびSYS.FGA_LOG$表内の監査データに対してDMLアクションを実行できるのは、SYSDBA権限を持つユーザーのみとなります。セキュリティを強化するためには、O7_DICTIONARY_ACCESSIBILITYパラメータをFALSEに設定して、非SYSDBAユーザーがSYSオブジェクトを監査できないようにします。
|
関連項目:
|
データベース全体の標準監査は、セキュリティ管理者が使用可能または使用禁止にします。使用禁止の場合、監査レコードは作成されません。監査オプションの構成の詳細は、前の項「標準監査の実行者」を参照してください。
データベースの監査機能が使用可能なときに、監査対象として構成されたアクションが発生すると、SQL文の実行フェーズ時または実行フェーズ後に監査レコードが生成されます。PL/SQLプログラム・ユニット内のSQL文は、プログラム・ユニットの実行時に必要に応じて個別に監査されます。
監査証跡レコードの生成と挿入は、ユーザー・トランザクションのコミットからは独立して実行されます。つまり、ユーザー・トランザクションがロールバックされても、監査証跡レコードはコミットされたままになります。
データベース・ユーザーがデータベースに接続した時点で有効になっていた文監査オプションと権限監査オプションは、そのセッションの持続期間中は有効です。セッションがすでにアクティブになっている場合、文監査または権限監査のオプションを設定または変更しても、そのセッション中は有効になりません。修正した文監査オプションまたは権限監査オプションは、カレント・セッションを終了し、新しいセッションを作成した時点で有効になります。
一方、オブジェクト監査オプションについて変更した内容は、カレント・セッションでただちに有効になります。
|
関連項目: SQL文処理の様々なフェーズや共有SQLについては、『Oracle Database概要』を参照してください。 |
この項の内容は、次のとおりです。
標準監査証跡を使用可能にするには、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 DB
例9-2に、SQL*Plusにログインし、標準監査証跡を使用可能にして、データベース・インスタンスを再起動する方法を示します。
例9-2 標準監査証跡を使用可能にする方法
CONNECT SYSTEM Enter password: password ALTER SYSTEM SET AUDIT_TRAIL=DB SCOPE=SPFILE; System altered. CONNECT SYS/AS SYSOPER Enter password: password SHUTDOWN Database closed. Database dismounted. ORACLE instance shut down. STARTUP ORACLE instance started.
この例では、データベース・インスタンスはサーバー・パラメータ・ファイル(SPFILE)を使用して起動されているため、SCOPE句を使用します。サーバー・パラメータ・ファイルを使用したデータベースの起動は、データベース・インスタンスの推奨される起動方法です。サーバー・パラメータ・ファイルの作成および構成の詳細は、『Oracle Database管理者ガイド』を参照してください。
表9-1に、AUDIT_TRAIL初期化パラメータに使用できる設定を示します。
表9-1 AUDIT_TRAIL初期化パラメータの設定
| AUDIT_TRAILの値 | 説明 |
|---|---|
|
|
オペレーティング・システムの監査証跡に常に書き込まれる必須監査レコードおよびSYS監査レコードを除いて、監査レコードをデータベース監査証跡(
「データベース監査証跡の管理」も参照してください。 |
|
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; ALTER SYSTEM SET AUDIT_TRAIL=EXTENDED,DB SCOPE=SPFILE; ALTER SYSTEM SET AUDIT_TRAIL=EXTENDED, DB SCOPE=SPFILE; ただし、 ALTER SYSTEM SET AUDIT_TRAIL='DB, EXTENDED' SCOPE=SPFILE; 以前のリリースでは、設定は |
|
|
|
すべての監査レコードをオペレーティング・システム・ファイルに書き込みます。 特に安全性の非常に高いデータベース構成を使用している場合は、
「オペレーティング・システム監査証跡の管理」も参照してください。 |
|
XML形式でオペレーティング・システム監査レコード・ファイルに書き込みます。 「オペレーティング・システム監査証跡の利点」および例9-4「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; 次の各項も参照してください。 |
|
|
|
次のことに注意してください。
AUDITまたはNOAUDIT文を実行した後、データベースを再起動する必要はありません。データベースの再起動が必要になるのは、AUDIT_TRAIL初期化パラメータの変更など、全般的な変更を加えた場合のみです。
ファイングレイン監査またはSYS監査を使用可能にする場合、AUDIT_TRAILの設定は不要です。ファイングレイン監査の場合は、ファイングレイン監査ポリシーを必要に応じて追加および削除して、監視する特定の操作またはオブジェクトに適用します。SYS監査を使用可能にするには、AUDIT_SYS_OPERATIONSパラメータをTRUEに設定します。
オペレーティング・システム監査証跡とデータベース監査証跡では、同じタイプの多くのアクションが取得されます。表9-2に、オペレーティング・システム監査証跡レコードを示します。ほとんどのレコードがDBA_AUDIT_TRAILビューの列に対応しています。これらの列の詳細は、『Oracle Databaseリファレンス』を参照してください。
表9-2 オペレーティング・システム監査証跡とデータベース監査証跡で共通して監査されるアクション
| オペレーティング・システム監査レコード | DBA_AUDIT_TRAILビューの対応する列 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
どの監査オプションが |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
脚注1たとえば、ACTIONの値が104(AUDIT)または105(NOAUDIT)の場合、SYS$OPTIONSの数値はSTMT_AUDIT_OPTION_MAP表にリストされた監査オプションを表します。ACTIONの値が108(GRANT)または109(REVOKE)の場合、この数値はSYSTEM_PRIVILEGE_MAP表にリストされた権限を表します。
この項の内容は、次のとおりです。
標準監査レコードは、DBA_AUDIT_TRAIL(SYS.AUD$表)に作成するかわりに、オペレーティング・システム・ファイルに作成できます。監査証跡を含むオペレーティング・システム・ファイルには、次のデータが記録されます。
データベース監査証跡レコード
必須監査レコード(つまり、常に監査されるデータベース・アクション)
管理ユーザー(SYS)用の監査レコード
オペレーティング・システム監査レコードは、テキスト・ファイルまたはXMLファイルに書き込むことができます。
オペレーティング・システム監査証跡ファイルのファイル形式は、テキストとXMLのいずれかです。テキスト・ファイルとXMLオペレーティング・システム・ファイルの内容にはいくつか違いがあること、そしてリリースが異なると形式が変わる場合があることに注意してください。Oracle Databaseのリリースごとに、監査タイプなど、新しい拡張機能がテキスト・ファイルではなくXMLファイルに対して行われてきました。テキストのオペレーティング・システム・ファイルでは、たとえばタイムスタンプが次のように異なった表示になります。
Wed May 6 00:57:36 2009 -07:00
ただし、このタイムスタンプは、イベント・ログやsyslogには表示されません(イベント・ログやsyslogでは、それぞれ独自の形式のタイムスタンプが使用されます)。このタイムスタンプ文字列は、テキスト形式のオペレーティング・システム監査ファイルにのみ表示されます。
例9-3は、Microsoft WindowsにインストールされているOracleデータベースでのログイン操作についての標準的テキストのオペレーティング・システム監査証跡を示しています。(実際のレコードのテキストは折り返して表示されますが、このマニュアルではわかりやすくするために各項目をそれぞれの行に分けて示しています。)
例9-3 テキスト・ファイル形式のオペレーティング・システム監査証跡
Audit trail: LENGTH: "349" SESSIONID:[5] "43464" ENTRYID:[1] "1" STATEMENT:[1] "1" USERID:[6] "DBSNMP" USERHOST:[7] "SHOBEEN" TERMINAL:[3] "MAU" ACTION:[3] "100" RETURNCODE:[1] "0" COMMENT$TEXT:[97] "Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.4)(PORT=2955))" OS$USERID:[19] "NT AUTHORITY\SYSTEM" DBID:[10] "1212547373" PRIV$USED:[1] "5"
この例の説明は、次のとおりです。
LENGTHは、この監査レコードで使用されている合計バイト数を示します。この数値には、監査レコードの末尾の改行バイト(\n)(存在する場合)も含まれます。
[](括弧)は、各監査エントリの各値の長さを示します。たとえば、USERIDエントリのDBSNMPの長さは6バイトです。
SESSIONIDは、監査セッションID番号を示します。セッションIDは、V$SESSIONデータ・ディクショナリ・ビューのAUDSID列を問い合せることでも確認できます。
ENTRYIDは、各監査証跡レコードに現在割り当てられている監査エントリ番号を示します。ENTRYIDの監査順序番号は、ファイングレイン監査レコードと標準監査レコードで共有されます。
STATEMENTは、ユーザーが実行する文に割り当てられた数値IDです。ユーザー・セッション中に発行される文ごとに表示されますが、これは1つの文で監査レコードが複数になる場合があるためです。
ACTIONは、ユーザーが実行したアクションを表す数値です。対応するアクション・タイプの名前はAUDIT_ACTIONS表に表示されます。たとえば、アクション100はLOGONを表します。
RETURNCODEは、監査対象のアクションが成功したかどうかを示します。0 (ゼロ)は、成功したことを示します。アクションが失敗した場合は、リターン・コードにOracle Databaseエラー番号が示されます。たとえば、存在しない表を削除しようとした場合、エラー番号はORA-00903「表名が無効です。」になり、これがRETURNCODE設定で903に変換されます。
COMMENT$TEXTは、監査レコードに関する追加のコメントを示します。たとえばLOGON監査レコードの場合、認証方式などがコメントとして考えられます。この情報は、DBA_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビューのCOMENT_TEXT列に対応します。
DBIDは、データベースが作成されるときに算出されるデータベース識別子です。この情報は、V$DATABASEデータ・ディクショナリ・ビューのDBID列に対応します。
ECONTEXT_IDは、アプリケーション実行コンテキストの識別子を示します。
PRIVS$USEDは、アクションを実行するために使用された権限を示します。権限を検索するには、SYSTEM_PRIVILEGE_MAP表を問い合せます。たとえば、権限5は、この表では-5として表され、CREATE SESSIONを意味します。PRIVS$USEDは、DBA_COMMON_AUDIT_TRAILのPRIV_USED列に対応します。このビューでは、名前別に権限が示されます。
他の値としては、次のものがあります。
SCN(たとえば、SCN:8934328925)は、システム変更番号(SCN)を示します。フラッシュバック問合せを実行して設定(たとえば、列)の値を検索する場合に、この値を使用します。たとえば、OE.ORDERS表のORDER_TOTAL列の値をSCN番号に基づいて検索するには、次のSELECT文を使用します。
SELECT ORDER_TOTAL FROM OE.ORDERS AS OF SCN = 8934328925 WHERE ORDER_TOTAL = 86;
SES_ACTIONSは、セッション中に実行されたアクションを示します。このフィールドは、BY SESSION句を使用してイベントが監査された場合にのみ存在します。このフィールドにはセッション中に実行されたアクションの詳細は示されないため、BY ACCESS句を使用して監査イベントを構成する必要があります。
SES_ACTIONSフィールドには16文字が表示されます。14、15および16桁目は、将来の使用のために予約されています。最初の12文字では、各桁がアクションの結果を示します。該当するアクションは、ALTER、AUDIT、COMMENT、DELETE、GRANT、INDEX、INSERT、LOCK、RENAME、SELECT、UPDATEおよびFLASHBACKです。たとえば、ユーザーがALTER文を正常に実行した場合、SES_ACTIONS設定は次のようになります。
S---------------
1桁目のSは(ALTERの場合)、成功を示します。ALTER文が失敗した場合は、かわりに文字Fが表示されます。アクションの結果が成功と失敗の両方の場合は、文字Bが表示されます。
SES$TIDは、監査対象のアクションの影響を受けたオブジェクトのIDです。
SPARE2は、ユーザーがSYS.AUD$表を変更したかどうかを示します。0(ゼロ)は、ユーザーがSYS.AUD$を変更したことを意味します。それ以外の場合、値はNULLです。
同様に、例9-4に、XML監査証跡レコードの表示形式を示します。実際のレコードのテキストは折り返して表示されますが、このマニュアルではわかりやすくするために各要素をそれぞれ個別の行に示しています。Webブラウザで次のスキーマを表示して、XML監査ファイルに表示されるすべてのタグを確認できます。
http://www.oracle.com/technology/oracleas/schema/dbserver_audittrail-11_2.xsd
例9-4 XMLファイル形式のオペレーティング・システム監査証跡
<?xml version="1.0" encoding="UTF-8"?>
<Audit xmlns="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail-11_2.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail-11_2.xsd">
<Version>11.2</Version>
<AuditRecord>
<Audit_Type>1</Audit_Type>
<Session_Id>43535</Session_Id>
<StatementId>1</StatementId>
<EntryId>1</EntryId>
<Extended_Timestamp>2009-04-29T18:32:26.062000Z</Extended_Timestamp>
<DB_User>SYSMAN</DB_User>
<OS_User>SYSTEM</OS_User>
<Userhost>shobeen</Userhost>
<OS_Process>3164:3648</OS_Process>
<Terminal>mau</Terminal>
<Instance_Number>0</Instance_Number>
<Action>100</Action>
<TransactionId>0000000000000000</TransactionId>
<Returncode>0</Returncode>
<Comment_Text>Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.4)(PORT=3536))</Comment_Text>
<Priv_Used>5</Priv_Used>
</AuditRecord>
</Audit>
この例の説明は、次のとおりです。
AuditRecord要素には、監査レコード全体が含まれます。(Audit_Record要素内の要素の詳細は、例9-3を参照してください。)
Audit_Typeは、監査証跡のタイプを示します。次の値があります。
1: 標準監査レコード
2: ファイングレイン監査レコード
4: SYS監査レコード
8: 必須監査レコード
このフィールドは、XML形式の監査ファイルにのみ表示され、テキスト形式のオペレーティング・システム監査ファイルには表示されません。
Extended_Timestampは、監査対象の操作が実行された時間(AUDIT SESSIONで作成されたエントリに対するユーザー・ログインのタイムスタンプ)を示します。この時間は、協定世界時(UTC)またはグリニッジ標準時(GMT)で示されます。このフィールドは、XML形式の監査ファイルにのみ表示され、テキスト形式のオペレーティング・システム監査ファイルには表示されません。
Instance_Numberは、Oracle Real Application Clusters環境でユーザーが接続しているインスタンスの番号を示します。この例では、番号は0で、単一インスタンス・データベース・インストールに使用されます。この番号は、INSTANCE_NUMBER初期化パラメータで指定します。
AUDIT_TRAILパラメータをXML, EXTENDEDに設定すると、次の値が表示されます。これらの値はどちらもDBA_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビューにリストされます。
Sql_Bind(たとえば、<Sql_Bind>#1(5):89</Sql_Bind>)は、バインド変数の値を示します。構文は、次のとおりです。
VariablePosition(LengthOfVariableValue):ValueofBindVariable
例の#1(5):89は、バインド変数が1つ存在し、その値の長さが5文字であり、バインド変数の値が89であることを示します。
Sql_Text(たとえば、<Sql_Text>begin procedure_one(:num); end; </Sql_Text>)は、AUDIT_TRAILパラメータをXML, EXTENDEDに設定している場合に表示されます。これは、ユーザーが入力したSQLテキストを示します。
オペレーティング・システム監査証跡を使用する利点は、次のとおりです。
監査証跡の保護が容易になります。監査人がデータベース管理者とは別のユーザーである場合は、OS、XML、またはXML, EXTENDED設定を使用する必要があります。この設定を使用しない場合、データベースに格納される監査情報をデータベース管理者が表示および変更できます。
オペレーティング・システム監査証跡では、監査証跡が特定のユーザーに制限可能な特定の場所へ書き込まれているため、業務分離の概念が規定されます。
監査証跡をオペレーティング・システム・ファイルに書き込むと、データベースのオーバーヘッドが最小になります。この理由から、大規模なデータベースには最適です。
オペレーティング・システム・ファイルに格納された監査レコードは、データベース管理者にはないファイル権限をアクセス時に必要とするため、データベースに格納された監査レコードよりも安全です。また、オペレーティング・システムでの監査レコードの格納では、データベースが一時的にアクセス不可能な状態でも監査レコードが使用可能であるため、可用性の向上というもう1つの利点があります。
AUDIT_TRAIL初期化パラメータがXML(またはXML, EXTENDED)に設定されている場合、監査レコードはXMLファイルとしてオペレーティング・システムに書き込まれます。V$XML_AUDIT_TRAILビューを使用すると、データベース管理者は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ファイルに監査証跡レコードを書き込み、SQLテキストおよびSQLバインド情報をオペレーティング・システムXML監査ファイルに追加します。
AUDIT_FILE_DEST初期化パラメータでは、オペレーティング・システム監査ファイルの場所を設定します。データベースにSYSDBAまたはSYSOPER権限でログインするユーザーによって発行されたトップレベルの文を監査する場合は、AUDIT_SYS_OPERATIONSパラメータをTRUEに設定します。これらの設定の詳細は、表9-1「AUDIT_TRAIL初期化パラメータの設定」を参照してください。
オペレーティング・システム・ファイルに書き込まれるレコードは、SYS.AUD$およびSYS.FGA_LOG$表には記録されません。この場合も、DBA_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せると、XML形式のオペレーティング・システム監査ファイルの内容を表示できます。このビューを問い合せると、AUDIT_FILE_DESTディレクトリ内のすべてのXMLファイル(.xml拡張子を持つすべてのファイル)が解析され、リレーショナル表の形式で表示されます。XMLは標準文書形式であるため、XMLデータを解析および分析できる多くのユーティリティがあります。使用しているオペレーティング・システムにこの機能が実装されているかどうかは、そのオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。
AUDIT_TRAIL初期化パラメータがOS、XML、またはXML, EXTENDEDに設定されている場合は、AUDIT_FILE_DEST初期化パラメータを使用して監査証跡が書き込まれるオペレーティング・システム・ディレクトリを指定します。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パラメータの現行の設定を調べるには、次のコマンドを発行します。
SHOW PARAMETER AUDIT_FILE_DEST
オペレーティング・システム・ファイルの場所は、次の状況によって異なります。
データベースが実行されておらず、AUDIT_FILE_DESTパラメータを設定していない場合、オペレーティング・システム・ファイルは最初のデフォルトの場所($ORACLE_BASE/admin/$ORACLE_SID/adumpディレクトリ)に配置されます。
データベースが実行されておらず、最初のデフォルトの場所($ORACLE_BASE/admin/$ORACLE_SID/adumpディレクトリ)がアクセス不能か書込み不能になっている場合、またはOracleプロセスで環境変数を識別できない場合、2番目のデフォルトの場所($ORACLE_HOME/rdbms/audit)が使用されます。
データベースがオープンされており、Oracle Databaseでデータベース・インスタンスの初期化ファイル(initSID.ora)が読み取られた場合、AUDIT_FILE_DESTパラメータの値がオペレーティング・システム監査ファイル・ディレクトリとして使用されます。
UNIXおよびSolarisシステムの場合、すべてのオペレーティング・システム・ファイルがオペレーティング・システム内のディレクトリに書き込まれます。Windowsの場合、テキスト形式のオペレーティング・システム・レコードについては、Windowsイベントビューアから使用でき、XML形式のオペレーティング・システム・ファイルについては、前述の箇条書き項目に示すようにオペレーティング・システム・ディレクトリから使用できます。
|
注意: UNIX、SolarisおよびWindows以外のプラットフォームを使用している場合は、そのプラットフォームのマニュアルでオペレーティング・システム・ファイルの正しいターゲット・ディレクトリを確認してください。 |
UNIXシステムでは、syslog監査証跡を作成することによって、ユーザー(権限を持つユーザーを含む)のアクティビティを監査して、syslogファイルにこれらのアクティビティを記録できます。
この項の内容は、次のとおりです。
syslog監査証跡を使用して、オペレーティング・システムのSyslog機能で提供される集中化された監査機能を構成できます。syslogとは、ネットワークの様々なコンポーネントからのログ情報のUNIXベース・システムでの標準プロトコルです。アプリケーションはsyslogデーモンに情報を記録するためのsyslog()関数をコールし、syslogデーモンは情報をどこに記録するかを決定します。syslogファイルを使用するよう構成すると、メッセージがsyslogデーモン・プロセスに送信されることに注意してください。syslogデーモン・プロセスは、syslogファイルへのコミットされた書込みを示す確認応答をOracle Databaseに返しません。
Oracleプロセスなどのアプリケーションがsyslog()関数を使用して情報をsyslogデーモンに記録するため、権限を持つユーザーにはsyslogメッセージの記録先ファイル・システムへのアクセス権はありません。このため、syslog監査証跡を使用して格納された監査レコードは、オペレーティング・システムの監査証跡を使用して格納された監査レコードよりも安全に保護されます。権限を持つユーザーに対するファイル・システムへのアクセス権の制限に加えて、syslog監査証跡をセキュリティで保護するために、権限を持つユーザーもOracleプロセスも、監査レコードが書き込まれるシステムへのrootアクセスはできないようにする必要があります。
|
注意: syslog監査を使用可能にする前に、syslogの使用方法をよく理解しておく必要があります。syslogの詳細は次の資料を参照してください。
|
オペレーティング・システムの監査証跡レコードと同様に、Oracle Databaseでは、セキュリティを強化するためにsyslogレコードがエンコードされます。Oracle Audit Vaultをインストール済の場合は、Syslog Collectorを使用し、syslog監査レコードを抽出して中央のOracle Audit Vaultサーバーに転送できます。
例9-5は、表示されるsyslog監査証跡を示しています。(この例では、わかりやすくするためにテキストは書式変更されています。実際には、テキストはすべてが1行で表示されます。)他のOracle Database監査証跡と同じように、括弧内は監査された値の長さを示しています。syslog監査証跡では、LENGTH:以降のテキストがOracle Database監査レコードです。先頭に追加されたテキスト(日付とOracle Audit [10085]の行)は、syslogユーティリティによって追加されています。
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
AUDIT_SYSLOG_LEVELの詳細は、『Oracle Databaseリファレンス』を参照してください。
syslog構成ファイル/etc/syslog.confが存在するコンピュータにスーパーユーザー(ルート)権限でログインします。
監査ファイルの宛先をsyslog構成ファイル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
SHUTDOWN IMMEDIATE
STARTUP
|
関連項目: AUDIT文の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
標準監査オプションを構成するには、AUDIT SQL文を使用します。
表9-3に、AUDIT文を使用できるカテゴリを示します。
表9-3 標準監査レベルとその影響
| レベル | 影響 |
|---|---|
|
文 |
特定の型のデータベース・オブジェクトに影響を与える特定のSQL文または文のグループを監査します。たとえば、 |
|
権限 |
特定のシステム権限によって許可されるSQL文を監査します。たとえば、 |
|
オブジェクト |
|
|
ネットワーク |
ネットワーク・プロトコルの不測エラーまたはネットワーク・レイヤーの内部エラーを監査します。 |
文、権限およびスキーマ・オブジェクトの監査では、文の正常な実行、異常終了した実行、またはその両方の文実行を選択して監査できます。このため、監査対象の文が正常終了しなかった場合にも、アクションを監視できます。異常終了したSQL文を監視することで、アクセス違反や不当な処理を行っているユーザーを判別できます。ただし、異常終了したSQL文の原因はそのどちらでもない場合がほとんどです。
この監査方法は、監査証跡が減少するため特定のアクションに重点を置きやすくなるという点でも役立ちます。これにより、データベースの良好なパフォーマンスを維持できます。
オプションは、次のとおりです。
WHENEVER NOT SUCCESSFUL句: この句を指定すると、監査対象の文の異常終了した実行のみが監査されます。
異常終了した文の監査では、有効なSQL文を実行しても適切な認可がないために異常終了した場合や、存在しないスキーマ・オブジェクトを参照したために異常終了した場合にのみ監査レポートが生成されます。有効ではなかったために異常終了した文は監査できません。
たとえば、異常終了した文の実行を監査するように権限監査オプションが設定されている場合は、対象のシステム権限を使用しても他の原因で異常終了した文が監査されます。1つの例として、CREATE TABLE監査条件を設定したが、指定した表領域に対する割当て制限が不十分だったためにCREATE TABLE文が異常終了した場合などがあります。
WHENEVER SUCCESSFULまたはWHENEVER NOT SUCCESSFULを省略した場合: これらの句を省略すると、Oracle Databaseでは監査対象の文の正常な実行と異常終了した実行の両方が監査されます。
次に例を示します。
AUDIT CREATE TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;
Oracle Databaseでは、次のように、監査対象の文または操作が実行されるたびに監査レコードが生成されます。
監査が設定されたSQL文が実行されるたび。これには、PL/SQLプロシージャ内でのSQL文の実行も含まれます。
監査が構成されている権限が使用されるたび
監査が構成されているオブジェクトが操作されるたび
カーソル内で監査対象の操作が実行されるたびに、Oracle Databaseでは監査証跡に監査レコードが1つ挿入されます。カーソルを再利用させるイベントは、次のとおりです。
カーソルを再利用のためにオープン状態にしておく、Oracle Formsなどのアプリケーション
新しいバインド変数を使用したカーソルの継続実行
1つのカーソルを再利用するためにPL/SQLエンジンにより文が最適化される場合に、PL/SQLループ内で実行される文
監査は、カーソルが共有されているかどうかの影響を受けません。それぞれのユーザーは、カーソルの最初の実行時に自分の監査証跡レコードを作成します。
デフォルトでは、Oracle DatabaseはBY ACCESS句の機能を使用して、監査対象イベントごとに新しい監査レコードを書き込みます。この機能を使用するには、AUDIT文にBY ACCESSを指定します。これはデフォルト設定であるため、省略することもできます (Oracle Database 11g リリース2(11.2.0.2)の時点では、BY ACCESS句はデフォルト設定です)。
AUDIT文では、BY SESSIONではなくBY ACCESSを監査することをお薦めします。AUDIT文でBY ACCESS句を使用する利点は、次のとおりです。
BY ACCESS監査オプションを使用した場合、実行ステータス(リターン・コード)、実行日時、使用された権限、アクセスされたオブジェクト、SQLテキスト自体とそのバインド値など、より多くの情報を含む監査レコードが生成されます。また、BY ACCESS監査オプションを使用すると、実行ごとにSCNが取得されるため、フラッシュバック問合せに役立ちます。
Oracle Databaseでは、SQL文の各実行、権限の使用および監査対象オブジェクトへのアクセスを個別に記録します。各実行に対してリターン・コード、タイムスタンプおよびSQLテキストの値が正確に記録されることによって、そのアクションの実行回数を特定することが容易になります。
BY ACCESS監査レコードには、それぞれにファイングレイン・タイムスタンプが付けられたLOGONエントリとLOGOFFエントリが別個に存在します。
次に例を示します。
AUDIT SELECT TABLE BY ACCESS;
この使用例は、次のとおりです。
ユーザーjwardでデータベースに接続し、departmentsという表に対して5つのSELECT文を発行した後、そのデータベースとの接続を切断します。
ユーザーswilliamsでデータベースに接続し、departments表に対して3つのSELECT文を発行した後、そのデータベースとの接続を切断します。
監査証跡には、SELECT文ごとに1レコードずつ、8件のレコードが記録されます。
文監査オプションと権限監査オプションでは、任意のユーザーが発行した文を監査するか、特定のユーザー・リストに含まれるユーザーが発行する文を監査するかを選択できます。特定のユーザーに限定すると、生成される監査レコードの数は最小限に抑えられます。
例9-6に、ユーザーscottとblakeが表やビューを問い合せたり更新するときに、ユーザー別に文を監査する方法を示します。
ユーザー別の監査の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
NOAUDIT文を使用すると、監査オプションが解除されます。このオプションは、文監査オプション、権限監査オプションおよびオブジェクト監査オプションの設定を解除するために使用します。文監査オプションおよび権限監査オプションを設定するNOAUDIT文では、BY user句によってユーザーのリストを指定し、各監査オプションの適用範囲を限定できます。
NOAUDIT文では、WHENEVER句を使用して監査オプションを選択的に使用禁止にできます。この句の指定がない場合は、正常終了と異常終了のどちらの場合にも監査オプションは完全に使用禁止となります。
NOAUDIT文では、BY ACCESS句はサポートされていません。このため、監査オプションは、その設定状況(有効かどうか)に関係なく、適切なNOAUDIT文によって解除できます。
|
関連項目: NOAUDIT文の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
この項の内容は、次のとおりです。
SQL文監査とは、特定タイプのデータベース構造やスキーマ・オブジェクトに関するSQL文の関連グループに対する選択的な監査のことです。ただし、監査の対象として特定の構造やスキーマ・オブジェクトを指定することはできません。
監査可能な文は、次のカテゴリに分類されます。
文監査では、監査の対象を拡大してすべてのデータベース・ユーザーのアクティビティを監査したり、対象を限定して特定のアクティビティ・リストのアクティビティのみを監査できます。
SQL文監査を構成するには、AUDIT文を使用します。監査を使用可能にするには、AUDIT SYSTEMシステム権限が必要です。通常、このシステム権限はセキュリティ管理者にのみ付与されています。
例9-7に、SELECT TABLE SQL文を監査する方法を示します。
例9-8に、すべての表の異常終了したSELECT、INSERTおよびDELETE文を、全データベース・ユーザーに対して個々の監査対象文別にすべて監査する方法を示します。
すべてのSQL文、個々のユーザー接続または存在しないオブジェクトへの参照を監査する予定の場合は、次のガイドラインに従ってください。
個々のユーザーのすべてのSQL文を監査する場合。ALL STATEMENTS句を使用して、トップレベルのSQL文のみを監査できます。この監査オプションの動作は、他の文の監査オプションとは異なります。PL/SQLプロシージャ内から発行されたSQL文は、ALL STATEMENTS監査オプションでは監査されません。この監査オプションは、設定済の他のAUDITオプションには影響しません。
たとえば、ユーザーjwardおよびjsmithによって発行され、正常終了したすべての文を監査するには、次のように入力します。
AUDIT ALL STATEMENTS BY jward, jsmith BY ACCESS WHENEVER SUCCESSFUL;
個別のユーザーが実行するすべてのSQL文ショートカット・アクティビティを監査する場合。ALL句を使用すると、『Oracle Database SQL言語リファレンス』の表13-1および表13-2にリストされているすべてのSQL文ショートカットを監査できます。
次に例を示します。
AUDIT ALL BY jward BY ACCESS;
ユーザーに関係なく、現行セッションのすべてのSQL文を監査する場合。ALL STATEMENTS監査オプションでIN SESSION CURRENT句を使用して、ユーザー・セッションの存続期間におけるトップレベルのSQL文を監査できます。特定のユーザーに対してIN SESSION CURRENT句を使用することはできません。監査はユーザー・セッションが続いているかぎり継続し、NOAUDIT文を使用して取り消すことはできません。ユーザーがセッションを終了すると、監査は終了します。
たとえば、現行ユーザー・セッションにおいて異常終了したすべての文を監査するには、次のように入力します。
AUDIT ALL STATEMENTS IN SESSION CURRENT BY ACCESS WHENEVER NOT SUCCESSFUL;
AUDIT ALL STATEMENTS監査オプションとIN SESSION CURRENT句は、データベース・ログイン・トリガー内に指定できます。データベース・ログイン・トリガーでは、SYS_CONTEXT関数を使用して、午後6時30分から午前9時までの期間のユーザー・ログインなど、特定の条件に限定してこの監査を構成できます。これにより、営業時間外にデータベースにログインしたユーザーによって実行されたSQL文を取得できるようになります。
このタイプの監査は、対象の接続がセキュアでないか、内部の脅威をもたらす疑いがある場合に、監査アクティビティの収集を拡張するのに役立ちます。たとえば、データベース・ログイン・トリガーを使用すると、SYS_CONTEXTファンクションによって接続コンテキストの内容を問い合せることができます。
ログイン・トリガー機能によって、対象の接続についてより徹底した監査を実施できるようになります。次のSQLコマンドを発行します。
AUDIT ALL STATEMENTS IN SESSION CURRENT;
このタイプの監査は、対象のセッションが終了するまで有効です。
ログイン時とログオフ時の接続と切断を監査する場合。AUDIT SESSION文では、ログイン・イベントとログオフ・イベントごとに独立した監査レコードが生成されます。これにより、ユーザーに関係なく、データベースとの間で正常終了および異常終了した接続と切断をすべて監査できます。
次に例を示します。
AUDIT SESSION BY ACCESS;
次の例に示すように、このオプションはユーザーごとに設定することもできます。
AUDIT SESSION BY jward, jsmith BY ACCESS;
オブジェクトがないために異常終了した文を監査する場合。AUDIT文のNOT EXISTSオプションを指定して、ターゲット・オブジェクトがないために異常終了したすべてのSQL文を監査できます。
次に例を示します。
AUDIT NOT EXISTS;
AUDIT SQL文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
SQL文監査を解除するには、NOAUDIT SQL文を使用します。(権限監査は有効のままになります。)SQL文監査を解除するには、AUDIT SYSTEMシステム権限が必要です。AUDIT ALL STATEMENTSオプションを構成した場合は、NOAUDIT AUDIT STATEMENTS文を発行しても、設定してある他の監査オプションへの影響はありません。IN SESSION CURRENT句をAUDIT文に含めた場合は、NOAUDIT文を使用してこのAUDIT文を解除できません。(監査設定は、ユーザーのセッションが終了すると中断します。)
例9-9に、NOAUDIT文を使用して監査を解除する例を示します。
例9-9 NOAUDITを使用してセッションおよびSQL文監査を解除する方法
NOAUDIT session; NOAUDIT session BY preston, sebastian; NOAUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE;
例9-10に、NOAUDIT文を使用してすべての文の監査を解除する方法を示します。
NOAUDIT文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
この項の内容は、次のとおりです。
任意のシステム権限の使用を監査できます。文監査と同様に、権限監査では、すべてのデータベース・ユーザーのアクティビティを監査したり、特定のデータベース・ユーザーのアクティビティのみを監査します。
文監査と権限監査の両方について類似の監査オプションを設定しても、生成される監査レコードは1つのみです。たとえば、文の句TABLEとシステム権限のCREATE TABLEの両方を監査すると、表が作成されるたびに監査レコードが1つのみ生成されます。
権限監査は、アクションが既存の所有者およびオブジェクト権限によってすでに許可されている場合は実行されません。権限監査がトリガーされるのは、権限が不十分な場合、つまりアクションを可能にする権限がシステム権限である場合のみです。たとえば、ユーザーSCOTTにSELECT ANY TABLE権限が付与されており、SELECT ANY TABLEが監査対象であるとします。SCOTTが自分の表(たとえば、SCOTT.EMP)を選択した場合、SELECT ANY TABLE権限は使用されません。自分自身のスキーマ内でSELECT文を実行したため、監査レコードは生成されません。一方、SCOTTが他のスキーマ(たとえばHR.EMPLOYEES表)から選択すると、監査レコードが生成されます。SCOTTは自分自身のスキーマ外にある表を選択したため、SELECT ANY TABLE権限を使用する必要がありました。
権限監査は文監査よりも対象が絞られますが、これは各々の権限監査オプションは、文の関連リストではなく、特定タイプの文のみ監査するためです。たとえば、文監査句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-11に、DELETE ANY TABLE権限を監査する方法を示します。
DELETE ANY TABLEシステム権限の正常な使用の場合と異常終了した使用の場合をすべて監査するには、次の文を実行します。
AUDIT DELETE ANY TABLE BY ACCESS;
権限監査オプションをすべて解除するには、次の文を入力します。
NOAUDIT ALL PRIVILEGES;
この例では、例9-11の監査設定を使用禁止にしています。
NOAUDIT DELETE ANY TABLE;
権限監査オプションを使用禁止にするには、AUDIT SYSTEMシステム権限が必要です。通常、このシステム権限はセキュリティ管理者にのみ付与されています。
AUDIT文を使用して、複数層環境のクライアントのアクティビティを監査できます。複数層環境では、クライアントの識別情報をすべての層を通して保持できます。したがって、クライアントにかわって中間層アプリケーションにより行われたアクションを、AUDIT文の中でBY user句を使用することで監査できます。監査は、プロキシ・セッションを含むすべてのユーザー・セッションに適用されます。
中間層では、データベース・セッションでユーザーのクライアント識別情報を設定し、中間層アプリケーションでエンド・ユーザーのアクションを監査することもできます。そうすることにより、エンド・ユーザーのクライアント識別情報が監査証跡に記録されます。
例9-12は、ユーザーjacksonによって発行されたSELECT TABLE文を監査する方法を示しています。
複数層環境でユーザー・アクティビティを監査できます。監査を開始した後で、DBA_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せることでこれらのアクティビティを確認できます。
図9-1に、DBA_AUDIT_TRAILビューのCOMMENT_TEXT、PROXY_SESSIONID、ACTION_NAMEおよびSESSION_ID列を問い合せることで、プロキシ・ユーザーを監査する方法を示します。このシナリオでは、データベース・ユーザーとプロキシ・ユーザーの両方のアカウントがデータベースに認識されます。セッション・プーリングを使用できます。
図9-2に、DBA_AUDIT_TRAILデータ・ディクショナリ・ビューのCLIENT_ID列を問い合せることで、複数のデータベース・セッションにわたるクライアント識別子情報を監査する方法を示します。この例では、クライアント識別子はCLIENT_Aに設定されています。図9-1に示すプロキシ・ユーザー/データベース・ユーザーの例と同様に、セッション・プーリングを使用できます。
この項の内容は、次のとおりです。
スキーマ・オブジェクト監査では、表やビューなど、監査対象のオブジェクトに対して実行されるアクションが監視されます。オブジェクト監査はすべてのユーザーに適用されますが、監査対象のオブジェクトのみに限定されます。ユーザーは、自分のスキーマ内のオブジェクトに対してAUDITおよびNOAUDIT文を使用できます。
監査できる文は表、ビュー、順序、スタンドアロンのストアド・プロシージャまたはファンクション、およびパッケージを参照する文です。パッケージ内の個々のプロシージャを参照する文は監査できません。(これらのタイプのオブジェクトの監査の詳細は、「ファンクション、プロシージャ、パッケージおよびトリガーの監査」を参照してください。)
クラスタ、データベース・リンク、索引またはシノニムを参照する文は、直接監査できません。ただし、実表に影響を与える操作を監査することによって、これらのスキーマ・オブジェクトへのアクセスを間接的に監査できます。
スキーマ・オブジェクトを監査する場合、監査はデータベースのすべてのユーザーに適用されます。これらのオプションは、特定のユーザーのリストに対しては設定できません。監査対象のすべてのスキーマ・オブジェクトに対して、デフォルトのスキーマ・オブジェクト監査オプションを設定できます。
|
関連項目: 監査対象のスキーマ・オブジェクトの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
エディション付きオブジェクトに監査ポリシーが付加されている場合、そのオブジェクトが表示されるすべてのエディションにそのポリシーが適用されます。エディション付きオブジェクトが実現化されると、そのオブジェクトに付加されている監査ポリシーが新しい実際のオブジェクトに新たに付加されます。継承されたエディション付きオブジェクトに新たに監査ポリシーを適用すると、そのオブジェクトが実現化されます。
監査対象のオブジェクトが表示されるエディションを調べるには、DBA_COMMON_AUDIT_TRAILおよびV$XML_AUDIT_TRAILデータ・ディクショナリ・ビューのOBJECT_NAMEおよびOBJ_EDITION_NAME列を問い合せます。
|
関連項目: エディションの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。 |
ビューとプロシージャ(ストアド・ファンクション、パッケージおよびトリガーを含む)の定義は、基礎となるスキーマ・オブジェクトを参照します。この依存性があるために、複数の監査レコードが生成される場合があるなど、ビューとプロシージャの監査には、固有の特性がいくつかあります。
ビューとプロシージャは、デフォルトの監査オプションも含め、ベース・スキーマ・オブジェクトで使用可能な監査オプションに依存します。これらのオプションは、結果のSQL文にも適用されます。
次の一連のSQL文について考えてみます。
AUDIT SELECT ON HR.EMPLOYEES BY ACCESS;
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 BY ACCESS;
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表の監査レコードは生成されません。
AUDIT文を使用して、現行エディションにオブジェクト監査を構成できます。AUDITに有効なオブジェクト監査オプションと、各オプションが使用できるスキーマ・オブジェクトのタイプの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
ユーザーは、自分のスキーマ内にあるオブジェクトのオブジェクト監査オプションを設定できます。他のユーザーのスキーマ内にあるオブジェクトのオブジェクト監査オプションを設定したり、デフォルトのオブジェクト監査オプションを設定するには、AUDIT ANYシステム権限が必要です。通常、AUDIT ANY権限はセキュリティ管理者にのみ付与されています。
図9-2に、laurel.emp表に対する正常終了および異常終了したDELETE文をすべて監査する方法を示します。
例9-14に、ユーザーjwardが所有するdept表に対する正常終了したSELECT、INSERTおよびDELETE文をすべて監査する方法を示します。
例9-15に、ON DEFAULT句を使用して、AUDIT文の設定後に作成された新規オブジェクト(表、ビューおよび順序)に適用する方法を示します。この例では、将来作成される新規オブジェクトが、異常終了したすべてのSELECT文について監査されます。
例9-16に、PL/SQLプロシージャまたはファンクションの実行を監査する方法を示します。
オブジェクト監査を解除するには、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 BY ACCESS;
この文では、デフォルトで以降のすべてのオブジェクト作成文が監査されます。ONキーワードは、オブジェクト監査を指定します。ON DEFAULT句では、以降に作成されて次の文の影響を受けるオブジェクトの監査を構成します。
| 文A-D | 文E-I | 文I-R | 文S-Y |
|---|---|---|---|
ALTER |
EXECUTE |
INSERT |
SELECT |
AUDIT |
GRANT |
LOCK |
UPDATE |
COMMENT |
FLASHBACK |
READ |
- |
DELETE |
INDEX |
RENAME |
- |
ON DEFAULTを特定のアクションに限定するには、次のような文を入力します。
AUDIT ALTER, DELETE ON DEFAULT BY ACCESS;
監査オプションとAUDIT SQL文のON DEFAULT句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。デフォルトで監査対象となるオブジェクトを検索するには、ALL_DEF_AUDIT_OPTSデータ・ディクショナリ・ビューを問い合せます。
この項の内容は、次のとおりです。
ディレクトリ・オブジェクトは監査可能です。たとえば、ORACLE_LOADERアクセス・ドライバで使用されるプリプロセッサ・プログラムを含むディレクトリ・オブジェクトを作成するとします。ディレクトリ・オブジェクト内のこのプログラムを実行するすべてのユーザーを監査できます。
オブジェクト監査を使用可能にするには、AUDIT文を使用します。例9-17に、ディレクトリ・オブジェクトmy_execに対するEXECUTE権限を監査する方法を示します。
ディレクトリ・オブジェクト監査を使用禁止にするには、NOAUDIT文を使用します。次に例を示します。
NOAUDIT EXECUTE ON DIRECTORY my_exec;
この項の内容は、次のとおりです。
ファンクション、プロシージャ、PL/SQLパッケージおよびトリガーを監査できます。監査可能な領域は次のとおりです。
すべての実行の監査を使用可能にすると、データベース内のすべてのトリガーおよびPL/SQLパッケージ内のすべてのファンクションとプロシージャが監査されます。
PL/SQLパッケージ内のファンクションまたはプロシージャを個別に監査することはできません。
Oracle Virtual Privateデータベース・ポリシーに関連付けられているファンクションを監査する場合は、次のことに注意してください。
例9-18に、データベースの任意のユーザーによるファンクション、プロシージャ、パッケージまたはトリガーの実行を監査する方法を示します。
例9-19に、ユーザーpsmithによるファンクション、プロシージャ、パッケージおよびトリガーの正常終了および異常終了した実行を監査する方法を示します。
例9-20に、sales_dataスキーマ内のcheck_workという名前のスタンドアロン・プロシージャを監査する方法を示します。この方法は、スタンドアロン・ファンクションにも適用されます。
ファンクション、プロシージャおよびトリガーの監査を解除するには、NOAUDIT文を使用します。次に例を示します。
NOAUDIT EXECUTE PROCEDURE; NOAUDIT EXECUTE PROCEDURE BY psmith; NOAUDIT EXECUTE ON sales_data.checkwork;
この項の内容は、次のとおりです。
AUDIT文を使用して、ネットワーク・プロトコルの予期しないエラーやネットワーク層で発生した内部エラーを監査できます。ネットワーク監査によって、ネットワーク上のクライアントとの通信中に発生するエラーが取得されます。これらのエラーは、SQL*Netドライバによってスローされます。ネットワーク・エラーの原因には様々なものがあります。たとえば、データベース・エンジニアがテスト目的で設定した内部イベントがネットワーク・エラーの原因になることもあります。他にも、ネットワークが暗号化の作成または処理に必要な情報を見つけられないなど、暗号化の構成設定の競合などが原因として考えられます。ネットワーク監査で発見されるエラー(ACTION 122 ネットワーク・エラーなど)は接続障害ではありません。ネットワーク監査で対象となるのは、ネットワーク上を移動するデータに限られます。
ネットワーク監査の監査レコードでは、監査レコードのCOMMENT_TEXTフィールドにクライアント(使用可能な場合)の認証タイプとSQL*Netアドレスが次の形式でリストされます。
Authenticated by: authentication_type; Client Address: SQLNetAddress_of_client
Client Address: SQLNetAddress_of_client部分は、この情報が使用可能な場合にのみ表示されます。
表9-4に、4つの一般的なエラー状況の解決方法を示します。
表9-4 監査可能なネットワーク・エラーの状況
| エラー | 原因 | 処置 |
|---|---|---|
|
|
アルゴリズムの選択後、サーバーはアルゴリズムの表でその索引を見つけることができませんでした。アルゴリズムが(間接的に)このリストから選択されているため、処理ができません。 |
詳細を調べるためにトレースをオンにしてから、操作を再実行してください。(このエラーは、通常はユーザーに表示されません。)エラーが解決しない場合は、Oracleサポート・サービスまでお問い合せください。 |
|
|
Oracle Advanced Securityのアルゴリズム・リスト・パラメータが空です。 |
インストールされているアルゴリズムのうち、少なくとも1つのアルゴリズム名が含まれるようにリストを変更するか、インストールされているすべてのアルゴリズムが許容できない場合は、リスト全体を削除します。 |
|
|
Oracle Advanced Securityのアルゴリズム・リスト・パラメータに、認識されていないアルゴリズム名が含まれています。 |
アルゴリズム名を削除、スペルが間違っている場合はスペルを修正、あるいは欠落しているアルゴリズムのドライバをインストールします。 |
|
|
クライアントとサーバーには、暗号化またはデータ整合性、あるいはこれら両方についての共通のアルゴリズムがありません。 |
共通のアルゴリズム・セットを選択します。つまり、クライアント・アルゴリズムの選択肢の1つをサーバー・リストに追加するか、サーバー・リストの選択肢の1つをクライアント・アルゴリズムに追加します。 |
この項の内容は、次のとおりです。
Database Configuration Assistant (DBCA)を使用して、新しいデータベースを作成する場合、Oracle Databaseはセキュリティに関連する最も一般的に使用されるSQL文と権限を監査するようにデータベースを構成します。また、AUDIT_TRAIL初期化パラメータをDBに設定します。別の監査証跡のタイプ(たとえば、監査証跡レコードをオペレーティング・システム・ファイルに記録する場合はOS)を使用する場合は、そのような設定もでき、Oracle Databaseは、デフォルトで監査された権限を引き続き監査します。AUDIT_TRAILパラメータをNONEに設定して監査を無効にすると、監査は実行されません。
If データベースを手動で作成した後、secconf.sqlスクリプトを実行して、デフォルト監査設定をデータベースに適用する必要があります。詳細は、「デフォルト監査設定の無効化および有効化」を参照してください。
SQL文および権限の監査を個別に制御するには、AUDIT文とNOAUDIT文を使用します。詳細は、「SQL文の監査」および「権限の監査」を参照してください。
Oracle Databaseでは、デフォルトで次の権限が監査されます。
| 権限A-C | 権限C-D | 権限D-G |
|---|---|---|
ALTER ANY PROCEDURE |
CREATE ANY LIBRARY |
DROP ANY TABLE |
ALTER ANY TABLE |
CREATE ANY PROCEDURE |
DROP PROFILE |
ALTER DATABASE |
CREATE ANY TABLE |
DROP USER |
ALTER PROFILE |
CREATE EXTERNAL JOB |
EXEMPT ACCESS POLICY |
ALTER SYSTEM |
CREATE PUBLIC DATABASE LINK |
GRANT ANY OBJECT PRIVILEGE |
ALTER USER |
CREATE SESSION |
GRANT ANY PRIVILEGE |
AUDIT SYSTEM |
CREATE USER |
GRANT ANY ROLE |
CREATE ANY JOB |
DROP ANY PROCEDURE |
- |
Oracle Databaseでは、デフォルトで次のSQLショートカットが監査されます。
| ショートカットD-P | ショートカットP-R | ショートカットS |
|---|---|---|
DATABASE LINK |
PUBLIC SYNONYM |
SYSTEM AUDIT |
PROFILE |
ROLE |
SYSTEM GRANT |
|
関連項目:
|
アプリケーションでOracle Database 10g リリース2(10.2)のデフォルトの監査設定を使用している場合、リリース11gの監査設定を使用するようにアプリケーションを変更するまでは、設定の復元が可能です。そのためには、undoaud.sqlスクリプトを実行します。
リリース11gの監査設定に準拠するようにアプリケーションを変更した後は、データベースを手動で更新して、実際のビジネス・ニーズに合った監査構成を使用することも、secconf.sqlスクリプトを実行して、リリース11gのデフォルトの監査設定を適用することもできます。必要に応じて、異なるセキュリティ設定を使用するようにこのスクリプトをカスタマイズできますが、元のスクリプトにリストされている設定は、Oracle推奨の設定であることに注意してください。
データベースを手動で作成した場合は、secconf.sqlスクリプトを実行して、リリース11gのデフォルト監査設定をデータベースに適用する必要があります。Database Configuration Assistantを使用して作成されたデータベースではこの設定が使用されますが、手動で作成したデータベースでは使用されません。
undoaud.sqlおよびsecconf.sqlスクリプトは、$ORACLE_HOME/rdbms/adminディレクトリにあります。undoaud.sqlスクリプトは監査設定にのみ影響し、secconf.sqlスクリプトは監査設定とパスワード設定の両方に影響します。いずれも他のセキュリティ設定には影響を与えません。
この項の内容は、次のとおりです。
ファイングレイン監査では、ポリシーを作成して、監査が実行される特定の条件を定義できます。これにより、内容に基づいてデータ・アクセスを監視できるようになります。問合せと、INSERT、UPDATE、およびDELETE操作に対して詳細な監査を提供します。たとえば、中央の税務当局は、所員による権限外の閲覧を防止するために、どのデータがアクセスされたかを判断できる十分な詳細を使用して納税申告書へのアクセスを追跡する必要があります。特定の表に対して特定のユーザーによってSELECT権限が使用されたことを知るのみでは不十分です。ファイングレイン監査によって、完全な監視機能が実現します。
通常、ファイングレイン監査ポリシーは、選択的監査の条件である、表オブジェクトに対する単純なユーザー定義SQL述語に基づいています。フェッチ中に行がポリシーの条件を満たすと、その問合せが監査対象となります。
ファイングレイン監査を使用すると、次のタイプのアクションを監査できます。
午後9時から午前6時の間、または土曜日と日曜日に表にアクセスする場合
社内ネットワーク外部のIPアドレスを使用する場合
表の列を選択または更新する場合
表の列の値を変更する場合
ファイングレイン監査レコードは、SYS.FGA_LOG$表に格納されます。有効な監査ポリシーに対して生成されたレコードを検索するには、DBA_FGA_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。DBA_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビューは、標準監査とファイングレイン監査の両方のログ・レコードを結合します。また、V$XML_AUDIT_TRAILビューを問い合せて、XML形式のファイルに書き込まれたファイングレイン監査レコードを検索できます。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
Oracle Databaseは、SYS.FGA_LOG$ (およびSYS.AUD$)表に対するDELETE、INSERT、UPDATE、およびMERGE操作を常に監査し、SYS.AUD$表に記録します。監査レコードは、ユーザーSYSが操作を実行する場合を除いて削除できません。AUDIT_SYS_OPERATIONS初期化パラメータをTRUEに設定した場合は、ユーザーSYSの操作が監査されます。この場合、すべてのSYS操作の監査レコードは、AUDIT_FILE_DEST初期化パラメータが指しているディレクトリに書き込まれます。AUDIT_FILE_DESTが設定されていない場合、レコードが書き込まれる場所はオペレーティング・システムによって異なります。
ファイングレイン監査を実行すると、監査対象に指定したアクションのみを含む、より有用な監査証跡を作成できます。各表へのアクセスが記録された場合に生じる不要な情報が排除されます。ファイングレイン監査には、標準監査と比べて次のような利点があります。
ブール条件のチェックが実行されます。指定したブール条件と一致すると(表が土曜日にアクセスされているなど)、監査が行われます。
監査をトリガーしたSQLが取得されます。監査が行われたSQL文と関連バインド変数の両方を取得できます。取得できるのは、スカラー列型のデータのみであることに注意してください。オブジェクト列、LOBまたはユーザー定義の列型のデータは取得できません。たとえば、次の問合せを考えてみます。
SELECT NAME FROM EMPLOYEE WHERE SSN = :1
この例で、:1が整数型でSSNの値が987654321の場合は、監査証跡でこの情報を取得できます。ただし、:1がBLOB、CLOB、オブジェクトまたはユーザー定義の型の場合、この情報は取得できません。
この機能を使用できるのは、DBMS_FGA.ADD_POLICY PL/SQLプロシージャのaudit_trailパラメータをDB+EXTENDEDまたはXML+EXTENDEDに設定してファイングレイン監査ポリシーを作成する場合です。
機密情報が含まれた列に特別な保護を追加します。給与または社会保障番号など、機密情報が格納されている可能性のある特定の関連列を監査できます。
イベント処理機能が提供されます。たとえば、夜中に変更されないようにする必要がある監査対象の列が更新された場合に、セキュリティ管理者に電子メール・アラートを送信する関数を作成できます。
ファイングレイン監査を使用可能にするために初期化パラメータを設定する必要がありません。AUDIT_TRAILなどの初期化パラメータを設定するかわりに、DBMS_FGA PL/SQLパッケージを使用して、監視する特定の操作またはオブジェクトに適用するファイングレイン監査ポリシーを必要に応じて追加および削除します。
ファイングレイン監査ポリシーを作成するには、DBMS_FGA PL/SQLパッケージに対するEXECUTE権限が必要です。パッケージは、SYSユーザーが所有します。
SYS.AUD$表には、非SYSユーザーがSYS.FGA_LOG$表に対して実行したINSERT、UPDATE、MERGE、DELETEなど、すべてのデータ操作言語(DML)文が記録されます。これらのアクティビティが実行されるSYS.FGA_LOG$表に対して監査が構成されていない場合でも、監査は実行されます。これらのアクティビティを調べるには、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.ADD_POLICY audit_trailパラメータのDB+EXTENDEDおよびXML+EXTENDED設定によりこのデータが取得されることに注意してください。この状況に対処する方法は、「機密情報の監査」を参照してください。 |
ファイングレイン監査証跡では、SQL文内の表またはビューの参照ごとに監査レコードが取得されます。たとえば、HR.EMPLOYEES表を2回参照するUNION文を実行した場合、文の監査ポリシーによって2つ(HR.EMPLOYEES表へのアクセスごとに1つ)の監査レコードが生成されます。
この項の内容は、次のとおりです。
ファイングレイン監査ポリシーを管理するには、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パッケージ・ポリシーを異なる複数のエディションで使用する場合、ポリシーの結果を制御できます。つまり、結果をすべてのエディションで同一にするか、またはポリシーが使用されているエディションに固有にすることができます。詳細は、「エディションがグローバル・アプリケーション・コンテキストのPL/SQLパッケージの結果に与える影響」を参照してください。 |
ファイングレイン監査ポリシーを作成するには、DBMS_FGA.ADD_POLICYプロシージャを使用します。このプロシージャは、監査条件として提供された述語を使用して、監査ポリシーを作成します。ポリシーの述語は、ポリシーを作成したユーザーの権限で実行されます。表オブジェクトまたはビュー・オブジェクトに設定可能なファイングレイン・ポリシーの最大数は256です。Oracle Databaseでは、ポリシーはデータ・ディクショナリ表に格納されますが、SYSスキーマ内に存在しない表またはビューに関するポリシーを作成できます。
作成したファイングレイン監査ポリシーは特定のスキーマには属しておらず、その定義はSYS.FGA$データ・ディクショナリ表に格納されています。
ファイングレイン監査ポリシーを作成後に変更することはできません。ポリシーの変更が必要になった場合は、削除してから再作成します。
表の列にファイングレイン監査ポリシーが含まれている場合は、(UPDATE文を使用して)この列を暗号化することも復号化することもできないことに注意してください。実行した場合、ORA-28133「完全な表アクセスがファイングレイン・セキュリティによって制限されています」エラーが発生します。列を更新する場合は、まずファイングレイン監査ポリシーを一時的に無効にし、それから列を暗号化または復号化します。その後に、ファイングレイン監査ポリシーを再有効化します。詳細は、「ファイングレイン監査ポリシーの無効化および有効化」を参照してください。
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: 監査するオブジェクトのスキーマを指定します。(NULLの場合、現行のログイン・ユーザーのスキーマと想定されます。)
object_name: 監査するオブジェクトの名前を指定します。
policy_name: 作成するポリシーの名前を指定します。この名前は必ず一意にしてください。
audit_condition: 行のブール条件を指定します。NULLも指定できます(TRUEとして機能します)。詳細は、「特定の列および行の監査」を参照してください。監査条件にNULLを指定するか、何も指定しない場合は、そのポリシーが設定された表に対するアクションが行われると、行が戻されるかどうかに関係なく監査レコードが作成されます。
次のガイドラインに従ってください。
ファンクションは、同じ実表で監査可能な文を実行するため、audit_condition設定に含めないでください。たとえば、HR.EMPLOYEES表に対してINSERT文を実行するファンクションを作成するとします。ポリシーのaudit_conditionには、このファンクションが含まれていて、これは(statement_typesにより設定される)INSERT文のポリシーです。このポリシーが使用されると、ファンクションはシステムのメモリーが足りなくなるまで再帰的に実行します。これにより、 ORA-1000: 最大オープン・カーソル数を超えました。または ORA-00036: 再帰的SQLレベルの最大値(50)を超えましたのエラーが発生する場合があります。
DBMS_FGA.ENABLE_POLICY文またはDBMS_FGA.DISABLE_POLICY文を、ポリシーの条件に含まれるファンクションから発行しないでください。
audit_column: 監査対象の1つ以上の列(非表示列も含む)を指定します。NULLに設定するかまたは省略すると、すべての列が監査されます。Oracle Label Securityの非表示列やオブジェクト・タイプ列も対象になります。デフォルトのNULLでは、列へのアクセスや影響があった場合に監査が行われます。
handler_schema: ポリシーに違反した場合の応答のトリガーにアラートが使用される場合は、イベント・ハンドラが含まれているスキーマの名前を指定します。デフォルトのNULLでは、現行のスキーマが使用されます。「例: ファイングレイン監査ポリシーへの電子メール・アラートの追加」も参照してください。
handler_module: イベント・ハンドラの名前を指定します。イベント・ハンドラが含まれるパッケージも対象になります。このファンクションは、問合せの監査条件と一致する最初の行が処理された後でのみ実行されます。
次のガイドラインに従ってください。
再帰的ファイングレイン監査ハンドラを作成しないでください。たとえば、HR.EMPLOYEES表に対してINSERT文を実行するハンドラを作成するとします。このハンドラに関連付けられるポリシーは、(statement_typesパラメータにより設定される)INSERT文のポリシーです。このポリシーが使用されると、ハンドラはシステムのメモリーが足りなくなるまで再帰的に実行します。これにより、 ORA-1000: 最大オープン・カーソル数を超えました。または ORA-00036: 再帰的SQLレベルの最大値(50)を超えましたのエラーが発生する場合があります。
DBMS_FGA.ENABLE_POLICY文またはDBMS_FGA.DISABLE_POLICY文をポリシー・ハンドラから発行しないでください。これらの文を発行すると、 ORA-28144: ファイングレイン監査ハンドラの実行に失敗しましたエラーが発生する場合があります。
enable: TRUEまたはFALSEを使用してポリシーを使用可能または使用禁止にします。省略した場合、ポリシーは使用可能になります。デフォルトはTRUEです。
statement_types: 監査対象のSQL文を指定します。INSERT、UPDATE、DELETEまたはSELECTのみです。デフォルト値はSELECTです。
audit_trail: ファイングレイン監査レコードの宛先(DBまたはXML)を指定します。LSQLTEXTおよびLSQLBINDをFGA_LOG$に移入するかどうかも指定します。ただし、クレジット・カード情報などの機密データもクリアテキストで記録できることに注意してください。この状況に対処する方法は、「機密情報の監査」を参照してください。
audit_trailパラメータをXMLに設定すると、XMLファイルはAUDIT_FILE_DEST初期化パラメータで指定されたディレクトリに書き込まれます。
読取り専用データベースの場合、audit_trailの設定に関係なく、ファイングレイン監査証跡はXMLファイルに書き込まれます。
audit_column_opts: audit_columnパラメータで複数の列を指定した場合は、すべての列を監査するか特定の列を監査するかをこのパラメータで決定します。詳細は、「特定の列および行の監査」を参照してください。
ADD_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
例9-21に、表HR.EMPLOYEESに対する文INSERT、UPDATE、DELETEおよびSELECTを監査する方法を示します。この例では、audit_column_optsパラメータが必須パラメータではないため省略されていることに注意してください。
例9-21 DBMS_FGA.ADD_POLICYを使用してファイングレイン監査ポリシーを作成する方法
BEGIN DBMS_FGA.ADD_POLICY( object_schema => 'HR', object_name => 'EMPLOYEES', policy_name => 'chk_hr_employees', enable => TRUE, statement_types => 'INSERT, UPDATE, SELECT, DELETE', audit_trail => DBMS_FGA.DB); 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-21では、部門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,
関連列を指定しない場合、監査はすべての列に適用されます。
DBMS_FGA.ADD_POLICYプロシージャ内のaudit_condition、audit_columnおよびaudit_column_optsパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。その項のADD_POLICYプロシージャの使用方法も参照してください。
ファイングレイン監査ポリシーを使用禁止にするには、DBMS_FGA.DISABLE_POLICYプロシージャを使用します。DISABLE_POLICYの構文は、次のとおりです。
DBMS_FGA.DISABLE_POLICY( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2 );
例9-22に、例9-21で作成したファイングレイン監査ポリシーを使用禁止にする方法を示します。
例9-22 ファイングレイン監査ポリシーを使用禁止にする方法
DBMS_FGA.DISABLE_POLICY( object_schema => 'HR', object_name => 'EMPLOYEES', policy_name => 'chk_hr_employees'); /
DISABLE_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
例9-23に、DBMS_FGA.ENABLE_POLICYプロシージャを使用してchk_hr_empポリシーを再度使用可能にする方法を示します。
例9-23 ファイングレイン監査ポリシーを使用可能にする方法
DBMS_FGA.ENABLE_POLICY( object_schema => 'HR', object_name => 'EMPLOYEES', policy_name => 'chk_hr_employees', enable => TRUE); /
ENABLE_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
DBMS_FGA.ADD_POLICYプロシージャのobject_nameパラメータで指定されたオブジェクトを削除したり、監査ポリシーを作成したユーザーを削除した場合、自動的に監査ポリシーが削除されます。
例9-24に、DBMS_FGA.DROP_POLICYプロシージャを使用して、ファイングレイン監査ポリシーを手動で削除する方法を示します。
例9-24 ファイングレイン監査ポリシーを削除する方法
DBMS_FGA.DROP_POLICY( object_schema => 'HR', object_name => 'EMPLOYEES', policy_name => 'chk_hr_employees');
DROP_POLICYの構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
この項の内容は、次のとおりです。
ユーザー(または侵入者)がポリシーに違反した場合に実施される電子メール・アラートをファイングレイン監査ポリシーに追加できます。そのためには、最初にアラートを生成するプロシージャを作成し、次のDBMS_FGA.ADD_POLICYパラメータを使用して、ユーザーがこのポリシーに違反した場合にこのファンクションをコールする必要があります。
handler_schema: ハンドラ・イベントが格納されるスキーマ
handler_module: イベント・ハンドラの名前
アラートは、電子メールまたはポケベルによる通知や、特定のファイルまたは表の更新など、環境に適した形式で生成できます。アラートを作成すると、California Senate Bill 1386などの特定のコンプライアンス規制を満たすことも可能です。この例では、電子メール・アラートを作成します。
この例では、セキュリティ管理者に対して、人事部門の担当者がHR.EMPLOYEES表内の給与情報を選択または変更しようとしていることを通知する電子メール・アラートを作成します。担当者はこの表を変更することを許可されていますが、コンプライアンス規制を満たすために、表内の給与情報に対するすべての選択および変更操作に関するレコードを作成できます。
ユーザーSYSとしてSYSDBA権限でログインします。
sqlplus sys as sysdba
Enter password: password
UTL_MAILパッケージをインストールします。
@$ORACLE_HOME/rdbms/admin/utlmail.sql @$ORACLE_HOME/rdbms/admin/prvtmail.plb
UTL_MAILパッケージにより、電子メールの管理が可能になります。UTL_MAILの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
現在、UTL_MAIL PL/SQLパッケージではSSLサーバーはサポートされていないことに注意してください。
この例が終了した後に元に戻すことができるよう、SMTP_OUT_SERVER初期化パラメータの現行の値を調べて書き留めておきます。
次に例を示します。
SHOW PARAMETER SMTP_OUT_SERVER
SMTP_OUT_SERVERパラメータがすでに設定されている場合は、次のような出力が表示されます。
NAME TYPE VALUE ----------------------- ----------------- ---------------------------------- SMTP_OUT_SERVER string some_imap_server.example.com
次のALTER SYSTEM文を発行します。
ALTER SYSTEM SET SMTP_OUT_SERVER="imap_mail_server.example.com";
imap_mail_serverを、電子メール・ツールのアカウント設定にあるSMTPサーバーの名前に置き換えます。これらの設定を引用符で囲んでください。次に例を示します。
ALTER SYSTEM SET SMTP_OUT_SERVER="my_imap_server.example.com"
SYSとしてSYSOPER権限で接続し、データベースを再起動します。
CONNECT SYS/AS SYSOPER
Enter password: password
SHUTDOWN IMMEDIATE
STARTUP
SMTP_OUT_SERVERパラメータ設定が正しいことを確認します。
CONNECT SYS/AS SYSDBA
Enter password: password
SHOW PARAMETER SMTP_OUT_SERVER
次のような出力が表示されます。
NAME TYPE VALUE ----------------------- ----------------- ---------------------------------- SMTP_OUT_SERVER string my_imap_server.example.com
SYSとしてSYSDBA権限で接続していることを確認し、sysadmin_fgaアカウント(ファイングレイン監査ポリシーの作成者)を作成します。
次に例を示します。
CONNECT SYS/AS SYSDBA Enter password: password GRANT CREATE SESSION, DBA TO sysadmin_fga IDENTIFIED BY password; GRANT EXECUTE ON DBMS_FGA TO sysadmin_fga; GRANT CREATE PROCEDURE, DROP ANY PROCEDURE TO sysadmin_fga; GRANT EXECUTE ON UTL_TCP TO sysadmin_fga; GRANT EXECUTE ON UTL_SMTP TO sysadmin_fga; GRANT EXECUTE ON UTL_MAIL TO sysadmin_fga; GRANT EXECUTE ON DBMS_NETWORK_ACL_ADMIN TO sysadmin_fga;
passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。
UTL_TCP、UTL_SMTP、UTL_MAILおよびDBMS_NETWORK_ACL_ADMIN PL/SQLパッケージは、作成する電子メール・セキュリティ・アラートで使用されます。
ユーザーSYSTEMで接続します。
CONNECT SYSTEM
Enter password: password
HRスキーマ・アカウントのロックが解除され、パスワードが付与されていることを確認します。必要に応じて、HRのロックを解除し、このユーザーにパスワードを付与します。
SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'HR';
DBA_USERSビューに、ユーザーHRがロックされて期限切れになっていると表示された場合は、次の文を入力して、HRアカウントのロックを解除し、新しいパスワードを作成します。
ALTER USER HR ACCOUNT UNLOCK IDENTIFIED BY password;
安全なパスワードを入力します。セキュリティを向上させるため、以前のリリースのOracle Databaseと同じパスワードをHRアカウントに指定しないでください。パスワードを作成するための最低要件は、「パスワードの最低要件」を参照してください。
人事部門の担当者であるSusan Mavris用のユーザー・アカウントを作成し、このユーザーにHR.EMPLOYEES表へのアクセス権を付与します。
GRANT CREATE SESSION TO smavris IDENTIFIED BY password;
GRANT SELECT, INSERT, UPDATE, DELETE ON HR.EMPLOYEES TO SMAVRIS;
UTL_MAILなどのPL/SQLネットワーク・ユーティリティ・パッケージを使用する場合は、外部ネットワーク・サービスに対するファイングレイン・アクセスを可能にする、アクセス制御リスト(ACL)ファイルを事前に構成する必要があります。詳細は、「PL/SQLパッケージおよびタイプでのファイングレイン・アクセスの管理」を参照してください。
電子メール・アラート用にアクセス制御リストを構成する手順は、次のとおりです。
ユーザーsysadmin_fgaでSQL*Plusに接続します。
CONNECT sysadmin_fga
Enter password: password
次のアクセス制御リストとその権限定義を作成します。
BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL ( acl => 'email_server_permissions.xml', description => 'Enables network permissions for the email server', principal => 'SYSADMIN_FGA', is_grant => TRUE, privilege => 'connect'); END; /
principal設定には、正確なユーザー名を大文字で入力してください。この例では、principalの名前としてSYSADMIN_FGAを入力します。
アクセス制御リストを電子メール・サーバーの送信SMTPネットワーク・ホストに割り当てます。
BEGIN DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( acl => 'email_server_permissions.xml', host => 'SMTP_OUT_SERVER_setting', lower_port => port); END; /
この例の説明は、次のとおりです。
SMTP_OUT_SERVER_setting: 「手順1: UTL_MAIL PL/SQLパッケージのインストールと構成」のSMTP_OUT_SERVERパラメータに設定したSMTP_OUT_SERVER設定を入力します。この設定は、使用している電子メール・ツールで送信サーバー用に指定されている設定と完全に一致させる必要があります。
port: 電子メール・ツールで送信サーバーに指定されているポート番号を入力します。通常、この設定は25です。この値をlower_port設定に入力します。(現在、UTL_MAILパッケージではSSLをサポートしていません。電子メール・サーバーがSSLサーバーの場合、その電子メール・サーバーが別のポート番号を使用していても、ポート番号に25を入力します。)
ユーザーsysadmin_fgaで、次のプロシージャを作成します。(最初の行のCREATE OR REPLACEの前にカーソルを置くことで、このテキストをコピーして貼り付けることができます。)
CREATE OR REPLACE PROCEDURE email_alert (sch varchar2, tab varchar2, pol varchar2)
AS
msg varchar2(20000) := 'HR.EMPLOYEES table violation. The time is: ';
BEGIN
msg := msg||TO_CHAR(SYSDATE, 'Day DD MON, YYYY HH24:MI:SS');
UTL_MAIL.SEND (
sender => 'youremail@example.com',
recipients => 'recipientemail@example.com',
subject => 'Table modification on HR.EMPLOYEES',
message => msg);
END email_alert;
/
この例の説明は、次のとおりです。
CREATE OR REPLACE PROCEDURE ...AS: 次の手順で監査ポリシーに定義するスキーマ名(sch)、表名(tab)および監査プロシージャ名(pol)を表す署名を指定する必要があります。
senderおよびrecipients: youremail@example.comを自分の電子メール・アドレス、recipientemail@example.comを通知の受信対象者の電子メール・アドレスに置き換えます。
ユーザーsysadmin_fgaで、chk_hr_empポリシーをファイングレイン監査ポリシーとして次のように作成します。
BEGIN DBMS_FGA.ADD_POLICY ( object_schema => 'HR', object_name => 'EMPLOYEES', policy_name => 'CHK_HR_EMP', audit_column => 'SALARY', handler_schema => 'SYSADMIN_FGA', handler_module => 'EMAIL_ALERT', enable => TRUE, statement_types => 'SELECT, UPDATE', audit_trail => DBMS_FGA.DB + DBMS_FGA.EXTENDED); END; /
データベースに加えた変更をコミットします。
COMMIT;
今までに作成した設定をテストします。
EXEC email_alert ('hr', 'employees', 'chk_hr_emp');
SQL*Plusに「PL/SQLプロシージャが正常に終了しました。」というメッセージが表示されます。まもなく、電子メール・サーバーの速度に応じて、電子メール・アラートを受信します。
ORA-24247「アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました」エラーの後にORA-06512「string行string」エラーが発生した場合は、アクセス制御リスト・ファイル内の設定を確認してください。
ユーザーsmavrisでSQL*Plusに接続し、自分の給与を確認して金額を引き上げます。
CONNECT smavris
Enter password: password
SELECT SALARY FROM HR.EMPLOYEES WHERE LAST_NAME = 'Mavris';
SALARY
-----------
6500
UPDATE HR.EMPLOYEES SET SALARY = 13000 WHERE LAST_NAME = 'Mavris';
次に、HR.EMPLOYEES表のSALARY以外の列から選択します。
SELECT FIRST_NAME, LAST_NAME FROM HR.EMPLOYEES WHERE LAST_NAME = 'Raphaely';
次の出力が表示されます。
FIRST_NAME LAST_NAME -------------------- -------------------- Den Raphaely
ここまでの手順を実行すると、電子メール・サーバーの速度に応じて、自分自身(または通知の受信対象者)にTable modification on HR.EMPLOYEESという件名ヘッダーの電子メールが届き、HR.EMPLOYEES表の改ざんについて通知されます。
ユーザーsysadmin_fgaで、Susan Mavrisの監査対象アクティビティを含むDBA_FGA_AUDIT_TRAILデータ・ディクショナリ・ビューを問い合せます。
CONNECT sysadmin_fga
Enter password: password
col dbuid format a10
col lsqltext format a66
col ntimestamp# format a15
SELECT DBUID, LSQLTEXT, NTIMESTAMP# FROM SYS.FGA_LOG$ WHERE POLICYNAME='CHK_HR_EMP';
次のような出力が表示されます。
DBUID LSQLTEXT ---------- ------------------------------------------------------------------ NTIMESTAMP# -------------------------------------------------------------------------- SMAVRIS SELECT SALARY FROM HR.EMPLOYEES WHERE LAST_NAME = 'Mavris' 23-JUN-09 03.48.59.111000 PM SMAVRIS UPDATE HR.EMPLOYEES SET SALARY = 13000 WHERE LAST_NAME = 'Mavris' 23-JUN-09 03.49.07.330000 PM
監査証跡では、Susan Mavrisが実行し、HR.EMPLOYEES表のSALARY列に影響を与えた2つのSQL文が取得されます。Susan Mavrisが実行した3つ目の文(Den Raphaelyに関して尋ねた文)は、監査ポリシーの影響を受けなかったため、記録されませんでした。これは、Oracle Databaseでは、監査関数は自律型トランザクションとして実行され、handler_module設定のアクションのみをコミットし、ユーザー・トランザクションはコミットしないためです。この関数はユーザーのSQLトランザクションには影響を与えません。
SYSTEM権限を持つユーザーでSQL*Plusに接続し、ユーザーsysadmin_fga(sysadmin_fgaスキーマ内のオブジェクトを含む)とsmavrisを削除します。
CONNECT SYSTEM
Enter password: password
DROP USER sysadmin_fga CASCADE;
DROP USER smavris;
ユーザーHRで接続し、Susan Mavrisの引き上げた給与を元に戻します。
CONNECT HR
Enter password: password
UPDATE HR.EMPLOYEES SET SALARY = 6500 WHERE LAST_NAME = 'Mavris';
他のユーザーがHRを使用しない場合、このアカウントはロックして期限切れにできます。
ALTER USER HR PASSWORD EXPIRE ACCOUNT LOCK;
SYSDBA権限を持つユーザーSYSで接続し、email_server_permissions.xmlアクセス制御リストを削除します。
BEGIN
DBMS_NETWORK_ACL_ADMIN.DROP_ACL(
acl => 'email_server_permissions.xml');
END;
/
アクセス制御リストは、作成者ユーザーのスキーマ内ではなく、SYSスキーマ内に存在します。
次のALTER SYSTEM文を発行して、「手順1: UTL_MAIL PL/SQLパッケージのインストールと構成」の手順4からSMTP_OUT_SERVERパラメータを前の値にリストアします。
ALTER SYSTEM SET SMTP_OUT_SERVER="previous_value";
この設定は引用符で囲みます。次に例を示します。
ALTER SYSTEM SET SMTP_OUT_SERVER="some_imap_server.example.com"
データベース・インスタンスを再起動します。
SHUTDOWN STARTUP
この項の内容は、次のとおりです。
ユーザーSYSとしてSYSDBA権限でログインします。
sqlplus SYS AS SYSDBA
Enter password: password
sysadmin_fgaアカウントを作成します。このアカウントでファイングレイン監査ポリシーを作成します。
GRANT CREATE SESSION, DBA TO sysadmin_fga IDENTIFIED BY password;
GRANT SELECT ON OE.ORDERS TO sysadmin_fga;
GRANT EXECUTE ON DBMS_FGA TO sysadmin_fga;
GRANT SELECT ON SYS.FGA_LOG$ TO sysadmin_fga;
passwordを安全なパスワードに置き換えます。詳細は、「パスワードの最低要件」を参照してください。
この例ではサンプル・ユーザーOEも使用するため、DBA_USERSデータ・ディクショナリ・ビューを問い合せて、OEがロックされていたり、期限切れになっていないことを確認します。
SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'OE';
DBA_USERSビューに、ユーザーOEがロックされて期限切れになっていると表示された場合は、ユーザーSYSTEMでログインし、次の文を入力して、OEアカウントのロックを解除し、新しいパスワードを作成します。
ALTER USER OE ACCOUNT UNLOCK IDENTIFIED BY password;
安全なパスワードを入力します。セキュリティを向上させるため、以前のリリースのOracle Databaseと同じパスワードをOEアカウントに指定しないでください。パスワードを作成するための最低要件は、「パスワードの最低要件」を参照してください。
ユーザーsysadmin_fgaでSQL*Plusに接続します。
CONNECT sysadmin_fga
Enter password: password
BEGIN
DBMS_FGA.ADD_POLICY(OBJECT_SCHEMA => 'OE',
OBJECT_NAME => 'ORDERS',
POLICY_NAME => 'ORDERS_FGA_POL',
AUDIT_CONDITION => 'SYS_CONTEXT(''USERENV'', ''CLIENT_IDENTIFIER'') = ''Robert''',
HANDLER_SCHEMA => NULL,
HANDLER_MODULE => NULL,
ENABLE => True,
STATEMENT_TYPES => 'INSERT,UPDATE,DELETE,SELECT',
AUDIT_TRAIL => DBMS_FGA.DB + DBMS_FGA.EXTENDED,
AUDIT_COLUMN_OPTS => DBMS_FGA.ANY_COLUMNS);
END;
/
この例では、AUDIT_CONDITIONパラメータで非データベース・ユーザーの名前がRobertであると想定しています。ポリシーでは、Robertが実行するINSERT、UPDATE、DELETEおよびSELECT文を監視します。
ユーザーOEで接続し、OE.ORDERS表から選択します。
CONNECT OE
Enter password: password
SELECT COUNT(*) FROM ORDERS;
次の出力が表示されます。
COUNT(*)
----------
105
ユーザーsysadmin_fgaで接続し、監査レコードが生成されたかどうかを確認します。
CONNECT sysadmin_fga
Enter password: password
SELECT DBUID, LSQLTEXT FROM SYS.FGA_LOG$ WHERE POLICYNAME='ORDERS_FGA_POL';
次の出力が表示されます。
no rows selected
ログインしてOE.ORDERS表の問合せを行う非データベース・ユーザーは存在しなかったため、監査証跡は空です。
ユーザーOEで再接続し、クライアント識別子をRobertに設定し、OE.ORDERS表から再選択します。
CONNECT OE
Enter password: password
EXEC DBMS_SESSION.SET_IDENTIFIER('Robert');
SELECT COUNT(*) FROM ORDERS;
次の出力が表示されます。
COUNT(*)
----------
105
ユーザーsysadmin_fgaで再接続し、監査証跡を再び確認します。
CONNECT sysadmin_fga
Enter password: password
SELECT DBUID, LSQLTEXT FROM SYS.FGA_LOG$ WHERE POLICYNAME='ORDERS_FGA_POL';
今回は、Robertが存在し、OE.ORDERS表を問い合せたため、監査証跡ではそのアクションが取得されます。
DBUID LSQLTEXT ---------------- ---------------------------- OE SELECT COUNT(*) FROM ORDERS;
ユーザーSYSTEMでSQL*Plusに接続し、ユーザーsysadmin_fga(sysadmin_fgaスキーマ内のオブジェクトを含む)を削除します。
CONNECT SYSTEM
Enter password: password
DROP USER sysadmin_fga CASCADE;
他のユーザーがOEを使用しない場合、このアカウントはロックして期限切れにできます。
ALTER USER OE PASSWORD EXPIRE ACCOUNT LOCK;
この項の内容は、次のとおりです。
標準およびファイングレイン監査機能を使用して、SYSTEMユーザーを監査できます。監査に関するかぎり、ユーザーSYSTEMは一般的なデータベース・ユーザー(HR、OEなど)であり、監査対象の特別な構成はありません。
例9-25に、ユーザーSYSTEMによって発行された表挿入操作を監査する方法を示します。
SYSとして接続するユーザーと、SYSDBAまたはSYSOPER権限を使用して接続しているすべてのユーザーのセッションを完全に監査できます。これによりAUDIT_TRAILパラメータがNONE、DB、またはDB, EXTENDEDに設定されていても、管理ユーザーのアクションをオペレーティング・システム・ファイルに書き込むことができるようになります。管理ユーザーはSYS.AUD$表から不正な行動を示す行を削除できるため、管理者ユーザーのアクションをオペレーティング・システム監査ファイルに書き込むことは、SYS.AUD$表に書き込むよりも安全です。
ユーザーSYSDBAおよびSYSOPERの監査設定を構成する手順は、次のとおりです。
AUDIT_SYS_OPERATIONS初期化パラメータをTRUEに設定します。
ALTER SYSTEM SET AUDIT_SYS_OPERATIONS=TRUE SCOPE=SPFILE;
この設定は、データベースにSYSDBAまたはSYSOPER権限を使用して接続したユーザーによって直接発行されたトップレベルの操作を記録します。監査レコードはオペレーティング・システム監査証跡に書き込まれます。すべての文のSQLテキストは、オペレーティング・システム監査証跡レコードのACTIONフィールドに書き込まれます。
システム管理者によるアクティビティをXMLファイルに書き込む場合は、AUDIT_TRAIL初期化パラメータをXMLまたはXML, EXTENDEDに設定します。
次に例を示します。
ALTER SYSTEM SET AUDIT_TRAIL=XML, EXTENDED SCOPE=SPFILE;
どのオペレーティング・システムでも、AUDIT_TRAILをXMLまたはXML,EXTENDEDに設定すると、監査レコードはAUDIT_FILE_DEST初期化パラメータで指定したディレクトリにXMLファイルとして書き込まれます。デフォルトでは、監査レコードはオペレーティング・システム・ファイルに書き込まれます。
これらの設定の詳細は、表9-1「AUDIT_TRAIL初期化パラメータの設定」を参照してください。「標準監査証跡を使用可能または使用禁止にする方法」も参照してください。
データベースを再起動します。
データベースを再起動すると、SYSDBAおよびSYSOPERユーザーによって実行され、正常終了したすべてのアクションが監査され、これらの監査レコードが、SYS.AUD$表ではなく、オペレーティング・システム監査証跡に書き込まれます。
Windowsでは、AUDIT_TRAIL初期化パラメータをOSに設定している場合、監査レコードはイベントビューアのログ・ファイルにイベントとして書き込まれます。
|
注意: AUDIT_FILE_DEST初期化パラメータが設定されていないか、有効なディレクトリを指し示していない場合は、$ORACLE_BASE/admin/$ORACLE_SID/adumpディレクトリが最初のデフォルトの場所として使用されます。最初のデフォルトの場所への書込みが失敗するか、データベースがクローズされている場合、$ORACLE_HOME/rdbms/auditディレクトリがバックアップのデフォルトの場所として使用されます。この試みも失敗すると、監査した操作が失敗し、アラート・ログにメッセージが書き込まれます。
$ORACLE_SID_short_form_process_name_processid_sequence_number.aud
順序番号の開始番号は1です。 たとえば、専用サーバー・プロセスとして短いプロセス名
|
AUDIT_FILE_DEST初期化パラメータを指定しない場合、デフォルトの場所は、LinuxとSolarisでは$ORACLE_BASE/admin/$ORACLE_SID/adump、Microsoft Windowsでは%ORACLE_BASE%\admin\%ORACLE_SID%\adumpです。他のオペレーティング・システムについては、監査証跡に関するそれぞれのドキュメントを参照してください。
Oracle Databaseでは、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文の両方がオペレーティング・システム監査ファイルに、次の出力のように表示されます。(この書式は、Oracle Databaseの異なるリリースでは変わる場合があることに注意してください。)
Tue May 5 04:53:37 2009 -07:00 LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[7] 'laurelh' CLIENT TERMINAL:[5] 'pts/0' STATUS:[1] '0' DBID:[9] '561542328' Tue May 5 04:53:40 2009 -07:00 LENGTH : '183' ACTION :[30] 'ALTER SYSTEM FLUSH SHARED_POOL' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[7] 'laurelh' CLIENT TERMINAL:[5] 'pts/0' STATUS:[1] '0' DBID:[9] '561542328' Tue May 5 04:53:49 2009 -07:00 LENGTH : '200' ACTION :[47] 'UPDATE salary SET base=1000 WHERE name='laurel'' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[7] 'laurelh' CLIENT TERMINAL:[5] 'pts/0' STATUS:[1] '0' DBID:[9] '561542328'
括弧は値の長さを示します。たとえば、PRIVILEGEは、6文字のSYSDBAに設定されています。また、SYSおよび必須監査レコードの場合は、値が一重引用符で囲まれています。
SYSDBAで接続したユーザーはスーパーユーザー権限を使用できるため、データベース管理者にはこの接続を必要な場合にのみ使用することをお薦めします。データベース管理者は通常、日常的なメンテナンス・アクティビティを実行できます。これらのデータベース管理者は、DBAロールを持つ標準のデータベース・ユーザーであるか、または組織でカスタマイズされたDBAロール(mydbaやjr_dbaなど)と同等の権限が付与されているデータベース・ユーザーです。
トリガーを使用して、Oracle Databaseの組込みの監査機能を補完できます。作成するトリガーでは、ユーザー・アクションが個別のデータベース表に記録されます。アクティビティによってトリガーが起動されると、そのトリガーによってアクションがこの表に記録されます。トリガーは、表の変更前と変更後の情報など、カスタマイズされた情報を記録する場合に役立ちます。トリガーの作成方法の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
監査を使用可能にしていなくても、どのタイプの監査を使用可能にしていても、トリガーは動作します。トリガーの動作は、データベース監査機能とは独立しています。
監査トリガーを作成する場合は、次のガイドラインに従ってください。
データをSYS.AUD$表に書き込むトリガーは記述しないでください。つまり、SYS.AUD$表の内容は変更しないでください。SYS.AUD$に値を書き込もうとし、トリガーが期待どおりに動作しなかった場合、標準監査に悪影響が及ぶ可能性があります。SYS.AUD$表はOracle Databaseが所有する表であり、Oracle Databaseのみが書込み可能です。
可能な場合、トリガーはAFTERトリガーとして作成してください。トリガー文は、適用される制約が存在する場合、その影響を受けます。レコードが見つからない場合、AFTERトリガーは起動せず、監査処理が不必要に実行されることはありません。
トリガーはAFTER行トリガーまたはAFTER文トリガーとして作成してください。AFTER行トリガーとAFTER文トリガーのどちらを選択するかは、監査対象の情報によって決まります。たとえば、行トリガーでは、表の行ごとに値ベースの監査が可能です。トリガーでは、監査対象のSQL文を発行するための理由コードの入力を要求することもできます。これは、行レベルと文レベルのどちらの監査でも役立ちます。
表9-5に、トリガーベースの監査と組込みのデータベース監査機能の比較を示します。
表9-5 組込みの監査とトリガーベースの監査の比較
| 監査機能 | 説明 |
|---|---|
|
DMLおよびDDL監査 |
標準監査オプションでは、すべてのタイプのスキーマ・オブジェクトと構造に関して、DMLおよびDDL文の監査が可能です。それに対し、トリガーでは、表に対して入力されたDML文の監査および |
|
集中監査証跡 |
データベースの監査機能を使用すると、すべてのデータベース監査情報が集中的および自動的に記録されます。 |
|
宣言方法 |
標準データベース機能を使用して有効化する監査機能は、トリガーで定義する監査機能と比べて、宣言とメンテナンスが容易で、エラーが発生しにくくなります。 |
|
監査オプションの監査 |
既存の監査オプションの変更も監査して、不正なデータベース・アクティビティから保護できます。 |
|
セッションと実行時間の監査 |
データベース監査機能を使用すると、監査対象の文が入力されるたびにレコードが生成されます。トリガーを使用した場合は、トリガーで監査されている表が参照されるたびに監査レコードが生成されます。 |
|
データ・アクセスの失敗の監査 |
データベース監査は、データ・アクセスの失敗を監査するように設定できます。ただし、自律型トランザクションを使用しないかぎり、トリガー文がロールバックされると、トリガーによって生成されたすべての監査情報がロールバックされます。自律型トランザクションの詳細は、『Oracle Database概要』を参照してください。 |
|
セッションの監査 |
標準データベース監査を使用すると、接続、切断およびセッション・アクティビティ(物理I/O、論理I/O、デッドロックなど)を記録できます。 |
例9-26では、emp_tab表の特定の行に対する変更をトリガーで監査しています。トリガーによって、更新を行ったユーザーと更新時刻を含め、古い値と新しい値がemp_audit_tab表に書き込まれます。
例9-26 表の変更前と変更後の情報を記録する監査トリガー
/* 1. Create the following table: */ CREATE TABLE emp_tab ( empno NUMBER(4), ename VARCHAR2(10), job VARCHAR2(9), mgr NUMBER(4), hiredate DATE, sal NUMBER(8,2), deptno NUMBER(2)); /* 2. Create a table to capture the audit data. */ CREATE TABLE emp_audit_tab ( oldname VARCHAR2(10), oldjob VARCHAR2(9), oldsal NUMBER (8,2), newname VARCHAR2(10), newjob VARCHAR2(9), newsal NUMBER(8,2), user1 varchar2(10), systemdate TIMESTAMP); /* 3. Create a trigger to record the old and new values, the author of the change, and when the change took place. */ CREATE OR REPLACE TRIGGER emp_audit_trig AFTER INSERT OR DELETE OR UPDATE ON emp_tab FOR EACH ROW BEGIN INSERT INTO emp_audit_tab ( oldname, oldjob, oldsal, newname, newjob, newsal, user1, systemdate ) VALUES ( :OLD.ename, :OLD.job, :OLD.sal, :NEW.ename, :NEW.job, :NEW.sal, user, sysdate ); END; /
このトリガーをテストするには、行をemp_tab表に追加し、emp_tab表のename、jobまたはsal列の値を変更します。その後、emp_audit_tab表を問い合せて監査データを調べます。
この項の内容は、次のとおりです。
監査レコードには、監査された操作、操作を行ったユーザー脚注 2 、そして操作の日時に関する情報が含まれます。選択した監査タイプに応じて、監査レコードをデータ・ディクショナリ表(データベース監査証跡)またはオペレーティング・システム・ファイル(オペレーティング・システム監査証跡)に書き込むことができます。
監査レコードをデータベース監査証跡に書き込むように選択すると、デフォルト監査と標準監査の場合は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データ・ディクショナリ・ビューを問い合せることで確認できます。
この項の内容は、次のとおりです。
データベース監査証跡は、AUD$表(標準監査用)とFGA_LOG$表(ファイングレイン監査用)のペアであり、各Oracle Databaseデータ・ディクショナリのSYSスキーマにあります。標準監査とファイングレイン監査の両方のアクティビティを記録します。各種データ・ディクショナリ・ビューは、この表の情報を使用する場合に役立ちます。「監査アクティビティに関する情報の検索」では、すべての監査関連ビューがリストされてます。
監査対象のイベントと設定されている監査オプションに応じて、データベース監査証跡には様々な種類の情報が記録されます。たとえば、AUDIT_TRAIL初期化パラメータをDB、EXTENDEDまたはXML, EXTENDEDに設定している場合、SQL_BINDおよびSQL_TEXT列に、SQL文で使用されているSQLバインド変数および監査のトリガーとなったSQLテキストがそれぞれ示されます。これらのビューの内容の詳細は、『Oracle Databaseリファレンス』を参照してください。ただし、DBA_AUDIT_TRAILビューの形式と列はOracle Databaseの各リリースで異なる場合があることに注意してください。
|
注意: AUDIT_TRAIL初期化パラメータがXMLまたはXML, EXTENDEDに設定されている場合、標準監査レコードはXML形式でオペレーティング・システム・ファイルに送信されます。XMLは標準文書形式であるため、XMLデータを解析および分析できる多くのユーティリティがあります。 |
監査レコードのデータベースの宛先がいっぱいか使用できなくなったために新規レコードが入らなくなると、監査対象のアクションは完了できません。かわりにエラー・メッセージが生成され、監査対象のアクションは実行されません。監査証跡のサイズを調節すると、管理しやすくなります。(これは特にお薦めします。)詳細は、「データベース監査証跡のサイズの制御」を参照してください。「監査済情報の管理しやすい状態での維持」も参照してください。
監査証跡には、監査対象の文に関連するデータ値の情報は格納されません。たとえば、UPDATE文を監査しているときに、更新された行の新旧のデータ値は格納されません。ただし、ファイングレイン監査方法を使用すれば、この特別なタイプの監査を実行できます。
フラッシュバック問合せ機能を使用すると、現在有効な監査ポリシーに従って、更新された行の新旧のデータ値を表示できます。フラッシュバックが、最初は別のポリシーに従っていた旧問合せに対する内容の場合でも、現在のポリシーが適用されます。現行のビジネス・アクセス・ルールが常に適用されます。
|
関連項目:
|
データベース監査証跡がいっぱいになり、これ以上監査レコードを挿入できなくなった場合は、監査証跡を削除しないかぎり、基礎となる文を正常に完了できません。Oracle Databaseでは、監査が行われる文を発行するすべてのユーザーに対してエラーが発行されます。このため、監査証跡の増加とサイズを制御する必要があります。
監査が使用可能で、監査レコードが生成されているときは、次の2つの要因によって監査証跡が増加します。
使用可能な監査オプションの数
監査対象の文の実行頻度
監査証跡の増加を制御するには、次の方法を使用します。
データベース監査を使用可能および使用禁止にします。使用可能にすると、監査レコードが生成されて監査証跡に格納されます。使用禁止の場合、監査レコードは生成されません。(一部のアクティビティは常に監査されることに注意してください。)
使用可能な監査オプションを選択的に絞り込みます。選択的な監査を実施すると、不要な監査情報が生成されず、監査証跡に格納されません。ファイングレイン監査を使用すると、特定の条件のみを選択的に監査できます。
オブジェクト監査を実行できるかを厳密に制御します。これには次の方法があります。
セキュリティ管理者がすべてのオブジェクトを所有し、AUDIT ANYシステム権限を他のユーザーには付与しない方法。また、すべてのスキーマ・オブジェクトを、対応するユーザーにCREATE SESSION権限がないスキーマに所属させることもできます。
すべてのオブジェクトを、実際のデータベース・ユーザーに対応していない(つまり、対応するユーザーにCREATE SESSION権限が付与されていない)スキーマに格納しておく方法。セキュリティ管理者のみにAUDIT ANYシステム権限を付与します。
どちらの方法でも、セキュリティ管理者がオブジェクト監査を完全に制御できます。
データベース監査証跡表(AUD$およびFGA_LOG$表)の最大サイズは、その表がデフォルトで格納されているSYSTEM表領域のデフォルトの記憶域パラメータによって決まります。データベース監査証跡が大きくなりすぎてSYSTEM表のパフォーマンスに影響することが懸念される場合は、データベース監査証跡表を別の表領域に移動することを検討します。
|
関連項目: 監査レコードをオペレーティング・システムの監査証跡に書き込んでいる場合の、オペレーティング・システム監査証跡の管理方法の詳細は、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。 |
デフォルトでは、SYSTEM表領域にデータベース監査証跡SYS.AUD$およびSYS.FGA_LOG$表が格納されます。このデフォルトの場所を別の表領域(SYSAUX表領域やユーザーが作成した表領域など)に変更できます。SYSTEM表領域がいっぱいの場合、必要に応じてデータベース監査証跡表を別の表領域に移動できます。また、DBMS_AUDIT_MGMT PL/SQLパッケージ・プロシージャを使用して監査証跡表を削除する場合も、それらの監査証跡表を別の表領域に移動できます。
データベース監査証跡表を別の表領域に移動する場合、監査表内の監査データの量によっては処理に時間がかかることがあります。そのため、この処理は、データベースの負荷が低い時間帯に行うのが賢明です。
SYSTEM内のデータベース監査証跡を別の表領域に移動する手順は、次のとおりです。
DBMS_AUDIT_MGMT PL/SQLパッケージに対するEXECUTE権限を持つ管理者としてSQL*Plusにログインします。
DBMS_AUDIT_MGMT PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
データベース監査証跡表の移動先の表領域を確認します。
SYSAUX補助表領域を含め、対象の表領域を最適化してより多くの領域を割り当てることが必要となる場合があります。詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION PL/SQLプロシージャを実行して、移動先の表領域の名前を指定します。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, AUDIT_TRAIL_LOCATION_VALUE => 'AUD_AUX'); END;
この例の説明は、次のとおりです。
AUDIT_TRAIL_TYPE: データベース監査証跡タイプを表します。次のいずれかの値を入力します。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: 標準監査証跡表とファイングレイン監査証跡表の両方です。
AUDIT_TRAIL_LOCATION_VALUE: 移動先の表領域を指定します。この例では、AUD_AUXという名前の表領域を指定しています。
アプリケーションで、通常のユーザー(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.FGA_LOG$表に対するDELETE、INSERT、UPDATE、およびMERGE操作は常に監査されます。これらの監査レコードは削除できません。 |
監査証跡が大きくなりすぎないように、定期的にアーカイブしてから削除する必要があります。アーカイブと削除により、監査証跡の領域が解放され、データベース監査証跡の削除が容易になります。監査証跡レコードの別の削除方法は、「監査証跡レコードの削除」を参照してください。
次のいずれかの方法でデータベース監査証跡のアーカイブを作成できます。
Oracle Audit Vault。Oracle Audit VaultをOracle Databaseとは別にインストールします。詳細は、『Oracle Audit Vault管理者ガイド』を参照してください。
Oracle Data Warehouse。Oracle Data Warehouseは、Oracle Databaseとともに自動的にインストールされます。詳細は、『Oracle Warehouse Builderインストレーションおよび管理ガイド』を参照してください。
アーカイブが完了したら、データベース監査証跡の内容を削除できます。詳細は、「監査証跡レコードの削除」を参照してください。
標準監査レコードとファイングレイン監査レコードをアーカイブするには、関連するレコードを通常のデータベース表にコピーします。次に例を示します。
INSERT INTO table SELECT ... FROM SYS.AUD$ ...; INSERT INTO table SELECT ... FROM SYS.FGA_LOG$ ...;
|
関連項目: データベース監査証跡の様々なパージ方法は、次のセクションを参照してください。 |
オペレーティング・システムの監査証跡またはファイル・システム(Windowsイベント・ログなど)がいっぱいになることがあり、そのためにOracle Databaseの監査レコードも含めて、新しいレコードが入らなくなる可能性があることに注意してください。この場合、Oracle Databaseでは、通常は常に監査される操作を含めて、実行される操作が取り消されてロールバックされます。(「すべてのプラットフォームについて常に監査されるアクティビティ」を参照してください。)オペレーティング・システム監査証跡がいっぱいになった場合は、データベース監査証跡を使用するようにAUDIT_TRAILパラメータを設定します(DBまたはDB, EXTENDEDなど)。これにより、監査レコードを格納できない場合は監査対象のアクションの完了が防止されます。このようなタイプの障害を防止するためには、オペレーティング・システム監査ファイルを定期的にアーカイブして削除する必要があります。
オペレーティング・システム監査を使用する場合は、オペレーティング・システムの監査証跡またはファイル・システムがいっぱいにならないようにしてください。ほとんどのオペレーティング・システムでは、このような状況を回避できるように十分な情報と警告が管理者に提供されています。データベースの監査証跡を使用するように監査を構成すると、監査情報を失う危険性を回避できます。監査証跡が文に関するデータベース監査レコードを受け入れられない場合は、監査されているイベントの発生をOracle Databaseが防止しているためです。
オペレーティング・システム監査証跡の内容を定期的にアーカイブして削除します。詳細は、「オペレーティング・システム監査証跡のアーカイブ」および「監査証跡レコードの削除」を参照してください。
オペレーティング・システム監査証跡のサイズを制御するには、DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY PL/SQLプロシージャを使用してDBMS_AUDIT_MGMT.OS_FILE_MAX_SIZEプロパティを設定します。このプロシージャを使用するには、DBMS_AUDIT_MGMT PL/SQLパッケージに対するEXECUTE権限が必要です。オペレーティング・システム・ファイルがサイズ制限の設定値に達すると、現行ファイルへのレコードの追加が停止され、それ以降のレコード用に新しいオペレーティング・システム・ファイルが作成されます。DBMS_AUDIT_MGMT PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZEとDBMS_AUDIT_MGMT.OS_FILE_MAX_AGE(「オペレーティング・システム監査証跡の有効期間の設定」の説明を参照)の両方のプロパティを設定した場合は、最初に達したほうのプロパティ値の制限に基づいてアクションが実行されます。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS, AUDIT_TRAIL_PROPERTY => DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE, AUDIT_TRAIL_PROPERTY_VALUE => 10240); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_TYPE: オペレーティング・システム監査証跡を指定します。次のいずれかの値を入力します。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。また、AUDIT_SYSLOG_LEVEL初期化パラメータが設定されているときは、syslog監査レコードにも適用されません。)
DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML監査証跡ファイルです。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: オペレーティング・システム監査証跡ファイルとXML監査証跡ファイルの両方です。
AUDIT_TRAIL_PROPERTY: DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZEプロパティを指定して、最大サイズを設定します。現行のプロパティ設定のステータスを調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューのPARAMETER_NAMEおよびPARAMETER_VALUE列を問い合せます。
AUDIT_TRAIL_PROPERTY_VALUE: 最大サイズを10240KB(つまり、10MB)に設定します。デフォルト設定は10000KB(約10MB)です。2GBを超えることはできません。
DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE設定の消去
ファイルの最大サイズの設定を消去するには、DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTYプロシージャを使用します。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS, AUDIT_TRAIL_PROPERTY => DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE, USE_DEFAULT_VALUES => TRUE ); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_TYPE: オペレーティング・システム監査証跡を指定します。「オペレーティング・システム監査証跡のサイズの設定」に示したAUDIT_TRAIL_TYPE値のいずれかを入力します。
AUDIT_TRAIL_PROPERTY: DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZEプロパティを指定します。このプロパティの現行のステータスを調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューを問い合せます。
USE_DEFAULT_VALUES: 次のいずれかの値を入力します。
TRUE: 現行の値を消去し、かわりにデフォルト値の10000KBを使用します。
FALSE: オペレーティング・システム・ファイルまたはXMLファイルの増大にデフォルトの最大サイズは適用されません。DBMS_AUDIT_MGMT.OS_FILE_MAX_AGEプロパティを構成しないかぎり、ファイルは無制限に大きくなります。デフォルト設定はFALSEです。
オペレーティング・システム監査証跡の有効期間を制御するには、DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY PL/SQLプロシージャを使用します。このプロシージャを使用するには、DBMS_AUDIT_MGMT PL/SQLパッケージに対するEXECUTE権限が必要です。オペレーティング・システム・ファイルが有効期間制限の設定値に達すると、現行ファイルへのレコードの追加が停止され、それ以降のレコード用に新しいオペレーティング・システム・ファイルが作成されます。DBMS_AUDIT_MGMT PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
DBMS_AUDIT_MGMT.OS_FILE_MAX_AGEとDBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE(「オペレーティング・システム監査証跡のサイズの設定」の説明を参照)の両方のプロパティを設定した場合は、最初に達したほうのプロパティ値の制限に基づいて監査ファイルの増大が制御されます。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS, AUDIT_TRAIL_PROPERTY => DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE, AUDIT_TRAIL_PROPERTY_VALUE => 10 ); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_TYPE: オペレーティング・システム監査証跡を指定します。次のいずれかの値を入力します。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。また、AUDIT_SYSLOG_LEVEL初期化パラメータが設定されているときは、syslog監査レコードにも適用されません。)
DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML監査証跡ファイルです。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: オペレーティング・システム監査証跡ファイルとXML監査証跡ファイルの両方です。
AUDIT_TRAIL_PROPERTY: DBMS_AUDIT_MGMT.OS_FILE_MAX_AGEプロパティを指定して、最大有効期間を設定します。現行のプロパティ設定のステータスを調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューを問い合せます。
AUDIT_TRAIL_PROPERTY_VALUE: 最大有効期間を10日に設定します。1から495の値を入力します。デフォルトの有効期間は5日です。
DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE設定の消去
ファイルの最大有効期間の設定を消去するには、DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTYプロシージャを使用します。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS, AUDIT_TRAIL_PROPERTY => DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE, USE_DEFAULT_VALUES => TRUE ); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_TYPE: オペレーティング・システム監査証跡を指定します。「オペレーティング・システム監査証跡の有効期間の設定」に示したAUDIT_TRAIL_TYPE値のいずれかを入力します。
AUDIT_TRAIL_PROPERTY: DBMS_AUDIT_MGMT.OS_FILE_MAX_AGEプロパティを指定します。このプロパティの現行のステータスを調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューのPARAMETER_NAMEおよびPARAMETER_VALUE列を問い合せます。
USE_DEFAULT_VALUES: 次のいずれかの値を指定します。
TRUE: 現行の値を消去し、かわりにデフォルト値の5日を使用します。
FALSE: オペレーティング・システム・ファイルまたはXMLファイルの増大にデフォルトの最大有効期間は適用されません。この場合、DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZEプロパティを構成しないかぎり、ファイルは無期限で使用されます。デフォルト設定はFALSEです。
オペレーティング・システム監査証跡は定期的にアーカイブする必要があります。プラットフォーム固有のオペレーティング・システム・ツールを使用して、オペレーティング・システム監査ファイルのアーカイブを作成します。
オペレーティング・システム監査ファイルをアーカイブするには、次の方法を使用します。
Oracle Audit Vaultを使用します。Oracle Audit VaultをOracle Databaseとは別にインストールします。詳細は、『Oracle Audit Vault管理者ガイド』を参照してください。
テープまたはディスクにバックアップを作成します。監査ファイルの圧縮ファイルを作成し、それをテープまたはディスクに格納できます。詳細は、使用しているオペレーティング・システムのマニュアルを参照してください。
その後、監査証跡の領域を解放して監査証跡管理を容易にするために、オペレーティング・システム監査レコードをパージ(削除)する必要があります。オペレーティング・システム監査証跡レコードの別の削除方法は、「監査証跡レコードの削除」を参照してください。
この項の内容は、次のとおりです。
監査証跡が大きくなりすぎると新しいレコードが入らなくなるため、監査証跡レコードを定期的にアーカイブしてから削除(パージ)する必要があります。この項では、データベース監査証跡レコードとオペレーティング・システム監査証跡レコードの両方を削除するために使用できる様々な方法について説明します。データベース監査証跡レコードのサブセットを削除できます。データベース監査証跡とオペレーティング・システム監査証跡のどちらのタイプについても、レコードを手動で削除したり、削除ジョブを作成して指定した時間間隔で実行できます。その場合、削除操作ではアーカイブ・タイムスタンプより前に作成された監査証跡レコードが削除されるか、すべての監査証跡レコードが削除されます。
監査証跡の削除タスクを実行するには、ほとんどの場合、DBMS_AUDIT_MGMT PL/SQLパッケージを使用します。DBMS_AUDIT_MGMTを使用するには、そのEXECUTE権限が必要です。
Oracle Audit Vaultをインストールしている場合は、このマニュアルで説明しているプロシージャとは異なる監査証跡削除プロセスを使用します。たとえば、Oracle Audit Vaultでは、監査証跡が自動的にアーカイブされます。『Oracle Audit Vault管理者ガイド』を参照してください。
|
関連項目:
|
表9-6に、監査証跡の削除方法を選択するための手引きを示します。
表9-6 監査証跡の削除方法の選択
| 削除対象 | このタイプの削除方法の概要 |
|---|---|
|
すべての監査レコードまたは指定したタイムスタンプより前に作成された監査レコード(定期的) |
削除操作を特定の時間に実行するようにスケジューリングできます。たとえば、土曜日の午前2時に毎回実行するようにスケジューリングできます。 一般手順
詳細は、「監査証跡の自動削除ジョブのスケジューリング」を参照してください。 |
|
すべての監査レコードまたは指定したタイムスタンプより前に作成されたレコード(必要に応じて) |
削除スケジュールを作成するのではなく、1回の手動操作で監査レコードを即座に削除できます。 一般手順
詳細は、「監査証跡の手動削除」を参照してください。 |
|
データベース監査証跡内の監査レコードのサブセットのみ |
監査レコードのサブセットのみを手動で削除できます。たとえば、2010年5月14日から2010年6月14日までの期間に作成されたすべての監査レコードを削除できます。 一般手順
詳細は、「データベース監査証跡内のレコードのサブセットの削除」を参照してください。 |
監査証跡全体を削除することも、タイムスタンプより前に作成された一部の監査証跡のみを削除することもできます。データベース監査証跡の場合、タイムスタンプより前に作成された個々の監査レコードを削除できます。オペレーティング・システム監査証跡の場合、タイムスタンプより前に作成された監査ファイルを削除します。
監査証跡(特に、大きいもの)を削除する場合は、完了するまでに時間がかかることがあります。削除ジョブは、データベースの負荷が低い時間帯に実行するようにスケジューリングするのが賢明です。
競合しないかぎり、異なる監査証跡タイプに対する複数の削除ジョブを作成できます。たとえば、標準監査証跡表の削除ジョブを作成し、その後でファイングレイン監査証跡表の削除ジョブを作成できます。ただし、DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STDまたはDBMS_AUDIT_MGMT.AUDIT_TRAIL_ALLプロパティを使用して、両方のタイプまたはすべてのタイプをまとめて処理する削除ジョブを作成することはできません。
自動削除ジョブを作成してスケジューリングする手順は、次のとおりです。
削除プロセスでは、REDOログが追加生成される場合があります。監査表の削除プロセスを実行する前に、プロセス中に追加生成されるレコードに対応するために、オンラインREDOログとアーカイブREDOログのサイズのチューニングが必要になる場合があります。ログ・ファイルのチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Database管理者ガイド』を参照してください。
データベース監査レコードとオペレーティング・システム監査レコードをアーカイブするには、これらのレコードのタイムスタンプを記録する必要があります。タイムスタンプの日付は、DBA_AUDIT_MGMT_LAST_ARCH_TSデータ・ディクショナリ・ビューを問い合せることで確認できます。その後、削除を実行すると、このタイムスタンプの日付より前に作成された監査証跡レコードのみが削除されます。詳細は、「手順4: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)」を参照してください。
レコードのタイムスタンプを設定したら、アーカイブを開始できます。詳細は、次の各項を参照してください。
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャを使用して監査証跡を削除するには、事前に監査証跡をクリーン・アップ操作用に初期化する必要があります。データベース監査証跡については、SYSTEM表領域のデータベース監査証跡表(SYS.AUD$およびSYS.FGA_LOG$)を別の表領域に移動していない場合、このプロセスにより、これらの表がSYSAUX表領域または「データベース監査証跡の別の表領域への移動」で指定した表領域に移動されます。これらの表の移動には時間がかかるため、初期化プロセスはデータベースの負荷が低い時間帯にスケジューリングするのが賢明です。
監査証跡をクリーン・アップ操作用に初期化する手順は、次のとおりです。
DBMS_AUDIT_MGMT PL/SQLパッケージに対するEXECUTE権限を持つ管理ユーザーとしてSQL*Plusにログインします。
まだログインしていない場合は、DBMS_AUDIT_MGMT.INIT_CLEANUPプロシージャを実行して監査証跡クリーン・アップ操作を初期化します。(この手順は1回だけ実行する必要があります。
DBMS_AUDIT_MGMT.IS_CLEANUP_INITIALIZED関数を実行して、監査証跡がクリーン・アップ用に初期化されたかどうかを確認できます。「監査証跡がクリーン・アップ用に初期化されたことの確認」を参照してください。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.INIT_CLEANUP( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, DEFAULT_CLEANUP_INTERVAL => 12 ); END; /
次のように値を指定します。
AUDIT_TRAIL_TYPE: 次のいずれかの値を入力します。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: 標準監査証跡表とファイングレイン監査証跡表の両方です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。)
DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XMLオペレーティング・システム監査証跡ファイルです。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: オペレーティング・システム監査証跡ファイルとXML監査証跡ファイルの両方です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: すべての監査証跡レコード、つまりデータベース監査証跡タイプとオペレーティング・システム監査証跡タイプの両方です。
DEFAULT_CLEANUP_INTERVAL: 目的のデフォルト削除間隔(時間単位)を指定します(たとえば、12時間ごとに実行する場合は12)。DBMS_AUDIT_MGMTプロシージャでは、この値に基づいて監査レコードの削除方法が決定されます。DBMS_AUDIT_MGMT.INIT_CLEANUPプロシージャを実行すると、計時が開始されます。この値を後で更新するには、DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTYプロシージャのDBMS_AUDIT_MGMT.CLEAN_UP_INTERVALプロパティを設定します。
DEFAULT_CLEANUP_INTERVAL設定には、DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILをコールする頻度を指定する必要があります。頻度が不確定の場合は、概略値を設定します。この値は、後でDBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTYプロパティを使用して変更できます。
すべての監査証跡を削除する場合は、この手順を省略できます。
最後の監査レコードがアーカイブされた時点のタイムスタンプを設定できます。設定したアーカイブ・タイムスタンプは、クリーン・アップ・インフラストラクチャに対するヒントとなり、それに基づいてクリーン・アップ操作が6時間ごとに実行されます。
データベース監査証跡の場合、監査証跡をクリーン・アップ操作用に初期化した後でタイムスタンプを設定する必要があります。監査証跡の最終アーカイブ・タイムスタンプを調べるには、DBA_AUDIT_MGMT_LAST_ARCH_TSデータ・ディクショナリ・ビューを問い合せます。タイムスタンプを設定した後でDBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャを実行すると、そのタイムスタンプより前の時間を示すすべての監査レコードが監査証跡から削除されます。アーカイブ・タイムスタンプ設定を消去する場合は、「アーカイブ・タイムスタンプ設定の消去」を参照してください。
オペレーティング・システム監査証跡の場合、オペレーティング・システム監査ファイル(XMLを含む)内の監査レコードは個別に削除できないことに注意してください。かわりに、タイムスタンプが設定されたレコードを含むファイル全体が削除されます。
Oracle Real Application Clusters(Oracle RAC)を使用している場合は、ネットワーク・タイム・プロトコル(NTP)を使用して、Oracle Databaseインスタンスをインストールしている各コンピュータ上の時間を同期化してください。たとえば、1つのOracle RACインスタンス・ノードの時間を午前11:00:00に設定し、次のOracle RACインスタンス・ノードの時間を11:00:05に設定するとします。その結果、2つのノードの時間に矛盾が生じます。ネットワーク・タイム・プロトコル(NTP)を使用して、これらのOracle RACインスタンス・ノードの時間を同期化できます。
タイムスタンプを設定するには、DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP PL/SQLプロシージャを使用します。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, LAST_ARCHIVE_TIME => '2009-05-28 06:30:00.00' RAC_INSTANCE_NUMBER => 0 ); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_TYPE: 次のいずれかの設定を入力します。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$を指定します。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$を指定します。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。)
DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML監査証跡ファイルを指定します。
LAST_ARCHIVE_TIME: タイムスタンプを入力します。AUDIT_TRAIL_DB_AUDおよびAUDIT_TRAIL_FGA_STD(標準監査証跡およびファイングレイン監査証跡)の場合は、YYYY-MM-DD HH:MI:SS.FF UTC(協定世界時)形式で入力し、AUDIT_TRAIL_OSおよびAUDIT_TRAIL_XML(オペレーティング・システム監査証跡およびXML監査証跡)の場合は、ローカル・タイム・ゾーンで入力します。
RAC_INSTANCE_NUMBER: Oracle RACインストールのインスタンス番号を指定します。監査証跡タイプとしてDBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STDまたはDBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STDを指定した場合は、RAC_INSTANCE_NUMBER引数を省略できます。これは、Oracle RACインストールの場合でも、存在するAUD$およびFGA_LOG$表は1つのみであるためです。デフォルトは0(ゼロ)で、単一インスタンス・データベース・インストールに使用されます。
通常、タイムスタンプを設定したら、DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャを使用して、タイムスタンプの日付より前に作成された監査レコードを削除できます。
DBMS_AUDIT_MGMT.CREATE_PURGE_JOB PL/SQLプロシージャを実行して、削除ジョブを作成してスケジューリングします。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.CREATE_PURGE_JOB (AUDIT_TRAIL_TYPE=> DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, AUDIT_TRAIL_PURGE_INTERVAL => 12, AUDIT_TRAIL_PURGE_NAME => 'Standard_Audit_Trail_PJ',USE_LAST_ARCH_TIMESTAMP=> TRUE ); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_TYPE: 次のいずれかの値を入力します。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: 標準監査証跡表とファイングレイン監査証跡表の両方です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。)
DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML監査証跡ファイルです。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: オペレーティング・システム監査証跡ファイルとXML監査証跡ファイルの両方です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: すべての監査証跡レコード、つまりデータベース監査証跡タイプとオペレーティング・システム監査証跡タイプの両方です。
AUDIT_TRAIL_PURGE_INTERVAL: この削除ジョブを実行する間隔(時間単位)を指定します。DBMS_AUDIT_MGMT.CREATE_PURGE_JOBプロシージャを実行すると、計時が開始されます(この例では、このプロシージャを実行してから12時間後)。後でこの値を更新する場合は、DBMS_AUDIT_MGMT.SET_PURGE_JOB_INTERVALプロシージャを実行します。
USE_LAST_ARCH_TIMESTAMP: 次の設定のいずれかを入力します。
TRUE: 最終アーカイブ・タイムスタンプより前に作成された監査レコードを削除します。最後に記録されたタイムスタンプを調べるには、DBA_AUDIT_MGMT_LAST_ARCH_TSデータ・ディクショナリ・ビューのLAST_ARCHIVE_TS列を問い合せます。デフォルト値はTRUEです。USE_LAST_ARCH_TIMESTAMPはTRUEに設定することをお薦めします。
FALSE: 最終アーカイブ・タイムスタンプを考慮せずに、すべての監査レコードを削除します。削除してはならない監査レコードを誤って削除しないように、この設定を使用する際には注意が必要です。
デフォルトでは、DBMS_AUDIT_MGMTパッケージ・プロシージャでデータベース監査証跡レコードおよびオペレーティング・システム監査証跡レコードを削除する場合、バッチで10000個のデータベース監査レコードまたは1000個のオペレーティング・システム監査ファイルが削除されます。必要に応じて、このバッチ・サイズを別の値に設定できます。その後、Oracle Databaseで削除ジョブを実行すると、すべてのレコードではなく、各バッチが削除されます。監査証跡が非常に大きい場合(および、非常に大きくなる可能性がある場合)、バッチでレコードを削除すると削除操作の効率が向上します。
現行のバッチ設定を調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューのPARAMETER_NAMEおよびPARAMETER_VALUE列を問い合せます。バッチ・サイズを設定するには、DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTYプロシージャを使用します。後でこの設定を消去する場合は、「データベース監査証跡のバッチ・サイズの消去」を参照してください。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, AUDIT_TRAIL_PROPERTY => DBMS_AUDIT_MGMT.DB_DELETE_BATCH_SIZE, AUDIT_TRAIL_PROPERTY_VALUE => 100000); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_TYPE: 監査証跡タイプ(この例では、データベース・システム監査証跡)を指定します。次のいずれかの値を入力します。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: オペレーティング・システム監査ファイルです。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML監査ファイルです。
AUDIT_TRAIL_PROPERTY: DBMS_AUDIT_MGMT.DB_DELETE_BATCH_SIZEプロパティを使用して、データベース監査証跡のバッチ・サイズ設定を指定します。オペレーティング・システム監査証跡のバッチを作成するには、FILE_DELETE_BATCH_SIZEプロパティを使用します。
AUDIT_TRAIL_PROPERTY_VALUE: 監査レコード・ファイルの数をバッチごとに100000個に設定します。100から1000000の値を入力します。この数を決定する際には、削除対象のレコードの合計数および削除操作を実行する時間間隔を考慮します。デフォルトは、データベース監査証跡の場合は10000、オペレーティング・システム監査証跡レコードの場合は1000です。
監査証跡は、削除ジョブをスケジューリングしなくても、手動で即座に削除できます。削除ジョブと同様に、アーカイブ・タイムスタンプの日付より前に作成された監査証跡レコード、または監査証跡内のすべてのレコードを削除できます。
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャに関しては、次のことに注意してください。
このプロシージャを実行した場合、現行の監査ディレクトリのみがクリーン・アップされます。
DBMS_AUDIT_MGMTパッケージではWindowsイベントビューアのクリーン・アップはサポートされていないため、Microsoft WindowsでAUDIT_TRAIL_TYPEプロパティをDBMS_AUDIT_MGMT.AUDIT_TRAIL_OSに設定しても効果はありません。Windows上のオペレーティング・システム監査レコードはWindowsイベントビューアに書き込まれるためです。DBMS_AUDIT_MGMTパッケージでは、このタイプのクリーン・アップ操作はサポートされていません。
UNIXプラットフォームでは、AUDIT_SYSLOG_LEVEL初期化パラメータを、『Oracle Databaseリファレンス』に示されている有効な値に設定すると、オペレーティング・システムのログ・ファイルがsyslogファイルに書き込まれます。AUDIT_TRAIL_TYPEプロパティをDBMS_AUDIT_MGMT.AUDIT_TRAIL_OSに設定すると、監査ディレクトリ内の.audファイルのみが削除されます(このディレクトリは、AUDIT_FILE_DEST初期化パラメータで指定します)。
AUDIT_TRAIL_TYPEパラメータをDBMS_AUDIT_MGMT.AUDIT_TRAIL_XMLに設定すると、現行の監査ディレクトリ内のXML監査ファイル(.xml)のみがクリーン・アップされます。XML監査で生成されたXMLファイルをリストした索引ファイル(adx_$ORACLE_SID.txt)は保持されます。クリーン・アップ・プロシージャでは、このファイルは削除されません。
データベース監査証跡の場合、DBMS_AUDIT_MGMT.INIT_CLEANUPプロシージャを実行してから、「データベース監査証跡内のレコードのサブセットの削除」で説明する方法を使用してデータベース監査証跡を削除することによって、クリーン・アップ・インフラストラクチャを初期化する必要があります。
監査証跡を手動で削除する手順は、次のとおりです。
「監査証跡の自動削除ジョブのスケジューリング」で説明した次の手順を実行します。
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL PL/SQLプロシージャを実行して、監査証跡レコードを削除します。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, USE_LAST_ARCH_TIMESTAMP => TRUE ); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_TYPE: 次のいずれかの値を入力します。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: 標準監査証跡表とファイングレイン監査証跡表の両方です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。)
DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XML監査証跡ファイルです。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: オペレーティング・システム監査証跡ファイルとXML監査証跡ファイルの両方です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: すべての監査証跡レコード、つまりデータベース監査証跡タイプとオペレーティング・システム監査証跡タイプの両方です。
USE_LAST_ARCH_TIMESTAMP: 次の設定のいずれかを入力します。
TRUE: 最終アーカイブ・タイムスタンプより前に作成された監査レコードを削除します。アーカイブ・タイムスタンプを設定する方法は、「手順4: 監査レコードのアーカイブ・タイムスタンプの設定(必要に応じて)」を参照してください。デフォルト(推奨)値はTRUEです。USE_LAST_ARCH_TIMESTAMPはTRUEに設定することをお薦めします。
FALSE: 最終アーカイブ・タイムスタンプを考慮せずに、すべての監査レコードを削除します。削除されているはずの監査レコードを誤って削除しないように、この設定を使用する際には注意が必要です。
データベース監査証跡表からレコードを手動で削除できます。この方法は、レコードの特定のサブセットを削除する場合に役立ちます。データベース監査証跡表が表領域(SYSTEM表領域を含む)に存在する場合に、この方法を使用できます。
たとえば、2009年2月28日の夜から2009年3月28日までに作成された監査レコードを削除するには、次の文を入力します。
DELETE FROM SYS.AUD$
WHERE NTIMESTAMP# > TO_TIMESTAMP ('28-FEB-09 09.07.59.907000 PM') AND
NTIMESTAMP# < TO_TIMESTAMP ('28-MAR-09 09.07.59.907000 PM');
また、すべての監査レコードを監査証跡から削除するには、次の文を入力します。
DELETE FROM SYS.AUD$;
データベース監査証跡からレコードを削除できるのは、ユーザーSYS、またはSYSがSYS.AUD$に対するDELETE権限を付与したユーザーのみです。
|
注意: 監査証跡がいっぱいになっている場合に、接続が監査されているとき(つまり、AUDIT SESSION文を設定している場合)は、その接続に対応する監査レコードを監査証跡に挿入できないため、通常のユーザーはデータベースに接続できません。この場合、SYSDBA権限を持つSYSで接続し、領域を監査証跡で使用可能にします。SYSによる操作は標準監査証跡には記録されませんが、AUDIT_SYS_OPERATIONSパラメータをTRUEに設定した場合は監査されます。 |
データベース監査証跡表から行を削除すると、解放された領域をその表で再利用できるようになります。(SYS.AUD$表には、現行の監査証跡レコードを保持するために必要な数だけエクステントが割り当てられます)。この領域を表で再利用できるようにするのに特に必要な操作はありません。この領域を他の表に使用する場合は、次の手順を実行します。
AUD$表を、自動セグメント領域管理表領域に移動します。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION (audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD, audit_trail_location_value => 'USERS'); END; /
次の文を実行します。
ALTER TABLE SYSTEM.AUD$ ENABLE ROW MOVEMENT; ALTER TABLE SYSTEM.AUD$ SHRINK SPACE CASCADE;
AUD$表をSYSTEM表領域に戻すには、次の文を実行してください。
BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION (audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD, audit_trail_location_value => 'SYSTEM'); END; /
データベース監査証跡表からすべての行を削除し、さらに他の表領域オブジェクト用に使用済領域を解放する場合、TRUNCATE TABLE文を使用します。次に例を示します。
TRUNCATE TABLE SYS.AUD$;
|
注意: 直接変更できるSYSオブジェクトは、SYS.AUD$およびSYS.FGA_LOG$のみです。 |
この項の内容は、次のとおりです。
DBMS_AUDIT_MGMT.IS_CLEANUP_INITIALIZED関数を実行して、監査証跡がクリーン・アップ用に初期化されたかどうかを確認できます。監査証跡が初期化されている場合は、TRUEが戻されます。初期化されていない場合は、FALSEが戻されます。
次に例を示します。
SET SERVEROUTPUT ON
BEGIN
IF
DBMS_AUDIT_MGMT.IS_CLEANUP_INITIALIZED(DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD)
THEN
DBMS_OUTPUT.PUT_LINE('AUD$ is initialized for cleanup');
ELSE
DBMS_OUTPUT.PUT_LINE('AUD$ is not initialized for cleanup.');
END IF;
END;
/
この例では、データベースの標準監査証跡が初期化されているかどうかを確認し、そのステータスを示すメッセージを戻しています。別の監査証跡の設定を選択するには、「手順3: クリーン・アップ操作のための監査証跡の初期化」で説明したAUDIT_TRAIL_TYPE設定から選択します。
指定した監査証跡タイプに対して次の削除操作が実行されるまでのデフォルトの削除操作間隔を時間単位で設定できます。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, AUDIT_TRAIL_PROPERTY => DBMS_AUDIT_MGMT.CLEAN_UP_INTERVAL, AUDIT_TRAIL_PROPERTY_VALUE => 24 ); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_TYPE: 監査証跡タイプ(この例では、データベースの標準監査証跡)を指定します。次の設定から選択します。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: 標準監査証跡表AUD$です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: ファイングレイン監査証跡表FGA_LOG$です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: 標準監査証跡表とファイングレイン監査証跡表の両方です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: 拡張子.audが付けられたオペレーティング・システム監査証跡ファイル。(この設定はWindowsイベント・ログ・エントリには適用されません。)
DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: XMLオペレーティング・システム監査証跡ファイルです。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: オペレーティング・システム監査証跡ファイルとXML監査証跡ファイルの両方です。
DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: すべての監査証跡レコード、つまりデータベース監査証跡タイプとオペレーティング・システム監査証跡タイプの両方です。
競合しないかぎり、複数の監査証跡タイプに対してデフォルトの間隔を設定できます。たとえば、DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STDおよびDBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STDプロパティに対しては個別の間隔を設定できますが、DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STDプロパティに対しては設定できません。
AUDIT_TRAIL_PROPERTY: DBMS_AUDIT_MGMT.CLEAN_UP_INTERVALプロパティを設定して、削除操作の間隔設定を指定します。現行のプロパティ設定を調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューのPARAMETER_NAMEおよびPARAMETER_VALUE列を問い合せます。DBMS_AUDIT_MGMT.CLEAN_UP_INTERVALプロパティを設定すると、計時が開始されます。
AUDIT_TRAIL_PROPERTY_VALUE: DBMS_AUDIT_MGMT.INIT_CLEANUPプロシージャで設定したデフォルトの間隔(時間単位)を更新します。1から999の値を入力します。
DBMS_AUDIT_MGMT.DEINIT_CLEANUPプロシージャを実行して、DBMS_AUDIT_MGMT.INIT_CLEANUP設定(つまり、デフォルトのクリーン・アップ間隔)を取り消すことができます。
たとえば、標準監査証跡のすべての削除設定を取り消すには、次のように入力します。
BEGIN DBMS_AUDIT_MGMT.DEINIT_CLEANUP( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_TYPE: 「手順3: クリーン・アップ操作のための監査証跡の初期化」に示したAUDIT_TRAIL_TYPE設定のいずれかを入力します。
監査証跡の削除ジョブを使用可能または使用禁止にするには、DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUS PL/SQLプロシージャを使用します。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUS( AUDIT_TRAIL_PURGE_NAME => 'OS_Audit_Trail_PJ', AUDIT_TRAIL_STATUS_VALUE => DBMS_AUDIT_MGMT.PURGE_JOB_ENABLE); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_PURGE_NAME: OS_Audit_Trail_PJという削除ジョブを指定します。既存の削除ジョブを調べるには、DBA_AUDIT_MGMT_CLEANUP_JOBSデータ・ディクショナリ・ビューのJOB_NAMEおよびJOB_STATUS列を問い合せます。
AUDIT_TRAIL_STATUS_VALUE: 次のプロパティのいずれかを入力します。
DBMS_AUDIT_MGMT.PURGE_JOB_ENABLE: 指定した削除ジョブを使用可能にします。
DBMS_AUDIT_MGMT.PURGE_JOB_DISABLE: 指定した削除ジョブを使用禁止にします。
次の削除ジョブ操作が実行されるまでのデフォルトの削除操作間隔を時間単位で設定できます。DBMS_AUDIT_MGMT.CREATE_PURGE_JOBプロシージャで使用される間隔設定が、この設定よりも優先されます。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.SET_PURGE_JOB_INTERVAL( AUDIT_TRAIL_PURGE_NAME => 'OS_Audit_Trail_PJ', AUDIT_TRAIL_INTERVAL_VALUE => 24 ); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_PURGE_NAME: 監査証跡の削除ジョブの名前を指定します。既存の削除ジョブのリストを調べるには、DBA_AUDIT_MGMT_CLEANUP_JOBSデータ・ディクショナリ・ビューのJOB_NAMEおよびJOB_STATUS列を問い合せます。
AUDIT_TRAIL_INTERVAL_VALUE: DBMS_AUDIT_MGMT.CREATE_PURGE_JOBプロシージャで設定したデフォルトの間隔(時間単位)を更新します。1から999の値を入力します。削除ジョブを実行すると、計時が開始されます。
監査証跡の削除ジョブを削除するには、DBMS_AUDIT_MGMT.DROP_PURGE_JOB PL/SQLプロシージャを使用します。既存の削除ジョブを調べるには、DBA_AUDIT_MGMT_CLEANUP_JOBSデータ・ディクショナリ・ビューのJOB_NAMEおよびJOB_STATUS列を問い合せます。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.DROP_PURGE_JOB( AUDIT_TRAIL_PURGE_NAME => 'FGA_Audit_Trail_PJ'); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_PURGE_NAME: FGA_Audit_Trail_PJという削除ジョブを指定します。
アーカイブ・タイムスタンプ設定を消去するには、DBMS_AUDIT_MGMT.CLEAR_LAST_ARCHIVE_TIMESTAMP PL/SQLプロシージャを使用します。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.CLEAR_LAST_ARCHIVE_TIMESTAMP( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML', RAC_INSTANCE_NUMBER => 1 ); END; /
この例の説明は、次のとおりです。
RAC_INSTANCE_NUMBER: AUDIT_TRAIL_TYPEプロパティをDBMS_AUDIT_MGMT.AUDIT_TRAIL_OSまたはDBMS_AUDIT_MGMT.AUDIT_TRAIL_XMLに設定している場合、RAC_INSTANCE_NUMBERを0に設定することはできません。この設定は省略することも、インスタンス番号を示す1を指定することもできます。
AUDIT_TRAIL_TYPEをDBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STDまたはDBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STDに設定している場合、またはデータベースがOracle RACデータベースでない場合は、RAC_INSTANCE_NUMBER設定を省略できます。それ以外の場合は、正しいインスタンス番号を指定します。インスタンス番号を調べるには、SQL*PlusでSHOW PARAMETER INSTANCE_NUMBERコマンドを発行します。
バッチ・サイズの設定を消去するには、DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTYプロシージャを使用します。
次に例を示します。
BEGIN DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, AUDIT_TRAIL_PROPERTY => DBMS_AUDIT_MGMT.DB_DELETE_BATCH_SIZE, USE_DEFAULT_VALUES => TRUE ); END; /
この例の説明は、次のとおりです。
AUDIT_TRAIL_TYPE: 監査証跡タイプ(この例では、データベース・システム監査証跡)を指定します。「手順6: 監査証跡レコードのバッチ削除の構成(必要に応じて)」に示したAUDIT_TRAIL_TYPE値のいずれかを入力します。
AUDIT_TRAIL_PROPERTY: DB_DELETE_BATCH_SIZEプロパティを指定します。このプロパティの現行のステータスを調べるには、DBA_AUDIT_MGMT_CONFIG_PARAMSデータ・ディクショナリ・ビューを問い合せます。
USE_DEFAULT_VALUES: TRUEに設定します。これにより、監査レコードの現行のバッチ・サイズが消去され、かわりにデフォルト値の10000が使用されます。
例9-27の疑似コードはデータベース監査証跡削除操作を作成します。この操作は、ユーザーがDBMS_ADUIT.CLEAN_AUDIT_TRAILプロシージャを起動することでコールします。この削除操作では、ループを使用することで、前回アーカイブされたタイムスタンプより前に作成されたレコードを削除します。ループは監査レコードをアーカイブし、どの監査レコードがアーカイブされたかを計算してSetCleanUpAuditTrailコールを使用して最終アーカイブ・タイムスタンプを設定し、それからCLEAN_AUDIT_TRAILプロシージャをコールします。これにより、データベース監査証跡レコードが100,000個のレコードのバッチごとに削除されます。この例では、重要な手順は太字で示しています。
例9-27 データベース監査証跡の削除操作の直接コール
-- 1. Initialize the AUD$ table for cleanup: PROCEDURE CleanUpAuditTrailMain() BEGIN -- Connect to the database using appropriate login. CALL ConnectToDatabase(); -- The login used must have privileges to modify Audit settings. -- Currently, the DBA will be the authorized user DBMS_AUDIT_MGMT.INIT_CLEANUP( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, DEFAULT_CLEANUP_INTERVAL => 12 ); END; /*PROCEDURE */ / -- 2. Optionally, set the batch size: BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, AUDIT_TRAIL_PROPERTY => DBMS_AUDIT_MGMT.DB_DELETE_BATCH_SIZE, AUDIT_TRAIL_PROPERTY_VALUE => 100000 /* delete batch size */); END; /*PROCEDURE */ / -- 3. Set the last archive timestamp: PROCEDURE SetCleanUpAuditTrail() BEGIN CALL FindLastArchivedTimestamp(AUD$); DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, LAST_ARCHIVE_TIME => '20-AUG-2009 00:00:00'); END /* PROCEDURE */ / -- 4. Run a customized archive procedure to purge the audit trail records: BEGIN CALL MakeAuditSettings(); LOOP (/* How long to loop*/) -- Invoke function for audit record archival CALL DoAuditRecordArchival(AUD$); CALL SetCleanUpAuditTrail(); IF(/* Clean up is needed immediately */) DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, USE_LAST_ARCH_TIMESTAMP => TRUE); END IF END LOOP /*LOOP*/ END; /* PROCEDURE */ /
この項の内容は、次のとおりです。
表9-7に、監査情報を提供するデータ・ディクショナリ・ビューを示します。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
表9-7 データベース監査証跡に関する情報を表示するデータ・ディクショナリ・ビュー
| ビュー | 説明 |
|---|---|
|
|
現行ユーザーがアクセス可能な表とビューに対するファイングレイン監査ポリシーが表示されます。 |
|
|
現行ユーザーがアクセス可能な表とビューに対するファイングレイン監査ポリシーの列が表示されます。 |
|
オブジェクトの作成時に適用されるデフォルトのオブジェクト監査オプションがリストされます。 |
|
監査証跡のアクション・タイプ・コードが表示されます。 |
|
|
|
|
削除イベントの履歴が表示されます。定期的に、 DELETE FROM DBA_AUDIT_MGMT_CLEAN_EVENTS; |
|
|
現在構成されている監査証跡の削除ジョブが表示されます。 |
|
|
現在構成されている監査証跡プロパティが表示されます。これらのプロパティは、 |
|
|
監査証跡の削除用に設定された最後のアーカイブ・タイムスタンプが表示されます。 |
|
システム内にあるすべてのオブジェクトの監査証跡レコードがリストされます。 |
|
|
システム上にあるすべてのファイングレイン監査ポリシーがリストされます。 |
|
|
|
|
データベース全体の表とビューに対するファイングレイン監査ポリシーの列が表示されます。 |
|
|
データベース全体の |
|
|
|
|
|
標準監査とファイングレイン監査のログ・レコードが結合され、XML形式で書き込まれた |
|
|
ファイングレイン監査の監査証跡レコードがリストされます。 |
|
|
監査オプションが有効なオブジェクトが表示されます。 |
|
監査対象となっている現行のシステム権限がシステム全体およびユーザー別に表示されます。 |
|
現行の文監査オプションがシステム全体およびユーザー別に表示されます。 |
|
|
現行ユーザーがアクセス可能なオブジェクトに関する文の監査証跡レコードがリストされます。 |
|
|
現行ユーザーがアクセス可能な表とビューに対するファイングレイン監査ポリシーの列が表示されます。 |
|
|
現行ユーザーの接続および切断に関する監査証跡レコードがすべてリストされます。 |
|
ユーザーが発行した |
|
|
|
現行ユーザーが所有するすべてのオブジェクトの監査オプションが表示されます。 |
|
|
ログの履歴情報が表示されます。このビューを問い合せるには、 |
|
|
XML形式のファイルに書き込まれた標準監査、ファイングレイン監査、 |
ここでは、監査証跡情報の検討方法と解釈方法の具体例を説明します。次の疑わしいアクティビティについて、データベースを監査するとします。
データベース・ユーザーのパスワード、表領域の設定および割当て制限が許可なく変更されている。
おそらく排他的に表ロックを取得しているユーザーが原因で、デッドロックが頻繁に発生している。
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 ------------------- -------------------- --------- ---------- PSMITH 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
脚注
脚注1: 非データベース・ユーザーとは、CLIENT_IDENTIFIER属性を使用してデータベースで認識されるアプリケーション・ユーザーのことです。このタイプのユーザーを監査するには、ファイングレイン監査ポリシーを使用します。詳細は、「ファイングレイン監査を使用した特定のアクティビティの監査」を参照してください。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列に保存されます。