ApsaraDB RDS:Use the TDE feature

How TDE works

TDE performs real-time I/O encryption and decryption on data files at the database layer. This prevents attackers from bypassing the database to read sensitive information from storage files directly. Authenticated applications and users access plaintext data without any changes to application code or decryption configurations. OS users who attempt to read tablespace files, and unauthorized users who attempt to read backup data or on-disk data, cannot access plaintext data.

TDE is commonly used by organizations with compliance requirements such as PCI DSS and data-at-rest security mandates, where protecting storage-level data is a primary requirement.

• Transparent: Data is automatically encrypted when written to disk and decrypted when read from disk. The process is invisible to users and applications.

• Data encryption: TDE uses either the service key provided by Key Management Service (KMS) or a customer master key (CMK) that you upload to KMS to encrypt data files.

  Note

  • TDE keys are created and managed by KMS. ApsaraDB RDS does not provide the keys or certificates required for encryption.

  • ApsaraDB RDS for PostgreSQL supports keys of the Aliyun_AES_256 and Aliyun_SM4 types.

Encryption scope

• Table-level and index-level encryption: TDE encrypts and decrypts tables and their indexes, including TOAST tables and all associated data files.

• Batch encryption and decryption: You can encrypt and decrypt all indexes in a table at a time. You can also encrypt and decrypt all tables in a database at a time.

• Low performance impact: In normal business scenarios, TDE causes approximately 4% performance loss on encrypted tables.

Considerations

Before enabling TDE, review the following constraints:

• TDE cannot be disabled once enabled. There is no rollback. Plan your key management strategy before enabling the feature in production environments.

• Backups are also encrypted. After you enable TDE, data backups are encrypted along with the database. Backup files exposed outside the system do not expose plaintext data.

• Key dependency at startup. When the database starts, it contacts KMS to obtain the key encryption key (KEK) and decrypt the data encryption key (DEK) in memory. If key authorization is revoked, the database cannot start.

• Performance impact. In normal business scenarios, TDE causes approximately 4% performance loss on encrypted tables. Evaluate this against your workload requirements before enabling TDE.

Key management and encryption process

Key management options

TDE uses a two-tier key hierarchy: a key encryption key (KEK) and a data encryption key (DEK). The KEK comes from KMS, and there are two modes for managing it:

The key management mode is selected when you enable TDE. You cannot switch modes after TDE is enabled.

Terms

• Key encryption key (KEK): The service key from KMS or a customer master key (CMK) you provide. The KEK encrypts and decrypts data encryption keys (DEKs).

• Data encryption key (DEK): A key generated by the database to encrypt and decrypt data. The DEK is stored encrypted on disk and decrypted into memory at startup using the KEK.

Encryption process

All encryption and decryption operations run in memory. Data in memory is plaintext; data on disk is ciphertext. This protects against data exposure if a disk is physically stolen or accessed outside the database engine. No changes to database usage mode are required.

At database startup, the KEK is retrieved from KMS to decrypt the DEK. The decrypted DEK is held in memory and used to encrypt data on write and decrypt data on read.