Transparent data encryption for AlloyDB Omni

Select a documentation version:

To protect sensitive information and meet strict compliance requirements without modifying your application code, use transparent data encryption (TDE) to secure data at rest in AlloyDB Omni. This overview explains how TDE automatically encrypts database files, logs, and caches before they are written to disk, ensuring security in depth with minimal operational overhead.

Key hierarchy

AlloyDB Omni implements a two-tier key hierarchy that maintains a strict separation of duties between the database and the user-managed security infrastructure.

  • Data Encryption Keys (DEKs): keys that are generated and owned by AlloyDB Omni. These keys encrypt the actual data files, WAL, and temporary files. AlloyDB Omni stores DEKs on disk but wraps them with your KEK.
  • Key Encryption Key (KEK): the main key that you manage in an external Key Management Service (KMS). AlloyDB Omni uses your KEK to encrypt the DEKs. AlloyDB Omni accesses this key only at startup to unwrap the DEKs. Your KEK is never stored persistently on the database disk.
    • The KEK's location and access parameters are provided through environment variables and the --tde-kek-url initialization flag.

How TDE works with AlloyDB Omni

When TDE is enabled, AlloyDB Omni secures your data using a layered encryption model that integrates with an external KMS.

  • Initialization and key retrieval: during the cluster's startup or initialization phase, the AlloyDB Omni engine establishes a secure connection to your KMS. It authenticates using a JSON Web Token (JWT) for HashiCorp Vault or username and password credentials for Thales CipherTrust Manager, and retrieves the KEK.
  • Unwrapping the DEKs: AlloyDB Omni uses your KEK to unwrap the DEKs, which are stored on the local storage in a wrapped state. Then, these DEKs are loaded into memory.
  • Transparent data operations:
    • Writing to disk: as the database writes data blocks, WAL records, or temporary files to the physical disk, it automatically encrypts the data using AES-256 algorithms before writing it.
    • Reading from disk: when the database needs to read data into memory, it automatically decrypts the blocks using the DEKs that are held in memory.
    • Cache encryption: TDE also supports the disk cache, including columnar engine information stored in the cache. Data written to the chill cache storage layer is encrypted, and data spilled to the columnar engine's SSD cache is encrypted before being written to SSD and decrypted upon read.

  • Performance optimizations: TDE includes optimizations to maintain high performance while securing data. It uses optimized AES-256-XTS protection for data blocks and caches, and features synchronous write optimizations to minimize latency on fast paths.

  • Security boundaries: your KEK is never stored on the local database disk, ensuring that even if physical storage media is compromised, the data remains unreadable without authorized access to the external KMS.

Encryption scope and specifications

AlloyDB Omni uses industry-standard AES-256 algorithms to secure your data.

  • Data files (tables and indexes): AES-256-XTS.
  • Write-ahead logs (WAL): AES-256-CTR.
  • Temporary files: AES-256-XTS or AES-256-CTR depending on the type of temporary data.
  • Columnar engine cache files: AES-256-XTS.
  • Chill cache files: AES-256-XTS.
  • Key wrapping: AES-256-KWP.

Backup and high availability

When TDE is enabled, backups created using pgBackRest inherit the encryption configuration of the source cluster. This ensures that your backup data remains protected with the same level of security as your primary database.

You can only restore backups to clusters where the same KEK is available.

For HA setups, the recovery environment must be initialized with the same KMS environment variables. The KMS environment variables must be available on all participating hosts.

Supported KMS and authentication

AlloyDB Omni supports the following external KMS providers and authentication methods:

PostgreSQL tool compatibility

TDE-enabled clusters support all built-in PostgreSQL tools, except initdb, transparently through environment variables. If you are using initdb, then ensure that you pass the KEK URL explicitly. For more information, see Create a TDE-enabled cluster.

Limitations

  • You can't enable TDE on existing clusters.
  • After TDE is enabled, you can't disable it.
  • Major version upgrades aren't supported for TDE-enabled clusters.
  • You can't restore encrypted backups to unencrypted servers or unencrypted backups to encrypted servers.
  • DEK rotation isn't supported.
  • KEK rotation is supported as long as the KEK URL path remains the same.
  • You can't CREATE DATABASE using the FILE_COPY strategy.
  • On TDE-enabled clusters, Barman backups only support rsync mode. The postgres backup method isn't supported.

What's next