La protezione del dato a riposo (data at rest) nei database relazionali pone da tempo una sfida complessa in ambito enterprise. Storicamente, l'implementazione del Transparent Data Encryption (TDE) in ambienti PostgreSQL ha richiesto l'adozione di fork proprietari, l'applicazione di patch invasive al core del database o, in alternativa, la delega della cifratura a livello applicativo. Ognuna di queste vie comporta compromessi — vendor lock-in, complessità di manutenzione, overhead prestazionale — che finora non avevano un'alternativa nativa.

È in questo contesto che si inserisce il paper tecnico che Durighetto presenterà a PGConf.Asia 2026, la conferenza regionale della community PostgreSQL asiatica, in programma a Hong Kong il 17 e 18 novembre — a dieci anni dalla prima edizione (Giappone, 2016) e nell'anno in cui il progetto PostgreSQL compie trent'anni. La sessione, intitolata "pg_vault_tde: A Plug-and-Play Extension for Table Encryption", illustra le meccaniche interne di pg_vault_tde, estensione open source (licenza PostgreSQL) sviluppata da Miriade che abilita il TDE su PostgreSQL 17 e 18 senza alterare il core engine né il codice degli applicativi.

L'approccio architetturale: Table e Index Access Method

Dal punto di vista ingegneristico, la soluzione bypassa la necessità di un fork agendo al livello dei layer di astrazione del database. L'estensione si aggancia al Table Access Method (TAM) tramite il modulo encrypted_heap: ogni tupla viene cifrata con AES-256-GCM prima di toccare il disco.

Un elemento di interesse per i DBA è la gestione dell'header MVCC (Multi-Version Concurrency Control), che resta in chiaro — scelta progettuale che permette a controlli di visibilità, VACUUM e checksum di pagina di continuare a funzionare in modo nativo e inalterato.

Per i dati indicizzati, pg_vault_tde introduce un Index Access Method dedicato, tde_btree, che usa cifratura deterministica AES-256-SIV: permette alle query di uguaglianza di operare correttamente sui dati cifrati, ma non copre i range scan. L'accelerazione hardware passa dall'integrazione con OpenSSL EVP, che sfrutta le istruzioni AES-NI su x86 e le Crypto Extensions su ARM.

Key management e compliance enterprise

Per un CISO la cifratura vale quanto la gestione delle chiavi che la sostengono. L'architettura risponde a questo con una gerarchia di wrapping a due livelli: una Data Encryption Key (DEK) AES-256 per tabella cifra i dati, mentre una Key Encryption Key (KEK), custodita nel sistema di gestione chiavi scelto dal cliente, avvolge la DEK — solo la chiave avvolta risiede nel database.

I backend supportati, selezionabili per singolo database e senza riavvio dell'istanza, sono tre:

• HashiCorp Vault / OpenBao, via Transit engine, con autenticazione Token, AppRole o Kubernetes JWT — per la gestione centralizzata in ambienti cloud e microservizi.
• Wallet locali PKCS#12, protetti da passphrase con derivazione PBKDF2-SHA256 a 600.000 iterazioni — per deployment air-gapped con restrizioni di rete rigorose.
• HSM via PKCS#11, validati con Thales, Utimaco, YubiHSM e AWS CloudHSM, con master key non estraibile dal dispositivo — per la custodia hardware richiesta dagli ambienti più regolamentati.

Operatività, rotazione delle chiavi e limitazioni

Nella sessione, il team R&D di Miriade dimostrerà l'intero ciclo operativo: recupero di dati sensibili (SSN) in chiaro da un file heap non cifrato, cifratura della stessa tabella con una singola clausola DDL, rotazione delle chiavi sotto carico applicativo — sia DEK (pg_vault_tde_rotate_online) sia KEK — con zero downtime e avanzamento tracciabile. Sul fronte dei backup, pg_basebackup_tde applica una sigillatura anti-manomissione (HMAC) ai backup fisici, mentre pg_dump_tde e pg_restore_tde chiudono un leak non ovvio: un pg_dump ordinario esegue di fatto una lettura SQL e restituisce quindi i dati già decifrati, rendendo il backup logico un canale di fuga silenzioso in assenza degli strumenti dedicati.

Il talk non omette le limitazioni attuali: i metadati strutturali del WAL non sono cifrati, le statistiche del planner restano un canale di informazione indiretta, e gli indici cifrati supportano solo ricerche per uguaglianza — punti in parte indirizzati dalla roadmap della versione 1.8.

Conformità: cosa copre e cosa non copre

pg_vault_tde non rende "conforme" un ambiente da solo — nessun prodotto lo fa — ma il logging di audit sempre attivo si allinea a sotto-clausole specifiche del PCI-DSS Requisito 10 (autenticazione, ciclo di vita delle chiavi, accessi negati) e all'HIPAA §164.312(b); l'integrazione HSM copre i casi in cui la master key non può mai esistere fuori da un confine hardware certificato, e la cifratura a riposo supporta le buone pratiche dell'Art. 32 GDPR. Restano esplicitamente fuori perimetro i dati in memoria durante l'esecuzione delle query, il trasporto in rete (per cui resta necessario TLS) e l'autorizzazione a livello di database: un utente con permesso SELECT vede comunque i dati in chiaro, perché TDE non sostituisce RLS e RBAC.

Licenza e adozione

Il dettaglio non secondario per chi valuta l'adozione è la licenza: pg_vault_tde è distribuito sotto PostgreSQL License (BSD 2-Clause), permissiva e compatibile con MIT/BSD/ISC/Apache 2.0, senza codice GPL o AGPL — scelta che evita il lock-in tipico dei fork proprietari e lascia l'eventuale aggiornamento a PostgreSQL 19, quando disponibile, un'operazione ordinaria anziché una riscrittura di patch. Codice, changelog e pacchetti pronti (.deb, .rpm, immagine container) sono pubblici su GitHub, nel repository labmiriade/pg_vault_tde; Miriade offre inoltre un supporto annuale dedicato (MirCrypt) per chi preferisce affidare l'adozione in produzione a un servizio gestito.

Chi è Matteo Durighetto

Responsabile R&D, Miriade S.r.l.

Matteo Durighetto guida la Ricerca e Sviluppo di Miriade, con una specializzazione in database relazionali maturata su PostgreSQL, Oracle, MySQL e MSSQL. È l'ideatore e lead maintainer di pg_vault_tde, l'estensione open source per la Transparent Data Encryption su PostgreSQL sviluppata da Miriade.