Conceptul de WAF (Web Application Firewall) s-a născut din necesitatea de a avea o mai bună analiză asupra traficului pe serviciile expuse pe Internet și de a avea capacitatea de a reacționa rapid, independent de servicii, la anumite atacuri, vulnerabilități sau reguli în general. De obicei, aplicațiile sunt greoaie. De aceea, de multe ori, nu se justifică un proces de re-compilare, relansare a aplicației doar pentru a adăuga o mică regulă de rutare, de monitorizare sau de a realiza multe alte operații, care au legătură cu serviciul dar nu cu aplicația în sine.
Conceptul este simplu: aplicația WAF preia traficul de la utilizator, îl procesează, aplică regulile, și în funcție de rezultat trimite la origine (la aplicație), returnează o eroare sau execută acțiuni dintr-o gamă destul de mare pe care le are la dispoziție. Inițial, aceste aplicații au fost create să ruleze în rețeaua locală, în fața aplicațiilor, dar odată cu dezvoltarea soluțiilor de Cloud, au apărut și soluțiile de WAF care sunt livrate sub formă de servicii: traficul de la clienți este preluat de furnizorul de servicii, analizat și retransmis către origine. Diferența în funcționara WAF-ului nu diferă într-atât cum diferă arhitectura lanțului de componente dintre utilizator și serviciul pe care dorește să-l consume, în sensul că acest serviciu de WAF interpus modifică natura traficului în sine, ceea ce prezintă în multe situații avantaje.
Divizia Paddy Power Betfair, componentă a grupului Flutter Entertainment, este o divizie foarte tehnică și pe parcursul evoluției am preferat să dezvoltăm intern cât mai multe componente cu putință și să ne bazăm mai mult pe produse (hardware și software care rulează în spații fizice) și nu atât de mult pe servicii (software rulat de furnizori pe sistemele lor). Din punctul de vedere al securității cibernetice, ne bazăm foarte mult pe propria noastră experiență și pe echipamentele noastre.
Situația s-a schimbat, însă în decursul timpului deoarece compania s-a dezvoltat, serviciile s-au diversificat, a crescut, de asemenea, și numărul clienților. Dar cel mai mult s-a schimbat violența și frecvența cu care se manifestă factorii distructivi de pe Internet. Pentru noi, decizia de a implementa o soluție WAF pe o arhitectură, Cloud nu a fost ușoară pentru că am mers, oarecum, în direcția opusă tradițiilor noastre. În final, am decis că este soluția optimă în condițiile economice și tehnologice ale momentului.
Mai întâi, voi prezenta trei dintre principalele dezavantaje ale acestor soluții. Probabil sunt mai multe, dar cele prezentate pot avea consecințe pe termen lung asupra companiei, respectiv asupra viitorului Internetului în sine.
Primele două aspecte au un caracter practic, confruntându-ne cu ele de multe ori pe parcursul trecerii noastre la această arhitectură. În mod evident, orice companie se străduiește să asigure clienților săi o experiență cât mai bună și să evite întreruperile în servicii. La rândul lui, acest criteriu implică adoptarea unui principiu de redundanță în servicii pentru a putea oferi continuitate în cazul apariției unor defecțiuni. În ceea ce privește acest aspect, la PPB avem redundanță la tot ce este tehnologic posibil, inclusiv furnizorii de internet, dar ne străduim să evităm situațiile în care acest lucru nu este posibil. În cazul în care serviciile sunt mai reduse ca anvergură, situația se poate elimina prin implementarea a două soluții Cloud WAF și cu mecanisme de basculare în situații de urgență, dar la volumul nostru de trafic (în jur de 1 Petabyte de date transferate pe luna) acest lucru nu este fezabil din punctul de vedere al costurilor. Există desigur o circumstanță atenuantă prin faptul că furnizorul serviciului, în sine, oferă un oarecare grad de redundanță. Cu toate acestea, din punctul nostru de vedere depindem de un singur furnizor, care, dacă acesta are probleme, există șanse ca și noi să le resimțim. Prin urmare, este important de evaluat gradul de redundanță pe care furnizorul îl are, precum și istoricul evenimentelor nefericite pe care le-a avut și, nu în ultimul rând, atitudinea sa în acele momente.
Un alt aspect important vine din tendința inevitabilă de a ne folosi de funcționalitățile oferite de platformele cu care lucrăm, ceea ce automat duce la o integrare strânsă cu acești furnizori. Această integrare creează dependență, ceea ce îngreunează migrarea la un alt furnizor și poate face imposibilă adoptarea a două soluții de WAF pentru redundanță. În majoritatea cazurilor, acele funcții specifice se pot evita, garantând o mai mare portabilitate. Cum acest lucru prezintă oarecum o pierdere a facilităților, trebuie să ne rezumăm la funcționalități standard. Depinde în final de constrângerile fiecăruia și de cât de confortabil este forul decizional cu aceste inconveniențe.
Este, de asemenea, important de luat în considerare un aspect principial: Internetul a fost creat să fie distribuit, unul din beneficiile sale cele mai mari fiind, de fapt, această natură distribuită. Totodată, prin adoptarea acestor soluții WAF, traficul se canalizează printr-un număr foarte mic de servicii și furnizori, cărora le delegăm foarte multă putere. Cu timpul, aceasta poate deveni o puternică dependență și, de asemenea, un vector de abuz la adresa datelor.
Odată ce ne-am împăcat cu aceste minusuri, aceste soluții pot, într-adevăr, să aducă o serie de beneficii multilaterale (nu doar pe planul securității cibernetice), și nu doar multe, dar și într-un timp relativ scurt.
Evident, obiectivul principal al unei soluții WAF este securitatea cibernetică. Multe companii adoptă WAF cu această motivație în gând, dar este dificil, deseori, de justificat alocarea resurselor, atât financiare cât și de personal, din cauză că aceste soluții sunt scumpe și necesită adesea o transformare considerabilă în ceea ce privește arhitectura platformelor. Cel puțin în cazul nostru, această transformare s-a extins pe multe arii, necesitând implicarea multor departamente, alocarea de oameni, ceea ce a însemnat decalarea altor proiecte. Prin urmare, o decizie grea. În cazul nostru, decizia de a implementa Cloud WAF a fost catalizată de un atac DDoS (Distributed Denial of Service) la nivel de aplicație (Layer 7), care nu a putut fi negociată de către soluțiile clasice de DDoS de nivel de rețea deja implementate. Serviciile noastre au fost blocate o mare parte din ziua respectivă și în jurul orei 23 am decis să facem tranziția. Eram destul de bine pregătiți pentru această tranziție, pentru că echipa de securitate avusese acest proiect în pregătire de aproape un an la momentul respectiv; aveam oferte, înțelesesem impactul, mecanismul de tranziție și cel mai important, beneficiile.
Primul beneficiu pe care l-am observat, evident, după dispariția atacului, a fost vizibilitatea excepțională pe care am dobândit-o. Ca echipă de securitate ne-am străduit, întotdeauna, să avem o cât mai bună înțelegere a evenimentelor. Cu toate că la nivel de aplicație stăteam destul de bine la loguri (aproximativ 7TB pe zi), la nivel de rețea este foarte greu de capturat, și nu numai din perspectiva volumului imens de date care se generează din trafic, dar și din cauza faptului că unele informații nu sunt disponibile. De exemplu, acum știm exact nu numai din ce țară vine traficul, dar și furnizorul de internet prin care vine. Este extraordinar de util. De exemplu, dacă un client accesează aplicația cu un User Agent de Chrome, care, de fapt, provine din AWS, se știe sigur că acest client este, de fapt, un software oarecare, nu un browser. Aceste lucruri mărunte se adună și contribuie enorm la abilitatea noastră de a bloca traficul nedorit. Nu doar că aceste informații devin disponibile, dar deții marele avantaj de a acționa direct din WAF, pentru a elimina traficul nedorit, fâră a mai ajunge în infrastructură. De pildă, în momentul de față noi blocăm trafic cu anumite criterii pentru mai mult de 100 de țări cu risc ridicat. A durat un timp până am analizat fiecare rută din punctul de vedere al venitului din țările respective, al brandului și al jurisdicțiilor în care sunt licențiate, însă blocarea traficului ne-a eliminat o parte substanțială a traficului malițios.
Un alt mare avantaj a venit din reducerea complexității, ceea ce în oarecare măsură are și implicații de securitate: cu cât un sistem este mai complex, cu atât este mai dificil de apărat. Rutele, regulile sunt mult simplificate, sunt aplicate într-un singur loc, fiind definite pe bază de software. Toate configurările sunt prezente în git, iar la baza automatizării lor se află Terraform. Orice echipă poate contribui la aceste fișiere de configurare, necesitând doar o supervizare din partea echipei de securitate. În rest, fișierele de configurare conțin o reprezentare perfectă a stării WAF-lui. Am eliminat astfel necesitatea de a aplica diferite reguli în diferite sisteme, de multe ori manual, de către diferite echipe și în diferite utilitare de configurare. Printre altele, inclusiv componenta de certificare (SSL/TLS) a serviciilor a fost eliminată (preluată de către WAF în mod automat). Toate aceste lucruri se cumulează, în final ajungându-se la o reducere substanțială a erorilor.
Unul din cele mai vizibile beneficii, care ne-a ajutat foarte mult la modul în care a fost primit WAF-ul în celelalte departamente (cărora le-am dat de lucru prin această tranziție), a fost cel al performanței. Datorită unor combinații de arhitectură și platformă am ajuns la o reducere de 30 - 50% a timpului de încărcare a paginii - un procent enorm, realizat fără nicio modificare de aplicație. Spre exemplu, conexiunea TLS nu se mai realizează până în data centerul din Dublin, ci la cel mai apropiat PoP (point of presence / punct de prezență) al WAF-ului. Mulțumită faptului că acesta operează cu cele mai noi tehnologii (de exemplu, TLSv1.3 și HTTP/2) am reușit să obținem aceste creșteri în performanță. Impactul a fost atât de profund încât echipele și-au dorit migrarea componentelor, ceea ce ne-a ajutat enorm în acestă tranziție. Practic în 8 luni, au fost migrate în jur de 400 de servici (fiecare cu redundanța sa), de la preluarea traficului din propria infrastructură la Cloud WAF.
În ceea ce ne privește, implementarea încă nu s-a terminat. Sunt foarte multe aspecte în care putem să atragem beneficii. Conducerea noastră a acceptat dependența de un singur furnizor pe acest plan, nefiind lipsită de peripeții: la nici o lună de la pornirea proiectului, furnizorul a avut o cădere a serviciului de 20 de minute. Cu toate acestea, modul în care furnizorul a abordat eroarea și felul în care s-a comportat serviciul în cea mai intensivă perioadă pentru noi - au tranzacționat cu ușurință, uneori, peste 200.000 request-uri HTTPS pe secundă, doar pentru noi- au dovedit că beneficiile serviciului depășește cu mult riscul de a depinde de un singur furnizor.
Pe viitor, ne așteptăm la foarte multe transformări în această direcție. Există mult interes și din alte divizii la nivel de grup, la unele din punct de vedere arhitectural, la altele din punct de vedere al furnizorului. Prin urmare, suntem mândri de impactul pozitiv pe care l-am adus firmei și clienților săi.