Как устроена система прав в 1С:Предприятие
Разграничение доступа в 1С:Предприятие держится на цепочке «пользователь → профиль (набор ролей) → права на объекты метаданных → ограничения на уровне записей». Роли и условия RLS описываются в Конфигураторе, учётные записи и их привязка к должностям задаются в режиме Предприятия. Права проверяет платформа при обращении к данным, поэтому ни форма, ни внешний отчёт не покажут пользователю объект, на который нет права чтения.
Рабочий порядок для нового сотрудника: создать пользователя, выбрать способ аутентификации, назначить профиль доступа, при необходимости сузить видимость условием RLS и только потом настраивать интерфейс и начальную страницу. Такой порядок экономит время: интерфейс лишь прячет разделы, а реальные границы задают роли и ограничения.
Названия объектов и разделов зависят от версии платформы и релиза конфигурации. Ниже приведены варианты, которые встречаются в типовых решениях на базе Библиотеки стандартных подсистем (БСП); перед массовыми правками сверьте состав прав и названия в своей базе. Базовый разбор прав доступа в 1С для администраторов собран в отдельном руководстве по настройке прав в 1С.
Чем роль отличается от профиля доступа
Роль - объект конфигурации из ветки «Общие» → «Роли». Внутри роли для каждого объекта метаданных отмечаются разрешённые действия: чтение, добавление, изменение, удаление, а для документов ещё и интерактивные действия (интерактивное проведение, отмена проведения, пометка на удаление, интерактивное удаление). Туда же добавляется ограничение доступа к данным, это и есть RLS.
Профиль доступа объединяет роли и назначается пользователю или группе пользователей. Правка профиля не требует менять код конфигурации: достаточно изменить состав ролей в справочнике. Пример: роли «БазовыеПрава», «ПросмотрОтчетов» и «БанкИКасса» вместе дают профиль «Бухгалтер». В типовых конфигурациях профили хранятся в справочнике (в разных релизах он называется «Профили доступа» или «Профили групп доступа»), и состав профиля виден прямо в его карточке.
| Признак | Роль | Профиль доступа |
|---|---|---|
| Где создаётся | Конфигуратор, ветка «Общие» → «Роли» | Конфигуратор или справочник в режиме Предприятия |
| Что описывает | Права на объекты метаданных и условия RLS | Набор ролей под должность или функцию |
| Кому назначается | Профилю или пользователю напрямую | Пользователю или группе пользователей |
| Нужно ли обновлять конфигурацию базы данных | Да, изменение роли требует обновления | Обычно нет: состав меняется в справочнике |
Практический вывод: права собирайте ролями, а должности описывайте профилями. Перевод сотрудника на другую должность тогда сводится к смене профиля, а не к разбору десятков галочек.
Где настраиваются права: Конфигуратор и режим Предприятия
Конфигуратор отвечает за структуру: роли, шаблоны и условия RLS, состав профилей. После правки ролей выполните «Обновить конфигурацию базы данных». Изменения затрагивают всех пользователей с этой ролью, а активным сеансам, чтобы увидеть новый набор прав, нужен перезапуск: права считываются при старте сеанса. Сеансы завершают через Администрирование → Активные пользователи.
Режим Предприятия отвечает за людей: список пользователей, пароли, назначение профилей, интерфейсы, начальные страницы. Здесь же выдают дополнительные права, например разрешение экспорта данных или удаления помеченных объектов, если такой механизм есть в конфигурации.
Перед обновлением конфигурации базы данных в рабочей базе сделайте выгрузку .dt и предупредите пользователей: во время обновления база недоступна, а ошибка в роли может закрыть доступ сразу всем.
Как создать пользователя в 1С и связать его с учётной записью ОС или домена
Пользователь создаётся либо в списке пользователей Конфигуратора (Администрирование → Пользователи), либо в справочнике пользователей в режиме Предприятия: в конфигурациях на БСП при записи элемента справочника платформенный пользователь создаётся или обновляется автоматически. Набор полей одинаков: имя латиницей без пробелов, полное имя, способ аутентификации и профиль доступа.
Имя пользователя попадает в журнал регистрации и часто используется в условиях RLS, поэтому меняйте его до выдачи прав. Переименование позже ломает и историю действий, и ограничения.
Аутентификация средствами 1С, ОС и домена: что выбрать
| Способ | Как работает | Плюсы | Минусы и риски |
|---|---|---|---|
| Средствами 1С | Пароль хранит и проверяет платформа, администратор задаёт его в карточке пользователя | Не нужен домен, работает в любой сети, гибкие требования к сложности и сроку действия пароля | У сотрудника появляется ещё один пароль; блокировку и смену администрируют вручную |
| Операционная система | Вход под учётной записью ОС рабочего места, в списке пользователей 1С указано то же имя | Пароль вводить не нужно, удобно для терминальных серверов и тонких клиентов | Имя учётной записи ОС должно совпадать с указанным в 1С; локальная запись на другом компьютере не подойдёт; способ зависит от настроек кластера серверов |
| Домен Windows (SSO) | Аутентификация по учётной записи Active Directory | Единый вход, централизованные парольные политики и мгновенная блокировка в каталоге | Требует домена, доверия между сервером 1С и контроллерами домена, корректных настроек кластера; для файлового варианта не подходит |
В новых версиях платформы встречается также вход через OpenID Connect, состав доступных способов проверяйте в свойствах кластера серверов и в карточке пользователя своей базы.
Типовые ошибки этого шага: в карточке указали «user» вместо «DOMAIN\user»; сервер 1С стоит вне домена; аутентификация ОС или домена не разрешена в свойствах кластера серверов; сотрудник сменил имя в ОС, а в 1С осталось старое. Каждая из них даёт один и тот же результат: «Неверное имя или пароль пользователя».
Пошаговый пример: создание пользователя «Бухгалтер»
- Откройте Администрирование → Пользователи (или Конфигуратор → Администрирование → Пользователи) и создайте новый элемент.
- Заполните имя латиницей, например Ivanova, и полное имя: Иванова И.И.
- Выберите аутентификацию «1С:Предприятие» и задайте пароль. Требования к длине, сроку действия и запрету повторяющихся паролей настраиваются в политике паролей в типовых решениях на БСП.
- Назначьте профиль «Бухгалтер». Если такого профиля нет, создайте его и добавьте нужные роли.
- Проверьте дополнительные права: экспорт данных и удаление записей бухгалтеру обычно не нужны.
- Запишите элемент, войдите под новым пользователем в отдельном сеансе и проверьте, что нужные разделы открываются, а чужие организации и складские цены не видны.
Если после входа пользователь видит меньше, чем ожидалось, проверьте не только профиль, но и условия RLS: они могут отсекать записи из-за незаполненного реквизита.
Роли и профили доступа: собираем права для бухгалтера, кладовщика и администратора
В типовых конфигурациях готовые профили покрывают усреднённый сценарий. Если организаций несколько, склады разнесены по подразделениям или себестоимость нельзя показывать всем, профили дорабатывают: добавляют и убирают роли, а спорные данные закрывают условием RLS. Правило одно: сначала минимальный набор прав, расширение только по факту рабочей необходимости.
| Должность | Что разрешить | Что запретить |
|---|---|---|
| Бухгалтер | Базовые права, документы своего участка (банк, касса, зарплата), формирование отчётов | Администрирование, удаление документов, документы чужих организаций (через RLS) |
| Кладовщик | Складские документы, инвентаризации, печать первичных документов по складу | Финансовые документы, цены и себестоимость, администрирование |
| Администратор системы | Полные права, обновление конфигурации, журнал регистрации, список пользователей | Работа под общей учётной записью, постоянное использование этой роли рядовыми сотрудниками |
| Администратор прав | Управление пользователями, профилями и аудит прав | Изменение конфигурации, структуры метаданных и ролей |
Профиль для бухгалтера: что можно и что нельзя
Бухгалтеру нужны базовые права, доступ к документам своего участка и к отчётам. Права на удаление документов, изменение констант и администрирование этому профилю не требуются: корректировки проходят через пометку на удаление и разбор администратором. Отдельные участки (зарплата, банк) удобно развести разными профилями, чтобы бухгалтер по банку не открывал зарплатные ведомости.
Видимость себестоимости и цен ограничивается не на уровне реквизита, а на уровне объектов: платформенное ограничение доступа к данным работает с записями, а не с отдельными полями. Если себестоимость видна в документе, к которому у бухгалтера есть право чтения, скрыть отдельную графу штатными средствами не получится. Варианты: не давать право на объект, выносить показатели в отдельный объект или ограничивать записи условием RLS.
Профиль для кладовщика: доступ только к складу
Кладовщику выдают складские документы, инвентаризации и печать первички, а банковские документы, зарплату и администрирование закрывают. Похожая логика «выдать нужный раздел и скрыть финансовые показатели» применяется и в других учётных системах: например, в системе Controlata доступ собирают по разделам, а стоимость материалов и себестоимость скрывают отдельными переключателями (описание модели доступа в Controlata). Это иллюстрация подхода из другого продукта, правила 1С она не заменяет.
Ограничение «только свой склад» редко решается ролями: если у кладовщика есть право чтения складских документов, он увидит все склады. Здесь нужен RLS по реквизиту «Склад».
Профиль для администратора: полные права или разумное ограничение
Полные права нужны узкому кругу: обновление конфигурации, обслуживание базы, работа с журналом регистрации. Специалиста, который занимается только учётными записями и профилями, стоит вынести в отдельный профиль «Администратор прав»: управление пользователями и аудит без правки структуры. Тогда ошибка в профиле не превратится в случайное удаление данных.
Отдельный риск: сотрудник с полными правами не подпадает под ограничения RLS, поэтому проверку видимости данных всегда выполняйте под обычным пользователем.
Настройка интерфейса и рабочего места под конкретную должность
Интерфейс задаёт удобство, а не безопасность: он скрывает разделы и команды, но не заменяет права. Комбинация «скрытый раздел + право на объект» означает, что данные всё равно доступны через отчёты, поиск или форму связанного объекта.
Как скрыть лишние разделы и команды
В типовых решениях на БСП видимость разделов настраивается для пользователя в разделе администрирования (настройки пользователей и прав) или самим сотрудником в разделе сервиса и настроек. Для кладовщика оставляют раздел «Склад», для бухгалтера по банку - «Банк и касса» и отчёты. Командный интерфейс настраивается там же: лишние команды убирают из панелей, чтобы сотрудник не запускал недоступные операции и не получал ошибки доступа.
Порядок действий: сначала назначьте профиль, затем проверьте, какие разделы стали доступны по правам, и уже после этого скрывайте ненужные. Обратный порядок даёт ложное чувство защищённости.
Начальная страница и избранное для быстрого доступа
Начальную страницу собирают под задачи должности: бухгалтеру - задачи и списки документов участка, кладовщику - остатки и складские документы. Часто используемые отчёты добавляют в избранное, чтобы не искать их по меню. Настроенный интерфейс удобно переносить другим сотрудникам с той же должностью, это экономит время при вводе новых людей.
RLS в 1С: ограничение доступа на уровне записей
RLS (ограничение доступа на уровне записей) задаётся в роли для конкретного объекта и представляет собой условие на встроенном языке, которое платформа добавляет к запросам пользователя. В условиях доступны предопределённые параметры (в частности, &Пользователи со списком пользователей, к которым применяется ограничение) и собственные параметры, передаваемые в запрос. Повторяющиеся условия удобно выносить в шаблоны ограничений.
Условие задаётся отдельно для чтения, добавления, изменения и удаления. Если ограничение указано только для чтения, пользователь не увидит запись в списке, но операция записи останется без ограничений, поэтому набор условий проверяйте целиком.
Когда нужен RLS, а когда достаточно ролей
RLS нужен, когда несколько сотрудников с одинаковыми ролями должны видеть разные данные: разные организации, склады, проекты, партнёров. Если разграничение идёт по должности (бухгалтер, кладовщик, кадровик), хватает ролей и профилей, а RLS только усложнит сопровождение.
Условия добавляются в каждый запрос к защищаемой таблице, и на больших объёмах это заметно влияет на план выполнения: чем сложнее условие и чем меньше подходящих индексов, тем медленнее работают списки и отчёты. Ограничения на уровне записей в СУБД сталкиваются с той же проблемой, полезные приёмы разобраны в руководстве по правам доступа в PostgreSQL, MySQL и MS SQL.
Важное ограничение: в привилегированном режиме платформа права не проверяет, поэтому обработка, которая включает такой режим, покажет данные без учёта RLS. Ограничения не действуют и для пользователя с полными правами.
Пример условия RLS для бухгалтера: только своя организация
- Заведите у пользователя (или в связанном справочнике) реквизит «Организация» или список организаций, если сотрудник ведёт несколько.
- Создайте функцию, возвращающую список организаций текущего пользователя, и передайте её результат параметром в условие.
- В роли для нужных документов добавьте условие вида: Организация В (&СписокОрганизаций). Продублируйте его для чтения, изменения и удаления.
- Проверьте вход под бухгалтером: в списке должны остаться документы только его организаций.
Типичный сбой этого сценария: реквизит не заполнен, список пуст, и пользователь не видит ни одного документа. Со стороны это выглядит как «пропали данные», хотя права настроены корректно.
Пример условия RLS для кладовщика: только свой склад
- Свяжите пользователя со складом или списком складов через реквизит в справочнике пользователей.
- В роли для документов поступления, отгрузки и инвентаризации добавьте условие вида: Склад В (&СписокСкладов).
- Отдельно проверьте регистры: если остатки хранятся в регистре с разрезом по складу, ограничение потребуется и там.
- Войдите под кладовщиком и убедитесь, что видны документы только его склада, а финансовые документы недоступны вовсе.
Если кладовщик периодически подменяет коллегу на другом складе, не расширяйте ему профиль: добавьте второй склад в реквизит, RLS подхватит оба значения.
Типовые ошибки при настройке прав и как их избежать
Ошибка: дали слишком много прав
Самая частая причина инцидентов: роль с полными правами выдали «на время» и забыли забрать. Держите принцип минимальных привилегий: стартовый набор ролей, расширение только по обращению, периодический пересмотр. Системный подход к проектированию ролей и проверке избыточных прав описан в материале про модель RBAC на практике.
Ошибка: RLS не работает или работает не так
Причины по частоте: у пользователя есть роль с полными правами; условие задано для чтения, но не для записи и удаления; в условии ошибка (например, сравнение с пустой ссылкой); реквизит пользователя не заполнен; ограничение добавлено не ко всем объектам, через которые видны те же данные. Диагностика: тестовый вход под пользователем, проверка состава его ролей и профилей, просмотр журнала регистрации.
Ошибка: после обновления конфигурации права слетели
Если правки внесены прямо в основную конфигурацию, при переходе на новый релиз их приходится переносить вручную, а часть изменений теряется. Решение: держать доработки в расширении конфигурации и документировать каждое изменение прав. Для типовых конфигураций, снятых с поддержки, обновление всегда требует ручного сравнения.
Ошибка: общий логин и отсутствие проверки
Общая учётная запись на отдел уничтожает аудит: в журнале видно логин, а не человека. В учётных системах этот принцип формулируют прямо: один аккаунт на сотрудника, иначе невозможно понять, кто менял данные (пример такого требования в Controlata). Вторая ошибка того же класса: настроили профиль, но не вошли под новым пользователем и не проверили границы доступа.
Как проверить и аудировать настроенные права
Отчёт по правам пользователей
В типовых конфигурациях есть отчёт о правах пользователей (точное название зависит от релиза): он показывает профили и роли каждого сотрудника. Если отчёта нет, его несложно собрать в Конфигураторе по объектам метаданных. Проверяйте три вещи: нет ли ролей с полными правами, нет ли ролей «на всякий случай», совпадает ли набор прав с текущими обязанностями.
Журнал регистрации как инструмент аудита
Журнал регистрации (Администрирование → Обслуживание → Журнал регистрации) фиксирует входы, изменение и удаление данных. Фильтруйте его по пользователю и типу события, чтобы увидеть, какие операции сотрудник выполняет реально. В клиент-серверном варианте журнал разрастается быстро, поэтому настройте хранение и разделение по периодам, иначе база и диск сервера будут расти без пользы.
Порядок проверки: тестовый вход под пользователем, сверка видимых разделов и документов, отчёт по правам, выборочный анализ журнала. Работы выполняйте на тестовой базе, чтобы не мешать сотрудникам.
Безопасное внесение изменений в рабочей среде
Резервное копирование перед изменением прав
Копия нужна до любого изменения ролей, условий RLS и состава профилей. В файловом варианте достаточно копии файла базы, в клиент-серверном используют средства СУБД (например, pg_dump для PostgreSQL или BACKUP DATABASE для MS SQL), плюс выгрузку .dt через Конфигуратор. Без копии откат ошибочного условия RLS может занять часы: пользователи просто перестанут видеть документы.
Использование расширений для изменения ролей
Расширение конфигурации позволяет добавлять собственные роли и условия, не меняя основную конфигурацию, поэтому обновление релиза проходит предсказуемо. Учтите ограничение: не все правки существующих ролей удаётся сделать через расширение, часть изменений придётся переносить вручную после каждого обновления, и тогда особенно важна документация по настроенным правам.
Тестовую копию базы удобно держать на отдельном сервере: например, развернуть её на облачном VDS вроде Timeweb Cloud, чтобы проверять условия RLS и профили без риска для рабочей системы.
Чек-лист перед правкой прав: сделана резервная копия; изменения внесены в тестовой базе; пользователи предупреждены о перерыве; новые права проверены входом под тестовым пользователем; состав ролей и условий зафиксирован в документации. Общая проверка безопасности учётных записей и прав собрана в чек-листе безопасности административной панели. Следующий шаг: возьмите одну должность из вашей базы, соберите для неё профиль по таблице выше и проверьте результат под тестовым пользователем, прежде чем менять права остальным сотрудникам.