1. Perché serve la sicurezza informatica

Immagina uno studio notarile con l'archivio cartaceo, negli anni '80. Per rubare un documento importante, un ladro doveva entrare fisicamente nell'ufficio, cercarlo tra gli scaffali e portarlo via — lasciando dietro di sé una casella vuota, una porta forzata, qualcosa che prima o poi qualcuno avrebbe notato. Oggi lo stesso studio tiene vent'anni di documenti su un computer. Un estraneo può copiarli tutti senza mettere piede in ufficio, senza lasciare uno spazio vuoto sullo scaffale — e il proprietario può non accorgersene per mesi.

Questo è, in fondo, il motivo per cui esiste la sicurezza informatica: il mondo digitale ha regalato alle informazioni una comodità enorme (copiarle, spostarle, cercarle in un istante) ma gli ha tolto le protezioni "naturali" che aveva la carta — la necessità di un accesso fisico, la fatica di copiare a mano, il vuoto lasciato da un furto. La sicurezza informatica è, in un certo senso, la disciplina che studia come ricostruire in digitale le proprietà di sicurezza che il mondo cartaceo aveva quasi gratis.

Non è un problema astratto. Un'azienda meccanica del milanese ha ricevuto una mail, apparentemente dal proprio fornitore abituale, con un sollecito di pagamento: la contabile stava per versare 50.000€ sul conto indicato nella mail. Il fornitore vero, contattato per verifica, non aveva mai inviato quel messaggio. È un classico esempio di phishing, e mostra bene che la sicurezza informatica non è "solo software": un antivirus non ferma una mail che sembra legittima e convince una persona a fare un bonifico di sua spontanea volontà. Serve anche formazione, procedure di verifica, buon senso organizzativo.

2. La triade CIA: riservatezza, integrità, disponibilità

Quando si parla di "proteggere un dato", in realtà si stanno proteggendo tre proprietà diverse, che in inglese si ricordano con l'acronimo CIA (in italiano a volte RID): Confidentiality (riservatezza), Integrity (integrità), Availability (disponibilità). Capire quale di queste tre è in gioco aiuta a capire che tipo di problema stai affrontando.

• Riservatezza — solo chi è autorizzato può leggere l'informazione. Pensa a una busta chiusa consegnata a un dipendente: se quella busta viene lasciata aperta sulla scrivania della reception, la riservatezza è già violata — anche se nessuno l'ha effettivamente letta. Basta la possibilità che qualcuno non autorizzato potesse leggerla.
• Integrità — il dato deve restare genuino: nessuno deve averlo alterato, né per errore né apposta. Se firmi un contratto per 40.000€ e qualcuno lo modifica dopo la firma, quella modifica non ha alcun valore legale: non è più il documento che avevi accettato tu.
• Disponibilità — il dato o il servizio deve essere raggiungibile quando serve. Avere la ricetta medica giusta non serve a nulla se la farmacia è chiusa, o se il server che la contiene è spento o sotto attacco. Un dato "sicuro" ma irraggiungibile equivale, di fatto, a non averlo — ed è esattamente il motivo per cui un attacco ransomware è così devastante: non ruba i dati, li rende irraggiungibili.

3. Un quarto principio: il non ripudio

Alla triade CIA si affianca spesso un quarto principio: il non ripudio — la possibilità di attribuire un dato o un'azione a chi l'ha davvero compiuta, senza che questa persona possa negarlo in seguito. Pensa a SPID, l'identità digitale italiana: quando lo usi per firmare una pratica online, il sistema registra chi ha agito, cosa ha fatto e quando. Questo è ciò che dà valore legale all'operazione — senza non ripudio, gran parte dell'e-commerce e della pubblica amministrazione digitale come le conosciamo oggi non potrebbe funzionare, perché chiunque potrebbe negare di aver fatto un acquisto o firmato un documento.

4. Asset e misure di protezione

Tutto ciò che ha valore per un'organizzazione e va protetto si chiama asset: non solo i dati, ma anche i sistemi che li elaborano, le persone che ci lavorano, la reputazione stessa dell'azienda. Le misure per proteggere gli asset si dividono in due grandi famiglie, ed è un errore comune pensare che basti la prima:

• Misure tecniche — antivirus, firewall, cifratura, backup, autenticazione a più fattori: tutto ciò che si "compra e si installa".
• Misure organizzative — policy, formazione del personale, contratti con i fornitori che includono clausole di sicurezza: queste non si comprano, si scrivono — ed è esattamente il tema del Modulo 2.

Un errore che non ha nulla a che fare con l'hacking, ma che è pura sicurezza informatica: un dipendente che lascia l'azienda portandosi via — nella propria memoria, o peggio su una chiavetta — i contatti dei clienti. Nessun malware, nessun exploit: solo un buco nelle misure organizzative.

5. Attacchi, meccanismi, servizi

Tre parole che aiutano a mettere ordine in qualunque discussione di sicurezza. Pensa a un negozio: gli attacchi sono le rapine e i furti che potrebbero subire; i meccanismi sono gli strumenti concreti di difesa (serratura blindata, telecamere, allarme); i servizi sono l'obiettivo di più alto livello che quei meccanismi realizzano insieme (la "protezione del negozio"). Allo stesso modo, in informatica un servizio come "posta elettronica sicura" non è un prodotto singolo: è la somma di più meccanismi — password robuste, una policy su come sceglierle, cifratura del traffico, filtri antispam.

Da questa idea nasce il principio della difesa in profondità: non affidarsi mai a un unico meccanismo di protezione, perché se quello fallisce (o viene aggirato) non deve restare nient'altro tra l'attaccante e l'asset. Un singolo meccanismo la cui rottura fa crollare tutta la sicurezza si chiama single point of failure (punto singolo di fallimento) — e va sempre evitato, sia nella sicurezza sia, come vedrai nel Modulo 3, nella continuità operativa.

6. Da dove arriva un attacco: una prima classificazione

Un modo utile per orientarsi tra i tipi di attacco è chiedersi: quanto è vicino l'attaccante, e quanto si fa notare?

• Attacchi passivi — l'attaccante osserva senza interagire, come un investigatore che ti pedina per una città intera: non ti tocca, non ti parla, ma a fine giornata sa dove sei stato, con chi, per quanto tempo. Sono i più difficili da rilevare proprio perché non lasciano tracce di un'azione attiva (intercettazione del traffico, sniffing).
• Attacchi attivi — l'attaccante manomette o interrompe attivamente qualcosa, ed è quindi più facile da individuare. Esempio: un attacco DoS che manda giù un e-commerce proprio durante i saldi — qui il danno reale non è "i dati rubati" (non ce ne sono), è il fatturato perso ogni minuto che il sito resta irraggiungibile.
• Attacchi di prossimità (close-in) — richiedono all'attaccante di essere fisicamente vicino al bersaglio: leggere lo schermo di qualcuno alle spalle (shoulder surfing), lasciare una chiavetta USB infetta in un parcheggio aziendale sperando che qualcuno la infili incuriosito ("non è un regalo di Natale"), o presentarsi come un finto tecnico — di un ente energetico, di un fornitore — sfruttando la fiducia che le persone ripongono in una divisa o in un ruolo.
• Attacchi insider — arrivano da chi ha già accesso legittimo: è un po' come essere traditi da un amico. Un commerciale che, prima di passare alla concorrenza, si scarica l'intera anagrafica clienti su una chiavetta personale non usa nessuna tecnica di hacking: abusa semplicemente di un accesso che gli era stato concesso per fare il suo lavoro.
• Attacchi alla catena di distribuzione (supply chain) — colpiscono un fornitore per raggiungere, indirettamente, tutti i suoi clienti. Il caso più noto è SolarWinds (2020): un fornitore di software di monitoraggio IT usato da migliaia di aziende e agenzie governative si è visto inserire codice malevolo in un aggiornamento ufficiale. I clienti, semplicemente aggiornando il software come fanno sempre, si sono "auto-installati" una backdoor senza saperlo.

7. I vettori di attacco più comuni oggi

Al di là di come arriva un attacco, è utile conoscere le forme più diffuse che assume in pratica:

• Configurazione errata del cloud — non serve nemmeno un attaccante bravo: un'azienda che carica i propri backup su cloud e li lascia per errore accessibili pubblicamente si autodenuncia da sola. Casi così vengono scoperti anche mesi dopo, spesso da un ricercatore di sicurezza che scansiona internet.
• APT (Advanced Persistent Threat) — un attaccante che si infiltra e resta nascosto per mesi o anni, come una spia che si presenta come tecnico delle pulizie in un'ambasciata e lavora "in maniera impeccabile" finché non arriva il momento giusto per colpire.
• Virus e worm — un virus ha bisogno che qualcuno lo attivi (un click, un doppio clic su un allegato); un worm si propaga da solo sfruttando vulnerabilità di rete, senza bisogno di alcuna interazione umana. WannaCry (maggio 2017) è l'esempio da manuale di un worm: 200.000 macchine infettate in 150 paesi in appena 24 ore, colpito anche il servizio sanitario britannico (NHS) — nonostante Microsoft avesse già pubblicato la patch che chiudeva quella falla due mesi prima dell'attacco. La lezione non è tecnica, è organizzativa: la patch esisteva, semplicemente non era stata applicata in tempo.
• Ransomware — oggi spesso usa la tecnica della doppia estorsione: prima ruba i dati, poi li cifra. Così, anche se hai un backup perfettamente funzionante e puoi ripristinare tutto senza pagare, l'attaccante minaccia comunque di pubblicare i dati rubati se non paghi.
• Minacce mobile — i telefoni sono bersagli sempre più appetibili proprio perché li proteggiamo meno di un computer. Un attacco molto comune: un SMS di phishing che sembra provenire dalla propria banca — capace di ingannare chiunque, anche persone attente, se il momento è quello sbagliato.
• Botnet — una rete di dispositivi compromessi, spesso a insaputa dei proprietari, che agiscono insieme come un unico "esercito di zombie". Un singolo dispositivo debole (una telecamera economica, un router mai aggiornato) è quasi innocuo da solo, ma centomila insieme "abbattono qualunque porta". La botnet Mirai (2016) ha sfruttato le password di default lasciate su telecamere IP e router domestici per colpire Dyn, un fornitore di servizi DNS: per alcune ore, metà degli Stati Uniti non è riuscita a raggiungere Twitter, Netflix e Spotify.
• Phishing e le sue varianti — spear phishing (mirato su una persona specifica, spesso costruito con informazioni raccolte sui social), smishing (via SMS), vishing (via chiamata vocale, oggi reso ancora più credibile dalla clonazione della voce con l'IA). Il caso classico si chiama CEO fraud: una segretaria riceve una mail che sembra provenire dall'amministratore delegato, con la richiesta urgente di un bonifico da 50.000€ verso una banca all'estero — un bonifico fatto "di spontanea volontà" è quasi impossibile da recuperare.
• Minacce alle applicazioni web — oggi chiunque può costruire un sito o un'app con strumenti di IA generativa senza competenze tecniche, ma questo non lo rende sicuro: applicazioni create così vengono spesso violate nel giro di ore dalla pubblicazione.
• Minacce IoT — una smart TV in una sala riunioni, collegata alla stessa rete dei server gestionali e mai aggiornata da anni, è come una porta sul retro dell'edificio rimasta aperta. La contromisura più semplice è isolare i dispositivi IoT su una rete separata (una VLAN dedicata), così anche se vengono compromessi non hanno una via diretta verso i sistemi critici.

8. Cos'è una vulnerabilità

Immagina la porta di casa con una serratura difettosa. La vulnerabilità è il difetto della serratura in sé. L'exploit è la tecnica concreta per sfruttarlo — aprirla con una carta di credito, o con una forcina. La minaccia è l'esistenza di ladri nella zona. Il rischio, che vedrai tra poco, è la combinazione di tutto questo insieme al valore di ciò che c'è dentro casa.

Una vulnerabilità è "sfruttabile" solo se esiste davvero un modo pratico per approfittarne: un difetto puramente teorico che nessuno riesce a sfruttare concretamente resta un semplice bug, non una vulnerabilità in senso operativo. Le vulnerabilità si dividono in tre grandi famiglie, a seconda di dove si trova il difetto:

• Di rete — riguardano l'infrastruttura di comunicazione: protocolli mal configurati, servizi esposti che dovrebbero restare interni, dati trasmessi senza cifratura. Esempio da manuale: una stampante di rete la cui interfaccia web amministrativa, protetta solo dalla password di default, è raggiungibile anche dal Wi-Fi riservato agli ospiti.
• Di sistema — riguardano il sistema operativo: falle nel kernel, servizi non aggiornati, configurazioni di default lasciate invariate. In gran parte si risolvono con un patch management serio — cioè aggiornamenti pianificati e continui, non "quando capita".
• Delle applicazioni — riguardano il software che gira sul sistema, dal gestionale interno al sito web, fino al firmware del router: SQL injection, buffer overflow, controlli di autenticazione mal fatti.

9. Il ciclo di vita di una vulnerabilità e le CVE

Una vulnerabilità nasce quando viene scoperta (da un ricercatore, da un'azienda, a volte per caso), viene comunicata a chi può correggerla, poi viene pubblicata una patch. Ogni vulnerabilità nota e pubblica riceve un codice identificativo univoco, la CVE (Common Vulnerabilities and Exposures), e un punteggio di gravità, il CVSS, da 0 a 10.

Il periodo più pericoloso è quello tra la scoperta e la disponibilità di una patch: se la vulnerabilità viene sfruttata prima ancora che il produttore ne sia a conoscenza (e quindi prima che esista una correzione), si parla di exploit zero-day — i più pericolosi in assoluto, e i più costosi: un exploit zero-click capace di compromettere un iPhone leggendo solo un PDF malevolo può valere, sul mercato specializzato, alcuni milioni di dollari. Un esempio di vulnerabilità particolarmente grave e diffusa è Log4Shell (dicembre 2021): un punteggio CVSS di 10 su 10, capace di eseguire codice da remoto manipolando anche un singolo messaggio di log — e ha colpito anche aziende che non scrivevano una riga di codice Java, semplicemente perché quella libreria era una dipendenza nascosta di qualcos'altro.

Quando un ricercatore scopre una vulnerabilità, la prassi corretta si chiama responsible disclosure: comunicarla in modo riservato all'azienda coinvolta (spesso tramite piattaforme dedicate come HackerOne), dimostrando il problema con una prova di concetto, e concedere un periodo di tempo — tipicamente 90 giorni — prima di rendere pubblici i dettagli, così da lasciare il tempo di preparare una correzione. Il punteggio CVSS, va detto, non è sempre "neutro": a deciderlo è spesso il produttore stesso del software coinvolto, che ha un interesse (reputazionale, prima ancora che tecnico) a tenerlo più basso possibile — tranne nei casi di falle così gravi e conclamate che non lascerebbero spazio a nessuna discussione.

10. La Cyber Kill Chain: le sette fasi di un attacco

Ideata da Lockheed Martin ispirandosi a un concetto militare, la Cyber Kill Chain descrive un attacco informatico come una sequenza di sette fasi. L'idea più importante da portare a casa non è la lista in sé, ma questa: un attacco non è un evento istantaneo, è un processo — e basta riuscire a interrompere una sola delle sette fasi per fermarlo prima che faccia danni.

1. Reconnaissance — l'attaccante studia il bersaglio: profili LinkedIn dei dipendenti, repository pubblici su GitLab/GitHub, dispositivi esposti su internet trovabili con motori di ricerca specializzati come Shodan ("se cerchi 'telecamere' puoi arrivare a vedere le immagini in diretta di dispositivi mal configurati in tutto il mondo").
2. Weaponization — l'attaccante costruisce l'arma (un malware, un documento infetto) sui propri sistemi: fase invisibile ai difensori, perché avviene fuori dal loro perimetro.
3. Delivery — l'arma viene consegnata al bersaglio (mail, chiavetta USB, sito compromesso): è la prima fase che i difensori hanno una reale possibilità di rilevare.
4. Exploitation — l'arma viene attivata sul sistema bersaglio, sfruttando la vulnerabilità individuata.
5. Installation — l'attaccante installa un accesso persistente (una backdoor, un malware che sopravvive anche a un riavvio del sistema).
6. Command and Control (C2) — si apre un canale di comunicazione bidirezionale tra il sistema compromesso e l'attaccante. È una fase rilevabile osservando il traffico di rete: connessioni verso domini sospetti, a orari o con frequenze anomale, sono un campanello d'allarme — anche se l'attaccante usa servizi legittimi come Dropbox o Telegram per mascherare il canale.
7. Actions on Objectives — l'attaccante raggiunge finalmente il suo scopo: cifratura dei dati, furto di informazioni, sabotaggio, oppure — negli attacchi APT più sofisticati — movimento laterale verso altri sistemi della rete.

11. TTP: tattiche, tecniche, procedure

Quando i professionisti di sicurezza analizzano un gruppo di attaccanti, parlano spesso di TTP — Tattiche, Tecniche, Procedure. Il modo più semplice per distinguerle è un'analogia culinaria: la tattica è l'obiettivo generale ("preparare il pranzo"), la tecnica è il metodo scelto per raggiungerlo ("cuocere la pasta"), la procedura è l'esecuzione specifica e dettagliata ("5 litri d'acqua, 50 grammi di sale, 11 minuti di cottura"). Le procedure sono quasi una firma personale — un po' come la calligrafia di una persona: rendono un attaccante riconoscibile, perché tende a ripetere sempre gli stessi dettagli specifici, anche cambiando bersaglio.

È lo stesso principio della scienza forense: sulla scena di un crimine si raccolgono indizi, si confrontano con impronte già note, e si arriva a identificare un colpevole proprio dai dettagli che si ripetono. Il riferimento più usato nel settore per catalogare le TTP conosciute dei vari gruppi di attaccanti è la matrice MITRE ATT&CK, consultabile pubblicamente online.

12. Il rischio: come si misura

Il rischio informatico si calcola, tradizionalmente, come R = P × I × E, dove P è la probabilità che la minaccia si verifichi, I è l'impatto che avrebbe, ed E è l'efficacia dei controlli già in atto (più i controlli sono deboli, più il fattore pesa). Pensa a un ombrello: prima di uscire guardi il meteo (probabilità di pioggia), pensi a cosa devi fare oggi — un colloquio di lavoro importante o solo buttare la spazzatura (impatto se ti bagni), e valuti se hai già un impermeabile (efficacia dei controlli). Il rischio prima di prendere qualunque contromisura si chiama rischio inerente; quello che resta dopo aver applicato le difese si chiama rischio residuo — ed è quello che conta davvero, perché il rischio zero non esiste.

Per rendere il rischio concreto in termini economici si usano tre valori:

• SLE (Single Loss Expectancy) — quanto costa una singola occorrenza dell'evento.
• ARO (Annualized Rate of Occurrence) — quante volte ci si aspetta che accada in un anno.
• ALE (Annualized Loss Expectancy) — la perdita attesa in un anno, cioè SLE × ARO.

Un esempio concreto: un server web che genera 25.000$ l'ora di fatturato ha il 25% di probabilità di guastarsi nel corso dell'anno; un guasto comporterebbe 3 ore di fermo più 5.000$ di riparazione. SLE = (25.000$ × 3) + 5.000$ = 80.000$. ALE = 80.000$ × 25% = 20.000$ l'anno. A questo punto la domanda diventa gestionale: conviene investire in un sistema ridondante da 10.000$ una tantum, o continuare a rischiare 20.000$ l'anno? Attenzione però: l'ALE calcola solo il danno diretto e misurabile — non cattura facilmente il danno reputazionale, che per un servizio ad alta visibilità può valere molto di più del puro fermo tecnico.

13. Le quattro risposte possibili a un rischio

Una volta identificato e misurato un rischio, un'organizzazione ha sostanzialmente quattro strade, spesso combinate tra loro:

• Evitare (avoid) — eliminare del tutto la causa del rischio, ad esempio non offrendo più un servizio troppo esposto.
• Mitigare (mitigate) — ridurre la probabilità o l'impatto (è la strada più comune: patch, formazione, backup, controlli).
• Accettare (accept) — quando il costo della contromisura supera il danno atteso, si decide consapevolmente di convivere con il rischio, magari preparando un piano di emergenza.
• Trasferire (transfer) — spostare il peso economico del rischio su un terzo, tipicamente tramite un'assicurazione cyber.

Una regola pratica di buon senso, che vale quasi sempre: se un rischio ha probabilità alta ma impatto basso conviene mitigarlo con controlli economici; se ha impatto altissimo ma probabilità bassissima, spesso conviene trasferirlo con un'assicurazione piuttosto che spendere una fortuna per prevenire qualcosa di quasi impossibile.

1. Cosa sono le policy aziendali

Una policy è una decisione scritta dell'azienda su come ci si deve comportare rispetto a un certo aspetto della vita aziendale. Perché sia davvero una policy — e non solo un'abitudine informale che chiunque può ignorare — deve avere tre caratteristiche:

• Scritta — una regola che "tutti sanno" ma nessuno ha mai messo per iscritto non vale nulla se viene contestata.
• Approvata dal vertice aziendale — una policy nata sulla scrivania di un singolo responsabile IT, senza il supporto del management, non verrà mai applicata seriamente.
• Comunicata — anche una policy scritta e approvata, se resta chiusa in un cassetto, è inutile: va distribuita, fatta firmare per presa visione, aggiornata periodicamente.

Le policy aziendali si raggruppano in sei grandi famiglie: per i fornitori, per il personale, sull'uso accettabile delle risorse, sulle azioni disciplinari, la policy generale di sicurezza, e i piani di disaster recovery. Le vediamo una per una.

2. Policy per i fornitori (vendor)

Una banca può sembrare imprendibile guardandola dal portone principale: guardie armate, vetri antiproiettile, telecamere ovunque. Ma se l'azienda delle pulizie ha le chiavi del seminterrato e le passa al primo che paga di più, tutta quella difesa frontale non serve più a niente. È esattamente per questo che le policy per i fornitori esistono: la sicurezza di un'azienda non finisce al suo perimetro, si estende a tutta la sua supply chain.

Un caso reale: un dipendente di GitLab ha installato un'estensione malevola su Visual Studio Code (un normale editor di codice); il risultato è stato il furto di circa 3.800 repository di codice interni — un attacco supply chain nel senso più letterale, reso ancora più amaro dal fatto che VS Code è distribuito da Microsoft.

Le relazioni con i fornitori si formalizzano tipicamente in quattro tipi di documenti:

• SOP (Standard Operating Procedure) — il "libretto di istruzioni" condiviso: chi fa cosa, quando, come si gestisce un'emergenza alle 3 del mattino, chi si chiama per primo. Il meno affascinante dei quattro, ma il più utile quando le cose vanno davvero storte.
• SLA (Service Level Agreement) — traduce le aspettative in numeri misurabili: percentuale di disponibilità garantita, tempi di risposta e risoluzione, penali in caso di mancato rispetto.
• MOU/MOA — un accordo preliminare, meno vincolante, utile per collaborazioni temporanee o progetti pilota.
• ISA (Interconnection Security Agreement) — specifica i requisiti tecnici quando i sistemi informatici di due organizzazioni si collegano direttamente tra loro.

Per capire in pratica cosa significano le percentuali di un SLA, aiuta pensare ai cosiddetti "nove" di disponibilità: il 99% equivale a circa 7 ore di fermo al mese (accettabile per un sito vetrina senza vendite dirette); il 99,9% scende a circa 43 minuti al mese (adatto a un gestionale interno); il 99,99% a circa 4 minuti al mese (il livello tipico di banche online e grandi e-commerce); il 99,999% a circa 26 secondi al mese (telecomunicazioni critiche). Il punto da ricordare: passare da quattro a cinque "nove" può moltiplicare per dieci il costo dell'infrastruttura necessaria — il costo della disponibilità non cresce in modo lineare.

Con l'arrivo della direttiva europea NIS2, il tema dei fornitori è diventato ancora più delicato: se un attacco arriva attraverso un fornitore, la responsabilità tecnica può essere sua, ma la responsabilità di aver valutato correttamente quel rischio prima di affidargli dati o accessi resta dell'azienda che lo ha scelto. Le domande da porsi prima di firmare un contratto, oggi, includono: ho valutato il rischio cyber di questo fornitore? Il contratto prevede l'obbligo di notificarmi un incidente? Ha MFA, segmentazione di rete, un piano di risposta agli incidenti?

3. Policy per il personale

Molte policy sul personale sono nate, storicamente, nel settore bancario per un motivo molto pratico: scoprire le frodi interne.

• Ferie obbligatorie — chi sta frodando l'azienda difficilmente può permettersi di restare assente due settimane consecutive, perché in sua assenza chi lo sostituisce potrebbe notare le anomalie. Oggi la policy serve anche a prevenire il burnout e a trasferire forzatamente know-how a chi copre il ruolo. In Italia l'obbligo minimo (art. 2109 c.c.) è di almeno 4 settimane l'anno, di cui 2 consecutive.
• Rotazione dei ruoli (job rotation) — costruisce ridondanza umana: se solo una persona sa fare una cosa, quella persona è un single point of failure, un rischio sia per l'azienda (se si assenta o se ne va) sia per la persona stessa (che non può mai staccare del tutto). Va però calibrata al ruolo: un chirurgo o un ingegnere di sistemi critici non si "ruotano" con la stessa facilità di un ruolo amministrativo.
• Separazione dei compiti — il principio è: nessuno controlla l'intero processo da solo. In una pizzeria seria chi prende l'ordine non è chi incassa; in banca chi apre un conto non è chi lo autorizza. Vale anche in informatica: chi scrive codice non dovrebbe essere la stessa persona che lo mette in produzione, chi crea un utente non dovrebbe essere chi gli assegna i privilegi.

• Clean desk policy — impone di non lasciare materiale sensibile in vista sulla scrivania. In un audit di sicurezza fisica serale, un consulente ha fotografato in 20 minuti tre password su post-it sotto la tastiera, un organigramma in un cassetto senza chiave e il contratto di un cliente importante lasciato in un armadietto aperto — senza violare un solo sistema informatico.
• Background check — verifica di titoli di studio, casellario giudiziario, eventuali liste di sanzioni internazionali, condotta secondo i limiti del GDPR (principio di minimizzazione) e dello Statuto dei Lavoratori italiano, che vieta indagini sulle opinioni politiche, religiose o sindacali di un candidato.
• NDA (accordo di non divulgazione) — spesso firmato distrattamente tra i documenti di assunzione e poi dimenticato, ma essenziale in situazioni delicate: ad esempio prima che un penetration tester inizi a testare un sistema critico, per assicurarsi che non parli — nemmeno per leggerezza, magari su LinkedIn — di ciò che ha trovato.

Infine, la formazione continua: le minacce evolvono più in fretta di qualunque materiale didattico. Un corso anti-phishing fatto tre anni fa non copre il vishing con voce clonata dall'IA — oggi uno dei vettori più efficaci in assoluto, perché riconosci il timbro vocale del tuo responsabile e ti fidi istintivamente. La formazione efficace non è un video obbligatorio seguito da un quiz a crocette: è breve, ripetuta nel tempo, concreta, e idealmente misurata con simulazioni periodiche di phishing.

4. Acceptable Use Policy (AUP)

Definisce cosa i dipendenti possono e non possono fare con gli strumenti aziendali: uso personale di internet, installazione di software non autorizzato, dispositivi USB, cloud personali. Il rischio più concreto legato ai dispositivi rimovibili si chiama pod slurping — il nome viene dai primi iPod (anni 2000), usati come dischi esterni ad alta capacità per copiare di nascosto archivi aziendali interi; oggi il principio è identico con qualunque smartphone o chiavetta USB.

Un principio da ricordare: non bisogna confondere il vietare con l'impedire. Una policy senza un controllo tecnico che la faccia rispettare (blocco delle porte USB via Group Policy, soluzioni di prevenzione della perdita di dati, cifratura forzata) è solo carta firmata — una minaccia scritta, non una vera protezione.

5. Azioni disciplinari

Definiscono cosa succede quando un dipendente viola le regole. Tipicamente seguono una scala progressiva: richiamo verbale, richiamo scritto, sospensione, fino al licenziamento per giusta causa o, nei casi più gravi, un'azione legale. In Italia questa parte è regolata dall'art. 7 dello Statuto dei Lavoratori: le sanzioni sono applicabili solo se le regole erano state comunicate in anticipo (in bacheca, su intranet, consegnate direttamente), e devono essere proporzionate alla violazione — i giudici del lavoro annullano regolarmente licenziamenti sproporzionati rispetto al fatto contestato.

6. Policy generale di sicurezza e piano di disaster recovery

La general security policy è il documento "ombrello" che definisce la postura di sicurezza complessiva dell'azienda: principi, ruoli, responsabilità — la cornice dentro cui si inseriscono tutte le altre policy viste finora.

Il piano di disaster recovery, come sesta famiglia di policy, è il documento che raccoglie le procedure da seguire in caso di incidente grave. Qui ci limitiamo a inquadrarlo come documento organizzativo: il modo in cui si calcola quanto vale davvero un'ora di fermo, come si stima il rischio (ALE/SLE/ARO) e i concetti di RTO/RPO li trovi già nel Modulo 1; l'implementazione tecnica concreta — RAID, strategie di backup — è nel Modulo 3.

7. Legge o standard? Una distinzione da non confondere

Una legge è come il codice della strada: lo Stato la fa rispettare con sanzioni, e vale per tutti, senza eccezioni. Uno standard è più simile a un bollino di qualità come quelli del settore alimentare: nessuna legge ti obbliga ad averlo, ma se vuoi vendere in un certo mercato conviene, e a volte è di fatto indispensabile. Ci sono casi ibridi interessanti: il PCI-DSS è tecnicamente uno standard (imposto per contratto dai circuiti di pagamento come Visa e Mastercard, non da una legge), ma è di fatto obbligatorio per chiunque accetti pagamenti con carta; la certificazione ISO 27001 non è richiesta per legge, ma è sempre più spesso un requisito d'accesso nei bandi pubblici italiani ed europei.

8. PCI-DSS

Si applica a chiunque memorizzi, elabori o trasmetta dati di carte di pagamento: non solo grandi e-commerce, ma anche un ristorante col POS, un hotel, un distributore di benzina. Prevede quattro livelli di conformità in base al volume di transazioni annue gestite.

La regola d'oro, per una piccola attività, è semplice: se non sei un'azienda specializzata in pagamenti, non memorizzare tu stesso i dati della carta. Un ristorante che usa il POS fornito dalla propria banca, senza salvare i numeri di carta nei propri sistemi, scarica sulla banca la gran parte degli obblighi PCI-DSS; se sviluppasse un proprio gestionale che li memorizza, entrerebbe in un mondo di obblighi molto più complesso e costoso. Le conseguenze di una violazione includono multe dai circuiti di pagamento (anche decine di migliaia di euro), la possibile revoca della capacità di accettare carte — oggi quasi una condanna commerciale — oltre a costi forensi e obblighi di notifica.

9. ISO 27001

Si basa su un ciclo continuo — Plan-Do-Check-Act — non su un adempimento una tantum: pianificare, implementare, verificare, migliorare, e ricominciare. Il suo "Allegato A" elenca 93 controlli concreti, raggruppati in quattro aree: organizzativi, relativi alle persone, fisici, tecnologici. Per una PMI italiana di 50-100 persone, ottenere la certificazione costa indicativamente 15.000-40.000€ il primo anno, più 5.000-10.000€ l'anno di mantenimento.

10. SOX (Sarbanes-Oxley Act)

Nata negli Stati Uniti nel 2002, dopo gli scandali finanziari Enron e Worldcom — bilanci truccati per un decennio, crollo improvviso, azionisti e dipendenti rovinati (negli USA la pensione dipende spesso dai contributi versati, quindi il fallimento di un'azienda può danneggiare anche la pensione dei suoi stessi dipendenti). L'equivalente italiano, dopo il crack Parmalat del 2005, è la legge sul risparmio (D.Lgs. 262).

La rilevanza informatica è diretta: se i bilanci di un'azienda dipendono da sistemi informatici — e oggi è sempre così — quei sistemi devono avere controlli seri su chi vi accede, log delle modifiche, e revisioni esterne annuali.

11. DMCA e diritto d'autore

Il DMCA (Digital Millennium Copyright Act, USA) vieta di aggirare le protezioni tecnologiche di un'opera (DRM) e introduce il meccanismo del safe harbor: una piattaforma non è responsabile dei contenuti caricati dai suoi utenti, a patto che li rimuova rapidamente se le viene segnalata una violazione — è il meccanismo dietro alle rimozioni di contenuti su YouTube. In Italia ed Europa il riferimento è la legge sul diritto d'autore del 1941 (più volte aggiornata) e la direttiva UE 2019 sul copyright nel mercato unico digitale; le sanzioni sono gestite dall'AGCOM, che può anche ordinare il blocco DNS di siti pirata. Un aspetto di sicurezza spesso sottovalutato: molti siti che distribuiscono contenuti piratati veicolano malware nei file scaricati o nei link cliccati — non è un rischio solo legale, è anche un rischio tecnico concreto.

12. FISMA e il quadro normativo italiano/UE per la Pubblica Amministrazione

Il FISMA (Federal Information Security Management Act, USA 2002) ha poca rilevanza diretta in Italia, ma il principio che rappresenta è universale: uno Stato impone standard minimi di sicurezza alle proprie agenzie pubbliche, e questi obblighi si propagano lungo tutta la filiera dei fornitori. In Italia ed Europa l'equivalente si costruisce attraverso più livelli: il CAD (Codice dell'Amministrazione Digitale), le linee guida tecniche di AGID, l'ACN (Agenzia per la Cybersicurezza Nazionale, che dal 2021 qualifica anche i fornitori cloud per la PA), il perimetro di sicurezza nazionale cibernetica (2019) e, più di recente, la NIS2 (recepita in Italia col D.Lgs. 138/2024).

13. GDPR: il regolamento europeo sulla protezione dei dati

Il GDPR si basa su sette principi fondamentali: liceità/correttezza/trasparenza (il trattamento deve avere una base giuridica ed essere comprensibile per l'interessato), limitazione delle finalità, minimizzazione (raccogliere solo i dati davvero necessari), accuratezza, limitazione della conservazione (un CV inviato a un'azienda che non assume non può restare archiviato per anni: 12-24 mesi è un limite ragionevole, non 15 anni), sicurezza, e responsabilizzazione (accountability) — non basta rispettare il regolamento, bisogna poterlo dimostrare con registri dei trattamenti, log, prove di formazione erogata al personale.

I ruoli previsti: l'interessato (tu, quando lasci la tua mail su un sito), il titolare del trattamento (l'azienda che decide finalità e modalità del trattamento), il responsabile del trattamento (chi tratta i dati per conto del titolare, es. un fornitore cloud), il DPO — Data Protection Officer — obbligatorio per la PA e per trattamenti su larga scala di dati sensibili, e il Garante per la protezione dei dati personali, l'autorità di controllo.

I diritti dell'interessato: accesso ai propri dati, rettifica, cancellazione (il celebre "diritto all'oblio"), limitazione del trattamento, portabilità (poter trasferire i propri dati a un altro fornitore), opposizione (ad esempio a comunicazioni di marketing), e il diritto a non essere sottoposto a decisioni prese in modo completamente automatizzato senza intervento umano.

I dati sanitari meritano un discorso a parte. Negli Stati Uniti li regola l'HIPAA (Health Insurance Portability and Accountability Act): una privacy rule su chi può accedervi e con quale scopo, una security rule con i controlli tecnici obbligatori, un'enforcement rule che fissa le sanzioni (fino a 1,5 milioni di dollari per violazione). In Europa, il GDPR li classifica come "categorie particolari di dati personali" all'articolo 9: trattabili solo con consenso esplicito, per finalità di cura da parte di professionisti soggetti a segreto professionale, o per motivi di interesse pubblico sanitario. È esattamente quello che è successo durante il Covid: il Green Pass comunicava, di fatto, informazioni sul proprio stato sanitario; i termometri agli ingressi dei luoghi di lavoro misuravano (spesso male) la temperatura corporea; il datore di lavoro poteva, in certe condizioni, sapere se un dipendente si fosse vaccinato — situazioni normalmente impensabili, giustificate solo dall'eccezionalità dell'emergenza sanitaria.

Perché i dati sanitari sono considerati più sensibili di altri? Perché rappresentano lo stato della persona "in sé per sé": possono rivelare pericoli o rischi di contagio, sono spesso impossibili da cambiare (a differenza di una password), e possono incidere direttamente sulla dignità di una persona o sulle sue opportunità di lavoro. È anche per questo che, ad esempio, l'amministratore delegato di un'azienda non può consultare il fascicolo sanitario di un candidato: può al massimo richiedere una visita medica specifica legata alla mansione, mai accedere in autonomia alla sua storia clinica.

Un ultimo esempio, molto attuale: un'app di fitness che tiene traccia del battito cardiaco e dei percorsi di corsa sembra innocua, ma se il suo database cloud viene violato, quei dati rivelano molto più di quanto sembri — orari di uscita e di rientro, percorsi abituali, dove abiti, dove lavori, condizioni fisiche, ore di sonno. Un disastro sia per l'utente coinvolto sia, in termini di sanzioni e reputazione, per l'azienda che gestiva quei dati.

1. RAID e backup non sono la stessa cosa

È l'errore concettuale più comune in assoluto, e vale la pena chiarirlo subito: un sistema RAID e un backup risolvono due problemi diversi, e uno non sostituisce l'altro — sono complementari. Il RAID protegge dalla rottura fisica di un disco: se un componente si guasta, il sistema continua a funzionare senza interruzioni. Non protegge da nulla di ciò che riguarda il contenuto dei dati: se cancelli per errore un file, se un ransomware li cifra tutti, se un bug applicativo li corrompe, il RAID copia fedelmente anche l'errore su tutti i dischi, in tempo reale. Solo un backup — una copia separata, in un momento diverso, idealmente in un posto diverso — ti permette di tornare indietro nel tempo a prima del disastro.

2. Il sistema RAID: dischi che si aiutano a vicenda

RAID sta per Redundant Array of Independent Disks: un metodo per far lavorare insieme due o più dischi fisici, che il sistema operativo vede e tratta come se fossero un unico disco logico. A seconda di come i dischi vengono combinati, si ottengono equilibri diversi tra velocità, capacità e protezione dai guasti:

• RAID 0 (stripe) — i dati vengono distribuiti su più dischi per aumentare la velocità e sommare lo spazio disponibile. Non offre nessuna protezione: se si rompe anche un solo disco, l'intero array — e tutti i suoi dati — è perso. È l'equivalente di scrivere metà di un documento su un foglio e metà su un altro: se perdi un foglio, il documento non ha più senso.
• RAID 1 (mirroring) — ogni disco è una copia identica e speculare dell'altro. Se uno dei due si rompe, l'altro contiene comunque tutti i dati intatti. Semplice ed efficace, ma "costoso": metà dello spazio totale dei dischi è, di fatto, una copia.
• RAID 5 — distribuisce i dati su più dischi insieme a informazioni di parità (calcolate con l'operatore matematico XOR), che permettono di ricostruire i dati anche se un disco si guasta. Richiede almeno 3 dischi ed è oggi uno dei livelli più diffusi, perché bilancia bene capacità, prestazioni e protezione.
• RAID 10 — combina mirroring e stripe: prestazioni molto elevate insieme a una buona tolleranza ai guasti, al costo di richiedere almeno 4 dischi e di "sacrificare" metà della capacità totale, esattamente come il RAID 1.

Il meccanismo della parità funziona grazie a una proprietà matematica dell'operatore XOR: A xor B xor B = A. In pratica, il sistema calcola un "disco di parità" a partire dal contenuto degli altri dischi; se uno di questi si guasta, basta rifare l'operazione XOR tra i dischi rimasti e il disco di parità per ricostruire esattamente il contenuto perduto — senza aver mai fatto una vera "copia" di sicurezza di quei dati.

3. Il backup e le sue tre forme

Un backup è una copia dei dati, realizzata in un momento preciso e conservata su un supporto separato — idealmente anche in un luogo fisico diverso da quello dove i dati "vivono" normalmente. Esistono tre strategie principali, ciascuna con i propri compromessi:

• Backup completo — copia tutto, ogni volta. È il più semplice da ripristinare (basta un solo backup), ma anche il più lento e pesante da eseguire, soprattutto su grandi volumi di dati.
• Backup incrementale — copia solo ciò che è cambiato dall'ultimo backup di qualsiasi tipo (completo o incrementale). È il più veloce da eseguire, ma il ripristino richiede l'intera catena: l'ultimo completo più tutti gli incrementali successivi, in ordine — se manca anche solo un anello della catena, il ripristino si interrompe lì.
• Backup differenziale — copia tutto ciò che è cambiato dall'ultimo backup completo (non dall'ultimo differenziale). È una via di mezzo: più lento da eseguire di un incrementale (perché ogni volta copia sempre di più, man mano che passa il tempo dall'ultimo completo), ma molto più semplice da ripristinare, perché bastano solo due backup — l'ultimo completo e l'ultimo differenziale.

Non esiste una scelta "giusta" in assoluto: dipende da quanto tempo hai per fare il backup ogni notte, da quanto velocemente devi poter ripristinare, e da quanto spazio di archiviazione hai a disposizione.

4. Costruire una strategia: lo schema GFS

Per decidere quando fare ciascun tipo di backup e per quanto tempo conservarlo, lo schema più diffuso si chiama GFS — Grandfather-Father-Son (nonno-padre-figlio) — ispirato al modo in cui un tempo si organizzava la rotazione dei nastri magnetici:

• Figli — backup incrementali, eseguiti ogni giorno feriale.
• Padri — backup differenziali, eseguiti settimanalmente (ad esempio ogni venerdì).
• Nonni — backup completi, eseguiti mensilmente.

Il risultato è un compromesso intelligente: i backup quotidiani sono veloci e leggeri (incrementali), quelli settimanali offrono un ripristino più semplice (differenziali), e una fotografia completa e pulita dell'intero sistema resta comunque disponibile ogni mese.

5. RTO e RPO: quanto puoi restare fermo, quanto puoi perdere

Due valori aiutano a tradurre le esigenze di un'azienda in requisiti tecnici precisi per RAID e backup:

• RTO (Recovery Time Objective) — quanto tempo può restare fermo un sistema prima che il danno diventi inaccettabile.
• RPO (Recovery Point Objective) — quanti dati (in termini di tempo) l'azienda può permettersi di perdere, cioè quanto è "vecchio" al massimo l'ultimo backup utilizzabile.

Questi due valori cambiano moltissimo a seconda del tipo di attività. Una banca può avere un RTO di appena 15 minuti e un RPO vicino allo zero: pochissimi dati, se non nessuno, possono andare persi, e il sistema deve tornare operativo quasi subito. Una piccola attività artigianale può invece permettersi un RTO più lungo — magari alcune ore — e un RPO anche di un'intera giornata: perdere le modifiche di un solo giorno di lavoro è un fastidio, non una catastrofe. Non esiste un RTO/RPO "giusto" in senso assoluto: dipende da quanto costa, per quella specifica attività, restare ferma o perdere quei dati — ed è esattamente il calcolo del rischio che hai visto nel Modulo 1.

6. Cloud computing: SaaS, PaaS, IaaS

Il cloud computing permette di usare risorse informatiche (server, spazio di archiviazione, software) gestite da un fornitore esterno, pagando in base al consumo invece di comprare e mantenere hardware proprio. I tre modelli principali si distinguono per quanto del sistema è gestito da te e quanto dal fornitore — pensa alla differenza tra costruire una casa, affittare un appartamento arredato, o prenotare una stanza d'albergo con servizio incluso:

• IaaS (Infrastructure as a Service) — affitti l'infrastruttura di base: server, storage, rete. Sei tu a installarci sopra sistema operativo e applicazioni — è come affittare un terreno con gli allacci già pronti, ma la casa te la costruisci tu.
• PaaS (Platform as a Service) — il fornitore ti dà anche una piattaforma pronta per sviluppare e distribuire applicazioni, senza doverti preoccupare del server sottostante — è l'appartamento già arredato: ti concentri su come vivi lo spazio, non su tubature ed elettricità.
• SaaS (Software as a Service) — usi direttamente un'applicazione già completa e funzionante, accessibile da browser — è la stanza d'albergo: arrivi, e tutto è già pronto per l'uso. Se hai mai usato Gmail, Google Docs o Office 365, hai già usato una soluzione SaaS.

7. Modelli di distribuzione e rischi del cloud

Il cloud si distribuisce anche secondo modelli diversi: privato (a uso esclusivo di una singola organizzazione), pubblico (aperto a chiunque, come la maggior parte dei servizi cloud consumer), community (condiviso da un gruppo specifico di organizzazioni con esigenze comuni) e ibrido (una combinazione dei precedenti).

Affidarsi al cloud comporta anche rischi specifici da conoscere: la gestione dei privilegi diventa più delicata quando i dati non sono più "in casa"; la segregazione dei dati — visto che spesso più clienti condividono la stessa infrastruttura fisica del fornitore — richiede fiducia nell'isolamento tecnico tra un cliente e l'altro; e la conformità normativa resta comunque una responsabilità tua, anche se i dati fisicamente risiedono altrove — un principio che hai già incontrato nel Modulo 2 a proposito della responsabilità verso i fornitori.

8. Virtualizzazione e hypervisor

La virtualizzazione permette di eseguire più "computer" logici (le macchine virtuali) su un'unica macchina fisica, condividendone l'hardware. Il programma che rende possibile questa magia si chiama hypervisor, ed esiste in due forme:

• Tipo 1 (bare metal) — gira direttamente sull'hardware, senza un sistema operativo "normale" sotto di sé. Più efficiente e più usato in ambito server/aziendale. Esempi reali citati anche a lezione: VMware ESXi, Microsoft Hyper-V.
• Tipo 2 (hosted) — gira come una normale applicazione sopra un sistema operativo già esistente (Windows, macOS, Linux). Più comodo per uso personale o di test — VirtualBox, usato anche per il laboratorio di questo corso, è un hypervisor di tipo 2 — spesso gratuito, ma con qualche perdita di prestazioni rispetto al tipo 1.

Un vantaggio chiave della virtualizzazione, dal punto di vista della sicurezza: le macchine virtuali sono isolate tra loro. Se una VM viene compromessa da un malware, in condizioni normali il danno resta contenuto a quella singola macchina virtuale, senza propagarsi automaticamente alle altre sullo stesso hardware fisico.

9. Container: un'alternativa più leggera

I container sono un'alternativa più leggera alla virtualizzazione tradizionale: invece di simulare un intero computer con il proprio sistema operativo, condividono il kernel del sistema operativo host e isolano solo l'applicazione e le sue dipendenze. Questo li rende più veloci da avviare e permette di farne girare molti di più sulla stessa macchina fisica rispetto a un pari numero di macchine virtuali complete.

Il compromesso è sulla sicurezza: una macchina virtuale isola sia l'applicazione sia l'intero sistema operativo, mentre un container isola solo l'applicazione, condividendo il kernel con tutti gli altri container sulla stessa macchina. Se un'applicazione in un container viene compromessa, in teoria ha una superficie potenziale di attacco più ampia verso il resto del sistema rispetto a un'applicazione isolata in una VM completa. Per questo, oggi, la maggior parte delle aziende non sceglie "o l'uno o l'altro": usa una combinazione di entrambi, a seconda del carico di lavoro.

10. VDE e VDI: il desktop che vive altrove

Un'ultima applicazione della virtualizzazione riguarda il posto di lavoro stesso. Con un VDE (Virtual Desktop Environment) l'utente lavora su una sessione remota: vede sul proprio schermo cartelle, finestre e programmi, ma tutto è in realtà eseguito ed archiviato su un server lontano — è il principio dietro ai cosiddetti thin client. Con un VDI (Virtual Desktop Infrastructure) il desktop dell'utente gira dentro una vera e propria macchina virtuale ospitata in un data center. Il vantaggio comune a entrambi: se il dispositivo fisico dell'utente viene perso, rubato o danneggiato, nessun dato aziendale reale era effettivamente memorizzato lì sopra.

1. Perché esiste la crittografia

Immagina di dover mandare a un amico, per posta, il codice della tua cassaforte. Non puoi scriverlo in chiaro su una cartolina: chiunque la maneggi lungo il tragitto — il postino, un vicino curioso, chiunque — lo leggerebbe. Ti serve un modo per scrivere quel numero in modo che, se anche qualcuno lo intercetta, non riesca a capirlo. Solo il tuo amico, che sa come "tradurlo" indietro, deve poterlo leggere.

Questo è esattamente il problema che la crittografia risolve nel mondo digitale: trasformare un'informazione leggibile (testo in chiaro) in una forma illeggibile a chiunque non abbia il permesso di leggerla (testo cifrato), in modo che sia però possibile, per chi ha il permesso, tornare indietro e recuperare l'originale.

Non è un'invenzione recente: gli eserciti la usano da secoli per mandare ordini senza che il nemico li capisca se li intercetta. Oggi la usiamo ogni volta che mandiamo un messaggio WhatsApp, facciamo un acquisto online o vediamo il lucchetto accanto all'indirizzo di un sito web — anche se non ce ne accorgiamo.

2. Il vocabolario di base

Prima di andare avanti, fissiamo quattro parole che userai in tutto il modulo:

• Testo in chiaro (in inglese plaintext) — il messaggio originale, leggibile da chiunque.
• Testo cifrato (ciphertext) — lo stesso messaggio dopo la trasformazione, illeggibile senza la chiave giusta.
• Algoritmo di cifratura — la "procedura" matematica che trasforma il testo in chiaro in testo cifrato (e viceversa, per decifrare).
• Chiave — un valore segreto (un numero, in pratica) che l'algoritmo usa per personalizzare la trasformazione. Stesso algoritmo, chiavi diverse: risultati diversi.

Pensa all'algoritmo come al modello di lucchetto — sempre uguale, e chiunque può comprarne uno identico al negozio — mentre la chiave è la combinazione specifica di quel lucchetto, quella sì privata. Questa distinzione è così importante che ha un nome tutto suo.

3. Un rapido viaggio nella storia

Vedere come si cifrava prima dei computer aiuta a capire le due idee di base che, in fondo, usiamo ancora oggi.

La sostituzione. Il trucco più antico: sostituire ogni lettera con un'altra, seguendo una regola fissa. La cifratura di Cesare (II secolo, si narra usata da Giulio Cesare) spostava ogni lettera di tre posizioni nell'alfabeto: la "A" diventava "D", la "B" diventava "E", e così via. "CIAO" diventava "FLDR". Semplicissima da usare, ma anche semplicissima da rompere: bastano al massimo 25 tentativi per indovinare lo spostamento.

La trasposizione. Invece di cambiare le lettere, si cambia il loro ordine. La scitala lacedemonica spartana (400 a.C. circa) era un bastone attorno a cui si avvolgeva una striscia di cuoio: si scriveva il messaggio lungo il bastone, poi si srotolava la striscia, che a quel punto mostrava lettere apparentemente senza senso. Solo chi aveva un bastone dello stesso diametro poteva riavvolgerla e leggere il messaggio: il diametro, in pratica, era la chiave.

Da qui in poi le tecniche si sono complicate — il cifrario Playfair della Prima Guerra Mondiale cifrava coppie di lettere alla volta, usando una griglia 5×5 costruita a partire da una parola chiave — fino ad arrivare a Enigma, la macchina elettromeccanica usata dalla Germania nella Seconda Guerra Mondiale: una tastiera, un intricato sistema di rotori che cambiava la sostituzione a ogni lettera digitata, e un pannello di lampadine che mostrava il risultato cifrato. Fu proprio la sua complessità — insieme a un errore umano nell'uso — a renderla, alla fine, decifrabile dai crittoanalisti alleati a Bletchley Park.

Il punto da portare a casa: sostituzione e trasposizione sono i due mattoni di base. Gli algoritmi moderni che vedrai tra poco (come l'AES) li combinano entrambi, ripetuti per molti "giri" successivi, resi robusti dalla potenza di calcolo di un computer invece che da carta e penna.

4. La crittografia simmetrica: una chiave sola

Immagina un baule con un solo lucchetto. Tu hai una copia della chiave, il tuo destinatario ne ha un'altra copia identica. Tu chiudi il baule con la tua chiave, glielo spedisci, e lui lo apre con la sua. Questo è, in sintesi, il funzionamento della crittografia simmetrica (o a chiave privata): la stessa identica chiave serve sia per cifrare sia per decifrare.

È veloce ed efficiente — perfetta per cifrare grandi quantità di dati, come un intero hard disk o il traffico di una videochiamata. Gli algoritmi simmetrici lavorano in due modi diversi:

• Cifrari a flusso (es. RC4) — cifrano un bit alla volta, come un rubinetto continuo di dati.
• Cifrari a blocco (es. DES, 3DES, AES, Blowfish) — dividono il messaggio in blocchi di dimensione fissa e cifrano un blocco alla volta.

Il DES, sviluppato da IBM nel 1976, usava chiavi da 56 bit ed è stato per decenni lo standard — finché nel 1998 non è stato violato (con abbastanza potenza di calcolo, si può letteralmente provare ogni chiave possibile). Da qui il 3DES (applica DES tre volte con chiavi diverse, per guadagnare robustezza) e infine, nel 2001, l'AES (Advanced Encryption Standard): oggi è l'algoritmo simmetrico più usato al mondo, e a oggi non si conoscono attacchi capaci di romperlo in tempi ragionevoli.

5. Il problema (grosso) dello scambio delle chiavi

Torniamo al baule con il lucchetto. C'è un difetto evidente: prima di potersi scrivere in segreto, tu e il tuo destinatario dovete già essersi scambiati una copia identica della chiave — e quello scambio, se avviene su un canale che qualcuno può intercettare (come internet), è il punto debole di tutto il sistema. Se un intruso intercetta la chiave durante la consegna, può leggere tutto quello che verrà cifrato dopo, senza che nessuno se ne accorga.

È un problema che sembra un cane che si morde la coda: per comunicare in segreto serve già un segreto condiviso. Nel 1976 due ricercatori, Whitfield Diffie e Martin Hellman, trovarono un modo elegante per aggirarlo.

Una variante più moderna, usata molto sui dispositivi con poca potenza di calcolo (smartphone, oggetti IoT), è la Elliptic Curve Cryptography (ECC): ottiene lo stesso livello di sicurezza di Diffie-Hellman "classico" ma con chiavi molto più corte, quindi calcoli più veloci.

6. La crittografia asimmetrica: due chiavi, non una

Pensa a una cassetta della posta di quelle vecchie, con una fessura sul davanti e uno sportellino sul retro chiuso a chiave. Chiunque può imbucare una lettera nella fessura — non serve nessuna chiave per farlo. Ma solo tu, che hai la chiave dello sportellino sul retro, puoi aprirlo e leggere quello che è stato imbucato.

Questa è l'idea della crittografia asimmetrica (o a chiave pubblica): invece di un'unica chiave condivisa, ognuno genera una coppia di chiavi collegate matematicamente tra loro:

• una chiave pubblica — la fessura della cassetta: la puoi dare a chiunque, pubblicarla online, non serve proteggerla;
• una chiave privata — la chiave dello sportellino sul retro: questa sì che resta segreta, solo tua.

Chi vuole mandarti un messaggio segreto usa la tua chiave pubblica per cifrarlo. Una volta cifrato in questo modo, solo la chiave privata corrispondente può decifrarlo — nemmeno chi ha appena cifrato il messaggio può tornare indietro. In pratica scompare il problema visto prima: non devi più far viaggiare nessuna chiave segreta, perché quella pubblica può girare liberamente per definizione.

L'algoritmo asimmetrico più famoso è RSA (dalle iniziali dei suoi inventori: Rivest, Shamir, Adleman, 1977), basato sul fatto che moltiplicare due numeri primi molto grandi è facilissimo per un computer, ma fare il percorso inverso — scomporre il risultato nei suoi due fattori originali — è quasi impossibile in tempi ragionevoli, anche per computer potenti.

Il prezzo da pagare è la velocità: la crittografia asimmetrica è molto più "pesante" da calcolare rispetto a quella simmetrica. Per questo, nella pratica, i due mondi collaborano: si usa la crittografia asimmetrica solo per scambiarsi in sicurezza una chiave simmetrica temporanea, e poi si cifra il grosso dei dati con quella (veloce). È esattamente quello che succede ogni volta che il tuo browser si collega a un sito con il lucchetto (HTTPS).

7. Le funzioni di hash: l'impronta digitale dei dati

Fin qui abbiamo parlato di nascondere un contenuto. Le funzioni di hash risolvono un problema diverso: verificare che un contenuto non sia stato alterato, senza doverlo confrontare byte per byte.

Una funzione di hash prende in input qualsiasi cosa — un file da un megabyte o un intero film da 4 gigabyte, non importa — e restituisce sempre una stringa di lunghezza fissa, chiamata digest (o semplicemente "hash"): pensa all'impronta digitale di una persona. È corta, sempre della stessa lunghezza qualunque sia la "taglia" della persona, e — se la persona non cambia — resta sempre identica.

Tre proprietà rendono utile un buon algoritmo di hash:

• È deterministico: lo stesso file produce sempre lo stesso hash.
• Basta cambiare un solo carattere nel file originale perché l'hash risultante cambi in modo completamente diverso e imprevedibile.
• Non è invertibile: dall'hash non puoi ricostruire il file di partenza (è "a senso unico" — da qui il fatto che non è vera e propria crittografia, perché non c'è nulla da "decifrare").

Gli usi pratici sono ovunque: verificare che un file scaricato non sia corrotto o manomesso, controllare l'integrità dei file di sistema, e soprattutto memorizzare le password. Un sistema serio non salva mai la tua password in chiaro: salva il suo hash. Quando fai login, ricalcola l'hash di quello che hai digitato e lo confronta con quello salvato — se combaciano, sei tu (con buona probabilità). Così, anche se il database viene rubato, chi lo ruba non trova le password vere, solo le loro impronte.

Gli algoritmi più diffusi sono la famiglia SHA (Secure Hash Algorithm — SHA-2 è oggi lo standard) e MD5, ormai considerato debole e da evitare per usi seri.

C'è un attacco più subdolo che sfrutta proprio la probabilità di collisione, chiamato attacco del compleanno: prende il nome dal fatto, controintuitivo, che in un gruppo di sole 23 persone c'è già più del 50% di probabilità che due condividano lo stesso compleanno — molte meno persone di quanto ci si aspetterebbe istintivamente (365 giorni). Allo stesso modo, trovare una qualsiasi coppia di file con lo stesso hash richiede molti meno tentativi di quanto sembri a prima vista.

Un altro rischio riguarda proprio le password: un attaccante può pre-calcolare gli hash di milioni di password comuni e conservarli in tabelle già pronte, chiamate rainbow table, per poi cercare rapidamente una corrispondenza in un database rubato. La difesa si chiama salt: si aggiunge un valore casuale e diverso per ogni utente prima di calcolare l'hash della password, così le tabelle pre-calcolate diventano inutili — ogni password, anche se identica a un'altra, produce un hash diverso grazie al proprio "sale".

8. La firma digitale

Quando firmi un contratto di persona, chi lo riceve è certo di tre cose: sei stato tu a firmarlo, non puoi negarlo dopo, e nessuno può staccare la tua firma e incollarla su un altro foglio. La firma digitale cerca di garantire le stesse tre cose per un documento elettronico, combinando ciò che hai appena imparato: funzione di hash + crittografia asimmetrica.

Il procedimento, in tre passi:

1. Chi firma calcola l'hash del documento (la sua impronta digitale).
2. Cifra quell'hash con la propria chiave privata — questo passaggio è la "firma" vera e propria, e solo chi possiede quella chiave privata può produrla.
3. Allega la firma (e il proprio certificato digitale) al documento originale.

Chi riceve il documento fa il percorso inverso: ricalcola l'hash del documento ricevuto, poi usa la chiave pubblica del firmatario per decifrare la firma allegata, ottenendo l'hash originale. Se i due hash coincidono, sono sicuri di due cose insieme: che il documento non è stato alterato dopo la firma (integrità), e che è stato davvero firmato da chi possiede quella chiave privata (autenticità). Se anche una sola virgola del documento fosse cambiata dopo la firma, l'hash ricalcolato non coinciderebbe più, e la verifica fallirebbe.

Questa proprietà — non poter negare in seguito di aver firmato — si chiama non ripudio, ed è il motivo per cui la firma digitale ha valore legale: garantisce autenticità, integrità e appunto non ripudio, tutte cose che una semplice password non può garantire.

9. PKI e certificati digitali: chi garantisce per la chiave pubblica?

C'è un buco logico che forse hai già notato: se chiunque può generare una coppia di chiavi pubblica/privata, cosa impedisce a un impostore di creare una chiave pubblica e spacciarla per "la chiave pubblica della tua banca"? Se ci cadi, cifreresti i tuoi dati con la chiave dell'impostore, che potrebbe leggerli tranquillamente.

La soluzione è un po' come andare dal notaio: serve un terzo, di cui tutti si fidano, che certifichi "questa chiave pubblica appartiene davvero a questa entità". Questo terzo si chiama Certification Authority (CA, autorità di certificazione), e l'insieme di regole, ruoli e tecnologie che rendono possibile questo sistema di fiducia si chiama PKI (Public Key Infrastructure).

Il documento che la CA rilascia si chiama certificato digitale: contiene la chiave pubblica del titolare, il suo nome, la data di scadenza, e — punto cruciale — è firmato digitalmente dalla CA stessa. Chiunque riceva il certificato può verificare quella firma e fidarsi, a patto di fidarsi già della CA che l'ha emesso.

Lo vedi in azione ogni giorno: quando visiti un sito con il lucchetto nella barra degli indirizzi (HTTPS), il browser ha appena verificato il certificato digitale di quel sito, emesso da una CA di cui il tuo browser si fida "di fabbrica" (Windows, macOS e i browser mantengono una lista di CA affidabili preinstallata).

Se una chiave privata viene compromessa (rubata), il certificato corrispondente va invalidato prima della scadenza: questa procedura si chiama revoca, e i sistemi la controllano tramite liste di certificati revocati (CRL) o, in modo più moderno e in tempo reale, tramite il protocollo OCSP.

10. La steganografia: nascondere che stai comunicando

C'è una differenza sottile ma importante tra crittografia e steganografia. La crittografia nasconde il contenuto di un messaggio: chiunque lo vede sa che è un messaggio cifrato, semplicemente non riesce a leggerlo. La steganografia nasconde l'esistenza stessa del messaggio: agli occhi di un osservatore, non c'è nessun messaggio da vedere.

È l'equivalente digitale dell'inchiostro simpatico: una lettera che sembra parlare del tempo, ma che se scaldata rivela un testo nascosto scritto tra le righe. Nel mondo digitale, la tecnica più comune si chiama Least Significant Bit (LSB): in un'immagine, l'ultimo bit di ogni pixel (quello che influenza meno il colore visibile) viene sostituito con un pezzetto del messaggio segreto. Per l'occhio umano, l'immagine risulta identica a prima; ma chi sa dove guardare può estrarre il messaggio nascosto bit per bit. In ambiente Linux, uno strumento comune per questo è steghide.

11. Un accenno alla crittografia hardware

Fin qui abbiamo parlato di crittografia "via software". Esistono anche piccoli chip dedicati esclusivamente a operazioni crittografiche, più veloci e più difficili da attaccare perché isolati dal resto del sistema:

• TPM (Trusted Platform Module) — un chip montato direttamente sulla scheda madre di molti laptop aziendali, che cifra tutto ciò che il sistema operativo scrive sul disco.
• HSM (Hardware Security Module) — il termine generale per un dispositivo dedicato alla cifratura e alla custodia delle chiavi, usato tipicamente in ambito aziendale/server.

L'idea di fondo, in entrambi i casi: tenere le operazioni più delicate (e le chiavi più preziose) fuori dalla portata del sistema operativo principale, in un piccolo compartimento stagno dedicato solo a quello.

1. Tre passaggi per entrare in un sistema

Ogni volta che accedi a un sistema informatico — un computer, un servizio online, un bancomat — attraversi (anche senza accorgertene) tre passaggi distinti, in sequenza: identificazione ("chi dici di essere"), autenticazione ("dimostralo") e autorizzazione ("ok, ecco cosa puoi fare"). Confondere questi tre passaggi è un errore comune, ma sono concettualmente molto diversi: puoi identificarti correttamente e fallire l'autenticazione (username giusto, password sbagliata); puoi autenticarti correttamente ed essere comunque bloccato dall'autorizzazione (sei davvero tu, ma non hai i permessi per quella cartella).

2. Identificazione: chi dici di essere

L'identificazione è la dichiarazione della propria identità al sistema: nella maggior parte dei casi è semplicemente il tuo username, il tuo indirizzo email di login, o una chiave pubblica. È un'informazione che può anche essere pubblica — non c'è nulla di segreto nel tuo username — ma deve essere legata in modo affidabile a una persona fisica reale: se un'azienda assegna credenziali senza verificare seriamente chi le riceve, rompe fin dall'inizio la catena che collega un'identità digitale a una persona reale, vanificando ogni controllo successivo.

3. Autenticazione: dimostralo

Dopo esserti identificato, devi dimostrare di essere davvero tu. I sistemi di autenticazione si basano su cinque possibili "fattori":

• Qualcosa che sai (Tipo I) — una password, un PIN.
• Qualcosa che hai (Tipo II) — una smart card, un token, il tuo telefono.
• Qualcosa che sei (Tipo III) — un dato biometrico: impronta digitale, volto, iride.
• Qualcosa che fai — un gesto o un comportamento specifico da compiere.
• Da dove ti trovi — la posizione geografica, oggi usata raramente da sola, perché con dispositivi mobili l'idea di un luogo "atteso" ha sempre meno senso.

Un'ultima nota importante sulla biometria: a differenza di una password, un dato biometrico compromesso non si può "cambiare". Se il template della tua impronta digitale viene rubato da un database violato, non puoi generarne una nuova come faresti con una password — quella specifica caratteristica fisica resta compromessa per sempre. È un motivo in più per non affidarsi mai alla sola biometria come unico fattore su sistemi critici.

4. Federazione, Single Sign-On, Same Sign-On: tre cose diverse

Tre concetti che si assomigliano nel nome ma rispondono a domande diverse, e che vale la pena non confondere:

• Federated Identity — la possibilità di accedere a risorse su reti e organizzazioni diverse usando un'unica identità, grazie ad accordi di fiducia tra le organizzazioni coinvolte.
• Single Sign-On (SSO) — un'unica autenticazione dà accesso a tutte le risorse o i servizi di un singolo fornitore (ad esempio, accedere una volta a Google ti dà accesso automatico a Gmail, Drive, Calendar...).
• Same Sign-On — usi un provider di autenticazione esterno per accedere a una risorsa di terzi (ad esempio, il pulsante "accedi con Facebook" su un sito che non ha nulla a che fare con Facebook).

5. I protocolli di autenticazione in rete

Quando le identità devono essere verificate su una rete aziendale intera, e non su una singola macchina, entrano in gioco protocolli dedicati:

• LDAP (Lightweight Directory Access Protocol) — organizza utenti, gruppi e permessi in una struttura gerarchica centralizzata, così da non dover creare account separati su ogni singola macchina. È il protocollo su cui si basa Active Directory di Microsoft, lo standard de facto nelle reti aziendali Windows. Nella sua versione base LDAP trasmette le informazioni in chiaro; la versione cifrata, che va sempre preferita, si chiama LDAPS.
• Kerberos — nato al MIT negli anni '70, prende il nome dal cane a tre teste della mitologia greca, e usa i suoi tre "moduli" (autenticazione, autorizzazione, audit) come metafora. Funziona tramite un centro di distribuzione delle chiavi (KDC) che rilascia "biglietti" (ticket) temporanei, invece di far viaggiare ripetutamente la password sulla rete — un client autenticato una volta ottiene un ticket che può riutilizzare per accedere a più servizi, senza reinserire le credenziali ogni volta.
• RADIUS — protocollo client-server per l'autenticazione remota, molto diffuso presso i provider di connettività, che gestisce in un unico flusso autenticazione, autorizzazione e registrazione (le cosiddette "3 A": Authentication, Authorization, Accounting).
• TACACS+ — alternativa a RADIUS, molto diffusa nelle reti Cisco, che separa più nettamente le tre fasi di autenticazione, autorizzazione e accounting.

6. Autorizzazione: chi può fare cosa

Una volta verificata l'identità, resta da stabilire quali azioni sono concesse: è il campo dell'autorizzazione, riassumibile nella domanda "who can do what" — chi può fare cosa. Un modello di controllo degli accessi si costruisce sempre attorno a quattro elementi: gli utenti/soggetti che richiedono accesso, gli oggetti a cui si vuole accedere, le operazioni possibili su quegli oggetti, e i permessi che le collegano.

7. I modelli di controllo degli accessi

• MAC (Mandatory Access Control) — ogni dato viene etichettato con un livello di sicurezza (non classificato, riservato, segreto, top secret...) e l'accesso è deciso centralmente in base a quell'etichetta. Nato in ambito militare, è il più rigido dei modelli: nemmeno il proprietario di un dato può decidere autonomamente di condividerlo con qualcuno che non ha il livello di autorizzazione richiesto.
• DAC (Discretionary Access Control) — ogni risorsa ha un proprietario, che decide autonomamente ("a sua discrezione") chi altro può accedervi. È il modello più flessibile — è quello che usi ogni giorno nei permessi di file e cartelle di Windows o Linux — ma anche il più esposto al rischio di condivisioni sbagliate fatte in buona fede.
• RBAC (Role-Based Access Control) — i permessi non si assegnano alla singola persona, ma al ruolo che ricopre: non "Marco può modificare questo file", ma "il ruolo Editor può modificare questo file, e Marco è un Editor". Se Marco cambia ruolo, perde automaticamente gli accessi legati al ruolo precedente — un modello particolarmente comodo dove il turnover del personale è alto.
• Rule-Based Access Control — le regole di accesso si basano su condizioni esplicite (liste di permessi o di negazione: indirizzi IP, orari, domini ammessi), spesso combinate con l'RBAC per aggiungere flessibilità.
• ABAC (Attribute-Based Access Control) — il modello più recente e sofisticato: valuta l'intero contesto della richiesta di accesso, non solo "chi sei", ma anche da quale dispositivo, da quale luogo, a che ora, e con quali altri attributi. Rispetto all'RBAC (che valuta solo il ruolo), l'ABAC può negare un accesso altrimenti legittimo se il contesto appare anomalo — ad esempio un login con le credenziali corrette, ma da un paese mai visto prima, a un orario insolito.

8. Classificare i dati: pubblico, privato, riservato

Non tutti i dati meritano lo stesso livello di protezione, e classificarli è il primo passo per proteggerli in modo proporzionato:

• Pubblico — informazioni destinate a essere condivise liberamente (es. un comunicato stampa).
• Privato / a distribuzione limitata — informazioni per uso interno, la cui divulgazione potrebbe danneggiare l'organizzazione (documenti di lavoro, elenchi clienti).
• Confidenziale — il livello più sensibile, la cui divulgazione può causare danni gravi e diretti.

Due categorie meritano un'attenzione particolare: la PII (Personally Identifiable Information) — qualunque dato che possa identificare univocamente una persona, dal nome a un'impronta digitale a un numero di carta di credito — e la PHI (Personal Health Information), il sottoinsieme di dati relativi allo stato di salute, da trattare con lo stesso livello di attenzione visto per i dati sanitari nel Modulo 2.

9. Chi è responsabile di un dato: i ruoli

Ogni dato aziendale ha, idealmente, responsabili precisi e distinti: l'Owner (il proprietario) è la persona — spesso non tecnica — responsabile di decidere chi può accedere al dato e con quale scopo; lo Steward/Custodian è chi ne cura concretamente la sicurezza tecnica, tipicamente un amministratore di sistema o di database; il Privacy Officer è la figura (spesso coincidente con il DPO visto nel Modulo 2) incaricata di vigilare sulla protezione dei dati personali nel loro complesso. Separare questi ruoli — invece di farli coincidere in un'unica persona — è un'altra applicazione pratica della separazione dei compiti vista nel Modulo 2.

10. Per quanto tempo conservare un dato

Un dato non va conservato "per sempre, non si sa mai": va conservato solo per il tempo realmente necessario allo scopo per cui è stato raccolto — è il principio di limitazione della conservazione già incontrato nel GDPR. Alcuni termini di conservazione sono fissati direttamente dalla legge (ad esempio, i dati di traffico telefonico e telematico in Italia vanno conservati fino a un massimo di 72 mesi); altri sono lasciati alla valutazione dell'azienda, che può ragionevolmente ancorarli ai termini di prescrizione legale entro cui un soggetto esterno potrebbe far valere un diritto — aggiungendo un margine di sicurezza per i tempi tecnici di notifica di un eventuale procedimento legale.