API-ji so postali krona draguljev pobud za digitalno preobrazbo organizacij, s čimer so zaposlenim, partnerjem, kupcem in drugim zainteresiranim stranem omogočili dostop do aplikacij, podatkov in poslovnih funkcij v celotnem digitalnem ekosistemu. Zato ni čudno, da so hekerji povečali valove napadov na to kritično premoženje podjetja.
Žal se zdi, da se bo težava samo poslabšala. Gartner je napovedal, da bodo "do leta 2022 zlorabe API najpogostejši vektor napadov, kar bo povzročilo kršitve podatkov za spletne aplikacije podjetja."
Številna podjetja so se odzvala z uporabo rešitev za upravljanje API-jev, ki zagotavljajo mehanizme, kot so preverjanje pristnosti, avtorizacija in dušenje. To so obvezne zmogljivosti za nadzor, kdo dostopa do API-jev v ekosistemu API-ja in kako pogosto. Vendar pa se morajo organizacije pri gradnji svojih notranjih in zunanjih strategij API lotevati tudi rasti bolj dovršenih napadov na API-je z uporabo dinamične varnosti, ki jo poganja umetna inteligenca.
Ta članek preučuje orodja za upravljanje API in varnostna orodja, ki jih morajo organizacije vključiti za zagotovitev varnosti, celovitosti in razpoložljivosti v svojih ekosistemih API.
Varnostni ukrepi, ki temeljijo na pravilih in temeljijo na politiki
Varnostna preverjanja, ki temeljijo na pravilih in temeljijo na politikah, ki jih je mogoče izvajati na statičen ali dinamičen način, so obvezni deli katere koli rešitve za upravljanje API. Prehodi API služijo kot glavna vstopna točka za dostop do API-ja in zato običajno izvajajo uveljavljanje pravilnikov tako, da pregledujejo dohodne zahteve glede pravilnikov in pravil, povezanih z varnostjo, omejitvami hitrosti, dušenjem itd. vrednost, ki jo prinašajo.
Statični varnostni pregledi
Statična varnostna preverjanja niso odvisna od obsega zahteve ali kakršnih koli prejšnjih podatkov zahteve, saj običajno potrjujejo podatke sporočil glede na vnaprej določen nabor pravil ali pravilnikov. V prehodih se med drugim izvajajo različni statični varnostni pregledi, ki med drugim blokirajo vbrizgavanje SQL, napade kohezivnega razčlenjevanja, napade razširitve entitet in zastrupitve shem.
Medtem se lahko statična preverjanja pravilnikov med drugim uporabljajo za skeniranje koristnega tovora, pregledovanje glave in vzorce dostopa. Na primer, vbrizgavanje SQL je pogosta vrsta napada, ki se izvaja s koristnimi obremenitvami. Če uporabnik pošlje koristno obremenitev JSON (JavaScript Object Notation), lahko prehod API potrdi to posebno zahtevo glede na vnaprej določeno shemo JSON. Prehod lahko tudi omeji število elementov ali drugih atributov v vsebini, kot je potrebno za zaščito pred škodljivimi podatki ali vzorci besedila v sporočilih.
Dinamični varnostni pregledi
Dinamični varnostni pregledi v nasprotju s statičnimi varnostnimi pregledi vedno preverjajo, kaj se s časom spreminja. Običajno to vključuje potrjevanje podatkov zahtevka z odločitvami, sprejetimi z uporabo obstoječih podatkov. Primeri dinamičnih preverjanj vključujejo preverjanje veljavnosti žetonov dostopa, odkrivanje nepravilnosti in dušenje. Ta dinamična preverjanja so močno odvisna od količine podatkov, ki se pošlje na prehod. Včasih se ta dinamična preverjanja zgodijo zunaj prehoda API, nato pa se odločitve sporočijo prehodu. Oglejmo si nekaj primerov.
Omejevanje in omejevanje hitrosti sta pomembna za zmanjšanje učinka napadov, saj kadar koli napadalci dobijo dostop do API-jev, najprej preberejo čim več podatkov. Omejevanje zahtev za API - tj. Omejevanje dostopa do podatkov - zahteva, da v določenem časovnem obdobju hranimo število dohodnih zahtev. Če število zahtevkov takrat preseže dodeljeni znesek, lahko prehod blokira klice API. Z omejevanjem hitrosti lahko omejimo sočasni dostop, dovoljen za določeno storitev.
Preverjanje pristnosti
Preverjanje pristnosti pomaga prehodom API, da prepoznajo vsakega uporabnika, ki enolično prikliče API. Razpoložljive rešitve prehodov API na splošno podpirajo osnovno preverjanje pristnosti, varnost OAuth 2.0, JWT (JSON Web Token) in varnost na podlagi potrdil. Nekateri prehodi poleg tega nudijo še avtentikacijski sloj za dodatno natančno preverjanje veljavnosti dovoljenj, ki običajno temelji na jezikih za določanje pravil sloga XACML (eXtensible Access Control Markup Language). To je pomembno, če API vsebuje več virov, ki potrebujejo različne ravni nadzora dostopa za vsak vir.
Omejitve tradicionalne varnosti API
Politični pristopi k preverjanju pristnosti, avtorizaciji, omejevanju hitrosti in omejevanju hitrosti so učinkovita orodja, vendar še vedno puščajo razpoke, skozi katere lahko hekerji izkoristijo API-je. Predvsem API prehodi pred več spletnimi storitvami in API-ji, ki jih upravljajo, so pogosto naloženi z velikim številom sej. Tudi če bi analizirali vse te seje z uporabo pravilnikov in procesov, bi prehod težko pregledal vsako zahtevo brez dodatne računske moči.
Poleg tega ima vsak API svoj vzorec dostopa. Upravičen vzorec dostopa za en API lahko nakazuje zlonamerno dejavnost za drug API. Na primer, ko nekdo kupi izdelke prek aplikacije za spletno nakupovanje, bo pred nakupom opravil več iskanj. En uporabnik, ki v kratkem času pošlje 10 do 20 zahtev iskalnemu API-ju, je lahko legitimen vzorec dostopa za iskalni API. Če pa isti uporabnik pošlje več zahtev v API za nakup, lahko vzorec dostopa kaže na zlonamerno dejavnost, na primer heker, ki poskuša dvigniti čim več z ukradeno kreditno kartico. Zato je treba vsak vzorec dostopa do API analizirati ločeno, da se določi pravi odziv.
Še en dejavnik je ta, da se veliko število napadov zgodi znotraj. Tu uporabniki z veljavnimi poverilnicami in dostopom do sistemov izkoristijo svojo sposobnost napada na te sisteme. Zmogljivosti preverjanja pristnosti in avtorizacije na podlagi pravil niso namenjene preprečevanju tovrstnih napadov.
Tudi če bi lahko uporabili več pravil in pravilnikov za prehod API za zaščito pred tukaj opisanimi napadi, bi bili dodatni režijski stroški na prehodu API nesprejemljivi. Podjetja si ne morejo privoščiti, da bi frustrirala resnične uporabnike, tako da jih prosijo, naj nosijo zamude pri obdelavi svojih prehodov API. Namesto tega morajo prehodi obdelati veljavne zahteve, ne da bi blokirali ali upočasnili klice uporabniškega API-ja.
Primer za dodajanje varnostne plasti AI
Za zapolnitev razpok, ki jih puščajo zaščite API-jev, ki temeljijo na politikah, potrebujejo sodobne varnostne ekipe varnost na osnovi umetne inteligence, ki lahko zazna in se odzove na dinamične napade in edinstvene ranljivosti vsakega API-ja. Z uporabo modelov umetne inteligence za nenehno pregledovanje in poročanje o vseh dejavnostih API-ja lahko podjetja samodejno odkrijejo nepravilne dejavnosti API-jev in grožnje v API-infrastrukturah, ki jih tradicionalne metode pogrešajo.
Tudi v primerih, ko lahko standardni varnostni ukrepi odkrijejo nepravilnosti in tveganja, lahko odkritja trajajo mesece. Nasprotno pa bi z uporabo vnaprej izdelanih modelov, ki temeljijo na vzorcih uporabniškega dostopa, varnostna plast, ki jo poganja AI, omogočila zaznavanje nekaterih napadov v skoraj realnem času.
Pomembno je, da se mehanizmi AI običajno izvajajo zunaj prehodov API in jim sporočajo svoje odločitve. Ker prehodu API ni treba porabiti sredstev za obdelavo teh zahtev, dodajanje zaščite pred umetno inteligenco običajno ne vpliva na zmogljivost izvajanja.
Vključitev varnosti API-jev na podlagi politik in AI
Pri dodajanju varnosti, ki jo poganja AI, k izvedbi upravljanja API-ja, bosta na voljo točka za uveljavitev varnosti in točka odločitve. Običajno so te enote neodvisne zaradi velike računske moči, vendar ne sme dopustiti, da zakasnitev vpliva na njihovo učinkovitost.
Prehod API prestreže zahteve API in uporablja različne pravilnike. Z njo je povezana točka izvrševanja varnosti, ki opisuje atribute vsake zahteve (klic API) do točke odločitve, zahteva odločitev o varnosti in nato to odločitev uveljavi v prehodu. Odločitvena točka, ki jo poganja AI, se nenehno uči vedenja vsakega vzorca dostopa do API-ja, zazna nenavadna vedenja in označi različne atribute zahteve.
Morala bi biti možnost, da po potrebi dodate pravilnike na odločitveno točko in te tečaje - ki se lahko razlikujejo od API-ja do API-ja prikličete v obdobju učenja. Vse politike mora opredeliti varnostna skupina, ko bodo temeljito razumljene potencialne ranljivosti vsakega API-ja, ki ga nameravajo izpostaviti. Toda tudi brez podpore zunanjih politik se bo prilagodljiva tehnologija odločanja in izvršilnih točk, ki jo poganja umetna inteligenca, sčasoma naučila in preprečila nekatere zapletene napade, ki jih s politikami ne moremo zaznati.
Druga prednost obstoja dveh ločenih komponent varnostne točke in točke odločitve je zmožnost integracije z obstoječimi rešitvami za upravljanje API-jev. Preprosta izboljšava uporabniškega vmesnika in prilagojena razširitev bi lahko integrirala točko izvrševanja varnosti v založnik API in prehod. Iz uporabniškega vmesnika lahko založnik API izbere, ali naj omogoči varnost AI za objavljeni API, skupaj s posebnimi pravilniki, ki so potrebni. Razširjena točka izvrševanja varnosti bi objavila atribute zahteve na odločitveni točki in omejila dostop do API-ja v skladu z odzivom odločitvene točke.
Objavljanje dogodkov na odločitveni točki in omejitev dostopa na podlagi njegovega odziva bo trajalo nekaj časa in bo močno odvisno od omrežja. Zato ga je najbolje izvajati asinhrono s pomočjo mehanizma za predpomnjenje. To bo nekoliko vplivalo na natančnost, toda če upoštevamo učinkovitost prehoda, bo dodajanje varnostne plasti AI minimalno prispevalo k splošni zakasnitvi.
Izzivi varnostne plasti, ki temeljijo na umetni inteligenci
Koristi seveda ne pridejo brez stroškov. Medtem ko varnostni sloj, ki ga poganja AI, ponuja dodatno raven zaščite API, predstavlja nekaj izzivov, ki jih bodo morale rešiti varnostne ekipe.
- Dodatni režijski stroški. Dodatna zaščitna plast AI dodaja nekaj dodatnih stroškov toku sporočil. Torej, rešitve mediacije bi morale biti dovolj pametne, da lahko zbirajo in objavljajo informacije zunaj glavnega postopka mediacije.
- Lažno pozitivni. Veliko število lažno pozitivnih rezultatov bo zahtevalo dodatni pregled varnostnih strokovnjakov. Vendar lahko z nekaterimi naprednimi algoritmi AI zmanjšamo število sproženih lažno pozitivnih rezultatov.
- Pomanjkanje zaupanja. Ljudje se počutijo neprijetno, ko ne razumejo, kako je bila sprejeta odločitev. Nadzorne plošče in opozorila lahko uporabnikom pomagajo vizualizirati dejavnike odločitve. Če na primer opozorilo jasno navaja, da je bil uporabnik blokiran zaradi dostopa do sistema s neobičajno hitrostjo 1000 in večkrat v minuti, lahko ljudje razumejo odločitev sistema in ji zaupajo.
- Podatkovna ranljivost. Večina rešitev za umetno inteligenco in strojno učenje se zanaša na velike količine podatkov, ki so pogosto občutljivi in osebni. Posledično bi te rešitve lahko postale nagnjene k kršitvam podatkov in kraji identitete. Skladnost z GDPR Evropske unije (Splošna uredba o varstvu podatkov) pomaga ublažiti to tveganje, vendar ga ne odpravi v celoti.
- Označene omejitve podatkov. Najmočnejši sistemi umetne inteligence so usposobljeni z nadzorovanim učenjem, ki zahteva označene podatke, ki so organizirani tako, da jih stroji razumejo. Toda označeni podatki imajo omejitve in prihodnje avtomatizirano ustvarjanje vedno težjih algoritmov bo problem le še poslabšalo.
- Napačni podatki. Učinkovitost sistema umetne inteligence je odvisna od podatkov, na katerih je usposobljen. Slabi podatki so prepogosto povezani z etničnimi, skupnostnimi, spolnimi ali rasnimi pristranskostmi, kar lahko vpliva na ključne odločitve o posameznih uporabnikih.
Glede na današnjo ključno vlogo API-jev v podjetjih postajajo vedno bolj tarča hekerjev in zlonamernih uporabnikov. Mehanizmi, ki temeljijo na politikah, kot so preverjanje pristnosti, avtorizacija, skeniranje koristnega tovora, preverjanje veljavnosti sheme, dušenje in omejevanje hitrosti, so osnovne zahteve za izvajanje uspešne varnostne strategije API. Vendar pa bodo podjetja z dodajanjem modelov AI za nenehno pregledovanje in poročanje o vseh aktivnostih API zaščitena pred najsodobnejšimi varnostnimi napadi, ki se pojavljajo danes.
Sanjeewa Malalgoda je arhitekt programske opreme in pridruženi direktor inženiringa pri WSO2, kjer vodi razvoj WSO2 API Manager. Lakshitha Gunasekara je programski inženir v skupini WSO2 API Manager.
—
Forum New Tech ponuja prizorišče za raziskovanje in razpravo o nastajajoči podjetniški tehnologiji v globini in širini brez primere. Izbor je subjektiven in temelji na našem izboru tehnologij, za katere menimo, da so pomembne in najbolj zanimajo bralce. ne sprejema tržnih zavarovanj za objavo in si pridržuje pravico do urejanja celotne prispevane vsebine. Vsa vprašanja pošljite na[email protected].
