Ljus
Mörk
Författare
David Lindin @ Asurgent
Read time
8 min
26 mars 2026
Azures nätverkstjänster: vilket skydd behöver du egentligen? Har du någon gång suttit framför Azure-portalen och känt att du stirrar på fyra olika tjänster som alla verkar göra ungefär samma sak? Azure Firewall, Application Gateway, Front Door, alla med fina namn och övertygande beskrivningar. Det är lätt att antingen välja fel, eller att köpa allt på en gång och hoppas att det löser sig.
Det gör det sällan. Men det finns en logik i hur de hänger ihop, och när man väl ser den är det ganska uppenbart vad som passar vad.
Det hjälper att börja med en enkel fråga: var kommer trafiken ifrån, och vart ska den? Azure-tjänsterna för nätverkssäkerhet är byggda för olika delar av den resan, och de är tänkta att komplettera varandra snarare än ersätta.
En enkel bild av hur lagren förhåller sig till varandra:
Det är inte alltid alla lager behövs, men det är så de är tänkta att samverka. Mer om det längre ned, inklusive vad som händer inuti ett AKS-kluster när trafiken väl är inne.
Azure Firewall är den tjänst som kontrollerar trafiken inne i nätverket, mellan subnät, mot internet och mot andra anslutna miljöer. Den arbetar på nätverks- och applikationsnivå, kan filtrera baserat på FQDN, protokoll och IP-adresser, och är tänkt att sitta centralt i en hub-and-spoke-arkitektur.
Ett av de vanligaste misstagen är att glömma UDR, User Defined Routes, på spoke-nätens subnät. Utan dem går trafiken förbi brandväggen helt och hållet, oavsett hur väl den är konfigurerad. Det innebär i praktiken att lateral rörelse mellan spoke-nätverk är helt ohindrad, ett angripare som tar sig in i dev-miljön kan nå produktionsmiljön utan att ett enda brandväggsregelpaket granskas.
En annan klassiker är att starta med Azure Firewall Standard när miljön egentligen kräver Premium, särskilt om IDPS eller TLS-inspektion behövs. Standard-varianten saknar möjlighet att inspektera krypterad trafik, vilket betyder att skadlig kommunikation dold i HTTPS passerar obemärkt. Det går att uppgradera, men det är enklare att börja rätt.
Det tredje misstaget är mer subtilt: att lägga Azure Firewall i samma subnät som andra resurser. Den behöver ett dedikerat subnät som heter exakt AzureFirewallSubnet, annars vägrar den att starta. Det är inte en säkerhetsrisk i sig, men det blockerar hela deploymenten och skapar onödigt arkitekturarbete i efterhand.
Application Gateway: skyddet framför webbapplikationen
Application Gateway är en lastbalanserare designad för att ta emot HTTP- och HTTPS-trafik mot webbapplikationer. Den förstår HTTP-protokollet på djupet, kan terminera TLS, routa baserat på URL-sökvägar och skydda mot OWASP-attacker som SQL injection och cross-site scripting.
En sak värd att nämna direkt: WAF-funktionaliteten finns inte i alla SKU:er. Standard-varianten av Application Gateway saknar WAF, så om skyddet är syftet är det viktigt att välja WAF-SKU:n redan från start.
WAF i Detection-läge är en fälla som många går i. Det loggar, men det blockerar ingenting. Det är bra under en inkörsperiod för att undvika falska positiver, men det är förvånansvärt vanligt att det aldrig ändras till Prevention. Resultatet är en WAF som ser SQL injection-försök och cross-site scripting passera i realtid, dokumenterar dem noggrant i loggar, och låter dem gå vidare till applikationen utan att röra dem. En välkonfigurerad WAF i fel läge ger en falsk känsla av trygghet som är svårare att hantera än ingen WAF alls.
Ett annat misstag är att sätta backend-poolen till publika IP-adresser istället för privata. När backends exponeras publikt kan de nås direkt från internet utan att gå via Application Gateway, vilket innebär att WAF, routingregler och TLS-terminering kringgås fullständigt. Application Gateway bör kommunicera med sina backends via privat nätverk.
Och slutligen, Health Probes. Standardinställningen använder HTTP mot rot-URL:en, vilket inte alltid fungerar mot applikationer som kräver HTTPS eller har en specifik health-endpoint. En tyst misslyckad probe innebär att Application Gateway tar bort backends ur rotation utan någon uppenbar anledning, vilket leder till intermittenta 502-fel som är svåra att felsöka och ser ut som applikationsfel snarare än konfigurationsfel.
Azure Front Door: den globala ingångspunkten
Front Door är en global ingångspunkt, ett CDN och en lastbalanserare som fungerar över Microsofts globala nätverk. Den kan dirigera användare till närmaste friska backend, cachelagra innehåll, terminera TLS nära användaren och erbjuder också WAF-funktionalitet.
En fråga som dyker upp förr eller senare är om det verkligen behövs WAF på båda. Front Door har ju redan WAF, varför lägga till en till på Application Gateway?
Svaret beror på vad man vill uppnå. Front Doors WAF sitter nära användaren och blockerar trafik tidigt, innan den ens når den egna infrastrukturen, vilket är bra för prestanda och kostnad. Application Gateways WAF sitter däremot precis framför applikationen och kan inspektera trafik som redan passerat Front Door, till exempel om någon lyckas nå Application Gateway direkt via dess publika IP och kringgår Front Door helt.
Det finns alltså ett värde i att ha båda, men det är inte självklart motiverat i alla miljöer. För en enklare setup räcker WAF på ett ställe, förutsatt att backends är ordentligt låsta. För reglerade miljöer eller höga krav på djupförsvar kan dubbla lager vara precis rätt. Priset är högre och det kräver att WAF-reglerna hålls synkroniserade, annars skapas en falsk trygghet.
Det vanligaste misstaget med Front Door är att glömma låsa backends. Om Application Gateway eller App Service är tillgänglig direkt från internet går det att kringgå Front Door helt, inklusive dess WAF och geo-filtrering. En angripare som hittar backend-adressen via DNS-historik, Certificate Transparency-loggar eller enkel scanning kan skicka trafik direkt dit och undvika samtliga skyddslager som Front Door erbjuder. Backends bör begränsas till att enbart acceptera trafik från Front Doors service tag AzureFrontDoor.Backend.
Ett annat misstag är att blanda ihop Front Door Classic med Front Door Standard och Premium. Classic är den äldre varianten med andra begränsningar och annat pris, och det skapar förvirring när dokumentation och portal inte pratar om samma sak. Välj Standard eller Premium för nya deployments.
Inuti klustret: ingress, mesh och service-till-tjänste-kommunikation
Hittills har vi pratat om nätverksskydd utanför applikationslagren, men kör man AKS eller liknande containerplattformar tillkommer ett eget styrningslager som förändrar bilden något, och det är värt att förstå var det passar in.
När trafiken väl är inne i klustret behövs något som hanterar routning vidare till enskilda tjänster. Det klassiska sättet är en Ingress Controller, till exempel Nginx eller den inbyggda AGIC-integrationen som kopplar Application Gateway direkt mot AKS. Det fungerar bra för enklare scenarion och är välbekant för de flesta som jobbat med Kubernetes.
Nästa steg i komplexitet är Gateway API, en nyare Kubernetes-standard för ingresskontroll som ger mer flexibilitet och tydligare rolluppdelning än den äldre Ingress-resursen. Många service mesh-lösningar, däribland Istio, implementerar Gateway API som sin primära ingångspunkt.
Ett service mesh som Istio lägger till ytterligare ett lager ovanpå ingress: ömsesidig TLS mellan tjänster inuti klustret, trafikdelning mellan versioner, och detaljerade routingregler baserade på HTTP-headers eller JWT-claims, saker som ingen extern lastbalanserare är designad för.
En vanlig fråga är om man ens behöver Application Gateway när man har Gateway API eller Istio. Svaret beror på var ansvaret ska ligga. Application Gateway med WAF hanterar skyddet innan trafiken når klustret, vilket är en tydlig ansvarsfördelning som ofta passar bättre i reglerade miljöer eller när säkerhetsteamet och plattformsteamet är separata. Ingress-lagret inuti klustret lever däremot nära applikationerna och styrs av samma team som äger dem, vilket ger mer flexibilitet men också mer ansvar på samma ställe.
I praktiken ser man ofta båda tillsammans: Application Gateway som yttre skyddslager med WAF, och ingress-kontroller eller mesh som hanterar den interna routningen inne i klustret. Det är inte överkurs, det är en naturlig uppdelning när miljön växer i komplexitet.
Vad ska du välja?
Det beror på vad man skyddar och varifrån trafiken kommer. En intern miljö med känsliga resurser behöver Azure Firewall i centrum. En webbapplikation mot externa användare i en region mår bra av Application Gateway med WAF-SKU. En global tjänst vinner på att lägga Front Door som yttersta lager. Kör man Kubernetes med ett service mesh får man ett eget styrningslager inuti klustret som kompletterar resten snarare än ersätter det.
De är inte konkurrenter. De är lager i samma arkitektur, och de flesta mogna Azure-miljöer använder flera av dem tillsammans. Tricket är att förstå vilket problem varje tjänst är byggd för att lösa, och sedan bygga inifrån och ut.
Säkerhet är sällan en stor händelse. Det är summan av många små beslut, tagna i rätt riktning tillräckligt ofta. Ingen börjar om från noll, man börjar bara där man är.
Prenumerera på vårt nyhetsbrev för att ha koll på senaste nytt inom cybersäkerhetssfären.
