Аудит ИТ-инфраструктуры КИИ в 2026 году: как собрать эталонные данные для ФСТЭК и избежать штрафов

Регуляторы давят, а ИТ-отдел не успевает

Федеральный закон №187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» действует с 2018 года, но именно сейчас, в 2026 году, интенсивность проверок со стороны ФСТЭК (Федеральной службы по техническому и экспортному контролю) и ФСБ (Федеральной службы безопасности) достигла нового уровня. Большинство выявленных нарушений связаны не с реальными инцидентами, а с несоответствием документации фактическому состоянию инфраструктуры.

Под действие закона попадают организации из 13 отраслей: здравоохранение, транспорт, энергетика, банки, ТЭК, оборонная промышленность, госсектор и другие. Для всех них учет ИТ-активов — не вопрос удобства, а требование регулятора.

Что именно требует регулятор

Требования к значимым объектам КИИ определяются Приказом ФСТЭК №239. Если переводить нормативный язык в практический список, регулятор ожидает следующее.

Аппаратные средства

• Полный реестр оборудования с идентификационными данными (производитель, модель, серийный номер).

• Привязка каждого устройства к объекту КИИ и сегменту сети.

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

Программное обеспечение

• Перечень всего установленного ПО с версиями.

• Сведения о сертификации.

• Наличие обновлений безопасности и дата их последней установки.

• Реестр СЗИ (средства защиты информации) с реквизитами сертификатов.

Уязвимости

• Результаты сканирования в соответствии с банком данных угроз ФСТЭК (bdu.fstec.ru).

• Сведения о несертифицированном ПО на значимых объектах.

Топология

• Схема сети с выделением сегментов КИИ.

• Данные о взаимодействии с внешними сетями.

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

Почему стандартные инструменты не работают в закрытых контурах

Отдельная история — это изолированные сети, так называемые Air-gapped контуры. Это стандарт для объектов КИИ в энергетике, оборонной промышленности и госсекторе. И именно здесь большинство привычных инструментов инвентаризации не работают.

Облачные агенты не могут передать данные на сервер. Сетевые сканеры типа Nmap покажут IP и MAC, но не дадут данных об установленном ПО и версиях. WMI-опрос работает только в рамках Windows-домена и не покрывает Linux-сегменты, типичные для технологических сетей. А ручной обход и проверка ИТ-специалистом не масштабируется, когда в парке несколько сотен узлов.

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

Как создается аврал при множестве источников данных

Неделя 1. Получено уведомление о проверке. Ответственный за ИБ запрашивает реестр у ИТ-отдела. ИТ-отдел открывает Excel-файл месячной давности.

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

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

Неделя 4. Отчет собирается из нескольких источников, часть данных проставляется из Excel-таблиц, заполняемых вручную. Документ готов, но есть много «но».  Проверяющие фиксируют замечания.

Ошибка в отчете ФСТЭК — это не просто замечание, а основание для предписания об устранении нарушений, повторной проверки и возможного штрафа или приостановления аттестата соответствия.

Как «Инферит ИТМен» решает задачу инвентаризации КИИ

ИТМен закрывает задачу через гибкую архитектуру и разнообразие протоколов для сбора данных, которые перекрывают все типы инфраструктуры: от небольших офисных сетей до изолированных технологических контуров.

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

Агенты. Для технологических сетей, где Windows-домен отсутствует или ограничен, ИТМен использует агенты с нативной поддержкой российских ОС. Агент взаимодействует напрямую с пакетным менеджером (dpkg, rpm), собирает полный перечень установленного ПО с версиями и передает данные в общую базу, закрывая тот сегмент, который для большинства инструментов остается слепой зоной.

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

Гибкие отчеты для регуляторов. Система формирует детализированные отчеты по любым параметрам ИТ-подразделения. Там же можно собрать документ по требованиям Приказа ФСТЭК №239: реестр аппаратных средств, реестр ПО, сведения об уязвимостях, данные по СЗИ. Если ФСТЭК запрашивает данные за февраль, вы не реконструируете из разных источников и файлов, просто выгружаете срез за нужный период.

Разберем на типичном сценарии инвентаризация КИИ в промышленном секторе. Инфраструктура промышленного предприятия построена вокруг АСУ ТП (автоматизированных систем управления технологическим процессом). АСУ ТП работает в закрытом контуре по требованиям ИБ. ИТ-подразделению важно инвентаризировать весь этот комплекс, но как передать данные наружу, не нарушив периметр?

Пример инвентаризации с ИТМен в промышленном секторе в условиях закрытого контура.

Именно для таких сценариев в ИТМен реализованы сенсоры и множество протоколов, которые разворачиваются внутри закрытого контура и передают данные по защищенному каналу.

Чек-лист: готова ли ваша инфраструктура к проверке

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

✓ Реестр аппаратных средств обновлялся не позднее 30 дней назад.

✓ Каждое устройство привязано к объекту КИИ, сегменту сети и ответственному лицу.

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

✓ Несертифицированное ПО выявлено и задокументировано или устранено.

✓ Проведено сканирование на уязвимости в соответствии с БДУ ФСТЭК, результаты актуальны.

✓ Реестр СЗИ с реквизитами сертификатов доступен по запросу.

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

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

Выводы

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

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