Hvor forsvinder et VPN-brugernavn fra logpipelinen?

Sessioner vises på dashboardet, mens brugernavnskolonnen forbliver tom, og den første tilbøjelighed er at bebrejde parseren. Den tilbøjelighed springer tre tidligere trin over, hvor værdien kan være blevet tabt. En gateway kan maskere en identitet efter politik, en indtagsregel kan slette den før indeksering, og en udtrækning ved søgning kan ganske enkelt undlade at navngive den. Rettelsen afhænger af, hvilken grænse du kan bevise er ansvarlig, så det nyttige arbejde er sammenligning frem for konfiguration.

Start med én hændelse, ikke dashboardet

Vælg én enkelt godkendelseshændelse, og skriv ned, hvad der identificerer den: gatewayens model og version, godkendelsesmetoden, hændelsesidentifikatoren, tidsstemplet og kildeaddressen. Tilføj brugernavnet præcis som personen skrev det, inklusive store og små bogstaver, fordi en søgning, der skelner mellem store og små bogstaver, kan skjule et felt, der findes. Behandl den hændelse som reference for enhver senere sammenligning.

Hændelsestyper deler ikke samme skema. Et mislykket forsøg, et vellykket login uden klient og en genopkobling af tunnelen kan hver især give forskellige felter, og nogle gateways udelader identiteten, når forsøget aldrig nåede brugergodkendelse. En tom kolonne ved én hændelsestype er derfor svagt bevis for et pipelineproblem.

Arbejd med en godkendt testidentitet i stedet for en rigtig medarbejderkonto, og hold sammenligningen inden for de adgangsregler, der allerede styrer logdataene. At slå omfattende detaljeret godkendelseslogning til i bredden blot for at få en prøve ændrer det system, du forsøger at måle.

Sammenlign de fire grænser i rækkefølge

Værdien kan forsvinde ved et af fire punkter. Hvert punkt har en anden ejer og en anden rettelse.

Stop ved den første grænse, hvor værdien forsvinder. Uoverensstemmelse mellem enhedens visning og den rå kopi peger på transport eller collectorkonfiguration; overensstemmelse der, men en manglende værdi i den indekserede hændelse peger på en transformation; en værdi, der findes i den indekserede hændelse, men mangler på dashboardet, peger på udtrækning eller forespørgslen.

Denne rækkefølge betyder noget, fordi hvert senere trin kun kan tabe information, aldrig genskabe den. Et regulært udtryk kan ikke genskabe en streng, som et tidligere trin erstattede med en pladsholder, og en privatlivsindstilling kan ikke forklare en værdi, der aldrig blev sendt.

Maskering ved kilden er politik, ikke en parserfejl

Ciscos dokumentation om ASA-logning beskriver skjul af brugernavne som en konfigurerbar adfærd, herunder hvordan ugyldige eller ukendte brugernavne vises. En maskeret identitet i kildehændelsen kan derfor være præcis det, privatlivspolitikken kræver, og at behandle den som en parsingfejl fører til en anmodning, der svækker kontrollen.

Den præcise repræsentation afhænger af versionen og meddelelsestypen. Én hændelse kan bære en pladsholder, en anden kan udelade feltet helt, og en godkendelsesfejl kan aldrig indeholde et navn. Kontroller den dokumenterede adfærd for den konkrete hændelse i stedet for at anvende en gammel fejlrapport på enhver manglende identitet.

Når maskering er tilsigtet, ændres spørgsmålet fra, hvordan feltet genskabes, til, om revisionskravet kan opfyldes på en anden måde. Sessionsidentifikatorer, en kontrolleret identitetsmapping hos en mindre gruppe eller et snævrere autoriseret hændelsesfeed opfylder ofte behovet uden at sætte hvert forsøgt brugernavn foran enhver loglæser.

Anonymisering før indeksering kan ikke fortrydes

Splunks dokumentation om hændelsesbehandling beskriver anonymisering via sed-udtryk og transformationer, der omskriver eller fjerner data, før de indekseres. Netop placeringen er pointen: den rå hændelse ændres på vej ind, så en udtrækning ved søgning ikke har noget tilbage at finde.

Redaktion ved indeksering og feltudtræk ved søgning løser forskellige problemer. Redaktion begrænser, hvem der overhovedet kan se værdien; udtrækning afgør kun, hvilket navn forespørgslen bruger. Hashing er en mellemvej, der bevarer korrelation, men en stabil hash over et lille brugernavnrum er stadig identificerende, når nogen kan teste kandidatnavne mod den.

Hvis den gemte hændelse stadig indeholder identiteten, ligger problemet længere nede: kildetype, linjebrydning, håndtering af afgrænsere, feltaliaser eller selve forespørgslen. Det er almindelige parsingrettelser, og de rører ikke privatlivsgrænsen.

Vælg den rettelse, der passer til grænsen

Tre betingelser afgør svaret. For det første, har privatlivspolitikken til hensigt at udelukke identiteten? For det andet, har revisions- eller undersøgelsesprocessen brug for identiteten, et pseudonym eller kun sessionen? For det tredje, ved hvilken grænse er værdien nødvendig — indsamling, lagring eller præsentation?

Hvis politikken tilsigter udelukkelse, ændr kravet eller præsentationen, ikke kontrollen. Hvis politikken tillader identiteten, men indsamlingen taber den, ret collectoren og bekræft den rå hændelse. Hvis lagringen er intakt, ret udtrækningen, og test den mod den godkendte hændelse, du fangede i starten.

Afslut undersøgelsen ved at navngive grænsen i ændringsregistret: maskeret ved kilden, fjernet under indtag eller overset af udtrækningen. Den ene sætning fortæller den næste ingeniør, hvor der skal kigges først, og den forhindrer, at en dashboardklage bliver til en stille deaktiveret privatlivsfunktion.