データの暗号化とアクセス制御はセキュリティリスクを大幅に低減できますが、権限を持つユーザーの操作は引き続き記録する必要があります。これは、ユーザーログイン情報の漏洩やアクセス権限の乱用を防ぐためです。監査機能は、企業のデータセキュリティやコンプライアンスに対する要求を強化し、ユーザーの行動を追跡する主要なツールです。
機能の適用範囲
OceanBaseデータベースCommunity Editionは、現在セキュリティ監査をサポートしていません。
監査の有効化
パラメータ audit_trail を使用して監査機能を有効にします。設定は実行後すぐに反映されます。
NONE：監査を無効にします。
OS：監査レコードをローカルファイルに書き込みます。
DB：監査レコードを内部テーブルに書き込みます。
DB,EXTENDED：監査レコードを内部テーブルに書き込み、レコードには実行されたSQLステートメントが含まれます。
管理者ユーザーは最高権限を持ち、多くの操作を実行できるため、管理者に対しては別途監査を設定します。テナントのパラメータ audit_sys_operations が管理者の操作を監査レコードに残すかどうかを決定します。
監査ルールの設定
組み込みの監査管理ユーザー ORAAUDITOR を使用して、以下の監査ルールを設定できます：
ステートメント監査：特定の操作を監査します。具体的なオブジェクトは指定せず、特定のユーザーまたはすべてのユーザーに適用することができます。
オブジェクト監査：特定のオブジェクト上で実行される特定の操作を監査します。特定のユーザーまたはすべてのユーザーに適用することができます。
監査ルールは DDL ステートメント audit/noaudit ステートメントを使用して設定され、監査ルールも一種のスキーマオブジェクトです。
監査プロセス
監査チェックのタイミングは、ユーザーのSQLが実行終了し、応答パケットを準備する前です。監査チェックのプロセスは以下のとおりです：
現在のユーザーに対して監査を実施するかどうかを、テナント、ユーザー名、パラメータを総合的に判断して確認します。
SQLステートメント内で監査可能な操作を解析します。一つのSQLステートメントには複数の異なる操作が含まれる場合があります。例えば、
insert into t1 select * from t2, t3には(insert, t1), (select, t2), (select t3)の3つの操作が含まれます。各操作ごとに、任意の監査ルールに該当するかどうかを個別に判断します。
ルールに該当する各操作ごとに、個別の監査レコードを生成します。パラメータに基づき、監査レコードは内部テーブルまたはファイルに記録されます。
監査レコード
監査ファイルは audit ディレクトリに配置され、observer_${pid}_${timestamp}.aud のファイル名形式で保存されます。ファイルの書き込みにはObLoggerが提供するインターフェースが使用され、その機能は他のシステムログと同じです。ファイルサイズが256MBに達すると、分割されます。
内部テーブルへの監査レコードの挿入には、以下の特性があります：
AUDIT_TRAIL の値が DB の場合、ユーザーSQLは記録されません。値が DB,EXTENDED の場合、ユーザーSQLが記録されます。
監査レコードの挿入はユーザートランザクションと独立しています。ユーザートランザクションがロールバックしても、監査レコードは保持されます。
監査によるテーブルへの書き込みに失敗した場合、監査レコードをファイルに書き込む方法で保存を試みます。