Programování

Jak AI zlepší zabezpečení API

Rozhraní API se staly korunovačním klenotem iniciativ digitálních transformací organizací, které zaměstnancům, partnerům, zákazníkům a dalším zúčastněným stranám umožňují přístup k aplikacím, datům a podnikovým funkcím v celém jejich digitálním ekosystému. Není tedy divu, že hackeři zvýšili vlnu útoků na tato kritická podniková aktiva.

Bohužel to vypadá, že se problém jen zhorší. Gartner předpovídal, že „do roku 2022 bude zneužívání API nejčastějším vektorem útoku, který povede k narušení dat u podnikových webových aplikací.“

Mnoho podniků reagovalo implementací řešení pro správu API, která poskytují mechanismy, jako je ověřování, autorizace a omezování. Toto jsou funkce, které musíte mít, abyste mohli kontrolovat, kdo přistupuje k API v celém ekosystému API - a jak často. Při budování svých interních a externích strategií API však musí organizace také řešit růst sofistikovanějších útoků na API implementací dynamického zabezpečení řízeného umělou inteligencí (AI).

Tento článek zkoumá nástroje pro správu a zabezpečení API, které by organizace měly začlenit, aby zajistily zabezpečení, integritu a dostupnost napříč svými ekosystémy API.

Bezpečnostní opatření založená na pravidlech a zásadách

Kontroly zabezpečení založené na pravidlech a zásadách, které lze provádět staticky nebo dynamicky, jsou povinnou součástí jakéhokoli řešení pro správu API. Brány API slouží jako hlavní vstupní bod pro přístup k API, a proto obvykle zpracovávají vynucování zásad kontrolou příchozích požadavků na zásady a pravidla týkající se zabezpečení, omezení rychlosti, omezení atd. Podívejme se blíže na některé statické a dynamické kontroly zabezpečení, abychom viděli další hodnotu, kterou přinášejí.

Statické bezpečnostní kontroly

Statické kontroly zabezpečení nezávisí na objemu požadavku ani na žádných datech předchozího požadavku, protože obvykle ověřují data zprávy podle předdefinované sady pravidel nebo zásad. V branách se provádějí různé statické kontroly zabezpečení, které mimo jiné blokují injektování SQL, soudržné parsovací útoky, útoky na rozšíření entit a otravu schématu.

Mezitím lze statické kontroly zásad použít mimo jiné pro skenování užitečného zatížení, kontrolu záhlaví a přístupové vzory. Například SQL injection je běžný typ útoku prováděného pomocí užitečných dat. Pokud uživatel odešle užitečné zatížení JSON (JavaScript Object Notation), může brána API ověřit tento konkrétní požadavek podle předdefinovaného schématu JSON. Brána také může podle potřeby omezit počet prvků nebo jiných atributů v obsahu k ochraně před škodlivými daty nebo textovými vzory ve zprávách.

Dynamické bezpečnostní kontroly

Dynamické kontroly zabezpečení na rozdíl od statických prověřování zabezpečení vždy porovnávají s něčím, co se časem mění. Obvykle to zahrnuje ověření dat požadavku na základě rozhodnutí učiněných pomocí existujících dat. Mezi příklady dynamických kontrol patří ověření přístupového tokenu, detekce anomálií a omezení. Tyto dynamické kontroly silně závisí na objemu dat odesílaných do brány. Někdy se tyto dynamické kontroly vyskytují mimo bránu API a poté se rozhodnutí komunikují s bránou. Podívejme se na několik příkladů.

Omezení a omezení rychlosti jsou důležité pro snížení dopadu útoků, protože kdykoli útočníci získají přístup k API, první věcí, kterou udělají, je načíst co nejvíce dat. Omezení požadavků API - tj. Omezení přístupu k datům - vyžaduje, abychom udrželi počet příchozích požadavků v konkrétním časovém okně. Pokud počet požadavků v té době překročí přidělenou částku, brána může blokovat volání API. S omezením rychlosti můžeme omezit souběžný přístup povolený pro danou službu.

Ověření

Ověřování pomáhá bránám API identifikovat každého uživatele, který jedinečným způsobem vyvolá API. Dostupná řešení brány API obecně podporují základní ověřování, OAuth 2.0, zabezpečení JWT (JSON Web Token) a zabezpečení založené na certifikátech. Některé brány navíc poskytují vrstvu ověřování pro další jemně ověřené ověření oprávnění, které je obvykle založeno na jazycích definice zásad stylu XACML (eXtensible Access Control Markup Language). To je důležité, když API obsahuje více prostředků, které vyžadují různé úrovně řízení přístupu pro každý prostředek.

Omezení tradičního zabezpečení API

Přístupy založené na zásadách kolem ověřování, autorizace, omezování rychlosti a omezování jsou účinnými nástroji, ale stále zanechávají trhliny, kterými mohou hackeři využívat API. Je pozoruhodné, že brány API stojí před více webovými službami a rozhraní API, která spravují, jsou často načtena s vysokým počtem relací. I kdybychom všechny tyto relace analyzovali pomocí zásad a procesů, pro bránu by bylo obtížné zkontrolovat každý požadavek bez další výpočetní síly.

Každé API má navíc svůj vlastní vzor přístupu. Legitimní přístupový vzor pro jedno API by tedy mohl naznačovat škodlivou aktivitu pro jiné API. Například když někdo kupuje zboží prostřednictvím aplikace pro online nakupování, provede před nákupem několik vyhledávání. Jediný uživatel, který během krátké doby pošle 10 až 20 požadavků na vyhledávací API, tedy může být legitimním přístupovým vzorem pro vyhledávací API. Pokud však stejný uživatel odešle více požadavků na nákupní rozhraní API, přístupový vzor může naznačovat škodlivou aktivitu, například hacker, který se snaží co nejvíce stáhnout pomocí ukradené kreditní karty. Proto je třeba každý přístupový vzor API analyzovat samostatně, aby se určila správná odpověď.

Ještě dalším faktorem je, že interně dochází k významnému počtu útoků. Zde uživatelé s platnými pověřeními a přístupem k systémům využívají své schopnosti k útoku na tyto systémy. Funkce ověřování a autorizace založené na zásadách nejsou navrženy tak, aby zabránily těmto druhům útoků.

I kdybychom mohli na bránu API použít více pravidel a zásad k ochraně proti zde popsaným útokům, další režie na bráně API by byla nepřijatelná. Podniky si nemohou dovolit frustrovat skutečné uživatele tím, že je požádají, aby nesli zpoždění zpracování jejich bran API. Místo toho musí brány zpracovávat platné požadavky bez blokování nebo zpomalení volání API uživatele.

Případ přidání vrstvy zabezpečení AI

Aby vyplnily trhliny, které zanechaly ochrany API založené na zásadách, moderní bezpečnostní týmy potřebují zabezpečení API založené na umělé inteligenci, které dokáže detekovat a reagovat na dynamické útoky a jedinečné zranitelnosti každého API. Díky použití modelů AI k nepřetržité kontrole a hlášení všech aktivit API by podniky mohly automaticky objevit neobvyklou aktivitu API a hrozby napříč infrastrukturami API, které tradiční metody postrádají.

I v případech, kdy jsou standardní bezpečnostní opatření schopna detekovat anomálie a rizika, může objevy trvat měsíce. Naproti tomu pomocí předem připravených modelů založených na vzorcích přístupu uživatelů by vrstva zabezpečení řízená umělou inteligencí umožnila detekovat některé útoky téměř v reálném čase.

Důležité je, že motory AI obvykle běží mimo brány API a sdělují jim svá rozhodnutí. Protože brána API nemusí vynakládat prostředky na zpracování těchto požadavků, přidání zabezpečení AI obvykle nemá vliv na běhový výkon.

Integrace zabezpečení API založeného na zásadách a AI

Když přidáte zabezpečení založené na AI do implementace správy API, bude existovat bod vynucování zabezpečení a rozhodovací bod. Tyto jednotky jsou obvykle nezávislé kvůli vysokému požadovanému výpočetnímu výkonu, ale latence by neměla mít vliv na jejich účinnost.

Brána API zachycuje požadavky API a aplikuje různé zásady. Propojený s ním je bod vynucování zabezpečení, který popisuje atributy každého požadavku (volání API) na rozhodovací bod, požaduje rozhodnutí o zabezpečení a poté vynucuje toto rozhodnutí v bráně. Rozhodovací bod, založený na AI, se neustále učí chování každého přístupového vzoru API, detekuje anomální chování a označuje různé atributy požadavku.

Měla by existovat možnost přidat zásady do rozhodovacího bodu podle potřeby a vyvolat tyto zásady - které se mohou u jednotlivých API lišit - během období učení. Po důkladném porozumění potenciálním zranitelnostem každého API, které plánují vystavit, by měl bezpečnostní tým definovat jakékoli zásady. Avšak i bez podpory z externích zásad se adaptivní technologie rozhodovacích bodů a vynucovacích bodů na bázi AI nakonec naučí a zabrání některým komplexním útokům, které pomocí zásad nezjistíme.

Další výhodou dvou samostatných komponent vynucování zabezpečení a rozhodovacích bodů je schopnost integrace se stávajícími řešeními pro správu API. Jednoduché vylepšení uživatelského rozhraní a přizpůsobené rozšíření by mohlo integrovat bod vynucování zabezpečení do vydavatele API a brány. Z uživatelského rozhraní si vydavatel API mohl vybrat, zda povolit zabezpečení AI pro publikované API, spolu s jakýmikoli speciálními zásadami, které je třeba. Rozšířený bod vynucování zabezpečení by publikoval atributy požadavku do rozhodovacího bodu a omezil přístup k API podle odpovědi rozhodovacího bodu.

Publikování událostí do rozhodovacího bodu a omezení přístupu na základě jeho odezvy však bude nějakou dobu trvat a bude silně záviset na síti. Proto je nejlépe implementováno asynchronně pomocí mechanismu ukládání do mezipaměti. To trochu ovlivní přesnost, ale když vezmeme v úvahu efektivitu brány, přidání vrstvy zabezpečení AI minimálně přispěje k celkové latenci.

Výzvy bezpečnostní vrstvy založené na AI

Výhody samozřejmě nepřicházejí bez nákladů. Zatímco vrstva zabezpečení řízená umělou inteligencí nabízí další úroveň ochrany API, představuje některé výzvy, kterým se bezpečnostní týmy budou muset věnovat.

  • Další režie. Další vrstva zabezpečení AI přidává do toku zpráv určitou režii. Mediační řešení by tedy měla být dostatečně chytrá, aby zvládla shromažďování a publikování informací mimo hlavní mediační tok.
  • Falešné pozitivy. Velké množství falešných poplachů bude vyžadovat další kontrolu bezpečnostními profesionály. S některými pokročilými algoritmy AI však můžeme snížit počet spuštěných falešných poplachů.
  • Nedostatek důvěry. Lidé se cítí nepříjemně, když nechápou, jak bylo rozhodnuto. Řídicí panely a upozornění mohou uživatelům pomoci vizualizovat faktory, které stojí za rozhodnutím. Pokud například výstraha jasně uvádí, že uživatel byl blokován kvůli přístupu do systému neobvyklou rychlostí více než 1 000krát za minutu, lidé mohou rozhodnutí systému porozumět a důvěřovat mu.
  • Zranitelnost dat. Většina řešení pro umělou inteligenci a strojové učení se spoléhá na obrovské objemy dat, která jsou často citlivá a osobní. Ve výsledku by tato řešení mohla být náchylná k narušení dat a krádeži identity. Dodržování nařízení GDPR (obecné nařízení o ochraně osobních údajů) Evropské unie pomáhá toto riziko zmírnit, ale zcela ho nevylučuje.
  • Omezení označených dat. Nejvýkonnější systémy AI jsou trénovány pomocí supervizovaného učení, které vyžaduje označená data, která jsou organizována tak, aby byla strojům srozumitelná. Označená data však mají svá omezení a budoucí automatizovaná tvorba stále obtížnějších algoritmů problém jen prohloubí.
  • Chybná data. Efektivita systému AI závisí na datech, na kterých je trénován. Špatná data jsou příliš často spojována s etnickými, komunálními, genderovými nebo rasovými předsudky, což může ovlivnit zásadní rozhodnutí o jednotlivých uživatelích.

Vzhledem k zásadní roli API v dnešních podnicích se stále častěji stávají terčem hackerů a uživatelů se zlými úmysly. Mechanismy založené na zásadách, jako je ověřování, autorizace, skenování užitečné zátěže, ověření schématu, omezení a omezení rychlosti, jsou základní požadavky pro implementaci úspěšné strategie zabezpečení API. Pouze přidáním modelů AI k nepřetržité kontrole a hlášení o všech činnostech API však budou podniky chráněny před nejsofistikovanějšími bezpečnostními útoky, které se dnes objevují.

Sanjeewa Malalgoda je softwarový architekt a vedoucí technického inženýrství ve WSO2, kde vede vývoj WSO2 API Manager. Lakshitha Gunasekara je softwarový inženýr v týmu WSO2 API Manager.

Nové technologické fórum poskytuje místo, kde můžete prozkoumat a diskutovat o nově vznikajících podnikových technologiích v nebývalé hloubce a šíři. Výběr je subjektivní, založený na našem výběru technologií, které považujeme za důležité a pro čtenáře nejzajímavější. nepřijímá marketingové materiály ke zveřejnění a vyhrazuje si právo upravovat veškerý přispěný obsah. Všechny dotazy zasílejte na adresu[email protected].

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