Где нестаје корисничко име VPN из тока дневника?

Сесије се појављују на контролној табли док колона корисничког имена остаје празна, а први импулс је окривити парсер. Тај импулс прескаче три раније фазе у којима је вредност могла бити изгубљена. Пролаз може маскирати идентитет по политици, правило уноса може га избрисати пре индексирања, а издвајање при претрази може једноставно не успети да га именује. Поправка зависи од тога коју границу можете доказати као одговорну, зато је користан посао поређење, а не конфигурација.

Почните од једног догађаја, а не од контролне табле

Изаберите један догађај аутентификације и запишите шта га идентификује: модел и издање пролаза, метод аутентификације, идентификатор догађаја, временску ознаку и адресу извора. Додајте корисничко име тачно онако како га је особа унела, укључујући велика и мала слова, јер претрага осетљива на слова може сакрити поље које постоји. Третирајте тај догађај као референцу за свако касније поређење.

Типови догађаја не деле исту шему. Неуспешан покушај, успешна пријава без клијента и поновно повезивање тунела могу дати различита поља, а неки пролази изостављају идентитет када покушај никада није стигао до аутентификације корисника. Зато је празан стубац код једне врсте догађаја слаб доказ проблема у току.

Радите са одобреним тест идентитетом уместо са стварним налогом запосленог и држите поређење у оквиру правила приступа која већ уређују податке дневника. Широко укључивање детаљног евидентирања аутентификације само да бисте добили узорак мења систем који покушавате да измерите.

Упоредите четири границе по реду

Вредност може нестати на једној од четири тачке. Свака тачка има другог власника и другу поправку.

Зауставите се на првој граници на којој вредност нестаје. Неслагање између приказа уређаја и сирове копије указује на транспорт или конфигурацију сакупљача; поклапање тамо, али вредност која недостаје у индексираном догађају указује на трансформацију; вредност присутна у индексираном догађају, али одсутна на контролној табли указује на издвајање или упит.

Овај редослед је важан јер свака каснија фаза може само да изгуби информацију и никада да је поврати. Регуларни израз не може да врати низ који је ранија фаза заменила заменским знаком, а подешавање приватности не може да објасни вредност која никада није послата.

Маскирање на извору је политика, не грешка парсера

Документација компаније Cisco о евидентирању ASA описује скривање корисничког имена као подесиво понашање, укључујући како се приказују неважећа или непозната корисничка имена. Зато маскирани идентитет у изворном догађају може бити управо оно што политика приватности захтева, а третирање тога као грешке при парсирању води ка захтеву који слаби контролу.

Тачан приказ зависи од издања и типа поруке. Један догађај може носити заменски знак, други може потпуно изоставити поље, а неуспех аутентификације можда никада неће садржати име. Проверите документовано понашање за конкретан догађај уместо да примењујете стари извештај о грешци на сваки недостајући идентитет.

Када је маскирање намерно, питање се мења од тога како вратити поље на то да ли се захтев за ревизију може испунити на други начин. Идентификатори сесије, контролисано мапирање идентитета које држи мања група или ужи овлашћени ток догађаја често задовољавају потребу без излагања сваког покушајем обухваћеног корисничког имена сваком читаоцу дневника.

Анонимизација пре индексирања не може се опозвати

Документација компаније Splunk о обради догађаја описује анонимизацију кроз sed изразе и трансформације које преписују или уклањају податке пре индексирања. Управо је то место поента: сирови догађај се мења при улазу, па издвајање при претрази нема више шта да пронађе.

Редакција при индексирању и издвајање поља при претрази решавају различите проблеме. Редакција ограничава ко уопште може да види вредност; издвајање само одлучује које име упит користи. Хеширање је средња опција која чува корелацију, али стабилан хеш над малим простором корисничких имена и даље идентификује када неко може да тестира кандидатска имена против њега.

Ако сачувани догађај још садржи идентитет, проблем је даље: тип извора, раздвајање редова, руковање раздвајачима, псеудоними поља или сам упит. То су уобичајене поправке при парсирању и не дотичу границу приватности.

Изаберите поправку која одговара граници

Три услова одређују одговор. Прво, да ли политика приватности намерава да искључи идентитет? Друго, да ли процесу ревизије или истраге треба идентитет, псеудоним или само сесија? Треће, на којој граници је вредност потребна — прикупљање, чување или приказ?

Ако политика намерава да искључи, промените захтев или приказ, а не контролу. Ако политика дозвољава идентитет, али прикупљање га губи, поправите сакупљач и потврдите сирови догађај. Ако је чување нетакнуто, поправите издвајање и тестирајте га на одобреном догађају који сте забележили на почетку.

Затворите истрагу именовањем границе у запису о промени: маскиран на извору, уклоњен при уносу или пропуштен од издвајања. Та једна реченица каже следећем инжењеру где прво да погледа и спречава да се жалба на контролну таблу претвори у тихо искључену функцију приватности.