Security Best Practices

Optimizing Database Connection Configurations to Reduce Network Attack Risks

1. Do not bind an EIP to your RDS for MySQL instance to prohibit unauthorized access and DDoS attacks from the Internet.

   Do not deploy your instance on the Internet or in a demilitarized zone (DMZ). Instead, deploy it on an intranet and use routers or firewalls to control access to your instance. Do not bind an EIP to your instance to prohibit unauthorized access and DDoS attacks from the Internet. If an EIP has been bound to your instance, unbind it. If you do need an EIP, configure security group rules to restrict the source IP addresses that can access your instance.

2. Do not use the default port number.

   RDS for MySQL instances use the default port 3306, leaving your instance more vulnerable to malicious attacks. To avoid this risk, change the port number for your DB instance.

3. Restrict operations of a database user.

   If there is no limit for the resources that a database user can use, the system may be overloaded when the user is attacked, causing a denial of service (DoS) on the system. Setting limitations can prevent excessive resource consumption due to over-utilization of resources. To prevent service availability from being affected in heavy-load scenarios, use the following SQL statements to restrict the number of operations that an individual database user can perform based on your service model:

   alter user  '<user>'@'<hostname>' with max_queries_per_hour <queries_num>;
   alter user  '<user>'@'<hostname>' with max_user_connections <connections_num>;
   alter user  '<user>'@'<hostname>' with max_updates_per_hour <updates_num>;
   alter user  '<user>'@'<hostname>' with max_connections_per_hour <connections_per_hour>;

   • <user> indicates the username of the account you want to set the limits for.
   • <hostname> indicates the host name of the account.
   • <queries_num> indicates the maximum number of queries allowed for the account per hour.
   • <connections_num> indicates the maximum number of concurrent connections allowed for the account.
   • <updates_num> indicates the maximum number of updates that the account can issue per hour.
   • <connections_per_hour> indicates the maximum number of times the account can connect to the database server per hour.
4. Do not use the wildcard % for the host name.

   A host name specifies which host is allowed to connect to your database. You can use the host field in the user table to specify the host. If you enter a wildcard % as the host name, your database is accessible to any IP address, increasing the risk of attacks. To minimize the attack risk, set the host IP address to a specific network segment or IP address.

5. Limit the waiting time of idle database connections.

   Each connection to the MySQL server consumes memory, and the maximum number of connections supported is limited. If the MySQL server has a large number of idle connections, memory consumed by these connections is wasted and the maximum number of connections can be reached. Once the limit is reached, an error message "too many connections" is reported if a new connection is established. You need to set the waiting time for idle connections to ensure that idle connections are cleared in time. Change the values of wait_timeout and interactive_timeout by referring to Modifying Parameters of an RDS for MySQL Instance.

6. Ensure that SSL is enabled by default.

   If SSL is not configured, data transmitted between a MySQL client and server is in plaintext, which is vulnerable to eavesdropping, tampering, and man-in-the-middle attacks. To improve data transmission security, specify the REQUIRE SSL attribute for a database account and configure SSL.

   You can use the following SQL statements to require SSL connections for a specific account:

   create user '<user>'@'<hostname>' REQUIRE SSL;
   alter user '<user>'@'<hostname>' REQUIRE SSL;

Properly Managing Database Accounts and Passwords to Reduce Data Leakage Risks

1. Periodically change the password of the administrator.

   The default database administrator account root has high permissions. You are advised to periodically change the password of user root by referring to Resetting the Administrator Password to Restore Root Access.

2. Configure password complexity.

   As a collector of information, a database system is easy to be the target of attacks. You need to keep your database account and password secure. In addition, configure the complexity of your password to avoid using weak passwords. For details, see "Setting Password Complexity" in Database Account Security.

3. Configure a password expiration policy.

   Using the same password too long makes it easier for hackers to crack or guess your password. To prevent this, configure a password expiration policy to limit how long a password can be used.

Strengthening Permissions Management to Reduce Related Risks

1. Do not create stored procedures or functions as the administrator.

   Stored procedures and functions are run as creators by default. If you create stored procedures and functions as the administrator, regular users can run them through privilege escalation, so do not use the administrator account to create stored procedures or functions.

2. Review and harden permission configurations.

   Check whether the following permission configurations meet security requirements. If they do not meet security requirements, harden the security configuration.

   • Ensure that only the administrator account can perform operations on the mysql.user table.
   • Ensure that the Process_priv permission can be granted only to the administrator account.
   • Ensure that the Create_user_priv permission can be granted only to the administrator account.
   • Ensure that the Grant_priv permission can be granted only to the administrator account.
   • Ensure that the Reload_priv permission can be granted only to the administrator account.
   • Ensure that the replication account has only the replication slave permission.
   • Ensure that the database metric monitoring account has only the replication client permission.

   Example: If a non-administrator account has the Process permission, run the following SQL statement to revoke this permission:

   revoke process on *.* from <your_account>;

   In the preceding statement, <your_account> indicates the username of the account whose Process permission needs to be revoked.

Enabling Database Audit for Post-Event Backtracking

The database audit function records all user operations on the database in real time. This function logs, analyzes, and reports user activities in the database. Based on the audit logs, you can prepare compliance reports and track incidents, improving data asset security. For details, see Enabling SQL Audit.

Configuring Data Backup to Ensure Data Reliability

1. Enable data backup.

   RDS for MySQL supports automated and manual backups. You can periodically back up databases. If a database is faulty or data is damaged, you can restore the database using backups to ensure data reliability. For details, see Data Backups.

2. Configure a binlog clearing policy.

   Binlogs continuously increase as services run. You need to configure a clearing policy to prevent disk expansion. Set a retention period for RDS for MySQL binlogs.

Encrypting Data Before Being Stored

To improve data security, enable server-side encryption. After it is enabled, data will be encrypted on the server before being stored when you create a DB instance or scale up storage space. This reduces the risk of data leakage.

Hardening Parameter Configuration to Prevent Data Leakage

1. Set local_infile to ON.

   If local_infile is set to ON, a database client can use the load data local syntax to load local files to database tables. For example, when a web server functions as a database client to connect to a database, if the web server has an SQL injection vulnerability, an attacker can use the load data local command to load sensitive files on the web server to the database, causing information leakage. To prevent this, set local_infile to ON by referring to Modifying Parameters of an RDS for MySQL Instance.

2. Set sql_mode to STRICT_ALL_TABLES.

   When attempting to launch an attack, an attacker may enter various parameters in a trial-and-error manner. If the server adapts to incorrect statements, database data may be leaked. Therefore, STRICT_ALL_TABLES is recommended. Even if an error occurs in other rows than the first row, the statement will be discarded once an invalid data value is found. This method maximally ensures that database information is not disclosed. You are advised to set sql_mode to STRICT_ALL_TABLES by referring to Modifying Parameters of an RDS for MySQL Instance.

Using the Latest Database Version for Better Experience and Security

The MySQL community irregularly discloses newly discovered vulnerabilities. RDS for MySQL evaluates the actual risks of database kernel versions and release new database kernel versions accordingly. To improve the usability and security of the database system, you are advised to use the latest database version.

Using Other Cloud Services for Additional Data Security

To obtain extended data security capabilities, you are advised to use Database Security Service (DBSS).