API-er har blitt kronjuvelene til organisasjonenes digitale transformasjonsinitiativer, og gir ansatte, partnere, kunder og andre interessenter tilgang til applikasjoner, data og forretningsfunksjonalitet i hele deres digitale økosystem. Så det er ikke rart at hackere har økt sine bølger av angrep mot disse kritiske bedriftens eiendeler.
Dessverre ser det ut til at problemet bare vil forverres. Gartner har spådd at "Innen 2022 vil API-misbruk være den hyppigste angrepsvektoren, noe som resulterer i datainnbrudd for bedriftens webapplikasjoner."
Mange bedrifter har svart ved å implementere API-styringsløsninger som gir mekanismer, for eksempel autentisering, autorisasjon og struping. Dette er må-ha-muligheter for å kontrollere hvem som får tilgang til API-er på tvers av API-økosystemet - og hvor ofte. Men når de bygger sine interne og eksterne API-strategier, må organisasjoner også adressere veksten av mer sofistikerte angrep på API-er ved å implementere dynamisk, kunstig intelligens (AI) -drevet sikkerhet.
Denne artikkelen undersøker API-administrasjons- og sikkerhetsverktøy som organisasjoner bør innlemme for å sikre sikkerhet, integritet og tilgjengelighet i deres API-økosystemer.
Regelbaserte og politikkbaserte sikkerhetstiltak
Regelbaserte og policybaserte sikkerhetskontroller, som kan utføres på en statisk eller dynamisk måte, er obligatoriske deler av enhver API-administrasjonsløsning. API-gateways fungerer som det viktigste inngangspunktet for API-tilgang, og håndterer derfor vanligvis håndhevelse av policyer ved å inspisere innkommende forespørsler mot policyer og regler relatert til sikkerhet, hastighetsgrenser, struping osv. La oss se nærmere på noen statiske og dynamiske sikkerhetskontroller for å se de ekstra verdi de gir.
Statisk sikkerhetskontroll
Statisk sikkerhetskontroll avhenger ikke av forespørselsvolumet eller tidligere forespørselsdata, siden de vanligvis validerer meldingsdata mot et forhåndsdefinert sett med regler eller policyer. Ulike statiske sikkerhetsskanninger utføres i gateways for å blokkere SQL-injeksjon, sammenhengende parsingangrep, enhetsutvidelsesangrep og skjemaforgiftning, blant andre.
I mellomtiden kan statiske policy-kontroller brukes til blant annet nyttelastskanning, topptekstinspeksjon og tilgangsmønstre. For eksempel er SQL-injeksjon en vanlig type angrep utført ved hjelp av nyttelaster. Hvis en bruker sender en JSON-nyttelast (JavaScript Object Notation), kan API-gatewayen validere denne spesielle forespørselen mot forhåndsdefinert JSON-skjema. Gatewayen kan også begrense antall elementer eller andre attributter i innholdet etter behov for å beskytte mot skadelige data eller tekstmønstre i meldinger.
Dynamiske sikkerhetskontroller
I motsetning til statiske sikkerhetsskanninger sjekker dynamiske sikkerhetskontroller alltid noe som varierer over tid. Vanligvis innebærer dette å validere forespørselsdata med beslutninger tatt med eksisterende data. Eksempler på dynamiske kontroller inkluderer validering av tilgangstoken, deteksjon av avvik og struping. Disse dynamiske kontrollene avhenger sterkt av datavolumet som sendes til gatewayen. Noen ganger skjer disse dynamiske kontrollene utenfor API-gatewayen, og deretter blir beslutningene kommunisert til gatewayen. La oss se på noen eksempler.
Demping og hastighetsbegrensning er viktig for å redusere virkningen av angrep, for når angripere får tilgang til API-er, er det første de gjør å lese så mye data som mulig. Throttling API-forespørsler - dvs. å begrense tilgangen til dataene - krever at vi holder et antall innkommende forespørsler innenfor et bestemt tidsvindu. Hvis et antall forespørsler overstiger det tildelte beløpet på det tidspunktet, kan gatewayen blokkere API-anrop. Med taktsbegrensning kan vi begrense samtidig tilgang for en gitt tjeneste.
Godkjenning
Autentisering hjelper API-gateways til å identifisere hver bruker som påberoper seg en API unikt. Tilgjengelige API-gatewayløsninger støtter generelt grunnleggende autentisering, OAuth 2.0, JWT (JSON Web Token) sikkerhet og sertifikatbasert sikkerhet. Noen gateways gir også et autentiseringslag på toppen av det for ytterligere finkornet tillatelsesvalidering, som vanligvis er basert på XACML (eXtensible Access Control Markup Language) språkdefinisjonsspråk. Dette er viktig når en API inneholder flere ressurser som trenger forskjellige nivåer av tilgangskontroll for hver ressurs.
Begrensninger for tradisjonell API-sikkerhet
Retningslinjebaserte tilnærminger rundt autentisering, autorisasjon, hastighetsbegrensning og struping er effektive verktøy, men de gir fortsatt sprekker som hackere kan utnytte API-er gjennom. Spesielt API-gateways foran flere webtjenester, og API-ene de administrerer er ofte lastet med et høyt antall økter. Selv om vi analyserte alle disse øktene ved hjelp av policyer og prosesser, ville det være vanskelig for en gateway å inspisere alle forespørsler uten ekstra beregningskraft.
I tillegg har hvert API sitt eget tilgangsmønster. Så, et legitimt tilgangsmønster for en API kan indikere ondsinnet aktivitet for en annen API. For eksempel når noen kjøper varer gjennom en online shoppingapplikasjon, vil de utføre flere søk før de foretar kjøpet. Så, en enkelt bruker som sender 10 til 20 forespørsler til et søke-API innen kort tid, kan være et legitimt tilgangsmønster for et søke-API. Imidlertid, hvis den samme brukeren sender flere forespørsler til kjøps-API, kan tilgangsmønsteret indikere ondsinnet aktivitet, for eksempel en hacker som prøver å trekke ut så mye som mulig ved hjelp av et stjålet kredittkort. Derfor må hvert API-tilgangsmønster analyseres separat for å finne riktig svar.
Nok en faktor er at et betydelig antall angrep skjer internt. Her bruker brukere med gyldig legitimasjon og tilgang til systemer deres evne til å angripe disse systemene. Retningslinjebasert autentiserings- og autorisasjonsfunksjoner er ikke designet for å forhindre slike angrep.
Selv om vi kunne bruke flere regler og policyer på en API-gateway for å beskytte mot angrepene som er beskrevet her, vil den ekstra overhead på API-gatewayen være uakseptabel. Bedrifter har ikke råd til å frustrere ekte brukere ved å be dem om å bære behandlingsforsinkelser for deres API-gateways. I stedet må gateways behandle gyldige forespørsler uten å blokkere eller redusere bruker-API-samtaler.
Saken for å legge til et AI-sikkerhetslag
For å fylle sprekkene etter policy-baserte API-beskyttelse, trenger moderne sikkerhetsteam kunstig intelligensbasert API-sikkerhet som kan oppdage og svare på dynamiske angrep og de unike sårbarhetene til hver API. Ved å bruke AI-modeller for kontinuerlig inspeksjon og rapportering av all API-aktivitet, kan bedrifter automatisk oppdage unormale API-aktiviteter og trusler på tvers av API-infrastrukturer som tradisjonelle metoder savner.
Selv i tilfeller der standard sikkerhetstiltak er i stand til å oppdage avvik og risiko, kan det ta måneder å gjøre funnene. Derimot, ved å bruke forhåndsbygde modeller basert på brukertilgangsmønstre, ville et AI-drevet sikkerhetslag gjøre det mulig å oppdage noen angrep i nærmest sanntid.
Det er viktig at AI-motorer vanligvis kjører utenfor API-gateways og kommuniserer beslutningene til dem. Fordi API-gatewayen ikke trenger å bruke ressurser på å behandle disse forespørslene, påvirker tillegg av AI-sikkerhet vanligvis ikke kjøretidsytelsen.
Integrering av policybasert og AI-drevet API-sikkerhet
Når du legger til AI-drevet sikkerhet i en API-administrasjonsimplementering, vil det være et sikkerhetshåndhevelsespunkt og et avgjørelsespunkt. Vanligvis er disse enhetene uavhengige på grunn av den høye beregningskraften som kreves, men ventetid skal ikke få lov til å påvirke effektiviteten.
API-gatewayen avlytter API-forespørsler og bruker forskjellige retningslinjer. Koblet til det er sikkerhetshåndhevelsespunktet, som beskriver attributtene til hver forespørsel (API-anrop) til avgjørelsespunktet, ber om en sikkerhetsavgjørelse, og deretter håndhever avgjørelsen i gatewayen. Beslutningspunktet, drevet av AI, lærer kontinuerlig oppførselen til hvert API-tilgangsmønster, oppdager avvikende atferd og flagger forskjellige attributter for forespørselen.
Det bør være et alternativ å legge til policyer i avgjørelsespunktet etter behov og påkalle disse policyene - som kan variere fra API til API - i løpet av læringsperioden. Enhver policy bør defineres av sikkerhetsteamet når de potensielle sårbarhetene til hvert API de planlegger å eksponere, er grundig forstått. Imidlertid, selv uten støtte fra ekstern politikk, vil tilpasningsdyktig, AI-drevet beslutningspunkt og håndhevelsesteknologi til slutt lære og forhindre noen av de komplekse angrepene som vi ikke kan oppdage med politikk.
En annen fordel med å ha to separate sikkerhetshåndhevelsespunkter og beslutningspunktskomponenter er muligheten til å integrere med eksisterende API-administrasjonsløsninger. En enkel forbedring av brukergrensesnittet og tilpasset utvidelse kan integrere sikkerhetshåndteringspunktet til API-utgiveren og gatewayen. Fra brukergrensesnittet kunne API-utgiveren velge om AI-sikkerhet for den publiserte APIen skulle aktiveres, sammen med eventuelle spesielle retningslinjer som trengs. Det utvidede sikkerhetshåndhevelsespunktet vil publisere forespørselsattributtene til avgjørelsespunktet og begrense tilgangen til API i henhold til beslutningspunkts svar.
Å publisere hendelser til avgjørelsesstedet og begrense tilgangen basert på svaret vil imidlertid ta tid og avhenger sterkt av nettverket. Derfor implementeres den best asynkront ved hjelp av en cachemekanisme. Dette vil påvirke nøyaktigheten litt, men når du vurderer gatewayens effektivitet, vil det å legge til et AI-sikkerhetslag minimalt bidra til den totale ventetiden.
AI-drevne sikkerhetslag utfordringer
Selvfølgelig kommer fordelene ikke uten kostnader. Mens et AI-drevet sikkerhetslag tilbyr et ekstra nivå av API-beskyttelse, byr det på noen utfordringer som sikkerhetsteamene må ta tak i.
- Ekstra overhead. Det ekstra AI-sikkerhetslaget legger til noe overhead i meldingsflyten. Så meklingsløsninger bør være smarte nok til å håndtere informasjonsinnhenting og publisering utenfor hovedformidlingsflyten.
- Falske positive. Et høyt volum av falske positive vil kreve ytterligere gjennomgang av sikkerhetsfagfolk. Imidlertid, med noen avanserte AI-algoritmer, kan vi redusere antall utløste falske positive.
- Mangel på tillit. Folk føler seg ukomfortable når de ikke forstår hvordan en beslutning ble tatt. Dashboards og varsler kan hjelpe brukere å visualisere faktorene bak en beslutning. For eksempel, hvis et varsel tydelig sier at en bruker ble blokkert for tilgang til systemet med en unormal hastighet på 1000 pluss ganger i løpet av et minutt, kan folk forstå og stole på systemets beslutning.
- Datasårbarhet. De fleste AI- og maskinlæringsløsninger er avhengige av store datamengder, som ofte er sensitive og personlige. Som et resultat kan disse løsningene bli utsatt for datainnbrudd og identitetstyveri. Overholdelse av EUs GDPR (General Data Protection Regulation) bidrar til å redusere denne risikoen, men eliminerer den ikke helt.
- Merkede databegrensninger. De kraftigste AI-systemene blir trent gjennom overvåket læring, som krever merkede data som er organisert for å gjøre det forståelig av maskiner. Men merkede data har grenser, og den fremtidige automatiserte opprettelsen av stadig vanskeligere algoritmer vil bare forverre problemet.
- Feil data. Et AI-systems effektivitet avhenger av dataene det blir trent på. Altfor ofte er dårlige data assosiert med etniske, kommunale, kjønn eller rasemessige skjevheter, noe som kan påvirke avgjørende beslutninger om individuelle brukere.
Gitt den kritiske rollen API-er har i bedrifter i dag, blir de i økende grad mål for hackere og ondsinnede brukere. Retningslinjebaserte mekanismer, som autentisering, autorisasjon, nyttelastskanning, skjemavalidering, struping og hastighetsbegrensning, er grunnlinjekrav for å implementere en vellykket API-sikkerhetsstrategi. Imidlertid, bare ved å legge til AI-modeller for kontinuerlig inspeksjon og rapportering om all API-aktivitet, vil bedrifter bli beskyttet mot de mest sofistikerte sikkerhetsangrepene som dukker opp i dag.
Sanjeewa Malalgoda er programvarearkitekt og assisterende ingeniørdirektør i WSO2, hvor han leder utviklingen av WSO2 API Manager. Lakshitha Gunasekara er programvareingeniør i WSO2 API Manager-teamet.
—
New Tech Forum er et sted for å utforske og diskutere ny teknologi i enestående dybde og bredde. Valget er subjektivt, basert på vårt valg av teknologiene vi mener er viktige og av størst interesse for leserne. godtar ikke markedsføringssikkerhet for publisering og forbeholder seg retten til å redigere alt bidratt innhold. Send alle henvendelser til[email protected].
