Dzienniki kontroli transakcji

(Sekcja: Operacje i zarządzanie)

1) Cel i zasady

Ścieżka audytu jest podstawowym źródłem prawdy o tym, kto, co, gdzie, kiedy i dlaczego, z możliwością udowodnienia zapisów są niezmienne i autentyczne.

• Kompletność: uwzględniono działania osób, usług i partnerów zewnętrznych.
• Immutability: Zapisy nie mogą być nadpisane/usunięte bez widocznego śladu.
• Przypisanie: Działanie jest związane z tematem, rolą, kontekstem, artefaktami.
• Powtarzalność - zdarzenie można powtórzyć w raporcie/sporze.
• Minimalizacja PII: tylko konieczne, z maską i żetonami.

2) Obszary objęcia

Działania użytkownika: wejście/SSO/MFA, zmiana ról/limitów, operacje z PII.
Uprzywilejowane operacje: sesje JIT/PAM, break-glass, konsola administratora.
Finanse: cenniki/podatki/publikacje FX, płatności/wypłaty, powiernictwo, odpisy/zwroty.
Konfiguracje/wydania: phicheflags, schemat migracji, deploy/rollback, klucze/certyfikaty.
Integracje: haki internetowe, podpisy, paragony, klucze idempotencji.
Dane: odczyt/eksport PII, tworzenie/usuwanie artefaktów, zmiana zasad.

3) Architektura i niezmienność

Wejście bramki z uwierzytelniania, kontyngentów i walidacji obwodu.
Magazyn WORM (niezmienne wiadra/tylko dodatek): wersja, blokada retencji, blokada prawna.
Crypto quitances: w przypadku zdarzeń krytycznych powstaje 'receipt _ hash' i podpis DSSE.
Łańcuchy Merkle: okresowo zbudowane plastry (punkt kontrolny), opublikowano hash root.
Łańcuch opieki: śledzenie ruchu artefaktów (kto uzyskał dostęp, kiedy, na jakiej podstawie).
Synchronizacja czasu: etykiety NTP/PTP, 'event _ time' i 'ingest _ time', 'skew'.

4) Schemat zdarzeń (odniesienie)

audit_event {
id, event_time, ingest_time, producer, subject {
id, type: human    service    partner, roles[], mfa?, device_posture?
},
action: CREATE    READ    UPDATE    DELETE    EXECUTE    PUBLISH    APPROVE    ROLLBACK,
target { type, id, version?, region?, tenant? },
context { ip/asn, user_agent, env, trace_id, request_id },
policy_version, sod_check: pass    fail, justification?, ticket_ref?,
result: success    deny    error, error_code?,
diff_hash?, payload_hash?, receipt_hash?, dsee_signature?,
pii_classification: none    aggregated    tokenized    sensitive,
retention_class, labels[]
}

Opcjonalnie: dla finansów - „fx _ version/tax _ rule _ version/pricelist _ version”; dla webhooks - 'webhook _ id',' idempotence _ key '.

5) Model i strefy danych

Hot (RAM): 7-30 dni, szybkie żądania/deski rozdzielcze.
Ciepło (OLAP): 6-24 miesiące, analityka/wyszukiwanie.
Zimno (archiwum/WORM): do 7-10 lat (regulacja).
Klasy retencji: „operacyjne”, „finansowe”, „bezpieczeństwo”, „legal _ hold”.
Weryfikacja polityki - wszystkie zdarzenia oznaczone są jako „policy _ version”; Zmiana polityki - pojedyncze wydarzenie audytowe.

6) Dostęp i prywatność

RBAC/ABAC/ReBAC: widoczność według roli/lokatora/regionu/przypadku.
Maskowanie PII: tokenizacja identyfikatorów, wyjście pierwotne - tylko poprzez zatwierdzone zadania.
Brak bezpośredniego usunięcia: tylko „nagrobek” + blokada prawna; planowane „po czyszczeniu” z osobnym czasopismem.
Audyt samego audytu: kto obejrzał/rozładował dzienniki jest również rejestrowany.

7) Jakość, spójność, bierze

Umowy na dane: ścisły system i walidacje lambda na wejściu.
Idempotencja & dedup: '(event_id, producent)'; „widzialna pamięć podręczna” + KV.
Korekta czasu: znaki wodne dla późnych wydarzeń.
Kontrola kompletności: porównanie liczników źródeł i metryki połykania.

8) Deski rozdzielcze i zapytania

Działania operacyjne: działania uprzywilejowane, naruszenia SOD, podnoszenie praw JIT, dostęp do PII.
Finanse: publikacje FX/Tax/Z listy, podanie rozbieżności w realizacji transakcji, podpisy kluczowe.
Integracje: pokwitowania webhook, lag, retrai, takes.
Releases/configs: who/when/what turned on/rolled back, connection with incidents.
Skrypty wyszukiwania: 'trace _ id',' subject. id ',' cel. id', time/region/najemca, „policy _ version”.
Eksport: przesyłki na żądanie z potwierdzeniem odbioru (podpisany manifest).

9) API i haki internetowe

„POST/audit/ingest” - odbieranie zdarzeń (uwierzytelnianie, limity, system).
„GET/audit/search” - filtry, paginacja, ograniczenie wyniku.
„GET/audit/trace/{ trace _ id}” to łańcuch zdarzeń.
„POST/audyt/odbiór/weryfikacja” - rachunek kontrolny/DSSE.
Вебка: „SoDViolate”, „PrivilegedSession”, „PIIAccess”, „Changed”, „ArtifactPublished”.

10) Wskaźniki jakości SLO/audytu

Najnowsza dostępność: ≥ 99. 95%.
Świeżość (RAM): lag ≤ 30 z p95.
Kompletność: ≥ 99. 5% źródeł przesłało dane do okna.
Prawidłowość: rozbieżność kontrolna ≤ 0. 1%.
Dowody manipulacyjne: 100% okresów jest poświadczonych przez Merkle-roots/signatures.
Higiena PII: 100% zdarzeń z klasą wrażliwą - z maską/tokenem.

11) Playbooks i incydenty

Podejrzenie spoofingu rekordów: natychmiastowa weryfikacja korzeni Merkle, uzgodnienie wpływów DSSE, izolacja dostępu, blokada prawna.
Wyciek PII: wyszukiwanie zdarzeń/eksport, audyt dostępu, powiadomienia inspektora ochrony danych/regulatora według ram czasowych.
Naruszenie SoD: blok operacyjny, czasowe usuwanie ról, dochodzenie i dostosowanie polityki.
Awaria: bufor, tryb degradacji, powtórzenie po odzyskaniu, duplikat kontroli.

12) Ekspozycja prawna i zgodność

Zatrzymanie przez jurysdykcję: finanse/podatek - 5-10 lat; bezpieczeństwo - według polityki; dane osobowe - minimalny wymagany okres.
Blokada prawna: zamrażanie usuwania na żądanie sprawy/regulatora.
Artefakty sprawozdawcze: indeks okresowy, hashes root, lista sygnatariuszy, spis źródeł.
Bezzwrotność: podpisy kryptograficzne, niezależne oznaczanie czasu (TSA wewnętrzny).

13) Specyfika iGaming/fintech

Płatności/wypłaty: pełny ślad zezwoleń, rozliczeń, odmów, obciążeń zwrotnych; dopasowanie do wpływów bankowych.
RTP/limity: publikacje profilowe, zmiany, obserwowane decyzje RTP i limity - z podpisami i wersją.
Podmioty powiązane: odbiór haków internetowych, konwersje dedup, zastrzeżenia/escrow - tylko dla podpisanych artefaktów.
Cenniki/podatki/FX: wersja artefakt w każdej kolejności; rolki - z paragonami.

14) RACI

15) Zagrożenia i działania zapobiegawcze

Edytowalne dzienniki bez śladu → legalny brak wsparcia.
Brak synchronizacji czasu → brak nakładania się linii czasowych.
Eksport cieni bez wpływów → wycieki/spory.
Sekrety w dziennikach → kompromis.
Brak związku z SLO/incydenty → „cmentarz danych” bez korzyści.

16) Lista kontrolna wdrażania

• Określić obszary i policy_version zasięgu.
• Wprowadzanie przy użyciu uwierzytelniania, schematów i kwot.
• W tym WORM, plastry Merkle, podpisy DSSE, TSA.
• Skonfigurować klasę i legalne blokady.
• Wprowadź dostęp do RBAC/ABAC/ReBAC i dziennika audytu.
• Budowanie desek rozdzielczych: uprawnienia, PII, finanse, wydania/konfiguracje.
• Włącz playbooks: manipulator, wyciek PII, niepowodzenie połknięcia, naruszenie SoD.
• Wypróbuj powtórki i zrzuć na zestaw testowy.
• Eksport z paragonami i rejestrem zapytań.
• Przeprowadzanie kwartalnych audytów jakościowych (świeżość/kompletność/manipulator).

17) FAQ

Czy można przechowywać wszystko w regularnej bazie danych?
Dla RAM - tak, ale logi krytyczne powinny być powielane w WORM/append-only z podpisami i plasterkami Merkle.

Czy muszę logować wszystkie odczytane dane?
Czytanie PII/Finance jest obowiązkowe; reszta według polityki i kosztów.

Jak udowodnić niezmienność?
Hashes root, podpisy DSSE, niezależny TSA i powtarzalne procedury weryfikacji.

Co zrobić z „prawem do usunięcia” (RODO)?
Usuń podstawowy w systemach przetwarzania; w dziennikach audytu - przechowywać tokeny/hashes bez odzyskiwalnego PII i utrzymywać Legal Hold w razie potrzeby.

Podsumowanie: Dzienniki audytu nie są „logami w S3,”, ale kryptograficznie udowodnioną historią działań z jasną polityką, niezmienną retencją, zarządzanym dostępem oraz gotowością do przeglądu sporów/regulacji. Zbuduj na kontraktach, podpisz krytyczne wydarzenia, wesprzyj cięcia Merkle i deski rozdzielcze - a będziesz miał solidny fundament zaufania, bezpieczeństwa i zgodności.