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

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

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

Ниже разобраны практические сценарии для типовых конфигураций (Бухгалтерия предприятия, Управление торговлей, Зарплата и управление персоналом), а также общие приёмы для любых баз на платформе 1С:Предприятие 8.3.

Чем опасны полные права у рядовых пользователей

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

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

Как убрать полные права у пользователя

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

Если пользователю назначен профиль «Администратор» или напрямую выдана роль «Полные права», замените профиль на тот, который соответствует его функциям: «Бухгалтер», «Менеджер по продажам», «Кадровик» и т.д. Состав ролей профиля можно посмотреть и отредактировать в разделе «Администрирование» → «Настройки пользователей и прав» → «Профили групп доступа».

В старых конфигурациях на обычных формах (например, УПП 1.3, УТ 10.3) права настраиваются через «Сервис» → «Пользователи» → «Настройка прав пользователей» либо напрямую в конфигураторе: «Администрирование» → «Пользователи» → вкладка «Роли». Там нужно снять флажок «Полные права» и отметить только необходимые роли.

1. 1
   Создайте резервную копию базы или убедитесь, что актуальная копия существует
2. 2
   Откройте «Администрирование» → «Пользователи» и найдите нужного сотрудника
3. 3
   Проверьте назначенный профиль и состав ролей через ссылку «Права доступа»
4. 4
   Замените профиль «Администратор» на функциональный профиль сотрудника
5. 5
   Попросите пользователя перезайти в базу и проверьте доступ к его рабочим документам
6. 6
   Убедитесь, что лишние разделы и операции ему недоступны

Настройка профилей групп доступа

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

Чтобы посмотреть, какие роли входят в профиль, откройте его карточку — там отображается список ролей и доступных действий. Обратите внимание: изменение состава ролей профиля возможно только в конфигураторе для самих ролей; в режиме предприятия редактируется состав профиля из существующих ролей и дополнительные права (например, «Изменение текущего пользователя», «Печать непроведённых документов»).

Группы доступа позволяют назначить один профиль сразу нескольким сотрудникам. Это удобно при увольнении или переводе: достаточно исключить пользователя из группы, и все связанные права отзываются автоматически.

Ограничение доступа на уровне записей (RLS)

Даже без полных прав пользователь с ролью «Бухгалтер» видит документы всех организаций, если в базе их несколько. Ограничение доступа на уровне записей (RLS) решает эту задачу: сотрудник видит и может изменять только данные «своих» организаций, складов, подразделений или контрагентов из разрешённого списка.

Включение RLS выполняется в разделе «Администрирование» → «Настройки пользователей и прав» → «Группы доступа»: установите флажок «Ограничивать доступ на уровне записей». Затем в карточке группы доступа на вкладке «Ограничение доступа» укажите разрешённые значения — конкретные организации, склады, кассы.

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

Сравнение вариантов ограничения

Профили групп доступа

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

RLS (ограничение на уровне записей)

Подходят для разграничения по данным (чьи документы видны). Гибкие, но снижают производительность и сложнее в диагностике.

Даты запрета изменения

Защищают закрытые периоды от редактирования. Работают для всех пользователей без полных прав, почти не влияют на скорость.

Даты запрета изменения данных

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

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

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

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

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

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

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

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

Вход пользователя в базу

Норма

Вход выполняется, видны только его рабочие разделы

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

Появляется сообщение о нарушении прав или видны административные разделы

Отчёт «Права доступа»

Норма

В списке нет ролей «Полные права» и «Администратор системы»

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

Роли присутствуют через одну из групп доступа

Попытка удалить документ

Норма

Команда недоступна или выдаётся отказ в правах

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

Документ помечается на удаление

Изменение документа закрытого периода

Норма

Срабатывает дата запрета изменения данных

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

Документ сохраняется и проводится

Что делать, если стандартных ролей не хватает

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

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

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

Чем роль «Полные права» отличается от «Администратор системы»?

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

Пользователь потерял доступ к нужному документу после снятия полных прав. Что делать?

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

Можно ли ограничить права в файловой базе без конфигуратора?

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

Почему после включения RLS база стала работать медленнее?

Ограничение на уровне записей добавляет проверки к каждому запросу к данным, поэтому нагрузка на сервер растёт. Снизить влияние можно, ограничив доступ только по действительно необходимым видам (например, только по организациям) и отключив RLS для групп, которым он не нужен. На больших базах изменения стоит предварительно тестировать на копии.

Действуют ли даты запрета изменения для пользователя с полными правами?

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

Как быстро проверить, у кого в базе есть полные права?

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