セキュリティ監査の概要

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

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. ルールに該当する各操作ごとに、個別の監査ログが生成されます。設定によって、監査ログは内部テーブルまたはファイルに記録されます。