API tapo organizacijų skaitmeninės transformacijos iniciatyvų brangenybėmis, suteikiančiomis darbuotojams, partneriams, klientams ir kitoms suinteresuotosioms šalims prieigą prie programų, duomenų ir verslo funkcijų visoje jų skaitmeninėje ekosistemoje. Taigi nenuostabu, kad įsilaužėliai padidino atakų bangas prieš šį svarbų įmonės turtą.
Deja, panašu, kad problema tik pablogės. „Gartner“ prognozavo, kad „Iki 2022 m. API piktnaudžiavimas bus dažniausias atakų vektorius, dėl kurio bus pažeidžiami įmonės žiniatinklio programų duomenys“.
Daugelis įmonių atsakė įdiegdamos API valdymo sprendimus, kurie teikia tokius mechanizmus kaip autentifikavimas, autorizavimas ir reguliavimas. Tai yra būtinos galimybės kontroliuoti, kas ir kaip dažnai naudojasi API visoje API ekosistemoje. Tačiau kurdamos savo vidines ir išorines API strategijas, organizacijos taip pat turi spręsti vis sudėtingesnių išpuolių prieš API augimą, įgyvendindamos dinaminio, dirbtinio intelekto (AI) saugumą.
Šiame straipsnyje nagrinėjami API valdymo ir saugos įrankiai, kuriuos organizacijos turėtų įtraukti, kad užtikrintų saugumą, vientisumą ir prieinamumą visose savo API ekosistemose.
Taisyklėmis ir politika pagrįstos saugumo priemonės
Taisyklėmis ir politika pagrįstos saugos patikros, kurias galima atlikti statiniu ar dinaminiu būdu, yra privalomos bet kurio API valdymo sprendimo dalys. API šliuzai yra pagrindinis prieigos prie API prieigos taškas, todėl jie paprastai vykdo politikos vykdymą tikrindami gaunamus prašymus pagal politiką ir taisykles, susijusias su saugumu, tarifų apribojimais, ribojimu ir pan. Pažvelkime atidžiau į kai kuriuos statinius ir dinaminius saugumo patikrinimus, kad pamatytume papildomus jų suteikiamą vertę.
Statinis saugumo patikrinimas
Statiniai saugos patikrinimai nepriklauso nuo užklausos apimties ar bet kokių ankstesnių užklausų duomenų, nes jie paprastai patvirtina pranešimo duomenis pagal iš anksto nustatytą taisyklių ar strategijų rinkinį. Šliuzuose atliekami skirtingi statinio saugumo nuskaitymai, siekiant užkirsti kelią SQL įpurškimui, darnioms analizavimo atakoms, objekto išplėtimo atakoms ir apsinuodijimams schemomis.
Tuo tarpu statiniai politikos patikrinimai gali būti taikomi, be kita ko, naudingosios apkrovos nuskaitymui, antraštės tikrinimui ir prieigos šablonams. Pavyzdžiui, SQL įpurškimas yra dažnas atakų tipas, atliekamas naudojant naudingąsias apkrovas. Jei vartotojas siunčia JSON („JavaScript Object Notation“) naudingąją apkrovą, API šliuzas gali patvirtinti šią konkrečią užklausą pagal iš anksto nustatytą JSON schemą. Vartai taip pat gali apriboti elementų ar kitų turinio atributų skaičių, jei to reikia norint apsaugoti nuo žalingų pranešimų duomenų ar teksto šablonų.
Dinaminiai saugumo patikrinimai
Dinaminiai saugumo patikrinimai, priešingai nei statiniai saugos patikrinimai, visada tikrinami pagal tai, kas laikui bėgant skiriasi. Paprastai tai apima užklausos duomenų patvirtinimą priimant sprendimus naudojant esamus duomenis. Dinaminių patikrinimų pavyzdžiai yra prieigos žetonų patvirtinimas, anomalijų aptikimas ir droselio nustatymas. Šie dinaminiai patikrinimai labai priklauso nuo duomenų srauto, siunčiamo į šliuzą. Kartais šie dinaminiai patikrinimai atliekami už API šliuzo ribų, tada sprendimai perduodami šliuzui. Pažvelkime į porą pavyzdžių.
Dujos ir dažnio ribojimas yra svarbūs siekiant sumažinti atakų poveikį, nes kai tik užpuolikai gauna prieigą prie API, pirmiausia jie perskaito kuo daugiau duomenų. Taikant API užklausas, t. Y. Ribojant prieigą prie duomenų, reikalaujama, kad gautų užklausų skaičių nustatytume per tam tikrą laiką. Jei užklausų skaičius tuo metu viršija skirtą sumą, šliuzas gali blokuoti API skambučius. Ribodami tarifą, galime apriboti tuo pačiu metu leidžiamą prieigą prie tam tikros paslaugos.
Autentifikavimas
Autentifikavimas padeda API šliuzams identifikuoti kiekvieną vartotoją, kuris unikaliai naudoja API. Galimi API šliuzo sprendimai paprastai palaiko pagrindinį autentifikavimą, OAuth 2.0, JWT (JSON žiniatinklio žetonų) saugumą ir sertifikatu pagrįstą saugumą. Kai kurie šliuzai taip pat pateikia autentifikavimo sluoksnį, kad būtų galima atlikti papildomą tikslių leidimų patvirtinimą, kuris paprastai grindžiamas XACML (eXtensible Access Control Markup Language) stiliaus strategijos apibrėžimo kalbomis. Tai svarbu, kai API yra keli ištekliai, kuriems reikia skirtingo lygio prieigos valdymo kiekvienam ištekliui.
Tradicinio API saugumo apribojimai
Politikos principai, susiję su autentifikavimu, autorizavimu, tarifų ribojimu ir ribojimu, yra veiksmingos priemonės, tačiau jie vis tiek palieka įtrūkimus, kuriuos įsilaužėliai gali naudoti API. Pažymėtina, kad API šliuzai teikia kelias žiniatinklio paslaugas, o jų valdomose API dažnai būna daugybė seansų. Net jei analizuotume visus tuos seansus naudodamiesi politika ir procesais, vartams būtų sunku patikrinti kiekvieną užklausą be papildomos skaičiavimo galios.
Be to, kiekviena API turi savo prieigos modelį. Taigi teisėtas vienos API prieigos modelis gali reikšti kenkėjišką veiklą kitai API. Pavyzdžiui, kai kas nors perka prekes naudodamasis apsipirkimo internetu programa, prieš pirkdamas atliks kelias paieškas. Taigi, vienas vartotojas, per trumpą laiką išsiųsdamas 10–20 užklausų paieškos API, gali būti teisėtas paieškos API prieigos modelis. Tačiau jei tas pats vartotojas siunčia kelias užklausas pirkimo API, prieigos modelis gali rodyti kenkėjišką veiklą, pavyzdžiui, įsilaužėlis bando kuo daugiau atsiimti naudodamas pavogtą kreditinę kortelę. Todėl norint nustatyti teisingą atsakymą, kiekvieną API prieigos modelį reikia analizuoti atskirai.
Dar vienas veiksnys yra tas, kad didelis skaičius išpuolių įvyksta viduje. Čia vartotojai, turintys galiojančius kredencialus ir prieigą prie sistemų, naudojasi savo galimybėmis atakuoti tas sistemas. Politika pagrįstos tapatybės nustatymo ir prieigos teisės nėra skirtos užkirsti kelią tokio tipo atakoms.
Net jei mes galėtume taikyti daugiau taisyklių ir strategijų API šliuzams, kad apsaugotume nuo čia aprašytų atakų, papildomos API šliuzo pridėtinės išlaidos būtų nepriimtinos. Įmonės negali sau leisti nusivilti tikriems vartotojams, prašydamos jų atsiskaityti su savo API šliuzais. Vietoj to, šliuzai turi apdoroti galiojančias užklausas, neužblokuodami ar lėtindami vartotojo API skambučius.
Dirbtinio intelekto apsaugos sluoksnio pridėjimo atvejis
Norėdami užpildyti trūkumus, kuriuos paliko politika pagrįstos API apsaugos, šiuolaikinėms saugos komandoms reikalingas dirbtiniu intelektu pagrįstas API saugumas, kuris galėtų aptikti dinamines atakas ir į jas reaguoti bei unikalius kiekvienos API pažeidžiamumus. Taikydamos AI modelius nuolatos tikrindamos visą API veiklą ir teikdamos ataskaitas apie ją, įmonės galėtų automatiškai atrasti nenormalų API veiklą ir grėsmes visose API infrastruktūrose, kurių tradiciniai metodai praleidžia.
Net tais atvejais, kai standartinėmis saugumo priemonėmis galima nustatyti anomalijas ir riziką, atradimams gali prireikti mėnesių. Priešingai, naudojant iš anksto sukurtus modelius, pagrįstus vartotojų prieigos modeliais, dirbtiniu intelektu pagrįstas saugumo sluoksnis leistų aptikti kai kurias atakas beveik realiu laiku.
Svarbu tai, kad dirbtinio intelekto varikliai paprastai veikia už API šliuzų ribų ir jiems praneša apie savo sprendimus. Kadangi API šliuzas neprivalo išleisti išteklių, kad apdorotų šias užklausas, AI saugos pridėjimas paprastai neturi įtakos vykdymo laiko našumui.
Integruoti politika pagrįstą ir dirbtiniu intelektu pagrįstą API saugumą
Pridedant AI valdomą saugą prie API valdymo diegimo, bus saugos užtikrinimo punktas ir sprendimo punktas. Paprastai šie vienetai yra nepriklausomi dėl didelės reikalingos skaičiavimo galios, tačiau nereikėtų leisti, kad delsimas turėtų įtakos jų efektyvumui.
API šliuzas perima API užklausas ir taiko įvairias strategijas. Su juo susietas saugos vykdymo punktas, apibūdinantis kiekvienos užklausos (API iškvietimo) atributus prie sprendimo taško, prašantis priimti sprendimą dėl saugumo ir vykdantis tą sprendimą vartuose. Dirbtinio intelekto valdomas sprendimo taškas nuolat mokosi kiekvieno API prieigos modelio elgesio, aptinka nenormalų elgesį ir pažymi skirtingus užklausos atributus.
Turėtų būti galimybė pridėti politiką prie sprendimo taško, jei reikia, ir mokymosi laikotarpiu pasinaudoti šia politika, kuri gali skirtis nuo API. Bet kokia politika turėtų būti apibrėžta saugos komandos, kai bus išsamiai suprastos kiekvienos API, kurią jos ketina pateikti, pažeidžiamumai. Tačiau net ir be išorės politikos paramos adaptyvūs, dirbtiniu intelektu pagrįsti sprendimų priėmimo ir vykdymo taškų technologijos ilgainiui išmoks ir užkirs kelią kai kurioms sudėtingoms atakoms, kurių negalime aptikti taikydami politiką.
Kitas dviejų atskirų saugumo užtikrinimo ir sprendimo taškų komponentų privalumas yra galimybė integruotis su esamais API valdymo sprendimais. Paprastas vartotojo sąsajos patobulinimas ir pritaikytas plėtinys gali integruoti saugos užtikrinimo tašką į API leidėją ir šliuzą. Iš vartotojo sąsajos API leidėjas galėjo pasirinkti, ar įgalinti dirbtinio intelekto saugą paskelbtai API kartu su bet kokia reikalinga specialia politika. Išplėstinis saugumo užtikrinimo punktas paskelbtų užklausos atributus prie sprendimo taško ir apribotų prieigą prie API pagal sprendimo taško atsakymą.
Tačiau įvykių paskelbimas sprendimo punkte ir prieigos apribojimas atsižvelgiant į jo atsakymą užtruks ir priklausys nuo tinklo. Todėl jis geriausiai įgyvendinamas asinchroniškai naudojant talpyklos mechanizmą. Tai šiek tiek paveiks tikslumą, tačiau, atsižvelgiant į šliuzo efektyvumą, pridėjus PG saugos sluoksnį, minimaliai prisidedama prie bendros vėlavimo.
Dirbtiniu intelektu grindžiami iššūkiai
Žinoma, nauda neatsiranda be išlaidų. Nors dirbtiniu intelektu pagrįstas saugumo sluoksnis suteikia papildomą API apsaugos lygį, jis kelia keletą iššūkių, kuriuos saugos komandos turės išspręsti.
- Papildomos pridėtinės išlaidos. Papildomas dirbtinio intelekto apsaugos sluoksnis prideda šiek tiek pridėtinių pranešimų srauto. Taigi tarpininkavimo sprendimai turėtų būti pakankamai protingi, kad būtų galima rinkti ir skelbti informaciją už pagrindinio tarpininkavimo srauto ribų.
- Klaidingi teigiami rezultatai. Dideliam kiekiui klaidingų teigiamų duomenų reikės papildomų saugumo specialistų peržiūrų. Tačiau su kai kuriais pažangiais AI algoritmais galime sumažinti sukeltų klaidingų teigiamų rezultatų skaičių.
- Trūksta pasitikėjimo. Žmonės jaučiasi nejaukiai, kai nesupranta, kaip buvo priimtas sprendimas. Informacijos suvestinės ir įspėjimai gali padėti vartotojams įsivaizduoti veiksnius, lemiančius sprendimą. Pavyzdžiui, jei perspėjime aiškiai nurodoma, kad vartotojas buvo užblokuotas už prieigą prie sistemos neįprastu greičiu - 1 000 ir daugiau kartų per minutę, žmonės gali suprasti ir pasitikėti sistemos sprendimu.
- Duomenų pažeidžiamumas. Dauguma dirbtinio intelekto ir mašininio mokymosi sprendimų remiasi didžiuliu duomenų kiekiu, kuris dažnai yra jautrus ir asmeniškas. Todėl šie sprendimai gali būti linkę į duomenų pažeidimus ir tapatybės vagystes. Atitikimas Europos Sąjungos GDPR (Bendrasis duomenų apsaugos reglamentas) padeda sušvelninti šią riziką, tačiau jos visiškai nepanaikina.
- Pažymėtų duomenų apribojimai. Galingiausios dirbtinio intelekto sistemos yra mokomos prižiūrint mokymąsi, o tam reikalingi paženklinti duomenys, kurie yra sutvarkyti, kad mašinos juos suprastų. Tačiau pažymėti duomenys turi ribas, o ateityje automatizuotas vis sunkesnių algoritmų kūrimas tik sustiprins problemą.
- Netinkami duomenys. PG sistemos efektyvumas priklauso nuo duomenų, kuriais ji apmokoma. Labai dažnai blogi duomenys siejami su etniniu, bendruomeniniu, lyties ar rasiniu šališkumu, o tai gali turėti įtakos esminiams sprendimams dėl atskirų vartotojų.
Atsižvelgiant į svarbų API vaidmenį įmonėse šiandien, jie vis dažniau tampa įsilaužėlių ir kenksmingų vartotojų taikiniais. Politikos principais pagrįsti mechanizmai, tokie kaip autentifikavimas, autorizavimas, naudingosios apkrovos nuskaitymas, schemos patvirtinimas, ribojimas ir spartos ribojimas, yra pagrindiniai sėkmingos API saugos strategijos įgyvendinimo reikalavimai. Tačiau tik pridėjus PG modelius, kad būtų galima nuolat tikrinti ir pranešti apie visą API veiklą, įmonės bus apsaugotos nuo pačių sudėtingiausių šiandien atakų.
Sanjeewa Malalgoda yra programinės įrangos architektas ir asocijuotas inžinerijos direktorius WSO2, kur jis vadovauja WSO2 API vadybininko plėtrai. Lakshitha Gunasekara yra programinės įrangos inžinierė iš WSO2 API Manager komandos.
—
Naujųjų technologijų forumas suteikia galimybę tyrinėti ir aptarti besiformuojančios įmonės technologijas beprecedentiame gylyje. Atranka yra subjektyvi, atsižvelgiant į mūsų pasirinktas technologijas, kurios, mūsų manymu, yra svarbios ir labiausiai domina skaitytojus. nepriima rinkodaros užtikrinimo priemonės paskelbimui ir pasilieka teisę redaguoti visą pateiktą turinį. Visus klausimus siųskite adresu[email protected].
