La cifratura dei dati a riposo non è possibile? Guida per CISO ai controlli compensativi difendibili in audit

Il rilievo dell’auditor arrivò sulla scrivania della CISO Sarah Chen con un tonfo familiare. Un database legacy critico e generatore di ricavi, cuore operativo della linea produttiva aziendale, non supportava la cifratura moderna dei dati a riposo. L’architettura sottostante risaliva a dieci anni prima e il fornitore aveva da tempo cessato di fornire aggiornamenti di sicurezza. L’auditor, correttamente, lo segnalò come rischio rilevante. La raccomandazione: “Cifrare tutti i dati sensibili a riposo utilizzando algoritmi standard di settore”.
Per Sarah, non era solo un problema tecnico; era una crisi di continuità operativa. Aggiornare il sistema avrebbe comportato mesi di indisponibilità e costi per milioni, un’opzione inaccettabile per il Consiglio di amministrazione. Ma lasciare non cifrato un patrimonio di proprietà intellettuale sensibile era un rischio inaccettabile, una chiara deviazione dal Sistema di gestione per la sicurezza delle informazioni (SGSI).
Questo scenario rappresenta la realtà della cibersicurezza: le soluzioni perfette sono rare e la conformità non può essere sospesa. Accade quando file di backup critici sono archiviati su sistemi legacy, quando un fornitore SaaS strategico invoca “limitazioni tecniche” o quando applicazioni ad alte prestazioni non reggono il sovraccarico della cifratura. La risposta da manuale, “basta cifrare”, spesso si scontra con una realtà più complessa.
Che cosa accade, quindi, quando il controllo primario prescritto non è praticabile? Non si accetta semplicemente il rischio. Si costruisce una difesa più intelligente e resiliente mediante controlli compensativi. Non si tratta di trovare scuse, ma di dimostrare una gestione della sicurezza matura e basata sul rischio, in grado di resistere anche al più rigoroso esame di audit.
Perché la cifratura dei dati a riposo è un requisito ad alto impatto
La cifratura dei dati a riposo è un controllo fondamentale in tutti i moderni quadri di riferimento per la sicurezza, inclusi ISO/IEC 27001:2022, GDPR Article 32, NIS2, DORA e NIST SP 800-53 SC-28. La sua finalità è semplice ma critica: rendere illeggibili i dati archiviati se le difese fisiche o logiche falliscono. Un nastro di backup smarrito o un server rubato contenente dati non cifrati non è solo un errore tecnico; spesso costituisce una violazione dei dati soggetta a obbligo di notifica.
I rischi sono chiari e significativi:
- Furto o perdita di supporti portatili come unità USB e nastri di backup.
- Esposizione dei dati da dispositivi non gestiti, dimenticati o legacy.
- Impossibilità di applicare la cifratura nativa di dischi o database in specifici contesti SaaS, cloud, OT o legacy.
- Rischi di mancato ripristino dei dati in caso di perdita o gestione errata delle chiavi di cifratura.
Questi requisiti non sono solo tecnici: sono obblighi giuridici. GDPR Article 32 e DORA Articles 5 e 10 riconoscono esplicitamente la cifratura come “misura tecnica adeguata”. NIS2 la considera una baseline per garantire l’integrità dei sistemi e delle informazioni. Quando questa difesa primaria non è praticabile, l’onere della prova si sposta sull’organizzazione, che deve dimostrare che le misure alternative sono altrettanto efficaci.
Dal requisito puntuale alla difesa stratificata
La reazione istintiva a un rilievo di audit come quello di Sarah è spesso il panico. Ma un SGSI ben strutturato anticipa queste situazioni. La prima azione di Sarah non fu chiamare il team infrastrutturale; fu aprire la Politica sui controlli crittografici della sua organizzazione, un documento costruito con i template enterprise di Clarysec. Andò direttamente alla clausola che forniva la base della sua strategia.
Secondo la Politica sui controlli crittografici, la sezione 7.2.3 definisce esplicitamente il processo per stabilire:
“Controlli compensativi specifici da applicare”
Questa clausola è il miglior alleato di un CISO. Riconosce che un approccio unico alla sicurezza è inadeguato e fornisce un percorso autorizzato per trattare il rischio. La politica non opera in isolamento. Come indicato nella clausola 10.5, è direttamente collegata alla Politica di classificazione ed etichettatura dei dati, che “definisce i livelli di classificazione (ad esempio Riservato, Dati regolamentati) che attivano requisiti specifici di cifratura”.
Questo collegamento è critico. I dati nel database legacy erano classificati come “Riservato”, motivo per cui l’assenza di cifratura era stata segnalata. A quel punto, la missione di Sarah era chiara: costruire una barriera di controlli compensativi talmente robusta da mitigare il rischio di esposizione fino a un livello accettabile.
Progettare una strategia difendibile con lo Zenith Blueprint
La cifratura è un pilastro della sicurezza moderna, ma come spiega il Zenith Blueprint: roadmap in 30 passi per l’auditor di Clarysec nello Step 21, il controllo 8.24 Use of Cryptography non consiste semplicemente nel “mettere in funzione la cifratura”. Consiste invece nell’“integrare la crittografia nella progettazione, nelle politiche e nella gestione del ciclo di vita dell’organizzazione”.
Quando una parte della progettazione (il database legacy) fallisce, gli aspetti di policy e ciclo di vita devono compensare. Il team di Sarah utilizzò questo quadro di riferimento per progettare una difesa multilivello, fondata sull’obiettivo di impedire ai dati di lasciare il loro contenitore sicuro, seppur non cifrato.
Controllo compensativo 1: prevenzione della perdita di dati (DLP)
Se non è possibile cifrare i dati dove risiedono, è necessario garantire che non possano uscire. Il team di Sarah implementò una soluzione di prevenzione della perdita di dati (DLP) come presidio digitale. Non si trattava di una semplice regola di rete, ma di un controllo sofisticato e sensibile al contenuto.
Utilizzando la Zenith Controls: guida alla conformità trasversale di Clarysec, configurarono il sistema DLP in base alle indicazioni per il controllo ISO/IEC 27001:2022 8.12 Data leakage prevention. Le regole erano direttamente basate su 5.12 Classification of information. Qualsiasi dato corrispondente agli schemi delle informazioni “Riservato” presenti nel database legacy veniva automaticamente bloccato se trasferito tramite e-mail, caricamenti web o persino tramite copia e incolla in altre applicazioni.
Come spiega Zenith Controls:
“La prevenzione della perdita di dati (DLP) dipende in modo fondamentale da una classificazione dei dati accurata. Il controllo 5.12 garantisce che i dati siano etichettati in base alla sensibilità… La DLP è una forma specializzata di monitoraggio continuo, mirata al movimento dei dati… 8.12 può applicare politiche di cifratura per i dati che lasciano l’organizzazione, garantendo che, anche in caso di esfiltrazione di dati, questi restino illeggibili per soggetti non autorizzati.”
Questo controllo è riconosciuto in più quadri di riferimento, con mappatura verso GDPR Art. 32, NIS2 Art. 21, DORA Art. 10 e NIST SP 800-53 SI-4. Attuandolo, il team di Sarah creò una potente barriera protettiva, assicurando che i dati non cifrati rimanessero isolati.
Controllo compensativo 2: mascheramento dei dati per l’uso in ambienti non di produzione
Uno dei rischi principali per i dati legacy è il loro utilizzo in altri ambienti. Il team di sviluppo aveva spesso bisogno di dati provenienti dal sistema di produzione per testare nuove funzionalità applicative. Fornire loro dati riservati non cifrati era fuori discussione.
Qui Sarah fece riferimento allo Step 20 dello Zenith Blueprint, dedicato a 8.11 Data masking. La guida osserva che gli auditor chiederanno in modo diretto: “Utilizzate mai dati personali reali nei sistemi di test? In tal caso, come sono protetti?”
Seguendo queste indicazioni, il team di Sarah attuò una procedura rigorosa di mascheramento dei dati. Qualsiasi estrazione di dati richiesta dal team di sviluppo doveva passare attraverso un processo automatizzato che pseudonimizzava o anonimizzava i campi sensibili. Nomi dei clienti, formule proprietarie e metriche di produzione venivano sostituiti con dati realistici ma fittizi. Questo singolo controllo eliminò un’ampia superficie di rischio, assicurando che i dati sensibili non lasciassero mai, nella loro forma originale, l’ambiente di produzione altamente controllato.
Controllo compensativo 3: controlli fisici e logici rafforzati
Una volta trattati la perdita di dati e l’uso in ambienti non di produzione, l’ultimo livello di difesa si concentrò sul sistema stesso. Basandosi sui principi di 7.10 Storage media di Zenith Controls, il team di Sarah trattò il server fisico come un asset ad alta criticità. Sebbene 7.10 sia spesso associato ai supporti rimovibili, i suoi principi di gestione del ciclo di vita e sicurezza fisica sono pienamente applicabili.
Come osserva Zenith Controls su questo tema:
“ISO/IEC 27002:2022 fornisce indicazioni complete nella Clause 7.10 per gestire in modo sicuro i supporti di archiviazione lungo tutto il loro ciclo di vita. Lo standard raccomanda alle organizzazioni di mantenere un registro di tutti i supporti rimovibili…”
Applicando questa logica, il server fu spostato in un rack dedicato e chiuso a chiave nel data center, accessibile solo a due ingegneri senior nominativamente autorizzati. L’accesso fisico richiedeva la registrazione all’ingresso ed era monitorato tramite CCTV. Sul lato rete, il server fu collocato in una VLAN “legacy” segmentata. Le regole del firewall furono configurate per negare tutto il traffico per impostazione predefinita, con una singola regola esplicita che consentiva la comunicazione solo dal server applicativo designato su una porta specifica. Questo isolamento estremo ridusse drasticamente la superficie di attacco, rendendo i dati non cifrati invisibili e inaccessibili.
Affrontare l’audit: presentare una strategia difendibile e multilente
Quando l’auditor tornò per il follow-up, Sarah non presentò giustificazioni. Presentò un Piano di trattamento del rischio completo, corredato da documentazione, log e dimostrazioni live dei controlli compensativi del suo team. Un audit non è un singolo evento; è un confronto osservato da prospettive diverse, e un CISO deve essere preparato per ciascuna di esse.
La lente dell’auditor ISO/IEC 27001: L’auditor voleva verificare l’efficacia operativa. Il team di Sarah dimostrò il blocco di un’e-mail non autorizzata da parte del sistema DLP, mostrò l’esecuzione dello script di mascheramento dei dati e fornì i log di accesso fisico correlati ai ticket di lavoro.
La lente GDPR e privacy: L’auditor chiese come fosse applicata la minimizzazione dei dati. Sarah mostrò gli script automatizzati per la cancellazione sicura dei dati in cache e il processo di pseudonimizzazione per qualsiasi dato in uscita dal sistema di produzione, in linea con GDPR Article 25 (protezione dei dati fin dalla progettazione e per impostazione predefinita). La Politica sui controlli crittografici per PMI assegna esplicitamente al Responsabile della protezione dei dati (DPO) la responsabilità di “garantire che i controlli di cifratura siano allineati agli obblighi di protezione dei dati ai sensi dell’Article 32 del GDPR”.
La lente NIS2/DORA: Questa prospettiva si concentra sulla resilienza operativa. Sarah presentò i risultati dei test di backup e ripristino per il sistema isolato e gli addenda di sicurezza del fornitore per il software legacy, dimostrando una gestione del rischio proattiva come richiesto da NIS2 Article 21 e DORA Article 9.
La lente NIST/COBIT: Un auditor che utilizza questi quadri di riferimento cerca governance e metriche. Sarah presentò il Registro dei rischi aggiornato, che mostrava l’accettazione formale del rischio residuo (COBIT APO13). Mappò la DLP su NIST SP 800-53 SI-4 (monitoraggio dei sistemi), la segmentazione della rete su SC-7 (protezione dei confini) e i controlli degli accessi su AC-3 e AC-4, dimostrando che, pur non essendo soddisfatto direttamente SC-28 (protezione delle informazioni a riposo), era in essere un insieme equivalente di controlli.
Evidenze chiave per gli auditor sui controlli compensativi
Per comunicare efficacemente la strategia, il team di Sarah preparò evidenze calibrate su ciò che gli auditor si aspettano di vedere.
| Lente di audit | Evidenze richieste | Test di audit comune |
|---|---|---|
| ISO/IEC 27001 | Voci nel Registro dei rischi, registri delle deroghe alle politiche, regole DLP, inventari dei supporti di archiviazione | Riesame dei log di rischio/eccezione, richiesta dei log delle azioni DLP; tracciamento del ciclo di vita dei supporti. |
| GDPR | Procedure di mascheramento dei dati, preparazione alla notifica delle violazioni, registrazioni di cancellazione dei dati | Riesame di set di dati campione (mascherati e non mascherati), test dei trigger DLP, simulazione di uno scenario di violazione. |
| NIS2/DORA | Risultati dei test di backup/ripristino, valutazioni di sicurezza dei fornitori, esercitazioni di risposta agli incidenti | Simulazione di un tentativo di esportazione dei dati; riesame dei processi di gestione dei backup; test dei controlli DLP su dati critici. |
| NIST/COBIT | Log di monitoraggio tecnico, documentazione di integrazione delle politiche, interviste al personale | Simulazione di esfiltrazione di dati, confronto tra politica e procedura, intervista ai principali custodi dei dati e proprietari dei sistemi. |
Anticipando queste diverse prospettive, Sarah trasformò una potenziale non conformità in una dimostrazione di maturità della sicurezza.
Sintesi pratica per il tuo prossimo audit
Per rendere la strategia chiara e difendibile, il team di Sarah creò una tabella di sintesi nel proprio Piano di trattamento del rischio. È un approccio che qualsiasi organizzazione può adottare.
| Rischio | Controllo primario (non praticabile) | Strategia di controllo compensativo | Risorsa Clarysec | Evidenze per l’auditor |
|---|---|---|---|---|
| Divulgazione non autorizzata di dati a riposo | Cifratura completa del disco (AES-256) | 1. Prevenzione della perdita di dati (DLP): monitorare e bloccare tutti i tentativi non autorizzati di esfiltrazione di dati in base al contenuto e al contesto. | Zenith Controls (8.12) | Configurazione della policy DLP, log di allerta, procedure di risposta agli incidenti. |
| 2. Controllo rigoroso degli accessi logici: isolare il server in una rete segmentata con regole firewall “deny-all” e accesso tramite account di servizio fortemente limitato. | Zenith Controls (8.3) | Diagrammi di rete, set di regole firewall, riesami degli accessi utente, policy sulle credenziali degli account di servizio. | ||
| 3. Sicurezza fisica rafforzata: collocare il server in un rack dedicato e chiuso a chiave, con accesso fisico registrato e monitorato. | Zenith Controls (7.10) | Log di accesso al data center, registrazioni CCTV, registri di consegna delle chiavi del rack. | ||
| Uso di dati sensibili in ambienti non di produzione | Cifratura delle copie dei dati di test | Mascheramento dei dati: attuare una procedura formale per pseudonimizzare o anonimizzare tutte le estrazioni di dati prima dell’uso in test o sviluppo. | Zenith Blueprint (Step 20) | Documento formale della procedura di mascheramento dei dati, dimostrazione degli script di masking, set di dati mascherato di esempio. |
Conformità trasversale in sintesi
Una solida strategia di controlli compensativi è difendibile in tutti i principali quadri di riferimento. Zenith Controls di Clarysec fornisce la mappatura crosswalk per assicurare che le difese siano comprese e accettate in modo uniforme.
| Quadro di riferimento | Clausola/riferimento chiave | Come vengono riconosciuti i controlli compensativi |
|---|---|---|
| ISO/IEC 27001:2022 | 8.24, 7.10, 8.12, 8.11, 5.12 | L’approccio basato sul rischio consente controlli alternativi come DLP, gestione dei supporti di archiviazione e mascheramento dei dati, se giustificati. |
| GDPR | Art. 5(1)(f), 25, 32 | Richiede misure tecniche “adeguate”; pseudonimizzazione, controllo degli accessi e DLP possono soddisfare tale requisito quando la cifratura non è praticabile. |
| NIS2 | Art. 21, 23 | Impone un approccio basato sul rischio; controlli stratificati come DLP, protezione dei backup e verifiche sui fornitori sono trattamenti del rischio validi. |
| DORA | Art. 5, 9, 10, 28 | Enfatizza la resilienza operativa; DLP, controllo degli accessi e registrazione robusta sono essenziali per proteggere i dati finanziari, con o senza cifratura. |
| NIST SP 800-53 | SC-28, MP-2 to MP-7, AC-3/4, SI-4 | Consente controlli compensativi; DLP (SI-4), restrizioni di accesso (AC-3) e tracciamento dei supporti (serie MP) possono trattare i rischi dei dati non cifrati. |
| COBIT | DSS05, APO13, MEA03 | Si concentra su governance e misurazione; l’accettazione del rischio documentata (APO13) e il monitoraggio dei controlli compensativi (MEA03) dimostrano due diligence. |
Conclusione: trasformare l’anello debole in un punto di forza
La storia del database legacy non cifrabile non è una storia di fallimento. È una storia di gestione del rischio matura e consapevole. Rifiutando di accettare la semplice risposta “non si può fare”, il team di Sarah ha trasformato una vulnerabilità significativa in una dimostrazione delle proprie capacità di difesa in profondità. Ha dimostrato che la sicurezza non consiste nel barrare una singola casella denominata “cifratura”. Consiste nel comprendere il rischio e costruire una difesa ragionata, stratificata e verificabile in audit per mitigarlo.
Ogni organizzazione avrà inevitabilmente la propria versione di questo database legacy. Quando la individui, non considerarla un ostacolo. Considerala un’opportunità per costruire un programma di sicurezza più resiliente e difendibile.
Vuoi costruire un quadro di controllo solido e pronto per l’audit? Parti dalle basi corrette.
- Riesamina il tuo ecosistema di politiche con i toolkit completi di Clarysec.
- Esplora The Zenith Blueprint: An Auditor’s 30-Step Roadmap per guidare la tua attuazione.
- Sfrutta Zenith Controls: The Cross-Compliance Guide per assicurare che le tue difese resistano all’esame da ogni prospettiva.
Contatta Clarysec per un workshop su misura o per una valutazione completa di conformità trasversale. Perché nell’attuale scenario normativo, la preparazione è l’unico controllo che conta.
Riferimenti:
- Politica sui controlli crittografici
- Politica sui controlli crittografici per PMI
- Politica di classificazione ed etichettatura dei dati
- Zenith Blueprint: roadmap in 30 passi per l’auditor
- Zenith Controls: guida alla conformità trasversale
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

