Hardening dei sistemi: cos'è e come si fa

La risposta breve: l'hardening dei sistemi è il lavoro con cui si riduce la superficie di attacco di server, postazioni, apparati di rete e servizi cloud. Si tolgono servizi, account e funzioni che non servono, si cambiano le impostazioni predefinite, si installano gli aggiornamenti e si applica una configurazione di riferimento sicura. Poi si controlla nel tempo che il sistema resti com'era stato configurato.

La differenza con la manutenzione ordinaria la fanno tre cose: partire da una guida riconosciuta, documentare cosa si è deciso e perché, accorgersi quando la configurazione si sposta. Qui vediamo i passi concreti, le guide da usare e cosa chiedono NIS2 e ISO 27001.

Cosa significa hardening

Il termine viene dall'inglese to harden, indurire: lo stesso server, con meno porte aperte, meno utenze, meno software e regole più strette.

NIST, nella SP 800-70 Rev. 5 (maggio 2026), lo lega a uno strumento preciso: la checklist di configurazione sicura, che nel linguaggio comune si chiama anche guida di hardening, lockdown o benchmark. È una serie di istruzioni per configurare un prodotto IT secondo un certo livello di tolleranza al rischio, verificare che la configurazione sia stata applicata e individuare le modifiche non autorizzate.

La stessa pubblicazione spiega perché il lavoro serve. Molti prodotti arrivano con le impostazioni più restrittive disattivate, per funzionare subito nel maggior numero possibile di ambienti. Il risultato è che un prodotto installato così com'è può essere vulnerabile fin dal primo giorno. NIST aggiunge che nessuna checklist rende un sistema sicuro del tutto e che non sostituisce la manutenzione continua, come l'installazione delle patch: riduce i modi in cui il sistema può essere attaccato.

Perché le configurazioni predefinite sono il punto debole

Nell'advisory AA23-278A (5 ottobre 2023), NSA e CISA hanno messo in fila le dieci configurazioni errate che i loro red team, blue team e team di risposta agli incidenti trovano più spesso nelle reti che valutano. Le agenzie precisano che l'elenco non è in ordine di priorità. La prima voce sono le configurazioni predefinite di software e applicazioni; tra le altre ci sono la separazione insufficiente tra privilegi di utente e di amministratore e la gestione carente delle patch.

Sulle credenziali predefinite l'advisory è diretto: attaccanti e team di valutazione le trovano con una semplice ricerca sul web e le usano per entrare con un accesso autenticato: nelle VPN, per arrivare alla rete interna, e con le credenziali amministrative predefinite nelle applicazioni web e nei database. Il primo rimedio indicato è modificare la configurazione predefinita prima della messa in produzione, seguendo le guide di hardening del produttore e quelle pubbliche.

Il dato che fa riflettere è un altro. Secondo NSA e CISA questi errori mostrano una tendenza di debolezze sistemiche in molte grandi organizzazioni, comprese quelle con una postura di sicurezza matura. Non è un problema di chi non ha un team IT, ma di configurazioni mai rimesse in discussione dopo l'installazione.

Come si fa l'hardening di un sistema

La traccia più lineare resta quella della NIST SP 800-123, la guida alla sicurezza generale dei server (luglio 2008). È datata negli esempi, ma la sequenza vale ancora e si applica, con gli adattamenti del caso, anche alle postazioni e alle macchine virtuali.

1. Aggiornare prima di esporre

Le vulnerabilità note del sistema operativo si correggono prima che il server ospiti un servizio o sia raggiungibile da utenti non fidati. Nel frattempo la macchina resta scollegata, o su un segmento di rete isolato che permette solo il traffico necessario per aggiornarla e configurarla. La guida raccomanda anche di non installare le patch in produzione senza averle provate su un sistema configurato allo stesso modo. Come si organizza l'aggiornamento di tutto il parco, con priorità e tempi, lo spieghiamo nella guida al patch management.

2. Togliere quello che non serve

Servizi, applicazioni e protocolli di rete non necessari si rimuovono, e si disattivano solo quando non si possono rimuovere. NIST preferisce la rimozione perché un servizio disattivato può essere riattivato da un attaccante o per errore umano, mentre uno rimosso no. L'elenco tipico: condivisione di file e stampanti, accesso remoto senza cifratura robusta come Telnet, web server e posta dove non servono, compilatori e strumenti di sviluppo. Meno servizi significa anche meno log da leggere, quindi comportamenti anomali più facili da notare.

3. Sistemare account e autenticazione

Gli account predefiniti non necessari si eliminano o si disattivano; quelli che restano si rinominano dove possibile e ricevono password coerenti con la politica aziendale. Gli account di servizio che non richiedono un accesso interattivo si disattivano per il login. Si creano solo le utenze necessarie, si assegnano i diritti per gruppi e gli amministratori che usano il server anche come utenti hanno un account ordinario per farlo.

4. Mettere in sicurezza il software applicativo

Per il software che il server ospita la logica è la stessa, con qualche voce in più: togliere file di esempio e script di prova, applicare il template o lo script di hardening appropriato, far ascoltare ogni servizio solo sulle porte necessarie.

5. Verificare

L'ultimo passo della sequenza NIST è il test della sicurezza del sistema, per controllare che i passi precedenti abbiano coperto davvero i problemi. È qui che entrano le scansioni: un vulnerability assessment autenticato vede configurazioni deboli, servizi esposti e credenziali predefinite rimaste al loro posto.

Da dove partire: CIS Benchmarks e le altre guide

Nessuno scrive una baseline da zero: le fonti di riferimento sono pubbliche.

• CIS Benchmarks. Il Center for Internet Security li descrive come raccomandazioni prescrittive di configurazione per oltre 25 famiglie di prodotti, con più di 100 guide, sviluppate per consenso da esperti volontari, produttori e comunità. Si scaricano gratuitamente in PDF. Come si applicano senza rompere la produzione, anche su AWS e Azure, lo spieghiamo in CIS Benchmark: cos'è e come si usa.
• Guide dei produttori. Secondo NIST le checklist sono di solito create dai produttori per i propri prodotti, oltre che da enti pubblici, università e consorzi.
• DISA STIG. Le guide tecniche del Dipartimento della Difesa statunitense, citate anche da NSA e CISA come riferimento per modificare le configurazioni predefinite.
• National Checklist Repository di NIST. Il catalogo pubblico su checklists.nist.gov raccoglie i metadati delle checklist e rimanda al sito dove ciascuna è pubblicata.

I CIS Benchmarks organizzano le raccomandazioni in profili. Il Level 1 è la base: impostazioni che si applicano in tempi brevi e senza un forte impatto sulle prestazioni. Il Level 2 è pensato come difesa in profondità per ambienti dove la sicurezza ha la precedenza, e CIS avverte che può avere effetti negativi sull'organizzazione se non viene applicato con cura. Esiste anche un profilo STIG per chi deve allinearsi a quelle guide.

Su un punto CIS e NIST dicono la stessa cosa: la guida si prova prima in un ambiente di test, per capire l'impatto, e si adatta al proprio contesto.

Hardening, NIS2 e ISO 27001

Per i soggetti NIS italiani il riferimento sono le misure di sicurezza di base della determinazione ACN 379907/2025, che si applica dal 15 gennaio 2026. La pagina ACN sulle modalità e specifiche di base indica che le misure vanno adottate entro 18 mesi dalla comunicazione di inserimento nell'elenco nazionale NIS, e tra parentesi indica ottobre 2026. Sull'hardening le due categorie di soggetti hanno obblighi diversi.

Soggetti essenziali

Nell'allegato 2 la misura PR.PS-01 chiede che, per almeno i sistemi informativi e di rete rilevanti, siano definite e documentate in un elenco aggiornato le loro "configurazioni di riferimento sicure (hardened)", con procedure adottate e documentate. È l'obbligo più vicino alla parola hardening in tutte le misure di base. La PR.PS-02, al punto 4, chiede inoltre di verificare in ambiente di test l'aggiornamento del software ritenuto critico prima di usarlo in produzione.

Soggetti importanti

L'allegato 1 non contiene la PR.PS-01. Contiene però misure che coincidono con i passi dell'hardening: installare solo software per cui sono garantiti aggiornamenti di sicurezza e applicarli "senza ingiustificato ritardo" (PR.PS-02), tenere completamente distinte le utenze con e senza privilegi amministrativi degli amministratori di sistema, con credenziali diverse (PR.AA-05), disattivare l'esecuzione automatica dei supporti rimovibili (PR.DS-01). Le stesse misure si ritrovano anche nell'allegato 2.

Per il quadro complessivo degli obblighi il punto di partenza è la guida completa alla NIS2.

ISO/IEC 27001:2022

Nell'Annex A della norma il tema corrisponde al controllo 8.9, gestione della configurazione, uno dei controlli introdotti con la revisione del 2022, e si collega all'8.8 sulla gestione delle vulnerabilità tecniche. Chi prepara una certificazione trova il dettaglio nell'articolo sui requisiti dell'Annex A.

In audit, in entrambi i casi, serve l'elenco dei sistemi rilevanti, la baseline di ciascuno, le eccezioni motivate e la prova che la configurazione reale corrisponde a quella documentata.

Il problema vero: la configurazione che si sposta

Un sistema configurato bene il giorno dell'installazione non resta tale. Arriva un'eccezione temporanea per un fornitore, un servizio riattivato per un test, una regola del firewall aperta di notte per un'emergenza e mai richiusa. Nel linguaggio tecnico si chiama drift, deriva della configurazione.

La SP 800-70 Rev. 5 affronta questo punto in modo esplicito. Le checklist si applicano al rilascio e nelle verifiche periodiche, ma NIST incoraggia a integrarle nel monitoraggio continuo con verifiche automatiche quasi in tempo reale, tenendo conto del contesto e documentando le deviazioni note e approvate, invece di produrre un elenco piatto di superato e non superato. Negli ambienti che cambiano spesso, questa verifica continua permette di accorgersi prima di derive, errori di configurazione ed esposizioni.

Per il cloud e gli ambienti ibridi la pubblicazione aggiunge un passo: correlare le violazioni delle checklist su tutto lo stack, identità, rete e dati, per concentrare la correzione sui percorsi di attacco che portano davvero a dati sensibili. Un errore di configurazione pesa di più quando si somma ad altri: un archivio esposto e raggiungibile da un'identità con permessi eccessivi è un percorso di attacco, non una riga in un report.

Gli errori più comuni

• Hardening fatto una volta. La baseline viene applicata al rilascio e mai più verificata. Dopo un anno nessuno sa quanto i sistemi si siano allontanati.
• Nessun inventario. Si mettono in sicurezza i sistemi che si conoscono; quelli dimenticati, spesso i più vecchi, restano con le impostazioni di fabbrica.
• Benchmark applicato senza prova. Le regole che bloccano un'applicazione vengono tolte in blocco, e con loro anche quelle innocue.
• Eccezioni non scritte. Una deroga motivata va bene, e le misure ACN la prevedono esplicitamente; una deroga che esiste solo nella memoria di chi l'ha fatta non regge un audit.
• Hardening al posto del monitoraggio. Ridurre la superficie di attacco non elimina gli attacchi. Sulle postazioni, per esempio, serve comunque qualcuno che legga gli alert: ne parliamo nell'articolo sull'endpoint protection in azienda.

In sintesi

L'hardening riduce la superficie di attacco: si toglie ciò che non serve, si cambiano le impostazioni predefinite, si aggiorna e si applica una baseline riconosciuta, provata prima in test. Per i soggetti NIS essenziali la misura ACN PR.PS-01 chiede di documentare le configurazioni di riferimento sicure dei sistemi rilevanti; per gli importanti gli stessi passi arrivano da patch e separazione delle utenze amministrative. Il risultato lo decide la verifica continua.

Se vuoi capire quanto le configurazioni dei tuoi sistemi si sono allontanate dalla baseline e come tenerle sotto controllo, puoi partire dai nostri servizi di cybersecurity.