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

Проверить, кто может открыть конфигуратор 1С, проще всего через пункт «Администрирование» → «Пользователи»: если у сотрудника в ролях стоит «Администратор системы» или «Полные права», он способен войти в режим разработки и изменить код, структуру данных или настройки доступа. Оставить такие права широкому кругу пользователей — значит рисковать: даже случайное изменение в конфигураторе может остановить работу базы, повредить данные и потребовать дорогостоящего восстановления. Чтобы этого избежать, доступ к конфигуратору нужно заранее закрыть всем, кроме узкого круга доверенных специалистов.

Запретить открытие конфигуратора в 1С можно несколькими способами: через права ролей внутри самой конфигурации, через настройки на уровне СУБД и кластера серверов 1С, а также организационными мерами — ограничением доступа к файлам базы и установке паролей. Выбор метода зависит от режима работы базы (файловый или клиент-серверный) и от того, насколько жёсткий контроль требуется.

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

Как устроен запуск конфигуратора и что именно нужно блокировать

Конфигуратор — это отдельный режим запуска платформы 1С:Предприятие, предназначенный для разработки и администрирования. Запускается он тем же исполняемым файлом платформы, но с параметром DESIGNER (в русской версии — «Конфигуратор»). Любой пользователь, у которого установлена платформа и есть доступ к базе, теоретически может попробовать открыть конфигуратор.

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

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

Настройка ролей: убираем право на работу с конфигуратором

Основной и самый надёжный механизм — настройка ролей. В типовых конфигурациях (например, «1С:Бухгалтерия», «1С:Управление торговлей») уже предусмотрены готовые профили групп доступа, и полные права выдаются отдельно. Задача администратора — убедиться, что у обычных пользователей нет роли с полными правами.

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

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

1. 1
   Откройте список пользователей в конфигураторе или в режиме предприятия
2. 2
   Проверьте, какие роли и профили назначены каждому пользователю
3. 3
   Уберите роли с полными и административными правами у всех, кроме администраторов
4. 4
   Для самописных конфигураций проверьте системные права в свойствах ролей
5. 5
   Войдите под обычным пользователем и убедитесь, что конфигуратор не даёт внести изменения

Запрет запуска конфигуратора в файловом режиме

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

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

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

Защита в клиент-серверном режиме

В клиент-серверном варианте (1С:Предприятие + MS SQL Server, PostgreSQL или другая СУБД) возможностей для защиты заметно больше. Пользователи подключаются к базе через сервер 1С и не имеют прямого доступа к файлам данных, что само по себе снижает риск.

На уровне СУБД создайте отдельную учётную запись, под которой сервер 1С обращается к базе, и не сообщайте её пароль никому, кроме администратора. Пользователь, знающий пароль от СУБД, может подключиться к базе напрямую или через конфигуратор с особыми параметрами, минуя часть ограничений.

Дополнительно в консоли кластера серверов 1С можно настроить административный доступ: установить пароль администратора кластера, ограничить список тех, кто может управлять сервером. Это защитит от несанкционированных действий вроде блокировки сеансов или изменения параметров информационной базы.

Сравнение режимов работы

Файловый режим

Защита опирается на пароли пользователей 1С и права доступа к папке с файлом базы. Подходит для небольших баз, уязвим при свободном доступе к файлу.

Клиент-серверный режим

Дополнительные уровни защиты: доступ к СУБД, администрирование кластера, отсутствие прямого доступа к данным. Рекомендуется для баз с несколькими пользователями и ценными данными.

Дополнительные меры защиты

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

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

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

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

Проверка результата и типичные ошибки

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

Проверьте и обходные пути: запуск через ярлык с параметром DESIGNER, открытие внешней обработки в режиме предприятия, попытку изменить пользователей. Если хотя бы один сценарий проходит — настройка не завершена.

Контрольные точки

Как проверить результат

Запуск конфигуратора под обычным пользователем

Норма

Нет возможности изменить и сохранить конфигурацию

Тревожный признак

Конфигурация редактируется и сохраняется

Список пользователей базы

Норма

Заведены все пользователи, у каждого пароль, полные права только у администраторов

Тревожный признак

Пустой список или полные права у многих

Журнал регистрации

Норма

Входы в конфигуратор фиксируются, лишних событий нет

Тревожный признак

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

Часто задаваемые вопросы

Можно ли полностью запретить запуск конфигуратора, а не только изменения?

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

Пользователь всё равно открывает конфигуратор, хотя полных прав нет. Почему?

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

Чем опасен пустой список пользователей в файловой базе?

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

Как защититься от стороннего программиста, который дорабатывает конфигурацию?

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

Поможет ли пароль на папку с базой в файловом режиме?

Штатного механизма пароля на папку в Windows нет, но можно ограничить доступ через права NTFS: разрешить доступ к папке только конкретным учётным записям. Это эффективнее, чем попытки «спрятать» файл.

Нужно ли запрещать конфигуратор, если база работает в клиент-серверном режиме?

Да, настройка прав внутри 1С всё равно обязательна. Клиент-серверный режим защищает от прямого доступа к файлам данных, но пользователь с полными правами в 1С сможет изменить конфигурацию через конфигуратор независимо от режима работы.