Forenzička analiza API logova

Ovaj seminar bavi se istraživanjem forenzičke analize API logova kao važnog izvora digitalnih dokaza u suvremenim disribuiranim informacijskim sustavima. API-ji predstavljaju osnovni komunikacijski mehanizam modernih web aplikacija i mikroservisnih arhitektura, zbog čega sigurnosni incidenti poput neovlaštenog pristupa, zlouporabe funkcionalnosti i curenja podataka često ostavljaju tragova upravo u zapisima API komunikacije. Unatoč tome, APi logovi u praksi često nisu dizajnirani s ciljem forenzičke upotrebe, što otežava naknadnu analizu i rekonstrukciju samih događaja.

Cilj seminara je prikazati forenzički značaj API logova te objasniti metoda njihova prikupljanja, očuvanja i analize u kontekstu računalne forenzike. U radu se razmatra struktura tipičnih API zapisa, njihova uloga kao digitalnog dokaza te neke vrste sigurnosnih incidenata koje je moguće identificirati analizom API logova. Poseban naglasak stavljen je na izazove povezane s vremenskom korelacijom podataka, integritetom zapisa i analizom logova u distribuiranim i mikroservisnim sustavima.

Ključne riječi: API logovi; forenzička analiza, digitalna forenzika; distribuirani sustavi; digitalni dokazi

Razvoj suvremenih informacijskih sustava obilježen je širokom primjenom distribuiranih arhitektura, web aplikacija i mikroservisa, pri čemu API-ji predstavljaju temeljni mehanizam komunikacija između pojedinih komponenti sustava. Većina poslovne logike i obrade korisničkih zahtjeva u modernim aplikacijama odvija se putem API poziva, zbog čega se sigurnosni incidenti sve češće pojavljuju upravo na aplikacijskoj razini.

Tradicionalni pristupi računalnoj forenzici uglavnom su usmjereni na analizu krajnjih uređaja i mrežne infrastrukture, no u cloud i distribuiranim okruženjima takvi pristupi često nisu dovoljni za potpunu rekonstrukciju sigurnosnih incidenata. Aplikacije se izvršavaju na dinamičkim resursima, a tragovi napada raspoređeni su kroz više servisa. U tom kontekstu, API logovi postaju ključan izvor digitalnih dokaza jer omogućuju uvid u tijek komunikacije između korisnika i sustava.

Unatoč njihovoj forenzičkoj vrijednosti, u praksi se API logovi često prikupljaju isključivo u svrhu nadzora i otklanjanja grešaka, bez razmatranja njihove primjene u računalnoj forenzici.

Cilj ovog seminara je prikazati forenzički značaj API logova u modernim poslužiteljskim sustavima te razmotriti mogućnosti i ograničenja njihove analize u kontekstu računalne forenzike aplikacija.

Forenzika web aplikacija bavi se naknadnim praćenjem i rekonstrukcijom sigurnosnog napada nad web apliakcijom s ciljem utvrđivanja odakle je napad došao, kako je izveden i koje je komponente sustava zahvatio. U praksi to često uključuje prikupljanje i analizu logova te konfiguracija povezanih s web polužiteljem i bazom podataka kako bi se odredili uzrok, priroda i potencijalni počinitelj napada [1].

Zbog distribuirane prirode modernih web aplikacija (npr. reversy proxy, API gateway, mikroservisi), tragovi aktivnosti često su raspšeni kroz više hardverskih i softverskih komponenti. Tipični izazovi forenzike web aplikacija uključuju: potrebu za korelacijom velikih količina logova, ograničeno vrijeme za ustragu te otežano praćenje izvora napada u slučajevima korištenja reverse proxa i anonimizatora [1].

Uobičajeni indikatori da je web aplikacija bila meta napada mogu uključivati nemogućnost pristupa aplikaciji, sumnjive aktivnosti na korisničkim računima, curenje ili neovlašteno izlaganje osjetljivih podataka, preusmjeravanje URL-ova, spore performanse te druge anomalije u radu sustava [1]. Neke od najčešćih kategorija ranjivosti i napada na web aplikacije sustavno opisuje OWASP (Open Web Application Security Project) kroz dokument OWASP Top 10, koji predstavlja široko prihvaćen preged najkritičnijih sigurnosnih rizika web aplikacija [2]. Neki najpoznatiji i najčešći napadi:

1. SQL Injection - ubacivanje zlonamjernih SQL izraza kroz ulazne podatke
2. Cross-Site Scripting (XSS) - injektiranje skripti koje se izvršavaju u pregledniku žrtve
3. DoS/DDoS - napadi uskraćivanja usluge čiji je cilj degradirati dostupnost i performanse sustava preoterećivanjem resursa
4. Broken authentication - propusti u autentifikaciji i upravljanju sjednicama/tokenima koji omogućuju lažno predstavljanje
5. Broken access control - propusti u autorizaciji koji korisniku omogućuju pristup resursima izvan njegovih ovlasti
6. Nevalidirani ulazi / slaba validacija korisničkog inputa - izostanak ili nepravilna sanitizacija ulaza koji potom uzrokuje sigurnosne propuste kroz aplikaciju

Jedan od ključnih izvora tragova u istrazi web napada su logovi web poslužitelja ili API logovi. Uobičajeni zajednički format API logova obično uključuje elemente poput IP adrese klijenta, vremena, prve linije zahtjeva, statusnog koda, broja poslanih bajtova itd. dok s druge strane error log sadrži dijagnostičke poruke i greške korisne pri analizi incidenta [1].

Ukratko, forenzika web aplikacija polazi od činjenice da se incident rijetko može objasniti iz jednog izvora podataka, međutim ključnu ulogu u otkrivanju imaju upravo API logovi. Zbog toga se u praksi nastoji prikupiti i usporediti više (npr. web poslužitelji, aplikacijski sloj, baza podataka), te pritom voditi računa o očuvanju integriteta prikupljenih zapisa te na kraju provesi vremensku korelaciju kako bi se dobio smislen slijed događaja. Ovaj seminar nastavlja takav pristup, ali se u nastavku fokusira na API logove kao posebno važan te često najinformativniji izvor tragova u web aplikacijama [1].

API logovi su zapisi koje API servis (aplikacijski sloj) generira tijekom obrade zahtjeva. Njihova je vrijednost u tome što, za razliku od čistih infrastrukturnih logova, mogu sadržavati više konteksta o tome što je korisnik pokušao napraviti i kako je aplikacija reagirala [3].

U praksi se često API logovi mogu svesti na dvije skupine:

• Request/Access API logovi - zapisi o svakom obrađenom HTTP zahtjevu
• Error logovi - zapisi o greškama tijekom obrade zahtjeva

Za forenzičku analizu posebno je važno da logovi bilježe dovoljno informacija za odgovor na osnovna pitanja: kada se događaj dogodio, gdje se dogodio (na kojem servisu i kojem endpointu), tko je izvršio akciju te kakav je ishod zabilježene akcije. U praksi to znači da request/API log zapis najčešće uključuje vremensku oznaku, IP adresu klijenta, HTTP metodu i endpoint, statusni kod te osnovne informacije o odgovoru. Također, tamo gdje je to moguće, poželjno je zabilježiti i identitet korisnika ukoliko je isti poznat te identifikator zahtjeva (request_id) koji omogučuje povezivanje više zapisa koji pripadaju istoj korisničkoj aktivnosti ili istom lancu poziva [4].

Osim općih request zapisa, sigurnosno logiranje requestova treba obuhvatiti i događaje koji su često indikatori napada ili pokušaja zlouporabe. To uključuje neuspjele pokušaje autentifikacije i autorizacije, neuspjele validacije ulaznih podataka, sumnjive događaje povezane sa sjednicama i tokenima te korištenje osjetljivih funkcionalnosti. Takvi događaji mogu biti presudni za kasniju rekonstrukciju incidenta, jer daju jasne točke u vremenskoj analizi te omogućuju razlikovanje legitimnog korištenja sustava od zlouporabe [4].

Kod dizajniranja API logova, važno je izbjeći pretjerano logiranje koje stvara šum i otežava analizu. Logovi trebaju biti konzistentni i dovoljno strukturirani da se mogu pretraživati i korelirati. Također jako je važno voditi računa o tome da logovi sami po sebi ne postanu sigurnosni problem te je poželjno izbjegavati logiranje osjetljivih podataka kao što su lozinke, sjednički tokeni, tajni ključevi i druge povjerljive informacije ili kada je to potrebno, obaviti njihovo maskiranje i sanitizaciju [3]. Primjer jednog API loga prikazan je slikom 1.

Slika 1. Primjer API loga [3].

API logovi imaju visoku forenzičku vrijednost jer predstavljaju kronološki zapis interkacije između klijenta i poslužiteljskih sustava (API servisa) te često sadrže kontekst koji nije dostupan u infrastrukturnim logovima (npr. identitet korisnika, izvedena akcija, ishod). Zbog toga su korisni i u operativnim scenarijima (debugging, praćenje performansi), ali posebno u sigurnosnim slučajevima poput identifikacije incidenata, izrade audit trail-a i dodatne istrage [4]. Prikaz važnosti API logova prikazan je slikom 2.

Slika 2. Ilustracija prikupljanja logova [5]

Najizravnija forenzička vrijednost API logova je mogućnost izrade vremenske linije događaja te odgovaranje na pitanja: koji je endpoint pozvan, kada, kojim redoslijedom i s kakvim ishodom. Time se sumnjiva aktivnost može rekonstruirati kao slijed povezanih koraka (npr. učestali neuspjeli pokušaji autentifikacije - uspješna prijava - neuobičajeno velik broj poziva prema osjetljivim resursima - izvozi podataka). API logovi su posebno korisni jer mogu dopuniti istragu aplikacijski specifičnim informacijama koje često nedostaju u drugim izvorima logova te pomažu utvrditi tko je izvršio radnju i što je točno učinjeno jer aplikacija tipično ima pristup informacijama o identitetu korisnika (u slučaju autentificiranih zahtjeva), roli i ovlastima korisnika, kao i kontekstu samog događaja [4]. U forenzičkom smislu to omogućuje precizniju procjenu opsega incidenta

• koji korisnički računi su uključeni
• koje funkcionalnosti su zlorabljene
• koji su resursi bili dostupni ili izloženi

Forenzička analiza je brža i pouzdanija kada su logovi konzistentni i pogodni za korelaciju. Preporučuje se standardiziran format i dosljedna struktura kako bi se zapisi mogli jednostavno pretraživati, analizirati i povezivati u alatima za log management. Iako su API logovi često najinformativniji izvor tragova na aplikacijskoj razini, njihova vrijednost ovisi o tome jesu li ključni događaji uopće logirani, jesu li logovi pregledni i je li uspostavljen monitoring s pragovima. Ako se logovi ne prate ili ne čuvaju dovoljno dugo, naknadna rekonstrukcija incidenta može biti nepotpuna ili nemoguća [4].

API logovi omogućuju identifikaciju različitih vrsta sigurnosnih incidenata kroz specifične obrasce ponašanja. Za razliku od infrastrukturnih logova koji bilježe samo mrežnu komunikaciju, API logovi otkrivaju zlouporabu aplikacijske logike i neovlašteni pristup resursima. U ovom poglavlju razmatra se kako se najčešći napadi manifestiraju kroz zapise u API logovima.

1. Brute Force i Credential Stuffing

Brute force napadi pokušavaju pogoditi lozinke nasumičnim kombinacijama, dok credential stuffing koristi ukradene podatke iz drugih servisa. U API logovima prepoznatljivi su po karakterističnim obrascima:

• nagli porast neuspjelih prijava - visok broj HTTP 401 odgovora u kratkom vremenu
• distribuirani zahtjevi - dolaze iz geogreski raspršenih lokacija ili cloud infrastruktura
• nizak omjer uspjeha - napadači postižu 0.1% - 4% uspješnosti, ali pokušavaju tisuće kombinacija

Analiza Auth0 logova za detekciju credential stuffing napada traži IP adrese koje generiraju visok broj neuspjelih događaja unutar vremenskog prozora te neuobičajeni porast ukupnog broja neuspjelih prijava u sustavu [7].

2. Broken Object Level Authorization (BOLA)

BOLA napadi nastaju kada napadač manipulira identifikatorima objekata u API zahtjevima. U logovima vidljivi su kroz [6]:

• Sekvencijalni pristup - nizovi zahtjeva s inkrementalno promijenjenim ID-ovima (/api/users/1, /api/users/2, /api/users/3…)
• Neuobičajeno velik broj različitih objekata - korisnik pristupa stotinama različitih zapisa u kratkom vremenu
• Visoka frekvencija HTTP 403 (Forbidden) - pokušaji pristupa neovlaštenim resursima

3. API Rate Limiting Abuse

Napadi na iscrpljivanje resursa koriste legitimne API pozive u neuobičajenim količinama. Prepoznaju se kroz [6]:

• Neuobičajeno visok broj zahtjeva od pojedine IP adrese ili korisničkog računa
• Velika frekvencija prema resource-intensive endpointima - npr. operacije izvoza podataka ili generiranje izvještaja
• DoS/DDoS obrasci - masovni zahtjevi s ciljem preopterećenja resursa

4. Server Side Request Forgery (SSRF) Server Side Request Forgery javlja se kada API dohvaća udaljeni resurs bez validacije URL-a koji je dostavio korisnik. To omogućuje napadaču da prisili aplikaciju da šalje zahtjeve prema nenamjeravanom odredištu, čak i kada je zaštićeno firewall-om ili VPN-om [6]. U API logovima. SSRF npadi prepoznatljivi su kroz [8]:

• URL parametri s internim IP adresama - prisutnost lokalnih adresa (127.0.0.1, localhost, 0.0.0.0) ili privatnih IP raspona (10.0.0.0/8, 192.168.0.0/16, 169.254.169.254) u URL parametrima
• Zahtjevi prema cloud metadata servisima - pristup AWS, Azure ili GCP metadata endpointima na adresi 169.254.169.254 koji sadrže pristupne tokene i konfiguracijske podatke
• Neuobičajeni URL sheme - korištenje protokola poput file, gopher, dict ili ftp koji mogu omogućiti pristup lokalnim datotekama ili internim servisima
• Kodirane URL reprezentacije - pokušaji zaobilaženja validacije kroz heksadecimalne zapise IP adresa, decimalne reprezentacije ili URL enkodiranje
• Out-of-band indikatori - DNS upiti ili HTTP zahtjevi prema eksternim domenama pod kontrolom napadača koji služe za potvrdu uspješne eksploatacije

Svi navedeni napadi ostavljaju karakteristične tragove u API logovima, no njihova uspješna detekcija zahtijeva više od praćenja pojedinačnih sumjivih zahtjeva. Moderna forenzička analiza temelji se na uspostavi baseline normalnog ponašanja sustava te kontinuiranom prepoznavanju odstupanja od tog obrasca. Neuobičajeni spike u volumenu zahtjeva, do tada neviđene sekvence API poziva ili pristup iz neočekivanih geografskih lokacija mogu biti rani indikatori napada, čak i kada pojedinačni zahtjevi tehnički izgledaju legitimno. Stoga je za učinkovitu detekciju potreba pristup koji kombinira praćenje specifičnih sigurnosnih događaja s analizom ponašanja korisnika i sustava kroz vrijeme [6].

Kroz prethodna poglavlja pokazali smo da se iz API logova može vrlo precizno pratiti ponašanje sustava i korisnika (tko je što pozivao, u kojem trenutku i s kojim rezultatom). Međutim, u forenzičkom smislu ti zapisi vrijede samo onoliko koliko im možemo vjerovati: ključno je da su logovi cjeloviti, vremenski dosljedni i zaštićeni od naknadnih izmjena ili brisanja, uz jasno kontroliran pristup i mogućnost provjere integriteta

Integritet logova

Integritet podrazumijeva da se zapisi ne mogu neprimjetno mijenjati, brisati ili naknadno umetati, odnosno da se svaki pokušaj manipulacije može otkriti (npr. kroz obrasce “log injection” ili kroz naknadne izmjene pohranjenih datoteka). API logovi moraju biti zaštićeni tijekom prijenosa i pohrane iz dva ključna razloga: mogu sadržavati osjetljive podatke korisnika, ali i sami predstavljaju vrijedan forenzički dokaz, što ih čini metom napadača koji žele uništiti tragove svojih aktivnosti [4].

U praksi to možemo prikazati kroz dvije skupine mjera [4]:

• Zaštita logova u mirovanju (at rest): ugradnja mehanizama za uočavanje izmjena (tamper detection), što ranije izdvajanje/kopiranje u “read-only” oblik, bilježenje i nadzor svakog pristupa logovima te ograničavanje i periodična revizija privilegija čitanja
• Zaštita logova u prijenosu (in transit): korištenje sigurnih protokola kada se logovi šalju preko nepouzdanih mreža te razmatranje treba li potvrditi izvor događaja (npr. provjera autentičnosti izvora ili pouzdanosti kanala)

U konačnici, to znači da pristup repozitoriju logova treba biti strogo kontroliran, a logove je poželjno slati u centralno i zaštićeno okruženje (npr. centralni log sustav/SIEM) gdje su pravila pristupa, čuvanja i audita jasno definirana. Dodatno, važno je da se sadržaj koji se upisuje u logove prethodno “očisti”/normalizira (npr. uklanjanje problematičnih kontrolnih znakova) kako bi se smanjio rizik da napadač manipulira prikazom logova i time oteža analizu [4].

Pouzdanost logova

Pouzdanost se odnosi na to da su logovi točni, konzistentni i dovoljno potpuni da iz njih možemo rekonstruirati tijek događaja. U kontekstu API-ja, dva najčešća izvora nepouzdanosti su [4]:

• Vremenska nekonzistentnost — različiti serveri/slojevi (API gateway, aplikacija, autentifikacija) bilježe različito vrijeme pa timeline postaje nepouzdan
• Nepotpunost — logiranje prestane, razina logiranja se promijeni, ili se zapisi izgube zbog rotacije, resursnih ograničenja ili grešaka

Zato se u praksi uz logove uvode operativni mehanizmi koji osiguravaju da su događaji usporedivi po vremenu i da se što ranije uoče “rupe” u logiranju (npr. izostanak očekivanih događaja, nagli pad volumena zapisa ili indikacije neovlaštenog pristupa logovima). Za API forenziku to znači da timestampi moraju biti usporedivi kroz sve slojeve sustava, a nadzor treba alarmirati kada se pojave neuobičajeni prekidi ili odstupanja koja mogu utjecati na rekonstrukciju incidenta [4].

API log forenzika u teoriji izgleda jednostavno. U praksi, međutim, kvaliteta zaključaka izravno ovisi o tome jesu li logovi uopće prikupljeni, što točno sadrže, mogu li se međusobno povezati i mogu li se smatrati pouzdanima. Upravo zato se kod API sustava često pojavljuju ponavljajući izazovi koji ograničavaju rekonstrukciju incidenta i dokaznu snagu zapisa.

1. Nepotpuno ili neujednačeno logiranje

Čest problem je da aplikacijsko logiranje bude djelomično, nedosljedno ili loše konfigurirano (npr. logovi postoje na razini infrastrukture, ali nedostaju kontekst i detalji koje zna samo aplikacija). Posljedica je da se za pojedine zahtjeve ne bilježe ključna polja (identitet, autorizacijski ishod, ciljna operacija), pa se kasnije mora “pogađati” što se zapravo dogodilo. Dodatna poteškoća je balans “previše vs. premalo” zapisa: preopširni logovi otežavaju analizu i povećavaju trošak, dok presiromašni logovi ne omogućuju rekonstrukciju. Smjernice sigurnog logiranja naglašavaju da je važno logirati dovoljno za rekonstrukciju, ali bez nepotrebnog gomilanja podataka [4].

2. Ograničenja sadržaja logova (npr. bez tijela zahtjeva/odgovora)

Čak i kada je logiranje zahtjeva uključeno, platforma koja se bavi logiranjem može imati tehnička ograničenja koja forenziku ostavljaju bez potrebnog konteksta. Konkretan primjer je Amazon API Gateway, gdje su log događaji ograničeni na 1024 bajta, pa se veći sadržaji (uključujući request/response body) režu (truncate) prije slanja u sustav. To znači da istražitelj često ne dobije cijeli payload, nego samo njegov dio, što otežava dokazivanje (npr. točne vrijednosti parametara ili sadržaja koji je poslan). U općenitijem smislu, API logovi često sadrže “metapodatke o pozivu”, ali ne nužno i cjelovit sadržaj poruke, što je ozbiljno ograničenje kod analiza poput injection napada, zlouporabe parametara ili sličnih napada [9].

3. Teško povezivanje događaja u distribuiranim sustavima

Moderne API arhitekture tipično uključuju API gateway, više mikroservisa, autentikacijske servise, baze i vanjske integracije. Bez zajedničkog identifikatora (npr. interaction/correlation ID) jedan korisnički zahtjev se razbije na više internih događaja i logova koji izgledaju nepovezano. U smjernicama se zato ističe važnost bilježenja identifikatora koji povezuje događaje jedne interakcije, kako bi se kasnije omogućilo lakše rekonstrukiranje događaja. Ograničenje u praksi je ako taj identifikator nije dosljedno uveden kroz sve slojeve ili se gubi na granicama sustava (npr. prema trećim stranama), vremenska linija ostaje fragmentirana [4]. Primjer složene mikroservisne arhitekture prikazan je slikom 3.

Slika 3. Primjer mikroservisne arhitekture [10]

4. Privatnost i zakonitost

Forenzička analiza bila bi to bolja kada bi se sastojala od što više detalja, ali realnost je da logovi mogu sadržavati osobne i osjetljive podatke. Smjernice navode kategorije podataka koje se tipično ne bi trebale zapisivati direktno (npr. lozinke, tokeni, dio identifikatora sesije, osjetljivi PII) te potrebu maskiranja, hashiranja ili pseudonimizacije. To u praksi stvara ograničenja da se ponekad radi zaštite privatnosti i usklađenosti gubi dio detalja koji bi bio koristan za atribuciju i rekonstrukciju (npr. puni token ili puni identifikator sesije) [4].

Ovo poglavlje opisuje centralizirani pristup prikupljanju i upravljanju API logovima, umjesto oslanjanja na lokalne zapise po pojedinim poslužiteljima. Naglasak je na arhitekturi koja omogućuje dosljedno strukturirane zapise, njihovu korelaciju kroz više slojeva sustava te sigurnu pohranu i kontroliran pristup za analizu i izvještavanje.

Arhitektura centraliziranog prikupljanja logova

Centralizirani dizajn tipično uključuje nekoliko slojeva [4]:

• Izvori logova: API gateway/WAF, aplikacijski servisi (frontend/middleware), baze ili pomoćne komponente gdje svaki sloj generira svoje događaje
• Sloj prikupljanja (collector/receiver): komponenta koja prima logove te može obaviti osnovnu normalizaciju/sažimanje i proslijediti ih u centralno spremište
• Centralno spremište: mjesto gdje se logovi trajno pohranjuju (log storage/SIEM/analitička platforma) i iz kojeg se kasnije rade pretrage, korelacije i izvještaji
• Odvojeni pristup za pregled i preuzimanje: posebno sučelje/aplikacija za pregled i izvoz logova, odvojena od komponenti koje zapisuju logove. U praksi to znači i odvojene mrežne pristupe (portove) te različite uloge i privilegije

Ovakva segmentacija je korisna jer smanjuje rizik da kompromitacija jedne komponente automatski omogućuje brisanje ili manipulaciju centralnim logovima, a istovremeno olakšava audit pristupa i upravljanje zadržavanjem (retencijom). Primjer složene arhitekture za centralizirano prikupljanje logova prikazano je slikom 4.

Slika 4. Primjer centraliziranog prikupljanja logova [4]

Sigurnost i operativna pouzdanost centralnog sustava

Centralizacija sama po sebi nije dovoljna već mora biti sigurna i otporna na potencijalne napade [4]:

• Zaštita u prijenosu i pohrani: logove treba štititi od manipulacije tijekom slanja te od neovlaštenog čitanja/izmjene nakon pohrane (npr. tamper detection, read-only kopije, evidencija i nadzor pristupa)
• Zasebne svrhe, zasebni tokovi: sigurnosni događaji često se razlikuju od audit/transaction logova, pa se u praksi isplati držati ih odvojeno (zbog drugačije granularnosti, publike i zahtjeva zadržavanja).
• Monitoring log sustava: potrebno je imati procese koji otkrivaju prestanak logiranja te pokušaje neovlaštenog pristupa ili brisanja, i osigurati da su ozbiljni događaji odmah vidljivi odgovornim timovima.
• Retencija: logovi se ne smiju brisati prije isteka potrebnog razdoblja, ali ih se ne bi trebalo držati dulje od opravdanog (pravni, regulatorni i ugovorni zahtjevi).

Kroz seminar je pokazano da API logovi predstavljaju praktičnu i vrlo bitnu osnovu za forenzičku analizu incidenata nad web aplikacijama: iz njih se mogu izvući obrasci ponašanja, prepoznati sumnjive aktivnosti te procijeniti opseg i posljedice zlouporabe. Međutim, forenzička vrijednost takvih zapisa ovisi o kvaliteti samog logiranja i o tome jesu li logovi pripremljeni za naknadnu analizu te jesu li strukturirani, konzistentni, korelabilni između slojeva sustava te zaštićeni od manipulacije (npr. sanitizacijom ulaza prije logiranja i kontroliranim pristupom pohranjenim zapisima).

Dodatnu razinu vjerodostojnosti daje mogućnost provjere da logovi nakon nastanka nisu neprimjetno mijenjani ili brisani. U praksi se to postiže kombinacijom mjera poput detekcije pokušaja izmjena (tamper detection), ranog kopiranja/pohrane u read-only oblik, evidentiranja i nadzora pristupa logovima te sigurnog prijenosa prema centralnom spremištu, čime se smanjuje prostor za manipulaciju i jača dokazna vrijednost zapisa.

Zaključno, API logovi nisu samo operativni zapis rada sustava, nego forenzički artefakt te uz dobar dizajn logiranja, centralizirano prikupljanje i provjerljiv integritet, mogu pružiti pouzdan temelj za rekonstrukciju incidenta i kvalitetno izvještavanje. Bez tih preduvjeta, njihova se uloga često svodi na parcijalne indikacije koje je teže dokazno potkrijepiti.

[1] https://vishnushivalalp.medium.com/web-application-forensics-2099e8ce6589

[2] https://owasp.org/www-project-top-ten/

[3] https://www.merge.dev/blog/api-logs

[4] https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

[5] https://api7.ai/blog/unlocking-power-of-api-gateway-logging

[6] https://owasp.org/www-project-api-security/

[7] https://auth0.com/blog/Log-Detections-Credential-Stuffing-MFA-Exploit-Prevention/

[8] https://www.aptori.com/guide/ssrf-detecting-exploiting-and-preventing-server-side-request-forgery-in-apis

[9] https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.html

[10] https://microservices.io/patterns/microservices.html