Proteggere le reti con Zero Trust

I big data offrono nuove opportunità per ricavare nuove conoscenze e ottenere un vantaggio competitivo. Ci stiamo allontanando da un'era in cui le reti sono state chiaramente definite e di solito specifiche di una determinata posizione. Il cloud, i dispositivi mobili e altri endpoint espandono i limiti e modificano il paradigma. A questo punto non esiste necessariamente una rete contenuta/definita da proteggere. Esiste invece un vasto portfolio di dispositivi e reti, tutti collegati dal cloud.

Invece di ritenere sicuro tutto quello che c'è dietro il firewall aziendale, una strategia Zero Trust end-to-end presuppone che le violazioni siano inevitabili. Ciò significa che è necessario verificare ogni richiesta come se provenisse da una rete incontrollata e in questo caso la gestione delle identità ricopre un ruolo cruciale.

Secondo il modello Zero Trust, quando si tratta di proteggere la rete, gli obiettivi principali sono tre:

  • Preparati a gestire gli attacchi prima che si verifichino.

  • Ridurre al minimo l'entità del danno e la velocità di propagazione.

  • Aumenta la difficoltà di compromettere il footprint del cloud.

A questo scopo, seguiamo tre principi zero trust:

  • Verificare esplicitamente. L’autenticazione e l’autorizzazione sono eseguite sempre su tutti i punti di dati disponibili, inclusi l’identità dell’utente, la posizione, l’integrità del dispositivo, il servizio o il carico di lavoro, la classificazione dei dati e le anomalie.

  • Usare il principio dell’accesso con privilegi minimi. Limitare l'accesso degli utenti con JUST-In-Time e Just-Enough-Access (JIT/JEA), criteri adattivi basati sui rischi e protezione dei dati per proteggere i dati e la produttività.

  • Presupporre le violazioni. Ridurre al minimo il raggio d'azione delle violazioni e prevenire i movimenti laterali segmentando l'accesso in base alla rete, all'utente, ai dispositivi e alla consapevolezza delle applicazioni. Bisogna verificare che tutte le sessioni siano crittografate secondo il principio end-to-end. Usare l'analisi per ottenere visibilità, favorire il rilevamento delle minacce e migliorare le difese.

Obiettivi della distribuzione Zero Trust per la rete

Prima di iniziare il percorso Zero Trust, la maggior parte delle organizzazioni ha una sicurezza di rete caratterizzata dai seguenti aspetti:

  • Pochi perimetri di sicurezza di rete e reti flat aperte.

  • Protezione minima dalle minacce e filtro statico del traffico.

  • Traffico interno non crittografato.

Quando si implementa un framework Zero Trust end-to-end per la protezione delle reti, è consigliabile concentrarsi prima di tutto su questi obiettivi iniziali della distribuzione:

List icon with one checkmark.

Segmentazione di rete: molti micro-perimetri cloud in ingresso/uscita con una micro-segmentazione.

II.Protezione dalle minacce: filtro nativo del cloud e protezione per minacce note.

III.Crittografia: il traffico interno da utente a app viene crittografato.

Dopo averli raggiunti, concentrarsi su questi ulteriori obiettivi della distribuzione:

List icon with two checkmarks.

IV.Segmentazione di rete: microimetri cloud in ingresso/uscita completamente distribuiti e micro-segmentazione più profonda.

Protezione dalle minacce V.Threat: protezione dalle minacce basata su Machine Learning e filtro con segnali basati sul contesto.

VI.Crittografia: tutto il traffico è crittografato.

VII.Interrompere la tecnologia di sicurezza di rete legacy.

Guida alla distribuzione Rete Zero Trust

Questa guida illustra i passaggi necessari per proteggere le reti seguendo i principi di un framework di sicurezza Zero Trust.




Checklist icon with one checkmark.

Obiettivi iniziali della distribuzione

I. Segmentazione di rete: molti micro-perimetrali cloud in ingresso/uscita con micro-segmentazione

Le organizzazioni non devono avere solo una singola pipe grande dentro e fuori dalla rete. In un approccio Zero Trust, le reti vengono invece segmentate in isole più piccole in cui sono contenuti carichi di lavoro specifici. Ogni segmento ha controlli in ingresso e in uscita propri per ridurre al minimo il "raggio di esplosione" dell'accesso non autorizzato ai dati. Implementando perimetrali software-defined con controlli granulari, si aumenta la difficoltà per gli attori non autorizzati di propagarsi in tutta la rete e quindi ridurre lo spostamento laterale delle minacce.

Non esiste una progettazione dell'architettura adatta alle esigenze di tutte le organizzazioni. È possibile scegliere tra alcuni modelli di progettazione comuni per segmentare la rete in base al modello Zero Trust.

In questa guida alla distribuzione verranno illustrati i passaggi per ottenere una di queste progettazioni: Micro-segmentazione.

Con la micro-segmentazione, le organizzazioni possono superare semplici perimetri centralizzati basati sulla rete fino alla segmentazione completa e distribuita usando micro-perimetrali software-defined.

Le applicazioni vengono partizionate in diverse Rete virtuale di Azure e connesse usando un modello hub-spoke

Diagram of two virtual networks connected in a hub-and-spoke model.

Seguire questa procedura:

  1. Creare reti virtuali dedicate per applicazioni e/o componenti dell'applicazione diversi.

  2. Creare una rete virtuale centrale per configurare il comportamento di sicurezza per la connettività tra app e connettere le reti virtuali dell'app in un'architettura hub-spoke.

  3. Distribuire Firewall di Azure nella rete virtuale dell'hub per controllare e gestire il traffico tra le reti virtuali.

II. Protezione dalle minacce: filtro nativo del cloud e protezione per minacce note

Le applicazioni cloud che hanno aperto endpoint ad ambienti esterni, ad esempio Internet o il footprint locale, sono a rischio di attacchi provenienti da tali ambienti. È quindi fondamentale analizzare il traffico per individuare payload dannosi o logica.

Questi tipi di minacce rientrano in due categorie generali:

  • Attacchi noti. Minacce individuate dal provider di software o dalla community più ampia. In questi casi, la firma di attacco è disponibile ed è necessario assicurarsi che ogni richiesta venga verificata in base a tali firme. La chiave consiste nel poter aggiornare rapidamente il motore di rilevamento con eventuali attacchi appena identificati.

  • Attacchi sconosciuti. Si tratta di minacce che non corrispondono abbastanza a nessuna firma nota. Questi tipi di minacce includono vulnerabilità zero-day e modelli insoliti nel traffico delle richieste. La capacità di rilevare tali attacchi dipende da quanto bene le difese sappiano cosa è normale e cosa non è. Le difese devono essere costantemente apprese e aggiornate, ad esempio i modelli aziendali (e il traffico associato) si evolve.

Per proteggersi dalle minacce note, seguire questa procedura:

  1. Per gli endpoint con traffico HTTP/S, proteggere l'uso di Web application firewall (WAF) di Azure tramite:

    1. Attivazione del set di regole predefinito o del set di regole di protezione OWASP top 10 per la protezione da attacchi noti a livello Web

    2. Attivazione del set di regole di protezione del bot per impedire ai bot dannosi di rimuovere informazioni, eseguire il stuffing delle credenziali e così via.

    3. Aggiunta di regole personalizzate per la protezione dalle minacce specifiche dell'azienda.

    È possibile usare una delle due opzioni seguenti:

  2. Per tutti gli endpoint (HTTP o meno), front-with Firewall di Azure for threat intelligence-based filtering at Layer 4 (Front with Firewall di Azure for threat intelligence-based filtering at Layer 4:For all endpoints (HTTP or not), front with Firewall di Azure for threat intelligence-based filtering at Layer 4:

    1. Distribuire e configurare Firewall di Azure tramite il portale di Azure.

    2. Abilitare il filtro basato su intelligence sulle minacce per il traffico.

III. Crittografia: il traffico interno da utente a app è crittografato

Il terzo obiettivo iniziale da concentrarsi è l'aggiunta della crittografia per garantire che il traffico interno da utente a app sia crittografato.

Seguire questa procedura:

  1. Imporre la comunicazione solo HTTPS per le applicazioni Web con connessione Internet reindirizzando il traffico HTTP a HTTPS tramite Frontdoor di Azure.

  2. Connessione dipendenti/partner remoti a Microsoft Azure usando Azure Gateway VPN.

    1. Attivare la crittografia per qualsiasi traffico da punto a sito nel servizio azure Gateway VPN.
  3. Accedere alle macchine virtuali di Azure in modo sicuro usando la comunicazione crittografata tramite Azure Bastion.

    1. Connessione l'uso di SSH per una macchina virtuale Linux.

    2. Connessione l'uso di RDP in una macchina virtuale Windows.




Checklist icon with two checkmarks.

Obiettivi di distribuzione aggiuntivi

IV. Segmentazione di rete: microimetri cloud in ingresso/uscita completamente distribuiti e micro-segmentazione più profonda

Dopo aver raggiunto i tre obiettivi iniziali, il passaggio successivo consiste nel segmentare ulteriormente la rete.

Partizionare i componenti dell'app in subnet diverse

Diagram of a virtual network of servers in the Azure region.

Seguire questa procedura:

  1. All'interno della rete virtuale aggiungere subnet di rete virtuale in modo che i componenti discreti di un'applicazione possano avere i propri perimetri.

  2. Applicare le regole del gruppo di sicurezza di rete per consentire il traffico solo dalle subnet con un sottocomponente dell'app identificato come una controparte di comunicazione legittima.

Segmentare e applicare i limiti esterni

Diagram of a servers and devices with connections across boundaries.

Seguire questa procedura, a seconda del tipo di limite:

Limite Internet
  1. Se è necessaria la connettività Internet per l'applicazione che deve essere instradata tramite la rete virtuale dell'hub, aggiornare le regole del gruppo di sicurezza di rete nella rete virtuale dell'hub per consentire la connettività Internet.

  2. Attivare Protezione DDoS di Azure Standard per proteggere la rete virtuale dell'hub da attacchi a livello di rete volumetrico.

  3. Se l'applicazione usa protocolli HTTP/S, attivare Web application firewall di Azure per proteggersi dalle minacce di livello 7.

Limite locale
  1. Se l'app deve connettersi al data center locale, usare Azure ExpressRoute di VPN di Azure per la connettività alla rete virtuale dell'hub.

  2. Configurare il Firewall di Azure nella rete virtuale dell'hub per controllare e gestire il traffico.

Limite dei servizi PaaS
  • Quando si usano i servizi PaaS forniti da Azure (ad esempio, Archiviazione di Azure, Azure Cosmos DB o App Web di Azure, usare l'opzione di connettività PrivateLink per garantire che tutti gli scambi di dati si trovino nello spazio IP privato e il traffico non esca mai dalla rete Microsoft.

V. Protezione dalle minacce: protezione dalle minacce basata su Machine Learning e filtro con segnali basati sul contesto

Per una maggiore protezione dalle minacce, attivare Protezione DDoS di Azure Standard per monitorare costantemente il traffico dell'applicazione ospitata in Azure, usare i framework basati su ML per la baseline e rilevare le inondazioni del traffico metrico e applicare mitigazioni automatiche.

Seguire questa procedura:

  1. Configurare e gestire Protezione DDoS di Azure Standard.

  2. Configurare gli avvisi per le metriche di protezione DDoS.

VI. Crittografia: tutto il traffico è crittografato

Infine, completare la protezione di rete assicurandosi che tutto il traffico sia crittografato.

Seguire questa procedura:

  1. Crittografare il traffico back-end dell'applicazione tra reti virtuali.

  2. Crittografare il traffico tra l'ambiente locale e il cloud:

    1. Configurare una VPN da sito a sito tramite peering Microsoft ExpressRoute.

    2. Configurare la modalità di trasporto IPsec per il peering privato di ExpressRoute.

VII. Interrompere la tecnologia di sicurezza di rete legacy

Interrompere l'uso di sistemi di prevenzione delle intrusioni di rete (NIDS/NIPS) basati sulla firma e sulla prevenzione della perdita/perdita di dati di rete (DLP).

I principali provider di servizi cloud filtrano già i pacchetti in formato non valido e gli attacchi comuni a livello di rete, quindi non è necessario che una soluzione NIDS/NIPS rilevi tali pacchetti. Inoltre, le soluzioni NIDS/NIPS tradizionali sono in genere guidate da approcci basati sulla firma (considerati obsoleti) e vengono facilmente evasi da utenti malintenzionati e in genere producono un tasso elevato di falsi positivi.

La prevenzione della perdita dei dati basata sulla rete è in diminuzione per identificare sia la perdita accidentale che intenzionale dei dati. La maggior parte dei protocolli moderni e degli utenti malintenzionati usa infatti la crittografia a livello di rete per le comunicazioni in ingresso e in uscita. L'unica soluzione praticabile per questa soluzione è "SSL-bridging" che fornisce un "man-in-the-middle autorizzato" che termina e quindi riasablishe le connessioni di rete crittografate. L'approccio SSL-bridging è diminuito a causa del livello di attendibilità richiesto per il partner che esegue la soluzione e le tecnologie usate.

In base a questa logica, è consigliabile interrompere l'uso di queste tecnologie di sicurezza di rete legacy. Tuttavia, se l'esperienza organizzativa è che queste tecnologie hanno avuto un impatto palpabile sulla prevenzione e il rilevamento di attacchi reali, è possibile valutare la possibilità di convertirli nell'ambiente cloud.

Prodotti trattati in questa guida

Microsoft Azure

Rete di Azure

Rete virtuale e subnet

Gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni

Firewall di Azure

Protezione di Azure dagli attacchi DDoS

Azure Web Application Firewall

Gateway VPN di Azure

Azure ExpressRoute

Azure Network Watcher

Conclusione

La protezione delle reti è fondamentale per una strategia zero trust riuscita. Per altre informazioni o assistenza sull'implementazione, contattare il team customer success o continuare a leggere gli altri capitoli di questa guida, che si estende su tutti i pilastri zero trust.



Serie di guide alla distribuzione Zero Trust

Icon for the introduction

Icon for identity

Icon for endpoints

Icon for applications

Icon for data

Icon for infrastructure

Icon for networks

Icon for visibility, automation, orchestration