Configurare i componenti del gateway applicazione di Azure
Il gateway applicazione di Azure è costituito da una serie di componenti che si combinano per instradare le richieste a un pool di server Web e verificarne l'integrità. Questi componenti includono l'indirizzo IP front-end, i pool back-end, le regole di routing, i probe di integrità e i listener. Come opzione, il gateway può anche implementare un firewall.
Informazioni utili sui componenti del gateway applicazione di Azure
Si esaminerà ora il modo in cui i componenti di un gateway applicazione interagiscono.
L'indirizzo IP front-end riceve le richieste client.
Un web application firewall facoltativo controlla il traffico in ingresso per individuare le minacce comuni prima che le richieste raggiungano i listener.
Uno o più listener ricevono il traffico e instradano le richieste al pool back-end.
Le regole di routing definiscono come analizzare la richiesta per indirizzare la richiesta al pool back-end appropriato.
Un pool back-end contiene server Web per risorse come macchine virtuali o set di scalabilità di macchine virtuali. Ogni pool include un servizio di bilanciamento del carico per distribuire il carico di lavoro tra le risorse.
I probe di integrità determinano quali server sono disponibili per il bilanciamento del carico in un pool back-end.
Il diagramma di flusso seguente illustra come interagiscono i componenti del gateway applicazione per indirizzare le richieste di traffico tra il front-end e i pool back-end nella configurazione.
Indirizzo IP front-end
Le richieste client vengono ricevute tramite l'indirizzo IP del front-end. Il gateway applicazione può avere un indirizzo IP pubblico o privato o entrambi. È possibile avere un solo indirizzo IP pubblico e un solo indirizzo IP privato.
Web application firewall (facoltativo)
È possibile abilitare Web application firewall di Azure per consentire al gateway applicazione di Azure di gestire le richieste in ingresso prima che raggiungano il listener. Il firewall controlla ogni richiesta per verificare la presenza di minacce, sulla base di Open Web Application Security Project. Le minacce comuni includono SQL injection, scripting intersito, attacchi di tipo injection per i comandi, HTTP Request Smuggling e Response Splitting, Remote File Inclusion. Altre minacce possono derivare da bot, crawler, scanner e anomalie e violazioni 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 di Azure supporta due set di regole: CRS 2.2.9 e CRS 3.0. CRS 3.0 è il set di regole predefinito e più recente. Se necessario, è possibile scegliere di selezionare solo regole specifiche in un set di regole, per rilevare 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.
Listener
I listener accettano 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 routing. 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 dei percorsi di trasferimento
Una regola di routing 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 quindi 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 Altre informazioni sulla configurazione includono protocollo, persistenza della sessione, svuotamento della connessione, periodo di timeout della richiesta e probe di integrità.
Pool back-end
Un pool back-end fa riferimento a una raccolta di server Web. È necessario specificare l'indirizzo IP di ogni server Web e la porta in cui è in ascolto delle richieste durante la configurazione del pool. Ogni pool può specificare un set fisso di macchine virtuali, set di scalabilità di macchine virtuali, un'app ospitata da servizi app di Azure o una raccolta di server locali. A ogni pool back-end è associato un servizio di bilanciamento del carico che distribuisce il lavoro nel pool.
Probe di integrità
I probe di integrità determinano quali server nel pool back-end sono disponibili per il bilanciamento del carico. 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 (non integro).