Sicurezza DNS e risoluzione dei nomi privati

Questo articolo illustra come progettare DNS per le reti Azure usando zone DNS private, DNS di Azure resolver privato e controlli di sicurezza DNS. Vengono illustrati i modelli di risoluzione dei nomi privati, l'inoltro DNS ibrido, l'integrazione DNS dell'endpoint privato e la protezione dalle minacce a livello DNS.

Informazioni su questo articolo

DNS è la base della connettività di rete: ogni connessione inizia con una query di risoluzione dei nomi. In Azure, la progettazione DNS determina il modo in cui i carichi di lavoro si individuano tra reti virtuali, come i sistemi locali risolvono i nomi Azure ospitati e il modo in cui gli endpoint privati diventano raggiungibili dai nomi di dominio completi (FQDN). Oltre la risoluzione, dns è anche una superficie di attacco. Il tunneling DNS, l'esfiltrazione e le query a domini dannosi rappresentano minacce reali che richiedono controlli di sicurezza a livello DNS.

Questo articolo risolve tre problemi DNS:

  • Risoluzione dei nomi privati: Come le macchine virtuali, i contenitori e i servizi della piattaforma risolvono i nomi all'interno di Azure senza esporre query DNS alla rete Internet pubblica.
  • Inoltro DNS ibrido: Come le reti locali risolvono i nomi privati di Azure e come i carichi di lavoro di Azure risolvono i nomi dell'ambiente locale.
  • Sicurezza DNS: Come bloccare query DNS dannose, impedire l'esfiltrazione DNS e abilitare il filtro di rete basato su FQDN.

Chi ha bisogno di questo articolo

Leggere questo articolo se:

  • Distribuire endpoint privati (se applicabile al proprio scenario) e assicurarsi che i carichi di lavoro risolvano correttamente le zone DNS privatelink.*.
  • Gestire ambienti ibridi in cui i sistemi on-premises devono risolvere i nomi privati di Azure (o viceversa).
  • Usare Firewall di Azure e richiedere il filtro basato su FQDN nelle regole di rete.
  • Si desidera bloccare le query DNS verso domini malevoli noti a livello di risoluzione DNS.
  • Gestire ambienti con più reti virtuali in cui la risoluzione DNS centralizzata semplifica le operazioni.
  • Pianificare l'architettura DNS per topologie hub-spoke con servizi condivisi.

Focus su lift-and-shift: mantenere il comportamento di denominazione DNS esistente durante la migrazione. Usare l'inoltro bidirezionale tra il DNS locale e Azure, configurare i forwarder condizionali per la risoluzione split-horizon e ospitare i nomi privati di Azure nelle zone DNS private in modo che le applicazioni mantengano la configurazione DNS attuale.

Focus sulla modernizzazione: centralizzare la risoluzione dei nomi durante la migrazione dei carichi di lavoro a una nuova piattaforma. Usare DNS di Azure resolver privato con set di regole di inoltro per la risoluzione ibrida, integrare DNS privato zone con endpoint privati per i servizi PaaS e abilitare il proxy DNS Firewall di Azure in modo che le regole basate su FQDN e la risoluzione DNS condividono un singolo percorso memorizzato nella cache.

Focus sul multi-cloud: pianificare il cutover DNS tra cloud prima della migrazione del carico di lavoro. Usare DNS di Azure resolver privato per la risoluzione dei nomi tra cloud, configurare l'inoltro condizionale con il resolver AWS Route 53 o GOOGLE Cloud DNS e ridurre i valori TTL prima del cutover per ridurre il rischio di cache non aggiornata.

Azure servizi e funzionalità

La tabella seguente descrive i servizi e le funzionalità di Azure coinvolti nella sicurezza DNS e nella risoluzione dei nomi privati.

Servizio/Funzionalità Purpose Funzionalità chiave Quando utilizzare
DNS di Azure (zone pubbliche) Hosting autorevole per i nomi di dominio pubblici Rete anycast globale, integrazione con il controllo degli accessi in base al ruolo di Azure (RBAC), record alias per le risorse di Azure Si è proprietari di un dominio pubblico e si vuole ospitare i record DNS in Azure con disponibilità elevata.
Zone DNS private di Azure Risoluzione dei nomi all'interno di reti virtuali senza esposizione pubblica collegamento di VNet, registrazione automatica dei nomi host delle VM, hosting della zona Private Link Risoluzione dei nomi interna per i carichi di lavoro Azure. Obbligatorio per l'integrazione DNS dell'endpoint privato.
Sistema di risoluzione privato DNS di Azure Inoltro DNS tra Azure e reti esterne Endpoint in ingresso (risoluzione da ambiente locale ad Azure), endpoint in uscita (inoltro da Azure ad ambiente locale), set di regole per l'inoltro Gli ambienti ibridi necessitano di una risoluzione DNS bidirezionale senza distribuire macchine virtuali DNS personalizzate.
Firewall di Azure DNS proxy Intercettazione DNS centralizzata per il filtro FQDN Memorizza nella cache le risposte DNS, abilita le regole di rete basate su FQDN, fornisce un singolo endpoint DNS per le VNet spoke Si distribuisce Firewall di Azure ed è necessario il filtro FQDN nelle regole di rete. Obbligatorio per una risoluzione FQDN coerente.
Criteri di sicurezza DNS Protezione dalle minacce a livello DNS Blocca la risoluzione di domini dannosi noti usando il feed di Microsoft Threat Intelligence Si vuole impedire ai carichi di lavoro di connettersi a domini di distribuzione di comandi e controlli o malware.

concetti relativi alle zone di DNS privato

DNS privato zone forniscono la risoluzione dei nomi per le reti virtuali collegate senza esporre i record a Internet. Comportamenti principali:

  • Collegamento reti virtuali: È possibile collegare una zona DNS privata a più reti virtuali. Tutte le risorse nelle reti virtuali collegate possono risolvere i record nella zona.
  • Registrazione automatica: Se abilitata in un collegamento di rete virtuale, Azure crea automaticamente record A per le macchine virtuali distribuite nella rete virtuale. Azure rimuove i record durante la deallocazione o l'eliminazione di macchine virtuali. La registrazione automatica funziona solo per le macchine virtuali (solo scheda di interfaccia di rete primaria). Una rete virtuale può eseguire la registrazione automatica in una sola zona DNS privata, ma è possibile collegare più reti virtuali alla stessa zona.
  • DNS dell'endpoint privato: Azure servizi a cui si accede tramite endpoint privati richiedono zone DNS privatelink specifiche, privatelink.blob.core.windows.net ad esempio per Archiviazione BLOB di Azure. Senza la zona corretta, i client risolvono l'indirizzo IP pubblico anziché l'indirizzo dell'endpoint privato.

Architettura del resolver privato DNS

DNS di Azure resolver privato sostituisce la necessità di macchine virtuali DNS personalizzate in scenari di inoltro ibrido. Il diagramma seguente illustra il flusso di risoluzione DNS ibrido dall'ambiente locale tramite DNS di Azure resolver privato a un indirizzo IP dell'endpoint privato.

Diagramma che mostra il flusso di risoluzione DNS ibrida dall'ambiente locale, tramite l'endpoint in ingresso di DNS di Azure Private Resolver, verso una zona DNS privata e un indirizzo IP di un endpoint privato.

Il sistema di risoluzione usa due tipi di endpoint:

  • Endpoint in entrata: Fornisce un indirizzo IP che i server DNS locali possono usare come forwarder condizionale. DNS di Azure risolve le query inviate a questo indirizzo IP (incluse le zone di DNS privato collegate). Richiede una subnet dedicata delegata a Microsoft.Network/dnsResolvers.
  • Endpoint di uscita: Consente ai carichi di lavoro di Azure di inoltrare query DNS ai server DNS locali, ad altri provider cloud o a resolver esterni. Richiede anche una subnet dedicata. I set di regole di inoltro collegati all'endpoint in uscita definiscono i suffissi di dominio da inoltrare e quali server DNS di destinazione usare.

Importante

Gli endpoint in ingresso e in uscita richiedono ognuna una subnet dedicata. Non è possibile distribuire altre risorse in queste subnet. Una macchina virtuale collegata a un set di regole di inoltro non deve essere sottoposta a peering con la macchina virtuale del resolver. I collegamenti del set di regole funzionano indipendentemente dal peering VNet.

Come scegliere

Usare l'albero delle decisioni seguente per selezionare i componenti DNS corretti per l'ambiente in uso.

Albero delle decisioni

  1. Si usano endpoint privati?

    • Sì → Distribuire zone DNS privato con i nomi di zona appropriatiprivatelink.*. Collegare le zone alle reti virtuali che devono risolvere gli indirizzi degli endpoint privati.

  2. I sistemi locali devono risolvere Azure nomi privati?

    • Sì → Deploy DNS Private Resolver with an inbound endpoint (Distribuisci resolver privato DNS con un endpoint in ingresso). Configurate i server DNS locali con server di inoltro condizionale che puntano all'IP dell'endpoint di ingresso.

  3. I carichi di lavoro Azure devono risolvere i nomi locali?

    • Sì → Distribuisci il resolver DNS privato con endpoint in uscita. Creare set di regole di inoltro per i suffissi di dominio locali , ad esempio corp.contoso.com.

  4. Distribuite Firewall di Azure e avete bisogno del filtraggio FQDN nelle regole di rete?

    • Sì → Abilitare il proxy DNS del firewall. Configurare le VM spoke in modo che usino l'indirizzo IP privato del firewall come server DNS.

  5. Vuoi bloccare le query DNS verso domini malevoli noti?

    • Sì → Abilitare il criterio di sicurezza DNS con il feed di Microsoft Threat Intelligence nelle macchine virtuali di destinazione.

Modelli comuni

Modello Components Caso di utilizzo
Solo risoluzione di endpoint privati DNS privato zone e collegamenti di rete virtuale Carichi di lavoro esclusivamente nel cloud che accedono a servizi PaaS tramite endpoint privati. Nessuna connettività ibrida.
Risoluzione bidirezionale ibrida DNS privato zone + Sistema di risoluzione privato DNS (in ingresso e in uscita) L'ambiente locale risolve i nomi privati di Azure; Azure risolve i nomi di Active Directory locali.
DNS hub centralizzato Resolver privato DNS nella rete virtuale dell'hub e set di regole di inoltro collegati agli spoke Topologia hub-spoke in cui tutta la risoluzione DNS passa attraverso l'hub per la registrazione centralizzata e il controllo centralizzato.
DNS mediato dal firewall Firewall di Azure proxy DNS e zone di DNS privato Ambienti che usano firewall per il filtro FQDN. Il firewall intercetta il traffico DNS, consentendo una risoluzione coerente da FQDN a IP per le regole di rete.
Stack di sicurezza completo Tutte le opzioni precedenti, oltre ai criteri di sicurezza DNS Ambienti aziendali che richiedono la risoluzione ibrida, il filtro FQDN e la protezione dalle minacce a livello DNS.

Esempi di zona DNS dell'endpoint privato

Nella tabella seguente sono elencati i servizi di Azure comuni e i relativi nomi di zona DNS privato necessari.

Servizio di Azure Nome della zona DNS privata
Archiviazione BLOB di Azure (Servizio di archiviazione Blob di Azure) privatelink.blob.core.windows.net
Database SQL di Microsoft Azure privatelink.database.windows.net
Azure Key Vault (Archivio chiavi di Azure) privatelink.vaultcore.azure.net
File di Azure privatelink.file.core.windows.net
Registro dei container di Azure privatelink.azurecr.io
Azure Cosmos DB (API SQL) privatelink.documents.azure.com

Note

Per l'elenco completo dei nomi delle zone DNS private per tutti i servizi Azure, vedere Configurazione DNS dell'endpoint privato di Azure.

Prerequisiti

Prima di implementare la sicurezza DNS e la risoluzione dei nomi privati, assicurarsi di disporre di:

  • Una rete virtuale: Tutte le funzionalità DNS operano all'interno o tra reti virtuali. Per indicazioni fondamentali, vedere Reti virtuali e subnet . (F1)
  • Connettività di rete per scenari ibridi: Gli endpoint in ingresso del sistema di risoluzione privato DNS richiedono la raggiungibilità della rete dall'ambiente locale (ExpressRoute o VPN) alla rete virtuale del resolver.
  • Subnet dedicate per il sistema di risoluzione privato DNS: Ogni endpoint (in ingresso e in uscita) richiede la propria subnet delegata a Microsoft.Network/dnsResolvers. Pianificare almeno /28 per ogni subnet dell'endpoint.
  • Endpoint privati distribuiti (se si utilizzano zone privatelink): Le zone DNS private per i soli nomi privatelink.* sono utili solo quando esistono endpoint privati. Per indicazioni sulla distribuzione, vedere Accesso PaaS privato con endpoint privati . (C5)
  • Firewall di Azure distribuita (se si usa il proxy DNS): la funzionalità proxy DNS richiede un'istanza di Firewall di Azure esistente. Vedere Firewall di Azure e ispezione del traffico. (S1)
  • Autorizzazioni: Ruolo Collaboratore zona DNS per la gestione delle zone DNS privato. Collaboratore alla rete per la distribuzione del resolver privato DNS.

Considerazioni relative alla sicurezza

DNS introduce vettori di attacco specifici che richiedono controlli dedicati. Le sezioni seguenti illustrano i rischi di esfiltrazione, il blocco basato sulle minacce, il comportamento del proxy DNS del firewall e le limitazioni DNSSEC.

Rischi di esfiltrazione DNS

Il tunneling DNS codifica i dati nelle query DNS per esfiltrare le informazioni tramite un protocollo altrimenti senza restrizioni. Poiché la maggior parte delle reti consente il DNS in uscita (UDP/TCP 53), gli utenti malintenzionati usano DNS come canale di copertura. Attenuare questo rischio in base a:

  • Abilitare il proxy DNS di Firewall di Azure e instradare tutto il traffico DNS tramite il firewall. Il firewall registra tutte le query DNS, rendendo il tunneling rilevabile tramite l'analisi.
  • Applicazione dei criteri di sicurezza DNS per bloccare la risoluzione dei domini associati agli strumenti di esfiltrazione noti e all'infrastruttura di comando e controllo.
  • Monitoraggio dei modelli di query DNS in Monitoraggio di Azure per individuare anomalie quali etichette di sottodominio insolitamente lunghe, volumi di query elevati in un singolo dominio o query nei domini registrati di recente.

Criteri di sicurezza DNS

I criteri di sicurezza DNS con Microsoft Threat Intelligence bloccano la risoluzione DNS a domini dannosi noti a livello di rete virtuale. Quando un carico di lavoro tenta di risolvere un dominio contrassegnato da Microsoft Security Response Center (MSRC), i criteri bloccano la risoluzione prima che si verifichi una connessione di rete. Questo controllo funziona indipendentemente da Firewall di Azure e non richiede modifiche alle singole configurazioni del carico di lavoro.

Caratteristiche chiave:

  • Usa il feed di intelligence sulle minacce di Microsoft proveniente da MSRC.
  • Opera a livello di risoluzione DNS: blocca la query, non il traffico.
  • Applicato per ogni rete virtuale: abilitare in tutte le reti virtuali contenenti carichi di lavoro che accedono a Internet.
  • Diverso dal filtro FQDN del firewall: i criteri di sicurezza DNS bloccano i domini dannosi a livello globale senza richiedere la distribuzione del firewall.

Proxy DNS e filtraggio FQDN del firewall

Il proxy DNS di Firewall di Azure è necessario per il filtraggio basato su FQDN nelle regole di rete. Senza proxy DNS, le richieste DNS dalle macchine virtuali client potrebbero risolversi in momenti diversi rispetto alla risoluzione del firewall, causando mapping incoerente da IP a FQDN e mancata corrispondenza delle regole.

Quando si abilita il proxy DNS:

  • Configurare le VM spoke in modo che usino l'indirizzo IP privato del firewall come server DNS.
  • Il firewall risolve le query per conto dei client e memorizza nella cache i risultati (cache positiva fino a 1 ora, cache negativa fino a 30 minuti).
  • Le associazioni da FQDN a IP vengono aggiornate ogni 15 secondi. Il firewall rimuove le voci obsolete dopo 15 minuti.
  • Le regole dell'applicazione (L7) usano LNI (Server Name Indication) per la corrispondenza FQDN e non richiedono il proxy DNS. Le regole di rete (L4) richiedono il proxy DNS per la risoluzione FQDN.
  • Il filtro FQDN nelle regole di rete supporta solo corrispondenze esatte del dominio. I pattern jolly non sono supportati negli FQDN delle regole di rete. Usare le regole dell'applicazione per la corrispondenza FQDN con caratteri jolly.

Note

Se tutti i server DNS upstream configurati diventano non disponibili, il proxy DNS di Firewall di Azure non passa a un resolver alternativo. La risoluzione DNS fallisce finché almeno un server upstream non torna disponibile. Pianificare la ridondanza del server DNS nella configurazione upstream.

Attenzione

Se si abilita il proxy DNS ma non si configurano le macchine virtuali client per l'uso del firewall come server DNS, le regole di rete basate su FQDN non funzioneranno correttamente. I client e il firewall potrebbero risolvere indirizzi IP diversi per lo stesso FQDN, causando cali imprevisti del traffico.

Limitazioni di DNSSEC

DNS di Azure attualmente non supporta la convalida DNSSEC per le zone private. Le zone pubbliche ospitate in DNS di Azure supportano la firma DNSSEC per le risposte autorevoli, ma la risoluzione ricorsiva all'interno delle reti virtuali Azure non esegue la convalida DNSSEC. Se i requisiti di sicurezza impongono la convalida DNSSEC, valutare l'uso di un resolver DNS personalizzato che supporta la convalida o implementare la verifica a livello di applicazione.

Considerazioni relative alla progettazione

Focus sulla progettazione DNS lift-and-shift

  • Configurare l'inoltro DNS bidirezionale tra i server DNS locali e DNS di Azure resolver privato.
  • Utilizzare server di inoltro condizionale in modo che le query locali per i nomi ospitati in Azure vengano risolte in Azure e che le query di Azure per i nomi locali vengano risolte tramite l'infrastruttura DNS esistente.
  • Creare DNS privato zone per ogni servizio di Azure che usano i carichi di lavoro migrati, in particolare i servizi basati su endpoint privato.
  • Mantenere il comportamento DNS dell'applicazione durante la migrazione usando record alias o mapping CNAME anziché modificare le impostazioni del resolver client.

Modernizzare il focus sulla progettazione DNS

  • Centralizza la risoluzione DNS nell'hub tramite DNS di Azure Private Resolver con set di regole per l'inoltro condivisi tra reti virtuali spoke.
  • Associare le zone DNS private per ogni servizio PaaS supportato da endpoint privato, in modo che i carichi di lavoro ripiattaformati risolvano automaticamente i nomi privatelink.
  • Abilitare il proxy DNS Firewall di Azure in modo che le regole di rete basate su FQDN e la risoluzione DNS del carico di lavoro usino un percorso di risoluzione coerente e memorizzato nella cache.
  • Usare la registrazione automatica e il controllo degli accessi in base al ruolo di Azure nelle zone DNS private per ridurre la gestione manuale dei record DNS con l'adozione dell'infrastruttura come codice.

Focus sulla progettazione DNS tra cloud

  • Usare Resolver privato DNS di Azure come punto di controllo per l'inoltro della risoluzione dei nomi multi-cloud.
  • Configura l'inoltro condizionale tra il DNS privato di Azure, Resolver Route 53 di AWS e Cloud DNS di Google per ogni spazio dei nomi privato che deve essere risolto tra ambienti diversi.
  • Pianificare il cutover DNS in fasi: valori TTL inferiori, convalidare i percorsi di inoltro, modificare i record CNAME o A e monitorare la latenza delle query e il comportamento della cache.
  • Applicare DNSSEC nelle zone autorevoli in cui le piattaforme connesse lo supportano e documentare dove i percorsi di risoluzione privata non convalidano DNSSEC.

Ulteriori informazioni

Passaggi successivi

Tip

Esplorazione da sola? Tornare allo strumento di navigazione di panoramica per trovare l'articolo successivo in base alla funzionalità.

Successivamente, nel viaggio in modalità lift-and-shift:

Controllare il traffico Internet in uscita: centralizzare tutte le comunicazioni in uscita tramite Firewall di Azure e disattivare l'accesso in uscita predefinito.

Nel prossimo percorso di modernizzazione:

Configurare il monitoraggio della produzione: abilitare Network Watcher e Monitor prestazioni di rete per l'idoneità alla produzione da un giorno all'altro.

Il prossimo passo nel tuo percorso multicloud:

Proteggere il percorso di transito tra cloud: distribuire Firewall di Azure nell'hub virtuale sicuro per controllare tutto il traffico tra cloud, rami e internet.

  • Last updated on