Usare una configurazione DNS split-brain per ospitare un'applicazione web in Azure

Frontdoor di Azure
Gateway applicazione di Azure
Azure ExpressRoute
DNS di Azure

I team che gestiscono i carichi di lavoro spesso si basano su nomi di dominio completi (FQDN) per l'accesso dei clienti. I nomi di dominio completi (FQDN) vengono in genere combinati con l'indicazione del nome del server TLS (Transport Layer Security) SNI (Server Name Indication). Con questo approccio, quando i clienti pubblici accedono a un carico di lavoro dalla rete Internet pubblica o dai clienti aziendali accedono internamente a un carico di lavoro, il routing all'applicazione potrebbe seguire percorsi fissi e avere diversi livelli di sicurezza o qualità del servizio (QoS).

L'architettura seguente illustra un approccio per distinguere il modo in cui il traffico viene gestito in base al DNS (Domain Name System) e se il cliente ha origine da Internet o da una rete aziendale.

Architecture

Diagramma dell'architettura di hosting dell'applicazione.

Scaricare un file di Visio di questa architettura.

Le sezioni del flusso di lavoro seguenti descrivono due configurazioni: un flusso di lavoro Internet pubblico e un flusso di lavoro privato. Unire i due workflow per implementare un'architettura di hosting split-brain.

Flusso di lavoro Internet pubblico

Diagramma del flusso di lavoro Internet pubblico.

Scaricare un file di Visio di questa architettura.

  1. I clienti inviano una richiesta per l'applicazione app.contoso.com tramite internet pubblico.

  2. Viene configurata una zona DNS di Azure per il dominio contoso.com. Le voci di nome canonico (CNAME) appropriate sono configurate per gli endpoint di Frontdoor di Azure.

  3. I clienti esterni accedono all'applicazione Web tramite Frontdoor di Azure Standard o Premium, che funziona come un servizio di bilanciamento del carico globale e un web application firewall (WAF).

    • All'interno di Frontdoor di Azure, app.contoso.com viene assegnato come FQDN tramite route in un endpoint configurato. Frontdoor di Azure ospita anche i certificati SNI TLS per le applicazioni.

      Note

      Frontdoor di Azure non supporta i certificati autofirmato.

    • Frontdoor di Azure instrada le richieste al gruppo di origine configurato in base all'intestazione HTTP Host del cliente.

    • Il gruppo di origine è configurato per puntare all'istanza di gateway applicazione di Azure tramite l'indirizzo IP pubblico dell'Application Gateway.

  4. Un gruppo di sicurezza di rete (NSG) è configurato sulla subnet AppGW per consentire l'accesso in ingresso sulla porta 80 e sulla porta 443 dal tag del servizio AzureFrontDoor.Backend. Il gruppo di sicurezza di rete non consente il traffico in ingresso sulla porta 80 e sulla porta 443 dal tag del servizio Internet.

    Note

    Il tag del servizio AzureFrontDoor.Backend non limita il traffico esclusivamente all'istanza di Frontdoor di Azure. La convalida viene eseguita nella fase successiva.

  5. L'istanza del gateway applicativo ha un listener sulla porta 443. Il traffico viene indirizzato al back-end in base al nome host specificato all'interno del listener.

    • Per assicurarsi che il traffico provenga dal tuo profilo di Frontdoor di Azure, configurare una regola WAF personalizzata per controllare il valore dell'intestazione X-Azure-FDID.

    • Azure genera un identificatore univoco per ogni profilo frontdoor di Azure. L'identificatore univoco è il valore Frontdoor di Azure ID disponibile nella pagina di panoramica del portale di Azure.

  6. Il traffico raggiunge la risorsa di calcolo configurata come pool back-end nel Gateway Applicazione.

Flusso di lavoro aziendale privato

Diagramma del flusso di lavoro aziendale privato.

Scaricare un file di Visio di questa architettura.

  1. I clienti avviano una richiesta per l'applicazione app.contoso.com da un ambiente locale.

  2. I nomi di dominio completi dell'applicazione vengono configurati nel provider DNS locale. Questo provider DNS può essere server DNS Active Directory Domain Services (AD DS) locali o altre soluzioni partner. Le voci DNS per ogni FQDN dell'applicazione sono configurate per puntare all'indirizzo IP privato dell'istanza dell'Application Gateway.

  3. Un circuito Azure ExpressRoute o una VPN da sito a sito facilita l'accesso al gateway applicazione.

  4. Un NSG viene configurato nella subnet AppGW per consentire le richieste private in ingresso dalle reti dei clienti in sede da cui proviene il traffico. Questa configurazione garantisce che altre origini di traffico privato non possano raggiungere direttamente l'indirizzo IP privato del gateway applicazione.

  5. L'gateway applicativo ha un listener configurato sulla porta 80 e sulla porta 443. Il traffico viene indirizzato al back-end in base al nome host specificato all'interno del listener.

  6. Solo il traffico di rete privato raggiunge il sistema di calcolo configurato come pool back-end in Application Gateway.

Components

  • DNS è un sistema che esegue il mapping dei nomi di dominio agli indirizzi IP, che consente ai client di individuare e connettersi ai servizi. Per un flusso di lavoro Internet pubblico in questa architettura, è necessario configurare una zona DNS pubblica con il CNAME appropriato dell'FQDN dell'endpoint Frontdoor di Azure. Sul lato privato (aziendale), configurare il provider DNS locale (DNS di Active Directory Domain Services o una soluzione partner) per puntare ogni FQDN dell'applicazione all'indirizzo IP privato di Application Gateway.

  • DNS di Azure Resolver privato è un servizio completamente gestito che consente la risoluzione DNS tra ambienti locali e Azure senza distribuire server DNS personalizzati. In questa architettura, il sistema di risoluzione privato DNS consente la risoluzione dei clienti locali, in modo che gli utenti aziendali possano usare questa soluzione DNS split-brain per accedere alle applicazioni senza attraversare la rete Internet pubblica.

  • Frontdoor di Azure è un servizio di bilanciamento del carico globale e WAF che fornisce la distribuzione rapida e sicura di applicazioni Web ai clienti globali. In questa architettura, Frontdoor di Azure Standard o Premium indirizza i clienti esterni all'istanza di Application Gateway e offre opzioni di memorizzazione nella cache e ottimizzazione per migliorare l'esperienza dei clienti.

  • Il gateway applicativo è un servizio di bilanciamento del carico regionale e WAF che offre disponibilità elevata, scalabilità e sicurezza per le applicazioni Web. In questa architettura, Application Gateway indirizza le richieste esterne e interne dei clienti al backend e protegge l'applicazione web dai comuni attacchi web.

    Sia Frontdoor di Azure che il gateway applicazione offrono funzionalità WAF, ma il flusso di lavoro privato in questa soluzione non usa Frontdoor di Azure. Di conseguenza, entrambe le architetture usano la funzionalità WAF del gateway applicativo.

  • ExpressRoute è un servizio che estende le reti locali nel cloud tramite una connessione privata stabilita da un provider di connettività. In questa architettura, ExpressRoute facilita la connettività privata ad Application Gateway per i clienti on-premises.

Alternatives

Come soluzione alternativa, è possibile rimuovere Frontdoor di Azure Standard o Premium e puntare invece il record DNS pubblico all'indirizzo IP pubblico di Application Gateway. In base ai requisiti di questa architettura, è necessario cache e ottimizzare il traffico nel punto di ingresso in Azure. Di conseguenza, non è possibile usare la soluzione alternativa per questo scenario. Per altre informazioni, vedere Ottimizzazione costi.

Diagramma dell'architettura di hosting DNS split brain alternativa.

Scaricare un file di Visio di questa architettura.

Altre possibili alternative per il traffico in ingresso pubblico in questa architettura includono:

  • Gestione traffico di Azure: Gestione traffico è un servizio di routing del traffico basato su DNS che distribuisce il traffico tra diverse aree ed endpoint. È possibile usare Traffic Manager anziché Frontdoor di Azure Standard o Premium per instradare i clienti esterni all'istanza più vicina di Application Gateway. Tuttavia, Frontdoor di Azure offre funzionalità, ad esempio funzionalità WAF, memorizzazione nella cache e affinità di sessione. Gestione traffico non fornisce queste funzionalità.

  • Azure Load Balancer: Azure Load Balancer è un servizio di bilanciamento del carico di rete che offre disponibilità elevata e scalabilità per il traffico TCP (Transmission Control Protocol) e UDP (User Datagram Protocol). È possibile usare "Load Balancer" anziché "Application Gateway" per instradare le richieste dei clienti sia esterne che interne ai server Web back-end. Tuttavia, Application Gateway fornisce funzionalità, come le capacità WAF, la terminazione del Secure Sockets Layer (SSL) e l'affinità di sessione basata su cookie. Load Balancer non fornisce queste funzionalità.

Dettagli dello scenario

Questo scenario risolve il problema di hosting di un'applicazione Web che serve sia clienti esterni che interni. Questa architettura garantisce che il traffico segua un percorso appropriato in base all'origine di un cliente. Questa architettura:

  • Fornisce accesso rapido e affidabile tramite Internet a un'applicazione Web per i clienti non aziendali globali.

  • Offre ai clienti aziendali la possibilità di accedere a un'applicazione senza attraversare la rete Internet pubblica.

  • Protegge un'applicazione Web da attacchi Web comuni e da traffico dannoso.

Casi d'uso potenziali

Usare questa architettura per gli scenari che richiedono:

  • Split-brain DNS: Questa soluzione usa Frontdoor di Azure per i clienti esterni e il gateway applicazione per i clienti interni, con record DNS diversi per ogni servizio. Questo approccio consente di ottimizzare le prestazioni di rete, la sicurezza e la disponibilità per vari clienti.

  • Scalabilità delle applicazioni: Questa soluzione usa il gateway applicazione, che consente di distribuire il traffico tra le risorse di calcolo back-end configurate. Questo approccio consente di migliorare le prestazioni e la disponibilità dell'applicazione e supportare il ridimensionamento orizzontale.

Considerations

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Reliability

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.

  • Identificare i punti di errore. In questa architettura DNS split-brain, l'affidabilità dipende dal corretto funzionamento dei componenti chiave, ad esempio Frontdoor di Azure, l'Application Gateway e le configurazioni DNS. È necessario identificare i potenziali punti di errore, ad esempio errori di configurazione, problemi di certificato SSL o overload di capacità.

  • Valutare l'impatto. È necessario valutare l'impatto degli errori. Per i clienti esterni, qualsiasi interruzione di Frontdoor di Azure, che funge da gateway, potrebbe influire sull'accesso globale. Per i clienti interni, eventuali interruzioni del gateway applicazione potrebbero impedire le operazioni aziendali.

  • Implementare strategie di mitigazione. Per ridurre i rischi, implementare la ridondanza in più zone di disponibilità, usare probe di integrità per il monitoraggio in tempo reale e garantire la configurazione corretta del routing DNS per il traffico esterno e interno. Assicurarsi di aggiornare regolarmente i record DNS e di disporre di un piano di ripristino di emergenza.

  • Monitorare continuamente. Per tenere d'occhio la salute del sistema, impiega le funzionalità di Monitoraggio di Azure. Configurare avvisi per le anomalie e avere un piano di risposta agli eventi imprevisti pronto per risolvere tempestivamente potenziali problemi.

Rispettare questi principi per garantire un sistema affidabile e affidabile in grado di resistere alle sfide e mantenere la continuità del servizio.

Security

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per la sicurezza.

  • Usare l'approccio Zero Trust. Nella configurazione DNS split-brain applicare l'approccio Zero Trust. Verificare in modo esplicito l'identità di un cliente, indipendentemente dal fatto che provengano da Internet o da una rete aziendale. Questo approccio garantisce che solo le entità attendibili possano eseguire azioni autorizzate.

  • Implementare in modo efficace i controlli di identità e accesso. Implementare Microsoft Entra ID per una gestione affidabile delle identità. Usare i criteri di accesso condizionale di Microsoft Entra per applicare controlli di accesso rigorosi in base al contesto del cliente, all'integrità dei dispositivi e alla posizione.

    • Valutare le misure di sicurezza. Valutare l'efficacia delle misure di sicurezza per il carico di lavoro a doppio accesso implementando:

      • Valutare regolarmente gli investimenti difensivi. Valutare regolarmente l'efficacia di Frontdoor di Azure e Application Gateway. Assicurarsi che forniscano una protezione significativa dalle minacce.

      • Limitare l'ambito di impatto di potenziali violazioni. Assicurarsi di contenere violazioni della sicurezza all'interno di un ambito limitato. Ad esempio, isolare efficacemente i flussi di traffico esterni e interni.

  • Si supponga che una violazione sia sempre possibile. Riconoscere che gli utenti malintenzionati possono violare i controlli di sicurezza. Prepararsi per questi scenari.

  • Implementare misure di sicurezza in modo completo. Implementare la segmentazione di rete, la micro-segmentazione e i gruppi di sicurezza di rete. Si supponga che un utente malintenzionato possa ottenere l'accesso e progettare controlli di compensazione di conseguenza.

Integrare questi principi di sicurezza nell'architettura DNS split-brain per creare un sistema affidabile e resiliente che protegge l'accesso interno ed esterno al carico di lavoro.

Altri miglioramenti alla sicurezza

  • Application Gateway: È possibile usare un WAF sul Application Gateway per proteggere le applicazioni web da vulnerabilità e exploit web comuni. È anche possibile usare il collegamento privato di Azure per accedere in modo sicuro ai server applicazioni back-end dal gateway applicazione senza esporli alla rete Internet pubblica.

  • Firewall di Azure: È possibile aggiungere un Azure firewall alla rete virtuale hub e usare Firewall di Azure intelligence sulle minacce per bloccare il traffico dannoso da indirizzi IP e domini dannosi noti. È anche possibile usare Firewall di Azure come proxy DNS per intercettare ed esaminare il traffico DNS e applicare regole di filtro DNS.

  • Frontdoor di Azure: È possibile usare Web application firewall di Azure per proteggere le applicazioni Web da vulnerabilità Web e exploit comuni nei dispositivi perimetrali. È anche possibile usare il collegamento privato con il livello Frontdoor di Azure Premium per accedere in modo sicuro ai server applicazioni back-end da Frontdoor di Azure senza esporli alla rete Internet pubblica.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Ottimizzazione costi.

  • Calcolo back-end: Molti fattori, ad esempio la selezione dello SKU, il numero di repliche e l'area, determinano il costo dell'esecuzione di servizi di calcolo back-end. Assicurarsi di considerare tutti gli elementi di una risorsa di calcolo prima di selezionare l'opzione migliore per il carico di lavoro.

  • Gateway applicazione: I costi del gateway applicazione dipendono dal numero di istanze, dalle dimensioni delle istanze e dalla quantità di dati elaborati. È possibile ottimizzare i costi usando la scalabilità automatica per regolare il numero di istanze in base alla domanda di traffico. È anche possibile distribuire SKU a ridondanza di zona nelle zone di disponibilità per ridurre la necessità di istanze aggiuntive per garantire alta disponibilità.

  • Frontdoor di Azure: Frontdoor di Azure i costi dipendono dal numero di regole di routing, dal numero di richieste HTTP o HTTPS e dalla quantità di dati trasferiti. È possibile usare Frontdoor di Azure Standard o Premium per ottenere un'esperienza unificata con Rete di distribuzione dei contenuti di Azure, Web application firewall di Azure e collegamento privato. È anche possibile usare la funzionalità del motore regole di Frontdoor di Azure per personalizzare la gestione del traffico e ottimizzare le prestazioni e i costi.

Se lo scenario non richiede l'accesso globale o le funzionalità aggiuntive di Frontdoor di Azure, è possibile usare questa soluzione solo con il gateway applicazione. È possibile indirizzare tutti i record DNS pubblici all'indirizzo IP pubblico configurato nei listener del Gateway Applicazione.

Vedere un esempio di questa soluzione che approssima l'utilizzo tipico dei componenti in questa architettura. Modificare i costi in base allo scenario.

Contributors

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autore principale:

Altri collaboratori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi