Encriptación de datos transparente para AlloyDB Omni

Selecciona una versión de la documentación:

Para proteger la información sensible y cumplir con requisitos de cumplimiento estrictos sin modificar el código de tu aplicación, usa la encriptación de datos transparente (TDE) para proteger los datos en reposo en AlloyDB Omni. En esta descripción general, se explica cómo la TDE encripta automáticamente los archivos, los registros y las memorias caché de la base de datos antes de que se escriban en el disco, lo que garantiza una seguridad en profundidad con una sobrecarga operativa mínima.

Jerarquía de claves

AlloyDB Omni implementa una jerarquía de claves de dos niveles que mantiene una separación de funciones estricta 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, el WAL y los archivos temporales reales. 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 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 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 proporcionan a través de variables de entorno y la marca de inicialización --tde-kek-url.

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 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.
    • 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é: El 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 la caché inactiva se encriptan, y los datos volcados en la caché de SSD del motor columnar se encriptan antes de escribirse en la SSD y se desencriptan al leerse.

  • Optimizaciones del rendimiento: El TDE incluye optimizaciones para mantener un rendimiento alto mientras se protegen los datos. Utiliza protección AES-256-XTS optimizada para los bloques de datos y las memorias caché, y ofrece optimizaciones de escritura síncrona para minimizar la latencia en las rutas 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 vulneran los medios de almacenamiento físico, los datos no se puedan leer sin acceso autorizado a la bóveda externa.

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é de Chill: AES-256-XTS.
  • Unión de clave: 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 copias de seguridad permanezcan protegidos con el mismo nivel de seguridad que tu base de datos principal.

Las copias de seguridad solo se pueden restablecer en clústeres en los que esté disponible la misma KEK.

En el caso de las configuraciones de alta disponibilidad, el entorno de recuperación debe inicializarse con las mismas variables de entorno de la bóveda. Las variables de entorno de la bóveda deben estar disponibles en todos los hosts participantes.

KMS y autenticación admitidos

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 compatible es JWT.

Nota: AlloyDB Omni admite KMS basado en archivos. Sin embargo, te recomendamos que lo uses solo para realizar pruebas y no en cargas de trabajo de producción.

Compatibilidad con herramientas de PostgreSQL

Los clústeres habilitados para TDE admiten todas las herramientas integradas de PostgreSQL, excepto initdb, 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.
  • 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 no encriptados ni copias de seguridad no encriptadas en servidores encriptados.
  • No se admite la rotación de 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 DATABASE con la estrategia FILE_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 seguridad postgres.
  • La rotación de la clave de encriptación de claves (KEK) solo se admite para HashiCorp Vault como proveedor del sistema externo de administración de claves (KMS).

¿Qué sigue?