Funzionamento di Gateway applicazione di Azure
app Azure lication Gateway include una serie di componenti che si combinano per instradare e bilanciare in modo sicuro le richieste in un pool di server Web. Gateway applicazione include i componenti seguenti:
- Indirizzo IP front-end: le richieste client vengono ricevute tramite un indirizzo IP front-end. È possibile configurare il gateway applicazione con un indirizzo IP pubblico, un indirizzo IP privato o entrambi. Gateway applicazione non può avere più di un indirizzo IP pubblico e uno privato.
- Listener: il gateway applicazione usa uno o più listener per ricevere le richieste in ingresso. Un listener accetta il traffico in arrivo su una combinazione di protocollo, porta, host e indirizzo IP specificata. Ogni listener indirizza le richieste a un pool back-end di server in base alle regole di gestione specificate. Un listener può essere di tipo Base o Multisito. Un listener di base indirizza solo una richiesta in base al percorso nell'URL. Un listener Multisito può anche indirizzare le richieste usando l'elemento nome host dell'URL. I listener gestiscono anche i certificati TLS/SSL per proteggere l'applicazione tra l'utente e il gateway applicazione.
- Regole di gestione: una regola di gestione associa un listener ai pool back-end. Una regola specifica come interpretare gli elementi nome host e percorso nell'URL di una richiesta e reindirizza la richiesta al pool back-end appropriato. A una regola di gestione è anche associato un set di impostazioni HTTP. Queste impostazioni indicano se (e come) il traffico viene crittografato tra il gateway applicazione di Azure e i server back-end e forniscono altre informazioni sulla configurazione, quali Protocollo, Persistenza della sessione, Svuotamento della connessione, Periodo di timeout della richiesta e Probe di integrità.
Bilanciamento del carico nel gateway applicazione
gateway applicazione bilancia automaticamente il carico delle richieste inviate ai server in ogni pool back-end usando un meccanismo round robin. Il bilanciamento del carico funziona con il routing di livello OSI 7 implementato dal routing del gateway applicazione, ovvero bilancia il carico delle richieste in base ai parametri di routing (nomi host e percorsi) usati dalle regole del gateway applicazione. In confronto, altri servizi di bilanciamento del carico, come Azure Load Balancer, funzionano al livello OSI 4 e distribuiscono il traffico in base all'indirizzo IP della destinazione di una richiesta.
È possibile configurare la persistenza delle sessioni, se è necessario garantire che tutte le richieste per un client nella stessa sessione vengano instradate allo stesso server in un pool back-end.
Web application firewall
Il web application firewall (WAF) è un componente opzionale che gestisce le richieste in ingresso prima che raggiungano un listener. Il web application firewall controlla ogni richiesta per verificare la presenza di molte delle minacce più comuni, sulla base di Open Web Application Security Project (OWASP). Le minacce comuni includono: SQL injection, scripting tra siti, inserimento di comandi, contrabbando di richieste HTTP, suddivisione delle risposte HTTP, inclusione di file remoti, bot, crawler e scanner e violazioni e anomalie del protocollo HTTP.
OWASP definisce un set di regole generiche per il rilevamento degli attacchi. Queste regole vengono definite come Core Rule Set (CRS). I set di regole vengono sottoposti a revisione continua per restare al passo con l'evolvere del livello di complessità degli attacchi. Web application firewall supporta quattro set di regole: CRS 3.2, 3.1, 3.0 e 2.2.9. CRS 3.1 è l'impostazione predefinita. Se necessario, è possibile scegliere di selezionare solo regole specifiche in un set di regole, per affrontare determinate minacce. Inoltre, è possibile personalizzare il firewall in modo da specificare gli elementi da esaminare in una richiesta e limitare le dimensioni dei messaggi per impedire il sovraccarico dei server a causa di caricamenti di grandi dimensioni.
Pool back-end
Un pool back-end è una raccolta di server Web che possono essere costituiti da: un set fisso di macchine virtuali, un set di scalabilità di macchine virtuali, un'app ospitata da app Azure Services o una raccolta di server locali.
A ogni pool back-end è associato un servizio di bilanciamento del carico che distribuisce il lavoro nel pool. Quando si configura il pool, si specifica l'indirizzo IP o il nome di ogni server Web. Tutti i server nel pool back-end devono essere configurati allo stesso modo, anche per le impostazioni di sicurezza.
Se si usa TLS/SSL, il pool back-end ha un'impostazione HTTP che fa riferimento a un certificato usato per autenticare i server back-end. Il gateway crittografa nuovamente il traffico usando questo certificato prima di inviarlo a uno dei server nel pool back-end.
Se si usa Servizio app di Azure per ospitare l'applicazione back-end, non è necessario installare i certificati nel gateway applicazione per la connessione al pool back-end. Tutte le comunicazioni vengono crittografate automaticamente. Il gateway applicazione considera attendibili i server perché sono gestiti da Azure.
Il gateway applicazione usa una regola per specificare come indirizzare i messaggi ricevuti sulla porta in ingresso ai server nel pool back-end. Se i server usano TLS/SSL, è necessario configurare la regola in modo che indichi:
- Che i server si aspettano il traffico attraverso il protocollo HTTPS.
- Il certificato da usare per crittografare il traffico e autenticare la connessione a un server.
Routing di Gateway applicazione
Quando il gateway instrada una richiesta del client a un server Web nel pool back-end, usa un set di regole configurate per il gateway che determinano dove deve essere instradata la richiesta. Esistono due metodi principali di routing del traffico di questa richiesta del client: routing basato su percorso e routing multisito.
Routing basato sul percorso
Il routing basato su percorso invia richieste con percorsi URL a pool diversi di server back-end. Ad esempio, è possibile indirizzare le richieste con il percorso /video/* a un pool back-end contenente server ottimizzati per gestire lo streaming di video e indirizzare le richieste con il percorso /images/* a un pool di server che gestiscono il recupero di immagini.
Routing multisito
Il routing multisito consente di configurare più applicazioni Web nella stessa istanza del Gateway applicazione. In una configurazione multisito è possibile registrare più nomi DNS (CNAME) per l'indirizzo IP del gateway applicazione, specificando il nome di ogni sito. Il gateway applicazione usa listener separati per attendere le richieste per ogni sito. Ogni listener passa la richiesta a una regola diversa, che può instradare le richieste ai server in un pool back-end diverso. È ad esempio possibile indirizzare tutte le richieste per http://contoso.com ai server di un pool back-end e le richieste per http://fabrikam.com a un altro pool back-end. Il diagramma seguente mostra questa configurazione:
Le configurazioni multisito sono utili per supportare applicazioni multi-tenant, in cui ogni tenant ha un proprio set di macchine virtuali o altre risorse che ospitano un'applicazione Web.
gateway applicazione routing include anche queste funzionalità:
- Reindirizzamento. È possibile usare il reindirizzamento a un altro sito o da HTTP a HTTPS.
- Possibilità di riscrivere le intestazioni HTTP. Le intestazioni HTTP consentono al client e al server di passare informazioni sui parametri insieme alla richiesta o alla risposta.
- 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.
Terminazione TLS/SSL
Quando si termina la connessione TLS/SSL nel gateway applicazione, il gateway esegue l'offload dai server del carico di lavoro di terminazione TLS/SSL, che usa in modo intensivo la CPU. Non è inoltre necessario installare i certificati e configurare TLS/SSL nei server.
Se è necessaria la crittografia end-to-end, il gateway applicazione può decrittografare il traffico sul gateway usando la chiave privata e quindi crittografarlo nuovamente con la chiave pubblica del servizio in esecuzione nel pool back-end.
Il traffico entra nel gateway attraverso una porta front-end. È possibile aprire molte porte e il gateway applicazione può ricevere messaggi su qualsiasi porta. Il listener è il primo componente incontrato dal traffico in ingresso nel gateway attraverso una porta. Il listener è configurato per l'ascolto di un nome host specifico e di una porta specifica su un indirizzo IP specifico. Può usare un certificato TLS/SSL per decrittografare il traffico in ingresso nel gateway. Il listener usa quindi una regola definita per indirizzare le richieste in ingresso a un pool back-end.
Esporre il sito Web o l'applicazione Web tramite il gateway applicazione significa anche non connettere i server direttamente al Web. Si espone solo la porta 80 o la porta 443 nel gateway applicazione, che viene quindi inoltrata al server del pool back-end. In questa configurazione i server Web non sono direttamente accessibili da Internet, riducendo quindi la superficie di attacco dell'infrastruttura.
Probe di integrità
I probe di integrità determinano quali server sono disponibili per il bilanciamento del carico in un pool back-end. Il gateway applicazione usa un probe di integrità per inviare una richiesta a un server. Se il server restituisce una risposta HTTP con codice di stato compreso tra 200 e 399, il server è considerato integro. Se non si configura un probe di integrità, il gateway applicazione crea un probe predefinito che attende 30 secondi prima di determinare che un server non è disponibile. I probe di integrità assicurano che il traffico non venga indirizzato a un endpoint Web non rispondente o non riuscito nel pool back-end.
Scalabilità automatica
Gateway applicazione supporta la scalabilità automatica e l'aumento o la riduzione delle prestazioni in base alle variazioni 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.
Traffico WebSocket e HTTP/2
Il gateway applicazione offre il supporto nativo per i protocolli WebSocket e HTTP/2. I protocolli WebSocket HTTP/2 consentono una comunicazione full duplex tra un server e un client su una connessione TCP con esecuzione prolungata. Questo tipo di comunicazione è più interattivo tra il server Web e il client e può essere bidirezionale senza la necessità di eseguire il polling come 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.