The security audit (new version) feature enables all built-in database audit rules and anomaly detection models by default. You can disable any rules or models you do not need. This feature also lets you create custom detection models based on dimensions such as databases, tables, fields, access sources, and instances for more flexible security policies.
Prerequisites
Before you begin, ensure that you have:
The new version of the security audit feature enabled. For more information, see Enable security audit (new version)
Manage database audit rules
DAS enables all built-in database audit rules by default. You can disable any of these rules that you do not need.
Log on to the DAS console.
In the left-side navigation pane, click Security Center > Security Audit.
On the Security Audit page, click Alert rules > Database audit rules.
Disable the rules that you do not need.
Manage custom audit rules
If the built-in audit rules do not meet your security requirements, you can create custom audit rules to define specific database behaviors to monitor and the corresponding alert conditions.
Procedure
Log on to the DAS console.
In the left-side navigation pane, click Security Center > Security Audit.
On the Security Audit page, click the Alert rules > Custom audit rules tab.
On the tab, click Add Rule to open the Add Rule dialog box.
In the dialog box, configure the audit rule based on your business requirements.
Notes
When you configure a custom rule, ensure that the conditions are logically consistent. The following examples describe common condition conflicts to help you avoid configuring invalid rules.
Scenario 1: Asset scope conflict
Guideline: When you configure asset conditions in the Asset section, Instance name, Database name, and Table name must have a clear hierarchical relationship.
Incorrect example: In the asset scope, Instance name is set to
Instance-A, but Database name is set toDB-B, which does not belong toInstance-A.Reason: Because
DB-Bis not part ofInstance-A, the rule has an invalid monitoring scope and will never be triggered.
Scenario 2: Behavior and operation type conflict
Guideline: When you configure behavior conditions in the Behavior section, the SQL content must match its corresponding Operation type.
Incorrect example: You set SQL content to
login failed!and Operation type toSelect.Reason: The
login failed!message is generated only by theLoginoperation, not theSelectoperation. Therefore, these conditions conflict and the rule will never trigger.
Scenario 3: Behavior and execution result conflict
Guideline: A behavior condition must match its possible execution results.
Incorrect example 1:
Behavior: In the Behavior section, you set SQL content to be equal to
login failed!.Result: In the Result section, you set Affected rows to be greater than
10.Reason: A failed login does not perform data operations, so the number of affected rows is always 0. Therefore, this condition will never be met.
Incorrect example 2:
Behavior: In the Behavior section, you set SQL content to be equal to
login failed!.Result: In the Result section, you set Execution status to be equal to
Success.Reason:
login failed!indicates a login failure, which directly conflicts with the Success status.
Configuration tips
When the operator is Equals, you can select only one target object.
When the operator is Belongs to, you can enter multiple target objects. Press the Enter key to separate the objects.
Manage anomaly detection models
DAS enables all built-in anomaly detection models by default. You can disable any models you do not need.
Log on to the DAS console.
In the left-side navigation pane, click Security Center > Security Audit.
On the Security Audit page, click Alert rules > Anomaly detection models.
Disable the models that you do not need.
Custom detection models
If the built-in detection models do not meet your anomaly detection requirements, you can create a custom detection model.
Log on to the DAS console.
In the left-side navigation pane, click Security Center > Security Audit.
On the Security Audit page, click Alert rules > Custom detection models.
Click Add Rule.
In the Add Rule dialog box, configure the parameters for the custom model and click OK.
Parameter
Description
Rule name
Enter a name for the model. A descriptive name makes the model easier to identify.
Risk level
Select a risk level for the model from the drop-down list.
Asset type
Select the asset type for the model to monitor. Select RDS.
Filter conditions
Configure filter conditions to specify the anomaly events to detect.
Add More
Click Add More to add multiple filter conditions. These conditions are combined using the AND logical operator.
Alert condition
Set the time unit for detection and the alert condition. DAS checks data that matches the filter conditions and, if the alert condition is met within the specified time period, generates an anomaly alert.
After you create a model, you can view it in the model list and edit it if necessary. The default status of a newly created model is Disabled. The model must be enabled to take effect.
In the status column, turn on the switch to enable the model.