Kako će AI poboljšati sigurnost API-ja

API-ji su postali krunski dragulj inicijativa digitalne transformacije organizacija, osnažujući zaposlenike, partnere, kupce i druge dionike za pristup aplikacijama, podacima i poslovnoj funkcionalnosti kroz njihov digitalni ekosustav. Stoga nije čudo što su hakeri povećali svoje valove napada na tu ključnu imovinu poduzeća.

Nažalost, čini se da će se problem samo pogoršati. Gartner je predvidio da će "Do 2022. zlouporabe API-ja biti najčešći vektor napada što rezultira kršenjem podataka za poslovne web aplikacije."

Mnoga su poduzeća reagirala primjenom rješenja za upravljanje API-jem koja pružaju mehanizme, kao što su provjera autentičnosti, autorizacija i regulacija. To su nužne mogućnosti za kontrolu tko pristupa API-jevima kroz API ekosustav - i koliko često. Međutim, u izgradnji svojih unutarnjih i vanjskih API strategija, organizacije se također moraju pozabaviti rastom sofisticiranijih napada na API-je primjenom dinamičke sigurnosti, umjetne inteligencije (AI).

Ovaj članak ispituje alate za upravljanje API-jem i sigurnosne alate koje bi organizacije trebale uključiti kako bi osigurale sigurnost, integritet i dostupnost u svojim API ekosustavima.

Sigurnosne mjere zasnovane na pravilima i politike

Sigurnosne provjere temeljene na pravilima i politike, koje se mogu izvoditi na statički ili dinamički način, obvezni su dijelovi bilo kojeg rješenja za upravljanje API-jem. API pristupnici služe kao glavna ulazna točka za pristup API-ju i stoga obično obrađuju provođenje pravila inspekcijom dolaznih zahtjeva prema politikama i pravilima vezanim uz sigurnost, ograničenja brzine, reguliranje itd. Pogledajmo bliže neke statičke i dinamičke sigurnosne provjere kako bismo vidjeli dodatne vrijednost koju donose.

Statičke sigurnosne provjere

Statičke sigurnosne provjere ne ovise o opsegu zahtjeva ili bilo kojim prethodnim podacima zahtjeva, jer obično provjeravaju valjanost podataka poruka prema unaprijed definiranom skupu pravila ili pravila. U pristupnicima se izvode različita statička sigurnosna skeniranja kako bi se između ostalog blokirala SQL ubrizgavanje, kohezivni napadi raščlanjivanja, napadi proširenja entiteta i trovanje sheme.

U međuvremenu, statičke provjere pravila mogu se, među ostalim, primijeniti na skeniranje korisnog tereta, pregled zaglavlja i obrasce pristupa. Na primjer, ubrizgavanje SQL-a uobičajena je vrsta napada koja se izvodi pomoću korisnih tereta. Ako korisnik pošalje korisnički teret JSON (JavaScript Object Notation), API pristupnik može provjeriti valjanost ovog određenog zahtjeva prema unaprijed definiranoj JSON shemi. Pristupnik također može ograničiti broj elemenata ili drugih atributa u sadržaju kako bi se zaštitio od štetnih podataka ili tekstualnih uzoraka u porukama.

Dinamičke sigurnosne provjere

Dinamičke sigurnosne provjere, za razliku od statičkih sigurnosnih skeniranja, uvijek provjeravaju nešto što se vremenom mijenja. To obično uključuje provjeru valjanosti podataka zahtjeva s odlukama donesenim pomoću postojećih podataka. Primjeri dinamičkih provjera uključuju provjeru tokena pristupa, otkrivanje anomalija i reguliranje. Te dinamičke provjere uvelike ovise o količini podataka koja se šalje na pristupnik. Ponekad se te dinamičke provjere događaju izvan API pristupnika, a zatim se odluke prenose na pristupnik. Pogledajmo nekoliko primjera.

Ograničavanje i ograničavanje brzine važni su za smanjenje utjecaja napada, jer kad god napadači dobiju pristup API-ima, prvo što učine je pročitati što više podataka. Ograničavanje API zahtjeva - tj. Ograničavanje pristupa podacima - zahtijeva da broj dolaznih zahtjeva vodimo unutar određenog vremenskog razdoblja. Ako broj zahtjeva premaši dodijeljeni iznos u to vrijeme, pristupnik može blokirati API pozive. Ograničavanjem brzine možemo ograničiti istodobni pristup dopušten za određenu uslugu.

Ovjera

Autentifikacija pomaže API pristupnicima da identificiraju svakog korisnika koji jedinstveno poziva API. Dostupna rješenja API pristupnika općenito podržavaju osnovnu provjeru autentičnosti, OAuth 2.0, JWT (JSON Web Token) sigurnost i sigurnost na temelju certifikata. Neki pristupnici osim toga pružaju i sloj za provjeru autentičnosti za dodatnu preciznu provjeru dozvole, koja se obično temelji na jezicima za definiranje politike stila XACML (eXtensible Access Control Markup Language). To je važno kada API sadrži više resursa kojima su potrebne različite razine kontrole pristupa za svaki resurs.

Ograničenja tradicionalne API sigurnosti

Pristupi utemeljeni na politikama oko provjere autentičnosti, autorizacije, ograničavanja brzine i smanjenja protoka učinkoviti su alati, ali i dalje ostavljaju pukotine kroz koje hakeri mogu iskoristiti API-je. Važno je napomenuti da API pristupnici prelaze na više web usluga, a API-ji kojima oni upravljaju često su opterećeni velikim brojem sesija. Čak i ako bismo analizirali sve te sesije koristeći politike i procese, pristupniku bi bilo teško pregledati svaki zahtjev bez dodatne računarske snage.

Uz to, svaki API ima svoj vlastiti obrazac pristupa. Dakle, legitimni obrazac pristupa za jedan API mogao bi ukazivati ​​na zlonamjernu aktivnost za drugi API. Na primjer, kada netko kupuje predmete putem aplikacije za internetsku kupnju, provest će više pretraživanja prije kupnje. Dakle, jedan korisnik koji u kratkom vremenskom razdoblju pošalje API pretraživanju 10 do 20 zahtjeva može biti legitimni obrazac pristupa API-ju za pretraživanje. Međutim, ako isti korisnik pošalje više zahtjeva API-ju za kupnju, obrazac pristupa mogao bi ukazivati ​​na zlonamjernu aktivnost, poput hakera koji pokušava ukrasti što je više moguće koristeći ukradenu kreditnu karticu. Stoga svaki obrazac pristupa API-ju treba analizirati odvojeno kako bi se utvrdio točan odgovor.

Još je jedan faktor taj što se značajan broj napada događa iznutra. Ovdje korisnici s valjanim vjerodajnicama i pristupom sustavima koriste svoju sposobnost napada tih sustava. Mogućnosti provjere autentičnosti i autorizacije zasnovane na pravilima nisu namijenjene sprečavanju takvih vrsta napada. 

Čak i kad bismo na API pristupnik mogli primijeniti više pravila i pravila radi zaštite od ovdje opisanih napada, dodatni režijski troškovi na API pristupniku bili bi neprihvatljivi. Poduzeća si ne mogu priuštiti frustriranje stvarnih korisnika tražeći od njih da podnesu kašnjenja u obradi svojih API pristupnika. Umjesto toga, pristupnici trebaju obrađivati ​​valjane zahtjeve bez blokiranja ili usporavanja korisničkih API poziva.

Slučaj za dodavanje AI sigurnosnog sloja

Da bi popunili pukotine koje ostavljaju API zaštite temeljene na pravilima, moderni sigurnosni timovi trebaju API sigurnost zasnovanu na umjetnoj inteligenciji koja može otkriti i odgovoriti na dinamičke napade i jedinstvene ranjivosti svakog API-ja. Primjenjujući AI modele za kontinuirani pregled i izvještavanje o svim aktivnostima API-ja, poduzeća bi mogla automatski otkriti anomalne API aktivnosti i prijetnje u API infrastrukturama koje tradicionalne metode propuštaju.

Čak i u slučajevima kada su standardne sigurnosne mjere u stanju otkriti anomalije i rizike, otkrićima mogu potrajati mjeseci. Suprotno tome, pomoću unaprijed izgrađenih modela temeljenih na obrascima korisničkog pristupa, sigurnosni sloj upravljan umjetnom inteligencijom omogućio bi otkrivanje nekih napada u gotovo stvarnom vremenu.

Važno je da AI motori obično rade izvan API pristupnika i prenose im svoje odluke. Budući da API pristupnik ne mora trošiti resurse za obradu tih zahtjeva, dodavanje AI-sigurnosti obično ne utječe na performanse izvođenja.

Integriranje API-ja temeljenog na politikama i AI-a vođenog AI

Kada se u implementaciju upravljanja API-jem doda sigurnost koju pokreće AI, postojat će točka za provedbu sigurnosti i točka odluke. Tipično su ove jedinice neovisne zbog velike računske snage koja je potrebna, ali latencija ne bi smjela utjecati na njihovu učinkovitost.

API pristupnik presreće API zahtjeve i primjenjuje razne politike. S njom je povezana točka izvršenja sigurnosti, koja opisuje atribute svakog zahtjeva (API poziv) do točke odluke, zahtijeva sigurnosnu odluku, a zatim provodi tu odluku u pristupniku. Točka odluke, pokrenuta AI-om, kontinuirano uči ponašanje svakog uzorka pristupa API-ju, otkriva abnormalna ponašanja i označava različite atribute zahtjeva.

Trebala bi postojati mogućnost dodavanja pravila u točku odluke prema potrebi i pozivanje tih pravila - koja se mogu razlikovati od API-ja do API-a - tijekom razdoblja učenja. Sve politike treba definirati sigurnosni tim nakon što se temeljito shvate potencijalne ranjivosti svakog API-ja koji planiraju izložiti. Međutim, čak i bez podrške iz vanjskih politika, adaptivna tehnologija odlučivanja i točke provedbe koju pokreće AI na kraju će naučiti i spriječiti neke složene napade koje ne možemo otkriti pravilima.

Još jedna prednost posjedovanja dvije odvojene komponente sigurnosne točke i točke odlučivanja je sposobnost integracije s postojećim rješenjima za upravljanje API-jem. Jednostavno poboljšanje korisničkog sučelja i prilagođeno proširenje mogu integrirati točku izvršenja sigurnosti u API izdavača i pristupnik. Iz korisničkog sučelja izdavač API-ja mogao je odabrati hoće li omogućiti AI sigurnost za objavljeni API, zajedno sa svim potrebnim posebnim pravilima. Proširena točka izvršenja sigurnosti objavila bi atribute zahtjeva točki odluke i ograničila pristup API-ju u skladu s odgovorom točke odluke.

Međutim, objavljivanje događaja na točki odlučivanja i ograničavanje pristupa na temelju odgovora potrajat će i uvelike ovisiti o mreži. Stoga ga je najbolje implementirati asinkrono uz pomoć mehanizma za predmemoriranje. To će malo utjecati na točnost, ali kad se razmatra učinkovitost pristupnika, dodavanje sigurnosnog sloja AI minimalno će pridonijeti ukupnoj latenciji.

Izazovi sigurnosnog sloja vođeni umjetnom inteligencijom

Naravno, koristi ne dolaze bez troškova. Iako sigurnosni sloj vođen umjetnom inteligencijom nudi dodatnu razinu zaštite API-ja, on predstavlja neke izazove na koje će sigurnosni timovi morati odgovoriti.

  • Dodatni režijski troškovi . Dodatni AI sigurnosni sloj dodaje određeni dio protoka poruka. Dakle, rješenja za posredovanje trebala bi biti dovoljno pametna da se mogu baviti prikupljanjem i objavljivanjem informacija izvan glavnog tijeka posredovanja.
  • Lažni pozitivi . Veliki broj lažno pozitivnih rezultata zahtijevaće dodatni pregled sigurnosnih stručnjaka. Međutim, nekim naprednim algoritmima AI možemo smanjiti broj okidača lažno pozitivnih rezultata.
  • Nedostatak povjerenja . Ljudi se osjećaju nelagodno kad ne razumiju kako je donesena odluka. Nadzorne ploče i upozorenja mogu pomoći korisnicima da vizualiziraju čimbenike koji stoje iza odluke. Na primjer, ako upozorenje jasno kaže da je korisniku blokiran pristup sustavu nenormalnom brzinom od 1000 i više puta u minuti, ljudi mogu razumjeti i vjerovati odluci sustava.
  • Ranjivost podataka . Većina rješenja za umjetnu inteligenciju i za strojno učenje oslanjaju se na velike količine podataka, koji su često osjetljivi i osobni. Kao rezultat, ova rješenja mogu postati sklona kršenju podataka i krađi identiteta. Poštivanje GDPR-a Europske unije (Opća uredba o zaštiti podataka) pomaže ublažiti taj rizik, ali ga ne uklanja u potpunosti.
  • Označena ograničenja podataka . Najmoćniji AI sustavi obučavaju se pod nadzorom učenja, što zahtijeva označene podatke koji su organizirani kako bi ih strojevi učinili razumljivima. No, označeni podaci imaju ograničenja, a buduće automatizirano stvaranje sve težih algoritama samo će pogoršati problem.
  • Pogrešni podaci . Učinkovitost AI sustava ovisi o podacima na kojima je osposobljen. Prečesto su loši podaci povezani s etničkim, zajedničkim, rodnim ili rasnim pristranostima, što može utjecati na ključne odluke o pojedinačnim korisnicima.

S obzirom na kritičnu ulogu API-ja u poduzećima danas, oni sve više postaju meta hakera i zlonamjernih korisnika. Mehanizmi temeljeni na pravilima, kao što su provjera autentičnosti, autorizacija, skeniranje korisnog tereta, provjera valjanosti sheme, ograničavanje i ograničenje brzine, osnovni su zahtjevi za provedbu uspješne API sigurnosne strategije. Međutim, samo će dodavanjem AI modela za kontinuirani pregled i izvještavanje o svim aktivnostima API-ja poduzeća biti zaštićena od najsofisticiranijih sigurnosnih napada koji se danas pojavljuju.

Sanjeewa Malalgoda je softverski arhitekt i pridruženi direktor inženjeringa u WSO2, gdje vodi razvoj WSO2 API Managera. Lakshitha Gunasekara je softverski inženjer u timu WSO2 API Manager. 

-

New Tech Forum pruža mjesto za istraživanje i raspravu o novonastaloj tehnologiji poduzeća u neviđenoj dubini i širini. Izbor je subjektivan, zasnovan na našem odabiru tehnologija za koje vjerujemo da su važne i da najviše zanimaju čitatelje. ne prihvaća marketinške kolaterale za objavljivanje i zadržava pravo uređivanja cjelokupnog sadržaja. Pošaljite sve upite na  [email protected] .