Unde dispare un nume de utilizator VPN din pipeline-ul de jurnale?

Sesiunile apar în panou în timp ce coloana numelui de utilizator rămâne goală, iar primul instinct este să dăm vina pe parser. Acel instinct sare peste trei etape anterioare în care valoarea s-ar fi putut pierde. Un gateway poate masca o identitate conform politicii, o regulă de ingestie o poate șterge înainte de indexare, iar o extragere din momentul căutării poate pur și simplu să nu o numească. Remedierea depinde de care graniță puteți demonstra că este responsabilă, așa că munca utilă este comparația, nu configurarea.

Începeți cu un singur eveniment, nu cu panoul

Alegeți un singur eveniment de autentificare și notați ce îl identifică: modelul și versiunea gateway-ului, metoda de autentificare, identificatorul evenimentului, marcajul temporal și adresa sursă. Adăugați numele de utilizator exact cum l-a tastat persoana, inclusiv majusculele și minusculele, deoarece o căutare sensibilă la majuscule poate ascunde un câmp care există. Tratați acel eveniment ca referință pentru fiecare comparație ulterioară.

Tipurile de evenimente nu împart aceeași schemă. O încercare eșuată, o autentificare reușită fără client și o reconectare a tunelului pot produce câmpuri diferite, iar unele gateway-uri omit identitatea când încercarea nu a ajuns niciodată la autentificarea utilizatorului. O coloană goală la un tip de eveniment este, prin urmare, o dovadă slabă a unei probleme în pipeline.

Lucrați cu o identitate de test aprobată în locul unui cont real de angajat și țineți comparația în limitele regulilor de acces care guvernează deja datele de jurnal. Activarea pe scară largă a jurnalizării detaliate de autentificare doar pentru a obține o mostră schimbă sistemul pe care încercați să îl măsurați.

Comparați cele patru granițe în ordine

Valoarea poate dispărea într-unul din patru puncte. Fiecare punct are alt proprietar și altă remediere.

Opriți-vă la prima graniță unde valoarea dispare. O nepotrivire între vizualizarea dispozitivului și copia brută indică transportul sau configurația colectorului; o potrivire acolo dar o valoare lipsă în evenimentul indexat indică o transformare; o valoare prezentă în evenimentul indexat dar absentă din panou indică extragerea sau interogarea.

Această ordine contează deoarece fiecare etapă ulterioară poate doar pierde informație, niciodată să o restaureze. O expresie regulată nu poate recupera un șir pe care o etapă anterioară l-a înlocuit cu un substituent, iar o setare de confidențialitate nu poate explica o valoare care nu a fost niciodată trimisă.

Mascarea la sursă este politică, nu un defect al parserului

Documentația de jurnalizare ASA de la Cisco descrie ascunderea numelui de utilizator ca un comportament configurabil, inclusiv modul în care sunt reprezentate numele de utilizator invalide sau necunoscute. O identitate mascată în evenimentul sursă poate fi deci exact ceea ce cere politica de confidențialitate, iar tratarea ei ca o eroare de analiză duce la o cerere care slăbește controlul.

Reprezentarea exactă depinde de versiune și de tipul mesajului. Un eveniment poate purta un substituent, altul poate omite complet câmpul, iar o eroare de autentificare poate să nu includă niciodată un nume. Verificați comportamentul documentat pentru evenimentul concret în loc să aplicați un raport de eroare vechi fiecărei identități lipsă.

Când mascarea este intenționată, întrebarea se schimbă de la cum să restaurăm câmpul la dacă cerința de audit poate fi îndeplinită altfel. Identificatorii de sesiune, o mapare controlată a identităților deținută de un grup mai mic sau un flux de evenimente autorizat mai îngust satisfac adesea nevoia fără a pune fiecare nume de utilizator încercat în fața fiecărui cititor de jurnale.

Anonimizarea înainte de indexare nu poate fi anulată

Documentația Splunk despre procesarea evenimentelor descrie anonimizarea prin expresii sed și transformări care rescriu sau elimină date înainte de indexare. Exact această plasare este ideea: evenimentul brut este modificat la intrare, așa că o extragere din momentul căutării nu mai are ce găsi.

Redactarea la indexare și extragerea câmpurilor la căutare rezolvă probleme diferite. Redactarea limitează cine poate vedea vreodată valoarea; extragerea decide doar ce nume folosește interogarea. Hashingul este o opțiune intermediară care păstrează corelația, dar un hash stabil pe un spațiu mic de nume de utilizator rămâne identificator când cineva poate testa nume candidate împotriva lui.

Dacă evenimentul stocat conține încă identitatea, problema este mai departe: tipul sursei, despărțirea liniilor, tratarea delimitatorilor, aliasurile de câmp sau interogarea însăși. Sunt reparații obișnuite de analiză și nu ating granița de confidențialitate.

Alegeți remedierea care corespunde graniței

Trei condiții decid răspunsul. În primul rând, politica de confidențialitate intenționează să excludă identitatea? În al doilea rând, procesul de audit sau de investigație are nevoie de identitate, de un pseudonim sau doar de sesiune? În al treilea rând, la ce graniță este necesară valoarea — colectare, stocare sau prezentare?

Dacă politica intenționează excluderea, schimbați cerința sau prezentarea, nu controlul. Dacă politica permite identitatea dar colectarea o pierde, reparați colectorul și confirmați evenimentul brut. Dacă stocarea este intactă, reparați extragerea și testați-o pe evenimentul aprobat pe care l-ați capturat la început.

Încheiați investigația numind granița în registrul de modificări: mascată la sursă, eliminată în timpul ingestiei sau ratată de extragere. Acea singură frază îi spune următorului inginer unde să se uite mai întâi și împiedică o plângere despre panou să devină o funcție de confidențialitate dezactivată în tăcere.