Jurnalul de audit într-un SaaS B2B: ce evenimente înregistrezi și ce lași afară

Un jurnal de audit pentru un SaaS B2B ar trebui să arate cine a schimbat un drept de acces, un flux sau o setare, când s-a întâmplat și ce rezultat a avut acțiunea. Începe cu operațiunile care schimbă ce pot face alte persoane sau unde ajung datele. Dacă un administrator invită un coleg într-o organizație, înregistrarea utilă nu este simplul fapt că a apăsat un buton, ci invitația efectiv creată, rolul acordat și organizația afectată.

Alege evenimentele după riscul operațiunii

Ghidul OWASP pentru înregistrarea evenimentelor recomandă definirea jurnalizării încă din proiectare, proporțional cu riscurile. Include modificarea rolurilor, crearea și revocarea tokenurilor, folosirea accesului de administrator, exportul de date și schimbările de configurație. Într-un produs care trimite facturi, de exemplu, modificarea contului către care pleacă exportul contabil merită o urmă distinctă de simpla deschidere a paginii de setări.

Nu transforma fiecare mișcare a mouse-ului într-un eveniment de audit. Un jurnal plin de vizualizări de pagini ascunde acțiunile relevante și crește volumul de date de protejat. Separă, în proiectarea produsului, jurnalul de audit destinat administratorului clientului de logurile tehnice pentru diagnosticarea erorilor. Pot exista legături între ele printr-un identificator de cerere, însă publicul, perioada de păstrare și câmpurile necesare pot diferi.

Pentru prima versiune, scrie o listă de operațiuni reale din produs: invitație, schimbare de rol, dezactivarea unui utilizator, conectarea unei integrări, schimbarea unei reguli de aprobare și export. Pentru fiecare, stabilește ce rezultat trebuie consemnat. O încercare respinsă din lipsa drepturilor poate fi relevantă pentru investigație, chiar dacă documentul nu a fost modificat.

Construiește evenimentul astfel încât să poată fi verificat

OWASP rezumă informația de bază prin întrebările când, unde, cine și ce. Într-un SaaS cu mai mulți clienți, adaugă explicit identificatorul organizației: același utilizator poate aparține mai multor spații de lucru. Notează actorul, acțiunea, obiectul, rezultatul, momentul și un identificator stabil al evenimentului. Păstrează separat momentul producerii operațiunii de momentul în care un proces întârziat a scris evenimentul.

Un exemplu de structură ar fi: organizația A, administratorul cu ID intern 42, schimbare de rol pentru utilizatorul 87, din editor în administrator, operațiune reușită, cu referință la cererea care a produs modificarea. Exemplul descrie o schemă de proiectare, nu un eveniment real. Pentru un proces automat, actorul trebuie să indice serviciul sau cheia care a inițiat acțiunea, nu să fie trecut generic „sistemul”.

Înregistrează evenimentul după ce rezultatul operațiunii este cunoscut. Dacă interfața afișează „salvat”, dar tranzacția din baza de date a eșuat, un jurnal care spune „schimbare reușită” ar induce în eroare. Testează și acțiunile repetate: un retry nu ar trebui să apară drept două schimbări diferite dacă efectul a fost unul singur. Documentația GitLab pentru trimiterea evenimentelor de audit precizează că același eveniment poate fi livrat de mai multe ori și recomandă deduplicarea după ID.

Nu copia secretele în jurnal

OWASP indică parolele, tokenurile de acces, cheile de criptare, datele bancare și alte informații sensibile drept valori care, de regulă, trebuie excluse, mascate sau protejate înainte de jurnalizare. În locul valorii unui token nou, poți păstra ID-ul intern al cheii, cine a creat-o și ce permisiuni i-au fost atribuite. Când un utilizator exportă date, consemnează tipul exportului și organizația, dar evaluează separat dacă numele fișierului sau filtrele conțin date personale.

Accesul la jurnal trebuie acordat în funcție de rol. Un administrator al organizației A nu trebuie să poată vedea evenimentele organizației B. Verifică acest lucru și la export, filtrare și API, nu doar în interfața web. Consultă responsabilul juridic sau de protecție a datelor înainte de a stabili perioada de păstrare; o durată universală pentru toate produsele și contractele nu poate fi dedusă dintr-un ghid tehnic.

Verifică integritatea și exportul înainte să promiți auditabilitate

Un șir de rânduri într-o bază de date nu dovedește singur că nimeni nu le-a schimbat. Limitează cine poate modifica sau șterge evenimentele, urmărește accesul la ele și testează restaurarea după o defecțiune. AWS explică în documentația CloudTrail cum folosește hashuri și fișiere semnate pentru a detecta modificarea sau ștergerea logurilor livrate. Acesta este un exemplu de mecanism, nu o garanție automată pentru jurnalul propriei aplicații: funcția trebuie activată și validarea executată.

Testează un export cu un incident simulat. Poate echipa reconstitui schimbarea de rol, cu momentul și actorul corect, fără să citească datele altui client? Poate identifica o pauză în colectarea evenimentelor? GitHub arată în documentația jurnalului său organizațional că perioada disponibilă în interfață poate fi diferită de cea a unui sistem extern de streaming; verifică limitele instrumentului folosit înainte să promiți clientului o arhivă mai lungă.

Leagă verificarea jurnalului de procedura pentru primele 60 de minute ale unui incident. Dacă jurnalul este păstrat într-un serviciu separat, include-l și în testul de restaurare a datelor: recuperarea aplicației fără istoricul schimbărilor lasă echipa fără o parte din explicația incidentului. Prima versiune este suficientă când răspunde consecvent la întrebările concrete ale clientului și când limitele de acoperire sunt documentate, nu mascate.