Razlike

Slijede razlike između dviju inačica stranice.

--- racfor_wiki:seminari2025:dz54240 [2026/01/21 23:04]
Dominik Zoričić [Najbolje prakse za forenzički dizajn arhitekture prikupljanja logova]
+++ 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 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 [10]
+{{ :racfor_wiki:seminari2025:microservice_architecture.png?400 |}} Slika 3. Primjer mikroservisne arhitekture [10]
 **4. Privatnost i zakonitost**
@@ Redak 161: / Redak 161: @@
 **Arhitektura centraliziranog prikupljanja logova**
-Centralizirani dizajn tipično uključuje nekoliko slojeva:
+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
@@ Redak 167: / Redak 167: @@
   * 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).
+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 =====

racfor_wiki/seminari2025/dz54240.1769036696.txt.gz · Zadnja izmjena: 2026/01/21 23:04 od Dominik Zoričić