Пункт 7.1 приложения 3 к ПТКЗИ: перечень разрешенного программного обеспечения

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

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

Перечень – не формальный список названий. Он связывается с активами, назначением, версиями, источником установки и владельцем.

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

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

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

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

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

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

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

Требование относится к ПО активов ИС и средств защиты в границах системы. Уровень детализации должен позволять однозначно определить, разрешена ли конкретная программа.

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

Что включать в перечень

• операционные системы и серверные роли;
• прикладные системы и клиентские компоненты;
• СУБД, web-серверы, middleware и интеграционные средства;
• средства удалённого администрирования;
• СЗИ, мониторинг и резервное копирование;
• драйверы, плагины и расширения, влияющие на безопасность;
• служебные утилиты администраторов;
• переносимые приложения, если они допускаются.

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

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

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

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

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

Порядок установки и использования

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

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

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

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

После обновления или замены программы следует проверять не только факт установки, но и влияние на защитные механизмы: журналы, антивирусную проверку, резервное копирование, сетевые соединения и совместимость с СЗИ. Легитимное обновление иногда изменяет порты, службы и каталоги хранения данных.

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

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

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

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

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

Выборочную сверку лучше проводить по нескольким группам активов: серверы, пользовательские АРМ, административные рабочие места и средства защиты. Один полностью соответствующий компьютер не доказывает, что процесс охватывает всю систему.

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

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

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

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

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

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

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

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

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

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

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

• Пункт 4.2: замена и модернизация активов.
• Пункт 7.2: контроль состава активов ИС и СЗИ.
• Пункт 7.8: обновление программного обеспечения.

Вывод

Пункт 7.1 формирует управляемую границу допустимого программного состава.

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

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

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

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

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

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