Līdzsvars starp ierakstīšanu un bloķēšanu WAF režīmā

Informatec Digital » Resursi » Reģistrēšanas un bloķēšanas līdzsvarošana WAF vidē

Pareizā līdzsvara atrašana starp reģistrēšanu un bloķēšanu bezvadu lietojumprogrammu (WAF) vidē ir kļuvusi par vienu no biežākajām galvassāpēm drošības un operāciju komandām. Tīmekļa lietojumprogrammu ugunsmūris var apturēt ļoti nopietnus uzbrukumus, taču, ja tas ir konfigurēts pārāk agresīvi, tas var bloķēt likumīgus pirkumus, piekļuvi vai API izsaukumus. Ja tas ir konfigurēts pārāk brīvi, tas kļūst gandrīz tikai dekoratīvs. Galvenais ir rūpīgi pielāgot, kad reģistrēt, kad skaitīt, kad atļaut un kad bloķēt.

Šajā rakstā mēs padziļināti aplūkosim, kā panākt šo līdzsvaru, izmantojot mūsdienīgas WAF iespējas (atļauto sarakstus, uz frekvencēm balstītus noteikumus, mācību režīmus, SIEM integrāciju, mašīnmācīšanos utt.), ko atbalsta konkrēti piemēri no AWS WAF, ModSecurity, mākonī balstītiem WAF un lokāliem risinājumiem . Jūs uzzināsiet, kā ierobežot viltus pozitīvus rezultātus, nepazeminot aizsardzības līmeni, kā organizēt politikas pēc lietojumprogrammas un kā izmantot reģistrēšanu kā sabiedroto, nevis kā pastāvīgu, nekontrolējamu trokšņa avotu.

Kas ir WAF un kāpēc reģistrācija ir tik svarīga?

Tīmekļa lietojumprogrammu ugunsmūris darbojas kā inteliģents slānis starp lietotāju un serveri , reāllaikā analizējot HTTP/HTTPS datplūsmu. Atšķirībā no tradicionālā tīkla ugunsmūra, kas uzrauga portus un IP adreses, WAF iedziļinās dziļāk: URL, parametrus, pieprasījumu pamattekstus, galvenes, sīkfailus, HTTP metodes un citus datus.

Tās misija ir atklāt un apturēt tipiskus 7. slāņa uzbrukumus : SQL injekciju, XSS, LFI/RFI, uzbrukumus piekļuves kontrolei, API ļaunprātīgu izmantošanu, agresīvu datu nokasīšanu, brutālu spēku un pat noteiktus lietojumprogrammu līmeņa DDoS modeļus. Lai to paveiktu, tā izmanto noteikumu, parakstu un drošības politiku kopas, kas tiek pastāvīgi atjauninātas.

Reģistrēšana ir monētas otra puse. Katram WAF lēmumam — atļaušanai, bloķēšanai vai tikai skaitīšanai — žurnālos var pievienot detalizētu notikumu . Šie žurnāli ļauj:

• Izmeklēt incidentus: rekonstruēt notikušo un to, kā tika mēģināts izmantot ievainojamību.
• Pielāgot noteikumus: atklāt viltus pozitīvus rezultātus, redzot, kurus likumīgos pieprasījumus WAF bloķē.
• Ievērot noteikumus: pierādīt, ka pastāv aktīvas kontroles (PCI DSS, GDPR, iekšējās revīzijas utt.).
• SIEM barošana: korelē lietojumprogrammu uzbrukumus ar tīkla, sistēmas, identitātes u. c. notikumiem.

Problēma ir tā, ka slikti noregulēts WAF var piepildīt žurnālus ar tūkstošiem neatbilstošu notikumu , padarot neiespējamu atrast svarīgo un turklāt izraisot nepamatotu likumīgas datplūsmas noraidīšanu. Tieši šeit noder māksla eksperimentēt ar reģistrēšanas, skaitīšanas un bloķēšanas režīmiem.

Drošības modeļi WAF: bloķēšanas saraksti, atļaujas saraksti un hibrīda pieeja

Lielākā daļa mūsdienu WAF apvieno vairākas filtrēšanas pieejas, kas tieši ietekmē pieprasījumu reģistrēšanu un bloķēšanu . Vispārīgi runājot, mēs varam izdalīt divas klasiskas filozofijas, kā arī ļoti izplatītu hibrīda modeli.

Uz bloķēšanas sarakstu balstīts WAF ievēro negatīvas drošības modeli. Tā pamatprincips ir: "Es atļauju visu, izņemot to, ko zinu kā ļaunprātīgu." Tas darbojas, izmantojot zināmu uzbrukumu parakstus (SQL injekcija, XSS, botu modeļi utt.) un noteikumus, kas nosaka, kas tiek uzskatīts par aizdomīgu. Sākotnēji to ir vieglāk ieviest, taču, paļaujoties tikai uz šo modeli, pastāv risks, ka jauni uzbrukumu vektori vai varianti var nepamanīti izslīdēt cauri.

WAF ar atļauju sarakstu darbojas pretēji: "bloķēt visu, izņemot to, kas ir skaidri atļauts". Tas ir balstīts uz pozitīvu drošības modeli. Tiek pieņemta tikai tāda datplūsma, kas atbilst definētajai likumīgajai uzvedībai — maršrutiem, metodēm, parametriem, formātiem, izmēriem utt. Tas ir daudz drošāk, taču prasa ievērojamu precizēšanu un sākotnēji var ģenerēt kļūdaini pozitīvus rezultātus, ja tas nav pareizi sagatavots.

Ņemot vērā katras pieejas priekšrocības un trūkumus, arvien izplatītāks kļūst hibrīdmodelis, kas apvieno atļauju un bloķēšanas sarakstus . Šādā scenārijā tiek definēti paredzamie datplūsmas profili (piemēram, kas veido parastu pieteikšanos vai maksājuma pieprasījumu), un vienlaikus tiek lietoti paraksti un heiristika, lai atklātu tipiskus ļaunprātīgus modeļus. Reģistrēšanas nolūkos šī hibrīdpieeja ļauj:

• Atzīmēt kā augsta riska notikums kas pārkāpj atļauto priekšmetu sarakstu.
• Uztvert kā vidējas/zemas prioritātes brīdinājumi vispārīgi bloķēšanas saraksta modeļi.
• Izmantojiet "skaitīšanas" režīmu, lai redzētu, kas pārkāptu noteikumu pirms bloķēšanas aktivizēšanas.

WAF tīklā, uzņēmējdatorā un mākonī: ietekme uz reģistrēšanu un bloķēšanu

WAF izvietošanas modelis būtiski ietekmē datplūsmas reģistrēšanas un bloķēšanas apstrādi. Pieprasījumu reģistrēšana tīkla ierīcē nav tas pats, kas to reģistrēšana aģentā serverī vai pārvaldītā mākoņpakalpojumā.

Tīklā bāzēta WAF parasti tiek izvietota kā fiziska vai virtuāla ierīce infrastruktūrā, starp internetu un lietojumprogrammām. Šī ir klasiskā pieeja, ko izmanto tādi ražotāji kā F5. Tā piedāvā augstas veiktspējas un detalizētas kontroles priekšrocības , taču konfigurācija un pārvaldība var būt sarežģīta. Reģistrēšana parasti tiek nosūtīta uz sistēmas žurnālu vai centrālo SIEM, un ir svarīgi rūpīgi filtrēt saglabātos datus, lai izvairītos no krātuves un analīzes rīku pārslodzes, kā arī lai diagnosticētu problēmas IP un DNS tīklos.

Uz resursdatora balstītie WAF darbojas tajos pašos serveros (vai konteineros), kur atrodas lietojumprogramma, parasti kā modulis vai aģents (piemēram, ModSecurity ir integrēts Nginx vai Apache; apvienojot to ar Linux aizsardzību, izmantojot SELinux, tiek uzlabota drošības situācija). Šis modelis nodrošina plašāku lietojumprogrammas kontekstu un ļoti specifiskus noteikumus katram pakalpojumam, vienlaikus patērējot lokālos resursus un pieprasot izkliedētāku žurnālu pārvaldību. Žurnālus var glabāt lokālos failos un pēc tam pārsūtīt vai integrēt ar centralizētiem reģistrēšanas pakalpojumiem.

Mākonī balstīti WAF (Cloudflare, Akamai, Imperva Cloud, AWS WAF u. c.) integrējas ar slodzes līdzsvarotājiem, CDN vai virtuālajiem tīkliem. Pakalpojumu sniedzēji parasti piedāvā informācijas paneļus un žurnālu eksportēšanu uz S3, BigQuery, attāliem sistēmas žurnāliem vai SIEM. Parasti tos ir vieglāk iestatīt, taču reģistrēšanas politikas ir jāpielāgo pakalpojumu sniedzēja modelim: notikumu veidi, saglabāšanas periodi, nopietnības filtri utt.

Viena vai otra modeļa izvēle nav tikai tehnisks lēmums, bet arī jautājums par to, kā vēlaties līdzsvarot reģistrēšanu un bloķēšanu: mākonī pārvaldīts pakalpojums vienkāršo daudzus aspektus, taču atbilstības vai konfidencialitātes politikas dēļ jūs, iespējams, vēlēsities pilnīgu kontroli pār žurnālu glabāšanas vietu , kas jūs mudina izvēlēties lokālos vai hibrīdmodeļus.

Noteikumi, noteikumi un tīmekļa ACL: kā WAF izlemj, vai bloķēt, atļaut vai tikai reģistrēt

Neatkarīgi no ražotāja, visi mūsdienu WAF ir balstīti uz piekļuves nosacījumu, noteikumu un politiku koncepciju . Izpratne par to ir būtiska, lai veiksmīgi izmantotu skaitīšanas, reģistrēšanas un bloķēšanas režīmus ražošanas vidē.

Nosacījumi apraksta , kura pieprasījuma daļa tiek pārbaudīta: avota IP adrese, konkrētas HTTP galvenes (resursdators, lietotāja aģents, pieņemšanas aģents, satura tips…), vaicājuma parametri, pieprasījuma pamatteksts, sīkfaili, HTTP metode, izcelsmes valsts utt. Piemēram, AWS WAF Classic varat definēt IP nosacījumu ar līdz pat 10 000 adresēm vai diapazoniem vai virknes atbilstības nosacījumu URL daļai.

Noteikumi apvieno vienu vai vairākus nosacījumus un piešķir nolūku: atļaut, bloķēt vai skaitīt. Ja noteikumam ir vairāki nosacījumi, tie parasti tiek novērtēti ar loģisku UN : lai noteikums tiktu aktivizēts, ir jāizpilda visi nosacījumi. Parasts noteikums bez nosacījumiem praksē neatbilst nekam, un tā darbība nekad netiek aktivizēta.

Daudziem WAF, tostarp AWS WAF, ir arī uz ātrumu balstīti noteikumi . Šie noteikumi skaita pieprasījumus, kas ienāk no IP adreses (vai IP adrešu kopas, kas atbilst noteiktiem nosacījumiem) laika logā, piemēram, piecu minūšu laikā. Ja tiek pārsniegts slieksnis, piemēram, 1.000 pieprasījumi piecu minūšu laikā, noteikums stājas spēkā: bloķēšana vai vienkārši skaitīšana. Tas ir ļoti noderīgi:

• Kontrolēt brutāls spēks pieteikšanās formās.
• Ierobežojiet agresīvu datu ieguvi vai rupjus robotprogrammatūras.
• Noteiktu DDoS uzbrukumu veidu mazināšana lietojumprogrammu līmenī.

Nākamais līmenis ir tīmekļa ACL (piekļuves kontroles saraksts) . Šeit noteikumi ir grupēti, un ir definēta novērtēšanas secība un noklusējuma darbība (ATĻAUT vai BLOĶĒT). Pieprasījums iziet cauri noteikumiem secībā; ja tas atbilst vienam noteikumam, tiek piemērota tā darbība, un pārējo novērtēšana tiek apturēta. Ja tas neatbilst nevienam noteikumam, tiek piemērota ACL definētā noklusējuma darbība.

Runājot par reģistrēšanas un bloķēšanas līdzsvarošanu, ACL ir vieta, kur jūs izvēlaties, vai vēlaties, lai sistēma pēc noklusējuma būtu atļaujoša (ATĻAUT un bloķēt tikai ar konkrētiem noteikumiem) vai ļoti ierobežojoša (BLOĶĒT, izņemot izņēmuma gadījumus). Turklāt daudzi risinājumi ļauj iestatīt noteikumus "skaitīšanas" režīmā ACL ietvaros, lai tie reģistrētu atbilstības, bet nebloķētu datplūsmu — ideāli piemērots regulēšanas fāzei.

Baltie saraksti un trokšņu samazināšana žurnālos

Atļauju saraksti ir būtisks rīks viltus pozitīvu rezultātu un trokšņu samazināšanai žurnālā . Ideja ir vienkārša: noteiktos kontekstos jūs norādāt WAF nepiemērot direktīvu vai noteikumu kopumu konkrētai datplūsmai, kuru jau esat klasificējis kā uzticamu vai par kuru zināt, ka tā ir ārpus normas, bet likumīga.

Piemēram, AWS WAF var izveidot atļauju saraksta noteikumus, lai, ja pieprasījums nāk no konkrētas IP adreses vai diapazona vai ja tas atbilst zināmam URL modelim un HTTP metodei, noteiktas parakstu pārbaudes netiktu piemērotas. Tas palīdz:

• Novērst iekšējās API, kas izmanto "dīvainus" modeļus ģenerēt pastāvīgus viltus pozitīvus rezultātus.
• Samaziniet latentumu, ko rada padziļināta datplūsmas pārbaude, kuru jau uzskatāt par uzticamu.
• Samaziniet nevajadzīgo ierakstu apjomu WAF žurnālos.

Tādās platformās kā ModSecurity ieteicamā pieeja nav mainīt standarta noteikumus (piemēram, OWASP Core Rule Set), bet gan izveidot konkrētus izņēmumus pēc noteikumu ID noteiktiem parametriem, ceļiem vai lietotājiem. Tas ļauj saglabāt vispārēju aizsardzību, neradot milzīgas ievainojamības, atspējojot veselus noteikumus visā vietnē.

Svarīgi ir padarīt atļaušanas sarakstus ķirurģiskus , nevis vispārēju pieeju. Daudz labāk ir izslēgt konkrētu kombināciju (noteikums X + parametrs Y URL Z), nekā atspējot noteikumu X globāli. Tādā veidā reģistrēšana joprojām ir noderīga un jūs neradāt nevajadzīgas aklās zonas.

Protokola noteikumi un ierobežojumi: kad bloķēt, kad brīdināt

Daudzos WAF tīklos ir iekļauts HTTP protokola attīrīšanas noteikumu kopums, kas darbojas kā pirmais filtrs nepareizi veidotai vai aizdomīgai datplūsmai . Šie noteikumi pārbauda nepieciešamās galvenes, metodes, argumentu izmērus utt., un tie bieži vien ir gan labas aizsardzības, gan kļūdaini pozitīvu rezultātu avots, ja tie netiek pareizi saprasti.

Daži ļoti izplatīti piemēri:

• Trūkst apstiprināšanas galvenes (Trūkstoša galvene “Accept”): Tas nav gluži RFC pārkāpums, taču daudzi pieprasījumi bez šīs galvenes nāk no automatizētiem rīkiem vai slikti uzrakstītiem skriptiem. Tas var ietekmēt pielāgotus API vai klientus, kas to nesūta. Daudzās vidēs reģistrēšana un skaitīšana ir vēlamāka par pilnīgu bloķēšanu.
• Trūkstoša resursdatora galveneSaskaņā ar HTTP/1.1 standartiem Host galvene ir obligāta. WAF sistēmām tā ir nepieciešama arī, lai noteiktu, kuru politiku piemērot. Bloķēšana šeit parasti ir saprātīga, taču tā var ģenerēt viltus pozitīvus rezultātus testēšanas laikā vai nepareizi konfigurētas iekšējās datplūsmas dēļ; pirms stingras bloķēšanas iespējošanas ieteicams uzraudzīt žurnālus.
• Trūkst lietotāja aģenta galvenesŠis noteikums mēģina ierobežot vienkāršus robotus un neidentificētu datplūsmu. Problēma ir tā, ka daudzas likumīgas API var nenosūtīt lietotāja aģentu. Vissaprātīgākā pieeja parasti ir reģistrēt, un, ja tiek konstatēta konsekventa un likumīga API, pievienot viņu IP adresi vai modeli atļauto sarakstam.
• GET/HEAD validācija ar pamattekstuLai gan RFC stingri neaizliedz sūtīt pamattekstu ar GET vai HEAD pieprasījumiem, tā nav izplatīta prakse un var liecināt par mēģinājumiem apiet pieprasījumus. Daudzos gadījumos pirmais solis ir reģistrēt visus šos pieprasījumus un, ja tie tiek atzīti par aizdomīgām anomālijām, tos bloķēt.
• Trūkst satura tipa ar pamattekstuJa ir pamatteksts, bet nav Content-Type, tas skaidri norāda uz nepareizu protokola izmantošanu vai mēģinājumu izvairīties no analīzes. Šādos gadījumos parasti ir lietderīgāka agresīvāka bloķēšanas pieeja, īpaši interneta vidē.

Papildus šiem protokola noteikumiem bieži tiek izmantoti argumentu ierobežojumi , lai aizsargātu pret lietojumprogrammu līmeņa plūdiem un DoS uzbrukumiem. Piemēram:

• Maksimālais argumentu skaits vienā pieprasījumā (pēc noklusējuma dažos WAF ir 255).
• Atsevišķa argumenta maksimālais garums (piemēram, 400 rakstzīmes).
• Visu argumentu kopējais lielums (piemēram, 64 000 baiti).

Šīs vērtības ir saprātīgas daudzām lietojumprogrammām, taču ir gadījumi — sarežģītas veidlapu augšupielādes, uzlaboti filtri, lielas JSON ielādes —, kad rodas kļūdaini pozitīvi rezultāti. Šādos gadījumos vispiesardzīgākā pieeja ir sākt ar reģistrēšanu un skaitīšanu , pārskatīt, kuri galapunkti pārkāpj ierobežojumus, un pielāgot tikai šos maršrutus, nevis atcelt visus ierobežojumus visai vietnei.

Viltus pozitīvi rezultāti: kā tos atklāt un nenomirt mēģinot

Viltus pozitīvs rezultāts ir likumīgs pieprasījums, ko WAF identificē kā ļaunprātīgu un bloķē vai atzīmē kā uzbrukumu. No tiem nevar izvairīties, īpaši, ja ir iespējoti visaptveroši noteikumu kopumi, piemēram, OWASP CRS, taču tos var profesionāli pārvaldīt, lai tie nekļūtu par ikdienas galvassāpēm.

Viltus pozitīvu rezultātu noteikšana sākas ar rūpīgu žurnālu pārskatīšanu . Tas ietver to pieprasījumu pārbaudi, kuri tiek bloķēti, kuri noteikumi tos aktivizē un konteksts, kurā tie rodas (URL, parametri, lietotājs, izcelsme utt.). Vizuālie rīki un informācijas paneļi var palīdzēt identificēt 403 kļūdu pieaugumus vai neparastus modeļus.

Gan mākoņpakalpojumu sniedzēju, gan ModSecurity kopienas ļoti ieteicama pieeja ir simulācijas vai skaitīšanas režīma izmantošana . Šajā režīmā noteikumi, kurus vēlaties testēt, reģistrē katru atbilstību, bet nebloķē. Tas ļauj, piemēram, redzēt, cik daudz likumīgu pieprasījumu jauns SQLi noteikums būtu bloķējis, pirms jūs uzdrošinājāties to aktivizēt ražošanas vidē.

Tāpat ieteicams noteikumus pārbaudīt izmēģinājuma vai pirmsražošanas vidē , kas saņem reālu vai simulētu datplūsmu. Tādi rīki kā OWASP ZAP vai datplūsmas atkārtošanas skripti var palīdzēt simulēt likumīgus modeļus un zināmus uzbrukumus, lai pārbaudītu WAF darbību.

Turklāt ir svarīgi ņemt vērā kļūdaini pozitīvu rezultātu ietekmi uz darbību un reputāciju: maksājumu pārtraukumi, lietotāju reģistrācijas kļūmes, kritiski API izsaukumi, kas neizdodas bez paskaidrojumiem — tas viss var tieši ietekmēt ieņēmumus un zīmola tēlu. Pārāk daudz kļūdaini pozitīvu rezultātu arī pārslogo drošības komandu ar brīdinājumiem, kas nesniedz pievienoto vērtību, apgrūtinot īstu incidentu identificēšanu.

Stratēģijas noteikumu pielāgošanai un reģistra inteliģentai izmantošanai

Viltus pozitīvu rezultātu pārvaldība nenozīmē izslēgt noteikumus, līdz "viss darbojas", bet gan precīzi noregulēt WAF . Šeit noder tādas labas prakses kā tālāk norādītās:

Pirmkārt, izvairieties no noteikumu globālas atspējošanas. Vēlams izveidot ļoti specifiskus izņēmumus : izslēgt noteikuma ID tikai konkrētam maršrutam, noteiktiem parametriem vai iekšējai datplūsmai. Tādā veidā jūs saglabājat aizsardzību pārējā lietojumprogrammā un uzturēsiet noderīgus žurnālus.

Otrkārt, pirms bloķēšanas izmantojiet skaitīšanas režīmu . Jaunu noteikumu aktivizēšana sākotnēji tikai reģistrēšanas režīmā ļauj izmērīt, cik daudz likumīgu pieprasījumu tiktu ietekmēti. To var papildināt ar brīdinājumiem SIEM sistēmā, lai ātri noteiktu, vai noteikums ģenerē neparastu atbilstību skaitu.

Treškārt, integrējiet WAF ar SIEM vai centralizētu reģistrēšanas platformu . Tas atvieglo WAF notikumu korelāciju ar citiem rādītājiem: neparastu sistēmas aktivitāti, masveida autentifikācijas kļūmēm, aizdomīgām konfigurācijas izmaiņām utt. Tas arī palīdz noteikt prioritātes, kurus noteikumus pielāgot vispirms, pamatojoties uz notikumu nopietnību un biežumu.

Ceturtkārt, dokumentējiet visas izmaiņas: kurš noteikums tika precizēts, kuram galapunktam, ar kādu pamatojumu un ar kādiem pierādījumiem. Šim nolūkam var būt noderīgas serveru rokasgrāmatas . Šī dokumentācija ne tikai palīdz uzturēt iekšējo kontroli, bet arī ir nenovērtējama drošības auditos un pārskatos, kur vēlaties pierādīt, ka kontroles netiek atspējotas vieglprātīgi.

Automatizācija, mašīnmācīšanās un adaptīvie noteikumi WAF vidē

Tā kā lietojumprogrammas aug un datplūsma kļūst sarežģītāka, WAF manuāla pārvaldība kļūst nereāla. Šeit noder automatizācija, uzlabota žurnālu analīze un dažos gadījumos mašīnmācīšanās.

Pirmkārt, integrācija ar SIEM ļauj veidot korelācijas noteikumus un automatizētas atbildes : piemēram, ja IP adrešu kopa atkārtoti aktivizē injekcijas vai XSS noteikumus, varat ģenerēt automātisku darbību, lai šīs IP adreses pievienotu pagaidu bloķēšanas sarakstam vai pastiprinātu pārbaudes līmeni.

Otrkārt, daži WAF ietver mašīnmācīšanās režīmus , kas novēro likumīgu datplūsmu noteiktā laika periodā. Pamatojoties uz šiem datiem, tie piedāvā vai pielāgo normālas uzvedības robežvērtības, modeļus un profilus. Tas palīdz samazināt kļūdaini pozitīvu rezultātu skaitu, kad noteikumi tiek pārslēgti uz bloķēšanas režīmu, un noteikt sekojošas datplūsmas novirzes.

Pētniecības un laboratorijas vidē uzraudzītas mācīšanās metodes ir izmantotas, lai apmācītu modeļus, kas atšķir likumīgu un ļaunprātīgu datplūsmu, pilnveidojot politikas, kuras pēc tam tiek izmantotas ražošanā. Lai gan šī pieeja nav brīnumlīdzeklis, tā var palīdzēt atklāt smalkus modeļus , ko klasiskie uz parakstiem balstītie noteikumi viegli neatklāj.

Visbeidzot, nepārtraukta automatizēta testēšana (izmantojot tādus rīkus kā OWASP ZAP, pielāgotus skriptus vai CI/CD cauruļvadus) ļauj pārbaudīt, vai izmaiņas WAF neizjauc kritisku funkcionalitāti vai neatstāj acīmredzamas ievainojamības. Šo testu integrēšana izvietošanas ciklā padara drošību par dabisku izstrādes plūsmas sastāvdaļu, nevis pēdējā brīža ielāpu.

Politikas izstrāde katram lietojumam un melnie saraksti katram pakalpojumam

Sarežģītās vidēs, piemēram, mitināšanas pakalpojumu sniedzēja vai interneta pakalpojumu sniedzēja vidē, viena WAF politika nav pietiekama, īpaši, ja ir iesaistīta ēnu IT . Bieži vien aiz viena slodzes līdzsvarotāja ir vairāki domēni vai lietojumprogrammas, katrai no kurām ir atšķirīgas drošības vajadzības un datplūsmas profili . Šeit ir svarīgi izstrādāt pakalpojumiem specifiskas politikas un sarakstus.

Ilustratīvs piemērs ir HTTP/S slodzes līdzsvarotājs, kas darbojas kā apgrieztais starpniekserveris vairākām vietnēm (piemēram, www.company1.com un www.company2.com), kas atrodas aiz vienas virtuālas IP adreses. Šādā scenārijā WAF var konfigurēt tā, lai tas novērtētu resursdatora galveni un avota IP adresi, tiklīdz pieprasījums tiek saņemts, pat pirms tas sasniedz slodzes līdzsvarošanas moduli.

Loģika būtu apmēram šāda: WAF pārbauda, ​​vai SERVER_NAME (resursdatora) un klienta IP kombinācija atbilst vietnei specifiskam melnajam sarakstam. Ja IP ir norādīts kā bloķēts vietnei www.company2.com, bet ne vietnei www.company1.com, atbilde 403 Forbidden tiek nosūtīta tikai pirmajā gadījumā. "Tīrā" datplūsma pēc tam tiek nodota slodzes līdzsvarošanas modulim, kas izlemj, kura aizmugursistēma apkalpos pieprasījumu.

Tas ļauj uzturēt, piemēram, domēnam specifiskus melnos sarakstus , nevis vienu globālu sarakstu visam piekļuves punktam. Reģistrēšanas līmenī katrs noraidījums tiek reģistrēts sistēmas žurnālā ar tādu informāciju kā noteikuma ID, atbilstošo nosacījumu, URL, resursdatoru un klienta IP adresi, atvieglojot turpmāku analīzi un šo sarakstu paplašināšanu vai atkļūdošanu.

Stāsta morāle ir tāda, ka jo segmentētākas ir jūsu politikas (pēc lietojumprogrammas, pēc vides, pēc lietotāja tipa), jo precīzāk varat atrast līdzsvaru starp reģistrēšanu un bloķēšanu: administratīvajos portālos varat būt ļoti stingri un informatīvās tīmekļa vietnēs nedaudz elastīgāki, piemēram, žurnālos vienmēr norādot katra lēmuma pieņemšanas iemeslus.

Papildus klasiskajam WAF: WAAP un API aizsardzība

Apdraudējumu ainava nav apstājusies. Mūsdienās daudzas lietojumprogrammas ir mākoņpakalpojumos balstītas, izmanto mikropakalpojumu arhitektūras un atklāj publiskas un privātas API , padarot tās par galvenajiem uzbrucēju mērķiem. Tradicionālās WAF ir attīstījušās par plašākām platformām, kas pazīstamas kā WAAP (tīmekļa lietojumprogrammu un API aizsardzība) vai WAAS (tīmekļa lietojumprogrammu un API drošība).

Šie risinājumi ne tikai automātiski atrod tīmekļa lietojumprogrammas, bet arī identificē API galapunktus , pieņem specifikācijas, piemēram, OpenAPI vai Swagger, un izmanto šo definīciju, lai pārbaudītu pieprasījumu atbilstību: paredzētos datu tipus, atļautos parametrus, lieluma ierobežojumus utt. Atkarībā no galapunkta (piemēram, tāda, kas apstrādā ļoti sensitīvus datus) var piemērot daudz augstāku pārbaudes un bloķēšanas līmeni.

Reģistrēšanas līmenī WAAP mēdz ģenerēt kontekstam bagātus notikumus : kurš precīzs API galapunkts tika uzbrukts, kura darbība (GET, POST, PUT…), kurš lietotājs vai marķieris bija iesaistīts, kura specifikācijas daļa tika pārkāpta utt. Tas ļauj pieņemt precīzākus bloķēšanas lēmumus, nevis paļauties tikai uz vispārīgiem lietderīgās slodzes modeļiem.

Turklāt daudzi WAAP rīki ietver lietojumprogrammām un API specifisku DoS aizsardzību, ģeolokācijas filtrēšanu, IP reputācijas pārvaldību, botu un datu nokasīšanas noteikšanu, kā arī iespējas pielāgot brīdinājuma līmeņus katram pakalpojumam. Atkal runa ir par elastību, lai izlemtu, kur vēlaties stabilāku pieeju un kur vēlaties piešķirt prioritāti nevainojamai darbībai , neupurējot stabilu žurnālu datubāzi incidentu izmeklēšanai.

Kopumā labi noregulēts WAF — neatkarīgi no tā, vai tas ir klasisks, uz WAAP balstīts vai integrēts mākoņa ekosistēmā — kļūst par būtisku mūsdienu lietojumprogrammu un API aizsardzības sastāvdaļu, kas spēj apvienot detalizētu reģistrēšanu, intelektuālu bloķēšanu un nepārtrauktu pielāgošanos mainīgajai apdraudējumu ainavai.