データ暗号化とアクセス制御はセキュリティリスクを大幅に低減できますが、権限を持つユーザーの操作を記録し、ユーザーログイン情報の漏洩やアクセス権限の乱用を防ぐ必要があります。監査機能は、企業のデータセキュリティやコンプライアンスに関する要件を強化し、ユーザーの行動を追跡する主要なツールです。
適用対象
この内容はOceanBaseデータベースEnterprise Editionにのみ適用されます。OceanBaseデータベースCommunity Editionは、現在監査機能をサポートしていません。
MySQLモードの監査
フィルターを使用して監査対象のリクエストタイプ（ログイン/ログアウト、DMLステートメント、CMDステートメントなど）を設定します。対応するレコードはローカルディスクまたはOSS監査ファイルに永続化され、設定されたポリシーに従ってローテーション、クリーンアップ、圧縮が実行されます。
監査の概要
OceanBaseデータベースのMySQLモードでは、データベース監査機能は一連のフィルターを通じて特定のイベントを監査します。フィルターは、アカウント、イベントタイプ、イベント属性などの次元でフィルタリングし、選別されたイベントを監査するかどうかを決定します。フィルターを設定した後、ユーザーに適用する必要があります。フィルターとユーザーの関係は1対多です。1つのフィルターは複数のユーザーに適用できますが、各ユーザーは1つのフィルターのみを適用できます。同時に、明示的にフィルターが設定されていないすべてのユーザーに適用されるデフォルトフィルターを設定できます。
監査プロセス
MySQLテナントの監査プロセスには、セキュリティ監査の有効化、監査ルールの設定と表示、監査レコードの表示、およびセキュリティ監査の無効化が含まれます。セキュリティ監査を有効にする際は、監査範囲を確定し、使用上の制限に注意した上で、データフィルタリングを行うためのフィルターを作成して設定する必要があります。監査ルールの設定と表示には、ログポリシー、形式、データマスキング、出力パス、アーカイブ、クリーンアップ、圧縮などの設定が含まれます。ログを通じて監査レコードを表示し、最後にセキュリティ監査を無効にする際は、フィルター設定をクリアしてフィルターを削除します。
Oracleモードの監査
テナント単位で、監査員ORAAUDITORが実行し、Oracle標準に準拠するSQLステートメントとデータオブジェクト操作を記録し、結果をディスクファイルまたはデータベーステーブルに保存しますが、統一的な監査や監査データの削除はサポートしていません。
監査の概要
監査はテナント単位で行われます。テナントAが開始した監査は、テナントA配下のユーザーの操作にのみ有効で、他のテナントには無効です。
監査操作は監査員
ORAAUDITORのみが実行でき、三権分立の要件を満たしています。監査内容、構文はOracle標準監査と基本的に一致しています。統一的な監査はサポートしていません。
監査結果はディスクファイルにもデータベーステーブルにも保存できます。
SQLステートメントとデータオブジェクトの監査タイプをサポートしています。
監査データの変更、上書き、削除はサポートしていません。
監査プロセス
監査チェックのタイミングは、ユーザーのSQL実行完了後、応答パケットを準備する前です。監査チェックのプロセスは以下のとおりです：
現在のユーザーに対して監査を実施するかどうかを、テナント、ユーザー名、パラメータを総合的に判断してチェックします。
SQLステートメント内で監査可能な操作を解析します。1つのSQLステートメントには複数の異なる操作が含まれる場合があります。例えば、
insert into t1 select * from t2, t3には(insert, t1)、(select, t2)、(select t3)の3つの操作が含まれます。各操作ごとに、任意の監査ルールに該当するかどうかを個別に判断します。
ルールに該当する各操作ごとに、個別の監査レコードを生成します。設定によって、監査レコードは内部テーブルまたはファイルに記録されます。