Jerarquía de claves
AlloyDB Omni implementa una jerarquía de claves de dos niveles que mantiene una estricta separación de funciones entre la base de datos y la infraestructura de seguridad administrada por el usuario.
- Claves de encriptación de datos (DEK): Son claves que genera y posee AlloyDB Omni. Estas claves encriptan los archivos de datos reales, WAL, y los archivos temporales. AlloyDB Omni almacena las DEK en el disco, pero las une con tu KEK.
-
Clave de encriptación de claves (KEK): Es la clave principal que administras en un
servicio de administración de claves (KMS) externo.
AlloyDB Omni usa tu KEK para encriptar las DEK.
AlloyDB Omni accede a esta clave solo al inicio para desunir
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 proporcionan a través
variables de entorno y la
--tde-kek-urlinicialización marca.
-
La ubicación y los parámetros de acceso de la KEK se proporcionan a través
variables de entorno y la
Cómo funciona la 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 inicio o inicialización del clúster, el motor de AlloyDB Omni establece una conexión segura con tu KMS. Se autentica con un token web JSON (JWT) para HashiCorp Vault o con credenciales de nombre de usuario y contraseña para Thales CipherTrust Manager, y recupera la KEK.
- Desunión de las DEK: AlloyDB Omni usa tu KEK para desunir las DEK, que se almacenan en el almacenamiento local en un estado unido. 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 WAL o archivos temporales en el disco físico, encripta automáticamente los datos con algoritmos AES-256 antes de escribirlos.
- 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.
- Encriptación de caché: La TDE también admite la memoria caché del disco, incluida la información del motor de columnas almacenada en la caché. Los datos escritos en la capa de almacenamiento de caché inactiva se encriptan, y los datos que se derraman en la caché SSD del motor de columnas se encriptan antes de escribirse en la SSD y se desencriptan cuando se leen.
Optimizaciones de rendimiento: La TDE incluye optimizaciones para mantener un alto rendimiento mientras se protegen los datos. Usa protección
AES-256-XTSoptimizada para bloques de datos y memorias caché, y cuenta con optimizaciones de escritura síncrona para minimizar la latencia en rutas de acceso rápidas.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 ve comprometido el medio de almacenamiento físico, los datos no se puedan leer sin acceso autorizado al KMS externo.
Alcance y especificaciones de la 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
- Archivos de caché del motor de columnas: AES-256-XTS
- Archivos de caché inactiva: AES-256-XTS
- Unión de claves: AES-256-KWP
Copia 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 copia de seguridad permanezcan protegidos con el mismo nivel de seguridad que tu base de datos principal.
Para las configuraciones de HA, el entorno de recuperación debe inicializarse con las mismas variables de entorno de KMS. Las variables de entorno de KMS deben estar disponibles en todos los hosts participantes.
KMS y autenticación compatibles
AlloyDB Omni admite los siguientes proveedores de KMS externos y métodos de autenticación:
- HashiCorp Vault:
Admite el motor de secretos KV-V2 con autenticación de token web JSON (
jwt) . - Thales CipherTrust Manager:
Admite la administración de secretos con autenticación de nombre de usuario y contraseña (
password) .
Compatibilidad con herramientas de PostgreSQL
Los clústeres habilitados para TDE admiten todas las herramientas integradas de PostgreSQL, exceptoinitdb, de forma transparente a través de variables de entorno.
Si usas initdb, asegúrate de pasar la URL de la KEK de forma explícita.
Para obtener más información, consulta
Crea un clúster habilitado para TDE.
Limitaciones
- No puedes habilitar la TDE en clústeres existentes.
- Después de habilitar la TDE, no puedes inhabilitarla.
- 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 DEK.
- Se admite la rotación de KEK siempre que la ruta de URL de la KEK siga siendo la misma. La rotación de KEK solo se admite para HashiCorp Vault y Thales CipherTrust Manager como proveedores de KMS externos, no para KMS basado en archivos.
- 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 información para crear un clúster habilitado para TDE.
- Soluciona problemas de encriptación de datos transparente.