Cifratura AES-256 nelle Virtual Data Room: cos'è, perché è lo standard, come verificarla

Cos'è AES-256 e perché è lo standard

AES (Advanced Encryption Standard) è l'algoritmo di cifratura simmetrica adottato dal NIST nel 2001 e oggi standard de facto in tutta l'industria della sicurezza informatica. Il suffisso 256 indica la lunghezza della chiave in bit: 2^256 combinazioni possibili, una scala che lo rende non attaccabile via brute‑force con la tecnologia attuale.

Quando si dice che una Virtual Data Room "cifra i documenti con AES‑256", significa che ogni file caricato viene memorizzato in forma cifrata sui server, e la chiave necessaria a decifrarlo è gestita dal provider. Senza la chiave, il documento è una sequenza di byte indistinguibile da rumore casuale.

Tre dimensioni della cifratura in una VDR

Per la maggior parte dei casi d'uso VDR, AES‑256 at‑rest + TLS 1.2 in transit è il perimetro standard. End‑to‑end è raro perché complica la gestione di permessi granulari, watermark e audit lato server.

• At‑rest (a riposo): il file memorizzato sul disco è cifrato. AES‑256 è lo standard.
• In‑transit (in transito): i trasferimenti browser↔server sono cifrati con TLS 1.2 o 1.3.
• End‑to‑end: la cifratura è applicata nel browser del mittente e decifrata solo nel browser del destinatario. Rara nelle VDR; tipica delle messaging app.

Chi possiede le chiavi di cifratura

Una distinzione cruciale, spesso trascurata. Tre modelli principali:

• Provider‑managed keys (default): le chiavi sono gestite dal provider VDR, con rotazione automatica. È il modello standard.
• Customer‑managed keys (CMK): il cliente fornisce e controlla la chiave, tipicamente via KMS (AWS KMS, Azure Key Vault). Il provider non può accedere ai dati senza la chiave del cliente.
• Sealed cloud / zero‑knowledge: architettura in cui — per progettazione — nemmeno il personale del provider può accedere alle chiavi. È il modello di idgard.

Provider VDR e cifratura dichiarata

Come verificare l'implementazione

Una dichiarazione di marketing "AES‑256" sulla homepage non basta. Per verificare l'implementazione effettiva conviene:

1. Richiedere la security whitepaper del provider — documento tecnico che descrive cifratura, gestione chiavi, rotazione, KMS utilizzato.
2. Chiedere il SOC 2 Type II report (sotto NDA) — contiene i controlli sulla cifratura verificati da auditor terzi.
3. Verificare la certificazione ISO 27001 — il control A.10 dell'allegato copre la cifratura.
4. Per provider open source come Papermark, ispezionare direttamente il codice su GitHub (modulo crypto, gestione KMS).

AES-256 è davvero inviolabile?

Non esistono attacchi pratici contro AES‑256 con la tecnologia attuale. La sicurezza reale dipende dalla gestione delle chiavi: una chiave debole o compromessa rende inutile l'algoritmo perfetto.

Cosa succede se il provider perde la chiave?

Sui sistemi enterprise le chiavi sono replicate e backup‑ate in KMS dedicati con politiche di disaster recovery. La perdita della chiave master è uno scenario che i provider seri progettano per non realizzarsi mai. Per estrema sicurezza, il modello customer‑managed keys mantiene la chiave sotto il controllo del cliente.

TLS 1.2 è abbastanza, o serve TLS 1.3?

TLS 1.2 con suite cifrari moderne è ancora considerato sicuro e largamente diffuso. TLS 1.3 è preferibile per nuove implementazioni; molti provider VDR lo offrono come default insieme al fallback 1.2.

Cifratura end-to-end è disponibile su Virtual Data Room?

Raramente nelle VDR mainstream perché complica funzionalità lato server (ricerca full-text, watermark, audit). idgard si avvicina con la sealed cloud. Papermark con self‑hosting permette di applicare cifratura aggiuntiva lato applicazione cliente.