Gdzie ginie nazwa użytkownika VPN z potoku logów?

Sesje pojawiają się na pulpicie, podczas gdy kolumna nazwy użytkownika pozostaje pusta, a pierwszym odruchem jest obwinianie parsera. Ten odruch pomija trzy wcześniejsze etapy, na których wartość mogła zginąć. Brama może zamaskować tożsamość zgodnie z polityką, reguła przyjmowania może ją usunąć przed indeksowaniem, a wyodrębnianie w czasie wyszukiwania może po prostu jej nie nazwać. Naprawa zależy od tego, którą granicę potrafisz udowodnić jako odpowiedzialną, więc pożyteczną pracą jest porównywanie, a nie konfiguracja.

Zacznij od jednego zdarzenia, nie od pulpitu

Wybierz jedno zdarzenie uwierzytelniania i zapisz, co je identyfikuje: model i wersję bramy, metodę uwierzytelniania, identyfikator zdarzenia, znacznik czasu i adres źródłowy. Dodaj nazwę użytkownika dokładnie tak, jak ją wpisała osoba, łącznie z wielkością liter, ponieważ wyszukiwanie rozróżniające wielkość liter może ukryć istniejące pole. Traktuj to zdarzenie jako odniesienie dla każdego późniejszego porównania.

Typy zdarzeń nie dzielą jednego schematu. Nieudana próba, udane logowanie bez klienta i ponowne połączenie tunelu mogą dawać różne pola, a niektóre bramy pomijają tożsamość, gdy próba nigdy nie dotarła do uwierzytelniania użytkownika. Pusta kolumna w jednym typie zdarzenia jest więc słabym dowodem problemu w potoku.

Pracuj z zatwierdzoną tożsamością testową, a nie z prawdziwym kontem pracownika, i trzymaj porównanie w granicach reguł dostępu, które już obowiązują dla danych logów. Szerokie włączenie szczegółowego rejestrowania uwierzytelniania tylko po to, by uzyskać próbkę, zmienia system, który próbujesz zmierzyć.

Porównaj cztery granice po kolei

Wartość może zniknąć w jednym z czterech punktów. Każdy punkt ma innego właściciela i inną naprawę.

Zatrzymaj się na pierwszej granicy, na której wartość znika. Rozbieżność między widokiem urządzenia a surową kopią wskazuje na transport lub konfigurację kolektora; zgodność tam, ale brak wartości w zdarzeniu zindeksowanym wskazuje na transformację; wartość obecna w zdarzeniu zindeksowanym, ale nieobecna na pulpicie wskazuje na wyodrębnianie lub zapytanie.

Ta kolejność ma znaczenie, ponieważ każdy późniejszy etap może tylko tracić informacje, nigdy ich nie odtworzyć. Wyrażenie regularne nie odzyska ciągu, który wcześniejszy etap zastąpił symbolem zastępczym, a ustawienie prywatności nie wyjaśni wartości, która nigdy nie została wysłana.

Maskowanie u źródła to polityka, nie błąd parsera

Dokumentacja rejestrowania ASA firmy Cisco opisuje ukrywanie nazwy użytkownika jako zachowanie konfigurowalne, w tym sposób prezentowania nieprawidłowych lub nieznanych nazw użytkowników. Zamaskowana tożsamość w zdarzeniu źródłowym może więc być dokładnie tym, czego wymaga polityka prywatności, a traktowanie jej jako błędu parsowania prowadzi do wniosku, który osłabia kontrolę.

Dokładna reprezentacja zależy od wersji i typu komunikatu. Jedno zdarzenie może nieść symbol zastępczy, inne może całkowicie pominąć pole, a niepowodzenie uwierzytelniania może nigdy nie zawierać nazwy. Sprawdź udokumentowane zachowanie dla konkretnego zdarzenia, zamiast stosować stary raport o błędzie do każdej brakującej tożsamości.

Gdy maskowanie jest zamierzone, pytanie zmienia się z tego, jak przywrócić pole, na to, czy wymóg audytu można spełnić inaczej. Identyfikatory sesji, kontrolowane mapowanie tożsamości prowadzone przez mniejszą grupę lub węższy autoryzowany strumień zdarzeń często zaspokajają potrzebę bez stawiania każdej wypróbowanej nazwy użytkownika przed każdym czytelnikiem logów.

Anonimizacji przed indeksowaniem nie da się cofnąć

Dokumentacja Splunka dotycząca przetwarzania zdarzeń opisuje anonimizację za pomocą wyrażeń sed i transformacji, które przepisują lub usuwają dane przed indeksowaniem. Właśnie to umiejscowienie jest istotą: surowe zdarzenie jest zmieniane przy wejściu, więc wyodrębnianie w czasie wyszukiwania nie ma już czego znaleźć.

Redakcja w czasie indeksowania i wyodrębnianie pól w czasie wyszukiwania rozwiązują różne problemy. Redakcja ogranicza, kto w ogóle może zobaczyć wartość; wyodrębnianie decyduje tylko, której nazwy używa zapytanie. Haszowanie to opcja pośrednia, która zachowuje korelację, ale stabilny hasz w małej przestrzeni nazw użytkowników nadal identyfikuje, gdy ktoś może testować przeciw niemu nazwy kandydatów.

Jeśli przechowywane zdarzenie nadal zawiera tożsamość, problem jest dalej: typ źródła, dzielenie wierszy, obsługa separatorów, aliasy pól lub samo zapytanie. To zwykłe naprawy parsowania i nie dotykają granicy prywatności.

Wybierz naprawę pasującą do granicy

O odpowiedzi decydują trzy warunki. Po pierwsze, czy polityka prywatności zamierza wykluczyć tożsamość? Po drugie, czy proces audytu lub dochodzenia potrzebuje tożsamości, pseudonimu, czy tylko sesji? Po trzecie, na której granicy wartość jest potrzebna — zbieranie, przechowywanie czy prezentacja?

Jeśli polityka zamierza wykluczyć, zmień wymaganie lub prezentację, nie kontrolę. Jeśli polityka dopuszcza tożsamość, ale zbieranie ją gubi, napraw kolektor i potwierdź surowe zdarzenie. Jeśli przechowywanie jest nienaruszone, napraw wyodrębnianie i przetestuj je na zatwierdzonym zdarzeniu, które przechwyciłeś na początku.

Zamknij dochodzenie, nazywając granicę w zapisie zmiany: zamaskowana u źródła, usunięta podczas przyjmowania albo pominięta przez wyodrębnianie. To jedno zdanie mówi następnemu inżynierowi, gdzie patrzeć najpierw, i nie pozwala, by skarga na pulpit zamieniła się w cicho wyłączoną funkcję prywatności.