Alerty logowania VPN: które zdarzenie powinno je właściwie wyzwalać?
Udana autoryzacja, ustanowiony tunel i RADIUS accounting Start to trzy różne twierdzenia. Wybierz to, na które Twój odbiorca może zareagować, a następnie je skoreluj.
Udana autoryzacja, ustanowiony tunel i RADIUS accounting Start to trzy różne twierdzenia, a e-mail o logowaniu znaczy coś dopiero wtedy, gdy wybierzesz jedno z nich. Większość projektów alertów VPN miesza wszystkie trzy i tworzy skrzynkę, której nikt nie ufa. Decyzja zależy od tego, kto czyta alert i co może zrobić w ciągu najbliższych pięciu minut. Jeśli to zawiedziesz, alert staje się szumem, który ukrywa jedno zdarzenie, którego potrzebowałeś.
Trzy pytania decydują o wyzwalaczu
Zapytaj, kto go otrzyma, co zrobi i jak szybko musi nastąpić działanie. Zespół bezpieczeństwa pilnujący nadużyć poświadczeń chce wzorca porażki, a potem sukcesu z jednego konta w ciągu kilku minut. Zespół operacyjny pilnujący pojemności chce czasu trwania sesji i powodów rozłączenia, a nie logowań. Helpdesk chce tożsamości sesji, aby dopasować ją do zgłoszenia.
Te odpowiedzi wskazują na różne zdarzenia i żadna pojedyncza reguła nie zaspokaja wszystkich trzech. Jeśli działaniem odbiorcy jest „zadzwoń do użytkownika”, autoryzacja wystarczy. Jeśli działaniem jest „zwolnij licencję” albo „sprawdź, czy tunel przenosił ruch”, zadziała tylko ustanowienie albo accounting Start. Jeśli działaniem jest „zafakturuj czas”, potrzebujesz rekordów Stop, a nie logowania.
Zapisz odpowiedź w jednym zdaniu, zanim cokolwiek skonfigurujesz. „Ten e-mail mówi inżynierowi dyżurnemu, że konto X otworzyło tunel z sieci Y o czasie Z, aby mógł sprawdzić, czy wykorzystano okno serwisowe.” Jeśli nie możesz wypełnić każdego pola, wyzwalacz nie jest jeszcze wybrany.
Dopasuj zdarzenie do twierdzenia, które formułujesz
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
Tabela ukrywa zależność: każdy wiersz jest wiarygodny tylko wtedy, gdy brama wysyła go niezawodnie, a Twój kolektor zachowuje potrzebne pole. Przeczytaj definicję zdarzenia dla dokładnie tej wersji, którą eksploatujesz, ponieważ nazwa „sesja ustanowiona” zmienia się między wersjami, a znaczenie zmienia się częściej niż nazwa. Gdy definicja jest niejasna, poproś o zapis sesji zamiast zgadywać z etykiety.
Traktowanie Access-Accept jako zakończenia wszystkiego, co następuje, to najczęstszy błąd. To wyrok o poświadczeniach, nie sesja. Błędem lustrzanym jest czytanie dopasowania polityki jako dowodu autoryzacji, choć reguła może pasować, a następny krok nadal może się nie udać.
Jedna sesja, jedno powiadomienie
Jedno konto, wiele urządzeń, ponowne transmisje i ponowne połączenia: jeden e-mail na zdarzenie będzie błędny w obu kierunkach, duplikując jedną sesję i rozdzielając inną. Oprzyj klucz powiadomienia na bramie i identyfikatorze sesji, a nazwę konta traktuj jako atrybut, nie jako klucz. Użytkownik z laptopem i telefonem może mieć dwa tunele naraz i oba zasługują na własny wiersz.
Ponownie wysyłane rekordy księgowe są normalne, więc usuń duplikaty według identyfikatora sesji i znacznika czasu, zanim wyrenderujesz wiadomość. Kolejne sesje z tego samego urządzenia powinny pozostać osobne, a ponowne połączenie w oknie serwisowym powinno pozostać widoczne zamiast zlewać się z poprzednią. Jeśli Twój kolektor przepisuje znaczniki czasu przy przyjmowaniu danych, usuwaj duplikaty według pól oryginalnego rekordu, a nie zapisanych.
Brakujący rekord Stop to niepewność, nie trwała sesja. Restarty bramy, awarie kolektora i utrata UDP zostawiają luki, więc alert potrzebuje ścieżki uzgadniania, która odpyta tabelę aktywnych sesji, zanim ktoś stwierdzi, że tunel nadal działa.
Trzymaj audyt i powiadomienia osobno
Strumień audytu i strumień alertów mają różne zadania. Zachowaj surowe rekordy, w tym konto, bramę, identyfikator sesji, znaczniki czasu i powód zakończenia, nawet gdy rutynowe e-maile są grupowane, wyciszane lub wysyłane do małej listy dyżurnej. Próg istotności to filtr dostarczania, a nie wybór zdarzenia cyklu życia, które chciałeś ogłosić.
Wysyłaj minimalny kontekst potrzebny odbiorcy do znalezienia chronionego rekordu. Nazwy kont, adresy wewnętrzne i szczegóły sesji są wrażliwe, a e-mail, który dobrze się przekazuje dalej, to e-mail, który dobrze wycieka.
Następnie udowodnij to od początku do końca. Przeprowadź zwykłe logowanie i wylogowanie, ponowne połączenie, dwie jednoczesne sesje i wymuszoną awarię dostarczania, a następnie prześledź jedno zdarzenie od bramy przez kolektor do dostarczonej wiadomości. Jeśli e-mail przychodzi bez identyfikatora sesji, umowa jest niepełna. Jeśli dwa e-maile opisują jedną sesję, korelacja jest zepsuta. Żaden z tych problemów nie pojawia się, gdy jedyne, co testujesz, to działanie dostarczania poczty.