Czy niezmienny dziennik audytowy może pozostać prywatny na serwerze domowym?

Tak, dziennik audytowy może pozostać prywatny na serwerze domowym, a jednocześnie być odporny na manipulacje, jednak jeden administrator nie jest w stanie samodzielnie zapewnić jego absolutnej niezmienności.

Gospodarstwo domowe może potrzebować trwałego rejestru działań agenta AI, zdarzeń związanych z drzwiami, zmian konfiguracji lub usunięć kopii zapasowych bez publikowania tych informacji. Lokalne przechowywanie zapewnia poufność, natomiast łańcuchy skrótów, podpisane punkty kontrolne i uprawnienia umożliwiające wyłącznie dopisywanie sprawiają, że późniejsze przepisywanie historii staje się wykrywalne. Pozostaje jednak pytanie o zaufanie: kto chroni klucz podpisujący i poprzedni punkt kontrolny, jeśli ten sam właściciel serwera może kontrolować aplikację, system plików, bazę danych i kopie zapasowe.

Prywatność i niezmienność to odrębne właściwości

Prywatność określa, kto może odczytać zdarzenie. Niezmienność określa, czy historię można zmienić bez wykrycia lub autoryzacji. Szyfrowanie może ukryć zawartość dziennika, ale nie powstrzymuje administratora przed usunięciem zaszyfrowanego pliku. Uprawnienia tylko do odczytu mogą zablokować konto aplikacji, ale nadal mogą zostać ominięte przez użytkownika root. Dlatego przydatny projekt łączy poufność, ograniczony dostęp do dopisywania i ciągłość kryptograficzną.

Niezmienna baza danych, taka jak immudb weryfikuje historię, zachowuje wcześniejsze wersje rekordów i umożliwia klientom sprawdzanie dowodów kryptograficznych. Zdarzenia mogą pozostać w prywatnej sieci; weryfikacja sama w sobie nie wymaga publicznego udostępniania tekstu jawnego. Istotne jest to, aby późniejszy stan zawierał zobowiązanie do wcześniejszych stanów, a weryfikator zachował wystarczająco dużo zaufanych informacji, by wykryć przepisaną historię.

Oznacza to, że określenie „prywatny niezmienny dziennik” należy zwykle rozumieć jako prywatny, przeznaczony wyłącznie do dopisywania i niezależnie weryfikowalny. Jest on bezpieczniejszy niż zwykła tabela audytowa w bazie danych, ale słabszy niż fizyczny nośnik, którego nigdy nie można zmienić. To rozróżnienie ma znaczenie w przypadku serwera domowego, ponieważ funkcje ułatwiające obsługę, takie jak odzyskiwanie przez administratora, migawki i pełne przywracanie dysku, mogą również przywrócić starszy stan dziennika, chyba że wycofanie zmian jest wykrywalne.

Dowody Merkle’a wykrywają przepisywanie bez ujawniania każdego zdarzenia

Łańcuch skrótów sprawia, że każdy wpis zależy od poprzedniego; drzewo Merkle’a łączy wiele skrótów wpisów w jeden zwięzły korzeń. Zmiana starego zdarzenia zmienia wynikowe zobowiązanie. Weryfikator może użyć dowodu przynależności, aby potwierdzić, że dane zdarzenie należy do zatwierdzonego drzewa, oraz dowodu spójności, aby potwierdzić, że nowsze drzewo rozszerza starsze.

RFC 9162 opisuje przejrzyste dzienniki przeznaczone wyłącznie do dopisywania, zbudowane na drzewach Merkle’a i dowodach spójności. Chociaż transparency logs certyfikatów są publiczne, ten mechanizm kryptograficzny można zastosować do prywatnych zdarzeń. System domowy może eksportować wyłącznie podpisane korzenie drzew lub zaszyfrowane pakiety dowodów, zachowując treść zdarzeń i metadane umożliwiające identyfikację wewnątrz zaufanej sieci.

Samo haszowanie nie ukrywa przewidywalnych danych. Jeśli zdarzenie ma tylko kilka możliwych wartości, obserwator może odgadnąć wartość i porównać jej skrót. W przypadku poufnych danych używaj szyfrowania uwierzytelnionego, przechowuj w postaci jawnej minimalną ilość metadanych i stosuj wartości jednorazowe tam, gdzie jest to właściwe. Częstsze publiczne punkty kontrolne poprawiają wykrywanie wycofania zmian, ale publikowanie surowych skrótów zdarzeń bez analizy prywatności może ujawniać informacje o czasie lub przynależności.

Granica zaufania pojedynczego serwera prędzej czy później zostaje przekroczona

Jeśli atakujący uzyska bazę danych dziennika, klucz podpisujący, dane uwierzytelniające aplikacji i wszystkie przechowywane punkty kontrolne, może przepisać historię i utworzyć spójną zastępczą wersję. Lokalne oprogramowanie przeznaczone wyłącznie do dopisywania podnosi koszt ataku, ale nie potrafi odróżnić nowej, sfałszowanej osi czasu, gdy wszystkie kotwice zaufania zostaną zastąpione jednocześnie. To podstawowe ograniczenie przechowywania wszystkich dowodów na jednej maszynie.

Dziennik przejrzystości Rekor projektu Sigstore wykorzystuje rekordy przeznaczone wyłącznie do dopisywania, podpisane materiały i zewnętrzną weryfikację, dzięki czemu różne podmioty mogą monitorować spójność. Prywatny projekt domowy może zapożyczyć tę niezależność bez publikowania zawartości: kopiować podpisane korzenie na drugie urządzenie, drukować lub eksportować okresowe punkty kontrolne albo wysyłać same zobowiązania do konta, które nie może modyfikować serwera.

Twierdzenie o niezmienności przestaje być prawdziwe w przypadku całkowitego przejęcia systemu, jeśli żaden zaufany punkt kontrolny nie przetrwa poza nim. Przestaje być prawdziwe także wtedy, gdy dzienniki można wyłączyć przed wykonaniem działania, zegary można zmienić bez pozostawienia śladów lub aplikacja rejestruje jedynie ogólny komunikat o powodzeniu. Chroń ścieżkę przyjmowania danych i rejestruj tożsamość żądania, wykonawcę, cel, wynik oraz monotoniczny numer sekwencyjny — nie tylko końcową narrację wygenerowaną przez agenta AI.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Zweryfikuj dziennik za pomocą testu wycofania zmian

Utwórz zdarzenia testowe, zachowaj podpisany punkt kontrolny na innym urządzeniu, a następnie przeprowadź trzy ataki na kopii przeznaczonej do testów: zmień stare zdarzenie, usuń zdarzenie i przywróć wcześniejszą migawkę. Po każdej próbie uruchom weryfikację na podstawie zewnętrznego punktu kontrolnego. Prawidłowy projekt powinien wykryć każdą zmianę historii, nawet jeśli przywrócona baza danych wygląda wewnętrznie spójnie.

Trwałe dane aplikacji wymagają odrębnych ról dla bieżącego stanu, historii i kopii zapasowych. Wyjaśnienie ról trwałych danych w ZimaSpace stanowi przydatną analogię dotyczącą przechowywania: stan operacyjny i dowody historyczne nie są wymienne. Przechowuj dziennik audytowy, punkty kontrolne weryfikacji, klucze szyfrujące i zwykły katalog kopii zapasowych w odrębnie chronionych lokalizacjach.

Test można uznać za zaliczony dopiero wtedy, gdy niezależny weryfikator wykrywa edycję, usunięcie i wycofanie zmian, a nieuprawniony czytelnik nadal nie może odzyskać treści zdarzeń. Jeśli weryfikacja działa tylko na tym samym serwerze, przenieś przynajmniej podpisane korzenie w inne miejsce. Jeśli prywatność jest zagrożona, ogranicz publikowane metadane lub szyfruj pakiety dowodów. Praktycznym celem jest wykrywalność manipulacji w ramach określonego modelu zagrożeń, a nie bezwarunkowa obietnica, że żaden bit nigdy się nie zmieni.

Najczęściej zadawane pytania

Czy wymagany jest dysk WORM?

Nie. Sprzętowa ochrona lub blokada przechowywania obiektów może zwiększyć odporność na usuwanie, ale dowody kryptograficzne i niezależne punkty kontrolne mogą sprawić, że historia zarządzana programowo będzie wykazywać ślady manipulacji. Każde z tych rozwiązań chroni przed innym zagrożeniem.

Czy mogę usunąć dane osobowe z niezmiennego dziennika?

Zaplanuj minimalizację danych i okres przechowywania, zanim je zapiszesz. Jedno z rozwiązań polega na szyfrowaniu poufnych danych i późniejszym zniszczeniu klucza przypisanego do rekordu przy zachowaniu niepoufnego zobowiązania, ale wymogi prawne zależą od jurysdykcji i przypadku użycia.

Czy prywatny dziennik potrzebuje technologii blockchain?

Nie. Podpisany łańcuch skrótów lub drzewo Merkle’a z niezależnymi punktami kontrolnymi może zapewnić weryfikowalną historię przeznaczoną wyłącznie do dopisywania, bez konsensusu, publicznych tokenów i publikowania zdarzeń domowych.