Активы-призраки: как найти сервер, которого нет в CMDB

Вчера мы говорили о сервере без владельца: виртуалка работает, наружу смотрит, данные обрабатывает, но для компании почти не существует.

Сегодня – обещанная инженерная часть. Как находить такие активы раньше злоумышленника и не превратить инвентаризацию в очередной Excel на 14 тысяч строк, которому никто не верит.

Первая мысль обычно выглядит разумно:

Давайте поставим сканер помощнее, обойдём все диапазоны и загрузим найденное в CMDB.

Так делать не надо.

Через месяц вы получите тысячи IP-адресов, дубли виртуальных машин, давно выключенные узлы, сетевые интерфейсы вместо устройств и записи вида unknown-linux-17. У каждой будет разная степень правды, но выглядеть они будут одинаково официально.

Доверие к такой базе закончится очень быстро. А CMDB, которой не верят, превращается в дорогой архив.

Нужен не один волшебный инструмент, а конвейер:

источники факта
      ↓
промежуточный реестр
      ↓
нормализация и дедупликация
      ↓
назначение владельца и критичности
      ↓
NetBox / GLPI / CMDB
      ↓
контроль расхождений и жизненного цикла

Главная мысль: сначала мы собираем наблюдения, а уже потом решаем, какие из них являются активами.

NetBox или GLPI: что выбрать

Они решают разные задачи, поэтому вопрос «что лучше» поставлен не совсем правильно.

NetBox – источник доверия для инфраструктуры

NetBox хорошо подходит для описания того, как инфраструктура должна выглядеть:

площадки и стойки;
физические устройства;
виртуальные машины и кластеры;
IP-адреса и префиксы;
VLAN и VRF;
каналы связи;
роли, арендаторы, статусы и теги;
пользовательские поля;
связи между объектами.

NetBox сознательно не является сетевым сканером. Он не должен внезапно обнаруживать устройство и объявлять его истиной. Его роль – быть программируемым источником доверия, доступным через REST API.

Это важное архитектурное разделение.

Сканер говорит: «Я что-то увидел».

NetBox говорит: «Вот что у нас должно быть и в каком состоянии».

Расхождение между этими двумя утверждениями и есть полезный сигнал.

GLPI – инвентаризация рабочих мест и операционный учёт

GLPI Agent полезен там, где надо собирать фактическую конфигурацию:

оборудование;
операционные системы;
установленное ПО;
серийные номера;
сетевые интерфейсы;
локальные устройства;
часть данных о виртуализации;
сетевые устройства через discovery и SNMP.

У GLPI Agent есть отдельные задачи для network discovery и network inventory. Это удобно для парка рабочих станций, принтеров, коммутаторов и другой инфраструктуры, которую хочется видеть не только как IP-адрес.

Можно использовать оба

Нормальная схема вполне может выглядеть так:

NetBox      → сеть, адресное пространство, виртуализация, intended state
GLPI        → endpoints, ПО, серийные номера, операционная инвентаризация
EDR / MDM   → управляемость и фактическое состояние защитных агентов
Cloud API   → ресурсы облачных аккаунтов
Discovery   → то, что выпало из остальных источников

Но надо заранее решить, какая система является хозяином каждого типа данных.

Если владелец поля не определён, интеграция быстро превращается в перетягивание каната:

GLPI изменил hostname;
NetBox вернул старое значение;
скрипт снова перезаписал его данными из vCenter;
через час никто не понимает, чему верить.

Слой 1. Собираем фактическое состояние

Один источник никогда не покажет всю инфраструктуру. У каждого своя слепая зона.

Виртуализация

Начать стоит с управляющих платформ:

VMware vCenter;
Proxmox VE;
Hyper-V / SCVMM;
OpenStack;
Kubernetes API;
панели хостинг-провайдеров.

Оттуда нужны не только имена VM, но и стабильные идентификаторы:

VM UUID;
ID объекта в платформе;
cluster / host;
папка или проект;
статус питания;
дата создания;
теги;
MAC-адреса;
IP-адреса, если guest tools действительно их видят.

Название srv-app-01 может измениться. UUID виртуальной машины обычно живёт стабильнее и лучше подходит для сверки.

EDR и MDM

EDR и MDM отвечают на другой вопрос: какие устройства действительно находятся под управлением.

Полезные поля:

agent ID;
hostname;
ОС и версия;
последний выход на связь;
IP и MAC;
пользователь;
политика;
статус защиты;
tenant или группа.

Если сервер есть в vCenter, но его нет в EDR, это не обязательно инцидент. Возможно, это appliance или технологическое исключение. Но это уже конкретное расхождение, которое можно проверить.

Если устройство есть в EDR, но отсутствует во всех инфраструктурных реестрах, становится ещё интереснее.

Сеть

Сетевое обнаружение нужно не как главный источник истины, а как детектор неожиданностей.

Для первого прохода по согласованному диапазону достаточно host discovery:

nmap -sn 10.20.0.0/24 -oX alive.xml

Опция -sn выполняет обнаружение активных узлов без сканирования портов. XML удобнее обычного текста, потому что его затем можно разбирать автоматически.

Для локального сегмента полезны ARP-таблицы коммутаторов и маршрутизаторов. Они часто показывают устройства, которые не отвечают на ICMP.

Дополнительные источники:

DHCP leases;
DNS A/AAAA и PTR-записи;
таблицы MAC на коммутаторах;
ARP / Neighbor Discovery;
NAC;
Wi-Fi-контроллеры;
балансировщики;
firewall sessions;
логи прокси и VPN.

Важно: сканировать можно только согласованные диапазоны своей инфраструктуры. Не надо превращать инвентаризацию в неожиданный пентест и проверять устойчивость старого принтера к полному -A.

GLPI Agent

Для отдельного прохода GLPI Agent умеет запускать network discovery по диапазону:

glpi-netdiscovery \
  --first 10.20.0.1 \
  --last 10.20.0.254 \
  --threads 10

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

Облака

В облаке не надо пытаться восстанавливать картину только по IP-адресам. Сама платформа уже знает свои ресурсы и отдаёт их через API.

Российские площадки здесь ничем не отличаются по смыслу от зарубежных: сначала надо получить список доступных организаций, облаков, проектов или каталогов, а затем пройти по API всех используемых сервисов. Один список виртуальных машин не покажет управляемые базы, Kubernetes, балансировщики, диски, сети и Object Storage.

Yandex Cloud

В Yandex Cloud основной scope для многих API – каталог. Поэтому сначала надо получить список каталогов облака, а затем опросить нужные сервисы в каждом из них:

yc resource-manager folder list \
  --cloud-id CLOUD_ID \
  --format json

yc compute instance list \
  --folder-id FOLDER_ID \
  --format json

Команда yc compute instance list вернёт VM конкретного каталога. В ответе API доступны ID, имя, статус, зона, labels, диски и сетевые интерфейсы.

Но Compute Cloud – только начало. Отдельно надо пройти по:

Managed Service for Kubernetes;
управляемым базам данных;
дискам и снимкам;
Load Balancer;
VPC;
Container Registry;
Object Storage;
сервисным учётным записям и ключам.

Особенно полезны labels: из них можно получить проект, среду, владельца и cost center. Если обязательных labels нет, это уже готовое расхождение для тикета.

VK Cloud и Selectel

Для IaaS-сервисов на базе OpenStack удобно использовать OpenStack API и CLI. После авторизации в конкретном проекте базовый сбор может выглядеть так:

openstack server list -f json
openstack volume list -f json
openstack network list -f json
openstack router list -f json

В документации Selectel отдельно указано, что openstack server list показывает ресурсы только тех проектов и пулов, для которых настроена API-авторизация.

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

В VK Cloud надо учитывать тот же принцип scope и отдельно собирать управляемые сервисы, которые не представлены обычным списком Compute: базы данных, Kubernetes, объектное хранилище, балансировщики и другие PaaS-компоненты.

Cloud.ru

У Cloud.ru есть Cloud CLI и API Explorer для вызова API сервисов, а у платформ и продуктов – отдельные справочники API. Например, для виртуальных машин доступен Compute API.

Здесь снова нужен не один запрос, а набор коллекторов:

Compute + диски + VPC + Kubernetes + DBaaS
+ Object Storage + IAM + теги

Для сверки полезны также данные потребления и resource tags. Если ресурс создаёт расходы, но отсутствует в техническом реестре, это хороший кандидат на роль очередного призрака.

Иностранные облака

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

Azure

Azure Resource Graph позволяет запросить ресурсы сразу по подпискам:

Resources
| project
    id,
    name,
    type,
    resourceGroup,
    subscriptionId,
    location,
    tags

Через CLI:

az graph query -q "
Resources
| project id, name, type, resourceGroup,
          subscriptionId, location, tags
"

AWS

AWS Config Advanced Query умеет собирать текущее состояние поддерживаемых ресурсов:

SELECT
  resourceId,
  resourceName,
  resourceType,
  accountId,
  awsRegion,
  tags
WHERE
  resourceType LIKE 'AWS::EC2::%'

Если аккаунтов и регионов много, нужен aggregator. Иначе прекрасный скрипт честно покажет только тот кусок AWS, в который его пустили, а команда решит, что увидела всё.

Google Cloud

Cloud Asset Inventory позволяет искать ресурсы на уровне проекта, папки или организации:

gcloud asset search-all-resources \
  --scope=organizations/ORG_ID \
  --format="json(name,assetType,project,location,labels)"

Во всех облаках особое внимание надо уделять scope и правам сервисной учётной записи. Пустой результат может означать не отсутствие ресурсов, а отсутствие доступа к ним.

Слой 2. Промежуточный реестр

Самая полезная вещь во всей схеме – staging-таблица между discovery и CMDB.

Туда попадает не «сервер», а наблюдение из конкретного источника.

Минимальная модель:

Поле	Зачем нужно
`source`	vCenter, EDR, GLPI, Nmap, AWS, Azure, GCP
`external_id`	стабильный ID в исходной системе
`asset_type`	VM, physical server, endpoint, network device, cloud resource
`hostname` / `fqdn`	имена, полученные из источника
`ip_addresses`	все наблюдавшиеся адреса
`mac_addresses`	сетевые интерфейсы
`serial` / `uuid`	устойчивые идентификаторы
`account` / `subscription` / `project`	облачный или организационный контекст
`platform`	ОС, гипервизор, тип ресурса
`tags`	владелец, проект, среда, cost center
`first_seen`	когда увидели впервые
`last_seen`	когда источник подтвердил существование
`owner_hint`	предполагаемый владелец
`raw_payload`	исходный ответ для разбора спорных случаев

Зачем хранить raw_payload?

Потому что через неделю кто-нибудь спросит: «Почему вы решили, что этот сервер относится к проекту retail?». И вместо гадания можно показать исходный тег, папку vCenter или поле из API.

Слой 3. Нормализация

Разные системы описывают одно и то же по-разному.

APP-SRV-01
app-srv-01
app-srv-01.corp.local
vm-10482
/subscriptions/.../virtualMachines/app-srv-01

До сопоставления данные надо привести к общему виду:

hostname – в нижний регистр;
FQDN – отдельно от короткого имени;
IP – в каноническом формате;
MAC – без различий AA-BB, aa:bb и aabb;
даты – в UTC;
типы ОС – через общий справочник;
теги владельцев – через таблицу соответствий;
названия сред – к фиксированным значениям prod, stage, dev, test.

Особенно важно нормализовать организационные данные.

В одном облаке владелец записан как owner=team-retail, в другом – support_group=RET_APP, а в vCenter нужная VM лежит в папке Retail/Production.

Без справочника соответствий автоматика увидит три разных команды.

Слой 4. Дедупликация

Главная ошибка – считать IP-адрес идентификатором актива.

Сегодня на адресе одна VM, завтра другая. Один сервер имеет несколько интерфейсов. NAT прячет десятки систем за одним адресом. В Kubernetes IP может жить меньше рабочего созвона.

Сопоставлять лучше каскадом:

cloud resource ID;
UUID виртуальной машины;
серийный номер;
agent ID EDR/MDM/GLPI;
комбинация FQDN и MAC;
hostname, сеть и дополнительные признаки;
IP – только как вспомогательный сигнал.

Практично присваивать совпадению уровень уверенности:

100 – совпал cloud resource ID или VM UUID
90  – совпал серийный номер
80  – совпал agent ID и hostname
60  – совпали FQDN и MAC
30  – совпали только hostname или IP

Автоматически объединять стоит только записи выше установленного порога. Всё спорное отправляется в очередь ручной сверки.

Иначе CMDB начнёт не только плодить дубли, но и склеивать разные серверы в один. Это уже хуже, чем просто мусор.

Слой 5. Сверяем факт и ожидаемое состояние

После нормализации появляются три действительно полезных класса расхождений.

Есть в источнике доверия, но нигде не наблюдается

Возможные причины:

актив выключен;
выведен из эксплуатации, но запись осталась;
агент сломан;
источник discovery не покрывает сегмент;
изменился идентификатор;
запись была создана «на будущее».

Такой актив не надо сразу удалять. Его переводят в stale и проверяют.

Наблюдается, но отсутствует в источнике доверия

Это и есть наш актив-призрак:

временная VM;
forgotten staging;
инфраструктура подрядчика;
самовольный cloud resource;
старый appliance;
лабораторный сервер;
устройство, подключённое без процесса.

Он получает статус unidentified и тикет владельцам сегмента, облачного аккаунта или бизнес-сервиса.

Есть с обеих сторон, но данные расходятся

Например:

в NetBox система dev, а в облаке тег prod;
владелец указан старый;
IP изменился;
VM переехала в другой cluster;
EDR не выходил на связь 40 дней;
сервер числится выведенным, но продолжает обслуживать запросы.

Это configuration drift. И именно его стоит превращать в регулярные задачи, а не в ежегодную генеральную уборку.

Слой 6. Назначаем владельца

Найти актив мало. Без владельца всё снова упрётся в фразу: «А задачу кому ставить?».

Владельца можно попытаться определить по:

обязательным cloud tags;
папке или resource group;
cost center;
проекту в системе заявок;
владельцу подписки или аккаунта;
группе поддержки;
репозиторию и CI/CD;
создателю ресурса из audit logs;
последним администраторам;
бизнес-сервису, с которым общается актив.

Но создатель ресурса и владелец – не одно и то же. Инженер мог создать VM по заявке, а ответственность лежит на продуктовой команде.

Я бы разделял две роли:

технический владелец – отвечает за эксплуатацию, патчи, агент, бэкап и восстановление;
бизнес-владелец – подтверждает назначение, критичность, допустимый риск и решение о выводе.

Если определить владельца автоматически не удалось, актив должен получить:

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

«Разобраться потом» – не статус. Это способ подарить серверу корпоративное бессмертие.

Жизненный цикл актива

Одна из причин смерти CMDB – отсутствие понятных статусов.

Рабочая модель может выглядеть так:

discovered
   ↓
identified
   ↓
managed
   ↓
stale
   ↓
decommissioning
   ↓
retired

Отдельная ветка:

discovered → unowned → quarantined → managed / retired

Что означает каждый статус

discovered – источник впервые увидел объект;
identified – понятно, что это за объект, но контроль ещё не завершён;
managed – есть владелец, критичность и обязательные контроли;
unowned – актив подтверждён, но ответственный не назначен;
quarantined – связность и действия ограничены до решения;
stale – актив давно не подтверждался источниками;
decommissioning – идёт вывод из эксплуатации;
retired – актив выведен, доступы и данные обработаны.

Никогда не удаляйте запись автоматически только потому, что один источник её не увидел. Сначала должен пройти grace period и проверка по другим системам.

Как писать в NetBox через API

Сначала лучше выгрузить существующие объекты и сравнить их со staging:

curl -sS \
  -H "Authorization: Bearer $NETBOX_TOKEN" \
  "https://netbox.example/api/virtualization/virtual-machines/?fields=id,name,status,cluster,custom_fields"

Для обновления конкретной записи используйте PATCH, а не полную замену объекта:

curl -sS -X PATCH \
  -H "Authorization: Bearer $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  "https://netbox.example/api/virtualization/virtual-machines/123/" \
  --data '{
    "custom_fields": {
      "technical_owner": "team-retail",
      "inventory_source": "vcenter-prod",
      "last_seen": "2026-07-23T06:00:00Z"
    }
  }'

Практические правила:

отдельный API-токен для интеграции;
минимальные права;
сначала режим read-only;
журналировать каждое изменение;
передавать request ID;
не перезаписывать поля, которыми владеет другая система;
массовые операции сначала проверять на staging-контуре.

Самое плохое, что можно сделать, – дать скрипту полный доступ и команду «синхронизируй всё». Он обязательно синхронизирует. Вопрос лишь в том, в какую сторону.

Контроль качества: что измерять

Количество записей в CMDB почти ничего не говорит о качестве.

Полезнее четыре базовые метрики.

Owner coverage

Доля активных объектов с назначенным техническим и бизнес-владельцем:

managed assets with owner / all active assets

Inventory freshness

Доля активов, подтверждённых источником за допустимый период.

Для рабочих станций это может быть 7–14 дней. Для сетевого оборудования – сутки. Для облака – несколько часов. Единого срока для всех типов нет.

Unmatched assets

Число наблюдений, которые не удалось сопоставить с источником доверия.

Эту метрику полезно смотреть по сегментам, облачным аккаунтам и владельцам.

Mean time to ownership

Среднее время от первого обнаружения до назначения владельца.

Если новый cloud resource остаётся бесхозным три недели, процесс не работает, даже если красивый дашборд показывает 98% покрытия.

Дополнительно:

количество stale-активов;
доля систем без EDR;
доля систем без бэкапа;
расхождения по критичности;
просроченный decommissioning;
количество обязательных тегов, исправленных вручную;
число повторно появившихся активов после «выключения».

Минимальный пилот без покупки новой платформы

Не надо начинать со всей компании. Возьмите один понятный контур:

один vCenter или Proxmox cluster;
один сетевой сегмент;
одну консоль EDR;
одну облачную подписку;
100–300 активов.

Шаг 1. Зафиксировать источники

Определить, откуда берутся:

UUID;
hostname;
IP и MAC;
владелец;
среда;
критичность;
дата последнего наблюдения.

Шаг 2. Сделать staging

Для пилота хватит PostgreSQL, SQLite или даже аккуратного CSV в Git. Главное – не писать сразу в боевую CMDB.

Шаг 3. Нормализовать

Привести имена, MAC, даты, типы ОС, статусы и теги к единому формату.

Шаг 4. Сопоставить

Сначала точные ID, затем составные признаки. Всё с низкой уверенностью – на ручную проверку.

Шаг 5. Разобрать расхождения руками

Именно здесь вы поймёте реальную природу данных:

где клоны VM имеют одинаковые признаки;
где агент переустановили и ID изменился;
где IP переиспользуется;
где cloud tags пишут как придётся;
где сервер существует только потому, что его боятся выключить.

Шаг 6. Только потом автоматизировать запись

Когда правила сверки проверены на живых данных, можно обновлять NetBox или GLPI через API и автоматически создавать тикеты.

Что обычно ломает проект

Подключили всё сразу

Команда получает миллион наблюдений, которые не успевает разобрать. Проект тонет не в технической сложности, а в очереди неопределённости.

Автоматически импортировали всё найденное

Discovery превратился в генератор записей, а не в механизм контроля расхождений.

Считали IP уникальным ключом

Получили дубли, ложные объединения и очень странную историю изменений.

Не определили владельцев полей

Несколько систем начинают перезаписывать друг друга.

Не придумали decommissioning

Новые записи появляются автоматически, старые никогда не умирают.

Назначили владельцем «ИТ»

Формально поле заполнено. Практически задача снова идёт в общий чат с вопросом: «Чьё это?».

Сделали ежегодную инвентаризацию

Через неделю после проверки инфраструктура снова меняется. Инвентаризация должна быть непрерывным процессом сверки, а не корпоративным субботником.

Чек-лист живой инвентаризации

Перед запуском задайте себе десять вопросов:

Какие системы описывают ожидаемое состояние?
Какие источники показывают фактическое состояние?
Есть ли у каждого типа данных хозяин?
Какой стабильный идентификатор используется для каждого класса активов?
Куда попадают наблюдения до записи в CMDB?
Как обрабатываются сомнительные совпадения?
Как назначается технический и бизнес-владелец?
Что происходит с активом без владельца?
Через сколько дней объект становится stale?
Кто и как подтверждает вывод из эксплуатации?

Если на половину вопросов нет ответа, новый сканер не исправит ситуацию. Он просто быстрее покажет масштаб проблемы.

В итоге

Здоровая CMDB – не та, где записано всё.

Здоровая CMDB – та, где:

каждой записи можно доверять;
понятно, откуда пришли данные;
есть живой владелец;
расхождения создают действия;
активы не только появляются, но и корректно умирают.

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

Сверить результаты. Разобрать расхождения руками. Описать правила. И только после этого включать автоматизацию.

Именно на первой честной сверке обычно находятся самые интересные активы-призраки.

Найти сервер мало. Нужно понять, зачем он существует, кто за него отвечает и когда его можно выключить.