Messa in sicurezza e migrazione dell'infrastruttura IT

L'infrastruttura di molte aziende di questa dimensione non è stata progettata: si è depositata. Un server comprato nel momento in cui serviva, un secondo aggiunto quando il primo non bastava più, uno switch sostituito d'urgenza, un firewall configurato anni fa da qualcuno che non lavora più lì, un NAS che qualcuno ha collegato “intanto”.

Ogni singola decisione, presa nel suo momento, era ragionevole. L'insieme, a distanza di otto o dieci anni, presenta un profilo che riconosciamo con regolarità:

• Server oltre la vita utile, spesso senza contratto di assistenza attivo e con ricambi non più disponibili.
• Backup che esistono ma non sono mai stati ripristinati, quindi tecnicamente sono un'ipotesi, non una garanzia.
• Rete piatta: il computer del magazzino, la stampante, il gestionale, le telecamere e il portatile del consulente esterno vivono tutti nello stesso spazio, senza separazioni.
• Accessi remoti aperti per necessità durante il lavoro da casa e mai più richiusi né irrobustiti.
• Privilegi amministrativi diffusi, spesso perché “altrimenti il gestionale dava problemi”.
• Nessuna documentazione: la conoscenza dell'infrastruttura vive nella testa di una o due persone.

La frase che accompagna quasi sempre questa situazione è la stessa, ed è comprensibile: “finora è sempre andata bene”. Il punto che cerchiamo di rendere evidente, senza allarmismi, è che in questo assetto non esiste un modo per accorgersi che sta andando male finché non è troppo tardi: senza registri, senza monitoraggio e senza segmentazione, un problema diventa visibile solo quando ha già fermato qualcosa.

Come negli altri progetti, il primo passo non è tecnico ma di misura: capire quali sistemi sono critici, quanto costa un'ora di fermo per ciascuno, e da dove si ripartirebbe oggi se domattina non ripartisse nulla.

Prima di parlare di tecnologie, in un progetto come questo poniamo al cliente due domande. Sono semplici e spesso non hanno mai avuto una risposta scritta:

Quanti dati possiamo permetterci di perdere?

Se l'ultimo salvataggio utile è di ieri notte, l'azienda accetta di riscrivere una giornata di lavoro?

Quanto tempo possiamo restare fermi?

Il magazzino può lavorare due giorni senza gestionale? E l'ufficio commerciale?

Le risposte a queste due domande — in gergo tecnico l'obiettivo di punto di ripristino e l'obiettivo di tempo di ripristino — determinano ogni scelta successiva: quanto spesso salvare, dove tenere le copie, quanta ridondanza serve, quanto conviene investire.

È un passaggio che cambia il tono della conversazione, perché sposta la discussione da “quale prodotto compriamo” a “quale livello di rischio l'azienda decide di accettare”. Ed è una decisione della direzione, non dell'ufficio tecnico.

1. 01

   Inventario e valutazione dello stato di fatto

   Non si mette in sicurezza ciò di cui si ignora l'esistenza. La prima attività è la ricostruzione completa di quello che c'è: server fisici e virtuali, applicazioni e loro dipendenze, apparati di rete, postazioni, licenze, accessi remoti, utenze privilegiate, fornitori con accesso ai sistemi, contratti e scadenze.

   Il risultato è un documento che, in molte aziende, non è mai esistito prima: la mappa dell'infrastruttura. Da sola vale già una parte del progetto, perché è ciò che permette a chiunque — anche a un fornitore diverso da noi — di capire come è fatta l'azienda senza chiedere a qualcuno che ricorda.

   In parallelo si valuta lo stato di sicurezza: aggiornamenti mancanti, servizi esposti verso Internet, configurazioni deboli, account non più utilizzati e mai disattivati. Da qui esce un elenco di criticità ordinato per gravità ed esposizione, che diventa il piano di lavoro.

2. 02

   Interventi immediati a basso impatto

   Prima di qualunque migrazione, si chiudono le esposizioni più gravi con interventi che non richiedono fermi e producono un beneficio immediato. Tipicamente:

   • Autenticazione a più fattori su posta, accessi remoti e utenze amministrative. È la misura singola con il miglior rapporto tra risultato e sforzo.
   • Chiusura dei servizi di accesso remoto esposti direttamente su Internet, sostituiti da un canale controllato.
   • Disattivazione delle utenze non più utilizzate, che sono una delle vie d'ingresso più banali e più sfruttate.
   • Rimozione dei privilegi amministrativi dall'uso quotidiano, con account separati per le operazioni che li richiedono.
   • Aggiornamenti critici su sistemi e apparati, pianificati e verificati.

   Questa fase esiste per una ragione precisa: una migrazione richiede settimane, e nel frattempo l'azienda deve essere meno esposta di prima, non uguale.

3. 03

   Progettazione della nuova infrastruttura

   Il progetto vero e proprio, che ruota attorno a tre principi.

   Segmentazione. La rete viene divisa in aree che non hanno motivo di parlarsi: server, postazioni degli uffici, dispositivi di magazzino, sistemi di videosorveglianza, rete ospiti, dispositivi non aggiornabili. Il traffico tra le aree è consentito solo dove serve davvero. L'effetto pratico è decisivo: un problema che nasce in un'area non arriva automaticamente a tutte le altre. È la differenza tra un incidente circoscritto e un incidente che ferma l'azienda.

   Ridondanza dove conta. Non tutto merita di essere duplicato: si individuano i sistemi la cui indisponibilità ferma la produzione o la vendita, e si elimina il punto singolo di rottura solo per quelli. Duplicare tutto costa e complica; duplicare nulla è ciò che rende un guasto banale un evento aziendale.

   Ipotesi di lavoro realistica. L'infrastruttura si progetta assumendo che prima o poi un componente si guasterà, un aggiornamento andrà storto e qualcuno cliccherà dove non doveva. Le domande di progetto diventano quindi: che cosa succede quando accade? chi se ne accorge? in quanto tempo si torna operativi?

   Sulla scelta tra sede e cloud manteniamo una posizione che non tutti i fornitori dichiarano: la risposta corretta è quasi sempre mista, e dipende dal singolo carico. Ha senso in cloud ciò che deve essere raggiungibile ovunque, scalare con il carico o non giustifica hardware dedicato; ha senso in sede ciò che ha vincoli di latenza, volumi di dati importanti o dipendenze locali forti. Le variabili da valutare esplicitamente sono il costo ricorrente reale a tre e cinque anni, la dipendenza dalla connettività, la difficoltà di cambiare fornitore in futuro e i vincoli sulla localizzazione dei dati. Un fornitore che propone la stessa risposta a ogni azienda non sta progettando.

4. 04

   Protezione dei dati: la parte non negoziabile

   Il criterio che applichiamo è la regola consolidata nel settore: tre copie dei dati, su due supporti diversi, con una copia fuori sede, a cui oggi si aggiungono due condizioni diventate essenziali:

   • Una copia immutabile, cioè non modificabile né cancellabile per un periodo definito, nemmeno da chi possiede le credenziali di amministrazione. È ciò che distingue un backup che sopravvive a un attacco da uno che viene cifrato insieme al resto.
   • Ripristini di prova periodici, cronometrati e verbalizzati. Un backup mai testato non è una protezione: è una speranza documentata.

   Su questo punto siamo diretti con i clienti anche quando non è quello che vorrebbero sentire: la ridondanza non è un backup. Un secondo disco, un sistema RAID o la sincronizzazione su cloud proteggono dal guasto di un componente, non da una cancellazione, da un errore umano o da un file cifrato — che si propagano istantaneamente a tutte le copie sincronizzate.

   Va inoltre verificato che il backup non sia raggiungibile con le stesse credenziali dei sistemi principali: è la prima cosa che un attaccante cerca, ed è la ragione per cui le copie immutabili esistono.

5. 05

   Migrazione, per passi reversibili

   La migrazione vera e propria si svolge per fasi, con una regola che non deroghiamo mai: ogni passo deve avere una via di ritorno.

   Nella pratica significa:

   • Si migra un sistema alla volta, partendo da quelli meno critici per rodare la procedura.
   • Ogni migrazione ha un piano di ritorno scritto, con tempi e criteri decisionali definiti prima di iniziare: entro quale ora si decide di tornare indietro se qualcosa non torna.
   • Il sistema vecchio resta disponibile, spento ma ripristinabile, per un periodo concordato — non lo si smantella il giorno dopo.
   • I fermi si concentrano fuori dall'orario operativo, che in un'azienda con magazzino su due turni va concordato con attenzione e non dato per scontato.
   • Ogni finestra di intervento prevede un momento di verifica con gli utenti reali prima di dichiararla conclusa: non basta che il servizio risponda, deve funzionare il lavoro delle persone.
6. 06

   Visibilità: accorgersi delle cose

   Un'infrastruttura sicura senza monitoraggio è un'infrastruttura sicura di cui nessuno può dimostrare nulla. Si introducono quindi:

   • Monitoraggio della disponibilità dei sistemi critici, con avvisi che arrivano a qualcuno che può intervenire — non a una casella che nessuno legge.
   • Raccolta centralizzata dei registri, conservati per un periodo definito. Senza registri non si scopre un incidente e, dopo, non lo si ricostruisce.
   • Protezione comportamentale delle postazioni, con visibilità centralizzata degli allarmi.
   • Controllo dello stato degli aggiornamenti su tutto il parco macchine.

   Vale la pena sottolineare un aspetto che collega questa fase agli obblighi normativi: le scadenze di notifica in caso di incidente — 72 ore per le violazioni di dati personali, e i termini più stretti previsti per i soggetti che rientrano nel perimetro della direttiva europea sulla sicurezza delle reti — presuppongono tutte di essersi accorti di qualcosa. Il monitoraggio non è un lusso tecnico: è il presupposto della conformità.

7. 07

   Documentazione, procedure e trasferimento di conoscenza

   La chiusura del progetto non è l'ultimo server migrato. È la consegna di:

   • Mappa aggiornata dell'infrastruttura, mantenuta viva nel tempo.
   • Procedure operative scritte per le situazioni ricorrenti: nuovo assunto, cessazione, ripristino di un file, guasto di un sistema, incidente di sicurezza.
   • Piano di continuità, con ruoli assegnati, contatti reperibili fuori orario e — dettaglio che sembra banale e non lo è — una copia cartacea, perché un piano di emergenza salvato solo sul sistema che si è fermato non serve a nulla.
   • Formazione del personale, sia tecnico sia utente finale.

Ordini di grandezza indicativi per un progetto strutturato così, non dati misurati su un caso reale.

Il cambiamento più significativo, però, non è misurabile con un indicatore: è il passaggio da “speriamo che non succeda” a “sappiamo cosa fare se succede”. È anche l’unico argomento che, nella nostra esperienza, convince davvero una direzione a finanziare un intervento di questo tipo — perché sposta la discussione dal costo della tecnologia al costo del fermo.

Un progetto di questa natura ha due caratteristiche che preferiamo dichiarare in fase di offerta, invece di lasciarle scoprire strada facendo.

Non è un intervento invisibile. Ci saranno finestre di fermo programmato, richieste di collaborazione agli utenti, un periodo di assestamento in cui qualcosa funzionerà diversamente da prima. Pianificarle e comunicarle in anticipo è parte del lavoro; fingere che non esistano è il modo migliore per perdere la fiducia dell'azienda a metà progetto.

Una parte della spesa diventa ricorrente. Licenze, servizio di conservazione delle copie, monitoraggio, aggiornamenti, verifiche periodiche. Un'infrastruttura mantenuta costa ogni anno; il punto è che costa molto meno di un fermo prolungato, e la differenza va mostrata con i numeri dell'azienda, non con statistiche generiche.