Applicare principi Zero Trust a una rete virtuale spoke con i servizi PaaS di Azure
Questo articolo illustra come applicare i principi del modello di sicurezza Zero Trust a un carico di lavoro PaaS usando le reti virtuali di Azure e gli endpoint privati 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 il rilevamento delle minacce in Firewall di Azure e app Azure lication Gateway per convalidare il traffico e verificare se il traffico è accettabile. |
| 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. | Ridurre l'ingresso e l'uscita dai servizi di Azure alla rete privata. Usare i gruppi di sicurezza di rete per consentire solo l'ingresso specifico dalla rete virtuale. Usare un'istanza centrale Firewall di Azure per concedere al servizio di Azure l'accesso al traffico non di rete virtuale. |
| 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. | Limitare le comunicazioni non necessarie tra le risorse. Assicurarsi di eseguire la registrazione dai 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. |
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 ad Azure IaaS.
Rete autonoma o spoke Zero Trust per i servizi PaaS di Azure
Molti servizi PaaS contengono funzionalità di controllo in ingresso e in uscita personalizzate native del servizio. È possibile usare questi controlli per proteggere l'accesso di rete alle risorse del servizio PaaS senza la necessità di infrastruttura, ad esempio reti virtuali. Ad esempio:
- database SQL di Azure dispone di un firewall specifico che può essere usato per consentire indirizzi IP client specifici che devono accedere al server di database.
- Gli account di archiviazione di Azure hanno un'opzione di configurazione che consente le connessioni da una rete virtuale specifica o di bloccare l'accesso alla rete pubblica.
- app Azure Servizio supporta le restrizioni di accesso per definire un elenco di consenti/rifiuto ordinato con priorità che controlla l'accesso alla rete all'app.
Tuttavia, per le implementazioni guidate di Zero Trust, questi controlli di accesso nativo del servizio spesso non sono sufficienti. In questo modo si crea una diffusione dei controlli di accesso e della registrazione che possono aumentare la gestione e ridurre la visibilità.
Inoltre, i servizi PaaS possono usare nomi di dominio completi (FQDN) che si risolvono in un indirizzo IP pubblico assegnato dinamicamente allocato da un pool di indirizzi IP pubblici in un'area specifica per un tipo di servizio. Per questo motivo, non sarà possibile consentire il traffico da o verso un servizio PaaS specifico usando il relativo indirizzo IP pubblico, che può cambiare.
Microsoft consiglia di usare endpoint privati. Un endpoint privato è un'interfaccia di rete virtuale che usa un indirizzo IP privato dalla rete virtuale. L’interfaccia di rete connette l'utente in modo privato e sicuro a un servizio gestito dal collegamento privato di Azure. Abilitando un endpoint privato, si inserisce il servizio nella rete virtuale.
A seconda dello scenario della soluzione, potrebbe essere comunque necessario l'accesso in ingresso pubblico ai servizi PaaS. Tuttavia, a meno che non si faccia, Microsoft consiglia che tutto il traffico rimanga privato per eliminare potenziali rischi per la sicurezza.
Questa guida fornisce istruzioni per un'architettura di riferimento specifica, ma i principi e i metodi possono essere applicati ad altre architetture in base alle esigenze.
Architettura di riferimento
Il diagramma seguente illustra un'architettura di riferimento comune per i carichi di lavoro basati su PaaS.
Nel diagramma:
- Una rete virtuale spoke include componenti per supportare un'applicazione PaaS.
- L'applicazione PaaS è un'applicazione a due livelli che sfrutta i servizi di app Azure lication per un'app Web o un front-end e un database SQL di Azure per i database relazionali.
- Ogni livello è contenuto in una subnet dedicata per l'ingresso con un gruppo di sicurezza di rete dedicato.
- Il livello Web contiene una subnet dedicata per l'uscita.
- L'accesso all'applicazione viene fornito tramite un gateway applicazione contenuto nella propria subnet.
Il diagramma seguente illustra l'architettura logica di questi componenti all'interno di una sottoscrizione di Azure.
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 (denominati con "NSG" nel diagramma) per i livelli di database, applicazione e front-end
- Due gruppi di sicurezza delle applicazioni (denominati con "ASG" nel diagramma)
- Due endpoint privati
Inoltre, le risorse per la rete virtuale dell'hub vengono distribuite nella sottoscrizione di connettività appropriata.
Che cos'è in questo articolo
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à |
|---|---|
| 1 | Sfruttare il controllo degli accessi in base al ruolo di Microsoft Entra o configurare ruoli personalizzati per le risorse di rete. |
| 2 | Isolare l'infrastruttura nel proprio gruppo di risorse. |
| 3 | Creare un gruppo di sicurezza di rete per ogni subnet. |
| 4 | Proteggere il traffico e le risorse all'interno della rete virtuale:
|
| 5 | Proteggere l'ingresso e l'uscita per i servizi PaaS di Azure. |
| 6 | Proteggere l'accesso alla rete virtuale e all'applicazione. |
| 7 | Abilitare il rilevamento avanzato delle minacce, gli avvisi e la protezione. |
Questa guida presuppone che sia già disponibile un servizio di app Azure lication e database SQL di Azure distribuito nei propri gruppi di risorse.
Passaggio 1: Sfruttare il controllo degli accessi in base al ruolo di Microsoft Entra o configurare ruoli personalizzati per le risorse di rete
È possibile sfruttare i ruoli predefiniti controllo degli accessi in base al ruolo di Microsoft Entra per i collaboratori di rete. Tuttavia, un altro approccio consiste nel sfruttare i ruoli personalizzati. I responsabili della rete virtuale 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. Un ruolo personalizzato può essere usato 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 che può essere usato è il ruolo personalizzato Gestione rete, che dispone delle 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 di risorse
Questo ruolo può essere creato usando gli script nel repository GitHub dell'architettura di riferimento della zona di destinazione di Azure oppure può essere creato tramite Microsoft Entra ID con ruoli personalizzati di Azure.
Passaggio 2: Isolare l'infrastruttura nel proprio gruppo di risorse
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.
Anziché avere le risorse di rete spoke disponibili in più contesti in un gruppo di risorse condivise, creare un gruppo di risorse dedicato. Il diagramma dell'architettura seguente illustra questa configurazione.
Nel diagramma le risorse e i componenti nell'architettura di riferimento sono suddivisi in gruppi di risorse dedicati per i servizi applicazioni, i database SQL di Azure, gli account di archiviazione, le risorse della rete virtuale dell'hub e le risorse della rete virtuale spoke.
Con un gruppo di risorse dedicato, è possibile assegnare un ruolo personalizzato usando l'esercitazione Concedere a un utente l'accesso alle risorse di Azure usando l'esercitazione portale 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 le procedure di gestione delle identità aziendali.
Se non si usano criteri che applicano l'inoltro dei log nei gruppi di risorse, configurare questa operazione nel log attività per il gruppo di risorse:
- Trovare il gruppo di risorse nella portale di Azure.
- 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. Ecco un esempio:
Per informazioni su come esaminare questi log e ricevere avvisi, vedere Impostazioni di diagnostica.
Democratizzazione delle sottoscrizioni
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, vedere Principi di progettazione della zona di destinazione di Azure.
Passaggio 3: Creare un gruppo di sicurezza di rete per ogni subnet
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. Questa operazione viene applicata 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 negano il traffico di rete in ingresso o il traffico di rete in uscita rispettivamente verso o da diversi tipi di risorse di Azure. Per ogni regola, è possibile specificare gli indirizzi IP di origine e di destinazione, un protocollo (ad esempio TCP o UDP) e una porta.
Per le applicazioni multilivello, è consigliabile creare un gruppo di sicurezza di rete dedicato ("gruppo di sicurezza di rete" nel diagramma seguente) per ogni subnet che ospita un componente di rete.
Nel diagramma:
- Ogni livello dell'applicazione ha una subnet di ingresso dedicata, ad esempio una per il livello Web e un'altra per il livello dati.
- app Azure lication Services dispone di una subnet in uscita dedicata per un servizio applicazione specifico.
- Un gruppo di sicurezza di rete è configurato per ognuna di queste subnet.
La configurazione dei gruppi di sicurezza di rete in modo diverso da quello del diagramma 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.
Vedere Creare, modificare o eliminare un gruppo di sicurezza di rete di Azure per gestire le impostazioni dei gruppi di sicurezza di rete.
Altre informazioni sui gruppi di sicurezza di rete per comprendere come possono essere usati per proteggere gli ambienti.
Passaggio 4: Proteggere il traffico e le risorse all'interno della rete virtuale
In questa sezione vengono descritte le raccomandazioni seguenti:
- Distribuire le regole di negazione della baseline per i gruppi di sicurezza di rete
- Distribuire regole specifiche dell'applicazione
- Pianificare il traffico di gestione nella rete virtuale
- Distribuire la registrazione dei flussi dei gruppi di sicurezza di rete
Distribuire le regole di negazione della baseline per i 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 negata in ognuna delle regole in ingresso e in uscita con priorità 4096. Si tratta dell'ultima priorità personalizzata disponibile, ovvero l'ambito rimanente per configurare le azioni consentite.
A tale scopo, 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.
Nella scheda Regole di sicurezza in ingresso viene visualizzato l'accesso di avviso alla regola. Ecco un esempio.
Fare clic sulla regola e scorrere fino alla fine per visualizzare altri dettagli. Ecco un esempio:
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. Ciò significa che solo perché qualcosa si trova in questa rete virtuale, non significa che avrà accesso immediato alle risorse. Per ogni modello di traffico, creare una regola che lo consenta in modo esplicito ed è consigliabile farlo con la quantità minima di autorizzazioni.
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, è necessario controllarlo qui.
Regole alternative di negazione
Nota
Le raccomandazioni contenute in questa sezione si applicano solo alla subnet web in uscita.
Se si usa Firewall di Azure per gestire le connessioni in uscita, anziché eseguire un deny-outbound-all, è possibile creare regole alternative per le connessioni in uscita. Come parte dell'implementazione di Firewall di Azure, si configura una tabella di route che invia il traffico predefinito (0.0.0.0/0) al firewall. Questo gestisce il traffico all'esterno della rete virtuale.
È quindi possibile creare una regola di negazione di tutte le reti virtuali in uscita oppure consentire tutte le regole in uscita, ma proteggere gli elementi con le regole in ingresso.
Vedere Firewall di Azure e tabelle di route per comprendere come possono essere usati per aumentare ulteriormente la sicurezza dell'ambiente.
Distribuire regole specifiche dell'applicazione
Definire modelli di traffico con la quantità minima di autorizzazioni e seguire solo i percorsi consentiti in modo esplicito. Usando le subnet come origini, definire i modelli di rete nei gruppi di sicurezza di rete. Ecco un esempio.
Usare il processo Gestisci gruppi di sicurezza di rete: creare una regola di sicurezza per aggiungere regole ai gruppi di sicurezza di rete.
Per proteggere questo scenario, aggiungere le regole seguenti:
| Gruppo di sicurezza di rete per subnet | Direzione | Origine | Dettagli origine | Porta di origine | Destinazione | Dettagli destinazione | Service | Nome del gruppo di sicurezza di rete | Descrizione del gruppo di sicurezza di rete |
|---|---|---|---|---|---|---|---|---|---|
| subnet servizio app | In entrata | Indirizzi IP | Intervallo di indirizzi IP privati della subnet gateway applicazione | 443 | Indirizzi IP | Indirizzo IP esplicito dell'endpoint privato del servizio app | MS SQL | AllowGWtoAppInbound | Consente l'accesso in ingresso al servizio app dal gateway applicazione. |
| subnet di integrazione servizio app | In uscita | Indirizzi IP | Intervallo di indirizzi IP della subnet di integrazione servizio app | 1433 | Indirizzi IP | Indirizzo IP esplicito dell'endpoint privato del database SQL | MS SQL | AllowApptoSQLDBOutbound | Consente l'accesso in uscita all'endpoint privato SQL dalla subnet di integrazione servizio app. |
| Azure SQL Subnet | In entrata | Indirizzi IP | Intervallo di indirizzi IP della subnet di integrazione servizio app | 1433 | Indirizzi IP | Indirizzo IP esplicito dell'endpoint privato del database SQL | MS SQL | AllowApptoSQLDBInbound | Consente l'accesso in ingresso all'endpoint privato SQL da servizio app subnet di integrazione. |
Nota
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.
Nota
Per la priorità, usare un valore compreso tra 100 e 4000. È possibile iniziare da 105.
Oltre alle regole del gruppo di sicurezza di rete nella subnet gateway applicazione.
Con queste 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.
Pianificare il traffico di gestione nella rete virtuale
Oltre al traffico specifico dell'applicazione, pianificare il traffico di gestione. Tuttavia, poiché il traffico di gestione ha origine in genere all'esterno della rete virtuale spoke, sono necessarie altre regole. Prima di tutto, 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.
Per l'architettura di riferimento completa, vedere Applicare i principi Zero Trust ad Azure IaaS .
La configurazione varia in base alle esigenze di gestione specifiche. Tuttavia, è consigliabile usare regole per appliance firewall e regole nel gruppo di sicurezza di rete per consentire in modo esplicito le connessioni sia sui lati rete della piattaforma che della rete del carico di lavoro.
Pianificazione delle distribuzioni
Poiché i servizi e i database dell'applicazione usano ora la rete privata, pianificare il funzionamento delle distribuzioni di codice e dati in queste risorse. Aggiungere regole per consentire ai server di compilazione privati di accedere a questi endpoint.
Distribuire la registrazione dei flussi dei gruppi di sicurezza di rete
Anche se il gruppo di sicurezza di rete blocca il traffico non necessario, non significa che gli obiettivi siano soddisfatti. Per rilevare un attacco, è comunque necessario osservare il traffico che si verifica all'esterno dei modelli espliciti.
Il traffico verso gli endpoint privati non viene registrato, ma se altri servizi vengono distribuiti nelle subnet in un secondo momento, questo log consentirà di rilevare le attività.
Per abilitare la registrazione del flusso del gruppo di sicurezza di rete, seguire l'esercitazione Esercitazione: Registrare il flusso del traffico di rete da e verso una macchina virtuale per il gruppo di sicurezza di rete esistente per gli endpoint privati.
Nota
Tenere presenti questi consigli:
È consigliabile limitare l'accesso ai log in base alle esigenze.
I log devono essere trasmessi a Log Analytics e Microsoft Sentinel in base alle esigenze.
Passaggio 5: Proteggere l'ingresso e l'uscita per i servizi PaaS di Azure
Questa sezione contiene due passaggi necessari per proteggere l'ingresso e l'uscita per i servizi PaaS:
- Distribuire endpoint privati per l'ingresso nei servizi.
- Distribuire l'integrazione della rete virtuale per consentire al servizio applicazioni di comunicare con la rete virtuale.
Inoltre, è consigliabile considerare anche la configurazione DNS per consentire la risoluzione dei nomi.
Distribuire endpoint privati per l'ingresso
Anche se molti servizi consentono di creare endpoint privati dal pannello specifico della risorsa nel portale di Azure, un'esperienza più coerente consiste nel creare un endpoint privato dalla creazione di risorse. A tale scopo, le risorse devono essere già distribuite. Dopo la distribuzione, è possibile creare l'endpoint privato.
Quando si distribuiscono gli endpoint privati, configurarli come segue:
- Inserirli nel gruppo di risorse specifico che ospita le risorse padre per mantenere le risorse con un ciclo di vita simile e fornire l'accesso centrale.
- Inserirli nella subnet appropriata nella rete virtuale in base al proprio ruolo.
- Per il servizio di app Azure lication, è possibile configurare endpoint privati sia per il front-end normale che per il relativo endpoint SCM, usato per le distribuzioni e la gestione.
Inoltre, come parte di questa distribuzione, è necessario assicurarsi che il firewall specifico del servizio sia impostato per negare il traffico in ingresso. In questo modo verranno negati eventuali tentativi di ingresso pubblico.
Per il database SQL di Azure, gestire le regole del firewall IP a livello di server. Assicurarsi che l'accesso alla rete pubblica sia impostato su Disabilita dal pannello di rete nel portale di Azure.
Per il servizio di app Azure lication, l'aggiunta dell'endpoint privato imposta il firewall a livello di servizio per bloccare l'accesso in ingresso per impostazione predefinita. Per altre informazioni, vedere Uso di endpoint privati per le app servizio app.
Distribuire l'integrazione della rete virtuale per l'uscita
Oltre agli endpoint privati per l'ingresso, abilitare l'integrazione della rete virtuale. Ogni piano di servizio app può avere l'integrazione della rete virtuale abilitata e in questo modo alloca un'intera subnet per il servizio app. Per altre informazioni, vedere Integrare l'app con una rete virtuale di Azure.
Per configurare la servizio app, vedere Abilitare l'integrazione della rete virtuale nel servizio app Azure. Assicurarsi di inserirlo nella subnet designata per l'uscita.
Considerazioni sul DNS
Come parte dell'uso di endpoint privati, abilitare la risoluzione DNS dei nomi di dominio completi delle risorse ai nuovi indirizzi IP privati. Per le istruzioni per implementare questa funzionalità in diversi modi, vedere Configurazione DNS dell'endpoint privato.
Nota
La risoluzione DNS deve essere applicata a tutto il traffico. Le risorse nella stessa rete virtuale non saranno in grado di risolvere a meno che non usino le zone DNS corrette.
Passaggio 6: Proteggere l'accesso alla rete virtuale e all'applicazione
La protezione dell'accesso alla rete virtuale e alle applicazioni include:
- Protezione del traffico all'interno dell'ambiente Azure per l'applicazione
- Uso dell'autenticazione a più fattori (MFA) e dei criteri di accesso condizionale per l'accesso utente alle applicazioni.
Il diagramma seguente mostra entrambe le modalità di accesso nell'architettura di riferimento.
Proteggere il traffico all'interno dell'ambiente Azure per la rete virtuale e l'applicazione
Gran parte del lavoro del traffico di sicurezza all'interno dell'ambiente Azure è già stato completato. Vedere Applicare principi Zero Trust all'archiviazione di Azure per configurare connessioni sicure tra le risorse di archiviazione e le macchine virtuali.
Vedere Applicare principi Zero Trust a una rete virtuale hub in Azure per proteggere l'accesso dalle risorse hub alla rete virtuale.
Uso di MFA e criteri di accesso condizionale per l'accesso utente alle applicazioni
L'articolo Applicare i principi Zero Trust alle macchine virtuali consiglia di proteggere le richieste di accesso direttamente alle macchine virtuali con 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 alle applicazioni con MFA e l'accesso condizionale. Questo vale per tutti gli utenti che accedono all'applicazione.
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.
Passaggio 7: Abilitare il rilevamento e la protezione avanzata delle minacce
La rete virtuale spoke basata su Azure può essere protetta da Microsoft Defender per il cloud 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, Defender per il cloud è uno strumento CWP (Cloud Security Posture Management) e Cloud Workload Protection (CWP) che offre raccomandazioni sulla sicurezza, avvisi e funzionalità avanzate, ad esempio la protezione avanzata della rete adattiva per facilitare l'avanzamento del percorso di sicurezza nel cloud.
Questo articolo non descrive Defender per il cloud in dettaglio, ma è importante comprendere che Defender per il cloud funziona in base ai criteri e ai log di Azure inseriti in un'area di lavoro Log Analytics. Dopo aver abilitato le sottoscrizioni con la rete virtuale spoke e le risorse associate, è possibile visualizzare raccomandazioni per migliorare il comportamento di sicurezza. È possibile filtrare ulteriormente queste raccomandazioni in base alla tattica MITRE, al gruppo di risorse e ad altri utenti. Valutare la priorità per risolvere le raccomandazioni che hanno un impatto maggiore sul punteggio di sicurezza dell'organizzazione. Ecco un esempio.
Esistono Defender per il cloud piani che offrono protezioni avanzate dei carichi di lavoro che includono raccomandazioni per la protezione avanzata adattiva della rete per migliorare le regole dei gruppi di sicurezza di rete esistenti. Ecco un esempio.
È possibile accettare la raccomandazione selezionando Applica, che creerà una nuova regola del gruppo di sicurezza di rete o ne modificherà una esistente.
Formazione consigliata
- 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
- Progettare e implementare l'accesso privato ai servizi di Azure
Passaggi successivi
Vedere questi articoli aggiuntivi per l'applicazione dei principi Zero Trust ad Azure:
- Per Azure IaaS:
- Desktop virtuale Azure
- Rete WAN virtuale di Azure
- Applicazioni IaaS in Amazon Web Services
- Microsoft Sentinel e Microsoft Defender XDR
Riferimenti
- Adottare la sicurezza proattiva con Zero Trust
- Proteggere le reti con Zero Trust
- Rete Zero Trust per le applicazioni Web con Firewall di Azure e gateway applicazione
- Criteri della zona di destinazione di Azure
- Identità Zero Trust e dispositivo comuni tra i criteri
- Che cos'è un endpoint privato?
- Configurazione DNS dell'endpoint privato
- Integrare l'app con una rete virtuale di Azure
- Uso di endpoint privati per le app di servizio app
- Connettersi a un server SQL di Azure usando un endpoint privato di Azure