Rejestrowanie i pozyskiwanie drewna
1) Dlaczego potrzebujemy dzienników i protokołów
Dzienniki są „czarną skrzynką” organizacji: dostarczają dowodów na audyty i dochodzenia, zmniejszają ryzyko operacyjne i regulacyjne, pozwalają przywrócić przebieg zdarzeń i potwierdzić realizację polityk (dostęp, zatrzymywanie, szyfrowanie, KYC/AML, PCI, itp.).
Cele:- Śledzenie działań (kto/co/kiedy/gdzie/dlaczego/co).
- Wykrywanie i ograniczanie zdarzeń (kontrola detektywna i zapobiegawcza).
- Podstawa dowodowa dla organów regulacyjnych/audytorów (immutability).
- SLA/SLO wydajność i zgodność analizy.
2) Taksonomia kłód (minimalny zasięg)
Dostęp i tożsamość (IAM/IGA): uwierzytelnianie, odwracanie ról, SoD, dostęp JIT.
Infrastruktura/chmura/IaC: połączenia API, dryf konfiguracyjny, zdarzenia KMS/HSM.
Aplikacje/biznes - transakcje, PI/finanse, cykl życia zapytań (DSAR)
Bezpieczeństwo: IDS/IPS, EDR, DLP/EDRM, WAF, luki/łatki, antywirusowe.
Sieć: firewall, VPN/Zero Trust, proxy, DNS.
CI/CD/DevSecOp: buduje, depla, SAST/DAST/SCA, tajne skanowanie.
Dane/analityka: rodowód, dostęp do sklepu, maskowanie/anonimizacja.
Operacje: ITSM/bilety, incydenty, zarządzanie zmianą, badania DR/BCP.
Vendors/3rd-party: haki internetowe, federacja SSO, wydarzenia SLA.
3) Wymogi regulacyjne (wytyczne)
RODO/ISO 27701: minimalizacja/maskowanie PI, przechowywanie w harmonogramie, legalne trzymanie, śledzenie DSAR.
SOC 2/ISO 27001: ścieżki audytu, kontrola dostępu do dziennika, dowód wykonania kontroli.
PCI DSS: rejestrowanie dostępu do danych mediów/kart, integralność dziennika, codzienna recenzja.
AML/KYC: możliwość śledzenia kontroli, kontrola sankcji/PEP, protokoły STR/SAR.
4) Wzorcowa architektura pozyskiwania drewna
1. Producenci: aplikacje, chmura, sieć, agenci hosta.
2. Autobus/kolektory: back-pressure, retry, TLS mTLS, deduplication.
3. Normalizacja: pojedynczy format (JSON/OTel), wzbogacenie (najemca, użytkownik, geo, dotkliwość).
- Gorący (wyszukiwanie/SIEM): 7-30 dni, szybki dostęp.
- Zimno (obiekt): miesiące/lata, tanie przechowywanie.
- Archiwum-dowód (WORM/Object Lock): immutability, hash receipts.
- 5. Integralność i podpis: łańcuchy hash/merkley-tree/timestamps.
- 6. Dostęp i bezpieczeństwo: RBAC/ABAC, segmentacja według jurysdykcji, dostęp oparty na przypadku.
- 7. Analityka i wpisy: SIEM/SOAR, identyfikator korelacji, playbooks.
- 8. Katalogi i schematy: rejestr typu zdarzenia, wersioning, testy schematu.
5) Polityka jako kod (przykłady YAML)
Zatrzymanie i przechowywanie prawne
yaml id: LOG-RET-001 title: "Access logs retention"
scope: ["iam. ","app. access"]
retention:
hot_days: 30 cold_days: 365 worm_years: 3 legal_hold: true # when Legal Hold is active, block privacy removal:
pii_mask: ["email","phone","ip"]
review: "annual"Integralność i podpis
yaml id: LOG-INT-001 title: "Signature and commercial fixation"
hashing: "SHA-256"
anchor:
cadence: "hourly"
store: "s3://evidence/anchors"
verification:
schedule: "daily"
alert_on_failure: true6) Wymagania dotyczące jakości dziennika
Strukturyzacja: tylko JSON/OTel, bez tekstu surowego.
Synchronizacja czasu: NTP/PTP, kontrola dryfu; "timestamp", "received _ at 'entry.
Identyfikatory korelacji: 'trace _ id',' span _ id', 'request _ id',' user _ id' (alias).
Semantyka terenowa: słownik danych i kontrakt na schemat testowy.
Lokalizacja/język: pola - klucze angielskie, wartości - ujednolicone (enum).
Polityka dotycząca wielkości i spadku: zakaz niekontrolowanego spadku; kolejki/kwoty/pobieranie próbek ryzyka.
Dane wrażliwe: maskowanie/tokenizacja; zakaz całkowitego przechowywania tajemnic/kart.
7) Prywatność i minimalizacja
Higiena PII: hashes/tokens dziennika zamiast wartości; ścisła maska do e-maila/telefonu/IP.
Kontekst: Nie płacić danymi osobowymi bez powodu.
Jurysdykcja: przechowywanie i dostęp według kraju (miejsce zamieszkania danych), identyfikowalność kopii.
DSAR: etykiety wyszukiwania i eksportu w poszczególnych przypadkach; możliwość drukowania raportów z depersonalizacją.
8) Niezmienność i dowody
WORM/Object Lock - zapobiega usuwaniu/nadpisywaniu w danym okresie.
Podpis kryptograficzny: podpis partii; Korzenie Merkli z codziennym kotwiczeniem.
Łańcuch przechowywania: dziennik dostępu, potwierdzenia skrótu, kwoty w raportach.
Weryfikacja: okresowe kontrole integralności i pozasynchronizowane wpisy.
9) Kontrola dostępu do dziennika
RBAC/ABAC: czytaj/wyszukaj tylko role vs export/sharing.
Dostęp oparty na przypadku: dostęp do dzienników wrażliwych - tylko w ramach dochodzenia/biletu.
Sekrety/klucze: KMS/HSM; rotacja, podział wiedzy, podwójna kontrola.
Audyt dostępu: osobny magazyn' którzy czytają, które dzienniki "+ alerty anomalii.
10) Metryki i rejestrowanie SLO
Połknięcie Lag: 95 procent opóźnienia odbioru (cel ≤ 60 sekund).
Wskaźnik spadku: odsetek utraconych zdarzeń (cel 0; alert> 0. 001%).
Zgodność schematu:% zdarzeń zatwierdzonych schematem (≥ 99. 5%).
Zasięg:% systemów pod scentralizowanym rejestrowaniem (≥ 98% krytyczne).
Pass Integrity: udane kontrole łańcucha hash (100%).
Przegląd dostępu: miesięczne roszczenie o prawa, opóźnienie - 0.
Wskaźnik przecieku PII: wykryte „czyste” PI w dziennikach (cel 0 krytyczny).
11) Deski rozdzielcze (minimalny zestaw)
Ingestion & Lag: objętość/prędkość, opóźnienie, spadek, gorące sprężyny.
Integralność i WORM: status kotwiczenia, weryfikacje, blokada obiektów.
Zdarzenia bezpieczeństwa: korelacje krytyczne, karta MITRE.
Dostęp do dzienników: Kto i co czytać/eksportowane; anomalie.
Widok zgodności: statusy zatrzymywania/legalnego trzymania, raporty z audytu, eksport DSAR.
Schemat zdrowia: parsing błędy/schemat wersje, procent spuścizny agentów.
12) SOP (standardowe procedury)
SOP-1: Połączenie źródła dziennika
1. Rejestracja źródła i krytyki → 2) wybór programu/OTel → 3) TLS/mTLS, żetony →
2. suchy-run w ustawianiu (walidacja schematów, maski PII) → 5) połączenie w produkcji →
3. dodawanie do katalogów/desek rozdzielczych → 7) weryfikacja retencji/WORM.
SOP-2: Odpowiedź na incydent (dzienniki jako dowód)
Wykryć → Triage → zakres przypadku → Hold Legal →
Hash Capture and Anchoring → Analityka/Timeline → Raport i CAPA → Wydanie lekcji.
SOP-3: Wniosek/audyt
1. Otwórz skrzynkę i filtry przez żądanie ID → 2) eksport do wymaganego formatu →
2. Weryfikacja prawna/zgodność → 4) streszczenie hash → 5) wysyłanie i rejestrowanie.
SOP-4: Wersja dostępu do dziennika
miesięczna certyfikacja właścicieli; auto-roar praw „osieroconych”; Raport SoD.
13) Formaty i przykłady
Przykład zdarzenia dostępu (JSON)
json
{
"ts": "2025-10-31T13:45:12. 345Z",
"env": "prod",
"system": "iam",
"event": "role_grant",
"actor": {"type": "user", "id": "u_9f1...", "tenant": "eu-1"},
"subject": {"type": "user", "id": "u_1ab..."},
"role": "finance_approver",
"reason": "ticket-OPS-1422",
"ip": "0. 0. 0. 0",
"trace_id": "2a4d...",
"pii": {"email": "hash:sha256:..."},
"sign": {"batch_id":"b_20251031_13","merkle_leaf":"..."}
}Reguła wykrywania (pseudo-Rego)
rego deny_access_if_sod_conflict {
input. event == "role_grant"
input. role == "finance_approver"
has_role(input. subject. id, "vendor_onboarder")
}14) Role i RACI
15) Dostawca i zarządzanie łańcuchem dostaw
W umowach: prawo do audytu dzienników, formatów, przechowywania i dostępu SLA, WORM/immutability.
Podwykonawcy: rejestr źródłowy i zatrzymanie „end-to-end”.
Eksport/offboard: potwierdzenie zniszczenia i skróconego raportu.
16) Antypattery
Loguje się w „wolnym tekście”, bez diagramów i korelacji.
Przechowywanie bez WORM i utrwalenia hash jest sporem w audycie.
Dane wrażliwe w dziennikach „jak jest”.
Nie ma synchronizacji czasu i normalnych trace_id.
Spadek zdarzeń przy szczytach obciążenia; brak ciśnienia wstecznego.
Uniwersalny dostęp do dzienników bez kontroli etui.
„Wieczne” prawa do czytania dzienników, bez ponownej certyfikacji.
17) Listy kontrolne
Uruchamianie funkcji rejestrowania
- Zidentyfikowano taksonomię źródłową i krytykę.
- Deklarowane systemy i polityki zatrzymywania/Legalne przechowywanie (jako kod).
- TLS/mTLS, żetony, środki automatycznej aktualizacji.
- Testowane maski/żetony PII.
- WORM/Object Lock i kotwiczenie są włączone.
- Ustanowiono deski rozdzielcze/alerty/mierniki.
- Wersja dostępu i SoD są skonfigurowane.
Przed audytem/Reg Request
- „pakiet audytu” zebrany: schematy, polityki, sprawozdania dotyczące integralności, próbki.
- Sprawdza integralność i dzienniki dostępu w danym okresie.
- Potwierdzone statusy DSAR/Legal Hold.
- Wygenerowano podsumowanie skrótu przesyłania i wysyłania potwierdzenia.
18) Model zapadalności (M0-M4)
Podręcznik M0: rozproszone dzienniki, brak schematów i retencji.
M1 Scentralizowana kolekcja: wyszukiwanie podstawowe, taksonomia częściowa.
M2 Managed: schematy i zasady-as-code, deski rozdzielcze, retencja/WORM.
M3 Integrated: OTel odwzorowanie, SOAR, kotwiczenie/merkly, case-based access.
M4 Zapewniono: „audyt gotowy za pomocą przycisku”, wykrywanie prognostyczne, automatyczna kontrola integralności i legalnie istotne wpływy.
19) Powiązane artykuły wiki
Ciągły monitoring zgodności (CCM)
KPI i wskaźniki zgodności
Prawne przechowywanie i zamrażanie danych
Polityka i procedury Cykl życia
Przekazywanie rozwiązań w zakresie zgodności
Zarządzanie zmianami w polityce zgodności
Należyta staranność i ryzyko outsourcingu
Razem
Silna funkcja logowania nie jest „magazynem wiadomości”, ale zarządzanym systemem: ustrukturyzowane zdarzenia, rygorystyczne schematy i uprawnienia, niezmienność i podpis, domyślna prywatność, ścisła kontrola dostępu i replikacja dowodów. Taki system umożliwia szybkie przeprowadzanie dochodzeń, przewidywanie audytów i zarządzanie ryzykiem.