La encriptación es transparente porque las consultas en SQL y las operaciones de DDL y DML funcionan con normalidad sin requerir cambios en la aplicación. Los datos se encriptan automáticamente antes de escribirse en el disco y se desencriptan cuando se leen en la memoria.
Jerarquía de claves
AlloyDB Omni implementa una jerarquía de claves de dos niveles que mantiene una separación estricta de las responsabilidades entre la base de datos y la infraestructura de seguridad administrada por el usuario.
- Claves de encriptación de datos (DEK): AlloyDB Omni las genera y posee. Estas claves encriptan los archivos de datos reales, el WAL y los archivos temporales. AlloyDB Omni almacena las DEK en el disco, pero las encapsula con tu KEK.
-
Clave de encriptación de claves (KEK): Es la clave principal que administras en un servicio externo de administración de claves (KMS).
AlloyDB Omni usa tu KEK para encriptar las DEK.
AlloyDB Omni accede a esta clave solo al inicio para desencriptar las DEK. Tu KEK nunca se almacena de forma persistente en el disco de la base de datos.
-
La ubicación y los parámetros de acceso de la KEK se definen dentro del recurso personalizado
TdeConfig.
-
La ubicación y los parámetros de acceso de la KEK se definen dentro del recurso personalizado
Cómo funciona el TDE con AlloyDB Omni
Cuando la TDE está habilitada, AlloyDB Omni protege tus datos con un modelo de encriptación en capas que se integra con un KMS externo.
- Inicialización y recuperación de claves: Durante la fase de inicialización o inicio del clúster, el motor de AlloyDB Omni establece una conexión segura con tu KMS. Se autentica con un token web JSON (JWT) y recupera la KEK.
- Desempaquetado de las DEK: AlloyDB Omni usa tu KEK para desempaquetar las DEK, que se almacenan en el almacenamiento local en un estado empaquetado. Luego, estas DEK se cargan en la memoria.
- Operaciones de datos transparentes:
- Escritura en el disco: A medida que la base de datos escribe bloques de datos, registros de WAL o archivos temporales en el disco físico, encripta automáticamente los datos con algoritmos AES-256 antes de escribirlos en el disco físico.
- Lectura desde el disco: Cuando la base de datos necesita leer datos en la memoria, desencripta automáticamente los bloques con las DEK que se encuentran en la memoria.
- Límites de seguridad: Tu KEK nunca se almacena en el disco de la base de datos local, lo que garantiza que, incluso si se vulnera el medio de almacenamiento físico, los datos no se puedan leer sin acceso autorizado a la bóveda externa.
Permiso y especificaciones de encriptación
AlloyDB Omni usa algoritmos AES-256 estándar de la industria para proteger tus datos.
- Archivos de datos (tablas e índices): AES-256-XTS.
- Registros de escritura anticipada (WAL): AES-256-CTR
- Archivos temporales: AES-256-XTS o AES-256-CTR, según el tipo de datos temporales.
- Unión de claves: AES-256-KWP
Copias de seguridad y alta disponibilidad
Cuando la TDE está habilitada, las copias de seguridad creadas con pgBackRest heredan la configuración de encriptación del clúster de origen. Esto garantiza que tus datos de copias de seguridad permanezcan protegidos con el mismo nivel de seguridad que tu base de datos principal.
Para las configuraciones de HA, el TdeConfig debe estar presente en el espacio de nombres como el recurso DbCluster.
KMS y autenticación compatibles
AlloyDB Omni admite HashiCorp Vault como proveedor externo de KMS. AlloyDB Omni solo admite el motor de secretos KV-V2, y el único método de autenticación admitido es JWT.
Compatibilidad con herramientas de PostgreSQL
Los clústeres habilitados para TDE admiten todas las herramientas integradas de PostgreSQL a través del recurso TdeConfig.
Limitaciones
- No puedes habilitar la TDE en clústeres existentes.
- Una vez habilitada, no podrás inhabilitar la TDE.
- No se admiten las actualizaciones de versiones principales para los clústeres habilitados para TDE.
- No puedes restablecer copias de seguridad encriptadas en servidores sin encriptar ni copias de seguridad sin encriptar en servidores encriptados.
- No se admite la rotación de la DEK.
- Se admite la rotación de la KEK siempre y cuando la ruta de URL de la KEK siga siendo la misma.
- No puedes
CREATE DATABASEcon la estrategiaFILE_COPY. - En los clústeres habilitados para TDE, las copias de seguridad de Barman solo admiten el modo
rsync. No se admite el método de copia de seguridadpostgres.
¿Qué sigue?
- Obtén más información para crear un clúster habilitado para TDE.