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.

Powiązane wpisy

Jak to wygląda wewnątrz Atlasa?

Przejdź do strony produktu