Balans tussen opnemen en blokkeren in WAF

Informatic Digital » Middelen » Balans tussen opnemen en blokkeren in WAF

Vind de Een evenwicht vinden tussen het registreren en vastleggen van een WAF. Het is uitgegroeid tot een van de meest voorkomende problemen voor beveiligings- en operationele teams. Een webapplicatie-firewall kan zeer ernstige aanvallen tegenhouden, maar als deze te agressief is geconfigureerd, kan deze legitieme aankopen, toegang of API-aanroepen blokkeren. Als de configuratie te los is, is de firewall vrijwel puur decoratief. De sleutel is om zorgvuldig af te stemmen wanneer er gelogd moet worden, wanneer er geteld moet worden, wanneer er toegang toegestaan ​​moet worden en wanneer er geblokkeerd moet worden.

In dit artikel gaan we dieper in op hoe je deze balans kunt bereiken met behulp van moderne WAF-functionaliteiten (toegangslijsten, frequentiegebaseerde regels, leermodi, SIEM-integratie, machine learning, enz.), ondersteund door concrete voorbeelden. AWS WAF, ModSecurity, cloud WAF en on-premise oplossingenJe leert hoe je valse positieven kunt beperken zonder het beschermingsniveau te verlagen, hoe je beleidsregels per applicatie kunt organiseren en hoe je het register als een hulpmiddel kunt gebruiken in plaats van als een constante, onbeheersbare bron van ruis.

Wat is een WAF en waarom is registratie zo belangrijk?

Een webapplicatie-firewall fungeert als een intelligente laag tussen de gebruiker en de serverHet analyseren van HTTP/HTTPS-verkeer in realtime. In tegenstelling tot een traditionele netwerkfirewall, die alleen naar poorten en IP-adressen kijkt, analyseert een WAF alles tot in detail: URL's, parameters, request bodies, headers, cookies, HTTP-methoden, enzovoort.

Hun missie is Detecteer en stop typische aanvallen op laag 7.SQL-injectie, XSS, LFI/RFI, aanvallen op toegangscontrole, API-misbruik, agressief scrapen, brute force-aanvallen en zelfs bepaalde DDoS-aanvallen op applicatieniveau zijn allemaal beschermd tegen deze aanvallen. Dit wordt bereikt door voortdurend bijgewerkte sets regels, signatures en beveiligingsbeleid.

Logging is de andere kant van de medaille. Elke WAF-beslissing – toestaan, blokkeren of alleen tellen – kan gepaard gaan met een Gedetailleerde gebeurtenis in de logboekenDeze gegevens maken het volgende mogelijk:

• Onderzoek incidenten: reconstrueer wat er is gebeurd en hoe er een poging is gedaan om een ​​kwetsbaarheid te misbruiken.
• Regels aanpassenValse positieven detecteren door te kijken welke legitieme verzoeken de WAF blokkeert.
• Voldoen aan de regelgeving: aantonen dat er actieve controles bestaan ​​(PCI DSS, AVG, interne audits, enz.).
• Een SIEM-systeem van gegevens voorzien: correleren van applicatieaanvallen met gebeurtenissen op het gebied van netwerk, systeem, identiteit, enz.

Het probleem is dat een slecht afgestelde WAF de logbestanden kan volgooien met duizenden irrelevante gebeurtenissenwaardoor het onmogelijk wordt om te vinden wat belangrijk is en bovendien leidt dit tot onterechte afwijzingen van legitiem verkeer. Dat is waar de kunst van het manipuleren van registratie-, tel- en blokkeringsmethoden om de hoek komt kijken.

Beveiligingsmodellen in WAF: blokkeerlijsten, toegangslijsten en een hybride aanpak.

De meeste moderne WAF's combineren verschillende filtermethoden, wat een directe impact heeft op... hoe verzoeken worden geregistreerd en geblokkeerdGrofweg kunnen we spreken van twee klassieke filosofieën, plus een veelvoorkomend gemengd model.

Een WAF gebaseerd op blokkeerlijst Het volgt een negatief beveiligingsmodel. Het idee erachter is: "Ik sta alles toe, behalve wat ik weet dat slecht is." Het werkt op basis van signaturen van bekende aanvallen (SQL-injectie, XSS, botpatronen, enz.) en regels die definiëren wat als verdacht wordt beschouwd. Het is in eerste instantie gemakkelijker te implementeren, maar als u uitsluitend op dit model vertrouwt, loopt u het risico op... nieuwe aanvalsvectoren of -varianten onopgemerkt binnenglippen.

Een WAF van toegestane lijst Het is precies het tegenovergestelde: "blokkeer alles behalve wat expliciet is toegestaan." Het is gebaseerd op een positief beveiligingsmodel. Alleen verkeer dat voldoet aan het gedefinieerde legitieme gedrag – routes, methoden, parameters, formaten, groottes, enz. – wordt geaccepteerd. Het is veel veiliger, maar vereist aanzienlijke fijnafstemming en kan problemen veroorzaken. valse positieven aan het begin als het niet goed bereid is.

Gezien de voor- en nadelen van elke aanpak, wordt één enkel model steeds gebruikelijker. een combinatie van een toelatingslijst en een blokkeerlijst.In dit scenario worden verwachte verkeersprofielen gedefinieerd (bijvoorbeeld wat een normale login- of betalingsaanvraag inhoudt), en tegelijkertijd worden signatures en heuristieken toegepast om typische kwaadaardige patronen te detecteren. Voor logboekregistratiedoeleinden maakt de hybride aanpak het volgende mogelijk:

• Markeer als hoogrisico-evenement Datgene wat in strijd is met de lijst van toegestane artikelen.
• Behandelen als waarschuwingen met gemiddelde/lage prioriteit Algemene blokkeerlijstpatronen.
• Gebruik de "tel"-modus om te zien wat een regel zou overtreden voordat het blok wordt geactiveerd.

WAF in het netwerk, op de host en in de cloud: impact op logboekregistratie en vergrendeling

Het WAF-implementatiemodel heeft grote invloed op hoe het loggen en blokkeren van verkeer wordt afgehandeld. Het loggen van verzoeken op een netwerkapparaat is niet hetzelfde als het loggen ervan op een agent binnen de server of op een beheerde cloudservice.

Een WAF netwerkgebaseerd Het wordt doorgaans ingezet als een fysiek of virtueel apparaat binnen de infrastructuur, tussen het internet en de applicaties. Dit is de klassieke aanpak van fabrikanten zoals F5. Het heeft als voordeel dat het het volgende biedt: hoge prestaties en nauwkeurige controleDe configuratie en het beheer kunnen echter complex zijn. Logbestanden worden doorgaans naar syslog of een centraal SIEM-systeem verzonden, en het is belangrijk om zorgvuldig te filteren wat er wordt opgeslagen om overbelasting van de opslag, analysetools en diagnostische systemen te voorkomen. IP- en DNS-netwerkproblemen.

De WAF host-gebaseerd Het draait op dezelfde servers (of containers) waar de applicatie zich bevindt, meestal als een module of agent (bijvoorbeeld ModSecurity geïntegreerd in Nginx of Apache; het combineren ervan met Linux-beveiliging met SELinux (verbetert de veiligheidshouding). Dit model biedt u de mogelijkheid om te beschikken over Meer toepassingscontext en zeer specifieke regels per service, ten koste van het verbruik van lokale resources en de noodzaak van meer gedistribueerd logbeheer. Ze kunnen worden opgeslagen in lokale bestanden en vervolgens worden doorgestuurd, of worden geïntegreerd met gecentraliseerde logservices.

De WAF in de cloud (Cloudflare, Akamai, Imperva Cloud, AWS WAF, enz.) integreert met load balancers, CDN's of virtuele netwerken. De provider biedt hier doorgaans het volgende aan. panelen, dashboards en logboekexport naar S3, BigQuery, externe syslog of SIEM. Activeren is meestal eenvoudiger, maar u moet uw logbeleid aanpassen aan het model van de provider: gebeurtenistypen, bewaartermijn, ernstfilters, enz.

De keuze voor het ene model boven het andere is niet alleen een technische beslissing; het hangt ook af van hoe u de balans tussen loggen en blokkeren wilt vinden. Een cloudgebaseerde service vereenvoudigt veel aspecten, maar u wilt misschien... Volledige controle over waar de logbestanden worden opgeslagen. vanwege nalevings- of vertrouwelijkheidsvoorschriften, wat leidt tot een voorkeur voor on-premise of hybride modellen.

Voorwaarden, regels en web-ACL's: hoe de WAF bepaalt of een website wordt geblokkeerd, toegestaan ​​of alleen geregistreerd.

Ongeacht de fabrikant zijn alle moderne WAF's gebaseerd op het idee van voorwaarden, regels en toegangsbeleidDit begrijpen is essentieel om met tel-, log- en vergrendelingsmodi te kunnen werken zonder problemen te veroorzaken in de productieomgeving.

De condiciones Ze beschrijven welk deel van het verzoek wordt gecontroleerd: bron-IP-adres, specifieke HTTP-headers (Host, User-Agent, Accept, Content-Type, enz.), queryparameters, de request body, cookies, HTTP-methode, land van herkomst, enz. In AWS WAF Classic kunt u bijvoorbeeld een IP-voorwaarde definiëren met maximaal 10.000 adressen of bereiken, of een voorwaarde voor het matchen van een tekenreeks op een deel van de URL.

De reglement Ze combineren een of meer voorwaarden en kennen een intentie toe: toestaan, blokkeren of tellen. Wanneer een regel meerdere voorwaarden heeft, worden deze meestal geëvalueerd met een logische ENAlle voorwaarden moeten vervuld zijn om de regel te activeren. Een normale regel zonder voorwaarden komt in de praktijk nergens mee overeen en de bijbehorende actie wordt nooit uitgevoerd.

Veel WAF's, waaronder AWS WAF, hebben ook op tarieven gebaseerde regelsDeze regels tellen de verzoeken die binnenkomen vanaf een IP-adres (of een set IP-adressen die aan bepaalde voorwaarden voldoen) gedurende een tijdsvenster, bijvoorbeeld vijf minuten. Als een drempelwaarde wordt overschreden – bijvoorbeeld 1.000 verzoeken in vijf minuten – treedt de regel in werking: het adres wordt geblokkeerd of er wordt simpelweg geteld. Dit is erg handig voor:

• Om te controleren Brute force-aanval op inlogformulieren.
• Beperk agressief scrapen of onbeschofte bots.
• Het beperken van bepaalde soorten DDoS-aanvallen op applicatieniveau.

Het volgende niveau is de Web-ACL (Access Control List)Hier worden de regels gegroepeerd en worden een evaluatievolgorde en een standaardactie (TOESTAAN of BLOKKEREN) gedefinieerd. Een verzoek doorloopt de regels in volgorde; als het aan een regel voldoet, wordt de bijbehorende actie toegepast en wordt de evaluatie van de overige regels gestopt. Als het aan geen enkele regel voldoet, wordt de standaardactie toegepast die in de ACL is gedefinieerd.

Wat betreft de balans tussen loggen en vergrendelen, bepaal je in de ACL of het systeem standaard wel of niet moet loggen of vergrendelen. Wees tolerant (TOESTAAN en blokkeren alleen volgens specifieke regels) of zeer restrictief (BLOKKEREN, behalve in bepaalde gevallen). Bovendien bieden veel oplossingen de mogelijkheid om regels in de "telmodus" binnen de ACL in te stellen, zodat ze overeenkomsten registreren maar het verkeer niet blokkeren, ideaal voor de afstemmingsfase.

Witte lijsten en ruisonderdrukking in logbestanden

Toelatingslijsten zijn een essentieel hulpmiddel voor Verminder valse positieven en ruis in de registratie.Het idee is simpel: in bepaalde contexten geef je de WAF de opdracht om een ​​bepaalde richtlijn of set regels niet toe te passen op specifiek verkeer dat je al hebt gecategoriseerd als betrouwbaar, of waarvan je weet dat het afwijkt van de norm maar wel legitiem is.

In AWS WAF kun je bijvoorbeeld whitelist-regels maken, zodat als een verzoek afkomstig is van een IP-adres of specifiek bereikOf, als het overeenkomt met een bekend URL-patroon en HTTP-methode, worden bepaalde handtekeningcontroles niet toegepast. Dit helpt bij:

• Voorkom dat interne API's "vreemde" patronen gebruiken. genereren voortdurend valse positieven.
• Verminder de latentie die wordt veroorzaakt door diepgaande inspectie in verkeer dat u al als betrouwbaar beschouwt.
• Verminder het aantal onnodige records in de WAF-logboeken.

Op platforms zoals ModSecurity is de aanbevolen aanpak niet om de standaardregels (bijv. de OWASP Core Rule Set) aan te passen, maar om nieuwe regels te creëren. specifieke uitsluitingen per regel-ID voor specifieke parameters, routes of gebruikers. Dit maakt het mogelijk om de algehele bescherming te behouden zonder enorme kwetsbaarheden te creëren door volledige sitebrede regels uit te schakelen.

Het belangrijkste is dat de toegestane lijsten chirurgischGeen drastische maatregel. Het is veel beter om een ​​specifieke combinatie uit te sluiten (regel X + parameter Y in URL Z) dan om regel X globaal uit te schakelen. Op die manier blijft de logging nuttig en creëer je geen onnodige blinde vlekken.

Protocolregels en -limieten: wanneer te blokkeren, wanneer te waarschuwen

Veel WAF's bevatten een reeks regels voor het saneren van HTTP-protocollen die functioneren als eerste misvormde of verdachte verkeersfilterDeze regels controleren verplichte headers, methoden, argumentgroottes, enz., en vormen een veelvoorkomende bron van zowel goede beveiliging als valse positieven als ze niet goed worden begrepen.

Enkele veelvoorkomende voorbeelden:

• Ontbrekende Accept-header (Ontbrekende Accept-header): Dit is strikt genomen geen schending van de RFC, maar veel verzoeken zonder deze header zijn afkomstig van geautomatiseerde tools of slecht geschreven scripts. Het kan gevolgen hebben voor aangepaste API's of clients die deze header niet meesturen. In veel omgevingen heeft het loggen en tellen van verzoeken de voorkeur boven het direct blokkeren ervan.
• Ontbrekende hostheaderVolgens de HTTP/1.1-standaarden is de Host-header verplicht. WAF's hebben deze ook nodig om te bepalen welk beleid moet worden toegepast. Blokkeren is hier meestal terecht, maar het kan valse positieven genereren tijdens het testen of door verkeerd geconfigureerd intern verkeer; het is raadzaam om de logboeken te controleren voordat strikte blokkering wordt ingeschakeld.
• Ontbrekende User-Agent-headerDeze regel is bedoeld om rudimentaire bots en onbekend verkeer te beperken. Het probleem is echter dat veel legitieme API's geen User-Agent meesturen. De meest verstandige aanpak is meestal om te loggen en, als een consistente en legitieme API wordt gedetecteerd, Voeg hun IP-adres of patroon toe aan een lijst met toegestane gebruikers..
• GET/HEAD-validatie met bodyHoewel de RFC het versturen van de body met GET- of HEAD-verzoeken niet strikt verbiedt, is het geen gangbare praktijk en kan het duiden op pogingen tot ontwijking. In veel gevallen is een eerste stap het loggen van al deze verzoeken en, als ze verdachte afwijkingen blijken te zijn, ze te blokkeren.
• Ontbrekend inhoudstype met inhoudAls er wel een body is, maar geen Content-Type, is dat een duidelijke indicatie van onjuist protocolgebruik of een poging om analyse te omzeilen. In dergelijke gevallen is een agressievere blokkeringsaanpak meestal zinvol, vooral in omgevingen die direct met internet verbonden zijn.

Naast deze protocolregels is het gebruikelijk om het volgende te vinden grenzen van argumenten Ter bescherming tegen overbelasting van applicaties en DoS-aanvallen. Bijvoorbeeld:

• Maximum aantal argumenten per verzoek (standaard 255 in sommige WAF's).
• Maximale lengte van een individueel argument (bijvoorbeeld 400 tekens).
• De totale gecombineerde grootte van alle argumenten (bijvoorbeeld 64.000 bytes).

Deze waarden zijn redelijk voor veel toepassingen, maar er zijn gevallen – complexe formulieruploads, geavanceerde filters, grote JSON-ladingen – waarin valse positieven voorkomen. In die scenario's is de meest verstandige aanpak... Begin met het registreren en tellen.Bekijk welke eindpunten de limieten overschrijden en pas deze alleen voor die routes aan, in plaats van alle limieten voor de hele site op te heffen.

Vals-positieve resultaten: hoe je ze kunt opsporen zonder eraan te hoeven sterven.

Een vals positief resultaat is een legitiem verzoek dat de WAF niet kan verwerken. wordt geïdentificeerd als kwaadaardig en blokkeert of markeert als een aanval. Ze zijn onvermijdelijk, vooral wanneer je brede regelsets zoals OWASP CRS activeert, maar ze kunnen professioneel beheerd worden zodat ze geen dagelijkse bron van ergernis worden.

Het opsporen van vals-positieve resultaten begint met een zorgvuldige observatie van de logboekenBekijk welke verzoeken worden geblokkeerd, welke regel ze activeert en in welke context (URL, parameters, gebruiker, herkomst, enz.). Visuele tools en dashboards helpen bij het identificeren van pieken in 403-fouten of ongebruikelijke patronen.

Een zeer aanbevolen aanpak, zowel door cloudproviders als door de ModSecurity-gemeenschap, is het gebruik van een simulatiemodus of telmodusIn deze modus worden alle overeenkomsten van de regels die u wilt testen geregistreerd, maar niet geblokkeerd. Hierdoor kunt u bijvoorbeeld zien hoeveel legitieme verzoeken een nieuwe SQLi-regel zou hebben geblokkeerd voordat u deze in productie zou durven activeren.

Het is ook een goed idee om de regels te testen in een enscenerings- of pre-productieomgeving die echt of gesimuleerd verkeer ontvangt. Tools zoals OWASP ZAP of scripts voor het afspelen van verkeer kunnen helpen bij het simuleren van legitieme patronen en bekende aanvallen om het gedrag van de WAF te testen.

Daarnaast is het cruciaal om rekening te houden met de operationele en reputatieschade van valse positieven: betalingsonderbrekingen, mislukte gebruikersregistraties, kritieke API-aanroepen die zonder duidelijke reden mislukken – allemaal zaken die direct kunnen leiden tot omzetverlies en een negatief merkimago. Een overvloed aan valse positieven overspoelt het beveiligingsteam bovendien met meldingen die geen toegevoegde waarde bieden, waardoor het moeilijk wordt om echte incidenten te identificeren.

Strategieën voor het aanpassen van regels en intelligent gebruik van het register

Het beheersen van valse positieven draait niet om het uitschakelen van regels totdat "alles werkt", maar om... De WAF (Wife Acceptance Factor) nauwkeurig afstellen met een scalpel.Hier komen goede praktijken zoals de volgende van pas:

Ten eerste is het beter om regels niet globaal uit te schakelen. Het is beter om ze afzonderlijk aan te maken. zeer specifieke uitzonderingenSluit de regel-ID alleen uit voor een specifieke route, bepaalde parameters of intern verkeer. Op deze manier blijft u beschermd in de rest van de applicatie en behoudt u nuttige logboeken.

Ten tweede, profiteer van de manier van inhoud Voordat je een regel blokkeert, kun je door deze eerst alleen in de logmodus te activeren meten hoeveel legitieme verzoeken erdoor worden beïnvloed. Je kunt dit aanvullen met SIEM-waarschuwingen om snel te detecteren of een regel een abnormaal hoog aantal overeenkomsten genereert.

Ten derde, integreer de WAF met een SIEM of gecentraliseerd logboekplatformDit maakt het gemakkelijker om WAF-gebeurtenissen te correleren met andere indicatoren: ongebruikelijke systeemactiviteit, massale authenticatiefouten, verdachte configuratiewijzigingen, enz. Het helpt ook bij het prioriteren van welke regels als eerste moeten worden aangepast op basis van de ernst en frequentie van de gebeurtenissen.

Ten vierde, documenteer elke wijziging: welke regel is verfijnd, voor welk eindpunt, op basis van welke rechtvaardiging en met welk bewijs. Raadpleeg hiervoor de handleidingen voor servers Deze documentatie kan nuttig zijn. Het helpt niet alleen bij het handhaven van interne controle, maar is ook van onschatbare waarde bij audits en beveiligingsbeoordelingen, waarbij u wilt aantonen dat... Bedieningselementen worden niet zomaar uitgeschakeld..

Automatisering, machine learning en adaptieve regels in WAF

Naarmate applicaties groeien en het verkeer complexer wordt, wordt het handmatig beheren van de WAF onrealistisch. Dit is waar de Automatisering, geavanceerde loganalyse en in sommige gevallen het gebruik van machine learning..

Ten eerste maakt integratie met SIEM het mogelijk om te bouwen correlatieregels en geautomatiseerde reactiesAls bijvoorbeeld een reeks IP-adressen herhaaldelijk injectie- of XSS-regels activeert, kan er een geautomatiseerde actie worden gegenereerd om die IP-adressen toe te voegen aan een tijdelijke blokkeerlijst of het inspectieniveau te verhogen.

Ten tweede bevatten sommige WAF's de volgende elementen: machine learning-modi (leermodus) die legitiem verkeer gedurende een bepaalde periode observeert. Op basis van deze gegevens stelt het drempelwaarden, patronen en profielen van normaal gedrag voor of past deze aan. Dit helpt valse positieven te verminderen wanneer regels worden overgeschakeld naar de blokkeringsmodus en detecteert daaropvolgende afwijkingen in het verkeer.

In onderzoeks- en laboratoriumomgevingen worden technieken voor begeleid leren gebruikt om modellen te trainen die onderscheid kunnen maken tussen legitiem en kwaadaardig verkeer, waardoor beleidsregels worden verfijnd die vervolgens in productie worden toegepast. Hoewel dit geen wondermiddel is, kan deze aanpak wel helpen. Ontdek subtiele patronen die klassieke, op handtekeningen gebaseerde regels niet gemakkelijk detecteren.

Tenslotte de continue geautomatiseerde testen (Met behulp van tools zoals OWASP ZAP, aangepaste scripts of CI/CD-pipelines) kunt u controleren of wijzigingen aan de WAF geen kritieke functionaliteit verstoren of duidelijke kwetsbaarheden achterlaten. Door deze tests in de implementatiecyclus te integreren, wordt beveiliging een natuurlijk onderdeel van het ontwikkelingsproces, in plaats van een patch die op het laatste moment wordt toegevoegd.

Beleidsontwerp per applicatie en zwarte lijsten per dienst.

In complexe omgevingen – bijvoorbeeld bij een hostingprovider of een internetprovider – is een enkel, universeel toepasbaar WAF-beleid niet voldoende, vooral niet wanneer er sprake is van IT in de schaduwHet is gebruikelijk om meerdere domeinen of applicaties achter dezelfde load balancer te hebben, elk met verschillende beveiligingsbehoeften en verkeersprofielenDit is waar het ontwerpen van servicespecifieke beleidsregels en lijsten zinvol is.

Een illustratief voorbeeld is een HTTP/S-loadbalancer die fungeert als Reverse proxy voor meerdere sites (bijvoorbeeld www.company1.com en www.company2.com) achter één virtueel IP-adres. In dit scenario is het mogelijk om de WAF zo te configureren dat, zodra het verzoek binnenkomt, de Host-header en het bron-IP-adres worden geëvalueerd, nog voordat het de load balancing-module bereikt.

De logica zou ongeveer als volgt zijn: de WAF controleert of de combinatie van SERVER_NAME (Host) en client-IP Het komt overeen met een sitespecifieke blacklist. Als het IP-adres geblokkeerd is voor www.company2.com, maar niet voor www.company1.com, wordt alleen in het eerste geval een 403 Forbidden-respons teruggestuurd. "Schoon" verkeer wordt vervolgens doorgestuurd naar de load balancing-module, die bepaalt welke backend het verzoek afhandelt.

Dit stelt u in staat om bijvoorbeeld het volgende te onderhouden: zwarte lijsten per domeinIn plaats van een algemene lijst voor het gehele toegangspunt, wordt elke afwijzing in syslog vastgelegd met details zoals de regel-ID, de overeenkomende voorwaarde, de URL, de host en het IP-adres van de client. Dit vergemakkelijkt latere analyse en het uitbreiden of debuggen van deze lijsten.

De moraal van het verhaal is dat hoe meer je beleid is onderverdeeld (per applicatie, per omgeving, per gebruikerstype), hoe beter je de balans kunt vinden tussen loggen en blokkeren: je kunt bijvoorbeeld heel streng zijn op administratieve portalen en wat flexibeler op informatieve websites, maar zorg er altijd voor dat in de logs staat waarom elke beslissing is genomen.

Naast de klassieke WAF: WAAP en API-beveiliging

Het dreigingslandschap is niet onveranderd gebleven. Tegenwoordig zijn veel applicaties cloud-native, maken ze gebruik van microservices-architecturen en stellen ze hun systemen bloot aan risico's. Publieke en private API's die het primaire doelwit van aanvallers worden. De traditionele WAF is geëvolueerd naar bredere platforms die bekend staan ​​als WAAP (Web Application and API Protection) of WAAS (Web Application & API Security).

Deze oplossingen ontdekken niet alleen automatisch webapplicaties, maar ook API-eindpunten identificerenZe accepteren specificaties zoals OpenAPI of Swagger en gebruiken die definitie om de conformiteit van verzoeken te controleren: verwachte gegevenstypen, toegestane parameters, groottelimieten, enz. Afhankelijk van het eindpunt (bijvoorbeeld een eindpunt dat zeer gevoelige gegevens verwerkt), kan een veel hoger niveau van controle en blokkering worden toegepast.

Op het niveau van de logboekregistratie genereert WAAP doorgaans het volgende: gebeurtenissen met een rijkere contextDit maakt nauwkeurigere blokkeringsbeslissingen mogelijk, in plaats van uitsluitend te vertrouwen op generieke payloadpatronen. Deze informatie kan worden gebruikt om het exacte API-eindpunt te bepalen dat is aangevallen, de specifieke bewerking die daarbij betrokken was (GET, POST, PUT, enz.), de betrokken gebruiker of het token, het deel van de specificatie dat is overtreden, enzovoort.

Bovendien bevatten veel WAAP-tools applicatie- en API-specifieke DoS-bescherming, geolocatiefiltering, IP-reputatiebeheer, detectie van bots en webscraping, en opties om waarschuwingsniveaus per service aan te passen. Het gaat er dus om de flexibiliteit te hebben om zelf te kunnen kiezen. waar je een stevige hand wilt en waar je juist prioriteit wilt geven aan flexibiliteit.zonder een goede documentatie op te offeren om elk incident te onderzoeken.

Samengevat vormt een goed afgestelde WAF – of het nu een klassieke, op WAAP gebaseerde of in een cloudomgeving geïntegreerde variant is – een essentieel onderdeel van moderne applicatie- en API-beveiliging, die in staat is om de volgende zaken te combineren: Gedetailleerde registratie, intelligente vergrendeling en continue aanpassing aan het veranderende dreigingslandschap.