Waar verdwyn ’n VPN-gebruikersnaam uit die logpyplyn?

Sessies verskyn op die paneelbord terwyl die gebruikersnaamkolom leeg bly, en die eerste instink is om die ontleder te blameer. Daardie instink slaan drie vroeëre stadiums oor waar die waarde kon verlore gegaan het. ’n Gateway kan ’n identiteit per beleid maskeer, ’n inname-reël kan dit voor indeksering verwyder, en ’n soektyd-onttrekking kan bloot versuim om dit te benoem. Die regstelling hang daarvan af watter grens jy kan bewys verantwoordelik is, so die nuttige werk is vergelyking eerder as konfigurasie.

Begin by een gebeurtenis, nie die paneelbord nie

Kies ’n enkele verifikasie-gebeurtenis en skryf neer wat dit identifiseer: die gateway-model en vrystelling, die verifikasiemetode, die gebeurtenis-identifiseerder, die tydstempel en die bronadres. Voeg die gebruikersnaam presies by soos die persoon dit getik het, insluitend hoofletters, want ’n hooflettergevoelige soektog kan ’n veld verberg wat wel daar is. Behandel daardie gebeurtenis as die verwysing vir elke latere vergelyking.

Gebeurtenistipes deel nie ’n skema nie. ’n Mislukte poging, ’n suksesvolle kliëntlose aanmelding en ’n tonnel-herverbinding kan elk verskillende velde lewer, en sommige gateways laat die identiteit weg wanneer die poging nooit gebruikersverifikasie bereik het nie. ’n Leë kolom op een gebeurtenistipe is dus swak bewyse van ’n pyplynprobleem.

Werk met ’n goedgekeurde toetsidentiteit eerder as ’n regte werknemerrekening, en hou die vergelyking binne die toegangsreëls wat reeds die logdata beheer. Om breedvoerige verifikasielogging wyd te aktiveer net om ’n monster te kry, verander die stelsel wat jy probeer meet.

Vergelyk die vier grense in volgorde

Die waarde kan by een van vier punte verdwyn. Elke punt het ’n ander eienaar en ’n ander herstel.

Stop by die eerste grens waar die waarde verdwyn. ’n Verskil tussen die toestel-aansig en die rou kopie dui op vervoer- of versamelaarkonfigurasie; ’n ooreenstemming daar maar ’n ontbrekende waarde in die geïndekseerde gebeurtenis dui op ’n transformasie; ’n waarde wat in die geïndekseerde gebeurtenis teenwoordig is maar op die paneelbord ontbreek, dui op onttrekking of die navraag.

Hierdie volgorde maak saak omdat elke latere stadium slegs inligting kan verloor, nooit herstel nie. ’n Regex kan nie ’n string terugkry wat ’n vroeëre stadium met ’n plekhouer vervang het nie, en ’n privaatheidinstelling kan nie ’n waarde verklaar wat nooit gestuur is nie.

Maskering by die bron is beleid, nie ’n ontlederfout nie

Cisco se ASA-logdokumentasie beskryf die wegsteek van gebruikersname as ’n konfigureerbare gedrag, insluitend hoe ongeldige of onbekende gebruikersname voorgestel word. ’n Gemaskeerde identiteit in die brongebeurtenis kan dus presies wees wat die privaatheidsbeleid vereis, en om dit as ’n ontledingsfout te behandel lei tot ’n versoek wat die beheer verswak.

Die presiese voorstelling hang af van die vrystelling en die boodskaptipe. Een gebeurtenis kan ’n plekhouer dra, ’n ander kan die veld heeltemal weglaat, en ’n verifikasiefout kan nooit ’n naam insluit nie. Kontroleer die gedokumenteerde gedrag vir die spesifieke gebeurtenis eerder as om ’n historiese foutverslag op elke ontbrekende identiteit toe te pas.

Wanneer maskering opsetlik is, verander die vraag van hoe om die veld te herstel na of die ouditvereiste op ’n ander manier nagekom kan word. Sessie-identifiseerders, ’n beheerde identiteitstoewysing wat deur ’n kleiner groep gehou word, of ’n nouer gemagtigde gebeurtenisstroom bevredig dikwels die behoefte sonder om elke gepoogde gebruikersnaam voor elke logleser te plaas.

Anonimisering voor indeksering kan nie ongedaan gemaak word nie

Splunk se dokumentasie oor gebeurtenisverwerking beskryf anonimisering deur sed-uitdrukkings en transformasies wat data herskryf of verwyder voordat dit geïndekseer word. Daardie plasing is die punt: die rou gebeurtenis word op pad in verander, so ’n soektyd-onttrekking het niks oor om te vind nie.

Indekstyd-redaksie en soektyd-veldonttrekking los verskillende probleme op. Redaksie beperk wie die waarde ooit kan sien; onttrekking besluit net watter naam die navraag gebruik. Hashing is ’n middelopsie wat korrelasie bewaar, maar ’n stabiele hash oor ’n klein gebruikersnaamruimte is steeds identifiserend wanneer iemand kandidaatname daarteen kan toets.

As die gestoorde gebeurtenis steeds die identiteit bevat, is die probleem stroomaf: brontipe, reëlbreek, skeidingstekenhantering, veldaliase of die navraag self. Dit is gewone ontledingsherstelwerk en dit raak nie die privaatheidsgrens nie.

Kies die regstelling wat by die grens pas

Drie voorwaardes bepaal die reaksie. Eerstens, beoog die privaatheidsbeleid om die identiteit uit te sluit? Tweedens, het die oudit- of ondersoekproses die identiteit, ’n skuilnaam of slegs die sessie nodig? Derdens, by watter grens is die waarde nodig — versameling, stoor of aanbieding?

As beleid uitsluiting beoog, verander die vereiste of die aanbieding, nie die beheer nie. As beleid die identiteit toelaat maar versameling dit laat val, herstel die versamelaar en bevestig die rou gebeurtenis. As die stoor intact is, herstel die onttrekking en toets dit teen die goedgekeurde gebeurtenis wat jy aan die begin vasgelê het.

Sluit die ondersoek af deur die grens in die veranderingsrekord te noem: by die bron gemaskeer, tydens inname verwyder, of deur onttrekking gemis. Daardie een sin sê vir die volgende ingenieur waar om eerste te kyk, en dit keer dat ’n paneelbordklagte in ’n stilweg gedeaktiveerde privaatheidsfunksie verander.