Есть фраза, после которой в 1С-сопровождении почти всегда начинается расследование:
“У коллеги видно, а у меня нет”.
Или другая версия:
“Что это за ошибка доступа появляется?”
Пользователь открывает документ — ошибка. Пытается сформировать отчет — данные не выводятся. Нажимает команду — не хватает прав. Открывает форму — часть информации недоступна. У коллеги при этом всё работает.
Первое желание в такой ситуации часто простое:
“Ну добавьте ему такую же роль”.
Иногда это действительно решает проблему. Но далеко не всегда.
В 1С доступы могут зависеть не только от ролей. Есть группы доступа, ограничения по организациям и подразделениям, RLS, права на связанные объекты, права на регистры, настройки формы, кодовые проверки, расширения и особенности конкретной конфигурации.
Именно поэтому диагностика прав иногда превращается в неприятный квест. Ошибка есть, пользователь недоволен, руководитель просит “быстро дать доступ”, а ты еще не понимаешь, где именно ограничение.
В этой статье разберем, почему права в 1С ломаются не только из-за ролей, как подойти к диагностике без гадания и почему лишние права могут быть опаснее, чем временное неудобство пользователя.
Ошибка доступа — это симптом, а не диагноз
Когда пользователь говорит “нет доступа”, это еще не объясняет причину.
За одной и той же жалобой могут стоять разные проблемы:
- не хватает роли;
- не настроена группа доступа;
- ограничение RLS отфильтровало данные;
- нет прав на связанный справочник;
- нет прав на регистр;
- форма скрывает команду по условию;
- код проверяет права отдельно;
- расширение добавило новый объект, но права на него не выдали;
- пользователь не входит в нужную организацию или подразделение;
- объект открывается по ссылке, но прямой доступ к нему не должен быть разрешен.
Поэтому я бы не начинал с фразы “какую роль добавить?”.
Я бы начинал с другого:
“Что именно пользователь делает, на каком объекте, при каком сценарии и какой результат ожидает?”
Пока нет сценария, можно бесконечно сравнивать роли и всё равно не найти причину.
Роли — важны, но это не вся система доступа
Роль в 1С — это только один слой.
Да, без нужной роли пользователь не сможет выполнить действие. Но наличие роли не всегда означает, что он увидит все данные и сможет выполнить весь сценарий.
Условно доступ можно представить как цепочку:
Пользователь → роли → группы доступа → RLS → объект → связанные объекты → регистры → кодовые проверки → интерфейс
Если проблема находится на любом из этих уровней, пользователь может получить ошибку или неполный результат.
Например, пользователю добавили роль на документ. Документ он теперь открывает. Но при проведении возникает ошибка, потому что обработчик обращается к регистру, на который прав нет.
Или отчет формируется, но часть строк не выводится. Не потому что отчет сломан, а потому что RLS ограничивает видимость данных по организации.
Или кнопка не отображается. Не потому что нет роли на документ, а потому что команда формы скрыта по условию или доступность проверяется в коде.
Вот почему “добавить роль” — это не универсальный способ лечения.
Права на регистры: то, о чем часто вспоминают поздно
Отдельная боль — права на регистры.
Про документы и справочники обычно вспоминают быстрее. Пользователь открывает документ, видит ошибку, и все понимают, куда смотреть.
С регистрами сложнее.
Они могут участвовать внутри отчета, обработки, проведения документа, проверки остатка, заполнения формы или обмена. Пользователь может напрямую не знать, что система обращается к регистру.
Снаружи это выглядит так:
- отчет не формируется;
- в отчет выводится не всё;
- документ не проводится;
- форма открывается с ошибкой;
- команда отрабатывает у одного пользователя и падает у другого;
- часть данных выглядит “пустой”.
А внутри причина может быть простой: не хватает прав на чтение или запись регистра.
И тут важно не решить проблему слишком грубо.
Можно быстро выдать широкие права и “починить” ошибку. Но вместе с этим случайно открыть пользователю данные, которые он видеть не должен.
Лишние права опаснее, чем временное неудобство.
Временное неудобство видно сразу: пользователь не может выполнить действие.
Лишние права могут долго оставаться незаметными. Пользователь просто получает доступ к данным, которые не должен видеть.
Когда доступ есть там, где его быть не должно
Проблемы прав — это не только “пользователь не может”.
Не менее опасная ситуация — пользователь может больше, чем должен.
Например, пользователь через поиск открывает регистр, данные которого ему не предназначены. Или по ссылке открывает документ, который не должен видеть в обычном рабочем сценарии.
Формально может казаться: “Ну он же случайно”. Но для безопасности это слабое утешение.
Если пользователь может открыть данные через поиск, ссылку, избранное, историю или обходной путь интерфейса, значит доступ настроен не полностью.
В 1С важно проверять не только основной сценарий:
“Видит ли пользователь нужную команду в разделе?”
Но и обходные:
- может ли открыть объект по ссылке;
- может ли найти объект через глобальный поиск;
- может ли открыть связанный документ;
- видит ли движения или записи регистров;
- может ли сформировать отчет по чужим данным;
- может ли получить данные через обработку или расширение;
- видит ли данные другой организации или подразделения.
Иногда интерфейс выглядит безопасным, но доступ к данным всё равно есть.
Это как дверь, которая закрыта спереди, но открыта через служебный вход.
RLS: когда данные есть, но пользователь их не видит
RLS часто выглядит для пользователя как странная магия.
Документ существует. У коллеги он виден. В базе он точно есть. Но конкретный пользователь его не видит или не может получить в отчете.
С точки зрения пользователя это звучит просто:
“У коллеги видно, а у меня нет”.
С точки зрения сопровождения это уже задача на диагностику.
Нужно понять, что именно ограничивает данные:
- организация;
- подразделение;
- группа доступа;
- профиль доступа;
- вид документа;
- ответственный;
- партнер или контрагент;
- склад;
- настройки конкретной конфигурации;
- дополнительные ограничения в коде.
Типовой пример: пользователю добавили роль на отчет, но отчет всё равно показывает не все данные. Разработчик открывает отчет под полными правами — всё есть. Под пользователем — часть строк пропадает.
В такой ситуации отчет может быть ни при чем. Он просто честно работает в рамках ограничений доступа.
Проблема не в отчете. Проблема в настройке доступности данных.
Почему диагностика прав раздражает
Самое неприятное в диагностике прав — непонятно, где именно ограничение.
Ошибка может появляться на действии, которое само по себе выглядит простым.
Например, пользователь открывает документ. Но при открытии форма выполняет запрос к связанным данным, читает регистр, проверяет состояние процесса, получает настройки или обращается к объекту, на который прав нет.
Снаружи это “не открывается документ”.
Внутри это может быть проблема:
- в праве на чтение самого документа;
- в праве на связанный справочник;
- в праве на регистр сведений;
- в RLS по организации;
- в дополнительной проверке роли;
- в коде расширения;
- в форме, которая обращается к лишним данным при открытии.
Вторая неприятность — воспроизведение.
У разработчика под полными правами всё работает. У пользователя — ошибка. Нужно либо заходить под пользователем, либо воспроизводить его набор ролей и ограничений, либо аккуратно сравнивать настройки.
Именно поэтому хорошая диагностика прав начинается не с хаотичного добавления ролей, а с нормального сценария воспроизведения.
Алгоритм диагностики: от пользователя к коду
Я бы шел от простого к сложному.
Не сразу в код. Не сразу менять роли. Сначала понять контекст.
1. Уточнить сценарий
Нужно получить не просто “нет доступа”, а конкретику:
- какой пользователь;
- какая база;
- какой объект;
- какое действие выполняет;
- какой текст ошибки;
- когда появилось;
- у кого работает;
- что должно быть видно;
- что фактически видно.
Фраза “у коллеги видно” полезна, если известен коллега. Тогда можно сравнивать не абстрактные права, а две конкретные настройки.
2. Проверить пользователя
Сначала базовое:
- активен ли пользователь;
- к каким группам относится;
- какой профиль или группа доступа назначены;
- какие роли получены напрямую или через группы;
- нет ли отличий от пользователя, у которого всё работает.
3. Проверить роли и группы доступа
На этом этапе важно не просто добавить всё подряд, а понять, какой роли не хватает и почему.
Если дать слишком широкие права, проблему можно скрыть, но не решить.
Особенно осторожно нужно относиться к ПолнымПравам.
ПолныеПрава удобны для проверки, но опасны как постоянное решение.
4. Проверить RLS и ограничения по данным
Если объект существует, но пользователь его не видит, нужно смотреть ограничения:
- организация;
- подразделение;
- склад;
- ответственный;
- группа доступа;
- сегмент данных;
- настройки конкретной подсистемы.
Здесь полезно сравнить пользователя, у которого работает, и пользователя, у которого не работает.
5. Проверить права на объект и связанные данные
Документ редко живет один.
В форме или обработке могут участвовать:
- справочники;
- регистры сведений;
- регистры накопления;
- задачи;
- бизнес-процессы;
- файлы;
- дополнительные сведения;
- настройки пользователей;
- связанные документы.
Права нужно проверять не только на главный объект, но и на то, что он использует.
6. Проверить кодовые проверки
Если стандартные настройки выглядят корректно, пора идти в код.
В коде могут быть проверки:
- ролей;
- групп пользователей;
- функциональных опций;
- организаций;
- состояния документа;
- этапа процесса;
- дополнительных настроек;
- параметров сеанса.
Иногда доступность команды или формы определяется не только правами, но и логикой разработчика.
7. Проверить расширения и доработки
Расширение может добавить объект, команду, обработчик или проверку.
Если права на новый объект не настроены, пользователь получит ошибку. Если команда добавлена на форму, но доступность не продумана, она может быть видна не тем пользователям или не видна тем, кому нужна.
После релизов и обновлений такие вещи особенно важно проверять.
Что проверять при ошибке доступа
| Уровень | Что проверить | Что может быть причиной |
|---|---|---|
| Пользователь | Активность, группы, профиль доступа | Пользователь не включен в нужную группу |
| Роли | Наличие прав на объект и действие | Не хватает роли на чтение, запись, проведение или интерактивное открытие |
| Группы доступа | Настройки доступных организаций, подразделений, объектов | Пользователь ограничен не той областью данных |
| RLS | Ограничения на уровне записей | Данные есть, но фильтруются ограничением |
| Связанные объекты | Справочники, документы, файлы, задачи | Форма или отчет обращается к объекту без прав |
| Регистры | Чтение и запись регистров | Отчет или документ не может получить данные |
| Код | Проверки ролей, условий, параметров | Доступ ограничен логикой доработки |
| Расширения | Новые команды, объекты, обработчики | После доработки не настроены права |
Эта таблица не заменяет полноценную диагностику, но помогает не прыгать сразу в случайные места.
Почему лишние права опаснее временного неудобства
Когда пользователь не может выполнить работу, это заметно сразу.
Он пишет в поддержку. Звонит. Просит исправить. Руководитель уточняет срок. Проблема видима.
А вот лишние права могут жить тихо.
Пользователь может видеть чужие документы, регистры, данные другой организации, служебную информацию, технические объекты или то, что не относится к его функции.
И если никто это не проверяет, ситуация может сохраняться месяцами.
Особенно опасны временные решения:
- “давайте дадим ПолныеПрава на пару дней”;
- “пусть пока работает так”;
- “потом уберем”;
- “ему нужно срочно, разберемся позже”;
- “добавим роль пошире, чтобы ошибка ушла”.
Проблема в том, что “потом” часто не наступает.
Права остаются. Пользователь меняет должность. Проект заканчивается. Временный доступ превращается в постоянный. Через год уже никто не помнит, почему он был выдан.
Лишние права опаснее, чем временное неудобство, потому что неудобство видно сразу, а лишний доступ может годами оставаться незамеченным.
Что должен видеть руководитель или администратор
В отчете по правам не всегда полезна огромная техническая простыня.
Руководителю и администратору нужны понятные ответы:
- кто имеет ПолныеПрава;
- у кого есть доступ к критичным объектам;
- кто может видеть документы и данные вне своей зоны ответственности;
- есть ли активные пользователи с лишними ролями;
- есть ли технические учетные записи с широкими правами;
- какие ограничения реально действуют;
- какие пользователи выбиваются из общей модели доступа;
- где есть риск открытия регистров или документов через поиск/ссылку;
- что нужно проверить в первую очередь.
Хороший аудит прав должен показывать не только “у пользователя такие-то роли”, а возможный риск.
| Что нашли | Почему это риск | Что сделать |
|---|---|---|
| Пользователь с ПолнымиПравами | Может видеть и менять больше, чем требуется | Проверить необходимость и срок доступа |
| Доступ к регистрам через поиск | Можно увидеть данные вне рабочего сценария | Проверить права на чтение и ограничения |
| Доступ к документам по ссылке | Интерфейс может скрывать объект, но прямой доступ остается | Проверить RLS и права на объект |
| Широкие роли у обычного пользователя | Доступ может превышать должностные обязанности | Сравнить с профилем должности |
| Нет ограничений по организации | Пользователь может видеть чужую область данных | Настроить группы доступа и RLS |
| Временные права без срока | Временный доступ становится постоянным | Ввести дату пересмотра прав |
Здесь важна не охота на виноватых.
Права в 1С часто расползаются постепенно: срочная задача, временное назначение, переход сотрудника, доработка, релиз, новая роль, забытая учетная запись.
Если это не контролировать, система доступа со временем перестает отражать реальную организационную структуру.
Мини-чек-лист аудита прав
Для первичной проверки я бы использовал такой чек-лист.
| Что проверить | Зачем |
|---|---|
| Пользователи с ПолнымиПравами | Найти самый высокий уровень риска |
| Активные пользователи | Понять, кто реально может входить в систему |
| Технические учетные записи | Проверить, не используются ли они шире необходимого |
| Роли обычных пользователей | Сравнить с должностными обязанностями |
| Группы доступа | Проверить ограничения по организациям, подразделениям и объектам |
| Доступ к критичным документам | Понять, кто может читать и изменять важные данные |
| Доступ к регистрам | Исключить просмотр данных через обходные сценарии |
| Открытие объектов по ссылке | Проверить, не обходится ли интерфейсное ограничение |
| Доступ через отчеты | Понять, не раскрывают ли отчеты лишние данные |
| Изменения прав за период | Найти неожиданные назначения и снятия ролей |
Этот чек-лист особенно полезен после крупных изменений:
- обновления конфигурации;
- внедрения новых ролей;
- запуска расширений;
- изменения оргструктуры;
- массового перевода сотрудников;
- инцидента с доступом;
- приемки базы на сопровождение.
Как не превратить настройку прав в хаос
Права нужно сопровождать так же, как код и процессы.
Не идеально, не бюрократически, но системно.
1. Не выдавать широкие права без причины
Если пользователь просит “как у коллеги”, это еще не основание копировать все роли.
Сначала нужно понять, какая конкретно операция не выполняется.
2. Фиксировать временные доступы
Если права выданы временно, должен быть срок пересмотра.
Иначе временный доступ почти гарантированно станет постоянным.
3. Проверять не только интерфейс
Если пользователь не видит объект в разделе, это еще не значит, что он не может открыть его по ссылке или через поиск.
Для важных данных нужно проверять обходные сценарии.
4. Следить за правами на регистры
Регистры часто содержат данные, которые пользователь не должен видеть напрямую.
Если открыть доступ слишком широко, можно случайно раскрыть больше информации, чем планировалось.
5. Документировать логику ролей
Не обязательно писать большой регламент.
Но должно быть понятно:
- какие роли для кого предназначены;
- какие права считаются опасными;
- кто согласует выдачу;
- кто проверяет лишние доступы;
- как часто проводится пересмотр.
Без этого через год никто не вспомнит, почему конкретному пользователю дали конкретную роль.
План проверки прав за 30 дней
Если доступы давно не проверялись, не обязательно сразу устраивать большой проект.
Можно начать с короткого практического цикла.
Неделя 1. Собрать картину
- Выгрузить список активных пользователей.
- Отдельно выделить пользователей с ПолнымиПравами.
- Найти технические учетные записи.
- Собрать основные роли и группы доступа.
- Отметить пользователей, которые выбиваются из типовой модели.
Неделя 2. Проверить критичные зоны
- Определить важные документы, справочники и регистры.
- Проверить, кто имеет доступ к этим объектам.
- Проверить доступ через поиск и открытие по ссылке.
- Посмотреть, не видят ли пользователи данные чужих организаций или подразделений.
Неделя 3. Разобрать спорные доступы
- Проверить, почему выданы широкие роли.
- Уточнить необходимость временных доступов.
- Согласовать снятие лишних прав.
- Зафиксировать исключения, если они действительно нужны.
Неделя 4. Закрепить контроль
- Описать минимальные правила выдачи прав.
- Ввести периодический пересмотр пользователей с ПолнымиПравами.
- Согласовать порядок временных доступов.
- Добавить проверку прав в чек-лист после релизов и расширений.
Задача такого плана — не построить идеальную модель безопасности за месяц.
Задача проще: перестать жить в ситуации, когда никто не понимает, кто что видит и почему.
Главный вывод
Проблемы доступа в 1С не всегда решаются добавлением роли.
Иногда причина в RLS. Иногда в группе доступа. Иногда в организации или подразделении. Иногда в правах на регистр. Иногда в связанном объекте. Иногда в коде или расширении.
Поэтому диагностика прав должна идти по слоям, а не по принципу “давайте дадим побольше”.
Когда пользователь не видит нужный документ, это неприятно. Но это видно сразу и обычно быстро попадает в поддержку.
Когда пользователь видит лишнее, это может не попасть никуда. Он просто имеет доступ к данным, которые не должен видеть.
Именно поэтому я бы оставил главный тезис таким:
Лишние права опаснее, чем временное неудобство.
Удобство важно. Пользователь должен работать без лишних барьеров.
Но если ради удобства раздавать широкие доступы без диагностики и контроля, система постепенно превращается в набор исключений, временных решений и забытых прав.
А потом наступает момент, когда вопрос уже звучит не “почему пользователь не видит документ?”, а гораздо хуже:
“Почему он вообще мог это увидеть?”
И лучше задать этот вопрос во время аудита, а не после инцидента.
Сравнение пользователей, ролей и прав 1С: кто получил полные права и какие роли изменились
Вступайте в нашу телеграмм-группу Инфостарт