Tasapaino tallennuksen ja estämisen välillä WAF:ssa

Informatec Digital » Resurssit » Tasapaino tallennuksen ja estämisen välillä WAF:ssa

Oikean tasapainon löytäminen lokitietojen ja estojen välillä WAF-ympäristössä on tullut yhdeksi yleisimmistä päänsäryistä tietoturva- ja operatiivisille tiimeille. Verkkosovelluspalomuuri voi estää erittäin vakavat hyökkäykset, mutta liian aggressiivisesti määritettynä se voi estää lailliset ostokset, käyttöoikeudet tai API-kutsuja. Liian löyhästi määritettynä siitä tulee lähes pelkästään koristeellinen. Tärkeintä on säätää huolellisesti, milloin lokitiedot kirjataan, milloin lasketaan, milloin sallitaan ja milloin estetään.

Tässä artikkelissa perehdymme siihen, miten tämä tasapaino saavutetaan käyttämällä nykyaikaisia ​​WAF-ominaisuuksia (sallitut listat, taajuuspohjaiset säännöt, oppimistilat, SIEM-integraatio, koneoppiminen jne.) ja hyödyntämällä konkreettisia esimerkkejä AWS WAF:sta, ModSecuritysta, pilvipohjaisista WAF-järjestelmistä ja paikallisista ratkaisuista . Näet, miten vääriä positiivisia tuloksia voidaan rajoittaa heikentämättä suojaustasoa, miten käytäntöjä voidaan järjestää sovelluksen mukaan ja miten lokitietoja voidaan käyttää apuna jatkuvan, hallitsemattoman kohinalähteen sijaan.

Mikä on WAF ja miksi rekisteröinti on niin tärkeää?

Verkkosovelluspalomuuri toimii älykkäänä kerroksena käyttäjän ja palvelimen välillä ja analysoi HTTP/HTTPS-liikennettä reaaliajassa. Toisin kuin perinteinen verkkopalomuuri, joka valvoo portteja ja IP-osoitteita, WAF-palomuuri tutkii asioita syvällisemmin: URL-osoitteita, parametreja, pyyntöjen rungon otsikoita, evästeitä, HTTP-metodeja ja paljon muuta.

Sen tehtävänä on havaita ja pysäyttää tyypillisiä Layer 7 -hyökkäyksiä : SQL-injektiota, XSS:ää, LFI/RFI:tä, hyökkäyksiä pääsynhallintaa vastaan, API-väärinkäyttöä, aggressiivista tiedonkaappausta, raa'aa voimaa ja jopa tiettyjä sovellustason DDoS-hyökkäysmalleja. Tätä varten se käyttää jatkuvasti päivittyviä sääntöjä, allekirjoituksia ja tietoturvakäytäntöjä.

Lokikirjaus on kolikon toinen puoli. Jokaiseen WAF-päätökseen – salliminen, estäminen tai vain laskeminen – voi liittyä yksityiskohtainen tapahtuma lokitiedostoissa . Näiden lokien avulla voidaan:

• Tutki tapahtumia: rekonstruoi, mitä tapahtui ja miten haavoittuvuutta yritettiin hyödyntää.
• Säädä sääntöjä: havaitsee vääriä positiivisia tuloksia näkemällä, mitä laillisia pyyntöjä WAF estää.
• Noudata määräyksiä: osoitettava, että aktiivisia valvontamekanismeja on olemassa (PCI DSS, GDPR, sisäiset tarkastukset jne.).
• SIEM-järjestelmän ruokinta: korreloi sovellushyökkäykset verkko-, järjestelmä-, identiteetti- jne. tapahtumien kanssa.

Ongelmana on, että huonosti viritetty WAF voi täyttää lokit tuhansilla epäolennaisilla tapahtumilla , mikä tekee mahdottomaksi löytää tärkeän ja kaiken lisäksi aiheuttaa perusteettomia laillisen liikenteen hylkäämisiä. Tässä kohtaa lokikirjaus-, laskenta- ja estotilojen kanssa leikkiminen astuu kuvaan.

WAF:n tietoturvamallit: estolistat, sallittulistat ja hybridilähestymistapa

Useimmat nykyaikaiset WAF-suodattimet yhdistävät useita suodatusmenetelmiä, jotka vaikuttavat suoraan pyyntöjen lokiin kirjaamiseen ja estämiseen . Yleisesti ottaen voimme tunnistaa kaksi klassista filosofiaa sekä hyvin yleisen hybridimallin.

Estolistapohjainen WAF noudattaa negatiivista tietoturvamallia. Sen ydinperiaate on: "Sallit kaiken paitsi sen, minkä tiedän olevan haitallista." Se toimii käyttämällä tunnettujen hyökkäysten (SQL-injektio, XSS, bottikuviot jne.) tunnisteita ja sääntöjä, jotka määrittelevät, mikä katsotaan epäilyttäväksi. Se on helpompi ottaa käyttöön aluksi, mutta pelkästään tähän malliin luottaminen voi antaa uusien hyökkäysvektorien tai -varianttien päästä läpi huomaamatta.

Sallittujen yhteyksien listalla varustettu WAF toimii päinvastoin: "estä kaikki paitsi se, mikä on nimenomaisesti sallittu". Se perustuu positiiviseen tietoturvamalliin. Vain määriteltyä laillista toimintaa – reittejä, metodeja, parametreja, formaatteja, kokoja jne. – vastaava liikenne hyväksytään. Se on paljon turvallisempaa, mutta vaatii merkittävää hienosäätöä ja voi aluksi tuottaa vääriä positiivisia tuloksia, jos sitä ei ole valmisteltu kunnolla.

Kummankin lähestymistavan etujen ja haittojen vuoksi sallittujen ja estojen listoja yhdistävä hybridimalli on yleistymässä . Tässä skenaariossa määritellään odotetut liikenneprofiilit (esimerkiksi mikä on normaali kirjautuminen tai maksupyyntö), ja allekirjoituksia ja heuristiikkaa käytetään samanaikaisesti tyypillisten haitallisten toimintamallien havaitsemiseksi. Lokikirjauksen osalta tämä hybridilähestymistapa mahdollistaa:

• Merkitse nimellä korkean riskin tapahtuma joka rikkoo sallittujen esineiden listaa.
• Käsittele kuten keskitason/matalan prioriteetin hälytykset yleiset estolistamallit.
• Käytä "laskenta"-tilaa nähdäksesi, mikä rikkoisi säännön ennen eston aktivointia.

WAF verkossa, isännöintiympäristössä ja pilvessä: vaikutus lokikirjaukseen ja lukitukseen

WAF-käyttöönottomalli vaikuttaa merkittävästi liikenteen lokitietojen ja estojen käsittelyyn. Pyyntöjen lokitietojen kirjaaminen verkkolaitteelle ei ole sama asia kuin niiden kirjaaminen palvelimen agentille tai hallittuun pilvipalveluun.

Verkkopohjainen WAF otetaan tyypillisesti käyttöön fyysisenä tai virtuaalisena laitteena infrastruktuurin sisällä internetin ja sovellusten välillä. Tämä on klassinen lähestymistapa, jota valmistajat, kuten F5, käyttävät. Se tarjoaa etuna korkean suorituskyvyn ja yksityiskohtaisen hallinnan , mutta konfigurointi ja hallinta voivat olla monimutkaisia. Lokitiedot lähetetään yleensä syslogiin tai keskitettyyn SIEM-järjestelmään, ja on tärkeää suodattaa tallennettavat tiedot huolellisesti, jotta vältetään tallennus- ja analyysityökalujen ylikuormitus ja voidaan diagnosoida ongelmia IP- ja DNS-verkoissa.

Isäntäpohjaiset WAF-palvelimet toimivat samoilla palvelimilla (tai konteilla), joissa sovellus sijaitsee, tyypillisesti moduulina tai agenttina (esimerkiksi ModSecurity integroituna Nginxiin tai Apacheen; sen yhdistäminen Linuxin suojaukseen SELinuxin avulla parantaa tietoturvaa). Tämä malli mahdollistaa laajemman sovelluskontekstin ja erittäin tarkat säännöt palvelua kohden, mutta se kuluttaa paikallisia resursseja ja vaatii hajautetumpaa lokien hallintaa. Lokit voidaan tallentaa paikallisiin tiedostoihin ja lähettää sitten edelleen tai integroida keskitettyihin lokipalveluihin.

Pilvipohjaiset WAF-ympäristöt (Cloudflare, Akamai, Imperva Cloud, AWS WAF jne.) integroituvat kuormituksen tasaajiin, CDN-verkkoihin tai virtuaaliverkkoihin. Palveluntarjoajat tarjoavat tyypillisesti koontinäyttöjä ja lokien vientiä S3:een, BigQueryyn, etälokeihin tai SIEM-järjestelmiin. Ne ovat yleensä helpompia ottaa käyttöön, mutta sinun on mukautettava lokikäytäntöjäsi palveluntarjoajan malliin: tapahtumatyypit, säilytysajat, vakavuussuodattimet jne.

Mallin valinta ei ole pelkästään tekninen päätös, vaan myös kysymys siitä, miten haluat tasapainottaa lokien tallentamisen ja lukituksen: pilvipalvelu yksinkertaistaa monia näkökohtia, mutta saatat haluta täydellisen hallinnan lokien tallennuspaikasta vaatimustenmukaisuus- tai luottamuksellisuuskäytäntöjen vuoksi, mikä ohjaa sinua kohti paikallisia tai hybridimalleja.

Ehdot, säännöt ja verkkokäyttöoikeusluettelot: miten WAF päättää, estetäänkö, sallitaanko vai vain rekisteröidäänkö

Valmistajasta riippumatta kaikki modernit WAF-rakenteet perustuvat käyttöehtojen, sääntöjen ja käytäntöjen käsitteeseen . Tämän ymmärtäminen on avainasemassa laskenta-, lokikirjaus- ja lukitustilojen onnistuneessa käytössä tuotannossa.

Ehdot kuvaavat , mitä osaa pyynnöstä tarkastellaan: lähteen IP-osoitetta, tiettyjä HTTP-otsikoita (isäntä, käyttäjäagentti, hyväksyntä, sisällön tyyppi…), kyselyparametreja, pyynnön runkoa, evästeitä, HTTP-menetelmää, alkuperämaata jne. Esimerkiksi AWS WAF Classicissa voit määrittää IP-ehdon, jossa on jopa 10 000 osoitetta tai aluetta, tai merkkijonon vastaavuusehdon URL-osoitteen osalle.

Säännöt yhdistävät yhden tai useamman ehdon ja määrittävät niille tarkoituksen: sallia, estää tai laskea. Kun säännöllä on useita ehtoja, ne arvioidaan tyypillisesti loogisella JA -operaattorilla : kaikkien ehtojen on täytyttävä, jotta sääntö käynnistyy. Normaali sääntö ilman ehtoja ei käytännössä vastaa mitään, eikä sen toiminto koskaan käynnisty.

Monissa WAF-verkoissa, mukaan lukien AWS WAF, on myös nopeuteen perustuvia sääntöjä . Nämä säännöt laskevat IP-osoitteesta (tai tietyt ehdot täyttävistä IP-osoitteista) saapuvat pyynnöt tietyn aikaikkunan, esimerkiksi viiden minuutin, aikana. Jos kynnysarvo ylittyy – esimerkiksi 1 000 pyyntöä viidessä minuutissa – sääntö tulee voimaan: esto tai yksinkertaisesti laskenta. Tämä on erittäin hyödyllistä seuraavissa tilanteissa:

• ohjaus raaka voima kirjautumislomakkeissa.
• Rajoita aggressiivista tiedonhakua tai töykeitä botteja.
• Tietyntyyppisten DDoS-hyökkäysten lieventäminen sovellustasolla.

Seuraava taso on Web ACL (Access Control List) . Tässä säännöt ryhmitellään ja määritellään arviointijärjestys ja oletustoiminto (ALLOW tai BLOCK). Pyyntö käy läpi säännöt järjestyksessä; jos se vastaa yhtä sääntöä, sen toimintoa sovelletaan ja muiden sääntöjen arviointi pysäytetään. Jos se ei vastaa mitään sääntöä, käytetään ACL:ssä määritettyä oletustoimintoa.

Lokikirjauksen ja estämisen tasapainottamisen kannalta ACL:ssä päätetään, onko järjestelmän oletusarvoisesti sallittu (SALLI ja esto vain tiettyjen sääntöjen mukaisesti) vai erittäin rajoittava (ESTÄ paitsi poikkeustapauksissa). Lisäksi monet ratkaisut mahdollistavat sääntöjen asettamisen "laskenta"-tilassa ACL:ssä, jolloin ne kirjaavat osumat, mutta eivät estä liikennettä – ihanteellinen säätövaiheessa.

Valkoiset listat ja kohinanvaimennus lokeissa

Sallittujen listat ovat olennainen työkalu väärien positiivisten tulosten ja lokikohinan vähentämiseen . Idea on yksinkertainen: tietyissä yhteyksissä käsket WAF:ia olemaan soveltamatta direktiiviä tai sääntöjoukkoa tiettyyn liikenteeseen, jonka olet jo luokitellut luotettavaksi tai jonka tiedät olevan normin ulkopuolella, mutta laillista.

Esimerkiksi AWS WAF:ssa voit luoda sallittujen luettelon sääntöjä siten, että jos pyyntö tulee tietystä IP-osoitteesta tai IP-väliltä tai jos se vastaa tunnettua URL-osoitemallia ja HTTP-menetelmää, tiettyjä allekirjoitustarkastuksia ei suoriteta. Tämä auttaa:

• Estä sisäiset API:t, jotka käyttävät "outoja" kaavoja tuottaa jatkuvasti vääriä positiivisia.
• Vähennä syvällisen tarkastuksen aiheuttamaa viivettä liikenteessä, jota jo pidät luotettavana.
• Vähennä tarpeettomien tietueiden määrää WAF-lokeissa.

ModSecurityn kaltaisilla alustoilla suositeltu lähestymistapa ei ole muokata vakiosääntöjä (esim. OWASP Core Rule Set), vaan pikemminkin luoda tiettyjä poissulkemisia sääntötunnusten perusteella tietyille parametreille, poluille tai käyttäjille. Näin voit ylläpitää yleistä suojausta luomatta valtavia haavoittuvuuksia poistamalla käytöstä kokonaisia ​​sääntöjä koko sivustolla.

Tärkeintä on tehdä sallittujen listojen käytöstä kirurgista , ei yleistä lähestymistapaa. On paljon parempi sulkea pois tietty yhdistelmä (sääntö X + parametri Y URL-osoitteessa Z) kuin poistaa sääntö X käytöstä globaalisti. Tällä tavoin lokitiedot pysyvät hyödyllisinä etkä luo tarpeettomia katvealueita.

Protokollasäännöt ja -rajoitukset: milloin estää, milloin varoittaa

Monet WAF-verkot sisältävät joukon HTTP-protokollan puhdistussääntöjä, jotka toimivat ensimmäisenä suodattimena väärin muotoillulle tai epäilyttävälle liikenteelle . Nämä säännöt tarkistavat pakolliset otsikot, metodit, argumenttien koot jne. ja ovat usein sekä hyvän suojauksen että väärien positiivisten tulosten lähde, jos niitä ei ymmärretä oikein.

Joitakin hyvin yleisiä esimerkkejä:

• Puuttuva hyväksyntäotsikko (Puuttuva Accept-otsikko): Tämä ei ole varsinaisesti RFC-rikkomus, mutta monet pyynnöt ilman tätä otsikkoa tulevat automatisoiduista työkaluista tai huonosti kirjoitetuista skripteistä. Se voi vaikuttaa mukautettuihin API-rajapintoihin tai asiakasohjelmiin, jotka eivät lähetä sitä. Monissa ympäristöissä lokinnusta ja laskemista suositaan suoraan estämiseen verrattuna.
• Puuttuva isäntäotsikkoHTTP/1.1-standardien mukaan Host-otsikko on pakollinen. Myös WAF-verkot tarvitsevat sitä määrittääkseen, mitä käytäntöä sovelletaan. Estäminen tässä on yleensä kohtuullista, mutta se voi tuottaa vääriä positiivisia tuloksia testauksen aikana tai väärin määritetyn sisäisen liikenteen vuoksi. On suositeltavaa seurata lokeja ennen tiukan eston käyttöönottoa.
• Puuttuva käyttäjäagentin otsikkoTämä sääntö pyrkii hillitsemään alkeellisia botteja ja tunnistamatonta liikennettä. Ongelmana on, että monet lailliset API:t eivät välttämättä lähetä käyttäjäagenttia. Järkevin lähestymistapa on yleensä kirjata tiedot lokiin, ja jos johdonmukainen ja laillinen API havaitaan, lisää heidän IP-osoitteensa tai mallinsa sallittujen luetteloon.
• GET/HEAD-vahvistus rungollaVaikka RFC ei tiukasti kiellä rungon lähettämistä GET- tai HEAD-pyynnöissä, se ei ole yleinen käytäntö ja voi viitata väistöyrityksiin. Monissa tapauksissa ensimmäinen askel on kirjata kaikki nämä pyynnöt ja, jos ne havaitaan epäilyttäviksi poikkeaviksi, estää ne.
• Puuttuva sisältötyyppi ja runkoJos on runko, mutta ei Content-Type-arvoa, se on selvä osoitus väärästä protokollan käytöstä tai yrityksestä välttää analyysia. Näissä tapauksissa aggressiivisempi estotapa on yleensä järkevä, erityisesti internet-ympäristöissä.

Näiden protokollasääntöjen lisäksi käytetään usein argumenttirajoituksia suojautumiseksi sovellustason tulvilta ja palvelunestohyökkäyksiltä. Esimerkiksi:

• Argumenttien enimmäismäärä pyyntöä kohden (oletusarvoisesti 255 joissakin WAF-ympäristöissä).
• Yksittäisen argumentin enimmäispituus (esimerkiksi 400 merkkiä).
• Kaikkien argumenttien yhteenlaskettu koko (esimerkiksi 64 000 tavua).

Nämä arvot ovat kohtuullisia monille sovelluksille, mutta on tapauksia – monimutkaiset lomakkeiden lataukset, edistyneet suodattimet, suuret JSON-lataukset – joissa esiintyy vääriä positiivisia tuloksia. Näissä tilanteissa järkevin lähestymistapa on aloittaa kirjaamalla ja laskemalla , tarkistaa, mitkä päätepisteet rikkovat rajoituksia, ja säätää vain näitä reittejä sen sijaan, että poistettaisiin kaikki rajoitukset koko sivustolta.

Väärät positiiviset: miten ne havaitaan ja miten vältytään yrittäessä kuolemasta

Väärä positiivinen tulos on oikeutettu pyyntö, jonka WAF tunnistaa haitalliseksi ja estää tai merkitsee hyökkäykseksi. Niitä on mahdotonta välttää, varsinkin kun käytössä on kattavat säännöstöt, kuten OWASP CRS, mutta niitä voidaan hallita ammattimaisesti, jotta niistä ei tule päivittäistä päänvaivaa.

Väärien positiivisten havaitseminen alkaa lokien huolellisella tarkastelulla . Tämä tarkoittaa estettyjen pyyntöjen, niiden laukaisevan säännön ja niiden esiintymiskontekstin (URL-osoite, parametrit, käyttäjä, alkuperä jne.) tutkimista. Visuaaliset työkalut ja kojelaudat voivat auttaa tunnistamaan 403-virheiden piikkejä tai epätavallisia kaavoja.

Sekä pilvipalveluntarjoajat että ModSecurity-yhteisö suosittelevat erittäin paljon simulointi- tai laskentatilan käyttöä . Tässä tilassa testattavat säännöt kirjaavat lokiin jokaisen osuman, mutta eivät estä niitä. Näin voit esimerkiksi nähdä, kuinka monta laillista pyyntöä uusi SQLi-sääntö olisi estänyt ennen kuin uskalsit aktivoida sen tuotannossa.

On myös hyvä idea testata sääntöjä testi- tai esituotantoympäristössä , joka vastaanottaa todellista tai simuloitua liikennettä. Työkalut, kuten OWASP ZAP tai liikenteen toistoskriptit, voivat auttaa simuloimaan laillisia kaavoja ja tunnettuja hyökkäyksiä WAF:n toiminnan testaamiseksi.

Lisäksi on tärkeää ottaa huomioon väärien positiivisten tulosten operatiiviset ja mainevaikutukset: maksujen keskeytykset, käyttäjien rekisteröintivirheet, kriittiset API-kutsut, jotka epäonnistuvat ilman selitystä – kaikki nämä voivat vaikuttaa suoraan tuloihin ja brändikuvaan. Liian suuri määrä vääriä positiivisia tuloksia myös ylikuormittaa tietoturvatiimin hälytyksillä, jotka eivät tuo lisäarvoa, mikä vaikeuttaa aitojen tapausten tunnistamista.

Strategioita sääntöjen mukauttamiseen ja rekisterin älykkääseen käyttöön

Väärien positiivisten hallinta ei tarkoita sääntöjen poistamista käytöstä, kunnes "kaikki toimii", vaan WAF:n hienosäätöä kirurgin tarkkuudella . Tässä kohtaa seuraavat hyvät käytännöt tulevat esiin:

Ensinnäkin, vältä sääntöjen poistamista käytöstä globaalisti. On suositeltavaa luoda hyvin erityisiä poikkeuksia : jätä säännön tunnus pois vain tietyltä reitiltä, ​​tietyiltä parametreilta tai sisäiseltä liikenteeltä. Tällä tavoin pysyt suojattuna sovelluksen muissa osissa ja ylläpidät hyödyllisiä lokeja.

Toiseksi, hyödynnä laskentatilaa ennen estämistä. Uusien sääntöjen aktivointi aluksi vain lokikirjaustilassa antaa sinun mitata, kuinka moneen lailliseen pyyntöön säännöllä olisi vaikutusta. Voit täydentää tätä SIEM-hälytyksillä, joiden avulla voit nopeasti havaita, jos sääntö tuottaa epänormaalin määrän osumia.

Kolmanneksi, integroi WAF SIEM:iin tai keskitettyyn lokikirjausalustaan . Tämä helpottaa WAF-tapahtumien korrelointia muiden indikaattoreiden, kuten epätavallisen järjestelmätoiminnan, joukkotodennuksen epäonnistumisten, epäilyttävien kokoonpanomuutosten jne., kanssa. Se auttaa myös priorisoimaan, mitä sääntöjä muutetaan ensin tapahtumien vakavuuden ja esiintymistiheyden perusteella.

Neljänneksi, dokumentoi jokainen muutos: mitä sääntöä on hienosäädetty, mitä päätepistettä varten, millä perusteilla ja millä todisteilla. Palvelimen käyttöoppaiden tarkastelu voi olla hyödyllistä tässä. Tämä dokumentaatio ei ainoastaan ​​auta ylläpitämään sisäistä valvontaa, vaan se on myös korvaamatonta tietoturvatarkastuksissa ja -arvioinneissa, joissa haluat osoittaa, että valvontaa ei poisteta käytöstä kevytmielisesti.

Automaatio, koneoppiminen ja adaptiiviset säännöt WAF:ssa

Sovellusten kasvaessa ja liikenteen monimutkaistuessa WAF:n manuaalinen hallinta käy epärealistiseksi. Tässä kohtaa automaatio, edistynyt lokitietojen analysointi ja joissakin tapauksissa koneoppiminen tulevat avuksi.

Ensinnäkin SIEM-integraatio mahdollistaa korrelaatiosääntöjen ja automatisoitujen vastausten rakentamisen : esimerkiksi jos IP-osoitteiden joukko toistuvasti laukaisee injektio- tai XSS-säännöt, voit luoda automaattisen toiminnon, jolla kyseiset IP-osoitteet lisätään väliaikaiseen estolistalle tai vahvistetaan tarkastustasoa.

Toiseksi, jotkut WAF-verkot sisältävät koneoppimistiloja , jotka tarkkailevat laillista liikennettä tietyn ajanjakson aikana. Näiden tietojen perusteella ne ehdottavat tai säätävät normaalin käyttäytymisen kynnysarvoja, malleja ja profiileja. Tämä auttaa vähentämään vääriä positiivisia tuloksia, kun säännöt vaihdetaan estotilaan, ja havaitsemaan myöhemmät liikenteen poikkeamat.

Tutkimus- ja laboratorioympäristöissä ohjatun oppimisen tekniikoita on käytetty kouluttamaan malleja, jotka erottavat laillisen ja haitallisen liikenteen, ja tarkentamaan käytäntöjä, joita sitten käytetään tuotannossa. Vaikka tämä lähestymistapa ei olekaan mikään ihmelääke, se voi auttaa paljastamaan hienovaraisia ​​​​kuvioita , joita klassiset allekirjoituspohjaiset säännöt eivät helposti havaitse.

Lopuksi, jatkuva automatisoitu testaus (käyttäen työkaluja, kuten OWASP ZAP, mukautettuja skriptejä tai CI/CD-putkia) mahdollistaa sen, että voit varmistaa, etteivät WAF:n muutokset riko kriittisiä toimintoja tai jätä ilmeisiä haavoittuvuuksia. Näiden testien integrointi käyttöönottosykliin tekee tietoturvasta luonnollisen osan kehitysprosessia viime hetken korjauksen sijaan.

Käytännön suunnittelu sovelluskohtaisesti ja mustat listat palvelukohtaisesti

Monimutkaisissa ympäristöissä – esimerkiksi hosting-palveluntarjoajan tai internet-palveluntarjoajan – yksi WAF-käytäntö ei riitä, varsinkaan silloin, kun kyseessä on varjo-IT . On yleistä, että saman kuormituksen tasaajan takana on useita verkkotunnuksia tai sovelluksia, joilla jokaisella on erilaiset tietoturvatarpeet ja liikenneprofiilit . Tässä kohtaa palvelukohtaisten käytäntöjen ja luetteloiden suunnittelu on olennaista.

Havainnollistava esimerkki on HTTP/S-kuormituksen tasaaja, joka toimii käänteisenä välityspalvelimena useille sivustoille (esim. www.company1.com ja www.company2.com) yhden virtuaalisen IP-osoitteen takana. Tässä skenaariossa WAF voidaan konfiguroida arvioimaan isäntäotsikkoa ja lähde-IP-osoitetta heti pyynnön saapuessa, jopa ennen kuin se saavuttaa kuormituksen tasausmoduulin.

Logiikka olisi jotakuinkin seuraavanlainen: WAF tarkistaa, vastaako SERVER_NAME (isäntä) ja asiakkaan IP-osoite sivustokohtaista mustaa listaa. Jos IP-osoite on estetty osoitteelle www.company2.com, mutta ei osoitteelle www.company1.com, 403 Forbidden -vastaus lähetetään vain ensimmäisessä tapauksessa. "Puhdas" liikenne välitetään sitten kuormituksen tasapainotusmoduulille, joka päättää, mikä taustajärjestelmä käsittelee pyynnön.

Tämä mahdollistaa esimerkiksi verkkotunnuskohtaisten mustien listojen ylläpitämisen koko tukiaseman kattavan yhden globaalin listan sijaan. Lokikirjaustasolla jokainen hylkäys tallennetaan järjestelmälokiin, ja siihen tallennetaan tietoja, kuten säännön tunnus, vastaava ehto, URL-osoite, isäntä ja asiakkaan IP-osoite, mikä helpottaa näiden listojen myöhempää analysointia ja laajentamista tai virheenkorjausta.

Tarinan opetus on, että mitä segmentoidumpia käytäntösi ovat (sovelluksen, ympäristön, käyttäjätyypin mukaan), sitä paremmin voit löytää tasapainon lokien ja estämisen välillä: voit olla hyvin tiukka hallinnollisilla portaaleilla ja jonkin verran joustavampi tiedotussivustoilla, esimerkiksi aina ja lokeissa on todisteet siitä, miksi kukin päätös tehtiin.

Klassisen WAF:n tuolla puolen: WAAP- ja API-suojaus

Uhkakenttä ei ole pysähtynyt. Nykyään monet sovellukset ovat pilvinatiiveja, käyttävät mikropalveluarkkitehtuureja ja altistavat julkisille ja yksityisille API-rajapinnoille , mikä tekee niistä ensisijaisia ​​kohteita hyökkääjille. Perinteiset WAF-rajapinnat ovat kehittyneet laajemmiksi alustoiksi, jotka tunnetaan nimellä WAAP (Web Application and API Protection) tai WAAS (Web Application & API Security).

Nämä ratkaisut eivät ainoastaan ​​löydä verkkosovelluksia automaattisesti, vaan myös tunnistavat API-päätepisteitä , hyväksyvät määrityksiä, kuten OpenAPI tai Swagger, ja käyttävät tätä määritelmää pyyntöjen vaatimustenmukaisuuden tarkistamiseen: odotetut tietotyypit, sallitut parametrit, kokorajoitukset jne. Päätepisteestä riippuen (esimerkiksi erittäin arkaluonteisia tietoja käsittelevä) voidaan soveltaa paljon tiukempaa valvontaa ja estoa.

Lokikirjaustasolla WAAP yleensä luo kontekstipitoisia tapahtumia : mitä tarkalleen ottaen hyökkäyksen kohteeksi joutui, mikä operaatio (GET, POST, PUT…), mikä käyttäjä tai token oli mukana, mitä osaa määrityksestä rikottiin jne. Tämä mahdollistaa tarkemmat estopäätökset sen sijaan, että luotettaisiin pelkästään yleisiin hyötykuormamalleihin.

Lisäksi monet WAAP-työkalut sisältävät sovellus- ja API-kohtaisen DoS-suojauksen, geolokaatiosuodatuksen, IP-maineenhallintajärjestelmän, bottien ja kaapimisen tunnistuksen sekä vaihtoehtoja hälytystasojen mukauttamiseen palvelukohtaisesti. Jälleen kerran kyse on joustavuudesta päättää, missä haluat vankemman lähestymistavan ja missä haluat priorisoida sujuvan toiminnan tinkimättä vankasta lokitietokannasta mahdollisten tapausten tutkimista varten.

Yhteenvetona voidaan todeta, että hyvin viritetty WAF – olipa se sitten klassinen, WAAP-pohjainen tai pilviekosysteemiin integroitu – on olennainen osa nykyaikaista sovellus- ja API-puolustusta, joka kykenee yhdistämään yksityiskohtaisen lokinkirjauksen, älykkään estämisen ja jatkuvan sopeutumisen muuttuvaan uhkamaisemaan.