Log bezpieczeństwa pomaga odtworzyć, kto próbował wykonać daną czynność, na jakim zasobie, kiedy i z jakim skutkiem. Nie jest kopią wszystkich żądań ani zrzutem wyjątków. Jego celem jest dostarczenie przydatnych dowodów do badania podejrzanych dostępów i działań przy użyciu niezbędnego minimum danych oraz zabezpieczeń, które zapobiegają temu, by sam log stał się źródłem wycieku.
Projektując logowanie zdarzeń bezpieczeństwa w PHP, warto najpierw zdefiniować istotne zdarzenia i ich przeznaczenie: wykrywanie, badanie, audyt operacyjny lub zgodność z wewnętrzną polityką. Następnie należy ustalić wspólny format, zdecydować, kto może przeglądać logi, i przetestować cały przepływ. Log, który istnieje, ale nie pozwala uporządkować zdarzeń, określić wyniku ani odróżnić prób od zakończonych działań, nie zaspokaja potrzeb związanych z badaniem incydentów.
Oddziel logi techniczne, aktywność i zdarzenia bezpieczeństwa
Logi techniczne opisują działanie aplikacji: błędy, wyjątki, opóźnienia, problemy z połączeniami lub konfiguracją. Pomagają diagnozować dostępność i zachowanie systemu. Rejestr aktywności dokumentuje działania biznesowe przypisane użytkownikom, takie jak edycja faktury lub zmiana danych konta. Zdarzenia bezpieczeństwa koncentrują się natomiast na faktach istotnych dla ochrony tożsamości, uprawnień, zasobów i granic dostępu.
Kategorie te częściowo się pokrywają, ale nie są zamienne. Zmiana roli może być zarówno działaniem biznesowym, jak i zdarzeniem bezpieczeństwa; wyjątek bazy danych jest zwykle zdarzeniem technicznym, choć seria błędów podczas wrażliwej operacji może uzasadniać alert bezpieczeństwa. Określenie celów pozwala uniknąć bezcelowego powielania informacji oraz dobrać odpowiednie okresy przechowywania, uprawnienia dostępu i formaty.
Nie używaj logu bezpieczeństwa jako nieograniczonego archiwum audytowego ani zamiennika metryk i śladów. Nie zakładaj też, że rejestrowanie zdarzenia oznacza jego wykrycie: do generowania alertów potrzebne są reguły, progi i osoby odpowiedzialne za reakcję. Udokumentuj, który system wytwarza poszczególne dane i który zespół z nich korzysta.
Wybierz działania i kontekst, które umożliwiają badanie
Zacznij od inwentaryzacji działań i zagrożeń istotnych dla aplikacji. Wśród zdarzeń, które zwykle warto uwzględnić, są nieudane logowania, blokady kont, zmiany danych uwierzytelniających, nadawanie lub odbieranie uprawnień, zmiany konfiguracji, wrażliwe eksporty i operacje administracyjne. Lista powinna odzwierciedlać specyfikę produktu: rejestrowanie każdego odczytu strony może generować szum, podczas gdy pominięcie zmiany uprawnień uniemożliwia odtworzenie nieuprawnionego dostępu.
Dla każdego zdarzenia określ, na jakie pytanie ma pozwalać odpowiedzieć. Jeśli badana jest zmiana uprawnienia, istotne może być ustalenie aktora, użytkownika lub zasobu, którego dotyczy zmiana, poprzedniego i nowego uprawnienia, wyniku oraz czasu. W przypadku nieudanego uwierzytelnienia istotny może być znormalizowany lub pseudonimizowany identyfikator konta, zgodnie z polityką, a także wynik i źródło żądania, jeśli ich zebranie jest uzasadnione. Nie wyciągaj wniosków o tożsamości na podstawie współdzielonego adresu IP.
Rozróżniaj próbę, decyzję i wynik. Odrzucone żądanie nie oznacza zakończonej zmiany; zaakceptowane żądanie może zakończyć się niepowodzeniem przed zapisaniem danych. Rejestruj rzeczywisty wynik, a gdy jest to potrzebne do badania — także osiągnięty etap. Zdefiniuj również znaczenie poszczególnych wartości, takich jak denied, failed czy succeeded, aby różne komponenty nie używały ich w sprzeczny sposób.
Stosuj spójny schemat umożliwiający korelację
Ustrukturyzowany format, zwykle JSON, ułatwia filtrowanie i korelowanie zdarzeń w narzędziach operacyjnych. Jako podstawę uwzględnij następujące pola:
- Identyfikator zdarzenia: stabilna, wersjonowana nazwa, na przykład
authorization.permission_changed. - Czas: data i godzina w UTC, z odpowiednią precyzją i zsynchronizowanymi zegarami systemów.
- Aktor: wewnętrzny identyfikator lub pseudonim; procesy i zadania automatyczne oznaczaj jawnie.
- Działanie i zasób: wykonana operacja oraz typ i identyfikator zasobu, którego dotyczy, bez uwzględniania jego zawartości.
- Wynik: powodzenie, odrzucenie lub błąd wraz z niesensytywną, skategoryzowaną przyczyną.
- Korelacja: identyfikator żądania lub operacji, który pozwala powiązać zdarzenia bez zapisywania całego żądania.
- Kontekst źródła: usługa lub komponent, który wygenerował zdarzenie, oraz — jeśli jest to uzasadnione — ograniczone dane dotyczące źródła sieciowego.
Nazwy i typy pól powinny pozostawać stabilne. Identyfikator korelacyjny żądania musi być generowany lub weryfikowany przez infrastrukturę; bezkrytyczne zaakceptowanie dowolnego identyfikatora może prowadzić do kolizji lub niejednoznaczności. Nie zapisuj kompletnych nagłówków, treści żądań HTTP ani wszystkich parametrów. Kontekst ma pomagać odtworzyć sekwencję, a nie kopiować wszystkie przetwarzane dane.
Wyklucz sekrety i ogranicz dane osobowe do minimum
Nigdy nie rejestruj haseł, tokenów dostępu, kluczy API, sekretów sesji, kodów odzyskiwania ani wartości umożliwiających uwierzytelnienie. Unikaj też pełnych danych osobowych, jeśli wystarczy wewnętrzny identyfikator. W przypadku pól takich jak adres e-mail, numer telefonu czy adres zamieszkania zdecyduj, czy ich zapis jest niezbędny, czy można je zamaskować albo zastąpić pseudonimizowanym identyfikatorem. Decyzja zależy od celu, ryzyka i obowiązujących wymogów.
Redakcja danych powinna nastąpić przed wysłaniem zdarzenia poza proces; nie polegaj wyłącznie na późniejszym filtrze agregatora. W PHP unikaj bezpośredniej serializacji obiektów żądań, nagłówków i wyjątków, które mogą zawierać wartości wrażliwe. Utwórz jawny obiekt lub tablicę z dozwoloną listą pól; strategia oparta na liście blokowanych pól jest zawodna, gdy pojawiają się nowe pola. Waliduj również wartości kontrolowane przez użytkownika i ograniczaj ich długość, aby zmniejszyć ryzyko wstrzykiwania nowych linii, szumu i nadmiernego zużycia zasobów.
Przetestuj przypadki, w których dane tajne pojawiają się w parametrach lub komunikatach błędów, i sprawdź, czy nie trafiają do docelowego systemu logowania. Sanityzacja powinna zachować informacje wystarczające do badania, na przykład kategorię błędu, bez utrwalania pełnego komunikatu, jeśli może on zawierać dane uwierzytelniające.
Chroń dostęp, integralność i cykl życia
Logi również zawierają informacje wrażliwe. Ogranicz, kto może zapisywać, odczytywać i eksportować logi oraz zarządzać ich retencją; te funkcje mogą wymagać odrębnych uprawnień. Zabezpiecz transmisję i przechowywanie odpowiednimi dla infrastruktury kontrolami, a także unikaj sytuacji, w której przejęte konto aplikacji może bez śladu usunąć lub zmienić całą historię. Gdy uzasadnia to ryzyko, użyj magazynu tylko do dopisywania albo weryfikowalnych mechanizmów kontroli integralności i udokumentuj ich ograniczenia.
Ustal jawny okres przechowywania dla każdej klasy zdarzeń. Bezterminowe przechowywanie zwiększa ryzyko ujawnienia danych i koszty; zbyt wczesne usunięcie może utrudnić badanie. Polityka powinna uwzględniać kopie, eksporty, środowiska testowe i żądania usunięcia dotyczące danych osobowych. Rejestruj i weryfikuj dostęp operatorów do samych logów, zwłaszcza eksporty i zmiany polityki.
Logowanie może zawieść z powodu niedostępności miejsca docelowego, limitów pamięci masowej lub błędów serializacji. Zależnie od krytyczności zdecyduj, co ma się wtedy wydarzyć. Nie pozwól, by awaria systemu logowania umożliwiała ciche wykonanie operacji wysokiego ryzyka, ale nie dopuść też, by wyjątek podczas logowania powodował niespójny wynik lub duplikował transakcję. W przypadku operacji krytycznych może być konieczne zagwarantowanie zapisu zdarzenia razem ze zmianą za pomocą strategii transakcyjnej, takiej jak wzorzec outbox. Jeśli używana jest kolejka, określ zasady ponawiania prób, deduplikacji i obsługi oczekujących zdarzeń.
Sprawdź, czy zdarzenie jest rejestrowane i bezpieczne
Testy powinny weryfikować więcej niż samo wywołanie funkcji logującej. Przetestuj reprezentatywne scenariusze: odmowę dostępu, nadanie uprawnienia, jego odebranie oraz pomyślne i nieudane zakończenie wrażliwej zmiany. Sprawdź, czy zdarzenie zawiera aktora, zasób, wynik, czas i identyfikator korelacyjny; czy wynik odpowiada temu, co rzeczywiście się wydarzyło; oraz czy nie pojawiają się w nim hasła, tokeny ani zbędne dane.
Uwzględnij testy niedostępności miejsca docelowego logów i sprawdź, czy główna operacja pozostaje w spójnym stanie, czy generowany jest alternatywny sygnał oraz czy błąd jest widoczny dla zespołu operacyjnego. W przypadku wrażliwego działania potwierdź, że nie jest ono zgłaszane jako udane, jeśli zmiana nie została zapisana. Przetestuj również limity i spreparowane dane wejściowe, na przykład znaki nowej linii w wartościach kontrolowanych przez użytkownika, a także odczyt z uwzględnieniem ról: użytkownik biznesowy nie powinien domyślnie mieć dostępu do repozytorium zdarzeń.
Lista kontrolna do przeglądu implementacji
- Czy dla każdego zdarzenia określono cel, osobę odpowiedzialną i politykę przechowywania?
- Czy rozróżniono próby, odrzucenia, błędy i zakończone operacje?
- Czy schemat pozwala zidentyfikować aktora, działanie, zasób, wynik i czas?
- Czy zdarzenia są korelowane z żądaniem bez rejestrowania całej jego zawartości?
- Czy przed wysłaniem wyklucza się sekrety i ogranicza ilość danych osobowych?
- Czy kontrolowane są dostęp, transmisja, przechowywanie i usuwanie?
- Czy przetestowano niedostępność miejsca docelowego, integralność operacji i uprawnienia do odczytu?
W pierwszej kolejności uwzględnij zdarzenia chroniące konta, uprawnienia i operacje o największym wpływie. Następnie należy ujednolicić schemat, ograniczyć ilość danych i zautomatyzować testy, które kończą się niepowodzeniem, gdy sekret trafia do logów. Dzięki temu logowanie zdarzeń bezpieczeństwa w PHP dostarcza użytecznych dowodów, nie stając się drugą bazą danych informacji wrażliwych.
