Zacznij od pracy użytkownika
Przydatne dzienniki wyjaśniają wydarzenie z najmniejszą praktyczną ilością informacji. Zacznij od pytania, na które operator musi odpowiedzieć: która operacja nie powiodła się, na jakim etapie, w jakiej wersji i z jakim skutkiem jest zależność? Logowanie całego organu żądającego jest łatwym skrótem, który często zmienia oprzyrządowanie operacyjne w niekontrolowaną kopię danych klienta.
Zachować zakres celowy
Preferuj ustrukturyzowane nazwy zdarzeń, znaczniki czasu, identyfikatory żądań i niewrażliwe kody wyników. Zachować szczegółową zawartość klienta w autoryzowanym systemie biznesowym zamiast kopiować go do dzienników. Wytyczne OWASP dotyczące logowania nie obejmują danych wrażliwych i ochrony dostępu do dziennika. Zdecyduj zasady retencji, dostępu i redakcji, zanim incydent produkcyjny kusi kolekcję awaryjną.
Scenariusz do próby
Wyobraź sobie integrację odrzucającą aktualizację klienta. Przydatne zdarzenie rejestruje nazwę integracji, identyfikator operacji, numer próby i kategorię błędów mapowanych. Operator może zlokalizować autoryzowany rekord biznesowy oddzielnie. Sprawdź, czy błąd dostawcy zawierający adres e-mail lub token jest również oczyszczony; czyszczenie własnych pól nie czyści wiadomości o błędzie osoby trzeciej. Weryfikacja rzeczywistego zapisanego dziennika, nie tylko wejścia funkcji logowania.
Unikaj poruszania problemem
Nie umieszczaj tajemnic w URL, które proxy lub analityki mogą zapisywać. Unikaj traktowania szyfrowanego identyfikatora jako automatycznie anonimowego i nie pozwól, aby tryb debugowania po cichu zwiększył kolekcję produkcji. Oddzielenie ścieżki audytu bezpieczeństwa od ogólnej diagnostyki, w której ich dostęp i zachowanie są zróżnicowane. Błąd logowania w sposób, który nie ujawnia wartości wrażliwych w samym błędzie awaryjnym.
Projektowanie zdarzenia logowania przed incydentem go potrzebuje
Weź nieudaną aktualizację integracji i napisz mały kontrakt eventowy. Dołącz nazwę zdarzenia, czas, identyfikator operacji, wersję aplikacji, numer próby i kategorię wyników ograniczoną. Zdecyduj, które pola są niezbędne do korelacji i które są tylko wygodne. Preferuj wyraźnie dozwolone pola nad serializacją arbitralnego obiektu, ponieważ nowe pola mogą później pojawić się w tym obiekcie bez zmiany polityki logowania. Zachowaj to zdarzenie przydatne nawet wtedy, gdy wiadomość zwrócona do klienta jest celowo bardziej ogólna.
Namierz pełną trasę, którą dane prowadzą do sklepu z dziennikami. Rejestrator aplikacji jest tylko jednym ze źródeł: reverse proxy, warstwa obsługi żądań, narzędzia śledzenia błędów, procesy zadań i biblioteki zależności także mogą tworzyć dane diagnostyczne. Sprawdź łańcuchy zapytań, nagłówki, błędy rzucone i zagnieżdżone odpowiedzi dostawcy w reprezentatywnych niepowodzeń. Użyj wymyślonych wartości znaczników przypominających e-mail, token dostępu i korpus wiadomości, a następnie sprawdź każdy wynik zlewu dla tych markerów. Badanie jednostki redakcji jest cenne, ale nie dowodzi, że inny składnik nigdy wcześniej nie zarejestrował wartości pierwotnej.
Planować dostęp i usuwanie jako zadania operacyjne. Identyfikacja osób, które mogą przeszukiwać, eksportować i zmieniać sposób zatrzymywania, i sprawić, że tymczasowa kolekcja diagnostyczna wygaśnie, a nie pozostanie włączona po zdarzeniu. Jeśli inżynier musi sprawdzić pierwotny rejestr biznesowy, użyj ścieżki autoryzacji systemu zamiast poszerzać dostęp do dziennika dla wszystkich. Rozważyć zatrzymany eksport i skopiowane notatki incydentów przy podejmowaniu decyzji, co usunięcie rzeczywiście obejmuje. Sprawdzić, czy pozostałe zdarzenie nadal wspiera diagnozę po usunięciu wrażliwych pól. Zbyt wiele redakcji może spowodować nieprzydatny ogólny błąd; odpowiedzią jest dodanie bezpiecznego kontekstu strukturalnego, a nie przywrócenie całego osobistego obciążenia. Zachować mały zestaw oczyszczonych przykładów incydentów, aby wykonać tę równowagę podczas zmiany aplikacji.
Matryca przeglądu logowania
| Badanie | Dowody do kontroli |
|---|---|
| Błąd dostawcy zawiera symbol dostępu | Przechowywane stosowanie i późniejsze wyjście diagnostyczne pomija token przy jednoczesnym zachowaniu użytecznej kategorii błędów. |
| Żądanie URL zawiera wrażliwe wejście | Wartość nie wycieka przez logowanie proxy lub middleware nawet jeśli pola aplikacji są oczyszczone. |
| Tymczasowy tryb debugowania wygasa | Kolekcja powraca do normalnego zakresu i zasad dostępu bez zależności od kogoś pamiętającego ręczne czyszczenie. |
| Autoryzowana diagnoza wymaga więcej kontekstu | Operator może skorelować bezpieczne wydarzenie z systemem biznesowym w ramach istniejących uprawnień, a nie otrzymywać masowe treści klientów. |
Jak ocenić wynik
Które pytanie diagnostyczne potrzebuje każdego pola? Kto może czytać lub eksportować dzienniki? Kiedy są usuwane, łącznie z kopiami? Doprowadzić reprezentatywne błędy sanitarne do przeglądu equitare- ratownictwa i udowodnić, że operator może zbadać prawdziwy wzorzec awarii bez otrzymania pełnej wiadomości klienta.
Źródła i dalsza lektura
Ratowanie i rozwój oprogramowania
Przemyślany kolejny etap dla istniejącego oprogramowania.
Porozmawiaj o tej usłudze