L’hardening di Windows e Linux riduce la superficie di attacco attraverso configurazioni, privilegi e servizi coerenti con il ruolo del sistema. Il risultato da ottenere non è una raccolta di comandi eseguiti una volta, ma una baseline applicata, verificata e mantenuta. La configurazione deve proteggere il servizio senza renderlo inutilizzabile o impedire un recupero controllato.
Questa guida segue il percorso del rafforzamento dei sistemi: inventario, accessi, superficie di rete, aggiornamenti, protezioni, collaudo e gestione delle eccezioni. Le baseline ufficiali Windows e la documentazione di sicurezza Ubuntu sono riferimenti da selezionare secondo versioni e componenti effettivamente utilizzati. Non vanno applicati indistintamente a qualunque macchina.
Stabilire ruolo e perimetro del sistema
Registrate sistema operativo, versione, supporto disponibile, applicazioni ospitate e referente. Distinguete server, workstation, macchina di amministrazione e ambiente di sviluppo. Una regola appropriata per un terminale ordinario può non essere sufficiente per chi gestisce identità e privilegi dell’intera organizzazione.
Collegate il sistema alla mappatura delle applicazioni e dei flussi. Identificate chi vi accede, da quali reti e attraverso quali servizi. Cercate anche utilizzi non documentati, come una cartella condivisa mantenuta per un vecchio processo o un accesso remoto utilizzato dal fornitore soltanto durante l’assistenza.
Prima delle modifiche salvate la configurazione necessaria a un ritorno controllato e verificate la disponibilità di un accesso di recupero. Stabilite chi autorizza l’intervento e chi conferma il funzionamento del servizio dopo il cambiamento. Un’azione tecnicamente corretta può produrre un’interruzione se nessuno conosce una dipendenza applicativa nascosta.
Scegliere una baseline documentata
Una baseline è un insieme di impostazioni approvate per una classe di sistemi. Registrate fonte, versione, data di valutazione e adattamenti. Se combinate riferimenti diversi, controllate i conflitti: due strumenti di gestione possono impostare valori differenti sulla stessa funzione e produrre un risultato instabile.
Classificate ciascuna impostazione come applicata, non pertinente, da attuare o oggetto di eccezione. «Non pertinente» richiede una ragione verificabile, per esempio assenza del componente cui si riferisce. «Eccezione» significa invece che il controllo sarebbe rilevante, ma non viene applicato nelle condizioni previste. Confondere queste categorie nasconde rischio residuo.
| Decisione | Informazione da conservare |
|---|---|
| Applicazione | Gruppo di sistemi e versione della baseline |
| Adattamento | Differenza rispetto al riferimento e motivazione |
| Collaudo | Operazioni verificate e risultato |
| Eccezione | Rischio, compensazione, referente e riesame |
| Distribuzione | Modalità, progressione e controllo dell’esito |
| Ritorno | Condizioni di attivazione e configurazione da recuperare |
Ridurre i privilegi e separare l’amministrazione
Gli utenti dovrebbero disporre dei privilegi necessari al lavoro ordinario. Gli accessi amministrativi richiedono un percorso distinto, con identità riconoscibile e controlli proporzionati. Evitate che un account privilegiato sia usato abitualmente per posta, navigazione e attività non amministrative: ciò amplia le occasioni di esposizione.
In ambiente Windows verificate gruppi locali, deleghe, account di servizio e strumenti di gestione remota. In ambiente Linux controllate autorizzazioni di elevazione, chiavi di accesso, account non più utilizzati e permessi su file di configurazione. L’obiettivo è poter spiegare perché ogni privilegio esiste e chi ne conferma la necessità.
Coordinate queste scelte con la politica password e MFA. Un account amministrativo protetto sul percorso principale può restare raggiungibile attraverso un protocollo alternativo. La verifica deve includere accessi locali, remoti, automatizzati e di emergenza, evitando di dedurre la copertura dalla sola configurazione dell’identità centrale.
Limitare servizi e superficie di rete
Rimuovete o disabilitate componenti non necessari dopo averne verificato l’uso. Elencate porte e servizi attesi, con origine e destinazione dei collegamenti. Una regola di rete deve riflettere un’esigenza applicativa: consentire intere reti «per evitare problemi» rende difficile distinguere un flusso legittimo da uno introdotto successivamente.
Esaminate separatamente i punti esposti a Internet e gli strumenti di amministrazione. Limitate l’accesso a percorsi controllati e verificate le dipendenze del fornitore. Un intervento di assistenza non dovrebbe lasciare attivo indefinitamente un canale creato per un’emergenza. Registrate anche come viene chiuso e chi verifica la chiusura.
La progettazione di TLS e certificati completa la protezione dei collegamenti. La cifratura del traffico non corregge però un servizio eccessivamente esposto o privilegi non necessari: le misure devono essere considerate insieme, senza attribuire a una sola configurazione la copertura dell’intero rischio.
Gestire aggiornamenti e componenti non supportati
Costruite un processo che parte dall’inventario e arriva alla verifica dell’installazione. Valutate esposizione, sfruttabilità, criticità del servizio e disponibilità di misure temporanee. Non esiste un termine tecnico unico valido per ogni vulnerabilità e ogni organizzazione; eventuali obblighi applicabili devono essere identificati nel loro contesto.
Preparate un ambiente o un gruppo pilota rappresentativo e definite cosa controllare dopo l’aggiornamento. Per i sistemi che non possono essere aggiornati subito, documentate il rischio e le compensazioni: riduzione dell’esposizione, isolamento, limitazione dei privilegi o sostituzione programmata. Una deroga senza un percorso di uscita tende a diventare permanente.
Verificate anche applicazioni, agenti, librerie e strumenti di amministrazione. L’aggiornamento del solo sistema operativo non copre necessariamente questi componenti. Chiedete ai fornitori chi mantiene ciascun livello e come vengono comunicate vulnerabilità e fine del supporto; conservate le risposte nel fascicolo del servizio.
Applicare protezioni e controllare i loro limiti
I meccanismi di protezione degli endpoint e di confinamento delle applicazioni possono ridurre le possibilità di abuso. Su Linux, la scelta dipende dalla distribuzione e dalla politica disponibile; la documentazione AppArmor di Ubuntu descrive il relativo modello di profili. La presenza del componente non dimostra che l’applicazione critica sia effettivamente confinata.
Su entrambi i sistemi verificate stato operativo, aggiornamenti, esclusioni e gestione degli allarmi. Un’esclusione molto ampia può neutralizzare il controllo su aree importanti. Ogni esclusione deve avere motivo, proprietario e riesame; la sua necessità deve essere rivalutata quando cambia la versione applicativa che l’aveva originata.
Collegate le rilevazioni ai log di sicurezza. Il controllo deve raggiungere una persona o una funzione che possa intervenire. La semplice produzione di eventi, senza presa in carico e capacità di distinguere i falsi positivi, lascia incompleto il processo di protezione.
Distribuire per gruppi e verificare la deriva
Dopo il pilota, procedete per gruppi omogenei e controllate sia l’applicazione delle impostazioni sia le funzioni del servizio. Registrate dispositivi non raggiungibili, errori e risultati parziali. Una console che mostra una percentuale elevata di successo può nascondere proprio le macchine più esposte o più difficili da gestire.
Confrontate periodicamente la configurazione osservata con quella approvata. Le differenze possono derivare da aggiornamenti, interventi manuali o conflitti fra strumenti. Prima di correggerle automaticamente, valutate se il cambiamento sia autorizzato e se la baseline debba essere aggiornata. La deriva va interpretata, non soltanto contata.
Per i servizi cloud affiancate un controllo distinto: l’hardening del tenant Microsoft 365 riguarda identità, condivisioni e accessi che la sola configurazione del dispositivo non descrive.
Chiudere il fascicolo di rafforzamento
Riunite inventario, riferimento tecnico, adattamenti, prove, eccezioni e azioni aperte. Se restano più interventi da finanziare, il piano dei controlli di igiene informatica aiuta a ordinarli per esposizione, conseguenze e dipendenze. Fate confermare al referente del servizio che le funzioni essenziali siano operative e che il percorso di recupero sia utilizzabile. Il piano di continuità operativa deve conoscere eventuali limiti introdotti dalle nuove regole.
Se un penetration test individua una debolezza, valutate se la correzione riguardi soltanto la macchina esaminata o l’intera baseline. Questo passaggio trasforma un risultato puntuale in un miglioramento ripetibile. Conservate comunque i limiti della verifica: un test riuscito su un campione non dimostra l’assenza di vulnerabilità in tutti i sistemi né sostituisce manutenzione e gestione del cambiamento.
Alla chiusura di un’eccezione, eliminate anche le istruzioni temporanee consegnate all’assistenza e verificate le automazioni che potrebbero ripristinare il vecchio valore. Una correzione manuale può essere annullata dal successivo ciclo di gestione centralizzata. Il controllo della sorgente della configurazione è quindi parte della verifica, insieme all’osservazione dello stato della singola macchina.