Настройка прав доступа, ролей и RLS в 1С. Профили безопасности, разграничение данных. Безопасная оплата через защищённый счёт Платформы.
Права доступа в 1С — это тихая, но критичная часть системы. Пока всё настроено правильно, её не замечают; стоит ошибиться — и менеджер видит чужие сделки, кладовщик правит цены, а уволившийся сотрудник продолжает заходить в базу. Грамотная настройка ролей и профилей делает так, чтобы каждый видел и менял ровно то, что нужно для работы, и ничего сверх этого. Это одновременно вопрос порядка и вопрос защиты данных.
На Koderion такие задачи заказывают и при запуске новой базы, когда роли раздаются с нуля, и в работающей системе, где доступы разрослись хаотично за годы. Бизнес описывает структуру компании и кому что положено видеть, верифицированные специалисты предлагают схему разграничения. Оплата замораживается и уходит исполнителю после приёмки, поэтому настройку доводят до рабочего состояния, а не оставляют наполовину.
Базовый запрос — навести порядок в ролях: сделать так, чтобы продавцы работали только с продажами, бухгалтерия — с учётом, а руководители видели сводную картину без права лезть в первичные документы. На практике это означает продуманные профили доступа, собранные из ролей под реальные должности, а не выдачу прав по принципу «дайте всё, чтобы не мешало работать».
Часто просят разграничить данные между подразделениями или филиалами: чтобы один офис не видел продажи и контрагентов другого, а общие справочники при этом оставались едиными. Это уже не про роли целиком, а про ограничения на уровне конкретных записей, и здесь начинается самая тонкая часть настройки.
Ещё один регулярный запрос — закрыть чувствительные участки: зарплату, себестоимость, персональные данные. Доступ к ним должен быть у единиц, и настройка должна это гарантировать, а не полагаться на договорённость не заглядывать.
Когда недостаточно просто открыть или закрыть целый раздел, в ход идёт ограничение доступа на уровне записей. RLS позволяет показывать сотруднику не весь справочник или журнал, а только те строки, которые относятся к нему: его клиентов, его склад, его подразделение. Снаружи интерфейс выглядит обычно, но данные отфильтрованы прозрачно для пользователя.
Настройка RLS требует аккуратности, потому что ограничения работают на уровне запросов к базе и при неумелой реализации заметно замедляют систему. Опытный специалист балансирует между строгостью разграничения и производительностью, проверяя, что фильтры не превращают каждое открытие списка в тяжёлый запрос.
Важно и протестировать результат от лица разных сотрудников. Настройка считается завершённой не тогда, когда написаны условия, а когда под каждой ролью видно ровно то, что задумано, и ничего лишнего не просачивается через отчёты или связанные документы.
В компаниях с несколькими отделами или филиалами доступ удобно привязывать к структуре: сотрудник автоматически видит данные своего подразделения, руководитель — своего направления целиком, а центральный офис — всё. Такая схема избавляет от ручной раздачи прав каждому новому человеку: его достаточно отнести к нужному подразделению, и доступы выстраиваются сами.
Тонкость в пограничных случаях. Сотрудник переходит между отделами, работает на два направления сразу или замещает коллегу на время отпуска. Хорошая схема разграничения заранее учитывает такие ситуации, чтобы они решались настройкой, а не срочным вмешательством администратора каждый раз.
Разграничение прав — это первый рубеж, но не единственный. Для чувствительных данных важно не только ограничить доступ, но и видеть, кто что делал: кто открывал, менял или выгружал информацию. Журнал регистрации и настройки протоколирования позволяют восстановить картину, если возникнут вопросы к изменениям или утечке.
Отдельная тема — гигиена учётных записей. Общие логины «на отдел», бессрочные права у подрядчиков, активные учётки уволенных сотрудников сводят на нет любую тонкую настройку ролей. Специалист обычно наводит порядок и здесь: персональные учётные записи, своевременное отключение, регулярный пересмотр того, у кого какие права остались.
Простые задачи — собрать пару профилей, закрыть один раздел, отключить лишние права — стоят немного и делаются быстро. Цена растёт вместе со сложностью логики: разграничение по подразделениям, ограничения на уровне записей и нетиповые правила доступа требуют проектирования и тщательного тестирования, и это уже работа на десятки тысяч рублей.
Самые объёмные проекты — выстроить систему доступа с нуля для большой компании со сложной структурой и множеством ролей — оцениваются индивидуально. На Koderion стоимость называет исполнитель, оттолкнувшись от вашего описания структуры и требований. Полезно сразу приложить схему, кто какие данные должен видеть, — чем точнее вводные, тем предметнее предложения специалистов.
Настройка прав — область, где ошибка не всегда видна сразу, а всплывает в самый неудобный момент. Поэтому важен специалист, который мыслит сценариями: проговаривает, что должно быть видно каждой роли, и обязательно проверяет результат под разными пользователями, а не только декларирует, что всё настроил. Просите показать, как именно он тестирует разграничение.
Хороший знак — когда кандидат думает и о производительности, и о поддержке: предупреждает, где RLS может замедлить систему, и оставляет схему доступа понятной для будущего администратора, а не запутанным набором исключений. На Koderion выбрать помогают отзывы и история похожих работ, а безопасная сделка гарантирует, что оплата уйдёт только после того, как вы убедитесь: доступы работают именно так, как договаривались.
RLS (Record Level Security) — это механизм ограничения доступа не только к объектам конфигурации, но и к конкретным записям в базе данных. Например, менеджер видит только своих клиентов, а кладовщик — только свой склад. Настройка RLS требует опыта и глубокого знания структуры данных конфигурации.
Стандартная практика: менеджеры видят заказы, счета, клиентов и цены — но не видят себестоимости и финансовой отчётности. Бухгалтерия видит финансовые проводки, но не может изменять прайс-листы и условия договоров. Специалист на Koderion спроектирует матрицу доступа под вашу структуру.
Да, это решается через RLS на поле «Ответственный» или «Менеджер». Сотрудник видит только те документы и записи, где он указан ответственным. Это один из самых частых сценариев при настройке прав в 1С:УТ и 1С:ERP.
Зависит от типа обновления. При обновлении типовой конфигурации стандартные роли обновляются автоматически, а пользовательские роли сохраняются. Однако при добавлении новых объектов в конфигурации их права нужно прописать вручную. Специалист проверит это при обновлении.