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

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

Уже упоминавшийся нами ГОСТ Р ИСО/МЭК 27001-2021 содержит требование об инвентаризации активов. С практической точки зрения, конечным результатом инвентаризации я бы назвал собственно реестр хостов. Это может быть как обычная «экселька», так и какая-то мудрёная информационная система; главное здесь — содержание, а не форма. Из своего опыта я бы выделил следующие поля, которые неплохо иметь в реестре:

• IP-адрес (или адреса, если их несколько);
• имя хоста;
• владелец системы (с точки зрения бизнеса);
• администратор системы;
• операционная система (если она типовая);
• среда (тестовая/эксплуатационная и так далее);
• описание (название ИС либо понятное краткое описание, например «пользователи», «межсетевой экран», «точка доступа Wi-Fi» и т. д.);
• комментарий.

При желании можно добавить и иные поля, например «хранимая информация», «степень критичности для бизнеса», различные теги («PCI DSS» или «бухгалтерия»). Но лучше всё-таки начать с базовых полей, а уже затем (возможно, никогда) добавлять новые. Вообще, автор является ярым приверженцем той идеи, что лучше сделать немного, но качественно, чем замахнуться на рубль, а ударить на копейку — как, к сожалению, зачастую и получается на практике. 

Давайте быстро пробежимся по наиболее очевидным частям нашего реестра. Во-первых, там, разумеется, должны присутствовать все серверы и рабочие станции. Надо помнить, что не все они работают под управлением Windows, и заметная их часть может отсутствовать в Active Directory, поэтому ограничиваться простым экспортом данных из AD нельзя. Во-вторых, в реестре должно присутствовать сетевое оборудование — как минимум имеющее IP-адрес. В-третьих, не забудем специфические системы и сервисы, такие как IP-телефония, СКУД, гипервизоры, промышленные контроллеры, интернет вещей (IoT) и т. д. 

Один из неочевидных моментов — это множественные адреса: если какой-то сервер имеет несколько сетевых интерфейсов (например, для доступа из других сетей), то все они тоже должны фигурировать в реестре. То же самое касается различных NAT-адресов, сконфигурированных на сетевом оборудовании: их тоже стоит внести в реестр, снабдив кратким описанием. И отдельно стоит отметить важность наличия в документе публичных IP-адресов организации, чтобы можно было легко найти, какой сервер/сервис обитает на том или ином IP-сокете, доступном из интернета. 

Уделим короткий абзац решениям, которые предлагают «автоматически сгенерировать реестр хостов». Увы, но это так не работает — на выходе в лучшем случае получится просто список IP-адресов и имён без указания владельцев, администраторов и описания. Польза от такой информации есть, но заметно меньшая. 

Вот вкратце и всё по теме инвентаризации хостов. К сожалению, организации не спешат выделять ресурсы на создание и поддержание актуальности такого реестра. В результате попытки разобраться в том, что происходит в корпоративной сети, напоминают путешествие в открытом море без карт: вокруг мелькают контуры неизведанных подсетей, рифы внезапных NAT, забытые сервера давно умерших приложений и сервисов… Надежда только на память старого лоцмана из IT-отдела да на обрывки старых списков хостов, составленных неизвестно кем в далёком прошлом. Звучит захватывающе, но на практике такая навигация крайне малоприятна. Лучше уж заранее позаботиться о карте и составить реестр хостов (ну или хотя бы подсетей для начала).