Vmesni povezovalni člen

Programabilni vtičniki API so informatikom in razvijalcem omogočili, da med seboj povežejo najrazličnejše sisteme, aplikacije, storitve in vsebine. Prav zato nekateri sodobno digitalno gospodarstvo imenujejo kar gospodarstvo vtičnikov API. Zagotavljanje varnosti hiperpovezanih okolij je seveda velik izziv.

Dobrodošli med nevarnosti vedno bolj povezanega sveta. S tem, ko vedno več aplikacij dostopa do podatkov in informacij na najrazličnejših napravah in si izmenjuje podatke, se povečujejo tudi varnostna tveganja. Vtičniki API so se med razvijalci programske opreme praktično takoj prijeli, saj so jim omogočili, da njihovi programi dostopajo do podatkov praktično kjerkoli v internetu ali kakšnem krajevnem sistemu. Razmah programabilnih vtičnikov API so sprožile mobilne aplikacije, saj se prek njih povezujejo na najrazličnejše strežnike, kjer so shranjeni uporabnikovi podatki, dostopajo do storitev ipd. Spletne aplikacije prek omenjenih vtičnikov prejemajo informacije spletnih strani. Spletne trgovine pa vtičnike API uporabljajo zato, da redno osvežujejo razpoložljivost ali stanje zalog izdelkov pri dobaviteljih. Vtičniki so vedno pomembnejši tudi pri komunikaciji med podjetji. Z vidika tehnologije so zgolj navodila in protokoli, kako komunicirati s posameznim sistemom oziroma rešitvijo. S poslovnega vidika pa je njihova vloga bistveno pomembnejša – so način ustvarjanja ali dostavljanja (dodane) vrednosti.

»APIji so v zadnjih leti prerasli tehnološke okvirje in postali pomemben element digitalizacije. Še več, danes si digitalizacije oz. digitalne transformacije brez njih ne moremo zamisliti. Zato je za podjetja zelo pomembno, da razvijejo poslovne APIje, vzpostavijo mehanizme za njihovo izpostavljanje in upravljanje ter nadzor, osvojijo tehnologijo mikrostoritev na temelju oblačne arhitekture in – nenazadnje – APIje učinkovito integrirajo z zalednimi sistemi,« je povedal prof. dr. Matjaž B. Jurič.

Zadnja leta je raba vtičnikov API doživela absoluten razcvet, saj večina izdelovalcev programske opreme prek njih omogoča zunanjim razvijalcem in partnerjem dostop do (izbranih) podatkov in informacij ter snovanje inovativnih načinov rabe. Nekatera podjetja omenjene vtičnike uporabljajo celo za poenostavljeno interakcijo med poslovnimi uporabniki, predvsem za mobilni dostop do podatkov. Po zaslugi poenostavljenega dostopa do podatkov in spletnih funkcionalnosti vtičniki API podjetjem omogočajo agilnejše poslovne procese, hitrejše inoviranje in krajše razvojne cikle.

Tam, kjer so podatki, so tudi napadalci

Na lanski konferenci Black Hat Security Conference je podjetje Akana predstavilo ugotovitve lastne raziskave rabe vtičnikov API. Skoraj vsa podjetja (95 odstotkov) menijo, da so pomemben člen zagotavljanja rasti njihovega poslovanja, okoli 60 odstotkov izmed 1200 anketiranih podjetij jih že uporablja za dostop do podatkov iz drugih virov ali pa prek njih omogoča dostop do lastnih podatkov. Nič čudnega torej, da je priljubljenost vtičnikov API privabila tudi hekerje. Ti so prvo večjo »zmago« zaradi ranljivosti vtičnika API dosegli decembra 2013, ko so spletni storitvi Snapchat odtujili 4,6 milijona uporabniških imen in telefonskih številk. Po zaslugi razpoke v varnosti v svojem vtičniku API je pred dvema letoma napadalcem uspelo ukrasti podatke o okoli sto tisoč davkoplačevalcih, in to kar ameriški davčni upravi. Z vedno večjo razširjenostjo vtičnikov API gre pričakovati še več varnostnih incidentov, saj podjetja, ki jih šele uvajajo, pogosto ne poznajo vseh nevarnosti in mimogrede ustvarijo kakšno razpoko, ki jo v nadaljevanju izkoristijo napadalci.

Strokovnjake IT najbolj skrbi trojica napadov, ki merijo na šibke točke vmesnikov API. Že omenjeno podjetje Akana je razkrilo, da napadalci prek vtičnikov API spletnim strežnikom najraje podtaknejo t. i. bombo XML. Ta izkorišča ranljivost XML, ki navzven morebiti ni dostopna napadalcu, zato oblikujejo posebno kodo in jo prek vmesnika API pošljejo do strežnika, da bi ga preobremenili (zaradi tega lahko tudi neha delovati). Druga nevarnost so napadi z zavrnitvijo storitve (DoS), kjer podobno vstavljena koda preobremeni pasovno širino strežnika in ga naredi neodzivnega. Tretji najpogostejši napad pa je skrivanje t. i. SQL-injicirane kode v klice vtičnika API, s katerimi napadalci napadajo zbirke podatkov podjetij. Informatike ti napadi seveda skrbijo, a kar 60 odstotkov podjetij praktično ne stori nič za varovanje prejemne strani, ki ji vtičnik API posreduje podatke – vse pogosteje so to mobilne aplikacije. Izdelovalci vtičnikov API, posebej tisti z nekaj izkušnjami, že sledijo vsem korakom ustreznega varovanja podatkov, toda naprave in aplikacije, ki jim ti vtičniki dostavijo podatke, te naprave slabše varujejo, če sploh.

Varnost in varovanje vtičnikov API je treba razumeti

Podjetja, ki menijo, da je vtičnike API moč varovati s pristopom »ena rešitev za vse«, se motijo. Razmišljanje, da se varnostna funkcija razlikuje le na strani uporabniške izkušnje uporabnika (kako bo vnesel uporabniško ime in geslo ali uporabil drug način avtentikacije), ni le napačno, temveč nevarno. Rešitve seveda so, celoten koncept varnosti vtičnikov API temelji na štirih predpostavkah – avtorizaciji, avtentikaciji, združevanju in delegiranju.

Podjetje, ki ima podatke, ji seveda želi zaščititi. A če svojim poslovnim partnerjem omogoča vtičnik API z dostopom do vseh podatkov, je to zanj prava mora. Analogija sefa z odprtimi vrati, ki kar kliče po tatvini. Podjetja k rabi vtičnikov API navadno pristopajo na dva načina, le redko pa uporabijo kombinacijo obojega, ki je še najbolj smiselna. Nekatera podjetja puščajo svoje sisteme in funkcionalnosti odprte, saj predpostavljajo, da imajo tisti, s katerimi si delijo podatke prek vtičnikov API, zgolj dobre namene. Spet druga so na nasprotnem bregu – dovolijo dostop do le določenega vira in obsega podatkov, pri tem pa onemogočijo vse druge funkcionalnosti vtičnika. Kot rečeno, je z vidika poslovanja najboljša rešitev nekaj vmes. Vtičnike API je treba že ustrezno načrtovati. Torej predvideti, do katerih podatkov bo druga stran dostopala, zakaj in kako, ter ji to omogočiti na način, da bodo vitalni deli sistema podjetja v kar najmanjši nevarnosti. Odjemalci nato v praksi prejmejo različne vloge, z njimi pa tudi dostop do podatkov in stopnjo odgovornosti.

»Zagotavljanje varnosti APIjev je zahtevna, a rešljiva naloga, ki ni popolnoma nova. Podjetja so svoje podatke izpostavljala že prej, prek storitev SOAP, še prej prek EDI, itd. Je pa res, da so predvsem REST APIji prinesli nova načela varovanja, ki jih je treba razumeti in pravilno uporabiti. OAuth2, OpenID Connect, strategije izmenjave žetonov, kombiniranje večstopenjskih avtentikacij, omejevanje dostopa itn. so prakse, ki APIjem, če jih uporabimo pravilno, zagotavljajo visoko stopnjo varnosti. Če v arhitekturo vključimo še prehod API, ki izvaja dodatne varnostne mehanizme, smo že precej varni,« je dodal prof. dr. Jurič.

Avtentikacija = identiteta

Avtentikacija uporabnika oziroma sistema ali aplikacije, ki želi prek vtičnika dostopati do našega sistema in podatkov, je temeljni del varnosti vtičnikov API. Težiti je treba k močnim metodam avtentikacije, minimalno k uporabniškim imenom in zahtevnim geslom. Strokovnjaki za varnost seveda priporočajo vsaj dvofaktorsko avtentikacijo, ki ob poskusu prijave v spletni sistem uporabniku na mobilno napravo pošlje še žeton, ključ ali geslo za enkratno prijavo in ga šele po vnosu tega dodatka spusti do podatkov oziroma storitve.

Avtorizacija = nivo dostopa

Avtorizacija je povsem druga raven varnosti, čeprav jo uporabniki včasih zamenjujejo z avtentikacijo. Avtentikacija, kot smo omenili, preveri, ali je tisti, ki želi dostop do naših podatkov, res tisti, za katerega se izdaja. Avtorizacija pa v sistemu preveri, kolikšna stopnja dostopa mu pripada, oziroma do katerih podatkov sploh ima dostop.

Razvijalci vtičnikov API na avtorizacijo pogosto pozabijo ali, še huje, med razvojem vtičnika nastavijo pravice za sistemskega skrbnika. Ta seveda lahko dostopa do vseh virov in podatkov in, če to nato uporabnikom omogoča končna različica vtičnika API, tak vtičnik je seveda za podjetje potencialno zelo nevaren. Praviloma namreč uporabnik potrebuje le zelo omejen nabor funkcij in virov.

Združevanje prijavnih podatkov (identitet)

Vtičniki API lahko povezujejo večje število sistemov, aplikacij, spletnih strani in storitev. Nekateri razvijalci vtičnikov API omogočajo uporabo enakih prijavnih podatkov za dostop do različnih povezanih strani oziroma storitev. Avtentikacija se seveda opravi le na prvi domeni, dostop do preostalih je omogočen na podlagi medsebojnega zaupanja. Tak pristop je v praksi redkejši, še najpogosteje ga uporabljajo ponudniki spletnih storitev za svoje storitve oziroma upravitelji več povezanih spletnih strani.

Delegiranje = predaja (omejenih) pravic

Delegiranje je še en proces, s katerim dostop in pravice podelimo avtoriziranim uporabnikom in obenem ohranimo njihov razmeroma omejen dostop. Združevanje pravic z uporabniškim žetonom deluje prek več domen, delegiranje pa deluje kot avtorizacija uporabnika, ki se v nadaljevanju obnaša kot drug, a še vedno s pravili omejen uporabnik.

Pod črto so načela zagotavljanja varnosti vtičnikov API zelo dobro opredeljena in zagotavljajo varno rabo nadvse zapletenih ali pa povsem preprostih vtičnikov. Njihovi razvijalci so tisti, ki morajo poskrbeti, da bodo podatki uporabnikov (uporabniška imena in gesla) na varnem, to pa najlaže storijo tako, da prijavne podatke in uporabnike nivojsko ločijo. Strokovnjaki za varnost razvijalcem vtičnikov API tudi odsvetujejo »klicanje« prijavnih podatkov čez nekatere javne vtičnike API, ki nimajo ustrezne zaščite (beri: enkripcije), saj bi bila tako uporabniška imena in gesla lahko lahek plen za napadalce.