Var försvinner ett VPN-användarnamn ur loggpipelinen?
Jämför gateway-händelsen, insamlarens råa kopia, den indexerade händelsen och fältet vid sökning innan du ändrar en sekretessinställning för loggar.
Sessioner visas i instrumentpanelen medan kolumnen för användarnamn står tom, och den första impulsen är att skylla på parsern. Den impulsen hoppar över tre tidigare steg där värdet kan ha gått förlorat. En gateway kan maskera en identitet enligt policy, en inmatningsregel kan radera den före indexering, och ett uttag vid sökning kan helt enkelt misslyckas med att namnge den. Rättelsen beror på vilken gräns du kan bevisa är ansvarig, så det nyttiga arbetet är jämförelse snarare än konfiguration.
Börja med en händelse, inte instrumentpanelen
Välj en enda autentiseringshändelse och skriv ned vad som identifierar den: gateway-modell och version, autentiseringsmetod, händelseidentifierare, tidsstämpel och källadress. Lägg till användarnamnet exakt som personen skrev det, inklusive versaler och gemener, eftersom en sökning som skiljer på skiftläge kan dölja ett fält som finns. Behandla händelsen som referens för varje senare jämförelse.
Händelsetyper delar inte samma schema. Ett misslyckat försök, en lyckad inloggning utan klient och en återanslutning av tunneln kan var och en ge olika fält, och vissa gateways utelämnar identiteten när försöket aldrig nådde användarautentisering. En tom kolumn för en händelsetyp är därför svagt bevis för ett pipeline-problem.
Arbeta med en godkänd testidentitet i stället för ett riktigt medarbetarkonto, och håll jämförelsen inom de åtkomstregler som redan gäller för loggdata. Att brett slå på utförlig autentiseringsloggning bara för att få ett prov ändrar systemet du försöker mäta.
Jämför de fyra gränserna i ordning
Värdet kan försvinna vid en av fyra punkter. Varje punkt har en annan ägare och en annan åtgärd.
| 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 |
Stanna vid den första gräns där värdet försvinner. Avvikelse mellan enhetens vy och den råa kopian pekar på transport eller insamlarkonfiguration; överensstämmelse där men ett saknat värde i den indexerade händelsen pekar på en transformering; ett värde som finns i den indexerade händelsen men saknas i instrumentpanelen pekar på uttaget eller frågan.
Den här ordningen spelar roll eftersom varje senare steg bara kan förlora information, aldrig återställa den. Ett reguljärt uttryck kan inte hämta tillbaka en sträng som ett tidigare steg ersatte med en platshållare, och en sekretessinställning kan inte förklara ett värde som aldrig skickades.
Maskering vid källan är policy, inte ett parserfel
Ciscos dokumentation om ASA-loggning beskriver döljande av användarnamn som ett konfigurerbart beteende, inklusive hur ogiltiga eller okända användarnamn visas. En maskerad identitet i källhändelsen kan därför vara precis det som sekretesspolicyn kräver, och att behandla det som ett parsningsfel leder till en begäran som försvagar kontrollen.
Den exakta representationen beror på versionen och meddelandetypen. En händelse kan bära en platshållare, en annan kan utelämna fältet helt, och ett autentiseringsfel kan aldrig innehålla ett namn. Kontrollera det dokumenterade beteendet för den specifika händelsen i stället för att tillämpa en gammal felrapport på varje saknad identitet.
När maskeringen är avsiktlig ändras frågan från hur fältet återställs till om revisionskravet kan uppfyllas på annat sätt. Sessionsidentifierare, en kontrollerad identitetsmappning hos en mindre grupp eller en snävare auktoriserad händelseström uppfyller ofta behovet utan att sätta varje försökt användarnamn framför varje loggläsare.
Anonymisering före indexering kan inte ångras
Splunks dokumentation om händelsebehandling beskriver anonymisering genom sed-uttryck och transformeringar som skriver om eller tar bort data före indexering. Just placeringen är poängen: den råa händelsen ändras på vägen in, så ett uttag vid sökning har inget kvar att hitta.
Redigering vid indexering och fältuttag vid sökning löser olika problem. Redigering begränsar vem som alls kan se värdet; uttaget avgör bara vilket namn frågan använder. Hashning är ett mellanting som bevarar korrelation, men en stabil hash över ett litet användarnamnrum är fortfarande identifierande när någon kan testa kandidatnamn mot den.
Om den lagrade händelsen fortfarande innehåller identiteten ligger problemet längre ned: källtyp, radbrytning, hantering av avgränsare, fältalias eller själva frågan. Det är vanliga parsningsreparationer och de rör inte sekretessgränsen.
Välj den åtgärd som passar gränsen
Tre villkor avgör svaret. För det första, avser sekretesspolicyn att utesluta identiteten? För det andra, behöver revisions- eller utredningsprocessen identiteten, en pseudonym eller bara sessionen? För det tredje, vid vilken gräns behövs värdet — insamling, lagring eller presentation?
Om policyn avser uteslutning, ändra kravet eller presentationen, inte kontrollen. Om policyn tillåter identiteten men insamlingen tappar den, reparera insamlaren och bekräfta den råa händelsen. Om lagringen är intakt, reparera uttaget och testa det mot den godkända händelse du fångade i början.
Avsluta utredningen genom att namnge gränsen i ändringsloggen: maskerad vid källan, borttagen vid inmatning eller missad av uttaget. Den enda meningen talar om för nästa ingenjör var de ska titta först, och den hindrar ett klagomål på instrumentpanelen från att bli en tyst inaktiverad sekretessfunktion.