Kto co zmienił: ślad audytu dla hosta
Na współdzielonym hoście najtrudniejszym pytaniem po incydencie nie jest to, co się zepsuło; jest nim to, kto co zmienił, zanim się zepsuło. Atlas zapisuje ślad audytu krytycznych operacji: sprawcę, działanie, czas i wynik, trzymane na hoście w dwóch miejscach.
Dlaczego pytanie kto co zrobił zwykle zostaje bez odpowiedzi
Zwykłe narzędzia rozpraszają dowody. Dziennik zadań PVE zna część operacji, historia powłoki zna inne, a edycje konfiguracji często nie znają żadnych. Odtworzenie jednego wieczoru oznacza zszywanie znaczników czasu z trzech źródeł.
Współdzielony dostęp roota to pogarsza. Gdy kilka osób może działać jako root, działania przestają mieć autorów; pliki historii może edytować ta sama moc, która wykonała zmianę.
A większość audytów odbywa się w najgorszym momencie: po incydencie, pod presją, przy czym osoba znająca odpowiedź może być osobą, która go spowodowała.
Ręczne odtwarzanie incydentu
Bez śladu zwykłe dochodzenie wygląda tak:
Lektura dziennika zadań PVE wokół okna incydentu i notatka z tego, co widać.
Przeszukaj historie powłoki na hoście, licząc, że nikt nie użył konta współdzielonego.
Przegląd journalctl dla tego samego okna i próba dopasowania znaczników czasu.
Porównanie bieżących konfiguracji z ostatnią kopią, żeby znaleźć ciche edycje.
Zapytaj na czacie zespołu, kto tego dnia dotykał hosta.
Notatka o incydencie oparta na przypuszczeniach i przejście dalej.
Co Atlas zapisuje
Krytyczne operacje zostawiają ślad w chwili, gdy się dzieją, a nie zagadkę na później.
Zapisane działania krytyczne
Operacje, które zmieniają albo zagrażają systemowi, niszczące prace na pamięci masowej i sieci, zabijanie procesów, działania wrażliwe na uprawnienia, trafiają do śladu w chwili wykonania.
Sprawca, działanie, czas, wynik
Każdy wpis odpowiada naraz na cztery pytania incydentu: kto to uruchomił, co dokładnie się wykonało, kiedy i czy się powiodło.
Dwie kopie, odporne na manipulacje
Wpisy trafiają do dziennika systemowego, którego użytkownicy bez roota nie mogą przepisać, oraz do osobnego pliku. Zatarcie śladów oznacza pokonanie obu.
Role Proxmoksa uszanowane
Atlas nie wymyśla własnego świata uprawnień. Kto co może, wynika z użytkowników i ról Proxmoksa, więc ślad odwzorowuje prawdziwe tożsamości.
Żadnych danych poufnych w dzienniku
Hasła i tokeny nigdy nie są zapisywane. Ślad odnotowuje, że działanie miało miejsce, a nie poświadczenia, które je niosły.
Znaleziska docierają same
Wartownik Watch zgłasza krytyczne znaleziska pocztą w chwili, gdy się pojawiają, więc ślad czyta się przed incydentem, a nie dopiero po.
Częste pytania
- Co dokładnie jest zapisywane?
- Operacje krytyczne i wrażliwe na uprawnienia: niszczące zmiany pamięci masowej i sieci, sygnały do procesów, działania na poziomie usług i podobne. Zwykłe odczyty nie są szumem w śladzie.
- Czy administrator może zatrzeć swoje ślady?
- Ślad jest trzymany dwukrotnie: w dzienniku systemowym, którego nie da się przepisać bez manipulacji na poziomie roota, oraz w osobnym pliku. Ciche poprawianie historii przestaje być trywialne.
- Czy przechowywane są hasła albo treści żądań?
- Nie. Dane poufne nigdy nie trafiają do śladu; wpisy niosą sprawcę, działanie, czas i wynik.
- Gdzie mieszka dziennik?
- Na hoście, w dzienniku systemowym oraz w osobnym pliku. Nic nie jest wysyłane do usługi zewnętrznej.
- Czy używa kont Proxmoksa?
- Tak. Atlas odzwierciedla użytkowników, grupy i role Proxmoksa zamiast wymyślać własne, więc wpisy audytu odwzorowują te same tożsamości, którymi zarządza już Proxmox.
- Czy zapisywanie spowalnia host?
- Nie. Zapisywane są tylko operacje krytyczne, a nie każde kliknięcie; ślad to kilka linii na ryzykowne działanie.
Powiązane wpisy
- Odebrałem uprawnienia, a ta osoba nadal jest w środku: sesja to nie to samo co uprawnienie Odebrałeś uprawnienie, wyłączyłeś nawet konto, a ta osoba nadal potrafi coś zrobić. Nic nie jest zepsute: odbieranie dostępu i kończenie sesji to dwie osobne czynności.
- Zejście z roota: decyzja, do której nikt cię nie zmusza, i ta, która najbardziej się opłaca Praca jako root nie wybucha pewnego dnia. Po cichu psuje dwie rzeczy: to, na kogo wskazuje zapis, i to, gdzie zatrzymuje się błędne kliknięcie. Lekarstwem nie jest wyłączenie roota, tylko zdjęcie z niego codziennej pracy.
- Zapis audytu: odpowiedź na pytanie kto to zrobił, a nie co się stało Monitorowanie mówi, co się stało, zapis audytu mówi, kto to zrobił. Jego wartość ujawnia się w dni, których nie chcesz przeżyć, a jeśli tego dnia go nie masz, to nigdy nie istniał.