Najważniejsze wnioski
- Monitoring powinien odpowiadać na pytanie, co jest krytyczne i kto ma zareagować.
- Zabbix skupia się na metrykach, dostępności, wydajności i stanie usług.
- Wazuh analizuje logi, zmiany w systemach i zdarzenia związane z bezpieczeństwem.
- Największą wartość daje połączenie alertu z właścicielem, priorytetem i instrukcją reakcji.
- Setki nieprzefiltrowanych powiadomień nie są monitoringiem - są nowym źródłem problemów.
Po co firmie monitoring?
Bez monitoringu firma dowiaduje się o awarii najczęściej od użytkownika. Wtedy trudno ustalić, kiedy rozpoczął się problem, co było jego przyczyną i czy podobne zdarzenie wystąpiło wcześniej. Metryki, logi i historia alertów pozwalają reagować wcześniej oraz planować rozbudowę na podstawie danych.
Monitoring bezpieczeństwa ma inny cel niż monitoring wydajności. Nie każde przeciążenie jest incydentem, a nie każda zmiana w logu jest atakiem. Dlatego systemy i reguły muszą być dopasowane do środowiska oraz procesu weryfikacji.
Zabbix i Wazuh - dwa uzupełniające się spojrzenia
Zabbix
Mierzy CPU, pamięć, miejsce na dyskach, dostępność usług, czas odpowiedzi, ruch sieciowy i parametry urządzeń. Pomaga wykryć degradację zanim dojdzie do awarii.
Wazuh
Zbiera i analizuje logi, wykrywa wybrane zmiany plików, nietypowe procesy, błędy zabezpieczeń i zdarzenia wymagające weryfikacji.
Dashboardy
Powinny pokazywać stan usług ważnych dla firmy, a nie każdą możliwą metrykę. Widok dla administratora może być inny niż raport dla właściciela procesu.
Reakcja
Alert musi mieć priorytet, właściciela, kanał eskalacji i instrukcję. Bez tego pozostaje tylko informacją.
Jak ocenić obecną sytuację?
- Czy wiemy, które systemy i usługi są krytyczne?
- Czy znamy normalne wartości obciążenia i czasów odpowiedzi?
- Czy błędy backupu, miejsce na dyskach i temperatura generują alert?
- Czy logi z ważnych serwerów i urządzeń trafiają do jednego miejsca?
- Czy każdy alert ma właściciela i ustalony czas reakcji?
- Czy alerty są testowane po zmianach konfiguracji?
- Czy logowanie do systemu monitoringu jest chronione i audytowane?
- Czy firma wie, co zrobić po wykryciu podejrzanego zdarzenia?
Alerty, które mają sens
Próg powinien wynikać z wpływu na usługę, a nie z przypadkowej wartości. Przykładowo, chwilowy skok CPU może być normalny, ale brak miejsca na dysku systemu produkcyjnego wymaga konkretnej reakcji. Warto używać opóźnień, zależności i deduplikacji, aby jeden problem nie tworzył kilkudziesięciu zgłoszeń.
Informacja
Zdarzenie obserwacyjne, które nie wymaga natychmiastowej reakcji.
Ostrzeżenie
Trend lub stan wymagający sprawdzenia w ustalonym czasie.
Krytyczne
Problem z bezpośrednim wpływem na usługę lub bezpieczeństwo.
Eskalacja
Alert, który nie został potwierdzony lub rozwiązany w założonym czasie.
Logi i bezpieczeństwo
Wazuh może wspierać analizę logów, kontrolę integralności plików i wykrywanie zdarzeń na hostach. Reguły powinny być dostosowane do systemów firmy, a wynik analizy musi być weryfikowany przez człowieka. Sam wpis w logu nie oznacza jeszcze potwierdzonego incydentu.
- Ogranicz dostęp administratorów do systemu monitoringu.
- Chroń logi przed usunięciem i nieautoryzowaną zmianą.
- Ustal czas przechowywania i zakres zbieranych danych.
- Nie zbieraj wszystkiego bez celu - ogranicz szum i koszty.
- Przygotuj procedurę izolacji konta lub urządzenia.
- Dokumentuj weryfikację i zamknięcie zdarzeń.
Najczęstsze błędy
Włączone wszystkie reguły
Nadmierna liczba alertów powoduje zmęczenie i ignorowanie ważnych zdarzeń. Reguły trzeba stroić na podstawie realnego środowiska.
Brak właściciela alertu
Powiadomienie wysłane do wspólnej skrzynki często nie prowadzi do reakcji. Każdy priorytet powinien mieć odpowiedzialność i eskalację.
Monitoring bez testów
Jeśli nie sprawdzasz alarmu po awarii usługi, możesz nie wiedzieć, że system monitoringu sam przestał działać.
Od czego zależy koszt?
Na koszt wpływają liczba hostów i urządzeń, ilość logów, wymagany czas przechowywania, retencja, wysoka dostępność, integracje, kanały powiadomień i czas potrzebny na analizę. Tańsze narzędzie nie pomaga, jeśli firma nie ma procesu weryfikacji i reakcji.
Plan wdrożenia krok po kroku
- Określ cele. Wybierz usługi i zdarzenia, które mają znaczenie dla pracy firmy.
- Zinwentaryzuj źródła. Spisz serwery, urządzenia, aplikacje i logi dostępne w środowisku.
- Ustal normalny stan. Zbierz bazowe wartości obciążenia, dostępności i ruchu.
- Zaprojektuj alerty. Określ progi, priorytety, właścicieli i eskalację.
- Wykonaj pilotaż. Testuj na ograniczonej grupie i stroń reguły przed rozszerzeniem.
- Udokumentuj reakcję. Przygotuj krótkie runbooki i regularnie sprawdzaj działanie monitoringu.
Lista kontrolna
- Lista systemów krytycznych jest aktualna.
- Metryki i logi mają określone cele.
- Alerty mają priorytety i właścicieli.
- Istnieje kanał eskalacji.
- Dashboardy pokazują ważne informacje.
- Logi są chronione przed zmianą.
- Monitoring ma własny monitoring dostępności.
- Runbooki są aktualizowane po zmianach.
Co firma może zrobić samodzielnie?
Można zacząć od spisu usług krytycznych, zdefiniowania właścicieli oraz listy zdarzeń, o których firma chce wiedzieć. Warto też sprawdzić, czy obecne alerty są czytelne i czy ktoś potwierdza ich obsługę.
Kiedy potrzebne jest wsparcie specjalisty?
Wsparcie przydaje się przy integracji wielu źródeł logów, strojeniu reguł bezpieczeństwa, wdrożeniu wysokiej dostępności, porządkowaniu eskalacji i wtedy, gdy incydent wymaga szybkiej izolacji oraz analizy.
Najczęstsze pytania
Czy monitoring obciąża serwery?
Może generować niewielkie obciążenie, ale zakres i częstotliwość pomiarów dobiera się do możliwości środowiska. Warto zacząć od najważniejszych metryk.
Czy Zabbix i Wazuh muszą działać osobno?
Nie zawsze. W małym środowisku można rozpocząć od wspólnej infrastruktury, ale przy większej ilości danych rozdzielenie ułatwia wydajność i niezawodność.
Czy alert oznacza incydent bezpieczeństwa?
Nie. Alert jest sygnałem do weryfikacji. Dopiero analiza kontekstu, źródła i skutku pozwala zaklasyfikować zdarzenie.
Czy monitoring może tworzyć zgłoszenia w helpdesku?
Tak. Integracja może automatycznie tworzyć zgłoszenie z priorytetem, opisem i linkiem do wykresu lub logu.
Jak często stroić alerty?
Po wdrożeniu częściej, a później po zmianach środowiska i przeglądach. Progi powinny odzwierciedlać aktualny sposób pracy.