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

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

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

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

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

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

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

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

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

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

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

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

Настройка профилей и групп доступа в режиме «1С:Предприятие»

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

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

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

Группа доступа связывает профиль с пользователями. В карточке группы указывается профиль, список участников и, если профиль использует виды доступа, конкретные разрешённые значения — например, только организация «ООО Ромашка». Один пользователь может состоять в нескольких группах; его итоговые права — объединение прав всех групп.

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

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

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

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

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

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

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

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

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

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

Норма

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

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

Видны лишние разделы или, наоборот, ошибки «Нарушение прав доступа» при штатных операциях

Проведение документа

Норма

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

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

Ошибка доступа к регистру или справочнику при проведении

Ограничение по организации

Норма

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

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

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

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

Типичные ошибки при настройке прав

Чаще всего проблемы возникают не из-за сложности механизма, а из-за спешки и отсутствия проверки. Ниже — ошибки, которые регулярно встречаются на практике.

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

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

Чем роль отличается от профиля группы доступа?

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

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

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

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

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

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

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

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

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

Влияет ли настройка RLS на скорость работы базы?

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