Разрешённое и запрещённое ПО: как вести перечень и исключения

Согласованный источник отвечает, откуда файл имеет право появиться. Перечень отвечает, какое имя программы вообще можно ставить, даже из правильного репозитория. Без перечня «официальный пакет» с торрент-клиентом на сервере с персональными данными формально взят из Debian, но для компании это всё равно дыра. Ниже таблица, которую можно вести в одной книге, и порядок исключений.
Статья опирается на логику направления «Управление ИТ-активами» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Откуда ставить: источники и контрольные суммы. Что уже стоит: учёт пакетов.
Два списка, а не один
| Список | Что в нём | Как применять |
|---|---|---|
| Разрешённое | Программы, которые можно ставить без отдельного письма: ОС, агент мониторинга, браузер, офисный пакет | Установка только из указанного источника |
| Запрещённое | То, что нельзя даже «на тест»: удалённое управление без учёта, клиенты обмена файлами, майнеры, взломщики паролей | Блокировать при обнаружении, разбирать как инцидент |
| Исключения | Разрешённое вне общего списка, на срок, с владельцем | Дата окончания; без даты исключение считается бессрочной дырой |
Для небольшой компании не стройте каталог на десять тысяч пакетов дистрибутива. Разрешайте семейства: «пакеты из основного репозитория Debian, нужные роли сервера» плюс короткий список прикладных программ. В запрещённое кладите конкретные имена и классы. Не пытайтесь сразу внедрить контроль запуска на всех станциях: сначала документ и сверка, иначе список никто не будет обновлять.
Какие поля вести
name,class,source,owner,status,until,note
firefox,browser,vendor-repo,IT,allowed,,
syncthing,file-exchange,n/a,IB,denied,,
vendor-agent,monitoring,vendor-repo,IT,exception,2027-01-15,пилот на двух серверах
Поля:
- name — имя пакета или продукта, как его ищут в системе.
- class — зачем оно нужно, чтобы похожие программы не плодились.
- source — отсылка к согласованному источнику, не «интернет».
- owner — кто отвечает за обновление и вывод из эксплуатации.
- status —
allowed,deniedилиexception. - until — обязателен для исключения.
Владелец актива в реестре ИТ-активов и владелец программы в этом перечне могут совпадать; если нет, при установке нужны оба согласия. Изменение состава ПО на сервере проводите карточкой: управление изменениями.
Как оформить исключение
- Заявитель пишет, зачем программа, на каких узлах, откуда будет ставиться, до какой даты.
- Ответственный за ИБ проверяет источник и класс: нет ли уже разрешённого аналога.
- Руководитель владельца системы подтверждает, что риск ему понятен.
- Строка попадает в перечень со статусом
exceptionи датой. В календаре — напоминание за неделю до окончания.
Исключение без даты пересмотра не заводите. Риск «поставили на неделю, забыли на год»: программа остаётся с дырами и без учёта. По истечении срока либо включаете в разрешённое, либо снимаете.
Как сверить с хостами
Раз в месяц наложите CSV учёта пакетов на перечень. Всё, чего нет ни в разрешённом, ни в исключениях, — очередь на разбор, а не «так исторически». Начните с серверов с персональными данными и с узлов из интернета, не со всех рабочих станций сразу.
Техническая блокировка запуска (политики Windows, ограничения Linux) имеет смысл, когда перечень уже совпадает с реальностью хотя бы на критичных узлах. Иначе политика только мешает работе и её обходят.
Диагностика
| Симптом | Причина и что делать |
|---|---|
| Список есть, ставят что угодно | Нет сверки и нет отказа. Назначьте дату сверки и один канал заявки |
| Исключений больше, чем разрешённых строк | Перечень не догоняет практику. Перенесите повторяющиеся исключения в разрешённое или запретите класс |
| Запретили мессенджер, им пользуются в браузере | Закрыли пакет, не закрыли сервис. Допишите класс «веб-сервисы» и правило для SaaS: ПДн в облаке |
| Администратор ставит «как на домашнем ПК» | Нет согласованных источников. Вернитесь к проверке репозиториев и сумм |
Где это в модели зрелости
Материал относится к направлению «Управление ИТ-активами» (хаб: управление ИТ-активами, карта: карта зрелости). Гигиена здесь — явный разрешённый и запрещённый набор и оформленные исключения, а не продукт контроля запуска. Сверка с установленным ПО замыкает контур: источник, имя программы, фактический пакет на сервере.
Как проверить
- Есть актуальный файл перечня с полями статуса и владельца.
- У каждого исключения заполнена дата окончания, просроченных нет.
- Последняя сверка с учётом пакетов не старше месяца хотя бы для серверов с внешним доступом.
- Запрещённый класс нельзя поставить «потому что в репозитории дистрибутива есть» без заявки.
- Новая установка прикладной программы проходит через заявку или уже есть в разрешённом списке.
Источники
- CIS Controls v8.1, контроль 2: учитывать ПО так, чтобы ставилось только разрешённое. Это не закон РФ: cisecurity.org.
- NIST Cybersecurity Framework 2.0, учёт активов. Это не закон РФ: nist.gov/cyberframework.
- Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.


















