Programmēšana

Kā AI uzlabos API drošību

API ir kļuvuši par organizāciju digitālās pārveidošanas iniciatīvu dārgakmeņiem, dodot darbiniekiem, partneriem, klientiem un citām ieinteresētajām personām piekļuvi lietojumprogrammām, datiem un biznesa funkcionalitātei visā viņu digitālajā ekosistēmā. Tāpēc nav brīnums, ka hakeri ir palielinājuši uzbrukumu viļņus pret šiem kritiskajiem uzņēmuma aktīviem.

Diemžēl izskatās, ka problēma tikai pasliktināsies. Gartners ir paredzējis, ka "Līdz 2022. gadam API ļaunprātīga izmantošana būs visizplatītākais uzbrukuma vektors, kā rezultātā tiks pārkāpti uzņēmuma tīmekļa lietojumprogrammu dati."

Daudzi uzņēmumi ir reaģējuši, ieviešot API pārvaldības risinājumus, kas nodrošina tādus mehānismus kā autentifikācija, autorizācija un ierobežošana. Šīs ir obligātas iespējas kontrolēt, kurš piekļūst API visā API ekosistēmā un cik bieži. Tomēr, veidojot savas iekšējās un ārējās API stratēģijas, organizācijām ir jārisina arī sarežģītāku API uzbrukumu pieaugums, ieviešot dinamisku, mākslīgā intelekta (AI) vadītu drošību.

Šajā rakstā ir apskatīti API pārvaldības un drošības rīki, kas organizācijām jāiekļauj, lai nodrošinātu drošību, integritāti un pieejamību visās viņu API ekosistēmās.

Uz noteikumiem un politikā balstīti drošības pasākumi

Uz noteikumiem un politikām balstītas drošības pārbaudes, kuras var veikt statiskā vai dinamiskā veidā, ir obligātas jebkura API pārvaldības risinājuma daļas. API vārtejas kalpo kā galvenais piekļuves punkts piekļuvei API, un tāpēc parasti rīkojas ar politikas ieviešanu, pārbaudot ienākošos pieprasījumus atbilstoši politikām un noteikumiem, kas saistīti ar drošību, tarifu ierobežojumiem, ierobežošanu utt. Apskatīsim tuvāk dažas statiskās un dinamiskās drošības pārbaudes, lai redzētu papildu vērtību, ko tie nes.

Statiskās drošības pārbaudes

Statiskās drošības pārbaudes nav atkarīgas no pieprasījuma apjoma vai jebkādiem iepriekšējiem pieprasījumu datiem, jo ​​parasti ziņu dati tiek apstiprināti, izmantojot iepriekš noteiktu kārtulu vai politiku kopu. Vārtejās tiek veikti dažādi statiski drošības skenējumi, lai cita starpā bloķētu SQL ievadīšanu, saliedētus parsēšanas uzbrukumus, entītijas paplašināšanas uzbrukumus un saindēšanos ar shēmu.

Tikmēr statiskās politikas pārbaudes var piemērot, cita starpā, kravas skenēšanai, galvenes pārbaudei un piekļuves modeļiem. Piemēram, SQL injekcija ir izplatīts uzbrukuma veids, kas tiek veikts, izmantojot lietderīgās kravas. Ja lietotājs nosūta JSON (JavaScript Object Notation) lietderīgo slodzi, API vārteja var pārbaudīt šo konkrēto pieprasījumu, izmantojot iepriekš noteiktu JSON shēmu. Vārteja var arī ierobežot satura elementu vai citu atribūtu skaitu, kā nepieciešams, lai pasargātu no kaitīgiem datiem vai teksta modeļiem ziņojumos.

Dinamiskas drošības pārbaudes

Dinamiskās drošības pārbaudes, atšķirībā no statiskās drošības skenēšanas, vienmēr tiek pārbaudītas pret kaut ko, kas laika gaitā mainās. Parasti tas ietver pieprasījuma datu apstiprināšanu ar lēmumiem, kas pieņemti, izmantojot esošos datus. Dinamisko pārbaužu piemēri ietver piekļuves marķiera validāciju, anomāliju noteikšanu un droselēšanu. Šīs dinamiskās pārbaudes ir ļoti atkarīgas no datu apjoma, kas tiek sūtīts uz vārteju. Dažreiz šīs dinamiskās pārbaudes notiek ārpus API vārtejas, un pēc tam lēmumi tiek paziņoti vārtejai. Apskatīsim pāris piemērus.

Droselēšana un ātruma ierobežošana ir svarīga, lai samazinātu uzbrukumu ietekmi, jo ikreiz, kad uzbrucēji iegūst piekļuvi API, vispirms viņi nolasa pēc iespējas vairāk datu. API pieprasījumu ierobežošana - t.i., piekļuves ierobežošana datiem - prasa, lai mēs noteiktu laiku reģistrētu ienākošo pieprasījumu skaitu. Ja pieprasījumu skaits tajā laikā pārsniedz piešķirto summu, vārteja var bloķēt API izsaukumus. Ar ātruma ierobežošanu mēs varam ierobežot vienlaicīgu piekļuvi, kas atļauta konkrētam pakalpojumam.

Autentifikācija

Autentifikācija palīdz API vārtejām identificēt katru lietotāju, kurš unikāli izsauc API. Pieejamie API vārtejas risinājumi parasti atbalsta pamata autentifikāciju, OAuth 2.0, JWT (JSON Web Token) drošību un uz sertifikātiem balstītu drošību. Dažas vārteja nodrošina autentifikācijas slāni papildus tam, lai veiktu papildu detalizētu atļauju validāciju, kas parasti balstās uz XACML (eXtensible Access Control Markup Language) stila politikas definēšanas valodām. Tas ir svarīgi, ja API satur vairākus resursus, kuriem katram resursam nepieciešama atšķirīga piekļuves kontrole.

Tradicionālās API drošības ierobežojumi

Uz politiku balstītas pieejas autentifikācijai, autorizācijai, ātruma ierobežošanai un ierobežošanai ir efektīvi instrumenti, taču tie joprojām atstāj plaisas, caur kurām hakeri var izmantot API. Konkrēti, API vārtejas nodrošina vairākus tīmekļa pakalpojumus, un viņu pārvaldītās API bieži tiek ielādētas ar lielu sesiju skaitu. Pat ja mēs analizētu visas šīs sesijas, izmantojot politikas un procesus, vārtejai būtu grūti pārbaudīt katru pieprasījumu bez papildu aprēķina jaudas.

Katrai API ir savs piekļuves modelis. Tātad vienas API likumīgs piekļuves modelis varētu norādīt uz ļaunprātīgu darbību citai API. Piemēram, kad kāds pērk preces, izmantojot tiešsaistes iepirkšanās programmu, viņš pirms pirkuma veikšanas veiks vairākus meklējumus. Tātad viens lietotājs īsā laika posmā meklēšanas API nosūta 10 līdz 20 pieprasījumus, un tas var būt likumīgs piekļuves modelis meklēšanas API. Tomēr, ja viens un tas pats lietotājs nosūta vairākus pieprasījumus pirkšanas API, piekļuves modelis varētu norādīt uz ļaunprātīgām darbībām, piemēram, hakeris mēģina pēc iespējas vairāk izņemt naudu, izmantojot nozagtu kredītkarti. Tādēļ katrs API piekļuves modelis ir jāanalizē atsevišķi, lai noteiktu pareizo atbildi.

Vēl viens faktors ir tas, ka ievērojams skaits uzbrukumu notiek iekšēji. Šeit lietotāji ar derīgiem akreditācijas datiem un piekļuvi sistēmām izmanto savas iespējas uzbrukt šīm sistēmām. Uz politiku balstītas autentifikācijas un autorizācijas iespējas nav paredzētas, lai novērstu šāda veida uzbrukumus.

Pat ja mēs varētu piemērot vairāk noteikumu un politikas API vārtejai, lai aizsargātu pret šeit aprakstītajiem uzbrukumiem, papildu vārti API vārtejā būtu nepieņemami. Uzņēmumi nevar atļauties nomākt patiesos lietotājus, lūdzot viņus izturēties pret viņu API vārteju apstrādes kavējumiem. Tā vietā vārtejām ir jāapstrādā derīgi pieprasījumi, nebloķējot vai palēninot lietotāja API zvanus.

AI drošības slāņa pievienošanas gadījums

Lai aizpildītu plaisas, kuras atstāj uz politiku balstītas API aizsardzības, mūsdienu drošības komandām nepieciešama uz mākslīgā intelekta balstīta API drošība, kas var atklāt dinamiskus uzbrukumus un katras API unikālās vājās vietas un reaģēt uz tiem. Izmantojot AI modeļus, lai nepārtraukti pārbaudītu un ziņotu par visām API darbībām, uzņēmumi varētu automātiski atklāt anomālas API darbības un draudus visā API infrastruktūrā, kuru tradicionālās metodes pietrūkst.

Pat gadījumos, kad standarta drošības pasākumi spēj atklāt anomālijas un riskus, atklājumu veikšana var ilgt mēnešus. Turpretī, izmantojot iepriekš izveidotus modeļus, kuru pamatā ir lietotāju piekļuves modeļi, ar mākslīgo intelektu balstīts drošības slānis ļautu dažus uzbrukumus atklāt gandrīz reālā laikā.

Svarīgi, ka AI dzinēji parasti darbojas ārpus API vārtejām un paziņo viņiem savus lēmumus. Tā kā API vārtejai nav jāiztērē resursi, lai apstrādātu šos pieprasījumus, AI drošības pievienošana parasti neietekmē izpildlaika veiktspēju.

Integrēta uz politiku un AI vadīta API drošība

Pievienojot AI pārvaldītu drošību API pārvaldības ieviešanai, būs drošības izpildes punkts un lēmumu pieņemšanas punkts. Parasti šīs vienības ir neatkarīgas, ņemot vērā nepieciešamo lielo skaitļošanas jaudu, taču nevajadzētu ļaut latentumam ietekmēt to efektivitāti.

API vārteja pārtver API pieprasījumus un piemēro dažādas politikas. Ar to ir saistīts drošības izpildes punkts, kas apraksta katra pieprasījuma (API izsaukuma) atribūtus lēmuma pieņemšanas punktam, pieprasa drošības lēmumu un pēc tam izpilda šo lēmumu vārtejā. Ar AI darbināms lēmuma pieņemšanas punkts nepārtraukti apgūst katra API piekļuves modeļa darbību, atklāj anomālu uzvedību un atzīmē dažādus pieprasījuma atribūtus.

Būtu jābūt iespējai pēc nepieciešamības pievienot politikas lēmuma pieņemšanas vietai un mācību periodā izmantot šīs politikas - kas dažādās API var atšķirties. Drošības komandai ir jādefinē visas politikas, tiklīdz ir pilnībā izprastas katras API iespējamās ievainojamības, kuras viņi plāno atklāt. Tomēr pat bez ārējās politikas atbalsta adaptīvie, ar AI darbināmi lēmumu pieņemšanas un izpildes punktu tehnoloģija galu galā iemācīsies un novērsīs dažus sarežģītus uzbrukumus, kurus mēs nevaram atklāt ar politiku.

Vēl viena divu atsevišķu drošības izpildes punktu un lēmumu punktu sastāvdaļu priekšrocība ir spēja integrēties ar esošajiem API pārvaldības risinājumiem. Vienkāršs lietotāja interfeisa uzlabojums un pielāgots paplašinājums varētu integrēt drošības izpildes punktu API izdevējā un vārtejā. No lietotāja saskarnes API izdevējs varēja izvēlēties, vai iespējot AI drošību publicētajai API, kā arī nepieciešamās īpašās politikas. Paplašinātais drošības izpildes punkts publicētu pieprasījuma atribūtus lēmuma punktam un ierobežotu piekļuvi API atbilstoši lēmuma punkta atbildei.

Tomēr notikumu publicēšana lēmuma pieņemšanas vietā un piekļuves ierobežošana, pamatojoties uz tā reakciju, prasīs laiku un būs ļoti atkarīga no tīkla. Tāpēc to vislabāk var veikt asinhroni, izmantojot kešatmiņas mehānismu. Tas nedaudz ietekmēs precizitāti, taču, ņemot vērā vārtejas efektivitāti, AI drošības slāņa pievienošana minimāli veicinās kopējo latentumu.

Ar mākslīgo intelektu saistītais drošības slāņa izaicinājums

Protams, pabalsti nerodas bez izmaksām. Kaut arī ar mākslīgo intelektu saistītais drošības slānis piedāvā papildu API aizsardzības līmeni, tas rada dažas problēmas, kas drošības komandām būs jārisina.

  • Papildu pieskaitāmās izmaksas. Papildu AI drošības slānis ziņu plūsmai pievieno dažas papildu izmaksas. Tātad, starpniecības risinājumiem vajadzētu būt pietiekami gudriem, lai apstrādātu un publicētu informāciju ārpus galvenās starpniecības plūsmas.
  • Viltus pozitīvs. Lielam skaitam viltus pozitīvu rezultātu būs nepieciešama drošības speciālistu papildu pārbaude. Tomēr, izmantojot dažus uzlabotus AI algoritmus, mēs varam samazināt aktivēto viltus pozitīvo rezultātu skaitu.
  • Uzticības trūkums. Cilvēki jūtas neērti, ja nesaprot, kā tika pieņemts lēmums. Informācijas paneļi un brīdinājumi var palīdzēt lietotājiem vizualizēt lēmuma faktorus. Piemēram, ja brīdinājumā skaidri norādīts, ka lietotājs tika bloķēts, lai minūtes laikā varētu piekļūt sistēmai ar nenormālu ātrumu 1000 plus reizes, cilvēki var saprast un uzticēties sistēmas lēmumam.
  • Datu ievainojamība. Lielākā daļa AI un mašīnmācīšanās risinājumu balstās uz milzīgu datu apjomu, kas bieži ir sensitīvs un personisks. Rezultātā šie risinājumi varētu kļūt pakļauti datu pārkāpumiem un identitātes zādzībām. Atbilstība Eiropas Savienības GDPR (Vispārīgā datu aizsardzības regula) palīdz mazināt šo risku, bet pilnībā to nenovērš.
  • Apzīmētu datu ierobežojumi. Spēcīgākās AI sistēmas tiek apmācītas, izmantojot uzraudzītu mācīšanos, kurai nepieciešami apzīmēti dati, kas ir sakārtoti, lai padarītu tos saprotamus mašīnām. Bet marķētiem datiem ir ierobežojumi, un turpmāka automatizēta arvien grūtāku algoritmu izveide tikai saasinās problēmu.
  • Nepareizi dati. AI sistēmas efektivitāte ir atkarīga no datiem, uz kuriem tā tiek apmācīta. Pārāk bieži slikti dati ir saistīti ar etnisko, kopienas, dzimuma vai rasu aizspriedumiem, kas var ietekmēt izšķirošus lēmumus par atsevišķiem lietotājiem.

Ņemot vērā API kritisko nozīmi mūsdienās uzņēmumos, tie arvien vairāk kļūst par hakeru un ļaunprātīgu lietotāju mērķiem. Uz politiku balstīti mehānismi, piemēram, autentifikācija, autorizācija, lietderīgās slodzes skenēšana, shēmas validēšana, ierobežošana un ātruma ierobežošana, ir pamatprasības veiksmīgas API drošības stratēģijas ieviešanai. Tomēr tikai pievienojot AI modeļus, lai nepārtraukti pārbaudītu un ziņotu par visām API darbībām, uzņēmumi tiks pasargāti no mūsdienīgākajiem drošības uzbrukumiem.

Sanjeewa Malalgoda ir programmatūras arhitekts un WSO2 inženierzinātņu asociētais direktors, kur viņš vada WSO2 API vadītāja izstrādi. Lakšita Gunasekara ir programmatūras inženieris WSO2 API Manager komandā.

Jauno tehnoloģiju forums nodrošina vietu, kur bezprecedenta dziļumā un plašumā izpētīt un pārrunāt topošās uzņēmuma tehnoloģijas. Izvēle ir subjektīva, balstoties uz mūsu izvēlētajām tehnoloģijām, kuras, mūsuprāt, ir svarīgas un interesē lasītājus. nepieņem mārketinga nodrošinājumu publicēšanai un patur tiesības rediģēt visu ieguldīto saturu. Nosūtiet visus jautājumus uz[email protected].

$config[zx-auto] not found$config[zx-overlay] not found