Подробный гайд: Настройка замкнутой программной среды в ПАК Dallas Lock - Часть 1

Подробный гайд: Настройка замкнутой программной среды в ПАК Dallas Lock - Часть 1

1. Что такое ЗПС в контексте Dallas Lock

Замкнутая программная среда — это режим защиты, при котором на защищаемых компьютерах разрешен запуск только заранее одобренных программ, компонентов, скриптов, библиотек или модулей. Все остальное либо блокируется, либо регистрируется в режиме аудита.

В практике применения Dallas Lock ЗПС обычно включает:

1. Контроль запуска исполняемых файлов.
2. Контроль запуска скриптов и интерпретаторов, если поддерживается.
3. Контроль установки и обновления программ.
4. Запрет запуска из небезопасных каталогов: %TEMP%, %APPDATA%, съемные носители, сетевые папки с правом записи.
5. Использование цифровых подписей, хэшей и контролируемых путей.
6. Журналирование попыток запуска.
7. Применение политики даже при временной недоступности сервера управления, если агент кэширует правила.

---

---

---

Главный принцип ЗПС:

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

---

2. Когда это нужно и что дает

Настройка ЗПС в Dallas Lock применяется, если необходимо:

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

ЗПС особенно эффективна в связке с другими механизмами Dallas Lock:

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

---

3. Архитектура решения

Упрощенно схема выглядит так:

Администратор
      ↓
Консоль администрирования Dallas Lock
      ↓
Сервер управления / хранилище политик
      ↓
Агенты на компьютерах
      ↓
Локальное применение правил ЗПС:
- разрешить запуск
- запретить запуск
- зарегистрировать событие

Важно учитывать:

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

---

4. Подготовка к внедрению

Это самый важный этап. Ошибки при ЗПС чаще всего возникают не из-за самой настройки, а из-за плохой подготовки.

4.1. Определите область внедрения

Разделите инфраструктуру на группы:

1. Тестовая группа.
2. Пилотная группа.
3. Обычные пользователи.
4. Привилегированные рабочие места.
5. Серверы, если для них тоже требуется ЗПС.
6. Специализированные АРМ, технологические и производственные системы.

Не включайте ЗПС сразу на всю организацию.

---

4.2. Проведите инвентаризацию ПО

Нужно понять, какие программы реально используются.

Соберите данные:

• исполняемые файлы .exe;
• библиотеки .dll, если контролируются;
• скрипты .ps1, .vbs, .js, .bat, .cmd, .py, .jar — в зависимости от поддерживаемых типов;
• установщики .msi, .exe;
• службы;
• драйверы, если включен контроль драйверов;
• ПО с автоматическим обновлением;
• портативные утилиты;
• внутренние самописные программы.

В Dallas Lock для этого можно использовать:

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

Рекомендуемый срок аудита перед боевым режимом:

• небольшой офис: 1–2 недели;
• крупная инфраструктура: 2–4 недели;
• сложное специализированное ПО: до 1 месяца и дольше.

---

4.3. Определите, кто и как будет администрировать ЗПС

Нужно назначить роли:

Роль	Ответственность
Владелец ЗПС	принимает решения о включении блокировки, утверждает исключения
Администратор Dallas Lock	настраивает политики, правила, агенты
Администратор ИБ	анализирует события, согласует исключения
Администратор ОС/инфраструктуры	помогает с ПО, установками, обновлениями
Служба поддержки	принимает заявки пользователей о блокировках

---

---

---

4.4. Подготовьте аварийный доступ

До включения блокировки обязательно подготовьте:

1. Учетную запись аварийного администратора.
2. Локальный административный доступ к критичным машинам.
3. Резервную копию политик.
4. Экспорт правил ЗПС.
5. Понимание, как временно перевести политику в режим аудита.
6. Процедуру срочного добавления программы в исключения.
7. Контакты вендора или поддержки, если используется критичная инфраструктура.

---

5. Рекомендуемая модель правил

Для ЗПС лучше использовать комбинацию типов правил.

Приоритет типов правил

Приоритет	Тип правила	Когда использовать
1	Цифровая подпись / издатель	Для ПО с валидной подписью вендора
2	Хэш файла	Для неподписанных, но неизменяемых файлов
3	Путь	Только если каталог защищен от записи пользователями
4	Исключения	Точечные, контролируемые случаи

---

5.1. Правила по цифровой подписи

Это самый предпочтительный вариант.

Пример:

• издатель: Microsoft Windows;
• продукт: Windows Operating System;
• версия: разрешить нужную ветку или использовать осторожный диапазон.

Преимущества:

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

Риски:

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

---

5.2. Правила по хэшу

Используются для:

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

Пример:

Файл: utility.exe
SHA-256: 9F86D081884C7D659A2FEAA0C55AD015...

Плюсы:

• высокая точность;
• защита от подмены файла.

Минусы:

• любое обновление файла меняет хэш;
• требуется процесс сопровождения.

---

5.3. Правила по пути

Самый рискованный тип.

Пример плохого правила:

Разрешить все из %APPDATA%\Tools

Это опасно, если пользователь может сам писать в этот каталог.

Пример относительно допустимого правила:

Разрешить только из:
C:\Program Files\Vendor\App\

При условии:

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

---

6. Пошаговая настройка ЗПС в Dallas Lock

Ниже — практическая последовательность. Названия пунктов могут отличаться в зависимости от версии, но логика сохраняется.

---

Шаг 1. Проверьте установку компонентов

Убедитесь, что:

1. Сервер управления Dallas Lock установлен и доступен.
2. Консоль администрирования подключается к серверу.
3. Агенты установлены на целевых компьютерах.
4. Агенты видны в консоли.
5. Агенты получают политики.
6. Время на сервере, рабочих станциях и контроллерах синхронизировано.
7. Используется актуальная версия Dallas Lock и агентов.

Проверьте базовые вещи:

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

---

Шаг 2. Создайте отдельную политику или тестовый контур

Не меняйте сразу основную политику.

Сделайте:

1. Тестовую группу компьютеров.
2. Отдельную политику ЗПС для этой группы.
3. Отдельный набор правил.
4. Режим аудита.

Например:

Группа: ПК-Тест-ЗПС
Политика: ЗПС-Аудит
Режим: Только регистрация, без блокировки

---

Шаг 3. Включите режим аудита

Найдите раздел, связанный с контролем приложений или замкнутой программной средой.

Обычно это может быть:

Политики безопасности
→ Контроль приложений
→ Замкнутая программная среда

или:

Политика
→ Правила запуска программ
→ Режим ЗПС

---

---

Установите режим:

Только аудит / регистрация событий / не блокировать

Цель режима аудита:

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

---

Шаг 4. Соберите журнал запусков

После 1–2 недель аудита проанализируйте события.

Нужно получить список:

1. Программ, которые реально запускаются.
2. Программ, которые запускаются только у отдельных пользователей.
3. Скриптов и интерпретаторов.
4. Обновляемых программ.
5. Программ с сетевых дисков.
6. Программ со съемных носителей.
7. Программ из %TEMP%, %APPDATA%, %LOCALAPPDATA%.

Сформируйте таблицу:

Программа	Путь	Подпись	Хэш	Кто использует	Основание	Решение
1C Enterprise	C:\Program Files\1cv8\...	есть	—	Бухгалтерия	рабочее ПО	разрешить по подписи
PortableTool.exe	D:\Soft\PortableTool.exe	нет	есть	ИТ	исключение	хэш, запрет копирования
updater.exe	%LOCALAPPDATA%\App\updater.exe	есть	—	маркетинг	автообновление	перенести в Program Files или запретить

---

Шаг 5. Сформируйте доверенный перечень

Рекомендуется начинать с базового набора:

5.1. Компоненты ОС

Разрешите критичные компоненты Windows, если они поддерживаются политикой:

• системные компоненты, подписанные Microsoft Windows;
• необходимые компоненты установщика;
• службы, которые нужны для работы агента и ОС.

Но не делайте чрезмерно широкое правило вида:

Разрешить все, подписанное Microsoft

без дополнительных ограничений, если это может разрешить нежелательные компоненты или сценарии.

---

5.2. Драйверы и системные модули

Если Dallas Lock контролирует драйверы или модули ядра, отдельно продумайте:

• драйверы оборудования;
• драйверы виртуализации;
• антивирусные компоненты, если есть;
• драйверы Dallas Lock;
• драйверы принтеров, сканеров, токенов, смарт-карт.

Для драйверов особенно опасны широкие правила по пути. Лучше использовать подпись или хэш.

---

5.3. Офисное и прикладное ПО

Внесите:

• Microsoft Office или альтернативный офис;
• браузер, если разрешен;
• почтовый клиент;
• 1С, SAP, ЭДО, банковские клиенты;
• криптопровайдеры;
• средства электронной подписи;
• внутренние приложения;
• утилиты администрирования.

---

5.4. Скрипты и интерпретаторы

Если Dallas Lock контролирует скрипты, настройте отдельно:

• PowerShell;
• cmd;
• WSH;
• VBS;
• JS;
• BAT/CMD;
• Python;
• Java, если нужно.

Рекомендуемая стратегия:

1. Пользователям запретить запуск неподписанных скриптов.
2. Администраторам разрешать только проверенные сценарии.
3. Требовать подпись скриптов внутренним сертификатом.
4. Ограничить запуск скриптов из пользовательских каталогов.
5. Контролировать параметры интерпретаторов, если возможно.

---

Шаг 6. Создайте правила разрешения

В консоли Dallas Lock создайте правила для доверенного ПО.

Общий порядок:

1. Открыть раздел правил ЗПС / контроля приложений.
2. Создать новое правило.
3. Выбрать тип: подпись, хэш, путь или комбинированное.
4. Указать объект: файл, папку, издателя, сертификат, хэш.
5. Выбрать действие: разрешить.
6. Задать область применения: пользователь, группа, компьютер.
7. Проверить правило на тестовой машине.
8. Сохранить и применить политику.

---

Шаг 7. Создайте правила запрета

Даже при модели «по умолчанию запрещено» могут понадобиться явные запреты.

Например:

Что запретить	Почему
%TEMP%	частый запуск вредоносных файлов
%APPDATA%	пользовательская запись
%LOCALAPPDATA%\Temp	временные файлы
Съемные носители	запуск с флешек
Сетевые папки с записью	копирование и запуск
*.exe из загрузок браузера	риск вредоносного ПО
Неподписанные скрипты	высокий риск
Портативные утилиты вне утвержденных каталогов	неконтролируемое ПО

---

---

Пример явного запрета:

Путь: %TEMP%\*\*.exe
Действие: запретить

или:

Все исполняемые файлы на съемных носителях
Действие: запретить

---

Шаг 8. Настройте исключения

Исключения должны быть только контролируемыми.

Плохие исключения:

Разрешить все из %USERPROFILE%
Разрешить все .exe в папке Загрузки
Разрешить все скрипты для всех пользователей

Хорошие исключения:

Разрешить конкретный хэш файла для конкретной группы ПК.
Разрешить установку конкретного подписанного пакета.
Разрешить временное выполнение установщика по заявке с ограничением по времени.

Для каждого исключения фиксируйте:

• кто запросил;
• зачем;
• кто согласовал;
• срок действия;
• риск;
• способ проверки;
• дату пересмотра.

---

Шаг 9. Проверьте поведение при недоступности сервера

Нужно определить, что делает агент, если сервер управления недоступен.

Возможные сценарии:

1. Использовать последнюю полученную политику.
2. Перейти в режим аудита.
3. Заблокировать запуск неизвестных программ.
4. Разрешить только базовые компоненты.

Для большинства рабочих мест безопаснее:

Применять последнюю известную политику ЗПС.

Но это зависит от требований вашей организации.

Проверьте:

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

---

Шаг 10. Тестирование на пилотной группе

После подготовки правил переведите пилотную группу в режим аудита или тестовой блокировки.

Проверьте:

1. Запуск разрешенных программ.
2. Запуск запрещенных программ.
3. Установка нового ПО администратором.
4. Установка ПО пользователем, если должна быть запрещена.
5. Обновление ПО.
6. Запуск со съемного носителя.
7. Запуск из сетевой папки.
8. Запуск скриптов.
9. Перенос разрешенного файла в другой каталог.
10. Переименование запрещенного файла.
11. Подмену файла при сохранении имени.
12. Работу после перезагрузки.
13. Работу после обновления агента.
14. Работу без связи с сервером.

---

Шаг 11. Анализ ложных срабатываний

На этапе аудита и пилота смотрите события:

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

Типичные ложные срабатывания:

• программа обновилась и изменился хэш;
• программа лежит в пользовательском профиле;
• установщик запускает временный файл из %TEMP%;
• скрипт не подписан;
• компонент использует библиотеку вне доверенного каталога;
• сетевой диск воспринимается как небезопасный источник.

---

Шаг 12. Включение боевого режима

Когда в течение достаточного периода нет критичных ложных блокировок, включайте режим блокировки.

Обычно это параметр:

Режим: блокировать запрещенные запуски

или:

ЗПС: принудительное применение

Делайте поэтапно:

1. Первая небольшая группа.
2. Подразделение с понятным набором ПО.
3. Отделы с типовыми рабочими местами.
4. Сложные АРМ.
5. Серверы и инфраструктурные системы, если требуется.

---

7. Пример базовой политики ЗПС

Ниже — пример концептуальной политики. Реализация в Dallas Lock может называться иначе, но смысл такой.

7.1. Общие параметры

Режим ЗПС: включен
Поведение по умолчанию: запретить
Неизвестные программы: блокировать
Аудит: вести
Применение при отсутствии связи: последняя политика
События: отправлять на сервер управления

---

7.2. Разрешенные категории

Категория	Правило	Комментарий
ОС	Подпись компонентов Microsoft Windows	только необходимые компоненты
Агент Dallas Lock	Подпись/хэш компонентов агента	критично для работы СЗИ
Офисное ПО	Подпись вендора	например, офисный пакет
Браузер	Подпись вендора	если разрешен политикой
1С	Подпись или хэш исполняемых файлов	учитывать обновления
Криптопровайдер	Подпись/хэш	критично для ЭП
Антивирус/EDR	Подпись/хэш	если используется
Внутренние приложения	Хэш или подпись внутреннего ЦС	обязательно сопровождение
Скрипты администрирования	Подпись внутреннего сертификата	только для администраторов

---

---

---

7.3. Запрещенные категории

Категория	Действие
Запуск из %TEMP%	запретить
Запуск из %APPDATA%	запретить или сильно ограничить
Запуск со съемных носителей	запретить
Запуск из общедоступных сетевых папок	запретить
Неподписанные скрипты пользователей	запретить
Портативные утилиты вне утвержденного перечня	запретить
Исполняемые файлы, загруженные из интернета	блокировать, если не разрешены

---

8. Работа с цифровыми подписями

Правила по подписи удобны, но требуют аккуратности.

8.1. Проверяйте сертификат

Для подписанного ПО убедитесь:

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

---

8.2. Не разрешайте слишком широкие подписи

Опасно:

Разрешить все, что подписано любым сертификатом

или:

Разрешить все от издателя без проверки продукта

Лучше:

Издатель: конкретный вендор
Продукт: конкретный продукт
Диапазон версий: контролируемый

---

8.3. Учитывайте обновления

Подписанные программы могут обновляться.

Для них нужно:

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

---

9. Работа с хэшами

Хэш подходит для неподписанных и редко меняющихся файлов.

9.1. Какой хэш использовать

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

1. SHA-256 — предпочтительно.
2. SHA-1 — только если невозможно иначе, нежелательно.
3. MD5 — не использовать, если есть выбор.

---

9.2. Когда хэш уместен

Хорошо подходит:

• для внутренних утилит;
• для портативных программ;
• для специализированного ПО;
• для неизменяемых компонентов;
• для файлов без цифровой подписи.

Плохо подходит:

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

---

9.3. Учет хэшей

Ведите реестр:

Файл	Хэш	Версия	Назначение	Ответственный	Дата добавления	Дата проверки

---

10. Работа с правилами по пути

Правила по пути можно использовать только при жестком контроле каталога.

10.1. Условия безопасного правила по пути

Разрешайте путь, только если:

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

---

10.2. Примеры

Относительно безопасно:

C:\Program Files\Vendor\App\
C:\Program Files (x86)\Vendor\App\

при условии, что обычные пользователи не имеют права записи.

Небезопасно:

%USERPROFILE%\Downloads
%APPDATA%\App
%TEMP%
\\fileshare\soft

---

---

---

11. Настройка для пользовательских каталогов

Это критичный раздел ЗПС.

11.1. Запрет запуска из пользовательских папок

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

%TEMP%
%LOCALAPPDATA%\Temp
%USERPROFILE%\Downloads
%USERPROFILE%\Desktop
%APPDATA%
%LOCALAPPDATA%

Исключения должны быть точечными.

---

11.2. Особое внимание к %LOCALAPPDATA%

Многие легитимные программы устанавливаются в %LOCALAPPDATA%, но эта зона опасна, потому что пользователь часто имеет туда запись.

Для таких программ лучше:

• переустановить в Program Files, если возможно;
• использовать правило по подписи издателя и продукту;
• запретить запуск из подкаталогов, где может быть произвольный файл;
• контролировать обновления.

---

12. Скрипты и командные интерпретаторы

Если ЗПС должна быть действительно строгой, нельзя разрешать только .exe и игнорировать скрипты.

12.1. Что контролировать

• .bat
• .cmd
• .ps1
• .vbs
• .js
• .wsf
• .jar
• .py
• другие исполняемые сценарии и интерпретаторы, если поддерживаются.

---

12.2. Рекомендуемые меры

1. Пользователям запретить запуск скриптов из локальных профилей.
2. Разрешить только подписанные скрипты, если поддерживается.
3. Ограничить запуск cmd, powershell, wscript, cscript для пользователей.
4. Для администраторов разрешить сценарии из защищенного каталога.
5. Вести аудит всех запусков скриптов.
6. Контролировать сетевые скрипты, если они используются.

---

13. Установщики и обновления ПО

Это один из самых сложных участков ЗПС.

13.1. Установка ПО администратором

Рекомендуется:

• пользователи не имеют прав установки;
• установка выполняется администратором или через систему развертывания;
• установочные пакеты хранятся в защищенной папке;
• пакеты подписаны или проверены по хэшу;
• временные файлы установщика контролируются.

---

13.2. Типовая проблема

Установщик запускает временный файл из %TEMP%, а ЗПС запрещает запуск из %TEMP%.

Решения:

1. Если возможно, запускать установку с параметром, который не использует временные исполняемые файлы.
2. Разрешить конкретный подписанный установщик, но не всю папку %TEMP%.
3. Использовать хэш временного компонента, если он стабилен.
4. Переупаковать установку в корпоративный пакет.
5. Устанавливать через управляемый дистрибутив из защищенного каталога.

Не делайте постоянное правило:

Разрешить все из %TEMP%

---

13.3. Автообновление программ

Если программа обновляется сама:

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

---

Продолжение в Части 2

---

Информация предоставлена в ознакомительных целях. Применение описанных настроек в системах, должно осуществляться только после согласования с ответственными за информационную безопасность и в соответствии с требованиями ФСТЭК, ФСБ и иных уполномоченных органов.

---