Къде изчезва потребителското име на VPN от конвейера на журнала?

Сесиите се показват в таблото, докато колоната с потребителско име остава празна и първият импулс е да обвиним парсера. Този импулс пропуска три по-ранни етапа, където стойността може да е била изгубена. Шлюзът може да маскира самоличност по политика, правило за прием може да я изтрие преди индексиране, а извличане при търсене може просто да не я назове. Поправката зависи от това коя граница можете да докажете като отговорна, затова полезната работа е сравнение, а не конфигурация.

Започнете от едно събитие, а не от таблото

Изберете едно събитие за удостоверяване и запишете какво го идентифицира: моделът и версията на шлюза, методът за удостоверяване, идентификаторът на събитието, времевата марка и адресът на източника. Добавете потребителското име точно както го е въвел човекът, включително регистъра, защото търсене, чувствително към регистъра, може да скрие поле, което присъства. Приемайте това събитие за ориентир при всяко следващо сравнение.

Типовете събития не споделят една схема. Неуспешен опит, успешен вход без клиент и повторно свързване на тунел могат да дадат различни полета, а някои шлюзове пропускат самоличността, когато опитът не е стигнал до удостоверяване на потребителя. Затова празна колона при един тип събитие е слабо доказателство за проблем в конвейера.

Работете с одобрена тестова самоличност, а не с реален служебен акаунт, и дръжте сравнението в рамките на правилата за достъп, които вече управляват данните от журнала. Широкото включване на подробно журналиране на удостоверяването само за да получите образец променя системата, която се опитвате да измерите.

Сравнете четирите граници по ред

Стойността може да изчезне в една от четири точки. Всяка точка има различен собственик и различна поправка.

Спрете на първата граница, където стойността изчезва. Несъответствие между изгледа на устройството и суровото копие сочи към транспорт или конфигурация на колектора; съвпадение там, но липсваща стойност в индексираното събитие сочи към трансформация; стойност, налична в индексираното събитие, но липсваща в таблото, сочи към извличане или заявка.

Този ред е важен, защото всеки следващ етап може само да губи информация и никога да я възстановява. Регулярен израз не може да върне низ, който по-ранен етап е заменил с контейнер, а настройка за поверителност не може да обясни стойност, която никога не е била изпратена.

Маскирането в източника е политика, а не дефект на парсера

Документацията за журналиране на ASA на Cisco описва скриването на потребителско име като конфигурируемо поведение, включително как се представят невалидни или неизвестни имена. Затова маскирана самоличност в изходното събитие може да е точно това, което изисква политиката за поверителност, а третирането ѝ като грешка при анализ води до заявка, която отслабва контрола.

Точното представяне зависи от версията и типа съобщение. Едно събитие може да носи контейнер, друго може да пропусне полето изцяло, а неуспех при удостоверяване може никога да не включва име. Проверете документираното поведение за конкретното събитие, вместо да прилагате стар доклад за дефект към всяка липсваща самоличност.

Когато маскирането е умишлено, въпросът се променя от това как да възстановим полето към това дали изискването за одит може да бъде изпълнено по друг начин. Идентификатори на сесия, контролирано съпоставяне на самоличности, поддържано от по-малка група, или по-тесен разрешен поток от събития често задоволяват нуждата, без да поставят всяко опитано потребителско име пред всеки читател на журнала.

Анонимизирането преди индексиране не може да се отмени

Документацията на Splunk за обработка на събития описва анонимизиране чрез изрази на sed и трансформации, които пренаписват или премахват данни преди индексиране. Точно мястото е важното: суровото събитие се променя при влизане, така че извличането при търсене не остава нищо за намиране.

Редакцията при индексиране и извличането на полета при търсене решават различни проблеми. Редакцията ограничава кой изобщо може да види стойността; извличането само решава кое име използва заявката. Хеширането е междинен вариант, който запазва корелация, но стабилен хеш върху малко пространство от потребителски имена все още идентифицира, когато някой може да тества кандидат-имена срещу него.

Ако съхраненото събитие все още съдържа самоличността, проблемът е надолу по веригата: тип източник, разкъсване на редове, обработка на разделители, псевдоними на полета или самата заявка. Това са обикновени поправки при анализ и те не засягат границата на поверителност.

Изберете поправката, която отговаря на границата

Три условия определят отговора. Първо, предвижда ли политиката за поверителност изключване на самоличността? Второ, нужен ли е на процеса по одит или разследване самата самоличност, псевдоним или само сесията? Трето, на коя граница е нужна стойността — събиране, съхранение или представяне?

Ако политиката предвижда изключване, променете изискването или представянето, а не контрола. Ако политиката позволява самоличността, но събирането я губи, поправете колектора и потвърдете суровото събитие. Ако съхранението е непокътнато, поправете извличането и го тествайте срещу одобреното събитие, което сте записали в началото.

Затворете разследването, като назовете границата в записа за промяна: маскирана в източника, премахната при приема или пропусната от извличането. Това едно изречение казва на следващия инженер къде да гледа първо и не позволява оплакване от таблото да се превърне в тихо изключена функция за поверителност.