Rete e connettività per carichi di lavoro cruciali in Azure

La rete è un'area fondamentale per un'applicazione cruciale, data l'approccio consigliato per la progettazione attiva-attiva distribuita a livello globale.

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

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 cruciale?

Routing del traffico globale

L'uso di più indicatori 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 in più aree.

In alternativa, è possibile considerare tecnologie di routing globale 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 le tecnologie di routing da parte dei provider della rete CDN.

Questa sezione illustra le principali differenze tra i servizi di routing di Azure per definire il modo in cui ognuno può essere usato per ottimizzare diversi scenari.

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 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 il failover in una tecnologia alternativa quando vengono soddisfatte determinate condizioni di errore. L'introduzione di più servizi di routing globali 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 delle applicazioni per i percorsi in ingresso.
  • È anche possibile considerare tecnologie di terze parti, fornendo resilienza globale di routing a tutti i livelli di errori della piattaforma Azure.

• La disparità di capacità tra Frontdoor di Azure e Gestione traffico significa che se le due tecnologie sono posizionate una accanto all'altra per la ridondanza, sarebbe necessario un percorso di ingresso o modifiche di progettazione diverse per garantire un livello di servizio coerente e accettabile.

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

  • Gli scenari ipotetici di errore di una scala sufficientemente grande da 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 globali della piattaforma per quasi tutti i servizi di Azure. Se viene applicata una tecnologia di Azure ridondante, è probabile che anche il servizio secondario stia riscontrando un'indisponibilità o un servizio danneggiato.
    • Gli scenari di errore del servizio di routing globale hanno un impatto significativo su molti altri servizi usati per i componenti chiave dell'applicazione 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 offre comunque un valore minimo.

• La ridondanza globale del servizio di routing offre una mitigazione per un numero estremamente ridotto di scenari ipotetici di errore, 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-attivo multicloud. Un approccio di distribuzione attivo-attivo multicloud introduce notevoli complessità operative, che comportano rischi significativi di resilienza, probabilmente superiori ai rischi ipotetici di un'interruzione globale.

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

  • Se usato 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 l'SLO composito massimo raggiungibile, indipendentemente dal numero di aree di distribuzione considerate.

• Quando il controllo client non è possibile, le mitigazioni operative possono essere considerate 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 altro è in genere un processo lungo dura diverse ore, in particolare quando viene considerata la propagazione DNS.

• Alcuni servizi di routing globale di terze parti forniscono un contratto di servizio del 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 poco significativo quando l'impatto dell'indisponibilità è significativo, ad esempio con scenari critici per la 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 è del 100%.

Frontdoor di Azure

• Frontdoor di Azure offre il bilanciamento del carico HTTP/S globale e la connettività ottimizzata usando il protocollo Anycast con tcp diviso per sfruttare i vantaggi della 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 tramite il backbone Microsoft al back-end appropriato usando connessioni esistenti o gestite dalla cache interna di un nodo perimetrale.
  • Questo approccio è efficiente nella distribuzione di volumi di traffico elevati sulle connessioni back-end.

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

• Web application firewall di Azure (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 protezione DDoS di Azure Basic. Azure DDoS Standard offre funzionalità aggiuntive e più avanzate di protezione e rilevamento e possono essere aggiunte come livello aggiuntivo a Frontdoor di Azure.

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

• Frontdoor di Azure Premium supporta gli endpoint privati, consentendo il flusso del traffico da Internet direttamente alle reti virtuali di Azure. In questo modo si elimina la necessità di usare indirizzi IP pubblici nella rete virtuale per rendere i back-end accessibili tramite Frontdoor di Azure Premium.

• 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, il nodo perimetrale smetterà di inviare richieste. I back-end non integri vengono quindi rimossi in modo trasparente dalla circolazione del traffico senza alcun ritardo.

• Supporta solo protocolli HTTP/S.

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

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

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

  • Basato sulla latenza: l'impostazione predefinita che indirizza il traffico al back-end "più vicino" dal client; in base alla latenza della richiesta.
  • Basato sulla priorità: utile per le configurazioni attive-passive, in cui 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 una determinata percentuale di traffico viene inviata 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à di sessione può essere configurata nel front-end. Usa un cookie sul 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 indirizzate direttamente all'endpoint back-end senza Gestione traffico interazione. Elimina il passaggio di connettività aggiuntivo che offre vantaggi sui costi 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 funziona 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 di 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 la durata (TTL) scade, non c'è garanzia che i server DNS pubblici rispedano questo valore, in modo che la propagazione DNS possa effettivamente richiedere molto più tempo. Ciò significa che il traffico può continuare a essere inviato all'endpoint non integro per un periodo di tempo prolungato.

Azure Load Balancer Standard

Importante

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

Suggerimenti per la progettazione

• Usare Frontdoor di Azure come servizio di routing globale principale per scenari HTTP/S. Frontdoor di Azure è fortemente consigliato per i carichi di lavoro HTTP/S perché offre 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 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 indirizzare alla 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 complessiva di gestione dei certificati e la logica di routing per un failover.
  • Classificare in ordine di priorità l'uso di tecnologie di routing di terze parti come servizio di failover secondario, poiché ciò ridurrà il maggior numero 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 ridotto, 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 ridurre realmente il rischio di errori globali all'interno della piattaforma Azure, è consigliabile considerare un approccio di distribuzione attivo-attivo multicloud, con indicatori di distribuzione attivi ospitati in due o più provider di servizi cloud e tecnologie di routing ridondanti di terze parti usate per il routing globale.

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

• Sebbene non sia consigliabile, per i carichi di lavoro HTTP che usano Gestione traffico di Azure per la ridondanza globale del routing in Frontdoor di Azure, valutare la possibilità di eseguire l'offload di Web Application Firewall (WAF) per gateway applicazione per il traffico accettabile che passa attraverso Frontdoor di Azure.
  • In questo modo verrà introdotto un punto di errore aggiuntivo per il percorso di ingresso standard, un componente di percorso critico aggiuntivo da gestire e ridimensionare e comporta costi aggiuntivi per garantire la disponibilità elevata globale. Tuttavia, semplificherà 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, sia in termini di esecuzione waf che di endpoint applicazione privati.
  • La perdita di memorizzazione nella cache perimetrale in uno scenario di errore influirà sulle prestazioni complessive e deve essere allineata a un livello accettabile di servizio o di mitigazione dell'approccio di progettazione. Per garantire un livello coerente di servizio, è consigliabile eseguire l'offload della memorizzazione nella cache perimetrale in un provider di rete CDN di terze parti per entrambi i percorsi.

È consigliabile prendere in considerazione un servizio di routing globale di terze parti al posto di due servizi di routing globale di Azure. Questo 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 Il web application firewall (WAF) di Frontdoor di Azure per fornire protezione ai dispositivi perimetrali da exploit Web e vulnerabilità comuni, ad esempio SQL injection.

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

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

• Configurare i punti di ingresso della piattaforma dell'applicazione per convalidare le richieste in ingresso tramite il filtro basato su intestazioni usando X-Azure-FDID per garantire che tutto il traffico venga propagato attraverso l'istanza di Frontdoor configurata. Valutare anche la configurazione dell'ACL IP usando i tag del servizio Frontdoor per convalidare l'origine del traffico dallo spazio indirizzi IP back-end di Frontdoor di Azure e dai servizi di infrastruttura di Azure. 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 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 di base. 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 ai probe di integrità vengano registrate e inseriscano 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 nell'intera applicazione.

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

  • A tale scopo, impostare il parametro "Latenza di riservatezza (latenza aggiuntiva)" su un valore sufficientemente elevato per soddisfare le differenze di latenza tra le diverse aree del back-end. Assicurarsi una tolleranza accettabile per il carico di lavoro dell'applicazione relativamente alla latenza complessiva delle richieste client.

• Non abilitare l'affinità di sessione a meno che non sia richiesta dall'applicazione, perché può avere un impatto negativo sul bilanciamento della distribuzione del traffico. Con un'applicazione completamente senza stato, se viene seguito l'approccio di progettazione di applicazioni cruciali consigliato, qualsiasi richiesta può essere gestita da una delle distribuzioni a livello di area.

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 Gestione traffico, usando app Azure gateway di comunicazione.

• Configurare un valore TTL adeguatomente 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 riflessa nella risposta fornita dagli endpoint di integrità.

  Tuttavia, per Gestione traffico considerazione aggiuntiva deve essere data al 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.

• È necessario 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. Quando vengono offerte anche funzionalità WAF perimetrali dal servizio di terze parti, è consigliabile prendere in considerazione per semplificare il percorso di ingresso e potenzialmente rimuovere la necessità di gateway applicazione.

Servizi per il recapito di applicazioni

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

Questa sezione si basa sulle raccomandazioni di routing globali esplorando le principali funzionalità di distribuzione delle applicazioni, considerando i servizi pertinenti, ad esempio Azure Load Balancer Standard, app Azure lication Gateway e Azure Gestione API.

Considerazioni relative alla progettazione

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

• Un Web Application Firewall offre protezione da exploit Web e vulnerabilità comuni, ad esempio sql injection o scripting tra siti, ed è essenziale per ottenere le massime aspirazioni di affidabilità di un'applicazione cruciale.

• Azure WAF offre una protezione predefinita contro le 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, app Azure lication Gateway o Rete CDN di Azure (attualmente in anteprima pubblica).
    • Le funzionalità offerte in ognuno dei servizi differiscono leggermente. Ad esempio, frontdoor di Azure WAF 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 prevenzione.
    • La roadmap per Azure WAF garantisce che venga fornito un set di funzionalità WAF coerente in tutte le integrazioni di servizi.

• È anche possibile considerare tecnologie WAF di terze parti, ad esempio appliance virtuali di rete e controller di ingresso avanzati all'interno di Kubernetes, per fornire una protezione della vulnerabilità necessaria.

• La configurazione ottimale di WAF richiede in genere l'ottimizzazione, 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 di Azure globale 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.
  • Gli 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 di certificato completamente gestito che un metodo bring-your-own-certificate per i certificati SSL rivolti al client. Il servizio certificati 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 proteggersi da rischi per i certificati scaduti. Se vengono usati certificati autogestito, i certificati aggiornati devono essere distribuiti entro 24 ore dalla scadenza del certificato esistente. In caso contrario, i client potrebbero ricevere errori di certificato scaduti.

• Gli aggiornamenti dei certificati genereranno tempi di inattività solo se Frontdoor di Azure passa da "Gestito" a "Usa il proprio certificato".

• Frontdoor di Azure è protetto da Protezione DDoS di Azure Basic, integrato in Frontdoor per impostazione predefinita. In questo modo viene fornito il monitoraggio del traffico sempre attivo, la mitigazione in tempo reale e si difende anche dalle inondazioni di query DNS di livello 7 comuni o dagli attacchimetrici 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 rendere non disponibile una risorsa di destinazione sovraccaricandola con traffico non autorizzato.

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

  Azure Load Balancer

• Lo SKU di Azure Load Balancer Basic 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 nel minor numero possibile di posizioni per garantire la sicurezza semplificando al tempo stesso il ciclo di vita della gestione dei certificati.

• Usare connessioni crittografate (ad esempio HTTPS) dal punto in cui si verifica l'offload TLS ai back-end dell'applicazione effettivi. Gli endpoint dell'applicazione non saranno visibili agli utenti finali, quindi 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 un'unica posizione del servizio, a livello globale con Frontdoor di Azure o a livello di area con app Azure lication Gateway, perché 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à rilevamento (ad esempio solo la registrazione ma non il blocco delle richieste sospette) quando la riduzione delle prestazioni della modalità di prevenzione è troppo elevata. Il rischio aggiuntivo implicito deve essere pienamente compreso e allineato ai requisiti specifici dello scenario del carico di lavoro.

• Classificare in ordine di priorità l'uso del WAF di Frontdoor di Azure perché offre il set di funzionalità nativo di Azure più ricco e applica protezioni all'perimetro globale, semplificando così la progettazione complessiva e determina un'ulteriore 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 Load Balancer Standard di Azure per qualsiasi scenario di distribuzione del traffico interno all'interno di carichi di lavoro del microservizio.

  • Fornisce un contratto di servizio del 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 contenuto statico

Un trattamento speciale di contenuto statico come 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 nella rete perimetrale consente di velocizzare i tempi di caricamento del client, migliorando così l'esperienza utente e riducendo i costi per il traffico, le operazioni di lettura e la potenza di calcolo sui servizi back-end coinvolti.

Considerazioni relative alla progettazione

• Non tutti i contenuti resi disponibili da una soluzione tramite Internet vengono generati dinamicamente. Le applicazioni servono sia asset statici (immagini, JavaScript, CSS, file di localizzazione e così via) che contenuto dinamico.
• I carichi di lavoro con contenuto statico a cui si accede di frequente traggono molto vantaggio dalla memorizzazione nella cache, poiché riduce il carico sui servizi back-end e riduce la latenza di accesso al contenuto per gli utenti finali.
• La memorizzazione nella cache può essere implementata in modo nativo in Azure usando Frontdoor di Azure o azure rete per la distribuzione di contenuti (rete CDN).
  • 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 sarà probabilmente più conveniente, ma non offre le stesse funzionalità avanzate di routing e web application firewall (WAF) consigliate per altre aree di progettazione di applicazioni. Offre tuttavia una maggiore flessibilità per l'integrazione con servizi simili di 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 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 (il prezzo varia in base alla destinazione).

Suggerimenti per la progettazione

• Il contenuto statico generato, ad esempio le copie ridimensionate 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 durata variabile della memorizzazione nella cache.
• Separare la distribuzione di contenuto statico e dinamico agli utenti e distribuire contenuto pertinente da una cache per ridurre il carico nei servizi back-end ottimizza le prestazioni per gli utenti finali.
• Data la raccomandazione avanzata (area di progettazione di rete e connettività ) di usare Frontdoor di Azure per il routing globale e web application firewall (WAF), è consigliabile classificare in ordine di priorità l'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 i 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 con cui viene ottenuta l'integrazione delle applicazioni 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 generali, che determina il modo in cui l'integrazione dell'applicazione può verificarsi a livello di rete.

1. Applicazione pubblica senza connettività di rete aziendale.
2. Applicazione pubblica con connettività di rete aziendale.
3. Applicazione privata con connettività di rete aziendale.

Attenzione

Quando si esegue la distribuzione all'interno di una zona di destinazione di Azure, la 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 layering nell'uso appropriato di azure Rete virtuale e dei servizi di rete di Azure circostanti 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 di Azure considerati 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 la rete Internet pubblica.
  • La connettività a qualsiasi sistema esterno ad Azure verrà fornita dalla rete Internet pubblica.

• 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. Può trattarsi di una soluzione accettabile per scenari meno sensibili alla sicurezza. Tutti i servizi e le dipendenze dell'applicazione sono accessibili tramite un endpoint pubblico, lasciandoli vulnerabili a vettori di attacco aggiuntivi orientati a 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 rigido per una rete virtuale sottostante.

Reti virtuali isolate

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

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

• Anche se la connettività privata tra i componenti dell'applicazione si verificherà su reti virtuali, tutta la connettività con dipendenze esterne si baserà comunque su endpoint pubblici.

  • La connettività ai servizi della piattaforma 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 qualsiasi sistema esterno ad Azure verrebbe fornita dalla rete Internet pubblica.

• Per gli scenari in cui non sono previsti 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 indirizzamento e vincoli di routing associati all'integrazione di rete più ampia.

• Azure Bastion è un servizio PaaS completamente gestito dalla piattaforma che può essere distribuito in una rete virtuale e fornisce 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 di reti virtuali dell'applicazione introduce notevoli complessità di distribuzione all'interno delle 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.

  • È necessario stabilire un percorso di rete privato sicuro per consentire agli strumenti CI/CD di eseguire le azioni necessarie.
  • Gli agenti di compilazione privati possono essere distribuiti all'interno delle reti virtuali dell'applicazione per delegare l'accesso alle risorse protette dalla rete virtuale.

Reti virtuali connesse

• Per gli scenari con requisiti di integrazione di rete esterna, le reti virtuali dell'applicazione possono essere connesse ad altre reti virtuali all'interno di Azure, a un altro provider di servizi cloud o a reti locali usando un'ampia gamma di opzioni di connettività. Ad esempio, alcuni scenari di applicazione possono 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 per quanto riguarda argomenti come l'indirizzamento e il routing.

• Gli spazi di indirizzi IP sovrapposti tra aree di Azure o reti locali creeranno conflitti principali quando viene considerata l'integrazione di rete.

  • È possibile aggiornare una risorsa di rete virtuale per considerare spazio indirizzi aggiuntivo, tuttavia, quando uno spazio di indirizzi di rete virtuale di una rete con peering 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 del 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 quanto gli indirizzi di spreco inutilmente.

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

  • Un circuito ExpressRoute può essere ridimensionato per fornire larghezze 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-spoke e fino a 20 Gbps in Azure rete WAN virtuale.

Nota

Quando si esegue la distribuzione all'interno di una zona 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-spoke.

• L'inclusione di percorsi di rete e risorse aggiuntivi introduce ulteriori considerazioni sull'affidabilità e sulle operazioni per l'applicazione per garantire la manutenzione dell'integrità.

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 Azure. Gli endpoint di servizio possono essere considerati per i servizi che supportano collegamento privato, a condizione che i rischi di esfiltrazione dei dati siano accettabili o mitigati tramite controlli alternativi.

• Per gli scenari di applicazione che non richiedono la connettività di rete aziendale, considerare tutte le reti virtuali come risorse temporanee che vengono 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 il 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-verde dei francobolli di distribuzione regionali aggiornati.

• Negli scenari in cui è necessaria la connettività di rete aziendale per facilitare l'integrazione delle applicazioni 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 causare 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), è consigliabile usare IPv6.
    • Se è necessario usare l'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 assicurarsi che lo spazio indirizzi IP della rete dell'applicazione non si sovrapponga ad altre reti tra posizioni locali o aree di Azure.
  • Non creare reti virtuali di applicazioni inutilmente di grandi dimensioni per assicurarsi che lo spazio degli indirizzi IP non venga sprecato.

• Classificare in ordine di priorità l'uso di Azure CNI per l'integrazione di rete del servizio Azure Kubernetes, poiché supporta un set di funzionalità più completo.

  • Si consideri Kubenet per scenari con un numero limitato di indirizzi IP disponibili per adattare l'applicazione all'interno di uno spazio di indirizzi vincolato.

  • Classificare in ordine di priorità l'uso del plug-in di rete Azure CNI per l'integrazione della rete del servizio Azure Kubernetes e prendere in considerazione Kubenet per scenari con un intervallo limitato di indirizzi IP disponibili. Per altri dettagli, vedere Micro-segmentazione e criteri di rete kubernetes.

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

  • Verificare che il livello di affidabilità applicato a ExpressRoute o VPN soddisfi completamente i requisiti dell'applicazione.
  • Quando necessario, è consigliabile considerare più percorsi di rete per fornire ridondanza aggiuntiva, ad esempio circuiti ExpressRoute con connessione incrociata 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 distribuiti dal team applicativo dei team IT centrali.

  Nota

  Quando si esegue la distribuzione all'interno di una zona di destinazione di Azure e l'integrazione con una topologia di rete aziendale più ampia, prendere in considerazione le indicazioni sulla rete per garantire che la rete di base sia allineata alle procedure consigliate di Microsoft.

• Usare Azure Bastion o connessioni private proxy 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 cruciale 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 l'uscita di Internet garantendo al tempo stesso la sicurezza, l'affidabilità e le prestazioni sostenibili, evidenziando i requisiti chiave in uscita per i servizi consigliati in un contesto cruciale.

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 il 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 si sposta verso Internet, deve avvenire 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 viene eseguito su una scala ridotta, l'impatto sulle prestazioni deve essere trascurabile, tuttavia, se si verifica un numero elevato di problemi di rete delle richieste in uscita. Questi problemi si presentano in genere sotto forma di esaurimento delle porte NAT (o SNAT) di origine.

• In un ambiente multi-tenant, ad esempio app Azure Servizio, è 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 ai requisiti di ispezione della sicurezza.

  • 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 di 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.

Gateway NAT di Azure

• 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 della 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 sono necessarie numerose 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 si usa una dipendenza 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 anche essere resi disponibili 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 mission-critical, per ridurre i rischi associati all'uso di una risorsa condivisa a livello centrale, ad esempio scenari vicini rumorosi.

• Quando viene distribuita all'interno di un ambiente rete WAN virtuale, è necessario considerare 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 delle applicazioni.

Connettività tra zone e aree

Anche se la progettazione dell'applicazione supporta fortemente 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 in base al quale 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 contenute in 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 applicata 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 isolamento di errore fisico e logico 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 zone.

• La connettività della zona di disponibilità dipende dalle caratteristiche a livello di area e pertanto il traffico che entra in un'area tramite una posizione perimetrale potrebbe dover essere instradato tra le zone per raggiungere la destinazione. In questo modo 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 i carichi di lavoro ipersensivi.

• zone di disponibilità vengono considerati come entità logiche all'interno del contesto di una singola sottoscrizione, pertanto le 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.

• Con scenari di applicazione estremamente chatti tra i componenti dell'applicazione, la distribuzione dei livelli di 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ù francobolli 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 superiore.

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

• Per i servizi di comunicazione da servizio collegamento privato può essere usato 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 in 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 all'interno di Azure, che introduce rischi di latenza e affidabilità. Espande il ruolo di ExpressRoute e i componenti del gateway associati da Azure/locale per includere anche la connettività di Azure/Azure.

• Quando è necessaria una latenza di sottomillisecondo 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 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 chiacchierati tra i componenti, è consigliabile vincolare un timbro di distribuzione a una singola zona e distribuire più timbri tra le diverse zone. In questo modo si garantisce che la ridondanza di zona venga mantenuta a livello di un timbro di distribuzione incapsulato anziché un singolo componente dell'applicazione.

• Se possibile, considerare ogni stamp 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'ipertenza, assegnare priorità all'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 singoli carichi di lavoro delle applicazioni, con criteri applicati per limitare il traffico di rete tra carichi di lavoro basati su un modello 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 mission-critical può applicare la sicurezza di rete a livello di applicazione usando i gruppi di sicurezza di rete (NSG) a livello di subnet o di interfaccia di rete, elenchi di servizi Controllo di accesso e criteri di rete quando si usano 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 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. È necessario pianificare e ridimensionare correttamente la 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 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 i 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 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, poiché in questo modo il traffico ha origine 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 ridurre 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 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 sia di Azure CNI che di Kubenet. Questa scelta di rete è selezionata 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 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ù ampio con un'adozione e un supporto più ampi della community.

Passaggio successivo

Esaminare le considerazioni per quantificare e osservare l'integrità delle applicazioni.

Modellazione e osservabilità dell'integrità