CompTIA SY0-701: Sicurezza dei Dati, Privacy e Crittografia — Guida allo studio

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Fa parte della CompTIA Security+ SY0-701 — Guida allo studio. Esercitati con risposte verificate nel centro esami CompTIA, oppure fai test cronometrati su ExamRoll.io.

I dati sono l’obiettivo finale della maggior parte degli attacchi e la crittografia è il principale meccanismo tecnico per proteggerli in transito, a riposo e in uso. Comprendere le proprietà, i limiti e la corretta applicazione delle primitive crittografiche è fondamentale, non solo per l’esame, ma per progettare sistemi che rimangano sicuri anche in caso di fallimento dei singoli controlli.

Classificazione e Gestione dei Dati

La classificazione dei dati assegna etichette di sensibilità che determinano i requisiti di gestione. I framework governativi utilizzano le classificazioni Non Classificato, Riservato, Segreto e Top Secret. I framework commerciali usano tipicamente Pubblico, Interno, Confidenziale e Riservato (o equivalenti). La classificazione deve essere guidata dalla sensibilità dei dati e dagli obblighi normativi, non dalla convenienza.

I sistemi di Data Loss Prevention (DLP) applicano le policy di gestione ispezionando il contenuto su endpoint, punti di uscita dalla rete (egress) e storage cloud. Una regola DLP potrebbe bloccare gli allegati email contenenti stringhe di 16 cifre che corrispondono a modelli di carte di credito, o avvisare quando un utente carica un file contenente la frase “obiettivo di acquisizione” su un servizio di storage cloud personale. L’efficacia del DLP dipende da una classificazione accurata: se i dati sensibili non sono etichettati, il DLP non può proteggerli.

La sovranità dei dati (data sovereignty) riguarda il luogo in cui i dati risiedono fisicamente e le leggi della giurisdizione a cui sono soggetti. Il GDPR richiede che i dati personali dell’UE trasferiti al di fuori dell’UE siano protetti da decisioni di adeguatezza, Clausole Contrattuali Standard (Standard Contractual Clauses) o Norme Vincolanti d’Impresa (Binding Corporate Rules). Le organizzazioni che operano a livello globale devono mappare i flussi di dati e garantire che le sedi di archiviazione ed elaborazione siano conformi alle normative applicabili.

Crittografia in Transito e a Riposo

TLS 1.3 è lo standard attuale per la crittografia dei dati in transito. Elimina le suite di cifratura deboli, impone la forward secrecy (scambio di chiavi effimero Diffie-Hellman) e riduce l’handshake a un singolo round trip. TLS 1.0 e 1.1 sono deprecati; TLS 1.2 rimane accettabile ma deve essere configurato con suite di cifratura robuste. Una configurazione Nginx che impone gli standard attuali:

# Enforcing TLS 1.2+ in an Nginx server block
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

La crittografia a riposo (at rest) protegge i dati sui supporti di archiviazione. La crittografia dell’intero disco (BitLocker, FileVault, LUKS) cifra l’intero volume; la crittografia a livello di file (EFS, contenitori VeraCrypt) cifra i singoli file. La crittografia a livello di database (Transparent Data Encryption in SQL Server e Oracle) cifra i file di dati e i backup. L’aspetto critico da comprendere è che la crittografia a riposo protegge dal furto fisico dei supporti, ma non protegge da un’applicazione compromessa che ha già decifrato i dati per elaborarli.

Primitive Crittografiche

Gli algoritmi simmetrici (AES-128, AES-256, ChaCha20) utilizzano una singola chiave condivisa e sono veloci, adatti per grandi volumi di dati (bulk data). Gli algoritmi asimmetrici (RSA, ECDSA, Ed25519, ECDH) utilizzano coppie di chiavi e consentono lo scambio di chiavi, le firme digitali e l’associazione di identità (identity binding), ma sono computazionalmente onerosi. I sistemi ibridi, come TLS, utilizzano la crittografia asimmetrica per negoziare una chiave di sessione simmetrica, per poi crittografare simmetricamente il traffico di massa.

L’hashing (SHA-256, SHA-3) è una funzione unidirezionale che produce un digest di lunghezza fissa. Gli hash non sono crittografia: non possono essere invertiti con una chiave perché non esiste una chiave. Gli hash delle password con salt (utilizzando bcrypt, scrypt, Argon2 o PBKDF2) aggiungono un valore casuale per utente per sconfiggere le rainbow table. Gli hash forniscono la verifica dell’integrità; l’HMAC combina un hash con una chiave segreta per fornire sia integrità che autenticità.

Le modalità di cifratura (cipher modes) sono importanti tanto quanto l’algoritmo. AES in modalità ECB cifra ogni blocco in modo indipendente, producendo un testo cifrato identico per blocchi di testo in chiaro identici: una proprietà catastrofica che rivela i pattern dei dati. AES-GCM (Galois/Counter Mode) fornisce sia confidenzialità che integrità in un unico passaggio ed è lo standard per i protocolli moderni. La modalità CBC con un padding appropriato e un HMAC è accettabile, ma più complessa da implementare correttamente.

Gestione e Archiviazione delle Chiavi

La robustezza della crittografia dipende direttamente dalla gestione delle sue chiavi. Le chiavi devono essere generate con una forte entropia, archiviate separatamente dai dati che proteggono, ruotate secondo una pianificazione e distrutte quando non più in uso. Gli Hardware Security Module (HSM) forniscono archiviazione delle chiavi resistente alla manomissione (tamper-resistant) e accelerazione crittografica. Un Trusted Platform Module (TPM) è un chip sugli endpoint che archivia le chiavi utilizzate da BitLocker e dal measured boot. Il key escrow deposita una copia delle chiavi presso una terza parte fidata per il recupero legale, mentre i key recovery agent consentono alle aziende di decifrare i dati dei dipendenti quando necessario. I servizi KMS cloud (AWS KMS, Azure Key Vault, Google Cloud KMS) offrono la crittografia envelope, in cui una chiave di crittografia dei dati (DEK) protegge i dati ed è a sua volta crittografata da una chiave di crittografia delle chiavi (KEK) conservata nell’HSM.

Infrastruttura a Chiave Pubblica (PKI)

La PKI lega le identità alle chiavi pubbliche tramite certificati emessi da una Certificate Authority (CA). Una CA subordinata si collega a una CA radice (root CA) il cui certificato deve essere pre-autorizzato (pre-trusted). Il ciclo di vita del certificato inizia con una Certificate Signing Request (CSR) generata insieme a una chiave privata:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US"

La CA convalida il richiedente, firma la CSR ed emette un certificato X.509. La revoca viene pubblicata tramite Certificate Revocation List (CRL) — elenchi scaricati periodicamente di numeri di serie revocati — o tramite i responder Online Certificate Status Protocol (OCSP) che rispondono a query per singolo certificato in tempo reale. L’OCSP stapling consente al server di presentare uno stato recente e firmato durante l’handshake TLS, evitando le ricerche dal client alla CA. I certificati scadono e devono essere rinnovati; l’automazione tramite ACME (Let’s Encrypt, server ACME interni) previene le interruzioni di servizio dovute a certificati scaduti.

Firma del Codice e Convalida dell’Integrità

La firma del codice (code signing) utilizza la chiave privata di uno sviluppatore per firmare un artefatto software; i destinatari verificano la firma con il certificato dello sviluppatore, confermando sia l’integrità che l’origine. Questo protegge dalla manomissione della catena di fornitura (supply-chain tampering). Gli strumenti di monitoraggio dell’integrità dei file (Tripwire, AIDE) e la pubblicazione di hash (valori sha256sum accanto ai download) rilevano in modo simile le modifiche non autorizzate, ma l’hashing da solo dimostra solo che il file corrisponde a un valore, non autentica chi ha prodotto quel valore. Solo una firma digitale, supportata da una PKI, fornisce sia l’integrità che il non ripudio (non-repudiation).

Conservazione, Sanitizzazione e Smaltimento Sicuro

Le policy di conservazione (retention) definiscono per quanto tempo ogni classe di dati deve essere mantenuta e quando deve essere eliminata. Le normative spesso impongono sia dei minimi (registri finanziari per sette anni) sia dei massimi (dati personali conservati non più a lungo del necessario). I backup non sono esenti: se un interessato esercita il diritto alla cancellazione (right to erasure), l’organizzazione deve disporre di un processo difendibile per rimuovere tali dati dai backup o per documentare i vincoli tecnici e i controlli compensativi. I blocchi legali (legal hold) prevalgono sulla normale conservazione e “congelano” i dati durante un contenzioso.

Quando un supporto raggiunge la fine del suo ciclo di vita, la sanitizzazione deve essere adeguata alla sensibilità dei dati e alla destinazione del supporto. Lo standard NIST SP 800-88 definisce tre livelli: Clear (sovrascrittura logica, sufficiente per il riutilizzo all’interno dell’organizzazione), Purge (cancellazione crittografica, cancellazione a blocchi o degaussing, sufficiente per il riutilizzo all’esterno) e Destroy (distruzione fisica, disintegrazione, incenerimento, polverizzazione). La cancellazione crittografica (cryptographic erasure) — che consiste nel distruggere la chiave di cifratura rendendo il testo cifrato irrecuperabile — è rapida ed efficace per le unità auto-crittografanti (self-encrypting drives) da riutilizzare. Il degaussing rende inutilizzabili i supporti magnetici e non funziona sugli SSD. La distruzione fisica è l’unico metodo sicuro per i supporti danneggiati o per i dati con le più alte classificazioni di sicurezza.

Scenario Pratico: Violazione a Causa di una Gestione Fallimentare delle Chiavi

Un’azienda SaaS ha crittografato il suo database clienti utilizzando AES-256, ma ha archiviato la chiave di cifratura in un file di configurazione in chiaro (plaintext) nello stesso repository del codice dell’applicazione. Quando uno sviluppatore ha accidentalmente inviato (push) il repository a un account GitHub pubblico, un bot automatizzato per la scansione delle credenziali ha scoperto la chiave in 11 minuti. L’attaccante ha utilizzato la chiave per decrittare un backup del database che era stato archiviato in un bucket S3 accessibile pubblicamente (un’altra errata configurazione). La cifratura era tecnicamente corretta — AES-256 è inviolabile con un attacco brute force — ma la gestione delle chiavi (key management) era catastroficamente difettosa. Una corretta gestione delle chiavi avrebbe previsto l’archiviazione della chiave in un secrets manager (come AWS Secrets Manager o HashiCorp Vault) con accesso controllato tramite ruoli IAM, mai nel codice sorgente o nei file di configurazione.

← Sicurezza di Cloud · Tutti i domini · Continuità Operativa e Ripristino di Emergenza →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →