Нормативный источник: пункт 7.3 Приложения 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ).
Смысл требования
Пункт 7.3 приложения 3 к ПТКЗИ – практический разбор требования «автоматизированный контроль активов». Пункт 7.3 развивает 7.2 и требует автоматизированно получать фактические сведения об активах и изменениях.
Автоматизация может состоять из нескольких источников, если данные регулярно собираются, сопоставляются и приводят к обработке отклонений.
Современная инфраструктура меняется быстрее, чем человек успевает обновлять таблицы вручную. Виртуальные машины и облачные ресурсы создаются за минуты, а ноутбук может подключиться к сети без предварительного уведомления.
Смысл автоматизации – сократить время между появлением неизвестного объекта и реакцией. Чем быстрее обнаружена новая ВМ, пропавший агент защиты или подключившееся устройство, тем меньше период неконтролируемого риска.
Формулировка требования
Приложение 3 к Положению о порядке технической и криптографической защиты информации, пункт 7.3: «автоматизированный контроль за составом активов информационной системы, средств защиты информации».
Нормативная формулировка обычно короче, чем реальный процесс её выполнения. Поэтому при внедрении её следует разложить на понятные действия: определить объект контроля, назначить ответственных, установить технические правила и подготовить доказательства фактической реализации.
Обязательность применения
Требование обязательно для классов 3-бг, 3-юл и 3-дсп. Для классов 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин и 3-спец оно является рекомендуемым.
Для обязательных классов ручной реестр без автоматического получения фактических данных не закрывает пункт 7.3.
Для обязательных классов ручной реестр не заменяет автоматическое получение фактических данных. При этом автоматизация должна охватывать всю установленную границу, а не только ту часть, где удобно установить агент.
Источники автоматизированных данных
- каталог домена и управление конечными узлами;
- EDR или централизованный антивирус;
- платформа виртуализации и контейнеров;
- сетевой мониторинг и NAC;
- CMDB с discovery;
- облачные API;
- средства управления конфигурациями;
- консоли СЗИ и резервного копирования.
Конкретная технология не предписана. Решение должно соответствовать архитектуре ИС и обеспечивать заявленный результат.
Один источник редко видит всю инфраструктуру. AD хорошо показывает доменные компьютеры, платформа виртуализации – ВМ и хосты, сетевой мониторинг – фактические подключения, а облачные API – ресурсы провайдера.
Поэтому сведения обычно сопоставляются по нескольким признакам: имени, уникальному идентификатору, серийному номеру, MAC-адресу, облачному ID и другим атрибутам. Это помогает отличить новый объект от переименованного и уменьшает число дублей.
При выборе источников важно учитывать ограничения. Агент не увидит устройство, на которое его невозможно установить; сетевой сканер не всегда определит владельца; облачный API не покажет локальные активы. Поэтому охват необходимо оценивать по типам объектов и сегментам.
Собранные сведения должны нормализоваться. Разные системы могут по-разному записывать имя хоста, производителя или версию ОС. Без нормализации один актив будет ошибочно выглядеть как несколько разных записей.
Как должен работать контроль
- выявлять новые, изменённые и исчезнувшие объекты;
- сопоставлять фактические данные с реестром;
- формировать оповещение или задачу;
- сохранять историю;
- назначать ответственного;
- измерять полноту и возраст телеметрии;
- учитывать активы без агента;
- защищать технические учётные записи.
Рабочий цикл не заканчивается формированием отчёта. Обнаруженное отклонение должно получить ответственного и решение: зарегистрировать актив, исправить запись, изолировать объект или удалить его.
Также требуется контролировать саму телеметрию. Если агент или источник давно не передаёт данные, отсутствие новых событий нельзя считать подтверждением, что состав системы не изменился.
Приоритет обработки следует определять по риску. Неизвестный сервер в продуктивном сегменте требует немедленной проверки, а давно отключённая тестовая ВМ может обрабатываться в обычном порядке. Однако оба события должны иметь статус и ответственного.
Автоматизированный контроль полезно связывать с системой заявок. Тогда обнаруженное отклонение автоматически превращается в задачу, получает срок и историю решения. Это значительно надёжнее, чем периодический отчёт, который никто не обязан разбирать.
Что следует подтвердить при проверке
- перечень автоматизированных источников;
- охват типов активов и сегментов;
- периодичность получения данных;
- последнюю инвентаризацию;
- примеры выявленных отклонений;
- историю обработки;
- метрики полноты;
- права технических записей;
- порядок действий при отказе источника.
Доказательства должны подтверждать фактическое состояние всей заявленной области, а не единичный пример.
Проверка должна показывать связь между документами и реальной конфигурацией. Схема, реестр, настройка и журнал изменений должны описывать один и тот же объект, а не разные состояния системы.
Лучше готовить не отдельные случайные скриншоты, а связанный набор доказательств: утверждённое правило, техническую реализацию, результат контроля и пример обработки выявленного отклонения.
Нужно продемонстрировать не только текущий экран консоли, но и пример полного жизненного цикла события: обнаружение нового объекта, уведомление ответственного, проверка законности, регистрация или удаление и закрытие задачи.
Отдельно следует показать контроль источников данных. Если интеграция с платформой виртуализации перестала работать, система должна выявить отсутствие обновлений, иначе отчёт будет выглядеть стабильным именно потому, что данные больше не поступают.
Следует учитывать и ложные срабатывания. Слишком большое число дубликатов и незначимых событий приводит к тому, что действительно опасные изменения теряются в общем потоке. Поэтому правила сопоставления и приоритизации нужно периодически корректировать на основании результатов эксплуатации.
Для изолированных сегментов автоматизация может работать без постоянного соединения с центральной системой. В таком случае необходимо определить локальный источник данных, безопасный порядок передачи отчётов и максимально допустимый интервал между инвентаризациями.
Что закрепить в ТЗ, ЛПА и ОРД
- архитектуру контроля;
- источники и периодичность;
- идентификаторы сопоставления;
- критерии изменения;
- роли обработки событий;
- исключения;
- метрики полноты;
- срок хранения истории.
Документы не должны переписывать интерфейс конкретного продукта. Их задача – установить устойчивые правила: кто принимает решение, что именно контролируется, когда выполняется проверка и какие действия предпринимаются при нарушении.
Такая формулировка остаётся применимой после замены оборудования или программного обеспечения и не требует полностью переписывать ЛПА при каждом техническом обновлении.
Полезно установить допустимый возраст данных. Например, если сведения об активе не обновлялись дольше заданного срока, запись помечается как недостоверная и требует проверки. Это предотвращает использование старой телеметрии как подтверждения актуального состава.
При использовании нескольких источников следует определить порядок разрешения противоречий. Например, платформа виртуализации может показывать активную ВМ, а CMDB – статус «выведена». Регламент должен устанавливать, кто проверяет такое расхождение, какой источник считается технически достоверным и в какой срок исправляются связанные записи.
Типичные ошибки
- CMDB считается автоматизацией при ручном вводе;
- агенты установлены только на части узлов;
- облачные активы не охвачены;
- новые объекты никто не разбирает;
- дубли скрывают состав;
- инвентаризация запускается только перед проверкой;
- история не сохраняется.
Большинство перечисленных ошибок возникает, когда мера существует только в документах либо реализована на части активов. Исправление следует начинать с определения фактического охвата, а затем устранять разрыв между требованиями, настройками и эксплуатационными действиями.
Распространённая ошибка – считать любой автоматический экспорт полноценным контролем. Если данные выгружаются, но не сопоставляются с утверждённым составом и не приводят к действиям, автоматизация остаётся только способом сбора информации.
Связанные материалы
- Пункт 7.2: контроль состава активов.
- Пункт 1.3: централизованный сбор событий.
- Пункт 7.16: контроль внешних подключений.
Вывод
Пункт 7.3 требует автоматизированного получения фактических данных и управляемой обработки изменений.
Наличие продукта без охвата, актуальной телеметрии и реакции на отклонения недостаточно.
Эффективная автоматизация часто строится из нескольких уже используемых систем. Ключевой результат – не единая красивая консоль, а своевременное выявление изменений и доведение каждого значимого отклонения до решения.
Понятный критерий эффективности – время от появления нового актива до принятого решения. Чем короче этот интервал и чем меньше неразобранных отклонений, тем лучше работает автоматизированный контроль.
Нормативная основа
- Приказ ОАЦ № 66 от 20.02.2020 в редакции приказа ОАЦ № 259 от 10.12.2024 – приложение 3, пункт 7.3. Официальный источник.
- Положение о порядке технической и криптографической защиты информации – требования к ТЗ, ЛПА и эксплуатации. Официальный источник.
При применении материала необходимо использовать актуальную редакцию нормативного акта и учитывать класс конкретной ИС, её границы и решения, закреплённые в техническом задании.