Inkomend internet: uw toepassing beschikbaar maken op internet

Dit artikel helpt u bij het kiezen van de juiste Azure service om uw toepassing bereikbaar te maken vanaf internet. Hiermee worden openbare IP-adressen, Azure Load Balancer, Application Gateway, Azure Front Door en Azure Traffic Manager vergeleken. Kies de optie die past bij het protocol, de schaal en de beveiligingsvereisten van uw workload.

Wat in dit artikel wordt behandeld

Elke Azure workload die externe gebruikers bedient, heeft een inkomend pad nodig: een manier voor internetverkeer om uw toepassing veilig en betrouwbaar te bereiken. Het kiezen van de verkeerde toegangsbeheerservice leidt tot overprovisioning, beveiligingsproblemen of onnodige complexiteit. Dit artikel helpt u bij het evalueren van zeven Azure services die binnenkomende verbindingen van externe gebruikers accepteren en deze verbindingen routeren naar uw back-endbronnen binnen een virtueel netwerk. U kunt de combinatie selecteren die overeenkomt met uw protocol, schaal, geografie en beveiligingspostuur.

Wie heeft dit artikel nodig

Lees dit artikel als een of meer van deze voorwaarden van toepassing zijn:

• Uw toepassing moet binnenkomende verbindingen van gebruikers of systemen op internet accepteren.
• U moet kiezen uit een openbaar IP-adres, Load Balancer, Application Gateway, Front Door of Traffic Manager op basis van protocol en bereik.
• U moet een beveiligd openbaar toegangspunt ontwerpen voor web-, API- of TCP/UDP-workloads.
• U moet internetblootstelling combineren met WAF, DDoS-beveiliging, TLS-beëindiging of regionale en wereldwijde verkeersdistributie.

Azure services en functies

Azure biedt verschillende services voor inkomend internet. Elke service werkt op een andere laag van de netwerkstack en dient voor een andere use-case.

Hoe elke service werkt

Inzicht in de interne architectuur van elke service helpt u bij het voorspellen van prestaties, het oplossen van problemen en het plannen van de grootte van subnetten.

Openbaar IP-adres

Een openbaar IP-adres van een standaard-SKU is een softwaregedefinieerde resource waarmee een routeerbaar IPv4- of IPv6-adres rechtstreeks wordt toegewezen aan een netwerkinterface, een front-end van de load balancer of een gateway. Het adres is standaard zone-redundant in ondersteunde regio's, wat betekent dat het platform failover in beschikbaarheidszones afhandelt zonder dat dit door u hoeft te worden gewijzigd. Openbare IP-adressen hebben geen verkeersverwerking. Pakketten stromen rechtstreeks naar de gekoppelde resource zonder statuscontrole of distributielogica.

Azure Load Balancer (Standaard, openbaar)

Standard Load Balancer gebruikt een op hash gebaseerd distributiealgoritme over 5-tuple-stromen (bron-IP, bronpoort, doel-IP, doelpoort, protocol). Het werkt volledig in het datapad op laag 4, dus het beëindigt nooit verbindingen en inspecteert nooit de inhoud van pakketten. Statuscontroles (TCP, HTTP of HTTPS) controleren voortdurend backend-instanties en verwijderen niet-functionerende instanties binnen enkele seconden uit roulatie. Load Balancer schaalt automatisch. Er zijn geen capaciteitsplanning of dimensionering van instanties.

Azure Load Balancer (Standaard, intern)

Interne Load Balancer werkt hetzelfde als zijn openbare tegenhanger, maar maakt gebruik van een privé-front-end-IP van het subnet van het virtuele netwerk. Het distribueert verkeer tussen interne lagen, zoals een weblaag die verkeer verzendt naar een API-cluster in de middelste laag. Omdat het geen openbaar IP-adres heeft, is het onzichtbaar voor internet. Koppel deze aan een openbare toegangsbeheerservice, zoals Front Door, Application Gateway of een openbare Load Balancer, die de externe grens afhandelt.

Azure Application Gateway

Application Gateway is een toegewezen virtueel apparaat dat is geïmplementeerd in het subnet van uw virtuele netwerk. Hierbij worden TLS-verbindingen op de gateway beëindigd, worden HTTP-headers en URL's geïnspecteerd en worden verzoeken naar backendpools gerouteerd op basis van padregels, hostheaders of aangepaste statuscontroles. De v2-SKU ondersteunt automatisch schalen (0 tot 125 exemplaren) en zoneredundantie. Omdat het VNet-resident is, kan het privé-back-ends bereiken zonder openbare IP-adressen op deze back-ends te vereisen.

Application Gateway met WAF

Wanneer u de WAF-laag toevoegt, schakelt u de OWASP Core Rule Set en Microsoft Threat Intelligence-regels rechtstreeks in de verwerkingspijplijn van Application Gateway in. Elke HTTP-aanvraag doorloopt de WAF-engine voordat de routeringsregels worden bereikt. De WAF ondersteunt beleidsregels per site, zodat u verschillende regelconfiguraties voor verschillende listener- of hostcombinaties op dezelfde gateway kunt hebben. WAF werkt in de modus Detectie (alleen loggen) of Preventie (blokkeren en loggen).

Azure Front Door (een cloudgebaseerde dienst voor netwerkbeveiliging en contentlevering)

Front Door werkt vanuit het Microsoft wereldwijde edge-netwerk (190+ aanwezigheidspunten). Wanneer een gebruiker verbinding maakt, vinden de TCP-handshake en TLS-onderhandeling plaats op het dichtstbijzijnde aanwezigheidspunt met behulp van Split TCP. Het aanwezigheidspunt onderhoudt een permanente warme verbinding met uw oorsprong, dus elimineert het de koude-startlatentie die gebruikers rechtstreeks kunnen ervaren om verbinding te maken. Front Door voert layer 7-routering, WAF-inspectie, caching en compressie uit aan de netwerkrand voordat het verzoek via het backbone-netwerk van Microsoft wordt doorgestuurd naar de dichtstbijzijnde beschikbare origin.

Azure Traffic Manager

Traffic Manager is een op DNS gebaseerde service zonder tussenkomst van gegevenspaden. Wanneer een client uw Traffic Manager-hostnaam oplost, wordt een CNAME geretourneerd die verwijst naar het gezondste of dichtstbijzijnde eindpunt op basis van uw routeringsmethode (prioriteit, gewogen, prestaties, geografische, meerdere waarden of subnet). Traffic Manager test continu de eindpuntstatus en werkt DNS-antwoorden dienovereenkomstig bij. Omdat het toepassingsverkeer nooit ziet, werkt het met elk protocol: HTTP, TCP, UDP of bedrijfseigen protocollen.

Vergelijking van kostenmodel

Elke ingress-service hanteert een ander facturatiemodel. Gebruik deze tabel om de kosten te schatten op het verwachte verkeersvolume.

Hoe te kiezen

Gebruik de volgende beslissingstabellen om de juiste ingress-service voor uw workload te kiezen. Begin met de beslissingstabel op hoog niveau en gebruik vervolgens de gedetailleerde vergelijking om uw keuze te bevestigen.

Application Gateway versus Front Door versus Traffic Manager

In deze tabel kunt u kiezen tussen de drie meest voorkomende HTTP- en HTTPS-toegangsbeheerservices.

Vergelijking van ingress-services

Gebruik deze gedetailleerde vergelijking wanneer u de mogelijkheden van elke service moet begrijpen.

Architectuur voor inkomend internetverkeer

In het volgende diagram ziet u veelvoorkomende servicechainingpatronen voor inkomend verkeer naar Azure workloads. Elk patroon combineert laag 7- en Laag 4-services die overeenkomen met een specifiek protocol, regionaal bereik en beveiligingspostuur.

Algemene patronen voor inkomend verkeer

De volgende patronen combineren meerdere services voor een complete ingress-architectuur. Kies het patroon dat overeenkomt met uw protocolvereisten, regionaal bereik en beveiligingspostuur.

Patroon 1: Globale webtoepassing met edge-beveiliging

Diensten: Front Door → Application Gateway (met WAF) → VM’s/containers

Scenario: Een SaaS-toepassing die klanten in Noord-Amerika, Europa en Azië bedient, heeft wereldwijde versnelling, DDoS-beveiliging aan de rand en regionale padgebaseerde routering naar verschillende microservices nodig.

Front Door beëindigt gebruikersverbindingen op het dichtstbijzijnde aanwezigheidspunt (PoP), past globale WAF-regels toe en slaat statische inhoud in de cache op. Verkeer routeert via de Microsoft backbone naar de regionale Application Gateway, die op URL's gebaseerde routering uitvoert (bijvoorbeeld /api/* naar de API-pool, /static/* naar een back-end voor opslag). Dit patroon biedt twee lagen WAF-inspectie: één aan de rand en één in de regio.

Patroon 2: niet-HTTP voor meerdere regio's met DNS-failover

Diensten: Traffic Manager → Standard Load Balancer (per regio) → VM's

Scenario: Een gamingbedrijf voert toegewezen gameservers uit op UDP-poort 7777 in drie regio's. Spelers maken automatisch verbinding met de dichtstbijzijnde gezonde regio.

Traffic Manager gebruikt de routeringsmethode voor prestaties om de DNS-record te retourneren voor de regio met de laagste latentie. Elke regio heeft een Standard Load Balancer die UDP-verkeer over een Virtual Machine Scale Set verdeelt. Als statustests een regionale fout detecteren, werkt Traffic Manager DNS bij om spelers naar de dichtstbijzijnde regio te routeren.

Patroon 3: Eenvoudige regionale web-app met WAF

Diensten: Application Gateway (met WAF) → VM’s

Scenario: Een interne Line-Of-Business-toepassing die wordt blootgesteld aan externe partners. Eén regio, gemiddeld verkeer, heeft OWASP-beveiliging en TLS-beëindiging nodig.

Application Gateway biedt padgebaseerde routering, cookieaffiniteit voor sessiebeheer en WAF-beveiliging, allemaal van één regionale resource binnen het virtuele netwerk. Dit patroon voorkomt de complexiteit en kosten van een wereldwijde service wanneer verkeer geografisch is geconcentreerd.

Patroon 4: Front Door met afgeschermde privé-origins

Diensten: Front Door Premium → Private Link → interne Load Balancer →-VM's

Scenario: Een toepassing voor financiële dienstverlening met strikte eisen waaraan de oorsprong geen openbare IP-blootstelling mag hebben. Al het verkeer moet het Microsoft backbone-netwerk passeren zonder openbare internethops.

Front Door Premium maakt verbinding met de oorsprong via een Private Link-eindpunt. De oorspronkelijke back-end heeft geen openbaar IP-adres en geen blootstelling aan internet. Dit patroon biedt de beveiliging van een volledig privé-origin in combinatie met de prestatievoordelen van het wereldwijde edge-netwerk van Front Door.

Inkomend verkeer in meerdere regio's met Front Door

In het volgende diagram ziet u Azure Front Door als een globaal toegangspunt, waarbij gebruikers worden omgeleid naar de dichtstbijzijnde gezonde regionale oorsprong met automatische failover.

Prerequisites

Voordat u uw toepassing beschikbaar maakt op internet, moet u ervoor zorgen dat u over de volgende onderdelen beschikt:

• Virtueel netwerk geïmplementeerd: Uw back-endbronnen moeten worden uitgevoerd binnen een Azure virtueel netwerk met subnetten met de juiste grootte. Zie Ontwerp uw virtuele netwerk en subnetten voor richtlijnen voor subnetplanning.
• Actieve workload: U hebt ten minste één back-endresource (virtuele machine, container of platformservice) nodig die gereed is voor verkeer.
• DNS-naam: Een openbare DNS-naam die externe gebruikers gebruiken om uw toepassing te bereiken. U kunt Azure DNS of een externe DNS-provider gebruiken.
• Subnetplanning voor toegangsbeheerservices: Application Gateway vereist een toegewezen subnet (minimaal /24 aanbevolen voor productie). Standard Load Balancer back-endinstanties kunnen een subnet delen met andere resources.

Ontwerpoverwegingen

Beveiligingsoverwegingen

Internetingress is de voordeur van uw toepassing. Het is de grens waar niet-vertrouwd internetverkeer uw Azure-omgeving binnenkomt. Volg deze procedures om uw toegangspad te beveiligen.

Virtuele machines nooit rechtstreeks beschikbaar maken met openbare IP-adressen

Wijs geen openbaar IP-adres rechtstreeks toe aan de netwerkinterface van een virtuele machine voor het verwerken van toepassingsverkeer op poort 80 of 443. Plaats in plaats daarvan een load balancer of Application Gateway tussen internet en uw VM's. Deze benadering biedt u het volgende:

• Statuscontroles om defecte instanties uit de roulatie te halen
• Eén punt voor SSL- of TLS-beëindiging
• Een plek om WAF-regels en frequentiebeperking toe te passen
• Gecentraliseerde logboekregistratie van al het binnenkomende verkeer

WAF inschakelen in de preventiemodus

Als u Application Gateway implementeert met WAF of Azure Front Door met WAF, stelt u de WAF in op de preventiemodus voor productieworkloads. De preventiemodus blokkeert schadelijke aanvragen voordat ze uw toepassing bereiken. De detectiemodus registreert alleen bedreigingen zonder ze te blokkeren. Gebruik de detectiemodus alleen tijdens het eerste testen om regels af te stemmen en fout-positieven te identificeren.

De WAF Default Rule Set (DRS) beschermt tegen OWASP top 10-aanvallen, waaronder SQL-injectie, scripting op meerdere sites en uitvoering van externe code. DRS bevat ook Microsoft Threat Intelligence-regels die bekende schadelijke IP-adressen en payloads detecteren.

DDoS-beveiliging inschakelen

Voor alle virtuele netwerken met openbare resources moet DDoS-beveiliging zijn ingeschakeld. Azure DDoS Network Protection biedt adaptieve afstemming, aanvalstelemetrie en kostenbeveiliging voor uw openbare IP-adressen. Zonder DDoS-beveiliging kan een volumetrische aanval uw toegangsbandbreedte verzadigen en uw toepassing onbereikbaar maken.

Zie DDoS-beveiliging voor uw netwerk voor meer informatie.

NSG's gebruiken voor diepgaande verdediging

Zelfs wanneer u een load balancer of Application Gateway gebruikt, configureert u regels voor netwerkbeveiligingsgroepen op uw back-endsubnetten om te beperken welke verkeersbronnen uw VM's kunnen bereiken. Een correct geconfigureerde NSG:

• Hiermee staat u alleen verkeer toe vanuit het subnet of de servicetag van de load balancer
• Weigert direct inkomend verkeer vanaf het internet naar backend-VM's
• Registreert geweigerd verkeer voor beveiligingsmonitoring

Zie Netwerkbeveiligingsgroepen en toepassingsbeveiligingsgroepen voor het plannen van NSG's.

TLS 1.2 of hoger afdwingen

Configureer alle toegangsbeheerservices om alleen TLS 1.2 of TLS 1.3 te accepteren. Schakel TLS 1.0 en 1.1 uit, met bekende beveiligingsproblemen. Zowel Application Gateway als Front Door ondersteunen minimale TLS-versieconfiguratie via hun TLS-beleidsinstellingen. Gebruik vooraf gedefinieerde beleidsregels, zoals AppGwSslPolicy20220101 voor Application Gateway, in plaats van aangepaste coderingsconfiguraties, tenzij u specifieke nalevingsvereisten hebt.

Origins vergrendelen voor Front Door

Wanneer u Azure Front Door gebruikt, beperkt u uw oorspronkelijke servers om alleen verkeer van Front Door te accepteren. Als uw oorsprong verkeer van een bron accepteert, kunnen slechte actoren de WAF van Front Door omzeilen door rechtstreeks verbinding te maken met het ip-adres van de oorsprong, waardoor uw hele WAF-investering ineffectief is.

Origin Lockdown maakt gebruik van twee onafhankelijke verificatiemechanismen. Beide toepassen voor diepgaande verdediging:

Beperking van servicetags (netwerklaag)

Configureer de NSG van uw origin of Azure Firewall om alleen inkomend HTTP/HTTPS-verkeer van de AzureFrontDoor.Backend servicetag toe te staan. Deze servicetag bevat alle IP-bereiken die door Front Door worden gebruikt om verbinding te maken met origins. Pas deze regel toe op het subnet of de NIC waar uw oorsprong zich bevindt:

• NSG-regel: Prioriteit 100, Bron = Service Tag AzureFrontDoor.Backend, Doel = uw backendsubnet, Poorten = 80, 443, Actie = Toestaan.
• Standaard blokkeren: Zorg ervoor dat geen andere regel binnenkomend verkeer op poorten 80/443 vanaf het internet toestaat. De standaardregel DenyAllInbound van de NSG verwerkt dit, tenzij u een bredere regel Voor toestaan toevoegt.

De servicetag alleen is onvoldoende omdat alle Front Door-exemplaren in alle Azure klanten dezelfde IP-adresbereiken voor servicetags delen. Een slechte actor kan een eigen Front Door-profiel maken en dit routeren naar uw oorspronkelijke IP-adres, waarbij uw WAF-regels worden overgeslagen.

Validatie van de X-Azure-FDID-header (applicatielaag)

Elke aanvraag van Front Door bevat een X-Azure-FDID header met de unieke id (GUID) van het Front Door-exemplaar dat de aanvraag heeft verzonden. Valideer deze header in uw toepassing of omgekeerde proxy om te bevestigen dat de aanvraag afkomstig is van uw Front Door-profiel, niet een slechte actor:

1. Zoek uw Front Door-id in de Azure-portal onder de overzichtspagina van uw Front Door-profiel (het veld Front Door-id).
2. In de configuratie van uw toepassingscode of webserver negeert u een aanvraag die X-Azure-FDID niet overeenkomt met de verwachte GUID.
3. HTTP 403 retourneren voor aanvragen met een ontbrekende of onjuiste headerwaarde.

Als u de servicetag combineert (niet-Front Door-verkeer op het netwerk blokkeert) met headervalidatie (blokkeert het Front Door-verkeer van andere klanten in de toepassing), zorgt u ervoor dat alleen uw Front Door-exemplaar uw oorsprong kan bereiken.

Private Link-oorsprongen (meest beperkende vergrendeling)

Voor workloads waarvoor het hoogste niveau van oorsprongisolatie is vereist, ondersteunt Front Door Premium Private Link origins. Uw origin-server heeft geen publiek IP-adres nodig. Front Door maakt verbinding via een privé-eindpunt via de Microsoft backbone. Deze aanpak elimineert de noodzaak van servicetagregels of headervalidatie omdat de oorsprong volledig van het openbare internet onbereikbaar is.

Verwante artikelen

• Uw virtuele netwerk en subnetten ontwerpen: Subnetgrootte voor Application Gateway en Load Balancer back-ends
• Netwerkbeveiligingsgroepen en toepassingsbeveiligingsgroepen: NSG-regels om back-endtoegang te beperken na inkomend verkeer
• Levering en prestaties van toepassingen: prestaties afstemmen nadat uw toegangspad tot stand is gebracht
• Uitgaande internettoegang: Uitgaand verkeer beheren, de uitgaande tegenhanger voor inkomend verkeer
• Beveiligde beheerderstoegang: beheerderstoegangspatronen, verschillend van inkomend internet voor toepassingsgebruikers
• Web Application Firewall: gedetailleerde WAF-configuratie en regelafstemming
• DDoS-beveiliging voor uw netwerk: DDoS-beveiligingsplanning voor alle openbare resources

Meer informatie

• Wat is Azure Load Balancer?
• Wat is Azure Application Gateway?
• Wat is Azure Front Door?
• Wat is Azure Traffic Manager?
• Openbare IP-adressen in Azure
• Azure Web Application Firewall in Application Gateway
• overzicht van Azure DDoS-netwerkbeveiliging

Volgende stappen