Configuring Database Audit Instance Rules

Scenario 1: Detecting Abnormal Access to Important Tables

Example: An e-commerce website has multiple microservices in the backend, including order management, user management, and offering search. These services are deployed on different nodes and have different IP addresses, as shown in Figure 1.

Figure 1 Service deployment

The green arrows indicate the access paths. If the order management service or product search service node is attacked, the attacker will access the user information tables from the intruded node. Such access is abnormal.

DBSS allows you to set the following rule to detect abnormal database access.

Figure 2 Adding abnormal database access

The rule shown in Figure 2 indicates that all requests sent from 192.168.1.1 or 192.168.3.3 to the user_info table are regarded highly risky.

After this rule is set, all abnormal access to the high-risk table will be audited, and risk alarms will be triggered.

Click Add Object, enter the target database and target table, and click OK.

Figure 3 Adding a target table

Scenario 2: Optimizing SQL Statements

Example: An application responds slowly when users perform some operations. It is found that latency occurs when the application accesses the database. However, the statements that cause the latency cannot be identified.

In this case, you can use the database slow SQL detection function of DBSS to locate the fault and optimize the performance.

Perform the following steps:

1. Log in to the DBSS console and choose the Risky Operation tab.
   Figure 4 Accessing the Risky Operations tab page
   

2. Locate Database_Slow_SQL_Detection and click Edit in the Operation column. In the Results dialog box that is displayed, set Operation Duration to Greater than 1000 ms.
   Figure 5 Setting the operation duration
   

3. Click OK.
4. After the configuration is complete, wait for a while and search for the slow SQL detection rule by its name. For example, enter SQL in the Rule Name search box on the Statements tab page.
   Figure 6 Slow SQL detection results
   
   

   • You can analyze the search result and optimize the SQL statements.
   • You can gradually decrease the value of Operation Duration and perform multiple rounds of optimization.

Scenario 3: Adding a Whitelist to Reduce False Positive SQL Injection Alarms

In daily enterprise operations, database security is paramount. However, frequent false alarms place a heavy burden on O&M teams. When you configure database audit instance rules to prevent SQL injection risks, prioritize alarm policy optimization to minimize false positives. High false-positive rates not only inflate workloads but can also mask genuine security threats, causing critical risks to be overlooked.

1. SQL injection characteristics

   Identify and define typical SQL injection patterns. Configure accurate audit rules based on SQL syntax structure, risk keywords, or other characteristics to reduce false alarm generation.

2. Whitelist mechanism

   Risky operation rules take precedence over SQL injection rules. You can configure secure SQL statements as trusted statements or add them to a whitelist to reduce false alarm generation. Additionally, establish a mechanism to update the whitelist promptly as services change.

3. Regular audit and rule optimization

   You can analyze historical alarms, identify the statements that cause false alarms, and adjust audit policies to improve the accuracy and effectiveness of alarms.

The following example describes how to set secure SQL statements as trusted statements.

Example: Some legitimate statements generated by programs may match SQL injection rules and trigger false positives. The statement shown in Figure 7 is a SELECT statement used to access the TABLES table in the information_schema database. To avoid repeated alarms for this statement, you can set it as trusted.

Figure 7 False positive SQL injection alarm