Каждый актив в инфраструктуре проходит свой жизненный цикл: он появляется, функционирует, а со временем выводится из эксплуатации. Новые активы часто создаются как копии существующих, но со временем обрастают уникальными особенностями. Из-за постоянных изменений в инфраструктуре возникают аномалии данных: дубликаты, «склейки» и цифровые призраки — активы, которых уже нет, но они продолжают числиться в системе.
Чтобы справиться с этой проблемой, нужно решить три нетривиальные задачи:
Идентификация — сопоставить данные из разных источников с конкретным активом.
Слияние — корректно обработать изменения между предыдущим и новым состоянием.
Ведение истории — отследить жизненный путь актива и зафиксировать момент его исчезновения.
В этой статье мы, Кирилл Маслов и Гамзат Штанчаев, эксперты Positive Technologies в области управления активами, приоткроем внутреннюю кухню MaxPatrol VM. Расскажем, как мы отличаем один актив от другого, как обновляем данные без потерь и почему в системе не должно оставаться призраков. А главное — поделимся готовыми инструментами, которые помогут вам наладить процесс инвентаризации и держать инфраструктуру под контролем.
(Этот материал — текстовая версия вебинара, который мы провели для пользователей MaxPatrol VM. Если вам удобнее смотреть и слушать, видеозапись доступна по ссылке.)
Почему в инфраструктуре появляются призраки
Причин для появления аномалий в отображении инфраструктуры несколько. Как правило, призраки возникают, когда эти причины складываются в некую комбинацию.
Изменения — активы постоянно меняются и исчезают.
Разные источники — данные не всегда совпадают.
Конфликты — один актив может выглядеть по-разному.
Дубли — возникают лишние и ошибочно объединенные записи.
Устаревание — в системе остаются неактуальные записи.
Призраки — в инвентаре остаются активы, которых уже нет.
Когда эти причины накладываются друг на друга, данные начинают противоречить друг другу — и разобраться в них становится всё сложнее.
Почему с этим нужно бороться? Точность в управлении уязвимостями всегда начинается с актива, ведь если мы не знаем, что защищать, мы не сможем это защитить. Поэтому корректная инвентаризация — один из столпов процесса управления уязвимостями. Борьба с аномалиями позволяет правильно выставить приоритеты в задачах, своевременно заметить изменения и устранить уязвимости. Вся эта работа носит многокомпонентный характер, а значит, нужна единая логика работы с активами на всех этапах — именно поэтому в основе MaxPatrol VM лежит единый подход: идентификация, корректное слияние изменений и сохранение истории на протяжении всего жизненного цикла актива.
История актива: жизненный цикл в снимках
Теперь давайте заглянем внутрь MaxPatrol VM и посмотрим, как именно мы решаем эти задачи. Начнем с одного из ключевых механизмов — истории актива. Для системы актив не существует в реальном времени — для наглядности его можно сравнить с одним из кадров на кинопленке, которая хранится в системе.
Первый кадр в этой кинопленке — момент обнаружения актива. Это может быть host discovery, аудит гипервизоров или служб каталогов. На этом этапе мы видим только сам факт его существования, иногда — всего лишь IP-адрес.
Затем, зная этот адрес, мы можем просканировать актив в режиме чёрного ящика, например, проведя пентест или обнаружение сервисов (service discovery). На этом снимке мы узнаем уже больше: операционную систему, открытые порты, запущенные службы.
Следующий шаг — аудит в режиме белого ящика, который дает максимум информации. Это полноценное сканирование, которое дает максимум информации: пользователи, группы, установленное ПО, сетевые интерфейсы и так далее. Выполнять все три шага нужно постоянно, замыкая их в цикл. Обнаружили, просканировали в режиме чёрного ящика, затем в белом — и так по кругу, непрерывно актуализируя данные об инфраструктуре.
Помимо базовых режимов, важно сканировать актив специализированными профилями. Например, если аудит показал, что на системе установлена СУБД PostgreSQL, следующим шагом нужно настроить задачу с профилем PostgreSQL Audit, чтобы узнать, какие пользователи к ней подключаются, с каких узлов, какие базы данных существуют. В MaxPatrol VM есть большой набор таких профилей — они позволяют смотреть на актив с разных сторон, используя разные протоколы удаленного доступа, их еще называют «транспорты» (SSH, WMI, LDAP и другие) и обогащая информацию об активе.
История актива в интерфейсе выглядит как таймлайн с отметками — переключаясь между датами, мы видим, как менялись данные: например, версия ядра Linux на одном снимке была одной, а на другом уже другой. Эти отметки на графике сканирования и есть те самые кадры, из которых состоит история.
Механизм устаревания данных
Проблема в том, что между задачами сканирования мы не знаем, что на самом деле происходит с активом — возможно, он уже выведен из эксплуатации. Для этого существует механизм устаревания данных. С помощью политик можно задать два параметра: срок актуальности данных и срок, после которого данные считаются устаревшими.
Эти параметры можно настраивать индивидуально для разных групп активов. С помощью PDQL-запросов и динамических групп можно вовремя выявлять активы, по которым давно не обновлялись данные, и принимать решения — либо выяснять причину проблем с доступностью или учётной записью, либо удалять актив из системы.
Помимо этого, есть глобальный параметр для системы - время устаревания активов, который по умолчанию составляет 90 дней. Если за это время данные не обновились, актив скрывается из интерфейса: он не попадает в списки, не участвует в расчетах уязвимостей. Но с точки зрения истории мы всегда можем откатиться назад с помощью PDQL-запросов и посмотреть, каким был актив в любой период времени. Подчеркну: актив только скрывается, а не удаляется безвозвратно.
Идентификация: как отличить один актив от другого
Теперь перейдем к механизму, который отвечает на главный вопрос: как мы понимаем, что скан относится к конкретному активу? Сканирование в MaxPatrol VM не привязано к активу жестко. Задача сканирования просто приносит скан, а дальше начинается магия идентификации, которая определяет, к какому активу его отнести. Если подходящий актив не найден — создается новый.
У каждой системы есть набор ключевых параметров, которые могут её уникально идентифицировать. Но этот набор отличается в зависимости от типа системы. Вот несколько примеров.
Сетевое устройство идентифицируется по хостнейму, IP-адресу и system ID.
Windows-система — по system ID, IP-адресу, MAC-адресу и полному имени домена (FQDN), а также по хостнейму.
Для Linux-системы набор короче: IP-адрес, хостнейм и MAC-адрес.
При этом для одной и той же системы набор ключевых атрибутов может отличаться в зависимости от способа сканирования. Аудит приносит наиболее полный набор: system ID, FQDN, хостнейм, MAC-адреса и IP-адреса. Host discovery или пентест — только IP-адреса.
Тип источника данных тоже влияет на набор ключевых атрибутов: при сканировании Active Directory создаются активы с FQDN и хостнеймами, а при сканировании гипервизора в актив добавляется VM ID — идентификатор виртуальной машины, который известен только гипервизору, поэтому он работает то лько в этом сценарии.
Сам алгоритм идентификации устроен нелинейно и содержит разные условия и ответвления, в которых сравниваются те или иные ключи. Однако для простоты понимания можно ориентироваться на общий порядок приоритета: при аудите наиболее приоритетным является system ID, за ним следуют FQDN, хостнейм, MAC-адрес и IP-адрес, а для виртуальных машин VM ID имеет более высокий приоритет, чем все остальные, но, как уже говорилось, доступен только в ограниченных ситуациях.
Кроме того, мы обязательно валидируем ключи — если скан приходит вообще без ключей, мы не сможем отнести его ни к какому активу, и такой скан будет просто отброшен.
Общее правило гласит, что скан должен содержать хотя бы один ключевой атрибут, но для аудита правила строже: требуются IP-адреса, MAC-адреса, хостнейм и system ID. Единственное исключение — аудит Linux, где system ID может отсутствовать, если система сканируется от непривилегированной учётной записи и ей не хватило прав для получения этого идентификатора.
Если скан не проходит валидацию, в журнале появляется соответствующая запись. А в логах сервиса можно увидеть более подробную информацию — какие именно ключевые атрибуты не прошли проверку.
Слияние: как обновлять данные без потерь
Когда у нас есть актив, есть скан, который мы отнесли к этому активу — настало время обновить информацию. Самое важное здесь не перезаписывать все подряд, а аккуратно слить новое с тем, что уже есть.
Чтобы понять, как работает слияние, нужно сначала разобраться, из чего вообще состоит актив. У нас в MaxPatrol VM состоит из объектов, а объекты — из атрибутов с примитивными типами данных или из других объектов. Сам актив, по сути, тоже объект. Например, коллекция установленного ПО — это объекты, у каждого из которых есть атрибуты: имя, вендор, версия. Чтобы посмотреть тип объекта, можно воспользоваться PDQL — обратиться к алиасу FullType или Type. Это помогает при настройке частичного сканирования: можно указать, какие классы объектов загружать или пропускать.
Сам принцип слияния довольно прост: при слиянии двух объектов те атрибуты, которые присутствуют в новом скане, полностью обновляют соответствующие атрибуты актива, а те, которых в скане нет, остаются без изменений — для вложенных объектов эта логика повторяется рекурсивно.
Однако есть важный нюанс — объекты могут приходить из разных источников. Например, информацию об открытом SSH мы можем получить и через аудит, и через пентест, но если мы удалили этот софт и запустили только пентест, он может просто не обнаружить его. Было бы неправильно удалять объект только на этом основании, поэтому мы удаляем объект только в том случае, если все источники, которые его приносили, были запущены и не принесли его в новом скане.
Ещё одна полезная возможность — частичное сканирование, с помощью которого можно настроить, какие классы объектов собирать, а какие пропускать. Например, в продукте уже есть подготовленный профиль Windows-аудит, который собирает только информацию, необходимую для расчёта уязвимостей, и таким профилем можно сканировать чаще, а полный аудит, выполняющийся дольше, запускать реже — такой подход экономит ресурсы и ускоряет получение критически важных данных.
Источниками данных об активе могут выступать не только сканирования, но и DD-правила — механизм на языке Declarative Detect, который создаёт и обновляет активы на основе событий из внешних систем. В зависимости от режима работы такие правила могут по-разному влиять на модель активов: например, на событиях из SIEM создаются новые активы или обновляются существующие, при сканировании Active Directory или гипервизора правила запускаются на других активах и порождают новые, а в некоторых случаях DD-правило работает непосредственно на самом активе и обновляет его данные.
Охота на призраков
Теперь перейдем к практике и рассмотрим несколько типичных ситуаций, в которых в MaxPatrol VM появляются дубли и призраки.
Одинаковое имя, но разные IP-адреса
Проблема: вы ищете в системе актив с именем debian-pt.local. А в ответ получаете сразу два актива. С виду — дубли. Но на самом деле у них разные IP-адреса, другие свойства тоже вроде бы различаются.
Причина: машины разворачивались из одного шаблона или клонировались, и им забыли поменять имя хоста. Это не дублирование активов в смысле ошибки идентификации — это просто два разных актива с одинаковым хостнеймом. Система их не склеила, потому что ключевые атрибуты не совпали.
Что делать: привести имена в соответствие и впредь использовать уникальные хостнеймы при развертывании.
Клонирование виртуальной машины — изменился MAC и VM ID
Проблема: два актива похожи, system ID у них совпадает, но отличаются VM ID и MAC-адрес. Оба актуализируются примерно в одно время, и создается впечатление, что это один и тот же актив, который почему-то раздвоился.
Причина: при клонировании виртуальной машины гипервизор автоматически меняет MAC-адрес, чтобы избежать конфликтов в сети. Алгоритм идентификации для виртуальных машин считает MAC-адрес более приоритетным, чем system ID — поэтому активы не склеились, а разошлись в разные объекты. При этом хостнейм и FQDN у них остались одинаковыми.
Что делать: в первую очередь — понять, что это не дубли, а действительно разные активы, просто с одинаковыми именами. Рекомендация — поменять хостнейм и FQDN на уникальные, чтобы в дальнейшем не путаться. Кроме того, стоит настраивать виртуальные машины так, чтобы после клонирования у них менялся и system ID. Если этого не сделать, в некоторых случаях система может не определить, что перед ней виртуальная машина, и склеить активы в один — тогда отловить проблему станет гораздо сложнее. Если склейка всё же произошла, проще всего удалить актив, перенастроить виртуальные машины и запустить сканирование заново.
Странности с призрачной-коллекцией при частичном сканировании
Этот кейс выделяется среди остальных: он касается не идентификации активов, а слияния данных внутри уже существующего актива. Мы решили рассказать о нём, потому что здесь поведение системы становится неочевидным для пользователя, а главное — эту особенность можно обратить себе на пользу.
Проблема: вы просканировали актив полным аудитом и собрали коллекцию файловых объектов. Потом решили включить частичное сканирование, указав, что файловые объекты больше не собираете. В результате коллекция файловых объектов осталась в том состоянии, в котором была на момент последнего полного аудита, и продолжает висеть в активе, хотя новые сканы её не приносят.
Причина: это ожидаемое поведение системы при частичном сканировании. Данные, которые не собираются, не удаляются автоматически — они остаются в активе, потому что система не знает, перестали ли вы их собирать намеренно или временно.
Что делать: либо удалить актив и пересканировать заново (радикально, но эффективно), либо обратиться в техподдержку — у нас есть несколько воркэраундов для таких случаев.
Полезный нюанс: этим же механизмом можно пользоваться осознанно. Например, при сканировании большого контроллера домена настроить три задачи последовательно: первая собирает компьютеры, вторая — пользователей, третья — группы. Каждая следующая задача добавляет данные к активу, не перезаписывая предыдущие. Так можно распределить нагрузку во времени и собрать полные данные порционно, используя тот же механизм призрачных-коллекций, но с пользой.
Инструменты для охоты: PDQL, руководство и скрипт
Как и обещали в начале, мы подготовили для вас несколько готовых инструментов, которые помогут ловить призраков в инфраструктуре.
Набор PDQL-запросов, оформленный в виде файла. Скачивайте, пользуйтесь и находите аномалии в своих данных.
Экспертное руководство по аудиту активов. Это практический документ, который поможет настроить процесс управления активами и инвентаризации с нуля: в нём последовательно описаны шаги, условия их применения и технические детали вроде PDQL-запросов для поиска определённых активов. Рекомендуем скачать, ознакомиться и держать под рукой — в процессе эксплуатации оно всегда пригодится.
Скрипт автоматизации для поиска проблем с аудитом. Он позволяет выйти на новый уровень: проверять полноту получаемых данных, находить пробелы и неточности. В результате скрипт формирует Excel-таблицу, которую можно использовать как чек-лист, и с ней вы сможете последовательно разбираться, почему возникают проблемы и как их устранить. Очень удобная штука — оставляем ссылку, все лежит на GitHub.
Кроме того, у нас есть серия вебинаров и статей «Страшно, когда не видно», где мы уже рассказывали, как с разных сторон смотреть на активы, собирать данные и работать с нюансами.
Главный вывод: призраков не стоит бояться
С призраками в инфраструктуре можно и нужно работать, и бояться их не стоит. В условиях постоянных изменений и того, как мы сканируем инфраструктуру, такие аномалии — это не проблема, а задача, которая должна быть частью процесса управления уязвимостями и инвентаризации.
Чаще всего призраки возникают из-за комбинации нескольких факторов, но в любой ситуации можно разобраться и найти решение. Мы постоянно изучаем подобные случаи и сценарии от клиентов, чтобы адаптировать продукт и сделать его более точным в отражении динамики инфраструктуры. Ключ к решению проблемы — постоянное сканирование и процессный подход к инвентаризации. А со сложными случаями всегда поможет поддержка — обращайтесь!