Как запретить пользователям запускать конфигуратор 1С: проверенные технические способы

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Проблема несанкционированного запуска режима Конфигуратор обычными пользователями часто встает перед администраторами 1С, особенно в крупных распределенных сетях. Ситуация осложняется, если инфраструктура не использует лицензии уровня КОРП, которые позволяют штатно ограничивать функциональность на уровне рабочих серверов. В таких случаях пользователи, имея доступ к VPN и возможность самостоятельно устанавливать дистрибутивы (толстый клиент), могут заходить в конфигуратор. Даже если у них нет прав на изменение конфигурации, сам факт открытой сессии может мешать регламентным работам, обновлению базы или работе скриптов автоматизации. Для регулярного проведения регламентных процедур без участия пользователей можно использовать программу для автоматического обновления и обслуживания баз 1С.

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

Метод 1: Автоматическое завершение сессий через утилиту RAC

Проанализируем самый эффективный способ — программное отслеживание и мгновенное завершение сеансов типа Designer. Для этого нам понадобится штатная утилита rac (клиент сервера администрирования 1С). Этот метод хорош тем, что он работает на стороне сервера и не зависит от того, что установлено на компьютере пользователя.

Рассмотрим алгоритм работы скрипта автоматизации:

  1. Скрипт раз в несколько секунд опрашивает список активных сессий кластера.
  2. В полученном списке ищется параметр app-id=Designer.
  3. Если такая сессия найдена и она не принадлежит администратору (проверка по имени пользователя или IP), скрипт отправляет команду на принудительное завершение этой сессии.

Пример логики команды для получения списка сессий:

rac session --cluster=[ID_кластера] list [ID_инфобазы]

Выясним, как автоматизировать этот процесс на PowerShell для Windows-сервера:


$clusterId = "ваш-id-кластера"
$sessions = & "C:\Program Files\1cv8\current\bin\rac.exe" session --cluster=$clusterId list
# Здесь должен быть парсинг текста для поиска сессий с app-id=Designer
# Если найдена сессия с ID 'session-id-123':
& "C:\Program Files\1cv8\current\bin\rac.exe" session --cluster=$clusterId terminate --session=session-id-123

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

Метод 2: Фильтрация трафика на уровне протокола (Layer 7)

Посмотрим на ситуацию со стороны сетевой безопасности. Когда клиент 1С подключается к серверу, он обменивается пакетами данных. В самом первом пакете (рукопожатии) клиент передает информацию о типе приложения. Если ваша сеть построена на базе микросервисов или управляемых роутеров (например, Mikrotik или решения NGFW), можно настроить фильтрацию по сигнатурам.

Проанализируем структуру запроса. При попытке входа в конфигуратор в трафике передается строка, содержащая AppID=Designer. Мы можем настроить правило Firewall, которое будет анализировать содержимое пакетов на порты 1541, 1560-1591.

Для Mikrotik это может выглядеть так (упрощенно):

  1. Создаем правило в Layer7 Protocols с регулярным выражением, ищущим «Designer».
  2. В правилах Filter Rules настраиваем Action=Drop для пакетов, соответствующих этой сигнатуре, если источником не является IP-адрес программиста.

Важный момент: этот метод требует высокой производительности сетевого оборудования, так как глубокий анализ пакетов (DPI) нагружает процессор роутера.

Метод 3: Использование тонкого клиента через HTTP (публикация)

Разберем вариант, который часто ошибочно путают с использованием веб-клиента (через браузер). Речь идет о работе тонкого клиента через веб-сервер (Apache или IIS). Этот режим поддерживает все функции толстого клиента (кроме специфических низкоуровневых операций), но дает нам мощный инструмент контроля — файл публикации default.vrd.

В файле публикации можно явно запретить доступ к конфигуратору. Для этого найдем секцию описания информационной базы и добавим параметр:


<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       base="/BaseName"
       ib="Srvr=&quot;ServerName&quot;;Ref=&quot;BaseName&quot;;">
    <design enable="false"/>
</point>

Установив design enable="false", мы полностью блокируем возможность подключения в режиме конфигуратора через данный URL. Даже если у пользователя есть полные права в базе и установлен толстый клиент, попытка зайти через это соединение в конфигуратор закончится ошибкой. При этом пользователи продолжат работать в привычном интерфейсе 1С, не замечая разницы в протоколах связи.

Метод 4: Использование COM-соединения для мониторинга

Если вы предпочитаете решать задачи внутри самой экосистемы 1С, рассмотрим вариант создания внешней обработки, которая запускается на сервере под системной учетной записью. Она может использовать COM-объект V83.COMConnector для периодического мониторинга соединений.

Посмотрим на пример кода, который возвращает список активных пользователей и их режимы работы:


Соединение = Новый COMОбъект("V83.COMConnector");
Агент = Соединение.ConnectAgent("ИмяСервера");
Кластеры = Агент.GetClusters();
// Выбираем нужный кластер
РабочийПроцесс = Агент.GetWorkingProcesses(Кластеры[0])[0];
СоединениеСРабочимПроцессом = Соединение.ConnectWorkingProcess(РабочийПроцесс.HostName + ":" + РабочийПроцесс.MainPort);
// Получаем сессии
Сессии = СоединениеСРабочимПроцессом.GetInfoBaseSessions(ОписаниеИнфобазы);
Для Каждого Сессия Из Сессии Цикл
    Если Сессия.AppID = "Designer" Тогда
        СоединениеСРабочимПроцессом.TerminateSession(Сессия);
    КонецЕсли;
КонецЦикла;

Эту обработку можно поставить в планировщик задач Windows на сервере приложений, чтобы она выполнялась каждые 5 минут. Это менее оперативно, чем метод с RAC, но проще в реализации для 1С-разработчика.

Дополнительные рекомендации

Выясним, какие еще административные меры можно предпринять для минимизации рисков:

Подводя итог, можно сказать, что отсутствие лицензии КОРП — не приговор. Комбинируя мониторинг через RAC и настройку публикации через веб-сервер, вы сможете надежно защитить свою базу от нежелательных заходов в режим разработки, обеспечив стабильную работу всей системы.

← На главную