Centralizacja logów w firmie.
Po co zbierać logi z serwerów, firewalli i aplikacji w jednym miejscu?

Logi w większości firm już istnieją. Problem polega na tym, że znajdują się wszędzie.

Dopóki wszystko działa, nie stanowi to większego problemu. Problem pojawia się w chwili, gdy trzeba odpowiedzieć na pytanie:

Administrator zaczyna wtedy obchód:

i ręcznie próbuje zbudować jedną historię. Centralizacja logów ma przede wszystkim sprawić, żeby ta historia istniała, zanim będzie potrzebna.

Centralizacja logów nie oznacza od razu SIEM

To ważne rozróżnienie. Można centralizować logi bez:

Pierwszy cel może być znacznie prostszy:

Już samo to daje dużą wartość podczas awarii i incydentów.

Cztery główne powody centralizacji logów

1. Incident Response

Załóżmy, że o 14:03 dzieje się coś podejrzanego:

Jeżeli każde zdarzenie znajduje się w osobnym systemie, trzeba ręcznie ustalić:

• › czy dotyczyły tego samego użytkownika,
• › czy pochodziły z tego samego IP,
• › w jakiej kolejności nastąpiły,
• › czy były częścią jednej operacji.

Po centralizacji możemy po prostu szukać:

user = user123
czas = 14:00-14:10

i zobaczyć historię z wielu źródeł. Centralny system nie wykrywa automatycznie każdego ataku. Daje natomiast coś fundamentalnego: wspólny timeline. Jak wykorzystać go w pierwszych minutach incydentu, opisujemy w artykule AI podczas awarii: pierwsze 30 minut incydentu.

2. Troubleshooting i awarie

Centralizacja logów nie jest tylko narzędziem security. Często większą wartość daje administratorowi podczas zwykłej diagnostyki. Przykład:

10:14 aplikacja zaczyna zgłaszać timeout
10:14 PostgreSQL raportuje brak wolnych połączeń
10:15 systemd restartuje worker
10:16 nginx zaczyna zwracać 502

service = erp
czas = 10:10-10:20

To może skrócić diagnostykę nawet wtedy, gdy nie wydarzył się żaden incydent bezpieczeństwa.

3. Audyt i możliwość odtworzenia zdarzeń

Czasem trzeba odpowiedzieć na pytania:

Jeżeli log istnieje tylko na hoście źródłowym, mamy kilka problemów:

Przesłanie logu do oddzielnego systemu zmniejsza to ryzyko. Ale sama centralizacja nie gwarantuje integralności. Dla istotnych logów warto rozważyć:

4. Zachowanie historii po awarii hosta

Lokalna rotacja logów chroni przede wszystkim dysk. Nie historię incydentu. Jeżeli serwer ulegnie awarii, centralna kopia logów nadal może istnieć. To szczególnie istotne dla:

NIS2 i RODO: dwie strony tej samej decyzji

Dlatego nie istnieje uniwersalna zasada "każdy log = 365 dni". Retencja powinna wynikać z:

Od jakich źródeł zacząć?

Nie zaczynałbym od "zbieramy wszystko". W małej i średniej firmie sensowniejsza jest kolejność według wartości informacji.

Ta kolejność nie jest uniwersalnym standardem. Firma produkcyjna może zacząć od OT. Firma SaaS może zacząć od aplikacji i chmury. Chodzi o zasadę:

Tożsamość

Jedno z najważniejszych źródeł. Warto widzieć między innymi:

Bez tej warstwy podczas incydentu często nie da się odpowiedzieć na podstawowe pytanie: "Kto to zrobił?"

Windows: nie zawsze potrzebujesz dodatkowego agenta

W środowisku Windows można wykorzystać Windows Event Forwarding i Windows Event Collector. Microsoft pozwala skonfigurować subskrypcje, w których komputery źródłowe przesyłają wybrane zdarzenia do centralnego collectora przez mechanizmy Windows Remote Management.

Dopiero stamtąd można przesyłać zdarzenia dalej do SIEM, Loki, OpenSearch, Wazuh lub innego systemu logowego. To szczególnie ciekawa opcja, jeżeli firma już posiada domenę Windows.

Linux

Typowe źródła to:

Nie trzeba od razu wysyłać wszystkiego. Warto zacząć od logowania, privilege escalation, krytycznych usług, błędów aplikacyjnych i zdarzeń bezpieczeństwa.

Firewall i VPN

To źródła bardzo cenne zarówno dla security, jak i diagnostyki. Przykład trzech zdarzeń z trzech różnych systemów:

Centralizacja pozwala połączyć te zdarzenia w jedną historię. Co jeszcze warto zbierać z urządzeń sieciowych, opisujemy w artykule monitoring sieci w firmie.

Backup

Logi backupu często są niedoceniane. Powinniśmy móc szybko znaleźć:

Centralny system może wtedy odpowiedzieć: "Które backupy nie wykonały się poprawnie przez ostatnie siedem dni?". Nie zastępuje to monitoringu backupów ani testów odtwarzania. Ale daje historię.

Jak transportować logi?

Tu trzeba rozdzielić kilka przypadków.

Nie pisałbym więc, że "UDP 514 jest zawsze błędem". Ale dla ważnych logów i transmisji przez niezaufane sieci zdecydowanie preferowałbym bezpieczniejszy transport.

Przykładowe agenty

Promtail już nie powinien trafiać do nowych wdrożeń

Jeśli Promtail nadal działa w Twojej infrastrukturze, to dobry przykład oprogramowania po końcu wsparcia, o którym piszemy w artykule koniec wsparcia systemu lub urządzenia.

Lokalny bufor ma ogromne znaczenie

Wyobraźmy sobie, że collector jest przez dziesięć minut niedostępny. Co dzieje się z logami?

Fluent Bit posiada filesystem buffering oraz możliwość ograniczenia rozmiaru kolejki per output. To szczególnie ważne, ponieważ utrata połączenia z systemem logowania często występuje właśnie podczas problemu, który próbujemy później zdiagnozować.

Przykład Fluent Bit z filesystem buffering

To tylko szkic pokazujący ideę:

service:
  flush: 5
  log_level: info
  storage.path: /var/lib/fluent-bit/storage
  storage.type: filesystem
  storage.inherit: on

pipeline:
  inputs:
    - name: systemd
      tag: linux.journal
      storage.type: filesystem

  outputs:
    - name: forward
      match: "*"
      host: logs.internal.example
      port: 24224
      tls: on
      tls.verify: on
      storage.total_limit_size: 1G

W produkcji trzeba oczywiście dopasować:

Synchronizacja czasu jest częścią systemu logowania

Jeżeli serwery mają różne zegary, wspólny indeks nie wystarczy. Możemy dostać:

14:02 firewall
14:05 aplikacja
14:01 hypervisor

choć wszystkie zdarzenia nastąpiły w odwrotnej kolejności. Dlatego potrzebujemy:

Interfejs może później prezentować czas lokalny użytkownika. Dane źródłowe powinny pozwalać jednoznacznie ustalić kolejność.

Normalizacja pól

Centralizacja jest dużo bardziej użyteczna, gdy podobne informacje mają podobne nazwy. Na przykład:

Nie oznacza to jednak, że wszystkie te pola powinny być indeksowane w ten sam sposób.

Szczególnie ważne przy Grafana Loki

Loki działa inaczej niż klasyczne systemy indeksujące pełną treść. Indeksuje przede wszystkim labels opisujące log stream, a nie zawartość każdej linii.

Grafana zaleca dla tego typu informacji structured metadata lub parsowanie podczas zapytania zamiast tworzenia ogromnej liczby unikalnych streamów. To ważne, bo źle zaprojektowane labels mogą bardzo mocno pogorszyć działanie Loki.

Gdzie i jak długo przechowywać logi?

Nie każda firma potrzebuje klasycznego podziału hot/warm/cold. Chodzi o to, żeby koszt przechowywania odpowiadał temu, jak często logi są używane.

Nie podawałbym też jednej retencji typu "90 dni" dla całej firmy. Inną może mieć log bezpieczeństwa, log debug aplikacji, access log WWW, audit log IAM czy log backupu. Dla każdego źródła warto odpowiedzieć na kilka pytań:

To jest dużo lepsze niż "wszystko przez rok, bo może się przydać".

Centralny log nie jest backupem

To inne problemy. Centralizacja logów nie zastępuje backupu bazy, VM, Microsoft 365 ani kopii konfiguracji urządzeń. Podobnie backup logów nie zastępuje prawidłowej retencji i dostępności platformy logowej.

A czy sam system logów powinien mieć backup?

To zależy od jego architektury i wymagań. Jeżeli logi mają znaczenie dowodowe albo długą wymaganą retencję, warto zastanowić się nad replikacją, snapshotami, osobnym archiwum, immutable storage i ograniczeniem możliwości usunięcia. Najgorszy wariant:

Co się stanie, jeśli ransomware obejmie również ten system?

RBAC: nie każdy powinien widzieć wszystkie logi

To różne role. Developer aplikacji może potrzebować app=shop, ale niekoniecznie Windows Security, HR czy logów VPN innych użytkowników. Dlatego centralizacja powinna obejmować również RBAC, audit dostępu, separację tenantów lub indeksów oraz ograniczenie delete.

Logi mogą same zawierać sekrety

To częsty problem. Aplikacja zapisuje na przykład:

Authorization: Bearer eyJ...
password=...
?token=...

Po centralizacji taki sekret znajduje się nagle w jednym dużym indeksie, w backupie, w archiwum i w panelu dostępnym dla większej liczby administratorów.

Ten sam problem wraca, gdy logi trafiają do modeli AI, o czym piszemy w artykule AI w cyberbezpieczeństwie firmy.

Jaki stack wybrać?

Nie istnieje jeden najlepszy. Każdy ma inny profil.

Nie oznacza to, że jeden stack jest zawsze tańszy od drugiego. Metryki z tych samych serwerów można zbierać obok, o czym piszemy w artykule jak monitorować serwery Windows i Linux w jednym miejscu.

Od czego zacząć w małej firmie?

Nie od licencji SIEM. Zacząłbym od pytania:

Następnie pierwsze wdrożenie:

Przez pierwsze tygodnie celem powinno być ustalenie:

Dopiero potem dodajemy kolejne źródła.

Najpierw dashboard czy alert?

Ani jedno, ani drugie. Kolejność jest taka:

Inaczej budujemy ładną wizualizację niekompletnych danych.

Pierwsze alerty

Nie zaczynałbym od 200 reguł. Kilka naprawdę użytecznych przykładów:

Ostatnie dwa są bardzo ważne. Brak zdarzeń również może być zdarzeniem.

Każdy alert powinien mieć odpowiedź na pytanie "co dalej?"

Nie wystarczy WARNING. Administrator powinien wiedzieć:

Jeżeli alert generuje e-mail, którego nikt nie otwiera, nie mamy monitoringu. Mamy generator poczty.

Dlaczego projekty SIEM się wykładają?

Kontrolę działania collectora i retencji warto wpisać do comiesięcznej checklisty utrzymania IT.

A gdzie AI?

Dopiero później. Najpierw fundament, potem warstwa analityczna:

Model językowy analizujący przypadkowo wybrane logi z trzech hostów nie tworzy observability. Tworzy szybszy sposób analizowania niepełnych danych. Jeżeli natomiast mamy dobre dane, AI może pomóc streszczać incydenty, grupować podobne błędy, budować timeline, proponować hipotezy i przygotowywać post-mortem. Jak to zrobić rozsądnie, opisujemy w artykule AI w analizie logów Linux.

Jak może wyglądać małe wdrożenie?

Linux --------+
              |
Windows ------+
              |
Firewall -----+--> COLLECTOR --> LOKI / OPENSEARCH --> GRAFANA
              |
VPN ----------+
              |
Backup -------+

Do tego:

I już mamy rozwiązanie dające realną wartość. Na pierwszym etapie nie potrzebujemy:

Sama centralizacja nie zastąpi też innych warstw ochrony, o czym piszemy w artykule antywirus nie wystarczy.

Jak podchodzimy do centralizacji logów w PRO-Admin?

Nie zaczynamy od produktu. Najpierw sprawdzamy:

Dopiero później dobieramy collectory, storage, transport, retencję, dashboardy i alerty.

FAQ - centralizacja logów

Podsumowanie

Dobra architektura wygląda tak:

Najważniejsze rzeczy to:

Dashboard jest końcem tego procesu. Nie początkiem.