Как работает инвентаризация техники без агентов?

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

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

Сначала определите, что именно вы считаете

Единицей учета должен быть физический экземпляр техники, а не IP-адрес, имя компьютера или строка в бухгалтерской выгрузке. Адрес меняется при новом DHCP-сеансе, имя переиспользуют после переустановки, а одна бухгалтерская карточка иногда охватывает комплект из системного блока, монитора и периферии. Если принять любой из этих признаков за сам актив, дубли и ложные списания неизбежны.

Для каждого физического устройства заведите внутренний asset_id, который никогда не переезжает на другой экземпляр. Рядом храните наблюдаемые идентификаторы: серийный номер, UUID из SMBIOS, MAC-адреса интерфейсов, имя узла, инвентарный номер бухгалтерии, пользовательское подразделение и место размещения. У каждого значения должны быть источник и время получения. Запись «серийный номер ABC, получен локальным опросом 12 мая» сильнее записи «ABC», происхождение которой никто не помнит.

Разделите состояние актива и качество сведений о нем. Компьютер может числиться «в эксплуатации», но иметь устаревшие сетевые данные. Другой может отвечать в гостевой сети, хотя его владельца и основание появления еще не установили. Практичная модель содержит как минимум четыре независимых поля: жизненный статус, ответственный, последнее наблюдение и уровень доверия к сопоставлению.

До первого опроса зафиксируйте охват. В него входят корпоративные подсети, VPN-пулы, Wi-Fi для сотрудников, серверные VLAN, филиалы, лабораторные сегменты и диапазоны удаленного управления. Гостевую сеть тоже стоит наблюдать, но найденные там устройства нельзя автоматически объявлять активами организации. Отдельно перечислите исключения: медицинское оборудование, производственные контроллеры, кассы и другие системы, где активный опрос разрешает только владелец сервиса.

Виртуальные машины и облачные экземпляры учитывайте в отдельном классе, даже если бухгалтерия не считает их основными средствами. Их серийные номера, MAC-адреса и имена легко клонируются вместе с шаблоном, а жизненный цикл измеряется минутами или днями. Идентификатор гипервизора либо облачной платформы связывает экземпляр с техническим объектом, но не с физическим сервером. Для контейнеров обычно нужен не реестр каждого краткоживущего экземпляра, а учет кластеров, узлов и утвержденных образов. Границу следует записать до сбора, иначе один отчет смешает имущество, виртуальные ресурсы и сетевые сервисы. Внешнее оборудование подрядчиков тоже храните как отдельный тип со сроком разрешения, владельцем договора и ожидаемым сегментом. Тогда его не примут за собственность, но и не потеряют среди гостевых подключений.

Сеть дает карту присутствия, а не готовый реестр

Сетевой опрос нужно начинать с обнаружения узлов и только затем переходить к разрешенному сбору атрибутов. Руководство Nmap прямо отделяет host discovery от сканирования портов: параметр -sn останавливает работу после поиска доступных узлов. В локальном Ethernet Nmap обычно использует ARP, а через маршрутизатор сочетает ICMP и TCP-пробы. Поэтому один ICMP ping считается слабой проверкой, а молчание узла ничего не доказывает.

Запускайте опрос из нескольких согласованных точек, по одной в каждом крупном сетевом контуре. Межсетевой экран, трансляция адресов и правила между VLAN меняют видимость. Центральный сканер может не увидеть рабочую станцию, которую локальный ARP-опрос обнаружит сразу. Перед запуском согласуйте диапазоны, время, скорость и типы проб с сетевой командой и службой информационной безопасности. Инвентаризация не оправдывает несанкционированное сканирование.

Минимальный проход можно сохранить в XML, чтобы следующий этап разбирал структурированный результат, а не текст терминала:

nmap -sn -n -oX discovery-2025-05-12.xml 10.24.16.0/24

В XML будут элементы host со статусом, адресами и, когда источник видит локальный канал, MAC-адресом. Не превращайте этот файл сразу в перечень компьютеров. В нем окажутся принтеры, телефоны, точки доступа, виртуальные интерфейсы и временные устройства. Он отвечает на узкий вопрос: какой сетевой идентификатор проявил себя из этой точки в этот момент.

Дополните снимок арендой DHCP, таблицами ARP или Neighbor Discovery на маршрутизаторах, регистрациями Wi-Fi-контроллера и данными коммутаторов. RFC 2131 допускает, что DHCP-клиент идентифицирует себя через client identifier, а не только аппаратный адрес. Поэтому поле ClientId нельзя без проверки считать MAC-адресом. На Windows DHCP Server команда Get-DhcpServerv4Lease возвращает записи аренды, включая активные и, с параметром -AllLeases, истекшие и отклоненные. История аренды полезна для выключенных сегодня ноутбуков, но старую аренду нельзя выдавать за текущее присутствие.

Сетевые устройства и принтеры можно опрашивать через SNMP, если организация уже настроила его безопасно. RFC 3418 определяет sysDescr, sysObjectID, sysName и sysLocation, но эти поля заполняет администратор или производитель, и они часто пусты либо устарели. SNMPv1 и общая строка community ради удобства учета создают ненужный риск. Используйте действующую защищенную конфигурацию и доступ только на чтение, а не ослабляйте устройство ради инвентаризации.

Пассивные источники снижают нагрузку, но требуют такой же осторожной трактовки. Журналы межсетевого экрана, DNS-запросы, события аутентификации и данные контроля доступа показывают активность, которая уже происходила, поэтому их можно анализировать без новых проб. Однако один адрес в журнале может принадлежать балансировщику, прокси или транслятору, а DNS-имя может пережить сам компьютер. Храните ссылку на исходное событие, временное окно и сетевой контекст. Не загружайте в реестр весь сетевой журнал: извлекайте только поля, нужные для связи наблюдения с кандидатом. Сочетание пассивной истории и контролируемого активного снимка полезнее постоянного агрессивного сканирования. Первое показывает прошлую активность, второе проверяет доступность сейчас, и ни одно по отдельности не подтверждает владение.

Штатный удаленный опрос раскрывает состав компьютера

Для управляемых Windows-компьютеров удаленный CIM-опрос дает модель, производителя, серийный номер, UUID, память, операционную систему и сетевые интерфейсы без постоянного агента. Он работает через штатные интерфейсы управления и требует заранее настроенной аутентификации, правил межсетевого экрана и прав. Не открывайте WMI или WinRM всему административному сегменту и не запускайте сбор под учетной записью администратора домена. Выделите учетную запись с минимальными правами и журналируйте обращения.

Microsoft описывает Win32_ComputerSystem как источник производителя и модели, Win32_BIOS как источник серийного номера BIOS, а Win32_ComputerSystemProduct как источник UUID из SMBIOS. Эти данные полезны, но документация предупреждает о качестве сведений от производителя. На практике встречаются пустые строки, шаблонные серийные номера и нулевой UUID. Ни одно из полей не получает право на ошибку только потому, что пришло из прошивки.

Такой фрагмент собирает компактную запись с удаленного узла:

$session = New-CimSession -ComputerName PC-042
$cs = Get-CimInstance -CimSession $session -ClassName Win32_ComputerSystem
$bios = Get-CimInstance -CimSession $session -ClassName Win32_BIOS
$product = Get-CimInstance -CimSession $session -ClassName Win32_ComputerSystemProduct
$os = Get-CimInstance -CimSession $session -ClassName Win32_OperatingSystem
[pscustomobject]@{
  ComputerName = $cs.Name
  Manufacturer = $cs.Manufacturer
  Model = $cs.Model
  SerialNumber = $bios.SerialNumber
  UUID = $product.UUID
  OS = $os.Caption
  LastObservedAt = (Get-Date).ToUniversalTime().ToString('o')
  Source = 'remote-cim'
} | ConvertTo-Json -Compress
Remove-CimSession $session

Результат имеет форму одной JSON-записи с именем, моделью, серийным номером, UUID, ОС, временем и источником. Обрабатывайте отдельно четыре исхода: успешный сбор, узел доступен, но доступ запрещен, интерфейс управления недоступен, узел не отвечает. Если свалить их в одну ошибку «не найден», команда будет чинить сеть там, где нужны права, и списывать технику, которая просто выключена.

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

Сбор при входе находит ноутбуки вне офисной сети

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

Для Windows сценарий можно назначить существующей групповой политикой или механизмом управления, который уже принят в организации. Не маскируйте его и не собирайте содержимое диска. Достаточно имени, серийного номера, UUID, модели, версии ОС, вошедшего корпоративного пользователя и времени. Пользователей нужно уведомить о составе и цели сбора в соответствии с внутренними правилами и применимыми требованиями к персональным данным.

Доставка требует аккуратности. Общая папка с правом создания файлов, но без чтения чужих отчетов, лучше папки, где каждый сотрудник видит весь парк. Еще лучше внутренний HTTPS-приемник с аутентификацией устройства, ограничением размера и защитой от повторной отправки. Сервер должен считать входные данные недоверенными: проверять схему, ограничивать длину строк и не использовать присланное имя файла как путь.

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

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

Бухгалтерия подтверждает актив, но не его присутствие

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

Сначала нормализуйте выгрузку, не меняя исходник. Выделите инвентарный номер, наименование, серийный номер, дату принятия, подразделение, ответственное лицо, статус и номер документа. Уберите пробелы по краям, приведите регистр серийных номеров к одному виду, но сохраните оригинальное значение рядом. Ведущие нули инвентарного номера значимы, поэтому не позволяйте электронной таблице превращать его в число.

Отдельно разберите комплекты. Если бухгалтерия учитывает «рабочее место» одной карточкой, а ИТ-служба видит системный блок и два монитора, создайте связь «комплект содержит», а не три фиктивных бухгалтерских номера. Если после ремонта системный блок получил новую системную плату, UUID может измениться, хотя бухгалтерский актив остался тем же. Такое событие требует истории компонентов и документа ремонта, а не автоматического создания нового имущества.

Сверка должна выдавать категории работы, а не один столбец «совпало». Полезны статусы «точное совпадение», «вероятное совпадение», «только в бухгалтерии», «только в ИТ-наблюдениях», «конфликт атрибутов» и «нужен осмотр». Для вероятного совпадения храните причину, например одинаковые модель, подразделение и наклейка при отсутствующем серийном номере. Решение человека также записывайте с датой и автором, иначе следующий импорт снова откроет уже разобранный спор.

Сопоставляйте источники по силе идентификатора

Серийный номер производителя обычно лучше имени и IP-адреса, но слепо доверять ему нельзя. Устойчивость идентификатора зависит от класса техники и качества прошивки. Для рабочего компьютера сильной связкой часто будет нормализованный серийный номер плюс производитель; UUID помогает подтвердить совпадение. Для сетевого устройства пригодятся серийный номер из разрешенного интерфейса управления и запись закупки. Для монитора, который сеть не видит, понадобятся наклейка, данные EDID с подключенного компьютера и физическая проверка.

Задайте правила сопоставления явно и выполняйте их от сильных к слабым:

1. Точное совпадение уникального серийного номера и производителя связывает записи автоматически, если номер не входит в список шаблонных значений.
2. Совпадение корректного UUID и модели дает сильного кандидата, но замена системной платы требует проверки истории ремонта.
3. MAC-адрес связывает сетевые наблюдения с интерфейсом, а не навсегда с корпусом; док-станции, виртуальные адаптеры и смена платы ограничивают его ценность.
4. Имя узла, IP-адрес, пользователь и подразделение только повышают или понижают уверенность. Они не должны создавать автоматическое точное совпадение.
5. Конфликт двух сильных идентификаторов отправляет запись на ручную проверку и никогда не разрешается по принципу «последний источник победил».

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

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

Для каждого автоматического совпадения сохраняйте версию правила, входные наблюдения и полученную оценку. Простого значения «95 процентов» недостаточно, если никто не может объяснить его расчет. Лучше записать понятный вывод: серийный номер и производитель совпали, UUID подтвердил связь, конфликтов нет. Порог автоматического связывания проверяйте на размеченной выборке из собственного парка, потому что качество идентификаторов различается между поставками и классами техники. Ложное объединение опаснее временного дубля: дубль попадет в очередь, а ошибочно склеенные устройства скрывают неизвестный актив и назначают ему чужую историю. После изменения правил повторно прогоняйте старые наблюдения в тестовой копии и сравнивайте, какие связи появились, исчезли или сменили уровень уверенности. Это превращает сопоставление из непрозрачной формулы в проверяемую процедуру.

Неизвестная техника находится в расхождениях

Неизвестным считается устройство, которое проявилось в контролируемой среде, но не связалось ни с утвержденным ИТ-активом, ни с разрешенным исключением. Не всякое такое устройство нарушает правила. Это может быть новый компьютер до импорта накладной, оборудование подрядчика, личный телефон в разрешенной сети или забытая система лаборатории. Цель проверки состоит в установлении владельца и основания подключения.

Начните с очереди сетевых идентификаторов, которые повторялись в нескольких снимках и не получили связи. Одно краткое появление случайного MAC-адреса в Wi-Fi не заслуживает того же приоритета, что узел, который ежедневно получает адрес в серверном VLAN. Случайные адреса на пользовательских устройствах и виртуальные интерфейсы делают подсчет по MAC неточным, поэтому учитывайте сегмент, регулярность, имя, производителя адресного блока только как подсказку и сведения контроллера доступа.

Затем ищите обратные расхождения. Актив есть в каталоге, но давно не входил. Бухгалтерская карточка действует, но ни сеть, ни локальный отчет не видели устройство. Сценарий входа сообщает серийный номер, которого нет в закупках. Коммутатор показывает устройство на порту переговорной, хотя за помещением ничего не закреплено. Каждая комбинация ведет к разному владельцу задачи: службе поддержки, бухгалтерии, закупкам, сетевой команде или ответственному за помещение.

Показательный сбой выглядит так. Сканирование нашло адрес 10.24.16.87, DHCP сохранил имя DESKTOP-7K2, а каталог содержит одноименный отключенный объект трехлетней давности. Автоматическая система склеила записи по имени и закрыла исключение. При осмотре выяснилось, что это компьютер подрядчика, которому случайно задали старое имя из инструкции. Если бы правило потребовало серийный номер или UUID, устройство осталось бы в очереди неизвестных и получило правильную проверку.

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

Отсутствие агента оставляет измеримые слепые зоны

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

Назначьте срок свежести по классу и источнику. Для рабочего ноутбука локальный отчет недельной давности может быть нормальным, а для серверного порта такой разрыв требует проверки. Конкретные интервалы зависят от режима работы организации, поэтому не копируйте чужие числа. Зафиксируйте свои сроки, владельца реакции и допустимые исключения.

Каталог Active Directory тоже нельзя читать как датчик точного последнего входа. Microsoft объясняет, что lastLogonTimestamp реплицируется с задержкой, рассчитанной вокруг 14-дневного интервала с случайным уменьшением. Атрибут подходит для грубого поиска неактивных учетных записей, но не для ответа «кто входил вчера». Точный анализ требует понимания других атрибутов и контроллеров домена, а для инвентаризации лучше использовать его как одно слабое наблюдение.

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

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

Повторяемая сверка важнее идеального первого снимка

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

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

Контроль качества удобно строить вокруг нескольких понятных очередей: новые неизвестные устройства, конфликты сильных идентификаторов, активы без свежих наблюдений, бухгалтерские карточки без связи и ИТ-объекты без основания владения. У каждой очереди должен быть ответственный и срок разбора. Процент «охвата» без списка исключений мало что говорит, потому что его легко улучшить, удалив неудобные записи.

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

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

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