La sicurezza informatica ha un problema di proprietà. Non nel senso legale del termine, ma nel senso pratico: nessuno si sente responsabile di tutta la catena. Il committente pensa che sia un problema dello sviluppatore — "hai scritto tu il software". Lo sviluppatore pensa che sia un problema del sistemista — "hai tu i server, ci pensi tu". Il sistemista hardena l'host, chiude le porte, aggiorna i pacchetti — e si trova con un'applicazione che apre buchi che nessun firewall riesce a chiudere dall'esterno.
Questa visione a compartimenti è il primo problema di sicurezza di molti progetti, e si manifesta prima ancora di scrivere una riga di codice o di accendere un server.
La Top 10 di OWASP non mente
OWASP (Open Web Application Security Project) pubblica da anni una classifica delle vulnerabilità applicative più critiche, costruita su dati reali di incidenti e penetration test. La lista cambia lentamente, e non è un caso: broken access control, injection, broken authentication, security misconfiguration dominano da oltre un decennio. Sono quasi tutte vulnerabilità applicative — non di sistema operativo, non di configurazione di rete.
Se fosse vero che la sicurezza si riduce a mettere in piedi un server ben configurato, quei numeri non esisterebbero. Un host può essere indurito al massimo — SELinux attivo, porte chiuse, aggiornamenti al giorno, fail2ban configurato — e un'applicazione con SQL injection aperta resta un cancello spalancato. Il server non può ispezionare le query che l'applicazione costruisce dinamicamente. La distinzione tra livello applicativo e livello infrastrutturale non è accademica: determina dove si manifesta il problema e, soprattutto, chi è nelle condizioni di risolverlo.
I container non sono un ambiente sicuro per definizione
Negli ultimi anni si è diffusa l'idea che i container — Docker, principalmente — siano di per sé un ambiente sicuro. L'isolamento che offrono rispetto al sistema host esiste, ma va capito nei suoi limiti reali prima di costruirci sopra assunzioni di sicurezza.
Un container è uno strumento di isolamento del deployment e di riproducibilità degli ambienti. Riduce la superficie d'attacco condivisa con l'host; non la azzera. I container escape — vulnerabilità che permettono a un processo dentro un container di accedere all'host — sono documentati e reali. CVE-2019-5736 colpiva runC, il runtime di basso livello usato da Docker e Kubernetes: permetteva a un container malevolo di sovrascrivere il binario dell'host ed eseguire codice arbitrario con privilegi root. Nel 2024 il gruppo di vulnerabilità noto come Leaky Vessels (CVE-2024-21626 tra le altre) ha riguardato ancora runC con uno scenario di escape analogo. Non sono esercizi teorici: sono CVE con exploit dimostrati e patch di emergenza.
Ma anche senza uscire dal container, un'applicazione vulnerabile resta vulnerabile. I dati a cui ha accesso — database, file, variabili d'ambiente, secret montati come volume — sono tutti raggiungibili dall'interno. Il movimento laterale verso altri servizi nella stessa rete è possibile senza toccare l'host. E le misconfigurazioni più comuni amplificano il problema in modo significativo: container avviati con il flag --privileged, docker socket montato come volume, volumi con dati sensibili senza policy di accesso, capability di sistema eccessive. In quei casi l'isolamento è più apparente che reale — e l'illusione di sicurezza è più pericolosa dell'assenza di sicurezza, perché riduce la vigilanza.
Il monitoring vede meno di quanto si pensi
Vale la pena chiarire un aspetto tecnico che non è intuitivo, perché influenza le decisioni di architettura.
Strumenti come auditd, Wazuh per il file integrity monitoring, CrowdSec e osquery lavorano a livello di kernel o filesystem dell'host. Sono efficaci e potenti nel loro ambito. All'interno di un container la visibilità è parziale per costruzione: auditd può intercettare le syscall di un container se configurato esplicitamente per farlo, ma il namespace di processo separato limita cosa e come. Wazuh FIM monitora il filesystem dell'host; se i dati sensibili risiedono solo nel layer del container e non su volumi montati sull'host, l'agente non li vede. CrowdSec analizza i log che riesce a leggere: se il container non espone i propri log in formato accessibile sull'host, non c'è niente da analizzare.
Non è un difetto degli strumenti — è la conseguenza logica di come funziona l'isolamento. Una stack containerizzata richiede una strategia di osservabilità progettata su misura: aggregazione dei log, runtime security dedicata (Falco, per esempio), policy esplicite su cosa esce dal container e dove finisce. Senza questo, il sistemista vede chiaramente l'host e una serie di namespace sostanzialmente opachi.
Una preferenza personale, non una crociata
A questo punto è corretto essere esplicito sulla mia posizione, perché non è neutrale.
Quando posso scegliere, preferisco lavorare su VPS — macchine virtuali con sistema operativo direttamente gestito. Il motivo è pratico: ho controllo completo sulla configurazione, posso standardizzare hardening, backup, monitoring e logging su tutta la flotta con gli stessi strumenti, posso applicare e verificare le stesse policy in modo uniforme. La visibilità è totale e diretta.
Non è una crociata contro i container. Chi fa orchestrazione a scala, pipeline CI/CD con ambienti effimeri, scaling orizzontale automatico su Kubernetes ha ragioni legittime e solide per usarli — riproducibilità, isolamento del deployment, efficienza delle risorse. Sono ragioni reali e importanti. Ma sono ragioni di deployment, non primariamente di sicurezza. La sicurezza in un ambiente containerizzato è un problema di progettazione aggiuntivo che richiede scelte esplicite, non una caratteristica che viene inclusa per default.
Il gap non è di competenza, è culturale
Ho lavorato come sviluppatore prima di diventare sistemista. Non è una credenziale che voglio spendere più del necessario, ma cambia il modo in cui leggo certi problemi: capisco i vincoli e le priorità di entrambe le parti perché ci sono stato.
Lo sviluppatore lavora sotto pressione di delivery. Feature, bug, deadline. La sicurezza tende a scivolare fuori dallo scope quando non è esplicitamente a capitolato, non per negligenza, ma perché le sue conseguenze sono differite — i problemi emergono dopo, spesso molto dopo, e spesso in modo difficile da ricondurre alla causa originale. Aggiungere validazione dell'input, gestire i secret correttamente, implementare il principio del minimo privilegio: sono scelte che richiedono tempo e attenzione in fase di progettazione, e che vengono sacrificate facilmente quando la deadline si avvicina e il capo prodotto chiede la feature.
Il sistemista arriva su un'infrastruttura che qualcun altro ha progettato, su un'applicazione che qualcun altro ha scritto, con vincoli di runtime che non controlla. Può fare moltissimo a livello di host — e deve farlo — ma non può correggere le scelte architetturali che non gli appartengono. Non può tappare dall'esterno un'autenticazione rotta dall'interno.
Il mio lavoro è modellare l'infrastruttura sul software: capire come funziona l'applicazione, dove sono i punti critici, cosa serve a livello di rete e di runtime. E venire incontro allo sviluppatore — non imporre una visione infrastrutturale, ma costruire insieme un perimetro che regga. Funziona quando si lavora coordinati dall'inizio del progetto. Il problema reale non è che mancano le competenze: è che dev e sistemista raramente si parlano abbastanza presto nel ciclo di vita di quello che stanno costruendo.
I vincoli normativi arrivano quasi sempre a giochi fatti
C'è un terzo attore in questa dinamica, spesso invisibile nelle fasi di progettazione: il quadro normativo.
Il GDPR impone requisiti precisi su come i dati personali vengono trattati, conservati e cancellati. La NIS2 (Network and Information Security Directive 2, recepita in Italia nel 2024) estende gli obblighi di sicurezza informatica a un perimetro molto più ampio di organizzazioni rispetto alla direttiva precedente — PMI incluse, in settori che spaziano dall'energia ai servizi digitali, dalla sanità alle infrastrutture critiche. Data minimization, retention dei log, diritto all'oblio, notifica delle violazioni entro 72 ore: sono vincoli tecnici oltre che legali, che riguardano la struttura del database, la politica di conservazione degli accessi, l'architettura dell'autenticazione.
Raramente questi requisiti vengono considerati durante la progettazione. Non per negligenza: semplicemente non rientrano nel contratto, nessuno ha esplicitato il requisito, e il tema sembra distante mentre si scrive codice. Quasi mai i committenti li inseriscono a capitolato. Il sistemista arriva a giochi fatti e cerca di rendere "difendibile" quello che era stato progettato solo per "funzionare".
È uno schema che si ripete con una certa regolarità. Cambiarlo richiede che committenti e responsabili di progetto capiscano che i requisiti normativi non sono una verifica finale da aggiungere in fondo alla lista, ma vincoli architetturali da includere fin dall'inizio. E che la persona giusta per tradurli in requisiti tecnici sia presente quando le decisioni vengono prese — non quando l'applicazione è già in produzione e i log vengono tenuti tre anni più del necessario su un volume senza cifratura.
La sicurezza è una proprietà di sistema
La sicurezza di un sistema digitale è la sovrapposizione di almeno tre strati: il codice, l'infrastruttura e le scelte organizzative su chi decide cosa e quando. Nessuno dei tre è sufficiente da solo, e la debolezza in uno non viene compensata dalla solidità degli altri due.
La buona notizia è che il coordinamento tra chi presidia questi strati non richiede processi formali complessi né budget aggiuntivi: richiede che le conversazioni giuste avvengano nel momento giusto. Il sistemista che legge le specifiche dell'applicazione prima che sia scritta. Lo sviluppatore che chiede come viene monitorato quello che sta per deployare. Il committente che include i requisiti di sicurezza nel contratto invece di darli per scontati. Sono scelte di metodo, non di tecnologia.
Per capire meglio il perimetro di cosa fa e non fa un sistemista Linux in questo contesto, questo articolo lo chiarisce.
La sicurezza si costruisce coordinando infrastruttura e sviluppo fin dall'inizio del progetto.
Parliamone →