Kvar forsvinn eit VPN-brukarnamn frå loggpipelinen?
Samanlikn gateway-hendinga, den rå kopien frå innsamlararen, den indekserte hendinga og feltet ved søk før du endrar ein personverninnstilling for loggar.
Økter viser seg i dashbordet medan brukarnamnkolonnen står tom, og den første impulsen er å skylde på parsaren. Den impulsen hoppar over tre tidlegare trinn der verdien kan ha blitt borte. Ein gateway kan maskere ein identitet etter policy, ein inntaksregel kan slette han før indeksering, og ein uthenting ved søk kan rett og slett la vere å namngje han. Rettinga avheng av kva grense du kan prove er ansvarleg, så det nyttige arbeidet er samanlikning framfor konfigurasjon.
Start med éi hending, ikkje dashbordet
Vel éi einskild autentiseringshending og skriv ned kva som identifiserer ho: gateway-modell og versjon, autentiseringsmetode, hendingsidentifikator, tidsstempel og kjeldeadresse. Legg til brukarnamnet nøyaktig slik personen skreiv det, inkludert store og små bokstavar, fordi eit søk som skil mellom store og små bokstavar kan skjule eit felt som finst. Behandle den hendinga som referanse for kvar seinare samanlikning.
Hendingstypar deler ikkje same skjema. Eit mislukka forsøk, ei vellukka innlogging utan klient og ein gjentilkopling av tunnelen kan kvar gje ulike felt, og nokre gatewayar utelèt identiteten når forsøket aldri nådde brukarautentisering. Ein tom kolonne på éin hendingstype er derfor svakt prov for eit pipeline-problem.
Arbeid med ein godkjend testidentitet i staden for ein ekte tilsettkonto, og hald samanlikninga innanfor tilgangsreglane som allereie gjeld for loggdataa. Å slå på omfattande detaljert autentiseringslogg berre for å få eit prov endrar systemet du prøver å måle.
Samanlikn dei fire grensene i rekkjefølgje
Verdien kan forsvinne på eitt av fire punkt. Kvart punkt har ein annan eigar og ei anna retting.
| Boundary | What to compare | A gap means |
|---|---|---|
| Gateway event view | The device's own event display and logging policy | The identity was masked or never emitted |
| Collector receive | The raw event as received, before parsing | Transport, filter or source selection dropped it |
| Index-time pipeline | Transforms applied before storage | Redaction or rewriting removed the value |
| Search-time extraction | The field name and regex used by the query | The label does not match the stored key |
Stopp ved den første grensa der verdien forsvinn. Avvik mellom eining-visninga og den rå kopien peikar på transport eller innsamlar-konfigurasjon; samsvar der, men ein manglande verdi i den indekserte hendinga peikar på ein transformasjon; ein verdi som finst i den indekserte hendinga men manglar i dashbordet peikar på uthenting eller spørjinga.
Denne rekkjefølgja har noko føre seg fordi kvart seinare trinn berre kan miste informasjon, aldri gjenopprette han. Eit regulært uttrykk kan ikkje gjenopprette ein streng som eit tidlegare trinn erstatta med ein plasshaldar, og ei personverninnstilling kan ikkje forklare ein verdi som aldri vart send.
Maskering ved kjelda er policy, ikkje ein parsarfeil
Ciscos dokumentasjon om ASA-logging skildrar skjuling av brukarnamn som åtferd som kan konfigurerast, inkludert korleis ugyldige eller ukjende brukarnamn vert viste. Ein maskert identitet i kjeldehendinga kan derfor vere nøyaktig det personvernpolicyen krev, og å handsame han som ein parsingsfeil fører til ein førespurnad som svekkjer kontrollen.
Den nøyaktige representasjonen avheng av versjonen og meldingstypen. Éi hending kan bere ein plasshaldar, ei anna kan utelate feltet heilt, og ein autentiseringsfeil kan aldri innehalde eit namn. Kontroller den dokumenterte åtferda for den konkrete hendinga i staden for å bruke ein gammal feilrapport på kvar manglande identitet.
Når maskeringa er tilsikta, endrar spørsmålet seg frå korleis feltet vert gjenoppretta til om revisjonskravet kan oppfyllast på ein annan måte. Sesjonsidentifikatorar, ein kontrollert identitetstilordning hos ei mindre gruppe eller ein snevrare autorisert hendingsstraum oppfyller ofte behovet utan å setje kvart forsøkte brukarnamn framfor kvar logglesar.
Anonymisering før indeksering kan ikkje angrast
Dokumentasjonen til Splunk om hendingshandsaming skildrar anonymisering gjennom sed-uttrykk og transformasjonar som skriv om eller fjernar data før dei vert indekserte. Nettopp plasseringa er poenget: den rå hendinga vert endra på veg inn, så ein uthenting ved søk har ingenting att å finne.
Redigering ved indeksering og feltuthenting ved søk løyser ulike problem. Redigering avgrensar kven som i det heile kan sjå verdien; uthenting avgjer berre kva namn spørjinga brukar. Hasjing er eit mellomval som bevarer korrelasjon, men ein stabil hash over eit lite brukarnamnrom er framleis identifiserande når nokon kan teste kandidatnamn mot han.
Viss den lagra hendinga framleis inneheld identiteten, ligg problemet lenger nede: kjelde type, linjebryting, handsaming av skiljeteikn, feltalias eller sjølve spørjinga. Det er vanlege parsingsrettingar, og dei rører ikkje personverngrensa.
Vel rettinga som passar til grensa
Tre vilkår avgjer svaret. For det første, har personvernpolicyen til hensikt å utelate identiteten? For det andre, treng revisjons- eller granskingsprosessen identiteten, eit pseudonym eller berre økta? For det tredje, ved kva grense trengst verdien — innsamling, lagring eller presentasjon?
Viss policyen har til hensikt å utelate, endre kravet eller presentasjonen, ikkje kontrollen. Viss policyen tillèt identiteten men innsamlinga mistar han, reparer innsamlararen og stadfest den rå hendinga. Viss lagringa er intakt, reparer uthentinga og test ho mot den godkjende hendinga du fanga i starten.
Avslutt granskinga ved å namngje grensa i endringsloggen: maskert ved kjelda, fjerna under inntak eller oversett av uthentinga. Den eine setninga fortel neste ingeniør kvar dei skal sjå først, og ho hindrar at ein dashbordklage vert ein stille deaktivert personvernfunksjon.