Log Management

Co to jest Log Management?

Log Management (zarządzanie logami) to proces generowania, przesyłania, przechowywania, analizowania i usuwania dzienników zdarzeń (logów) tworzonych przez systemy, aplikacje i urządzenia sieciowe. Taką definicję podaje NIST w dokumencie SP 800-92 „Guide to Computer Security Log Management” (2006).

Log to rekord ze znacznikiem czasu, który dokumentuje zdarzenie w środowisku IT: logowanie użytkownika, błąd aplikacji, zmianę konfiguracji czy próbę nieuprawnionego dostępu. Logi są głównym źródłem dowodów w analizie powłamaniowej i podstawą do zgłoszenia incydentu w terminach wymaganych przez znowelizowaną ustawę o krajowym systemie cyberbezpieczeństwa (UoKSC).

Jakie są etapy cyklu życia logów?

Cykl życia logów obejmuje 6 etapów: wygenerowanie w systemie źródłowym, przesłanie do centralnego kolektora, parsowanie i normalizację, przechowywanie i indeksowanie, analizę oraz archiwizację lub usunięcie po okresie retencji. Każdy z tych etapów ma istotne znaczenie dla całego procesu. Pominięcie któregokolwiek z nich może obniżyć jakość i użyteczność danych.Niekompletne zbieranie danych uniemożliwia rzetelną analizę, a brak normalizacji sprawia, że nawet kompletne dane są bezużyteczne dla systemów korelacyjnych.

Jak wybrać strategię gromadzenia logów?

Strategię gromadzenia logów należy dobrać, równoważąc potrzebę zapewnienia pełnego wglądu w środowisko z kosztami przechowywania danych oraz obciążeniem sieci. W praktyce stosuje się dwa podstawowe podejścia: 

• Zbieranie wszystkich danych – rejestrowanie zdarzeń ze wszystkich źródeł, niezależnie od tego, czy są aktualnie potrzebne. Zapewnia dane historyczne do prześledzenia nowego ataku, ale jest kosztowne i generuje dużo szumu informacyjnego.
• Zbieranie selektywne (pod kątem scenariuszy wykrywania) – gromadzenie wyłącznie logów potrzebnych do zdefiniowanych reguł wykrywania. Podejście to pozwala ograniczyć koszty, jednak może prowadzić do powstawania luk w monitoringu, jeśli atakujący zastosuje technikę nieuwzględnioną w istniejących scenariuszach.

W praktyce organizacje często łączą oba podejścia i optymalizują proces gromadzenia logów. Stosują m.in. strukturyzację danych już na etapie ich generowania, filtrowanie zbędnych komunikatów diagnostycznych oraz kompresję danych przed transmisją. 

Co dzieje się z logami po okresie retencji?

Po upływie okresu retencji logi mogą zostać przeniesione do tańszego archiwum lub trwale usunięte. Decyzja zależy od ich dalszej wartości dowodowej, operacyjnej lub biznesowej.Okres retencji określa polityka bezpieczeństwa organizacji z uwzględnieniem przepisów (w tym RODO) i potrzeb analizy powłamaniowej.

Jak standaryzacja formatów wpływa na analizę logów?

Ujednolicenie struktury logów pozwala ograniczyć liczbę niestandardowych parserów, ułatwia normalizację oraz zwiększa skuteczność systemów monitorowania i korelacji zdarzeń.

Przez dziesięciolecia jednym z najczęściej stosowanych standardów wymiany komunikatów logów był Syslog, wywodzący się ze środowisk uniksowych.

RFC 3164 (BSD Syslog) opisuje historyczny format logów, zawierający m.in.: priorytet (PRI), skrócony znacznik czasu, nazwę hosta i nieustrukturyzowany tekst. Znacznik nie zawiera roku ani strefy czasowej, a nieustrukturyzowana treść wymaga stosowania osobnych reguł parsowania dla poszczególnych typów urządzeń i aplikacji.

RFC 5424 (IETF Syslog) wprowadza bardziej ustandaryzowaną strukturę komunikatu. Obsługuje m.in. kodowanie UTF-8, znaczniki czasu zgodne z formatem ISO 8601 oraz pole STRUCTURED-DATA, umożliwiające przekazywanie dodatkowych informacji w ustandaryzowanej postaci. Dzięki temu parser może bezpośrednio wyodrębniać określone pola zamiast analizować wyłącznie nieustrukturyzowany tekst.

Kategorię komunikatu Syslog określa wartość PRI = Facility × 8 + Severity. Facility wskazuje źródło zdarzenia (np. 4 – bezpieczeństwo i autoryzacja), a Severity – krytyczność w skali 0–7. PRI równe 34 (4 × 8 + 2) oznacza krytyczny komunikat z kategorii bezpieczeństwa/autoryzacji.

W nowoczesnych środowiskach powszechnie stosowany jest również JSON, który dobrze sprawdza się w przypadku aplikacji, mikrousług i systemów chmurowych. Jego struktura umożliwia łatwe reprezentowanie zagnieżdżonych obiektów i tablic oraz ułatwia dalsze przetwarzanie danych przez systemy analityczne, SIEM i XDR.

Atrybut	RFC 3164 (BSD Syslog)	RFC 5424 (IETF Syslog)	JSON
Znacznik czasu	Bez roku i strefy czasowej	ISO 8601, do mikrosekund	Zwykle ISO 8601
Struktura	Tekst nieustrukturyzowany	Dane klucz-wartość	Zagnieżdżone obiekty i tablice
Kodowanie	ASCII	UTF-8	UTF-8
Zastosowanie	Starsze systemy i urządzenia	Nowoczesne urządzenia sieciowe, systemy SIEM	Aplikacje natywnie chmurowe, mikrousługi, SIEM/XDR

Czym Log Management różni się od SIEM?

Log Management różni się od SIEM pod względem zakresu funkcjonalności. Zarządzanie logami (Log Management) odpowiada za agregację, przechowywanie oraz udostępnianie danych do przeszukiwania i analizy. SIEM (Security Information and Event Management) rozszerza te możliwości o korelację zdarzeń, reguły detekcji zagrożeń oraz generowanie alertów. Log Management jest fundamentem SIEM, nie jego alternatywą.

SIEM normalizuje dane z całego środowiska IT i analizuje je pod kątem sygnatur ataków lub odchyleń od wzorców normalnej aktywności (baselining). Platformy takie jak SecureVisio czy Splunk łączą funkcje Log Management i SIEM  w jednym rozwiązaniu.

Jakie problemy rozwiązują nowsze architektury analizy logów?

Nowoczesne architektury analizy logów odpowiadają przede wszystkim na wyzwania związane ze skalą danych i kosztami ich przetwarzania.  Pierwsze generacje SIEM głęboko indeksowały każdy rekord, co przy dzisiejszej ilości danych znacząco podnosiło koszty. W rezultacie organizacje często ograniczały liczbę monitorowanych źródeł, co tworzyło luki w monitoringu i zwiększało ryzyko przeoczenia incydentu. Dodatkowym problemem jest nadmiar nieodfiltrowanych alertów, który prowadzi do zjawiska zmęczenia alertami (alert fatigue).

Odpowiedzią są platformy XDR oraz architektury oparte na strumieniowym przetwarzaniu danych i wyszukiwaniu bez konieczności pełnego indeksowania.Pozwalają one analizować znacznie większe wolumeny danych przy zachowaniu krótkiego czasu odpowiedzi na zapytania. 

Uzupełnieniem tych rozwiązań są systemy SOAR (Security Orchestration, Automation and Response). Wykorzystują one scenariusze reagowania (playbooki), które automatyzują procesy takie jak zbieranie danych, powiadamianie zespołu bezpieczeństwa czy izolacja zagrożonego hosta. Rola analityka polega na weryfikacji alertu i podjęciu ostatecznej decyzji dotyczącej dalszych działań.

Równolegle do rozwiązań technologicznych ewoluują wytyczne  NIST: nowy projekt SP 800-92 Rev. 1 „Cybersecurity Log Management Planning Guide” z października 2023 r. według stanu na wrzesień 2026 r. nadal pozostaje wersją roboczą.. Obowiązującym dokumentem pozostaje SP 800-92 z 2006 roku.

Jakie wyzwania stawia zarządzanie logami w chmurze i kontenerach?

Zarządzanie logami w środowiskach chmurowych wymaga rozróżnienia dwóch podstawowych kategorii danych: logów płaszczyzny kontrolnej (Control Plane) oraz logów płaszczyzny danych (Data Plane).

Logi płaszczyzny kontrolnej (Control Plane) rejestrują operacje zarządcze: utworzenie maszyny wirtualnej, zmianę reguł sieciowych, nadanie roli. Są zwykle dostępne domyślnie (np.  w usługach AWS CloudTrail, Azure Activity Log). Dane te są jednak przechowywane przez ograniczony czas, dlatego dłuższa retencja wymaga ich eksportu do dedykowanego repozytorium, np. poprzez skonfigurowanie trailu w AWS CloudTrail lub ustawień diagnostycznych w Microsoft Azure. Logi te odgrywają kluczową rolę w wykrywaniu nadużyć związanych z wykorzystaniem kluczy API, nieautoryzowanych zmian konfiguracji oraz prób eskalacji uprawnień.

Logi płaszczyzny danych rejestrują natomiast operacje wykonywane na danych oraz ruch sieciowy generowany przez usługi i aplikacje. Ze względu na bardzo duży wolumen generowanych informacji oraz związane z tym koszty przechowywania i analizy, w wielu usługach chmurowych są one domyślnie wyłączone i wymagają świadomego włączenia przez administratora.

Dodatkowe wyzwania pojawiają się w środowiskach kontenerowych. Kontenery zarządzane przez Kubernetes mogą działać jedynie przez kilka minut, a po ich usunięciu lokalnie przechowywane logi zazwyczaj bezpowrotnie znikają. Z tego powodu konieczne jest przesyłanie logów w czasie rzeczywistym do zewnętrznej platformy zbierającej i analizującej dane. Najczęściej odpowiada za to agent uruchomiony na każdym węźle klastra w formie DaemonSetu, który odczytuje standardowe wyjście (stdout i stderr) kontenerów i przekazuje je do centralnego systemu logowania.
Istotnym źródłem informacji są również logi audytowe serwera API Kubernetes, które dokumentują działania wykonywane w klastrze i umożliwiają analizę zmian konfiguracji, operacji administracyjnych oraz prób nieautoryzowanego dostępu.

Dlaczego niezmienność logów (WORM) jest tak ważna?

Niezmienność logów ma kluczowe znaczenie dla wiarygodności dowodów cyfrowych.  Logi mogą stanowić materiał dowodowy,tylko wtedy, gdy można wykazać, że nie został zmodyfikowany. Atakujący po eskalacji uprawnień często usuwa lub nadpisuje lokalne logi, aby zatrzeć ślady swojej aktywności i utrudnić analizę incydentu.

Ochronę niezmienności logów zapewnia model WORM (Write Once, Read Many): zapisany rekord nie może zostać zmieniony ani usunięty. W środowiskach chmurowych odpowiednikiem takiego rozwiązania jest np. S3 Object Lock w trybie Compliance, w którym dane nie mogą zostać usunięte przed upływem retencji, nawet przez administratora z pełnymi uprawnieniami. Dodatkowym zabezpieczeniem są łańcuchy skrótów (hash chains), które umożliwiają potwierdzenie integralności zapisów i wykrycie prób ingerencji w chronologię zdarzeń.

Jak logi pomagają zrekonstruować przebieg ataku?

Logi odgrywają kluczową rolę w rekonstrukcji przebiegu incydentu bezpieczeństwa, ponieważ dopiero analiza wielu źródeł danych pozwala odtworzyć pełną sekwencję działań atakującego. Pojedyncze zdarzenia często wydają się niegroźne, jednak ich korelacja ujawnia rzeczywisty kontekst.

Przykładowo, seria nieudanych prób logowania SSH odnotowanych w pliku auth.log, następnie udane logowanie, użycie polecenia sudo oraz pobranie pliku za pomocą narzędzia curl mogą wskazywać na przejęcie dostępu do systemu i instalację tylnej furtki (backdoora). Każde z tych zdarzeń analizowane osobno może wydawać się rutynową aktywnością administracyjną, jednak ich zestawienie pozwala zidentyfikować pełny przebieg ataku.

Niszczenie logów bywa też elementem samego ataku. Złośliwe oprogramowanie NotPetya (Petya/ExPetr) z czerwca 2017 roku – wiper podszywający się pod ransomware – usuwało  dzienniki Windows (Setup, System, Security i Application) za pomocą narzędzia wevtutil, aby utrudnić analizę. Kopia logów w centralnym, niezmiennym repozytorium pozwala odtworzyć przebieg ataku mimo takich działań.

Jakie przepisy i normy określają wymagania wobec zarządzania logami w Polsce?

Prawne wymagania wobec zarządzania logami w Polsce wynikają z UoKSC i RODO, a dobre praktyki w tym zakresie opisuje norma ISO/IEC 27001.

UoKSC. Znowelizowana ustawa obowiązuje od 3 kwietnia 2026 r. Podmioty, które w tym dniu spełniały kryteria podmiotu kluczowego lub ważnego, mają czas na wdrożenie obowiązków do 3 kwietnia 2027 r.

Ustawa wymaga od nich prowadzenia dokumentacji bezpieczeństwa systemu informacyjnego, zapewnienia jej integralności i przechowywania jej przez co najmniej 2 lata od wycofania z systemu z użytkowania lub zakończenia świadczenia usługi. Ustawa wymaga też zgłaszania incydentów poważnych do właściwego CSIRT w terminach 24 godzin (wczesne ostrzeżenie), 72 godzin (zgłoszenie incydentu) i 1 miesiąca od zgłoszenia incydentu (raport końcowy). 

Choć ustawa nie nakazuje wprost wdrożenia centralnego systemu zarządzania logami, w praktyce spełnienie wymogów dotyczących wykrywania, analizowania i raportowania incydentów bez takiego rozwiązania jest bardzo trudne.

ISO/IEC 27001:2022.

Norma ISO/IEC 27001:2022 określa wymagania dotyczące systemu zarządzania bezpieczeństwem informacji oraz związanych z nim zabezpieczeń.

Zabezpieczenie A.8.15 (Rejestrowanie zdarzeń) wymaga rejestrowania, przechowywania, ochrony i analizy logów, w tym działań użytkowników uprzywilejowanych. Zabezpieczenie A.8.17 (Synchronizacja zegarów) wymaga zgodności zegarów systemowych z wiarygodnym źródłem czasu (zwykle NTP). Spójność znaczników czasu ma kluczowe znaczenie dla korelacji zdarzeń pochodzących z różnych systemów i zachowania ich wartości dowodowej.

RODO. Logi systemowe często zawierają dane, które mogą zostać uznane za dane osobowe, takie jak adresy IP, identyfikatory sesji, loginy użytkowników czy identyfikatory urządzeń.  RODO w art. 4 pkt 1 wprost wskazuje identyfikatory internetowe jako przykład danych osobowych. Dodatkowo Trybunał Sprawiedliwości Unii Europejskiej w wyroku C-582/14 (Breyer przeciwko Republice Federalnej Niemiec) uznał, że dynamiczny adres IP może stanowić daną osobową, jeżeli istnieją prawne lub praktyczne możliwości powiązania go z konkretną osobą.

W konsekwencji organizacje muszą zachować równowagę między potrzebami bezpieczeństwa a ochroną prywatności. Z jednej strony logi powinny zawierać wystarczającą ilość informacji, aby umożliwić wykrywanie incydentów i analizę działań intruza. Z drugiej strony należy stosować odpowiednie okresy retencji, ograniczać zakres przetwarzanych danych oraz wykorzystywać mechanizmy pseudonimizacji lub maskowania danych osobowych, szczególnie w przypadku przekazywania logów podmiotom zewnętrznym.

Pojęcia powiązane z zarządzaniem logami