Un server compromesso raramente rappresenta la fine di un attacco. Se quel server può raggiungere ogni altra macchina della rete, un intruso potrebbe usarlo come punto di partenza per rubare credenziali, distribuire ransomware, modificare applicazioni o attaccare i sistemi di backup. La segmentazione di rete riduce il raggio d'azione dell'attacco controllando quali sistemi possono comunicare e per quale motivo.
La segmentazione non consiste in un singolo prodotto o in un'unica impostazione. È una disciplina di progettazione che combina VLAN, subnet, zone di sicurezza, routing, policy firewall, controlli delle identità e monitoraggio. L'obiettivo è semplice: un server web non dovrebbe poter avviare connessioni arbitrarie verso i laptop dei dipendenti, un database non dovrebbe essere raggiungibile da Internet e un server di produzione non dovrebbe avere automaticamente accesso amministrativo all'infrastruttura di backup.
Per agenzie e piccole imprese, una progettazione ragionevole non deve essere complicata. Deve però riflettere il funzionamento effettivo dei sistemi, usare ove possibile l'accesso negato per impostazione predefinita ed essere verificata regolarmente. La segmentazione dovrebbe inoltre integrare una strategia di backup isolata e ripristinabile. Non può garantire che una violazione venga contenuta e non può ripristinare dati che un attaccante ha crittografato o eliminato.
Da cosa protegge la segmentazione di rete
La segmentazione di rete divide l'infrastruttura in aree separate e colloca tra loro confini controllati. Questi confini possono essere implementati con reti fisiche, VLAN, subnet instradate, firewall virtuali, firewall degli host o una combinazione di questi controlli.
Il principale vantaggio in termini di sicurezza è la limitazione del movimento laterale. Il movimento laterale è il processo con cui un attaccante passa dal sistema inizialmente compromesso ad altri sistemi presenti nell'ambiente. Un server web esposto al pubblico può essere compromesso tramite un framework non aggiornato. L'attaccante cerca quindi credenziali del database, interfacce di gestione, condivisioni di file, servizi di dominio, hypervisor e console di backup. Ogni servizio raggiungibile crea un'ulteriore opportunità.
Una rete piatta rende questo processo più semplice. In una progettazione piatta, server, workstation, stampanti, hypervisor e strumenti di gestione possono trovarsi tutti nello stesso ampio intervallo IP. La raggiungibilità di rete viene spesso trattata come un'autorizzazione. Una volta entrato, l'attaccante può analizzare l'ambiente, connettersi a servizi mai destinati a essere pubblici e sfruttare controlli interni deboli.
La segmentazione modifica questa ipotesi predefinita. I sistemi vengono collocati in zone in base al loro ruolo e alla loro esposizione, mentre il traffico tra le zone viene controllato esplicitamente. Un server web compromesso può essere comunque pericoloso, ma dovrebbe disporre solo delle connessioni necessarie a fornire l'applicazione. Non dovrebbe poter analizzare la rete di gestione né connettersi a ogni server tramite desktop remoto e SSH.
Chi ricerca segmentazione di rete e sicurezza dei server contro il movimento laterale troverà numerose architetture possibili. Il punto importante non è copiare ciecamente un diagramma. La progettazione deve seguire le dipendenze reali delle applicazioni, i processi amministrativi e i requisiti di ripristino.
VLAN, subnet e zone di sicurezza: concetti correlati ma diversi
Le VLAN forniscono una separazione logica
Una LAN virtuale, o VLAN, separa i dispositivi a livello 2 anche quando utilizzano le stesse apparecchiature fisiche di switching. Ad esempio, un'azienda potrebbe collocare le workstation dell'ufficio in una VLAN, i server di produzione in un'altra e le interfacce di gestione in una terza. Le VLAN riducono l'estensione del broadcast e creano punti chiari in cui il traffico deve essere instradato.
Le VLAN da sole non costituiscono un confine di sicurezza. Se un router, uno switch di livello 3 o un firewall consente tutto il traffico tra le VLAN, la separazione è soprattutto amministrativa. Il valore in termini di sicurezza deriva dall'ispezione e dal controllo del traffico quando attraversa il confine.
Le subnet definiscono reti instradate
Ogni VLAN dispone comunemente della propria subnet IP. Una subnet per i server potrebbe usare un intervallo di indirizzi privati, mentre la subnet di gestione ne usa un altro. Le subnet rendono più semplici da comprendere route e policy firewall, ma intervalli IP separati non impediscono automaticamente la comunicazione. Sono ancora il routing e le liste di controllo degli accessi a determinare ciò che è consentito.
Le zone di sicurezza descrivono fiducia ed esposizione
Una zona di sicurezza è un concetto di policy. Raggruppa sistemi con un livello di esposizione o uno scopo di sicurezza simile. Un ambiente di piccole dimensioni può includere tipicamente:
- Zona Internet o perimetrale: firewall, proxy inversi, bilanciatori di carico e altri sistemi direttamente esposti alle reti esterne.
- Zona web: server web esposti al pubblico che accettano richieste da Internet o da un proxy perimetrale.
- Zona applicativa: servizi applicativi che dovrebbero accettare richieste solo da sistemi web o di integrazione approvati.
- Zona database: server di database che dovrebbero essere raggiungibili solo da specifici servizi applicativi e da percorsi amministrativi approvati.
- Zona di gestione: jump host, console di monitoraggio, sistemi di configurazione, gestione degli hypervisor e altre interfacce amministrative.
- Zona backup: agenti di backup, repository, sistemi di gestione e infrastruttura di ripristino separati dai carichi di lavoro di produzione.
- Zona utenti: dispositivi dei dipendenti, stampanti e altre apparecchiature d'ufficio, che in genere richiedono una policy di accesso diversa da quella dei server.
Queste zone possono essere fisiche, virtuali o ospitate da un provider. Ciò che conta è che il traffico tra loro passi attraverso un punto di applicazione delle policy e venga registrato in modo sufficiente per analizzare comportamenti imprevisti.
Progetta in base ai requisiti di comunicazione
Il punto di partenza migliore non è un elenco di numeri VLAN, ma un inventario dei servizi e dei relativi requisiti di comunicazione. Per ogni server, annota cosa fornisce, chi lo utilizza, quali porte sono necessarie, se la comunicazione viene avviata in una sola direzione o in entrambe e cosa accade se la dipendenza non è disponibile.
Poni domande come:
- Il livello web deve raggiungere il livello applicativo oppure un proxy inverso interno può svolgere questa funzione?
- Il server applicativo deve accedere direttamente al database e, in tal caso, su quale porta?
- Quali sistemi necessitano di DNS, sincronizzazione dell'ora, servizi di identità o certificati?
- Il monitoraggio interroga i server oppure gli agenti inviano i dati a un collector?
- Quali amministratori necessitano di accesso SSH, desktop remoto, console o hypervisor?
- Un server ha davvero bisogno di accesso a Internet in uscita e, in tal caso, verso quali destinazioni?
- Quali connessioni di backup vengono avviate dal server di produzione, dal server di backup o da entrambi?
Documenta le risposte in una matrice di comunicazione. Una matrice semplice può elencare zona di origine, zona di destinazione, protocollo, porta, scopo, direzione, responsabile e data di revisione. Questo evita un errore comune: consentire un'intera subnet perché un'applicazione necessita di una sola connessione.
Le dipendenze delle applicazioni devono essere verificate e non date per scontate. La documentazione del fornitore può indicare che un servizio usa una porta, mentre la distribuzione reale dipende anche da DNS, un provider di identità, un servizio di licenze, un relay SMTP o un'API cloud. Inizia con una policy prudente, osserva il traffico legittimo e aggiungi regole definite in modo restrittivo, con un responsabile identificabile.
Una progettazione pratica a livelli per agenzie e piccole imprese
Una piccola agenzia può ospitare siti web dei clienti, applicazioni interne, database e strumenti di gestione su un numero limitato di server fisici o virtuali. Potrebbe non avere un team dedicato alla sicurezza di rete. È comunque possibile adottare una progettazione utile, capace di separare i principali rischi senza creare un labirinto ingestibile.
Livello web
Il livello web comprende i sistemi che gestiscono richieste non attendibili. Questi server devono essere considerati più rischiosi perché espongono servizi a Internet. Consenti il traffico in entrata solo per i protocolli web necessari, normalmente attraverso un firewall, un proxy inverso o un livello di bilanciamento del carico. L'accesso amministrativo dovrebbe provenire dal percorso di gestione, non dall'interfaccia pubblica.
Un server web di solito deve avviare connessioni verso il livello applicativo, recuperare aggiornamenti approvati o contattare servizi esterni selezionati. Non dovrebbe avere accesso illimitato alla rete dei database, alle condivisioni di file interne, ai dispositivi dei dipendenti o alle interfacce degli hypervisor. Se il server fornisce solo contenuti statici, le destinazioni consentite possono essere ancora più limitate.
Livello applicativo
Il livello applicativo esegue la logica di business, le API, i processi in background e i servizi di integrazione. Dovrebbe accettare traffico solo da server web definiti, integrazioni attendibili o utenti interni quando necessario. L'accesso in uscita dovrebbe essere limitato ai database, alle code, ai servizi di identità e alle API esterne effettivamente utilizzati dall'applicazione.
Non dare per scontato che collocare i server applicativi e quelli di database in VLAN separate sia sufficiente. Il firewall dovrebbe consentire solo il protocollo e la porta del database necessari all'applicazione, dagli indirizzi specifici dell'applicazione. L'accesso amministrativo al database dovrebbe utilizzare un percorso di gestione separato e un'autenticazione più forte.
Livello database
I database contengono un valore concentrato e dovrebbero avere la minore esposizione di rete praticabile. Non dovrebbero accettare connessioni da Internet o dalle reti generiche degli utenti. In molti ambienti, solo un numero limitato di server applicativi dovrebbe poter connettersi al servizio database.
I server database possono aver bisogno di DNS, sincronizzazione dell'ora, monitoraggio e connettività di backup. Questi requisiti dovrebbero essere gestiti con regole separate, anziché essere inclusi in una policy permissiva generale. Se il motore database supporta la crittografia in transito e un'autenticazione forte, utilizza questi controlli come ulteriore livello di protezione. La segmentazione riduce la raggiungibilità, ma non rende automaticamente affidabile una connessione consentita.
Livello di monitoraggio e logging
I sistemi di monitoraggio hanno bisogno di visibilità, ma visibilità non significa accesso illimitato. Se gli agenti di monitoraggio inviano dati a un collector, consenti la connessione in uscita dell'agente verso quel collector. Se il collector interroga i sistemi, consenti solo i protocolli di polling necessari dalla subnet di monitoraggio.
I log dovrebbero essere inviati in una posizione che un attaccante non possa modificare facilmente dopo aver compromesso un server di produzione. Limita chi può amministrare la piattaforma di monitoraggio, proteggi separatamente le relative credenziali e genera avvisi per le modifiche alle regole firewall, agli account privilegiati e alla configurazione dei backup. Il monitoraggio dovrebbe aiutare a individuare sia gli attacchi sia i problemi di segmentazione.
Livello di gestione
Il livello di gestione è una delle aree più sensibili dell'ambiente. Può contenere jump host, strumenti di amministrazione remota, console degli hypervisor, gestione della configurazione, servizi di directory, gestione dei dispositivi di rete e piattaforme di sicurezza.
Le interfacce di gestione non dovrebbero essere esposte direttamente a Internet. Gli amministratori dovrebbero connettersi tramite un servizio di accesso remoto controllato e, quando appropriato, attraverso un jump host protetto. Il jump host dovrebbe avere un insieme limitato di destinazioni consentite e non dovrebbe essere usato per la normale navigazione web o la posta elettronica.
Usa regole firewall deny-by-default
Deny-by-default significa che il traffico viene bloccato salvo quando una regola specifica lo autorizza. È più sicuro che consentire un accesso interno ampio e cercare in seguito di rimuovere le eccezioni pericolose. Inoltre rende visibile l'architettura prevista all'interno dell'insieme di regole.
Una regola firewall utile dovrebbe rispondere a cinque domande:
- Quali indirizzi di origine, identità o zone sono coinvolti?
- Quale sistema o servizio di destinazione è necessario?
- Quale protocollo e quale porta sono consentiti?
- La connessione è in entrata, in uscita o bidirezionale?
- Chi è responsabile della regola, perché esiste e quando dovrebbe essere revisionata?
Preferisci indirizzi specifici dei server o gruppi di indirizzi strettamente delimitati, anziché intere subnet. Preferisci oggetti di servizio denominati a intervalli di porte ampi. Evita regole come “qualsiasi origine verso qualsiasi destinazione”, salvo quando esista un motivo temporaneo chiaramente documentato e una data di scadenza.
L'ordine delle regole è importante. Una regola permissiva ampia collocata sopra una regola restrittiva può vanificare silenziosamente la progettazione prevista. Usa regole di negazione esplicite quando migliorano la visibilità e registra selettivamente il traffico negato. Registrare ogni pacchetto può sovraccaricare un team ridotto, ma registrare i ripetuti tentativi negati tra zone sensibili può rivelare scansioni, malware o una dipendenza applicativa non funzionante.
Le regole firewall dovrebbero essere gestite come infrastruttura, non modificate informalmente sotto pressione. Conserva un registro delle modifiche, usa la revisione tra pari per le policy sensibili e rimuovi gli accessi temporanei al termine del lavoro. Quando la piattaforma lo supporta, integra le modifiche alle regole con la gestione della configurazione e conserva le versioni precedenti per poter effettuare un rollback.
Controlla il traffico est-ovest, non solo quello Internet
Il traffico nord-sud scorre tra l'ambiente interno e Internet. Il traffico est-ovest scorre tra i sistemi interni. La sicurezza perimetrale tradizionale si concentra spesso sul traffico nord-sud e presume che la rete interna sia affidabile. Questa ipotesi non regge quando un attaccante compromette un server, ruba le credenziali di un amministratore o collega un dispositivo infetto alla rete dell'ufficio.
I controlli est-ovest dovrebbero coprire il traffico tra:
- Server web e server applicativi
- Server applicativi e database
- Server di produzione e interfacce di gestione
- Server e workstation degli utenti
- Macchine virtuali sullo stesso host o cluster
- Sistemi di produzione e repository di backup
- Collector di monitoraggio e dispositivi monitorati
I firewall basati sull'host aggiungono un ulteriore livello. Sono particolarmente utili quando i carichi di lavoro condividono uno switch virtuale o quando il traffico non passa attraverso un firewall fisico centrale. Un firewall dell'host può limitare i servizi locali e bloccare connessioni che non dovrebbero mai essere necessarie, anche se una policy di rete è accidentalmente troppo ampia.
La microsegmentazione può spingersi oltre applicando policy a singoli carichi di lavoro o identità, anziché solo alle VLAN. Le piccole organizzazioni non hanno sempre bisogno di una piattaforma specializzata per la microsegmentazione. Firewall degli host gestiti con attenzione, gruppi di sicurezza, identità dei servizi e policy locali possono fornire una separazione significativa se vengono documentati e mantenuti.
Separa l'amministrazione dal traffico di produzione
L'accesso amministrativo merita un percorso dedicato perché le credenziali degli amministratori possono sbloccare molti sistemi contemporaneamente. Combinare il traffico degli utenti, quello delle applicazioni e quello di gestione sulla stessa rete rende più difficile distinguere l'amministrazione legittima dall'attività di un attaccante.
Un modello più sicuro prevede che gli amministratori si connettano a un gateway di accesso remoto o a una VPN, effettuino l'autenticazione con account individuali e, quando possibile, usino l'autenticazione a più fattori. Da lì raggiungono un jump host protetto o la zona di gestione. Il jump host si connette quindi alle interfacce dei server approvate. È opportuno evitare l'accesso diretto da un laptop non gestito a ogni server.
I controlli amministrativi dovrebbero includere:
- Account amministrativi personali e distinti, anziché credenziali privilegiate condivise
- Autenticazione a più fattori per l'accesso remoto e i sistemi privilegiati
- Permessi con il minimo privilegio basati sul ruolo lavorativo
- Accesso di breve durata o just-in-time per le attività sensibili, quando supportato
- Restrizioni sulle reti di origine che possono raggiungere SSH, desktop remoto e API di gestione
- Registrazione centralizzata delle autenticazioni e delle attività privilegiate
- Conservazione sicura e rotazione delle credenziali dei servizi
Non trascurare l'amministrazione fuori banda. La gestione degli hypervisor, i controller delle console remote, i sistemi di storage e i dispositivi di rete dovrebbero trovarsi nella zona di gestione, non nello stesso segmento dei carichi di lavoro ordinari. Se un server di produzione viene compromesso, l'attaccante non dovrebbe ottenere automaticamente un percorso verso la piattaforma che controlla tutte le macchine virtuali.
Mantieni indipendente la rete di backup
I backup vengono spesso presi di mira dopo che un attaccante ha raggiunto la produzione. Se la console di backup, il repository e i server di produzione condividono le stesse credenziali e un accesso di rete illimitato, il ransomware potrebbe riuscire a eliminare i punti di ripristino prima di crittografare i sistemi attivi.
Separa il traffico e la gestione dei backup dal normale traffico di produzione, quando l'architettura lo consente. Una rete di backup può includere VLAN dedicate, regole firewall, route limitate, account di servizio separati e accesso al repository non disponibile dalle zone utenti o web.
La segmentazione deve rispondere a due domande diverse. Primo: il sistema di backup può raccogliere o ricevere i dati necessari? Secondo: un server di produzione compromesso può modificare, eliminare o amministrare i punti di ripristino archiviati? La prima connessione può essere necessaria; la seconda dovrebbe essere strettamente limitata.
I controlli di rete sono solo una parte della resilienza dei backup. I backup dovrebbero essere crittografati prima di lasciare l'ambiente controllato dal cliente, con la chiave di crittografia detenuta dal cliente e non dal provider di backup. Dovrebbero essere conservati lontano dalla produzione e protetti da eliminazioni o modifiche per tutta la durata della finestra di conservazione.
Se un server compromesso raggiunge i sistemi di produzione e tenta di distruggere le opzioni di ripristino, un servizio isolato, crittografato e immutabile come il backup off-site Safenix per server aziendali fornisce un ulteriore confine di recupero. Safenix protegge i server controllati dal cliente; non è un piano di backup per siti web in hosting condiviso.
Valuta con attenzione VPS e infrastrutture web in hosting
La segmentazione è più complessa quando l'infrastruttura è ospitata da un provider, perché il cliente potrebbe non controllare gli switch fisici o la rete a monte. La progettazione dovrebbe distinguere tra i controlli configurabili dal cliente all'interno dell'ambiente VPS o cloud e quelli che devono essere forniti dalla piattaforma di hosting.
Al livello del cliente, usa reti virtuali separate, gruppi di sicurezza, firewall degli host e interfacce private quando disponibili. Mantieni le interfacce pubbliche limitate ai servizi necessari. Colloca database ed endpoint di gestione su reti private e non esporli con indirizzi IP pubblici solo per comodità.
Chiedi al provider come funziona l'isolamento di rete, se il traffico privato viene filtrato, come vengono applicate le policy firewall e se l'accesso di gestione è separato dai carichi di lavoro del cliente. Esamina anche la gestione di snapshot, immagini e backup da parte del provider. Uno snapshot accessibile attraverso lo stesso piano di controllo compromesso potrebbe non essere una copia di ripristino indipendente.
Per le organizzazioni che utilizzano VPS e infrastrutture web in hosting con zone di sicurezza separate, le domande pratiche sono le stesse che si porrebbero in una sala server: quale sistema può avviare una connessione, quale servizio è esposto, chi può amministrarlo e come verrebbe revocato l'accesso durante un incidente? Un'infrastruttura ospitata non elimina la necessità della segmentazione. Cambia quali controlli sono disponibili e chi li gestisce.
L'hosting condiviso richiede particolare attenzione nel descrivere le responsabilità. Un cliente può configurare le impostazioni dell'applicazione o un firewall a livello di account, ma ciò non gli conferisce il controllo sulla rete dei server del provider o sugli account vicini. Safenix protegge i server aziendali controllati dal cliente e non dovrebbe essere presentato come servizio di backup per un sito in hosting condiviso.
Errori comuni nella segmentazione
Creare VLAN senza applicare policy
VLAN separate con routing inter-VLAN senza restrizioni creano l'apparenza della segmentazione senza la protezione prevista. Esamina il percorso effettivo di inoltro e la policy firewall. Verifica che il traffico non possa bypassare il punto di ispezione attraverso un'interfaccia alternativa, un bridge o uno switch non gestito.
Consentire l'intera subnet per comodità
Quando un'applicazione deve raggiungere un database, consentire l'intera subnet web è più rapido che identificare l'origine esatta. Consente però anche a ogni host compromesso o configurato erroneamente in quella subnet di raggiungere il database. Usa invece gruppi di indirizzi e regole specifiche per servizio.
Lasciare attive le eccezioni temporanee
L'accesso di emergenza spesso diventa permanente. Ogni regola temporanea dovrebbe avere un responsabile, un motivo, una data di creazione e una data di scadenza. Esamina le regole scadute durante le normali operazioni, non solo dopo un incidente.
Usare credenziali condivise
Le credenziali condivise di amministratori e servizi rendono difficile attribuire le attività e facilitano il passaggio dell'attaccante tra i sistemi. Usa account individuali per le persone, identità di servizio separate per le applicazioni e credenziali univoche per i sistemi di backup e gestione.
Collocare le interfacce di gestione sulle reti di produzione
Le porte di gestione dei server, le console degli hypervisor e l'amministrazione dello storage non dovrebbero essere raggiungibili dai normali dispositivi degli utenti o dai carichi di lavoro esposti al pubblico. Una rete di gestione è utile solo se l'accesso a essa è a sua volta limitato.
Dimenticare i dispositivi non server
Stampanti, telecamere, sistemi degli edifici e apparecchiature di rete economiche sono spesso mantenuti meno accuratamente dei server. Non dovrebbero condividere un accesso senza restrizioni con l'infrastruttura sensibile. Collocali in una zona dispositivi appropriata e consenti solo i servizi necessari.
Non documentare le eccezioni
Le regole non documentate diventano ipotesi permanenti. Quando un tecnico lascia l'azienda o un'applicazione cambia, nessuno sa perché esista una connessione o se possa essere rimossa. La documentazione è parte del controllo, non un semplice ornamento amministrativo.
Come verificare se la segmentazione funziona
Una progettazione non è dimostrata da un diagramma di rete. Verifica i punti di applicazione dei controlli dalle stesse posizioni che potrebbe usare un attaccante. Mantieni un piano di test approvato, così che scansioni e tentativi di connessione non interrompano la produzione.
Verifica i percorsi consentiti
Da ogni zona di origine, verifica che i servizi necessari siano raggiungibili. Testa il protocollo e la porta esatti, non solo la risposta della destinazione al ping. Conferma che transazioni applicative, monitoraggio, amministrazione e processi di backup funzionino attraverso i percorsi previsti.
Verifica i percorsi vietati
Tenta connessioni dai server web alle interfacce di gestione, dalle reti degli utenti ai database, dai server applicativi a sistemi di produzione non correlati e dai server ordinari alle porte di amministrazione dei backup. Questi test dovrebbero fallire. Una connessione riuscita richiede un'indagine anche se il servizio non espone dati.
Testa dalla prospettiva di un host compromesso
Usa un account di test controllato o una valutazione di sicurezza approvata per simulare un attaccante che ha ottenuto accesso a un server. Verifica se da quella posizione è possibile effettuare discovery di rete, raggiungere servizi di credenziali, amministrazione remota, condivisione di file o altre zone. Cerca percorsi trascurati perché la documentazione originale descriveva il traffico previsto anziché quello effettivo.
Esamina log e avvisi
Conferma che le connessioni negate siano visibili con un livello di dettaglio utile. Gli avvisi dovrebbero identificare scansioni insolite, ripetuti tentativi di accesso alle zone sensibili e modifiche alle policy di sicurezza. Assicurati che i log siano conservati in una posizione che un server compromesso non possa cancellare.
Testa guasti e ripristino
Firewall, switch e gateway VPN possono guastarsi o essere configurati erroneamente. Verifica come si comporta l'ambiente durante il guasto di un dispositivo, la distribuzione di una policy o la perdita del percorso di gestione principale. Conferma che l'accesso di emergenza sia controllato e documentato, invece di affidarti a un bypass non documentato.
Ripeti i test dopo modifiche importanti: nuove applicazioni, migrazioni di server, riprogettazioni delle VLAN, cambi di provider e aggiornamenti dei firewall possono modificare la raggiungibilità. La validazione automatizzata delle policy e la scansione delle vulnerabilità pianificata possono aiutare, ma dovrebbero supportare la revisione umana delle dipendenze aziendali, non sostituirla.
Segmentazione e risposta agli incidenti
Durante un incidente, la segmentazione dovrebbe aiutare il team a isolare rapidamente un server senza portare offline l'intera azienda. Mantieni azioni di contenimento predefinite per le situazioni comuni. Possono includere la disattivazione della porta dello switch dell'host, la rimozione di un server dalla VLAN di produzione, il blocco di un account di servizio, la limitazione dell'accesso in uscita di una zona o lo spostamento dell'amministrazione su un percorso di emergenza.
Mantieni un inventario accurato degli asset e delle dipendenze. Se chi risponde all'incidente non sa quali servizi dipendono da un server, potrebbe isolarlo troppo lentamente o causare interruzioni non necessarie. Registra per i sistemi importanti il responsabile aziendale, il responsabile tecnico, la zona, le dipendenze critiche, la policy di backup e la priorità di ripristino.
I playbook di risposta agli incidenti dovrebbero indicare chi può approvare modifiche firewall di emergenza, come registrare le modifiche e come ripristinare la policy normale in seguito. Testa i playbook. Un controllo che esiste solo in un documento ma non può essere utilizzato sotto pressione offre una protezione limitata.
Perché la segmentazione non può sostituire i backup isolati
La segmentazione limita la raggiungibilità, ma non rende sicuro un sistema compromesso. Un attaccante può sfruttare una connessione applicativa consentita, compromettere la workstation di un amministratore, rubare credenziali, abusare di un'eccezione firewall o attaccare il sistema di backup attraverso percorsi di gestione legittimi. Il malware può inoltre danneggiare i dati prima dell'esecuzione del processo di backup.
La possibilità di ripristino richiede più di una copia conservata da qualche parte. La copia deve essere disponibile dopo la compromissione della produzione, protetta da eliminazioni non autorizzate, crittografata in modo appropriato, conservata per il periodo necessario e ripristinabile entro gli obiettivi di recupero dell'azienda.
Safenix fornisce backup off-site per server aziendali controllati dal cliente. I dati vengono crittografati con una chiave che Safenix non detiene, archiviati in Germania e mantenuti immutabili per tutta la durata della finestra di conservazione. Questo modello integra la segmentazione: i controlli di rete riducono la probabilità che un incidente si propaghi, mentre una copia di ripristino indipendente aiuta l'azienda a tornare a uno stato noto e integro se i sistemi o i backup locali vengono danneggiati.
Progetta la connessione di backup come parte dell'architettura. Limita quali host possono inviare dati di backup, mantieni l'amministrazione dei backup separata dagli account di produzione ordinari e testa i ripristini, anziché verificare soltanto che i processi risultino completati. Un processo di backup riuscito dimostra che i dati sono stati copiati; un ripristino riuscito dimostra che i dati possono effettivamente supportare il recupero.
Un piano di implementazione gestibile
I team di piccole dimensioni possono migliorare la segmentazione per fasi. Inizia dai sistemi che presentano il rischio e il valore maggiori, anziché tentare subito una riprogettazione perfetta.
- Mappa l'ambiente. Identifica server, macchine virtuali, utenti, dispositivi di rete, interfacce di gestione, database, sistemi di backup e dipendenze esterne.
- Classifica l'esposizione. Contrassegna i sistemi esposti a Internet, interni, sensibili, amministrativi e di ripristino. Identifica i punti in cui una singola compromissione avrebbe l'impatto maggiore.
- Definisci le zone. Inizia con gruppi pratici come perimetrale, web, applicativa, database, gestione, utenti e backup. Suddividi ulteriormente le zone solo quando la differenza di policy giustifica il costo operativo.
- Costruisci la matrice di comunicazione. Registra origine, destinazione, protocollo, porta, direzione, responsabile e scopo richiesti.
- Applica prima i confini di maggior valore. Separa i server esposti al pubblico dai database, gli utenti dai sistemi di gestione e la produzione dall'amministrazione dei backup.
- Applica regole deny-by-default. Aggiungi eccezioni specifiche per le dipendenze verificate e registra i tentativi negati importanti.
- Rafforza le identità. Elimina le credenziali condivise, abilita l'autenticazione a più fattori per l'amministrazione remota e limita l'accesso privilegiato al percorso di gestione.
- Testa e documenta. Verifica i percorsi consentiti e bloccati, registra i risultati e aggiorna l'inventario degli asset e delle regole.
- Rivedi continuamente. Riesamina le policy dopo modifiche alle applicazioni, cambi di personale, migrazioni del provider e incidenti di sicurezza.
L'obiettivo non è creare un ambiente in cui nulla possa comunicare. È assicurarsi che ogni connessione importante sia intenzionale, limitata e difendibile. Quando un server viene compromesso, sono queste decisioni a determinare se l'incidente rimarrà contenuto o diventerà un'interruzione dell'intera infrastruttura.