Infrastruttura IT sicura e resiliente per aziende
Un'infrastruttura IT moderna non deve soltanto funzionare. Deve continuare a erogare i servizi quando un componente si guasta, limitare l'impatto di un attacco, proteggere i dati e consentire un ripristino verificabile. Per questo server, rete, sicurezza, backup e cloud si progettano insieme, come parti di un unico sistema.
- Architettura e dipendenze
- Sicurezza by design
- Backup e disaster recovery
- Resilienza proporzionata
- Prestazioni
- risorse adeguate ai carichi reali, non a quelli immaginati
- Sicurezza
- identità, rete e sistemi protetti per progetto
- Continuità
- i servizi critici restano disponibili se un componente cade
- Recuperabilità
- dati e servizi si ripristinano, e lo si è verificato
- Scalabilità
- si cresce aggiungendo, non rifacendo
- Gestibilità
- documentata, monitorata, aggiornabile
- Governance
- responsabilità, rischi e decisioni sono chiari
Sette proprietà dello stesso sistema: migliorarne una a scapito delle altre non rende l'infrastruttura più solida.
01 Il punto di partenza
La complessità IT di una PMI non dipende dal numero di dipendenti
Un'azienda di venti persone può dipendere dall'informatica più di una di duecento. Conta quanto il lavoro si ferma quando l'IT si ferma.
Una PMI oggi lavora su un gestionale o un ERP, su un database, su Microsoft 365, spesso su un e-commerce o su applicazioni web, su file condivisi, su accessi da remoto e VPN, magari su più sedi e su servizi cloud di fornitori diversi. Ognuno di questi elementi ha dipendenze proprie, e molti sono critici per il fatturato del giorno.
Per questo la domanda corretta non è «quanti server servono a un'azienda come la nostra», ma «quali servizi non possono fermarsi, per quanto tempo e con quanta perdita di dati». È da qui che si dimensiona un'infrastruttura, non dall'organigramma.
Che cosa determina davvero la complessità
- Dipendenza del business dall'IT
- Criticità dei servizi
- Utenti e dispositivi
- Carichi di lavoro e applicazioni
- Numero di sedi
- Volume e crescita dei dati
- Tolleranza alla perdita di dati (RPO)
- Tempo di ripristino accettabile (RTO)
- Esposizione al rischio cyber
- Accessi remoti e fornitori
- Integrazioni fra sistemi
- Obblighi normativi e contrattuali
- Dipendenze da servizi cloud
02 Da elementi separati a un sistema
Un'infrastruttura IT non è un elenco di prodotti
Il modo più comune di costruire l'IT di una PMI è per acquisti successivi: un server quando serve, un firewall dopo un problema, un backup quando qualcuno lo chiede. Ogni pezzo può essere buono. L'insieme raramente lo è.
Approccio frammentato
- Server
- Firewall
- Backup
- Antivirus
Acquistati e gestiti separatamente, spesso da fornitori diversi. Nessuno risponde di come si comportano insieme quando qualcosa va storto.
Approccio di System Integration
- Servizi di business
- Applicazioni
- Identità
- Endpoint
- Rete
- Sicurezza
- Calcolo
- Virtualizzazione
- Storage
- Dati
- Backup
- Disaster recovery
- Cloud
- Monitoraggio
- Processi
Progettati come un unico sistema: ogni componente è scelto sapendo da chi dipende, chi dipende da lui e cosa succede se si ferma.
03 Cos'è oggi un'infrastruttura IT
Infrastruttura IT non significa «server»
Un'infrastruttura IT aziendale è l'insieme degli strati che portano un servizio dal bisogno dell'azienda fino al dato salvato e recuperabile. Ogni strato regge quello sopra.
- Businessi processi e i servizi che l'azienda deve erogare
- Utentipersone, ruoli, sedi, lavoro da remoto
- Identitàaccount, autenticazione, privilegi
- EndpointPC, portatili, dispositivi mobili
- ReteLAN, Wi-Fi, collegamenti fra sedi, VPN
- Sicurezzaperimetro, segmentazione, controlli
- Calcolo e virtualizzazioneserver fisici, hypervisor, macchine virtuali
- Storagedischi, NAS, SAN, dove vivono i dati
- Applicazionigestionale, ERP, posta, e-commerce, database
- Datil'elemento che non si ricompra, se perso
- Backupcopie separate e recuperabili dei dati
- Disaster recoverycome si riportano in servizio i sistemi
Trasversali a tutti gli strati
- Monitoraggio
- Log
- Sicurezza
- Governance
- Gestione
04 Perché serve un System Integrator
La specializzazione è necessaria, ma nessuna tecnologia vive da sola
Le dieci confusioni che incontriamo più spesso hanno la stessa radice: si attribuisce a un singolo componente una proprietà che appartiene al sistema.
Cluster in alta affidabilità≠dati recuperabili
Un cluster mantiene acceso il servizio se cade un nodo, ma non protegge i dati: una cancellazione, un errore o una cifratura da ransomware agiscono sull'unica copia, o vengono replicati sugli altri nodi. Senza backup separati, i dati persi restano persi.
Backup≠ripristino verificato
Un backup vale quanto il suo ultimo ripristino riuscito. Finché nessuno lo ha provato, è un'ipotesi.
Firewall≠identità protette
Il firewall filtra il traffico, ma non sa se chi entra con credenziali valide sia davvero chi dice di essere. Servono MFA e gestione dei privilegi.
Alta affidabilità≠disaster recovery
L'alta affidabilità copre il guasto di un componente nella stessa sede. Il disaster recovery copre la perdita della sede, dei dati o di tutto l'ambiente.
RAID≠backup
Il RAID tollera la rottura di uno o più dischi. Non protegge da cancellazioni, corruzione logica, ransomware o guasto del controller.
Snapshot≠backup
Uno snapshot vive di solito sullo stesso storage dei dati: se lo storage si guasta o viene compromesso, si perdono entrambi.
Replica≠backup
La replica copia le modifiche, anche quelle sbagliate. Diventa protezione solo se conserva punti di ripristino nel tempo, separati dalla produzione.
Cloud≠nessuna responsabilità
Il fornitore cloud gestisce la sua parte. Configurazioni, identità, dati e loro backup restano in larga parte responsabilità dell'azienda.
Cybersecurity≠un prodotto
La sicurezza è un insieme di controlli su identità, rete, sistemi, dati e processi. Un singolo prodotto ne copre una parte.
Compliance≠una tecnologia installata
Gli obblighi normativi riguardano governance, processi e responsabilità. La tecnologia ne supporta l'attuazione, non la sostituisce.
Spesso il problema non è la mancanza di tecnologia. È la mancanza di integrazione: componenti validi che nessuno ha progettato per lavorare insieme.
05 Il ruolo della consulenza IT
La tecnologia si sceglie dopo, non prima
La consulenza è il ponte fra le esigenze dell'azienda e l'architettura tecnica. Il suo compito è definire che cosa serve prima di decidere con che cosa farlo.
Dai requisiti all'evoluzione
- Requisiti di business
- Assessment dell'esistente
- Inventario degli asset
- Mappa delle dipendenze
- Analisi del rischio
- Capacità e crescita
- Requisiti di sicurezza
- Requisiti di continuità
- RPO e RTO per servizio
- Architettura
- Scelta delle tecnologie
- Integrazione
- Monitoraggio
- Evoluzione
Quando un progetto parte dal prodotto («ci serve un nuovo server», «passiamo al cloud»), l'architettura finisce per adattarsi a quella scelta invece del contrario. Quando parte dai requisiti, la stessa decisione può risultare giusta, sbagliata o semplicemente prematura, e lo si sa prima di spendere.
Nella sequenza qui accanto la scelta delle tecnologie arriva all'undicesimo passo. Prima ci sono i servizi da proteggere, le dipendenze fra i sistemi, i rischi, la crescita prevista e il tempo di fermo che l'azienda può sostenere. Sono queste informazioni a dire se servono due server o un cluster, un backup locale o anche una copia fuori sede, un firewall nuovo o una rete segmentata meglio.
È il lavoro che svolgiamo nella consulenza informatica e nella progettazione dei sistemi: questa pagina spiega il quadro d'insieme, le pagine dedicate entrano nel merito dei servizi.
06 I componenti dell'infrastruttura
Dodici componenti, una sola architettura
Per ciascun componente: a cosa serve, da cosa dipende e quale rischio gestisce. È la lettura che rende evidente perché nessuno di loro può essere progettato da solo.
Calcolo
- Funzione
- Fornisce CPU e memoria ai servizi.
- Dipende da
- Alimentazione, raffreddamento, storage, rete.
- Rischio che gestisce
- Rallentamenti e fermi per risorse insufficienti o hardware guasto.
Virtualizzazione
- Funzione
- Separa i servizi in macchine virtuali e li rende spostabili.
- Dipende da
- Calcolo, storage (condiviso o replicato), rete di gestione.
- Rischio che gestisce
- Un guasto o un aggiornamento che trascina più servizi insieme.
Rete
- Funzione
- Collega utenti, sedi, server e servizi esterni.
- Dipende da
- Apparati, cablaggio, collegamenti Internet.
- Rischio che gestisce
- Servizi integri ma irraggiungibili; propagazione di un attacco.
Identità
- Funzione
- Stabilisce chi può accedere a cosa.
- Dipende da
- Directory, MFA, processi di assunzione e uscita.
- Rischio che gestisce
- Accessi con credenziali rubate, privilegi eccessivi.
Sicurezza
- Funzione
- Previene, rileva e contiene gli attacchi.
- Dipende da
- Rete segmentata, identità, aggiornamenti, log.
- Rischio che gestisce
- Compromissione e movimento laterale fra i sistemi.
Storage
- Funzione
- Conserva dati e dischi delle macchine virtuali.
- Dipende da
- Dischi, controller, rete dello storage.
- Rischio che gestisce
- Perdita o lentezza dei dati per tutti i servizi che lo usano.
Backup
- Funzione
- Mantiene copie separate e recuperabili.
- Dipende da
- Storage separato, rete, credenziali protette.
- Rischio che gestisce
- Perdita definitiva dei dati dopo guasti, errori o ransomware.
Disaster recovery
- Funzione
- Riporta in servizio i sistemi dopo un evento grave.
- Dipende da
- Backup o repliche fuori sede, procedure, test.
- Rischio che gestisce
- Fermo prolungato dopo la perdita di una sede o dell'ambiente.
Monitoraggio
- Funzione
- Rende osservabile lo stato del sistema.
- Dipende da
- Metriche, log, soglie, qualcuno che riceve gli allarmi.
- Rischio che gestisce
- Problemi scoperti dagli utenti invece che dai tecnici.
Cloud
- Funzione
- Estende l'infrastruttura con servizi esterni.
- Dipende da
- Connettività, identità, contratti e configurazioni.
- Rischio che gestisce
- Dipendenza dal fornitore, dati e configurazioni non governati.
Applicazioni
- Funzione
- Erogano il lavoro quotidiano: gestionale, posta, e-commerce.
- Dipende da
- Tutti gli strati sottostanti.
- Rischio che gestisce
- È qui che l'utente vede il fermo, qualunque sia la causa.
Governance
- Funzione
- Assegna responsabilità, priorità e decisioni.
- Dipende da
- Documentazione, inventario, processi.
- Rischio che gestisce
- Interventi improvvisati, rischi non visti, nessuno che decide.
07 La catena delle dipendenze
Un servizio aziendale è una catena: si rompe nell'anello più debole
L'utente vede «il gestionale non va». Sotto ci sono almeno dieci livelli, e il guasto di uno solo basta a fermare il servizio anche se tutti gli altri funzionano.
- Servizio di businessemettere un ordine, fatturare
- Applicazioneil gestionale
- Databasedove il gestionale scrive
- Macchina virtualeil sistema che ospita il database
- Hypervisoril server che esegue le VM
- Storagei dischi delle VM
- Reteswitch, VLAN, firewall interno
- Identità e sicurezzachi può accedere e da dove
- Backup e DRcome si torna indietro
- Monitoraggiochi se ne accorge, e quando
Scenario di esempio
Il server è acceso, ma l'azienda è ferma
Lo storage condiviso arriva al limite dello spazio. L'hypervisor è in funzione, le macchine virtuali risultano accese, la rete risponde. Ma il database non riesce più a scrivere, il gestionale va in errore e gli ordini si fermano.
Nessun componente è «rotto» nel senso classico. Il problema è che nessuno aveva collegato la crescita dei dati alla capacità dello storage e a un allarme che arrivasse prima del blocco. È un errore di integrazione, non di tecnologia.
Ragionare come System Integrator significa partire dal servizio e scendere lungo la catena, chiedendosi per ogni anello che cosa lo può fermare, chi se ne accorge e come si ripristina.
08 Architettura di riferimento
Un esempio concettuale di architettura resiliente
Non è un modello da copiare: è uno schema per mostrare come i componenti si collegano. Ogni azienda ne realizza una versione proporzionata ai propri servizi e rischi.
Perimetro e segmentazione
Il firewall separa l'azienda da Internet, ma è la segmentazione interna a impedire che la compromissione di un PC raggiunga server e backup.
Cluster e storage
Più nodi consentono di spostare le macchine virtuali durante guasti e manutenzioni. Se lo storage è condiviso (SAN o NAS) e non è a sua volta ridondato, resta un unico punto di guasto sotto tutti i nodi; con storage distribuito o replicato, per esempio Ceph, i dati stanno su più nodi ma servono rete dedicata e dimensionamento corretto. In nessun caso sostituisce il backup.
Backup su più livelli
La copia locale serve ai ripristini rapidi, quella fuori sede alla perdita della sede, quella isolata o immutabile ai casi in cui un attaccante arriva anche ai backup.
Disaster recovery
L'ambiente di DR può essere un secondo sito, un'infrastruttura in cloud o una procedura di ricostruzione: conta che sia documentato, dimensionato e provato.
09 Virtualizzazione e Proxmox
La virtualizzazione organizza i carichi di lavoro, non li protegge da sola
È lo strato che rende gestibile un'infrastruttura moderna. Proprio per questo va progettata insieme a storage, rete e backup.
Virtualizzare significa eseguire più server logici sullo stesso hardware, ognuno isolato dagli altri. Il vantaggio non è solo il consolidamento: è poter trattare un server come un oggetto che si crea, si sposta, si clona e si ripristina.
- Consolidamento. Meno hardware fisico per lo stesso numero di servizi, con risorse assegnate in base al carico reale.
- Isolamento. Ogni ruolo nella sua macchina virtuale: il picco o il guasto di un servizio non trascina gli altri.
- Provisioning. Un nuovo server si prepara in minuti da un modello, non in giorni.
- Cluster e alta affidabilità. Con più nodi e storage condiviso o replicato, le VM vengono riavviate automaticamente su un altro nodo se uno si guasta.
- Manutenzione. Con storage condiviso o replicato si aggiorna un nodo alla volta migrando le VM, di norma senza fermare i servizi.
- Migrazione e crescita. Si aggiunge capacità o si cambia hardware senza reinstallare i servizi.
Dove usiamo Proxmox VE
Proxmox VE è una piattaforma di virtualizzazione open source che usiamo nei progetti dei clienti quando è coerente con i requisiti, e sulla nostra infrastruttura: Hector Cluster, l'infrastruttura su cui girano i servizi Hector di TN Solutions (Hector AI, Hector LIS, Hector Biz), poggia su ambienti Linux virtualizzati con Proxmox dietro un perimetro pfSense.
Non è sempre la scelta giusta. In ambienti con licenze VMware già in essere, competenze interne consolidate o requisiti specifici di certificazione delle applicazioni, la valutazione può portare altrove. Il confronto va fatto su costi, funzionalità, competenze e percorso di migrazione, non sull'etichetta.
10 Open source in azienda
Open source o proprietario: si decide sull'architettura, non sull'etichetta
Le tecnologie open source mature hanno un ruolo concreto nelle infrastrutture aziendali. Non perché siano sempre migliori o sempre più economiche, ma perché in molti casi offrono un buon equilibrio fra controllo, interoperabilità e costo complessivo.
Interoperabilità
Standard aperti e formati documentati facilitano l'integrazione con il resto dell'infrastruttura.
Controllo
Configurazione e comportamento sono ispezionabili: si sa cosa si sta eseguendo.
Licenze
Nessun costo di licenza d'uso, ma il supporto professionale è spesso a sottoscrizione (per Proxmox VE, per socket CPU).
Vendor lock-in
Meno dipendenza dalle scelte commerciali di un unico fornitore, purché anche dati e procedure restino portabili.
Supportabilità
Serve qualcuno che sappia gestirla in produzione: interno, fornitore o comunità non sono equivalenti.
Competenze
Il risparmio di licenza si trasforma in costo se mancano le competenze per configurarla e mantenerla.
Ciclo di vita
Versioni, aggiornamenti e fine supporto vanno pianificati come per qualunque prodotto.
TCO
Il costo totale include licenze, hardware, competenze, manutenzione, fermi e uscita dalla piattaforma.
Tecnologie open source che usiamo e documentiamo
- Proxmox VEvirtualizzazione e cluster
- Linuxserver e servizi applicativi
- pfSensefirewall e segmentazione
- HAProxybilanciamento e terminazione TLS
- MariaDB e Galeradatabase e replica sincrona
- Rediscache in memoria e sessioni
- Elasticsearchmotore di ricerca
- Dockerservizi applicativi in container
La tecnologia deve essere scelta in funzione dell'architettura, dei requisiti e del TCO, non dell'etichetta open source o proprietaria. Nelle stesse infrastrutture usiamo anche Windows Server, VMware, WatchGuard e Synology, quando sono la risposta migliore.
11 Applicazioni e Microsoft 365
Le applicazioni sono l'ultimo anello, e spesso stanno in cloud
Posta, documenti, collaborazione e identità vivono sempre più spesso in Microsoft 365. Non per questo escono dall'infrastruttura: ne diventano una parte, con le stesse domande su sicurezza, recuperabilità e governo.
Un tenant Microsoft 365 dipende dall'identità degli utenti, dai dispositivi da cui si accede, dalla rete e dai record DNS del dominio. A sua volta regge la posta, i file e la comunicazione dell'azienda. È un componente dell'architettura come gli altri, e va progettato con gli stessi criteri.
Gli errori tipici sono gli stessi visti finora: un tenant senza MFA sugli amministratori, una migrazione della posta che dimentica DNS e caselle condivise, un file server copiato in SharePoint con tutto il suo disordine, licenze scelte senza sapere quali controlli servono, dati affidati al cestino come se fosse un backup.
- Exchange Online posta e calendari: identità, DNS, sicurezza e migrazione vanno progettati insieme.
- SharePoint, OneDrive e Teams contenuti e collaborazione: prima l'architettura delle informazioni e i permessi, poi la migrazione.
- Entra ID e Intune identità, accesso condizionale e dispositivi: il nuovo perimetro.
- Licenze il piano giusto dipende da ruoli, dispositivi e controlli di sicurezza richiesti, non dal prezzo.
- Backup conservazione e cestino non sono un backup indipendente dei dati del tenant.
12 Cybersecurity by design
Sicurezza e infrastruttura non si progettano separatamente
Una rete piatta, un backup raggiungibile con le credenziali di dominio o un pannello di gestione esposto non si correggono con un prodotto in più: sono scelte architetturali.
Segmentazione
Reti separate per utenti, server, gestione, ospiti e backup, con regole esplicite fra le zone.
Firewall e VPN
Perimetro controllato e accessi remoti solo attraverso canali cifrati e autenticati.
MFA
Autenticazione a più fattori almeno per accessi remoti, posta e account amministrativi.
Minimo privilegio
Ogni account ha solo i permessi che gli servono, e i privilegi elevati sono separati dall'uso quotidiano.
Hardening
Servizi non necessari spenti, configurazioni sicure, interfacce di gestione non raggiungibili da reti non fidate.
Patch management
Aggiornamenti pianificati su sistemi, firmware e applicazioni, con priorità alle vulnerabilità sfruttate.
EDR
Rilevamento e risposta sugli endpoint e sui server, dove il rischio lo giustifica.
Log e monitoraggio
Eventi raccolti e conservati per capire che cosa è successo e accorgersene in tempo.
Gestione delle vulnerabilità
Verifiche periodiche, dal vulnerability assessment al penetration test quando serve.
Accessi amministrativi
Postazioni e percorsi dedicati per la gestione, credenziali dei backup distinte da quelle di dominio.
Ogni controllo dipende dagli altri: l'MFA protegge le identità, la segmentazione limita i danni se un'identità viene comunque compromessa, i log permettono di ricostruire l'accaduto e i backup isolati permettono di ripartire.
13 NIS2 come esempio
Perché NIS2 parla di continuità e backup, non solo di sicurezza
La direttiva NIS2 è un buon esempio di come rischio, sicurezza e continuità vengano ormai trattati insieme.
La direttiva (UE) 2022/2555, recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138, chiede ai soggetti essenziali e importanti che rientrano nel suo ambito misure di gestione del rischio proporzionate che vanno oltre la protezione tecnica (art. 21): comprendono la continuità operativa, inclusa la gestione dei backup, il disaster recovery e la gestione delle crisi, la gestione degli incidenti, la sicurezza della catena di fornitura e la valutazione dell'efficacia delle misure. Gli organi di gestione approvano le misure e ne rispondono (art. 20).
Non tutte le PMI rientrano nell'ambito della NIS2: l'applicabilità dipende dal settore, dalla dimensione e da altri criteri previsti dalla norma, e va verificata caso per caso. Ma l'elenco delle misure è utile a chiunque, perché descrive le aree che un'infrastruttura resiliente deve coprire.
Nessuna tecnologia rende un'azienda conforme da sola. Un'infrastruttura progettata bene supporta l'attuazione delle misure; la conformità resta responsabilità dell'organizzazione, che la costruisce con processi, documentazione e governance. Noi affianchiamo i clienti sulla parte tecnica.
Aree che la NIS2 mette insieme
- Analisi dei rischi e politiche di sicurezza
- Gestione degli incidenti
- Continuità operativa, backup e disaster recovery
- Sicurezza della catena di fornitura
- Gestione delle vulnerabilità
- Controllo degli accessi e gestione degli asset
- Valutazione dell'efficacia delle misure
- Crittografia e autenticazione a più fattori
- Igiene informatica, formazione e responsabilità degli organi di gestione
Fonti primarie
Contenuto tecnico a scopo informativo, non consulenza legale. Per stabilire se e come la NIS2 si applica alla vostra organizzazione fate riferimento alle fonti ufficiali e a un consulente legale.
14 Backup, disaster recovery e continuità
Dal dato salvato al servizio ripristinato
Backup, disaster recovery e business continuity sono tre livelli diversi della stessa domanda: che cosa succede, e in quanto tempo si riparte, se si perde qualcosa.
- Produzionei dati e i servizi in uso
- Backupcopie a intervalli definiti
- Separazionesu sistemi e credenziali diversi dalla produzione
- Fuori sedeuna copia lontana dalla sede principale
- Isolamento o immutabilitàuna copia che un attaccante, anche con credenziali compromesse, non può cancellare o modificare finché dura la retention
- Test di ripristinola prova che le copie funzionano
- Disaster recoveryla procedura per riportare in servizio i sistemi
- Business continuitycome l'azienda continua a lavorare nel frattempo
- RPO · Recovery Point Objective
- La quantità massima di dati che l'azienda accetta di perdere, espressa in tempo. Con un solo backup notturno l'RPO effettivamente ottenibile è fino a 24 ore: si torna ai dati della notte prima.
- RTO · Recovery Time Objective
- Il tempo massimo entro cui un servizio deve tornare disponibile dopo un'interruzione. Dipende da dove sono le copie, da quanto sono grandi e da quanto è pronta la procedura.
- Backup
- Una copia dei dati, separata dalla produzione, da cui si può ripristinare uno stato precedente.
- Disaster recovery
- L'insieme di infrastruttura e procedure per riportare in servizio i sistemi dopo un evento che rende inutilizzabile l'ambiente principale.
- Business continuity
- La capacità dell'azienda di continuare le attività essenziali durante e dopo un'interruzione, IT compresa ma non solo.
| Tecnologia o processo | Cosa protegge | Cosa non protegge | Ruolo nell'architettura |
|---|---|---|---|
| RAID | Il guasto di uno o più dischi, secondo il livello | Cancellazioni, corruzione, ransomware, guasto del controller o del server | Disponibilità dello storage |
| Snapshot | Il ritorno rapido a uno stato precedente, per esempio prima di un aggiornamento | Il guasto o la compromissione dello storage su cui risiede | Strumento operativo, non copia indipendente |
| Replica | La disponibilità di una copia aggiornata su un altro sistema | Errori, cancellazioni e cifrature, che vengono replicati; protegge da questi solo se conserva punti di ripristino separati dalla produzione | Riduzione dell'RTO e base per l'alta affidabilità o il DR |
| Backup | Il recupero dei dati a un punto nel tempo | Il fermo del servizio durante il ripristino; la perdita dei dati dopo l'ultima copia | Recuperabilità dei dati |
| Backup fuori sede | La perdita della sede: incendio, furto, allagamento | Un attacco che raggiunge anche la copia remota con le stesse credenziali | Protezione geografica |
| Backup immutabile o isolato | La cancellazione o la cifratura dei backup da parte di un attaccante | I dati prodotti dopo l'ultima copia; un backup già compromesso alla fonte (dati cifrati o malware dormiente copiati); un ripristino mai provato | Ultima barriera contro la cancellazione dei backup |
| Alta affidabilità | Il guasto di un componente: nodo, alimentatore, collegamento | Errori logici, ransomware, perdita della sede | Continuità del servizio, di norma nella stessa sede (i cluster estesi su più siti sono un caso a parte) |
| Disaster recovery | La perdita dell'ambiente principale | Un piano mai provato; i dati successivi all'ultima copia o replica (RPO); il fermo durante il ripristino | Ripristino dei servizi entro l'RTO definito |
| Business continuity | La continuità delle attività essenziali dell'azienda | Non sostituisce nessuno dei livelli tecnici | Quadro organizzativo che li coordina |
Una strategia di backup ha valore operativo solo quando il ripristino è verificabile: per questo i test di ripristino sono un passo dell'architettura, non un'attività facoltativa.
15 Tre livelli di criticità
Non esiste un'infrastruttura giusta per tutte le PMI
Gli scenari che seguono mostrano come cambiano le scelte al crescere della criticità. Non dipendono dalla dimensione dell'azienda: una piccola realtà può stare al terzo livello, una grande al primo.
Servizi standard
Un fermo di qualche ora è un disagio, non un danno grave. I dati cambiano poco nell'arco della giornata.
Servizi business critical
Gestionale, produzione o vendite si fermano con l'IT. Ogni ora di fermo e ogni dato perso hanno un costo misurabile.
Alta criticità o requisiti specifici
Servizi che non possono fermarsi, dati regolamentati, obblighi contrattuali o normativi stringenti.
| Aspetto | Servizi standard | Servizi business critical | Alta criticità o requisiti specifici |
|---|---|---|---|
| Ridondanza | Componenti critici ridondati (dischi, alimentazione) | Server e rete ridondati sui servizi critici | Ridondanza estesa, anche fra siti |
| Alta affidabilità | Di solito non necessaria | Cluster sui servizi critici | Cluster e servizi progettati per il failover |
| Backup | Locale e fuori sede | Più frequenti, con copia isolata o immutabile | Più livelli, retention definita, copie isolate |
| RPO / RTO | Definiti, anche ampi | Definiti per servizio e verificati | Stretti, contrattualizzati e provati |
| Monitoraggio | Stato dei sistemi e dei backup | Metriche, soglie e allarmi con escalation | Monitoraggio continuo con reperibilità |
| Controlli di sicurezza | Firewall, MFA, aggiornamenti, antivirus o EDR | Segmentazione, EDR, log centralizzati | Controlli estesi, verifiche periodiche e test |
| Disaster recovery | Procedura di ricostruzione documentata | Piano di DR con ambiente di ripristino | Sito o ambiente di DR pronto e provato |
| Test | Ripristini a campione | Test di ripristino pianificati | Esercitazioni di DR periodiche |
| Documentazione | Inventario e schema di rete | Più procedure operative e di ripristino | Più ruoli, responsabilità e registro delle prove |
| SLA | Tempi di intervento standard | Tempi garantiti sui servizi critici | SLA stringenti e presidio esteso |
Valori indicativi per mostrare la logica, non requisiti universali: RPO, RTO e SLA si definiscono servizio per servizio durante l'assessment.
16 Cosa succede senza integrazione
Nove problemi che nascono fra un componente e l'altro
Nessuno di questi casi richiede tecnologia sbagliata. Basta tecnologia giusta messa insieme senza un progetto.
Virtualizzazione senza capacity planning
Le VM si aggiungono una alla volta finché storage o memoria si saturano e rallentano tutti i servizi insieme.
Backup senza test di ripristino
Il giorno del bisogno si scopre che le copie sono incomplete, illeggibili o richiedono giorni per tornare in linea.
Cybersecurity senza inventario
Non si può proteggere ciò che non si sa di avere: il server dimenticato è quello senza aggiornamenti.
Firewall senza segmentazione
Il perimetro tiene, ma una volta dentro un attaccante raggiunge server e backup dalla rete degli utenti.
Cloud senza governance
Servizi attivati da reparti diversi, account senza MFA, dati fuori da qualunque backup aziendale.
Alta affidabilità senza disaster recovery
Il cluster regge il guasto di un nodo, ma un ransomware o un incendio colpiscono tutti i nodi insieme.
Monitoraggio senza escalation
L'allarme parte, arriva a una casella che nessuno legge, e il problema lo segnala un cliente.
Applicazione veloce su storage lento
Il nuovo gestionale è performante sulla carta, ma database e storage sono rimasti quelli di cinque anni fa.
Account privilegiati senza protezione
Un'unica credenziale di amministratore, senza MFA, usata anche per la posta: è la chiave di tutto.
Spesso il problema non è l'assenza di tecnologia. È l'assenza di integrazione.
17 Il ruolo del System Integrator
Che cosa fa un System Integrator, in concreto
Il valore non sta nel saper installare un prodotto in più, ma nel progettare e governare il modo in cui tutti i prodotti lavorano insieme.
- Comprende il servizio di business prima della tecnologia
- Identifica le dipendenze fra sistemi, applicazioni e fornitori
- Individua i singoli punti di guasto
- Valuta il rischio e lo traduce in priorità
- Definisce requisiti di sicurezza, continuità, RPO e RTO
- Progetta l'architettura
- Seleziona le tecnologie adatte ai requisiti
- Integra i componenti e ne verifica il funzionamento d'insieme
- Considera sicurezza, recuperabilità, capacità e prestazioni nello stesso progetto
- Definisce monitoraggio ed escalation
- Pianifica il ciclo di vita: aggiornamenti, rinnovi, dismissioni
Che cosa non significa. Un System Integrator non deve realizzare internamente ogni tecnologia. Può coordinare fornitori, servizi cloud e specialisti: ciò che non può delegare è la responsabilità di come l'insieme si comporta.
Initpc: un e-commerce che è un'infrastruttura
Per Initpc, di cui siamo partner tecnico dal 2006, gestiamo un e-commerce con oltre 280.000 prodotti a catalogo e più di un milione di immagini.
Non lo citiamo per raccontare un cliente, ma perché mostra bene la tesi di questa pagina: un unico servizio di business, vendere online, richiede competenze in virtualizzazione, Linux, rete, sicurezza, database, cache, ricerca, storage, backup, monitoraggio e software, progettate per lavorare insieme.
Il criterio di progetto documentato nel caso studio è chiaro: per ogni strato ci siamo chiesti che cosa succede se si ferma. Solo l'ingresso HAProxy e il database MariaDB spengono davvero il negozio, ed è su quelli che si concentrano monitoraggio e procedure di ripristino; gli altri strati sono progettati per degradare invece di bloccare la vendita.
- Il caso studio Initpc
- L'architettura dell'infrastruttura
- Infrastruttura IT e sicurezza per uno studio legale
Tutte le informazioni tecniche provengono dal caso studio pubblicato. Non riportiamo dati di uptime, RPO o RTO che il caso studio non dichiara.
Le competenze che un solo servizio ha richiesto
- VirtualizzazioneProxmox VE su Ubuntu Server, una VM per ruolo
- IngressoHAProxy per bilanciamento e terminazione TLS
- CacheVarnish per le pagine, Redis per oggetti e sessioni
- DatiMariaDB in VM dedicata, con backup propri
- RicercaElasticsearch in Docker
- PerimetropfSense e segmentazione della rete
- MonitoraggioHector LIS per intrusioni e traffico
- Storage e backupmedia su storage separato, immagini delle VM, dump del database
- Softwareintegrazione con il gestionale e sincronizzazione dei magazzini
- AIHector AI per le schede prodotto
19 Il metodo
Dall'analisi al miglioramento continuo
Sono le fasi con cui affrontiamo i progetti infrastrutturali, dalla consulenza alla gestione: coerenti con l'impostazione della progettazione dei sistemi IT: dall'analisi dei requisiti al collaudo e alla messa in produzione, con backup, controlli d'accesso, aggiornamenti e monitoraggio attivo.
Analisi
Requisiti di business, inventario, dipendenze, rischi e situazione attuale, servizio per servizio.
Progettazione
Architettura, RPO e RTO per servizio, sicurezza, capacità e scelta delle tecnologie.
Integrazione
Realizzazione per fasi, migrazione dei servizi e collaudo dell'insieme, non dei singoli pezzi.
Protezione
Controlli di sicurezza, backup su più livelli e procedure di disaster recovery.
Monitoraggio
Metriche, allarmi ed escalation verso chi interviene.
Verifica
Test di ripristino e controlli periodici: ciò che non è provato non si considera funzionante.
Miglioramento
Aggiornamenti, revisione dei rischi ed evoluzione dell'architettura con l'azienda.
20 Quanto costa un'infrastruttura resiliente
I fattori che determinano il costo
Non esiste un prezzo a utente o a server che abbia senso in astratto. Esistono fattori che, combinati, determinano l'investimento e il costo di gestione.
Dimensione
- Utenti e dispositivi
- Sedi da collegare
- Server, VM e carichi di lavoro
- Volume e crescita dei dati
Continuità
- Criticità dei servizi
- RPO e RTO richiesti
- Alta affidabilità
- Retention dei backup
- Copia fuori sede e disaster recovery
Sicurezza e regole
- Requisiti di sicurezza
- Obblighi normativi e contrattuali
- Verifiche e test periodici
Gestione
- Monitoraggio
- SLA e tempi di intervento
- Reperibilità
- Ciclo di vita e rinnovi
Perché due PMI simili possono spendere in modo molto diverso. Due aziende con trenta dipendenti: la prima usa soprattutto servizi cloud e può tollerare mezza giornata di fermo; la seconda produce su un gestionale interno, ha due sedi e perde fatturato a ogni ora di blocco. Stesso organico, requisiti di RPO, RTO, ridondanza e monitoraggio diversi: infrastrutture, e costi, diversi.
21 Checklist
Venti domande per valutare la vostra infrastruttura
Una verifica pratica, senza punteggi: ogni risposta «no» o «non lo so» è un punto da approfondire.
Conoscenza
- Esiste un inventario aggiornato di asset e servizi?
- C'è uno schema di rete aggiornato?
- Sono documentate le dipendenze fra i servizi critici?
- È chiaro chi è responsabile di cosa, anche fra i fornitori?
Sicurezza
- La rete è segmentata?
- Gli aggiornamenti seguono un processo pianificato?
- Gli amministratori usano l'MFA?
- I privilegi sono assegnati per necessità e rivisti?
- I log vengono raccolti e conservati?
Recuperabilità
- I backup stanno su sistemi separati dalla produzione?
- Esiste una copia fuori sede?
- Esiste una copia isolata o immutabile dove serve?
- I ripristini vengono provati periodicamente?
- Sono definiti RPO e RTO per ogni servizio critico?
Continuità e gestione
- L'alta affidabilità c'è dove serve, e solo lì?
- Esiste un piano di disaster recovery scritto?
- Gli allarmi hanno un percorso di escalation?
- La documentazione operativa è aggiornata?
- Ci sono test periodici dell'insieme?
- È pianificato il ciclo di vita di hardware e software?
La checklist non sostituisce un assessment: serve a capire da dove cominciare.
Non sono servizi isolati: sono parti della stessa architettura
- Consulenza IT
- comprende business, requisiti, rischi e vincoli
- Architettura
- definisce come i componenti devono funzionare insieme
- System Integration
- integra tecnologie e sistemi
- Cybersecurity
- protegge identità, rete, sistemi e dati
- Virtualizzazione
- organizza e rende gestibili i carichi di lavoro
- Networking
- connette e segmenta
- Storage
- sostiene dati e carichi di lavoro
- Backup
- protegge la recuperabilità dei dati
- Disaster recovery
- pianifica il ripristino dei servizi
- Business continuity
- protegge la continuità del lavoro
- Monitoraggio
- rende osservabile il sistema
- Cloud
- estende l'architettura quando è appropriato
- Open source
- offre tecnologie da usare quando coerenti con requisiti e TCO
- NIS2
- mostra perché rischio, sicurezza, continuità e governance vanno affrontati insieme
Le tecnologie sono strumenti. L'architettura è il valore. La consulenza stabilisce che cosa serve, la System Integration fa funzionare insieme le parti, la resilienza permette al sistema di sostenere l'azienda anche quando qualcosa va storto.
22 · Assessment dell'infrastruttura
Richiedi un assessment dell'infrastruttura IT
Partiamo dai vostri servizi e da come lavorate oggi. Il risultato è un quadro chiaro di rischi, priorità e interventi proporzionati, non un preventivo di prodotti.
Cosa può comprendere
- Architettura attuale
- Dipendenze fra i servizi
- Singoli punti di guasto
- Virtualizzazione
- Rete
- Cybersecurity
- Backup e recuperabilità
- Monitoraggio
- Capacità
- RPO e RTO
- Scalabilità
- Ciclo di vita
Il perimetro dell'assessment si concorda all'inizio, in base alle dimensioni e alla criticità dell'ambiente.