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ł.
AtlasPVE ·
Ten wpis odpowiada na
- proxmox kto co zrobił
- proxmox dziennik audytu
- proxmox historia działań
- proxmox kto to usunął
- proxmox śledzenie zmian
Monitorowanie i zapis audytu to dwie różne rzeczy, a bywają mylone. Monitorowanie odpowiada na pytanie, co się stało: dysk się zapełnił, usługa padła, obciążenie wzrosło. Zapis audytu odpowiada na pytanie, kto to zrobił. Wartość tego drugiego ujawnia się w dni, których nie chcesz przeżyć.
Trzy momenty
Coś się zmieniło i nikt nie pamięta, żeby to zmieniał. Odpowiedź brzmi zwykle: ty, trzy tygodnie temu, i jest to raczej ulga niż oskarżenie: nieznana zmiana niepokoi znacznie bardziej niż znana.
Dwie osoby pracują na tej samej maszynie i każda zakłada, że zrobiła to druga. W takiej sytuacji jedyną rzeczą kończącą dyskusję jest zapis.
Coś naprawdę poszło źle i potrzebujesz kolejności zdarzeń. Stan końcowy mówi, co się stało; kolejność mówi, jak. Bez tej drugiej to samo się powtarza.
Zdanie, że zrobił to root, nie jest odpowiedzią
Jeśli wszyscy logują się tym samym kontem, nazwa w zapisie jest dla wszystkich ta sama. Zapis dalej odpowiada, co się stało, ale przestaje odpowiadać, kto to zrobił. Dlatego zapis audytu jest nieistotny w konfiguracji jednoosobowej i staje się krytyczny w dniu, w którym pojawia się druga osoba.
Czego w zapisie być nie może
Treści żądania. Przechodzą przez nią hasła, klucze i tokeny. Zapis chwytający wszystko oznacza nowe miejsce, w którym mieszkają twoje sekrety, a to miejsce jest zwykle słabiej chronione, bo uchodzi za zwykły dziennik.
Zapis audytu potrzebuje pięciu rzeczy: kto, co, kiedy, wobec czego i z jakim wynikiem. Gdy chcesz dodać szóstą, najpierw zapytaj, czy niesie sekret.
Miejsce, w którym siedzi, decyduje, czy jest dowodem
Zapis, który tylko aplikacja może pisać i przepisywać, jest pamiętnikiem, a nie dowodem. Jeśli sama aplikacja zostanie przejęta, poprawi też zapis.
Dlatego zapis musi też lądować tam, gdzie aplikacja nie sięga. Własny dziennik systemu istnieje właśnie po to: aplikacja tam pisze, ale nie może stamtąd kasować.
Okres przechowywania
Zapis audytu trzymany trzy dni odpowiada na pytanie, kto co zrobił wczoraj, i nic więcej. A większość tych pytań przychodzi po tygodniach, bo skutek zmiany zwykle nie jest widoczny od razu. Trzymaj zapis audytu według innego rozumowania niż kopie zapasowe: zajmuje mało miejsca i długo pozostaje cenny.
Co robi Atlas
Atlas zapisuje w audycie tylko pięć rzeczy: kto, co, kiedy, wobec czego i z jakim wynikiem. Treść żądania nigdy nie jest zapisywana, bo żądanie logowania niesie hasło, a nie ma żadnej korzyści z tego, żeby to hasło istniało po raz drugi w pliku dziennika.
Zapis ląduje w dwóch miejscach naraz. Jednym jest własny dziennik systemu: Atlas tam pisze, ale nie może stamtąd brać ani tego zmieniać. Drugim jest plik w folderze danych produktu, który nie jest kasowany przez aktualizacje. Nie musisz więc schodzić do dziennika systemowego, żeby przeczytać zapis, ale jest tam, gdy go potrzebujesz.
Drobny, ale znaczący szczegół: znacznik czasu jest zapisywany na samym końcu rekordu. Dzięki temu nawet jeśli strona tworząca rekord poda własny znacznik czasu, nie może go nadpisać. Dziś nikt tego nie próbuje, ale w zapisie audytu prawidłowa kolejność leży w naturze rzeczy.
I odrzucone żądania też są zapisywane, nie tylko te wykonane. Informacja, że ktoś próbował i nie wyszło, także siedzi więc w zapisie; częściej niż rzadziej to właśnie tego zdania szukałeś.
Źródła
Własna dokumentacja Proxmoksa. Po angielsku i to ona ma ostatnie słowo w tej sprawie.