Wybór dowodów HTTP: dzienniki bramy czy dzienniki aplikacji

Monitorowanie sieci zaczyna się od celu, a nie od punktu przechwytywania. Liczenie aktywnych klientów, pomiar czasu wywołania API i czytanie treści komunikatów wymagają różnych dowodów i różnych decyzji dotyczących prywatności. Brama, która przekazuje chroniony HTTPS, widzi połączenia, a nie zawartość strony. Wybór niewłaściwej warstwy daje dane, które wyglądają bogato i nie odpowiadają na nic.

Nazwij pytanie przed źródłem danych

Zacznij od decyzji operacyjnej, którą dane mają wspierać. Pytania o dostępność wymagają zliczeń i czasów, pytania o żądania — ścieżek i kodów stanu, a pytania o treść — treści komunikatów. Każdy krok do wewnątrz dodaje wrażliwość i złożoność inżynierską. Poproś właściciela usługi i właściciela bezpieczeństwa o zatwierdzenie odbiorców, celu i przetwarzania przed rozpoczęciem zbierania, ponieważ obsługa tunelu nie jest tą decyzją.

Zapisz pytanie w jednym zdaniu i trzymaj je obok planu zbierania. To jedyna wiarygodna kontrola zakresu.

Co brama może pokazać, a czego nie

Brama przekazująca poprawnie chroniony HTTPS zwykle widzi adresy, porty i woluminy, a nie wiersze żądań czy treści.

conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'

Lista conntrack pokazuje przepływy i tłumaczenia, a krótkie przechwycenie pokazuje pakiety bez czytelnej treści aplikacji. To wystarcza, by odpowiedzieć, czy ruch płynie, ile i między którymi punktami końcowymi. To nie jest lista URL, a zwykły proxy CONNECT przekazuje zaszyfrowaną wymianę bez kończenia TLS aplikacji. Gdy ktoś obiecuje ścieżki żądań z tej pozycji, zapytaj, który komponent odszyfrowuje i pod czyim zaufaniem.

Dzienniki aplikacji odpowiadają na większość pytań o żądania

Dla aplikacji, którą obsługujesz, jej własne obsługiwane rejestrowanie zwykle odpowiada na pytanie na poziomie żądania bez odszyfrowywania cudzych połączeń.

curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.log

Żądanie stanu mierzy dostępność z pozycji klienta, a dziennik dostępu zapisuje pola, które serwer już wybrał do zachowania. Wybierz pola potrzebne do zadania, a resztę pomiń, bo nawet URL może nieść wrażliwe parametry. Wiersz dziennika jest dowodem o tej usłudze, a nie o każdej innej usłudze, do której użytkownik dotarł przez tunel. Wąskie zbieranie utrzymuje też małe pytanie o retencję, więc ustaw okno krótsze niż eksperyment myślowy, który wytworzył wymaganie.

Przechwytywanie to odrębny projekt zaufania

Jeśli inspekcja na poziomie komunikatu jest naprawdę konieczna, przechwytywanie TLS tworzy nowy zaufany punkt końcowy i porozumienie zaufania klienta, które trzeba rozpowszechnić i utrzymywać. Aplikacje przypinające certyfikaty ulegną awarii, a operator trzyma teraz klucze prywatne, których ochrona liczy się tak samo jak każdego klucza serwera. Uruchomienie zbierania przez osłabienie walidacji certyfikatów lub przez łatanie aplikacji, która przypina swoje certyfikaty, wymienia kontrolę bezpieczeństwa na wiersz dziennika. Preferuj udokumentowany projekt inspekcji, którego dystrybucją zaufania już się zarządza, i trzymaj klucz prywatny organu poza wszystkim, co jest współdzielone.

Pod koniec okna zbierania usuń konfigurację i jej materiał zaufania przez ich właścicieli, i zutylizuj zachowane dowody zgodnie z uzgodnioną polityką. Wystarczająca wiarygodna informacja dla podanego celu jest kryterium sukcesu, a nie największe możliwe przechwycenie.