Почему роли в 1С надо строить не по должностям, а по живым сценариям работы
Привет, это СБиСик. И вот вам история, которая в компаниях повторяется с завидным упрямством: «давайте дадим сотруднику права на все, чтобы не тормозил». На словах удобно, на деле — почти всегда тихий хаос. Сегодня кто-то случайно удалил документ, завтра увидел лишний отчет, послезавтра бухгалтерия ищет, кто поменял проведенный документ, а найти уже непросто. Вроде бы 1С работает, люди не жалуются, а внутри системы уже накопилась мина замедленного действия.
Именно поэтому настройка ролей в 1С — это вообще не про «поставить галочку в конфигураторе». Это про то, как у вас устроены бизнес-процессы, кто что делает, кто только смотрит, а кто еще и имеет право что-то менять. И вот тут очень важный поворот: роль нельзя проектировать по названию должности. Нельзя думать в стиле «ну он же менеджер, значит, ему надо как менеджеру». Нет, не надо. Сначала смотрим на сценарий работы: какие документы человек создает, какие редактирует, а какие вообще не должен даже видеть.
Я это часто повторяю, потому что именно здесь и начинается нормальная архитектура безопасности. Если роль описывает не реальную работу, а абстрактную должность, потом система быстро превращается в склад лишних прав. А лишние права — это уже не про удобство, а про риски. Кстати, короткие заметки по таким историям я иногда выкладываю быстрее в наш канал в MAX, потому что пока длинно расскажешь, в практике уже успевает всплыть еще один похожий случай.
В типовых конфигурациях 1С — будь то Бухгалтерия, УТ или ЗУП — стандартные роли, конечно, есть. И это хорошо, без них было бы совсем грустно. Но жизнь, как обычно, любит вносить свои поправки. У одной компании менеджер по продажам только создает заказы, у другой — еще и меняет цены, у третьей — согласует скидки, а в четвертой вообще работает через отдельное подразделение и видит только свой регион. И вот попробуй под это подвести одну-единственную стандартную роль. Не выйдет. Начинается сборка собственной модели доступа, гибридной такой: где-то технически роли создаются в конфигураторе, а потом уже удобно назначаются через профили групп доступа в пользовательском режиме.
И это, кстати, очень правильный путь. Потому что в 1С роли лучше делать атомарными, то есть маленькими, точечными, на одну функцию или близкий набор действий. Не клубок прав, а аккуратный кирпичик. Одна роль — чтение справочника, другая — добавление и изменение документов, третья — отдельное действие вроде запуска внешней обработки. А потом из этих кирпичиков собирается профиль. Вот профиль и становится тем самым удобным инструментом для назначения прав человеку или целой группе сотрудников.
Если сказать совсем по-человечески: роль — это не «кто ты по жизни», а «что ты делаешь в системе». И это, между прочим, одно из самых частых заблуждений. Менеджер по закупкам в одной компании может только заводить заявки, а в другой — еще согласовывать поставщиков и смотреть аналитику по ценам. Должность одна, сценарии разные. Поэтому роль должна называться и проектироваться по смыслу, а не по табличке в штатном расписании. Иначе потом начинается веселье: один сотрудник видит слишком много, другой — слишком мало, а третий вообще не может провести свой же документ, хотя «вроде же доступ был».
Сначала сценарий, потом конфигуратор
Вот тут и появляется нормальный порядок работы. Не с создания роли в 1С начинается история, а с бумажки, схемы, списка задач — как угодно назовите. Сначала надо понять: какие документы пользователь создает, какие редактирует, какие только просматривает, какие отчеты ему нужны, а какие, если честно, вообще ни к чему. И только потом уже идти в конфигуратор, в ветку Общие/Роли, и собирать нужные права.
Причем подход «ненужного не видать» здесь очень помогает не только безопасности, но и самой работе людей. Когда сотрудник не видит лишние документы и отчеты, у него меньше шума перед глазами. Меньше соблазнов что-то открыть «а вдруг пригодится». Меньше случайных кликов. Меньше путаницы. В интерфейсе вообще становится чище, и человек быстрее понимает, куда ему идти. Я это видел не раз: после нормальной разгрузки прав рабочее место вдруг становится легче, и сотрудники сами удивляются, почему раньше у них на экране было по двадцать пунктов меню, из которых реально нужно три.
А еще есть неприятная вещь, о которой обычно вспоминают только после инцидента: доступ «на все» очень плохо лечится потом. Полные права кажутся спасением, когда «нужно срочно проверить», «временно посмотреть», «пока не разобрались». А потом эти временные права живут годами. И вот уже бухгалтер с полными правами может удалить документ за прошлый месяц, поправить проведенную операцию или случайно исказить отчет. Дальше начинается перепроведение, сверки, поиск виноватых, а иногда и совсем неприятные юридические вопросы. Тут уже не до удобства, честно говоря.
Кстати, в реальной работе я однажды видел ситуацию, когда сотруднику дали расширенные права просто потому, что он «часто просит доступ к документам». Не злой умысел, нет. Просто все хотели сэкономить время. А потом выяснилось, что он случайно удалил старый документ по списанию ТМЦ. И вроде бы мелочь, но когда такой документ влияет на учет и пересчет, мелочь моментально превращается в большую головную боль. Вот вам и «удобно».
И еще один важный момент: в 1С пользователь в нормальной схеме получает не роль напрямую, а профиль группы доступа. Это очень удобная штука, потому что профиль уже собирает нужный набор ролей. То есть администратор или ответственный сотрудник назначает человеку не десяток отдельных прав, а один понятный профиль. Для массового управления это вообще спасение. Особенно если сотрудников много, а изменения происходят часто. Внешне это выглядит просто, но на самом деле это и есть тот самый аккуратный слой между конфигуратором и живыми пользователями.
Иногда такие истории сначала попадают в наш Telegram-канал, потому что там удобно быстро обсудить нюанс, коротко показать ошибку или случай из практики без долгого разбора. А потом уже из этих заметок вырастает большая статья, как сейчас.
Но тут есть важная тонкость, которую часто упускают. Роли создаются в конфигураторе, а вот менять их в режиме пользователя нельзя. Нельзя зайти в карточку сотрудника и «подправить роль». В пользовательском режиме работают именно с профилями и их назначением. И это логично: роли — это объект конфигурации, то есть часть архитектуры системы. А профили — уже административная прослойка, удобная для назначения.
Из-за этого у многих и возникают странные ожидания. Создали пользователя, а он не заходит. Или не видит нужный пункт меню. Начинают искать, где «поставить галочку на роль». А галочки-то и нет. Сначала проверяют, назначен ли профиль доступа, потом смотрят, входит ли туда нужная роль, а уже потом лезут глубже. И да, бывает и совсем банально: пользователя создали, а профиль ему просто не назначили. Такое, увы, случается чаще, чем хотелось бы.
Есть еще один момент, без которого вся система может развалиться на ровном месте: в базе всегда должен быть хотя бы один пользователь с ролью ПолныеПрава. Вот прямо обязательно. Если его случайно заблокировать, удалить или потерять доступ к этой учетке, система становится очень неудобной для обслуживания, а иногда и почти неуправляемой. То есть минимизация доступа — это правильно, но крайностей тут быть не должно. Администратор с полным доступом нужен как страховка, как технический ключ от машины, который лежит не в багажнике, а у того, кто реально может открыть капот, если что-то пошло не так.
И вот здесь я бы отдельно подчеркнул: принцип минимально необходимого доступа — это не жадность и не бюрократия. Это нормальная защита бизнеса. Если человеку нужен только просмотр, не надо давать ему редактирование. Если он должен только создавать документы, не надо делать ему права на удаление всего подряд. Если он работает только по своему подразделению, не надо пускать его в чужие данные. Каждое лишнее право — это лишняя точка риска. Причем риск не только для безопасности, но и для скорости работы. Чем больше лишнего в системе, тем больше у человека шума в голове, а это уже мешает быстрее делать свою работу.
И тут же всплывает тема стандартных и специальных прав. Например, для интерактивного открытия внешних отчетов и обработок нужна отдельная роль с соответствующим правом. Если ее нет, пользователь может видеть, что файл существует, но открыть его не сможет. Технически мелочь, а в жизни это сразу вызывает вопросы: «почему у меня не запускается отчет?», «почему обработка не открылась?», «вчера же работало». И начинается обычная для 1С история — вроде бы доступ есть, а вроде бы и нет.
Если говорить совсем практично, правильная настройка ролей в 1С должна проходить по цепочке. Сначала анализируем задачи. Потом описываем сценарии. Потом создаем атомарные роли в конфигураторе. Потом собираем профили групп доступа. Потом назначаем профиль пользователю. И только потом тестируем не просто вход в программу, а весь сценарий целиком: создал документ, провел, посмотрел отчет, открыл нужную обработку, попробовал изменить данные. Вот тогда сразу видно, где что-то забыли, где права пересекаются, а где, наоборот, человека лишили необходимого действия.
И да, важная ремарка на полях: если у вас в конфигурации используются расширения, то роли для нового функционала тоже добавляются именно там, в расширении, а назначение идет через новые профили. Это многие почему-то пропускают, а потом удивляются, что модуль внедрили, отчет появился, а бухгалтер его не видит. Ну конечно не видит — если роль создали, а профиль с ней в базу не добавили, чудес не будет. Точнее, чудеса будут, но только из серии «почему ничего не работает».
Дальше уже начинается самый интересный кусок: как именно разложить права по объектам, где разделять чтение и изменение, почему проведение документов не всегда требует прямых прав на регистры, и как не наделать клубок из ролей, от которого потом сама же 1С начинает скрипеть. Там как раз и всплывают тонкие вещи про RLS, привилегированный режим и тестирование по реальным сценариям, а вот это уже отдельная история, и она, честно, бывает очень показательной…
Отличия в сценариях работы и их последствия
Когда мы говорим о сценариях, важно понимать, что именно сценарий определяет, какие роли нужны. Например, в одной компании продавцы могут заниматься только созданием заказов, а в другой — еще и указывать скидки. Следовательно, если будете настраивать роль для продавца, подчеркните именно его сценарий: создание документа и, возможно, изменение. Но вряд ли стоит предоставлять возможность доступа к согласованию цен или оборотам компании.
На практике это означает, что мы должны проанализировать, что же конкретно делает каждый сотрудник. Как минимум, это позволит избежать ситуации, когда, к примеру, менеджер по закупкам видит не только свои закупки, но и зарплаты остальных сотрудников — такое смешение ролей не только путает, но и может привести к потенциальным утечкам информации.
Ошибки при настройке ролей
Еще одна распространенная ошибка — это когда администраторы забывают о том, что при обновлении конфигурации может появиться необходимость пересмотреть доступы. У одного клиента я сталкивался с ситуацией: обновление нового функционала пошло без потерь, но старые пользователи не видели новых полей в документах. Внутренние процессы работали под старую схему: роли новых объектов не были доработаны.
Внимание к обновлениям — это не просто формальность. Права должны устанавливаться по умолчанию для новых объектов, чтобы не возникало ситуаций, когда информация недоступна или недоступно редактирование необходимых данных.
Выбор между правами и безопастностью
Важно помнить: не всегда необходимы все права. Один из клиентов, стремясь упростить работу бухгалтера, дал ему доступ на удаление старых документов. Результат — случайное удаление необходимого документа, который был закрыт или использовался для отчетности. Возникает вопрос: насколько облегчение работы того стоило, если выходило в итоге на несколько неприятных случаев сборки данных заново?
Это не единичный пример. Давайте взвесим противоречивый подход: можно быстро настроить роли «на всё», что, казалось бы, упростит всё, но на выходе это приведет лишь к в адвокате, который все же требует её фиксировать. Неправильные настройки могут привести к худшим эффектам.
Тестирование прав доступа
Не забывайте про тестирование. Проверка прав не должна заключаться в простом входе в систему и выходе. Пройдите полный жизненный цикл: создаете документ, проводите, формируете отчет — и сразу обнаружите проблемные места. Я однажды провел такой тест и наткнулся на ситуацию, когда права не совпадали — документ провел, на числе данных — было запрещено.
Клиенты, которые провели эту процедуру несколько раз, отмечали, что это сократило время доработки и свело к минимуму конфликты прав. Не пренебрегайте этой простейшей практикой.
И под конец: создание ролей в 1С — это не разовая процедура. Обеспечьте внимание к изменениям в бизнес-процессах и конфигурациях. Это как живое существо — требует заботы и контроля. Никакой фиксированной схемы, только адаптация и тестирование.