データの暗号化とアクセス制御はセキュリティリスクを大幅に低減できますが、権限を持つユーザーに対しても、ユーザーのログイン情報の漏洩やアクセス権限の乱用を防ぐために、その操作を記録する必要があります。監査機能は、企業のデータセキュリティやコンプライアンスなどの要件を強化し、ユーザー行動を追跡するための主要なツールです。
適用対象
OceanBaseデータベースCommunity Editionは、現在セキュリティ監査をサポートしていません。
監査の有効化
構成パラメータaudit_trailを使用して監査機能を有効にします。実行後すぐに反映されます。
NONE：監査を無効にします。
OS：監査レコードをローカルファイルに書き込みます。
DB：監査レコードを内部テーブルに書き込みます。
DB,EXTENDED：監査レコードを内部テーブルに書き込み、レコードには実行されたSQL文が含まれます。
管理者ユーザーは最高権限を持ち、多くの操作を実行できるため、管理者に対しては個別に監査を設定します。テナント構成パラメータaudit_sys_operationsは、管理者の操作を監査レコードに記録するかどうかを決定します。
監査ルールの設定
組み込みの監査管理ユーザーORAAUDITORを使用して、監査ルールを設定できます。これには以下が含まれます：
ステートメント監査：特定の操作を監査します。具体的なオブジェクトを指定しない場合、特定のユーザーまたはすべてのユーザーに対して有効にすることができます。
オブジェクト監査：特定のオブジェクト上で実行される特定の操作を監査します。特定のユーザーまたはすべてのユーザーに対して有効にすることができます。
監査ルールは、DDLステートメントaudit/noauditステートメントを使用して設定され、監査ルールも一種のスキーマオブジェクトです。
監査プロセス
監査チェックのタイミングは、ユーザーのSQL実行完了後、レスポンスパケットの準備前です。監査チェックのプロセスは以下のとおりです：
現在のユーザーに対して監査が実施されるかどうかを、テナント、ユーザー名、構成パラメータを総合的に判断して確認します。
SQLステートメント内で監査可能な操作を解析します。1つの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が記録されます。
監査レコードの挿入はユーザートランザクションから独立しており、ユーザートランザクションがロールバックされても、監査レコードは保持されます。
監査書き込みテーブルに失敗した場合、監査レコードを監査書き込みファイル方式で保存しようとします。