Каде исчезнува корисничкото име на VPN од текот на дневниците?

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

Започнете од еден настан, а не од контролната табла

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

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

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

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

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

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

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

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

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

Точниот приказ зависи од изданието и типот на пораката. Еден настан може да носи заменски знак, друг може целосно да го испушти полето, а неуспехот при автентикација може никогаш да не содржи име. Проверете го документираното однесување за конкретниот настан наместо да применувате стар извештај за грешка на секој отсутен идентитет.

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

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

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

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

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

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

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

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

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