Applicare principi Zero Trust alla segmentazione delle comunicazioni di rete basate su Azure

Articolo
05/31/2024

Questo articolo fornisce indicazioni per l'applicazione dei principi di Zero Trust per la segmentazione delle reti in ambienti Azure. Ecco i principi Zero Trust.

Principio zero trust	Definizione
Verificare esplicita	Eseguire sempre l'autenticazione e l'autorizzazione in base a tutti i punti dati disponibili.
Usare l'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.
Presunzione di violazione	Ridurre al minimo il raggio di attacco e l'accesso al segmento. Verificare la crittografia end-to-end e usare l'analisi per ottenere visibilità, guidare il rilevamento delle minacce e migliorare le difese. È possibile ridurre al minimo il raggio di attacco informatico e segmentare l'accesso eseguendo la segmentazione di rete a vari livelli nell'infrastruttura di Azure.

Questo articolo fa parte di una serie di articoli che illustrano come applicare i principi di Zero Trust alla rete di Azure.

Man mano che le organizzazioni crescono da piccole imprese a grandi aziende, spesso devono passare da una singola sottoscrizione di Azure a più sottoscrizioni per separare le risorse per ogni reparto. È importante pianificare attentamente la segmentazione della rete per creare limiti logici e isolamento tra ambienti.

Ogni ambiente, in genere che riflette un reparto separato dell'organizzazione, deve avere le proprie autorizzazioni di accesso e criteri per carichi di lavoro specifici. Ad esempio, gli utenti della sottoscrizione per sviluppatori di software interno non devono avere accesso alla gestione e alla distribuzione delle risorse di rete nella sottoscrizione di connettività. Tuttavia, questi ambienti richiedono ancora la connettività di rete per ottenere le funzionalità necessarie ai servizi di base, ad esempio DNS, connettività ibrida e essere in grado di raggiungere altre risorse tra reti virtuali di Azure diverse.

La segmentazione dell'infrastruttura di Azure fornisce non solo l'isolamento, ma può anche creare limiti di sicurezza che impediscono a un utente malintenzionato di spostarsi tra ambienti e infliggere danni aggiuntivi (principio Presuppone violazione Zero Trust).

Architettura di riferimento

È possibile usare diversi livelli di segmentazione in Azure per proteggere le risorse da accessi non autorizzati o attacchi dannosi. Questi livelli di segmentazione iniziano a livello di sottoscrizione e passano fino alle applicazioni in esecuzione nelle macchine virtuali. La segmentazione crea un limite che separa un ambiente da un altro, ognuno con regole e criteri specifici. Supponendo che le violazioni possano verificarsi, è necessario segmentare le reti per prevenirne la diffusione.

La rete di Azure usa i livelli di segmentazione seguenti:

Sottoscrizioni

Una sottoscrizione di Azure è un contenitore logico usato per il provisioning delle risorse in Azure. È collegato a un account Azure in un tenant di Microsoft Entra ID e funge da singola unità di fatturazione per le risorse di Azure assegnate alla sottoscrizione. Una sottoscrizione di Azure è anche un limite logico per l'accesso alle risorse contenute nella sottoscrizione. L'accesso tra risorse in sottoscrizioni diverse richiede autorizzazioni esplicite.
Reti virtuali

Una rete virtuale di Azure è una rete privata isolata che per impostazione predefinita consente a tutte le macchine virtuali al suo interno di comunicare tra loro. Per impostazione predefinita, le reti virtuali non possono comunicare con altre reti virtuali, a meno che non si creino connessioni tra di esse tramite peering, connessioni VPN o ExpressRoute. Le singole reti virtuali possono essere usate come limite di attendibilità che divide applicazioni, carichi di lavoro, reparti o organizzazioni diverse.

Azure Rete virtuale Manager (AVNM) è un servizio di gestione della rete che consente a un singolo team di amministrazione di gestire le reti virtuali e applicare regole di sicurezza tra più sottoscrizioni a livello globale. È possibile usare AVNM per definire i gruppi di rete per determinare quali reti virtuali possono comunicare tra loro. È anche possibile usare AVNM per monitorare le modifiche della configurazione di rete.
Carichi di lavoro all'interno di una rete virtuale

Per i carichi di lavoro all'interno di una rete virtuale, ad esempio macchine virtuali o servizi PaaS che supportano l'integrazione della rete virtuale, ad esempio Azure Databricks e servizio app, la comunicazione è consentita per impostazione predefinita perché sono contenute nella stessa rete virtuale e devono essere ulteriormente protette usando i gruppi di sicurezza di rete. Gli strumenti e i servizi per la segmentazione all'interno di una rete virtuale includono quanto segue:
- Firewall di Azure
  
  Firewall di Azure è un servizio distribuito in una rete virtuale per filtrare il traffico tra risorse cloud, locale e Internet. Con Firewall di Azure è possibile definire regole e criteri per consentire o negare il traffico a livello di rete e applicazione. È anche possibile trarre vantaggio dalle funzionalità avanzate di protezione dalle minacce fornite da Firewall di Azure come il rilevamento e la prevenzione delle intrusioni (IDPS), l'ispezione TLS (Transport Layer Security) e il filtro basato sull'intelligence sulle minacce.
- Gruppo di sicurezza di rete
  
  Un gruppo di sicurezza di rete è un meccanismo di controllo di accesso che filtra il traffico di rete tra le risorse di Azure, ad esempio le macchine virtuali all'interno di una rete virtuale. Un gruppo di sicurezza di rete contiene regole di sicurezza che consentono o negano il traffico a livello di subnet o macchina virtuale in una rete virtuale. Un uso comune dei gruppi di sicurezza di rete consiste nel segmentare i set di macchine virtuali in subnet diverse.
- Gruppo di sicurezza delle applicazioni
  
  Un gruppo di sicurezza delle applicazioni è un'estensione di un gruppo di sicurezza di rete che consente di raggruppare le interfacce di rete delle macchine virtuali in base ai relativi ruoli e funzioni. È quindi possibile usare i gruppi di sicurezza delle applicazioni in un gruppo di sicurezza di rete su larga scala senza dover definire gli indirizzi IP delle macchine virtuali.
- Frontdoor di Azure
  
  Frontdoor di Azure è il cloud moderno di Microsoft rete per la distribuzione di contenuti (RETE CDN) che offre accesso rapido, affidabile e sicuro tra gli utenti e il contenuto Web statico e dinamico delle applicazioni in tutto il mondo.

Il diagramma seguente illustra l'architettura di riferimento per i livelli di segmentazione.

Nel diagramma le linee rosse solide indicano i livelli di segmentazione tra:

Sottoscrizioni di Azure
Reti virtuali in una sottoscrizione
Subnet in una rete virtuale
Internet e una rete virtuale

Il diagramma mostra anche un set di reti virtuali gestite da AVNM che possono estendersi su sottoscrizioni di Azure.

Che cos'è in questo articolo?

I principi Zero Trust vengono applicati nell'architettura di riferimento all'interno del cloud di Azure. Nella tabella seguente vengono descritte le raccomandazioni per la segmentazione delle reti in questa architettura per rispettare il principio Assume violazione Zero Trust.

Passaggio	Attività
1	Segmentare all'interno delle singole reti virtuali.
2	Connettere più reti virtuali con il peering.
3	Connettere più reti virtuali in una configurazione hub-spoke.

Passaggio 1: Segmentare all'interno delle singole reti virtuali

All'interno di una singola rete virtuale in una sottoscrizione di Azure si usano le subnet per ottenere la separazione e la segmentazione delle risorse. Ad esempio, all'interno di una rete virtuale potrebbe essere presente una subnet per i server di database, un'altra per le applicazioni Web e una subnet dedicata per un gateway di Firewall di Azure o app Azure lication con un Web Application Firewall. Per impostazione predefinita, tutte le comunicazioni tra subnet sono abilitate all'interno di una rete virtuale.

Per creare l'isolamento tra subnet, è possibile applicare gruppi di sicurezza di rete o gruppi di sicurezza delle applicazioni per consentire o negare traffico di rete specifico in base a indirizzi IP, porte o protocolli. Tuttavia, la progettazione e la gestione dei gruppi di sicurezza di rete e dei gruppi di sicurezza delle applicazioni possono anche creare un sovraccarico di gestione.

Questa figura mostra una configurazione comune e consigliata di un'applicazione a tre livelli con subnet separate per ogni livello e l'uso di gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni per creare limiti segmentati tra ogni subnet.

È anche possibile ottenere la segmentazione delle risorse instradando il traffico tra subnet usando route definite dall'utente (UDR) che puntano a un Firewall di Azure o a un'appliance virtuale di rete di terze parti. Firewall di Azure e appliance virtuali di rete hanno anche la possibilità di consentire o negare il traffico usando i controlli di livello 3 a livello 7. La maggior parte di questi servizi offre funzionalità avanzate di filtro.

Per altre informazioni, vedere le linee guida in Modello 1: Rete virtuale singola.

Passaggio 2: Connettere più reti virtuali con il peering

Per impostazione predefinita, non è consentita alcuna comunicazione tra reti virtuali con una singola sottoscrizione di Azure o tra più sottoscrizioni. Più reti virtuali, ognuna appartenente a entità diverse, ha i propri controlli di accesso. Possono connettersi tra loro o a una rete virtuale hub centralizzata usando il peering reti virtuali, in cui un'Firewall di Azure o un'appliance virtuale di rete di terze parti controlla tutto il traffico.

Questa figura mostra una connessione peering reti virtuali tra due reti virtuali e l'uso di Firewall di Azure in ogni estremità della connessione.

Una rete virtuale hub contiene in genere componenti condivisi, ad esempio firewall, provider di identità e componenti di connettività ibrida, tra gli altri. La gestione della route definita dall'utente diventa più semplice perché l'aggiunta di route definite dall'utente specifiche per la micro-segmentazione sarebbe necessaria solo se il traffico all'interno della rete virtuale è un requisito. Tuttavia, poiché la rete virtuale ha limiti propri, i controlli di sicurezza sono già presenti.

Per altre informazioni, vedere le linee guida seguenti:

Passaggio 3: Connettere più reti virtuali in una configurazione hub-spoke

Per più reti virtuali in una configurazione hub-spoke, è necessario considerare come segmentare il traffico di rete per questi limiti:

Limite Internet
Limite di rete locale
Limiti ai servizi globali di Azure

Limite Internet

La protezione del traffico Internet è una priorità fondamentale nella sicurezza di rete, che comporta la gestione del traffico in ingresso da Internet (non attendibile) e il traffico in uscita diretto verso Internet (attendibile) dai carichi di lavoro di Azure.

Microsoft consiglia che il traffico in ingresso da Internet abbia un singolo punto di ingresso. Microsoft incoraggia vivamente l'attraversamento del traffico in ingresso attraverso una risorsa PaaS di Azure, ad esempio Firewall di Azure, Frontdoor di Azure o app Azure lication Gateway. Queste risorse PaaS offrono più funzionalità rispetto a una macchina virtuale con un indirizzo IP pubblico.

Firewall di Azure

Questa figura mostra come Firewall di Azure nella propria subnet funge da punto di ingresso centrale e limite di segmentazione per il traffico tra Internet e un carico di lavoro a tre livelli in una rete virtuale di Azure.

Per altre informazioni, vedere Firewall di Azure in Microsoft Azure Well-Architected Framework.

Frontdoor di Azure

Frontdoor di Azure può fungere da limite tra Internet e i servizi ospitati in Azure. Frontdoor di Azure supporta collegamento privato connettività alle risorse, ad esempio bilanciamento del carico interno (ILB) per l'accesso alla rete virtuale, account di archiviazione per siti Web statici e archiviazione BLOB e servizi app Azure. Frontdoor di Azure viene in genere eseguito per le distribuzioni su larga scala.

Frontdoor di Azure è più di un servizio di bilanciamento del carico. L'infrastruttura frontdoor di Azure include la protezione DDoS incorporata. Quando la memorizzazione nella cache è abilitata, il contenuto può essere recuperato da posizioni POP (Point of Presence) anziché accedere costantemente ai server back-end. Alla scadenza della cache, Frontdoor di Azure recupera la risorsa richiesta e aggiorna la cache. Anziché gli utenti finali che accedono ai server, Frontdoor di Azure usa Split TCP per due connessioni separate. Ciò non solo migliora l'esperienza dell'utente finale, ma impedisce agli attori malintenzionati di accedere direttamente alle risorse.

Questa figura mostra come Frontdoor di Azure fornisce la segmentazione tra gli utenti Internet e le risorse di Azure, che possono trovarsi negli account di archiviazione.

Per altre informazioni, vedere Frontdoor di Azure in Azure Well-Architected Framework.

Gateway applicazione di Azure

Il punto internet di ingresso può anche essere una combinazione di punti di ingresso. Ad esempio, il traffico HTTP/HTTPS può essere in ingresso attraverso un gateway applicazione protetto da un Web Application Firewall o da Frontdoor di Azure. Il traffico non HTTP/HTTPS, ad esempio RDP/SSH, può in ingresso tramite Firewall di Azure o un'appliance virtuale di rete. È possibile usare questi due elementi insieme per un'ispezione più approfondita e per controllare il flusso del traffico usando le route definite dall'utente.

Questa figura mostra il traffico in ingresso Internet e l'uso di un gateway applicazione con un web application firewall per il traffico HTTP/HTTPS e un Firewall di Azure per tutto il traffico.

Due scenari comunemente consigliati sono:

Posizionare un Firewall di Azure o un'appliance virtuale di rete in parallelo con un gateway applicazione.
Posizionare un Firewall di Azure o un'appliance virtuale di rete dopo un gateway applicazione per un'ulteriore ispezione del traffico prima che raggiunga la destinazione.

Per altre informazioni, vedere app Azure lication Gateway in Microsoft Azure Well-Architected Framework.

Ecco altri modelli comuni per i flussi di traffico Internet.

Traffico in ingresso con più interfacce

Un approccio prevede l'uso di più interfacce di rete nelle macchine virtuali quando si usano appliance virtuali di rete: un'interfaccia per il traffico non attendibile (esterno) e un'altra per il traffico attendibile (con connessione interna). In termini di flusso del traffico, è necessario instradare il traffico in ingresso dall'ambiente locale all'appliance virtuale di rete usando le route definite dall'utente. Il traffico in ingresso da Internet ricevuto dall'appliance virtuale di rete deve essere instradato al carico di lavoro di destinazione nella rete virtuale o nella subnet appropriata tramite una combinazione di route statiche nell'appliance del sistema operativo guest e nelle route definite dall'utente.

Traffico in uscita e route definite dall'utente

Per il traffico che parte dalla rete virtuale per Internet, è possibile applicare una route definita dall'utente usando una tabella di route con l'appliance virtuale di rete scelta come hop successivo. Per ridurre la complessità, è possibile distribuire un Firewall di Azure o un'appliance virtuale di rete all'interno dell'hub rete WAN virtuale di Azure e attivare la sicurezza Internet con finalità di routing. Ciò garantisce che sia il traffico nord-sud (in entrata e in uscita da un ambito di rete) che il traffico est-ovest (tra i dispositivi all'interno di un ambito di rete) destinato agli indirizzi IP virtuali (VIP) non di Azure venga controllato.

Traffico in uscita e route predefinite

Alcuni metodi comportano la gestione di una route predefinita (0.0.0.0/0) con metodi diversi. Come regola generale, è consigliabile che il traffico in uscita originato in Azure usi punti di uscita e ispezione con Firewall di Azure o appliance virtuali di rete a causa della velocità effettiva che l'infrastruttura di Azure può gestire, che nella maggior parte dei casi potrebbe essere molto maggiore e più resiliente. In questo caso, la configurazione di una route predefinita nelle route definite dall'utente delle subnet del carico di lavoro può forzare il traffico verso tali punti di uscita. Potrebbe anche essere preferibile instradare il traffico in uscita dall'ambiente locale ad Azure come punto di uscita. In questo caso, usare il server di route di Azure in combinazione con un'appliance virtuale di rete per annunciare una route predefinita all'ambiente locale usando il protocollo BGP (Border Gateway Protocol).

Ci sono casi speciali quando è necessario che tutto il traffico in uscita venga indirizzato all'ambiente locale annunciando una route predefinita su BGP. In questo modo il traffico che lascia la rete virtuale deve essere sottoposto a tunneling tramite la rete locale a un firewall per l'ispezione. Questo ultimo approccio è il meno desiderato a causa di una maggiore latenza e della mancanza di controlli di sicurezza forniti da Azure. Questa pratica è ampiamente adottata dai settori governativi e bancari che hanno requisiti specifici per l'ispezione del traffico all'interno dell'ambiente locale.

In termini di scalabilità:

Per una singola rete virtuale, è possibile usare i gruppi di sicurezza di rete, che rispettano rigorosamente la semantica di livello 4 oppure è possibile usare un Firewall di Azure conforme alla semantica di livello 4 e di livello 7.
Per più reti virtuali, è comunque possibile usare un singolo Firewall di Azure se raggiungibile oppure distribuire un Firewall di Azure in ogni rete virtuale e indirizzare il traffico con route definite dall'utente.

Per le reti distribuite aziendali di grandi dimensioni, è comunque possibile usare il modello hub-spoke e indirizzare il traffico con route definite dall'utente. Tuttavia, ciò può comportare un sovraccarico di gestione e limiti di peering reti virtuali. Per semplificare l'uso, Azure rete WAN virtuale può ottenere questo risultato se si distribuisce un Firewall di Azure nell'hub virtuale e si attiva la finalità di routing per la sicurezza Internet. In questo modo verranno inserite route predefinite in tutti gli spoke e nelle reti di succursali e invierà il traffico associato a Internet al Firewall di Azure per l'ispezione. Il traffico privato destinato ai blocchi di indirizzi RFC 1918 viene inviato al Firewall di Azure o all'appliance virtuale di rete come hop successivo designato all'interno dell'hub rete WAN virtuale di Azure.

Limite di rete locale

In Azure, i metodi principali per stabilire la connettività con le reti locali includono tunnel IPsec (Internet Protocol), tunnel ExpressRoute o tunnel WAN software-defined (SD-WAN). In genere si usa una connessione VPN da sito a sito di Azure per carichi di lavoro più piccoli che richiedono meno larghezza di banda. Per i carichi di lavoro che richiedono un percorso di servizio dedicato e esigenze di velocità effettiva più elevate, Microsoft consiglia ExpressRoute.

Questa figura mostra i diversi tipi di metodi di connessione tra un ambiente di Azure e una rete locale.

Sebbene le connessioni VPN di Azure possano supportare più tunnel, ExpressRoute è spesso configurato per reti aziendali di grandi dimensioni che richiedono una maggiore larghezza di banda e connessioni private tramite un partner di connettività. Per ExpressRoute, è possibile connettere la stessa rete virtuale a più circuiti, ma a scopo di segmentazione, spesso non è ideale perché consente alle reti virtuali non connesse tra loro di comunicare.

Un metodo di segmentazione prevede la scelta di non usare un gateway remoto nelle reti virtuali spoke o la disabilitazione della propagazione della route BGP se si usano tabelle di route. È comunque possibile segmentare gli hub connessi a ExpressRoute con appliance virtuali di rete e firewall. Per gli spoke con peering agli hub, è possibile scegliere di non usare il gateway remoto nelle proprietà di peering reti virtuali. In questo modo, gli spoke apprendono solo gli hub connessi direttamente e non le route locali.

Un altro approccio emergente per segmentare il traffico da e verso l'ambiente locale è l'uso di tecnologie SD-WAN. È possibile estendere le posizioni dei rami in Azure SD-WAN usando appliance virtuali di rete di terze parti in Azure per creare la segmentazione basata su tunnel SD-WAN provenienti da rami diversi all'interno delle appliance appliance di appliance di rete. È possibile usare il server di route di Azure per inserire i prefissi degli indirizzi per i tunnel SD-WAN nella piattaforma Azure per una topologia hub-spoke.

Per una topologia WAN virtuale, è possibile avere l'integrazione diretta dell'appliance virtuale di rete SD-WAN di terze parti all'interno dell'hub virtuale. È anche possibile usare gli endpoint BGP per consentire l'uso di soluzioni SD-WAN, creando tunnel dall'appliance virtuale di rete integrata nell'hub virtuale.

Per entrambi i modelli, è possibile usare ExpressRoute per segmentare la connettività privata o pubblica sottostante con peering privato o peering Microsoft. Per la sicurezza, una pratica comune consiste nell'annunciare una route predefinita tramite ExpressRoute. In questo modo tutto il traffico che lascia la rete virtuale deve essere sottoposto a tunneling nella rete locale per l'ispezione. Analogamente, il traffico proveniente sia dalla VPN che da ExpressRoute può essere inviato a un'appliance virtuale di rete per un'ulteriore ispezione. Questo vale anche per il traffico che lascia Azure. Questi metodi sono semplici quando l'ambiente è più piccolo, ad esempio una o due aree.

Per reti distribuite di grandi dimensioni, è anche possibile usare Azure rete WAN virtuale attivando l'ispezione del traffico privato usando la finalità di routing. Questo indirizza tutto il traffico destinato a un indirizzo IP privato dell'appliance virtuale di rete per l'ispezione. Come con i metodi precedenti, questa operazione è molto più semplice da gestire quando l'ambiente si estende su più aree.

L'altro approccio con Azure rete WAN virtuale consiste nell'usare tabelle di route personalizzate per i limiti di isolamento. È possibile creare route personalizzate e associare e propagare solo le reti virtuali desiderate alle tabelle di route. Tuttavia, questa funzionalità non può essere combinata con la finalità di routing oggi. Per isolare i rami, è possibile assegnare etichette per associare rami a tale etichetta. È anche possibile disabilitare la propagazione dell'etichetta predefinita in base all'hub. Attualmente, non è possibile isolare singoli rami in Azure separatamente in un singolo hub. Ad esempio, non è possibile isolare SD-WAN da ExpressRoute. Ma in un intero hub è possibile disabilitare la propagazione nell'etichetta predefinita.

Limiti ai servizi globali di Azure

In Azure la maggior parte dei servizi è accessibile per impostazione predefinita tramite la rete WAN globale di Azure. Questo vale anche per l'accesso pubblico ai servizi PaaS di Azure. Ad esempio, Archiviazione di Azure dispone di un firewall predefinito che può limitare l'accesso alle reti virtuali e bloccare l'accesso pubblico. Tuttavia, spesso è necessario un controllo più granulare. La preferenza tipica consiste nel connettersi privatamente agli indirizzi VIP di Azure, anziché usare gli indirizzi IP pubblici predefiniti forniti.

Il metodo più comune per limitare l'accesso alle risorse PaaS è tramite collegamento privato di Azure. Quando si crea un endpoint privato, viene inserito nella rete virtuale. Azure usa questo indirizzo IP privato per eseguire il tunneling della risorsa PaaS in questione. Azure esegue il mapping di un record DNS A all'endpoint privato usando le zone di azure DNS privato ed esegue il mapping di un record CNAME alla risorsa PaaS di collegamento privato.

Gli endpoint di servizio offrono un metodo alternativo per la connessione a indirizzi VIP PaaS. È possibile selezionare i tag del servizio per consentire le connessioni a tutte le risorse PaaS all'interno di tale tag e fornire connettività privata alla risorsa PaaS.

Un altro metodo prevalente prevede l'uso del peering Microsoft per ExpressRoute. Se si vuole connettersi a indirizzi VIP PaaS dall'ambiente locale, è possibile configurare il peering Microsoft. È possibile scegliere la community BGP per gli indirizzi VIP da utilizzare e questo viene annunciato tramite il percorso di peering Microsoft.

Per altre informazioni, vedere le linee guida seguenti:

Riepilogo della segmentazione

Questa tabella riepiloga i diversi livelli di segmentazione e metodi di sicurezza.

tra	Comportamento predefinito	Comunicazione abilitata da...	Metodi di sicurezza di segmentazione
Sottoscrizioni	Nessuna comunicazione	- Peering reti virtuali - Gateway VPN	Firewall di Azure
Reti virtuali	Nessuna comunicazione	- Peering reti virtuali - Gateway VPN	Firewall di Azure
Carichi di lavoro nelle subnet all'interno di una rete virtuale	Comunicazione aperta	N/D	- Gruppi di sicurezza di rete - Gruppi di sicurezza delle applicazioni
Internet e una rete virtuale	Nessuna comunicazione	- Bilanciamento del carico - IP pubblico - gateway applicazione - Frontdoor di Azure	- gateway di app Azure lication con un web application firewall - Firewall di Azure - Frontdoor di Azure con web application firewall
Internet e le reti locali	Nessuna comunicazione	- VPN da sito a sito di Azure - Tunnel IPSec - Tunnel ExpressRoute - Tunnel SD-WAN	Firewall di Azure
Internet e macchine virtuali in una rete virtuale	Nessuna comunicazione se le macchine virtuali hanno solo indirizzi IP privati	Assegnazione della macchina virtuale a un indirizzo IP pubblico	Firewall della macchina virtuale locale

Formazione consigliata

Passaggi successivi

Per altre informazioni sull'applicazione di Zero Trust alla rete di Azure, vedere:

Riferimenti

Fare riferimento a questi collegamenti per informazioni sui vari servizi e tecnologie menzionati in questo articolo.

Condividi tramite