Автоинвентаризация ИТ-инфраструктуры: как находить неизвестные устройства и контролировать изменения
Habr ·
От обнаружения к реестру Новый сервер, неизвестный IP-адрес, дополнительный сетевой интерфейс на рабочем компьютере — инфраструктура меняется быстрее, чем её успевают описывать вручную. Даже аккуратный реестр активов быстро теряет ценность, если данные в нём расходятся с фактическим состоянием сети. В прошлой статье мы разбирали, зачем нужен единый источник данных об оборудовании, адресах и связях и почему мониторинг, SIEM и ITSM не должны превращаться в независимые конкурирующие реестры. Теперь следующий вопрос: как поддерживать мастер-реестр в актуальном состоянии, когда инфраструктура постоянно меняется? Автоинвентаризация здесь полезна не как «сканер, который сам всё занесёт в CMDB». Нормальная рабочая схема выглядит иначе: собрать сведения из нескольких источников, определить, к какому активу они относятся, проверить расхождения и только после этого обновить мастер-данные. Именно такой подход заложен в исходном материале: результаты Сонара и плагина виртуализации сначала проходят через промежуточный этап проверки, а затем интегрируются в ОдинХаб . Это важное разделение. IP-адрес может перейти другому узлу, имя — измениться, виртуальная машина — переехать или быть переименована. Поэтому совпадение по одному признаку нельзя автоматически считать доказательством идентичности объектов. Точно так же открытый TCP-порт или баннер сервиса позволяет сформировать гипотезу, но не подтверждает модель устройства, серийный номер, владельца или его физическое расположение. Официальная документация Nmap прямо описывает service/version detection как механизм определения протокола, приложения, версии, семейства ОС и типа устройства там, где это удаётся определить по ответам сервиса ; полнота такой идентификации зависит от того, какую информацию сервис раскрывает. Читать далее