API sa stali korunovačným klenotom iniciatív organizácií v oblasti digitálnej transformácie, ktoré umožňujú zamestnancom, partnerom, zákazníkom a ďalším zainteresovaným stranám prístup k aplikáciám, dátam a obchodným funkciám v celom ich digitálnom ekosystéme. Niet teda divu, že hackeri zvýšili svoje vlny útokov na tieto kritické podnikové aktíva.
Bohužiaľ to vyzerá, že problém sa bude iba zhoršovať. Spoločnosť Gartner predpovedala, že „do roku 2022 bude zneužívanie API najčastejším vektorom útoku, ktorý bude mať za následok narušenie údajov pre podnikové webové aplikácie.“
Mnoho podnikov odpovedalo implementáciou riešení správy API, ktoré poskytujú mechanizmy, ako je autentifikácia, autorizácia a obmedzenie. Toto sú nevyhnutné schopnosti na kontrolu toho, kto a ako často pristupuje k API v celom ekosystéme API. Pri budovaní svojich interných a externých stratégií API však musia organizácie tiež riešiť rast sofistikovanejších útokov na API implementáciou dynamickej bezpečnosti riadenej umelou inteligenciou (AI).
Tento článok skúma nástroje na správu a zabezpečenie API, ktoré by organizácie mali používať na zabezpečenie bezpečnosti, integrity a dostupnosti v rámci svojich ekosystémov API.
Bezpečnostné opatrenia založené na pravidlách a politikách
Bezpečnostné kontroly založené na pravidlách a zásadách, ktoré je možné vykonávať staticky alebo dynamicky, sú povinnou súčasťou každého riešenia správy API. Brány API slúžia ako hlavný vstupný bod pre prístup k rozhraniu API, a preto zvyčajne zabezpečujú vynucovanie politiky kontrolou prichádzajúcich žiadostí v porovnaní s politikami a pravidlami súvisiacimi so zabezpečením, obmedzeniami rýchlosti, obmedzovaním atď. Pozrime sa bližšie na niektoré statické a dynamické kontroly zabezpečenia, aby sme videli ďalšie hodnotu, ktorú prinášajú.
Statické bezpečnostné kontroly
Statické kontroly bezpečnosti nezávisia od objemu žiadosti ani od údajov predchádzajúcej žiadosti, pretože zvyčajne overujú údaje správ podľa vopred definovanej sady pravidiel alebo politík. V bránach sa vykonávajú rôzne statické kontroly zabezpečenia, aby sa blokovalo vstrekovanie SQL, útoky súdržnej syntaktickej analýzy, útoky na rozšírenie entity a otrava schémy.
Medzitým možno statické kontroly politiky okrem iného použiť na skenovanie užitočného zaťaženia, kontrolu hlavičiek a prístupové vzory. Napríklad injekcia SQL je bežným typom útoku uskutočňovaného pomocou užitočného zaťaženia. Ak používateľ odošle užitočné zaťaženie JSON (JavaScript Object Notation), brána API môže overiť túto konkrétnu požiadavku na preddefinovanú schému JSON. Brána tiež môže podľa potreby obmedziť počet prvkov alebo iných atribútov obsahu na ochranu pred škodlivými údajmi alebo textovými vzormi v správach.
Dynamické bezpečnostné kontroly
Dynamické bezpečnostné kontroly, na rozdiel od statických bezpečnostných skenov, vždy porovnávajú s niečím, čo sa časom mení. Spravidla to zahŕňa overenie údajov žiadosti s rozhodnutiami prijatými pomocou existujúcich údajov. Medzi príklady dynamických kontrol patrí overenie prístupového tokenu, detekcia anomálií a obmedzenie. Tieto dynamické kontroly veľmi závisia od objemu údajov odosielaných na bránu. Niekedy sa tieto dynamické kontroly vyskytujú mimo bránu API a potom sa rozhodnutia komunikujú s bránou. Pozrime sa na pár príkladov.
Škrtenie a obmedzenie rýchlosti sú dôležité pre zníženie dopadu útokov, pretože kedykoľvek útočníci získajú prístup k API, prvá vec, ktorú urobia, je prečítať čo najviac údajov. Škrtenie požiadaviek API - t. J. Obmedzenie prístupu k údajom - vyžaduje, aby sme udržali počet prichádzajúcich požiadaviek v konkrétnom časovom okne. Ak počet požiadaviek prekročí v danom čase pridelené množstvo, brána môže blokovať volania API. S obmedzením rýchlosti môžeme obmedziť súčasný prístup povolený pre danú službu.
Overenie
Autentifikácia pomáha bránam API identifikovať každého používateľa, ktorý jedinečne vyvolá API. Dostupné riešenia brány API všeobecne podporujú základné overovanie, OAuth 2.0, zabezpečenie JWT (JSON Web Token) a zabezpečenie založené na certifikáte. Niektoré brány navyše poskytujú vrstvu overovania pre ďalšie podrobnejšie overenie povolení, ktoré je zvyčajne založené na jazykoch definície politiky v štýle XACML (eXtensible Access Control Markup Language). To je dôležité, keď API obsahuje viac zdrojov, ktoré vyžadujú rôzne úrovne riadenia prístupu pre každý zdroj.
Obmedzenia tradičného zabezpečenia API
Politické prístupy týkajúce sa autentifikácie, autorizácie, obmedzenia rýchlosti a škrtenia sú účinnými nástrojmi, ale stále nechávajú trhliny, cez ktoré môžu hackeri využívať API. Brány API sú predovšetkým popredné webové služby a API, ktoré spravujú, sú často načítané s veľkým počtom relácií. Aj keby sme všetky tieto relácie analyzovali pomocou zásad a procesov, pre bránu by bolo ťažké skontrolovať každú požiadavku bez dodatočnej výpočtovej sily.
Každé API má navyše svoj vlastný prístupový vzor. Takže legitímny prístupový vzor pre jedno API môže naznačovať škodlivú aktivitu pre iné API. Napríklad, keď niekto kupuje položky prostredníctvom aplikácie na nakupovanie online, pred uskutočnením nákupu vykoná viacnásobné vyhľadávanie. Jediný používateľ, ktorý v krátkom čase pošle 10 až 20 požiadaviek na vyhľadávacie rozhranie API, môže byť legitímnym prístupovým vzorom pre vyhľadávacie rozhranie API. Ak však ten istý používateľ pošle nákupnému API viac požiadaviek, vzor prístupu môže naznačovať škodlivú aktivitu, napríklad hacker, ktorý sa snaží čo najviac vybrať pomocou ukradnutej kreditnej karty. Preto je potrebné každý prístupový vzor API analyzovať osobitne, aby sa určila správna odpoveď.
Ďalším faktorom je, že sa interne vyskytujú značné počty útokov. Tu používatelia s platnými povereniami a prístupom do systémov využívajú svoju schopnosť útočiť na tieto systémy. Schopnosti autentifikácie a autorizácie založené na politikách nie sú navrhnuté tak, aby zabránili týmto druhom útokov.
Aj keby sme na bránu API mohli použiť viac pravidiel a politík na ochranu pred tu opísanými útokmi, ďalšie režijné náklady na bránu API by boli neprijateľné. Podniky si nemôžu dovoliť frustrovať skutočných používateľov tým, že ich požiadajú, aby znášali oneskorenia pri spracovaní svojich brán API. Namiesto toho musia brány spracovávať platné požiadavky bez blokovania alebo spomaľovania hovorov používateľských rozhraní API.
Prípad pridania bezpečnostnej vrstvy AI
Aby vyplnili medzery, ktoré zanechali ochrany API založené na zásadách, potrebujú moderné bezpečnostné tímy zabezpečenie API založené na umelej inteligencii, ktoré dokáže detekovať a reagovať na dynamické útoky a jedinečné zraniteľnosti každého API. Aplikáciou modelov AI na nepretržitú kontrolu a správu o všetkých činnostiach API mohli podniky automaticky odhaliť anomálnu aktivitu API a hrozby naprieč infraštruktúrami API, ktoré tradičným metódam chýbajú.
Aj v prípadoch, keď sú štandardné bezpečnostné opatrenia schopné odhaliť anomálie a riziká, môže odhalenie trvať aj mesiace. Naopak, pomocou vopred pripravených modelov založených na vzoroch prístupu používateľov by vrstva zabezpečenia založená na umelej inteligencii umožnila detekovať niektoré útoky takmer v reálnom čase.
Dôležité je, že motory AI zvyčajne bežia mimo brán API a komunikujú s nimi svoje rozhodnutia. Pretože brána API nemusí vynakladať prostriedky na spracovanie týchto požiadaviek, pridanie zabezpečenia AI zvyčajne nemá vplyv na výkon za behu.
Integrácia zabezpečenia API založeného na zásadách a AI
Pri pridávaní zabezpečenia na báze AI k implementácii správy API bude existovať bod presadzovania zabezpečenia a bod rozhodnutia. Typicky sú tieto jednotky nezávislé kvôli vysokému požadovanému výpočtovému výkonu, ale nemalo by sa dovoliť, aby latencia ovplyvňovala ich účinnosť.
Brána API zachytáva požiadavky API a uplatňuje rôzne politiky. S ním je spojený bod vynútiteľnosti zabezpečenia, ktorý popisuje atribúty každej žiadosti (volanie API) k rozhodovaciemu bodu, požaduje bezpečnostné rozhodnutie a potom vynúti toto rozhodnutie v bráne. Rozhodovací bod založený na umelej inteligencii sa neustále učí správanie každého prístupového vzoru API, detekuje anomálne správanie a označuje rôzne atribúty požiadavky.
Mala by existovať možnosť pridať politiky do rozhodovacieho bodu podľa potreby a vyvolať tieto politiky - ktoré sa môžu líšiť od API k API - počas obdobia učenia. Po dôkladnom pochopení potenciálnych zraniteľností každého API, ktoré plánujú vystaviť, by mal bezpečnostný tím definovať akékoľvek politiky. Avšak aj bez podpory externých politík sa adaptívna technológia rozhodovacieho bodu a bodu vynútenia založená na AI nakoniec naučí a zabráni niektorým zložitým útokom, ktoré pomocou politík nedokážeme odhaliť.
Ďalšou výhodou dvoch samostatných komponentov bodu zabezpečenia a rozhodovacieho bodu je schopnosť integrácie s existujúcimi riešeniami správy API. Jednoduché vylepšenie používateľského rozhrania a prispôsobené rozšírenie by mohlo integrovať bod vynucovania zabezpečenia do vydavateľa API a do brány. Z používateľského rozhrania si vydavateľ API mohol zvoliť, či má pre zverejnené API povoliť zabezpečenie umelej inteligencie spolu so všetkými potrebnými špeciálnymi politikami. Rozšírený bod presadzovania bezpečnosti by zverejnil atribúty požiadavky k rozhodovaciemu bodu a obmedzil prístup k API podľa odpovede rozhodovacieho bodu.
Publikovanie udalostí do rozhodovacieho bodu a obmedzenie prístupu na základe jeho odpovede však bude trvať určitý čas a bude závisieť do veľkej miery od siete. Preto je najlepšie ho implementovať asynchrónne pomocou mechanizmu vyrovnávacej pamäte. To trochu ovplyvní presnosť, ale keď vezmeme do úvahy efektívnosť brány, pridanie bezpečnostnej vrstvy AI minimálne prispeje k celkovej latencii.
Výzvy bezpečnostnej vrstvy riadené umelou inteligenciou
Výhody samozrejme neprichádzajú bez nákladov. Aj keď bezpečnostná vrstva riadená umelou inteligenciou ponúka ďalšiu úroveň ochrany API, predstavuje niektoré výzvy, ktorým sa budú musieť bezpečnostné tímy venovať.
- Dodatočná réžia. Dodatočná bezpečnostná vrstva AI zvyšuje tok správ. Mediačné riešenia by teda mali byť dostatočne inteligentné na to, aby zvládli zhromažďovanie a zverejňovanie informácií mimo hlavného mediačného toku.
- Falošné pozitíva. Veľké množstvo falošných poplachov si bude vyžadovať ďalšie preskúmanie bezpečnostnými odborníkmi. Pomocou niektorých pokročilých algoritmov AI však môžeme znížiť počet spustených falošných poplachov.
- Nedostatok dôvery. Ľudia sa cítia nepríjemne, keď nechápu, ako bolo rozhodnuté. Informačné panely a výstrahy môžu používateľom pomôcť vizualizovať si faktory, ktoré stoja za rozhodnutím. Napríklad, ak sa v upozornení jasne uvádza, že používateľ bol zablokovaný kvôli prístupu do systému neobvyklou rýchlosťou viac ako 1 000-krát za minútu, ľudia môžu pochopiť a dôverovať rozhodnutiu systému.
- Zraniteľnosť údajov. Väčšina riešení umelej inteligencie a strojového učenia sa spolieha na obrovské objemy dát, ktoré sú často citlivé a osobné. Vo výsledku by tieto riešenia mohli byť náchylné na narušenie údajov a krádež identity. Dodržiavanie Európskej únie GDPR (všeobecné nariadenie o ochrane údajov) pomáha toto riziko zmierniť, ale úplne ho nevylučuje.
- Obmedzenia označených údajov. Najvýkonnejšie systémy umelej inteligencie sa trénujú pomocou supervidovaného učenia, ktoré vyžaduje označené údaje, ktoré sú usporiadané tak, aby boli strojom zrozumiteľné. Označené údaje však majú svoje limity a budúce automatické vytváranie čoraz zložitejších algoritmov tento problém iba prehĺbi.
- Chybné údaje. Účinnosť systému AI závisí od údajov, na ktorých je trénovaný. Zlé údaje sú príliš často spojené s etnickými, komunálnymi, rodovými alebo rasovými predsudkami, ktoré môžu mať vplyv na rozhodujúce rozhodnutia o jednotlivých používateľoch.
Vzhľadom na rozhodujúcu úlohu API v dnešných podnikoch sa čoraz častejšie stávajú terčmi hackerov a škodlivých používateľov. Mechanizmy založené na pravidlách, ako napríklad autentifikácia, autorizácia, skenovanie užitočného zaťaženia, overenie schémy, obmedzenie a obmedzenie rýchlosti, sú základnými požiadavkami na implementáciu úspešnej stratégie zabezpečenia API. Avšak iba pridaním modelov AI k neustálej kontrole a reportovaniu všetkých aktivít API budú podniky chránené pred najsofistikovanejšími bezpečnostnými útokmi, ktoré sa dnes objavujú.
Sanjeewa Malalgoda je softvérový architekt a pomocný riaditeľ pre inžinierstvo vo WSO2, kde vedie vývoj manažéra WSO2 API. Lakshitha Gunasekara je softvérový inžinier v tíme WSO2 API Manager.
—
Nové technologické fórum poskytuje miesto na preskúmanie a diskusiu o vznikajúcich podnikových technológiách v nebývalej hĺbke a šírke. Výber je subjektívny, založený na našom výbere technológií, ktoré považujeme za dôležité a pre čitateľov najväčší záujem. neprijíma marketingové záruky na zverejnenie a vyhradzuje si právo upravovať všetok prispievaný obsah. Všetky otázky posielajte na adresu[email protected].
