Как провести инвентаризацию ИТ без большого проекта

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

Для старта не обязательно сразу внедрять CMDB и пытаться описать всю инфраструктуру до последнего кабеля. Полезнее ограничить задачу, собрать первую проверяемую версию реестра и отдельно отметить сведения, которых пока нет.

1. Начните с решения, для которого нужен реестр

Перед сбором данных сформулируйте один ближайший вопрос. Например:

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

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

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

2. Считайте не только устройства, но и рабочие сервисы

Список ноутбуков, серверов и коммутаторов полезен, но не показывает, что произойдёт с работой компании при отказе одного из них.

Поэтому первую строку реестра удобнее начинать с понятного сервиса или функции:

• корпоративная почта;
• 1С и связанные базы;
• доступ сотрудников к файлам;
• приём и обработка заказов;
• складской учёт;
• телефония;
• видеонаблюдение;
• удалённый доступ;
• резервное копирование;
• работа производственной или торговой площадки.

После этого к сервису привязывают технические компоненты: приложения, серверы, облака, сетевые устройства, каналы связи, учётные записи и поставщиков.

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

3. Какие поля нужны в первой версии

Для каждого сервиса или системы достаточно зафиксировать:

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

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

4. Соберите данные в три прохода

Проход 1. Что нужно бизнесу

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

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

Проход 2. Из чего это состоит

ИТ-команда и подрядчики дополняют список компонентами и связями:

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

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

Проход 3. Что подтверждается фактически

Выберите несколько наиболее важных сервисов и сопоставьте запись с наблюдаемым состоянием. Например:

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

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

5. Отделяйте подтверждённое от предположений

Реестр — это описание инфраструктуры, а не сама инфраструктура. Даже аккуратно заполненная таблица может быть неполной или устаревшей.

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

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

Статус «неизвестно» полезнее правдоподобной догадки. Он показывает, где требуется проверка и какое решение пока нельзя принимать уверенно.

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

6. Не назначайте ответственность одной колонкой

Для одного сервиса могут существовать разные роли:

• владелец бизнес-процесса определяет, что должно работать;
• ИТ-специалист администрирует систему;
• подрядчик выполняет согласованные операции;
• поставщик отвечает за внешний сервис или канал;
• руководитель разрешает существенные изменения;
• сотрудник безопасности согласует доступ.

Фамилия в поле «ответственный» не доказывает, что человек действительно имеет нужные полномочия, знания и доступ. Поэтому в реестре лучше разделить роли и проверить, кто фактически может выполнить действие или принять решение.

7. Что должно получиться после первого цикла

Первая полезная версия инвентаризации — это не обязательно полный каталог активов. Результатом может быть:

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

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

8. Когда лёгкого реестра уже недостаточно

Более формальная система учёта и автоматического обнаружения нужна, если:

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

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

Минимальная проверка перед завершением первого цикла

1. Для каждого включённого сервиса понятно его назначение.
2. Названы пользователи, площадки и важные бизнес-зависимости.
3. Разделены владелец, исполнитель и внешний поставщик.
4. Известно, кто может предоставить административный доступ.
5. Указаны основные технические зависимости.
6. Для критичных сведений есть дата и способ проверки.
7. Неизвестные данные не заменены предположениями.
8. Определено событие, после которого запись нужно проверить снова: изменение, инцидент, смена поставщика или плановый пересмотр.

Короткий вывод

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

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

Источники и границы материала

• NIST Cybersecurity Framework 2.0 — Asset Management — учёт оборудования, программ, сервисов, систем, внешних услуг, потоков данных и приоритетов активов.
• CIS Control 1: Inventory and Control of Enterprise Assets — поддержание актуального реестра физических, виртуальных, удалённых и облачных активов, включая владельца и подразделение.
• CISA StopRansomware Guide — связь инвентаризации с критичными системами, данными и зависимостями, важными для восстановления.

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