Audit și jurnale imuabile

Audit și jurnale imuabile

1) De ce aveți nevoie de ea

Scopul auditului este de a captura „cine, ce, unde, când și de ce” cu o integritate dovedită pentru a menține securitatea, investigațiile, raportarea financiară și conformitatea.
Jurnal imuabil - un format și stocare în care evenimentele sunt înregistrate numai prin adăugare, iar modificarea/ștergerea ulterioară este fie imposibilă, fie detectabilă prin mijloace criptografice și politici de stocare.

2) Modelul amenințării și obiectivele de control

• Editarea/ștergerea intenționată a evenimentelor de către un insider.
• Înlocuirea timp/sursă (reluare/backdating).
• „Linişte” închidere logare pe nod.
• Pierderea unei părți a jurnalului în timpul accidentelor/migrațiilor.
• Colectarea PII excesivă și discordia cu confidențialitatea.

1. Integritate: dovedită prin protecție împotriva modificărilor/ștergerilor.

2. Completitudine: închiderea fluxurilor cheie (plan de control, plan de date, acces, bani).

3. Precizia timpului: timp reproductibil, sincronizat.

4. Accesibilitate: citire şi căutare în cadrul SLO.

5. Confidențialitate: minim PII, tokenizare/criptare, legalitatea utilizării.

3) Taxonomia și prioritățile evenimentului

• Planul de control: autentificare/autorizare, modificări de configurare, operațiuni cheie (KMS), management secret, modificări de politică.
• Planul de date: acces la obiecte/înregistrări/verificări/plăți; citiți/creați/ștergeți.
• Admin și DevOps: SSH/consolă, CI/CD, infrastructură/modificări IaC, escaladarea drepturilor.
• Produs: tranzactii, facturare, operatiuni clienti.
• Sistem/rețea: kernel/agenți/proxies/balancers, brokeri, baze de date.
• Securitate: IDS/IPS/EDR, WAF, anti-DDoS, antifraudă, DLP.

Pentru fiecare clasă, stabilim: criticalitate, schemă, câmpuri obligatorii, termen de valabilitate, cerințe pentru invariabilitate.

4) Câmpuri și formate obligatorii

ID-urile de corelare sunt 'trace _ id',' span _ id', 'request _ id',' actor _ id' (user/service), 'tenant _ id',' resource _ id'.
Context A&A: metoda de autentificare, roluri/politici în momentul acțiunii.
Timp: RFC3339/UTC, milisecunde/nanosecunde; sursa de sincronizare.
Acțiune și rezultat: tipul de operație, scopul, starea, numărul de obiecte afectate.
Integritate: înregistrări locale HMAC, număr de secvență, hash-anterior.
Schema: JSON cu un model stabil (de exemplu, compatibil cu dicționarele comune de evenimente).

Interzis: secrete, chei, jetoane, PAN complet, parole, chei private. PII - numai atunci când este necesar, cu mascare/tokenizare.

5) Timp și sincronizare

Sursa timpului: cel puțin două surse independente (NTP/PTP) + monitorizarea prejudecăților.
Semnături de timp critice: Utilizați servicii de ștampilă de timp de încredere (TSA) sau un serviciu intern de etanșare a timpului pentru loturi de evenimente.
Reguli: fără zone orare locale, numai UTC; jurnal și offset/calitatea timpului.

6) Arhitectura fluxului de jurnal

Agenți Buffer Transport Aterizare Hash Chain/Signature Cold/Archive Index pentru căutare.

Colectarea pe nod: agenți de lumină (daemonset/sidecar) cu un tampon pe disc (back-pressure).
Transport: canal protejat (TLS/mTLS), livrare garantată (cel puțin o dată), idempotent-ingera.
Zona de aterizare: stocarea obiectelor într-o formă „brută” (loturi după dată/chiriaș/tip).
Index: motor de căutare/analiză pentru interogări online (hot layer).
Arhiva (WORM): găleți/benzi imuabile cu politici de păstrare și menținere legală.
Ancora/sigiliu: „etanșare” periodică a pachetelor de lanțuri hash (a se vedea mai jos).

7) Imutabilitate criptografică

7. 1 Lanțuri de hashes (numai pentru adăugare)

Fiecare intrare conține: 'hash _ curr = H (record)', 'hash _ anterior' din intrarea anterioară, 'seq'. Orice editare rupe lanţul.

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 Semnătura pachetelor și ștampila de timp

La fiecare N secunde/MB formăm un bloc: rădăcina Merkle a tuturor 'hash _ curr'.
Semnăm blocul cu cheia de audit (stocată stabil în KMS/HSM).
Adăugați un timestamp TSA și publicați „Jurnalul de transparență”.
Opțional: ancorați periodic hash-ul rădăcinii într-un spațiu extern dovedibil (de exemplu, un jurnal independent sau stocare publică neschimbabilă).

7. 3 Managementul cheilor de audit

Cheile de semnătură - în KMS/HSM, rotație în program, acces multifactor, dual-control pentru export.
Revocarea cheie → unei noi ramuri de încredere; semnăturile vechi rămân verificabile.

8) Politici de retenție și WORM

WORM/imutabilitate: include containere/găleți imuabile cu politici de păstrare și deținere legală pentru clasele P0/P1.
Versioning: activat; ștergerea - numai pentru procedurile cu întârziere (interzicerea epurării instantanee).
Retentie: cald (7-30 zile), cald (3-6 luni), rece/arhiva (1-7 ani sau mai mult - in functie de regulator/contract).
Multi-chirie: namespaces separate/conturi/chei de criptare per chiriaș; raportarea accesului la jurnal.

9) Confidențialitate și minimizare

Colectarea în conformitate cu principiul necesității: nu înregistrăm inutile.
Tokenizarea/pseudonimizarea câmpurilor sensibile, hash de sare pentru identificatori.
Criptarea câmpului producătorului (AEAD) atunci când este stocată în stocarea obiectelor partajate.
Dreptul de ștergere (dacă este cazul): este implementat prin ștergerea cripto a cheilor de câmp/parte, fără a încălca invariabilitatea containerului (planificată în timpul proiectării).

10) Accesul, rolurile și auditul auditului în sine

Split: producători ≠ cititori ≠ administratori.
Citiți numai de la WORM; schimbarea politicilor de păstrare - prin roluri și proceduri separate cu aprobare.
Toate operațiunile de citire/export sunt înregistrate într-un jurnal secundar (meta audit).
Export pentru investigație/conformitate - în formă criptată cu un director bloc hash și un lanț de încredere.

11) Observabilitate și SLO

Valori: rata de injectare, lag la index,% pierdut/repetat, fracțiune de timp nesincronizat, erori de semnare/ancorare, umplere tampon.
SLO: ≥99. 9% din evenimentele livrate ≤ X secunde la indicele cald; 0 „găuri” inexplicabile în secvențe; 100% din blocuri sunt semnate și timbrate.
Alerte: pauză de injectare> N minute, creștere invalid-hash, divergență în lanț, eșec semnătură/timestamp, timp compensat dincolo de prag.

12) Testarea și verificarea

Teste roșu/albastru: o încercare de a edita/șterge o înregistrare în diferite etape; verificarea detectării.
Haos: dezactivarea agentului pe nod, ruperea rețelei, depășirea tamponului, „spoofing de timp”.
Controale cripto: validarea regulată a lanțurilor, reconcilierea rădăcinilor Merkle și a timbrelor.
Criminalistica: redarea scenariilor de investigație de la jurnalele end-to-end.

13) Funcționarea și procedurile

Runbook „verificarea integrității” (la cerere și programată).
Procedura de deținere legală și de „înghețare” temporară a părților.
Descoperirea și procedura de export menținând în același timp lanțul de încredere.
Planul de rotație a cheilor de audit și răspunsul la compromis (noua ramură de încredere, re-semnarea blocurilor, notificări).

14) Mini rețete

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)

• Control/Data plane P0: fierbinte 30 zile → cald 6 luni → arhiva 7 ani (WORM).
• DevOps: fierbinte 14 zile → cald 3 luni → arhiva 1 an.
• Securiti semnale: fierbinte 90 de zile (pentru investigații), apoi 1-3 ani.

15) Erori frecvente

"Jurnalele sunt text fără schemă. "Fără o schemă, nu există integritate deterministă și căutare; JSON canonic și câmpurile fixe sunt obligatorii.
Nici o corelaţie. Absența "trace _ id' descompune investigațiile.
Ora locală. Numai UTC și control offset.
Scrie la volume modificabile. Fără WORM, orice imutabilitate este o ficțiune.
Nu log citește. Citirea datelor sensibile este important să se stabilească nu mai puțin de scris.
Secrete în buşteni. Porniți dezinfectante înainte de a trimite, „liste roșii” de modele.
O cheie pentru orice. Semnarea și criptarea cheilor - separat, cu rol și rotație.

16) Respectarea și reglementarea

Cerințele privind termenul de valabilitate/imutabilitatea depind de domeniu (finanțe, plăți, telecom etc.).
Provabilitate: disponibilitatea protocoalelor WORM/retenție, a rapoartelor de validare a circuitelor, a jurnalelor de acces, a procedurilor legale și a procedurilor de export.

17) Liste de verificare

Înainte de vânzare

• Taxonomia evenimentelor și schema aprobată (câmpurile obligatorii).
• Agenți, tampoane, transport protejat, back-pressure configurat.
• Incluse: lanțuri hash, semnătură bloc, timestamp, jurnal de transparență.
• WORM/stocare de prezentare este activat; test pentru incapacitatea de a suprascrie/șterge.
• Masking/tokenizing câmpuri sensibile.
• Sincronizarea timpului și monitorizarea offset.
• Planul de rotație și stocarea cheilor de audit în KMS/HSM.

Funcționare

• Validarea săptămânală a lanțurilor și blocurilor (+ raport).
• Întreruperea circuitului/Eroare de semnătură/Alerte decalaj de timp.
• Teste periodice de substituție/ștergere a echipei roșii.
• Revizuirea regulată a retențiilor și costurilor.

18) ÎNTREBĂRI FRECVENTE

Î: Este doar „doar adăugarea” la nivelul bazei de date suficient?
Oh, nu. Avem nevoie de garanții criptografice (lanțuri de hashes, semnături de bloc, ștampile de timp) și politici WORM.

Î: Cum rămâne cu dreptul de a șterge datele?
R: Proiectați cripto-ștergerea (eliminarea cheilor) pentru câmpuri/părți, menținând media neschimbabilă și jurnalele dovedibile.

Î: Am nevoie de o cheie separată pentru a semna blocurile?
Oh, da. Separați cheile de semnare a blocurilor de cheile de criptare de stocare; magazin în KMS/HSM, cu rotație și audit.

Î: Este posibilă „ancorarea” într-un spațiu public?
R: Opțional. Acest lucru îmbunătățește verificabilitatea și va întrerupe „rescrierea istoricului” în cadrul circuitului.

• „La criptare de odihnă”
• „În criptarea tranzitului”
• „Managementul secret”
• „Managementul și rotația cheilor”
• „Semnează și verifică cererile”