Jurnalul de audit și accesul suportului: cine, ce și când

Gândește-te la Marta, office manager într-o companie cu 250 de angajați, două etaje și o parcare. Marți, ora 9:50. Trei oameni îi scriu în zece minute: rezervările lor de birou au fost eliberate ca neprezentări, deși au ajuns la 9:40, ca în fiecare săptămână. Ceva s-a schimbat și nimeni nu își amintește să fi schimbat ceva. Organizația are patru administratori, plus o integrare care sincronizează utilizatorii din directorul companiei. Întrebarea este simplă: cine a schimbat ce și când?

O săptămână mai târziu, responsabilul cu protecția datelor pune o altă întrebare pentru evaluarea anuală a furnizorilor: „S-a uitat furnizorul software în datele noastre anul acesta și, dacă da, când?” La astfel de întrebări se răspunde adesea cu un document de politică. Marta ar vrea să răspundă cu o listă.

Acest articol arată, pas cu pas, cum răspunde jurnalul de audit Desk & Park la ambele întrebări și ce nu face.

Pasul 1: deschide jurnalul de audit și găsește modificarea

Administratorii găsesc jurnalul la Jurnal de audit. Sus sunt trei contoare: evenimentele din ultimele 24 de ore, avertismentele și evenimentele critice. Dedesubt se află un tabel cu cele mai recente intrări, de la cea mai nouă, cu următoarele coloane:

• Marcaj temporal: când s-a întâmplat.
• Gravitate: Informație, Avertisment sau Critic.
• Actor: adresa de e-mail a celui care a făcut modificarea, cu rolul dedesubt, sau „system” pentru acțiunile automate.
• Acțiune și Resursă: ce s-a făcut și asupra ce tip de obiect.
• Detalii: valorile implicate, de exemplu role: MEMBER → ADMIN pentru o schimbare de rol.
• Adresă IP: de unde a venit cererea.

Marta scrie „policy” în câmpul de căutare („Căutați după actor, acțiune sau detalii...”). Intrarea este acolo: ieri la 17:12, unul dintre administratori a modificat politica de rezervare și a scurtat termenul de check-in. Intrarea înregistrează valorile dinainte și de după modificare, așa că discuția care urmează este despre dacă noul termen are sens, nu despre cine l-a schimbat. (Dacă ajustezi acest termen, articolul nostru despre rezervările fantomă și eliberarea automată explică compromisul.)

Ce se înregistrează

Jurnalul acoperă modificările pe care un administrator ar avea vreodată nevoie să le reconstituie: utilizatori și roluri, rezervări, spații și hărți, locații, politica de rezervare, integrări, setările de single sign-on și SCIM, sincronizarea calendarelor, vizitatori, dispozitive kiosk și copii de siguranță. Apar și modificările făcute automat prin provizionarea SCIM, așa că „directorul a dezactivat această persoană” se distinge de „un administrator a făcut-o”.

Fiecare intrare stochează actorul și rolul său, acțiunea și obiectul vizat, rezultatul, valorile dinainte și de după, adresa IP și user agentul browserului.

Filtrul de gravitate

Schimbările de rol, dezactivările și ștergerile sunt marcate Avertisment. Acțiunile eșuate sunt Critic. Filtrarea după gravitate este cea mai rapidă revizuire săptămânală: setează filtrul la Avertisment, parcurge cine a fost promovat sau dezactivat și gata.

Pasul 2: fluxul de securitate, în același tabel

Modificările de conținut sunt doar jumătate din imagine. Același tabel arată și fluxul de securitate: autentificările reușite și eșuate, blocările după eșecuri repetate, codurile de doi factori cerute și eșuate, activarea sau dezactivarea autentificării cu doi factori, resetările și schimbările de parolă și reutilizarea unui token de sesiune revocat. O autentificare eșuată, o blocare sau un token reutilizat apar ca Critic; dezactivarea autentificării cu doi factori apare ca Avertisment.

Pentru Marta, asta înseamnă un singur loc în care să se uite. Dacă un cont a fost blocat la 7:00 și rolul lui s-a schimbat la 7:05, ambele rânduri stau unul lângă altul.

Pasul 3: răspunsul pentru DPO: accesul suportului este înregistrat în propriul tău jurnal

Acum, a doua întrebare. Când operatorul platformei, echipa care administrează Desk & Park, deschide vizualizarea de suport a organizației tale pentru a rezolva un tichet, sistemul scrie o intrare în propriul jurnal de audit al organizației tale. Aceasta apare ca TENANT SUPPORT ACCESS, cu adresa de e-mail a operatorului, ora și adresa IP.

Așa că Marta scrie „support” în câmpul de căutare și primește răspunsul sub formă de listă: când cineva din partea furnizorului a deschis datele organizației și cine a fost. Aceasta este diferența dintre „avem o politică” și „iată înregistrarea”. Intrarea ajunge în jurnalul tău, nu într-un jurnal pe care doar furnizorul îl poate citi. Pentru că pagina arată cele mai recente intrări, Marta face din această verificare un obicei lunar și păstrează exportul, în loc să aștepte evaluarea anuală.

Unde se află jurnalul și cât timp rămâne

Fiecare organizație din Desk & Park are propria bază de date PostgreSQL, cu propriul rol de autentificare în baza de date, iar jurnalul de audit este stocat acolo, alături de utilizatorii, hărțile și rezervările tale. Explicăm de ce contează această arhitectură în de ce datele spațiului de lucru au nevoie de o bază de date izolată. Fluxul de securitate este păstrat de serviciul de autentificare al platformei și îți este afișat filtrat pentru organizația ta.

Intrările de audit și de securitate sunt păstrate implicit 365 de zile și apoi șterse automat, în conformitate cu perioadele de păstrare din politica de confidențialitate. În jurul jurnalului se află celelalte controale pe care un administrator le are asupra datelor organizației:

• Copii de siguranță criptate în fiecare noapte ale bazei de date a organizației, pe care administratorul organizației le poate dezactiva.
• Un export JSON al datelor organizației, pentru administratori.
• O cerere de ștergere pentru întreaga organizație.

Condițiile de prelucrare a datelor se găsesc în DPA.

Sfaturi practice

• Dă-i fiecăruia propriul cont de administrator. Un cont comun „admin@” face coloana Actor inutilă. O persoană, un cont.
• Fă o revizuire săptămânală de cinci minute. Filtrează după Avertisment, apoi după Critic. Caută schimbări de rol la care nu te așteptai și autentificări eșuate repetate.
• Păstrează o copie dacă ai nevoie de un istoric mai lung. Butonul Exportați CSV descarcă intrările încărcate în acel moment pe pagină, adică pe cele mai recente. Dacă auditorii tăi vor mai mult de un an, exportă după un program regulat și păstrează fișierele împreună cu celelalte înregistrări de conformitate.
• Adaugă accesul suportului în evaluarea furnizorului. O dată pe lună, caută „support”, exportă rezultatul și arhivează-l pentru evaluarea anuală. Durează un minut.
• Combină jurnalul cu o autentificare puternică a administratorilor. Jurnalul îți spune ce s-a întâmplat; autentificarea cu doi factori pe fiecare cont de administrator face mai puțin probabil să se întâmple ceva rău. Vezi SSO, passkey și autentificarea cu doi factori.

Ce nu face

Pagina de administrare arată cele mai recente intrări și oferă căutare în text liber și un filtru de gravitate pentru ele, nu filtrare după interval de date. Exportul CSV acoperă intrările încărcate pe pagină, nu întregul an. Nu există transmiterea evenimentelor de audit în flux către un SIEM. Intrările mai vechi decât perioada de păstrare sunt șterse, așa că arhivarea pe termen lung este exportul tău, nu produsul. Iar izolarea descrisă mai sus este o bază de date separată pentru fiecare organizație, nu hardware separat.

Întrebări frecvente