Configure and troubleshoot DAS security audit alert rules - Database Autonomy Service

Prerequisites

The security audit (new version) feature is enabled. For more information, see Enable security audit (new version).
You have identified the target instance, database account, source IP, and operation type that you want to monitor.

Note
Before you create a rule, find a target operation in the audit logs and note its instance, database account, table name, and operation type. Rules are matched against the values in the audit logs. Do not guess the operation type based on the SQL text alone.

Manage database audit rules

DAS enables all built-in database audit rules by default. You can disable any you don't 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.
Find the target rule and adjust its status as needed.

Custom audit rules

When built-in rules do not cover the behavior that you want to monitor, you can create a custom audit rule. For example, you can monitor the Update operations that a specific database account performs on a specified table.

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 Audit Rules.
Click Add Rule.
Configure the required Rule Name, Rule Type, Risk Level, and Asset Type parameters. Then set conditions such as the instance, database, table, database account, SQL content, operation type, and execution result as needed.
Click Submit, and then return to the list to verify the rule content and its enabled status.

Match modes and input requirements

When you configure a custom audit rule, select a match mode as described in the following table.

Field	Match mode	Input requirements
SQL content	Contains	Enter a single distinctive keyword. Do not use Equals or In to match an SQL fragment.
Database name, table name, or operation type	Equals or In	Match by the full name or operation type. Do not use Contains.

Equals: The field value is exactly the same as the single configured value. You can configure only one value. For example, the operation type equals Update.
In (standard option): The field value is exactly the same as any one of the specified values. You can configure multiple values. For example, if the operation type belongs to Update or Delete, either operation matches.
Contains: The field value contains the specified contiguous text. For example, the SQL content contains demo_orders.

When you select In and enter values manually, press Enter after each value and confirm that each value forms a separate entry. If drop-down candidates are available, select each value from the list.

When you configure SQL content, use a single keyword without spaces. Avoid pasting an entire SQL statement or a fragment that contains quotation marks, backslashes, or other symbols. This reduces match failures caused by formatting or escaping differences. To limit the scope to a database or table, configure the database name or table name instead. This prevents an SQL keyword from incorrectly matching a similar name.

How multiple conditions are combined

The conditions configured on different fields must all be satisfied (an AND relationship). When you select In for a single field and configure multiple values, satisfying any one of the values is enough.

The instance, database, and table must belong to the same target asset. For example, if you select instance A, a database or table that belongs only to instance B does not match. If the operation type is set to equal Select, Login logs do not match. If the number of affected rows is set to greater than 10, records with 0 affected rows do not match. If the execution result is set to equal success, failed records do not match.

Configuration example: monitor the Update operations of a specified account

Suppose that you want to monitor the update operations that the demo_app account performs on the demo_db.demo_orders table of an RDS instance. First, confirm the instance, database, table, account, and operation type in the audit logs. Then, create a rule as described in the following table. The names in the table are examples. Configure the rule based on the values in your target logs.

Parameter	Example value
Rule Name (required)	`demo-orders-update`
Rule Type (required)	Other. This is only an example. Select a type based on your business needs.
Risk Level (required)	Medium. Adjust the level based on your business risk.
Asset Type (required)	RDS
Instance name	Select the instance that generates the target audit logs.
Database name and table name	Set them to Equals `demo_db` and Equals `demo_orders`, respectively.
Accessor (database account)	Equals `demo_app`.
Operation type	Equals `Update`

Update is a standalone option. You do not need to select Merge. After you submit the rule, verify that it is enabled, and then check it against newly generated audit logs. Each field of the target operation must satisfy all the preceding conditions. Operations that the same account performs on other tables, or Select operations that it performs on this table, must not match this rule. Whether an alert is generated also depends on the rule status, the whitelist, and the actual audit logs.

Manage anomaly detection models

DAS enables all built-in anomaly detection models by default. You can disable any you don't 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 Model.
Find the target model and adjust its status as needed.

FAQ

Why does my SQL content not match even though I entered a complete statement?

For SQL content, select Contains and enter a single distinctive keyword, preferably without spaces. Avoid pasting an entire SQL statement or a fragment that contains quotation marks, backslashes, or other symbols. The format or escaped form of a complete SQL statement may differ from the content in the audit logs, which causes match failures. Do not use Equals or In to match an SQL fragment. Verify the keyword against the target audit logs. To limit the scope to a database or table, configure the database name or table name instead.

How long does it take for a rule change to take effect?

Typically, a rule takes about 1 minute to synchronize. After an operation that matches the rule occurs, the alert may take about 10 more minutes to appear.

The preceding times are for troubleshooting reference only. The actual duration is affected by the collection and processing of audit data. If an expected alert does not appear about 20 minutes after a target operation that is newly generated after the rule takes effect, check it against the answer to the next question. After you confirm that both the configuration and the target logs are correct, submit a ticket for technical support.

Why do I not see an alert or receive a notification after configuring a rule?

First, confirm in SQL Explorer and Audit that the target logs are generated after the rule takes effect. Then verify that the rule or model is enabled, that the conditions match the logs, and that the behavior is not on the whitelist. Alerts generated by custom audit rules are viewed in audit alerts. If an alert record exists but you did not receive a notification, check the notification channel. If you still cannot locate the issue, submit a ticket in the DAS console for technical support.

How do I contact you after confirming that the configuration is correct?

Submit a ticket through the DAS console. Provide the instance, region, and event time, along with the desensitized rule configuration, target logs, and related alert information to facilitate troubleshooting.