Funzionalità di gateway applicazione di Azure

  • Articolo

Il gateway applicazione di Azure è un servizio di bilanciamento del carico del traffico Web che consente di gestire il traffico verso le applicazioni Web.

Application Gateway conceptual

Nota

Per i carichi di lavoro Web, è consigliabile usare la protezione DDoS di Azure e un web application firewall per proteggersi dagli attacchi DDoS emergenti. Un'altra opzione consiste nell'usare Frontdoor di Azure insieme a un web application firewall. Frontdoor di Azure offre protezione a livello di piattaforma contro gli attacchi DDoS a livello di rete. Per altre informazioni, vedere baseline di sicurezza per i servizi di Azure.

Il gateway applicazione include le funzionalità seguenti:

Terminazione di Secure Sockets Layer (SSL/TLS)

Il gateway applicazione supporta la terminazione SSL/TLS nel gateway, dopo la quale il traffico scorre generalmente non crittografato verso i server back-end. Questa funzionalità consente ai server Web di non gestire il costoso carico di crittografia e decrittografia. In alcuni casi, tuttavia, le comunicazioni non crittografate verso i server non rappresentano un'opzione accettabile. Questo può dipendere dai requisiti di sicurezza e conformità o dal fatto che l'applicazione può accettare solo connessioni sicure. Per queste applicazioni, il gateway applicazione supporta la crittografia SSL/TLS end-to-end.

Per altre informazioni, vedere Panoramica della terminazione SSL e di SSL end-to-end con il gateway applicazione

Scalabilità automatica

Il gateway applicazione Standard_v2 supporta la scalabilità automatica e può aumentare o ridurre le prestazioni in base alla modifica dei modelli di carico del traffico. La scalabilità automatica elimina anche la necessità di scegliere un numero di istanze o le dimensioni della distribuzione durante il provisioning.

Per altre informazioni sulle funzionalità del gateway applicazione Standard_v2, vedere Che cos'è il gateway applicazione di Azure v2?.

Ridondanza della zona

Un gateway applicazione Standard_v2 può estendersi su più zone di disponibilità, offrendo una migliore resilienza degli errori e rimuovendo la necessità di effettuare il provisioning di gateway applicazione separati in ogni zona.

Indirizzo VIP statico

Il gateway applicazione Standard_v2 SKU supporta esclusivamente il tipo di indirizzo VIP statico. Questa funzionalità garantisce che l'indirizzo VIP associato al gateway applicazione non cambi nel corso del ciclo di vita del gateway applicazione.

Web application firewall

Web Application Firewall (WAF) è un servizio che fornisce protezione centralizzata delle applicazioni Web da exploit e vulnerabilità comuni. WAF si basa su regole dei set di regole principali OWASP (Open Web Application Security Project) 3.1 (solo WAF_v2), 3.0 e 2.2.9.

Le applicazioni Web sono sempre più vittime di attacchi che sfruttano le più comuni vulnerabilità note. Per citarne alcuni, tra i più comuni troviamo gli attacchi SQL injection e gli attacchi di scripting intersito. Impedire questo tipo di attacchi nel codice dell'applicazione può essere un'operazione complessa e potrebbe richiedere una manutenzione rigorosa, l'applicazione di patch e il monitoraggio a più livelli della topologia dell'applicazione. Un Web application firewall centralizzato semplifica notevolmente la gestione della sicurezza e offre agli amministratori delle applicazioni migliori garanzie contro le minacce o le intrusioni. Una soluzione WAF è anche in grado di reagire più velocemente a una minaccia alla sicurezza tramite l'applicazione di patch su una vulnerabilità nota in una posizione centrale, anziché proteggere ogni singola applicazione Web. È possibile convertire facilmente i gateway applicazione esistenti in un gateway applicazione con Web application firewall.

Per indicazioni su come usare Azure WAF con il gateway applicazione per proteggersi dagli attacchi DDoS, vedere Protezione DDoS dell'applicazione. Per altre informazioni, vedere Che cos'è Azure Web Application Firewall?.

Controller di ingresso per il servizio Azure Kubernetes

Il controller di ingresso del gateway applicazione consente di usare il gateway applicazione come ingresso per un cluster del servizio Azure Kubernetes.

Il controller di ingresso viene eseguito come un pod nel cluster del servizio Azure Kubernetes, utilizza risorse in ingresso Kubernetes e le converte in una configurazione del gateway, applicazione che consente al gateway di bilanciare il carico del traffico indirizzato ai pod Kubernetes. Il controller di ingresso supporta solo gli SKU gateway applicazione Standard_v2 e WAF_v2.

Per altre informazioni, vedere Controller di ingresso del gateway applicazione di Azure.

Routing basato su URL

Il routing basato su percorso URL consente di instradare il traffico a pool di server back-end in base ai percorsi URL della richiesta. Uno degli scenari è il rounting delle richieste di tipi di contenuto diversi a pool diversi.

Ad esempio, per le richieste http://contoso.com/video/* viene eseguito il rounting verso VideoServerPool mentre per le richieste http://contoso.com/images/* viene eseguito il rounting verso ImageServerPool. In caso di mancata corrispondenza dei percorsi, viene selezionato DefaultServerPool.

Per altre informazioni, vedere Panoramica del routing basato sul percorso URL.

Hosting di più siti

Con il gateway applicazione è possibile configurare il routing in base al nome host o al nome di dominio per più applicazioni Web nello stesso gateway applicazione. Consente di configurare una topologia più efficiente per le distribuzioni aggiungendo fino a più di 100 siti Web a un unico gateway applicazione. Ogni sito Web può essere indirizzato al proprio pool back-end. Ad esempio, tre domini, contoso.com, fabrikam.com e adatum.com, puntano all'indirizzo IP del gateway applicazione. Si creeranno tre listener multisito e si configurerà ogni listener per la rispettiva impostazione della porta e del protocollo.

Per le richieste http://contoso.com viene eseguito il routing verso ContosoServerPool, mentre per le richieste http://fabrikam.com viene eseguito il routing verso FabrikamServerPool, e così via.

Analogamente, la stessa distribuzione del gateway applicazione può ospitare due sottodomini dello stesso dominio padre. Gli esempi di uso di sottodomini possono includere http://blog.contoso.com e http://app.contoso.com ospitati in una singola distribuzione del gateway applicazione. Per altre informazioni, vedere Hosting di più siti di gateway applicazione.

È anche possibile definire nomi host con caratteri jolly in un listener multisito e fino a cinque nomi host per ogni listener. Per altre informazioni, vedere nomi host jolly nel listener.

Reindirizzamento

Uno scenario comune per molte applicazioni Web è il supporto del reindirizzamento automatico da HTTP a HTTPS per assicurare che tutte le comunicazioni tra l'applicazione e gli utenti avvengano tramite un percorso crittografato.

È possibile che in passato siano state usate tecniche come la creazione di un pool dedicato il cui unico scopo è quello di reindirizzare le richieste ricevute su HTTP ad HTTPS. Il gateway applicazione consente di reindirizzare il traffico sul gateway applicazione. Questo semplifica la configurazione delle applicazioni, ottimizza l'utilizzo delle risorse e supporta i nuovi scenari di reindirizzamento, tra cui il reindirizzamento globale e basato sul percorso. Il supporto del reindirizzamento nel gateway applicazione non è limitato al solo reindirizzamento da HTTP ad HTTPS. Si tratta di un meccanismo di reindirizzamento generico che consente di eseguire il reindirizzamento da e verso qualsiasi porta definita mediante regole. Supporta anche il reindirizzamento a un sito esterno.

Il supporto del reindirizzamento nel gateway applicazione offre le funzionalità seguenti:

  • Reindirizzamento globale da una porta a un'altra porta nel gateway. che consente il reindirizzamento da HTTP a HTTPS in un sito.
  • Reindirizzamento basato sul percorso. Questo tipo di reindirizzamento consente il reindirizzamento da HTTP a HTTPS solo in un'area specifica del sito, ad esempio l'area del carrello acquisti indicata da /cart/*.
  • Reindirizzamento a un sito esterno.

Per altre informazioni, vedere Panoramica del reindirizzamento del gateway applicazione.

Affinità di sessione

L'affinità di sessione basata su cookie è utile quando si vuole mantenere una sessione utente nello stesso server. Usando cookie gestiti dal gateway, il gateway applicazione può indirizzare il traffico successivo proveniente da una sessione utente allo stesso server per l'elaborazione. Questo è importante nei casi in cui lo stato della sessione viene salvato in locale sul server per una sessione utente.

Per altre informazioni, vedere Funzionamento di un gateway applicazione.

Traffico WebSocket e HTTP/2

Il gateway applicazione offre il supporto nativo per i protocolli WebSocket e HTTP/2. Non esistono impostazioni configurabili dall'utente per abilitare o disabilitare in modo selettivo il supporto di WebSocket.

I protocolli WebSocket HTTP/2 consentono una comunicazione full duplex tra un server e un client su una connessione TCP con esecuzione prolungata. Questo consente una comunicazione più interattiva tra il server Web e il client che può essere bidirezionale senza necessità di polling che invece è richiesto nelle implementazioni basate su HTTP. A differenza del protocollo HTTP, questi protocolli presentano un sovraccarico ridotto e possono riutilizzare la stessa connessione TCP per più richieste/risposte garantendo così un uso più efficiente delle risorse. Questi protocolli sono progettati per usare le porte HTTP 80 e 443 tradizionali.

Per altre informazioni, vedere Supporto per WebSocket e supporto per HTTP/2.

Svuotamento della connessione

Lo svuotamento delle connessioni aiuta a rimuovere in modo controllato i membri del pool back-end durante gli aggiornamenti pianificati del servizio o problemi con l'integrità back-end. Questa impostazione viene abilitata tramite l'impostazione back-end e viene applicata a tutti i membri del pool back-end durante la creazione della regola. Una volta abilitata, il gateway applicazione assicura che tutte le istanze di un pool back-end in fase di annullamento della registrazione non ricevano nuove richieste e che le richieste esistenti vengano completate entro un limite di tempo configurato. Si applica ai casi in cui le istanze back-end sono:

  • rimosse in modo esplicito dal pool back-end dopo una modifica della configurazione da parte di un utente
  • segnalate come non integre dai probe di integrità o
  • rimosse durante un'operazione di scalabilità orizzontale

L'unica eccezione è quando le richieste continuano a essere inoltrate tramite proxy alle istanze di deregistrazione a causa dell'affinità di sessione gestita dal gateway.

Lo svuotamento delle connessioni viene rispettato anche per le connessioni WebSocket. Viene richiamato lo svuotamento delle connessioni per ogni singolo aggiornamento al gateway. Per evitare la perdita di connessione ai membri esistenti del pool back-end, assicurarsi di abilitare lo svuotamento delle connessioni.

Per informazioni sui limiti di tempo, vedere Configurazione delle impostazioni back-end.

Pagine di errore personalizzate

Il gateway applicazione consente di creare pagine di errore personalizzate da visualizzare al posto delle pagine di errore predefinite. Con una pagina di errore personalizzata è possibile usare il layout e il marchio aziendali.

Per altre informazioni, vedere Errori personalizzati.

Riscrivere l'URL e le intestazioni HTTP

Le intestazioni HTTP consentono al client e al server di passare informazioni aggiuntive insieme alla richiesta o alla risposta. La riscrittura delle intestazioni HTTP consente di affrontare diversi scenari importanti, ad esempio:

  • Aggiunta di campi di intestazione relativi alla sicurezza come HSTS/X-XSS-Protection.
  • Rimozione di campi di intestazione della risposta che possono rivelare informazioni riservate.
  • Rimozione delle informazioni sulle porte dalle intestazioni X-Forwarded-For.

Il gateway applicazione e lo SKU WAF v2 supportano la possibilità di aggiungere, rimuovere o aggiornare le intestazioni di richieste e risposte HTTP durante lo spostamento dei pacchetti di richiesta e risposta tra il client e i pool back-end. È anche possibile riscrivere gli URL, i parametri della stringa di query e il nome host. Con la riscrittura dell'URL e il routing basato sul percorso URL, è possibile scegliere di indirizzare le richieste a uno dei pool back-end in base al percorso originale o al percorso riscritto, usando l'opzione Rivaluta mappa percorso.

Consente anche di aggiungere le condizioni necessarie per garantire che le intestazioni specificate o l'URL vengono riscritti solo in presenza di determinate condizioni. Queste condizioni sono basate sulle informazioni della richiesta e della risposta.

Per altre informazioni, vedere Riscrivere le intestazioni HTTP e l’URl.

Dimensionamento

Lo Standard_v2 del gateway applicazione può essere configurati per la scalabilità automatica o per le distribuzioni con dimensioni fisse. Lo SKU v2 non offre dimensioni di istanza diverse. Per altre informazioni sulle prestazioni e sui prezzi v2, vedere Scalabilità automatica V2 e Informazioni sui prezzi.

Il gateway applicazione Standard (v1) è disponibile in tre dimensioni: Small, Medium e Large. Le dimensioni delle istanze piccole sono destinate a scenari di sviluppo e test.

Per un elenco completo dei limiti del gateway applicazione, vedere i limiti del servizio Gateway applicazione.

La tabella seguente illustra una velocità effettiva media delle prestazioni per ogni istanza del gateway applicazione v1 con offload SSL abilitato:

Dimensioni medie risposta della pagina di back-end Piccola Medio Grande
6 KB 7,5 Mbps 13 Mbps 50 Mbps
100 kB 35 Mbps 100 Mbps 200 Mbps

Nota

Questi valori sono indicazioni approssimative della velocità effettiva di un gateway applicazione. La velocità effettiva dipende da vari dettagli ambientali come le dimensioni medie delle pagine, la posizione delle istanze back-end e il tempo di elaborazione per gestire una pagina. Per dati esatti sulle prestazioni, è consigliabile eseguire propri test. Questi valori vengono forniti solo come indicazioni per la pianificazione della capacità.

Confronto delle funzionalità di versione

Per un confronto delle funzionalità del gateway applicazione v1-v2, vedere Che cos'è il gateway applicazione di Azure v2?.

Passaggi successivi