Wdrożenie centralnego systemu logów zwykle zaczyna się od decyzji „zbieramy wszystko, potem się zobaczy”. Po kilku miesiącach dysk jest pełny, wyszukiwanie trwa minutami, a odpowiedzi na proste pytanie o logowania konkretnego użytkownika trzeba szukać wśród milionów zdarzeń o odświeżaniu polityk grupowych. Strategia logowania to zestaw decyzji podjętych przed uruchomieniem, nie po.
Pytanie pierwsze: po co
Każdy strumień logów powinien mieć odpowiedź na pytanie, do czego zostanie użyty. W praktyce są trzy odpowiedzi:
- Bezpieczeństwo i audyt. Logowania, zmiany uprawnień, zmiany w grupach uprzywilejowanych, tworzenie kont, dostęp do zasobów wrażliwych. Te zdarzenia muszą być kompletne, niezmienialne i przechowywane długo, często ze względu na wymagania formalne.
- Diagnostyka. Błędy aplikacji, zdarzenia systemowe, logi usług. Potrzebne szybko po wystąpieniu problemu, rzadko potrzebne po miesiącu.
- Metryki wyprowadzone z logów. Liczba żądań, czasy odpowiedzi, liczba błędów na minutę. Same logi po policzeniu można usunąć, liczniki zostają.
Strumień, który nie ma przypisanego celu, nie powinien trafiać do centrali. Można go zostawić lokalnie z krótką rotacją.
Pytanie drugie: co dokładnie z kontrolerów domeny
Kontrolery domeny Active Directory generują ogromne ilości zdarzeń, z których większość nie ma wartości poza lokalną diagnostyką. Zbieranie całego dziennika zabezpieczeń z trzech kontrolerów potrafi wygenerować więcej danych niż wszystkie pozostałe serwery razem.
Zamiast całego dziennika warto wybrać identyfikatory zdarzeń, które odpowiadają na konkretne pytania:
| Pytanie | Zdarzenia |
|---|---|
| Kto i skąd się logował | 4624, 4625, 4768, 4769, 4771 |
| Kto zmienił członkostwo w grupach | 4728, 4729, 4732, 4733, 4756, 4757 |
| Kto tworzył lub modyfikował konta | 4720, 4722, 4725, 4726, 4738, 4740 |
| Kto zmieniał hasła | 4723, 4724 |
| Zmiany w politykach i uprawnieniach | 4670, 4719, 4739 |
Agent zbierający logi powinien filtrować po stronie źródła. Wysyłanie wszystkiego i filtrowanie w centrali to marnowanie łącza, miejsca i mocy obliczeniowej.
Pytanie trzecie: w jakiej formie
Log w postaci wolnego tekstu jest łatwy do wysłania i trudny do przeszukania. Log ze sparsowanymi polami, w którym nazwa użytkownika, adres źródłowy i wynik są osobnymi atrybutami, pozwala budować zapytania, pulpity i alerty bez wyrażeń regularnych.
Parsowanie należy wykonywać najbliżej źródła, gdzie struktura zdarzenia jest znana. Agent na serwerze Windows wie, że pole TargetUserName to nazwa użytkownika. Centrala, która dostaje tekst, musi się tego domyślać.
Format transportu ma znaczenie drugorzędne, ale protokół już nie. UDP jest prostszy i tańszy, lecz gubi zdarzenia przy przeciążeniu lub restarcie odbiorcy, i nikt się o tym nie dowie. Dla zdarzeń bezpieczeństwa należy używać TCP lub protokołu z potwierdzeniami, nawet jeśli oznacza to więcej konfiguracji.
Pytanie czwarte: jak długo
Retencja to koszt, który rośnie liniowo z czasem i objętością. Różne strumienie potrzebują różnych okresów:
- zdarzenia bezpieczeństwa: rok lub dłużej, zależnie od wymagań,
- logi aplikacji i systemowe: dwa do czterech tygodni,
- logi diagnostyczne o wysokim wolumenie: kilka dni albo tylko lokalnie.
Wymaga to osobnych strumieni lub indeksów w systemie centralnym, z osobnymi politykami retencji. Jeden wspólny indeks z jedną retencją oznacza, że albo płacisz za rok przechowywania szumu, albo tracisz zdarzenia audytowe po miesiącu.
Pytanie piąte: kto patrzy
Log, na który nikt nie patrzy i który nie generuje alertów, ma wartość wyłącznie retrospektywną. To może być wystarczające dla zdarzeń audytowych, ale dla diagnostyki i bezpieczeństwa potrzebne są reguły: seria nieudanych logowań, dodanie konta do grupy administratorów domeny poza oknem serwisowym, logowanie kontem serwisowym z nieznanego adresu. Kilka dobrze dobranych alertów jest warte więcej niż pulpit z dwudziestoma wykresami.
Podsumowanie
Strategia logowania sprowadza się do pięciu decyzji na każdy strumień: po co, co dokładnie, w jakiej formie, jak długo i kto patrzy. Podjęte przed wdrożeniem, zajmują jedno popołudnie. Podejmowane po fakcie, wymagają migracji danych i przekonania zespołu, że coś, co „działało”, trzeba przebudować.