Monitoring infrastruktury z elementami SIEM: Zabbix, Checkmk i Wazuh w praktyce

Dwa światy, których nikt nie spina: monitoring i bezpieczeństwo

W typowej organizacji monitoring infrastruktury i bezpieczeństwo żyją osobno. Zabbix (lub Nagios/Checkmk) pilnuje, czy serwer odpowiada, czy jest miejsce na dysku i czy usługa działa. Logi bezpieczeństwa — jeśli są zbierane — leżą w osobnym systemie albo wcale. Efekt:

• Alarmy techniczne nie są powiązane z kontekstem bezpieczeństwa (np. skokowy wzrost logowań tuż przed awarią).
• Brak jednego źródła prawdy o tym, co dzieje się w infrastrukturze i w usługach.
• Brak korelacji — pojedyncze zdarzenia, które razem tworzą incydent, przechodzą niezauważone.
• Brak dowodów dla audytu: kto, kiedy i jak reagował.

Wymagania regulacyjne a rzeczywistość

Od 3 kwietnia 2026 r. obowiązuje nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (KSC), wdrażająca dyrektywę NIS2. Podmioty kluczowe i ważne, które w dniu wejścia w życie nowelizacji spełniały kryteria, mają:

• dokonać wpisu do Wykazu KSC do 3 października 2026 r.,
• podłączyć się do systemu S46 do 3 kwietnia 2027 r.,
• wdrożyć obowiązki ustawowe do 3 kwietnia 2027 r. — w tym SZBI, zgłaszanie incydentów do zespołów CSIRT i zarządzanie nimi,
• przeprowadzić pierwszy obowiązkowy audyt cyberbezpieczeństwa do 3 kwietnia 2028 r. (podmioty kluczowe), a kolejne co najmniej raz na trzy lata.

Monitoring i logowanie to jeden z twardych środków zarządzania ryzykiem wymienionych wprost w dyrektywie. Bez ciągłego monitoringu i retencji logów nie da się wykazać ani wykrycia incydentu, ani terminowego zgłoszenia (24 h / 72 h).

Kluczowe wymagania nowego środowiska

• Konsolidacja metryk i logów w jednym modelu operacyjnym.
• Ciągłość obserwacji — brak „martwych stref” na serwerach, sieciach, aplikacjach, bazach.
• Detekcja i korelacja zdarzeń bezpieczeństwa (nie tylko progi techniczne).
• Reakcja — automatyczna (active response) i proceduralna (runbooki).
• Retencja i dowody — okresy przechowywania logów zgodne z prawem i polityką.
• Skalowalność — od kilkudziesięciu do kilku tysięcy hostów, z agentami na Windows i Linux.

Architektura trzech warstw

WARSTWA 1 — METRYKI / DOSTĘPNOŚĆ      WARSTWA 2 — USŁUGI / OBSERWOWALNOŚĆ
ZABBIX                                CHECKMK
agent · SNMP · IPMI                   agent + auto-discovery
triggery · LLD · problemy             specjalni agenci (API)
SLA · eskalacje · mapy                monitoring biznesowy
            │                                     │
            └─────────────────┬───────────────────┘
                              ▼
WARSTWA 3 — BEZPIECZEŃSTWO / SIEM:  WAZUH
agenci · FIM · SCA · detekcja podatności · dekodery i reguły
korelacja · active response · compliance
                              ▼
Wazuh Indexer + Dashboard (OpenSearch) — dashboardy · alerty · API · eksport

Warstwa 1 — Zabbix (metryki, dostępność, SLA)

• Agenci (Windows/Linux) oraz metody bezagentowe (SNMP, IPMI, checks).
• Templates i Low-Level Discovery (LLD) do automatycznego wykrywania zasobów.
• Triggery i problemy z hierarchią ważności.
• Mapy sieci, dashboardy, raporty SLA i eskalacje.
• Skalowanie przez Zabbix Proxy dla wielu lokalizacji lub segmentów.

Zabbix to „fundament widoczności”: wykrywa niedziałające usługi, przeciążenia, brak miejsca i anomalie zasobowe — zanim staną się awarią.

Warstwa 2 — Checkmk (obserwowalność operacyjna i usługi)

• Automatyczne odkrywanie usług na hostach (mniejszy nakład na ręczną konfigurację).
• Specjalni agenci do integracji z API (aplikacje, bazy danych, urządzenia sieciowe, chmury).
• Monitoring oparty na regułach — spójne, wersjonowane konfiguracje.
• Monitoring biznesowy — widok „usługa działa / nie działa” złożony z wielu elementów.
• Powiadomienia do wielu kanałów: e-mail, Teams, Slack, ticketing.

Checkmk sprawdza się tam, gdzie liczy się szybkie wdrożenie i czytelność dla zespołu operacyjnego — oraz jako warstwa monitoringu usług dla NIS2.

Warstwa 3 — Wazuh (SIEM / HIDS / XDR)

• Agenci na Windows/Linux/macOS oraz zbieranie przez syslog (urządzenia, firewalle).
• File Integrity Monitoring (FIM) — wykrywanie zmian w plikach krytycznych.
• Security Configuration Assessment (SCA) — audyt zgodności z baseline’ami CIS.
• Detekcja podatności — porównanie inwentarza oprogramowania z bazami CVE.
• Dekodery i reguły — normalizacja i korelacja logów; własne reguły dla specyfiki organizacji.
• Active response — automatyczne działania (blokada IP, izolacja hosta, zatrzymanie procesu).
• Compliance mapping — mapowanie na NIS2, ISO 27001, PCI DSS, RODO.

Centrum platformy to Wazuh Manager (analiza), Wazuh Indexer (OpenSearch — przechowywanie i przeszukiwanie) oraz Wazuh Dashboard.

Integracje między warstwami

• Zdrowie samego stosu bezpieczeństwa — Zabbix/Checkmk monitorują kondycję serwerów Wazuh (obciążenie, kolejkę zdarzeń, zapełnienie indeksu). Awaria SIEM-u nie może przejść niezauważona.
• Korelacja techniczno-bezpieczeństwowa — alerty Wazuh (np. brute-force, BEC) trafiają do Zabbix jako traps, a zdarzenia techniczne trafiają do Wazuh przez logi.
• Jedno miejsce reakcji — powiadomienia spływają do wspólnego kanału / CMDB / ticketingu, a active response wykonuje automatyzację.
• Integracja z SIEM/SOAR — Wazuh wysyła alerty dalej (webhook, SNMP TRAP, custom integration), łącząc ekosystem z zewnętrznym SOC.

Mapowanie na wymagania NIS2 / SZBI

Retencja, dowody i czas reakcji

• Retencja logów dobrana do wymagań prawnych i wewnętrznych (typowo 6–12 mies., z uwzględnieniem kosztu storage).
• Zgłaszanie incydentów w terminach CSIRT (wczesne ostrzeżenie 24 h, pełne zgłoszenie 72 h) — monitoring dostarcza danych niezbędnych w raporcie.
• NTP/UTC jako wspólny czas wszystkich źródeł — bez tego korelacja traci sens.
• Backup konfiguracji stosu monitoringu i SIEM — równie ważny jak backup produkcji.

Wdrożenie krok po kroku

1. Inwentaryzacja — hosty, urządzenia sieciowe, aplikacje, bazy i urządzenia OT; krytyczność i właściciele.
2. Wybór ról — co idzie do Zabbix (metryki), co do Checkmk (usługi), a co do Wazuh (bezpieczeństwo/logi).
3. Architektura — sizing serwerów, sieć zarządzania w wydzielonym VLAN, HA, plan skalowania.
4. Wdrożenie Zabbix — agenci, SNMP, templates, triggery, mapy, SLA.
5. Wdrożenie Checkmk — auto-discovery, specjalni agenci, monitoring biznesowy, powiadomienia.
6. Wdrożenie Wazuh — manager, indexer, dashboard, agenci, FIM, SCA, reguły; retencja.
7. Integracje — Wazuh ↔ Zabbix/Checkmk, powiadomienia, ticketing, SNMP TRAP.
8. Dostrojenie detekcji — redukcja fałszywych alarmów, korelacja, progi, use-case’y.
9. Reakcja i procedury — runbooki, active response, eskalacje, ćwiczenia tabletop.
10. Zgodność i dowody — raporty NIS2/KSC, mapowanie SZBI, dokumentacja i przekazanie do utrzymania.

Realne dowody działania SZBI

Po wdrożeniu organizacja zyskuje nie tylko spokój operacyjny, ale i realne dowody działania SZBI: monitoring, detekcję, reakcję i retencję, które są wymagane wprost w ustawie i które audytor może zweryfikować.

Najczęstsze pytania

Checklist wdrożeniowy

• Inwentaryzacja zasobów i ustalenie krytyczności
• Podział ról: Zabbix / Checkmk / Wazuh
• Sieć zarządzania w wydzielonym VLAN + HA
• Agenci Zabbix/Checkmk/Wazuh + SNMP dla urządzeń
• FIM, SCA, detekcja podatności w Wazuh
• Reguły i korelacja + redukcja szumu
• Integracje między warstwami (traps, powiadomienia, ticketing)
• Active response i runbooki reakcji
• Retencja logów + NTP/UTC
• Backup konfiguracji stosu monitoringu
• Raporty i mapowanie NIS2/SZBI
• Ćwiczenia i przekazanie do utrzymania

Słowa kluczowe

Źródła

• Ministerstwo Cyfryzacji — Nowelizacja ustawy o KSC: obowiązki podmiotów kluczowych i ważnych
• Wazuh — Ensuring NIS2 compliance with Wazuh
• Zabbix — Zabbix and NIS2
• Wazuh — Dokumentacja: File Integrity Monitoring
• Checkmk — Checkmk Documentation