Ścieżki audytu i ślady dostępu
1) Cel i zakres
Cel: zapewnienie wiarygodności działań użytkownika/serwisu, przejrzystości dochodzeń, zgodności z wymogami regulacyjnymi i normami wewnętrznymi (RODO/AML, umowy z dostawcami PSP/KYC, w stosownych przypadkach ISO/PCI).
Zasięg: wszystkie systemy produkcyjne, usługi platformowe (konto, płatności, zwalczanie nadużyć finansowych, CUS/sankcje, RG), panele administracyjne, bramki API, DWH/BI, infrastruktura (K8s/chmura), integracja z dostawcami.
2) Co zalogować (klasy wydarzeń)
1. Identyfikacja i dostęp: login/logout, MFA, password/key change, SSO, „break-glass” access.
2. Działania administracyjne: zmiany ról/praw, konfiguracji, zasad zwalczania nadużyć finansowych/sankcji, flag funkcji.
3. Operacje z danymi PII/finansowymi: czytanie/eksport/usuwanie, przesyłanie, dostęp do KYC, przeglądanie profili VIP.
4. Transakcje i pieniądze: Gotówka/depozyty, anulowanie, zwroty, decyzje o obciążeniu zwrotnym.
5. Zgodność/AML/KYC: wyniki badań przesiewowych (sankcje/PEP/Adverse Media), decyzje (TP/FP), EDD/STR/SAR.
6. Incydenty i bezpieczeństwo: eskalacje, zmiany reguł WAF/IDS, izolacja usług, tajna rotacja.
7. Integracje/sprzedawcy: połączenia API, błędy, timeouts, eksport, usunięcie danych/potwierdzenie zwrotu.
3) Obowiązkowe pola zdarzeń (minimum)
'event _ id' (UUID),' ts _ utc', 'ts _ local', 'source _ service', 'trace _ id'/' span _ id'
"actor _ type" (użytkownik/usługa/sprzedawca), "actor _ id' (silny identyfikator)," actor _ org "(jeżeli B2B)
„subject _ type” (konto/tx/dokument/zestaw danych), „subject _ id”
„działanie” (np. „READ _ PII”, „EXPORT _ DATA”, „ROLE _ UPDATE”, „WITHDRAWAL _ APPROVE”)
'result' (success/deny/error) 'reason '/' error _ code'
„ip”, „device _ fingerprint”, „geo” (kraj/region), „auth _ context” (MFA/SSO)
„fields _ access ”/„ scope” (podczas pracy z danymi PII/finansowymi) - z maskowaniem
"purpose "/" ticket _ id' (powód: DSAR, incydent, wniosek regulatora, zadanie operacyjne)
4) Immutability i provability
Magazyn WORM do kopii „złotej” (niezmienne wiadra/polityka retencji).
Łańcuch podpisów kryptograficznych/hash: okresowe podpisywanie partii zdarzeń i/lub budowanie łańcucha hashes (łańcuchy hash) w celu identyfikacji modyfikacji.
Dziennik zmian w systemach/zasadach: systemy weryfikacji i polityka pozyskiwania drewna; wszelkie edycje przechodzą przez CAB.
Przechowywanie w dwóch pętlach: indeks online (wyszukiwanie) + archiwum/immutability.
5) Synchronizacja i śledzenie czasu
Pojedynczy NTP/Chrony we wszystkich środowiskach; w logach - 'ts _ utc' jako źródło prawdy.
Do każdego dziennika - 'trace _ id'/' span _ id' do śledzenia żądań od końca do końca (korelacja między usługami, dostawcami i przodem).
6) Prywatność i tajemnice
Zabronione: hasła, żetony, pełny PAN/CSC, pełne numery dokumentów, surowe dane biometryczne.
Domyślne maskowanie: e-mail/telefon/IBAN/PAN → żetony/wyświetlacz częściowy.
Aliasing: 'user _ id' → stabilny token w analityce; powiązanie z prawdziwym identyfikatorem - tylko w pętli chronionej.
Kompatybilność DSAR: możliwość selektywnego wydobywania kłód przez podmiot bez ujawniania obcych PII.
7) Okres trwałości i poziomy (zatrzymanie)
8) Dostęp i kontrola (RBAC/ABAC)
Role odczytu dziennika audytu są oddzielone od ról administracyjnych.
Dostęp MFA i Just-in-Time (break-glass) z automatycznym odwołaniem/rejestrowaniem przyczyn.
Polityka „minimum”: dostęp do PII/dziedzin finansowych tylko w razie potrzeby i z utrwaleniem „celu”.
Eksport/przesłanie: białe listy miejsc przeznaczenia i formatów; obowiązkowy podpis/hash, log przesyłania.
9) Integracja SIEM/SOAR/ETL
Przepływ zdarzeń audytowych wchodzi do SIEM dla korelacji (np. masa 'READ _ PII' + wejście z nowego urządzenia).
Playbooks SOAR: auto-bilety na naruszenie zasad (brak „celu”, nienormalna objętość, dostęp poza oknem).
ETL/DWH: „audit _ access”, „pii _ export”, „admin _ changes” windows with quality control and schema versioning.
10) Jakość danych i walidatory
Schematy jako kod (JSON/Protobuf/Avro): wymagane pola, typy, słowniki; Walidatory CI.
Kolejka odrzucenia i kwarantanny w przypadku zdarzeń z błędami schematu; metryki złomu.
Deduplikacja/idempotencja przez '(event_id, trace_id, ts)'; kontrola retransmisji.
11) RACI
12) SOP: dochodzenie w sprawie dostępu do danych
1. Wyzwalacz: alert SIEM (nieprawidłowy 'READ _ PII '/export), reklamacja, sygnał od sprzedawcy.
2. Zbiór artefaktów: zdarzenia rozładunkowe według 'actor _ id'/' subject _ id'/' trace _ id',' purpose 'log, related logs (WAF/IdP).
3. Weryfikacja legalności: obecność fundacji (zadanie DSAR/incydent/service), koordynacja, okna dostępu.
4. Ocena wpływu: zakres/kategorie PII, jurysdykcje, ryzyko dla uczestników.
5. Rozwiązanie: incydent-bridge (gdy High/Critical), przechowywanie (cofnięcie dostępu, rotacja klucza).
6. Sprawozdanie i umowy CAPA: przyczyny, polityka naruszona, środki (maskowanie, szkolenia, zmiany RBAC), terminy.
13) SOP: Data Export (Regulator/Partner/DSAR)
1. Wniosek → weryfikacja fundamentu i tożsamości (dla DSAR) → generacja wniosku do DWH.
2. Domyślnie depersonalizacja/minimalizacja; włączenie PII wyłącznie ze względów prawnych.
3. Pobierz generację (CSV/JSON/Parquet) → podpis/hash → napisz do dziennika pobierania (who/when/what/to/reason).
4. Transfer za pośrednictwem zatwierdzonego kanału (sFTP/Secure link); okres przechowywania kopii - według zasad.
5. Po inspekcji: potwierdzenie odbioru, usunięcie tymczasowych plików.
14) Wskaźniki i KRI/KPI
Zasięg: udział krytycznych systemów wysyłających zdarzenia audytowe ≥ 95%.
Błędy DQ: zdarzenia odrzucone przez walidator ≤ 0. 5% przepływu.
MTTD straty przepływu: ≤ 15 min (uwaga przy ciszy).
Nieprawidłowy dostęp bez „celu”: = 0 (KRI).
Czas odpowiedzi na badanie: mediana ≤ 4 h, P95 ≤ 24 h.
Eksport podpisany/hash: 100%.
Retencja: usunięcia/archiwa na czas ≥ 99%.
15) Wymagania dotyczące dostawcy i podwykonawcy przetwórstwa
DPA/SLA: opis dzienników kontroli (schematy, terminy, geografia, format wywozu), WORM/immutability, SLA zgłoszeń incydentów.
Dostęp dostawcy: nazwane konta usług, dzienniki ich działań, możliwość selektywnego audytu.
Offboarding: cofnięcie klucza, eksport/usunięcie dzienników, akt zamknięcia, potwierdzenie zniszczenia kopii zapasowej.
16) Bezpieczeństwo i ochrona przed manipulacją
Rozdzielenie ról: źródło administratora i administratora.
Podpis agenta/kolektora, mTLS między komponentami.
Sterowanie anty-manipulacyjne: porównanie hashes, regularne kontrole integralności, wpisy dotyczące rozbieżności.
Replikacja geodezyjna kopii WORM i regularne testy odzysku.
17) Błędy typu i anty-wzory
Rejestrowanie wartości wrażliwych (PAN/secrets) → natychmiastowe włączenie redaction-middleware.
Brak 'celu '/' ticket _ id' podczas dostępu do PII.
Lokalne przesyłanie „na pulpit” i wysyłanie pocztą elektroniczną.
Brak jednego schematu i walidacji → ciche pola, niemożność korelacji.
Jedno super konto bez powiązania z osobą lub usługą.
18) Listy kontrolne
18. 1 Uruchomienie/przegląd polityki
- Zatwierdza się schematy i słowniki; wymagane pola w tym
- Maskowanie i zakazy dotyczące tajemnic są włączone
- NTP skonfigurowane, 'trace _ id' wszędzie
- Warstwy gorące/ciepłe/zimne/WORM są ułożone
- RBAC/ABAC i szkło łamania są zaprojektowane
- Zintegrowane SIEM/SOAR, sprawdzone wpisy
18. 2 Miesięczny audyt
- Wybór eksportu: Poprawne podpisy/dzienniki
- Zatrzymanie/usunięcie kontroli/blokada prawna
- DQ metrics OK, quarantine parsing
- Dzienniki dostawcy dostępne/pełne
19) Plan działania w zakresie wdrażania
Tygodnie 1-2: inwentaryzacja systemów, koordynacja systemów i obowiązkowych pól, ustawienia czasu i śladu.
Tygodnie 3-4: włączanie maskowania, warstwa WORM, integracja SIEM/SOAR, uruchamianie dzienników eksportowych.
Miesiąc 2: walidator/automatyka alarmowa, odtwarzacze dochodzeniowe, szkolenie zespołu.
Miesiąc 3 +: regularne audyty, testy warunków skrajnych, wielopoziomowe, audyty dostawcy/kontraktowe.
TL; DR
Silne ścieżki audytu = pełne i ustrukturyzowane zdarzenia + immutability (WORM) i podpisy + maskowanie PII + twarde rejestry dostępu i przesyłania + integracja SIEM/SOAR. Przyspiesza to dochodzenie, zmniejsza ryzyko i sprawia, że zgodność jest możliwa do udowodnienia.