Applicare principi Zero Trust a una rete virtuale spoke in Azure
Riepilogo: per applicare principi Zero Trust a una rete virtuale spoke in Azure, è necessario sfruttare i Controllo di accesso basati sui ruoli, isolare subnet e macchine virtuali (gruppi di risorse, gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni), proteggere il traffico e le risorse all'interno delle applicazioni di rete virtuale e macchine virtuali e abilitare il rilevamento avanzato delle minacce, gli avvisi e la protezione.
Questo articolo illustra come applicare i principi di Zero Trust a una rete virtuale spoke (VNet) per i carichi di lavoro IaaS in Azure 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 i gruppi di sicurezza delle applicazioni per verificare che le singole schede di interfaccia di rete dispongano delle autorizzazioni per comunicare su canali specifici. |
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. | Non abilitare l'accesso 3389/RDP per impostazione predefinita in alcun canale. Usare le autorizzazioni corrette per il ruolo per il contesto spoke. |
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. | Limitare le comunicazioni non necessarie tra le risorse. Assicurarsi di poter accedere ai gruppi di sicurezza di rete e di avere una visibilità adeguata sul traffico anomalo. Tenere traccia delle modifiche apportate ai gruppi di sicurezza di rete. |
Questo articolo fa parte di una serie di articoli che illustrano come applicare i principi di Zero Trust in un ambiente in Azure che include una rete virtuale spoke che ospita un carico di lavoro basato su macchine virtuali. Per altre informazioni, vedere La panoramica sull'applicazione di principi Zero Trust ad Azure IaaS.
Il diagramma seguente illustra un'architettura di riferimento comune per i carichi di lavoro basati su IaaS.
Nel diagramma:
- Una rete virtuale spoke include componenti per supportare un'applicazione IaaS costituita da macchine virtuali.
- L'applicazione IaaS è un'applicazione a tre livelli costituita da due macchine virtuali per ogni livello: front-end, applicazione e dati.
- Ogni livello è contenuto all'interno di una subnet dedicata con un gruppo di sicurezza di rete dedicato.
- Ogni ruolo della macchina virtuale viene assegnato a un gruppo di sicurezza delle applicazioni corrispondente al relativo ruolo.
- L'accesso all'applicazione viene fornito tramite un gateway applicazione contenuto nella propria subnet.
L'applicazione illustrata nell'architettura di riferimento segue lo stile dell'architettura a più livelli
Il diagramma seguente illustra i componenti di un gruppo di risorse per una rete virtuale spoke in una sottoscrizione di Azure separata dalla sottoscrizione per la rete virtuale dell'hub.
Nel diagramma tutti i componenti della rete virtuale spoke sono contenuti in un gruppo di risorse dedicato:
- Una rete virtuale
- Un gateway di app Azure lication (GATEWAY app), incluso un web application firewall (WAF)
- Tre gruppi di sicurezza di rete, uno per ogni livello applicazione
- Tre gruppi di sicurezza delle applicazioni, uno per ogni livello applicazione
I principi Zero Trust vengono applicati nell'architettura, dal livello di tenant e directory fino all'assegnazione di macchine virtuali ai gruppi di sicurezza delle applicazioni. Nella tabella seguente vengono descritte le raccomandazioni per la protezione di questa architettura.
Passaggio | Attività | Principi zero trust applicati |
---|---|---|
1 | Usare il controllo degli accessi in base al ruolo (RBAC) di Microsoft Entra o configurare ruoli personalizzati per le risorse di rete. | Usare l'accesso con privilegi minimi |
2 | Isolare l'infrastruttura nel proprio gruppo di risorse. | Presunzione di violazione |
3 | Creare un gruppo di sicurezza di rete per ogni subnet. | Usare l'accesso con privilegi minimi Presunzione di violazione |
4 | Creare un gruppo di sicurezza delle applicazioni per ogni ruolo macchina virtuale. | Verificare in modo esplicito Usare l'accesso con privilegi minimi Presunzione di violazione |
5 | Proteggere il traffico e le risorse all'interno della rete virtuale: |
Verificare in modo esplicito Usare l'accesso con privilegi minimi Presunzione di violazione |
6 | Proteggere l'accesso alla rete virtuale e all'applicazione. | Usare l'accesso con privilegi minimi Presunzione di violazione |
7 | Abilitare il rilevamento avanzato delle minacce, gli avvisi e la protezione. | Presunzione di violazione |
Passaggio 1: Usare il controllo degli accessi in base al ruolo di Microsoft Entra o configurare ruoli personalizzati per le risorse di rete
È possibile usare i ruoli predefiniti controllo degli accessi in base al ruolo di Microsoft Entra per i collaboratori di rete. Tuttavia, un altro approccio consiste nell'usare ruoli personalizzati. I gestori di rete spoke non necessitano dell'accesso completo alle risorse di rete concesse dal ruolo Collaboratore alla rete RBAC di Microsoft Entra, ma necessitano di più autorizzazioni rispetto ad altri ruoli comuni. È possibile usare un ruolo personalizzato per definire l'ambito dell'accesso solo a ciò che è necessario.
Un modo semplice per implementare questo approccio consiste nel distribuire i ruoli personalizzati disponibili nell'architettura di riferimento della zona di destinazione di Azure.
Il ruolo specifico è il ruolo personalizzato Gestione rete con le autorizzazioni seguenti:
- Leggi tutto nell'ambito
- Eventuali azioni con il provider di rete
- Qualsiasi azione con il provider di supporto
- Eventuali azioni con il provider risorse
È possibile creare questo ruolo usando gli script per i ruoli personalizzati o tramite Microsoft Entra ID con il processo descritto in Ruoli personalizzati di Azure - Controllo degli accessi in base al ruolo di Azure.
Isolando le risorse di rete dalle risorse di calcolo, dati o archiviazione, si riduce la probabilità di esplodere le autorizzazioni. Inoltre, assicurandosi che tutte le risorse correlate si trovino in un unico gruppo di risorse, è possibile effettuare un'assegnazione di sicurezza e gestire meglio la registrazione e il monitoraggio per queste risorse.
Invece di disporre delle risorse di rete spoke disponibili in più contesti in un gruppo di risorse condivise, creare un gruppo di risorse dedicato. L'architettura di riferimento supportata da questo articolo illustra questo concetto.
Nella figura le risorse e i componenti nell'architettura di riferimento sono suddivisi in gruppi di risorse dedicati per macchine virtuali, account di archiviazione, risorse della rete virtuale hub e risorse della rete virtuale spoke.
Con un gruppo di risorse dedicato, è possibile assegnare un ruolo personalizzato usando il processo seguente: Esercitazione: Concedere a un utente l'accesso alle risorse di Azure usando il portale di Azure - Controllo degli accessi in base al ruolo di Azure.
Raccomandazioni aggiuntive:
- Fare riferimento a un gruppo di sicurezza per il ruolo invece di singoli utenti denominati.
- Gestire l'accesso al gruppo di sicurezza tramite i modelli di gestione delle identità aziendali.
Se non si usano criteri che applicano l'inoltro dei log nei gruppi di risorse, configurare questa opzione nel log attività per il gruppo di risorse: passare a Log attività Esporta log > attività e quindi selezionare + Aggiungi impostazione di diagnostica.
Nella schermata Impostazioni di diagnostica selezionare tutte le categorie di log (in particolare Sicurezza) e inviarle alle origini di registrazione appropriate, ad esempio un'area di lavoro Log Analytics per l'osservabilità o un account di archiviazione per l'archiviazione a lungo termine.
Anche se non direttamente correlato alla rete, è consigliabile pianificare il controllo degli accessi in base al ruolo della sottoscrizione in modo analogo. Oltre a isolare le risorse logicamente in base al gruppo di risorse, è necessario isolare anche la sottoscrizione in base alle aree aziendali e ai proprietari del portfolio. La sottoscrizione come unità di gestione deve essere limitata nell'ambito.
Per altre informazioni sulla democratizzazione delle sottoscrizioni, vedere Principi di progettazione della zona di destinazione di Azure - Cloud Adoption Framework.
La diagnostica viene configurata dalla categoria Sicurezza dell'impostazione diagnostica in Monitoraggio di Azure, come illustrato di seguito.
Per informazioni su come esaminare questi log e ricevere avvisi, vedere Impostazioni di diagnostica.
I gruppi di sicurezza di rete di Azure vengono usati per filtrare il traffico di rete tra le risorse di Azure in una rete virtuale di Azure. È consigliabile applicare un gruppo di sicurezza di rete a ogni subnet, che viene applicato tramite i criteri di Azure per impostazione predefinita durante la distribuzione delle zone di destinazione di Azure. Un gruppo di sicurezza di rete contiene regole di sicurezza che consentono o rifiutano il traffico di rete in ingresso o in uscita da diversi tipi di risorse di Azure. Per ogni regola, è possibile specificare origine e destinazione, porta e protocollo.
Per un'applicazione basata su macchine virtuali multilivello, è consigliabile creare un gruppo di sicurezza di rete dedicato (NSG) nella figura seguente, per ogni subnet che ospita un ruolo macchina virtuale.
Nel diagramma:
- Ogni livello dell'applicazione è ospitato in una subnet dedicata, ad esempio, il livello front-end, il livello app e il livello dati.
- Un gruppo di sicurezza di rete è configurato per ognuna di queste subnet.
La configurazione dei gruppi di sicurezza di rete in modo diverso rispetto a quanto illustrato nella figura può comportare una configurazione errata di alcuni o di tutti i gruppi di sicurezza di rete e può creare problemi nella risoluzione dei problemi. Può anche rendere difficile monitorare e registrare.
Creare un gruppo di sicurezza di rete usando questo processo: Creare, modificare o eliminare un gruppo di sicurezza di rete di Azure
Vedere Gruppi di sicurezza di rete per comprendere come usarli per proteggere l'ambiente.
I gruppi di sicurezza delle applicazioni consentono di configurare la sicurezza di rete come un'estensione naturale della struttura di un'applicazione, raggruppando le macchine virtuali e definendo i criteri di sicurezza di rete in base a tali gruppi. È possibile riusare i criteri di sicurezza su larga scala senza gestire manualmente indirizzi IP espliciti. La piattaforma gestisce la complessità degli indirizzi IP espliciti e di più set di regole, consentendo all'utente di concentrarsi sulla logica di business.
All'interno del carico di lavoro identificare i ruoli specifici della macchina virtuale. Compilare quindi un gruppo di sicurezza delle applicazioni per ogni ruolo. Nell'architettura di riferimento sono rappresentati tre gruppi di sicurezza delle applicazioni.
Nel diagramma:
- Vengono creati tre gruppi di sicurezza delle applicazioni per supportare questa app, una per ogni livello: front-end, app e dati.
- Ogni macchina virtuale viene assegnata al gruppo di sicurezza dell'applicazione corrispondente per il relativo ruolo (testo rosso nel diagramma).
Per altre informazioni sui gruppi di sicurezza delle applicazioni e su come assegnarli alle macchine virtuali, vedere Panoramica dei gruppi di sicurezza delle applicazioni di Azure.
Nota
Se si usano servizi di bilanciamento del carico, è necessario usare l'indirizzo IP del servizio di bilanciamento del carico nei gruppi di sicurezza di rete perché i gruppi di sicurezza delle applicazioni non possono definire l'ambito di un servizio di bilanciamento del carico.
Questa sezione illustra le raccomandazioni seguenti:
- Distribuire le regole di negazione della baseline per i gruppi di sicurezza di rete
- Distribuire regole specifiche dell'applicazione per i gruppi di sicurezza delle applicazioni
- Pianificare il traffico di gestione nella rete virtuale
- Distribuire la registrazione dei flussi dei gruppi di sicurezza di rete
Un elemento chiave di Zero Trust usa il livello minimo di accesso necessario. Per impostazione predefinita, i gruppi di sicurezza di rete hanno regole consentite. Aggiungendo una baseline di regole di negazione, è possibile applicare il livello di accesso minimo.
Dopo il provisioning, creare una regola di negazione di tutte le regole in ingresso e in uscita, con priorità 4096. Si tratta dell'ultima priorità personalizzata disponibile, ovvero l'ambito rimanente per configurare Consenti azioni.
Nel gruppo di sicurezza di rete passare a Regole di sicurezza in uscita e selezionare Aggiungi. Immettere i dati seguenti:
- Origine: Qualsiasi
- Intervalli di porte di origine: *
- Destinazione: qualsiasi
- Servizio: Personalizzato
- Intervalli di porte di destinazione: *
- Protocollo: tutti
- Azione: nega
- Priorità: 4096
- Nome: DenyAllOutbound
- Descrizione: nega tutto il traffico in uscita, a meno che non sia consentito in modo specifico.
Ecco un esempio.
Ripetere questo processo con le regole in ingresso, modificando il nome e la descrizione in base alle esigenze. Si noterà che nella scheda Regole di sicurezza in ingresso è presente un segno di avviso sulla regola, come illustrato di seguito.
Se si fa clic sulla regola e si scorre fino alla fine, verranno visualizzati altri dettagli, come illustrato di seguito.
Questo messaggio restituisce i due avvisi seguenti:
- Per impostazione predefinita, i servizi di bilanciamento del carico di Azure non potranno accedere alle risorse usando questo gruppo di sicurezza di rete.
- Per impostazione predefinita, altre risorse in questa rete virtuale non saranno in grado di accedere alle risorse usando questo gruppo di sicurezza di rete.
Per il nostro scopo in Zero Trust, questo è come dovrebbe essere. Significa che solo perché qualcosa si trova in questa rete virtuale, non significa che abbia accesso immediato alle risorse. Per ogni modello di traffico, è necessario creare una regola in modo esplicito consentendola ed è consigliabile farlo con la quantità minima di autorizzazioni. Pertanto, se sono presenti connessioni in uscita specifiche per la gestione, ad esempio per Dominio di Active Directory Services (AD DS) controller di dominio, macchine virtuali DNS private o per siti Web esterni specifici, devono essere controllati qui.
Se si usa Firewall di Azure per gestire le connessioni in uscita, invece di eseguire un rifiuto in uscita, è possibile lasciare aperte tutte le connessioni in uscita. Nell'ambito dell'implementazione Firewall di Azure si configurerà una tabella di route che invia la route predefinita (0.0.0.0/0) al firewall, che gestisce il traffico all'esterno della rete virtuale.
È quindi possibile creare una negazione di tutte le reti virtuali in uscita o consentire invece tutti gli elementi in uscita (ma sicuri con le regole in ingresso).
Altre informazioni su Firewall di Azure e tabelle di route per comprendere come usarle per aumentare ulteriormente la sicurezza dell'ambiente.
Per configurare le macchine virtuali con Microsoft Entra Login, Anti-Malware e aggiornamenti automatici abilitati, è necessario consentire le connessioni in uscita seguenti. Molti di questi sono per FQDN, vale a dire che è necessario Firewall di Azure per le regole FQDN o si creerà un piano più complesso. Firewall di Azure consigliato.
Le connessioni in uscita sono:
- Sulla porta 443:
- enterpriseregistration.windows.net
- settings-win.data.microsoft.com
- sls.update.microsoft.com
- v10.events.data.microsoft.com
- login.microsoftonline.com
- pas.windows.net
- 169.254.169.254
- Sulla porta 80:
- ctldl.windowsupdate.com
- www.msftconnecttest.com
- Sulla porta 123:
- time.windows.com
- Sulla porta 1688:
- Azkms.core.windows.net
Definire modelli di traffico con la quantità minima di autorizzazioni e seguire solo i percorsi consentiti in modo esplicito. Di seguito è riportato un diagramma di esempio dell'uso dei gruppi di sicurezza delle applicazioni per definire i modelli di traffico di rete nei gruppi di sicurezza di rete per una rete virtuale spoke usata insieme a una rete virtuale hub. Si tratta della configurazione consigliata.
Come altro esempio, ecco una configurazione per una rete virtuale spoke autonoma in cui web application firewall viene inserito nella subnet gateway applicazione della rete virtuale spoke.
Sono necessarie le regole del gruppo di sicurezza di rete seguenti:
- Consentire il traffico Internet nella subnet APP GW (HTTPS 443).
- Consentire il traffico dalla subnet del gateway APP alle macchine virtuali del livello front-end (HTTPS 433).
- Consentire il traffico dalle macchine virtuali del livello front-end al servizio di bilanciamento del carico del livello app (HTTPS 443).
- Consentire il traffico dal servizio di bilanciamento del carico del livello app alle macchine virtuali del livello app (HTTPS 443).
- Consentire il traffico dalle macchine virtuali del livello app al servizio di bilanciamento del carico del livello dati (SQL 1433).
- Consentire il traffico dal servizio di bilanciamento del carico del livello dati alle macchine virtuali del livello dati (SQL 1433).
- Consentire il traffico tra macchine virtuali livello dati (SQL 1433)
Configurare prima il modello SQL e quindi ripetere il processo con i livelli rimanenti. Le sezioni seguenti sono le configurazioni per le regole che limitano il traffico di rete per un singolo livello applicazione.
Regola 5- Consentire il traffico dalle macchine virtuali livello app al servizio di bilanciamento del carico del livello dati (SQL 1433)
Nel gruppo di sicurezza di rete per la subnet del livello app passare a Regole di sicurezza in ingresso e selezionare Aggiungi. Popolare l'elenco con quanto segue:
- Origine: Gruppo di sicurezza delle applicazioni
- Gruppi di sicurezza delle applicazioni di origine: selezionare il gruppo di sicurezza delle applicazioni del livello business
- Intervalli di porte di origine: 1433 (a volte il traffico di origine può provenire da porte diverse e, se questo modello si verifica, è possibile aggiungere intervalli di porte di origine a * per consentire qualsiasi porta di origine. La porta di destinazione è più significativa e alcuni consigli sono di usare sempre * per la porta di origine)
- Destinazione: indirizzi IP
- Indirizzi IP di destinazione/intervalli CIDR: indirizzo IP esplicito del servizio di bilanciamento del carico
- È necessario usare l'indirizzo IP esplicito perché non è possibile associare un servizio di bilanciamento del carico a un gruppo di sicurezza delle applicazioni.
- È possibile pianificare lo schema IP o distribuire il servizio di bilanciamento del carico e fare riferimento all'INDIRIZZO IP assegnato.
- Servizio: MS SQL
- Intervalli di porte di destinazione: viene compilato automaticamente per la porta 1433
- Protocollo: questa opzione viene selezionata automaticamente per TCP
- Azione: Consenti
- Priorità: valore compreso tra 100 e 4096. È possibile iniziare con 105.
- Nome: Allow-App-Tier-to-Data-LB-Inbound
- Descrizione: consente l'accesso in ingresso dal servizio di bilanciamento del carico del livello dati alle macchine virtuali livello app.
Si noterà che dopo il completamento è presente un'icona blu per gli avvisi informativi sulla regola. Facendo clic sulla regola viene visualizzato il messaggio seguente:
- "Le regole che usano i gruppi di sicurezza delle applicazioni possono essere applicate solo quando i gruppi di sicurezza delle applicazioni sono associati alle interfacce di rete nella stessa rete virtuale".
Ecco un esempio.
La regola si applica solo quando questo gruppo di sicurezza dell'applicazione viene usato in questa rete.
Infine, nello stesso gruppo di sicurezza di rete passare a Regole di sicurezza in uscita e selezionare Aggiungi. Popolare l'elenco in modo simile all'esempio, modificando Inbound in Outbound.
Regola 6 - Consentire il traffico dal servizio di bilanciamento del carico del livello dati alle macchine virtuali livello dati (SQL 1433)
Nel gruppo di sicurezza di rete per la subnet del livello dati passare a Regole di sicurezza in ingresso e selezionare Aggiungi. Popolare l'elenco con quanto segue:
- Origine: indirizzo IP
- Indirizzo IP di origine: indirizzo IP del servizio di bilanciamento del carico
- Intervalli di porte di origine: 1433
- Destinazione: gruppo di sicurezza delle applicazioni
- Gruppi di sicurezza delle applicazioni di destinazione: selezionare il gruppo di sicurezza dell'applicazione livello dati
- Servizio: MS SQL
- Intervalli di porte di destinazione: viene compilato automaticamente per la porta 1433.
- Protocollo: questa opzione viene selezionata automaticamente per TCP.
- Azione: Consenti
- Priorità: valore compreso tra 100 e 4096. È possibile iniziare con 105.
- Nome: Allow-SQL-LB-to-SQL-VMs-Inbound
- Descrizione: consente l'accesso in ingresso alle macchine virtuali del livello dati basate su SQL dal servizio di bilanciamento del carico del livello dati.
Nello stesso gruppo di sicurezza di rete passare a Regole di sicurezza in uscita e selezionare Aggiungi. Popolare l'elenco come fatto nell'esempio, modificando Inbound to Outbound (Inbound to Outbound).
Nel gruppo di sicurezza di rete per la subnet del livello dati passare a Regole di sicurezza in ingresso e selezionare Aggiungi. Popolare l'elenco con quanto segue:
- Origine: Gruppo di sicurezza delle applicazioni
- Gruppi di sicurezza delle applicazioni di destinazione: selezionare il gruppo di sicurezza dell'applicazione livello dati
- Intervalli di porte di origine: 1433
- Destinazione: gruppi di sicurezza delle applicazioni
- Gruppi di sicurezza delle applicazioni di destinazione: selezionare il gruppo di sicurezza dell'applicazione livello dati
- Servizio: MS SQL
- Intervalli di porte di destinazione: viene compilato automaticamente per la porta 1433.
- Protocollo: questa opzione viene selezionata automaticamente per TCP.
- Azione: Consenti
- Priorità: valore compreso tra 100 e 4096. È possibile iniziare con 105.
- Nome: Allow-SQL-VM-to-SQL-VM-Inbound
- Descrizione: consente l'accesso in ingresso tra macchine virtuali livello dati basate su SQL.
Nello stesso gruppo di sicurezza di rete passare a Regole di sicurezza in uscita e selezionare Aggiungi. Popolare l'elenco come elenco precedente, modificando Inbound in Outbound.Pop the list as the previous list, changing Inbound to Outbound.
Con queste tre regole, è stato definito il modello di connettività Zero Trust per un singolo livello applicazione. È possibile ripetere questo processo in base alle esigenze per flussi aggiuntivi.
Oltre al traffico specifico dell'applicazione, è necessario pianificare il traffico di gestione. Tuttavia, il traffico di gestione ha origine in genere all'esterno della rete virtuale spoke. Sono necessarie regole aggiuntive. Prima di tutto, è necessario comprendere le porte e le origini specifiche da cui proviene il traffico di gestione. In genere, tutto il traffico di gestione deve fluire da un firewall o da un'altra appliance virtuale di rete che si trova nella rete hub per lo spoke.
Vedere l'architettura di riferimento completa nell'articolo Applicare i principi Zero Trust ad Azure IaaS .
Questo varia in base alle esigenze di gestione specifiche. Tuttavia, è consigliabile usare regole per le appliance firewall e le regole nel gruppo di sicurezza di rete per consentire in modo esplicito le connessioni sia sul lato rete della piattaforma che sul lato rete del carico di lavoro.
Anche se il gruppo di sicurezza di rete blocca il traffico non necessario, non significa che gli obiettivi siano soddisfatti. È comunque necessario osservare il traffico che si verifica all'esterno dei modelli espliciti, in modo da sapere se si verifica un attacco.
Per abilitare la registrazione del flusso del gruppo di sicurezza di rete, è possibile seguire l'esercitazione Esercitazione: Registrare il flusso del traffico di rete da e verso una macchina virtuale rispetto al gruppo di sicurezza di rete esistente creato.
Nota
- L'account di archiviazione deve seguire le indicazioni per l'account di archiviazione Zero Trust.
- L'accesso ai log deve essere limitato in base alle esigenze.
- Devono anche essere trasmessi a Log Analytics e Sentinel in base alle esigenze.
Oltre ai controlli nella rete virtuale spoke, è anche possibile usare un Firewall di Azure per applicare un'ispezione aggiuntiva. Mentre la funzione Web application firewall per Frontdoor di Azure e gateway applicazione controlla il traffico per attacchi Web comuni, l'uso di Firewall di Azure può fornire un livello di ispezione più approfondito.
Per usare ogni segnale disponibile e mantenere visibilità centrale sul traffico di rete, è consigliabile instradare il traffico dal gateway applicazione a Firewall di Azure. Può quindi esaminare il traffico per rilevare segnali aggiuntivi e acquisire il comportamento nei log. Per altre informazioni su questa configurazione, vedere l'articolo Rete zero-trust per le applicazioni Web con Firewall di Azure e gateway applicazione. Per altre informazioni su come configurare questo comportamento, vedere Configurare Firewall di Azure Premium per Zero Trust.
La protezione dell'accesso alla rete virtuale e all'applicazione include:
- Protezione del traffico all'interno dell'ambiente Azure per l'applicazione.
- Uso dell'autenticazione a più fattori e dei criteri di accesso condizionale per l'accesso utente all'applicazione.
Il diagramma seguente mostra entrambe queste modalità di accesso nell'architettura di riferimento.
Gran parte del lavoro del traffico di sicurezza all'interno dell'ambiente Azure è già stato completato. Le connessioni sicure tra le risorse di archiviazione e le macchine virtuali sono configurate in Applicare i principi Zero Trust all'archiviazione di Azure.
Per proteggere l'accesso dalle risorse hub alla rete virtuale, vedere Applicare principi Zero Trust a una rete virtuale hub in Azure.
Uso dell'autenticazione a più fattori e dei criteri di accesso condizionale per l'accesso utente all'applicazione
L'articolo Applicare principi Zero Trust alle macchine virtuali consiglia di proteggere le richieste di accesso direttamente alle macchine virtuali con l'autenticazione a più fattori e l'accesso condizionale. Queste richieste sono molto probabilmente provenienti da amministratori e sviluppatori. Il passaggio successivo consiste nel proteggere l'accesso all'applicazione con l'autenticazione a più fattori e l'accesso condizionale. Questo vale per tutti gli utenti che accedono all'app.
In primo luogo, se l'applicazione non è ancora integrata con Microsoft Entra ID, vedere Tipi di applicazione per Microsoft Identity Platform.
Aggiungere quindi l'applicazione all'ambito dei criteri di accesso alle identità e ai dispositivi.
Quando si configura l'autenticazione a più fattori con l'accesso condizionale e i criteri correlati, usare il set di criteri consigliato per Zero Trust come guida. Sono inclusi i criteri "Punto di partenza" che non richiedono la gestione dei dispositivi. Idealmente, i dispositivi che accedono alle macchine virtuali vengono gestiti ed è possibile implementare il livello "Enterprise", consigliato per Zero Trust. Per altre informazioni, vedere Common Zero Trust identity and device access policies .For more information, see Common Zero Trust identity and device access policies.
Il diagramma seguente mostra i criteri consigliati per Zero Trust.
La rete virtuale spoke basata su Azure potrebbe essere già protetta da Microsoft Defender per il cloud (MDC) come altre risorse dell'ambiente aziendale IT in esecuzione in Azure o in locale, possono anche essere protette.
Come accennato negli altri articoli di questa serie, Microsoft Defender per il cloud è uno strumento CSPM (Cloud Security Posture Management) e Cloud Workload Protection (CWP) che offre raccomandazioni sulla sicurezza, avvisi e funzionalità avanzate, ad esempio Protezione avanzata adattiva per la rete, per facilitare l'avanzamento del percorso di sicurezza cloud. Per visualizzare meglio dove Defender per il cloud si inserisce nel panorama della sicurezza Microsoft più elevato, vedere Architetture di riferimento per la sicurezza informatica Microsoft.
Questo articolo non illustra in dettaglio Microsoft Defender per il cloud, ma è importante comprendere che Microsoft Defender per il cloud funziona in base a Criteri di Azure e ai log inseriti in un'area di lavoro Log Analytics. Dopo l'abilitazione nelle sottoscrizioni con la rete virtuale spoke e le risorse associate, sarà possibile visualizzare le raccomandazioni per migliorare il comportamento di sicurezza. È possibile filtrare ulteriormente queste raccomandazioni in base alla tattica MITRE, al gruppo di risorse e così via. Valutare la priorità della risoluzione delle raccomandazioni che hanno un impatto maggiore sul punteggio di sicurezza dell'organizzazione.
Ecco un esempio nel portale di Microsoft Defender per il cloud.
Se si sceglie di eseguire l'onboarding di uno dei piani di Defender per il cloud che offrono funzionalità avanzate di protezione dei carichi di lavoro, include raccomandazioni per la protezione avanzata adattiva della rete per migliorare le regole esistenti del gruppo di sicurezza di rete. Ecco un esempio.
È possibile accettare la raccomandazione selezionando Applica, che crea una nuova regola del gruppo di sicurezza di rete o ne modifica una esistente.
Queste illustrazioni sono repliche delle illustrazioni di riferimento contenute in questi articoli. Scaricare e personalizzare questi elementi per l'organizzazione e i clienti. Sostituire il logo contoso con il proprio.
Articolo | Descrizione |
---|---|
Scaricare Visio Aggiornamento di ottobre 2024 |
Applicare i principi Zero Trust ad Azure IaaS Usare queste illustrazioni con questi articoli: - Sintesi - Archiviazione di Azure - Macchine virtuali - Reti virtuali spoke di Azure - Reti virtuali dell'hub di Azure |
Scaricare Visio Aggiornamento di ottobre 2024 |
Applicare i principi Zero Trust ad Azure IaaS - Poster di una pagina Panoramica di una pagina del processo per l'applicazione dei principi di Zero Trust agli ambienti IaaS di Azure. |
Per altre illustrazioni tecniche, vedere Illustrazioni Zero Trust per architetti IT e implementatori.
- Proteggere le risorse di Azure con il controllo degli accessi in base al ruolo di Azure
- Configura e gestisci Monitoraggio di Azure
- Configurare i gruppi di sicurezza di rete
- Progettare e implementare la sicurezza di rete
- Proteggere l'accesso alle applicazioni usando i servizi di gestione delle identità di Azure
Per altre informazioni sulla sicurezza in Azure, vedere queste risorse nel catalogo Microsoft:
Sicurezza in Azure | Microsoft Learn
Vedere questi articoli aggiuntivi per l'applicazione dei principi Zero Trust ad Azure:
- Panoramica di Azure IaaS
- Desktop virtuale Azure
- Rete WAN virtuale di Azure
- Applicazioni IaaS in Amazon Web Services
- Microsoft Sentinel e Microsoft Defender XDR
- Adottare la sicurezza proattiva con Zero Trust
- Proteggere le reti con Zero Trust
- Rete senza attendibilità per le applicazioni Web con Firewall di Azure e gateway applicazione - Centro architetture di Azure
- Criteri della zona di destinazione di Azure
- Criteri comuni di identità e dispositivi Zero Trust