Share via

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

  • Articolo

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 il footprint del cloud.

Azure rete WAN virtuale consente un'architettura di rete di transito globale abilitando la connettività onnipresente e any-to-any tra set di carichi di lavoro cloud distribuiti a livello globale in reti virtuali (VNet), siti di succursali, 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:

Principio zero trust Definizione Met by
Verificare esplicita Eseguire sempre l'autenticazione e l'autorizzazione in base a tutti i punti dati disponibili. Usare Firewall di Azure con l'ispezione TLS (Transport Layer Security) per verificare i rischi e le minacce in base a tutti i dati disponibili. I controlli di accesso condizionale sono progettati per fornire l'autenticazione e l'autorizzazione da punti dati diversi e il Firewall di Azure non esegue l'autenticazione utente.
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. L'accesso degli utenti esula dall'ambito delle distribuzioni dell'infrastruttura di rete di Azure. L'uso di soluzioni di base delle identità come Privileged Access Management, accesso condizionale e altri controlli è il modo per realizzare questo principio.
Presunzione di violazione Ridurre al minimo il raggio di esplosione e l'accesso segmento. Verificare la crittografia end-to-end e usare l'analisi per ottenere visibilità, guidare il rilevamento delle minacce e migliorare le difese. Ogni rete virtuale spoke non ha accesso ad altre reti virtuali spoke, a meno che il traffico non venga instradato attraverso il firewall integrato all'interno di ogni hub di Azure rete WAN virtuale. Il firewall è impostato su Nega per impostazione predefinita, consentendo solo il traffico consentito dalle regole specificate. In caso di compromissione o violazione di un'applicazione o di un carico di lavoro, la distribuzione è limitata a causa del Firewall di Azure l'esecuzione dell'ispezione del traffico e l'inoltro solo del traffico consentito. Solo le risorse nello stesso carico di lavoro vengono esposte alla violazione nella stessa applicazione.

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 "bump-in-the-wire" di sicurezza tramite Firewall di Azure o 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 Firewall di Azure o NGFW (Next Generation Firewall) NGFW supportati all'interno di ogni hub rete WAN virtuale.
  • 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 dell'applicazione nelle reti spoke, insieme a una strategia di micro-perimetrali 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.

Diagramma dell'architettura di riferimento per Desktop virtuale Azure.

Azure rete WAN virtuale è distribuibile nei tipi Basic e Standard. L'applicazione di principi Zero Trust per Azure rete WAN virtuale con Firewall di Azure 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 Firewall di Azure.
  • Vpn da punto a sito (da punto a sito) e da sito a sito (S2S) e gateway ExpressRoute.
  • Rami collegati da P2S, S2S e ExpressRoute.
  • Una rete virtuale di servizi condivisi contenente risorse di infrastruttura di base che non possono essere distribuite in un hub di rete WAN virtuale, ad esempio macchine virtuali DNS personalizzate o resolver privato DNS di Azure, controller di dominio Dominio di Active Directory Services [AD DS] , Azure Bastion e altre risorse condivise.
  • Reti virtuali del carico di lavoro con gateway di app Azure lication, Web application firewall (WAF) di Azure e 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 nell'spoke servizi condivisi di rete virtuale nell'architettura di riferimento è solo un esempio di ciò che è possibile distribuire. Microsoft gestisce gli hub rete WAN virtuale di Azure e non è possibile installare altri elementi all'interno di essi, ad eccezione dei Firewall di Azure e delle appliance virtuali di rete supportate consentite in modo esplicito.

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

Sicurezza del routing

La protezione della propagazione della route e l'isolamento dell'ambiente locale è un elemento di sicurezza critico che deve essere gestito.

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 è 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 si usa Azure per trasportare il traffico tra le posizioni locali, ad esempio con tecnologie come Copertura globale di ExpressRoute, un prefisso locale annunciato da Azure indicherà 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 ad Azure a meno che non sia stato configurato il multi-percorso eBGP.

Architettura logica

Azure rete WAN virtuale è una raccolta di hub e servizi resi disponibili all'interno di un hub. È possibile distribuire tutti i rete WAN virtuale necessari. 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.

Diagramma dei componenti della topologia di Azure rete WAN virtuale e delle sottoscrizioni di Azure.

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 criteri di ereditarietà e gerarchia Firewall di Azure, i criteri padre e i criteri figlio devono trovarsi nella stessa area. È 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.

Passaggio Attività Principi zero trust applicati
1 Creare i criteri di Firewall di Azure. Verificare in modo esplicito
Presunzione di violazione
2 Convertire gli hub rete WAN virtuale di Azure in hub protetti. Verificare in modo esplicito
Presunzione di violazione
3 Proteggere il traffico. Verificare in modo esplicito
Presunzione di violazione
4 Proteggere le reti virtuali spoke. Presunzione di violazione
5 Esaminare l'uso della crittografia. Presunzione di violazione
6 Proteggere gli utenti P2S. Presunzione di violazione
7 Configurare il monitoraggio, il controllo e la gestione. Presunzione di violazione

È 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 Firewall di Azure in un'architettura hub-spoke classica, è necessario creare almeno un criterio di Azure in Firewall di Azure Manager e associato agli hub di Azure rete WAN virtuale. 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.

Firewall di Azure criteri 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 criteri figlio per implementare regole specifiche dell'hub tramite 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:

  • Proxy DNS: è necessario configurare Firewall di Azure come server DNS personalizzato per le reti virtuali spoke che proteggono il DNS reale che risiede in uno spoke di servizio condiviso o in locale. 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 punta all'indirizzo IP interno del Firewall di Azure nell'hub rete WAN virtuale. Non è consigliabile concedere l'accesso alla rete da spoke e rami 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 a Internet.

    • Ispezione TLS east-west per includere il traffico che passa da o verso rami locali e tra rete WAN virtuale spoke, che protegge i carichi di lavoro di Azure 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 per le minacce deve essere abilitata 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, è consigliabile usare la più restrittiva "Destination" e "Destination Type".

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

Al centro dell'approccio Zero Trust per Azure rete WAN virtuale è il concetto di hub protetto rete WAN virtuale (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.

È consigliabile Firewall di Azure Premium per Zero Trust e configurarlo con i criteri Premium descritti nel passaggio 1.

Nota

L'utilizzo della protezione DDoS non è supportato con un hub sicuro.

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.

Esempio dei criteri di routing Firewall di Azure.

Quando il criterio di routing "Traffico privato" è abilitato, il traffico della rete virtuale all'interno e all'esterno dell'hub rete WAN virtuale, incluso il traffico tra hub, viene inoltrato all'hop successivo Firewall di Azure o all'appliance virtuale di rete specificata nei criteri. Gli utenti con privilegi di Controllo di accesso controllo degli accessi in base al ruolo (RBAC) possono eseguire l'override della programmazione rete WAN virtuale route 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 di controllo degli accessi in base al ruolo per assegnare route definite dall'utente alle subnet della rete virtuale spoke devono essere limitate agli amministratori di rete centrale e non delegate ai proprietari della zona di destinazione delle reti virtuali spoke. Per associare una route definita dall'utente a una rete virtuale o a una subnet, un utente deve avere il ruolo Collaboratore rete o un ruolo personalizzato con l'azione o l'autorizzazione "Microsoft.Network/routeTables/join/action".

Nota

In questo articolo, Firewall di Azure viene considerato principalmente per il traffico Internet e il controllo del traffico privato. Per il traffico Internet, un'appliance virtuale di rete di sicurezza supportata di terze parti può essere usata o un provider security as a Service (edizione Standard CaaS) di terze parti. Per il traffico privato, le appliance virtuali di rete di sicurezza supportate da terze parti possono essere usate come alternativa a Firewall di Azure.

Nota

Le tabelle di route personalizzate in Azure rete WAN virtuale non possono essere usate in combinazione con finalità e criteri di routing e non devono essere considerate come un'opzione di sicurezza.

Passaggio 4: Proteggere le reti virtuali spoke

Ogni hub di Azure rete WAN virtuale può avere una o più reti virtuali connesse con il peering reti virtuali. 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. Azure rete WAN virtuale gestisce la connessione, la propagazione e l'associazione della route e il routing in uscita e in ingresso, ma non può influire sulla sicurezza 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:

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.
  • Sistema di risoluzione di azure DNS privato: la distribuzione di un sistema di risoluzione di azure DNS privato è supportata all'interno di una delle reti virtuali spoke connesse agli hub rete WAN virtuale. 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 rete WAN virtuale, ma deve essere distribuito all'interno di una rete virtuale 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. DNS privato zone non possono essere collegate agli hub di rete WAN virtuale. 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:

  • rete WAN virtuale gateway VPN da sito a sito fornisce la crittografia quando si usa Connessione VPN IPsec/IKE (IKEv1 e IKEv2).

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

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

    • 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. La finalità e i criteri 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.

Nota

rete WAN virtuale spoke non supporta la crittografia da rete virtuale a rete virtuale tramite Azure Gateway VPN perché è necessario usare rete WAN virtuale gateway remoto dell'hub.

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 tocco con rete WAN virtuale è nel metodo di autenticazione usato per consentire una VPN da punto a sito dell'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 Multi-Factor Authentication (MFA) e l'accesso condizionale applica principi Zero Trust ai dispositivi client e alle identità utente.

Nota

L'autenticazione Di Microsoft Entra è disponibile solo per i gateway che usano il protocollo OpenVPN, supportato solo per le connessioni al protocollo OpenVPN e richiede il client VPN di Azure.

Azure rete WAN virtuale 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 gruppi di utenti diversi di pool 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 altre informazioni, vedere Configurare gruppi di utenti e pool di indirizzi IP per VPN utente da sito a sito.

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 della 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 uguali a Firewall di Azure all'esterno di 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:

  • Firewall di Azure Analisi criteri fornisce informazioni dettagliate, visibilità centralizzata e controllo per 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 sulle "potenziali origini dannose" generate dalle funzionalità IDPS e Intelligence per le minacce del motore del firewall.

  • Firewall di Azure Workbook fornisce un'area di disegno flessibile per l'analisi dei dati 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 predefinito in 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 rete WAN (Wide Area Network) usando i servizi di rete di Azure rete WAN virtuale software-defined.

Inizio >

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.

Inizio >

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.

Inizio >

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.

Inizio >

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:

Riferimenti

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

Rete WAN virtuale di Azure

Baseline di sicurezza

Revisione di Well-Architected Framework

Sicurezza di Azure

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.