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

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

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

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

Как устроена модель прав в 1С

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

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

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

Создание пользователя и базовые настройки входа

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

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

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

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

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

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

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

1. 1
   Создайте резервную копию базы или зафиксируйте текущие настройки доступа
2. 2
   Создайте пользователя в разделе «Настройки прав и пользователей»
3. 3
   Создайте или выберите профиль групп доступа с минимально нужными ролями
4. 4
   Добавьте пользователя в группу доступа, связанную с профилем
5. 5
   При необходимости настройте группы доступа организаций, складов, контрагентов для RLS
6. 6
   Войдите под учётной записью сотрудника и проверьте доступность объектов

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

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

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

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

Отдельные сценарии ограничений

Запрет на удаление и изменение закрытых периодов

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

Ограничение доступа к зарплате и персональным данным

Кадровые и зарплатные данные защищаются отдельными ролями и профилями. В конфигурациях с блоком зарплаты (ERP, ЗУП, Комплексная автоматизация) доступ к начислениям дают только профили расчётчиков и кадровиков. Убедитесь, что в профиле бухгалтера по учёту товаров нет ролей на чтение регистров начислений — в типовых сборках такие пересечения встречаются, если профиль собирали вручную.

Только просмотр без права изменения

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

Способы ограничения прав

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

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

RLS

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

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

Для защиты закрытых периодов от редактирования. Ограничение: не разграничивает права между пользователями внутри открытого периода.

Изменение ролей в конфигураторе

Когда типовых ролей не хватает. Ограничение: требует снятия конфигурации с полной поддержки и усложняет обновления; применяйте только при реальной необходимости.

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

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

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

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

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

Вход под учётной записью сотрудника

Норма

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

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

Пустые журналы документов или ошибки «Нарушение прав доступа» при штатных операциях

Попытка открыть запрещённый раздел

Норма

Раздел скрыт из интерфейса или выдаёт отказ в доступе

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

Раздел открывается и позволяет изменять данные

Отчёт «Права доступа» по пользователю

Норма

Источники прав — только целевые профили

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

Права приходят из лишнего профиля или роли «Полные права»

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

Норма

Видны документы только своей организации или склада

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

Список пуст у всех или, наоборот, видны чужие документы

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

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

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

Удобная практика — называть профили по должностям или функциям («Кассир розничной точки», «Менеджер закупок без цен поставщиков»), а не по фамилиям сотрудников. Тогда при приёме нового человека на должность достаточно добавить его в готовую группу доступа, а при увольнении — просто деактивировать учётную запись, не разбирая персональные настройки.

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

Сотруднику нужны права двух должностей. Создавать отдельный профиль?

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

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

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

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

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

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

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

Что делать, если никто не может войти в базу после изменения прав?

Если есть второй пользователь с полными правами — войдите под ним и исправьте настройки. Если полные права потеряны у всех, в клиент-серверном варианте доступ восстанавливается через консоль кластера или добавлением администратора средствами СУБД. В файловой базе без единого администратора потребуется восстановление из резервной копии — поэтому копия перед изменением прав обязательна.

Влияет ли ограничение прав на обмены данными и регламентные задания?

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