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

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

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

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

Как устроена система прав в 1С

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

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

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

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

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

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

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

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

Как ограничить права на уровне конфигуратора

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

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

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

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

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

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

Учтите ограничения. RLS заметно нагружает запросы: на больших базах с несколькими измерениями доступа списки и отчёты могут открываться медленнее. Кроме того, RLS не скрывает сам факт существования объекта метаданных — оно фильтрует только записи. Если нужно полностью скрыть раздел (например, зарплату от всех, кроме расчётчиков), это делается ролями, а не RLS.

Сравнение вариантов

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

Штатный способ для типовых конфигураций. Настраивается в режиме предприятия, не мешает обновлениям. Ограничение: набор ролей фиксирован поставщиком конфигурации.

Роли в конфигураторе

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

RLS по значениям доступа

Когда нужно разделить одни и те же объекты между сотрудниками: по организациям, складам, контрагентам. Минус: дополнительная нагрузка на запросы.

Отдельная информационная база

Крайний вариант для жёсткой изоляции (например, зарплата в отдельной базе). Минус: нужна синхронизация данных и двойное администрирование.

Как проверить, что ограничение сработало

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

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

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

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

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

Вход под пользователем и состав видимых разделов

Норма

Видны только рабочие разделы, лишние журналы и справочники скрыты

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

Пользователь видит регламентные операции, настройки учёта или чужие разделы

Попытка изменить запрещённый объект

Норма

Появляется сообщение «Нарушение прав доступа»

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

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

Списки и отчёты при включённом RLS

Норма

Отображаются только разрешённые организации, склады, кассы

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

Видны записи чужих подразделений или пустые списки там, где данные должны быть

Выполнение штатных операций

Норма

Проведение, печать и отчёты работают без ошибок прав

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

Ошибки «Нарушение прав доступа» при обычной работе — права урезаны чрезмерно

Типичные ошибки при ограничении прав

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

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

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

Особые ситуации и границы самостоятельной настройки

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

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

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

Частые вопросы об ограничении прав в 1С

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

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

Можно ли запретить удаление документов, но оставить их изменение?

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

Как ограничить бухгалтера только одной организацией в многофирменной базе?

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

Что делать, если после ограничения прав документ перестал проводиться?

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

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

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

Можно ли временно расширить права сотруднику на период отпуска коллеги?

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