Internet-ingress: exponera ditt program för Internet

Den här artikeln hjälper dig att välja rätt Azure tjänst för att göra ditt program tillgängligt från Internet. Den jämför offentliga IP-adresser, Azure Load Balancer, Application Gateway, Azure Front Door och Azure Traffic Manager. Välj det alternativ som passar arbetsbelastningens protokoll-, skalnings- och säkerhetskrav.

Vad den här artikeln beskriver

Varje Azure arbetsbelastning som hanterar externa användare behöver en ingresssökväg: ett sätt för Internettrafik att nå ditt program på ett säkert och tillförlitligt sätt. Att välja fel ingresstjänst leder till överetablering, säkerhetsluckor eller onödig komplexitet. Den här artikeln hjälper dig att utvärdera sju Azure tjänster som accepterar inkommande anslutningar från externa användare och dirigerar dessa anslutningar till dina serverdelsresurser i ett virtuellt nätverk. Du kan välja den kombination som matchar ditt protokoll, din skala, ditt geografiska område och din säkerhetsstatus.

Vem behöver den här artikeln

Läs den här artikeln om ett eller flera av dessa villkor gäller:

• Ditt program måste acceptera inkommande anslutningar från användare eller system på Internet.
• Du måste välja mellan Public IP, Load Balancer, Application Gateway, Front Door eller Traffic Manager utifrån protokoll och omfång.
• Du måste utforma en säker offentlig startpunkt för webb-, API- eller TCP/UDP-arbetsbelastningar.
• Du måste kombinera internetexponering med WAF, DDoS-skydd, TLS-avslutning eller regional och global trafikdistribution.

Azure tjänster och funktioner

Azure tillhandahåller flera tjänster för ingress via Internet. Varje tjänst fungerar på olika lager i nätverksstacken och har olika användningsfall.

Så här fungerar varje tjänst

Genom att förstå den interna arkitekturen för varje tjänst kan du förutsäga prestanda, felsöka problem och planera storlek på undernät.

Offentlig IP-adress

En offentlig IP-adress av typen Standard SKU är en programvarudefinierad resurs som kopplar en dirigerbar IPv4- eller IPv6-adress direkt till ett nätverksgränssnitt, en lastbalanserares frontend eller en gateway. Adressen är zonredundant som standard i regioner som stöds, vilket innebär att plattformen hanterar redundans mellan tillgänglighetszoner utan någon ändring från din sida. Offentliga IP-adresser har ingen trafikbearbetning. Paket flödar direkt till den anslutna resursen utan hälsokontroll eller distributionslogik.

Azure Load Balancer (standard, offentlig)

Standard Load Balancer använder en hash-baserad distributionsalgoritm över 5 tupppelflöden (käll-IP, källport, mål-IP, målport, protokoll). Den fungerar helt i dataplanet på lager 4, så den avslutar aldrig anslutningar eller granskar nyttolasten. Hälsokontroller (TCP, HTTP eller HTTPS) kontrollerar kontinuerligt backend-instanser och tar bort icke-fungerande instanser från rotationen inom några sekunder. Load Balancer skalas automatiskt. Det finns ingen kapacitetsplanering eller instansstorlek.

Azure Load Balancer (standard, intern)

Intern Load Balancer fungerar på samma sätt som den offentliga motsvarigheten men använder en privat klientdels-IP från det virtuella nätverkets undernät. Den distribuerar trafik mellan interna nivåer, till exempel en webbnivå som skickar trafik till ett API-kluster på mellannivå. Eftersom den inte har någon offentlig IP-adress är den osynlig för Internet. Koppla ihop den med en offentlig ingresstjänst, till exempel Front Door, Application Gateway eller en offentlig Load Balancer, som hanterar den externa gränsen.

Azure Application Gateway

Application Gateway är en dedikerad virtuell installation som distribueras till ditt virtuella nätverksundernät. Den avslutar TLS-anslutningar i gatewayen, inspekterar HTTP-huvuden och URL:er och dirigerar begäranden till backendpooler baserat på sökvägsregler, värdrubriker eller anpassade hälsokontroller. V2 SKU stöder autoskalning (0 till 125 instanser) och zonredundans. Eftersom det är VNet-resident kan det nå privata serverdelar utan att kräva offentliga IP-adresser på dessa serverdelar.

Application Gateway med WAF

När du lägger till WAF-nivån aktiverar du OWASP Core Rule Set och Microsoft Threat Intelligence-regler direkt i Application Gateway-bearbetningspipelinen. Varje HTTP-begäran skickas via WAF-motorn innan du når routningsreglerna. WAF stöder principer per plats, så du kan ha olika regelkonfigurationer för olika lyssnare eller värdkombinationer på samma gateway. WAF fungerar antingen i läget Detektering (enbart loggning) eller Förebyggande (blockering och loggning).

Azure Front Door-tjänsten

Front Door fungerar från det Microsoft globala gränsnätverket (190+ närvaropunkter). När en användare ansluter sker TCP-handskakningen och TLS-förhandlingen vid den närmaste närvaropunkten med hjälp av Delad TCP. Närvaropunkten upprätthåller en ihållande aktiv anslutning till din ursprungsserver, vilket eliminerar den kallstartslatens som användare annars skulle uppleva vid direkt anslutning. Front Door utför Layer 7-routning, WAF-inspektion, cachelagring och komprimering vid kanten innan begäran vidarebefordras till närmaste felfria ursprung via Microsoft stamnätverk.

Azure Traffic Manager

Traffic Manager är en DNS-baserad tjänst utan inblandning av datavägar. När en klient löser ditt Traffic Manager-värdnamn returneras ett CNAME som pekar på den hälsosammaste eller närmaste slutpunkten baserat på routningsmetoden (prioritet, viktad, prestanda, geografisk, flervärdes- eller undernät). Traffic Manager avsöker kontinuerligt slutpunktshälsan och uppdaterar DNS-svar i enlighet med detta. Eftersom den aldrig ser programtrafik fungerar den med något protokoll: HTTP, TCP, UDP eller proprietära protokoll.

Jämförelse av kostnadsmodell

Varje ingresstjänst följer en annan faktureringsmodell. Använd den här tabellen om du vill beräkna kostnaderna för den förväntade trafikvolymen.

Så här väljer du

Använd följande beslutstabeller för att välja rätt ingresstjänst för din arbetsbelastning. Börja med beslutstabellen på hög nivå och använd sedan den detaljerade jämförelsen för att bekräfta ditt val.

Application Gateway jämfört med Front Door jämfört med Traffic Manager

Den här tabellen hjälper dig att välja mellan de tre vanligaste HTTP- och HTTPS-ingresstjänsterna.

Jämförelse av inkommande tjänster

Använd den här detaljerade jämförelsen när du behöver förstå funktionerna i varje tjänst.

Ingressarkitektur på Internet

Följande diagram visar vanliga mönster för tjänstekedjor för inkommande trafik till Azure-arbetsbelastningar. Varje mönster kombinerar Layer 7- och Layer 4-tjänster för att matcha ett specifikt protokoll, regionalt omfång och säkerhetsstatus.

Vanliga ingressmönster

Följande mönster kombinerar flera tjänster för en fullständig ingressarkitektur. Välj det mönster som matchar dina protokollkrav, regionala omfång och säkerhetsstatus.

Mönster 1: Globalt webbprogram med gränssäkerhet

Tjänster: Front Door → Application Gateway (med WAF) → virtuella datorer/containrar

Scenario: Ett SaaS-program som betjänar kunder i Nordamerika, Europa och Asien behöver global acceleration, DDoS-skydd vid gränsen och regional sökvägsbaserad routning till olika mikrotjänster.

Front Door avslutar användaranslutningar vid den närmaste närvaropunkten (PoP), tillämpar globala WAF-regler och cachelagrar statiskt innehåll. Trafikvägar över Microsoft stamnät till den regionala Application Gateway, som utför URL-baserad routning (till exempel /api/* till API-poolen, /static/* till en lagringsserverdel). Det här mönstret innehåller två lager av WAF-inspektion: ett vid kanten och ett i regionen.

Mönster 2: Icke-HTTP för flera regioner med DNS-redundans

Tjänster: Traffic Manager → Standard Load Balancer (per region) → virtuella datorer

Scenario: Ett spelföretag kör dedikerade spelservrar på UDP-port 7777 i tre regioner. Spelare ansluter automatiskt till närmaste felfria region.

Traffic Manager använder prestandaroutningsmetoden för att returnera DNS-posten för regionen med lägst svarstid. Varje region har en Standard Load Balancer som distribuerar UDP-trafik till en skalningsuppsättning för virtuella datorer. Om hälsoavsökningar upptäcker ett regionalt fel uppdaterar Traffic Manager DNS för att dirigera spelare till nästa närmaste region.

Mönster 3: Enkel regional webbapp med WAF

Tjänster: Application Gateway (med WAF) → virtuella datorer

Scenario: Ett internt verksamhetsspecifikt program som exponeras för externa partner. En region, måttlig trafik, behöver OWASP-skydd och TLS-avslutning.

Application Gateway tillhandahåller sökvägsbaserad routning, cookietillhörighet för sessionshantering och WAF-skydd, allt från en enda regional resurs i det virtuella nätverket. Det här mönstret undviker komplexiteten och kostnaden för en global tjänst när trafiken är geografiskt koncentrerad.

Mönster 4: Front Door med låst privat ursprung

Tjänster: Front Door Premium → Private Link → interna Load Balancer → virtuella datorer

Scenario: Ett program för finansiella tjänster med strikta krav på att ursprunget inte får ha någon offentlig IP-exponering. All trafik måste gå via Microsofts stamnät utan hopp via det publika internetet.

Front Door Premium ansluter till ursprunget via en Private Link slutpunkt. Ursprungsserverdelen har ingen offentlig IP-adress och ingen exponering för Internet. Det här mönstret erbjuder säkerheten hos ett helt privat ursprung i kombination med prestandafördelarna med Front Doors globala edge-nätverk.

Ingång i flera regioner med Front Door

Följande diagram visar Azure Front Door som en global startpunkt och dirigerar användare till närmaste felfria regionala ursprung med automatisk redundans.

Förutsättningar

Innan du exponerar programmet för Internet kontrollerar du att du har följande komponenter på plats:

• Virtuellt nätverk distribuerat: Dina serverdelsresurser måste köras i ett Azure virtuellt nätverk med rätt storlek på undernät. Se Designa ditt virtuella nätverk och undernät för planering av undernät.
• Aktiv arbetsbelastning: Du behöver minst en backendresurs (virtuell dator, container eller plattformstjänst) som är redo att betjäna trafik.
• DNS-namn: Ett offentligt DNS-namn som externa användare använder för att nå ditt program. Du kan använda Azure DNS eller en DNS-provider från tredje part.
• Undernätsplanering för ingresstjänster: Application Gateway kräver ett dedikerat undernät (minst /24 rekommenderas för produktion). Standard Load Balancer-backendinstanser kan dela ett undernät med andra resurser.

Designöverväganden

Säkerhetsfrågor

Internetingress är din applikations ytterdörr. Det är gränsen där obetrodd Internettrafik kommer in i din Azure miljö. Följ dessa rutiner för att säkra din ingressväg.

Exponera aldrig virtuella datorer direkt med offentliga IP-adresser

Tilldela inte en offentlig IP-adress direkt till en virtuell dators nätverksgränssnitt för att hantera programtrafik på portarna 80 eller 443. Placera i stället en lastbalanserare eller Application Gateway mellan Internet och dina virtuella datorer. Den här metoden ger dig:

• Hälsokontroller för att ta bort felaktiga instanser ur rotation
• En enskild punkt för SSL- eller TLS-avslutning
• En plats för att tillämpa WAF-regler och hastighetsbegränsning
• Centraliserad loggning av all inkommande trafik

Aktivera WAF i förebyggande läge

Om du distribuerar Application Gateway med WAF eller Azure Front Door med WAF ställer du in WAF på förebyggande läge för produktionsarbetsbelastningar. Förebyggande läge blockerar skadliga begäranden innan de når ditt program. Identifieringsläget loggar endast hot utan att blockera dem. Använd endast identifieringsläge under inledande testning för att justera regler och identifiera falska positiva identifieringar.

WAF-standardregeluppsättningen (DRS) skyddar mot OWASP:s 10 främsta attacker, inklusive SQL-inmatning, skriptkörning mellan platser och fjärrkörning av kod. DRS innehåller även Microsoft hotinformationsregler som identifierar kända skadliga IP-adresser och nyttolaster.

Aktivera DDoS-skydd

Alla virtuella nätverk med offentliga resurser bör ha DDoS-skydd aktiverat. Azure DDoS Network Protection ger anpassningsbar justering, attacktelemetri och kostnadsskydd för dina offentliga IP-adresser. Utan DDoS-skydd kan en volymrisk attack mätta din inkommande bandbredd och göra programmet oåtkomligt.

Mer information finns i DDoS-skydd för nätverket.

Använd NSG:er för djupförsvar

Även när du använder en lastbalanserare eller Application Gateway konfigurerar du regler för nätverkssäkerhetsgrupp i serverdelsundernäten för att begränsa vilka trafikkällor som kan nå dina virtuella datorer. En korrekt konfigurerad NSG:

• Tillåter endast trafik från lastbalanserarens undernät eller tjänsttagg
• Nekar direkt inkommande trafik från Internet till virtuella serverdelsdatorer
• Loggar nekad trafik för säkerhetsövervakning

Information om NSG-planering finns i Nätverkssäkerhetsgrupper och programsäkerhetsgrupper.

Framtvinga TLS 1.2 eller senare

Konfigurera alla ingresstjänster så att de endast accepterar TLS 1.2 eller TLS 1.3. Inaktivera TLS 1.0 och 1.1, som har kända säkerhetsrisker. Både Application Gateway och Front Door har stöd för lägsta TLS-versionskonfiguration via sina TLS-principinställningar. Använd fördefinierade principer, till exempel AppGwSslPolicy20220101 för Application Gateway, i stället för anpassade chifferkonfigurationer om du inte har specifika efterlevnadskrav.

Begränsa ursprung för Front Door

När du använder Azure Front Door begränsar du ursprungsservrarna till att endast acceptera trafik från Front Door. Om ditt ursprung accepterar trafik från någon källa kan dåliga aktörer kringgå Front Door WAF genom att ansluta direkt till ursprungs-IP-adressen, vilket gör hela WAF-investeringen ineffektiv.

Origin Lockdown använder två oberoende verifieringsmekanismer. Använd båda för skydd på djupet:

Begränsning av tjänsttaggar (nätverksnivå)

Konfigurera din ursprungs NSG eller Azure Firewall för att endast tillåta inkommande HTTP/HTTPS-trafik från AzureFrontDoor.Backend tjänsttaggen. Den här tjänsttaggen innehåller alla IP-intervall som används av Front Door för att ansluta till ursprung. Tillämpa den här regeln på undernätet eller nätverkskortet där ditt ursprung finns:

• NSG-regel: Prioritet 100, Källa = Tjänsttagg AzureFrontDoor.Backend, Mål = ditt serverdelsundernät, Portar = 80, 443, Åtgärd = Tillåt.
• Standard neka: Se till att ingen annan regel tillåter inkommande trafik på portar 80/443 från Internet. NSG:ns standardregel DenyAllInbound hanterar detta om du inte lägger till en bredare Tillåt-regel.

Enbart tjänsttaggen är otillräcklig eftersom alla Front Door-instanser i alla Azure kunder delar samma IP-intervall för tjänsttaggar. En dålig aktör kan skapa en egen Front Door-profil och dirigera den till din ursprungs-IP genom att kringgå dina WAF-regler.

Validering av X-Azure-FDID-sidhuvud (applikationslager)

Varje begäran från Front Door innehåller en X-Azure-FDID rubrik som innehåller den unika identifieraren (GUID) för Front Door-instansen som skickade begäran. Verifiera det här HTTP-huvudet i din applikation eller din omvända proxy för att bekräfta att begäran kom från din Front Door-profil, inte från en angripare:

1. Hitta ditt Front Door-ID i Azure portalen under Front Door-profilens översiktssida (fältet "Front Door-ID").
2. I programkoden eller webbserverkonfigurationen avvisar du alla begäranden där X-Azure-FDID inte matchar ditt förväntade GUID.
3. Returnera HTTP 403 för begäranden med ett saknat eller felaktigt rubrikvärde.

Genom att kombinera tjänsttaggen (blockerar icke-Front Door-trafik i nätverket) med sidhuvudvalidering (blockerar andra kunders Front Door-trafik i programmet) ser du till att endast din Front Door-instans kan nå ditt ursprung.

Private Link ursprung (starkaste nedlåsning)

För arbetsbelastningar som kräver den högsta nivån av ursprungsisolering stöder Front Door Premium Private Link ursprung. Ditt ursprung behöver ingen offentlig IP-adress. Front Door ansluter via en privat slutpunkt över Microsoft stamnät. Den här metoden eliminerar behovet av tjänsttaggregler eller sidhuvudvalidering eftersom ursprunget inte kan nås helt och hållet från det offentliga Internet.

Relaterade artiklar

• Utforma ditt virtuella nätverk och dina undernät: Storleksbestämning av undernät för backend-pooler i Application Gateway och Load Balancer
• Nätverkssäkerhetsgrupper och programsäkerhetsgrupper: NSG-regler för att begränsa åtkomst till serverdelen efter inkommande trafik
• Applikationsleverans och prestanda: Prestandaoptimering när din ingressväg har etablerats
• Utgående internetåtkomst: Kontrollera utgående trafik, den utgående motsvarigheten till inkommande
• Säker administrativ åtkomst: Mönster för administratörsåtkomst, som skiljer sig från Internet-ingress för programanvändare
• Brandvägg för webbprogram: Detaljerad WAF-konfiguration och regeljustering
• DDoS-skydd för nätverket: DDoS-skyddsplanering för alla offentliga resurser

Learn more

• Vad är Azure Load Balancer?
• Vad är Azure Application Gateway?
• Vad är Azure Front Door?
• Vad är Azure Traffic Manager?
• Offentliga IP-adresser i Azure
• Azure Web Application Firewall på Application Gateway
• Azure DDoS Network Protection-översikt

Nästa steg