Programmering

Hvordan AI forbedrer API-sikkerhed

API'er er blevet kronjuvelerne til organisationers digitale transformationsinitiativer og giver medarbejdere, partnere, kunder og andre interessenter adgang til applikationer, data og forretningsfunktionalitet på tværs af deres digitale økosystem. Så det er ikke underligt, at hackere har øget deres bølger af angreb mod disse kritiske virksomhedsaktiver.

Desværre ser det ud til, at problemet kun forværres. Gartner har forudsagt, at "I 2022 vil API-misbrug være den hyppigste angrepsvektor, der resulterer i databrud for virksomhedswebapplikationer."

Mange virksomheder har reageret ved at implementere API-styringsløsninger, der leverer mekanismer, såsom godkendelse, autorisation og begrænsning. Disse er must-have-muligheder for at kontrollere, hvem der får adgang til API'er på tværs af API-økosystemet - og hvor ofte. Men når de bygger deres interne og eksterne API-strategier, skal organisationer også tackle væksten af ​​mere sofistikerede angreb på API'er ved at implementere dynamisk, kunstig intelligens (AI) -drevet sikkerhed.

Denne artikel undersøger API-styring og sikkerhedsværktøjer, som organisationer skal indarbejde for at sikre sikkerhed, integritet og tilgængelighed på tværs af deres API-økosystemer.

Regelbaserede og politikbaserede sikkerhedsforanstaltninger

Regelbaseret og politikbaseret sikkerhedskontrol, som kan udføres på en statisk eller dynamisk måde, er obligatoriske dele af enhver API-styringsløsning. API-gateways fungerer som det vigtigste indgangssted for API-adgang og håndterer derfor typisk håndhævelse af politikker ved at inspicere indgående anmodninger mod politikker og regler relateret til sikkerhed, satsbegrænsninger, begrænsning osv. Lad os se nærmere på nogle statiske og dynamiske sikkerhedskontroller for at se de ekstra værdi, de bringer.

Statisk sikkerhedskontrol

Statisk sikkerhedskontrol afhænger ikke af anmodningsvolumen eller tidligere anmodningsdata, da de normalt validerer meddelelsesdata i forhold til et foruddefineret sæt regler eller politikker. Forskellige statiske sikkerhedsscanninger udføres i gateways for blandt andet at blokere SQL-injektion, sammenhængende parsingangreb, enhedsudvidelsesangreb og skemaforgiftning.

I mellemtiden kan der også anvendes statisk politikkontrol til nyttelastsscanning, headerinspektion og adgangsmønstre. For eksempel er SQL-injektion en almindelig type angreb, der udføres ved hjælp af nyttelast. Hvis en bruger sender en JSON-nyttelast (JavaScript Object Notation), kan API-gatewayen validere denne særlige anmodning mod foruddefineret JSON-skema. Gatewayen kan også begrænse antallet af elementer eller andre attributter i indhold efter behov for at beskytte mod skadelige data eller tekstmønstre i meddelelser.

Dynamiske sikkerhedskontrol

I modsætning til statiske sikkerhedsscanninger kontrolleres dynamiske sikkerhedskontrol altid mod noget, der varierer over tid. Normalt involverer dette validering af anmodningsdata med beslutninger truffet ved hjælp af eksisterende data. Eksempler på dynamisk kontrol inkluderer validering af adgangstoken, detektion af uregelmæssigheder og begrænsning. Disse dynamiske kontroller afhænger stærkt af datavolumen, der sendes til gatewayen. Nogle gange forekommer disse dynamiske kontroller uden for API-gatewayen, og derefter meddeles beslutningerne til gatewayen. Lad os se på et par eksempler.

Begrænsning og hastighedsbegrænsning er vigtig for at reducere indvirkningen af ​​angreb, for når angribere får adgang til API'er, er det første, de gør, at læse så mange data som muligt. Begrænsning af API-anmodninger - dvs. begrænsning af adgangen til dataene - kræver, at vi holder et antal optagelser inden for et bestemt tidsvindue. Hvis et antal anmodninger overstiger det tildelte beløb på det tidspunkt, kan gatewayen blokere API-opkald. Med satsbegrænsning kan vi begrænse den samtidige adgang, der er tilladt for en given tjeneste.

Godkendelse

Godkendelse hjælper API-gateways med at identificere hver bruger, der påberåber sig en unik API. Tilgængelige API-gatewayløsninger understøtter generelt grundlæggende godkendelse, OAuth 2.0, JWT (JSON Web Token) sikkerhed og certifikatbaseret sikkerhed. Nogle gateways giver også et autentificeringslag ud over det for yderligere finkornet tilladelsesvalidering, som normalt er baseret på XACML-stil (eXtensible Access Control Markup Language) sprogdefinitionssprog. Dette er vigtigt, når en API indeholder flere ressourcer, der har brug for forskellige niveauer af adgangskontrol for hver ressource.

Begrænsninger af traditionel API-sikkerhed

Politikbaserede tilgange omkring godkendelse, autorisation, hastighedsbegrænsning og begrænsning er effektive værktøjer, men de efterlader stadig revner, hvorigennem hackere kan udnytte API'er. Navnlig er API-gateways foran flere webtjenester, og de API'er, de administrerer, indlæses ofte med et stort antal sessioner. Selv hvis vi analyserede alle disse sessioner ved hjælp af politikker og processer, ville det være vanskeligt for en gateway at inspicere enhver anmodning uden yderligere beregningskraft.

Derudover har hver API sit eget adgangsmønster. Så et legitimt adgangsmønster for en API kan indikere ondsindet aktivitet for en anden API. For eksempel, når nogen køber varer gennem en online shoppingapplikation, foretager de flere søgninger, før de foretager købet. Så en enkelt bruger, der sender 10 til 20 anmodninger til en søgning API inden for en kort periode, kan være et legitimt adgangsmønster for et søgning API. Men hvis den samme bruger sender flere anmodninger til købs-API'en, kan adgangsmønsteret indikere ondsindet aktivitet, såsom en hacker, der prøver at trække så meget som muligt ud ved hjælp af et stjålet kreditkort. Derfor skal hvert API-adgangsmønster analyseres separat for at bestemme det korrekte svar.

Endnu en faktor er, at et betydeligt antal angreb sker internt. Her bruger brugere med gyldig legitimationsoplysninger og adgang til systemer deres evne til at angribe disse systemer. Politikbaseret godkendelses- og godkendelsesfunktioner er ikke designet til at forhindre denne slags angreb.

Selvom vi kunne anvende flere regler og politikker på en API-gateway for at beskytte mod de angreb, der er beskrevet her, ville den ekstra overhead på API-gatewayen være uacceptabel. Virksomheder har ikke råd til at frustrere ægte brugere ved at bede dem om at bære behandlingsforsinkelser for deres API-gateways. I stedet skal gateways behandle gyldige anmodninger uden at blokere eller bremse bruger-API-opkald.

Sagen til tilføjelse af et AI-sikkerhedslag

For at udfylde revnerne efter politikbaseret API-beskyttelse har moderne sikkerhedsteam brug for kunstig intelligensbaseret API-sikkerhed, der kan opdage og reagere på dynamiske angreb og de unikke sårbarheder i hver API. Ved at anvende AI-modeller til løbende at inspicere og rapportere om alle API-aktiviteter kunne virksomheder automatisk opdage unormale API-aktiviteter og trusler på tværs af API-infrastrukturer, som traditionelle metoder savner.

Selv i tilfælde, hvor standard sikkerhedsforanstaltninger er i stand til at opdage uregelmæssigheder og risici, kan det tage måneder at foretage opdagelserne. I modsætning hertil ville et AI-drevet sikkerhedslag ved hjælp af forudbyggede modeller baseret på brugeradgangsmønstre gøre det muligt at opdage nogle angreb i næsten realtid.

Det er vigtigt, at AI-motorer normalt kører uden for API-gateways og kommunikerer deres beslutninger til dem. Da API-gatewayen ikke behøver at bruge ressourcer på at behandle disse anmodninger, påvirker tilføjelsen af ​​AI-sikkerhed typisk ikke runtime-ydeevnen.

Integrering af politikbaseret og AI-drevet API-sikkerhed

Når du tilføjer AI-drevet sikkerhed til en API-ledelsesimplementering, vil der være et sikkerhedshåndhævelsespunkt og et beslutningspunkt. Typisk er disse enheder uafhængige på grund af den krævede høje beregningsstyrke, men latenstiden bør ikke få lov til at påvirke deres effektivitet.

API-gatewayen opfanger API-anmodninger og anvender forskellige politikker. Koblet til det er sikkerhedshåndhævelsespunktet, der beskriver attributterne for hver anmodning (API-opkald) til beslutningspunktet, anmoder om en sikkerhedsbeslutning og derefter håndhæver beslutningen i gatewayen. Beslutningspunktet, der er drevet af AI, lærer løbende opførelsen af ​​hvert API-adgangsmønster, registrerer uregelmæssig adfærd og markerer forskellige attributter for anmodningen.

Der bør være en mulighed for at tilføje politikker til beslutningspunktet efter behov og påberåbe sig disse politikker - som kan variere fra API til API - i løbet af læringsperioden. Enhver politik skal defineres af sikkerhedsteamet, når de potentielle sårbarheder i hver API, de planlægger at eksponere, er grundigt forstået. Men selv uden støtte fra eksterne politikker vil adaptiv, AI-drevet beslutningspunkt og håndhævelsespunktteknologi i sidste ende lære og forhindre nogle af de komplekse angreb, som vi ikke kan opdage med politikker.

En anden fordel ved at have to separate sikkerhedshåndhævelsespunkter og beslutningspunkter er evnen til at integrere med eksisterende API-styringsløsninger. En simpel forbedring af brugergrænsefladen og tilpasset udvidelse kan integrere sikkerhedshåndhævelsespunktet til API-udgiveren og gatewayen. Fra brugergrænsefladen kunne API-udgiveren vælge, om AI-sikkerhed for den offentliggjorte API skulle aktiveres sammen med eventuelle specielle politikker, der var nødvendige. Det udvidede sikkerhedshåndhævelsespunkt vil offentliggøre anmodningsattributterne til beslutningspunktet og begrænse adgangen til API'en i henhold til beslutningspunktets svar.

At offentliggøre begivenheder til beslutningspunktet og begrænse adgangen baseret på dets svar vil dog tage tid og afhænger meget af netværket. Derfor implementeres det bedst asynkront ved hjælp af en cachemekanisme. Dette vil påvirke nøjagtigheden lidt, men når man overvejer effektiviteten af ​​gatewayen, vil tilføjelse af et AI-sikkerhedslag minimalt bidrage til den samlede latenstid.

AI-drevet sikkerhedslag udfordringer

Naturligvis kommer fordele ikke uden omkostninger. Mens et AI-drevet sikkerhedslag tilbyder et ekstra niveau af API-beskyttelse, præsenterer det nogle udfordringer, som sikkerhedsteams skal løse.

  • Ekstra omkostninger. Det ekstra AI-sikkerhedslag tilføjer noget overhead til meddelelsesflowet. Så mæglingsløsninger skal være smarte nok til at håndtere informationsindsamling og offentliggørelse uden for den vigtigste mæglingsstrøm.
  • Falske positive. En stor mængde falske positive kræver yderligere gennemgang af sikkerhedsprofessionelle. Men med nogle avancerede AI-algoritmer kan vi reducere antallet af falske positive udløst.
  • Mangel på tillid. Folk føler sig ubehagelige, når de ikke forstår, hvordan en beslutning blev taget. Dashboards og alarmer kan hjælpe brugerne med at visualisere faktorer bag en beslutning. For eksempel, hvis en advarsel tydeligt angiver, at en bruger blev blokeret for at få adgang til systemet med en unormal hastighed på mere end 1.000 gange inden for et minut, kan folk forstå og stole på systemets beslutning.
  • Datasårbarhed. De fleste AI- og maskinlæringsløsninger er afhængige af store datamængder, som ofte er følsomme og personlige. Som et resultat kan disse løsninger blive udsat for databrud og identitetstyveri. Overholdelse af Den Europæiske Unions GDPR (generel databeskyttelsesforordning) hjælper med at mindske denne risiko, men eliminerer den ikke helt.
  • Mærkede databegrænsninger. De mest kraftfulde AI-systemer trænes gennem overvåget læring, som kræver mærket data, der er organiseret for at gøre det forståeligt af maskiner. Men mærkede data har grænser, og den fremtidige automatiserede oprettelse af stadig vanskeligere algoritmer vil kun forværre problemet.
  • Defekte data. Et AI-systems effektivitet afhænger af de data, det trænes i. Alt for ofte er dårlige data forbundet med etniske, kommunale, kønlige eller racemæssige fordomme, som kan påvirke afgørende beslutninger om individuelle brugere.

I betragtning af API'ernes kritiske rolle i virksomheder i dag bliver de i stigende grad mål for hackere og ondsindede brugere. Politikbaserede mekanismer, såsom godkendelse, godkendelse, nyttelastsscanning, skemavalidering, begrænsning og hastighedsbegrænsning, er grundlæggende krav til implementering af en vellykket API-sikkerhedsstrategi. Imidlertid er det kun ved at tilføje AI-modeller til løbende at inspicere og rapportere om al API-aktivitet, at virksomheder beskyttes mod de mest sofistikerede sikkerhedsangreb, der opstår i dag.

Sanjeewa Malalgoda er softwarearkitekt og associeret direktør for teknik hos WSO2, hvor han leder udviklingen af ​​WSO2 API Manager. Lakshitha Gunasekara er softwareingeniør i WSO2 API Manager-teamet.

New Tech Forum giver et sted at udforske og diskutere nye virksomhedsteknologier i hidtil uset dybde og bredde. Valget er subjektivt baseret på vores valg af de teknologier, som vi mener er vigtige og af største interesse for læserne. accepterer ikke markedsføringssikkerhed til offentliggørelse og forbeholder sig retten til at redigere alt bidraget indhold. Send alle henvendelser til[email protected].

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