Автоинвентаризация ИТ-инфраструктуры в ОдинХаб

От обнаружения к реестру

В прошлой статье мы разбирали, зачем нужен единый источник данных об оборудовании, адресах и связях и почему мониторинг, SIEM и ITSM не должны превращаться в независимые конкурирующие реестры. Теперь следующий вопрос: как поддерживать мастер-реестр в актуальном состоянии, когда инфраструктура постоянно меняется?

Автоинвентаризация здесь полезна не как «сканер, который сам всё занесёт в CMDB». Нормальная рабочая схема выглядит иначе: собрать сведения из нескольких источников, определить, к какому активу они относятся, проверить расхождения и только после этого обновить мастер-данные. Именно такой подход заложен в исходном материале: результаты Сонара и плагина виртуализации сначала проходят через промежуточный этап проверки, а затем интегрируются в ОдинХаб.

Это важное разделение. IP-адрес может перейти другому узлу, имя — измениться, виртуальная машина — переехать или быть переименована. Поэтому совпадение по одному признаку нельзя автоматически считать доказательством идентичности объектов. Точно так же открытый TCP-порт или баннер сервиса позволяет сформировать гипотезу, но не подтверждает модель устройства, серийный номер, владельца или его физическое расположение. Официальная документация Nmap прямо описывает service/version detection как механизм определения протокола, приложения, версии, семейства ОС и типа устройства там, где это удаётся определить по ответам сервиса; полнота такой идентификации зависит от того, какую информацию сервис раскрывает.

Практический цикл получается таким:

На первом скриншоте хорошо видно, почему этапы стоит оставлять разделёнными: подтверждение кандидата и запуск интеграции — разные действия. В продакшене это позволяет сначала оценить качество сопоставления и только затем включать автоматизацию. Автоподтверждение и автоинтеграцию стоит включать только после проверки правил сопоставления на тестовом контуре.

Практические сценарии

Неизвестное устройство или IP-адрес

Допустим, в контролируемом префиксе появился адрес, которого нет в реестре. Первая задача — не немедленно создать карточку «неизвестного сервера», а понять, какие факты вообще можно подтвердить.

Сонар в исходном сценарии выполняет сетевое обнаружение и опрос оборудования. Сонар сканирует сетевые префиксы, опрашивает устройства по SNMP и SSH и собирает сведения о соседях по LLDP/CDP. В зависимости от режима опроса используются Nmap, TCP-проверки, сервисные баннеры и SNMP/CLI.

Если на 22/tcp отвечает SSH и в баннере есть строка, указывающая на OpenSSH в Ubuntu, разумно записать это как признак Linux-системы, но не как окончательно установленную ОС актива. Аналогично наличие 3389/tcp или SMB может быть полезным признаком Windows-окружения, а IPP/9100 — признаком печати, но открытый порт сам по себе не доказывает назначение устройства. Nmap использует ответы сервисов именно для вероятностной идентификации протокола, приложения, версии, типа устройства и семейства ОС, причём не каждый сервис отдаёт все эти сведения.

В демонстрационном примере показан удачный пример: SSH-аутентификация не проходит, SNMP не отвечает, однако сервисный признак остаётся. Это именно тот случай, когда интерфейс должен говорить инженеру не «мы нашли Linux-сервер», а «есть такие-то основания предполагать Linux; модель, серийный номер и назначение пока неизвестны».

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

ARP и LLDP/CDP здесь нельзя смешивать. ARP предназначен для разрешения сетевого адреса в адрес канального уровня на непосредственно доступной сети; запись вида IP и MAC не описывает физическую кабельную трассу и не является доказательством того, в какой порт подключён узел. LLDP, напротив, стандартизирован именно для обмена сведениями между соседними станциями и обнаружения топологии между непосредственно соседствующими устройствами. Актуальный стандарт IEEE 802.1AB описывает механизмы обнаружения физической топологии соседних станций. CDP решает похожую задачу в экосистеме Cisco; например, Cisco указывает среди сведений о соседе Device ID, System Name и локальный интерфейс, на котором сосед обнаружен.

Поэтому из ARP разумно получить задачу «проверить IP/MAC», а из LLDP/CDP — более сильное основание для проверки соседства и порта. При наличии данных LLDP/CDP можно проверить соседство и сопоставить порты; автоматически созданные связи необходимо контролировать.

Межсетевой экран, ACL, закрытый management-интерфейс, иной порт управления или временная потеря связности могут дать тот же результат. Поэтому карточка неудачного опроса — диагностический факт, а не идентификация актива.

Практический результат этого сценария должен быть не «Сонар автоматически добавил сервер», а:

Расхождение между реестром и конфигурацией

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

Повторная инвентаризация позволяет показать расхождение до записи в реестр. На скриншоте показано сравнение, где обнаружены отсутствующие интерфейсы, IP-адреса, VLAN и свойства устройства.

Здесь принципиально важно не переинтерпретировать diff. Если сканер видит шесть интерфейсов, а каталог — ноль, это подтверждает расхождение текущих состояний, но не отвечает на вопросы, кто, когда и зачем создал интерфейсы. Для этого нужны журнал изменений, change request, конфигурационные логи или данные AAA/оборудования.

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

Для ИБ отсутствие заявки является хорошим сигналом для проверки, но само по себе не доказывает нарушение.

Подготовка замены коммутатора

Третий сценарий показывает, что инвентаризация нужна не только ИБ.

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

Сонар получает сведения о блоках питания, вентиляторах и SFP и затем передаёт их в предметы инвентаря. Поддержка конкретных моделей и полнота таких сведений зависят от адаптера устройства, доступных MIB/CLI и версии прошивки, поэтому полноту сбора следует проверять на используемом оборудовании.

Такой сбор не заменяет документацию производителя. Он отвечает на вопрос «что сейчас установлено и подключено?», а не «что гарантированно совместимо с новой моделью?». Совместимость SFP, блоков питания, вентиляторов и версий ПО всё равно нужно проверять по документации конкретного оборудования.

Зато к change window можно подготовить нормальный контрольный набор:

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

После переключения повторный сбор становится постпроверкой: сохранились ли нужные IP, VLAN, интерфейсы и соседства.

Новый сетевой адаптер на рабочем компьютере

Сетевой сканер видит сеть снаружи. Некоторые изменения важнее наблюдать изнутри ОС.

Эту роль выполняет Ревизор: агент собирает сведения о компьютере и сохраняет версии результатов, чтобы оператор мог увидеть изменения. Среди описанных данных — IP, MAC, сетевые интерфейсы, серийный номер, Boot ID и установленное ПО. Также заявлена интеграция с доменной учётной записью пользователя. Доступность конкретных полей и вариантов интеграции зависит от версии и конфигурации решения.

Предположим, между двумя передачами данных появился USB Ethernet.

Это хороший сигнал для ИБ, но плохой повод для автоматического вердикта. Адаптер мог появиться из-за док-станции, штатной диагностики, замены оборудования или временного подключения.

Проверка должна двигаться от факта к контексту:

При этом L3-шлюз или префикс не гарантируют точное рабочее место пользователя. Для уверенной привязки к физическому порту пригодятся дополнительные данные: состояние access-коммутатора, таблицы MAC, сведения DHCP, NAC/AAA или корректно заведённые кабельные связи.

ФИО пользователя и контакт площадки сокращают путь расследования, но не являются доказательством того, кто именно подключил адаптер. Это хорошее место в статье, потому что оно не даёт читателю ложного ощущения «автоматической атрибуции».

Архитектура источников

Один источник не может одинаково хорошо видеть физическую сеть, платформу виртуализации и состояние гостевой ОС. Поэтому в рассматриваемой архитектуре используется несколько уровней наблюдения. ОдинХаб объединяет IPAM/DCIM, учёт физических и виртуальных ресурсов и интеграции с источниками данных. Возможности отдельных компонентов необходимо соотносить с установленной версией продукта.

Сонар использует SNMP, SSH и LLDP/CDP. Для виртуализации используются интеграции с VMware, Proxmox VE, zVirt/oVirt, ПК СВ «Брест» и OpenStack; совместимость конкретных версий платформ следует уточнять.

Источники передают наблюдения в общий контур проверки и сопоставления, после чего подтверждённые данные попадают в реестр.

Для Аванпоста предусмотрен вариант HTTPS pull: агент внутри площадки инициирует соединение с ядром, выполняет локальный опрос и возвращает результаты; отдельно сказано, что прямое подключение агента к БД ОдинХаб не требуется. Параметры соединения и обработку длительных разрывов связи следует проверять при внедрении.

Для виртуализации самый важный вопрос — не сколько полей удалось собрать, а как система узнаёт, что очередной результат относится к уже существующей ВМ.

Для этого используется пара virt_source + virt_external_id, а имя и IP не являются ключом поиска. Это устойчивее сопоставления только по имени или IP, особенно при переименованиях; правила обработки изменения самого источника необходимо учитывать отдельно.

Внедрение и контроль качества

Начинать лучше не со «всей компании», а с одного контура, где результат можно независимо проверить: площадки, ЦОД, сетевого сегмента или отдельного класса активов. Как мы отмечали в предыдущем материале, сначала мастер-источник и небольшой контролируемый контур, затем интеграции и потребители данных.

Перед первым продуктивным запуском нужно договориться о трёх вещах.

Кто является владельцем каждого класса данных. Например, платформа виртуализации может быть приоритетным источником для vCPU, RAM и внешнего ID ВМ; агент ОС — для интерфейсов и установленного ПО; сетевой опрос — для сетевой топологии и аппаратных характеристик сетевого устройства. Это не универсальная матрица, а политика конкретной организации.

Как определяется идентичность объекта. IP и hostname — удобные атрибуты поиска, но опасные единственные ключи. Для разных классов активов нужны более устойчивые идентификаторы: serial, UUID, внешний ID платформы, сочетание источника и идентификатора и тому подобное.

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

Для сетевых учётных записей следует применять минимально необходимые права. Для опроса нужен read-only доступ к нужным командам вместо полного административного или root-доступа. Для SNMP, где оборудование это поддерживает, стоит рассматривать SNMPv3 с аутентификацией и privacy: стандарт USM определяет сервисы аутентификации, целостности и конфиденциальности сообщений.

У самой системы инвентаризации появляются чувствительные данные: credentials, API-токены, сетевые конфигурации, сведения о сотрудниках и топология. В ОдинХаб предусмотрены RBAC, журналирование, LDAP/AD/OAuth и интеграционные API. Также описаны интеграция с ОдинКлюч и сохранение SSH-конфигураций в Config Context с маскированием известных секретов. Механизм маскирования следует отдельно тестировать: фильтр по шаблонам никогда не стоит воспринимать как доказательство, что в конфигурационном архиве гарантированно не осталось чувствительных строк.

Минимальная программа приёмочного тестирования может выглядеть так:

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

Полезные метрики пилота тоже лучше выбирать не маркетинговые. Не «нашли 18 тысяч объектов», а:

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

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

Что в итоге даёт автоинвентаризация

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

Сонар отвечает на вопрос «что сейчас видно в сети и что известно об этом объекте». Платформа виртуализации даёт контекст ВМ, который невозможно достоверно восстановить только сетевым сканированием. Ревизор позволяет увидеть изменения внутри ОС. Аванпост переносит сбор в удалённые сегменты. Затем все эти сведения должны встретиться на этапе сопоставления и проверки. Так складывается единая картина инфраструктуры в IPAM/DCIM и реестре активов ОдинХаб.

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

Хорошая автоинвентаризация — это не максимальное количество автоматически заполненных полей. Это процесс, в котором понятно, откуда взялась каждая существенная информация, насколько ей можно доверять и кто должен принять решение, если источники расходятся.