Applicare principi Zero Trust a una distribuzione della rete WAN virtuale di Azure

Con il cloud moderno, i dispositivi mobili e l'evoluzione di altri endpoint, l'affidamento solo su firewall aziendali e reti perimetrali non è più sufficiente. Una strategia end-to-end Zero Trust presuppone che le violazioni della sicurezza siano inevitabili. Ciò significa che è necessario verificare ogni richiesta come se provenisse da una rete incontrollata. La rete svolge ancora un ruolo importante in Zero Trust per connettere e proteggere l'infrastruttura, le applicazioni e i dati. 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 la tua impronta nel cloud.

Azure Virtual WAN consente un'architettura di rete di transito globale abilitando la connettività onnipresente e punto-a-punto tra set di carichi di lavoro cloud distribuiti a livello globale in reti virtuali (VNet), filiali, applicazioni SaaS e PaaS e utenti. L'adozione di un approccio Zero Trust in Azure rete WAN virtuale è fondamentale per garantire che il backbone sia sicuro e protetto.

Questo articolo illustra i passaggi per applicare i principi di Zero Trust a una distribuzione di Azure rete WAN virtuale nei modi seguenti:

Per altre informazioni su come applicare i principi di Zero Trust in un ambiente IaaS di Azure, vedere La panoramica sull'applicazione dei principi Zero Trust all'infrastruttura di Azure.

Per una discussione del settore su Zero Trust, vedere Pubblicazione speciale NIST 800-207.

Rete WAN virtuale di Azure

La rete WAN virtuale di Azure è un servizio che raggruppa numerose funzionalità di rete, sicurezza e routing per offrire una singola interfaccia operativa. Alcune delle funzionalità principali includono:

• Funzionalità di routing avanzate
• Integrazione di sicurezza "bump-in-the-wire" tramite Azure Firewall o le appliance virtuali di rete supportate nell'hub
• ExpressRoute crittografato

Un approccio Zero Trust per Azure rete WAN virtuale richiede la configurazione di diversi servizi e componenti sottostanti della tabella dei principi Zero Trust elencata in precedenza. Ecco un elenco di passaggi e azioni:

• Distribuire Azure Firewall o firewall di nuova generazione (NGFW) supportati all'interno di ogni hub Virtual WAN.
• Configurare il routing tra reti virtuali e succursali locali per creare un ambiente Zero Trust inviando tutto il traffico alle appliance di sicurezza negli hub per l'ispezione. Configurare il routing per fornire filtri e protezione per le minacce note.
• Assicurarsi che nessuna risorsa negli spoke abbia accesso diretto a Internet.
• Fornire micro-segmentazione delle applicazioni nelle reti spoke, insieme a una strategia di micro-perimetri in ingresso/uscita.
• Fornire l'osservabilità per gli eventi di sicurezza di rete.

Architettura di riferimento

Il diagramma seguente illustra un'architettura di riferimento comune che illustra un ambiente distribuito comunemente e come applicare i principi di Zero Trust ad Azure rete WAN virtuale.

Azure rete WAN virtuale è distribuibile nei tipi Basic e Standard. L'applicazione dei principi Zero Trust per Azure Virtual WAN con Azure Firewall o un NGFW richiede il tipo Standard.

L'architettura di riferimento di Azure rete WAN virtuale con hub protetti include:

• Una singola rete WAN virtuale logica.
• Due hub virtuali protetti, uno per area.
• Istanza di Firewall di Azure Premium distribuita in ogni hub.
• Almeno un criterio Premium di Firewall di Azure.
• VPN da punto a sito (P2S) e da sito a sito (S2S) e gateway ExpressRoute.
• Sedi collegate tramite P2S, S2S e ExpressRoute.
• Una rete virtuale di servizi condivisi contenente risorse di infrastruttura di base che non possono essere distribuite in un hub Virtual WAN, come macchine virtuali DNS personalizzate o Azure DNS Private Resolver, controller di dominio di Active Directory Domain Services [AD DS], Azure Bastion e altre risorse condivise.
• Reti virtuali (VNets) per il carico di lavoro con il gateway applicazione Azure, il Web Application Firewall (WAF) di Azure, e gli endpoint privati, se necessario.

Azure rete WAN virtuale supporta l'integrazione di un set limitato di firewall di terze parti all'interno degli hub come alternativa alla Firewall di Azure nativa. Questo articolo descrive solo Firewall di Azure. Ciò che è incluso nello spoke VNet-Shared Services nell'architettura di riferimento è solo un esempio di ciò che è possibile distribuire. Microsoft gestisce gli hub di Azure Virtual WAN e non è possibile installare altri elementi all'interno di essi, tranne quanto consentito esplicitamente dal Firewall di Azure e le NVAs supportate.

Questa architettura di riferimento è allineata ai principi architettonici descritti nell'articolo "Cloud Adoption Framework" per la topologia di rete WAN virtuale.

Sicurezza del routing

La protezione della propagazione delle rotte e l'isolamento dell'ambiente on-premise sono elementi critici di sicurezza che devono essere gestiti.

Oltre alla segmentazione del traffico, la sicurezza del routing è una parte fondamentale di qualsiasi progettazione della sicurezza di rete. I protocolli di routing sono parte integrante della maggior parte delle reti, tra cui Azure. È necessario proteggere l'infrastruttura dai rischi intrinseci per il routing di protocolli, ad esempio errori di configurazione o attacchi dannosi. Il protocollo BGP usato per VPN o ExpressRoute offre possibilità molto avanzate di proteggere la rete da modifiche indesiderate al routing, che potrebbero includere l'annuncio di route troppo specifiche o route troppo ampie.

Il modo migliore per proteggere la rete consiste nel configurare i dispositivi locali con i criteri di route e le mappe di route appropriati per assicurarsi che solo i prefissi consentiti vengano propagati nella rete da Azure. È ad esempio possibile:

• Bloccare i prefissi in ingresso troppo generici.

  Se a causa di una configurazione errata di Azure inizia a inviare prefissi generici, ad esempio 0.0.0.0/0 o 10.0.0.0/8, potrebbe attirare traffico che altrimenti potrebbe rimanere nella rete locale.

• Bloccare i prefissi in ingresso troppo specifici.

  In determinate circostanze è possibile ottenere alcuni prefissi IPv4 lunghi da Azure (lunghezza del prefisso di rete da 30 a 32), che in genere sono inclusi in altri prefissi meno specifici e pertanto non necessari. L'eliminazione di questi prefissi impedisce alle tabelle di routing locali di aumentare inutilmente le dimensioni.

• Bloccare i prefissi in ingresso che non si trovano in Azure a meno che non si usi Azure come rete di transito.

  Se non stai utilizzando Azure per trasportare il traffico tra le tue sedi locali, ad esempio con tecnologie come ExpressRoute Global Reach, un prefisso locale annunciato da Azure indicherebbe un ciclo di routing. Solo l'acquisizione di prefissi di Azure nei router locali proteggerebbe l'utente da questi tipi di cicli di routing.

• Bloccare i prefissi in uscita che non sono locali.

  Se non si usa la rete locale per il transito tra aree di Azure, non è consigliabile pubblicizzare in Azure alcun prefisso che non si usa in locale. In caso contrario, si rischia di creare cicli di routing, in particolare considerando il fatto che le implementazioni eBGP nella maggior parte dei router pubblicizzano nuovamente tutti i prefissi su collegamenti non preferiti. Questo ha l'effetto di inviare i prefissi di Azure verso Azure, a meno che non sia stato configurato il multi-path eBGP.

Architettura logica

Azure rete WAN virtuale è una raccolta di hub e servizi resi disponibili all'interno di un hub. È possibile distribuire quante reti WAN virtuali sono necessarie. In un hub rete WAN virtuale sono disponibili più servizi, ad esempio VPN, ExpressRoute, Firewall di Azure o un'appliance virtuale di rete integrata di terze parti.

Il diagramma seguente illustra l'architettura logica dell'infrastruttura di Azure per una distribuzione di Azure rete WAN virtuale, come illustrato in Cloud Adoption Framework.

La maggior parte delle risorse è contenuta all'interno della sottoscrizione di connettività. Tutte le risorse rete WAN virtuale vengono distribuite in un singolo gruppo di risorse nella sottoscrizione di connettività, incluso quando si esegue la distribuzione in più aree. Gli spoke di rete virtuale di Azure si trovano nelle sottoscrizioni della zona di destinazione. Se si usano i criteri di ereditarietà e gerarchia della policy Firewall di Azure, la policy padre e la policy figlio devono trovarsi nella stessa regione. È comunque possibile applicare un criterio creato in un'area in un hub protetto da un'altra area.

Che cos'è in questo articolo?

Questo articolo illustra i passaggi per applicare i principi di Zero Trust nell'architettura di riferimento di Azure rete WAN virtuale.

È necessario eseguire i passaggi 1 e 2 nell'ordine. Gli altri passaggi possono essere eseguiti in qualsiasi ordine.

Passaggio 1: Creare criteri di Firewall di Azure

Per le distribuzioni autonome di Azure Firewall in un'architettura hub-spoke classica, è necessario creare almeno un criterio di sicurezza di Azure in Gestione firewall di Azure e associarlo agli hub di Azure Virtual WAN. Questo criterio deve essere creato e reso disponibile prima della conversione di qualsiasi hub. Dopo aver definito il criterio, viene applicato alle istanze di Firewall di Azure nel passaggio 2.

I criteri del Firewall di Azure possono essere disposti in una gerarchia padre-figlio. Per uno scenario hub-spoke classico o un rete WAN virtuale di Azure gestito, è necessario definire un criterio radice con un set comune di regole di sicurezza a livello IT per consentire o negare il traffico. Quindi, per ogni hub, è possibile definire un criterio figlio per implementare regole specifiche dell'hub attraverso l'ereditarietà. Questo passaggio è facoltativo. Se le regole che devono essere applicate a ogni hub sono identiche, è possibile applicare un singolo criterio.

Per Zero Trust, è necessario un criterio di Firewall di Azure Premium e deve includere le impostazioni seguenti:

• DNS Proxy – È necessario configurare il firewall di Azure come server DNS personalizzato per le reti virtuali spoke, per proteggere il DNS effettivo che risiede in uno spoke di servizio condiviso o in sede. I firewall di Azure fungono da proxy DNS, sono in ascolto sulla porta UDP 53 e inoltrano le richieste DNS ai server DNS specificati nelle impostazioni dei criteri. Per ogni spoke, è necessario configurare un server DNS a livello di rete virtuale che indirizza all'indirizzo IP interno del Firewall di Azure nell'hub WAN Virtuale. Non è consigliabile fornire l'accesso alla rete dagli spoke e dalle filiali al DNS personalizzato.

• L'ispezione TLS deve essere abilitata per questi scenari:

  • Ispezione TLS in uscita per proteggere da traffico dannoso inviato da un client interno ospitato in Azure verso Internet.

  • Ispezione TLS East-West per includere il traffico che passa da o verso le sedi locali e tra gli spoke del WAN virtuale. In questo modo i carichi di lavoro di Azure vengono protetti da potenziali traffico dannoso inviato dall'interno di Azure.

• Il sistema di rilevamento e prevenzione delle intrusioni (IDPS) deve essere abilitato in modalità "Avviso e Negazione".

• Intelligence sulle minacce deve essere attivata in modalità "Avviso e negazione".

Come parte della creazione dei criteri, è necessario creare le regole DNAT (Destination Network Address Translation) necessarie, le regole di rete e le regole dell'applicazione per abilitare solo i flussi di rete per il traffico consentito in modo esplicito. Per abilitare l'ispezione TLS per le destinazioni selezionate, la regola dell'applicazione corrispondente deve avere l'impostazione "Ispezione TLS" abilitata. Quando si creano regole nelle raccolte regole, si dovrebbe usare il "Destinazione" e il "Tipo di Destinazione" più restrittivi.

Passaggio 2: Convertire gli hub di Azure rete WAN virtuale in hub protetti

Al centro dell'approccio Zero Trust per Azure WAN Virtuale è il concetto di hub WAN Virtuale protetto (hub sicuro). Un hub sicuro è un hub rete WAN virtuale di Azure con un Firewall di Azure integrato. L'uso di appliance di sicurezza supportate da terze parti è supportato come alternativa a Firewall di Azure, ma non è descritto in questo articolo. È possibile usare queste appliance virtuali per controllare tutto il traffico a nord-sud, est-ovest e a Internet.

Si consiglia di utilizzare Azure Firewall Premium per Zero Trust e di configurarlo con il criterio Premium descritto nel passaggio 1.

Per altre informazioni, vedere Installare Firewall di Azure in un hub di rete WAN virtuale.

Passaggio 3: Proteggere il traffico

Dopo aver aggiornato tutti gli hub di Azure rete WAN virtuale per proteggere gli hub, è necessario configurare finalità e criteri di routing per i principi Zero Trust. Questa configurazione consente al Firewall di Azure in ogni hub di attirare e controllare il traffico tra spoke e rami nello stesso hub e tra hub remoti. È consigliabile configurare i criteri per inviare sia il "traffico Internet" che il "Traffico privato" tramite il Firewall di Azure o l'appliance virtuale di rete di terze parti). È necessario abilitare anche l'opzione "Inter-hub". Ecco un esempio.

Quando il criterio di routing "Traffico privato" è abilitato, il traffico della rete virtuale in entrata e in uscita dalla WAN virtuale, incluso il traffico inter-hub, viene inoltrato all'hop successivo specificato nei criteri, il Firewall di Azure o l'NVA. Gli utenti con privilegi di Controllo dell'accesso in base al ruolo (RBAC) possono eseguire l'override della programmazione delle rotte della WAN virtuale per le reti virtuali spoke e associare una route definita dall'utente personalizzata per ignorare il firewall dell'hub. Per evitare questa vulnerabilità, le autorizzazioni RBAC per l'assegnazione delle UDR alle subnet delle reti virtuali spoke devono essere limitate agli amministratori centrali di rete e non delegate ai proprietari delle zone di destinazione delle reti virtuali spoke. Per associare una UDR a una rete virtuale o a una subnet, un utente deve avere il ruolo di Collaboratore di rete o un ruolo personalizzato con l'azione e l'autorizzazione "Microsoft.Network/routeTables/join/action".

Passaggio 4: Proteggere le reti virtuali spoke

Ogni hub di Azure Virtual WAN può avere una o più reti virtuali collegate tramite il peering VNet. In base al modello di zona di destinazione in Cloud Adoption Framework, ogni rete virtuale contiene un carico di lavoro, applicazioni e servizi di destinazione che supportano un'organizzazione. Rete WAN Virtuale di Azure gestisce la connessione, la propagazione e l'associazione dell'instradamento e il routing in uscita e in ingresso, ma non può influire sulla sicurezza intra-VNet all'interno della rete virtuale. I principi Zero Trust devono essere applicati all'interno di ogni rete virtuale spoke in base alle indicazioni pubblicate in Applicare i principi Zero Trust a una rete virtuale spoke e ad altri articoli a seconda del tipo di risorsa, ad esempio macchine virtuali e archiviazione. Considerare gli elementi seguenti:

• Micro-segmentazione: anche se Azure rete WAN virtuale attira e filtra il traffico in uscita, è comunque consigliabile usare gruppi di sicurezza di rete (NSG) e gruppi di sicurezza delle applicazioni (ASG) per regolare i flussi all'interno della rete virtuale.

• Rete perimetrale locale: una regola DNAT creata nel firewall centrale all'interno dell'hub rete WAN virtuale di Azure deve filtrare e consentire il traffico non HTTP o HTTPS in ingresso. Il traffico HTTP o HTTPS in ingresso deve essere gestito da un Azure Application Gateway locale e da un firewall per applicazioni web associato.

  Sebbene gli hub virtuali sicuri di Azure Virtual WAN non supportino ancora la Protezione DDoS di Azure, l'uso della protezione DDoS per proteggere gli endpoint con connessione Internet nelle reti virtuali di collegamento è possibile e altamente consigliato. Per altre informazioni, vedere Problemi noti di Gestione firewall di Azure e Confronto tra rete virtuale hub e hub virtuale protetto.

• Rilevamento e protezione avanzata delle minacce: consulta Applicare i principi di Zero Trust a una rete spoke virtuale. Gli elementi all'interno dello spoke devono essere protetti con strumenti di protezione contro le minacce come Microsoft Defender per Cloud.

Poiché l'hub in Azure rete WAN virtuale è bloccato e gestito da Azure, i componenti personalizzati non possono essere installati o abilitati. Alcune risorse normalmente distribuite all'interno dell'hub, in un modello hub e spoke classico, devono essere inserite in uno o più spoke che fungono da reti di risorse condivise. Ad esempio:

• Azure Bastion:Azure Bastion supporta azure rete WAN virtuale, ma deve essere distribuito all'interno di una rete virtuale spoke perché l'hub è limitato e gestito da Azure. Da Azure Bastion spoke gli utenti possono raggiungere le risorse in altre reti virtuali, ma richiede una connessione basata su IP disponibile con lo SKU Standard di Azure Bastion.
• Server DNS personalizzati: il software server DNS può essere installato in qualsiasi macchina virtuale e funge da server DNS per tutti gli spoke in Azure rete WAN virtuale. Il server DNS deve essere installato in una rete virtuale spoke che gestisce direttamente tutti gli altri spoke o tramite la funzionalità proxy DNS offerta dal Firewall di Azure integrato all'interno dell'hub rete WAN virtuale.
• Azure Private DNS Resolver: La distribuzione di un Azure Private DNS Resolver è supportata all'interno di una delle reti virtuali spoke connesse agli hub di Virtual WAN. Firewall di Azure integrato all'interno dell'hub rete WAN virtuale può usare questa risorsa come DNS personalizzato quando si abilita la funzionalità Proxy DNS.
• Endpoint privati: questo tipo di risorsa è compatibile con Virtual WAN, ma deve essere distribuita all'interno di una VNet spoke. In questo modo viene fornita la connettività a qualsiasi altra rete virtuale o ramo connesso alla stessa rete WAN virtuale, se il Firewall di Azure integrato consente il flusso. Le istruzioni su come proteggere il traffico verso endpoint privati usando il Firewall di Azure integrato all'interno di un hub rete WAN virtuale sono disponibili in Proteggere il traffico destinato agli endpoint privati in Azure rete WAN virtuale.
• Zona DNS privato di Azure (collegamenti): questo tipo di risorsa non si trova all'interno di una rete virtuale, ma deve essere collegato a essi per funzionare correttamente. Le zone DNS private non possono essere collegate agli hub di rete WAN virtuali. Devono invece essere connessi alla rete virtuale spoke contenente server DNS personalizzati o un sistema di risoluzione DNS privato di Azure (scelta consigliata) o direttamente alle reti virtuali spoke che richiedono i record DNS da tale zona.

Passaggio 5: Esaminare la crittografia

Azure rete WAN virtuale offre alcune funzionalità di crittografia del traffico attraverso i propri gateway per il traffico che entra nella rete Microsoft. Quando possibile, la crittografia deve essere abilitata, in base al tipo di gateway. Considerare il comportamento di crittografia predefinito seguente:

• Il gateway VPN da sito a sito della rete WAN virtuale fornisce la crittografia quando si utilizza una connessione VPN IPsec/IKE (IKEv1 e IKEv2).

• La rete WAN virtuale VPN gateway da punto a sito fornisce la crittografia quando si usa la connessione VPN per utenti tramite OpenVPN o IPsec/IKE (IKEv2).

• Il gateway della rete WAN virtuale ExpressRoute non fornisce la crittografia, pertanto si applicano le stesse valutazioni relative a ExpressRoute standalone.

  • Solo per i circuiti ExpressRoute di cui è stato effettuato il provisioning su ExpressRoute Direct, è possibile sfruttare la crittografia MACsec fornita dalla piattaforma per proteggere le connessioni tra i router perimetrali e i router perimetrali di Microsoft.

  • È possibile stabilire la crittografia usando una connessione VPN IPsec/IKE dalla rete locale ad Azure tramite il peering privato di un circuito Azure ExpressRoute. I criteri di routing e finalità di routing supportano ora questa configurazione con passaggi di configurazione aggiuntivi necessari, come illustrato in Encrypted ExpressRoute.

• Per i dispositivi WAN software-defined (SD-WAN) di terze parti e le appliance virtuali di rete integrate nell'hub rete WAN virtuale, è necessario verificare e configurare funzionalità di crittografia specifiche in base alla documentazione del fornitore.

Dopo che il traffico è entrato nell'infrastruttura di rete di Azure tramite uno dei gateway o un'appliance virtuale di rete SD-WAN/NVA, non esiste un servizio o una funzionalità di rete WAN virtuale specifica che fornisce la crittografia di rete. Se il traffico tra un hub e la relativa rete virtuale e hub-to-hub non è crittografato, è necessario usare la crittografia a livello di applicazione, se necessario.

Passaggio 6: Proteggere gli utenti P2S

La rete WAN virtuale di Azure è un servizio che raggruppa numerose funzionalità di rete, sicurezza e routing per offrire una singola interfaccia operativa. Dal punto di vista dell'identità utente, l'unico punto di contatto con Virtual WAN è nel metodo di autenticazione usato per consentire una P2S VPN utente. Sono disponibili diversi metodi di autenticazione, ma è consigliabile seguire i principi generali zero trust per l'autenticazione di Microsoft Entra. Con Microsoft Entra ID è possibile richiedere l'autenticazione a più fattori (MFA) e l'accesso condizionale per applicare i principi Zero Trust ai dispositivi client e alle identità utente.

Rete WAN virtuale di Azure e Firewall di Azure non forniscono il routing e il filtro del traffico in base ai nomi di account utente o di gruppo, ma è possibile assegnare diversi gruppi di utenti a pool diversi di indirizzi IP. È quindi possibile definire regole sul Firewall di Azure integrato per limitare utenti o gruppi in base al pool di indirizzi IP P2S assegnato.

Se si suddivideno gli utenti da punto a sito in gruppi diversi in base ai requisiti di accesso alla rete, è consigliabile distinguerli a livello di rete e assicurarsi che possano accedere solo a un subset della rete interna. È possibile creare più pool di indirizzi IP per Azure rete WAN virtuale. Per ulteriori informazioni, vedere Configurare gruppi di utenti e pool di indirizzi IP per le VPN P2S (Point-to-Site).

Passaggio 7: Configurare il monitoraggio, il controllo e la gestione

Azure rete WAN virtuale offre funzionalità complete di monitoraggio e diagnostica con Monitoraggio di Azure. È possibile ottenere dettagli e topologie aggiuntivi usando un dashboard di monitoraggio incentrato e predefinito nella portale di Azure denominata Informazioni dettagliate di Monitoraggio di Azure per rete WAN virtuale. Questi strumenti di monitoraggio non sono specifici per la sicurezza. Il Firewall di Azure distribuito all'interno di ogni hub rete WAN virtuale fornisce il punto di integrazione per il monitoraggio zero trust e della sicurezza. È necessario configurare diagnostica e registrazione per Firewall di Azure come per i Firewall di Azure all'esterno della rete WAN virtuale.

Firewall di Azure fornisce gli strumenti di monitoraggio seguenti da usare per garantire la sicurezza e l'applicazione corretta dei principi Zero Trust:

• Analisi criteri di Firewall di Azure fornisce approfondimenti, visibilità centralizzata e controllo su Firewall di Azure. La sicurezza richiede che siano presenti regole del firewall appropriate ed efficaci per proteggere l'infrastruttura interna. Il portale di Azure riepiloga i dettagli su "Potenziali origini dannose" generati dalle funzionalità IDPS e di Threat Intelligence della piattaforma del firewall.

• La cartella di lavoro di Firewall di Azure offre un'area di disegno flessibile per l'analisi dei dati di Firewall di Azure. È possibile ottenere informazioni dettagliate sugli eventi Firewall di Azure, ottenere informazioni sull'applicazione e sulle regole di rete e visualizzare le statistiche per le attività del firewall tra URL, porte e indirizzi. È consigliabile esaminare periodicamente le statistiche dei log IDPS e dalla scheda Indagini , controllare il traffico negato, i flussi di origine e di destinazione e il report intelligence sulle minacce per esaminare e ottimizzare le regole del firewall.

Firewall di Azure si integra anche con Microsoft Defender per il cloud e Microsoft Sentinel. È consigliabile configurare correttamente entrambi gli strumenti e usarli attivamente per Zero Trust nei modi seguenti:

• Con Microsoft Defender per il cloud integrazione, è possibile visualizzare lo stato completo dell'infrastruttura di rete e della sicurezza di rete in un'unica posizione, inclusa la sicurezza di rete di Azure in tutte le reti virtuali e gli hub virtuali distribuiti in aree diverse in Azure. Con un'unica occhiata, è possibile visualizzare il numero di Firewall di Azure, criteri firewall e aree di Azure in cui vengono distribuiti Firewall di Azure.
• Una soluzione di Microsoft Sentinel per un'integrazione Firewall di Azure facile offre il rilevamento e la prevenzione delle minacce. Dopo la distribuzione, la soluzione consente il rilevamento delle minacce personalizzabile su Microsoft Sentinel. La soluzione include anche una cartella di lavoro, rilevamenti, query di ricerca e playbook.

Formazione per gli amministratori

I moduli di formazione seguenti aiutano il team con le competenze necessarie per applicare i principi Zero Trust alla distribuzione di Azure rete WAN virtuale.

Introduzione alla rete WAN virtuale di Azure

Formazione	Introduzione alla rete WAN virtuale di Azure
	Descrivere come costruire una Wide Area Network (WAN) utilizzando i servizi di rete Azure Virtual WAN software-defined.

Introduzione a Firewall di Azure

Formazione	Introduzione a Firewall di Azure
	Descrivere come Firewall di Azure protegge le risorse della rete virtuale di Azure, incluse le funzionalità di Firewall di Azure, le regole, le opzioni di distribuzione e l'amministrazione con Firewall di Azure Manager.

Introduzione a Gestione firewall di Azure

Formazione	Introduzione a Gestione firewall di Azure
	Descrivere se è possibile usare Gestione firewall di Azure per offrire funzionalità centralizzate di gestione dei criteri di sicurezza e delle route per i perimetri di sicurezza basati sul cloud. Valutare se Gestione firewall di Azure consente di proteggere i perimetri cloud.

Progettare e implementare la sicurezza di rete

Formazione	Progettare e implementare la sicurezza di rete
	Si apprenderà come progettare e implementare soluzioni di sicurezza di rete come DDoS di Azure, gruppi di sicurezza di rete, Firewall di Azure e Web application firewall.

Per altre informazioni sulla sicurezza in Azure, vedere queste risorse nel catalogo Microsoft:
Sicurezza in Azure

Passaggi successivi

Vedere questi articoli aggiuntivi per l'applicazione dei principi Zero Trust ad Azure:

• Panoramica di Azure IaaS
  • Archiviazione di Azure
  • Macchine virtuali
  • Reti virtuali spoke
  • Reti virtuali hub
• Desktop virtuale Azure
• Applicazioni IaaS in Amazon Web Services
• Microsoft Sentinel e Microsoft Defender XDR

Riferimenti

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

Rete WAN virtuale di Azure

• Panoramica di Azure rete WAN virtuale
• Come configurare i criteri di routing dell'hub rete WAN virtuale
• Installare Firewall di Azure in un hub di rete WAN virtuale
• Che cos'è un hub virtuale protetto?
• Come configurare i criteri di routing dell'hub rete WAN virtuale
• Esercitazione: Proteggere l'hub virtuale con Firewall di Azure Manager
• Esercitazione: Proteggere l'hub virtuale con Azure PowerShell
• Condividere un servizio di collegamento privato tra rete WAN virtuale
• Gestire l'accesso sicuro alle risorse nelle reti virtuali spoke per i client Point-to-Site

Baseline di sicurezza

• Firewall di Azure
• Gestione firewall di Azure

Revisione di Well-Architected Framework

• Firewall di Azure

Sicurezza di Azure

• Introduzione alla sicurezza di Azure
• Linee guida per l'implementazione zero trust
• Panoramica di Microsoft Cloud Security Benchmark
• Creazione del primo livello di difesa con i servizi di sicurezza di Azure
• Architetture di riferimento per la cybersecurity Microsoft

Illustrazioni tecniche

È possibile scaricare le illustrazioni usate in questo articolo. Utilizzare il file di Visio per modificare queste illustrazioni per un uso personalizzato.

PDF | Visio

Per altre illustrazioni tecniche, fare clic qui.