Администрирование · 11 мин
Как ограничить права доступа в 1С 8: роли, профили и запреты
Как ограничить права доступа в 1С 8: роли, профили групп доступа, RLS, запрет изменения данных. Пошаговая настройка, проверка результата и типичные ошибки.
Ограничение прав доступа в 1С 8 решает две задачи: защищает данные от случайной порчи и разграничивает зоны ответственности сотрудников. Кладовщик не должен видеть зарплату, менеджер по продажам — удалять проведённые документы, а бухгалтер — менять настройки обмена. Всё это настраивается штатными средствами платформы без доработки конфигурации.
Механизм прав в 1С 8 устроен двухуровнево. На уровне конфигурации существуют роли — наборы разрешений на объекты метаданных (справочники, документы, регистры). На уровне пользовательского режима работают профили групп доступа — это те же роли, но собранные в понятные наборы, которые администратор назначает пользователям или целым группам. В типовых конфигурациях (Бухгалтерия, ЗУП, Управление торговлей) именно профили — основной инструмент.
Дополнительно существует механизм RLS (Record Level Security) — ограничение доступа не к типу объектов, а к конкретным записям: например, менеджер видит только документы своей организации или своего склада. Он настраивается отдельно и требует более аккуратной работы.
Как устроена система прав в 1С 8
Каждая роль в конфигураторе содержит набор разрешений: чтение, добавление, изменение, удаление, проведение, просмотр и другие действия для каждого объекта. Пользователю можно назначить несколько ролей — итоговые права складываются по принципу «разрешено всё, что разрешено хотя бы одной ролью». Запрещающих правил в платформе нет: если хоть одна роль даёт право на удаление, пользователь сможет удалять.
Из этого следует главное правило настройки: права сокращаются не добавлением запретов, а удалением лишних ролей. Если пользователю доступно что-то лишнее, нужно искать, какая из назначенных ему ролей или профилей это разрешает, и убирать её.
Отдельно стоят административные права: «Администрирование», «Обновление конфигурации базы данных», «Толстый клиент», «Вывод» и другие. Их назначают только тем, кто обслуживает систему. Право «Администрирование» позволяет менять пользователей и их права — то есть фактически снять любые ограничения.
Настройка прав через профили групп доступа
Откройте раздел Администрирование → Настройки пользователей и прав → Профили групп доступа. В типовых конфигурациях уже есть готовые профили: «Бухгалтер», «Менеджер по продажам», «Кадровик» и другие. Если готовый профиль подходит — достаточно включить пользователя в соответствующую группу доступа.
Если типовой профиль избыточен, создайте свой: нажмите «Создать», задайте понятное имя (например, «Менеджер — только просмотр заказов») и отметьте только нужные роли. Не копируйте профиль «с запасом» — лишняя роль рано или поздно приведёт к случайному изменению данных.
Затем перейдите в Группы доступа, создайте группу, привяжите к ней профиль и добавьте пользователей. Один пользователь может входить в несколько групп — права суммируются. Это удобно для совместителей: «Кассир» + «Кладовщик».
- 1Откройте Администрирование → Настройки пользователей и прав → Профили групп доступа
- 2Создайте новый профиль и отметьте только необходимые роли
- 3Создайте группу доступа и привяжите к ней профиль
- 4Добавьте пользователей в группу доступа
- 5Завершите сеанс пользователя, чтобы права применились при новом входе
- 6Войдите под учётной записью пользователя и проверьте доступность объектов
Ограничение прав на уровне конфигуратора
Если конфигурация не типовая или профили отключены, права назначаются напрямую. В режиме предприятия: Администрирование → Пользователи, откройте карточку пользователя, вкладка «Права» (или «Роли») и отметьте нужное. В конфигураторе список пользователей находится в меню Администрирование → Пользователи.
Для тонкой настройки откройте конфигуратор, найдите нужную роль в ветке «Общие → Роли» и посмотрите, какие объекты и действия она разрешает. Копию типовой роли можно доработать: например, снять флажок «Удаление» у документов, оставив «Добавление» и «Изменение». Изменять типовые роли напрямую не рекомендуется — при обновлении конфигурации изменения могут затереться, лучше создавать собственные роли.
Ограничение доступа к конкретным данным (RLS)
Роли ограничивают действия с типами объектов, но не различают записи. Чтобы менеджер видел только свою организацию или свой склад, используется RLS. В типовых конфигурациях это настраивается через группы доступа контрагентов, номенклатуры, складов, организаций — в зависимости от конфигурации.
Общая схема: включите в настройках использование групп доступа соответствующего объекта (например, «Группы доступа складов»), создайте группы, распределите по ним элементы справочника, а в карточке пользователя или его группы доступа укажите, какие группы ему разрешены. После этого в списках и отчётах пользователь увидит только разрешённые записи.
Учтите: RLS работает на уровне запросов к базе и заметно усложняет их текст. На больших базах избыточное количество ограничений может снизить скорость формирования списков и отчётов. Включайте RLS только там, где это действительно требуется по регламенту.
Запрет изменения данных закрытых периодов
Частая задача — запретить редактирование документов прошлых периодов, по которым сдана отчётность. Для этого служит механизм дат запрета изменения данных: Администрирование → Поддержка и обслуживание → Регламентные операции → Настроить даты запрета изменения данных (в разных конфигурациях путь может немного отличаться).
Установите дату, например конец закрытого квартала. Все документы раньше этой даты станут недоступны для изменения и перепроведения. Дату можно задать общей для всех или индивидуально — для конкретных пользователей и даже по разделам учёта: бухгалтерский учёт закрыт, а складской ещё открыт.
Проверка проста: войдите под обычным пользователем и попробуйте изменить документ закрытого периода — программа должна выдать сообщение о запрете. Помните, что дата запрета не защищает от пользователя с правом её изменения, поэтому доступ к этой настройке должен быть только у администратора или главного бухгалтера.
Проверка результата и контроль назначенных прав
Единственный надёжный способ убедиться, что ограничения работают, — войти в базу под учётной записью ограниченного пользователя и пройти по типичному сценарию его работы. Откройте справочники и документы, к которым доступа быть не должно: они должны либо отсутствовать в интерфейсе, либо открываться с сообщением о нарушении прав.
Проверьте и обратную сторону: всё, что нужно для работы, должно открываться без ошибок. Классическая ошибка — чрезмерное ограничение, когда у менеджера не открывается печатная форма счёта, потому что у него нет права чтения какого-то вспомогательного регистра. Такие проблемы выявляются только практическим тестом.
Для анализа назначенных прав полезно периодически выгружать список пользователей с их профилями и сверять с должностными обязанностями. Уволенным сотрудникам доступ должен блокироваться в день увольнения: снимите флажок «Вход в программу разрешён» в карточке пользователя.
Как проверить результат
Открываются только нужные разделы и документы
Доступны лишние справочники или ошибки «Нарушение прав доступа» при штатной работе
Сообщение о дате запрета изменения данных
Документ сохраняется и проводится без предупреждений
Только администраторы системы
Административные права у рядовых пользователей
Типичные ошибки при разграничении прав
Самая распространённая ошибка — работа всех сотрудников под одной учётной записью с полными правами. В этом случае невозможно ни ограничить доступ, ни установить по журналу регистрации, кто изменил документ. Заведите отдельного пользователя для каждого сотрудника, даже если база файловая и кажется, что «и так понятно, кто работал».
Вторая ошибка — назначение профилей «с запасом» ради экономии времени. Проще выдать «Бухгалтер» вместо точечного профиля, но вместе с этим пользователь получает права, о которых никто не помнит. Через год такие избыточные права становятся источником случайных изменений и утечек.
Третья группа ошибок связана с забыванием: не завершён сеанс после смены прав, не заблокирован уволенный сотрудник, не проверен результат после настройки. Каждый из этих пунктов сводит на нет всю остальную работу.
Что важно запомнить
Права в 1С 8 сокращаются убиранием лишних ролей, а не добавлением запретов. Работайте через профили групп доступа, ограничивайте записи через RLS только при реальной необходимости, закрытые периоды защищайте датой запрета, а результат всегда проверяйте входом под учётной записью пользователя. Полные права — только администраторам.
Часто задаваемые вопросы
Можно ли запретить пользователю удаление документов, оставив право их создавать?
Да. Это делается на уровне роли: в конфигураторе для нужного вида документов снимается право «Удаление» (и при необходимости «Интерактивное удаление»), а права «Добавление» и «Изменение» остаются. В типовых конфигурациях проще подобрать или скопировать профиль, где удаление не включено. Дополнительно защитит от потери данных дата запрета изменения для прошлых периодов.
Почему после настройки прав у пользователя ничего не изменилось?
Права применяются при входе в базу, а не на лету. Если сеанс пользователя был открыт до изменений, он работает со старыми правами. Завершите его сеанс через список активных пользователей и попросите войти заново. Также проверьте, не входит ли пользователь в другую группу доступа с более широким профилем — права суммируются.
Как дать доступ только к отчётам, без изменения данных?
Создайте профиль, в котором для нужных объектов включены только права «Чтение» и «Просмотр», без «Добавления» и «Изменения». В типовых конфигурациях часто есть готовые профили вида «Только просмотр». Учтите, что отчётам нужно право чтения всех регистров, по которым они строятся, иначе пользователь получит ошибку при формировании.
Что делать, если заблокирован единственный администратор базы?
Профилактика проще восстановления: всегда держите минимум две учётные записи с полными правами и резервную копию. Если блокировка уже произошла, для клиент-серверной базы доступ можно восстановить средствами СУБД, а для файловой — специализированными утилитами. Это операции с риском повреждения данных, их стоит выполнять только с предварительной копией базы и привлечением специалиста.
Снижает ли RLS производительность базы?
Ограничение на уровне записей добавляет условия в каждый запрос к ограничиваемым таблицам, поэтому на больших объёмах данных замедление возможно, особенно в отчётах и динамических списках. На небольших файловых базах эффект обычно незаметен. Практическая рекомендация — включать RLS только для тех объектов, где разграничение действительно требуется, и не создавать чрезмерно дробных групп доступа.
Можно ли скрыть от пользователя целый раздел программы?
Да, и это происходит автоматически: если у пользователя нет прав ни на один объект раздела, соответствующие пункты меню и команды скрываются из интерфейса. Отдельно настраивать видимость меню обычно не требуется. Если раздел всё же отображается, значит, какая-то из назначенных ролей даёт право хотя бы на один объект в нём — ищите её через анализ профиля.