ApsaraDB RDS secures your data through two independent control layers: account-based access control (who can query or modify data after connecting) and network-based access control (which hosts are allowed to connect at all). Configure both layers to protect your instance.
Account-based access control
ApsaraDB RDS supports two account types. Choose based on the level of permission granularity your application requires.
| Account type | Permission granularity | Typical use |
|---|---|---|
| Standard account | Database level — read-only, read/write, DDL-only, or DML-only | Most applications |
| Privileged account | Table, view, and field level | Fine-grained access control across multiple teams or tenants |
Standard accounts are created through the ApsaraDB RDS console or API. Grant each account database-level permissions (read-only, read/write, DDL-only, or DML-only) on specific databases.
Privileged accounts, also created through the console or API, can log on to your instance and create standard accounts that are authorized to manage specific databases. Use a privileged account when you need to grant permissions at the table, view, or field level. A privileged account can grant fine-grained permissions to standard accounts.
Whitelist-based access control
The default IP address whitelist contains only 127.0.0.1, which means the instance denies connections from all IP addresses over the Internet or an internal network. Add the IP addresses or CIDR blocks of your application servers to the whitelist before your application can connect.
Configure the whitelist on the Data Security page of the ApsaraDB RDS console, or use the ApsaraDB RDS API. After you update a whitelist, you do not need to restart your RDS instance — this avoids interruptions to your workloads.