Gatekeeper-patroon

Beveilig toepassingen en services met behulp van een speciaal onderdeel voor brokeraanvragen tussen clients en de toepassing of service. De broker valideert en ontsmet de aanvragen en kan een extra beveiligingslaag bieden en de kwetsbaarheid voor aanvallen van het systeem beperken.

Context en probleem

Veel cloudservices maken eindpunten beschikbaar waarmee clienttoepassingen hun API's via internet of een ander niet-vertrouwd netwerk kunnen aanroepen. De code waarmee de API's worden geïmplementeerd, activeert of voert verschillende taken uit, waaronder maar niet beperkt tot verificatie, autorisatie, parametervalidatie en sommige of alle aanvraagverwerking. De API-code heeft waarschijnlijk namens de client toegang tot opslag en andere services.

Als een kwaadwillende gebruiker inbreuk maakt op het systeem en toegang krijgt tot de hostingomgeving van de toepassing, worden de beveiligingsmechanismen en toegang tot gegevens en andere services weergegeven. Als gevolg hiervan kan de kwaadwillende gebruiker onbeperkte toegang krijgen tot referenties, opslagsleutels, gevoelige informatie en andere services.

Solution

Een oplossing voor dit probleem is het loskoppelen van de code waarmee openbare eindpunten worden geïmplementeerd vanuit de code die aanvragen verwerkt en toegang krijgt tot opslag. Koppel de code los met behulp van een façadelaag die communiceert met clients en goedgekeurde aanvragen doorstuurt via een intern eindpunt, een wachtrij of broker naar de workloadonderdelen die de bedrijfsbewerking verwerken. Het diagram biedt een algemeen overzicht van dit patroon.

Diagram met een algemeen overzicht van het Gatekeeper-patroon.

U kunt het Gatekeeper-patroon gebruiken om opslag te beveiligen, of u kunt het gebruiken als een uitgebreidere gevel om alle functies van de toepassing te beveiligen. Belangrijke factoren zijn:

  • Gecontroleerde validatie: De gatekeeper valideert alle aanvragen en weigert aanvragen die niet voldoen aan de validatievereisten.

  • Beperkt risico en blootstelling: Risico's en blootstelling worden verminderd omdat de gatekeeper geen toegang heeft tot de referenties of sleutels die de vertrouwde host gebruikt voor toegang tot opslag en services. Als de gatekeeper wordt aangetast, hebben aanvallers geen toegang tot deze referenties of sleutels.

  • Juiste beveiliging: De gatekeeper wordt uitgevoerd in een modus met beperkte bevoegdheden, terwijl de rest van de toepassing wordt uitgevoerd in de modus volledig vertrouwen die is vereist voor toegang tot opslag en services. Als er met de gatekeeper is geknoeid, heeft deze niet rechtstreeks toegang tot de toepassingsservices of -gegevens.

Dit patroon fungeert als een firewall in een doorsnee netwerktopologie. In tegenstelling tot een traditionele firewall kan de gatekeeper aanvragen gedetailleerd onderzoeken en een toepassingsgestuurde beslissing nemen over het doorgeven van de aanvraag aan de vertrouwde host die de vereiste taken uitvoert. Voor deze beslissing moet de gatekeeper doorgaans de aanvraaginhoud valideren en opschonen voordat deze wordt doorgegeven aan de vertrouwde host. Gatekeepers kunnen de aanvraag autoriseren, zoeken naar onverwachte of ongeldige nettoladinginhoud, snelheidsbeperking uitvoeren en verschillende andere controles uitvoeren.

Problemen en overwegingen

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

  • Zorg ervoor dat de vertrouwde hosts alleen interne of beveiligde eindpunten beschikbaar maken die alleen door de gatekeeper worden gebruikt. De vertrouwde hosts mogen geen externe eindpunten of interfaces beschikbaar stellen.

  • De gatekeeper moet worden uitgevoerd in een modus met beperkte bevoegdheden. In de praktijk plaatst u de gatekeeper en de vertrouwde back-end in afzonderlijke rekenomgevingen en houdt u back-end-eindpunten privé.

  • De gatekeeper mag geen verwerking uitvoeren die betrekking heeft op de toepassing of services of toegang tot gegevens. De functie is uitsluitend bedoeld voor het valideren en opschonen van aanvragen. De vertrouwde hosts moeten mogelijk extra aanvraagvalidatie uitvoeren, maar de gatekeeper moet de kernvalidatie uitvoeren.

  • Gebruik waar mogelijk een beveiligd communicatiekanaal zoals HTTPS, Secure Sockets Layer (SSL) of Transport Layer Security (TLS) tussen de gatekeeper en de vertrouwde hosts of taken. Sommige hostomgevingen bieden echter geen ondersteuning voor HTTPS op interne eindpunten.

  • Het toevoegen van de extra laag voor het implementeren van het Gatekeeper-patroon heeft waarschijnlijk invloed op de prestaties vanwege de extra verwerking en netwerkcommunicatie die vereist is.

  • De gatekeeper kan een single point of failure (SPoF) zijn. Als u de impact van een fout wilt minimaliseren, kunt u redundante exemplaren implementeren en een mechanisme voor automatisch schalen gebruiken om de capaciteit te garanderen en de beschikbaarheid te behouden.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

  • U verwerkt gevoelige informatie.

  • U stelt services beschikbaar die sterke bescherming vereisen tegen schadelijk verkeer.

  • U voert bedrijfskritieke bewerkingen uit die geen directe blootstelling van back-endservices tolereren.

  • U moet validatie en opschoning van aanvragen gescheiden houden van de kern van de bedrijfslogica.

Dit patroon is mogelijk niet geschikt wanneer:

  • U kunt voldoen aan beveiligings- en validatievereisten via ingebouwde platformbesturingselementen op de back-endservice zonder een toegewezen gatekeeper-laag toe te voegen.

  • Extra netwerkhops en validatielatentie schenden strikte end-to-end-latentievereisten.

Ontwerp van werkbelasting

Beoordeel hoe u het Gatekeeper-patroon kunt gebruiken in het ontwerp van een workload om in te spelen op de doelstellingen en principes die aan bod komen in de Azure Well-Architected Framework pillars. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.

Pijler Hoe dit patroon ondersteuning biedt voor pijlerdoelen
Beslissingen over beveiligingsontwerpen helpen de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens en systemen van uw workload te waarborgen. Een gatekeeper in de aanvraagstroom helpt u bij het centraliseren van beveiligingsfunctionaliteit, zoals webtoepassingsfirewalls, DDoS-beveiliging, botdetectie, aanvraagbewerking, verificatieinitiatie en autorisatiecontroles.

- SE:06 Netwerkbeheer
- SE:10 Bewaking en detectie van bedreigingen
Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door middel van optimalisaties in schalen, gegevens en code. U kunt dit patroon gebruiken om beperking op gatekeeperniveau te implementeren in plaats van snelheidscontroles op knooppuntniveau te implementeren. Snelheidsstatuscoördinatie tussen alle knooppunten is niet inherent 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

Het Gatekeeper-patroon implementeert doorgaans een gelaagd aanvraagpad, waarbij elke laag een specifieke verantwoordelijkheid en een beperkt vertrouwensbereik heeft.

Diagram met het gelaagde Gatekeeper-patroon.

Een Visio-bestand van deze architectuur downloaden.

In dit ontwerp is Azure Application Gateway met Azure Web Application Firewall de buitenste gatekeeper. Het inspecteert internetverkeer en past beveiligingsmaatregelen toe voordat verkeer de API-laag bereikt. Azure API Management is de interne poortwachter. Het past API-specifieke besturingselementen toe en stuurt alleen goedgekeurd verkeer door naar privéback-ends.

Azure Web Application Firewall kan bijvoorbeeld SQL-injectie en scriptpatronen op meerdere sites detecteren en blokkeren, protocol- en aanvraaggrootteregels afdwingen en bot- en IP-filtering toepassen voordat aanvragen API Management of privéback-ends bereiken.

Wanneer u API Management in de binnenste laag gebruikt, wordt beleid toegepast op binnenkomende aanvragen en uitgaande antwoorden in de gatewaypijplijn. Zie Beleid in API Management voor meer informatie over hoe API Management aanvragen en antwoorden verwerkt. Zie de api Management-beleidsverwijzing voor beleidsopties zoals JSON Web Token-validatie (JWT), snelheidsbeperking, headertransformatie en antwoordvorming.

Gebruik beheerde identiteiten voor Azure resources consequent voor service-naar-service-authenticatie in dit traject. API Management kan bijvoorbeeld de authenticate gebruiken met beleid voor beheerde identiteiten om Microsoft Entra tokens op te halen voor back-end-aanroepen zonder geheimen op te slaan.

De backend blijft afgeschermd. De back-end kan bijvoorbeeld een Azure App Service-app zijn die gebruikmaakt van een private-eindpunt, zodat de app privé toegankelijk is.

Voor gecontaineriseerde workloads kan een alternatief het API Management plus het interne App Service-pad vervangen door ingress-gebaseerde compute:

In deze alternatieven kan ingress op host of pad routeren, TLS beëindigen en alleen intern beschikbare services blootstellen. Specifieke mogelijkheden, zoals aanvraaglimieten en regels voor toestaan of weigeren, zijn afhankelijk van de geselecteerde implementatie van inkomend verkeer. In alle gevallen moet u de grenzen van de gatekeeper behouden: validatie en beleidshandhaving toepassen op inkomend verkeer en back-endservices alleen bereikbaar houden via dat gatekeeper-pad.

Elke laag in dit pad verzendt logboeken en metrische gegevens die u moet centraliseren. Azure Web Application Firewall diagnostische logboeken bevatten overeenkomende en geblokkeerde regels per aanvraag. API Management verzendt gatewaylogboeken die de duur van de aanvraag, antwoordcodes en beleidsresultaten vastleggen. Back-endservices verzenden telemetrie op toepassingsniveau. Verzamel deze logboeken en metrische gegevens in Azure Monitor en routeer ze naar een Log Analytics werkruimte voor geïntegreerde query's. Standaardeer end-to-end-aanvraagcorrelatie door een correlatie-id aan de rand te genereren of door te sturen en door te geven via API Management- en back-endservices (bijvoorbeeld via aanvraagheaders en gedistribueerde traceringscontext), zodat één transactie traceerbaar blijft voor alle lagen. Gebruik Microsoft Defender voor Cloud om aanbevelingen voor beveiliging voor de gatekeeper-onderdelen weer te geven. Configureer waarschuwingen voor afwijkende Azure Web Application Firewall bloksnelheden of API Management-foutpieken om bedreigingen te detecteren voordat ze privéback-ends bereiken.

Volgende stappen 

De volgende richtlijnen zijn mogelijk relevant wanneer u dit patroon implementeert:

De volgende cloudontwerppatronen worden vaak samen met het Gatekeeper-patroon gebruikt:

  • Last updated on