Белые списки авторизованного программного обеспечения
Проактивная защита от неавторизованного ПО через технические средства контроля
Белый список, это больше, чем просто политика безопасности. Это архитектурный принцип, при котором система разрешает выполнение только заранее известных и проверенных приложений. Вместо того чтобы постоянно обновлять сигнатуры для блокировки нового вредоносного ПО, вы определяете узкий круг доверенного кода. Этот подход переворачивает классическую модель защиты с ног на голову и резко сужает пространство для атаки.
Реализация белых списков часто встречает сопротивление из-за кажущейся сложности администрирования. Но в долгосрочной перспективе этот метод снижает операционные риски, связанные с несанкционированным софтом, и упрощает инвентаризацию.
Требования регуляторов к белым спискам ПО
Подход «белого списка» прямо соответствует ряду требований в области защиты информации. Он является технической реализацией принципа минимально необходимых прав.
Ключевое требование можно сформулировать так: необходимо использовать технические средства контроля (например, списки разрешенных приложений), чтобы гарантировать исполнение исключительно авторизованного программного обеспечения. Проверка и актуализация этого списка должны проводиться не реже чем раз в два года, а в активных средах — значительно чаще.
На практике это выливается в два основных правила:
- Пользователи могут запускать ПО только из утвержденного перечня.
- Сам перечень авторизованных программ должен регулярно пересматриваться и обновляться — как минимум раз в полгода, а лучше при каждом изменении ИТ-ландшафта.
Организация репозитория авторизованного ПО
Перед технической настройкой нужна организационная основа. Централизованный репозиторий, это фундамент, без которого система белых списков превратится в хаос.
Сетевая директория для хранения ПО
Создайте общую сетевую папку или специализированное хранилище (вроде корпоративного Software Center), где будут размещаться установочные пакеты программ, разрешенных к использованию. Это исключает установку с непроверенных носителей или из интернета.
Структура по подразделениям
Организуйте внутреннюю структуру репозитория в соответствии с отделами компании. Отдел бухгалтерии получает доступ только к своему набору финансовых и офисных программ, отдел разработки — к своим инструментам.
Функциональная классификация
Помимо структуры по отделам, полезно группировать программы по их назначению: офисные пакеты, графические редакторы, средства аналитики, служебные утилиты, средства защиты. Это упрощает поиск и управление жизненным циклом ПО.
Инструкции администратора для установки ПО
Каждый программный пакет в репозитории должен сопровождаться стандартизированной инструкцией по установке. Это критически важно для воспроизводимости и безопасности процесса.
Обязательные элементы такой инструкции:
- Название программы и точная версия — для однозначной идентификации.
- Краткое функциональное описание — зачем нужна эта программа.
- Детальные шаги установки — пошаговый процесс, желательно со скриншотами ключевых этапов.
- Настройки безопасности — какие права доступа требуются, нужно ли создавать сервисные учетные записи, как ограничить функционал для рядового пользователя.
- Метод проверки установки — как администратор может убедиться, что программа установилась корректно и готова к работе.
Особое внимание следует уделять программам для ограниченного внутреннего использования, которые могут иметь нестандартные процедуры инсталляции.
Ограничения безопасности и политика ограниченного использования программ
Само по себе наличие репозитория не предотвращает запуск стороннего кода. Нужны технические барьеры.
Риски установки без прав администратора
Многие обходные пути не требуют повышенных привилегий:
- Microsoft Store и другие магазины приложений.
- Портативные (portable) версии программ, запускаемые из пользовательских папок.
- Скрипты (.bat, .ps1, .vbs, .js) и исполняемые файлы, скачанные из интернета.
- Использование командной строки или PowerShell для запуска неавторизованного кода.
Правила настройки Software Restriction Policies (SRP)
Для базовой реализации белых списков в среде Windows можно использовать Software Restriction Policies (Политики ограниченного использования программ). Их основная идея:
- Разрешить запуск приложений только из системных и доверенных директорий.
- Ограничить или заблокировать доступ к командной строке (cmd.exe).
- Заблокировать выполнение сценариев PowerShell.
- Запретить редактирование реестра с помощью regedit.exe.
Разрешенными для запуска обычно назначаются стандартные системные пути:
%Windir% %Windir%system32 C:Program Files C:Program Files (x86)
А также пути к сетевому репозиторию авторизованного ПО.
Настройка групповых политик для реализации белого списка
Политики SRP и дополнительные ограничения настраиваются через оснастку «Управление групповой политикой».
Ограничение доступа к инструментам обхода
- Командная строка: Конфигурация пользователя → Политики → Административные шаблоны → Система → Запретить доступ к командной строке.
- PowerShell: Конфигурация пользователя → Политики → Административные шаблоны → Система → Не запускать указанные приложения Windows (добавить powershell.exe, powershell_ise.exe).
- Редактор реестра: Конфигурация пользователя → Политики → Административные шаблоны → Система → Запретить доступ к средствам редактирования реестра.
Путь настройки SRP политик
Конфигурация компьютера → Параметры Windows → Параметры безопасности → Политики ограниченного использования программ → Дополнительные правила.
Переключение в режим белого списка
В узле «Уровни безопасности» необходимо установить уровень «Запрещено» в качестве значения по умолчанию. После этого все программы по умолчанию будут блокироваться, и нужно будет явно разрешить выполнение для путей из белого списка, добавив соответствующие правила.
Использование переменных реестра в правилах
Для большей гибкости и переносимости правил между разными системами в путях можно использовать переменные реестра. Это позволяет корректно обрабатывать пути на системах с нестандартной структурой дисков.
%HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionSystemRoot% %HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionProgramFilesDir% %HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionCommonFilesDir% %HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionCommonFilesDir (x86)% %HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionCommonW6432Dir% %HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionProgramFilesDir (x86)% %HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionProgramW6432Dir%
Рекомендации по усилению защиты: переход к AppLocker
Software Restriction Policies — устаревшая технология, которая в современных версиях Windows помечена как нерекомендуемая. Её основные недостатки: относительно простой обход через переименование файлов или использование альтернативных путей, а также отсутствие детального аудита.
Для надежной реализации белых списков рекомендуется использовать AppLocker. Он предоставляет более гибкие и безопасные механизмы контроля, позволяя создавать правила не только по пути к файлу, но и по издателю (цифровой подписи), версии продукта и хэшу файла. Это значительно усложняет обход защиты.
Ключевые этапы внедрения системы белых списков
- Создание и структурирование централизованного репозитория авторизованного ПО.
- Разработка стандартизированных процедур и инструкций для добавления нового ПО в репозиторий и его установки.
- Настройка политик ограничения выполнения (SRP для совместимости или AppLocker для современных систем).
- Ограничение доступа к инструментам обхода — командная строка, PowerShell, редактор реестра.
- Установка регулярного процесса пересмотра и обновления белых списков и репозитория.
- Настройка мониторинга и оповещений о попытках запуска неавторизованного кода для оперативного реагирования.
Внедрение белых списков, это не единовременная настройка, а процесс, который меняет культуру управления программным обеспечением в организации. Он требует первоначальных усилий, но в результате создает предсказуемую и контролируемую среду, где каждая исполняемая программа имеет известное происхождение и утвержденное назначение.