Gateway Offload-patroon

Gedeelde of gespecialiseerde servicefunctionaliteit offloaden naar een gatewayproxy. Deze aanpak vereenvoudigt de ontwikkeling van toepassingen door overkoepelende aspecten, zoals clientgerichte TLS-terminatie, te centraliseren in de gateway in plaats van die over meerdere services te dupliceren.

Wanneer meerdere services verantwoordelijkheden delen, zoals verificatie, bewaking of protocolomzetting, vermindert het consolideren van deze problemen in één gateway de overhead en implementatierisico's per serviceconfiguratie.

Context en probleem

Sommige functies worden vaak gebruikt op meerdere services en voor deze functies is configuratie, beheer en onderhoud vereist. Een gedeelde of gespecialiseerde service die u distribueert met elke toepassingsimplementatie voegt administratieve overhead toe en verhoogt de kans op implementatiefouten. U moet updates implementeren voor een gedeelde functie in alle services die die functie delen.

Beveiligingsproblemen zoals tokenvalidatie, versleuteling en TLS-certificaatbeheer kunnen vereisen dat teamleden zeer gespecialiseerde vaardigheden hebben. Als u bijvoorbeeld geen gateway hebt, moet u mogelijk een clientgericht certificaat configureren en implementeren op elk toepassingsexemplaren. U moet bijhouden wanneer het verloopt en het in al die instanties bijwerken, testen en verifiëren.

Andere algemene services zoals verificatie, autorisatie, registratie, controle of netwerkbeperking zijn wellicht moeilijk te implementeren en beheren als er een groot aantal implementaties is. Het consolideren van dit type functionaliteit vermindert de overhead en de kans op fouten.

Solution

Breng een deel van de functionaliteit onder in een gateway. De gateway regelt vervolgens overkoepelende aspecten, zoals certificaatbeheer voor clients, authenticatie, TLS-terminatie, monitoring, protocolvertaling en snelheidsbegrenzing namens backendservices.

In het volgende diagram ziet u een gateway die binnenkomende TLS-verbindingen beëindigt en gedeelde mogelijkheden toepast. De gateway valideert het back-endcertificaat en versleutelt verkeer opnieuw via een afzonderlijke TLS-verbinding met de back-endservice.

Diagram van een client die verbinding maakt met een gateway via TLS.

Dit patroon heeft de volgende voordelen:

  • Vereenvoudig de ontwikkeling van services door gedeelde configuratie, zoals authenticatie, snelheidsbeperking en logboekregistratie van aanvragen, te centraliseren in plaats van dit in elke back-endservice te implementeren. Centralisatie verbetert de consistentie en maakt service-upgrades eenvoudiger.

  • Laat gespecialiseerde teams functies implementeren waarvoor speciale expertise is vereist, zoals voor beveiliging. Uw kernteam kan zich vervolgens richten op toepassingsfunctionaliteit, waardoor deze gespecialiseerde, maar kruislingse zorgen aan de relevante experts worden overgelaten.

  • Enige mate van consistentie in het registreren en controleren van aanvragen en reacties. Zelfs als een service niet correct is geïnstrumenteerd, kan de gateway een basisniveau van monitoring en logging bieden.

  • Centraliseer koolstofbewust verkeerbeheer. Een gateway kan caching, snelheidsbeperking en logboekregistratiegedrag aanpassen op basis van realtime koolstofgehaltesignalen. Azure API Management biedt deze mogelijkheden in beperkte preview, in bepaalde regio's en klassieke lagen (Developer, Basic, Standard en Premium). Zie Milieuvriendelijke API's in Azure API Management voor beschikbaarheids- en configuratiedetails.

Problemen en overwegingen

Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:

  • Hoge beschikbaarheid en tolerantie. Zorg ervoor dat de gateway maximaal beschikbaar is en bestand is tegen fouten. Vermijd enkelvoudige storingspunten door meerdere instanties van uw gateway te laten draaien. Omdat de gateway clientverbindingen beëindigt en aanvraaginstanties kan bufferen, kunt u overwegen hoe aanvragen tijdens storingen in de vlucht worden verwerkt. Gebruik verbindingsafvoer of probleemloze afsluitmechanismen, zodat het verwijderen of opnieuw opstarten van een gateway-exemplaar geen actieve sessies verwijdert.

  • Capaciteit en schalen. Zorg dat de gateway geschikt is voor de capaciteits- en schaalvereisten van uw toepassing en eindpunten. Zorg ervoor dat de gateway geen knelpunt voor de toepassing wordt en voldoende schaalbaar is. De gateway moet zo worden gedimensioneerd dat deze plotselinge verkeerspieken kan verwerken, niet alleen de gemiddelde belasting. Het te krap dimensioneren van de gateway om kosten te besparen gaat direct ten koste van de prestaties van alle services erachter.

  • Bereik offloaden. Breng functies die door meerdere services of routes worden gedeeld centraal onder wanneer dat dubbele implementatie en beheer vermindert.

  • Scheiding van bedrijfslogica. Nooit bedrijfslogica naar de gateway offloaden.

  • Transacties bijhouden. Als u transacties wilt volgen, zou u correlatie-id's voor registratie kunnen genereren.

  • Overhead voor latentie. De gateway voegt een netwerkhop toe aan elke aanvraag. Elke offloaded functie die door de gateway wordt uitgevoerd, zoals TLS-beëindiging, verificatie of aanvraaginspectie, voegt verwerkingstijd toe aan het aanvraagpad. Het groeperen van gatewayverbindingen en keep-alive-verbindingen met back-endservices kan de latentiekosten gedeeltelijk compenseren door verbindingen opnieuw te gebruiken in plaats van nieuwe verbindingen te maken voor elke aanvraag. Evalueer of de gecombineerde latentie van de gatewayhop en de offloaded functies acceptabel is voor de prestatiedoelen van de workload.

  • Operationele complexiteit. Een gecentraliseerde gateway consolideert beheer, maar zorgt ook voor operationele verantwoordelijkheid. U moet de gatewayconfiguratie, levenscyclus van certificaten, beleidsupdates en versie-upgrades beheren als een gedeeld probleem. Zorg ervoor dat het team dat verantwoordelijk is voor de gateway de capaciteit en hulpprogramma's heeft om deze te beheren op de schaal van alle services die ervan afhankelijk zijn.

  • Gevolgen voor beveiliging. De gateway is een belangrijk doel, omdat deze geavanceerde beveiligingsfuncties, zoals verificatie, TLS-beëindiging en inspectie, centraliseert. Een inbreuk op de gateway kan alle downstreamservices beschikbaar maken. Beperk de gateway, beperk het beheeroppervlak en bewaak deze op afwijkend gedrag, onafhankelijk van de back-endservices die worden beveiligd.

  • Voorkoming van het omzeilen van de gateway. Configureer back-endservices om aanvragen alleen te accepteren via het beoogde gatewaypad. Zo niet, dan kunnen clients rechtstreeks verbinding maken met een backend en authenticatie, snelheidsbeperking, inspectie van aanvragen en logregistratie bij de gateway omzeilen.

  • Identiteitspropagatie. Geef aan of elke back-end de oorspronkelijke aanroeper, de workloadidentiteit van de gateway of beide autoriseert. Behoud aanroeptokens of vertrouwde claims alleen wanneer de back-end gedelegeerde gebruikerscontext vereist. Authenticeer de gateway altijd afzonderlijk bij de backend. Niet-geverifieerde doorgestuurde headers niet behandelen als bewijs van identiteit.

  • TLS-onderhoud. Als de gateway TLS beëindigt, breng dan opnieuw een TLS-verbinding tot stand met de back-end. Stuur geen verkeer door via niet-versleutelde HTTP. Alle netwerken behandelen als niet-vertrouwd. Deze topologie vereist nog steeds een proces voor het uitgeven, vernieuwen en intrekken van backendcertificaten.

  • Doorgestuurde headers en clientcontext. Wanneer de gateway clientverbindingen beëindigt en nieuwe verbindingen tot stand brengt met back-endservices, gaat informatie zoals het IP-adres van de client, het oorspronkelijke protocol en de hostnaam verloren, tenzij de gateway deze expliciet doorstuurt. Zie De oorspronkelijke HTTP-hostnaam behouden tussen een omgekeerde proxy en de bijbehorende back-endwebtoepassing voor risicobeperkingsstrategieën.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

  • Een toepassingsimplementatie heeft een gedeeld probleem, zoals TLS-certificaten of -versleuteling.
  • Een functie die gebruikelijk is voor toepassingsimplementaties, kan verschillende resourcevereisten hebben, zoals geheugenresources, opslagcapaciteit of netwerkverbindingen.
  • U wilt de verantwoordelijkheid voor problemen zoals netwerkbeveiliging, beperking of andere problemen met netwerkgrenzen verplaatsen naar een meer gespecialiseerd team.

Dit patroon is mogelijk niet geschikt wanneer:

  • De gateway moet servicespecifieke logica of routeringsregels bevatten waarmee de wijzigingen van de back-endservice nauw worden gekoppeld aan wijzigingen in de gatewayconfiguratie. Als u de gatewaylaag koppelt aan interne services, betekent dit dat back-endupdates de herimplementatie van de gateway kunnen afdwingen, waardoor implementatieonafhankelijkheid wordt verminderd.
  • De uitbestede taak is licht en de werklast is gevoelig voor latentie. De extra netwerkhop via de gateway is mogelijk niet gerechtvaardigd wanneer de overhead het voordeel van centralisatie opweegt.
  • Bij het centraliseren van problemen in een gedeelde gateway ontstaat een knelpunt voor wijzigingsbeheer. Als de releasecyclus van het gatewayteam langzamer is dan de serviceteams, kan offloading updates voor certificaten, verificatiebeleid of netwerkregels vertragen.

Ontwerp van werkbelasting

Een architect moet evalueren hoe het Gateway Offloading patroon kan worden gebruikt in het ontwerp van de workload om de doelstellingen en principes aan te spreken die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:

Pilaar Hoe dit patroon ondersteuning biedt voor pijlerdoelen
betrouwbaarheid ontwerpbeslissingen helpen uw workload tolerant te worden defect te raken en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een storing is opgetreden. Het offloaden van deze verantwoordelijkheid voor een gateway vermindert de complexiteit van toepassingscode op back-endknooppunten. In sommige gevallen vervangt offloading volledig de functionaliteit door een betrouwbare functie die door het platform wordt geleverd.

- RE:01 Eenvoud en efficiëntie
Beslissingen over beveiligingsontwerpen helpen de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens en systemen van uw workload te waarborgen. Door een gateway toe te voegen aan de aanvraagstroom, kunt u besturingselementen zoals webtoepassingsfirewalls en TLS-beleid voor clients centraliseren. Elke uitbestede functionaliteit die door het platform wordt geleverd, biedt verbeterde beveiliging.

- SE:06 Netwerkbeheer
- SE:08 Versterking van middelen
Kostenoptimalisatie is gericht op het ondersteunen en verbeteren van het rendement van uw workload op investeringen. Met dit patroon kunt u kosten omleiden van resources die per knooppunt worden besteed aan de implementatie van de gateway. Kosten in het gecentraliseerde verwerkingsmodel zijn vaak lager dan die van het gedistribueerde model.

- CO:14 Samenvoeging
Operational Excellence helpt bij het leveren van workloadkwaliteit via gestandaardiseerde processen en teamcohesie. In dit patroon zijn de configuratie en het onderhoud van de uitbestede functionaliteit ondergebracht bij één punt, in plaats van beheer vanuit meerdere knooppunten te vereisen. Deze centralisatie standaardiseert hoe kruislingse problemen worden toegepast, waardoor routine- en ad-hoc operationele wijzigingen consistent en voorspelbaar worden gemaakt.

- OE:02 Bewerkingen standaardiseren
Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door middel van optimalisaties in schalen, gegevens en code. Door een offloading-gateway toe te voegen aan het aanvraagproces, kunt u minder resources per knooppunt gebruiken omdat de functionaliteit is gecentraliseerd op de gateway. U kunt de implementatie van de offloaded functionaliteit onafhankelijk van de toepassingscode optimaliseren. Uitbestede platformgeleverde functionaliteit is waarschijnlijk al hoog presterend.

- PE:03 Services selecteren

Als dit patroon compromissen binnen een pijler introduceert, moet u deze tegen de doelstellingen van de andere pijlers overwegen.

Example

Azure Application Gateway WAF_v2 kan dit patroon implementeren voor een regionale webtoepassing. De gateway beëindigt client-TLS-verbindingen, past WAF- en routeringsbeleid toe en brengt nieuwe TLS-verbindingen tot stand met de back-endservices. Dit ontwerp houdt problemen met gedeelde aanvraagverwerking buiten de code van de back-endtoepassing.

Application Gateway met TLS-ontlasting

In het volgende diagram ziet u hoe Application Gateway binnenkomende TLS-verbindingen beëindigt, het verkeer inspecteert en filtert en opnieuw versleutelt voordat deze wordt doorgestuurd naar een back-endpool via TLS.

Diagram waarin Application Gateway binnenkomende TLS van clients beëindigt, WAF- en routeringsregels toepast en verkeer via TLS opnieuw versleutelt naar een back-endpool.

Deze architectuur maakt gebruik van de volgende Application Gateway-onderdelen om gedeelde mogelijkheden te offloaden en back-endverkeer opnieuw te versleutelen:

  • HTTPS-listenaar. Een HTTPS-listener op poort 443 accepteert binnenkomende TLS-verbindingen van clients.
  • TLS-certificaat. Een PFX-certificaat, afkomstig uit Azure Key Vault, is gekoppeld aan de HTTPS-listener. Application Gateway ontsleutelt inkomend verkeer om het te inspecteren en te routeren en versleutelt het vervolgens opnieuw naar de back-endpool. Back-endservers hebben nog steeds certificaten nodig voor de opnieuw versleutelde verbindingen, maar in veel gevallen kunnen door platform beheerde certificaten worden gebruikt.
  • Backendgroep. Een back-endpool definieert de set HTTPS-servers die het opnieuw versleutelde verkeer ontvangen. Back-enddoelen kunnen virtuele machines, Azure-schaalvergrotingssets voor virtuele machines, IP-adressen of Azure App Service-instanties zijn. Beperk back-endtoegang zodat clients Application Gateway en het WAF-beleid niet kunnen omzeilen door rechtstreeks verbinding te maken.
  • HTTP-instellingen voor back-end. Stel het back-endprotocol in op HTTPS en de poort naar de TLS-poort van de back-end, zoals 443. Configureer certificaatvertrouwen en een hostnaam die overeenkomt met het back-endcertificaat. Voor een persoonlijke certificeringsinstantie configureert u het vertrouwde basiscertificaat. Zie End-to-end TLS met de v2-SKU voor meer informatie.
  • Routeringsregel. Een aanvraagrouteringsregel koppelt de listener aan de back-endpool en de HTTP-instellingen voor de back-end. Op paden gebaseerde regels kunnen verschillende URL-paden naar verschillende backendpools doorsturen.
  • WAF-beleid. Het beleid definieert de beheerde en aangepaste regels die worden gebruikt om aanvragen te inspecteren, inclusief geomatch-regels.

Omdat Application Gateway het verkeer ontsleutelt, kan deze de aanvraaginhoud controleren op intelligente routering, HTTP-headers en URL's herschrijven en WAF-regels toepassen. Vervolgens wordt het verkeer opnieuw versleuteld voordat aanvragen naar de back-end worden doorgestuurd.

Zie End-to-end TLS-versleuteling met Application Gateway voor configuratierichtlijnen.

Ondersteunende technologieën

De volgende Azure-services kunnen u helpen dit patroon te implementeren:

Volgende stappen 

  • Last updated on