Де зникає ім’я користувача VPN з конвеєра журналів?

Сеанси з’являються на панелі, а стовпець імені користувача залишається порожнім, і перший порив — звинуватити аналізатор. Цей порив пропускає три ранніші етапи, де значення могло бути втрачене. Шлюз може маскувати ідентичність за політикою, правило приймання може видалити її до індексування, а вилучення під час пошуку може просто не назвати її. Виправлення залежить від того, який кордон ви можете довести як відповідальний, тому корисна робота — це порівняння, а не налаштування.

Почніть з однієї події, а не з панелі

Виберіть одну подію автентифікації та запишіть, що її ідентифікує: модель і версія шлюзу, метод автентифікації, ідентифікатор події, позначка часу й адреса джерела. Додайте ім’я користувача точно так, як його ввела людина, включно з регістром, бо пошук із урахуванням регістру може приховати наявне поле. Вважайте цю подію еталоном для кожного наступного порівняння.

Типи подій не поділяють одну схему. Невдала спроба, успішний вхід без клієнта й повторне підключення тунелю можуть давати різні поля, а деякі шлюзи пропускають ідентичність, коли спроба так і не дійшла до автентифікації користувача. Тож порожній стовпець для одного типу подій — слабкий доказ проблеми конвеєра.

Працюйте зі схваленою тестовою ідентичністю, а не з реальним обліковим записом працівника, і тримайте порівняння в межах правил доступу, які вже діють для даних журналів. Широке ввімкнення докладного журналювання автентифікації лише заради зразка змінює систему, яку ви намагаєтеся виміряти.

Порівняйте чотири кордони по порядку

Значення може зникнути в одній із чотирьох точок. Кожна точка має іншого власника та інше виправлення.

Зупиніться на першому кордоні, де значення зникає. Розбіжність між поданням пристрою та необробленою копією вказує на транспорт або налаштування збирача; збіг там, але відсутність значення в індексованій події вказує на перетворення; значення, наявне в індексованій події, але відсутнє на панелі, вказує на вилучення або запит.

Цей порядок важливий, бо кожен наступний етап може лише втрачати інформацію і ніколи не відновлювати її. Регулярний вираз не поверне рядок, який попередній етап замінив заповнювачем, а налаштування конфіденційності не пояснить значення, яке так і не було надіслано.

Маскування в джерелі — це політика, а не помилка аналізатора

Документація з журналювання ASA від Cisco описує приховування імені користувача як настроювану поведінку, зокрема те, як подаються недійсні або невідомі імена. Тож замаскована ідентичність у вихідній події може бути саме тим, чого вимагає політика конфіденційності, а ставлення до неї як до помилки розбору веде до запиту, який послаблює контроль.

Точне подання залежить від версії та типу повідомлення. Одна подія може містити заповнювач, інша може взагалі опустити поле, а збій автентифікації може ніколи не містити імені. Перевіряйте задокументовану поведінку для конкретної події, а не застосовуйте старий звіт про помилку до кожної відсутньої ідентичності.

Коли маскування навмисне, питання змінюється з того, як відновити поле, на те, чи можна виконати вимогу аудиту іншим способом. Ідентифікатори сеансу, контрольоване зіставлення ідентичностей у меншій групі або вужчий дозволений потік подій часто задовольняють потребу, не виставляючи кожне випробуване ім’я користувача перед кожним читачем журналів.

Анонімізацію до індексування не можна скасувати

Документація Splunk щодо обробки подій описує анонімізацію через вирази sed і перетворення, які переписують або видаляють дані до індексування. Саме це розташування і є суттю: необроблена подія змінюється на вході, тому вилученню під час пошуку нема чого більше знайти.

Редагування під час індексування та вилучення полів під час пошуку вирішують різні задачі. Редагування обмежує, хто взагалі може побачити значення; вилучення лише вирішує, яке ім’я використовує запит. Гешування — проміжний варіант, що зберігає кореляцію, але стабільний геш у малому просторі імен користувачів усе ще ідентифікує, коли хтось може перевіряти за ним імена-кандидати.

Якщо збережена подія все ще містить ідентичність, проблема нижче за потоком: тип джерела, розбиття рядків, обробка роздільників, псевдоніми полів або сам запит. Це звичайні виправлення розбору, і вони не торкаються кордону конфіденційності.

Виберіть виправлення, що відповідає кордону

Відповідь визначають три умови. По-перше, чи має намір політика конфіденційності виключити ідентичність? По-друге, чи потрібна процесу аудиту або розслідування сама ідентичність, псевдонім чи лише сеанс? По-третє, на якому кордоні потрібне значення — збирання, зберігання чи подання?

Якщо політика має намір виключити, змінюйте вимогу або подання, а не контроль. Якщо політика дозволяє ідентичність, але збирання її втрачає, виправте збирач і підтвердьте необроблену подію. Якщо зберігання ціле, виправте вилучення й перевірте його на схваленій події, яку ви зафіксували на початку.

Закрийте розслідування, назвавши кордон у записі про зміну: замасковано в джерелі, видалено під час приймання або пропущено вилученням. Це одне речення каже наступному інженеру, де дивитися насамперед, і не дає скарзі на панель перетворитися на тихо вимкнену функцію конфіденційності.