Audyt i dzienniki niezmienne

Audyt i dzienniki niezmienne

1) Dlaczego go potrzebujesz

Celem audytu jest przechwycenie „kto, co, gdzie, kiedy i dlaczego” z wiarygodną integralnością w celu utrzymania bezpieczeństwa, dochodzeń, sprawozdawczości finansowej i zgodności.
Dziennik niezmienny - format i przechowywanie, w którym zdarzenia są rejestrowane wyłącznie za pomocą dodatku, a późniejsza zmiana/usunięcie jest niemożliwa lub wykrywalna za pomocą środków kryptograficznych i zasad przechowywania.

2) Model zagrożenia i cele kontroli

• Zamierzona edycja/usuwanie zdarzeń przez insider.
• Wymiana czasu/źródła (powtórka/backdating).
• „Ciche” zamknięcie rejestru na węźle.
• Utrata części dziennika podczas wypadków/migracji.
• Nadmierna kolekcja PII i niezgodność z prywatnością.

1. Integralność: potwierdzona ochroną przed modyfikacjami/usunięciem.

2. Kompletność: zamknięcie przepływów kluczowych (płaszczyzna sterowania, płaszczyzna danych, dostęp, pieniądze).

3. Dokładność czasu: powtarzalny, zsynchronizowany czas.

4. Dostępność: czytanie i wyszukiwanie w ramach SLO.

5. Prywatność: minimum PII, tokenizacja/szyfrowanie, legalność użytkowania.

3) Priorytety w zakresie taksonomii i imprez

• Płaszczyzna sterowania: uwierzytelnianie/autoryzacja, zmiany konfiguracji, operacje klucza (KMS), tajne zarządzanie, zmiany zasad.
• Płaszczyzna danych: dostęp do obiektów/rekordów/kontroli/płatności; czytać/tworzyć/usuwać.
• Admin i DevOp: SSH/konsola, CI/CD, zmiany infrastruktury/IaC, eskalacja praw.
• Produkt: transakcje, rozliczenia, obsługa klienta.
• System/sieć: kernel/agents/proxies/balancers, brokers, databases.
• Bezpieczeństwo: IDS/IPS/EDR, WAF, anty-DDoS, antifraud, DLP.

Dla każdej klasy ustalamy: krytyczność, schemat, obowiązkowe pola, okres przydatności do spożycia, wymagania dotyczące niezmienności.

4) Wymagane pola i format

Identyfikatory korelacji to 'trace _ id',' span _ id', 'request _ id',' actor _ id' (użytkownik/usługa), 'lokator _ id',' resource _ id'.
Kontekst A&A: metoda uwierzytelniania, role/zasady w czasie działania.
Czas: RFC3339/UTC, milisekundy/nanosekundy; źródło synchronizacji.
Działanie i wynik: rodzaj operacji, cel, stan, liczba obiektów dotkniętych.
Integralność: lokalne rekordy HMAC, numer sekwencji, skrót.
Schemat: JSON ze stabilnym modelem (na przykład kompatybilny ze wspólnymi słownikami zdarzeń).

Zabronione: sekrety, klucze, żetony, pełny PAN, hasła, klucze prywatne. PII - tylko w razie potrzeby, z maskowaniem/tokenizacją.

5) Czas i synchronizacja

Źródło czasu: co najmniej dwa niezależne źródła (NTP/PTP) + monitorowanie stronniczości.
Krytyczne podpisy czasowe: Użyj zaufanego znacznika czasu (TSA) lub wewnętrznej usługi uszczelniania czasu dla partii zdarzeń.
Zasady: brak lokalnych stref czasowych, tylko UTC; dziennik i przesunięcie/jakość czasu.

6) Architektura strumienia dziennika

Agenci → Bufor → Transport → Lądowanie → Łańcuch Hash/Podpis → Zimno/Archiwum → Indeks do wyszukiwania.

Kolekcja na węźle: środki świetlne (daemonset/sidecar) z buforem na dysku (ciśnienie wsteczne).
Transport: kanał chroniony (TLS/mTLS), gwarantowana dostawa (co najmniej raz), idempotent-ingest.
Strefa wyładunku: składowanie obiektu w postaci „surowej” (partie według daty/najemcy/typu).
Indeks: wyszukiwarka/silnik analityczny do zapytań online (gorąca warstwa).
Archiwum (WORM): niezmienne wiadra/taśmy z polityką retencji i prawnym uchwytem.
Kotwica/pieczęć: okresowe „uszczelnianie” opakowań łańcuchów hash (patrz poniżej).

7) Niezmienność kryptograficzna

7. 1 Łańcuchy hashes (wyłącznie dodatek)

Każdy wpis zawiera: 'hash _ curr = H (record)', 'hash _' z poprzedniego wpisu, 'seq'. Każda edycja łamie łańcuch.

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7. 2 Podpis opakowań i znaczek czasu

Co sekundy N/MB tworzymy blok: Merkle root ze wszystkich 'hash _ curr'.
Podpisujemy blok z kluczem audytu (stabilnie przechowywany w KMS/HSM).
Dodaj znacznik czasu TSA i publikuj „Dziennik przejrzystości”.
Opcjonalnie: okresowo kotwicz hash korzeń do zewnętrznej przestrzeni dowodowej (na przykład, niezależny dziennik lub publiczna niezmienna pamięć).

7. 3 Zarządzanie kluczem audytu

Klucze podpisu - w KMS/HSM, obrót w harmonogramie, dostęp wielofaktorowy, podwójna kontrola do eksportu.
Cofnięcie klucza → nowy oddział zaufania; stare podpisy pozostają do zweryfikowania.

8) Polityka w zakresie zatrzymywania i WORM

WORM/immutability: obejmują niezmienne pojemniki/wiadra z polityką retencji i legalnego trzymania dla klas P0/P1.
Wersioning: włączony; usunięcie - tylko dla procedur z opóźnieniem (zakaz natychmiastowego oczyszczania).
Zatrzymanie: gorące (7-30 dni), ciepłe (3-6 miesięcy), zimne/archiwalne (1-7 lat lub więcej - w zależności od regulatora/umowy).
Wielopoziomowość: oddzielne obszary nazw/konta/klucze szyfrujące na najemcę; raportowanie dostępu do dziennika.

9) Prywatność i minimalizacja

Zbiór zgodnie z zasadą konieczności: nie logujemy się zbędnie.
Tokenizacja/pseudonimizacja pól wrażliwych, hash soli dla identyfikatorów.
Szyfrowanie pola po stronie producenta (AEAD) podczas przechowywania w magazynie obiektów współdzielonych.
Prawo do usunięcia (w stosownych przypadkach): jest realizowane poprzez usunięcie kluczy polowych/częściowych, bez naruszania niezmienności pojemnika (planowane podczas projektowania).

10) Dostęp, role i audyt samego audytu

Split: producenci i czytelnicy

Tylko do odczytu z WORM; zmiana polityki zatrzymywania - poprzez odrębne role i procedurę z zatwierdzeniem.
Wszystkie operacje odczytu/eksportu są rejestrowane do dziennika wtórnego (audyt meta).
Eksport do badania/zgodności - w formie zaszyfrowanej z katalogiem bloków hash i łańcuchem zaufania.

11) Obserwowalność i SLO

Wskaźniki: szybkość wtrysku, opóźnienie do wskaźnika,% utracone/powtarzane, ułamek niezsynchronizowanego czasu, błędy w podpisywaniu/kotwiczeniu, napełnianie bufora.
SLO: ≥ 99. 9% zdarzeń dostarczonych ≤ X sekund do gorącego indeksu; 0 niewyjaśnionych „otworów” w sekwencjach; 100% bloków jest podpisanych i znaczonych czasowo.
Alerty: pauza wtryskowa> N minut, nieprawidłowy wzrost skrótu, rozbieżność łańcucha, awaria sygnatury/znacznika czasu, przesunięcie czasu poza próg.

12) Badanie i weryfikacja

Testy czerwono-niebieskie: próba edycji/usunięcia rekordu na różnych etapach; kontrola wykrywania.
Chaos: wyłączenie agenta na węźle, rozbicie sieci, przepełnienie bufora, „spoofing czasu”.
Kontrole kryptograficzne: regularne zatwierdzanie łańcuchów, pojednanie korzeni i znaczków Merkle.
Technicy: odtwarzanie skryptów śledczych z dzienników końcowych.

13) Obsługa i procedury

Runbook „kontrola integralności” (na żądanie i zaplanowane).
Procedura legalnego posiadania i tymczasowego „zamrożenia” stron.
Procedura odkrywania i eksportu przy zachowaniu łańcucha zaufania.
Plan rotacji kluczy audytu i odpowiedzi na kompromis (nowy oddział zaufania, ponowne podpisanie bloków, powiadomienia).

14) Mini przepisy kulinarne

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• Sterowanie/płaszczyzna danych P0: gorące 30 dni → ciepłe 6 miesięcy → archiwum 7 lat (WORM).
• DevOps: gorące 14 dni → ciepłe 3 miesiące → archiwum 1 rok.
• Sygnały Securiti: gorące 90 dni (dla dochodzeń), a następnie 1-3 lata.

15) Częste błędy

"Dzienniki są tekstem bez schematu. "Bez schematu, nie ma deterministycznej integralności i poszukiwań; wymagane są kanoniczne pola JSON i stałe.
Brak korelacji. Brak 'trace _ id' powoduje załamanie dochodzeń.
Miejscowy czas. Tylko UTC i kontrola offsetowa.
Pisze do modyfikowalnych woluminów. Bez WORM, każda immutability jest fikcją.
Nie rejestruj odczytów. Czytanie danych wrażliwych jest ważne, aby naprawić nie mniej niż pisanie.
Sekrety w dziennikach. Włącz oczyszczacze przed wysłaniem, „czerwone listy” wzorów.
Jeden klucz do wszystkiego. Klucze do podpisywania i szyfrowania - oddzielnie, z rolą i obrotem.

16) Zgodność i regulacja

Wymagania dotyczące trwałości/niezmienności zależą od dziedziny (finanse, płatności, telekomunikacja itp.).
Sprawdzalność: dostępność protokołów WORM/retencji, raportów walidacji obwodów, dzienników dostępu do dzienników, legalnego przechowywania i procedur eksportu.

17) Listy kontrolne

Przed sprzedażą

• Taksonomia zdarzeń i zatwierdzony schemat (wymagane pola).
• Środki, bufory, transport chroniony, skonfigurowane pod ciśnieniem wstecznym.
• W zestawie: łańcuchy hash, podpis blokowy, znacznik czasu, dziennik przejrzystości.
• Umożliwia się przechowywanie WORM/prezentacji; test na niezdolność do nadpisania/usunięcia.
• Maskujące/tokenizujące pola wrażliwe.
• Synchronizacja czasu i monitorowanie offsetowe.
• Plan rotacji i przechowywanie kluczy audytu w KMS/HSM.

Operacja

• Cotygodniowe zatwierdzanie łańcuchów i bloków (+ raport).
• Obwód przerwy/błąd podpisu/czas Offset Alerts.
• Okresowe testy zastąpienia/usunięcia zespołu czerwonego.
• Regularny przegląd zatrzymań i kosztów.

18) FAQ

P: Czy wystarczy „tylko dodać” na poziomie bazy danych?
Och nie. Potrzebujemy gwarancji kryptograficznych (łańcuchy hashes, podpisy blokowe, znaczniki czasu) i polityki WORM.

P: Co z prawem do usunięcia danych?
Odp.: Projektowanie kryptowaluty (usuwanie kluczy) dla pól/stron, utrzymanie niezmienności mediów i udowodnienie dzienników.

P: Czy potrzebuję oddzielnego klucza do podpisania bloków?
Och, tak. Oddzielne klawisze podpisywania bloku z kluczy szyfrowania pamięci masowej; przechowywać w KMS/HSM, z rotacją i audytem.

P: Czy możliwe jest „zakotwiczenie” w przestrzeni publicznej?
Odp.: Opcjonalnie. Zwiększa to weryfikowalność i odetnie „historię pisania” w obwodzie.

• „W odpoczynku szyfrowanie”
• „W szyfrowaniu tranzytu”
• „Tajne zarządzanie”
• „Kluczowe zarządzanie i rotacja”
• „Podpisz i zweryfikuj żądania”