Checklist sicurezza container Docker: cosa controllare

Un container compromesso raramente resta un problema isolato. Se l'immagine contiene una dipendenza vulnerabile, il processo gira con privilegi eccessivi o il socket Docker è esposto, l'incidente può estendersi al server, ai dati applicativi e ai servizi collegati. Questa checklist sicurezza container Docker è pensata per chi gestisce applicazioni web, e-commerce e gestionali in produzione e deve ridurre rischi concreti senza trasformare ogni rilascio in un progetto infrastrutturale.

Docker offre velocità e ripetibilità, non sicurezza automatica. Il confine tra un ambiente ordinato e uno esposto dipende da decisioni precise: da dove arrivano le immagini, quali permessi ricevono i processi, come circolano i segreti e quanto rapidamente si rileva un comportamento anomalo.

Checklist sicurezza container Docker: partire dalle immagini

La sicurezza di un container inizia prima dell'avvio. Un'immagine è software distribuito: contiene sistema operativo, runtime, librerie e configurazioni. Se questa base è obsoleta o non verificata, la vulnerabilità entra nella pipeline insieme al codice applicativo.

Usare immagini ufficiali o mantenute da fornitori affidabili riduce il rischio, ma non basta. I tag generici come `latest` rendono i deploy poco prevedibili: oggi possono puntare a una versione, domani a un'altra. In produzione è preferibile fissare una versione specifica e, per gli ambienti più controllati, anche il digest dell'immagine.

Una buona pratica è costruire immagini minimali. Un container Laravel, Node.js o React non deve includere compilatori, utility di debug, credenziali di sviluppo o file sorgenti non necessari al runtime. Le build multi-stage permettono di compilare gli asset in uno stage e copiare nell'immagine finale solo ciò che serve per eseguire l'applicazione. Meno componenti significano meno superficie d'attacco e aggiornamenti più gestibili.

La scansione delle vulnerabilità va inserita nel processo di build e ripetuta nel tempo. Non è sufficiente eseguirla al rilascio: una CVE può essere pubblicata settimane dopo la creazione dell'immagine. Il risultato va valutato con criterio. Bloccare tutto per una vulnerabilità teorica può fermare inutilmente il lavoro; ignorare una criticità sfruttabile nel contesto reale è un errore opposto. Contano gravità, esposizione, componente coinvolto e disponibilità di una correzione.

Limitare privilegi e capacità del processo

Un container non è una macchina virtuale. Condivide il kernel dell'host e, se configurato male, può avere accesso a risorse che non dovrebbe vedere. Il principio corretto è semplice: ogni servizio riceve solo i privilegi indispensabili.

Il processo applicativo non dovrebbe girare come root. Nell'immagine va creato un utente dedicato, con ownership limitata alle directory che deve leggere o scrivere. Questo non elimina ogni rischio, ma riduce l'impatto di molte vulnerabilità applicative e di dipendenze compromesse.

Evitate la modalità privilegiata salvo casi molto specifici e documentati. `privileged: true` concede al container un livello di accesso incompatibile con la maggior parte di applicazioni web, worker, code e database. Anche l'aggiunta indiscriminata di capability Linux è da evitare. Partire dalla rimozione delle capability non necessarie e aggiungere solo quelle richieste dal servizio è più sicuro che fare il contrario.

Il filesystem può essere impostato in sola lettura quando l'applicazione non richiede scritture persistenti. Le directory necessarie, per esempio cache o file temporanei, vanno montate separatamente con permessi mirati. È un controllo utile contro modifiche non autorizzate al runtime, ma va testato: alcuni framework e processi di logging richiedono percorsi scrivibili e una configurazione incompleta può causare interruzioni operative.

Particolare attenzione al socket Docker. Montare `/var/run/docker.sock` dentro un container equivale spesso a concedergli controllo sull'host. Può essere necessario per strumenti di automazione, ma non deve mai diventare una scorciatoia per far comunicare servizi ordinari. Se serve davvero, va isolato, limitato e sottoposto a controllo rigoroso.

Rete, porte e persistenza dei dati

Esporre una porta significa aprire una superficie d'attacco. Un database, Redis, Elasticsearch o un pannello di amministrazione non devono essere pubblicati su Internet solo perché il container li rende disponibili. In una configurazione ordinata, l'unico punto esposto è il reverse proxy, come Nginx, che gestisce TLS, instradamento e policy di accesso. I servizi interni comunicano su reti Docker dedicate.

Separare le reti per funzione è utile quando i sistemi crescono. Il frontend può parlare con l'API, l'API con il database, ma il frontend non ha ragione di collegarsi direttamente al database. Questa segmentazione non sostituisce l'autenticazione né le regole firewall dell'host, tuttavia limita i movimenti laterali in caso di compromissione.

I volumi meritano la stessa attenzione del codice. Un volume database contiene dati aziendali, ordini, anagrafiche o informazioni di sessione: deve avere backup verificati, permessi coerenti e una politica di conservazione definita. Il backup che non viene mai ripristinato in un ambiente di test è soltanto una speranza. Per dati sensibili, valutate anche cifratura, separazione degli accessi amministrativi e registrazione delle operazioni.

Non usate mount dell'intero filesystem dell'host per comodità. Ogni bind mount deve essere esplicito e ristretto alla directory necessaria. Quando il container deve solo leggere configurazioni o asset, il mount va impostato in sola lettura.

Segreti: mai nell'immagine, mai nel repository

Password, token API, chiavi private e credenziali cloud non devono finire nel Dockerfile, nell'immagine o nel controllo versione. Anche se un file viene rimosso in un commit successivo, può restare nella cronologia Git o nei layer dell'immagine.

Le variabili d'ambiente sono pratiche, ma non sono una cassaforte. Possono comparire in processi, log, dump diagnostici o pannelli di gestione. Per credenziali poco sensibili e ambienti semplici possono essere una scelta accettabile se l'accesso al server è controllato. Per segreti critici, è preferibile usare un sistema dedicato di gestione dei segreti o almeno file protetti, montati solo nel container che ne ha bisogno.

La rotazione va prevista prima dell'emergenza. Sapere dove è usata una chiave, chi può sostituirla e come riavviare i servizi senza fermare l'operatività fa la differenza durante un incidente. Anche gli account tecnici devono avere privilegi minimi: un token usato da un worker non dovrebbe poter amministrare l'intera piattaforma.

Controlli operativi da rendere ripetibili

La sicurezza efficace non vive in un documento lasciato in una cartella. Va tradotta in controlli verificabili a ogni rilascio e in attività periodiche sull'infrastruttura. Per una piattaforma Docker in produzione, il presidio minimo dovrebbe includere:

• aggiornamento programmato di immagini base, runtime e host Linux, con verifica delle vulnerabilità rilevanti;
• revisione dei container esposti, delle porte pubbliche, delle reti e dei mount presenti sul server;
• controllo di utenti non root, capability, modalità privilegiata e accesso al socket Docker;
• backup automatizzati, monitorati e testati con procedure reali di ripristino;
• raccolta centralizzata di log applicativi e di sistema, con alert su errori, riavvii anomali e accessi sospetti;
• inventario aggiornato di servizi, responsabili, dipendenze e credenziali tecniche.

Non tutti gli ambienti richiedono lo stesso livello di formalizzazione. Un VPS che ospita un singolo gestionale interno ha esigenze diverse da un e-commerce con pagamenti, dati personali e picchi stagionali. La direzione, però, resta la stessa: rendere esplicite le scelte di sicurezza, eliminare privilegi superflui e ridurre le variabili non controllate.

Monitoraggio e risposta agli incidenti

Un container che si riavvia continuamente, un aumento improvviso del traffico in uscita o la creazione di processi inattesi sono segnali da indagare. Il monitoraggio non serve solo a misurare CPU e RAM: deve aiutare a capire se il comportamento operativo è coerente con quello previsto.

Conservate log utili senza raccogliere indiscriminatamente dati sensibili. Registrare richieste fallite, modifiche amministrative, errori di autenticazione e deploy consente di ricostruire un evento. Le informazioni devono avere timestamp coerenti tra host, container e applicazione, altrimenti correlare un incidente diventa lento e incerto.

Serve inoltre una procedura essenziale di risposta: chi viene avvisato, chi può isolare un servizio, come si revocano le credenziali e come si ripristina una versione nota e affidabile. Nei sistemi gestiti da più fornitori, questo punto è spesso il più debole. Senza responsabilità chiare, il tempo perso nel capire chi interviene diventa parte del danno.

La checklist non sostituisce una valutazione tecnica dell'architettura, ma evita che errori ricorrenti diventino vulnerabilità permanenti. Per molte PMI, il passaggio utile non è aggiungere un altro strumento: è assegnare a qualcuno la responsabilità continuativa di verificare che immagini, server, codice e procedure restino coerenti nel tempo.