Профили групп доступа: разграничение прав между организациями
Несколько юридических лиц в одной информационной базе — типовая картина для холдингов, торговых групп и внешних бухгалтерских служб. Сотрудник отдела продаж должен видеть счета и отгрузки своего юридического лица и не иметь доступа к первичке партнёра. Раздельные базы решают задачу, но дороги: обмен данными, дублирование справочников, разная учётная политика. Профили групп доступа в платформе 1С:Enterprise позволяют развести полномочия внутри единой базы.
Логика построения простая: права выдаются не пользователю напрямую, а группе доступа, в которую входят пользователи и профили. Профиль описывает, что разрешено — роли, виды цен, ограничения доступа на уровне записей, наборы значений доступа. Изменили профиль — все участники группы получили обновлённые полномочия, отдельную учётную запись править не нужно.
На специализированных форумах, в том числе на Infostart, вопросы о профилях возникают постоянно: почему документ открывается, но не проводится, откуда взялся запрет на изменение цены, как проверить настройки, не испортив рабочие данные. Часть сложностей связана с тем, что ограничения работают по-разному в типовых конфигурациях и в доработанных.
Отдельный нюанс: проверки доступа выполняются в сеансе пользователя. Регламентные задания, внешние обработки, подключённые расширения и узлы обмена данными могут работать в привилегированном режиме и обходить разграничение. Поэтому настройка профилей всегда сопровождается ревизией прикладного кода и служебных учётных записей.
Зачем разделять права по организациям
Единая база с разграничением по организациям решает сразу несколько задач. Во-первых, уменьшается количество ошибок ввода: бухгалтер не получает возможности открыть чужой счёт-фактуру и провести чужую оплату. Во-вторых, появляется основание для аудита — можно показать, какие документы были доступны сотруднику в конкретный момент времени.
Второй эффект — экономия и скорость внедрения. Не требуется синхронизировать справочники между базами, обмены запускаются реже, а отчётность по группе собирается из одного источника. Для компаний с общим товарным каталогом и разной структурой сделок это заметный выигрыш.
Наконец, тот же механизм используется для разделения функционала внутри одного юридического лица: казначейство, кладовщик и снабженец получают разные профили с разными наборами прав. Предикат по реквизиту «Организация» в этом случае отсекает документы, оформленные на другие подразделения.
Как устроены профили, группы доступа и роли
Профиль группы доступа создаётся через режим «Все функции» или раздел Администрирование — в зависимости от настроек интерфейса. В типовых конфигурациях, например в «1С:ERP» или «1С:Управлении торговлей», профили поставляются вместе с поставкой и служат отправной точкой: их копируют и уточняют под собственную схему разграничения.
В профиле задаются несколько обязательных элементов. Роли определяют действия над объектами метаданных: просмотр, изменение, проведение, пометка удаления. Ограничения доступа отвечают за видимость строк документов и записей регистров. Наборы значений доступа фильтруют элементы справочников, а виды цен и склады ограничивают номенклатуру и цены, которыми может оперировать сотрудник.
Группа доступа связывает пользователей с профилями. Один пользователь может состоять в нескольких группах, и тогда полномочия складываются. Реквизит «Организация» у пользователя, если он предусмотрен конфигурацией, чаще всего становится источником значения для параметра: ограничение вида «Организация = &Организация» подставляет текущее значение, а не введённое вручную.
Порядок настройки профиля под конкретную организацию
Настройка выглядит последовательно. Сначала описывается функционал: какие документы, отчёты и справочники нужны сотруднику, а какие должны остаться недоступными. Затем создаётся профиль, в него добавляются роли из стандартного набора или доработанные роли конфигурации, учитывающие специфику учёта.
Следующий шаг — ограничения доступа. В предикатах задаётся условие по реквизиту «Организация», привязанное к параметру сеанса, и заполняются наборы значений доступа, если требуется фильтр по элементам справочников. Отдельно указываются виды цен, склады и другие значения, к которым применяется разграничение полномочий.
Завершает работу группа доступа: в неё добавляются учётные записи сотрудников, у каждой из которых в приложении указан пользователь. После этого результат полезно проверить на копии базы — зайти под нужной учётной записью, попытаться открыть документ другой организации, сформировать отчёт и убедиться, что данные не выходят за пределы заданных параметров.
Способы ограничения доступа и их сравнение
Ограничение прав собирается несколькими способами, и выбор зависит от того, что именно требуется разграничить. Роли отвечают за действия, RLS — за строки, наборы значений — за элементы справочников. Сравнение выглядит следующим образом:
| Способ ограничения | Где настраивается | Что разграничивает | Ограничение подхода |
|---|---|---|---|
| Роли | Метаданные и профиль группы доступа | Действия над объектами: просмотр, изменение, проведение | Не разделяет записи внутри одной организации |
| Предикаты RLS | Профиль группы доступа, раздел ограничений доступа | Строки документов и записи регистров | Требует параметризации и проверки на каждом виде объектов |
| Наборы значений доступа | Профиль группы доступа, наборы значений | Элементы справочников и их реквизиты | Работает только со справочниками, включёнными в механизм |
| Виды цен и склады | Профиль группы доступа, виды цен | Цены, склады, ответственное лицо | Не защищает другие регистры и справочники |
В реальных внедрениях механизмы комбинируют: профиль с ролями даёт право работать с документами, предикат по «Организации» отсекает чужие строки, набор значений закрывает отдельные элементы справочников, например склады. Чем больше уровней задействовано, тем внимательнее стоит относиться к служебным учётным записям и привилегированному режиму.
Практические ориентиры и проверка результата
Ориентиры удобно разложить на две части: что имеет смысл заложить в профиль и какие ошибки встречаются чаще всего.
Что закладывать в профиль:
- Базовые роли чтения и проведения для нужных видов документов, без лишних административных прав
- Предикат по реквизиту «Организация», связанный с параметром сеанса, а не с фиксированным значением
- Наборы значений доступа для справочников, которые не должны показываться сотруднику целиком
- Виды цен, склады и подразделения, доступные при работе с номенклатурой
- Служебные права для учётных записей, обслуживающих обмен данными и регламентные задания
Частые ошибки при разграничении:
- Копирование типового профиля без проверки ограничений: в поставке нередко остаются общие наборы прав
- Пустой или неверно заполненный параметр предиката, из-за чего ограничение просто не применяется
- Привилегированный режим в обработках и расширениях, обходящий проверки доступа пользователя
- Проверка настроек в рабочей базе вместо копии, где уже накоплены реальные данные
На Infostart публикуются разборы по платформе 1С:Enterprise: обработки, расширения, конфигурации, интеграции, вопросы по администрированию сервера и информационных баз. Подписка на RSS-ленту позволяет следить за новыми материалами и обсуждать их в комментариях, а зарегистрированные пользователи делятся собственными решениями по разграничению прав.
Если задача выходит за рамки типовых настроек — например, нужен учёт по нескольким организациям с автоматизацией бизнес-процессов, — стоит посмотреть на продукт KUBiK и обсудить сценарий на форуме: практики, работающие с похожей архитектурой базы, обычно подсказывают и состав профилей, и способ проверки. Опубликуйте разбор собственной настройки — такой материал полезен тем, кто внедряет разграничение прав в первый раз.