ApsaraDB RDS for MySQL supports three complementary encryption methods—disk encryption, transparent data encryption (TDE), and column encryption—each protecting data at a different layer of the stack. This page explains what each method defends against, its performance cost, and when to use it.
How database encryption works
Encryption does not replace access control. Instead, it limits the damage when access controls fail—for example, when an administrator account is compromised or an attacker copies database files directly from disk.
The three methods protect data at different points in the system:
Disk encryption protects data at the Infrastructure as a Service (IaaS) layer, securing data on the physical disk.
TDE protects data at the Platform as a Service (PaaS) layer, encrypting data before it is written to the file system.
Column encryption (the basic edition of the always-confidential database feature) protects data in transit between the database and the client, ensuring query results are delivered as ciphertext.
The following diagram shows the attack paths that each method addresses.
Attack types and coverage
Eight categories of attack target database systems:
| Attack type | Description | Common methods |
|---|---|---|
| Attack Admins | Compromises system administrators. Database administrators (DBAs) can access data and change configurations. PaaS admins can access OS-level files. IaaS admins can access physical disks. | OS vulnerabilities, account leaks, misconfigured systems |
| Attack Users | Compromises end users with database access, then escalates privileges via SQL injection. | Account leaks, logical data breaches |
| Attack Apps | Exploits application servers exposed to the internet, which have a larger attack surface than the database itself. | Application and OS vulnerabilities |
| Attack Network | Intercepts traffic between the application and the database. Bypass methods make detection difficult. | Network listening and interception |
| Bypass Database | PaaS personnel copy data files or backup files directly from database disks. | Physical data breaches |
| Bypass OS | IaaS personnel copy data directly from local or cloud disks. | Mounting attacks |
| Exploit Database | Exploits code bugs in the database system to access data directly or indirectly. | Database OS vulnerabilities |
| Target Data Copies | Attacks development or test databases, which often mirror production data but lack equivalent security controls. | Any of the above |
Choosing an encryption method
Each method defends against a distinct subset of the attack types above. The table below summarizes key dimensions to help you select the right method—or combination of methods.
| Disk encryption | TDE | Column encryption (basic edition) | |
|---|---|---|---|
| Attack types addressed | Bypass OS, Attack Admins (IaaS) | Bypass Database, Bypass OS, Attack Admins (PaaS and IaaS) | Attack Users, Attack Apps, Attack Admins (DBA [1]), Attack Network, Target Data Copies |
| DBA visibility | Visible | Visible | Invisible |
| PaaS O&M visibility | Visible | Invisible | Visible [1] |
| IaaS O&M visibility | Invisible | Invisible | Visible [1] |
| Encryption granularity | Instance | Table and database | Column |
| Application changes | None | None | Replace JDBC with EncJDBC (no code changes) |
| Typical performance loss | Minimal to none | Less than 5% | Less than 7% |
| Performance loss under heavy load | Minimal | Up to 20% | Up to 21% |
| For more information | ECS disk encryption overview | Configure TDE | Column encryption overview |
[1] The basic edition cannot prevent PaaS or IaaS O&M personnel from accessing plaintext data. To defend against those layers, use the hardware-enhanced edition of the always-confidential database feature together with trusted hardware technology.
How each method works
Disk encryption
Disk encryption operates at the IaaS layer. Enable it when creating Elastic Compute Service (ECS) system or data disks, or add it to data disks after instance creation. Once enabled, the system automatically encrypts all data on the disks hosting the ECS instance—no key management infrastructure required.
Key characteristic: Data is invisible to IaaS O&M personnel (physical process engineers), but DBAs and PaaS administrators can still access plaintext data.
Performance: The impact is minimal and, in many cases, undetectable.
Transparent data encryption (TDE)
TDE operates at the PaaS layer. The database engine encrypts data in memory before writing it to the file system, and decrypts it when reading it back. The encryption and decryption happen transparently—applications require no changes.
Key characteristic: Data is invisible to both IaaS and PaaS O&M personnel. DBAs can still access plaintext data.
Performance: Performance loss depends on the sizes of sensitive tables relative to the database cache:
If the table fits in cache, performance loss is negligible.
If the table is much larger than the cache, loss can be significant.
In most workloads, loss stays below 5%. Under extremely heavy loads, it may reach 20%.
Column encryption
Column encryption (the basic edition of the always-confidential database feature) operates at the database kernel layer. Before the database sends query results to the client, it encrypts the data. The client decrypts the results using the required key. This separates data ownership from data management: the people who manage the database cannot view the data it contains.
Key characteristic: Data is invisible to DBAs. However, PaaS and IaaS O&M personnel can still access plaintext data at the storage level unless you upgrade to the hardware-enhanced edition.
Application change required: Replace the Java Database Connectivity (JDBC) driver with EncJDBC. No code changes are needed beyond the driver swap.
Performance: Performance loss depends on the volume of sensitive data in query results—not on table or database size:
Querying a single row: minimal loss.
Querying one million rows of encrypted data: significant loss.
In most workloads, loss stays below 7%. Under extremely heavy loads, it may reach 21%.
Technical architecture
The following table shows how the three methods differ architecturally.
| Disk encryption | TDE | Column encryption | |
|---|---|---|---|
| Effective scope | Operating system | Database kernel | Database kernel |
| Encryption scope | Host and ECS instance | Database instance | Database instance |
| Encryption granularity | Instance | Database and table | Column |
| Application awareness | Transparent | Transparent | Replace JDBC with EncJDBC |
When to use each method
Use disk encryption when you need to meet IaaS-layer compliance requirements or protect against scenarios where physical media is stolen or copied.
Use TDE when you need to prevent PaaS and IaaS O&M personnel—such as OS administrators—from accessing database file contents, without modifying your application.
Use column encryption when you need to prevent DBAs from viewing sensitive data, or when you need to protect data in transit between the database and your application.
These methods are complementary. A production environment with strict security requirements may use all three together.