Rete e connettività per carichi di lavoro cruciali in Azure

La rete è un'area fondamentale per un'applicazione fondamentale, in base all'approccio di progettazione attivo distribuito a livello globale consigliato.

Questa area di progettazione esplora vari argomenti della topologia di rete a livello di applicazione, considerando la connettività necessaria e la gestione del traffico ridondante. In particolare, evidenzia considerazioni critiche e raccomandazioni destinate a informare la progettazione di una topologia di rete globale sicura e scalabile per un'applicazione critica.

Importante

Questo articolo fa parte della serie di carichi di lavoro cruciali di Azure Well-Architected . Se non si ha familiarità con questa serie, è consigliabile iniziare con un carico di lavoro mission-critical?

Routing del traffico globale

L'uso di più stamp di distribuzione a livello di area attiva richiede un servizio di routing globale per distribuire il traffico a ogni stamp attivo.

Frontdoor di Azure, Gestione traffico di Azure e Azure Load Balancer Standard offrono le funzionalità di routing necessarie per gestire il traffico globale in un'applicazione multi-area.

In alternativa, è possibile considerare tecnologie di routing globali di terze parti. Queste opzioni possono essere quasi facilmente scambiate in per sostituire o estendere l'uso dei servizi di routing globale nativi di Azure. Le scelte più comuni includono tecnologie di routing per provider di rete CDN.

In questa sezione vengono illustrate le differenze principali dei servizi di routing di Azure per definire la modalità di utilizzo di ognuno per ottimizzare scenari diversi.

Considerazioni relative alla progettazione

• Un servizio di routing associato a una singola area rappresenta un singolo punto di errore e un rischio significativo per quanto riguarda le interruzioni a livello di area.

• Se il carico di lavoro dell'applicazione include il controllo client, ad esempio con applicazioni client per dispositivi mobili o desktop, è possibile fornire la ridondanza del servizio all'interno della logica di routing client.

  • Più tecnologie di routing globali, ad esempio Frontdoor di Azure e Gestione traffico di Azure, possono essere considerate in parallelo per la ridondanza, con i client configurati per eseguire il failover in una tecnologia alternativa quando vengono soddisfatte determinate condizioni di errore. L'introduzione di più servizi di routing globale introduce complessità significative per la memorizzazione nella cache perimetrale e le funzionalità di Web application firewall e la gestione dei certificati per l'offload SSL e la convalida dell'applicazione per i percorsi in ingresso.
  • È anche possibile considerare tecnologie di terze parti, fornendo resilienza di routing globale a tutti i livelli di errori della piattaforma Azure.

• La disparità di funzionalità tra Frontdoor di Azure e Gestione traffico significa che se le due tecnologie sono posizionate tra loro per la ridondanza, è necessario un percorso diverso in ingresso o modifiche di progettazione per garantire che venga mantenuto un livello coerente e accettabile di servizio.

• Frontdoor di Azure e Gestione traffico di Azure sono servizi distribuiti a livello globale con ridondanza e disponibilità in più aree predefinite.

  • Gli scenari di errore ipotetici di una scalabilità sufficiente per minacciare la disponibilità globale di questi servizi di routing resilienti presentano un rischio più ampio per l'applicazione in termini di errori a catena e correlati.
    • Gli scenari di errore di questa scalabilità sono causati solo da servizi di base condivisi, ad esempio DNS di Azure o ID Microsoft Entra, che fungono da dipendenze della piattaforma globale per quasi tutti i servizi di Azure. Se viene applicata una tecnologia di Azure ridondante, è probabile che il servizio secondario verifichi anche un'indisponibilità o un servizio danneggiato.
    • Gli scenari di errore del servizio di routing globale hanno un impatto elevato su molti altri servizi usati per i componenti dell'applicazione chiave tramite dipendenze tra servizi. Anche se viene usata una tecnologia di terze parti, l'applicazione sarà probabilmente in uno stato non integro a causa dell'impatto più ampio del problema sottostante, ovvero il routing agli endpoint dell'applicazione in Azure fornirà comunque un valore minimo.

• La ridondanza del servizio di routing globale offre una mitigazione per un numero estremamente piccolo di scenari di errore ipotetici, in cui l'impatto di un'interruzione globale è vincolato al servizio di routing stesso.

  Per offrire una ridondanza più ampia agli scenari di interruzione globali, è possibile considerare un approccio di distribuzione attivo-cloud multi-cloud. Un approccio di distribuzione attiva multi-cloud introduce complessità operative significative, che rappresentano rischi significativi di resilienza, probabilmente superano i rischi ipotetici di un'interruzione globale.

• Per gli scenari in cui il controllo client non è possibile, è necessario eseguire una dipendenza su un singolo servizio di routing globale per fornire un punto di ingresso unificato per tutte le aree di distribuzione attive.

  • Quando vengono usati in isolamento rappresentano un singolo punto di errore a livello di servizio a causa di dipendenze globali, anche se sono disponibili ridondanza e disponibilità in più aree predefinite.
  • Il contratto di servizio fornito dal servizio di routing globale selezionato rappresenta il contratto di servizio composito raggiungibile al massimo, indipendentemente dal numero di aree di distribuzione considerate.

• Quando il controllo client non è possibile, è possibile considerare le mitigazioni operative per definire un processo per la migrazione a un servizio di routing globale secondario se un'interruzione globale disabilita il servizio primario. La migrazione da un servizio di routing globale a un'altra è in genere un processo lungo durate diverse ore, in particolare in cui viene considerata la propagazione DNS.

• Alcuni servizi di routing globale di terze parti forniscono un contratto di servizio al 100%. Tuttavia, il contratto di servizio storico e raggiungibile fornito da questi servizi è in genere inferiore al 100%.

  • Sebbene questi servizi forniscano riparazioni finanziarie per l'indisponibilità, si tratta di un aspetto poco significativo quando l'impatto dell'indisponibilità è significativo, ad esempio con scenari critici di sicurezza in cui la vita umana è in gioco. La ridondanza tecnologica o le mitigazioni operative sufficienti devono pertanto essere considerate anche quando il contratto di servizio legale annunciato è 100%.

Frontdoor di Azure

• Frontdoor di Azure offre il bilanciamento del carico HTTP/S globale e la connettività ottimizzata usando il protocollo Anycast con split TCP per sfruttare la rete backbone globale Microsoft.

  • Per ognuno degli endpoint back-end vengono mantenute diverse connessioni.
  • Le richieste client in ingresso vengono prima terminate nel nodo perimetrale più vicino al client di origine.
  • Dopo qualsiasi ispezione del traffico necessaria, le richieste vengono inoltrate sul backbone Microsoft al back-end appropriato usando connessioni esistenti o gestite dalla cache interna di un nodo perimetrale.
  • Questo approccio è molto efficiente nella distribuzione di volumi di traffico elevati sulle connessioni back-end.

• Fornisce una cache predefinita che serve contenuto statico dai nodi perimetrali. In molti casi d'uso, questo può anche eliminare la necessità di una rete di distribuzione di contenuti dedicata (CDN).

• Azure Web application firewall (WAF) può essere usato in Frontdoor di Azure e poiché viene distribuito in posizioni perimetrali di rete di Azure in tutto il mondo, ogni richiesta in ingresso recapitata da Frontdoor controllata nella rete perimetrale.

• Frontdoor di Azure protegge gli endpoint dell'applicazione dagli attacchi DDoS usando Azure DDoS protection Basic. Azure DDoS Standard offre funzionalità di protezione e rilevamento aggiuntive e più avanzate e possono essere aggiunte come livello aggiuntivo a Frontdoor di Azure.

• Frontdoor di Azure offre un servizio certificato completamente gestito. Abilita la sicurezza della connessione TLS per gli endpoint senza dover gestire il ciclo di vita del certificato.

• Frontdoor Premium di Azure supporta gli endpoint privati, consentendo al traffico di scorrere da Internet direttamente nelle reti virtuali di Azure. Ciò eliminerebbe la necessità di usare indirizzi IP pubblici nella rete virtuale per rendere accessibili i back-end tramite Frontdoor Premium di Azure.

• Frontdoor di Azure si basa su probe di integrità e endpoint di integrità back-end (URL) chiamati a intervalli per restituire un codice di stato HTTP che riflette se il back-end funziona normalmente, con una risposta HTTP 200 (OK) che riflette uno stato integro. Non appena un back-end riflette uno stato non integro, dal punto di vista di un determinato nodo perimetrale, tale nodo perimetrale interromperà l'invio di richieste. I back-end non integri vengono pertanto rimossi in modo trasparente dalla circolazione del traffico senza alcun ritardo.

• Supporta solo protocolli HTTP/S.

• Il WAF di Frontdoor di Azure e gateway applicazione WAF offre un set di funzionalità leggermente diverso, anche se supportano regole predefinite e personalizzate e possono essere impostate per funzionare in modalità di rilevamento o in modalità di prevenzione.

• Lo spazio IP back-end di Frontdoor può cambiare, ma Microsoft garantirà l'integrazione con gli intervalli IP di Azure e i tag di servizio. È possibile sottoscrivere intervalli IP di Azure e tag di servizio per ricevere notifiche su eventuali modifiche o aggiornamenti.

• Frontdoor di Azure supporta varie configurazioni di distribuzione del carico:

  • Latenza basata su: impostazione predefinita che instrada il traffico al back-end "più vicino" dal client; in base alla latenza delle richieste.
  • Basato su priorità: utile per le configurazioni attive-passive, dove il traffico deve sempre essere inviato a un back-end primario, a meno che non sia disponibile.
  • Ponderato: applicabile per le distribuzioni canary in cui viene inviata una determinata percentuale di traffico a un back-end specifico. Se più back-end hanno gli stessi pesi assegnati, viene usato il routing basato sulla latenza.

• Per impostazione predefinita, Frontdoor di Azure usa il routing basato sulla latenza che può causare situazioni in cui alcuni back-end ottengono molto più traffico in ingresso rispetto ad altri, a seconda della provenienza dei client.

• Se una serie di richieste client deve essere gestita dallo stesso back-end, l'affinità sessione può essere configurata nel front-end. Usa un cookie lato client per inviare richieste successive allo stesso back-end della prima richiesta, purché il back-end sia ancora disponibile.

Gestione traffico di Azure

• Gestione traffico di Azure è un servizio di reindirizzamento DNS.

  • Il payload effettivo della richiesta non viene elaborato, ma Gestione traffico restituisce il nome DNS di uno dei back-end del pool, in base alle regole configurate per il metodo di routing del traffico selezionato.
  • Il nome DNS back-end viene quindi risolto nell'indirizzo IP finale che viene successivamente chiamato direttamente dal client.

• La risposta DNS viene memorizzata nella cache e riutilizzata dal client per un periodo TTL (Time-To-Live) specificato e le richieste effettuate durante questo periodo verranno inviate direttamente all'endpoint back-end senza interazione con Gestione traffico. Elimina il passaggio di connettività aggiuntiva che offre vantaggi di costo rispetto a Frontdoor.

• Poiché la richiesta viene effettuata direttamente dal client al servizio back-end, è possibile sfruttare qualsiasi protocollo supportato dal back-end.

• Analogamente a Frontdoor di Azure, Gestione traffico di Azure si basa anche sui probe di integrità per comprendere se un back-end è integro e operativo normalmente. Se viene restituito un altro valore o non viene restituito alcun valore, il servizio di routing riconosce i problemi in corso e interromperà il routing delle richieste a tale back-end specifico.

  • Tuttavia, a differenza di Frontdoor di Azure, questa rimozione dei back-end non integri non è istantanea perché i client continueranno a creare connessioni al back-end non integro fino alla scadenza del TTL DNS e viene richiesto un nuovo endpoint back-end dal servizio Gestione traffico.
  • Inoltre, anche quando il TTL scade, non vi è alcuna garanzia che i server DNS pubblici possano rispettare questo valore, in modo che la propagazione DNS possa effettivamente richiedere molto più tempo per verificarsi. Ciò significa che il traffico può continuare a essere inviato all'endpoint non integro per un periodo di tempo sostenuto.

Azure Load Balancer Standard

Importante

La Load Balancer Standard tra aree è disponibile in anteprima con limitazioni tecniche. Questa opzione non è consigliata per i carichi di lavoro cruciali.

Suggerimenti per la progettazione

• Usare Frontdoor di Azure come servizio di routing del traffico globale primario per scenari HTTP/S. Frontdoor di Azure è fortemente consigliato per i carichi di lavoro HTTP/S perché fornisce il routing del traffico ottimizzato, il failover trasparente, gli endpoint back-end privati (con lo SKU Premium), la memorizzazione nella cache perimetrale e l'integrazione con Web application firewall (WAF).

• Per gli scenari dell'applicazione in cui è possibile il controllo client, applicare la logica di routing lato client per considerare gli scenari di failover in cui la tecnologia di routing globale primaria ha esito negativo. Due o più tecnologie di routing globali devono essere posizionate in parallelo per la ridondanza aggiunta, se il contratto di servizio singolo non è sufficiente. La logica client è necessaria per instradare la tecnologia ridondante in caso di errore del servizio globale.

  • È consigliabile usare due URL distinti, con uno applicato a ognuno dei diversi servizi di routing globale per semplificare l'esperienza di gestione complessiva dei certificati e la logica di routing per un failover.
  • Definire la priorità dell'uso di tecnologie di routing di terze parti come servizio di failover secondario, poiché questo ridurrà il numero più elevato di scenari di errore globali e le funzionalità offerte dai provider di rete CDN leader del settore consentiranno un approccio di progettazione coerente.
  • È necessario considerare anche l'instradamento diretto a un singolo timbro a livello di area anziché a un servizio di routing separato. Anche se ciò comporterà un livello di servizio degradato, rappresenta un approccio di progettazione molto più semplice.

Questa immagine mostra una configurazione del servizio di bilanciamento del carico globale ridondante con failover client usando Frontdoor di Azure come servizio di bilanciamento del carico globale primario.

Importante

Per attenuare davvero il rischio di errori globali all'interno della piattaforma Azure, è consigliabile considerare un approccio di distribuzione attiva multi-cloud, con stamp di distribuzione attivi ospitati in due o più provider di cloud e tecnologie di routing di terze parti ridondanti usate per il routing globale.

Azure può essere integrato in modo efficace con altre piattaforme cloud. Tuttavia, è consigliabile non applicare un approccio multi-cloud perché introduce una notevole complessità operativa, con definizioni e rappresentazioni diverse dell'integrità operativa tra le diverse piattaforme cloud. Questa complessità a sua volta introduce numerosi rischi di resilienza all'interno della normale operazione dell'applicazione, che superano molto i rischi ipotetici di un'interruzione della piattaforma globale.

• Anche se non è consigliabile, per i carichi di lavoro HTTP usando Gestione traffico di Azure per la ridondanza globale del routing in Frontdoor di Azure, valutare l'offload di Web application firewall (WAF) per gateway applicazione per il flusso di traffico accettabile tramite Frontdoor di Azure.
  • In questo modo verrà introdotto un punto di errore aggiuntivo al percorso di ingresso standard, un componente di percorso critico aggiuntivo da gestire e ridimensionare e comporta anche costi aggiuntivi per garantire la disponibilità elevata globale. Tuttavia, semplifica notevolmente lo scenario di errore fornendo coerenza tra i percorsi di ingresso accettabili e non accettabili tramite Frontdoor di Azure e Gestione traffico di Azure, entrambi in termini di esecuzione WAF, ma anche endpoint dell'applicazione privata.
  • La perdita della memorizzazione nella cache perimetrale in uno scenario di errore influisce sulle prestazioni complessive e deve essere allineata a un livello accettabile di servizio o mitigazione dell'approccio di progettazione. Per garantire un livello coerente di servizio, considerare l'offload della memorizzazione nella cache perimetrale in un provider di rete CDN di terze parti per entrambi i percorsi.

È consigliabile considerare un servizio di routing globale di terze parti al posto di due servizi di routing globale di Azure. Ciò offre il livello massimo di mitigazione degli errori e un approccio di progettazione più semplice poiché la maggior parte dei provider di rete CDN leader del settore offre funzionalità perimetrali in gran parte coerenti con quella offerta da Frontdoor di Azure.

Frontdoor di Azure

• Usare il servizio certificato gestito di Frontdoor di Azure per abilitare le connessioni TLS e rimuovere la necessità di gestire i cicli di vita dei certificati.

• Usare l'Web application firewall frontdoor di Azure (WAF) per fornire protezione al bordo da exploit Web comuni e vulnerabilità, ad esempio l'inserimento SQL.

• Usare la cache predefinita di Azure Frontdoor per gestire il contenuto statico dai nodi perimetrali.

  • Nella maggior parte dei casi questa operazione eliminerà anche la necessità di una rete per la distribuzione di contenuti (CDN) dedicata.

• Configurare i punti di ingresso della piattaforma applicazione per convalidare le richieste in ingresso tramite il filtro basato sull'intestazione usando X-Azure-FDID per assicurarsi che tutto il traffico venga eseguito attraverso l'istanza di Frontdoor configurata. Si consideri anche la configurazione di ACLing IP usando i tag del servizio Frontdoor per convalidare il traffico proveniente dallo spazio indirizzi IP back-end di Azure Frontdoor e dai servizi di infrastruttura di Azure. Ciò garantisce che i flussi di traffico attraverso Frontdoor di Azure a livello di servizio, ma il filtro basato sull'intestazione sarà comunque necessario per garantire l'uso di un'istanza di Frontdoor configurata.

• Definire un endpoint di integrità TCP personalizzato per convalidare le dipendenze downstream critiche all'interno di un timbro di distribuzione a livello di area, incluse le repliche della piattaforma dati, ad esempio Azure Cosmos DB nell'esempio fornito dall'implementazione di riferimento fondamentale. Se una o più dipendenze diventano non integre, il probe di integrità deve riflettere questa situazione nella risposta restituita in modo che l'intero timbro regionale possa essere estratto dalla circolazione.

• Assicurarsi che le risposte al probe di integrità vengano registrate e inserire tutti i dati operativi esposti da Frontdoor di Azure nell'area di lavoro log analytics globale per facilitare un sink di dati unificato e una singola visualizzazione operativa in tutta l'applicazione.

• A meno che il carico di lavoro non sia estremamente sensibile alla latenza, distribuire il traffico uniformemente in tutti i francobolli regionali considerati per usare in modo più efficace le risorse distribuite.

  • A questo scopo, impostare il parametro "Riservatezza latenza (Latenza aggiuntiva)" su un valore sufficiente per soddisfare le differenze di latenza tra le diverse aree del back-end. Assicurarsi che una tolleranza accettabile per il carico di lavoro dell'applicazione rispetto alla latenza complessiva della richiesta client.

• Non abilitare l'affinità sessione a meno che non sia richiesta dall'applicazione, poiché può avere un impatto negativo sul saldo della distribuzione del traffico. Con un'applicazione completamente senza stato, se viene seguito l'approccio di progettazione dell'applicazione mission-critical consigliato, qualsiasi richiesta potrebbe essere gestita da una delle distribuzioni regionali.

Gestione traffico di Azure

• Usare Gestione traffico per scenari non HTTP/S come sostituzione di Frontdoor di Azure. Le differenze di funzionalità determinano diverse decisioni di progettazione per le funzionalità cache e WAF e la gestione dei certificati TLS.

• Le funzionalità WAF devono essere considerate all'interno di ogni area per il percorso di ingresso di Gestione traffico usando gateway applicazione di Azure.

• Configurare un valore TTL adeguatamente basso per ottimizzare il tempo necessario per rimuovere un endpoint back-end non integro dalla circolazione nel caso in cui il back-end diventi non integro.

• Analogamente a con Frontdoor di Azure, è necessario definire un endpoint di integrità TCP personalizzato per convalidare le dipendenze downstream critiche all'interno di un timbro di distribuzione a livello di area, che deve essere riflesso nella risposta fornita dagli endpoint di integrità.

  Tuttavia, per Gestione traffico è consigliabile prendere in considerazione il failover a livello di servizio a livello di servizio. ad esempio "dog legging", per attenuare il potenziale ritardo associato alla rimozione di un back-end non integro a causa di errori di dipendenza, in particolare se non è possibile impostare un TTL basso per i record DNS.

• È consigliabile considerare i provider di rete CDN di terze parti per ottenere la memorizzazione nella cache perimetrale quando si usa Gestione traffico di Azure come servizio di routing globale primario. Se le funzionalità WAF perimetrali vengono offerte anche dal servizio di terze parti, è consigliabile prendere in considerazione per semplificare il percorso di ingresso e rimuovere potenzialmente la necessità di gateway applicazione.

Servizi per il recapito di applicazioni

Il percorso di ingresso di rete per un'applicazione mission-critical deve anche considerare i servizi di recapito delle applicazioni per garantire traffico in ingresso sicuro, affidabile e scalabile.

Questa sezione si basa sulle raccomandazioni di routing globale esplorando le funzionalità di distribuzione delle applicazioni chiave, considerando i servizi pertinenti, ad esempio Azure Load Balancer Standard, gateway applicazione di Azure e Azure Gestione API.

Considerazioni relative alla progettazione

• La crittografia TLS è fondamentale per garantire l'integrità del traffico utente in ingresso a un'applicazione critica, con l'offload TLS applicato solo al punto di ingresso di un timbro per decrittografare il traffico in ingresso. L'offload TLS Richiede la chiave privata del certificato TLS per decrittografare il traffico.

• Un Web application firewall fornisce la protezione da exploit e vulnerabilità Web comuni, ad esempio l'inserimento SQL o lo script cross site, ed è essenziale per ottenere l'aspirazione massima di affidabilità di un'applicazione mission-critical.

• Azure WAF offre una protezione predefinita rispetto alle prime 10 vulnerabilità OWASP usando set di regole gestite.

  • È anche possibile aggiungere regole personalizzate per estendere il set di regole gestite.
  • Azure WAF può essere abilitato all'interno di Frontdoor di Azure, gateway applicazione di Azure o rete CDN di Azure (attualmente in anteprima pubblica).
    • Le funzionalità offerte su ognuno dei servizi differiscono leggermente. Ad esempio, il WAF di Frontdoor di Azure fornisce la limitazione della velocità, il filtro geografico e la protezione del bot, che non sono ancora disponibili all'interno del waF gateway applicazione. Tuttavia, supportano tutte le regole predefinite e personalizzate e possono essere impostate per funzionare in modalità di rilevamento o modalità di prevenzione.
    • La roadmap per Azure WAF garantisce che venga fornito un set di funzionalità WAF coerente in tutte le integrazioni del servizio.

• Le tecnologie WAF di terze parti, ad esempio NVA e controller di ingresso avanzati all'interno di Kubernetes, possono essere considerate anche per fornire la protezione delle vulnerabilità necessarie.

• La configurazione WAF ottimale richiede in genere un'ottimizzazione ottimale, indipendentemente dalla tecnologia usata.

  Frontdoor di Azure

• Frontdoor di Azure accetta solo il traffico HTTP e HTTPS e elabora solo le richieste con un'intestazione nota Host . Questo blocco di protocolli consente di attenuare gli attacchi volumetrici distribuiti tra protocolli e porte e attacchi di amplificazione DNS e avvelenamento TCP.

• Frontdoor di Azure è una risorsa globale di Azure in modo che la configurazione venga distribuita a livello globale in tutte le posizioni perimetrali.

  • La configurazione delle risorse può essere distribuita su larga scala per gestire centinaia di migliaia di richieste al secondo.
  • Aggiornamenti alla configurazione, incluse le route e i pool back-end, sono semplici e non causano tempi di inattività durante la distribuzione.

• Frontdoor di Azure offre sia un servizio certificato completamente gestito che un metodo bring-your-own-certificate per i certificati SSL con connessione client. Il servizio certificato completamente gestito offre un approccio operativo semplificato e consente di ridurre la complessità nella progettazione complessiva eseguendo la gestione dei certificati all'interno di un'unica area della soluzione.

• Frontdoor di Azure ruota automaticamente i certificati "Gestiti" almeno 60 giorni prima della scadenza del certificato per proteggere da rischi di certificati scaduti. Se vengono usati certificati self-managed, i certificati aggiornati devono essere distribuiti entro 24 ore prima della scadenza del certificato esistente, in caso contrario, i client potrebbero ricevere errori di certificato scaduti.

• Gli aggiornamenti dei certificati comportano un tempo di inattività solo se Frontdoor di Azure viene spostato tra "Managed" e "Use Your Own Certificate".

• Frontdoor di Azure è protetto da Azure DDoS Protection Basic, integrato in Frontdoor per impostazione predefinita. In questo modo viene fornito il monitoraggio del traffico always-on, la mitigazione in tempo reale e anche la difesa dalle inondazioni dns di livello 7 comuni o dagli attacchi volumetrici di livello 3/4.

  • Queste protezioni consentono di mantenere la disponibilità di Frontdoor di Azure anche in caso di attacco DDoS. Gli attacchi DDoS (Distributed Denial of Service) possono eseguire il rendering di una risorsa mirata non disponibile con il traffico non legittimo.

• Frontdoor di Azure offre anche funzionalità WAF a livello di traffico globale, mentre gateway applicazione WAF deve essere fornito all'interno di ogni stamp di distribuzione a livello di area. Le funzionalità includono set di regole del firewall da proteggere da attacchi comuni, filtro geografico, blocco degli indirizzi, limitazione della frequenza e corrispondenza delle firme.

  Azure Load Balancer

• Lo SKU di azure basic Load Balancer non è supportato da un contratto di servizio e presenta diversi vincoli di funzionalità rispetto allo SKU Standard.

Suggerimenti per la progettazione

• Eseguire l'offload TLS in più posizioni possibili per mantenere la sicurezza semplificando il ciclo di vita della gestione dei certificati.

• Usare connessioni crittografate (ad esempio HTTPS) dal punto in cui si verifica l'offload TLS nei back-end dell'applicazione effettivi. Gli endpoint dell'applicazione non saranno visibili agli utenti finali, pertanto i domini gestiti da Azure, ad esempio azurewebsites.net o cloudapp.net, possono essere usati con certificati gestiti.

• Per il traffico HTTP(S), assicurarsi che le funzionalità WAF vengano applicate all'interno del percorso di ingresso per tutti gli endpoint esposti pubblicamente.

• Abilitare le funzionalità WAF in una singola posizione del servizio, a livello globale con Frontdoor di Azure o a livello regionale con gateway applicazione di Azure, poiché semplifica l'ottimizzazione della configurazione e ottimizza le prestazioni e i costi.

  Configurare WAF in modalità prevenzione per bloccare direttamente gli attacchi. Usare waF solo in modalità di rilevamento (ad esempio solo la registrazione ma non blocca le richieste sospette) quando la penalità delle prestazioni della modalità di prevenzione è troppo elevata. Il rischio aggiuntivo implicito deve essere completamente compreso e allineato ai requisiti specifici dello scenario del carico di lavoro.

• Assegnare priorità all'uso del WAF di Frontdoor di Azure poiché fornisce il set di funzionalità nativo di Azure più ricco e applica protezioni all'perimetro globale, che semplifica la progettazione complessiva e determina ulteriori efficienza.

• Usare Azure Gestione API solo quando si espone un numero elevato di API a client esterni o team di applicazioni diversi.

• Usare lo SKU di Azure Load Balancer Standard per qualsiasi scenario di distribuzione del traffico interno all'interno dei carichi di lavoro del servizio micros.

  • Fornisce un contratto di servizio pari al 99,99% quando viene distribuito in zone di disponibilità.
  • Fornisce funzionalità critiche, ad esempio la diagnostica o le regole in uscita.

• Usare Protezione di rete DDoS di Azure per proteggere gli endpoint pubblici ospitati all'interno di ogni rete virtuale dell'applicazione.

Memorizzazione nella cache e distribuzione di contenuti statici

Il trattamento speciale del contenuto statico, ad esempio immagini, JavaScript, CSS e altri file può avere un impatto significativo sull'esperienza utente complessiva e sul costo complessivo della soluzione. La memorizzazione nella cache del contenuto statico sul bordo può velocizzare i tempi di caricamento del client, che comporta un'esperienza utente migliore e può anche ridurre il costo per il traffico, le operazioni di lettura e l'alimentazione di calcolo nei servizi back-end coinvolti.

Considerazioni relative alla progettazione

• Non tutti i contenuti che una soluzione rende disponibile tramite Internet vengono generati dinamicamente. Le applicazioni servono entrambi gli asset statici (immagini, JavaScript, CSS, file di localizzazione e così via) e contenuto dinamico.
• I carichi di lavoro con contenuto statico a cui si accede frequentemente possono trarre vantaggio notevolmente dalla memorizzazione nella cache perché riduce il carico nei servizi back-end e riduce la latenza di accesso ai contenuti per gli utenti finali.
• La memorizzazione nella cache può essere implementata in modo nativo in Azure usando Frontdoor di Azure o la rete CDN (Content Delivery Network).
  • Frontdoor di Azure offre funzionalità di memorizzazione nella cache perimetrale nativa di Azure e funzionalità di routing per dividere il contenuto statico e dinamico.
    • Creando le regole di routing appropriate in Frontdoor di Azure, /static/* il traffico può essere reindirizzato in modo trasparente al contenuto statico.
  • È possibile implementare scenari di memorizzazione nella cache più complessi usando il servizio rete CDN di Azure per stabilire una rete di distribuzione di contenuti completa per volumi di contenuto statici significativi.
    • Il servizio rete CDN di Azure probabilmente sarà più conveniente, ma non fornisce le stesse funzionalità avanzate di routing e Web application firewall (WAF) consigliate per altre aree di progettazione di un'applicazione. Tuttavia, offre ulteriore flessibilità per l'integrazione con servizi simili da soluzioni di terze parti, ad esempio Akamai e Verizon.
  • Quando si confrontano i servizi frontdoor di Azure e rete CDN di Azure, è necessario esaminare i fattori decisionali seguenti:
    • È possibile eseguire regole di memorizzazione nella cache necessarie usando il motore delle regole.
    • Dimensioni del contenuto archiviato e del costo associato.
    • Prezzo al mese per l'esecuzione del motore regole (addebitato per richiesta in Frontdoor di Azure).
    • Requisiti del traffico in uscita (prezzo diverso in base alla destinazione).

Suggerimenti per la progettazione

• Il contenuto statico generato, ad esempio le copie di dimensioni dei file di immagine che non cambiano mai o raramente possono trarre vantaggio anche dalla memorizzazione nella cache. La memorizzazione nella cache può essere configurata in base ai parametri URL e con una durata di memorizzazione nella cache variabile.
• Separare il recapito di contenuto statico e dinamico agli utenti e distribuire contenuti pertinenti da una cache per ridurre il carico nei servizi back-end ottimizzano le prestazioni per gli utenti finali.
• Dato il consiglio forte (area di progettazione rete e connettività) di usare Frontdoor di Azure per il routing globale e i Web application firewall (WAF), è consigliabile assegnare priorità all'uso delle funzionalità di memorizzazione nella cache di Frontdoor di Azure a meno che non esistano lacune.

Integrazione della rete virtuale

Un'applicazione mission-critical include in genere requisiti per l'integrazione con altre applicazioni o sistemi dipendenti, che possono essere ospitati in Azure, in un altro cloud pubblico o in data center locali. Questa integrazione dell'applicazione può essere eseguita usando endpoint pubblici e internet o reti private tramite l'integrazione a livello di rete. In definitiva, il metodo in base al quale viene ottenuta l'integrazione dell'applicazione avrà un impatto significativo sulla sicurezza, sulle prestazioni e sull'affidabilità della soluzione e influisce fortemente sulle decisioni di progettazione all'interno di altre aree di progettazione.

Un'applicazione mission-critical può essere distribuita all'interno di una delle tre configurazioni di rete che determinano il modo in cui l'integrazione dell'applicazione può verificarsi a livello di rete.

1. Applicazione pubblicasenza connettività di rete aziendale.
2. Applicazione pubblicacon connettività di rete aziendale.
3. Applicazione privatacon connettività di rete aziendale.

Attenzione

Quando si distribuisce all'interno di una zona di destinazione di Azure, configurazione 1. deve essere distribuito all'interno di una zona di destinazione online, mentre 2) e 3) deve essere distribuito all'interno di una zona di destinazione connessa per facilitare l'integrazione a livello di rete.

Questa sezione illustra questi scenari di integrazione di rete, il livello nell'uso appropriato delle reti virtuali di Azure e dei servizi di rete di Azure per garantire che i requisiti di integrazione siano soddisfatti in modo ottimale.

Considerazioni sulla progettazione

Nessuna rete virtuale

• L'approccio di progettazione più semplice consiste nel non distribuire l'applicazione all'interno di una rete virtuale.

  • La connettività tra tutti i servizi considerati di Azure verrà fornita interamente tramite endpoint pubblici e il backbone di Microsoft Azure. La connettività tra endpoint pubblici ospitati in Azure attraversa solo il backbone Microsoft e non passa attraverso Internet pubblico.
  • La connettività a tutti i sistemi esterni all'esterno di Azure verrà fornita da Internet pubblico.

• Questo approccio di progettazione adotta "identità come perimetro di sicurezza" per fornire il controllo di accesso tra i vari componenti del servizio e la soluzione dipendente. Questa può essere una soluzione accettabile per scenari meno sensibili alla sicurezza. Tutti i servizi e le dipendenze delle applicazioni sono accessibili tramite un endpoint pubblico li lascia vulnerabili a vettori di attacco aggiuntivi orientati per ottenere l'accesso non autorizzato.

• Questo approccio di progettazione non è applicabile anche per tutti i servizi di Azure, poiché molti servizi, ad esempio il servizio Azure Kubernetes, hanno un requisito difficile per una rete virtuale sottostante.

Reti virtuali isolate

• Per attenuare i rischi associati agli endpoint pubblici non necessari, l'applicazione può essere distribuita all'interno di una rete autonoma che non è connessa ad altre reti.

• Le richieste client in ingresso richiedono comunque l'esposizione di un endpoint pubblico a Internet, ma tutte le comunicazioni successive possono trovarsi all'interno della rete virtuale usando endpoint privati. Quando si usa Azure Frontdoor Premium, è possibile instradare direttamente dai nodi perimetrali agli endpoint dell'applicazione privata.

• Sebbene la connettività privata tra i componenti dell'applicazione si verifichi sulle reti virtuali, tutte le connessioni con dipendenze esterne si basano comunque sugli endpoint pubblici.

  • La connettività ai servizi della piattaforma di Azure può essere stabilita con endpoint privati se supportato. Se esistono altre dipendenze esterne in Azure, ad esempio un'altra applicazione downstream, la connettività verrà fornita tramite endpoint pubblici e il backbone di Microsoft Azure.
  • La connettività a tutti i sistemi esterni ad Azure verrebbe fornita da Internet pubblico.

• Per gli scenari in cui non sono presenti requisiti di integrazione di rete per le dipendenze esterne, la distribuzione della soluzione all'interno di un ambiente di rete isolato offre la massima flessibilità di progettazione. Nessun vincolo di indirizzamento e routing associato all'integrazione di rete più ampia.

• Azure Bastion è un servizio PaaS completamente gestito dalla piattaforma che può essere distribuito in una rete virtuale e offre connettività RDP/SSH sicura alle macchine virtuali di Azure. Quando ci si connette tramite Azure Bastion, le macchine virtuali non necessitano di un indirizzo IP pubblico.

• L'uso delle reti virtuali dell'applicazione introduce complesse complessità di distribuzione all'interno di pipeline CI/CD, poiché sia il piano dati che l'accesso del piano di controllo alle risorse ospitate nelle reti private è necessario per facilitare le distribuzioni delle applicazioni.

  • Il percorso di rete privato sicuro deve essere stabilito per consentire agli strumenti CI/CD di eseguire azioni necessarie.
  • Gli agenti di compilazione privati possono essere distribuiti all'interno di reti virtuali dell'applicazione per l'accesso proxy alle risorse protette dalla rete virtuale.

Reti virtuali connesse

• Per gli scenari con requisiti di integrazione della rete esterna, le reti virtuali dell'applicazione possono essere connesse ad altre reti virtuali all'interno di Azure, un altro provider di servizi cloud o reti locali usando diverse opzioni di connettività. Ad esempio, alcuni scenari dell'applicazione potrebbero considerare l'integrazione a livello di applicazione con altre applicazioni line-of-business ospitate privatamente all'interno di una rete aziendale locale.

• La progettazione della rete dell'applicazione deve essere allineata all'architettura di rete più ampia, in particolare sugli argomenti come l'indirizzamento e il routing.

• La sovrapposizione di spazi di indirizzi IP tra aree di Azure o reti locali creerà una contesa principale quando viene considerata l'integrazione di rete.

  • Una risorsa di rete virtuale può essere aggiornata per considerare spazio indirizzi aggiuntivo, tuttavia, quando uno spazio indirizzi di rete virtuale di una rete peered modifica una sincronizzazione nel collegamento di peering, che disabilita temporaneamente il peering.
  • Azure riserva cinque indirizzi IP all'interno di ogni subnet, che devono essere considerati quando si determinano le dimensioni appropriate per le reti virtuali dell'applicazione e le subnet incluse.
  • Alcuni servizi di Azure richiedono subnet dedicate, ad esempio Azure Bastion, Firewall di Azure o gateway di Azure Rete virtuale. Le dimensioni di queste subnet di servizio sono molto importanti, poiché devono essere sufficienti per supportare tutte le istanze correnti del servizio considerando i requisiti di scalabilità futuri, ma non così grandi come gli indirizzi di rifiuti inutili.

• Quando è necessaria l'integrazione di rete cross-cloud o locale, Azure offre due soluzioni diverse per stabilire una connessione sicura.

  • Un circuito ExpressRoute può essere ridimensionato per fornire larghezza di banda fino a 100 Gbps.
  • Una rete privata virtuale (VPN) può essere ridimensionata per fornire una larghezza di banda aggregata fino a 10 Gbps nelle reti hub e spoke e fino a 20 Gbps in Azure rete WAN virtuale.

Nota

Quando si distribuisce all'interno di un'area di destinazione di Azure, tenere presente che qualsiasi connettività necessaria alle reti locali deve essere fornita dall'implementazione della zona di destinazione. La progettazione può usare ExpressRoute e altre reti virtuali in Azure usando rete WAN virtuale o una progettazione di rete hub-and-spoke.

• L'inclusione di percorsi di rete e risorse aggiuntive introduce considerazioni aggiuntive sull'affidabilità e sulle operazioni per l'applicazione per garantire che l'integrità venga mantenuta.

Suggerimenti per la progettazione

• È consigliabile distribuire soluzioni cruciali all'interno delle reti virtuali di Azure, dove possibile rimuovere endpoint pubblici non necessari, limitando la superficie di attacco dell'applicazione per ottimizzare la sicurezza e l'affidabilità.

  • Usare endpoint privati per la connettività ai servizi della piattaforma di Azure. Gli endpoint di servizio possono essere considerati per i servizi che supportano collegamento privato, se i rischi di esfiltrazione dei dati sono accettabili o ridotti tramite controlli alternativi.

• Per gli scenari dell'applicazione che non richiedono la connettività di rete aziendale, considerare tutte le reti virtuali come risorse temporanee sostituite quando viene eseguita una nuova distribuzione a livello di area.

• Quando ci si connette ad altre reti di Azure o locali, le reti virtuali dell'applicazione non devono essere considerate temporanee perché creano complicazioni significative in cui sono interessati i peering di rete virtuale e le risorse del gateway di rete virtuale. Tutte le risorse dell'applicazione pertinenti all'interno della rete virtuale devono continuare a essere temporanee, con subnet parallele usate per facilitare le distribuzioni blu-verdi di stamp di distribuzione a livello di area aggiornate.

• Negli scenari in cui è necessaria la connettività di rete aziendale per facilitare l'integrazione dell'applicazione sulle reti private, assicurarsi che lo spazio indirizzi IPv4 usato per le reti virtuali dell'applicazione a livello di area non si sovrapponga ad altre reti connesse e sia ridimensionato correttamente per facilitare la scalabilità necessaria senza dover aggiornare la risorsa di rete virtuale e comportare tempi di inattività.

  • È consigliabile usare solo gli indirizzi IP dall'allocazione degli indirizzi per Internet privato (RFC 1918).
    • Per gli ambienti con una disponibilità limitata di indirizzi IP privati (RFC 1918), valutare l'uso di IPv6.
    • Se è necessario l'uso dell'indirizzo IP pubblico, assicurarsi che vengano usati solo i blocchi di indirizzi di proprietà.
  • Allinearsi ai piani dell'organizzazione per l'indirizzamento IP in Azure per garantire che lo spazio indirizzi IP di rete dell'applicazione non si sovrapponga ad altre reti tra posizioni locali o aree di Azure.
  • Non creare reti virtuali di applicazioni di grandi dimensioni inutilmente grandi per assicurarsi che lo spazio degli indirizzi IP non venga sprecato.

• Definire la priorità dell'uso di Azure CNI per l'integrazione della rete del servizio Azure Kubernetes, poiché supporta un set di funzionalità più avanzato.

  • Prendere in considerazione Kubenet per gli scenari con un limitato indirizzo IP disponibile per adattare l'applicazione all'interno di uno spazio indirizzi vincolato.

  • Definire la priorità dell'uso del plug-in di rete CNI di Azure per l'integrazione della rete del servizio Azure Kubenet e prendere in considerazione Kubenet per scenari con un intervallo limitato di indirizzi IP disponibili. Per altre informazioni, vedere Micro-segmentazione e criteri di rete kubernetes .

• Per gli scenari che richiedono l'integrazione della rete locale, assegnare priorità all'uso di Express Route per garantire la connettività sicura e scalabile.

  • Assicurarsi che il livello di affidabilità applicato a Express Route o VPN soddisfi completamente i requisiti dell'applicazione.
  • Quando necessario, è consigliabile considerare più percorsi di rete per fornire una ridondanza aggiuntiva, ad esempio circuiti ExpressRoute connessi incrociati o l'uso di VPN come meccanismo di connettività di failover.

• Assicurarsi che tutti i componenti nei percorsi di rete critici siano in linea con i requisiti di affidabilità e disponibilità dei flussi utente associati, indipendentemente dal fatto che la gestione di questi percorsi e il componente associato vengano recapitati dal team dell'applicazione dei team IT centrali.

  Nota

  Quando si distribuisce all'interno di un'area di destinazione di Azure e si integra con una topologia di rete aziendale più ampia, prendere in considerazione le indicazioni di rete per garantire che la rete di base sia allineata alle procedure consigliate di Microsoft.

• Usare Azure Bastion o connessioni private proxied per accedere al piano dati delle risorse di Azure o eseguire operazioni di gestione.

Internet in uscita

Internet in uscita è un requisito di rete fondamentale per un'applicazione fondamentale per facilitare la comunicazione esterna nel contesto di:

1. Interazione diretta dell'utente dell'applicazione.
2. Integrazione dell'applicazione con dipendenze esterne ad Azure.
3. Accesso alle dipendenze esterne richieste dai servizi di Azure usati dall'applicazione.

Questa sezione illustra il modo in cui è possibile ottenere internet in uscita, garantendo la sicurezza, l'affidabilità e le prestazioni sostenibili, evidenziando i requisiti chiave di uscita per i servizi consigliati in un contesto fondamentale.

Considerazioni sulla progettazione

• Molti servizi di Azure richiedono l'accesso agli endpoint pubblici per varie funzioni del piano di gestione e controllo per funzionare come previsto.

• Azure offre diversi metodi di connettività in uscita a Internet diretta, ad esempio gateway NAT di Azure o Azure Load Balancer, per macchine virtuali o istanze di calcolo in una rete virtuale.

• Quando il traffico dall'interno di una rete virtuale passa a Internet, è necessario che venga eseguito network Address Translation (NAT). Si tratta di un'operazione di calcolo che si verifica all'interno dello stack di rete e che può quindi influire sulle prestazioni del sistema.

• Quando NAT si verifica su una scala ridotta, l'impatto sulle prestazioni deve essere trascurabile, tuttavia, se si verificano un numero elevato di problemi di rete delle richieste in uscita. Questi problemi si presentano in genere sotto forma di esaurimento della porta NAT (o SNAT) di origine.

• In un ambiente multi-tenant, ad esempio Servizio app di Azure, è disponibile un numero limitato di porte in uscita per ogni istanza. Se queste porte si esauriscono, non è possibile avviare nuove connessioni in uscita. Questo problema può essere risolto riducendo il numero di attraversamenti perimetrali privati/pubblici o usando una soluzione NAT più scalabile, ad esempio il gateway NAT di Azure.

• Oltre alle limitazioni NAT, il traffico in uscita può essere soggetto anche alle ispezioni di sicurezza necessarie.

  • Firewall di Azure offre funzionalità di sicurezza appropriate per proteggere l'uscita di rete.

  • Firewall di Azure (o un'appliance virtuale di rete equivalente) può essere usata per proteggere i requisiti in uscita di Kubernetes fornendo un controllo granulare sui flussi di traffico in uscita.

• Grandi volumi di internet in uscita comportano addebiti per il trasferimento dei dati.

Azure NAT Gateway

• Il gateway NAT di Azure supporta 64.000 connessioni per TCP e UDP per ogni indirizzo IP in uscita assegnato.

  • È possibile assegnare fino a 16 indirizzi IP a un singolo gateway NAT.
  • Timeout di inattività TCP predefinito di 4 minuti. Se il timeout di inattività viene modificato in un valore superiore, i flussi verranno mantenuti per più tempo, aumentando così la pressione sull'inventario delle porte SNAT.

• Il gateway NAT non può fornire l'isolamento di zona esistente. Per ottenere la ridondanza di zona, è necessario allineare una subnet contenente risorse di zona con i gateway NAT di zona corrispondenti.

Suggerimenti per la progettazione

• Ridurre al minimo il numero di connessioni Internet in uscita perché ciò influirà sulle prestazioni NAT.

  • Se è necessario un numero elevato di connessioni con associazione a Internet, prendere in considerazione l'uso del gateway NAT di Azure per astrarre i flussi di traffico in uscita.

• Usare Firewall di Azure in cui sono presenti i requisiti per controllare e controllare il traffico Internet in uscita.

  • Assicurarsi che Firewall di Azure non venga usato per controllare il traffico tra i servizi di Azure.

Nota

Quando si esegue la distribuzione all'interno di una zona di destinazione di Azure, è consigliabile usare la piattaforma di base Firewall di Azure risorsa (o appliance virtuale di rete equivalente). Se una dipendenza viene eseguita su una risorsa della piattaforma centrale per l'uscita internet, il livello di affidabilità di tale risorsa e il percorso di rete associato devono essere strettamente allineati ai requisiti dell'applicazione. I dati operativi della risorsa devono essere resi disponibili anche all'applicazione per informare potenziali azioni operative in scenari di errore.

Se sono presenti requisiti su larga scala associati al traffico in uscita, è consigliabile considerare una risorsa di Firewall di Azure dedicata per un'applicazione cruciale, per ridurre i rischi associati all'uso di una risorsa condivisa a livello centrale, ad esempio scenari adiacenti rumorosi.

• Quando viene distribuita all'interno di un ambiente rete WAN virtuale, è necessario prestare attenzione a Gestione firewall per fornire una gestione centralizzata delle istanze di applicazioni dedicate Firewall di Azure per garantire che i comportamenti di sicurezza dell'organizzazione vengano osservati tramite criteri firewall globali.
• Assicurarsi che i criteri firewall incrementali vengano delegati ai team di sicurezza delle applicazioni tramite il controllo degli accessi in base al ruolo per consentire l'autonomia dei criteri dell'applicazione.

Connettività tra zone e aree

Anche se la progettazione di applicazioni supporta fortemente gli indicatori di distribuzione a livello di area indipendenti, molti scenari di applicazione possono comunque richiedere l'integrazione di rete tra i componenti dell'applicazione distribuiti in zone o aree di Azure diverse, anche se solo in circostanze di servizio ridotte. Il metodo con cui si ottiene la comunicazione tra zone e aree ha un impatto significativo sulle prestazioni e sull'affidabilità complessive, che verranno esaminate attraverso le considerazioni e le raccomandazioni all'interno di questa sezione.

Considerazioni sulla progettazione

• L'approccio di progettazione delle applicazioni per un'applicazione cruciale approva l'uso di distribuzioni regionali indipendenti con ridondanza di zona applicate a tutti i livelli di componente all'interno di una singola area.

• Una zona di disponibilità (AZ) è una posizione del data center fisicamente separata all'interno di un'area di Azure, fornendo l'isolamento degli errori fisici e logici fino al livello di un singolo data center.

  Una latenza di round trip inferiore a 2 ms è garantita per la comunicazione tra zone. Le zone avranno una piccola varianza di latenza in base a distanze diverse e percorsi in fibra tra le zone.

• La connettività della zona di disponibilità dipende dalle caratteristiche a livello di area e pertanto potrebbe essere necessario instradare il traffico che entra in un'area tramite una posizione perimetrale tra zone per raggiungere la destinazione. Verrà aggiunta una latenza di ~1ms-2ms data il routing tra zone e i vincoli di "velocità di luce", ma questo dovrebbe avere solo un cuscinetto per carichi di lavoro iper sensibili.

• zone di disponibilità vengono trattati come entità logiche all'interno del contesto di una singola sottoscrizione, quindi sottoscrizioni diverse potrebbero avere un mapping di zona diverso per la stessa area. Ad esempio, la zona 1 nella sottoscrizione A potrebbe corrispondere allo stesso data center fisico della zona 2 nella sottoscrizione B.

• La comunicazione tra zone all'interno di un'area comporta un addebito per il trasferimento dei dati per GB di larghezza di banda.

• Con gli scenari di applicazione estremamente chat tra i componenti dell'applicazione, la distribuzione dei livelli applicazione tra zone può introdurre una latenza significativa e un aumento dei costi. È possibile attenuare questo problema all'interno della progettazione vincolando un timbro di distribuzione a una singola zona e distribuendo più timbri tra le diverse zone.

• La comunicazione tra aree di Azure diverse comporta un addebito di trasferimento dei dati maggiore per GB di larghezza di banda.

  • La velocità di trasferimento dei dati applicabile dipende dal continente delle aree di Azure considerate.
  • I continenti di attraversamento dei dati vengono addebitati a una velocità notevolmente più elevata.

• I metodi di connettività ExpressRoute e VPN possono essere usati anche per connettere direttamente aree di Azure diverse per determinati scenari o anche piattaforme cloud diverse.

• Per i servizi al servizio la comunicazione collegamento privato può essere usata per la comunicazione diretta tramite endpoint privati.

• Il traffico può essere bloccato tramite circuiti ExpressRoute usati per la connettività locale per facilitare il routing tra reti virtuali all'interno di un'area di Azure e tra aree di Azure diverse all'interno della stessa area geografica.

  • Il traffico di acconciatura tramite ExpressRoute ignora i costi di trasferimento dei dati associati al peering di rete virtuale, quindi può essere usato come modo per ottimizzare i costi.
  • Questo approccio richiede hop di rete aggiuntivi per l'integrazione delle applicazioni in Azure, che introduce rischi di latenza e affidabilità. Espande il ruolo di ExpressRoute e i componenti gateway associati da Azure/locale per includere anche la connettività di Azure/Azure.

• Quando è necessaria una latenza di submillisecond tra i servizi, i gruppi di posizionamento di prossimità possono essere usati se supportati dai servizi usati.

Suggerimenti per la progettazione

• Usare il peering di rete virtuale per connettere le reti all'interno di un'area e tra aree diverse. È consigliabile evitare l'acconciatura all'interno di ExpressRoute.

• Usare collegamento privato per stabilire la comunicazione diretta tra i servizi nella stessa area o tra aree (servizio nell'area A che comunica con il servizio nell'area B.

• Per i carichi di lavoro dell'applicazione estremamente chatti tra i componenti, è consigliabile vincolare un timbro di distribuzione a una singola zona e distribuire più francobolli tra le diverse zone. Ciò garantisce che la ridondanza di zona venga mantenuta a livello di un timbro di distribuzione incapsulato anziché a un singolo componente dell'applicazione.

• Se possibile, considerare ogni timbro di distribuzione come indipendente e disconnesso da altri francobolli.

  • Usare le tecnologie della piattaforma dati per sincronizzare lo stato tra aree anziché ottenere coerenza a livello di applicazione con percorsi di rete diretti.
  • Evitare il traffico "dog legging" tra aree diverse, a meno che non sia necessario, anche in uno scenario di errore. Usare i servizi di routing globali e i probe di integrità end-to-end per eliminare la circolazione nel caso in cui un singolo livello componente critico non riesca, anziché instradare il traffico a livello di componente difettoso a un'altra area.

• Per gli scenari di applicazioni sensibili all'iper latenza, definire la priorità dell'uso delle zone con gateway di rete a livello di area per ottimizzare la latenza di rete per i percorsi in ingresso.

Micro-segmentazione e criteri di rete Kubernetes

La micro-segmentazione è un modello di progettazione della sicurezza di rete usato per isolare e proteggere i singoli carichi di lavoro delle applicazioni, con criteri applicati per limitare il traffico di rete tra carichi di lavoro in base a un modello di Zero Trust. Viene in genere applicato per ridurre la superficie di attacco di rete, migliorare il contenimento delle violazioni e rafforzare la sicurezza tramite controlli di rete a livello di applicazione basati su criteri.

Un'applicazione cruciale può applicare la sicurezza di rete a livello di applicazione usando gruppi di sicurezza di rete (NSG) a livello di subnet o interfaccia di rete, elenchi di Controllo di accesso di servizio e criteri di rete quando si usa servizio Azure Kubernetes (servizio Azure Kubernetes).

Questa sezione illustra l'uso ottimale di queste funzionalità, fornendo considerazioni chiave e consigli per ottenere la micro-segmentazione a livello di applicazione.

Considerazioni sulla progettazione

• Il servizio Azure Kubernetes può essere distribuito in due modelli di rete diversi:

  • Rete Kubenet: I nodi del servizio Azure Kubernetes sono integrati all'interno di una rete virtuale esistente, ma i pod esistono all'interno di una rete di sovrapposizione virtuale in ogni nodo. Il traffico tra pod in nodi diversi viene instradato tramite kube-proxy.
  • Rete CNI (Azure Container Networking Interface): Il cluster del servizio Azure Kubernetes è integrato all'interno di una rete virtuale esistente e dei relativi nodi, pod e servizi ricevuti indirizzi IP dalla stessa rete virtuale a cui sono collegati i nodi del cluster. Questo è rilevante per vari scenari di rete che richiedono la connettività diretta da e verso i pod. È possibile distribuire pool di nodi diversi in subnet diverse.

  Nota

  Azure CNI richiede più spazio indirizzi IP rispetto a Kubenet. È necessaria una pianificazione iniziale corretta e il dimensionamento della rete. Per altre informazioni, vedere la documentazione di Azure CNI.

• Per impostazione predefinita, i pod non sono isolati e accettano il traffico da qualsiasi origine e possono inviare traffico a qualsiasi destinazione; un pod può comunicare con ogni altro pod in un determinato cluster Kubernetes; Kubernetes non garantisce l'isolamento a livello di rete e non isola gli spazi dei nomi a livello di cluster.

• La comunicazione tra pod e spazi dei nomi può essere isolata usando i criteri di rete. Criteri di rete è una specifica Kubernetes che definisce i criteri di accesso per la comunicazione tra pod. Usando i criteri di rete, è possibile definire un set ordinato di regole per controllare il modo in cui il traffico viene inviato/ricevuto e applicato a una raccolta di pod che corrispondono a uno o più selettori di etichetta.

  • Il servizio Azure Kubernetes supporta due plug-in che implementano Criteri di rete, Azure e Calico. Entrambi i plug-in usano le tabelle IPTable Linux per applicare i criteri specificati. Per altre informazioni, vedere Differenze tra i criteri di Azure e Calico e le relative funzionalità .
  • I criteri di rete non sono in conflitto perché sono additivi.
  • Affinché sia consentito un flusso di rete tra due pod, sia i criteri in uscita nel pod di origine che i criteri di ingresso nel pod di destinazione devono consentire il traffico.
  • La funzionalità dei criteri di rete può essere abilitata solo in fase di creazione di istanze del cluster. Non è possibile abilitare i criteri di rete in un cluster del servizio Azure Kubernetes esistente.
  • Il recapito dei criteri di rete è coerente indipendentemente dal fatto che venga usato Azure o Calico.
  • Calico offre un set di funzionalità più completo, incluso il supporto per i nodi Windows e supporta Azure CNI e Kubenet.

• Il servizio Azure Kubernetes supporta la creazione di pool di nodi diversi per separare carichi di lavoro diversi usando nodi con caratteristiche hardware e software diverse, ad esempio nodi con e senza funzionalità GPU.

  • L'uso dei pool di nodi non fornisce alcun isolamento a livello di rete.
  • I pool di nodi possono usare subnet diverse all'interno della stessa rete virtuale. I gruppi di sicurezza di rete possono essere applicati a livello di subnet per implementare la micro-segmentazione tra pool di nodi.

Suggerimenti per la progettazione

• Configurare un gruppo di sicurezza di rete in tutte le subnet considerate per fornire un ACL IP per proteggere i percorsi di ingresso e isolare i componenti dell'applicazione in base a un modello di Zero Trust.

  • Usare i tag del servizio Frontdoor all'interno dei gruppi di sicurezza di rete in tutte le subnet contenenti back-end dell'applicazione definiti all'interno di Frontdoor di Azure, perché ciò convaliderà l'origine del traffico da uno spazio di indirizzi IP back-end di Frontdoor di Azure legittimo. In questo modo il traffico passa attraverso Frontdoor di Azure a livello di servizio, ma il filtro basato su intestazione sarà comunque necessario per garantire l'uso di una particolare istanza di Frontdoor e per attenuare anche i rischi di sicurezza dello spoofing IP.

  • Il traffico Internet pubblico deve essere disabilitato nelle porte RDP e SSH in tutti i gruppi di sicurezza di rete applicabili.

  • Classificare in ordine di priorità l'uso del plug-in di rete Azure CNI e prendere in considerazione Kubenet per gli scenari con un intervallo limitato di indirizzi IP disponibili per adattare l'applicazione all'interno di uno spazio indirizzi vincolato.

    • Il servizio Azure Kubernetes supporta l'uso di Azure CNI e Kubenet. Viene selezionato in fase di distribuzione.
    • Il plug-in di rete Azure CNI è un plug-in di rete più affidabile e scalabile ed è consigliato per la maggior parte degli scenari.
    • Kubenet è un plug-in di rete più leggero ed è consigliato per gli scenari con un intervallo limitato di indirizzi IP disponibili.
    • Per altri dettagli, vedere Azure CNI .

• La funzionalità Criteri di rete in Kubernetes deve essere usata per definire regole per il traffico in ingresso e in uscita tra i pod in un cluster. Definire criteri di rete granulari per limitare e limitare la comunicazione tra pod.

  • Abilitare Criteri di rete per servizio Azure Kubernetes in fase di distribuzione.
  • Classificare in ordine di priorità l'uso di Calico perché offre un set di funzionalità più completo con un'adozione e un supporto più ampi della community.

Passaggio successivo

Esaminare le considerazioni per quantificare e osservare l'integrità dell'applicazione.

Modellazione dell'integrità e osservabilità