Digitalna ekonomija, ki vse bolj temelji na tehnologiji, zahteva uporabo aplikacijskih programskih vmesnikov (API-jev) za povezovanje aplikacijskih storitev s strankami, potrošniki, partnerji in zaposlenimi. Tradicionalne, posodobljene in nove aplikacije se razvijajo v smeri arhitektur, ki temeljijo na API-jih, da bi pospešile razvoj aplikacij in zmanjšale čas do trženja. Približevanje funkcionalnosti aplikacij strankam za zmanjšanje trenja je izvor decentraliziranih arhitektur in gibanja API-first.
Na žalost se učinkovitost, pridobljena z API-ji v razvoju aplikacij, vse bolj zasenčuje z riziki, ki jih prinašajo za IT podjetja. Hekerji so spoznali, da je kompromitiranje API-jev enostavno, če so ti slabo zaščiteni ali celo nezaščiteni. Nihče ne bi trdil, da API-ji ne potrebujejo varnih praks, vendar v industriji ni soglasja o najboljšem načinu njihove zaščite. V nadaljevanju so navedeni nekateri ključni razlogi, zakaj API-ji potrebujejo večjo zaščito, kot jo običajno prejmejo.
Neobravnavane ranljivosti API-jev
Vedno večje število pomembnih varnostnih kršitev zaradi slabe vidljivosti in varnosti API-jev se dogaja in se bo nadaljevalo v bližnji prihodnosti. Poglobljena digitalizacija organizacij bo v produkcijo pripeljala več slabo zaščitenih API-jev. Mnoge organizacije bodo poskušale rešiti ranljivosti API-jev s pomočjo boljšega oblikovanja in kodiranja, vendar bodo ugotovile enake varnostne pomanjkljivosti kot pri aplikacijah na splošno. Delno zato, ker varnost ni osnovna kompetenca običajnega razvijalca aplikacij, varnostne ekipe pa morda niso seznanjene z vsemi medsebojnimi povezavami tretjih oseb znotraj njihovega okolja.
Pojav API sprawl-a
Jedro problema razširitve API-jev je pomanjkanje celovite strategije, ki vključuje upravljanje in najboljše prakse. Agilen razvoj aplikacij je privedel do več različic istega API-ja brez ustreznega nadzora nad različicami API-jev. Prehod na mikrostoritve povzroči, da aplikacija vsebuje več deset API-jev.
Neupravljani API-ji ustvarjajo senčne, “shadow” in “zombie” API-je. Do leta 2030 bo število API-jev doseglo 2 milijardi, kar bo problem še poslabšalo.
API prehodi niso dovolj za varnost API-jev v zapletenih ekosistemih
Danes je delovanje v porazdeljenem oblačnem okolju norma. Vendar pa uporaba namenskega API prehoda kot ene vstopne točke za nadzor varnosti ima svoje omejitve, vključno z enojnimi točkami okvare in poslabšanjem zmogljivosti. Ker so danes API prehodi ključna komponenta API infrastrukture, je postalo očitno, da razširitev API-jev povečuje uvedbo API prehodov – kar vodi do razširitve API prehodov.
Spletne požarne pregrade (WAF) le delno ščitijo API-je
Sodobne spletne požarne pregrade nudijo robustno zaščito in varnost za API protokole, vključno z GraphQL in gRPC, ter nudijo začasno rešitev za kritične programske ranljivosti – vendar pogosto ne nudijo potrebne opaznosti API-jev za zaznavanje naprednih groženj v hibridnih in večoblačnih arhitekturah. Mnoge spletne požarne pregrade nimajo dinamičnega odkrivanja API-jev, samodejnega zaznavanja in ublažitve groženj, testiranja ter avtomatizacije in izvajanja specifikacij dokumentov OpenAPI.
Kako zaščititi API-je?
Sedaj, ko vemo, zakaj hekerji obožujejo API-je, se vprašamo, kako jih lahko zaščitimo.
Uporaba predpisov in standardov za podporo projektom zaščite API-jev
Regulatorji so opazili tveganje, ki ga prinašajo API-ji, in spodbudili podjetja, da zmanjšajo svoje tveganje v celotnem IT okolju, vključno s tretjimi osebami. Ameriški oddelek za finance in Urad za finančno zaščito potrošnikov (CFPB) sta izdala močna priporočila za spoštovanje varnosti API-jev. S stališča standardov PCI DSS v4 zahteva varnost API-jev, NIST 800-95 Vodnik za varne spletne storitve pa priporoča varno upravljanje API-jev že od leta 2007 – NIST 800-24 Strategije varnosti za sisteme aplikacij na osnovi mikrostoritev natančno opredeljujejo varno upravljanje API-jev.
Poudarek na arhitekturi
Arhitektura varnosti API-jev mora upoštevati integracijo s porazdeljenim IT podjetjem, vključno z večoblaki, regionalnimi robovi in storitvenimi sloji. Rešitev mora biti uvedljiva na katerokoli strojno opremo, virtualizirano okolje, Docker, Kubernetes itd. Rešitev mora omogočati, da varnostne politike sledijo API-ju skozi njegov ekosistem. V nadaljevanju je primer referenčne arhitekture za zagotavljanje varnosti API-jev.
Končne misli
Hekerji so že dolgo časa spoznali, da API-ji trpijo enake varnostne pomanjkljivosti kot spletne aplikacije, vključno s šibkimi kontrolami avtentikacije in avtorizacije. Postali so vešči izkoriščanja ranljivosti API-jev, zlorabe poslovne logike in ustvarjanja “zero-day” napadov za dostop do IT podjetij z malo odpora.
Osebni podatki so last posameznika, ne aplikacije ali ponudnika storitev. Digitalna ekonomija spodbuja odprto deljenje podatkov. API-ji omogočajo zasebne, javne, partnerske in tretje osebe dostop do podatkov in storitev. API-ji potrebujejo tehnologije za ohranjanje zasebnosti, da bodo v skladu s predpisi o zasebnosti podatkov.
Uvajanje rešitve za varnost API-jev zahteva integracijo infrastrukture in povezovalnike, nekatere prilagojene za pravilno uvajanje v IT okolje. Razumevanje zapletenosti uvajanja zahteva načrtovanje arhitekture. Izbira rešitve, ki deluje neposredno znotraj obstoječe arhitekture IT podjetja, skrajša čas uvajanja.
Če želite izvedeti več o obrambi pred napadi na API-je, si pridobite nedavno poročilo, ki ga je naročil F5, Vodnik za vrednotenje rešitve za varnost API-jev. To poročilo obravnava najpomembnejše vidike izbire rešitve za zaščito API-jev.
[download_after_email id=”2355″]
