Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Skydda program och tjänster med hjälp av en dedikerad komponent för att förmedla begäranden mellan klienter och programmet eller tjänsten. Mäklaren validerar och sanerar begäranden och kan ge ett extra säkerhetslager och begränsa systemets attackyta.
Kontext och problem
Många molntjänster exponerar slutpunkter som gör det möjligt för klientprogram att anropa sina API:er via Internet eller ett annat ej betrott nätverk. Koden som implementerar API:erna utlöser eller utför flera uppgifter, inklusive men inte begränsat till autentisering, auktorisering, parameterverifiering och viss eller all bearbetning av begäranden. API-koden kommer sannolikt att komma åt lagring och andra tjänster för klientens räkning.
Om en obehörig användare komprometterar systemet och får åtkomst till programmets värdmiljö exponeras dess säkerhetsmekanismer och åtkomst till data och andra tjänster. Därför kan den skadliga användaren få obegränsad åtkomst till autentiseringsuppgifter, lagringsnycklar, känslig information och andra tjänster.
Lösning
En lösning på det här problemet är att frikoppla koden som implementerar offentliga slutpunkter från koden som bearbetar begäranden och får åtkomst till lagring. Frikoppla koden genom att använda ett fasadlager som kommunicerar med klienter och vidarebefordrar godkända förfrågningar via en intern slutpunkt, kö eller meddelandeförmedlare till de arbetslastkomponenter som hanterar affärsoperationen. Diagrammet ger en översikt på hög nivå över det här mönstret.
Du kan använda Gatekeeper-mönstret för att skydda lagring, eller så kan du använda det som en mer omfattande fasad för att skydda alla funktioner i programmet. Viktiga faktorer är:
Kontrollerad validering: Gatekeepern validerar alla begäranden och avvisar begäranden som inte uppfyller valideringskraven.
Begränsad risk och exponering: Riskerna och exponeringen minskar eftersom gatekeeper-funktionen inte har åtkomst till de autentiseringsuppgifter eller nycklar som den betrodda värddatorn använder för att komma åt lagring och tjänster. Om gatekeepern komprometteras kan angripare inte komma åt dessa autentiseringsuppgifter eller nycklar.
Lämplig säkerhet: Gatekeepern körs i ett begränsat behörighetsläge, medan resten av programmet körs i det fullständiga förtroendeläge som krävs för åtkomst till lagring och tjänster. Om gatekeepern komprometteras kan den inte få direkt åtkomst till programtjänster eller data.
Det här mönstret fungerar som en brandvägg i en typisk nätverkstopografi. Till skillnad från en traditionell brandvägg gör den det möjligt för gatekeepern att undersöka begäranden i detalj och fatta ett programstyrt beslut om huruvida begäran ska skickas till den betrodda värd som utför de uppgifter som krävs. Det här beslutet kräver vanligtvis att gatekeepern validerar och sanerar innehållet i begäran innan den vidarebefordrar det till den betrodda värddatorn. Gatekeepers kan auktorisera begäran, leta efter oväntat eller ogiltigt nyttolastinnehåll, utföra hastighetsbegränsning och utföra olika andra kontroller.
Problem och överväganden
Tänk på följande när du bestämmer hur du ska implementera det här mönstret:
Se till att de betrodda värdarna endast exponerar interna eller skyddade slutpunkter som endast gatekeepern använder. De betrodda värdarna får inte tillgängliggöra några externa slutpunkter eller gränssnitt.
Gatekeepern måste köras i ett läge med begränsad behörighet. I praktiken placerar du gatekeepern och den betrodda backenddelen i separata beräkningsmiljöer och håller backend-slutpunkterna privata.
Gatekeepern bör inte utföra bearbetning som är relaterad till programmet eller tjänsterna eller åtkomstdata. Dess funktion är endast att verifiera och sanera begäranden. De betrodda värdarna kan behöva utföra extra validering av begäranden, men gatekeepern bör utföra kärnverifieringen.
Använd en säker kommunikationskanal som HTTPS, Secure Sockets Layer (SSL) eller TLS (Transport Layer Security) mellan gatekeepern och betrodda värdar eller uppgifter där det är möjligt. Vissa värdmiljöer stöder dock inte HTTPS på interna slutpunkter.
Att lägga till det extra lagret för att implementera Gatekeeper-mönstret kommer sannolikt att påverka prestandan på grund av den extra bearbetning och nätverkskommunikation som krävs.
Gatekeepern kan vara en enskild felpunkt (SPoF). För att minimera effekten av ett fel bör du överväga att distribuera redundanta instanser och använda en mekanism för automatisk skalning för att säkerställa kapacitet och upprätthålla tillgänglighet.
När du ska använda det här mönstret
Använd det här mönstret i sådana här scenarier:
Du hanterar känslig information.
Du exponerar tjänster som kräver starkt skydd mot skadlig trafik.
Du hanterar verksamhetskritiska åtgärder som inte får utsättas för direkt exponering av backend-tjänster.
Du behöver hålla validering och rensning av förfrågningar åtskilda från den centrala affärslogiken.
Det här mönstret kanske inte är lämpligt när:
Du kan uppfylla säkerhets- och valideringskrav via inbyggda plattformskontroller på serverdelstjänsten utan att lägga till en dedikerad gatekeeper-nivå.
De tillagda nätverkshoppen och valideringslatensen strider mot strikta krav på end-to-end-latens.
Design av arbetsbelastning
Utvärdera hur du använder Gatekeeper-mönstret i en arbetsbelastnings design för att hantera de mål och principer som beskrivs i Azure Well-Architected Framework-pelarna. Följande tabell innehåller vägledning om hur det här mönstret stöder målen för varje pelare.
| Grundpelare | Så här stöder det här mönstret pelarmål |
|---|---|
| Beslut om säkerhetsdesign bidrar till att säkerställa konfidentialitet, integritet och tillgänglighet för arbetsbelastningens data och system. | En gatekeeper i begärandeflödet hjälper dig att centralisera säkerhetsfunktioner som brandväggar för webbprogram, DDoS-skydd, robotidentifiering, manipulering av begäranden, initiering av autentisering och auktoriseringskontroller. - SE:06 Nätverkskontroller - SE:10 Övervakning och hotidentifiering |
| Prestandaeffektivitet hjälper din arbetsbelastning effektivt uppfylla kraven genom optimering av skalning, data och kod. | Du kan använda det här mönstret för att implementera begränsning på en gatekeeper-nivå i stället för att implementera hastighetskontroller på nodnivå. Samordning av hastighetstillstånd mellan alla noder är inte i sig prestandaeffektiv. - PE:03 Välj tjänster |
Om detta mönster inför kompromisser inom en pelare bör du överväga dem mot målen för de andra pelarna.
Example
Gatekeeper-mönstret implementerar vanligtvis en sökväg för skiktade begäranden, där varje lager har ett specifikt ansvar och ett begränsat förtroendeomfång.
Ladda ned en Visio-fil av den här arkitekturen.
I den här designen är Azure Application Gateway med Azure Web Application Firewall den yttre grindvakten. Den inspekterar internetriktad trafik och tillämpar säkerhetskontroller innan trafiken når API-nivån. Azure API Management är den inre grindvakten. Den tillämpar API-specifika kontroller och vidarebefordrar endast godkänd trafik till privata serverdelar.
Till exempel kan Azure Web Application Firewall identifiera och blockera SQL-inmatning och skriptmönster mellan webbplatser, tillämpa regler för protokoll och begärandestorlek och tillämpa robot- och IP-baserad filtrering innan begäranden når API Management eller privata serverdelar.
När du använder API Management i det inre lagret tillämpas principer på inkommande begäranden och utgående svar i gateway-pipelinen. Mer information om hur API Management bearbetar begäranden och svar finns i Principer i API Management. För principalternativ som validering av JSON Web Token (JWT), hastighetsbegränsning, transformering av huvuden och utformning av svar, se referens för API Management-principer.
Använd hanterade identiteter för Azure-resurser konsekvent för autentisering mellan tjänster i den här sökvägen. API Management kan till exempel använda autentisera med hanterad identitetsprincip för att hämta Microsoft Entra token för backend-anrop utan att lagra hemligheter.
Serverdelen förblir privat. Serverdelen kan till exempel vara en Azure App Service app som använder en privat slutpunkt så att appen kan nås privat.
För containerbaserade arbetsbelastningar kan ett alternativ ersätta den interna sökvägen via API Management och App Service med ingressbaserade beräkningsresurser:
Azure Kubernetes Service (AKS), vilket ger dig mer kontroll över val av inkommande kontrollant, Kubernetes-principer, nätverkstopologi och klusteråtgärder.
Azure Container Apps, som är en serverlös hanterad containerplattform som tillhandahåller ingress-funktioner och minskar infrastrukturhanteringen.
I de här alternativen kan ingress dirigera trafik baserat på värdnamn eller sökväg, terminera TLS och exponera endast interna tjänster. Specifika funktioner, till exempel begränsningar för begäranden och tillåta eller neka regler, beror på den valda ingressimplementeringen. Upprätthåll i alla fall gatekeeper-gränserna: tillämpa validering och framtvinga efterlevnad av policyer vid ingress, och håll bakändstjänster endast åtkomliga via gatekeeper-vägen.
Varje lager i den här sökvägen genererar loggar och mått som du bör centralisera. Azure Web Application Firewall-diagnostikloggar registrerar matchade och blockerade regler för varje begäran. API Management genererar gatewayloggar som samlar in varaktighet för begäran, svarskoder och principresultat. Serverdelstjänster genererar telemetri på programnivå. Samla in dessa loggar och mått i Azure Monitor och dirigera dem till en Log Analytics arbetsyta för enhetliga frågor. Standardisera korrelation mellan slutpunkter genom att generera eller vidarebefordra ett korrelations-ID vid gränsen och sprida det via API Management och serverdelstjänster (till exempel via begärandehuvuden och distribuerad spårningskontext) så att en enda transaktion förblir spårbar i alla lager. Använd Microsoft Defender för molnet för att visa säkerhetsrekommendationer för alla gatekeeper-komponenter. Konfigurera aviseringar om avvikande Azure Web Application Firewall blockeringshastigheter eller API Management-feltoppar för att identifiera hot innan de når privata serverdelar.
Nästa steg
Följande vägledning kan vara relevant när du implementerar det här mönstret:
- Azure Web Application Firewall på Application Gateway
- Policys i API-hantering
- Använda privata slutpunkter för App Service-appar
Relaterade resurser
Följande molndesignmönster används ofta tillsammans med Gatekeeper-mönstret: