Security Best Practices

Optimizing Database Connection Configurations to Reduce Network Attack Risks

1. Do not bind an EIP to your RDS for MySQL instance for access over 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 protect it. Do not bind an EIP to your instance for access over the Internet to prevent unauthorized access and DDoS attacks. If you have bound an EIP to your instance, you are advised to 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 port 3306 by default, which is more vulnerable to malicious attacks. Change the port number for your DB instance.

3. Restrict available resources of a database user.

   If the resources available to a database user are not restricted, the system may be overloaded when the user is attacked, causing DoS. Restricting available resources of a database user can prevent excessive resource consumption caused by excessive resource occupation. To prevent service availability from being affected in heavy-load scenarios, you need to configure available resources for a database user based on the service model using the following SQL statements:

   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 name of the user you want to configure resources for.
   • <hostname> indicates the name of the host.
   • <queries_num> indicates the maximum number of queries allowed for the user per hour.
   • <connections_num> indicates the maximum number of connections allowed for the user.
   • <updates_num> indicates the maximum number of updates allowed for the user per hour.
   • <connections_per_hour> indicates the maximum number of connections allowed for the user per hour.
4. Do not use the wildcard % for the host name.

   The host name specifies which host is allowed to connect to your database. The host name corresponds to the host field in the user table. If the host name is set to the wildcard %, the user accepts connections from any IP address, increasing risks of attacks to the database. To minimize the attack risks, you are advised to 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 an RDS for MySQL server consumes memory, and the maximum number of connections supported is limited. If the RDS for MySQL server has a large number of idle connections, too much memory is consumed and the maximum number of connections can be reached. In this case, the error message "too many connections" will be 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 the MySQL client and server is in plaintext, which is vulnerable to eavesdropping, tampering, and man-in-the-middle attacks. To improve data transmission security, you are advised to add the REQUIRE SSL attribute and configure SSL for database users.

   You can use the following SQL statements:

   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, the database system is easy to be the target of attacks. You need to keep your database account and password secure to prevent disclosure. In addition, you are advised to configure the complexity of your password to avoid 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. You are advised to configure a password expiration policy to restrict the time when 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 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 configurations.

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

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

   revoke process on *.* from <your_account>;

   In the preceding command, <your_account> indicates the name of the user 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. By recording, analyzing, and reporting user access to the database, database audit helps generate compliance reports and trace accidents, 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. Configure binlog retention period by referring to Setting a Local Retention Period for RDS for MySQL Binlogs.

Encrypting Data Before Storage

To improve user data security, you are advised to enable server-side encryption. After server-side encryption is enabled, data will be encrypted on the server before being stored when you create a DB instance or scale up storage space, reducing data leakage risks.

Hardening Sensitive Parameters

1. Set local_infile to 0.

   If local_infile is set to 1, the 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. You are advised to set local_infile to 0 by referring to Modifying Parameters of an RDS for MySQL Instance.

2. Set the sql_mode parameter to a value containing 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 a value containing 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).