Evenimente append-only, înlănțuite criptografic, cu trasabilitate completă și integritate verificabilă.
De ce un jurnal obișnuit nu este de ajuns
Aproape orice aplicație scrie un jurnal. Puține pot demonstra că jurnalul nu a fost modificat după ce a fost scris. Diferența contează exact atunci când jurnalul este cerut ca probă: la un control, într-un litigiu, după un incident de securitate.
Un jurnal care poate fi editat de cineva cu acces la baza de date nu spune despre trecut decât că așa arată acum. Întrebarea auditorului nu este ce scrie în jurnal, ci de unde știm că scrie ce s-a întâmplat.
Cum funcționează înlănțuirea
Evenimentele se scriu o singură dată și nu se modifică — append-only. Fiecare eveniment poartă amprenta criptografică a celui dinaintea lui, astfel încât evenimentele formează un lanț. Modificarea unui eveniment din mijloc schimbă amprenta lui, deci rupe legătura cu toate cele de după, iar ruptura se vede la verificare.
Verificarea nu cere încredere în sistem: se recalculează amprentele pe lanț și se compară. Ori se potrivesc de la un capăt la altul, ori se arată exact unde s-a produs discontinuitatea.
Fiecare operațiune relevantă asupra unui document sau asupra unei înregistrări produce un eveniment: cine a făcut-o, ce a atins, când. Pentru registre, aceasta include și anulările și rectificările, care rămân în evidență cu motivul lor, în loc să șteargă istoria.
- evenimente scrise o singură dată, fără modificare ulterioară;
- înlănțuire criptografică între evenimente consecutive;
- verificare de integritate care arată nu doar că ceva s-a schimbat, ci unde;
- export structurat către sistemele de monitorizare a securității.
La ce folosește, concret
La reconstituirea unui incident: ce s-a întâmplat, în ce ordine, cine a fost implicat. La răspunsul către o autoritate de supraveghere, unde afirmația trebuie însoțită de dovadă. La lămurirea unei dispute interne despre cine a aprobat un document și când.
Și la ceva mai puțin spectaculos, dar mai frecvent: la a demonstra că nu s-a întâmplat nimic. Un lanț de audit continuu și verificabil este, de cele mai multe ori, dovada că sistemul a funcționat normal.
Politica scrisă și politica aplicată
Aproape orice organizație are politici de conformitate. Puține pot demonstra că sunt aplicate uniform. Diferența apare la audit: politica există într-un document aprobat, dar dovada că a fost respectată în fiecare caz trebuie strânsă manual, din mai multe locuri.
Motivul e simplu. O politică aplicată de oameni depinde de atenția lor într-o zi aglomerată. Una aplicată de sistem se aplică la fel de fiecare dată, inclusiv atunci când nimeni nu se uită.
Ce se automatizează
Retenția: fiecare categorie de document primește termenul ei, calculat din data relevantă, iar expirarea declanșează procesul de selecție, nu ștergerea tăcută.
Accesul: drepturile decurg din rol și din clasificarea documentului, nu din cereri individuale tratate una câte una. Un document clasificat ca având regim special nu devine vizibil pentru că cineva a uitat să restrângă un folder.
Protecția informațiilor: marcajele de confidențialitate se aplică pe categorii și determină ce se poate face cu documentul — cine îl vede, dacă se poate trimite în afară, dacă se poate tipări.
Iar ce nu se poate automatiza rămâne explicit: excepțiile se cer, se aprobă și rămân în evidență, în loc să fie tăceri convenabile.
- termene de retenție aplicate pe categorii, automat;
- drepturi care decurg din rol și din clasificare;
- marcaje de confidențialitate cu efecte concrete;
- excepții cerute și aprobate, nu tăcute.
Dovada, nu declarația
Valoarea automatizării se vede la control. Întrebarea „cum vă asigurați că politica de retenție se aplică" primește ca răspuns configurarea și jurnalul, nu o procedură scrisă și o promisiune.
Aceeași logică se aplică la solicitările persoanelor vizate, la raportările periodice și la inspecțiile interne: se interoghează sistemul, nu se reconstituie din dosare.
Întrebări și răspunsuri
Ce se întâmplă dacă cineva modifică baza de date direct?
Modificarea rupe lanțul de amprente, iar verificarea de integritate o semnalează, indicând poziția la care apare discontinuitatea. Jurnalul nu împiedică o intervenție la nivel de bază de date, dar o face vizibilă.
Cât timp se păstrează evenimentele de audit?
Perioada de păstrare se stabilește prin politica organizației și prin cerințele legale aplicabile domeniului dumneavoastră. Platforma nu impune o durată; o aplică pe cea configurată.
Se poate exporta jurnalul către un SIEM?
Da, prin export structurat. Formatul concret și frecvența se stabilesc la implementare, în funcție de sistemul de monitorizare pe care îl folosiți.
Ce operațiuni ajung în jurnal?
Operațiunile asupra documentelor și înregistrărilor — creare, consultare, modificare, anulare, rectificare — împreună cu autorul și momentul. Setul exact se poate detalia într-o discuție tehnică.
Politicile se pot schimba după implementare?
Da, prin configurare. Schimbarea rămâne în evidență, ca orice altă modificare de configurare.
Ce se întâmplă cu documentele deja în sistem când se schimbă o politică?
Comportamentul se stabilește la configurare: politica nouă se poate aplica de la o dată înainte sau retroactiv, după decizia organizației.
Automatizarea poate șterge documente din greșeală?
Expirarea termenului declanșează un proces de selecție, nu o ștergere directă. Eliminarea rămâne o decizie consemnată.
Acoperă și cerințele specifice domeniului nostru?
Politicile se configurează pe categoriile și termenele aplicabile organizației dumneavoastră, inclusiv cele din legislația de domeniu.