Data encryption and access control can significantly reduce security risks. However, it is still necessary to record the actions of users with privileges to prevent login information leaks or the abuse of access permissions. The auditing feature strengthens an enterprise’s ability to meet data security and compliance requirements, and is the primary tool for tracking user activities.
Applicability
This content applies only to OceanBase Database Enterprise Edition. The auditing feature is not supported in OceanBase Database Community Edition
Auditing in MySQL-compatible mode
You can specify the types of requests to be audited by using filters, such as login/logout requests, DML statements, and CMD statements. The requests are recorded in auditing files on the local disk or in Alibaba Cloud OSS, and the records are rotated, cleaned, and compressed according to specified policies.
Overview
In MySQL-compatible mode of OceanBase Database, the database auditing feature audits specific events by using a series of filters. Filters can screen events based on dimensions such as account, event type, and event attributes, and determine whether to audit the filtered events. After configuring filters, you must apply them to users for the filters to take effect. The relationship between filters and users is one-to-many: one filter can be applied to multiple users, but each user can have only one filter. You can also set a default filter, which applies to all users who do not have a filter specified.
Procedure
The auditing procedure in MySQL-compatible mode consists of the following steps: enabling security auditing, setting and viewing auditing rules, viewing auditing records, and disabling security auditing. When enabling security auditing, you need to specify the auditing scope and note any usage restrictions, then create and configure filters for data filtering. Setting and viewing auditing rules involves specifying log policies, formats, data masking, output paths, archiving, cleaning, and compression. Auditing records can be viewed through logs. When disabling security auditing, you must clear filter configurations and delete filters.
Auditing in Oracle-compatible mode
Auditing is performed on a tenant basis by an auditor with the ORAAUDITOR role. It records SQL statements that conform to Oracle standards and data object operations, saving the auditing results to disk files or database tables. Unified auditing and deletion of auditing data are not supported.
Overview
Auditing is conducted on a tenant basis. An auditing initiated by Tenant A applies only to operations performed by users within Tenant A and does not affect users in other tenants.
Only the
ORAAUDITORrole can perform auditing operations, which meets the requirements for separation of duties.The auditing content and syntax are consistent with standard Oracle auditing, except that unified auditing is not supported.
Auditing results can be saved to disk files or database tables.
Both SQL statements and data object operations are supported for auditing.
Deletion of auditing data is not supported.
Procedure
Auditing checks are performed after a user SQL statement has finished executing and before the response packet is prepared. The auditing check procedure is as follows:
Determine whether auditing applies to the current user based on tenant, username, and configuration settings.
Parse the SQL statement to identify all auditable operations. A single SQL statement may contain multiple different operations. For example, in the statement
insert into t1 select * from t2, t3, the operations are(insert, t1),(select, t2), and(select, t3).For each operation, check whether it matches any auditing rule.
Each operation that matches an auditing rule generates a separate auditing record. Depending on configuration settings, auditing records can be stored in internal tables or files.