Best practices for data security

Multi-zone deployment

In multi-zone deployment, the physical hosts of your primary and secondary instances reside in different zones within the same region. Network latency between zones in the same region is less than 3 ms. If one zone fails, your workload automatically switches to another zone — no changes to your application code are needed.

Select the multi-zone deployment method when you create an RDS instance. For more information, see Create an ApsaraDB RDS for MySQL instance.

If you already use single-zone deployment, migrate your instance to multiple zones (available only when your region supports multiple zones). For more information, see Migrate an ApsaraDB RDS for MySQL instance across zones in the same region.

Cross-region disaster recovery

ApsaraDB RDS uses Data Transmission Service (DTS) to synchronize data in real time between a primary RDS instance and a disaster recovery RDS instance in a different region. Both instances run on a primary/secondary high-availability architecture. If both the primary and secondary instances in the original region become inaccessible — for example, due to a natural disaster — switch your workload to the disaster recovery instance and update your application endpoint to minimize downtime.

For more information, see Create a disaster recovery ApsaraDB RDS for MySQL instance.

Cross-region backups

Cross-region backups automatically replicate your RDS instance backup files to an Object Storage Service (OSS) bucket in a different region. These backup files can be used for monitoring and disaster recovery. The backup files are independent of the instance: if the instance is released, the cross-region backup files are retained for the retention period you specify.

For more information, see Use the cross-region backup feature.

RAM user authorization

Resource Access Management (RAM) lets you create RAM users and control each user's permissions on your Alibaba Cloud resources. When multiple people in your organization need database access, assign each person a dedicated RAM user and follow the principle of least privilege (PoLP) — grant only the permissions each user needs. This avoids shared credentials and limits the blast radius of a compromised account.

For more information, see Use RAM for resource authorization.

Enforce disk encryption at instance creation

Configure a RAM policy to block RAM users from creating RDS instances without disk encryption enabled. This makes sure all new instances meet your encryption baseline before they go live.

For more information, see Use RAM policies to manage the permissions of RAM users on ApsaraDB RDS instances.

Database account authorization

Grant database account permissions at the level your production environment requires:

• Database level: Create an account and assign permissions to specific databases in the ApsaraDB RDS console. For more information, see Create accounts and databases.

• Table level: Execute an SQL statement to grant an account permissions on a specific table, view, or field. For more information, see Authorize accounts to manage tables, views, and fields.

Use a VPC

We recommend that you deploy your RDS instance in a virtual private cloud (VPC). A VPC is an isolated network environment that provides stronger security and better performance than the classic network. Create a VPC before you create an RDS instance in it. For more information, see Default VPCs and default vSwitches.

If your RDS instance is in the classic network, migrate it to a VPC. For more information, see Change the network type of an ApsaraDB RDS for MySQL instance.

Configure an IP address whitelist

After creating an RDS instance, configure an IP address whitelist to explicitly define which clients can connect. Access from any address not on the whitelist is denied.

For more information, see Use a database client or the CLI to connect to an ApsaraDB RDS for MySQL instance.

SQL Explorer

SQL Explorer lets you perform security audits and performance diagnostics on your RDS instance. Use it to audit suspicious queries, trace access patterns, and diagnose performance issues.

For more information, see Use the SQL Explorer feature on an ApsaraDB RDS for MySQL instance.

Log management

Log management gives you access to error logs, slow query log details, slow query log summaries, and primary/secondary switchover logs. Use these logs to troubleshoot instance issues and identify performance bottlenecks.

For more information, see View error logs and slow logs.

Event history

Event history records O&M events on your RDS instance — including instance creation and parameter reconfiguration — performed by both users and Alibaba Cloud. Use it to audit configuration changes and investigate incidents.

For more information, see View the event history of an ApsaraDB RDS instance.

Investigate the source of intrusion

1. On the instance details page in the RDS console, click Autonomy Service > SQL Explorer and Auditing in the left-side navigation pane.

2. Enable DAS Audit Log to view the operator accounts and source IP addresses associated with each SQL statement.

3. Go to Backup and Restore > Log Backup and download the relevant binary log (binlog) files.

4. Use the mysqlbinlog tool to parse the downloaded binlog files and identify abnormal SQL statements.

Contain the attack source

1. On the Whitelist and Security Group page, remove 0.0.0.0/0 from the whitelist to stop allowing unrestricted public access.

2. On the Security Group tab, add a deny rule to block the attacking IP address.

Harden your instance

1. Go to Data Security > SSL and enable SSL encryption.

2. Go to Data Security > Data Encryption and enable transparent data encryption (TDE).

SSL encryption

SSL encryption secures the connection between your application and your RDS instance at the transport layer. Enable SSL and install the SSL CA certificate on your application when connecting over the Internet.

For more information, see Configure the SSL encryption feature.

Transparent Data Encryption

Transparent Data Encryption (TDE) performs real-time I/O encryption and decryption on your data files. Data is encrypted before being written to disk and decrypted when read into memory. Enabling TDE does not increase data file size and requires no changes to your application configuration.

For more information, see Configure TDE.