Матрица доступа в 1С: почему кладовщик не должен видеть зарплатную ведомость

Расскажу историю, которая случилась у одного нашего клиента — оптовой компании со складом на сорок с лишним позиций. Кладовщик открыл 1С посмотреть остатки и случайно наткнулся на раздел «Зарплата». Не потому что он хакер. Просто у него были права «Полные», как у директора.

Как я вообще узнал про эту дыру

Мне позвонила директор в бешенстве. Кладовщик разболтал в курилке, сколько получает менеджер по продажам. Менеджер обиделся, устроил скандал, чуть не уволился. Директор искала виноватого — думала, слили бухгалтерию через почту или флешку. А оказалось всё проще и обиднее: у парня на складе стоял тот же логин в 1С, что и у главбуха. Роль «Полные права». Заходи и смотри что хочешь.

Мы подняли базы ещё пяти клиентов из того же сегмента — до пятидесяти рабочих мест — и картина одинаковая. Восемь баз из десяти живут с одной-двумя ролями на всех: либо «Администратор», либо самопальная роль, которую когда-то сделал приходящий программист «чтобы работало». Работает — да. Безопасно — нет.

Сетевой доступ — это не про 1С

Директора часто путают две вещи: защиту периметра и защиту данных внутри программы. У них стоит нормальный фаервол, VPN для удалённых сотрудников, сложные пароли на Windows, иногда даже КриптоПро для отчётности. И это правильно, это база. Но всё это защищает от того, кто снаружи. А права в 1С защищают от того, кто уже внутри — и таких людей у вас на порядок больше.

Классика: терминальный сервер на RDP, десять сотрудников заходят под своими windows-учётками, антивирус свежий, бэкапы Veeam ходят исправно. А в самой 1С — общий логин «Продажи» с паролем 1234, который знает вся отгрузка. Снаружи крепость, изнутри проходной двор. Я это вижу у клиентов регулярно, и это не про злой умысел — просто руки не дошли.

Из чего вообще состоит ролевая модель 1С

В 1С есть три уровня, и путать их не надо. Роли — это набор прав на объекты: читать справочник «Номенклатура», редактировать документ «Реализация», проводить, удалять. Профили групп доступа — это удобная обёртка над ролями, чтобы не назначать каждому по десять галочек вручную, а выдать готовый комплект «Кладовщик» или «Менеджер по продажам». И третий уровень, самый мощный и самый недооценённый — RLS, ограничение доступа на уровне записей.

RLS — это когда пользователь видит документ «Реализация», но не любой, а только по своему складу или своей организации. Или видит справочник «Контрагенты», но зарплатную ведомость из этого же меню — нет, потому что она физически в другом объекте метаданных, до которого роль просто не доходит. Большинство типовых конфигураций — Бухгалтерия, УТ, ЗУП — уже несут в себе десятки готовых ролей. Их почти никогда не используют. Проще один раз выдать «Полные права» и забыть.

Как это выглядит на практике — реальная матрица

У того же клиента мы в итоге построили простую таблицу на четыре роли. Кладовщик: видит номенклатуру, остатки по своему складу, документы поступления и реализации — но без закупочных цен и без вкладки «Расчёты». Зачем ему знать, что вы купили товар за 300 рублей, а продаёте за 900? Это не его работа, а для конкурента — готовая утечка маржи.

Менеджер по продажам видит своих клиентов, свои заказы, свою историю отгрузок — но не видит чужую клиентскую базу целиком и уж точно не видит раздел «Зарплата и кадры». Бухгалтер видит зарплату, налоги, банк — но не лезет в переписку с клиентами в CRM и не может завизировать себе премию задним числом. Директор видит всё — и это единственная роль, где так и должно быть.

Настраивается это не программированием с нуля, а комбинацией готовых профилей плюс два-три уточнения под конкретную компанию. У кого-то склад один, у кого-то три обособленных подразделения — тогда добавляем RLS по складу или по организации. Час работы конфигуратора против недели репутационных разборок — я считаю, это не вопрос выбора.

Ошибки, которые я вижу каждый месяц

Общий логин на всех — самая частая беда. «Продажи», «Склад», «Бухгалтерия» с одним паролем на отдел. Потом невозможно понять, кто именно провёл документ задним числом или удалил накладную — в журнале регистрации висит обезличенное «Продажи», а таких людей четверо.

Вторая беда — уволенные сотрудники с живыми учётками. У одного клиента бывший менеджер, уволенный в марте, спокойно зашёл в базу через RDP в мае — просто никто не отключил ему доступ — и выгрузил себе прайс-лист с реальными закупочными ценами. Ушёл к конкуренту. Доказать что-то в суде почти нереально, потому что формально доступ у него был.

Третья — роль «Полные права» выдаётся новому сотруднику на испытательный срок «чтобы быстрее разобрался». Разобрался, ушёл через два месяца, а до этого успел увидеть зарплаты всего отдела. Мелочь, а осадок у коллектива остаётся на годы.

Как мы это внедряем у клиентов — без остановки работы

Начинаем с аудита: смотрим, кто под какой ролью сидит сейчас, кто вообще ни разу не заходил последние три месяца — таких обычно человека два-три на компанию в двадцать сотрудников, это либо уволенные, либо технические учётки без хозяина. Потом короткое интервью с директором — не с айтишником, а именно с руководителем: кто реально должен видеть зарплату, кто — закупочные цены, кто — финансовый результат по сделкам.

Дальше конфигуратор, готовые профили плюс тонкая настройка через RLS там, где нужно. Тестируем на копии базы — заходим под тестовым пользователем каждой роли и физически проверяем, что кладовщик не видит зарплату, а не просто верим, что галочка сработала. Для базы на пятнадцать-двадцать пользователей это два-три дня работы, ценник обычно укладывается в 25-40 тысяч рублей в зависимости от количества уникальных ролей и сложности организационной структуры.

Отдельно всегда советую завести регламент: новый сотрудник — сразу под правильную роль, а не под «полные права до выяснения». Увольнение — в тот же день блокировка учётки, а не «на следующей неделе разберёмся». Это дешевле любого софта.

Что бизнес получает в итоге

Зарплата — это персональные данные, и по 152-ФЗ доступ к ним обязан быть ограничен кругом лиц, которым он нужен по работе. Если у вас проверка Роскомнадзора или трудовой спор дойдёт до суда, а выяснится, что зарплату видел весь склад — вопросов к директору будет много, и не только этических.

Но честно, дело даже не в бумажках. Дело в спокойствии. Когда я показываю директору готовую матрицу и мы вместе проходим по ролям — кладовщик, менеджер, бухгалтер — он выдыхает в буквальном смысле. Два-три дня настройки один раз против бесконечных мелких утечек, слухов в курилке и ухода людей с прайсом в кармане. Мне кажется, выбор тут очевидный.

Частые вопросы

Сколько стоит настроить права доступа в 1С для небольшой компании?
Для базы на 15-20 пользователей с четырьмя-пятью ролями это обычно 2-3 дня работы и 25-40 тысяч рублей. Если структура сложнее — несколько юрлиц, обособленные склады, разные виды деятельности — время и стоимость растут, но не кратно, потому что основа берётся из готовых профилей конфигурации.

Не будет ли 1С тормозить из-за ограничений на уровне записей (RLS)?
На базах до полусотни пользователей и разумного объёма данных заметной просадки я не видел ни разу. RLS добавляет условие в запрос, и на клиент-серверном варианте с нормальным SQL Server это единицы процентов нагрузки. Тормозит обычно не RLS, а старое железо сервера, но это отдельный разговор.

Что делать с уволенными сотрудниками, у которых остался доступ?
Блокировать учётку в день увольнения, а не когда вспомнят. Мы обычно настраиваем это как обязательный пункт в чек-листе увольнения вместе со сдачей пропуска и ноутбука. Отдельно проверяем раз в квартал список активных пользователей 1С на предмет тех, кто не заходил месяцами.

Как часто нужно пересматривать матрицу доступа?
Раз в полгода — плановая ревизия, плюс внепланово при смене должности сотрудника или запуске нового направления бизнеса. Матрица не высекается в камне: кладовщик, ставший начальником склада, законно получает больше прав, но именно осознанно, а не потому что никто не убрал старую роль.