Transparent Data Encryption (TDE)

Este parche de CYBERTEC a PostgreSQL es actualmente la única implementación para dar soporte transparente y criptográficamente seguro a la encriptación a nivel instancia (cluster).

¿Cómo funciona la encriptación?

La idea detrás de este parche es almacenar todos los archivos que componen un cluster PostgreSQL seguramente en el disco en formato encriptado (encriptación data-at-rest) y después desencriptar los bloques a medida que son leídos del disco. Esto requiere solamente que la Base de Datos sea inicializada con encriptación y que la clave utilizada para inicializar la base de datos sea accesible al servidor durante el startup. La clave de encriptación puede ser provista de dos maneras – a través de una variable de entorno o a través de un parámetro de configuración.

transparent data encryption

Detalles

Para encripción 128-bit se utiliza el algoritmo AES en modo XTS, también llamado XTS-AES. Es un cifrado en bloque con un «tweak» para extra seguridad y adhiere al standard IEEE P1619. La clave tiene que ser provista al servidor en cada inicialización y, cuando no coincida, el servidor se rehusará a comenzar. Todo estará encriptado en mayor o menor medida – archivos heap (tablas, índices, secuencias), xlog (ya que tambien contienen datos), clog, archivos temporales generados en queries grandes

El declive de la performance debida a la encripción-desencripción depende fuertemente de los casos concretos de uso. Para aquellos donde los espacios de trabajo entran bien en los buffers compartidos de PostgreSQL, es prácticamente despreciable

Transparent Data Encryption PostgreSQL

 

PostgreSQL TDE performance

Check out the performance analysis that compares PostgreSQL v13 with PostgreSQL Transparent Data Encryption.

PostgreSQL Performance: encrypted vs. unencryped

FAQ

P: ¿Qué es lo que realmente está siendo encriptado?
R: Todo excepto los datos de extensión de pg_stat_statements y los buffers temporarios utilizados para replicación lógica (si están en uso) – esto es, tablas, índices, logs de transacciones (xlogs),clog, tablas temporarias y no loggeadas, espacio libra, mapa de visibilidad y TOAST. Lo único que queda fuera también podrían ser encriptadas pero requieren «tinkering» y fueron dejadas fuera de la versión inicial porque no están activas por defecto.

P: ¿Cual es el método de encriptación utilizado?
R: Cifrado por Standard 128-bit AES-CTR

P: ¿Puedo usar otro método de encriptación?
R: No por defecto. Deberían implementarse una serie de rutinas en C para ello. Sin embargo, la interfaz misma es lo suficientemente simple

P: ¿Cuál es el costo de performance esperado?
R: En un servidor típico (si tal cosa existe), cuando la base de datos entra en el buffer compartido, entonces es despreciable (<3%). De lo contrario, las operaciones IO pueden ser hasta 2 o 3 veces más lentas. En trabajos futuros agregaremos soporte a encriptación de hardware (utilizando AES-NI) y esperamos reducir el overhead casi en un orden de magnitud

P:¿Puedo hacer un upgrade a una nueva versión mayor de una base de datos encriptada?
R: Si, siempre y cuando el nuevo cluster sea inicializado con la vieja clave de encriptación

P: ¿Es posible encriptar solamente ciertas tablas o tablespaces para ganar en performance?
R: Por el momento no. En teoría, podría ser agregado más tarde, pero como el XLOG va a ser encriptado totalmente de todos modos y todos los cambios normalmente van allí, probablemente no genera una diferencia significativa

P: ¿Es posible cambiar a clave de encriptación en los casos en que la misma se vea comprometida?
R: Por el momento no. Debería re inicializarse un nuevo cluster y hacerse un dump/restore. De todos modos, se puede usar la interfaz de comando de configuracion de clave para implementar una clave guardada encriptada para el master donde se puede cambiar las claves usadas para desbloquear la clave master

P:¿Se integra con mi HSM?
R: No por defecto. Sin embargo, existen dos maneras de integrar un HSM. Cuando el cacheo de la clave en la base de datos sea aceptable, use la interfaz de clave de configuracion para alimentar a PostgreSQL con la clave del HSM. Para mejor protección contra robo de claves en un servidor con una base de datos operativa es posible delegar toda la encriptación y desencriptación al HSM. Es necesario desarrollar una extensión especial en C para ello.

Q: TDE esta disponible para las versiones 12 y 13 de PostgreSQL?
A: Sí, TDE está ahora también disponible para las versiones 12.3 y 13.4 de PostgreSQL ¡Nuestro equipo de ventas estará encantado de hacerle una oferta sin compromiso!

Q: Encontre un bug. Donde debo reportarlo?
A: Por favor reporte cualquier bug o problema con TDE a bugs-tde@cybertec.at.

Descargar encriptación PostgreSQL a nivel instancia

Para las últimas versiones nuestro equipo de ventas estará encantado de hacerle una oferta sin compromiso.

¡Contacto!