Indice
Cybersecurity: il problema non è “se”, ma quanto siamo preparati
Nella maggior parte delle aziende la sicurezza entra in agenda quando è già successo qualcosa: un incidente, un audit andato male, una richiesta del legale, una mail del DPO o, peggio, un data breach finito sui giornali.
È una dinamica nota: la cybersecurity viene vista come un costo o un vincolo regolatorio, raramente come una leva strategica per proteggere capitale intellettuale, continuità operativa e reputazione.
Nel cloud, però, questo approccio reattivo non regge più.
La combinazione di:
- dati sempre più distribuiti
- architetture multi-tenant e servizi SaaS
- normative come GDPR
- e un ecosistema di attaccanti molto più attivi e strutturati
rende la sicurezza un tema di progettazione, non di “cerotto finale”.
È il filo conduttore della conversazione che ho avuto nel CTO Show con Marco Dragoni, Cloud Architect in Salesforce, che ha vissuto la sicurezza sia dal punto di vista tecnologico sia da quello dei clienti enterprise.
Oltre le patch: cos’è davvero una vulnerabilità
Quando si parla di “vulnerabilità” molti pensano automaticamente a:
- patch di sistema operativo non installate
- versioni vecchie di database
- librerie con CVE note
Questa è solo una parte del quadro.
Una vulnerabilità è qualsiasi debolezza sfruttabile per:
- accedere a dati non autorizzati
- compromettere un servizio
- danneggiare l’operatività o la reputazione dell’azienda
Questo include:
- Errori di configurazione (es. permessi troppo aperti, bucket esposti, ruoli amministrativi concessi con leggerezza)
- Processi carenti (nessuno monitora, nessuno fa review periodiche di permessi, nessuno si occupa di patching pianificato)
- Comportamenti umani (password deboli, condivisioni improprie, social engineering, uso promiscuo degli account)
- Minacce interne: il dipendente scontento che prima di andarsene esporta liste di clienti, dati tecnici, configurazioni, documenti strategici
Una parte significativa degli incidenti nasce proprio da questo ultimo punto. Non da hacker hollywoodiani, ma da persone che hanno già legittimamente accesso ai sistemi.
Per un CTO, quindi, parlare di vulnerabilità non significa solo “fare più pentest”, ma:
- chiarire chi può vedere cosa
- stabilire perimetri interni e non solo “fuori vs dentro”
- accettare che la superficie di attacco principale passa anche dai ruoli, dalle identity e dai processi quotidiani.
Valutare le vulnerabilità partendo dal valore dei dati
Non tutti i dati hanno lo stesso valore per un attaccante.
Eppure molte aziende si muovono con un approccio “cifra tutto” che genera tre problemi:
- Costi maggiori (licenze, storage, performance)
- Complessità architetturale e applicativa
- Impatti sulle funzionalità (ricerca, reporting, integrazioni)
La domanda giusta non è “possiamo cifrare tutto?”, ma:
“Quali dati, se rubati o esposti, creerebbero un danno reale al business?”
Alcuni esempi:
- Dati personali (PII) legati a clienti, dipendenti, pazienti
- Dati finanziari e informazioni contrattuali
- Segreti industriali, IP, algoritmi, configurazioni core di prodotto
- Credenziali, token, chiavi di integrazione e segreti applicativi
Da qui deriva la necessità di una classificazione dei dati e di un modello in cui:
- a dati diversi corrispondono livelli di protezione diversi
- la cifratura viene applicata in modo selettivo e consapevole
- si combina la protezione applicativa con controlli a livello di processo (permessi, segregazione dei compiti, logging, revisione periodica degli accessi)
Cifrare indiscriminatamente tutto può sembrare rassicurante, ma spesso è solo un modo per spostare il problema più avanti, in forma più costosa e meno gestibile.
Perché oggi dobbiamo preoccuparci più di prima
Il contesto in cui operano oggi CTO e Tech Leader è molto diverso rispetto a dieci anni fa:
- La maggior parte delle nuove soluzioni è cloud-based o SaaS
- Gli attaccanti utilizzano automazione, infrastrutture industrializzate e spesso lavorano con logiche veri e propri “business criminali”
- Regolatori e autorità di controllo (GDPR, ACN, AGID, ecc.) hanno aumentato aspettative e responsabilità
- I clienti sono sempre più sensibili ai temi di fiducia, affidabilità e protezione dei dati
Risultato:
non basta più “comprare il prodotto giusto” o delegare tutto al fornitore cloud.
La sicurezza è:
- una funzione di design (come progettiamo sistemi e processi)
- una questione di responsabilità interna (chi risponde di cosa)
- un tema di governance continua, non una checklist da spuntare una volta sola.
Shared responsibility: il modello che molti non vogliono vedere
Uno dei punti chiave del cloud, spesso frainteso, è il modello di shared responsibility.
- Il provider si occupa di sicurezza dell’infrastruttura, data center, ridondanza, protezione fisica, misure di base, cifratura di basso livello, ecc.
- Il cliente resta responsabile di:
- gestione identità e accessi
- configurazione delle policy
- controllo delle superfici esposte
- adozione o meno delle funzionalità di sicurezza avanzate messe a disposizione
- gestione dei dati e del proprio ciclo di vita delle informazioni
Metterla giù brutalmente:
puoi avere la porta blindata più costosa del mercato, ma se lasci le chiavi nella serratura la responsabilità è tua.
Questo significa che:
- scegliere un buon provider non è il punto di arrivo, ma il punto di partenza
- occorre qualcuno in azienda che conosca a fondo le funzionalità di sicurezza disponibili e decida come usarle
- vanno definite policy realistiche: password, MFA, gestione dei ruoli, separazione degli ambienti, logging, alerting, retention dei log
La vera differenza tra una piattaforma relativamente sicura e una esposizione costante non è quasi mai il provider, ma come il cliente sfrutta (o ignora) gli strumenti che ha a disposizione.
DevSecOps: portare la sicurezza dentro il processo, non in coda
Nel mondo sviluppo esiste uno schema classico:
si costruisce tutto, poi si manda “in QA” e, se va bene, qualcuno guarda anche la sicurezza alla fine.
Nella pratica:
- quando si arrivi alla fase finale è troppo tardi per cambiare davvero architettura o pattern
- eventuali problemi di sicurezza diventano tecnico-debito strutturale
- tutti sono già in ritardo e il “fix” viene rimandato alla prossima release, che non arriva mai
DevSecOps è il tentativo concreto di risolvere questo problema:
- integrare la sicurezza nelle pipeline di sviluppo
- adottare framework e linee guida (OWASP, NIST, ecc.) fin dalle prime fasi di analisi e design
- automatizzare controlli su librerie, dipendenze, configurazioni di base
- ragionare sulla superficie di attacco già in fase di definizione delle user story e delle API
Per CTO e Tech Leader questo si traduce in alcune scelte operative:
- Standard minimi obbligatori
Nessun nuovo progetto parte senza una baseline di sicurezza definita (autenticazione, logging, gestione errori, gestione segreti). - Tooling integrato nel flusso di lavoro
Scanner di dipendenze, static code analysis, controlli di configurazione inseriti in CI/CD, non come step estemporanei. - Responsabilità chiare
La sicurezza non è “del team di sicurezza”: è distribuita tra sviluppo, ops, architettura, prodotto, con ruoli e metriche esplicite. - Formazione continua
Sviluppatori e architetti devono conoscere le basi di secure coding e dei principali pattern di attacco.
Encryption: livelli, compromessi e impatti reali
Nel dialogo con Marco emerge chiaramente un punto che molti sottovalutano:
non esiste un solo tipo di encryption.
Possiamo avere cifratura a:
- livello di disco (disk encryption)
- livello di file system
- livello di database (column-level o table-level)
- livello applicativo (dati cifrati prima ancora di essere scritti nel database)
- livello degli allegati, degli index di ricerca, dei log
Ogni livello:
- protegge da scenari diversi
- ha impatti differenti su performance, UX e compatibilità funzionale
- richiede competenze architetturali specifiche
L’errore tipico è pensare che la cifratura sia un interruttore binario: “on/off”.
In realtà è un set di scelte che definiscono cosa sarà ancora possibile fare:
- ricerche full-text
- aggregazioni
- analisi e reporting
- integrazioni con sistemi terzi
La chiave non è “cifrare sempre di più”, ma cifrare meglio:
- partire da una chiara mappa dei dati sensibili
- capire per ciascuna categoria quali operazioni sono necessarie
- scegliere i livelli di encryption compatibili con il modello d’uso
Nuovi CTO, sistemi ereditati e la necessità di una checklist
Molti CTO e Tech Leader entrano in azienda a valle di anni di sviluppo, accumulo di debito tecnico e scelte di sicurezza mai realmente sistematizzate.
La domanda è: da dove cominciare?
Alcune mosse pragmatiche:
- Usare framework e certificazioni come checklist
Anche senza puntare subito a una certificazione, i framework NIST, le linee guida di ACN/AGID, le checklist dei principali standard forniscono un elenco strutturato di domande da porsi. - Mappare superfici di attacco e dati critici
- quali sistemi espongono servizi verso l’esterno
- dove vivono i dati più sensibili
- quali ambienti non sono minimamente segmentati
- Verificare identità e permessi
Spesso il problema più grande non è tecnologico, è organizzativo: ruoli amministrativi a troppe persone, account condivisi, ambienti di test con dati reali. - Stabilire un piano di remediation per fasi
Non tutto può essere sistemato in una volta. Serve una roadmap chiara di interventi progressivi, collegati a rischi concreti e non solo a “pulizia teorica”.
In sintesi: non serve la bacchetta magica, serve un approccio strutturato e continuativo.
Conclusione: la sicurezza come disciplina manageriale, non solo tecnica
La tesi di fondo è semplice: la cybersecurity non è più un tema solo per specialisti tecnici. È una disciplina manageriale.
Per CTO, Tech CEO e chi guida piattaforme digitali significa:
- portare il discorso sicurezza dentro la governance del prodotto e del portafoglio applicativo
- legare gli investimenti in sicurezza a rischi e impatti chiari sul business (reputazione, continuità, conformità, revenue)
- strutturare processi, ruoli e decisioni in modo da evitare di scoprire la sicurezza solo il giorno in cui arriva l’incidente
La conversazione con Marco Dragoni mette sul tavolo proprio questo cambio di prospettiva: non “quale tool compro”, ma come progetto e governo la sicurezza in un mondo cloud e data-driven.
È il tipo di cambio di mentalità che separa le aziende che subiscono gli incidenti da quelle che li trattano come parte di un sistema di rischio gestito in modo maturo.
