セキュリティ監査の概要

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

MySQLモードの監査

フィルターを使用して、監査対象のリクエストタイプを設定します。例えば、ログイン・ログアウト、DMLステートメント、CMDステートメントなどです。対応するレコードはローカルディスクまたはOSS監査ファイルに永続化され、設定されたポリシーに従ってローリング、クリーンアップ、圧縮が行われます。

監査の概要

OceanBaseデータベースのMySQLモードでは、データベース監査機能は一連のフィルターを使用して特定のイベントを監査します。フィルターは、アカウント、イベントタイプ、イベント属性などの次元でフィルタリングでき、フィルタリングされたイベントを監査するかどうかを決定します。フィルターを設定した後、ユーザーに適用して初めて有効になります。フィルターとユーザーの関係は1対多です：1つのフィルターは複数のユーザーに適用できますが、各ユーザーには1つのフィルターしか適用できません。同時に、明示的にフィルターが設定されていないすべてのユーザーに適用されるデフォルトのフィルターを設定できます。

監査プロセス

MySQLテナントの監査プロセスには、セキュリティ監査の有効化、監査ルールの設定と表示、監査レコードの表示、およびセキュリティ監査の無効化が含まれます。セキュリティ監査を有効にする際には、監査範囲を決定し、使用制限に注意した上で、データフィルタリングのためにフィルターを作成して設定する必要があります。監査ルールの設定と表示には、ログ戦略、形式、データの匿名化、出力パス、アーカイブ、クリーンアップ、圧縮などの決定が含まれます。ログを通じて監査レコードを表示し、最後にセキュリティ監査を無効にする際には、フィルター設定をクリアしてフィルターを削除します。

Oracleモードの監査

テナント単位で、監査員ORAAUDITORが実行し、Oracle標準に準拠するSQLステートメントとデータオブジェクトの操作を記録し、結果をディスクファイルまたはデータベーステーブルに保存しますが、統一的な監査や監査データの削除はサポートされていません。

監査の概要

• 監査はテナント単位で行われ、テナントAが開始した監査はテナントAのユーザーの操作にのみ有効であり、他のテナントには無効です。

• 監査操作は監査員ORAAUDITORのみが実行でき、三権分立の要件を満たしています。

• 監査内容、構文はOracle標準監査と基本的に一致しています。統一的な監査はサポートされていません。

• 監査結果はディスクファイルに保存することも、データベーステーブルに保存することもできます。

• SQLステートメントとデータオブジェクトの監査タイプをサポートしています。

• 監査データの変更、上書き、削除はサポートされていません。

監査プロセス

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

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

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

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

4. ルールにヒットした各操作ごとに、個別に監査レコードを生成します。構成パラメータに基づき、監査レコードは内部テーブルまたはファイルに記録されます。