Razlike

Slijede razlike između dviju inačica stranice.

--- racfor_wiki:seminari2025:dz54240 [2026/01/21 23:14]
Dominik Zoričić
+++ racfor_wiki:seminari2025:dz54240 [2026/01/21 23:32] (trenutno)
Dominik Zoričić [Zaključak]
@@ 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 169: / Redak 169: @@
 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
+{{ :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.1769037291.txt.gz · Zadnja izmjena: 2026/01/21 23:14 od Dominik Zoričić