Razlike

Slijede razlike između dviju inačica stranice.

--- racfor_wiki:seminari2025:dz54240 [2026/01/20 23:47]
Dominik Zoričić [Literatura]
+++ racfor_wiki:seminari2025:dz54240 [2026/01/21 23:32] (trenutno)
Dominik Zoričić [Zaključak]
@@ Redak 52: / Redak 52: @@
 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.
-{{ :racfor_wiki:seminari2025:log-structure.png?400 |}} Slika 1 Primjer API loga [3].
+{{ :racfor_wiki:seminari2025:log-structure.png?400 |}} Slika 1. Primjer API loga [3].
 ===== Forenzička vrijednost API logova =====
 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.
-{{ :racfor_wiki:seminari2025:api-log.png?400 |}} Slika 2 Ilustracija prikupljanja logova [5]
+{{ :racfor_wiki:seminari2025:api-log.png?400 |}} 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
@@ Redak 140: / Redak 140: @@
 **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.
+Č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**
@@ Redak 146: / Redak 146: @@
 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.
-{{ :racfor_wiki:seminari2025:microservice_architecture.png?400 |}} Slika 3 Primjer mikroservisne arhitekture
+{{ :racfor_wiki:seminari2025:microservice_architecture.png?400 |}} Slika 3. Primjer mikroservisne arhitekture [10]
 **4. Privatnost i zakonitost**
@@ Redak 155: / Redak 155: @@
-===== Najbolje prakse za forenzički dizajn API logova =====
+===== Najbolje prakse za forenzički dizajn arhitekture prikupljanja logova =====
+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.
+{{ :racfor_wiki:seminari2025:centralized-logging.png?400 |}} 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).
 ===== Zaključak =====
+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.
 ===== Literatura =====
@@ Redak 178: / Redak 208: @@
 [9] [[https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.html]]
+[10] [[https://microservices.io/patterns/microservices.html]]

racfor_wiki/seminari2025/dz54240.1768952876.txt.gz · Zadnja izmjena: 2026/01/20 23:47 od Dominik Zoričić