Unified Audit

Availability

This feature is available since MogDB 1.1.0.

Introduction

The audit mechanism is a security management solution that can effectively deal with the attackers' repudiation. The larger the audit scope is, the more operations can be monitored and the more audit logs are generated, affecting the actual audit efficiency. The unified audit mechanism is a technology that implements efficient security audit management by customizing audit policies. After the administrator defines the audit object and audit behaviors, if the task executed by a user is associated with an audit policy, the corresponding audit behavior is generated and the audit log is recorded. Customized audit policies can cover common user management activities, as well as DDL and DML operations, meeting routine audit requirements.

Benefits

Audit is indispensable for routine security management. When a traditional audit mechanism is used to audit an operation, such as SELECT, a large number of audit logs are generated, increasing the I/O of the entire system and affecting the system performance and audit efficiency of administrators. The unified audit mechanism allows you to customize policies for generating audit logs. For example, only the operation that database account A queries table a is audited. Customized audit greatly reduces the number of generated audit logs, ensuring audit behaviors and reducing the impact on system performance. In addition, customized audit policies can improve the audit efficiency of administrators.

Description

The unified audit mechanism customizes audit behaviors based on resource labels and classifies the supported audit behaviors into the ACCESS and PRIVILEGES classes. The SQL syntax for creating a complete audit policy is as follows:

CREATE RESOURCE LABEL auditlabel add table(table_for_audit1, table_for_audit2);
CREATE AUDIT POLICY audit_select_policy ACCESS SELECT ON LABEL(auditlabel) FILTER ON ROLES(usera);
CREATE AUDIT POLICY audit_admin_policy PRIVILEGES ALTER, DROP ON LABEL(auditlabel) FILTER ON IP(local);

auditlabel indicates the resource label in the current audit, which contains two table objects. audit_select_policy defines the audit policy for user usera to audit the SELECT operation on the objects with the auditlabel label, regardless of the access source. audit_admin_policy defines a local audit policy for ALTER and DROP operations on the objects with the auditlabel label, regardless of the user. If ACCESS and PRIVILEGES are not specified, all DDL and DML operations on objects with a resource label are audited. If no audit objects are specified, operations on all objects are audited. The addition, deletion, and modification of unified audit policies are also recorded in unified audit logs.

Currently, unified audit supports the following audit behaviors:

Enhancements

None.

Constraints

• The unified audit policy must be created by a user with the POLADMIN or SYSADMIN attribute, or by the initial user. Common users do not have the permission to access the security policy system catalog and system view.

• The syntax of a unified audit policy applies to either DDL or DML operations. DDL operations and DML operations are mutually exclusive in an audit policy. A maximum of 98 unified audit policies can be configured.

• Unified audit monitors the SQL statements executed by users on the clients, but does not record the internal SQL statements of databases.

• In the same audit policy, the same resource tag can be bound to different audit behaviors, and the same behavior can be bound to different resource tags. The ALL operation type includes all operations supported by DDL or DML.

• A resource label can be associated with different unified audit policies. Unified audit outputs audit information in sequence based on the policies matched by SQL statements.

• Audit logs of unified audit policies are recorded separately. Currently, no visualized query interfaces are provided. Audit logs depend on the OS service Rsyslog and are archived through the service configuration.

• In cloud service scenarios, logs need to be stored in the OBS. In hybrid cloud scenarios, you can deploy Elasticsearch to collect logs and perform visualized processing.

• It is recommended that APP in FILTER be set to applications in the same trusted domain. Since a client may be forged, a security mechanism must be formed on the client when APP is used to reduce misuse risks. Generally, you are not advised to set APP. If it is set, pay attention to the risk of client spoofing.

• Taking an IPv4 address as an example, the following formats are supported:

  IP Address Format	Example
  Single IP address	127.0.0.1
  IP address with mask	127.0.0.1|255.255.255.0
  CIDR IP address	127.0.0.1⁄24
  IP address segment	127.0.0.1-127.0.0.5

Dependencies

In the public cloud service scenario, the OSS or OBS is required for log storage.