Ohjelmointi

Kuinka tekoäly parantaa API-suojausta

Sovellusliittymistä on tullut organisaatioiden digitaalisen muutoksen aloitteiden kruunujalokiviä, jotka antavat työntekijöille, kumppaneille, asiakkaille ja muille sidosryhmille mahdollisuuden käyttää sovelluksia, tietoja ja liiketoiminnallisia toimintoja digitaalisessa ekosysteemissään. Ei siis ole ihme, että hakkerit ovat lisänneet hyökkäysaaltojaan näitä kriittisiä yritysvaroja vastaan.

Valitettavasti näyttää siltä, ​​että ongelma vain pahenee. Gartner on ennustanut, että "Vuoteen 2022 mennessä sovellusliittymän väärinkäytöt ovat yleisimpiä hyökkäysvektoreita, jotka johtavat tietojen rikkomiseen yrityksen verkkosovelluksissa."

Monet yritykset ovat vastanneet ottamalla käyttöön API-hallintaratkaisuja, jotka tarjoavat mekanismeja, kuten todennuksen, valtuutuksen ja kuristamisen. Näillä on oltava valmiudet hallita, kuka käyttää sovellusliittymiä API-ekosysteemissä - ja kuinka usein. Sisäisten ja ulkoisten sovellusliittymästrategioidensa rakentamisessa organisaatioiden on kuitenkin puututtava myös kehittyneempiin sovellusliittymiin kohdistuvien hyökkäysten kasvuun toteuttamalla dynaaminen, tekoälyyn (AI) perustuva turvallisuus.

Tässä artikkelissa tarkastellaan sovellusliittymien hallintaa ja suojaustyökaluja, jotka organisaatioiden tulisi sisällyttää turvallisuuden, eheyden ja käytettävyyden varmistamiseksi kaikissa API-ekosysteemeissä.

Sääntö- ja politiikkaan perustuvat turvatoimet

Sääntö- ja käytäntöpohjaiset turvatarkistukset, jotka voidaan suorittaa staattisesti tai dynaamisesti, ovat pakollisia osia kaikissa API-hallintaratkaisuissa. API-yhdyskäytävät toimivat API-pääsyjen pääsisääntulopisteenä ja käsittelevät siksi politiikkojen valvontaa tyypillisesti tarkastelemalla saapuvia pyyntöjä tietoturvaan, nopeusrajoihin, kuristuksiin jne. Liittyviin käytäntöihin ja sääntöihin nähden. niiden tuomaa arvoa.

Staattiset turvatarkastukset

Staattiset turvatarkastukset eivät riipu pyynnön määrästä tai aikaisemmista pyyntötiedoista, koska ne yleensä vahvistavat viestitiedot ennalta määritettyjen sääntöjen tai käytäntöjen mukaan. Yhdyskäytävissä suoritetaan erilaisia ​​staattisia tietoturvatarkistuksia muun muassa SQL-injektoinnin, yhtenäisten jäsentämishyökkäysten, entiteettilaajennushyökkäysten ja skeemamyrkytysten estämiseksi.

Samaan aikaan staattisia käytäntöjen tarkastuksia voidaan soveltaa muun muassa hyötykuorman skannaukseen, otsikkotarkastukseen ja pääsymalleihin. Esimerkiksi SQL-injektio on yleinen hyökkäystyyppi, joka suoritetaan hyötykuormilla. Jos käyttäjä lähettää JSON (JavaScript Object Notation) -kuorman, API-yhdyskäytävä voi vahvistaa tämän pyynnön ennalta määritettyyn JSON-skeemaan. Yhdyskäytävä voi myös rajoittaa sisällön elementtien tai muiden attribuuttien määrää tarpeen mukaan suojautuakseen viesteissä olevilta haitallisilta tiedoilta tai tekstimalleilta.

Dynaamiset turvatarkastukset

Dynaamiset turvatarkistukset, toisin kuin staattiset turvatarkistukset, tarkistavat aina jotain, joka vaihtelee ajan myötä. Yleensä tähän sisältyy pyyntötietojen vahvistaminen olemassa olevia tietoja käyttäen tehdyillä päätöksillä. Esimerkkejä dynaamisista tarkastuksista ovat pääsykoodin vahvistus, poikkeavuuksien havaitseminen ja kuristaminen. Nämä dynaamiset tarkistukset riippuvat suuresti yhdyskäytävälle lähetettävästä datamäärästä. Joskus nämä dynaamiset tarkistukset tapahtuvat API-yhdyskäytävän ulkopuolella, ja sitten päätökset ilmoitetaan yhdyskäytävälle. Katsotaanpa muutama esimerkki.

Kuristaminen ja nopeuden rajoittaminen ovat tärkeitä hyökkäysten vaikutusten vähentämiseksi, koska aina, kun hyökkääjät pääsevät käyttämään sovellusliittymiä, he ensin lukevat mahdollisimman paljon tietoja. API-pyyntöjen kuristaminen - eli pääsyn rajoittaminen tietoihin - edellyttää, että pidämme saapuvien pyyntöjen määrän tietyssä aikaikkunassa. Jos pyyntöjen määrä ylittää varatun määrän tuolloin, yhdyskäytävä voi estää API-puhelut. Nopeudenrajoituksella voimme rajoittaa tietyn palvelun sallittua samanaikaista pääsyä.

Todennus

Todennus auttaa API-yhdyskäytäviä tunnistamaan käyttäjän, joka kutsuu sovellusliittymän ainutlaatuisesti. Saatavilla olevat API-yhdyskäytäväratkaisut tukevat yleensä perustodennusta, OAuth 2.0-, JWT- (JSON Web Token) ja varmenteisiin perustuvaa suojausta. Jotkut yhdyskäytävät tarjoavat myös todennuskerroksen sen päälle ylimääräisen tarkan käyttöoikeuksien tarkistuksen varmistamiseksi, joka perustuu yleensä XACML (eXtensible Access Control Markup Language) -tyyppisiin käytäntömääritelmäkieliin. Tämä on tärkeää, kun sovellusliittymä sisältää useita resursseja, jotka tarvitsevat jokaiselle resurssille eri käyttöoikeustasot.

Perinteisen API-suojauksen rajoitukset

Politiikkaperusteiset lähestymistavat todennukseen, valtuutukseen, nopeuden rajoittamiseen ja kuristamiseen ovat tehokkaita työkaluja, mutta ne jättävät silti halkeamia, joiden kautta hakkerit voivat hyödyntää sovellusliittymiä. API-yhdyskäytävät etupuolella useita verkkopalveluja, ja niiden hallinnoimille sovellusliittymille on usein ladattu suuri määrä istuntoja. Vaikka analysoimme kaikkia näitä istuntoja käytäntöjen ja prosessien avulla, yhdyskäytävän olisi vaikea tarkistaa jokaista pyyntöä ilman ylimääräistä laskentatehoa.

Jokaisella sovellusliittymällä on lisäksi oma käyttömallinsa. Joten yhden käyttöliittymän laillinen käyttöoikeusmalli voi osoittaa haitallista toimintaa toiselle sovellusliittymälle. Esimerkiksi kun joku ostaa tavaroita verkkokauppasovelluksen kautta, hän suorittaa useita hakuja ennen ostoksen tekemistä. Joten yksi käyttäjä, joka lähettää 10-20 pyyntöä hakusovellusliittymälle lyhyessä ajassa, voi olla laillinen käyttöliittymä hakusovellusliittymälle. Jos sama käyttäjä lähettää kuitenkin useita pyyntöjä osto-sovellusliittymälle, käyttöoikeusmalli saattaa viitata haitalliseen toimintaan, kuten hakkeri yrittää nostaa mahdollisimman paljon varastettua luottokorttia käyttämällä. Siksi jokainen sovellusliittymän käyttömalli on analysoitava erikseen oikean vastauksen määrittämiseksi.

Vielä yksi tekijä on, että huomattava määrä hyökkäyksiä tapahtuu sisäisesti. Tässä käyttäjät, joilla on voimassa olevat kirjautumistiedot ja pääsy järjestelmiin, käyttävät kykyään hyökätä kyseisiin järjestelmiin. Politiikkaperusteisia todennus- ja valtuutusominaisuuksia ei ole suunniteltu estämään tällaisia ​​hyökkäyksiä.

Vaikka voisimme soveltaa enemmän sääntöjä ja käytäntöjä API-yhdyskäytävään suojautua tässä kuvattuilta hyökkäyksiltä, ​​API-yhdyskäytävän ylimääräisiä yleiskustannuksia ei voida hyväksyä. Yrityksillä ei ole varaa turhauttaa aitoja käyttäjiä pyytämällä heitä kantamaan API-yhdyskäytävänsä käsittelyviiveet. Sen sijaan yhdyskäytävien on käsiteltävä kelvollisia pyyntöjä estämättä tai hidastamatta käyttäjän sovellusliittymäkutsuja.

Tapaus tekoälyn turvakerroksen lisäämiseksi

Nykyaikaiset tietoturvaryhmät tarvitsevat tekoälypohjaisen API-suojauksen, jotta se pystyy havaitsemaan dynaamiset hyökkäykset ja vastaamaan kunkin sovellusliittymän ainutlaatuisiin haavoittuvuuksiin ja täyttämään niillä käytäntöihin perustuvien sovellusliittymien suojausten jättämät halkeamat. Soveltamalla tekoälymalleja jatkuvasti tarkastamaan ja raportoimaan kaikista sovellusliittymän toiminnoista yritykset voisivat automaattisesti löytää epänormaalin sovellusliittymän toiminnan ja uhat API-infrastruktuureista, joita perinteiset menetelmät kaipaavat.

Jopa tapauksissa, joissa tavanomaiset turvatoimet pystyvät havaitsemaan poikkeavuuksia ja riskejä, löytöjen tekeminen voi kestää kuukausia. Sen sijaan käyttämällä valmiiksi rakennettuja malleja, jotka perustuvat käyttäjien pääsymalleihin, tekoälyohjattu turvakerros antaisi mahdollisuuden havaita joitain hyökkäyksiä lähes reaaliajassa.

Tärkeää on, että tekoälymoottorit käyvät yleensä API-yhdyskäytävien ulkopuolella ja ilmoittavat päätöksistään heille. Koska API-yhdyskäytävän ei tarvitse käyttää resursseja näiden pyyntöjen käsittelyyn, tekoälyn suojauksen lisääminen ei yleensä vaikuta ajonaikaisiin suorituksiin.

Politiikkaan perustuvan ja tekoälyyn perustuvan sovellusliittymän tietoturvan integrointi

Kun lisätään tekoälypohjaista tietoturvaa API-hallinnan toteutukseen, siellä on tietoturvan valvontapiste ja päätöspiste. Nämä yksiköt ovat tyypillisesti riippumattomia vaaditun suuren laskentatehon takia, mutta latenssin ei pitäisi antaa vaikuttaa niiden tehokkuuteen.

API-yhdyskäytävä sieppaa API-pyynnöt ja soveltaa erilaisia ​​käytäntöjä. Siihen on liitetty tietoturvan valvontapiste, joka kuvaa kunkin pyynnön (API-kutsun) attribuutit päätöksentekopisteeseen, pyytää tietoturvapäätöstä ja panee tämän päätöksen täytäntöön yhdyskäytävässä. Tekoälyllä toimiva päätöksentekopiste oppii jatkuvasti jokaisen sovellusliittymän käyttömallin käyttäytymisen, havaitsee poikkeavan käyttäytymisen ja merkitsee pyynnön eri määritteet.

Olisi oltava mahdollisuus lisätä käytäntöjä päätöksentekopisteeseen tarpeen mukaan ja käyttää näitä käytäntöjä - jotka voivat vaihdella sovellusliittymästä API: hon - oppimisjakson aikana. Tietoturvaryhmän tulisi määritellä kaikki käytännöt, kun jokaisen API: n mahdolliset haavoittuvuudet on perusteellisesti ymmärretty. Jopa ilman ulkoisen politiikan tukea, mukautuva, tekoälypohjainen päätöksenteko- ja täytäntöönpanopisteteknologia kuitenkin oppii ja estää joitain monimutkaisia ​​hyökkäyksiä, joita emme voi havaita käytäntöjen avulla.

Toinen etu siitä, että sinulla on kaksi erillistä tietoturvan valvontapistettä ja päätöspistekomponenttia, on kyky integroida olemassa oleviin API-hallintaratkaisuihin. Yksinkertainen käyttöliittymän parannus ja räätälöity laajennus voivat integroida suojauksen valvontapisteen API-julkaisijaan ja yhdyskäytävään. Käyttöliittymästä sovellusliittymän julkaisija voi valita, otetaanko tekoälyn suojaus julkaistulle sovellusliittymälle mahdollisten erityisten käytäntöjen ohella. Laajennettu tietoturvan valvontapiste julkaisi pyyntöattribuutit päätöksentekopisteelle ja rajoittaisi pääsyä sovellusliittymään päätöksentekopisteen vastauksen mukaan.

Tapahtumien julkaiseminen päätöspisteessä ja pääsyn rajoittaminen sen vastauksen perusteella vie kuitenkin aikaa ja riippuu suuresti verkosta. Siksi se toteutetaan parhaiten asynkronisesti välimuistimekanismin avulla. Tämä vaikuttaa hieman tarkkuuteen, mutta kun otetaan huomioon yhdyskäytävän tehokkuus, tekoälyn suojaustason lisääminen vaikuttaa minimaalisesti yleiseen viiveeseen.

Tekoälyyn perustuvat tietoturvakerroksen haasteet

Edut eivät tietenkään tuota ilman kustannuksia. Tekoälyyn perustuva tietoturvakerros tarjoaa ylimääräisen API-suojauksen tason, mutta se asettaa joitain haasteita, joihin tietoturvaryhmien on vastattava.

  • Lisäkustannukset. AI-suojauksen lisäkerros lisää viestivirtaan yleiskustannuksia. Joten, sovitteluratkaisujen tulisi olla riittävän älykkäitä käsittelemään tiedonkeruuta ja julkaisua tärkeimmän sovitteluvirran ulkopuolella.
  • Väärät positiiviset. Suuri määrä vääriä positiivisia tuloksia edellyttää turvallisuusalan ammattilaisten lisäarviointia. Joillakin kehittyneillä tekoälyalgoritmeilla voimme kuitenkin vähentää laukaistujen väärien positiivisten lukumäärää.
  • Epäluottamus. Ihmiset tuntevat olonsa epämukavaksi, kun he eivät ymmärrä, miten päätös tehtiin. Koontinäytöt ja hälytykset voivat auttaa käyttäjiä visualisoimaan päätöksen taustalla olevat tekijät. Esimerkiksi, jos hälytyksessä ilmoitetaan selvästi, että käyttäjä on estetty pääsemästä järjestelmään epänormaalilla nopeudella, yli 1 000 kertaa kertaa minuutissa, ihmiset voivat ymmärtää järjestelmän päätöksen ja luottaa siihen.
  • Tietojen haavoittuvuus. Suurin osa tekoäly- ja koneoppimisratkaisuista perustuu suuriin tietomääriin, jotka ovat usein arkaluonteisia ja henkilökohtaisia. Tämän seurauksena nämä ratkaisut saattavat altistua tietorikkomuksille ja henkilöllisyysvarkauksille. Euroopan unionin GDPR: n (yleinen tietosuoja-asetus) noudattaminen auttaa vähentämään tätä riskiä, ​​mutta ei poista sitä kokonaan.
  • Merkityt tietorajoitukset. Tehokkaimmat tekoälyjärjestelmät koulutetaan valvotun oppimisen kautta, mikä edellyttää merkittyjä tietoja, jotka on järjestetty, jotta koneet ymmärtäisivät sen. Mutta merkittyillä tiedoilla on rajoituksia, ja yhä vaikeampien algoritmien tuleva automaattinen luominen vain pahentaa ongelmaa.
  • Vialliset tiedot. Tekoälyjärjestelmän tehokkuus riippuu tiedoista, joihin se on koulutettu. Liian usein huonot tiedot liittyvät etniseen, yhteisölliseen, sukupuoleen tai rotuun liittyvään puolueellisuuteen, mikä voi vaikuttaa yksittäisiä käyttäjiä koskeviin ratkaiseviin päätöksiin.

Kun otetaan huomioon sovellusliittymien kriittinen rooli yrityksissä, niistä on yhä enemmän hakkerien ja haitallisten käyttäjien kohteita. Politiikkaperusteiset mekanismit, kuten todennus, valtuutus, hyötykuorman skannaus, skeeman vahvistus, kuristaminen ja nopeuden rajoittaminen, ovat perusedellytyksiä onnistuneen API-suojausstrategian toteuttamiselle. Kuitenkin vain lisäämällä tekoälymalleja kaikkien API-toimintojen jatkuvaan tarkastamiseen ja raportointiin yritykset suojataan nykypäivän kehittyneimmiltä turvallisuushyökkäyksiltä.

Sanjeewa Malalgoda on ohjelmistoarkkitehti ja apulaisjohtaja WSO2: lla, missä hän johtaa WSO2 API Managerin kehitystä. Lakshitha Gunasekara on ohjelmistoinsinööri WSO2 API Manager -tiimissä.

New Tech Forum tarjoaa mahdollisuuden tutkia ja keskustella kehittyvistä yritysteknologioista ennennäkemättömällä syvyydellä ja laajuudella. Valinta on subjektiivinen, perustuu valitsemiemme tekniikoihin, joiden uskomme olevan tärkeitä ja kiinnostavia lukijoille. ei hyväksy markkinointivakuuksia julkaisua varten ja pidättää oikeuden muokata kaikkea lähetettyä sisältöä. Lähetä kaikki tiedustelut osoitteeseen[email protected].

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