Security Best Practices

1. Avoid binding EIPs to RDS for MySQL instances for direct Internet access.

   Deploy RDS for MySQL instances inside your internal network, not on the Internet or in a demilitarized zone (DMZ). Secure them with routers or firewalls instead of using EIPs for direct Internet access. This approach helps prevent unauthorized access and DDoS attacks. 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. Avoid using the default port number.

   RDS for MySQL uses port 3306 by default. This port is more likely to be targeted by malicious attacks. To avoid this risk, change the port for your instance.

3. Limit the resources available to database users.

   If database user resources are not restricted, the system may become overloaded during an attack, potentially resulting in a denial-of-service (DoS) condition. By setting limits, you can prevent excessive resource consumption caused by overuse. To avoid impacting workload availability under heavy load, set appropriate limits based on your application model.

   Use 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 username of the account you want to set the limits for.
   • <hostname> indicates the host of the account you want to set the limits for.
   • <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. Avoid using the wildcard % for the hostname.

   hostname specifies the host from which the user is allowed to connect to the DB server. It corresponds to the host column of the mysql.user table. If the hostname is set to the wildcard %, your DB instance is accessible to any IP address, which increases the risk of attacks. To minimize the risk, set the host IP address to a CIDR block or specific IP addresses.

5. Set a timeout for idle connections.

   Each connection to the MySQL server consumes memory, and there is a limit on how many connections are allowed. If the MySQL server maintains many idle connections, they waste memory and may cause the server to hit this limit. Once the limit is reached, any new connection attempt will fail with the "too many connections" error message. To prevent this, set a timeout for idle connections so they can be terminated in a timely manner. Adjust the settings of wait_timeout and interactive_timeout by referring to Modifying Instance Parameters. Set them depending on your workload requirements.

6. Ensure that SSL is enabled by default.

   If SSL encryption is not configured, data transmitted between a MySQL client and server is vulnerable to eavesdropping, tampering, and man-in-the-middle attacks. To enhance the security of data in transit, add the REQUIRE SSL attribute to database accounts and configure SSL for them.

   Use the following SQL statements:

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

1. Regularly update the administrator password.

   The default database administrator account, root, has high privileges. You are advised to change the root password regularly 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. Therefore, keep your database account and password secure and enforce password complexity. 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.

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. Check and harden the permission configuration.

   Check whether the following security requirements are met. If not, harden the configuration.

   • Only the administrator account can perform operations on the mysql.user table.
   • The Process_priv privilege can be granted only to administrator accounts.
   • The Create_user_priv privilege can be granted only to administrator accounts.
   • The Grant_priv privilege can be granted only to administrator accounts.
   • The Reload_priv privilege can be granted only to administrator accounts.
   • Replication accounts only have the replication slave privilege.
   • Database metric monitoring accounts only have the replication client privilege.

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

   revoke process on *.* from <your_account>;

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

Database audit logs record all user operations on DB instances in real time. They can be used to analyze user behavior, generate compliance reports, and trace the root cause of an incident. For details, see Enabling SQL Audit.

1. Enable data backups.

   RDS for MySQL supports automated and manual backups. You can periodically back up your instance. If it fails or data becomes corrupted, you can restore it from backups to ensure data availability. For details, see Data Backups.

2. Configure a binlog cleanup policy.

   The binlog grows continuously as your workload runs, so you need to configure a log cleanup policy to prevent excessive disk usage. Set a retention period for binlogs.

To enhance data security, enable server-side encryption. Once enabled, when you create an instance or scale up storage, data will be encrypted into ciphertext on the server before being stored. This reduces the risk of data leakage.

1. Set local_infile to OFF.

   If local_infile is set to ON, database clients are allowed to use LOAD DATA LOCAL to load data from their local files into database tables. For example, if a web server connects to a database as a database client and has an SQL injection vulnerability, it may allow attackers to craft a LOAD DATA LOCAL command. This command can make the database read files from the web server's local filesystem, potentially exposing sensitive data and leading to information leaks. To prevent this, set local_infile to OFF by referring to Modifying Instance Parameters.

2. Set sql_mode to include the value 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 deprecated once an invalid data value is found. This method offers robust protection against database information disclosure. Set sql_mode to include the value STRICT_ALL_TABLES by referring to Modifying Instance Parameters.

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 your database system, use the latest database version.

To obtain extended data security capabilities, use Database Security Service (DBSS).

RDS for MySQL supports high availability across AZs. When you create a DB instance, you can select the primary/standby instance type and place the primary and standby instances in different AZs. This deployment provides the cross-AZ failover capability and improves overall availability.

The RDS console provides critical operation protection. Once the function is enabled, the system verifies your identity before you perform critical operations (for example, deleting an instance) to better protect your data and configurations. To enable this function, enable Multi-Factor Authentication (MFA) on the Identity and Access Management (IAM) console. For details, see Critical Operation Protection.

RDS for MySQL allows you to use existing automated backups to restore DB instances to a specific point in time. The system downloads the most recent full backup before the specified time from OBS to the target DB instance for full restoration and then replays incremental backups to that time. PITR enhances RDS's ability to securely respond to data loss or corruption. For details, see PITR: Restoring a DB Instance to a Point in Time.

You are advised to enable disk encryption to improve data security. For details, see the description about disk encryption in Buying an RDS for MySQL DB Instance.

RDS for MySQL can upload error logs, slow query logs, and audit logs to Log Tank Service (LTS) and allows you to configure log retention periods according to compliance requirements. Once this function is configured, note the following points:

• New logs generated by DB instances will be uploaded to LTS for management.

• There is a delay of approximately 10 minutes before the function takes effect.
• You will be billed for using LTS. For details, see LTS Pricing Details.
• If you have configured audit log injection to LTS, all audit policies are uploaded by default.
• If audit logging is already enabled for your instance, LTS will reuse this audit policy. You will be billed for both audit logging and the ingestion of audit logs to LTS. (To stop billing for audit logging, disable this function.)
• If audit logging is already enabled for your instance when you configure audit log ingestion to LTS, keep audit logging enabled until you confirm that the audit log ingestion works well. This ensures that your instance runs properly.

For more information, see Log Reporting.