21 監査の概要

監査は、ユーザーがデータベースで行う変更を追跡します。

内容は次のとおりです。

注意:

この章では、すべての監査レコードが一元管理される完全な統合監査の使用方法について説明します。統合監査を使用するためにまだ移行していない場合は、『Oracle Databaseアップグレード・ガイド』を参照してください。アップグレード・プロセス自体では、統合監査が自動的に有効にならないことに注意してください。『Oracle Databaseアップグレード・ガイド』に説明に従って、統合監査に手動で移行する必要があります。

関連項目:

システム監査の際に従う一般的なガイドラインは、「監査に関するガイドライン」を参照してください。

監査とは

監査とは、構成済のデータベース・アクション(データベース・ユーザーと非データベース・ユーザーの両方からのアクション)を監視して記録することです。

非データベース・ユーザーとは、CLIENT_IDENTIFIER属性を使用してデータベースで認識されるアプリケーション・ユーザーのことです。ユーザーのこの対応を監査する場合は、統合監査ポリシー条件、ファイングレイン監査ポリシー、またはOracle Database Real Application Securityを使用できます。

実行されたSQL文のタイプなどの個々のアクション、またはユーザー名、アプリケーション、時間などの様々なデータの組合せをベースとして使用できます。

成功したアクティビティと失敗したアクティビティの両方の監査が可能で、特定のユーザーを監査対象に含めたり、除外したりできます。マルチテナント環境では、プラガブル・データベース(PDB)の個々のアクション、またはマルチテナント・コンテナ・データベース(CDB)全体の個々のアクションを監査できます。データベースで提供される標準のアクティビティの監査に加えて、監査には、Oracle Database Real Application Security、Oracle Recovery Manager、Oracle Data Pump、Oracle Data Mining、Oracle Database Vault、Oracle Label SecurityおよびOracle SQL*Loaderダイレクト・パス・イベントからのアクティビティを含めることができます。

監査はデフォルトで有効です。すべての監査レコードは、同一の形式で統合監査証跡に書き込まれ、UNIFIED_AUDIT_TRAILビューから使用できます。これらのレコードはAUDSYSスキーマにあります。監査レコードは、デフォルトでSYSAUX表領域に格納されます。統合監査証跡のために別の表領域を構成することをお薦めします。Enterprise Editionを除くほとんどのOracle Databaseエディションでは、統合監査の表領域の関連付けは1回のみになります。この関連付けは、統合監査証跡の監査レコードを生成する前に行う必要があります。表領域を関連付けると、Enterprise Editionではパーティション化のみがサポートされるため、表領域を変更できません。

次のいずれかの方法を使用して監査を構成できます。

監査設定を1つの統合監査ポリシーにグループ化する。データベースで必要なすべての監査設定を定義する統合監査ポリシーを1つ以上作成できます。これを実行する方法は、統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査に説明されています。
デフォルトの統合監査ポリシーのいずれかを使用する。Oracle Databaseでは、一般的な機関で必要な標準の監査設定に対応したデフォルトの統合監査ポリシーが3つ用意されています。事前定義の統合監査ポリシーを使用したアクティビティの監査を参照してください。
ファイングレイン監査ポリシーを作成する。アクションの発生時刻などのデータを取得するファイングレイン監査ポリシーを作成できます。ファイングレイン監査を使用した特定のアクティビティの監査を参照してください。

データベースを監査することをお薦めします。監査は、強固な内部制御を規定する有効な方法であるため、サイトでは米国サーベンス・オクスリー法(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)

監査のベスト・プラクティス

ベスト・プラクティスに関するガイドラインに従ってください。

原則として、法令順守要件を満たすために必要な量の情報を収集するように監査方針を策定しますが、大きなセキュリティ問題の原因となるアクティビティに焦点を合せてください。たとえば、データベース内のすべての表を監査するのではなく、給与など機密性の高いデータが入った表列を監査するのが実用的です。統合監査とファイングレイン監査の両方により、監査対象の特定のアクティビティに焦点を合せた監査ポリシーの策定に使用できるメカニズムがあります。
監査証跡データを定期的にアーカイブして削除します。詳細は、監査証跡レコードの削除を参照してください。

関連項目:

システム監査の際に従う一般的なガイドラインは、監査に関するガイドラインを参照してください

統合監査とは

統合監査では、統合監査証跡により、次の各種ソースから監査情報が取得されます。

統合監査では、次のソースから監査レコードを取得できます。

統合監査ポリシーおよびAUDIT設定による監査レコード(SYS監査レコードを含む)
DBMS_FGA PL/SQLパッケージによるファイングレイン監査レコード
Oracle Database Real Application Security監査レコード
Oracle Recovery Manager監査レコード
Oracle Database Vault監査レコード
Oracle Label Security監査レコード
Oracle Data Miningのレコード
Oracle Data Pump
Oracle SQL*Loaderダイレクト・ロード

統合監査証跡は、SYSAUX表領域のAUDSYSスキーマの読取り専用の表にあり、この情報をUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューで同一の形式で使用できるようにし、単一インスタンスおよびOracle Database Real Application Clustersの両方の環境で使用できます。ユーザーSYSに加えて、AUDIT_ADMINおよびAUDIT_VIEWERロールが付与されているユーザーもこれらのビューを問い合せることができます。ユーザーが監査ポリシーの作成ではなく、ビューの問合せのみを必要としている場合は、AUDIT_VIEWERロールを付与します。

データベースが書込み可能な場合、監査レコードは統合監査証跡に書き込まれます。データベースが書込み可能でない場合、監査レコードは$ORACLE_BASE/audit/$ORACLE_SIDディレクトリの新しい形式のオペレーティング・システム・ファイルに書き込まれます。

関連項目:

UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

統合監査証跡の利点

統合監査証跡には、次のように多くの利点があります。

次に例を示します。

統合監査の有効化後、以前のリリースで使用されていた初期化パラメータには依存しません。これらの初期化パラメータのリストは、表G-1を参照してください。
SYS監査証跡のレコードを含む、Oracle Databaseインストールのすべての監査コンポーネントの監査レコードは、1つの場所に1つの形式で配置されるため、様々な場所を参照して各種形式の監査証跡を探す必要はありません。この統合ビューにより、監査者は様々なコンポーネントから監査情報を相互に関連付けることができます。たとえば、INSERT文の実行中にエラーが発生した場合は、標準の監査でエラー番号と実行されたSQLを示すことができます。Oracle Database Vault固有の情報では、このエラーがコマンド・ルール違反またはレルム違反のどちらの原因で発生したかを示すことができます。別のAUDIT_TYPEの監査レコードが2つあります。この統合を適切に設定すると、AUDIT_TYPEがStandard Auditに設定されたSYS監査レコードが表示されます。
監査証跡の管理とセキュリティは、監査証跡を単一にすることでも改善されます。
監査の全体的なパフォーマンスが大幅に向上します。デフォルトでは、監査レコードがAUDSYSスキーマの内部リレーショナル表に自動的に書き込まれます。
SYS管理ユーザーだけでなく、サポートされているコンポーネント(この項の最初に記載)を各自で監査できる名前付きの監査ポリシーを作成できます。さらに、条件と除外を各自のポリシーに作成することもできます。
Oracle Audit Vault and Database Firewall環境を使用している場合は、このデータがすべて1つの場所から取得されるため、統合監査証跡により、監査データの収集がかなり容易になります。詳細は、『Oracle Audit Vault and Database Firewall管理者ガイド』を参照してください。

データベースが統合監査に移行したかどうかの確認

V$OPTION動的ビューは、データベースが統合監査に移行されたかどうかを示します。

次に示すようにUnified Auditingを入力して、V$OPTION動的ビューのVALUE列を問い合せます。

SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';

PARAMETER         VALUE
----------------  ----------
Unified Auditing  TRUE

この出力には、統合監査が有効であることが表示されます。統合監査が有効でない場合、出力はFALSEになります。

関連項目:

統合監査を無効にする必要がある場合は、統合監査の無効化を参照してください

混合モードの監査

混合モードの監査は、新しくインストールしたデータベースでのデフォルトの監査です。

内容は次のとおりです。

混合モードの監査について

混合モード監査では、従来の監査機能(リリース12cより前のリリースの監査機能)と新しい監査機能(統合監査)の両方を使用できます。

データベースは2つのモード(混合モード監査または完全な統合監査モード)のいずれでも有効にできます。これらのどちらのモードでも統合監査の機能は有効になりますが、両者に違いがあります。混合モードでは、新しい統合監査機能を従来の監査機能と並行して使用できます。完全な統合監査では、統合監査機能のみ使用します。

表21-1に、これらの2つのモードの機能とその有効化の方法のサマリーを示します。

表21-1 混合モード監査と完全な統合監査の違い

モード	機能	有効化する方法
混合モードの監査	従来の監査と統合監査の両方	任意の統合監査ポリシーを有効にします。データベースを再起動する必要はありません。
完全な統合監査	統合監査のみ	`oracle`バイナリを`uniaud_on`にリンクし、データベースを再起動します。

混合モードは統合監査を導入するためのもので、その機能や特徴、利点を知ることができます。混合モードで、統合監査を使用するように既存のアプリケーションおよびスクリプトを移行することができます。完全な統合監査を使用することにしたら、統合監査オプションを有効にしてoracleバイナリを再リンクし、統合監査をOracleデータベースで実行する唯一の監査機能として有効にします。混合モードに戻す必要がある場合は戻すことができます。

以前のリリース同様、従来の監査機能は、AUDIT_TRAIL初期化パラメータの影響を受けます。混合モードの監査の場合のみ、このパラメータを対応する従来の監査証跡に設定する必要があります。この従来の監査証跡には、統合監査証跡とともに、監査レコードが移入されます。

データベースを現在のリリースにアップグレードすると、従来の監査が保存され、新規監査レコードが従来の監査証跡に書き込まれます。移行(『Oracle Databaseアップグレード・ガイド』で説明)の完了後も、以前のリリースの監査レコードはこれらの監査証跡で引き続き使用可能です。企業の保存ポリシーに基づき、DBMS_AUDIT_MGMT PL/SQLプロシージャを使用して、これらの古い監査証跡をアーカイブして削除できます。

関連項目:

移行前と移行後の監査環境での機能の可用性の比較は、統合監査の移行による各監査機能への影響を参照してください
データベースが統合監査に移行したかどうかの確認
データベースを統合監査に移行する方法と、移行しない場合に使用するドキュメントは、『Oracle Databaseアップグレード・ガイド』を参照してください。

有効にした監査のタイプがデータベースの作成でどのように決定されるか

統合監査では、新しい形式のオペレーティング・システム・ファイルの場所として、$ORACLE_BASE/auditディレクトリが使用されます。

新しく作成されたデータベースでは、事前定義のポリシーORA_SECURECONFIGにより、混合モードの監査がデフォルトで有効になります。

統合監査の使用を開始するには、少なくとも1つの統合監査ポリシーを有効にし、その使用を停止するには、すべての統合監査ポリシーを無効にする必要があります。

関連項目:

ORA_SECURECONFIGポリシーの詳細は、セキュア・オプションの事前定義の統合監査ポリシーを参照してください

混合モードの監査の機能

混合モードの監査では、次の機能が提供されます。

これらの機能は次のとおりです。

既存の監査初期化パラメータのAUDIT_TRAIL、AUDIT_FILE_DEST、AUDIT_SYS_OPERATIONSおよびAUDIT_SYSLOG_LEVELをすべて使用できるようにします。
従来の監査証跡に必須の監査レコードのみを書き込みます。
標準の監査レコードを標準の監査構成に基づくようにし、AUDIT_TRAIL初期化パラメータで指定された監査証跡にこれらのレコードを書き込みます。

ただし。標準の監査証跡レコードは統合監査ポリシーに基づいても生成され、これらの監査レコードのみが統合監査証跡に書き込まれることに注意してください。統合監査ポリシーの結果として生成された標準の監査レコードは、統合監査ポリシーの有効化のセマンティクスに従います。
管理ユーザー・セッションにより、SYS監査レコードが生成されます。これらのレコードは、AUDIT_SYS_OPERATIONS初期化パラメータがTRUEに設定されている場合に書き込まれます。このプロセスでは、レコードは従来の監査証跡のみに書き込まれます。ただし、統合監査ポリシーが管理ユーザーで有効な場合は、これらの統合監査レコードも統合監査証跡に書き込まれます。
従来の監査証跡に書き込まれる監査レコードの形式は、Oracle Database 11gリリース2と同じままです。
デフォルトでは、Oracle Databaseで統合監査レコードがシステム・グローバル領域(SGA)キューに書き込まれます。つまり、レコードは即座にではなく定期的に書き込まれます。監査レコードが書き込まれる間隔を制御することはできません。詳細は、AUDSYSスキーマへの統合監査証跡レコードの書込みを参照してください。
監査レコードの書込みのパフォーマンス・コストは、監査レコードを生成して従来の監査証跡と統合監査証跡に書き込むのに必要な総時間と同等です。
混合モードの監査は、統合監査モードの機能の一部です。新しい形式の監査ポリシーと監査証跡に問題ない場合は、統合監査モードに移行することをお薦めします。統合監査に移行するには、『Oracle Databaseアップグレード・ガイド』を参照してください。

監査の実行者

Oracleでは監査を実行するユーザー用にAUDIT_ADMINとAUDIT_VIEWERという2つのロールが用意されています。

任意の種類の監査を実行するには、AUDIT_ADMINロールが付与されている必要があります。監査者は、AUDIT_VIEWERロールが付与された後に監査データを表示できます。

これらのロールによって提供される権限を次に示します。

AUDIT_ADMINロール。このロールでは、統合およびファイングレイン監査ポリシーの作成、AUDITおよびNOAUDIT SQL文の使用、監査データの表示、および監査証跡の管理が可能です。このロールは、信頼できるユーザーにのみ付与します。
AUDIT_VIEWERロール。このロールでは、ユーザーによる監査データの表示と分析が可能です。このロールが必要なユーザーの種類は、通常は外部監査者です。

注意:

以前のリリースでは、ユーザーは、追加の権限なしで、各自のスキーマのオブジェクトへの監査構成の追加と削除が許可されていました。この機能は使用できなくなりました。

マルチテナント環境での監査

統合監査をマルチテナント環境で使用できます。

ポリシーのタイプに応じて、各PDBに監査設定を適用したり、CDB全体に監査設定を適用できます。マルチテナント環境では、ルートを含むPDBにそれぞれ独自の統合監査証跡があります。

詳細は、次の各項を参照してください。

CREATE AUDIT POLICYおよびAUDIT文で作成された統合監査ポリシー: ルートと個々のPDBの両方のポリシーを作成できます。「マルチテナント環境での統合監査ポリシーまたはAUDIT設定の使用」を参照してください。
ファイングレイン監査ポリシー: ルートではなく、個々のPDBのポリシーのみを作成できます。「ファイングレイン監査ポリシーの作成」を参照してください
監査証跡の削除: ルートと個々のPDBの両方に対して、削除操作を実行できます。「監査証跡レコードの削除」を参照してください。

関連項目:

マルチテナント環境での一般的な監査構成の詳細は、『Oracle Database概要』を参照してください。

分散データベースでの監査

データベース・インスタンスでは直接接続しているユーザーによって発行された文のみが監査されるため、監査はサイトで自律的に実行されるといえます。

ローカルのOracle Databaseノードでは、リモート・データベースで発生するアクションを監査できません。