Как ограничить открытие внешних обработок и отчётов в 1С 8.3

Распространённое заблуждение: достаточно снять у роли право на открытие внешних обработок — и база защищена. На деле это закрывает только интерактивное открытие через Файл → Открыть. Обработку всё ещё можно подключить как дополнительную, вызвать из другой обработки или запустить кодом, если не ограничены остальные уровни.

Защита внешних обработок в 1С 8.3 складывается из нескольких независимых рычагов: безопасный режим ограничивает, что может сделать код; профили безопасности кластера задают рамки на уровне сервера; права ролей решают, кто вообще откроет файл .epf или .erf; защита от опасных действий предупреждает пользователя; механизм дополнительных обработок хранит доверенные файлы под контролем. Надёжнее всего включить сразу несколько — одно другое не заменяет.

Внешняя обработка — это файл с произвольным кодом. Открыв его, пользователь выполняет этот код с теми же правами, что и свои. Без ограничений обработка может удалить данные, выгрузить базу , обратиться к файловой системе или в интернет. Поэтому защита строится по принципу «запрещено всё, кроме разрешённого».

Угроза не всегда злой умысел. Чаще это обработка «от знакомого» или скачанная с форума, автор которой об опасных последствиях не думал: она массово меняет документы, пересчитывает регистры или чистит данные — и делает это в рабочей базе без копии. Ограничения ниже защищают и от вредоносного кода, и от неосторожного.

Безопасный режим: что он запрещает коду обработки

Безопасный режим — это ограничение прав исполняемого кода на время сеанса. Включается программно вызовом УстановитьБезопасныйРежим(Истина), а при подключении обработки через стандартные механизмы — соответствующим флагом. Режим действует до конца процедуры, где он установлен, либо до явного отключения.

Что блокируется в безопасном режиме:

• 🔒 привилегированный режим — вызов УстановитьПривилегированныйРежим(Истина) игнорируется, код работает только в правах текущего пользователя;
• 📁 доступ к файловой системе сервера и клиента;
• 🧩 загрузка внешних компонент;
• 🖥 запуск внешних приложений (ЗапуститьПриложение) и обращение к COM-объектам;
• 🌐 доступ к интернет-ресурсам.

Смысл в том, что даже вредоносный код в безопасном режиме не сможет выйти за пределы базы и прав пользователя. Это базовый уровень: он не мешает открыть обработку, но лишает её опасных возможностей.

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

Профили безопасности кластера: рамки на уровне сервера

В клиент-серверном варианте над безопасным режимом стоит ещё один уровень — профили безопасности. Они настраиваются администратором кластера и задают, что именно разрешено коду конкретной информационной базы: список каталогов, доступные COM-классы, внешние компоненты, приложения и интернет-адреса.

Информационной базе можно назначить два профиля:

Внутри профиля разрешения задаются по группам, и по умолчанию запрещено всё:

• 📁 каталоги файловой системы — с указанием прав на чтение и запись;
• 🧩 внешние компоненты и модули расширения, которые разрешено загружать;
• 🖥 приложения, которые код может запускать;
• 🌐 интернет-ресурсы — с протоколом, адресом и портом;
• 🔑 COM-классы;
• признак, разрешён ли коду привилегированный режим.

Настраиваются профили в консоли администрирования кластера серверов либо утилитой rac (список профилей — командой rac profile list; точный синтаксис остальных подкоманд смотрите в rac help). После назначения профиля код, который попытается выйти за разрешённые рамки, получит ошибку доступа, а не выполнится. Это и есть принцип «запрещено всё, кроме разрешённого» на уровне сервера: даже обработка без безопасного режима будет ограничена профилем базы.

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

Права ролей: кто вообще откроет внешний файл

Самый прямой рычаг — убрать у ролей два общих права конфигурации:

1. «Интерактивное открытие внешних отчётов»;
2. «Интерактивное открытие внешних обработок».

Снимаются они в конфигураторе: Общие → Роли, в правой панели у выбранной роли эти права находятся среди общих (не привязанных к объекту). Если ни одна роль пользователя их не содержит, команда открытия .epf и .erf через меню Файл → Открыть становится недоступной.

В коде наличие права проверяется функцией ПравоДоступа("ИнтерактивноеОткрытиеВнешнихОбработок") — это удобно, чтобы прятать кнопки запуска в своих формах.

Логика назначения прав: администратору и разработчику интерактивное открытие оставляют, рядовым пользователям — убирают. Всё, что им действительно нужно, выносят в доверенные дополнительные обработки.

В типовых конфигурациях роли пользователю назначаются не напрямую, а через профили групп доступа (Администрирование → Настройки пользователей и прав → Группы доступа). Поэтому проверяйте не одну роль, а весь набор профилей пользователя: достаточно одного профиля с правом открытия, чтобы запрет не сработал. Удобно завести отдельный профиль доступа для тех, кому открытие внешних файлов действительно нужно, и выдавать его точечно.

Защита от опасных действий: предупреждение платформы

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

Механизм рассчитан именно на человеческий фактор: присланный по почте или найденный в сети файл почти всегда открывают, не глядя. Лишний экран с предупреждением заставляет остановиться и задуматься, откуда взялся файл и кто его автор.

Предупреждение управляется флагом в свойствах пользователя информационной базы (список пользователей в конфигураторе или в режиме администрирования). Флаг «Защита от опасных действий» лучше держать включённым у всех, кому вообще оставили право открытия.

Доверенные обработки через справочник конфигурации

В типовых конфигурациях на БСП есть механизм дополнительных отчётов и обработок — это способ разрешить пользователям конкретные проверенные файлы, не раздавая им право открывать любые.

Как это выглядит:

1. Включите функциональную опцию в разделе Администрирование → Печатные формы, отчёты и обработки (пункт «Дополнительные отчёты и обработки»).
2. Добавьте обработку в справочник: загрузите файл .epf, укажите, в каких разделах и формах она доступна.
3. Для подключения оставьте включённым использование безопасного режима и, в клиент-серверном варианте, выберите профиль безопасности.
4. Настройте доступ — какие пользователи или группы видят команду обработки.

При загрузке файла механизм распознаёт его назначение — дополнительная обработка, отчёт, печатная форма, заполнение объекта или создание связанных документов — и предлагает настроить команды под соответствующие объекты. Для каждой команды задаётся, в каком разделе и у какой формы она появится, а также в каком режиме выполняется (клиент или сервер, в фоне или интерактивно).

Результат: файл хранится внутри базы под контролем администратора, запускается в заданных рамках, а пользователи получают только разрешённые команды. Присланный со стороны файл в этот список не попадёт, пока его не добавит администратор. Когда обработку обновляют, старую версию в справочнике заменяют новой — это даёт единую точку контроля: в базе всегда ровно тот код, который утверждён, а не копии разных версий на рабочих столах пользователей.

Про «цифровую подпись»: платформа не проверяет электронную подпись самого файла .epf при открытии. Доверие выстраивается не подписью файла, а белым списком — тем, что обработка внесена в справочник доверенных и подключается в безопасном режиме. Хранение внутри базы и ограниченный доступ к справочнику и есть механизм контроля подлинности.

Аудит: кто и когда подключал обработку

Защиту нужно не только настроить, но и наблюдать. Основной инструмент — журнал регистрации (Администрирование → Поддержка и обслуживание → Журнал регистрации в типовых, либо просмотр журнала в конфигураторе).

Что полезно отслеживать:

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

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

Для глубокого разбора на сервере настраивается технологический журнал (logcfg.xml) — он пишет больше низкоуровневых событий (вызовы, обращения к серверу, исключения), но быстро растёт в объёме, поэтому включайте его точечно и на время расследования, а потом отключайте.

Отдельно договоритесь о регламенте: кто и как часто просматривает журнал, какие события считаются поводом разобраться. Журнал, в который никто не заглядывает, защитой не является — он помогает только тогда, когда его читают.

Типичные ошибки настройки

Сняли право, но обработки всё равно запускаются. Чаще всего у пользователя осталась роль с этим правом (например, в составе профиля доступа) или обработка подключается как дополнительная — проверьте оба пути, а не только меню Файл.

Отключили защиту от опасных действий «чтобы не мешала». Это открывает запуск любого присланного файла в один клик. Правильнее внести обработку в доверенные, а предупреждение оставить.

Забыли про безопасный режим при подключении. Если дополнительная обработка добавлена без безопасного режима, её код получает полный доступ. Для сторонних файлов безопасный режим должен быть включён.

Профиль безопасности задан слишком широко. Разрешённый каталог «весь диск» или привилегированный режим в профиле сводят защиту на нет. Разрешайте только конкретные каталоги и адреса, которые реально нужны.

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

Защиту настроили один раз и забыли. Со временем появляются новые пользователи, профили доступа и обработки. Раз в несколько месяцев имеет смысл пройтись по списку: у кого осталось право открытия, какие обработки числятся доверенными, не работает ли какая-то из них без безопасного режима. Разовая настройка без пересмотра постепенно «протекает».

Частые вопросы