Modello di scarico del gateway

Spostare le funzionalità dei servizi condivisi o specializzati su un proxy gateway. Questo approccio semplifica lo sviluppo di applicazioni centralizzando problematiche trasversali, ad esempio la terminazione del certificato TLS rivolta al client, nel gateway anziché duplicarle tra i servizi.

Quando più servizi condividono responsabilità, ad esempio l'autenticazione, il monitoraggio o la conversione del protocollo, il consolidamento di tali problemi in un singolo gateway riduce il sovraccarico di configurazione per servizio e il rischio di distribuzione.

Contesto e problema

Alcune funzionalità usate comunemente in più servizi richiedono l'esecuzione di attività di configurazione, gestione e manutenzione. Un servizio condiviso o specializzato distribuito con ogni distribuzione di applicazioni comporta un sovraccarico amministrativo e aumenta la probabilità di errori di distribuzione. È necessario distribuire tutti gli aggiornamenti a una funzionalità condivisa in tutti i servizi che condividono tale funzionalità.

I problemi di sicurezza, ad esempio la convalida dei token, la crittografia e la gestione dei certificati TLS, possono richiedere ai membri del team competenze altamente specializzate. Ad esempio, senza un gateway, potrebbe essere necessario configurare e distribuire un certificato per client in ogni istanza dell'applicazione. È necessario tenere traccia della scadenza e dell'aggiornamento, testarlo e verificarlo in tutte le istanze.

L'implementazione e la gestione di altri servizi comuni, tra cui l'autenticazione, l'autorizzazione, la registrazione, il monitoraggio e la limitazione delle richieste, possono risultare complicate in un numero elevato di distribuzioni. Il consolidamento di questo tipo di funzionalità riduce il sovraccarico e la probabilità di errori.

Soluzione

Eseguire l'offload di alcune funzionalità in un gateway. Il gateway gestisce quindi le problematiche trasversali, ad esempio la gestione dei certificati rivolta al client, l'autenticazione, la terminazione TLS, il monitoraggio, la conversione del protocollo e la limitazione per conto dei servizi back-end.

Il diagramma seguente illustra un gateway che termina le connessioni TLS in ingresso e applica le funzionalità condivise. Il gateway convalida il certificato back-end e crittografa nuovamente il traffico tramite una connessione TLS separata al servizio back-end.

Diagramma di un client che si connette a un gateway tramite TLS.

I vantaggi di questo schema includono:

  • Semplificare lo sviluppo dei servizi centralizzando la configurazione condivisa, ad esempio l'autenticazione, la limitazione e la registrazione delle richieste, anziché implementarla in ogni servizio back-end. La centralizzazione migliora la coerenza e rende più semplici gli aggiornamenti dei servizi.

  • Possibilità per i team dedicati di implementare funzionalità che richiedono competenze specifiche, come la sicurezza. Il team principale può quindi concentrarsi sulle funzionalità dell'applicazione, lasciando questi problemi specializzati ma trasversali agli esperti pertinenti.

  • Implementazione di un certo livello di coerenza per la registrazione e il monitoraggio di richieste e risposte. Anche se un servizio non è instrumentato correttamente, il gateway può fornire un livello di base di monitoraggio e registrazione.

  • Centralizzare la gestione del traffico consapevole delle emissioni di carbonio. Un gateway può modificare i comportamenti di memorizzazione nella cache, limitazione della frequenza e registrazione in base ai segnali di intensità di carbonio in tempo reale. Gestione API di Azure offre queste funzionalità in anteprima limitata, in aree e livelli classici selezionati (Developer, Basic, Standard e Premium). Per informazioni dettagliate sulla disponibilità e sulla configurazione, vedere API sostenibili per l'ambiente in Gestione API di Azure.

  • Gestire le mappature statiche degli URL da vecchi a nuovi. Il gateway può restituire un reindirizzamento senza richiamare un back-end, mantenendo la gestione dell'URL legacy fuori dalla pipeline di richiesta di ogni servizio.

Problemi e considerazioni

Quando si decide come implementare questo modello, tenere presente quanto segue:

  • Disponibilità elevata e resilienza. Assicurarsi che il gateway sia a disponibilità elevata e resiliente agli errori. Evitare singoli punti di errore eseguendo più istanze del gateway. Poiché il gateway chiude le connessioni dei client e può memorizzare nel buffer il corpo delle richieste, è opportuno considerare come vengono gestite le richieste in corso in caso di guasto dell'istanza. Usare meccanismi di arresto normale o di svuotamento delle connessioni in modo che la rimozione o il riavvio di un'istanza del gateway non elimini le sessioni attive.

  • Capacità e scalabilità. Assicurarsi che il gateway che sia progettato per soddisfare i requisiti di capacità e scalabilità dell'applicazione e degli endpoint. Assicurarsi che il gateway non diventi un collo di bottiglia per l'applicazione ed è sufficientemente scalabile. Il gateway deve essere dimensionato per gestire i picchi di traffico, non solo il carico medio. Sottodimensionare il gateway per ridurre i costi degrada direttamente le prestazioni di ogni servizio che dipende da esso.

  • Ambito di scarico. Esternalizza le funzionalità condivise da più servizi o percorsi quando centralizzarle riduce l'implementazione e la gestione duplicate.

  • Reindirizzamento corrispondente Abbina solo gli URL legacy previsti e mantieni il routing normale per le richieste senza corrispondenza. Mantenere i reindirizzamenti che dipendono dallo stato aziendale o dall'autorizzazione specifica dell'applicazione nell'applicazione. Per indicazioni correlate, vedere Mantenere i collegamenti quando si sposta il contenuto.

  • Separazione della logica di business. Non eseguire mai l'offload della logica di business nel gateway.

  • Rilevamento delle transazioni. Se è necessario tenere traccia delle transazioni, provare a generare ID di correlazione ai fini della registrazione.

  • Sovraccarico di latenza. Il gateway aggiunge un hop di rete a ogni richiesta. Ogni funzione offloaded eseguita dal gateway, ad esempio terminazione TLS, autenticazione o ispezione delle richieste, aggiunge il tempo di elaborazione al percorso della richiesta. Il pool di connessioni gateway e le connessioni keep-alive ai servizi back-end possono compensare parzialmente il costo della latenza riutilizzando le connessioni invece di stabilire nuove connessioni per ogni richiesta. Valutare se la latenza combinata del passaggio attraverso il gateway e delle funzioni esternalizzate sia accettabile rispetto agli obiettivi prestazionali del carico di lavoro.

  • Complessità operativa. Un gateway centralizzato consolida la gestione, ma concentra anche la responsabilità operativa. È necessario gestire la configurazione del gateway, il ciclo di vita del certificato, gli aggiornamenti dei criteri e gli aggiornamenti delle versioni come preoccupazione condivisa. Assicurarsi che il team responsabile del gateway disponga della capacità e degli strumenti per gestirlo su larga scala di tutti i servizi che dipendono da esso.

  • Implicazioni per la sicurezza. Il gateway è una destinazione di alto valore perché centralizza funzioni di sicurezza trasversali, ad esempio l'autenticazione, la terminazione TLS e l'ispezione delle richieste. Una compromissione del gateway può esporre tutti i servizi downstream. Rafforzare la sicurezza del gateway, limitarne la superficie di gestione e monitorarlo in modo indipendente dai servizi di backend che protegge per rilevare comportamenti anomali.

  • Prevenzione del bypass del gateway. Configurare i servizi back-end per accettare le richieste solo tramite il percorso del gateway previsto. In caso contrario, i client possono connettersi direttamente a un back-end e ignorare l'autenticazione, la limitazione, l'ispezione delle richieste e la registrazione nel gateway.

  • Propagazione delle identità. Definite se ogni backend autorizza il chiamante originale, l'identità del carico di lavoro associata al gateway o entrambi. Mantenere i token del chiamante o le attestazioni attendibili solo quando il back-end richiede il contesto utente delegato. Autenticare sempre il gateway verso il backend in modo separato. Non considerare gli header inoltrati non verificati come prova dell'identità.

  • Manutenzione TLS. Se il gateway termina la connessione TLS, ristabilire una connessione TLS con il back-end. Non inoltrare il traffico tramite HTTP non crittografato. Considerare tutte le reti come non attendibili. Questa topologia richiede comunque un processo per rilasciare, ruotare e revocare i certificati back-end.

  • Intestazioni inoltrate e contesto client. Quando il gateway termina le connessioni client e stabilisce nuove connessioni ai servizi back-end, le informazioni come l'indirizzo IP client, il protocollo originale e il nome host vengono persi a meno che il gateway non lo inoltra in modo esplicito. Per le strategie di mitigazione, vedere Mantenere il nome host HTTP originale tra un proxy inverso e l'applicazione Web back-end.

Quando usare questo modello

Usare questo modello quando:

  • Una distribuzione di applicazioni presenta un problema condiviso, ad esempio certificati TLS o crittografia.
  • Una funzionalità comune nelle distribuzioni di applicazioni potrebbe avere requisiti di risorse diversi, ad esempio risorse di memoria, capacità di archiviazione o connessioni di rete.
  • Si vuole spostare la responsabilità di problemi quali la sicurezza di rete, la limitazione o altri problemi di rete a un team più specializzato.

Questo modello potrebbe non essere adatto quando:

  • Il gateway deve contenere regole di routing o logica specifiche del servizio che accoppiano strettamente le modifiche del servizio back-end alle modifiche alla configurazione del gateway. L'accoppiamento del livello gateway con i servizi interni significa che gli aggiornamenti back-end possono forzare la ridistribuzione del gateway, riducendo l'indipendenza della distribuzione.
  • L'attività delegata è leggera e il carico di lavoro è sensibile alla latenza. L'hop di rete aggiuntivo attraverso il gateway potrebbe non essere giustificato quando il sovraccarico supera il vantaggio della centralizzazione.
  • La centralizzazione degli aspetti in un gateway condiviso crea un collo di bottiglia nella gestione delle modifiche. Se il ciclo di rilascio del team del gateway è più lento rispetto ai team del servizio, l'offload può ritardare gli aggiornamenti ai certificati, ai criteri di autenticazione o alle regole di rete.

Progettazione del carico di lavoro

Un architetto deve valutare il modo in cui il modello di offload del gateway può essere usato nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Per esempio:

Pilastro Come questo modello supporta gli obiettivi di pilastro
decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resiliente a un malfunzionamento e assicurano che ripristini a uno stato completamente funzionante dopo che si verifica un guasto. L'offload di questa responsabilità in un gateway riduce la complessità del codice dell'applicazione nei nodi back-end. In alcuni casi, lo scaricamento sostituisce completamente la funzionalità con una caratteristica affidabile fornita dalla piattaforma.

- RE:01 Semplicità ed efficienza
Le decisioni di progettazione della sicurezza consentono di garantire la riservatezza, l'integrità e la disponibilità dei dati e dei sistemi del carico di lavoro. L'aggiunta di un gateway nel flusso di richiesta consente di centralizzare controlli come web application firewall e criteri TLS client. Qualsiasi funzionalità esternalizzata fornita dalla piattaforma offre già maggiore sicurezza.

- Controlli di rete SE:06
- Indurimento delle risorse SE:08
L'ottimizzazione dei costi è incentrata sul mantenimento e sul miglioramento del ritorno del carico di lavoro sugli investimenti. Questo modello consente di reindirizzare i costi dalle risorse che verrebbero spesi per nodo nell'implementazione del gateway. I costi nel modello di elaborazione centralizzato sono spesso inferiori a quelli del modello distribuito.

- CONSOLIDAMENTO CO:14
L'eccellenza operativa consente di offrire la qualità del carico di lavoro attraverso processi standardizzati e coesione del team. In questo modello, la configurazione e il backup della funzionalità offloaded sono associati a un singolo punto invece di richiedere la gestione da più nodi. Questa centralizzazione standardizza il modo in cui vengono applicate le problematiche trasversali, rendendo coerenti e prevedibili le modifiche operative di routine e ad hoc.

- Operazioni di standardizzazione di OE:02
l'efficienza delle prestazioni consente al carico di lavoro soddisfare in modo efficiente le richieste tramite ottimizzazioni di ridimensionamento, dati e codice. L'aggiunta di un gateway di offload al processo di richiesta consente di usare meno risorse per nodo perché la funzionalità è centralizzata nel gateway. È possibile ottimizzare l'implementazione della funzionalità offloaded indipendentemente dal codice dell'applicazione. È già probabile che la funzionalità fornita dalla piattaforma offloaded sia altamente efficiente.

- PE:03 Selezione dei servizi

Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.

Example

gateway applicazione di Azure WAF_v2 può implementare questo modello per un'applicazione Web regionale. Il gateway termina le connessioni TLS client, applica waf e criteri di routing e stabilisce nuove connessioni TLS ai servizi back-end. Questo design mantiene gli aspetti condivisi dell'elaborazione delle richieste al di fuori del codice dell'applicazione backend.

Gateway applicativo con scarico TLS

Il diagramma seguente illustra come il gateway applicazione termina le connessioni TLS in ingresso, controlla e filtra il traffico e lo crittografa nuovamente prima di inoltrarlo a un pool back-end tramite TLS.

Diagramma che mostra Application Gateway che termina le connessioni TLS in ingresso dai client, applica le regole WAF e di routing e crittografa nuovamente il traffico tramite TLS verso un pool di back-end.

Questa architettura utilizza i seguenti componenti di Application Gateway per delegare le funzionalità condivise e crittografare di nuovo il traffico backend:

  • Listener HTTPS. Un listener HTTPS sulla porta 443 accetta connessioni TLS in ingresso dai client.
  • Certificato TLS. Un certificato PFX, originato da Azure Key Vault, viene collegato al listener HTTPS. Application Gateway decritta il traffico in ingresso per ispezionarlo e instradarlo, quindi lo critta nuovamente verso il pool back-end. I server back-end necessitano ancora di certificati per le connessioni ricrittografate, ma in molti casi è possibile usare i certificati gestiti dalla piattaforma.
  • Pool backend. Un pool back-end definisce il set di server HTTPS che ricevono il traffico crittografato di nuovo. Le destinazioni back-end possono essere macchine virtuali, Set di scalabilità di macchine virtuali di Azure, indirizzi IP o istanze di Servizio app di Azure. Limita l'accesso al back-end in modo che i client non possano aggirare Application Gateway e i relativi criteri del WAF connettendosi direttamente.
  • Impostazioni HTTP back-end. Impostare il protocollo back-end su HTTPS e la porta sulla porta TLS del back-end, ad esempio 443. Configurare l'attendibilità del certificato e un nome host corrispondente al certificato back-end. Per un'autorità di certificazione privata, configurare il certificato radice attendibile. Per informazioni dettagliate, vedere TLS end-to-end con lo SKU v2.
  • Regola di routing. Una regola di instradamento delle richieste associa il listener al pool back-end e alle impostazioni HTTP back-end. Le regole basate sul percorso possono instradare percorsi URL diversi verso pool di backend diversi.
  • Criterio WAF. Il criterio definisce le regole gestite e personalizzate utilizzate per ispezionare le richieste, incluse eventuali regole Geomatch.

Poiché Application Gateway decrittografa il traffico, può esaminare il contenuto della richiesta per il routing intelligente, riscrivere le intestazioni HTTP e gli URL e applicare le regole WAF. Quindi crittografa nuovamente il traffico prima di inoltrare le richieste al back-end.

Per indicazioni per la configurazione, vedere Crittografia TLS end-to-end con Application Gateway.

Tecnologie di supporto

I servizi di Azure seguenti consentono di implementare questo modello:

Passaggi successivi

  • Ultimo aggiornamento: