Overview

Data encryption and access control can significantly reduce security risks. However, OceanBase Database still needs to record the operations of authorized users to prevent the leakage of user login information or the abuse of access permissions. Security audit is a feature for tracking user behavior, which can meet enterprises' strict data security and compliance requirements.

Audit in MySQL mode

You can use filters to specify the types of requests to be audited, such as login, logout, DML statements, and CMD commands. Corresponding records are persisted to the local disk or audit files of Alibaba Cloud Object Storage Service (OSS), and are rotated, deleted, and compressed based on the configured strategy.

Background information

In MySQL mode of OceanBase Database, the database audit feature audits specific events by using a series of filters. A filter can filter events by account, event type, and event attribute, and determine whether to audit the events that meet the filter conditions. A filter takes effect only after it is applied to a user. One filter corresponds to multiple users. You can apply one filter to multiple users, but each user can have only one filter. You can specify a default filter for all users that have no filter specified.

Audit process

The audit process for a MySQL tenant includes the following steps: enable the security audit feature, set and view audit rules, view audit records, and disable this feature. When you enable security audit, you must determine the audit scope and observe the limitations, and then create and configure filters for data filtering. When you set and view audit rules, you can specify the log strategy, format, data desensitization, output path, archiving, cleanup, and compression. You can view audit records in logs, and you must clear the filter configurations and delete the filters before disabling security audit.

Audit in Oracle mode

You can perform audit for an Oracle tenant of OceanBase Database as the ORAAUDITOR user. The security audit feature records SQL statements and data object operations that meet Oracle standards and saves the results to disk files or database tables. However, this feature does not support unified audit or deletion of audit data.

Background information

• Audit is performed in the unit of tenants. Tenant A can initiate an audit on user operations only in tenant A, and this audit does not take effect on other tenants.

• Audit must be performed by the ORAAUDITOR user, which complies with the requirement of separation of powers.

• The audit content and syntax are basically consistent with the audit requirements of Oracle. Unified audit is not supported.

• Audit results can be saved in a disk file or an internal database table.

• Audit can be performed on SQL statements and data objects.

• Audit data cannot be deleted.

Audit process

Security audit starts after an SQL statement is executed but before the return of data packets. The audit process is as follows:

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

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

3. Check whether each operation hits an audit rule.

4. Generate an audit record for each operation that hits an audit rule. Save the audit records in internal tables or files based on the parameters.

References

For more information about audit operations, see the following topics:

• Set and view audit rules
• View audit records