Raccomandazioni per la creazione di una strategia di segmentazione
Si applica alla raccomandazione dell'elenco di controllo per la sicurezza di Well-Architected Framework:
| SE:04 | Creare la segmentazione intenzionale e i perimetri nella progettazione dell'architettura e il footprint del carico di lavoro sulla piattaforma. La strategia di segmentazione deve includere reti, ruoli e responsabilità, identità del carico di lavoro e organizzazione delle risorse. |
|---|
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.
Definizioni
| Termine | Definizione |
|---|---|
| Containment | Tecnica per contenere il raggio dell'esplosione se un utente malintenzionato ottiene l'accesso a un segmento. |
| Accesso con privilegi minimi | Principio Zero Trust che mira a ridurre al minimo un set di autorizzazioni per completare una funzione di processo. |
| Perimetro | Limite di attendibilità intorno a un segmento. |
| Organizzazione delle risorse | Strategia per raggruppare le risorse correlate in base ai flussi all'interno di un segmento. |
| Ruolo | Set di autorizzazioni necessarie per completare una funzione del processo. |
| Segmento | Unità logica isolata da altre entità e protetta da un set di misure di sicurezza. |
Strategie di progettazione chiave
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 dei processi correlate allo sviluppo e alla gestione dei carichi di lavoro
- Livelli applicazione che isolano tramite l'utilità del carico di lavoro
- 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, viene effettuato il provisioning di più risorse quando gli ambienti di distribuzione eseguiti side-by-side vengono 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 accedere solo ai segmenti necessari per svolgere il proprio 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à.
Assegnare l'accesso con privilegi minimi. Se l'identità è consentita 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 se l'identità è mai 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.
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à.
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 la rete come perimetro
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 perimetrali software-defined nel footprint di rete usando 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.
Si pensi a un utente malintenzionato per ottenere un punto di accesso all'interno del carico di lavoro e stabilire controlli per ridurre al minimo 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 la visibilità da reti pubbliche alla rete il più possibile.
- 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 in base alla finalità. Ad esempio, 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.
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 hop, nella rete, ogni hop può essere un potenziale punto di guasto. Questi punti possono avere un effetto sull'affidabilità del sistema.
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. che possono variare da un gruppo IT centralizzato a piccoli team IT e DevOps pressoché indipendenti.
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.
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 di Azure supporta la segmentazione isolando l'accesso in base alla funzione del processo. Solo determinate azioni sono consentite per determinati ruoli e ambiti. Ad esempio, le funzioni di processo che devono osservare solo il sistema possono essere assegnate autorizzazioni di lettura rispetto alle autorizzazioni di collaboratore che consentono all'identità di gestire le risorse.
Per altre informazioni, vedere Procedure consigliate per il controllo degli accessi in base al ruolo.
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 indirizzi privati all'interno di una sottoscrizione
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 per controllare l'hop successivo 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 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 Firewall di Azure Manager per creare regole o criteri che consentano 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. supporto tecnico di Azure la distribuzione di appliance virtuali di rete, che consente la segmentazione da firewall di terze parti.
Esempio
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 processo
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. Concedere ai gruppi di sicurezza autorizzazioni di controllo degli accessi in base al ruolo, in piedi o just-in-time (JIT), in base alle proprie responsabilità nel carico di lavoro. Assegnare principi umani e di servizio ai gruppi di sicurezza in base all'accesso necessario.
L'appartenenza è altamente visibile a livello di assegnazione di ruolo, semplificando la visualizzazione dell'accesso di un ruolo . Ogni persona è in genere un membro di un solo gruppo di sicurezza, che semplifica 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 di controllo degli accessi in base al ruolo, permanenti o JIT in base alle esigenze, in base alla 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:
- Operatori di database di produzione
- Operatori di database di preproduzione
- Operatori di rotazione dei certificati di produzione
- Operatori di rotazione dei certificati di preproduzione
- Produzione live-site/valutazione
- Preproduzione di tutti gli accessi
Questo approccio mantiene l'accesso con privilegi minimi più rigorosi e fornisce gruppi di sicurezza in cui l'ambito è evidente, semplificando il controllo delle appartenenze rispetto ai compiti dei processi eseguiti. Spesso esiste un ruolo di Azure predefinito che corrisponde a questa funzione del processo.
Tuttavia, l'appartenenza viene astratta almeno un livello, forzando l'utente a passare al provider di identità per comprendere chi è nel gruppo quando si esamina dal punto di vista della risorsa. 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 lo stato attivo, non il 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 gruppi di sicurezza di rete che consentono alla subnet 1 di comunicare solo con subnet 2 e subnet 2 solo per comunicare con Internet. Questo modello fornisce il controllo di livello 3.
Modello 2: Segmentazione all'interno di un carico di lavoro
Questo modello è un esempio di segmentazione a livello di piattaforma. I c omponenti del carico di lavoro vengono distribuiti tra più reti senza eseguire il peering tra di essi. Tutte le comunicazioni vengono instradate tramite un intermediario che funge da punto di accesso pubblico. Il team del carico di lavoro è 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 eseguito quando non sono necessari altri endpoint pubblici.
| Considerazioni | Modello 1 | Modello 2 |
|---|---|---|
| Connettività e routing: modalità di comunicazione di ogni segmento | Il routing di sistema fornisce la connettività predefinita ai componenti del carico di lavoro. Nessun componente esterno può comunicare con il carico di lavoro. | All'interno della rete virtuale, uguale al modello 1. Tra reti, il traffico passa attraverso la rete Internet pubblica. Non esiste connettività diretta tra le reti. |
| Filtro del traffico a livello di rete | Il traffico tra i segmenti è consentito per impostazione predefinita. Usare gruppi di sicurezza di rete o gruppi di sicurezza di rete per filtrare il traffico. | All'interno della rete virtuale, uguale al modello 1. Tra le reti è possibile filtrare il traffico in ingresso e in uscita attraverso un firewall. |
| Endpoint aperti pubblici non intenzionali | Le schede di interfaccia di rete (NIC) non ottengono indirizzi IP pubblici. Le reti virtuali non sono esposte a Gestione API Internet. | Uguale al modello 1. Endpoint pubblico aperto previsto in una rete virtuale, che può essere configurato in modo errato per accettare più traffico. |
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 controllo degli accessi in base al ruolo. 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.
Nota
Alcuni ruoli con privilegi elevati, ad esempio il ruolo proprietario nel controllo degli accessi in base al ruolo, offrono agli utenti la possibilità di concedere ad altri utenti l'accesso a una risorsa. Limitare il numero di utenti o gruppi a cui viene assegnato il ruolo proprietario ed esaminare regolarmente i log di controllo per assicurarsi che eseguano solo operazioni valide.
Collegamenti correlati
- Isolamento nel cloud pubblico di Azure
- Raccomandazioni per il controllo degli accessi in base al ruolo
- Panoramica delle reti virtuali
- AsG
- Firewall di Azure
- Panoramica di Gestione firewall
Elenco di controllo relativo alla sicurezza
Fare riferimento al set completo di raccomandazioni.