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

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

Согласованный источник отвечает, откуда файл имеет право появиться. Перечень отвечает, какое имя программы вообще можно ставить, даже из правильного репозитория. Без перечня «официальный пакет» с торрент-клиентом на сервере с персональными данными формально взят из 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 — обязателен для исключения.

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

Как оформить исключение

  1. Заявитель пишет, зачем программа, на каких узлах, откуда будет ставиться, до какой даты.
  2. Ответственный за ИБ проверяет источник и класс: нет ли уже разрешённого аналога.
  3. Руководитель владельца системы подтверждает, что риск ему понятен.
  4. Строка попадает в перечень со статусом exception и датой. В календаре — напоминание за неделю до окончания.

Исключение без даты пересмотра не заводите. Риск «поставили на неделю, забыли на год»: программа остаётся с дырами и без учёта. По истечении срока либо включаете в разрешённое, либо снимаете.

Как сверить с хостами

Раз в месяц наложите CSV учёта пакетов на перечень. Всё, чего нет ни в разрешённом, ни в исключениях, — очередь на разбор, а не «так исторически». Начните с серверов с персональными данными и с узлов из интернета, не со всех рабочих станций сразу.

Техническая блокировка запуска (политики Windows, ограничения Linux) имеет смысл, когда перечень уже совпадает с реальностью хотя бы на критичных узлах. Иначе политика только мешает работе и её обходят.

Диагностика

Симптом Причина и что делать
Список есть, ставят что угодно Нет сверки и нет отказа. Назначьте дату сверки и один канал заявки
Исключений больше, чем разрешённых строк Перечень не догоняет практику. Перенесите повторяющиеся исключения в разрешённое или запретите класс
Запретили мессенджер, им пользуются в браузере Закрыли пакет, не закрыли сервис. Допишите класс «веб-сервисы» и правило для SaaS: ПДн в облаке
Администратор ставит «как на домашнем ПК» Нет согласованных источников. Вернитесь к проверке репозиториев и сумм

Где это в модели зрелости

Материал относится к направлению «Управление ИТ-активами» (хаб: управление ИТ-активами, карта: карта зрелости). Гигиена здесь — явный разрешённый и запрещённый набор и оформленные исключения, а не продукт контроля запуска. Сверка с установленным ПО замыкает контур: источник, имя программы, фактический пакет на сервере.

Как проверить

  1. Есть актуальный файл перечня с полями статуса и владельца.
  2. У каждого исключения заполнена дата окончания, просроченных нет.
  3. Последняя сверка с учётом пакетов не старше месяца хотя бы для серверов с внешним доступом.
  4. Запрещённый класс нельзя поставить «потому что в репозитории дистрибутива есть» без заявки.
  5. Новая установка прикладной программы проходит через заявку или уже есть в разрешённом списке.

Источники

  • CIS Controls v8.1, контроль 2: учитывать ПО так, чтобы ставилось только разрешённое. Это не закон РФ: cisecurity.org.
  • NIST Cybersecurity Framework 2.0, учёт активов. Это не закон РФ: nist.gov/cyberframework.
  • Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.

Комментарии закрыты.