Security audit

Data encryption and access control greatly reduce security risks. However, OceanBase Database still needs to record the behaviors of authorized users to prevent risks due to the leakage of user login information or the abuse of access permissions. Security audit is an effective tool for tracking user behaviors. It allows enterprises to meet higher data security and compliance requirements.

Enable security audit

Security audit is enabled through the audit_trail parameter. It takes effect immediately after the configuration is applied. Valid values:

• NONE: disables security audit.

• OS: writes audit records to local files.

• DB: writes audit records to internal tables.

• DB,EXTENDED: writes audit records to internal tables and the records include the executed SQL statements.

Administrator users have the highest privileges and can perform many operations. Therefore, there is separate audit configuration for administrators. The tenant parameter audit_sys_operations determines whether administrator operations are audited.

Set audit rules

Audit rules can be configured through the built-in audit management user ORAAUDITOR, including:

• Statement audit: audits specific operations without specifying objects. You can specify that it applies to specific users or all users.

• Object audit: audits specific operations performed on specific objects. You can specify that it applies to specific users or all users.

Audit rules are configured through DDL AUDIT/NOAUDIT statements. Audit rules are also schema objects.

Audit process

The audit check occurs after a user SQL statement is executed and before the response packet is returned. The audit process is as follows:

1. Check whether the current user is audited, based on tenant, username, and parameters.

2. Parse auditable operations in the SQL statement. One SQL statement can contain multiple different operations. For example, insert into t1 select * from t2, t3 contains three operations: (insert, t1), (select, t2), (select, t3).

3. For each operation, determine whether it matches any audit rule.

4. Each operation that matches a rule generates one audit record. Based on the parameters, audit records can be written to internal tables or files.

Audit records

Audit files are stored in the audit directory in the format observer_${pid}_${timestamp}.aud. File writing uses the interface provided by ObLogger, with the same behavior as other system logs. When the file size reaches 256 MB, it is split.

Writing audit records to internal tables has the following characteristics:

• When AUDIT_TRAIL is DB, user SQL is not recorded; when it is DB,EXTENDED, user SQL is recorded.

• Audit record insertion is independent of user transactions. Even if a user transaction is rolled back, the audit record is retained.

• When audit write to table fails, it attempts to save the audit record by writing to a file.