Web Application Firewall voor Azure netwerken

Azure Web Application Firewall (WAF) beschermt uw webtoepassingen tegen veelvoorkomende HTTP-laagaanvallen, zoals SQL-injectie, CROSS-site scripting (XSS) en paddoorkruising. In tegenstelling tot Azure Firewall, die verkeer op laag 3 tot en met 7 inspecteert voor bedreigingen op netwerkniveau, werkt WAF alleen op laag 7 en begrijpt HTTP-semantiek, waaronder aanvraagheaders, queryreeksen, aanvraaginstanties en cookies. Implementeer WAF als beleid dat is gekoppeld aan Azure Application Gateway (regionaal) of Azure Front Door (globale rand) om het beveiligingsbereik te koppelen aan uw toepassingsarchitectuur. Web Application Firewall is een van de drie kernnetwerkbeveiligingsdiensten van Azure, naast Azure Firewall en Azure DDoS Protection.

Wat in dit artikel wordt behandeld

Dit artikel bevat informatie over HTTP-laagbeveiliging met behulp van Azure Web Application Firewall. U krijgt meer informatie over:

  • Platformvergelijking tussen WAF op Application Gateway v2 en WAF op Azure Front Door.
  • Regelsets op basis van OWASP, waaronder standaardregelset (DRS) en CRS (Core Rule Set).
  • Detectiemodus versus preventiemodus en wanneer u deze wilt gebruiken.
  • Opties voor het WAF-beleidsbereik: globale koppelingen, koppelingen per site en koppelingen per listener.
  • Aangepaste regels voor frequentiebeperking, geofiltering en toepassingsspecifieke logica.
  • Het onderscheid tussen WAF (Laag 7 HTTP) en Azure Firewall (Laag 3-7-netwerk).

Wie heeft dit artikel nodig

WAF implementeren wanneer uw workloads voldoen aan een of meer van de volgende criteria:

  • Openbare webtoepassingen: Uw toepassingen accepteren binnenkomend HTTP/HTTPS-verkeer van internet, waarbij ze worden blootgesteld aan OWASP Top 10-beveiligingsproblemen, waaronder injectieaanvallen, misbruik van verificatie en pogingen tot blootstelling van gevoelige gegevens.
  • Nalevingsvereisten: Regelgevingskaders zoals PCI DSS (Payment Card Industry Data Security Standard) verplichten een webtoepassingsfirewall voor elke toepassing die betalingskaartgegevens verwerkt.
  • API-beveiliging: uw API's zijn openbaar toegankelijk en vereisen bescherming tegen request smuggling, te grote payloads en protocolaanvallen die netwerkfirewalls niet inspecteren.
  • Botbeperking: U moet geautomatiseerd verkeer categoriseren en beheren, schadelijke bots blokkeren terwijl legitieme crawlers en bewakingsservices worden toegestaan.

Organisaties die alleen verkeer filteren op netwerkniveau (IP, poort en protocol) zonder HTTP-aanvraaginspectie nodig hebben, moeten in plaats daarvan Azure Firewall of NSG's gebruiken.

Focus op lift-and-shift: Veel geherhoste interne apps hebben geen inkomend internetverkeer en hebben geen WAF nodig. Voeg WAF alleen toe wanneer u tijdens of na de migratie een web-app beschikbaar maakt op internet.

Focus moderniseren: Front klantgerichte web-apps met WAF op Azure Front Door voor globale apps, of op Application Gateway voor apps met één regio, afgestemd op uw Front Door versus Traffic Manager-leveringskeuze.

Focus op cross-cloud: Plaats een WAF op laag 7 op Application Gateway in de spoke voor gemigreerde openbare webapps en breng webbeveiligingen van andere clouds (zoals Google Cloud Armor) in kaart ten opzichte van Azure WAF.

Vergelijking van Azure WAF-platforms

Azure WAF is beschikbaar op twee platforms. Elk platform integreert WAF-inspectie in een ander punt in de verkeersstroom.

Diagram met Azure Web Application Firewall architectuur met application gateway- en Front Door-implementatieopties

Vermogen WAF op Application Gateway v2 WAF op Azure Front Door
Implementatiebereik Regionaal (één Azure regio) Wereldwijd (192+ edge PoPs wereldwijd)
Inspectiepunt Nadat het verkeer uw regio heeft bereikt Bij de edge PoP, voordat het verkeer de origin bereikt
Ondersteunde regelsets DRS 2.2, DRS 2.1, CRS 3.2 DRS 2.2, DRS 2.1, DRS 2.0
Aangepaste regels
Botbeveiliging ✔ (Alleen Premium-laag)
Snelheidsbeperking
Geo-filtering
Beleid per site ✔ (per-listener, per-pad) ✔ (per eindpunt)
Beheerde regelsets ✔ (Alleen Premium-laag; Standard ondersteunt alleen aangepaste regels)
Aanvraag carrosserie keuring Maximaal 128 kB (configureerbaar) Maximaal 128 kB (configureerbaar)
ondersteuning voor Private Link origin N/A (inline met App Gateway) ✔ (connectiviteit met privé-origin)
Ideaal voor Apps met één regio, L7-taakverdeling + WAF Apps voor meerdere regio's, wereldwijde acceleratie + WAF

Note

Azure Front Door heeft twee lagen: Standard en Premium. Beheerde regelsets (inclusief DRS- en botbeveiliging) zijn alleen beschikbaar op Front Door Premium. Front Door Standard ondersteunt alleen aangepaste regels. Front Door (klassiek) ondersteunt alleen DRS 1.1 of eerder.

Uw WAF-platform kiezen

Gebruik de volgende beslissingscriteria:

  • Kies WAF in Application Gateway wanneer uw toepassing in één regio wordt geïmplementeerd en u Application Gateway al gebruikt voor laag 7-taakverdeling, TLS-beëindiging of padgebaseerde routering. WAF voegt inline HTTP-inspectie toe zonder dat er een extra servicehop wordt ingevoerd.
  • Kies WAF op Azure Front Door wanneer uw toepassing meerdere regio's omvat, wereldwijde taakverdeling vereist of voordelen van CDN-versnelling (Content Delivery Network). Front Door WAF inspecteert het verkeer op het dichtstbijzijnde edge point of presence (PoP). De service blokkeert schadelijke aanvragen voordat ze de Azure backbone passeren om uw oorsprong te bereiken. Deze aanpak vermindert de blootstelling aan het aanvalsoppervlak en absorbeert volumetrische laag 7-aanvallen aan de rand.
  • Kies beide (gelaagd) wanneer een multiregionale applicatie die via Front Door wordt aangeboden ook regionaal WAF-beleid vereist dat per back-end verschilt. Front Door biedt een eerste verdedigingslinie op wereldwijde schaal, terwijl Application Gateway WAF aangepaste, regiospecifieke regels dichter bij de workload toepast.

Ontwerpoverwegingen

Ontwerpfocus voor LIFT-and-shift WAF

  • Sla WAF over voor opnieuw gehoste workloads die alleen intern worden gebruikt en geen inkomende verbinding vanaf het internet hebben; bekijk dit opnieuw wanneer u een app op het internet publiceert.
  • Wanneer u een web-app publiek toegankelijk maakt, start u WAF in de detectiemodus om een basislijn van het verkeer vast te stellen en schakelt u daarna over naar de preventiemodus nadat u de configuratie hebt afgestemd en de vals-positieven hebt weggewerkt.
  • Gebruik Application Gateway WAF voor een opnieuw gehoste web-app in één regio die u al achter Application Gateway hebt geplaatst voor routering op laag 7.
  • Gebruik de intentie van uw on-premises webbeveiligingsregels (bijvoorbeeld OWASP-dekking) opnieuw als het beginbeleid.

Focus op WAF-ontwerp moderniseren

  • Voer WAF uit in de preventiemodus vanaf het begin voor klantgerichte apps en gebruik de nieuwste beheerde regelset, zodat dekking nieuwe OWASP-bedreigingen automatisch bijhoudt.
  • Schakel botbeheer in om legitieme crawlers te scheiden van schadelijke automatisering tegen uw openbare apps.
  • WAF-beleid beheren als code, zodat actief-actieve regionale back-ends synchroon blijven via uw implementatiepijplijn.
  • Koppel edge WAF met de hubfirewall voor diepgaande verdediging en schakel de factureringskorting voor Application Gateway WAF in door DDoS-netwerkbeveiliging in te schakelen op het VNet.

Aandachtspunten voor cross-cloud WAF-ontwerp

  • Plaats een Layer 7-WAF in een Application Gateway in het spoke-VNet, zodat openbaar webverkeer kan worden geïnspecteerd zonder openbare IP-adressen rechtstreeks aan virtuele machines te koppelen.
  • Wijs bestaande webbeveiligingen van andere clouds (bijvoorbeeld AWS WAF of Google Cloud Armor) toe aan Azure door WAF beheerde regelsets, zodat dekking wordt overgedragen.
  • Inspecteer extern gerichte communicatie via de WAF, en laat inspectie van oost-westverkeer en cross-cloudtransit plaatsvinden op de Virtual WAN-hub-firewall.
  • Laat WAF tijdens de omschakeling eerst in detectie- (leer)modus draaien en schakel handhaving pas in zodra u legitieme verkeerspatronen hebt bevestigd.

Prerequisites

Voordat u Azure Web Application Firewall implementeert, moet u het volgende doen:

  • Application Gateway v2- of Azure Front Door-resource: WAF wordt geïmplementeerd als beleid dat is gekoppeld aan een van deze platforms. U moet een bestaand Application Gateway v2-exemplaar of Azure Front Door profiel hebben ingericht voordat u een WAF-beleid maakt en koppelt.
  • Openbare HTTP/HTTPS-workload: Uw toepassing moet binnenkomend HTTP/HTTPS-verkeer ontvangen. WAF inspecteert semantiek op aanvraagniveau en biedt geen voordeel voor niet-HTTP-workloads of uitsluitend interne services.
  • Inzicht in HTTP-verkeerspatronen: Bekendheid met de normale aanvraagpatronen van uw toepassing (headers, queryparameters en hoofdtekstinhoud) helpt u bij het configureren van uitsluitingen en het afstemmen van regels om fout-positieven te minimaliseren tijdens de overgang naar de detectie-naar-preventiemodus.

Regelsets en regelverwerking

WAF maakt gebruik van regelsets om schadelijke patronen in HTTP-aanvragen te detecteren. Als u de regelhiërarchie en de verwerkingsvolgorde begrijpt, kunt u WAF afstemmen voor uw specifieke toepassingen.

Beheerde regelsets

Microsoft beheert beheerde regelsets op basis van CRS-patronen (OWASP Core Rule Set). De aanbevolen regelset voor nieuwe implementaties is DRS 2.2 (standaardregelset). DRS 2.2 is gebaseerd op OWASP CRS 3.3.4 en voegt Microsoft Handtekeningen voor bedreigingsinformatie toe.

Regelset Op basis van Platformondersteuning Recommendation
DRS 2.2 OWASP CRS 3.3.4 + Microsoft Threat Intel App Gateway v2, Front Door Premium Aanbevolen voor nieuwe implementaties
DRS 2.1 OWASP CRS 3.3 App Gateway v2, Front Door Premium Vorige generatie; ondersteund op beide platforms
DRS 2.0 OWASP CRS 3.2 Alleen voor Front Door Premium Ondersteund; Front Door N-2-versie
CRS 3.2 OWASP CRS 3.2 App Gateway v2 alleen Ondersteund; DRS 2.2 gebruiken voor nieuwe implementaties

DRS- en CRS-regelsets maken gebruik van anomaliesscores. Elke overeenkomende regel draagt bij aan een score in plaats van de aanvraag onmiddellijk te blokkeren. Wanneer de cumulatieve anomaliescore een configureerbare drempelwaarde overschrijdt, neemt de WAF actie (blok of logboek). Deze aanpak vermindert valse positieven in vergelijking met het blokkeren op basis van afzonderlijke regels, omdat één match met lage betrouwbaarheid niet tot handhaving leidt.

Aangepaste regels

Aangepaste regels worden uitgevoerd vóór beheerde regels en gebruiken prioriteitsnummers om de evaluatievolgorde te beheren (lager getal = hogere prioriteit). Aangepaste regels gebruiken voor:

  • Rate limiting: Beperk het aantal aanvragen per client-IP-adres binnen een tijdvenster om credential stuffing en bruteforce-aanvallen tegen te gaan.
  • Geofiltering: Verkeer toestaan of weigeren op basis van het land of de regio van herkomst van de client.
  • IP-toestaanlijsten en blokkadelijsten: Sta IP-adressen van bekende partners toe of blokkeer bekende kwaadwillende partijen voordat beheerde regels worden toegepast.
  • Aanvraagheaderinspectie: Toepassingsspecifieke vereisten afdwingen, zoals verplichte API-sleutels of verwachte inhoudstypen.

Regelset voor botbeveiliging

Beide platforms bieden een set regels voor botbeveiliging die geautomatiseerd verkeer categoriseert in goede bots (geverifieerde zoekmachines), slechte bots (bekende schadelijke scanners) en onbekende bots. Configureer acties voor elke categorie: goede bots toestaan, slechte bots blokkeren en onbekende bots uitdagen met snelheidsbeperking of CAPTCHA.

Detectiemodus tegenover preventiemodus

WAF-beleid werkt in een van de twee modi die bepalen hoe het systeem overeenkomende aanvragen verwerkt:

Mode Gedrag Gebruiksituatie
Detectie Logboeken komen overeen met aanvragen, maar blokkeren ze niet. Aanvragen blijven naar de back-end. Eerste implementatie en regelafstemming. Controleer welke regels worden geactiveerd zonder dat dit invloed heeft op productieverkeer.
Preventie Blokkeert overeenkomende aanvragen en retourneert een 403-antwoord. Registreert de geblokkeerde aanvraag. Productieworkloads nadat het afstemmen van regels is voltooid. Actieve bescherming tegen aanvallen.
  1. Implementeren in de detectiemodus: Schakel WAF in met de door u gekozen regelset in de detectiemodus. Productieverkeer routeren via de WAF.
  2. Logboeken analyseren: Bekijk WAF-logboeken om fout-positieven te identificeren. Bepaal welke regels van toepassing zijn op legitiem applicatieverkeer.
  3. Uitsluitingen maken: Voor regels die valse positieven genereren, kunt u uitsluitingen definiëren waarbij wordt opgegeven welke velden in het verzoek (headers, cookies en queryparameters) voor specifieke regels moeten worden overgeslagen.
  4. Schakel over naar de preventiemodus: Na 1–2 weken met schone detectielogboeken en acceptabele percentages vals-positieven kunt u overschakelen naar de preventiemodus om actief te blokkeren.
  5. Doorlopende bewaking: Ga door met het bewaken van logboeken nadat u bent overgeschakeld naar de preventiemodus. Nieuwe applicatiefuncties of API-wijzigingen kunnen nieuwe vals-positieve patronen introduceren.

Important

Productieworkloads altijd uitvoeren in de preventiemodus. De detectiemodus biedt geen beveiliging. Er worden alleen potentiële aanvallen in logboeken opgeslagen. Gebruik de detectiemodus alleen tijdens de initiële afstemmingsfase of wanneer u een specifiek probleem met een vals-positieve melding oplost.

WAF-beleidsbereik en -koppeling

Een WAF-beleid is een zelfstandige Azure resource die uw modusselectie, configuratie van regelset, aangepaste regels en uitsluitingen bevat. Koppel het beleid aan een of meer doelen om het beveiligingsbereik te beheren.

Waf-beleidsbereik van Application Gateway

Koppel in Application Gateway een WAF-beleid op drie granulariteitsniveaus:

  • Globaal (gateway-breed): Het beleid is van toepassing op alle listeners en padregels in Application Gateway. Gebruik globaal bereik wanneer alle toepassingen achter de gateway dezelfde beveiligingsvereisten delen.
  • Listenerniveau: Een ander WAF-beleid is van toepassing op een specifieke listener (combinatie van hostnaam en poort). Gebruik het bereik op listenerniveau wanneer meerdere toepassingen een gateway delen, maar andere regelafstemming of uitsluitingen nodig hebben.
  • Padregelniveau: Een WAF-beleid is van toepassing op een specifieke URL-padregel binnen een listener. Gebruik het bereik van padregels voor gedetailleerde controle over applicaties met uiteenlopende gevoeligheidsniveaus van back-ends.

Wanneer meerdere toepassingsniveaus van toepassing zijn op één verzoek, krijgt het meest specifieke beleid voorrang: path-rule gaat boven listener-level, dat weer boven global gaat.

Bereik van het Front Door WAF-beleid

In Front Door worden WAF-beleidsregels gekoppeld aan het eindpunt- of routeniveau. Elk Front Door-eindpunt kan een eigen WAF-beleid hebben. Deze aanpak maakt toepassingsspecifieke beveiligingsprofielen mogelijk binnen één Front Door-exemplaar.

Beleid voor het delen van bronnen

Deel één WAF-beleid voor meerdere Application Gateway-exemplaren of Front Door-eindpunten. Azure Firewall Manager biedt gecentraliseerde zichtbaarheid en beheer voor al uw WAF-beleid, ongeacht het platform. Gebruik gedeeld beleid wanneer meerdere resources identieke beveiliging vereisen om het beheer te vereenvoudigen en consistente beveiligingspostuur te behouden.

Onderscheid tussen Azure Firewall

WAF en Azure Firewall beschermen verschillende lagen van de netwerkstack en dienen aanvullende rollen. Implementeer beide voor diepgaande verdediging.

Attribute Firewall voor Webapplicaties Azure Firewall
OSI-laag Laag 7 (alleen HTTP/HTTPS) Lagen 3-7 (netwerk en toepassing)
Verkeerstype Inkomende HTTP/HTTPS-aanvragen voor webtoepassingen Alle verkeersrichtingen (noord-zuid, oost-west)
Focus van de inspectie HTTP-semantiek: headers, body, cookies, URI's IP-adressen, poorten, protocollen, FQDNs, URLs
Regelmotor OWASP-gebaseerde patroonvergelijking + anomaliesscore Netwerkregels, toepassingsregels, NAT-regels
Implementatiemodel Geïntegreerd met App Gateway of Front Door Zelfstandig in hubsubnet met UDR-routering
Typische aanvallen geblokkeerd SQL-injectie, XSS, CSRF, padkruising Poortscans, C2-callbacks, DNS-exfiltratie

Gebruik WAF voor HTTP-toepassingsbeveiliging en Azure Firewall voor gecentraliseerde inspectie van netwerkverkeer. In een hub-spoke-architectuur stroomt verkeer van internet naar een webtoepassing doorgaans via Azure Firewall (voor DNAT- en netwerkinspectie) en vervolgens via Application Gateway met WAF (voor HTTP-laaginspectie). Zie Azure Firewall en verkeersinspectie voor het onderdeel op netwerkniveau.

Beveiligingsoverwegingen

De volgende beveiligingsprocedures helpen u de meeste bescherming te krijgen van WAF:

  • Preventieve modus voor productie: Laat productieworkloads nooit in detectiemodus staan. De detectiemodus biedt zichtbaarheid, maar geen afdwinging, waardoor toepassingen worden blootgesteld aan aanvallen.
  • Het afstemmen van regels is een doorlopend proces: Toepassingen evolueren. Nieuwe API-endpoints, parameters en contenttypen kunnen false positives veroorzaken in bestaande regelsets. Controleer regelmatig WAF-logboeken na implementaties.
  • Log Analytics-integratie: Verzend diagnostische WAF-logboeken naar een Log Analytics werkruimte. Gebruik de WAF-werkmap voor visualisatie van geblokkeerde aanvragen, geactiveerde regels en anomaliescoredistributies.
  • DDoS en WAF samen: WAF beschermt tegen laag 7-toepassingsaanvallen, maar vermindert geen DDoS-aanvallen op de volumetrische netwerklaag. Koppel WAF met Azure DDoS Protection voor volledige stack-dekking.
  • Vergrendeling van oorsprong: Wanneer u Front Door WAF gebruikt, configureert u uw oorsprong om alleen verkeer van de Front Door-servicetag te accepteren. Zonder vergrendeling van oorsprong kunnen aanvallers Front Door omzeilen en aanvragen rechtstreeks verzenden naar uw oorspronkelijke IP-adres.
  • Bescherming van gevoelige gegevens: WAF-logboeken kunnen aanvraaggegevens bevatten. Configureer regels voor het wissen van logboeken voor het maskeren van gevoelige velden (autorisatieheaders, cookies of inhoud van de hoofdtekst) in diagnostische WAF-logboeken.

In de volgende artikelen worden verwante onderwerpen over netwerkbeveiliging behandeld:

Meer informatie

Volgende stappen 

Tip

Zelf verkennen? Ga terug naar de overzichtsnavigator om uw volgende artikel per mogelijkheid te vinden.

De volgende stap in uw lift-and-shift-traject:

Bewaking instellen voor uw gemigreerde netwerk: connectiviteit en prestaties valideren na het configureren van uw webtoepassingsfirewall.

Vervolgens in uw moderniseringstraject:

DDoS-beveiliging inschakelen voor openbare eindpunten: bescherm uw openbare IP-resources tegen gedistribueerde denial-of-service-aanvallen.

De volgende stap in uw cross-cloudtraject:

Uw gemigreerde toepassingen opleveren: load balancers van AWS en Google Cloud toewijzen aan Azure-equivalenten voor uw cloudoverschrijdende workloads.