Proteggere i carichi di lavoro negli ambienti multicloud con Zero Trust Exchange di Zscaler

Per la maggior parte delle aziende, il cloud è diventato il nuovo data center e gli ambienti multi-cloud sono sempre più diffusi. I carichi di lavoro cloud devono comunicare in modo sicuro sia tra di loro, sia con Internet. Purtroppo, le opzioni disponibili per creare una connettività sicura da cloud a cloud e da cloud a Internet, che utilizzano firewall e VPN per estendere la WAN aziendale al cloud, generano rischi per la sicurezza, complessità operativa e problemi prestazionali.

Difficoltà nell'estensione della WAN aziendale al cloud

Tradizionalmente, due ambienti diversi vengono collegati utilizzando dei router. Poiché questi router vengono impiegati per chiudere i tunnel VPN o IPsec e i percorsi di scambio, ciascuno di questi ambienti ha accesso a tutti gli indirizzi IP degli altri ambienti. Tra questi ambienti, vengono utilizzati dei firewall per fornire il controllo statico dell'accesso e garantire che solo alcuni specifici IP in un ambiente abbiano accesso a specifici IP in altri ambienti. Questo è l'approccio legacy basato su firewall e IP che la maggior parte delle aziende è stata costretta ad adottare.

 

L'approccio basato su firewall e IP crea rischi per la sicurezza, perché la connettività flat di tipo IP full-mesh rende le reti suscettibili al movimento laterale delle minacce.

Questo approccio crea inoltre complessità operativa, con carichi di lavoro effimeri sul cloud. Quando gli IP si muovono in entrata e in uscita, ogni nuovo IP deve essere propagato dai router. Qualsiasi nuovo IP deve essere programmato nel firewall e, eventuali sovrapposizioni di questi IP devono essere risolte prima che possano connettersi a queste reti.

Questo approccio presenta anche sfide in termini di scalabilità e prestazioni, come la scalabilità del routing, i colli di bottiglia nei throughput e una latenza più elevata.

Le difficoltà diventano sempre più complesse man mano che più applicazioni vengono distribuite su diversi cloud e si adottano servizi nativi del cloud, come container, PaaS, e serverless.

In un approccio legacy, tutto il traffico diretto a Internet, o ad altri carichi di lavoro in un cloud diverso, deve passare attraverso un hub centralizzato con firewall, proxy Squid, router, ecc., in modo analogo a un'architettura di tipo "castello e fossato" in un data center. Tra le limitazioni vi sono:

 

 

1.Limitazioni relative al profilo di sicurezza:

Per un profilo di sicurezza completo, sono necessarie funzionalità aggiuntive, come proxy e protezione dei dati, perché l'ispezione SSL su larga scala non è realizzabile mediante firewall virtuali. Questo richiede ulteriori appliance virtuali per proxy Squid, sandboxing, ecc.

2. Rischi delle reti full mesh:

Per consentire la comunicazione dei carichi di lavoro in un ambiente multi-cloud, l'architettura IP legacy distribuisce percorsi e condivide informazioni degli IP e delle sottoreti in diversi ambienti, creando una rete flat e regole firewall statiche, che sono facili da eludere e che possono favorire il movimento laterale delle minacce.

3. Limitazione delle prestazioni degli appliance:

Il throughput è limitato dalla portata e dalle prestazioni del firewall. Più servizi di sicurezza vengono abilitati sui firewall, come l'ispezione SSL dei contenuti, più lente saranno le prestazioni.

4. Complessità nell'organizzazione e nella gestione:

I firewall legacy richiedono VM aggiuntive per l'organizzazione, le policy, le operazioni e la gestione delle licenze, che incrementano il livello di complessità e i costi. Replicare queste condizioni per ogni provider di servizi cloud complica ulteriormente le operazioni su più cloud.

5. Punti ciechi dovuti a multi-hop verso una destinazione:

Gli approcci legacy basati sugli IP necessitano di più strumenti, come firewall, router SD-WAN, NACL e gruppi di sicurezza. Ognuno di essi richiede la propria procedura di registrazione, e una correlazione errata dei registri crea ulteriori punti ciechi per i team che si occupano di rete e di sicurezza.

Estensione dello zero trust ai carichi di lavoro cloud

Fortunatamente, negli ultimi anni abbiamo già assistito alle difficoltà poste dalla WAN aziendale per l'accesso dei dipendenti. Per superare i limiti relativi alla sicurezza e alle prestazioni dell'approccio con IP e firewall, una percentuale crescente di aziende ha adottato una strategia zero trust. Gli stessi principi dello zero trust, reinventati per le esigenze specifiche dei carichi di lavoro cloud, rappresentano la strada da seguire per la rete multi-cloud.

Secondo questo approccio, le reti non devono essere mai considerate attendibili, ed è per questo che le informazioni su IP e routing non vengono mai scambiate. La connettività è abilitata a livello granulare per i carichi di lavoro, in base all'identità e al contesto, e non è necessario creare regole statiche del firewall per limitare l'accesso IP tra gli ambienti.

 

Zscaler Internet Access (ZIA) e Zscaler Private Access (ZPA) sono i leader nella protezione dell'accesso degli utenti finali a Internet e alle applicazioni private. Workload Communications di Zscaler, abilitato da Cloud Connector, estende queste soluzioni per proteggere l'accesso dei carichi di lavoro a Internet (ZIA per i carichi di lavoro) e l'accesso privato ai carichi di lavoro privati in remoto (con ZPA per i carichi di lavoro). È un approccio rivoluzionario che migliora la sicurezza, riduce la complessità operativa e migliora le prestazioni delle applicazioni.

 

Caso d'uso 1: abilitare lo zero trust per la comunicazione tra carichi di lavoro e Internet

Cloud Connector consente ai carichi di lavoro di connettersi direttamente al cloud Zscaler per l'accesso a Internet. Tutti i servizi di sicurezza, come proxy SSL, protezione dei dati e protezione dalle minacce avanzate, sono eseguiti in modo nativo su Zero Trust Exchange. Con questa architettura, è possibile applicare la stessa policy di sicurezza a tutti i carichi di lavoro che accedono a Internet, da qualsiasi cloud. Questo approccio è in netto contrasto con le architetture legacy, dove è invece necessario costruire una struttura a castello e fossato, con firewall e proxy Squid in ogni cloud.

 

Caso d'uso 2: abilitare lo zero trust per la comunicazione tra carichi di lavoro in un ambiente multi-cloud

Cloud Connector consente ai carichi di lavoro di connettersi direttamente al cloud Zscaler. I carichi di lavoro provenienti da qualsiasi cloud (AWS, Azure, data center) possono comunicare tra loro tramite Zero Trust Exchange, che utilizza l'identità e il contesto per verificare l'attendibilità e stabilire la connessione. È un approccio è in netto contrasto con le architetture legacy, in cui è richiesto il routing dell'IP tra ambienti cloud.

 

Caso d'uso 3: abilitare lo zero trust per la comunicazione tra carichi di lavoro all'interno di un VPC/VNET

Zscaler Workload Segmentation porta la segmentazione a un livello granulare, all'interno di una macchina virtuale a livello delle singole applicazioni o dei processi. Un agente di segmentazione del carico di lavoro fornisce l'identità del software generando impronte digitali a livello del processo. Il Machine Learning rileva tutti i percorsi disponibili per un particolare processo o applicazione e fornisce una raccomandazione sui percorsi consentiti, eliminando tutti quelli inutili che aumentano il rischio di movimento laterale delle minacce. Questo approccio è in contrasto con le architetture legacy, in cui vengono utilizzate ACL statiche (Access Control Lists, liste di controllo degli accessi) e SG (Security Groups, gruppi di sicurezza), che gli utenti malintenzionati possono facilmente eludere sfruttando le regole esistenti.

In che modo lo zero trust risolve i limiti di IP e firewall

 

 

Quando abbiamo studiato le architetture legacy, abbiamo rilevato che il problema di fondo comune è la connettività IP. Tradizionalmente, le reti e la sicurezza vengono considerate come funzionalità separate: prima viene abilitata la connessione (routing IP), e su questa base viene quindi applicata la sicurezza (filtro firewall). Alcuni fornitori hanno integrato entrambi questi elementi in un unico dispositivo, ma l'approccio e l'architettura sono gli stessi.

Zero Trust Exchange di Zscaler adotta un approccio completamente diverso: prima viene la sicurezza, poi la connettività. Perché creare una connettività non necessaria che a un certo punto bisognerà bloccare?

Nell'approccio zero trust di Zscaler, niente viene ritenuto attendibile. L'unica connettività predefinita è Zero Trust Exchange, non l'applicazione di destinazione. Tutto il traffico dei carichi di lavoro viene inoltrato a Cloud Connector, che quindi collega questi carichi di lavoro a Zero Trust Exchange.

Prima che l'origine e la destinazione vengano connesse, Zero Trust Exchange effettua i seguenti passaggi:

1° passaggio: definire l'identità

Zero Trust Exchange verifica la provenienza dei carichi di lavoro, ad esempio un Cloud Connector autenticato e registrato, o un VPC o VNET del cliente.

2° passaggio: definire la direzione

È possibile definire la policy in base alla destinazione, e Zero Trust Exchange è in grado di verificare se la destinazione rappresenta un'applicazione autorizzata o meno.

3° passaggio: definire il livello di rischio

È possibile avere una policy basata sul VPC/VNET sorgente. Solo i VPC aziendali vengono considerati attendibili per accedere a determinate destinazioni, mentre i VPC/VNET partner, che sono invece considerati rischiosi, non vi possono accedere.

4° passaggio: definire l'intento dell'utente

Per le destinazioni Internet non attendibili, è possibile abilitare un proxy SSL completo e ispezionare tutto ciò che proviene dall'origine ed è diretto alla destinazione, e viceversa.

5° passaggio: stabilire la connessione

Per le destinazioni Internet, facciamo da intermediari e stabiliamo una connessione alla destinazione. Per l'accesso privato alle applicazioni, viene instaurata una connessione dall'interno verso l'esterno, dall'Application Connector alla destinazione. Zero Trust Exchange è il punto di interscambio che stabilisce questa connessione.

I principali vantaggi dello zero trust per i carichi di lavoro cloud

1. Protezione dalle minacce informatiche per tutti i carichi di lavoro:

Impedisce la compromissione dei carichi di lavoro:
L'ispezione informatica viene effettuata per tutte le comunicazioni dei carichi di lavoro diretti a Internet, e questo consente di proteggerli da minacce come botnet, contenuti attivi dannosi e frodi.

Impedisce il movimento laterale delle minacce tra i cloud:
Grazie alla connettività zero trust, ogni ambiente (data center, regioni cloud, ecc.) viene isolato e qualsiasi destinazione negli altri ambienti non è indirizzabile. Ciò impedisce qualsiasi movimento laterale delle minacce, in tutti gli ambienti.

Impedisce il movimento laterale delle minacce all'interno di un data center o all'interno di una regione cloud:
La microsegmentazione basata sull'identità a livello di processo impedisce qualsiasi movimento laterale delle minacce all'interno di un data center o all'interno di una regione cloud.

2. Protezione dei dati su SaaS e cloud pubblici:

Protezione dei dati su cloud pubblici:
L'accesso a privilegi minimi ai carichi di lavoro viene garantito riducendo al minimo i diritti (CIEM), mentre il rischio di compromissione viene ridotto correggendo gli errori di configurazione (CSPM).

Protezione dei dati SaaS:
Si ottiene visibilità sulle operazioni dello shadow IT, per prevenire l'utilizzo di applicazioni non autorizzate e impedire la condivisione eccessiva (API CASB).

DLP in linea:
Le violazioni o esfiltrazioni dei dati vengono evitate, assicurando che tutto il traffico dei carichi di lavoro che attraversa Internet venga ispezionato dalla DLP.

3. Iperscalabilità e prestazioni:
Zscaler dispone di oltre 150 POP di servizio di Zero Trust Exchange. Questi POP effettuano il peering con tutti i principali fornitori di servizi cloud e ognuno di essi ha una capacità operativa di terabyte. Cloud Connector si connette al POP più vicino con la migliore disponibilità.
 

4. Supporto delle DevOps e automatizzazione completa:
La gestione e la policy sono amministrate a livello centrale e distribuite sul cloud, e tutti gli aggiornamenti per i Cloud Connectors sono gestiti da Zscaler. Il coordinamento Terraform può essere integrato facilmente con la pipeline CI/CD di DevOps. Vengono fornite anche le automazioni native delle piattaforme, come i modelli Cloudformation e Azure Resource Manager (ARM).

5. Registrazione completa e streaming dei log:
Tutto il traffico in uscita da qualsiasi Cloud Connector, incluso il traffico diretto a Zero Trust Exchange, viene registrato e può essere trasmesso in streaming a un SIEM/aggregatore di log a scelta. Sono disponibili filtri più sofisticati per lo streaming in posizioni critiche.

Distribuzione dei Cloud Connector

Il Cloud Connector può essere implementato in ciascun VPC/VNET, se è necessario l'isolamento a livello di VPC/VNET, oppure può essere implementato in una posizione centrale se è necessario isolare un gruppo di VPC/VNET. I modelli hanno la flessibilità necessaria per supportare deployment sia centralizzati che distribuiti.

 

 

 

In sintesi, i carichi di lavoro sono considerati immagini speculari degli utenti. Adottando un'architettura zero trust per le comunicazioni tra carichi di lavoro, è possibile proteggere i dati e i carichi di lavoro, eliminare le superfici di attacco e bloccare il movimento laterale delle minacce. Ti invitiamo a unirti a noi in questo percorso verso lo zero trust per trasformare la tua connettività cloud. Per programmare una dimostrazione, puoi contattarci all'indirizzo [email protected].