Waar verdwijnt een VPN-gebruikersnaam uit de logpijplijn?

Sessies verschijnen op het dashboard terwijl de kolom voor de gebruikersnaam leeg blijft, en de eerste neiging is de parser de schuld te geven. Die neiging slaat drie eerdere fasen over waarin de waarde verloren kan zijn gegaan. Een gateway kan een identiteit volgens beleid maskeren, een opnameregel kan die vóór indexering verwijderen, en een extractie tijdens het zoeken kan eenvoudigweg nalaten die te benoemen. De oplossing hangt af van welke grens u als verantwoordelijk kunt aantonen, dus het nuttige werk is vergelijken en niet configureren.

Begin bij één gebeurtenis, niet bij het dashboard

Kies één authenticatiegebeurtenis en schrijf op wat die identificeert: het model en de versie van de gateway, de authenticatiemethode, de gebeurtenisidentificatie, de tijdstempel en het bronadres. Voeg de gebruikersnaam precies toe zoals de persoon die heeft getypt, inclusief hoofdletters en kleine letters, omdat een zoekopdracht die hoofdlettergevoelig is een veld kan verbergen dat er wel is. Behandel die gebeurtenis als referentie voor elke latere vergelijking.

Gebeurtenistypen delen niet hetzelfde schema. Een mislukte poging, een geslaagde aanmelding zonder client en een herverbinding van de tunnel kunnen elk andere velden opleveren, en sommige gateways laten de identiteit weg wanneer de poging nooit de gebruikersauthenticatie heeft bereikt. Een lege kolom bij één gebeurtenistype is daarom zwak bewijs voor een probleem in de pijplijn.

Werk met een goedgekeurde testidentiteit in plaats van een echt werknemersaccount, en houd de vergelijking binnen de toegangsregels die al voor de loggegevens gelden. Uitgebreide gedetailleerde authenticatielogging breed inschakelen alleen om een voorbeeld te krijgen, verandert het systeem dat u probeert te meten.

Vergelijk de vier grenzen in volgorde

De waarde kan op een van vier punten verdwijnen. Elk punt heeft een andere eigenaar en een andere oplossing.

Stop bij de eerste grens waar de waarde verdwijnt. Een verschil tussen de weergave van het apparaat en de ruwe kopie wijst op transport of configuratie van de collector; overeenstemming daar maar een ontbrekende waarde in de geïndexeerde gebeurtenis wijst op een transformatie; een waarde die in de geïndexeerde gebeurtenis staat maar op het dashboard ontbreekt, wijst op extractie of de zoekopdracht.

Deze volgorde is belangrijk omdat elke latere fase alleen informatie kan verliezen en die nooit kan herstellen. Een reguliere expressie kan een tekenreeks niet terughalen die een eerdere fase door een plaatsaanduiding heeft vervangen, en een privacyinstelling kan een waarde niet verklaren die nooit is verzonden.

Maskeren bij de bron is beleid, geen parserfout

Cisco’s documentatie over ASA-logging beschrijft het verbergen van gebruikersnamen als configureerbaar gedrag, inclusief hoe ongeldige of onbekende gebruikersnamen worden weergegeven. Een gemaskeerde identiteit in de brongebeurtenis kan dus precies zijn wat het privacybeleid vereist, en die als een parserfout behandelen leidt tot een verzoek dat de controle verzwakt.

De exacte weergave hangt af van de versie en het berichttype. De ene gebeurtenis kan een plaatsaanduiding bevatten, een andere kan het veld helemaal weglaten, en een authenticatiefout bevat mogelijk nooit een naam. Controleer het gedocumenteerde gedrag voor de specifieke gebeurtenis in plaats van een oud bugrapport toe te passen op elke ontbrekende identiteit.

Wanneer maskering opzettelijk is, verandert de vraag van hoe het veld te herstellen naar of aan de auditvereiste op een andere manier kan worden voldaan. Sessie-identificaties, een beheerste identiteitstoewijzing bij een kleinere groep of een smallere geautoriseerde gebeurtenisstroom voldoen vaak aan de behoefte zonder elke geprobeerde gebruikersnaam voor elke loglezer te zetten.

Anonimisering vóór indexering is onomkeerbaar

De documentatie van Splunk over gebeurtenisverwerking beschrijft anonimisering via sed-expressies en transformaties die gegevens herschrijven of verwijderen voordat ze worden geïndexeerd. Juist die plaats is het punt: de ruwe gebeurtenis wordt bij binnenkomst gewijzigd, dus een extractie tijdens het zoeken heeft niets meer te vinden.

Redactie tijdens het indexeren en veldextractie tijdens het zoeken lossen verschillende problemen op. Redactie beperkt wie de waarde ooit kan zien; extractie bepaalt alleen welke naam de zoekopdracht gebruikt. Hashen is een tussenoptie die correlatie behoudt, maar een stabiele hash over een kleine gebruikersnaamruimte is nog steeds identificerend wanneer iemand kandidaatnamen ertegen kan testen.

Als de opgeslagen gebeurtenis de identiteit nog bevat, ligt het probleem stroomafwaarts: brontype, regelafbreking, verwerking van scheidingstekens, veldaliasen of de zoekopdracht zelf. Dat zijn gewone reparaties aan het parseren en ze raken de privacygrens niet.

Kies de oplossing die bij de grens past

Drie voorwaarden bepalen de reactie. Ten eerste, wil het privacybeleid de identiteit uitsluiten? Ten tweede, heeft het audit- of onderzoeksproces de identiteit, een pseudoniem of alleen de sessie nodig? Ten derde, bij welke grens is de waarde nodig — verzameling, opslag of weergave?

Als het beleid uitsluiting beoogt, wijzig dan de vereiste of de weergave, niet de controle. Als het beleid de identiteit toestaat maar de verzameling die laat vallen, repareer de collector en bevestig de ruwe gebeurtenis. Als de opslag intact is, repareer de extractie en test die tegen de goedgekeurde gebeurtenis die u aan het begin hebt vastgelegd.

Sluit het onderzoek af door de grens in het wijzigingsrecord te benoemen: gemaskeerd bij de bron, verwijderd tijdens de opname of gemist door de extractie. Die ene zin vertelt de volgende engineer waar die eerst moet kijken, en voorkomt dat een dashboardklacht verandert in een stilzwijgend uitgeschakelde privacyfunctie.