Контроль выполнения скриптов с белыми списками

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

От теории к принудительному исполнению: как белые списки становятся основой контроля

Скрипты — это фундаментальная автоматизация современной ИТ-инфраструктуры, от развертывания конфигураций до обработки данных. Эта же автоматизация становится главным вектором атаки, когда злоумышленник получает возможность запустить произвольный код. Вместо бесконечной игры в «кошки-мышки» с новыми вредоносными образцами, белый список (allowlist) переворачивает модель безопасности: запрещено всё, что явно не разрешено. Для организаций, попадающих под действие 152-ФЗ и требований ФСТЭК, это не рекомендация, а обязательный элемент защиты систем обработки персональных данных.

Суть белого списка: почему черный список проигрывает

Черный список блокирует известные угрозы, полагаясь на реактивное обновление сигнатур. Он беспомощен перед скриптовыми атаками «из живых систем» (Living off the Land), когда злоумышленники используют легитимные инструменты администрирования, такие как PowerShell или Python, для своих целей. Белый список, напротив, действует на опережение: в системе может выполняться только код, прошедший проверку и включенный в авторизованный реестр. Это кардинально сужает поверхность атаки.

Преимущества белого списка	Риски при его отсутствии
Защита от неизвестных и zero-day угроз, использующих скрипты	Выполнение вредоносных скриптов, маскирующихся под легитимные задачи
Предотвращение случайного или несанкционированного запуска кода	Атаки типа Living off the Land с использованием встроенных интерпретаторов
Четкий контроль и аудит любых изменений в инфраструктуре через код	Несанкционированная автоматизация атак, усложняющая детектирование
Формализация процессов, прямое соответствие требованиям регуляторов (ФСТЭК, 152-ФЗ)	Прямые нарушения требований по контролю исполняемого кода
Сокращение «шума» в системах мониторинга, фокус на реальных аномалиях	Увеличение времени обнаружения и реагирования на инциденты

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

Технические механизмы: от подписи до принудительного контроля

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

Цифровая подпись как гарант целостности и авторства

Цифровая подпись для скрипта — это не просто «штамп». Это криптографическое доказательство того, что код не изменялся после подписания доверенным издателем и что издатель действительно тот, за кого себя выдает. Система при попытке выполнения проводит несколько проверок:

Действительность и неизмененность цепочки сертификатов, удостоверяющих издателя.
Соответствие криптографического хеша (например, SHA-256) содержимого файла значению, зашифрованному в подписи.
Отсутствие аннулирования сертификата через списки отзыва (CRL) или онлайн-протокол (OCSP).
Наличие у сертификата правильного назначения (Extended Key Usage) — для подписи кода.

В PowerShell это реализуется политикой выполнения:

Set-ExecutionPolicy -ExecutionPolicy AllSigned -Scope LocalMachine

Эта команда требует, чтобы все загруженные сценарии PowerShell были подписаны доверенным сертификатом.

Принудительный контроль на уровне операционной системы

Подпись — это проверка «авторства», но не политика «разрешения». За политику отвечают механизмы принудительного контроля доступа:

AppLocker (Windows): позволяет создавать правила на основе пути к файлу, цифровой подписи издателя или хеша файла. Можно запретить выполнение интерпретаторов (powershell.exe, python.exe) из всех мест, кроме разрешенных, или разрешить выполнение только конкретных подписанных скриптов.
SELinux/AppArmor (Linux): реализуют мандатный контроль доступа, где политики могут строго ограничивать, какой процесс, с какими метками, может исполнить файл с определенными атрибутами.

<!— ИЗОБРАЖЕНИЕ: Скриншот консоли Windows с выводом команд Get-AppLockerPolicy -Effective и Test-AppLockerPolicy, демонстрирующий проверку скрипта (ошибка: Ошибка API генерации изображения: HTTP 503) —>.

Интеграция в CI/CD: безопасность как часть пайплайна

Чтобы белый список не тормозил разработку, его процессы должны быть автоматизированы и встроены в цикл поставки:

Автоматическое подписание скрипта происходит только после успешного прохождения всех этапов пайплайна: статического анализа кода (SAST), проверки зависимостей, unit-тестов.
Криптографические ключи для подписи хранятся не на CI-сервере, а в специализированных хранилищах (HashiCorp Vault, облачные аналоги), доступ к которым строго аудируется.
Факт подписания и метаданные скрипта автоматически регистрируются в служебном реестре (например, в базе данных CMDB).
Политики AppLocker могут автоматически обновляться через системы управления конфигурациями (Ansible, Chef) или групповые политики на основе данных из этого реестра.

Алгоритм практического внедрения: от аудита до мониторинга

Резкий переход на белые списки парализует работу. Внедрение должно быть поэтапным и основанным на данных.

1. Инвентаризация и аудит реальной активности

Сначала нужно понять, что уже работает. Используйте не только статический поиск файлов (Get-ChildItem, find), но и динамический аудит:

Включите детальное логирование событий выполнения процессов (Windows Event ID 4688, Linux auditd с правилами для execve).
Проанализируйте журналы EDR-систем (Endpoint Detection and Response) за последние несколько месяцев.
Соберите данные: какие интерпретаторы запускаются, откуда, кем, с какими аргументами.

Результат — не просто список файлов, а карта реального использования скриптов в инфраструктуре.

2. Классификация, проверка и создание исходного белого списка

Полученный список скриптов необходимо верифицировать:

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

3. Внедрение контроля в режиме аудита

Не активируйте политики блокировки сразу. Настройте AppLocker или SELinux в режиме аудита (Audit mode). В этом режиме система не блокирует выполнение, но регистрирует в логах все события, которые были бы заблокированы при включенной политике. Это выявит ложные срабатывания и скрытые зависимости, не отраженные в вашей инвентаризации.

4. Формализация процесса добавления нового скрипта

Создайте четкий и, по возможности, автоматизированный регламент. Стандартный путь нового скрипта:

Разработка и размещение в контролируемом репозитории (Git).
Автоматический запуск пайплайна: проверка кода, тестирование.
После успеха — автоматическое подписание сертификатом, доверенным в инфраструктуре.
Автоматическая регистрация в реестре и, при необходимости, обновление политик AppLocker.
Деплой в целевую среду.

Ответственность за каждый этап должна быть закреплена.

5. Мониторинг, реагирование и постоянное совершенствование

После включения политик блокировки работа не заканчивается:

Настройте оповещения из SIEM на попытки выполнения запрещенных скриптов — это индикатор потенциальной атаки или ошибки в процессах.
Ведите журнал всех успешных выполнений для аудита и расследования инцидентов.
Регулярно пересматривайте и очищайте белый список, удаляя устаревшие скрипты.
Проводите тесты на проникновение, целенаправленно пытаясь обойти собственные политики.

Дополнительные меры для критичных сред

Изоляция: Запуск скриптов с высокими привилегиями в изолированных контейнерах или на выделенных хостах с ограниченным сетевым доступом.
Расширенный мониторинг: Отслеживание создания скриптов во временных директориях, детектирование обфусцированного кода (base64, символьные замены), анализ нетипичных цепочек процессов (например, office.exe → powershell.exe).
Контроль прав: Строгое управление доступом к директориям, где хранятся авторизованные скрипты, и к самим интерпретаторам.

Принципы успешной реализации

Поэтапность: От аудита и тестовой среды к критичным системам, затем ко всей инфраструктуре.
Автоматизация и удобство: Если процесс добавления легитимного скрипта занимает недели и требует десятков согласований, сотрудники найдут способы его обойти. Автоматизируйте рутину.
Прозрачность и документирование: Каждый скрипт в белом списке должен иметь владельца, назначение и срок «годности». Все изменения в политиках и инциденты блокировки должны журналироваться.

Таким образом, белый список скриптов — это не статичный «забор», а динамичная система управления жизненным циклом исполняемого кода. Его ценность — в создании контролируемого, аудируемого и безопасного процесса, где каждый запущенный скрипт является не потенциальной угрозой, а легитимной, проверенной операцией. Это фундаментальный шаг для соответствия не только букве требований 152-ФЗ и ФСТЭК, но и их духу — минимизации рисков за счет архитектурных, а не только компенсирующих мер защиты.