監査ルールの設定

セキュリティ監査を有効にした後、ユーザーの操作を監査するための具体的なセキュリティ監査ルールを設定する必要があります。

ログポリシーの設定

パラメータ audit_log_strategy を使用して監査ログのポリシーを設定します。ASYNCHRONOUS、PERFORMANCE、SYNCHRONOUS の3種類の書き込みポリシーをサポートしており、必要に応じて対応する書き込みポリシーを選択することで、パフォーマンスとログの整合性のバランスを実現できます。

• ASYNCHRONOUS：非同期ログ書き込みを表します。bufferがいっぱいになると同期的に待機します。このポリシーはデフォルトポリシーです。

• PERFORMANCE：非同期ログ書き込みを表します。bufferがいっぱいになるとデータは破棄されます。

• SYNCHRONOUS：同期ログ書き込みを表します。

例えば、監査レコードのファイル書き込みポリシーを非同期ログ書き込みに設定すると、bufferがいっぱいになると同期的に待機します。

obclient [test]> ALTER SYSTEM SET audit_log_strategy='ASYNCHRONOUS';

非同期ログ書き込みを使用する場合、パラメータ audit_log_buffer_size を使用して bufferサイズを制御できます。

ログ形式の設定

パラメータ audit_log_format を設定して監査ログの形式を選択します。現在、CSV形式のみをサポートしています。

obclient [test]> ALTER SYSTEM SET audit_log_format='CSV';

データマスキングの設定

パラメータ audit_log_query_sql を使用して監査レコード内のSQLステートメントを選択します。値には ALL と NONE の2種類が含まれます。

• ALL：すべてのQuery SQLを記録します。

• NONE：Query SQLを記録しません。

例えば、監査レコード内のSQLステートメントを記録しないように設定します。

obclient [test]> ALTER SYSTEM SET audit_log_query_sql='NONE';

Query SQLを記録する際、監査ファイルでは以下のステートメントに対してデータマスキングを行いました：

• CMD：パスワード、AK/SKなどの機密情報を含むステートメント（ユーザー作成、バックアップ・リストアの開始、パラメータの変更など）は、一律に *** として記録されます。その他のタイプのCMDステートメントは、元のSQLを直接記録します。
• ステートメントのタイプが判断できない場合：例えばParser失敗の場合も *** として記録されます。

出力パスの設定

パラメータ audit_log_path を使用して監査ログの出力パスを設定します。ローカルストレージとクラウドストレージをサポートしています。audit_log_path の値が指定されていない場合、デフォルトで現在の作業ディレクトリ ${WORK_DIR}/audit が使用されます。

• ローカルストレージの場合

  同一テナント内で、異なるOBServerの監査ログは異なるディレクトリに出力されます。同一クラスタ内で、異なるテナントの出力パスを同じものに設定した場合、ディレクトリ構造に tenant_id の階層が追加されます。ローカルの出力ディレクトリ構造は以下のようになります：

  - ${audit_log_path}
  - tenant_id_1
  - ip1:port1
      - audit.log.20231031080646317[.zst]
      - audit.log.20231031084835263[.zst]
      - audit.log
  - ip2:port2
      - audit.log.20231031072457838[.zst]
      - audit.log.20231031093023607[.zst]
      - audit.log.20231031101213751[.zst]
      - audit.log
  - tenant_id_2
  

  監査ログの出力ディレクトリをローカルに設定する例を以下に示します。

  obclient [test]> ALTER SYSTEM SET audit_log_path='file:///logs/audit';
  

• クラウドストレージの場合

  OceanBaseデータベースは、複数のOBServerが同一の oss/nfs ディレクトリに出力する構成をサポートしています。ただし、ファイルの並行追記におけるパフォーマンスや、その後の圧縮・暗号化処理ではローカルファイルに対する操作が必要となる点を考慮し、アーカイブ済みのファイルのみがクラウドストレージに保存されます。アクティブなログの追記は、各OBServerのローカルにある audit ディレクトリ内のファイルに対して行われます。このため、下流のシステムがクラウドストレージ上の監査ログを利用する際、最新のログレコードの一部はまだOBServerのローカルにしか存在せず、下流からは参照できません。

  監査ログの出力ディレクトリを OSS に設定する例を以下に示します。

  obclient [test]> ALTER SYSTEM SET audit_log_path = 'oss://ob-audit/audit/?host=$OSS_HOST&access_id=$OSS_ACCESS_ID&access_key=$OSS_ACCESS_KEY';
  

  ここで、$OSS_HOST、$OSS_ACCESS_ID、$OSS_ACCESS_KEY は実際のホストアドレス、アクセスキーID、アクセスキーに置き換えてください。アクセスキーは暗号化されて保存されます。

ログアーカイブの設定

監査レコードは継続的に audit.log ファイルに追記されます。audit_log_rotate_on_size パラメータを設定することで、ログの自動アーカイブを有効にできます。audit.log のサイズが指定された値に達すると、新しいファイルが自動的に生成されます。このアーカイブ機能は個々のログファイルのサイズを制御する役割を担い、古いファイルをクリーンアップする役割は担いません。

例えば、監査レコードの単一ファイルのサイズを256MBに設定します。

obclient [test]> ALTER SYSTEM SET audit_log_rotate_on_size='256M';

ログクリーンアップの設定

パラメータ audit_log_max_size と audit_log_prune_seconds を使用して、アーカイブ後の監査ログの容量と保存期間を制御します。両方のパラメータは同時に有効にできます。新しいアーカイブファイルが生成されるたびに、クリーンアップが必要かどうかのチェックが実行されます。ログの合計サイズは、各OBServerディレクトリ内で個別に計算されます。

パラメータ audit_log_max_size を設定して、単一のOBServer上で保存できる監査ログの最大量を制御します。デフォルト値は0MBで、監査ログを保存しないことを意味します。

例えば、単一のOBServer上で保存できる監査ログの最大量を1GBに設定します。

obclient [test]> ALTER SYSTEM SET audit_log_max_size='1G';

パラメータ audit_log_prune_seconds を設定して、監査ログの最大保存時間を制御します。単位は秒です。設定時に単位を指定する必要はありません。デフォルト値は0で、監査ログを保存しないことを意味します。

例えば、監査ログの最大保存時間を2時間に設定します。

obclient [test]> ALTER SYSTEM SET audit_log_prune_seconds=7200;

ログ圧縮の設定（オプション）

パラメータ audit_log_compression を設定して、ログ圧縮の有効化を制御します。圧縮が有効な場合、ログアーカイブ時に直接圧縮済みファイルが生成されます。圧縮アルゴリズムは ZSTD のみをサポートし、ストリーミング圧縮も可能です。圧縮後のファイルは、外部ツール zstd を使用して直接解凍できます。

例えば、監査ログで使用する圧縮アルゴリズムを ZSTD に設定します。

obclient [test]> ALTER SYSTEM SET audit_log_compression='ZSTD';