Audytor prosi o logi sprzed pół roku — czy jesteś w stanie je pokazać?
Firmy, które przygotowują się do obowiązków wynikających z ustawy o krajowym systemie cyberbezpieczeństwa, zwykle zaczynają od kalendarza: kiedy trzeba zgłosić się do wykazu, w jakim czasie raportować incydent, do kiedy wdrożyć środki techniczne. To dobry początek — terminy zgłaszania incydentów opisaliśmy osobno. Problem pojawia się jednak dopiero przy drugim pytaniu, które pada zarówno podczas obsługi incydentu, jak i podczas kontroli: na jakiej podstawie twierdzisz, że tak właśnie było?
Odpowiedzią są logi. I to jest moment, w którym wiele organizacji odkrywa, że ma ich za mało, za krótko albo w niewłaściwym miejscu.
Logi to nie narzędzie diagnostyczne — to materiał dowodowy
Administratorzy traktują logi jako coś, do czego sięga się, kiedy „coś nie działa”. W kontekście zgodności ich rola jest inna: to jedyny obiektywny zapis tego, co wydarzyło się w systemie, kiedy nikt nie patrzył.
Trzy różne reżimy wymagają dokładnie tego samego:
- Ustawa o KSC (wdrażająca NIS2) — zgłoszenie incydentu to nie tylko formularz. Podmiot musi być w stanie odtworzyć przebieg zdarzenia, zakres naruszenia i podjęte działania, a potem uzupełnić raport końcowy o ustalenia, których w pierwszej dobie jeszcze nie miał.
- RODO — dokumentacja naruszenia ochrony danych osobowych ma wykazać, jakich danych dotyczyło zdarzenie i kto miał do nich dostęp. Bez logów dostępu jest to rekonstrukcja z pamięci.
- ISO 27001 — załącznik A wprost przewiduje kontrole dotyczące rejestrowania zdarzeń i monitorowania działań. Audytor nie sprawdza, czy masz logi, tylko czy potrafisz je przedstawić za deklarowany okres. Więcej o praktycznej stronie systemu zarządzania piszemy we wpisie o ISO 27001 i SZBI.
Wspólny mianownik: liczy się nie sam fakt logowania, ale dostępność zapisów po czasie i ich wiarygodność.
Trzy pytania, na które musi odpowiadać polityka retencji
Zanim kupisz jakiekolwiek narzędzie, odpowiedz na trzy pytania — najlepiej na piśmie, bo to ten dokument pokażesz audytorowi.
Co zbieramy? Minimum to: uwierzytelnienia (udane i nieudane), operacje administracyjne i podniesienie uprawnień, zmiany konfiguracji, zdarzenia z firewalla i systemu backupu oraz logi aplikacji przetwarzających dane osobowe. Zbieranie „wszystkiego” brzmi bezpiecznie, ale kończy się wolumenem, którego nikt nie przegląda i którego nie da się utrzymać.
Jak długo? Okres retencji powinien wynikać z realnego czasu wykrycia incydentu w Twojej organizacji, a nie z domyślnej konfiguracji narzędzia. Kilkanaście dni to typowe ustawienie — i typowa przyczyna, dla której przy kontroli okazuje się, że interesujący okres już się nadpisał. Retencja liczona w miesiącach dla logów bezpieczeństwa jest praktycznym punktem wyjścia, przy krótszym oknie dla zapisów czysto operacyjnych.
Gdzie? To pytanie decyduje o wszystkim pozostałym.
Dlaczego logi na zaatakowanej maszynie nie są dowodem
Jeżeli zapisy leżą wyłącznie na serwerze, którego dotyczył incydent, atakujący z uprawnieniami administratora może je usunąć lub zmodyfikować — a Ty nie masz jak wykazać, że tego nie zrobił. Ten sam mechanizm dotyczy kopii zapasowych i opisaliśmy go szerzej we wpisie o tym, dlaczego ransomware najpierw kasuje backup.
Wnioski praktyczne są trzy:
- Wysyłaj logi poza maszynę źródłową w czasie rzeczywistym. Centralny kolektor w oddzielnym segmencie sieci, z jednokierunkowym ruchem, to absolutne minimum.
- Oddziel konta. Administrator systemu produkcyjnego nie powinien mieć prawa kasowania archiwum logów.
- Zadbaj o niezmienialność i czas. Zapisy tylko-do-odczytu oraz spójna synchronizacja czasu na wszystkich urządzeniach — bez tego korelacja zdarzeń między serwerem, firewallem i aplikacją jest bezwartościowa.
Archiwum logów to dane, które muszą przetrwać awarię i atak, ale rzadko wymagają najszybszych dysków. W praktyce dobrze sprawdza się osobna, rozliczana za pojemność powierzchnia pod backup oraz wydzielona sieć wewnętrzna między maszynami, tak aby kolektor nie był wystawiony do internetu.
Czego nie wygenerujesz samodzielnie
Część materiału dowodowego powstaje poza Twoim systemem operacyjnym — i to zwykle ta część, której audytor lub biegły szuka najpierw.
- Kto fizycznie zbliżył się do sprzętu. W Sprint Data Center obszar operacyjny objęty jest całodobowym monitoringiem wizyjnym z pełnym zapisem wydarzeń oraz systemem dostępowym z pełną rejestracją wizyt, a wejście do stref technicznych odbywa się w asyście pracownika technicznego. W usłudze kolokacji dostęp do własnego serwera realizowany jest w asyście specjalisty — każde takie wejście zostawia ślad, którego nie da się odtworzyć z logów systemowych.
- Co działo się z ruchem sieciowym. Monitoring zewnętrzny i wewnętrzny oraz ochrona AntyDDoS działają na warstwie, do której serwer nie ma wglądu.
- Kto i kiedy realizował prace serwisowe. Obsługa techniczna w trybie 24/7/365 pracuje na zgłoszeniach, a te są rejestrowane po stronie operatora.
Jeśli Twoja infrastruktura stoi na serwerach dedykowanych lub w kolokacji, warto z góry ustalić, jakie zapisy operator jest w stanie udostępnić na wniosek i w jakim trybie. Najgorszy moment na zadanie tego pytania to trzecia godzina obsługi incydentu.
Podsumowanie
Zgodność nie polega na tym, że coś się wydarzyło zgodnie z procedurą — tylko na tym, że potrafisz to wykazać. Retencja logów jest tanim elementem architektury bezpieczeństwa i jednocześnie tym, który najczęściej zawodzi w praktyce, bo nikt nie sprawdził go przed kontrolą.
Zrób prosty test: wybierz losowy dzień sprzed sześciu miesięcy i spróbuj odtworzyć, kto logował się na kluczowy serwer. Jeśli zajmie to więcej niż kilkanaście minut albo skończy się na „już nie mamy” — masz gotowy punkt do planu naprawczego.
Chcesz omówić, jak rozłożyć odpowiedzialność za zapisy między swój zespół a operatora data center? Skontaktuj się z nami — doradzimy, jak ułożyć to w ramach kolokacji lub serwerów dedykowanych.
FAQ – najczęściej zadawane pytania o retencję logów
Jak długo trzeba przechowywać logi na potrzeby ustawy o KSC?
Przepisy nie podają jednej uniwersalnej liczby dni — okres retencji powinien wynikać z analizy ryzyka i realnego czasu wykrywania incydentów w organizacji. Praktyczny punkt wyjścia to retencja liczona w miesiącach dla logów bezpieczeństwa, udokumentowana w polityce, do której możesz odesłać audytora.
Czy backup serwera wystarczy zamiast archiwum logów?
Nie w pełni. Kopia zapasowa odtwarza stan systemu z danego momentu, ale nie daje ciągłego, chronologicznego zapisu zdarzeń między kopiami. Do rekonstrukcji przebiegu incydentu potrzebujesz strumienia logów wysyłanego poza maszynę na bieżąco — backup jest uzupełnieniem, nie zamiennikiem.
Kto odpowiada za logi w kolokacji — klient czy data center?
Za logi systemów i aplikacji na własnym sprzęcie odpowiada klient, ponieważ to on ma do nich wyłączny dostęp. Operator dysponuje zapisami z własnej warstwy: kontroli dostępu fizycznego, monitoringu i realizowanych zgłoszeń serwisowych. Podział ten warto opisać w umowie, zanim wydarzy się incydent.
Czy logi trzymane na tym samym serwerze mają wartość dowodową?
Ich wartość jest ograniczona. Osoba z uprawnieniami administracyjnymi — także atakujący, który je przejął — może je usunąć lub zmienić, a Ty nie wykażesz, że tak się nie stało. Dlatego kluczowa jest wysyłka do niezależnego kolektora i rozdzielenie uprawnień do systemu produkcyjnego oraz do archiwum.
Od czego zacząć, jeśli dziś nie mamy żadnej polityki retencji?
Od inwentaryzacji: wypisz systemy przetwarzające dane wrażliwe i sprawdź, co faktycznie logują oraz jak długo te zapisy przetrwają. Ta lista zwykle sama wskazuje priorytety — najczęściej brakuje centralnego kolektora i spójnej synchronizacji czasu, a to dwie zmiany o najlepszym stosunku efektu do kosztu.
Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu Sprint Data Center. Grafika ilustracyjna została wygenerowana przez AI.