pg_vault_tde
Transparent Data Encryption (TDE) per PostgreSQL
PostgreSQL non include una funzione nativa di Transparent Data Encryption. pg_vault_tde cifra i dati delle tabelle a riposo — su disco, nei backup, negli stream di replica logica — senza modificare le query applicative e senza patch al core di PostgreSQL. Si installa come una normale estensione, si integra con il sistema di gestione chiavi già in uso (HashiCorp Vault/OpenBao, wallet locale o HSM) e permette di ruotare le chiavi online, senza downtime.
In sintesi
| Prodotto | pg_vault_tde |
|---|---|
| Categoria | Estensione PostgreSQL — Transparent Data Encryption (TDE) |
| Versione corrente | 1.7 |
| Autore | Miriade S.r.l. |
| Licenza | PostgreSQL License (BSD 2-Clause) — permissiva, compatibile MIT/BSD/ISC/Apache 2.0; nessun codice GPL/AGPL |
| PostgreSQL supportati | 17, 18 (supporto a PostgreSQL 19 in roadmap) |
| Architetture CPU | x86-64, AArch64 (ARM64) |
| Accelerazione hardware | AES-NI, VAES+AVX2 (x86-64); ARM Crypto Extensions |
| Pacchettizzazione | .deb (Ubuntu 22.04/24.04, Debian 11/12), .rpm (Rocky/AlmaLinux 8/9), immagine container |
| Dipendenze | OpenSSL 3.x, libcurl |
| Installazione | shared_preload_libraries + CREATE EXTENSION — nessuna ricompilazione o patch del core |
| Maturità | 7 release incrementali (v1.0 → v1.7); oltre 130 test di regressione automatizzati; zero warning del compilatore su PG 17 e 18 |
PostgreSQL non ha una TDE nativa
Le organizzazioni regolamentate devono dimostrare che i dati sensibili sono illeggibili a chiunque acceda direttamente allo storage — un disco rubato, un backup non cifrato, uno snapshot cloud. Senza TDE nativa, i team hanno finora tre opzioni poco soddisfacenti:
Cifratura disco / filesystem
Protegge da un disco rubato, ma non da chi ha già accesso al sistema operativo, e non protegge nulla mentre il database è in esecuzione.
Cifratura applicativa (colonna)
Sicura, ma richiede riscritture invasive dell'applicazione, rompe indicizzazione e query e sposta la gestione chiavi dentro ogni applicazione.
Fork o patch del core
Potente, ma ogni aggiornamento richiede una nuova patch, i backport di sicurezza arrivano in ritardo e si perde l'accesso ai canali di supporto standard.
pg_vault_tde colma il divario usando le API pubbliche di PostgreSQL per Table Access Method e Index Access Method (esposte dalla versione 12 in poi): cifratura trasparente all'SQL, nessuna modifica applicativa, nessun onere di manutenzione di un fork.
Trasparente all'SQL, chiavi separate dai dati
Tabelle cifrate
Le tabelle si creano con USING encrypted_heap: ogni riga è cifrata prima di toccare il disco e decifrata in modo trasparente su una normale SELECT. Nessuna riscrittura delle query.
Gerarchia di chiavi a due livelli
Una Data Encryption Key (AES-256, per tabella) cifra i dati; una Key Encryption Key custodita nel tuo KMS la "wrappa". Solo la chiave wrappata è salvata nel database.
La master key non lascia il KMS
Un disco rubato, uno snapshot o un pg_basebackup contengono solo testo cifrato e chiavi wrappate: inutilizzabili senza un accesso separato al KMS.
Cifratura autenticata (AEAD)
Se il testo cifrato viene alterato, PostgreSQL genera un errore esplicito invece di restituire silenziosamente dati manomessi o corrotti.
Cosa offre
Motore di cifratura
AES-256-GCM autenticato su ogni riga via OpenSSL 3.x, con rilevamento manomissioni e legame crittografico per tabella. Tutto tramite le API pubbliche, senza patch al core.
Gestione chiavi flessibile
KMS selezionabile per singolo database: HashiCorp Vault/OpenBao, wallet locale o HSM (PKCS#11). Tenant diversi sullo stesso cluster possono usare backend diversi.
Rotazione chiavi online
Rotazione della chiave dati e della master key su traffico di produzione live, senza downtime né riscrittura completa della tabella. Avanzamento tracciabile in tempo reale.
Indici cifrati
tde_btree: indice B-tree su colonne cifrate per ricerche di uguaglianza, con cifratura deterministica misuse-resistant (AES-256-SIV).
Replica logica & backup
Plugin di output per la replica logica standard; strumenti dedicati pg_dump_tde / pg_restore_tde e key sealing autenticato (HMAC) per i backup fisici.
Audit & performance
Audit logging sempre attivo e strutturato (autenticazione KMS, rotazione chiavi, accessi negati); accelerazione hardware (AES-NI, VAES+AVX2, ARM) rilevata a runtime.
Il KMS lo scegli tu
| Backend | Indicato per | Come funziona |
|---|---|---|
| HashiCorp Vault / OpenBao | Infrastruttura KMS/secrets centralizzata già esistente | Motore Transit di Vault via HTTPS; autenticazione Token, AppRole e Kubernetes JWT |
| Wallet locale | Deployment standalone senza infrastruttura KMS esterna | File PKCS#12 protetto da passphrase, fuori dalla data directory; derivazione robusta (PBKDF2-SHA256, 600.000 iterazioni, NIST SP 800-132) |
| PKCS#11 / HSM | Ambienti regolamentati con custodia hardware delle chiavi | Interfaccia Cryptoki dell'HSM; master key non-estraibile sul dispositivo. Validato con Thales, Utimaco, YubiHSM, AWS CloudHSM |
| KMIP roadmap v1.9 | Interoperabilità con infrastrutture KMS enterprise | Non ancora disponibile — voce di roadmap |
Cosa protegge, e cosa no
Essere chiari sul perimetro è un punto di forza, non una debolezza: la TDE protegge i dati a riposo, non durante l'elaborazione o il transito.
Cosa protegge
Cosa è fuori perimetro (per progetto)
A supporto della compliance
pg_vault_tde non rende un ambiente "conforme" da solo: la compliance è una proprietà dell'intero ambiente. Ciò che si può affermare correttamente:
PCI-DSS Req. 10
L'audit logging sempre attivo mappa direttamente su specifiche sotto-clausole 10.2.1.x: autenticazione, ciclo di vita delle chiavi, accessi negati.
HIPAA §164.312(b)
Lo stesso sistema di audit logging è documentato come allineato ai controlli di audit richiesti dall'HIPAA.
Custodia hardware (HSM)
L'integrazione PKCS#11/HSM soddisfa i requisiti per cui la master key non deve mai esistere fuori da un confine hardware certificato.
FIPS & GDPR
OpenSSL può usare un provider validato FIPS (l'estensione non rivendica una validazione propria). La cifratura a riposo supporta le best practice dell'Art. 32 GDPR.
Cifra i dati senza toccare nulla
Cifra i dati PostgreSQL a riposo — senza toccare l'applicazione, il lavoro dei DBA o il codice sorgente di PostgreSQL.
Si installa con shared_preload_libraries e CREATE EXTENSION, senza ricompilazioni. Rilasciata da Miriade con licenza PostgreSQL (BSD 2-Clause): nessun lock-in, nessun codice GPL/AGPL.
Supporto e contesto
MirCrypt
Il supporto annuale di Miriade su pg_vault_tde: installazione, gestione chiavi, rotazione e mantenimento nel tempo.
Servizio · ControlGovernance & Qualità del Dato
Data Catalog, Lineage e Masking: sapere quali dati sono critici, prima di cifrarli.
Prodotto · PresidioDatabase Managed Service (MirDB)
Il presidio continuativo sui database PostgreSQL e non solo.
Domande frequenti
Richiede patch al core di PostgreSQL?
No. Si installa come estensione (shared_preload_libraries + CREATE EXTENSION) usando le API pubbliche di PostgreSQL, senza ricompilare né modificare i binari.
Devo modificare l'applicazione o le query?
No. La cifratura è trasparente all'SQL: le tabelle si creano con USING encrypted_heap e le query restano invariate.
Quali versioni di PostgreSQL supporta?
PostgreSQL 17 e 18; il supporto a PostgreSQL 19 è in roadmap.
Chi custodisce la master key?
Il tuo KMS: HashiCorp Vault/OpenBao, un wallet locale o un HSM. La master key non risiede mai nella data directory né viaggia con i backup.
Mi rende conforme a PCI-DSS o HIPAA?
No: nessun prodotto lo fa da solo. pg_vault_tde fornisce controlli (audit, cifratura, custodia chiavi) che supportano requisiti specifici come PCI-DSS Req. 10 e HIPAA §164.312(b).
Che impatto ha sulle performance?
Il motore sfrutta automaticamente l'accelerazione crittografica della CPU (AES-NI, VAES+AVX2, ARM Crypto) rilevata a runtime, senza configurazione.
Vuoi valutare pg_vault_tde sul tuo PostgreSQL?
Raccontaci il tuo ambiente (versioni, KMS, requisiti di sicurezza): ti aiutiamo a valutare l'estensione e, con MirCrypt, a portarla in produzione con supporto continuativo.
Scrivici per valutare pg_vault_tde
Raccontaci il tuo ambiente PostgreSQL e i tuoi obiettivi di compliance. Compilando il modulo, potrai fissare un confronto tecnico con il nostro team per valutare l'integrazione di pg_vault_tde nella tua architettura. Insieme potremo:
Nota privacy e sicurezza. Non inserire credenziali, password o dati sensibili nel form. Documenti, dati o accessi necessari all'assessment verranno gestiti successivamente tramite canali sicuri concordati.
