Manage whitelists - Database Autonomy Service - Alibaba Cloud Documentation Center

Security Audit (new version) whitelists suppress alerts generated by confirmed normal database activity. Narrow the scope by asset, account, source IP address, and operation type so that you do not suppress alerts for activity that requires detection. This topic explains how to add, edit, and delete whitelists, and uses the Update operation of a specified account as an example to describe the configuration method.

Prerequisites

Security Audit (new version) is enabled. For more information, see Enable security audit (new version).
You have confirmed the behavior to exclude through a whitelist and its business purpose, and identified the target instance, account, or source IP address, and the operation type to exclude.

Overview

Behavior that matches a whitelist no longer generates alerts within the covered scope. You can still query the raw logs in SQL Explorer and Audit, provided that the related log feature is enabled and the event is within the log retention period.
After you add, edit, or delete a whitelist, the configuration takes effect within 1 minute. It takes additional time for the effect to be reflected in the alert display. When you review alert results, consider the event time and the log-processing status.
You can view and manage, in the whitelist list, the whitelists that you added when handling alerts.

Operation types

You can specify the operation types to exclude in a whitelist. This topic lists only the common or easily confused types. For the meanings of other SQL statements, refer to the official documentation of your database. When you configure a whitelist, use the actual types recorded in the audit logs of the target instance.

Category	Operation types and meanings
Data read and write	Select: queries data. Insert: inserts data. Update: updates existing data. To configure a whitelist for an ordinary UPDATE operation, select this type. Delete: deletes data rows.
Object changes	Create: creates an object. Alter: changes an object definition, such as a table schema. Drop: deletes an object. Truncate: clears table data.
Connection events	Login: authenticates a database login or connection. Logout: exits or disconnects a database connection. Note Login and Logout are connection events, not SQL statements.
Data merge	Merge: conditionally merges data and is independent of Update.

Add a whitelist

To exclude alerts generated by confirmed normal database activity, you can add a whitelist for the corresponding account, IP address, or CIDR block based on the business scope.

Log on to the DAS console.
In the left-side navigation pane, click Security Center > Security Audit, and confirm the target region.
On the Security Audit page, go to System Settings > Whitelist.
On the Whitelist tab, click Add Entry.

In the Add Entry dialog box, configure the whitelist for the behavior that you want to exclude. Whitelist Name and Asset Type are required. The other parameters are optional and are used to narrow the whitelist scope. The following table describes some key parameters.

Parameter	Configuration guidance
Whitelist Name (required)	Enter a name that clearly identifies the purpose, such as `demo-app-update`.
Asset Type (required)	Select the actual asset type of the target database.
Instance Name	Select the target instance to prevent the whitelist from applying to other instances.
Database / Table Name	To further limit the object scope, select the corresponding database or table.
IP/Account	Limit the account or access source to the business scope.
Action Type	Select only the types to exclude. You can select multiple types when the whitelist must match multiple operations.

Review the other conditions and the full configuration scope on the page, and then click OK.
View the new configuration in the whitelist list, and verify the saved Instance Name, Account, source, and Action Type.

You can add a whitelist for an account, an IP address, a CIDR block, an account and an IP address, or an account and a CIDR block.

Example: Configure a whitelist for the Update operation of a specified account

Assume that the demo_app account updating demo_db.demo_orders on the target instance is confirmed as normal business activity, and that you want to exclude only the alerts generated by this activity. In the following table, "required" refers to the fields marked as required on the page. Instance Name, Database, Table, Account, and Update are the conditions selected to narrow the scope in this example.

Parameter	Example value
Whitelist Name (required)	`demo-app-update`
Asset Type (required)	Select the actual asset type of the target database.
Instance Name	Select the target instance.
Database / Table Name	`demo_db`, `demo_orders`
Account	`demo_app`
Action Type	Update

If the business also requires limiting the source IP address, configure the corresponding IP. Open the Action Type drop-down list, scroll down, and select Update. After you save the whitelist, check the actual configuration to make sure that Update is selected and that other types such as Merge are not selected by mistake. Each condition that you add must correspond to the same business activity that you want to exclude.

Verify the whitelist configuration

In a test environment or an approved business validation, check the behavior that you want to exclude and the behavior that should remain detectable:

Confirm that the raw audit logs contain the target Update event, and that its Instance Name, Account, source, and actual operation type match the configuration.
After the configuration takes effect, confirm that the event no longer generates alerts within the scope of the whitelist.
Check another account or an operation that is not in the whitelist. If it meets the trigger conditions of an enabled alert rule, it should still generate an alert.

Note

Seeing no alert alone does not confirm that the whitelist took effect. Also rule out cases such as logs not being collected, rules not being enabled, or the behavior not originally meeting the alert conditions.

Edit or delete a whitelist

Log on to the DAS console.
In the left-side navigation pane, click Security Center > Security Audit.
On the Security Audit page, go to System Settings > Whitelist.
In the Actions column of the target whitelist, click Edit or Delete, and complete the modification or deletion as prompted. After the change takes effect, re-check the scope of the behavior that you want to exclude. After you delete a whitelist, whether the related behavior generates alerts still depends on the enabled alert rules and detection conditions.

FAQ

What is the difference between Alter and Update?

Alter is commonly used to change an object definition, such as a table schema. Update is used to change records in a table. Select the type based on how the target operation is recorded in the audit logs.

How do I handle an operation that matches both an alert rule and a whitelist?

A custom alert rule detects target behavior and generates alerts, whereas a whitelist suppresses alerts within its covered scope. If both cover the same Update behavior, a configuration conflict occurs. If you want to receive alerts for that behavior, check and narrow or remove the whitelist that covers it, and then verify the result against the audit logs and alert records.

How do I troubleshoot alerts that remain after I add a whitelist?

Check whether the behavior corresponding to the alert occurred after the configuration took effect.
Compare the Instance Name, Database, Table Name, Account, IP, and Action Type item by item against the raw logs to make sure that no condition mismatches.
Check whether the alert is within the scope of the whitelist, and whether the configuration was edited or deleted.
If you still cannot locate the cause, go to Ticket in the upper-right corner of the DAS console and submit a ticket. Specify the instance, region, and event time, and attach the desensitized whitelist configuration, raw logs, and the corresponding alert information.