La cifratura dei dati personali protegge le informazioni rispetto a determinati accessi non autorizzati, purché le chiavi siano gestite in modo coerente con la minaccia. Cifrare un disco aiuta quando un dispositivo viene sottratto e resta spento; non impedisce necessariamente a un account già autenticato di leggere i documenti. La scelta della misura parte quindi dal percorso dei dati e dalle persone o componenti che possono decifrarli.
L’articolo 32 GDPR menziona la cifratura fra le misure da considerare per un livello di sicurezza adeguato al rischio. Non impone un algoritmo universale per tutti i trattamenti. Questa guida segue il percorso cifratura in transito, dati archiviati, chiavi, password e incidenti, traducendolo in una matrice di decisioni tecniche documentabili.
Identificare dati, copie e minacce
Elencate dove le informazioni vengono create, trasmesse, archiviate ed esportate. Comprendete dispositivi, database, allegati, copie di sicurezza e ambienti di assistenza. La mappatura dei sistemi e dei flussi permette di collegare questi luoghi ai responsabili e ai fornitori coinvolti. La protezione dell’archivio principale non copre automaticamente un’esportazione salvata su un computer.
Per ogni luogo descrivete l’accesso da contrastare: furto del supporto, intercettazione del traffico, amministratore non autorizzato, accesso del fornitore o compromissione dell’applicazione. Una medesima misura può essere efficace per uno scenario e irrilevante per un altro. La valutazione deve chiarire le ipotesi, evitando promesse generiche di dati «impossibili da leggere».
Indicate chi necessita del contenuto in chiaro per erogare il servizio. Se un’applicazione deve elaborare i dati sul server, una cifratura del supporto non impedisce al processo autorizzato di decifrarli. Quando l’obiettivo è escludere il fornitore dall’accesso al contenuto, architettura, gestione delle chiavi e funzionalità disponibili richiedono un esame specifico.
Proteggere i dati in transito
I collegamenti devono proteggere riservatezza e integrità e permettere di riconoscere l’interlocutore. Per i servizi web ciò richiede una configurazione TLS appropriata, validazione dei certificati e gestione delle scadenze. La presenza di HTTPS sulla pagina pubblica non descrive i collegamenti interni, le API o i trasferimenti verso altri servizi.
La verifica di TLS e certificati dovrebbe includere endpoint pubblici, componenti intermedi e comunicazioni applicative. Controllate dove termina la protezione e dove il contenuto torna in chiaro. Se un proxy decifra il traffico, il percorso successivo e i suoi privilegi diventano parte dell’analisi.
Prevedete anche il comportamento dei client in caso di certificato non valido. Un’applicazione configurata per ignorare gli errori può perdere la garanzia di autenticità pur mostrando un canale cifrato. Documentate le eccezioni di laboratorio e assicuratevi che non arrivino nell’ambiente che tratta dati reali.
Distinguere disco, database e singolo documento
La cifratura del disco protegge soprattutto lo scenario del supporto sottratto o dismesso. Quella del database può agire a livelli diversi: intero archivio, colonne o campi selezionati. La protezione di un documento esportato richiede invece di decidere come il destinatario riceve la chiave e cosa avviene dopo l’apertura.
| Livello | Scenario utile | Limite da esaminare |
|---|---|---|
| Dispositivo | Furto o perdita del supporto | Sessione già aperta e chiavi disponibili |
| Archivio | Accesso diretto a file o copie | Privilegi del servizio che legge i dati |
| Campo | Riduzione dell’esposizione di attributi selezionati | Ricerca, indicizzazione e gestione delle chiavi |
| Documento | Trasmissione a un destinatario specifico | Consegna della chiave e copie successive |
| Estremità | Riduzione dell’accesso degli intermediari | Identità dei partecipanti e recupero |
Verificate gli archivi temporanei e i file di lavoro. Un processo può decifrare un contenuto in una cartella condivisa o includerlo in un report diagnostico. La progettazione dei log di sicurezza deve evitare di copiare proprio i dati che l’architettura tenta di proteggere.
Governare l’intero ciclo delle chiavi
Una chiave ha un proprietario, uno scopo, un luogo di custodia e un ciclo di vita. Documentate generazione, distribuzione, utilizzo, rotazione, revoca e distruzione. Distinguete ambienti di sviluppo e produzione e limitate la possibilità di usare la stessa chiave su perimetri differenti senza una ragione esplicita.
Separate, quando necessario, il controllo delle chiavi dal controllo dei dati. Un servizio gestito può offrire modalità diverse, ma la denominazione commerciale non basta a descriverne le garanzie. Chiedete quali operazioni il fornitore possa eseguire, chi possa autorizzarle e quali evidenze siano disponibili. Una chiave formalmente «del cliente» può restare utilizzabile dall’applicazione ospitata presso il fornitore.
Preparate la rotazione prima che sia urgente. La procedura deve indicare come i dati esistenti rimangono leggibili, come vengono aggiornate le nuove scritture e quando una vecchia chiave può essere disabilitata. Provate anche la revoca: una copia della chiave in un ambiente secondario può rendere inefficace il risultato atteso.
Le chiavi di recupero richiedono particolare attenzione. Se nessuno può ripristinarle, la cifratura può trasformare un guasto in una perdita definitiva di disponibilità. Se troppe persone possono recuperarle senza controllo, la protezione perde significato. Il compromesso deve essere motivato in base ai dati e ai servizi coinvolti.
Trattare le password come un problema distinto
Le password degli utenti non dovrebbero essere conservate per poterle recuperare e leggere. La loro protezione richiede tecniche appropriate di derivazione e confronto, insieme a misure contro i tentativi abusivi. Cifrare reversibilmente una tabella di password non risolve lo stesso problema e concentra un rischio rilevante nella chiave di decifratura.
La politica password e autenticazione multifattore descrive gli accessi umani e il recupero degli account. I segreti applicativi, invece, possono richiedere un utilizzo effettivo da parte di un processo e devono essere custoditi, distribuiti e revocati attraverso un meccanismo dedicato. Non confondete questi casi soltanto perché entrambi usano stringhe riservate.
Valutare la cifratura durante un incidente
La presenza di cifratura deve essere valutata rispetto all’evento concreto. Chiedete quali dati fossero protetti, con quale misura e se le chiavi o le sessioni autorizzate siano state compromesse. Un documento cifrato inviato insieme alla password attraverso lo stesso canale può offrire una protezione diversa da quella prevista nel progetto.
L’articolo 34 GDPR contempla condizioni nelle quali misure che rendono i dati incomprensibili possono incidere sull’obbligo di comunicazione agli interessati. Ciò non equivale a una dispensa generale dalla valutazione del data breach o dalla notifica all’autorità. La procedura di comunicazione agli interessati mantiene distinte queste decisioni.
Conservate le evidenze tecniche disponibili: stato del dispositivo, configurazione, disponibilità delle chiavi e accessi osservati. Se un elemento non è noto, dichiaratelo nella valutazione e cercate informazioni ulteriori. La conclusione non può basarsi soltanto sul fatto che il contratto o la scheda commerciale usino la parola «cifratura».
Preparare una matrice di verifica
Per ciascun insieme di dati registrate finalità, luogo, minaccia, misura, soggetto che può decifrare e prova eseguita. Aggiungete dipendenze e limiti. Un controllo utile può consistere nel tentativo autorizzato di leggere una copia senza la chiave, nella verifica di un collegamento o nel recupero di un archivio su un ambiente separato.
Il piano di disaster recovery deve includere le chiavi necessarie e il loro ordine di recupero. Provate il ripristino senza assumere che l’identità centrale o il gestore delle chiavi siano già disponibili. Questa dipendenza circolare emerge spesso soltanto quando si tenta un recupero completo.
Per orientare la revisione delle misure, il quadro CNIL sulla sicurezza dei dati personali offre riferimenti tecnici utilizzabili come supporto metodologico. Riesaminate le scelte quando cambiano algoritmi supportati, fornitori, minacce o durata di sensibilità dei dati. L’inventario crittografico consente di pianificare una migrazione ragionata, evitando sia l’immobilità sia la sostituzione di componenti senza comprendere quali informazioni debbano rimanere protette e per quanto tempo.