セキュリティ監査

データ暗号化とアクセス制御はセキュリティリスクを大幅に低減できますが、権限を持つユーザーの操作を記録し、ユーザーログイン情報の漏洩やアクセス権限の乱用を防ぐ必要があります。監査機能は、企業のデータセキュリティやコンプライアンスに関する要件を強化するものであり、ユーザー行動を追跡する主要なツールです。

監査の有効化

パラメータ audit_trail を使用して監査機能を有効にします。設定は実行後すぐに反映されます。

• NONE：監査を無効にします。

• OS：監査レコードをローカルファイルに書き込みます。

• DB：監査レコードを内部テーブルに書き込みます。

• DB,EXTENDED：監査レコードを内部テーブルに書き込み、レコードには実行されたSQL文が含まれます。

管理者ユーザーは最高権限を持ち、多くの操作を実行できるため、管理者に対しては別途監査設定が必要です。テナントのパラメータ audit_sys_operations が管理者の操作を監査レコードに残すかどうかを決定します。

監査ルールの設定

組み込みの監査管理ユーザー ORAAUDITOR を使用して、監査ルールを設定できます。これには以下が含まれます：

• ステートメント監査：特定の操作を監査します。具体的なオブジェクトは指定せず、特定のユーザーまたはすべてのユーザーに適用するかどうかを指定できます。

• オブジェクト監査：特定のオブジェクト上で実行される特定の操作を監査します。特定のユーザーまたはすべてのユーザーに適用するかどうかを指定できます。

監査ルールは DDL ステートメントである audit/noaudit ステートメントを使用して設定され、監査ルール自体もスキーマオブジェクトの一種です。

監査プロセス

監査チェックのタイミングは、ユーザーのSQLが実行終了後、応答パケットを準備する前です。監査チェックのプロセスは以下のとおりです：

1. 現在のユーザーに対して監査を実施するかどうかを、テナント、ユーザー名、パラメータを総合的に判断して確認します。

2. SQL文内で監査可能な操作を解析します。1つのSQL文には複数の異なる操作が含まれる場合があります。例えば、insert into t1 select * from t2, t3 には (insert, t1), (select, t2), (select t3) の3つの操作が含まれています。

3. 各操作ごとに、任意の監査ルールに該当するかどうかを個別に判断します。

4. ルールにヒットした各操作ごとに、個別の監査レコードが生成されます。設定によって、監査レコードは内部テーブルまたはファイルに記録されます。

監査レコード

監査ファイルは audit ディレクトリに配置され、observer_${pid}_${timestamp}.aud のファイル名形式で保存されます。ファイルの書き込みにはObLoggerが提供するインターフェースが使用され、その機能は他のシステムログと同じです。ファイルサイズが256MBに達すると、分割されます。

内部テーブルへの監査レコードの書き込みには、以下の特性があります：

• AUDIT_TRAILの値がDBの場合、ユーザーSQLは記録されません。値がDBまたはEXTENDEDの場合、ユーザーSQLが記録されます。

• 監査レコードの挿入はユーザートランザクションとは独立しており、ユーザートランザクションがロールバックしても監査レコードは保持されます。

• 監査レコードのテーブルへの書き込みに失敗した場合、監査レコードをファイルに書き込む方法で保存する試みが行われます。