Hvor forsvinner et VPN-brukernavn fra loggpipelinen?

Økter vises i dashbordet mens brukernavnkolonnen står tom, og den første impulsen er å skylde på parseren. Den impulsen hopper over tre tidligere trinn der verdien kan ha blitt borte. En gateway kan maskere en identitet etter policy, en inntaksregel kan slette den før indeksering, og en uthenting ved søk kan rett og slett unnlate å navngi den. Rettelsen avhenger av hvilken grense du kan bevise er ansvarlig, så det nyttige arbeidet er sammenligning fremfor konfigurasjon.

Start med én hendelse, ikke dashbordet

Velg én enkelt autentiseringshendelse og skriv ned hva som identifiserer den: gateway-modell og versjon, autentiseringsmetode, hendelsesidentifikator, tidsstempel og kildeadresse. Legg til brukernavnet nøyaktig slik personen skrev det, inkludert store og små bokstaver, fordi et søk som skiller mellom store og små bokstaver kan skjule et felt som finnes. Behandle den hendelsen som referanse for enhver senere sammenligning.

Hendelsestyper deler ikke samme skjema. Et mislykket forsøk, en vellykket innlogging uten klient og en gjentilkobling av tunnelen kan hver gi ulike felt, og noen gatewayer utelater identiteten når forsøket aldri nådde brukerautentisering. En tom kolonne på én hendelsestype er derfor svakt bevis for et pipeline-problem.

Arbeid med en godkjent testidentitet i stedet for en ekte ansattkonto, og hold sammenligningen innenfor tilgangsreglene som allerede gjelder for loggdataene. Å slå på omfattende detaljert autentiseringslogging bare for å få en prøve endrer systemet du prøver å måle.

Sammenlign de fire grensene i rekkefølge

Verdien kan forsvinne på ett av fire punkter. Hvert punkt har en annen eier og en annen rettelse.

Stopp ved den første grensen der verdien forsvinner. Avvik mellom enhetsvisningen og den rå kopien peker på transport eller innsamlerkonfigurasjon; samsvar der, men en manglende verdi i den indekserte hendelsen peker på en transformasjon; en verdi som finnes i den indekserte hendelsen men mangler i dashbordet peker på uthenting eller spørringen.

Denne rekkefølgen betyr noe fordi hvert senere trinn bare kan miste informasjon, aldri gjenopprette den. Et regulært uttrykk kan ikke gjenopprette en streng som et tidligere trinn erstattet med en plassholder, og en personverninnstilling kan ikke forklare en verdi som aldri ble sendt.

Maskering ved kilden er policy, ikke en parserfeil

Ciscos dokumentasjon om ASA-logging beskriver skjuling av brukernavn som atferd som kan konfigureres, inkludert hvordan ugyldige eller ukjente brukernavn vises. En maskert identitet i kildehendelsen kan derfor være nøyaktig det personvernpolicyen krever, og å behandle den som en parsingsfeil fører til en forespørsel som svekker kontrollen.

Den nøyaktige representasjonen avhenger av versjonen og meldingstypen. Én hendelse kan bære en plassholder, en annen kan utelate feltet helt, og en autentiseringsfeil kan aldri inneholde et navn. Kontroller den dokumenterte atferden for den konkrete hendelsen i stedet for å bruke en gammel feilrapport på enhver manglende identitet.

Når maskeringen er tilsiktet, endres spørsmålet fra hvordan feltet gjenopprettes til om revisjonskravet kan oppfylles på en annen måte. Sesjonsidentifikatorer, en kontrollert identitetstilordning hos en mindre gruppe eller en snevrere autorisert hendelsesstrøm oppfyller ofte behovet uten å sette hvert forsøkte brukernavn foran enhver loggleser.

Anonymisering før indeksering kan ikke angres

Splunks dokumentasjon om hendelsesbehandling beskriver anonymisering gjennom sed-uttrykk og transformasjoner som skriver om eller fjerner data før de indekseres. Nettopp plasseringen er poenget: den rå hendelsen endres på vei inn, så en uthenting ved søk har ingenting igjen å finne.

Redigering ved indeksering og feltuthenting ved søk løser forskjellige problemer. Redigering begrenser hvem som i det hele tatt kan se verdien; uthenting avgjør bare hvilket navn spørringen bruker. Hasjing er et mellomvalg som bevarer korrelasjon, men en stabil hash over et lite brukernavnrom er fortsatt identifiserende når noen kan teste kandidatnavn mot den.

Hvis den lagrede hendelsen fortsatt inneholder identiteten, ligger problemet lenger ned: kildetype, linjebryting, håndtering av skilletegn, feltaliaser eller selve spørringen. Det er vanlige parsingsrettelser, og de berører ikke personverngrensen.

Velg rettelsen som passer til grensen

Tre betingelser avgjør svaret. For det første, har personvernpolicyen til hensikt å utelukke identiteten? For det andre, trenger revisjons- eller undersøkelsesprosessen identiteten, et pseudonym eller bare økten? For det tredje, ved hvilken grense trengs verdien — innsamling, lagring eller presentasjon?

Hvis policyen har til hensikt å utelukke, endre kravet eller presentasjonen, ikke kontrollen. Hvis policyen tillater identiteten men innsamlingen mister den, reparer innsamleren og bekreft den rå hendelsen. Hvis lagringen er intakt, reparer uthentingen og test den mot den godkjente hendelsen du fanget i starten.

Avslutt undersøkelsen ved å navngi grensen i endringsloggen: maskert ved kilden, fjernet under inntak eller oversett av uthentingen. Den ene setningen forteller neste ingeniør hvor de skal se først, og den hindrer at en dashbordklage blir en stille deaktivert personvernfunksjon.