retencja logów

Retencja logów to polityka określająca, jak długo i w jakiej postaci przechowuje się dzienniki zdarzeń systemów, aplikacji i urządzeń sieciowych. Od niej zależy, czy incydent sprzed miesięcy da się jeszcze odtworzyć. Zarządzanie logami, w tym ich przechowywanie, opisuje m.in. publikacja NIST SP 800-92 ^[1]. OWASP formułuje zasadę dwustronną: logów nie wolno niszczyć przed upływem wymaganego okresu przechowywania ani trzymać dłużej, niż ten okres przewiduje ^[2].

Jak działa

Polityka retencji odpowiada na kilka pytań: które logi się zbiera, gdzie się je przechowuje, jak długo, kto ma do nich dostęp i jak się je usuwa. OWASP podkreśla, że okresy wynikają z obowiązków prawnych, regulacyjnych i umownych ^[2]. Ta sama zasada dotyczy tymczasowych logów debugowania oraz kopii i wyciągów z logów ^[2].

Logi przechodzą zwykle przez kilka poziomów przechowywania, od szybkiego i drogiego do taniego i wolnego. Schemat poniżej pokazuje typowy cykl życia wpisu.

RYS. 1Cykl życia wpisu w logu

Amerykańskie memorandum M-21-31 definiuje przechowywanie aktywne jako takie, które ułatwia częste użycie i łatwy dostęp, a przechowywanie zimne jako minimalizujące koszty przy zachowaniu pewnego poziomu dostępu ^[3].

Okresy przechowywania

Nie ma jednego okresu retencji obowiązującego wszystkich. Wybrane punkty odniesienia zestawia tabela.

Memorandum M-21-31 z 27 sierpnia 2021 roku dotyczy federalnych agencji USA i zostało wydane po incydentach takich jak SolarWinds ^[3]. Zastrzega, że podane okresy są wartościami minimalnymi ^[3]. Przewiduje też uwzględnienie tych wymagań w kolejnej wersji SP 800-92 ^[3].

W Polsce przepisy nie wskazują jednej liczby. Sekurak, omawiając NIS2 i ustawę o KSC, zauważa, że akty te nie narzucają sztywnej retencji ^[5]. Autor proponuje model trzech stref: gorącej na 30–60 dni z pełnym indeksowaniem, ciepłej na 6–12 miesięcy i zimnej na co najmniej 24 miesiące, uzasadniając ją cyklem audytów ^[5].

Retencja a ochrona danych

Logi serwera WWW zawierają zwykle adresy IP. RODO w motywie 30 wskazuje, że osobom fizycznym mogą zostać przypisane identyfikatory internetowe, takie jak adresy IP i identyfikatory plików cookie ^[4]. Do takich logów stosuje się więc zasadę ograniczenia przechowywania: dane w formie umożliwiającej identyfikację wolno przechowywać nie dłużej, niż jest to niezbędne do celów przetwarzania ^[4]. Okres retencji powinien zatem wynikać z celu, na przykład z potrzeb reagowania na incydenty, i być opisany przez administratora danych.

OWASP wymienia dane, których w ogóle nie należy zapisywać w logach: hasła, identyfikatory sesji, tokeny dostępowe, klucze szyfrujące i dane kart płatniczych ^[2]. Wpis zawierający token sesyjny przedłuża ryzyko o cały okres retencji.

W WordPressie

Sam WordPress nie prowadzi dziennika zdarzeń bezpieczeństwa. Logi dostępu i błędów tworzy serwer WWW, a ich retencję ustala zwykle hosting; na hostingu współdzielonym właściciel strony ma na nią niewielki wpływ. Warto więc sprawdzić, ile dni logów przechowuje dostawca i czy można je pobierać.

Rdzeń ma tryb zapisu błędów PHP. Stała WP_DEBUG_LOG ustawiona na true zapisuje log w pliku debug.log w katalogu treści, zwykle wp-content/debug.log; można też podać inną ścieżkę ^[6]. Stała działa tylko przy włączonym WP_DEBUG ^[6]. Dokumentacja nie zaleca używania narzędzi debugowania na stronach produkcyjnych ^[6], co opisuje hasło tryb debugowania na produkcji. Plik w domyślnym miejscu może stać się jednym z publicznie dostępnych plików wrażliwych, dlatego bezpieczniej wskazać ścieżkę poza katalogiem publicznym.

// wp-config.php — log poza katalogiem publicznym, bez wyświetlania błędów
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/example/logs/wp-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );

Logi mają znaczenie po włamaniu. Dokumentacja WordPress.org zauważa, że analiza śledcza jest dla właścicieli stron często bardzo trudna, m.in. z powodu braku dostępnych danych ^[7]. Jeśli dane są, można je analizować narzędziami takimi jak OSSEC albo Splunk ^[7]. Zbyt krótka retencja oznacza, że ślady wejścia napastnika znikną, zanim ktoś zacznie ich szukać.

Zagrożenia i skutki

Zbyt krótka retencja uniemożliwia ustalenie, jak i kiedy doszło do włamania. Im dłuższy czas przebywania atakującego w sieci, tym większa szansa, że logi z początku incydentu zostały już nadpisane. Bez nich informatyka śledcza nie odtworzy przebiegu zdarzeń, a wskaźniki kompromitacji nie dadzą się sprawdzić wstecz.

Zbyt długa retencja też ma koszty. Rośnie ilość danych osobowych, które mogą wyciec, oraz koszt przechowywania. Logi bez ochrony mogą też zostać zmienione przez napastnika, który chce zatrzeć ślady.

Dobre praktyki

• Spisany okres retencji dla każdej kategorii logów, uzasadniony celem i przepisami ^[2].
• Centralizacja logów poza serwerem strony, na przykład w SIEM (Security Information and Event Management), tak aby włamanie na serwer nie kasowało śladów.
• Wykrywanie modyfikacji i usunięcia wpisów oraz jak najszybsze kopiowanie logów na nośnik tylko do odczytu ^[2]; pokrewne rozwiązanie opisuje hasło kopia niezmienna (immutable backup).
• Rejestrowanie i monitorowanie każdego dostępu do logów ^[2].
• Synchronizacja czasu na wszystkich serwerach i urządzeniach, bez której nie da się zestawić zdarzeń z różnych źródeł ^[2].
• Kontrola integralności logów w całym okresie retencji i alarm, gdy zapis logów niespodziewanie ustanie; oba wymagania stawia M-21-31 ^[3].
• Włączenie do retencji logów WAF, które często jako jedyne pokazują próby ataku na aplikację.