Где имя пользователя VPN исчезает из конвейера журналов?

Сеансы отображаются на панели, а столбец имени пользователя остаётся пустым, и первый порыв — обвинить анализатор. Этот порыв пропускает три более ранних этапа, где значение могло быть потеряно. Шлюз может маскировать идентичность по политике, правило приёма может удалить её до индексации, а извлечение во время поиска может просто не назвать её. Исправление зависит от того, какую границу вы можете доказать как ответственную, поэтому полезная работа — это сравнение, а не настройка.

Начните с одного события, а не с панели

Выберите одно событие аутентификации и запишите, что его идентифицирует: модель и версия шлюза, метод аутентификации, идентификатор события, отметка времени и адрес источника. Добавьте имя пользователя точно так, как его ввёл человек, включая регистр, потому что поиск с учётом регистра может скрыть существующее поле. Считайте это событие эталоном для каждого последующего сравнения.

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

Работайте с одобренной тестовой идентичностью, а не с реальной учётной записью сотрудника, и держите сравнение в рамках правил доступа, которые уже действуют для данных журналов. Широкое включение подробного журналирования аутентификации только ради образца меняет систему, которую вы пытаетесь измерить.

Сравните четыре границы по порядку

Значение может исчезнуть в одной из четырёх точек. У каждой точки свой владелец и своё исправление.

Остановитесь на первой границе, где значение исчезает. Расхождение между отображением устройства и необработанной копией указывает на транспорт или конфигурацию сборщика; совпадение там, но отсутствие значения в индексированном событии указывает на преобразование; значение есть в индексированном событии, но отсутствует на панели — это указывает на извлечение или на запрос.

Этот порядок важен, потому что каждый следующий этап может только терять информацию и никогда не восстанавливать её. Регулярное выражение не вернёт строку, которую предыдущий этап заменил заполнителем, а настройка конфиденциальности не объяснит значение, которое так и не было отправлено.

Маскирование в источнике — это политика, а не ошибка анализатора

Документация по журналированию ASA от Cisco описывает скрытие имени пользователя как настраиваемое поведение, включая то, как представляются недопустимые или неизвестные имена. Поэтому маскированная идентичность в исходном событии может быть именно тем, что требует политика конфиденциальности, а отношение к ней как к ошибке разбора ведёт к запросу, который ослабляет контроль.

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

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

Анонимизацию до индексации нельзя отменить

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

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

Если сохранённое событие всё ещё содержит идентичность, проблема ниже по потоку: тип источника, разбиение строк, обработка разделителей, псевдонимы полей или сам запрос. Это обычные исправления разбора, и они не затрагивают границу конфиденциальности.

Выберите исправление, соответствующее границе

Ответ определяют три условия. Во-первых, намерена ли политика конфиденциальности исключить идентичность? Во-вторых, нужен ли процессу аудита или расследования сама идентичность, псевдоним или только сеанс? В-третьих, на какой границе нужно значение — сбор, хранение или представление?

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

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