Multicloud security: criteri di segmentazione logica

L’adozione di ambienti multicloud (infrastrutture distribuite su due o più provider cloud pubblici, spesso combinati con risorse on-premise) è oggi la norma per le organizzazioni di medie e grandi dimensioni. Le ragioni sono concrete: resilienza operativa, ottimizzazione dei costi, best-of-breed per servizi specifici, requisiti di data residency.

Ma questa distribuzione introduce una complessità di sicurezza che il modello a perimetro tradizionale non è in grado di gestire: non esiste più un «dentro» e un «fuori» della rete aziendale, i workload si spostano dinamicamente tra ambienti diversi, e ogni provider applica i propri modelli di sicurezza con controlli, API e logiche differenti.

In questo scenario, la segmentazione logica è il controllo architetturale che fa la differenza tra un incidente contenuto e un incidente catastrofico. Quando un attaccante ottiene un accesso iniziale, magari attraverso una credenziale compromessa, una vulnerabilità software o un fornitore compromesso, la segmentazione determina fin dove può spingersi prima di essere bloccato.

Un ambiente multicloud non segmentato è un ambiente in cui la compromissione di un workload di bassa criticità può diventare il trampolino per raggiungere i sistemi più critici dell’organizzazione.

La segmentazione logica è la risposta tecnica a questa minaccia strutturale.

Cos’è la segmentazione logica e perché è cruciale nel multicloud

La segmentazione logica è la pratica di dividere un’infrastruttura IT in zone distinte, governate da policy di accesso che controllano quali flussi di traffico sono consentiti tra zone diverse.

L’aggettivo «logica» distingue questo approccio dalla segmentazione fisica tradizionale basata su separazione hardware e VLAN per sottolineare che i confini vengono applicati attraverso software, policy e controlli di identità piuttosto che attraverso la separazione fisica dei componenti.

In un ambiente multicloud, dove i workload sono per definizione distribuiti su infrastrutture fisiche di provider diversi, la segmentazione logica è l’unico approccio praticabile.

La criticità della segmentazione negli ambienti multicloud deriva da una proprietà fondamentale degli attacchi informatici moderni: il movimento laterale.

Un attaccante che ottiene accesso iniziale a un sistema raramente trova immediatamente ciò che cerca, tra cui dati sensibili, sistemi critici e credenziali privilegiate. La fase successiva all’accesso iniziale è la ricognizione e il movimento laterale: esplorare l’ambiente per identificare gli asset di maggior valore e spostarsi verso di essi.

La segmentazione logica è il controllo che interrompe questo movimento: ogni zona ha policy proprie, ogni attraversamento di zona richiede autenticazione e autorizzazione esplicita, ogni tentativo di comunicazione non autorizzata viene bloccato e loggato.

Differenze tra isolamento di rete tradizionale e approccio basato su software

Il modello tradizionale di segmentazione della rete, basato su VLAN, firewall perimetrali e ACL statiche, è stato progettato per infrastrutture fisicamente localizzate e relativamente statiche.

In questo modello, il «confine» è determinato dalla topologia fisica: i dispositivi nella stessa VLAN comunicano liberamente tra loro, mentre il traffico verso altre VLAN passa attraverso un firewall che applica regole predefinite.

Questo approccio funziona bene quando l’infrastruttura è stabile, i workload sono localizzati e i confini di fiducia coincidono con i confini fisici della rete.

In un ambiente multicloud, nessuna di queste condizioni è soddisfatta. I workload sono distribuiti su infrastrutture di AWS, Azure, Google Cloud e ambienti on-premise; migrano dinamicamente in funzione del carico; comunicano attraverso API e messaggistica asincrona su canali che attraversano internet pubblico.

Le VLAN non hanno significato al di là dei confini di un singolo provider; le ACL statiche non possono seguire workload dinamici; il perimetro di rete non esiste più come concetto operativo.

L’approccio software-defined alla segmentazione risolve questi limiti: le policy di sicurezza sono associate all’identità del workload, non alla sua posizione fisica nella rete, e vengono applicate ovunque il workload risieda, indipendentemente dal provider o dall’ambiente.

I rischi di una mancata separazione dei carichi di lavoro sensibili

L’assenza di segmentazione logica in un ambiente multicloud non è semplicemente una lacuna tecnica: è una moltiplicazione del rischio.

Ogni workload non segmentato che comunica liberamente con altri workload è un potenziale pivot point per un attaccante: una volta compromesso, diventa il trampolino per raggiungere i sistemi adiacenti.

Questo rischio è amplificato quando i workload appartengono a ambienti con diversi livelli di fiducia: produzione e sviluppo, sistemi interni e sistemi esposti su internet, dati regolamentati e dati pubblici.

La contaminazione tra ambienti è uno degli scenari più frequenti nelle analisi post-incidente: un sistema di sviluppo con credenziali di produzione hard-coded, un ambiente di test con accesso diretto ai database di produzione, un workload di connettività con visibilità sull’intera rete interna.

La mancata segmentazione amplifica inoltre il rischio cyber delle terze parti: un fornitore compromesso che ha accesso a un segmento non isolato può muoversi lateralmente verso workload critici che non avrebbe mai dovuto raggiungere, trasformando un incidente supply chain circoscritto in una compromissione sistemica.

Criteri fondamentali per progettare l’architettura di sicurezza

La progettazione di un’architettura di segmentazione logica efficace in ambienti multicloud richiede di partire da principi chiari prima di selezionare gli strumenti.

Il principio cardine è il least privilege applicato alla rete: ogni workload deve poter comunicare solo con i sistemi con cui ha una necessità operativa documentata, su porte e protocolli specifici, in direzioni predeterminate.

Qualsiasi comunicazione non esplicitamente autorizzata deve essere negata per default. Questo principio, deny by default, allow by exception, è esattamente l’opposto del modello tradizionale in cui tutto il traffico interno è consentito per default e solo il traffico verso l’esterno viene filtrato.

Il secondo principio è la coerenza delle policy tra ambienti diversi. In un ambiente multicloud, la stessa applicazione può avere componenti su AWS, Azure e on-premise.

Se le policy di segmentazione sono definite con strumenti e logiche diverse per ogni ambiente, il risultato è inevitabilmente disomogeneo: zone di sicurezza che esistono su un provider ma non sull’altro, regole coerenti all’interno di ogni ambiente ma incoerenti tra ambienti diversi.

La coerenza richiede uno strato di astrazione – tipicamente una piattaforma di policy management centralizzata – che consenta di definire le regole una volta e applicarle su tutti gli ambienti.

Definizione dei perimetri di sicurezza in base a identità e ruoli

Il modello Zero Trust («non fidarsi mai, verificare sempre») è il framework concettuale di riferimento per la segmentazione logica negli ambienti multicloud moderni.

Il suo assunto fondamentale è che la posizione nella rete non è più un indicatore affidabile di fiducia: un workload all’interno della rete aziendale non è intrinsecamente più affidabile di uno all’esterno, specialmente in un mondo in cui le credenziali vengono compromesse regolarmente e i fornitori esterni hanno accesso ai sistemi interni.

La fiducia deve essere basata sull’identità verificata, non sulla posizione, e deve essere continua, non limitata al momento dell’autenticazione iniziale.

In pratica, questo si traduce nell’assegnazione di un’identità crittografica a ogni workload, non solo agli utenti umani, e nell’uso di questa identità come base per le decisioni di autorizzazione.

Questo approccio è intrinsecamente multicloud: l’identità del workload rimane la stessa indipendentemente da dove il workload è deployato.

Classificazione dei dati e separazione degli ambienti di produzione e test

La classificazione dei dati è il prerequisito per una segmentazione logica sensata: non si possono definire perimetri di sicurezza appropriati senza sapere quali dati risiedono in quale workload e quale livello di protezione richiedono.

La classificazione deve essere formale, documentata e integrata nei processi di provisioning dei workload: ogni nuovo workload deve essere classificato prima di essere deployato, e la sua posizione nell’architettura di segmentazione deve riflettere il livello di sensibilità dei dati che gestisce.

La separazione degli ambienti di produzione, staging e sviluppo è uno dei requisiti di segmentazione più frequentemente violati nella pratica.

La pressione operativa porta spesso a compromessi: sviluppatori che hanno accesso diretto ai database di produzione per debug, ambienti di staging che condividono credenziali con la produzione, pipeline CI/CD con permessi eccessivamente ampi sugli ambienti produttivi.

Ciascuna di queste situazioni è un rischio documentato: gli ambienti di sviluppo hanno tipicamente controlli di sicurezza meno stringenti e un numero maggiore di persone con accesso, rendendoli bersagli più facili come punto di ingresso verso la produzione.

Come implementare la microsegmentazione tra provider cloud differenti

La microsegmentazione è l’implementazione granulare della segmentazione logica: invece di dividere la rete in macro-zone (produzione, sviluppo, DMZ), la microsegmentazione applica policy di accesso a livello di singolo workload o addirittura di singolo processo.

L’obiettivo è ridurre la «blast radius» (il raggio d’azione) di una compromissione al minimo possibile: se un container è compromesso, le policy di microsegmentazione impediscono che la compromissione si propaghi al container adiacente, anche se entrambi sono parte della stessa applicazione.

In ambiente multicloud, la microsegmentazione deve affrontare la sfida dell’eterogeneità: ogni provider ha i propri costrutti di rete (VPC su AWS, VNet su Azure, VPC su GCP), i propri strumenti di firewall (Security Groups su AWS, NSG su Azure, Firewall Rules su GCP) e le proprie logiche di policy.

Implementare la microsegmentazione in modo coerente su tre provider diversi usando gli strumenti nativi di ciascuno porta inevitabilmente a policy frammentate e difficili da mantenere.

La soluzione è l’adozione di un livello di orchestrazione sovra-provider (tipicamente una piattaforma di microsegmentazione come Illumio, Guardicore (ora Akamai) o Cisco Secure Workload) che astrae le differenze tra provider e consente di definire policy uniformi applicate ovunque.

Configurazione di policy di sicurezza coerenti tramite infrastruttura come codice

L’Infrastructure as Code (IaC) è il paradigma che consente di gestire le policy di sicurezza della rete con la stessa disciplina con cui si gestisce il codice applicativo: versioning, revisione, testing automatizzato, deployment controllato.

L’integrazione delle policy di sicurezza nella pipeline CI/CD è il passo che trasforma l’IaC da strumento di deployment a controllo di sicurezza attivo: ogni modifica alle regole di segmentazione passa attraverso una revisione del codice, un set di test automatizzati (che verificano che le nuove regole non violino i principi di least privilege o non aprano comunicazioni non autorizzate) e un processo di approvazione prima di essere applicata in produzione.

Gestione del traffico Est-Ovest e blocco dei movimenti laterali delle minacce

Il traffico Est-Ovest, ossia le comunicazioni tra workload all’interno della stessa infrastruttura, in contrasto con il traffico Nord-Sud che entra ed esce dal perimetro, è il vettore principale del movimento laterale.

La maggior parte degli strumenti di sicurezza tradizionali è progettata per il traffico Nord-Sud: firewall perimetrali, IDS/IPS di confine, Web Application Firewall.

Il traffico Est-Ovest, che in ambienti cloud può rappresentare oltre il 70% del traffico totale, è spesso completamente invisibile agli strumenti di sicurezza se non si adottano misure specifiche.

Il controllo del traffico Est-Ovest richiede due capacità complementari: la visibilità (sapere cosa comunica con cosa, su quali porte, con quale frequenza) e l’enforcement (bloccare le comunicazioni non autorizzate).

La visibilità si ottiene attraverso l’analisi dei flow log dei provider cloud (VPC Flow Logs su AWS, NSG Flow Logs su Azure, VPC Flow Logs su GCP), integrata con strumenti di network analytics che costruiscono una mappa delle comunicazioni effettive tra workload.

L’enforcement si implementa attraverso le regole di microsegmentazione, che devono essere derivate dalla mappa delle comunicazioni reali, non da assunzioni teoriche, per evitare di bloccare traffico legittimo.

Un approccio efficace per l’implementazione progressiva della microsegmentazione in ambienti esistenti prevede tre fasi: prima la visibilità (deployare gli strumenti di monitoring del traffico Est-Ovest senza ancora applicare restrizioni), poi la definizione delle baseline (costruire la mappa delle comunicazioni legittime su un periodo di osservazione di 2-4 settimane) e infine l’enforcement progressivo (applicare le regole partendo dai workload più critici, verificando che non vengano bloccate comunicazioni legittime prima di estendere la copertura).

Strumenti e tecnologie per il controllo unificato degli accessi

Il controllo degli accessi in ambienti multicloud è una delle sfide operative più complesse della sicurezza cloud moderna.

Ogni provider ha il proprio sistema IAM (AWS IAM, Azure Active Directory/Entra ID, Google Cloud IAM) con modelli di permessi, concetti e interfacce diverse. Senza un livello di unificazione, il risultato è una frammentazione che porta a inconsistenze: un utente con accesso correttamente limitato su AWS ma con permessi eccessivi su Azure, un account di servizio disabilitato su Google Cloud ma ancora attivo su AWS, una policy di least privilege rigorosa su on-premise ma non estesa agli ambienti cloud.

La soluzione è l’adozione di un Identity Provider (IdP) centralizzato, tipicamente Microsoft Entra ID, Okta o Ping Identity, federato con tutti i provider cloud attraverso protocolli standard (SAML, OIDC).

Questo approccio garantisce un’unica fonte di verità per le identità, la propagazione coerente delle politiche di accesso su tutti gli ambienti, e la revoca centralizzata degli accessi quando necessario.

La federazione non elimina la necessità di gestire i permessi specifici di ogni provider, ma garantisce che la gestione del ciclo di vita delle identità (provisioning, modifica, deprovisioning) avvenga in un unico punto.

Integrazione di soluzioni di Cloud Security Posture Management e SASE

Il Cloud Security Posture Management (CSPM) è la categoria di strumenti che fornisce visibilità continua sulla configurazione degli ambienti cloud, rilevando automaticamente le deviazioni dalle best practice di sicurezza e dai requisiti di compliance.

In un ambiente multicloud, il CSPM è lo strumento che risponde alla domanda fondamentale: l’architettura di segmentazione che ho definito è effettivamente implementata in modo corretto su tutti i provider?

Piattaforme come Microsoft Defender for Cloud, Prisma Cloud (Palo Alto), Wiz e Lacework offrono copertura multicloud nativa, con dashboard unificate che mostrano lo stato di conformità su AWS, Azure e GCP in un’unica vista.

Il Secure Access Service Edge (SASE) è il framework architetturale che unifica il networking e la sicurezza in un servizio cloud-native, combinando SD-WAN, Zero Trust Network Access (ZTNA), Cloud Access Security Broker (CASB) e Secure Web Gateway (SWG) in una piattaforma integrata.

Per gli ambienti multicloud con utenti distribuiti e workload su provider diversi, SASE offre un modello di accesso coerente basato sull’identità dell’utente e del dispositivo, non sulla posizione nella rete, che applica le stesse policy di sicurezza indipendentemente da dove si trova l’utente e da quale provider ospita il workload a cui accede.

Monitoraggio continuo e verifica della conformità dei criteri di isolamento

La segmentazione logica non è una configurazione da impostare una volta e dimenticare: è una proprietà dell’infrastruttura che deve essere verificata continuamente perché si degrada nel tempo.

Il configuration drift (la progressiva divergenza tra la configurazione desiderata e quella effettivamente implementata) è una realtà in qualsiasi ambiente cloud dinamico: nuovi workload vengono deployati senza seguire le policy di segmentazione, regole temporanee create per risolvere un problema operativo rimangono permanenti, aggiornamenti del provider modificano il comportamento dei controlli di sicurezza.

Senza un monitoraggio continuo, queste derive si accumulano silenziosamente fino a quando un incidente le rende visibili nel modo peggiore.

Il monitoraggio continuo della segmentazione richiede la combinazione di tre capacità:

1. il rilevamento del configuration drift (confronto automatico tra la configurazione definita nel codice IaC e quella effettivamente presente nell’infrastruttura);
2. il monitoraggio del traffico di rete (rilevamento di comunicazioni che violano le policy di segmentazione, anche se non bloccate da gap nelle regole);
3. la verifica periodica della conformità normativa (verifica che le policy di segmentazione soddisfino i requisiti di NIS2, DORA, GDPR e dei framework di riferimento applicabili).

Audit automatizzati e gestione delle eccezioni nelle regole di rete

Gli audit automatizzati della configurazione di rete sono il complemento indispensabile del monitoraggio continuo: dove il monitoraggio rileva anomalie in tempo reale, l’audit fornisce una valutazione periodica sistematica e documentata dello stato complessivo della segmentazione.

Le piattaforme CSPM offrono funzionalità di audit automatizzato rispetto a benchmark standard (CIS Benchmarks per AWS, Azure e GCP, NIST CSF, framework NIS2) che producono report strutturati con evidenze verificabili, il tipo di documentazione che ACN può richiedere in un’ispezione di conformità NIS2.

La gestione delle eccezioni è uno degli aspetti più delicati della governance della segmentazione: le eccezioni alle regole standard sono inevitabili in ambienti complessi, ma devono essere gestite in modo formale per evitare che diventino lacune permanenti nelle difese.

Un processo di eccezione maturo prevede: la documentazione della ragione business che giustifica l’eccezione, la valutazione del rischio aggiuntivo introdotto dall’eccezione, l’approvazione esplicita da parte del responsabile della sicurezza, una durata massima dell’eccezione con revisione obbligatoria alla scadenza, e il monitoraggio rafforzato del traffico sulla regola di eccezione per rilevare eventuali abusi.

Le eccezioni non documentate, che in molti ambienti rappresentano una percentuale significativa delle regole di rete, sono una delle vulnerabilità di governance più frequenti e più difficili da rilevare negli audit.

La maturità nella gestione della segmentazione logica in ambienti multicloud si misura dalla capacità di rispondere con evidenze concrete a tre domande: quale workload può comunicare con quale altro workload, su quali porte e in quale direzione? Come si verifica che questa configurazione sia effettivamente implementata su tutti i provider? Come si rileva e si gestisce una deviazione dalla configurazione attesa?

Le organizzazioni che hanno risposte documentate e automatizzate a queste tre domande sono quelle che, in caso di incidente, limitano il danno alla singola zona compromessa anziché assistere alla propagazione dell’attacco all’intera infrastruttura.