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

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

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

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

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

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

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

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

Аудит текущих прав: с чего начать

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

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

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

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

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

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

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

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

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

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

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

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

Тонкая настройка через роли в конфигураторе

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

Откройте конфигуратор, найдите нужную роль в ветке «Общие → Роли» и настройте права на конкретные объекты: просмотр, добавление, изменение, удаление, интерактивное удаление. Для тонких условий используется поле «Ограничение доступа» с языком запросов — например, разрешить изменение документов только текущего месяца через шаблон ГДЕ Дата >= &НачалоМесяца.

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

Проверка результата и тестирование

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

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

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

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

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

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

Норма

Открываются только нужные разделы и документы

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

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

Создание и проведение документа

Норма

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

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

Ошибка «Нарушение прав доступа» при проведении

Отчёты по разрешённым данным

Норма

Отчёт показывает полные данные в рамках доступа

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

Отчёт пустой или показывает часть данных без предупреждения

Типичные ошибки и как их избежать

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

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

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

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

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

Как узнать, какой роли не хватает пользователю?

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

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

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

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

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

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

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

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

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

Что такое даты запрета изменения данных и как они связаны с правами?

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