PolarDB:Overview

Background information

When your database is illegally accessed, attackers may obtain all data in the database. Even in routine O&M operations, if you execute a DELETE statement that does not contain WHERE clauses, a table in the database may be accidentally deleted.

To prevent such high-risk operations, PolarProxy provides the SQL firewall feature, which enables you to configure blacklist and whitelist rules to allow and block SQL statements. The following figure shows how the SQL firewall feature works.

Prerequisites

PolarDB PolarProxy is V2.5.1 or later. For more information about how to view the current version of and upgrade PolarProxy, see Minor version update.

Limits

• After the SQL firewall feature is enabled, PolarProxy creates a database named database:proxy_auditing and two tables named sql_list and org_sql_list in the current cluster. The sql_list table stores parameterized SQL statements in blacklist and whitelist rules, and the org_sql_list table saves SQL statements in blacklist rules. Each table can save up to 500,000 SQL statements.

• The first time you create a rule, the rule is applicable only to new connections. After the rule is modified, it takes effect on existing connections after five seconds.

• The SQL statements in a blacklist or whitelist rule created in custom parameterized SQL mode or custom SQL mode are not blocked when the rule is created, but are blocked after the rule is created.

• For the same account and endpoint, you cannot enable both a blacklist rule and a whitelist rule.

• Multi-statements are not supported. All multi-statements are blocked.

• SQL statements that cannot be parsed by PolarProxy are recorded in firewall audit logs but are not blocked. For example, if a SELECT statement contains syntax errors, the statement is not be blocked.

• The SQL statements in a blacklist or whitelist rule created in custom parameterized SQL mode or custom SQL mode are retained even if the blacklist or whitelist rule is disabled or deleted. If the blacklist or whitelist rule is enabled again, the rule is still applicable to the same accounts. If you want to completely delete the blacklist or whitelist rule, you can connect to the primary node in the cluster by using the super administrator account and delete the SQL statements.

• Blacklist and whitelist rules can only block common SQL commands (3) or PREPARE commands (22). Other commands are not blocked. For example, after you connect to a cluster by using the MySQL command line, the USE db; statement is converted into a COM_INIT_DB(1) command by the MySQL command line. This command is not blocked.

Impacts on performance

• After you enable the blacklist rule feature, performance overheads of less than 10% are incurred.

• If the whitelist rule feature is enabled and no alert logs are generated, performance overheads of about 10% are incurred.

• If alert logs are generated for all executed SQL statements, the request rate decreases by 20% to 30% in normal business conditions. However, not all SQL statements can trigger alert logs. Only some SQL statements can trigger alert logs. Therefore, in normal business conditions, the blacklist or whitelist rule feature does not have significant impact on the request rate.

Blacklist or whitelist rule feature

• Blacklist rule feature: You can configure a blacklist rule to block specified types of SQL statements or specific SQL statements. When an SQL statement that is added to the blacklist rule is executed, PolarProxy blocks the SQL statement. For more information, see Configure a blacklist rule.

• Whitelist rule feature: Business-related SQL statements are trained before they can be allowed by a whitelist rule. After the protection mode is enabled, only SQL statements that are added to the whitelist rule can be allowed. For more information, see Configure a whitelist rule.