Strategie di architettura per la creazione di una strategia di segmentazione

Si applica alla raccomandazione dell'elenco di controllo per la sicurezza di Well-Architected Framework:

Un segmento è una sezione logica della soluzione che deve essere protetta come un'unità. Una strategia di segmentazione definisce il modo in cui un'unità deve essere separata da altre unità con il proprio set di requisiti e misure di sicurezza.

Questa guida descrive le raccomandazioni per la creazione di una strategia di segmentazione unificata. Usando i perimetri e i limiti di isolamento nei carichi di lavoro, è possibile progettare un approccio di sicurezza adatto all'utente.

Terminologia 

Il concetto di segmentazione viene comunemente usato per le reti. Tuttavia, lo stesso principio sottostante può essere usato in una soluzione, inclusa la segmentazione delle risorse per scopi di gestione e controllo di accesso.

La segmentazione consente di progettare un approccio di sicurezza che applica la difesa avanzata in base ai principi del modello Zero Trust. Assicurarsi che un utente malintenzionato che viola un segmento di rete non possa ottenere l'accesso a un altro segmentando i carichi di lavoro con controlli di identità diversi. In un sistema sicuro, gli attributi di identità e di rete bloccano l'accesso non autorizzato e nascondono gli asset da esporre. Ecco alcuni esempi di segmenti:

• Sottoscrizioni che isolano i carichi di lavoro di un'organizzazione
• Gruppi di risorse che isolano gli asset del carico di lavoro
• Ambienti di distribuzione che isolano la distribuzione in base alle fasi
• Team e ruoli che isolano le funzioni lavorative correlate allo sviluppo e alla gestione dei carichi di lavoro.
• Livelli di applicazione che isolano in base all'utilità del workload
• Microservizi che isolano un servizio da un altro

Prendere in considerazione questi elementi chiave della segmentazione per assicurarsi di creare una strategia completa di difesa approfondita:

• Il limite o il perimetro è il bordo di ingresso di un segmento in cui si applicano i controlli di sicurezza. I controlli perimetrali devono bloccare l'accesso al segmento, a meno che non sia consentito in modo esplicito. L'obiettivo è impedire a un utente malintenzionato di attraversare il perimetro e di ottenere il controllo del sistema. Ad esempio, un livello applicazione potrebbe accettare il token di accesso di un utente finale quando elabora una richiesta. Tuttavia, il livello dati potrebbe richiedere un token di accesso diverso con un'autorizzazione specifica, che può richiedere solo il livello applicazione.

• Il contenimento è il bordo di uscita di un segmento che impedisce lo spostamento laterale nel sistema. L'obiettivo del contenimento è ridurre al minimo l'effetto di una violazione. Ad esempio, una rete virtuale di Azure può essere usata per configurare il routing e i gruppi di sicurezza di rete per consentire solo modelli di traffico previsti, evitando il traffico verso segmenti di rete arbitrari.

• L'isolamento è la pratica di raggruppamento di entità con garanzie simili per proteggerle con un limite. L'obiettivo è la facilità di gestione e il contenimento di un attacco all'interno di un ambiente. Ad esempio, è possibile raggruppare le risorse correlate a un carico di lavoro specifico in una sottoscrizione di Azure e quindi applicare il controllo di accesso in modo che solo i team del carico di lavoro specifici possano accedere alla sottoscrizione.

È importante notare la distinzione tra perimetri e isolamento. Il perimetro fa riferimento ai punti di posizione che devono essere controllati. L'isolamento riguarda il raggruppamento. Contenere attivamente un attacco usando questi concetti insieme.

L'isolamento non significa creare silo nell'organizzazione. Una strategia di segmentazione unificata fornisce l'allineamento tra i team tecnici e imposta linee chiare di responsabilità. La chiarezza riduce il rischio di errori umani e errori di automazione che possono causare vulnerabilità di sicurezza, tempi di inattività operativi o entrambi. Si supponga che venga rilevata una violazione della sicurezza in un componente di un sistema aziendale complesso. È importante che tutti comprendano chi è responsabile di tale risorsa in modo che la persona appropriata sia inclusa nel team di valutazione. L'organizzazione e gli stakeholder possono identificare rapidamente come rispondere a diversi tipi di eventi imprevisti creando e documentando una buona strategia di segmentazione.

Compromesso: la segmentazione introduce complessità perché si verifica un sovraccarico nella gestione. C'è anche un compromesso nel costo. Ad esempio, vengono fornite più risorse quando gli ambienti di distribuzione che vengono eseguiti fianco a fianco sono segmentati.

Rischio: la micro-segmentazione oltre un limite ragionevole perde il vantaggio dell'isolamento. Quando si creano troppi segmenti, diventa difficile identificare i punti di comunicazione o consentire percorsi di comunicazione validi all'interno del segmento.

Stabilire l'identità come perimetro di sicurezza primario

Diverse identità, ad esempio persone, componenti software o dispositivi, accedono ai segmenti del carico di lavoro. L'identità è un perimetro che deve essere la linea principale di difesa per autenticare e autorizzare l'accesso attraverso i limiti di isolamento, indipendentemente dalla posizione in cui ha origine la richiesta di accesso. Usare l'identità come perimetro per:

• Assegnare l'accesso in base al ruolo. Le identità devono avere accesso solo ai segmenti necessari per svolgere il loro lavoro. Ridurre al minimo l'accesso anonimo comprendendo i ruoli e le responsabilità dell'identità richiedente in modo da conoscere l'entità che richiede l'accesso a un segmento e a quale scopo.

  Un'identità potrebbe avere ambiti di accesso diversi in segmenti diversi. Si consideri una configurazione tipica dell'ambiente, con segmenti separati per ogni fase. Le identità associate al ruolo sviluppatore hanno accesso in lettura/scrittura all'ambiente di sviluppo. Man mano che la distribuzione passa alla gestione temporanea, tali autorizzazioni vengono frenate. Quando il carico di lavoro viene alzato di livello di produzione, l'ambito per gli sviluppatori viene ridotto all'accesso di sola lettura.

• Prendere in considerazione le identità di applicazione e gestione separatamente. Nella maggior parte delle soluzioni, gli utenti hanno un livello di accesso diverso rispetto agli sviluppatori o agli operatori. In alcune applicazioni è possibile usare diversi sistemi di identità o directory per ogni tipo di identità. È consigliabile usare gli ambiti di accesso e creare ruoli separati per ogni identità.

• Assegna l'accesso con privilegi minimi. Se all'identità è consentito l'accesso, determinare il livello di accesso. Iniziare con il privilegio minimo per ogni segmento e ampliare tale ambito solo quando necessario.

  Applicando il privilegio minimo, si limitano gli effetti negativi nel caso in cui l'identità venga compromessa. Se l'accesso è limitato per tempo, la superficie di attacco viene ridotta ulteriormente. L'accesso limitato al tempo è particolarmente applicabile agli account critici, ad esempio amministratori o componenti software con un'identità compromessa.

Compromesso: le prestazioni del carico di lavoro possono essere influenzate dai perimetri di identità. La verifica di ogni richiesta richiede in modo esplicito cicli di calcolo aggiuntivi e operazioni di I/O di rete aggiuntive.

Il controllo degli accessi in base al ruolo comporta anche un sovraccarico di gestione. Tenere traccia delle identità e dei relativi ambiti di accesso può diventare complesso nelle assegnazioni di ruolo. La soluzione alternativa consiste nell'assegnare ruoli ai gruppi di sicurezza anziché alle singole identità.

Rischio: le impostazioni di identità possono essere complesse. Le configurazioni errate possono influire sull'affidabilità del carico di lavoro. Si supponga, ad esempio, che si verifichi un'assegnazione di ruolo non configurata correttamente a cui viene negato l'accesso a un database. Le richieste iniziano a non riuscire, causando alla fine problemi di affidabilità che non possono essere altrimenti rilevati fino al runtime.

Per informazioni sui controlli delle identità, vedere Gestione delle identità e degli accessi.

A differenza dei controlli di accesso alla rete, l'identità convalida il controllo di accesso in fase di accesso. È consigliabile condurre una verifica di accesso regolare e richiedere un flusso di lavoro di approvazione per ottenere privilegi per gli account di impatto critico. Ad esempio, vedere Modelli di segmentazione delle identità.

Migliorare utilizzando il networking come perimetro di sicurezza

I perimetri di identità sono indipendenti dalla rete, mentre i perimetri di rete aumentano l'identità, ma non lo sostituiscono mai. I perimetri di rete vengono stabiliti per controllare il raggio di esplosione, bloccare l'accesso imprevisto, vietato e non sicuro e offuscare le risorse del carico di lavoro.

Mentre l'obiettivo principale del perimetro dell'identità è il privilegio minimo, è consigliabile presupporre che si verifichi una violazione quando si progetta il perimetro di rete.

Creare perimetri software-defined nella tua infrastruttura di rete utilizzando i servizi e le funzionalità di Azure. Quando un carico di lavoro (o parti di un determinato carico di lavoro) viene inserito in segmenti separati, si controlla il traffico da o verso tali segmenti per proteggere i percorsi di comunicazione. Se un segmento viene compromesso, è contenuto e impedito di distribuirlo successivamente attraverso il resto della rete.

Pensa come un attaccante per ottenere un punto d'appoggio all'interno del carico di lavoro e stabilire controlli per limitare un'ulteriore espansione. I controlli devono rilevare, contenere e impedire agli utenti malintenzionati di accedere all'intero carico di lavoro. Ecco alcuni esempi di controlli di rete come perimetro:

• Definire il perimetro perimetrale tra reti pubbliche e la rete in cui si trova il carico di lavoro. Limitare al massimo l'esposizione della propria rete alle reti pubbliche.
• Implementare zone demilitarizzate (DMZ) davanti all'applicazione con controlli appropriati tramite firewall.
• Creare micro-segmentazione all'interno della rete privata raggruppando parti del carico di lavoro in segmenti separati. Stabilire percorsi di comunicazione sicuri tra di essi.
• Creare limiti logici in base alla finalità. Ad esempio, posizionare i servizi che partecipano allo stesso flusso utente in un limite con regole sul traffico in ingresso e in uscita nel suo complesso. In alternativa, segmentare le reti funzionali del carico di lavoro dalle reti operative.

Per i modelli comuni correlati alla segmentazione di rete, vedere Modelli di segmentazione di rete.

Compromesso: i controlli di sicurezza di rete sono spesso costosi perché sono inclusi negli SKU Premium. La configurazione delle regole nei firewall comporta spesso una complessità eccessiva che richiede eccezioni generali.

La connettività privata modifica la progettazione dell'architettura, spesso aggiungendo più componenti, ad esempio jump box per l'accesso privato ai nodi di calcolo.

Poiché i perimetri di rete sono basati su punti di controllo o salti, ogni salto può essere un potenziale punto di guasto. Questi punti possono avere un effetto sull'affidabilità del sistema.

Rischio: i controlli di rete sono basati su regole e c'è una probabilità significativa di errori di configurazione, che è un problema di affidabilità.

Per informazioni sui controlli di rete, vedere Rete e connettività.

Definire ruoli e linee chiare di responsabilità

La segmentazione che impedisce confusione e rischi per la sicurezza viene ottenuta definendo chiaramente le linee di responsabilità all'interno di un team del carico di lavoro.

Documentare e condividere ruoli e funzioni per creare coerenza e facilitare la comunicazione. Designare gruppi o singoli ruoli responsabili delle funzioni chiave. Prendere in considerazione i ruoli predefiniti in Azure prima di creare ruoli personalizzati per gli oggetti.

Quando si assegnano autorizzazioni per un segmento, prendere in considerazione la coerenza tenendo conto di diversi modelli organizzativi. Questi modelli possono variare da un singolo gruppo IT centralizzato a team IT e DevOps per lo più indipendenti.

Rischio: l'appartenenza ai gruppi può cambiare nel tempo quando i dipendenti si uniscono o lasciano i team o modificano i ruoli. La gestione dei ruoli tra segmenti può comportare un sovraccarico di gestione.

Organizzare le risorse per promuovere la segmentazione

La segmentazione consente di isolare le risorse del carico di lavoro da altre parti dell'organizzazione o anche all'interno del team. I costrutti di Azure, ad esempio gruppi di gestione, sottoscrizioni, ambienti e gruppi di risorse, sono modi per organizzare le risorse che promuovono la segmentazione. Ecco alcuni esempi di isolamento a livello di risorsa:

• La persistenza poliglotta prevede una combinazione di tecnologie di archiviazione dei dati anziché di un singolo sistema di database per supportare la segmentazione. Usare la persistenza poliglotta per separare i vari modelli di dati, la separazione delle funzionalità, ad esempio l'archiviazione e l'analisi dei dati, o per separare i modelli di accesso.
• Allocare un servizio per ogni server quando si organizza il calcolo. Questo livello di isolamento riduce al minimo la complessità e può contribuire a contenere un attacco.
• Azure offre l'isolamento predefinito per alcuni servizi, ad esempio la separazione delle risorse di calcolo dall'archiviazione. Per altri esempi, vedere Isolamento nel cloud pubblico di Azure.

Compromesso: l'isolamento delle risorse potrebbe comportare un aumento del costo totale di proprietà (TCO). Per gli archivi dati, è possibile aggiungere complessità e coordinamento durante il ripristino di emergenza.

Facilitazione di Azure

Alcuni servizi di Azure sono disponibili per l'uso nell'implementazione di una strategia di segmentazione, come descritto nelle sezioni seguenti.

Identità

Il controllo degli accessi in base al ruolo (RBAC) di Azure supporta la segmentazione isolando l'accesso in base al ruolo lavorativo. Solo determinate azioni sono consentite per determinati ruoli e ambiti. Ad esempio, le funzioni lavorative che devono solo osservare il sistema possono ricevere autorizzazioni di lettura rispetto alle autorizzazioni di contributore che permettono all'identità di gestire le risorse.

Per ulteriori informazioni, consultare Pratiche consigliate per RBAC.

Rete

Reti virtuali: le reti virtuali forniscono il contenimento a livello di rete delle risorse senza aggiungere traffico tra due reti virtuali. Le reti virtuali vengono create in spazi di indirizzi privati all'interno di un abbonamento

Gruppi di sicurezza di rete (NSG): meccanismo di controllo di accesso per il controllo del traffico tra le risorse nelle reti virtuali e nelle reti esterne, ad esempio Internet. Implementare route definite dall'utente (UDR) per controllare il prossimo hop per il traffico. I gruppi di sicurezza di rete possono portare la strategia di segmentazione a un livello granulare creando perimetri per una subnet, una macchina virtuale (VM) o un gruppo di macchine virtuali. Per informazioni sulle possibili operazioni con subnet in Azure, vedere Subnet.

Gruppi di sicurezza delle applicazioni: i gruppi di sicurezza delle applicazioni consentono di raggruppare un set di macchine virtuali con un tag dell'applicazione e definire regole di traffico che vengono quindi applicate a ognuna delle macchine virtuali sottostanti.

Firewall di Azure: un servizio nativo del cloud, che può essere distribuito nella rete virtuale o nelle distribuzioni dell'hub della rete WAN virtuale di Azure . Usare Firewall di Azure per filtrare il flusso del traffico tra risorse cloud, Internet e risorse locali. Usare Firewall di Azure o Gestione firewall di Azure per creare regole o criteri che consentono o negano il traffico usando i controlli di livello 3 al livello 7. Filtrare il traffico Internet usando Firewall di Azure e terze parti indirizzando il traffico attraverso provider di sicurezza di terze parti per il filtro avanzato e la protezione degli utenti. Azure supporta la distribuzione di appliance virtuali per reti, facilitando la segmentazione all'interno di infrastrutture con firewall di terze parti.

Analisi del traffico: Analisi del traffico è una funzionalità di Azure Network Watcher che consente la visibilità continua nella segmentazione di rete analizzando e arricchire i log dei flussi di rete virtuale. Questa visibilità consente ai team di convalidare i criteri di segmentazione. Garantisce inoltre che il traffico rimanga limitato ai segmenti previsti e consenta di rilevare rapidamente eventuali violazioni o spostamenti laterali imprevisti. Grazie all'arricchimento dei dati del flusso con il contesto dalle configurazioni di rete e dai controlli di sicurezza, è possibile ottenere informazioni più approfondite sul comportamento della rete. L'integrazione dell'analisi del traffico consente di monitorare e applicare attivamente i limiti di segmentazione, perfezionare le strategie di micro-segmentazione e mantenere l'accesso con privilegi minimi. Questa integrazione rafforza la distribuzione Zero Trust.

Example

Ecco alcuni modelli comuni per segmentare un carico di lavoro in Azure. Scegliere un modello in base alle proprie esigenze.

Questo esempio si basa sull'ambiente IT (Information Technology) stabilito nella baseline di sicurezza (SE:01). Il diagramma seguente mostra la segmentazione a livello di gruppo di gestione eseguita da un'organizzazione.

Modelli di segmentazione delle identità

Modello 1: Raggruppamento basato sul titolo del lavoro

Un modo per organizzare i gruppi di sicurezza è per titolo di lavoro, ad esempio software engineer, amministratore del database, tecnico dell'affidabilità del sito, tecnico della garanzia di qualità o analista della sicurezza. Questo approccio prevede la creazione di gruppi di sicurezza per il team del carico di lavoro in base ai propri ruoli, senza considerare il lavoro da eseguire. Assegnare ai gruppi di sicurezza autorizzazioni di controllo degli accessi in base al ruolo, permanenti o just-in-time (JIT), in base alle proprie responsabilità nell'ambito lavorativo. Assegna principi per utenti e servizi ai gruppi di sicurezza in base al loro accesso secondo necessità.

L'appartenenza è chiaramente visibile nella distribuzione dei ruoli, rendendo facile comprendere a cosa ha accesso un ruolo. Solitamente, ciascuna persona appartiene a un solo gruppo di sicurezza, il che facilita l'onboarding e l'offboarding. Tuttavia, a meno che i titoli di lavoro non si sovrappongano perfettamente alle responsabilità, il raggruppamento basato sul titolo non è ideale per l'implementazione dei privilegi minimi. È possibile combinare l'implementazione con il raggruppamento basato su funzioni.

Modello 2: Raggruppamento basato su funzioni

Il raggruppamento basato su funzioni è un metodo di organizzazione del gruppo di sicurezza che riflette il lavoro discreto che deve essere eseguito, non tenendo conto della struttura del team. Con questo modello, si concedono ai gruppi di sicurezza le autorizzazioni RBAC, permanenti o JIT in base alle necessità, secondo la loro funzione richiesta nel carico di lavoro.

Assegnare principi umani e di servizio ai gruppi di sicurezza in base all'accesso necessario. Se possibile, usare gruppi omogenei esistenti come membri dei gruppi basati su funzione, ad esempio quelli del modello 1. Esempi di gruppi basati su funzioni includono:

• Gestori di database di produzione
• Operatori di database di preproduzione
• Operatori di gestione dei certificati di produzione
• Operatori di rotazione dei certificati di preproduzione
• Produzione live-site/triage
• Accesso totale alla preproduzione

Questo approccio mantiene il più rigoroso principio di minimo privilegio e fornisce gruppi di sicurezza in cui l'ambito è evidente, semplificando il controllo delle appartenenze rispetto alle mansioni lavorative svolte. Spesso esiste un ruolo di Azure predefinito che corrisponde a questa funzione del processo.

Tuttavia, l'appartenenza viene astratta di almeno un livello, costringendo l'utente a rivolgersi al provider di identità per comprendere chi è nel gruppo quando si osserva dal punto di vista delle risorse. Inoltre, una persona deve avere più appartenenze mantenute per una copertura completa. La matrice dei gruppi di sicurezza sovrapposti può essere complessa.

Il modello 2 è consigliato per rendere gli schemi di accesso il punto centrale, non l'organigramma. I organigrammi e i ruoli dei membri talvolta cambiano. L'acquisizione dell'identità e della gestione degli accessi del carico di lavoro da una prospettiva funzionale consente di astrarre l'organizzazione del team dalla gestione sicura del carico di lavoro.

Modelli di segmentazione di rete

Modello 1: Segmentazione all'interno di un carico di lavoro (limiti flessibili)

In questo modello il carico di lavoro viene inserito in una singola rete virtuale usando le subnet per contrassegnare i limiti. La segmentazione viene ottenuta usando due subnet, una per il database e una per i carichi di lavoro Web. È necessario configurare i gruppi di sicurezza di rete (NSG) che consentono alla subnet 1 di comunicare solo con subnet 2 e a subnet 2 di comunicare solo con Internet. Questo schema fornisce il controllo di livello 3 delle reti.

Modello 2: Segmentazione all'interno di un carico di lavoro

Questo modello è un esempio di segmentazione a livello di piattaforma. I componenti del carico di lavoro vengono distribuiti su più reti senza alcun collegamento di peering tra di loro. Tutte le comunicazioni vengono instradate tramite un intermediario che funge da punto di accesso pubblico. Il team di gestione del carico è proprietario di tutte le reti.

Il modello 2 fornisce il contenimento, ma presenta la complessità aggiuntiva della gestione e del dimensionamento della rete virtuale. La comunicazione tra le due reti avviene sulla rete Internet pubblica, che può essere un rischio. Esiste anche una latenza con le connessioni pubbliche. Tuttavia, è possibile eseguire il peering delle due reti, interrompendo la segmentazione collegandole per creare un segmento più grande. Il peering deve essere effettuato quando non si richiedono altri endpoint pubblici.

Modello 3: Isolamento PaaS

Prendere in considerazione l'uso del perimetro di sicurezza di rete di Azure per creare limiti logici per i servizi PaaS con regole rigorose per il traffico in ingresso e in uscita. Questo modello impedisce l'esfiltrazione di dati a destinazioni non autorizzate, senza richiedere singoli endpoint privati per ogni servizio.

Organizzazione delle risorse

Organizzare le risorse di Azure in base alla responsabilità di proprietà

Si consideri un ambiente di Azure che contiene più carichi di lavoro e componenti del servizio condiviso, ad esempio reti virtuali hub, firewall, servizi di gestione delle identità e servizi di sicurezza come Microsoft Sentinel. I componenti in tutto il patrimonio devono essere raggruppati in base alle aree funzionali, ai carichi di lavoro e alla proprietà. Ad esempio, le risorse di rete condivise devono essere raggruppate in una singola sottoscrizione e gestite da un team di rete. I componenti dedicati ai singoli carichi di lavoro devono trovarsi nel proprio segmento e potrebbero essere ulteriormente suddivisi in base ai livelli applicazione o ad altri principi dell'organizzazione.

Concedere l'accesso per gestire le risorse all'interno di singoli segmenti creando assegnazioni di ruolo RBAC. Ad esempio, al team di rete cloud potrebbe essere concesso l'accesso amministrativo alla sottoscrizione che contiene le risorse, ma non alle singole sottoscrizioni del carico di lavoro.

Una buona strategia di segmentazione consente di identificare facilmente i proprietari di ogni segmento. Prendere in considerazione l'uso dei tag delle risorse di Azure per annotare gruppi di risorse o sottoscrizioni con il team proprietario.

Configurare ed esaminare il controllo di accesso

Concedere l'accesso appropriato in base alle esigenze definendo chiaramente i segmenti per le risorse.

Considerare il principio dei privilegi minimi quando si definiscono i criteri di controllo di accesso. È importante distinguere tra le operazioni del piano di controllo (gestione della risorsa stessa) e le operazioni del piano dati (accesso ai dati archiviati dalla risorsa). Si supponga, ad esempio, di avere un carico di lavoro che contiene un database con informazioni riservate sui dipendenti. È possibile concedere l'accesso di gestione ad alcuni utenti che devono configurare impostazioni come i backup del database o gli utenti che monitorano le prestazioni del server di database. Tuttavia, questi utenti non devono essere in grado di eseguire query sui dati sensibili archiviati nel database. Selezionare le autorizzazioni che concedono l'ambito minimo necessario per consentire agli utenti di svolgere i propri compiti. Esaminare regolarmente le assegnazioni di ruolo per ogni segmento e rimuovere l'accesso non più necessario.

Collegamenti correlati

• Isolamento nel cloud pubblico di Azure
• Raccomandazioni per RBAC
• Panoramica delle reti virtuali
• ASGs
• Firewall di Azure
• Panoramica di Gestione firewall

Elenco di controllo relativo alla sicurezza

Fare riferimento al set completo di raccomandazioni.