Пункт 7.2 приложения 3 к ПТКЗИ: контроль состава активов ИС и СЗИ

Смысл требования

Пункт 7.2 приложения 3 к ПТКЗИ – практический разбор требования «контроль состава активов». Пункт 7.2 требует постоянно понимать, какие активы ИС и СЗИ входят в установленную границу.

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

Актив – это не только физический сервер. Им может быть виртуальная машина, сетевой коммутатор, система хранения, облачный ресурс, средство защиты или инфраструктурный сервис, без которого ИС не может нормально работать.

Защитить неизвестный объект невозможно. Неучтённая ВМ может остаться без обновлений, резервного копирования и журналирования, а выведенный сервер может продолжать иметь сетевой доступ и действующие учётные записи.

Формулировка требования

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

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

Обязательность применения

Требование обязательно для всех классов типовых ИС: 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл и 3-дсп.

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

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

Какие объекты учитывать

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

Конкретная технология не предписана. Решение должно соответствовать архитектуре ИС и обеспечивать заявленный результат.

Глубина учёта выбирается так, чтобы объект можно было идентифицировать, назначить владельца, связать с требованиями безопасности и проследить его жизненный цикл. Один IP-адрес для этого ненадёжен, поскольку он может измениться или быть повторно использован.

Особое внимание требуется общим сервисам – DNS, NTP, каталогам, удостоверяющим центрам и системам резервного копирования. Формально они могут находиться за границами прикладного сегмента, но отказ или компрометация такого сервиса влияет на защищаемую ИС.

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

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

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

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

Учёт следует встроить в обычный процесс изменений. Новый объект регистрируется до ввода в эксплуатацию, а не спустя несколько месяцев после появления в сети.

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

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

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

Что следует подтвердить при проверке

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

Доказательства должны подтверждать фактическое состояние всей заявленной области, а не единичный пример.

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

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

Хорошее доказательство – результат двусторонней выборки. Несколько объектов выбираются из реестра и находятся в инфраструктуре; затем несколько объектов выбираются из платформы виртуализации, сети или EDR и находятся в реестре. Такой метод одновременно выявляет устаревшие записи и неучтённые активы.

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

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

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

Что закрепить в ТЗ, ЛПА и ОРД

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

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

Такая формулировка остаётся применимой после замены оборудования или программного обеспечения и не требует полностью переписывать ЛПА при каждом техническом обновлении.

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

Типичные ошибки

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

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

Ещё одна проблема – отсутствие единого правила наименования. Один и тот же сервер в схеме, CMDB, системе мониторинга и резервном копировании может называться по-разному, из-за чего сопоставление становится ручным и ненадёжным.

Связанные материалы

• Пункт 7.1: перечень разрешённого ПО.
• Пункт 7.3: автоматизированный контроль состава активов.
• Пункт 4.2: замена и модернизация активов.

Вывод

Пункт 7.2 требует поддерживать доказуемо актуальный состав ИС и СЗИ.

Качественный контроль связан с жизненным циклом активов, схемами и управлением изменениями.

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

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

Нормативная основа

• Приказ ОАЦ № 66 от 20.02.2020 в редакции приказа ОАЦ № 259 от 10.12.2024 – приложение 3, пункт 7.2. Официальный источник.
• Положение о порядке технической и криптографической защиты информации – требования к ТЗ, ЛПА и эксплуатации. Официальный источник.

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