Безопасность 1С: как настроить роли, скрыть чужие зарплаты и включить аудит действий

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

Почему одна общая учётка — это бомба замедленного действия

Начну с конкретной истории. Прошлой осенью пришёл клиент — небольшая юрфирма, 18 рабочих мест, 1С:Бухгалтерия плюс самописная база учёта дел. В 1С все заходят под одним пользователем «Admin». Удобно: никто не забудет пароль, не надо звонить в поддержку. Через месяц выясняется — помощница юриста удалила платёжку на 340 тысяч рублей. Случайно или нет — теперь не разобрать. В журнале: ноль записей, кто это сделал. Все под одним логином. Восстанавливали по банковской выписке два дня.

Беда общей учётки — она убивает саму возможность разбирательства. Если пропали данные, а логи показывают одного безликого «Admin» — физически невозможно понять, что это было: ошибка, злой умысел или шифровальщик перед атакой прощупывал базу. Кстати, шифровальщики сейчас часто заходят именно через 1С — через слабый пароль администратора базы или незакрытый RDP. Мы с таким сталкивались.

Правило простое до банальности: у каждого сотрудника — свой логин. Полчаса работы на компанию из 15 человек. В обмен — возможность через год сказать точно: вот эта операция сделана Ивановой 14 марта в 16:42. Без этого вся остальная безопасность теряет смысл — можете дальше статью не читать.

Роли в 1С: что это и почему стандартных наборов обычно мало

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

На одном нашем проекте — производственная компания, 40 человек, три бухгалтера — стандартная роль «Бухгалтер» открывала вообще всё: и зарплату, и себестоимость, и остатки на счетах учредителей. Пришлось делать три отдельные роли вручную через конфигуратор: «Бухгалтер-первичка» (накладные, счета), «Бухгалтер-касса» и «Расчёт зарплаты» — последнюю только двум конкретным людям. Наш программист потратил часов шесть с учётом тестирования. Не бесплатно, но и не космос.

Важный нюанс: роль сама по себе прав не даёт — она назначается пользователю через список пользователей или через справочник «Пользователи» в режиме предприятия. И вот тут классическая ошибка: назначили роль при найме, через два года человек сменил отдел, а роль осталась старая. Советую раз в квартал делать ревизию — кто есть, какие роли назначены, совпадает ли это с реальными обязанностями. Пятнадцать минут, и потом кучу нервов сэкономите.

RLS — как физически спрятать чужие зарплаты, а не просто убрать кнопку из меню

Тут начинается самое интересное — и самое часто игнорируемое. Роли ограничивают доступ к объектам целиком: открыть справочник «Начисления зарплаты» или нет. Но что, если бухгалтер должен видеть зарплаты своего цеха, а зарплаты соседнего — нет? Тут приходит RLS, Row Level Security — ограничение доступа на уровне записей. В 1С это делается в конфигураторе: пишется условие, которое накладывается на каждый запрос к базе.

Разница принципиальная. Убрать пункт меню — это заклеить замочную скважину бумажкой. Любой продвинутый пользователь откроет нужный отчёт через универсальную обработку или консоль запросов — и всё равно всё увидит. RLS работает на уровне СУБД: запрос физически не вернёт строки, на которые нет прав, даже если человек полезет в базу в обход интерфейса через консоль запросов или внешнюю обработку.

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

Журнал регистрации: кто, когда и что поменял

Журнал регистрации — встроенный в 1С механизм, который пишет вообще всё: вход в базу, открытие документа, изменение реквизита, удаление, ошибку авторизации. Открывается через Все функции — Журнал регистрации, либо через отдельную утилиту логов, если база большая. Кстати, крайне рекомендую вынести журнал в отдельные файлы на диске — когда пользователей больше 15, журнал внутри базы начинает тормозить саму базу. Это отдельная настройка, пять минут делается.

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

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

Технический периметр вокруг 1С — потому что роли бессмысленны при дырявом входе

Тонкая настройка ролей — это ноль, если в базу можно зайти в обход всей системы. Классика: RDP-доступ к серверу 1С открыт напрямую в интернет на порту 3389, потому что «удалёнщикам так удобнее». Это первое, что сканируют боты — круглосуточно, без выходных. Заходят не под ролью бухгалтера, а сразу с правами администратора сервера. Там ваши роли 1С вообще не действуют.

Что мы делаем при аудите у нового клиента в первую очередь: закрываем прямой RDP, поднимаем VPN или терминальный шлюз с двухфакторной авторизацией, обновляем Windows Server до поддерживаемой версии — тот же 2012 R2 давно снят с поддержки, а на нём до сих пор крутится половина баз 1С в малом бизнесе, которые мы видим. Отдельно смотрим, кто имеет права администратора самой базы 1С через конфигуратор. Нередко находим забытую учётку бывшего программиста-фрилансера с паролем, который никто не менял три года.

И раз уж про периметр — бэкапы. Veeam, встроенное архивирование 1С — неважно что именно. Без регулярной резервной копии вся история про роли и журналы теряет смысл при первом шифровальщике. У одного клиента — мы взяли его обслуживание уже после инцидента — шифровальщик прошёл через слабый пароль RDP-администратора, зашифровал базу за одну ночь. Последний бэкап делался восемь месяцев назад. Восстанавливали частично из выгрузок в банк-клиент и по памяти бухгалтера. Не повторяйте.

Как внедрить это без остановки работы бухгалтерии

Часто слышу возражение: «мы не можем перекраивать доступ, конец квартала, отчётность». Понимаю. В лоб такие вещи не делают. Мы разносим внедрение на три этапа. Первый — персональные логины и базовая ролевая модель: один вечер, без остановки работы, старые права просто копируются на новые учётки. Второй — RLS на самые чувствительные данные: зарплату и банковские счета, с обязательным тестированием на копии базы вне рабочего времени.

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

Отдельно про КриптоПро — раз уж речь про безопасность в 1С. Если у вас есть электронная подпись для отчётности или ЭДО, доступ к контейнеру подписи должен быть персональным. А не лежать общим файлом на сетевой папке, куда у всех доступ на чтение. Видел и такое. Не раз.

Что в итоге стоит эта безопасность и сколько стоит её отсутствие

Настройка ролей, RLS по зарплате и журнала регистрации под ключ для компании на 20-40 рабочих мест у нас обычно укладывается в 35-70 тысяч рублей разово. Плюс небольшое ежемесячное сопровождение, если нужно, чтобы кто-то раз в квартал проверял актуальность прав. Сравните с недостачей в 1,2 миллиона из истории выше. Или с неделей простоя после шифровальщика — когда бэкапа нет.

Честно: большинство директоров малого бизнеса считают эту тему второстепенной, пока не столкнутся лично. Понимаю — своих забот хватает, не обязаны разбираться в RLS и журналах регистрации. Но делегировать это стоит не тому, кто просто настраивает 1С для проводок, а тому, кто думает о безопасности данных как отдельной задаче. Это разные компетенции. Многие 1С-программисты уверены, что умеют и то, и другое — но это не одно и то же.

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

Можно ли настроить роли и RLS самостоятельно, без привлечения программиста?
Базовые роли из типовых заготовок назначить может и штатный пользователь с правами администратора, это делается через список пользователей за несколько минут. А вот RLS — это уже работа в конфигураторе с написанием условий на языке запросов, здесь без опыта легко посадить производительность базы или, хуже, оставить дыру, которая выглядит как защита, но не защищает. Это лучше доверить тому, кто делал такое раньше.

Журнал регистрации сильно замедляет работу базы?
Сам по себе — нет, если настроен правильно и хранится не внутри самой базы, а в отдельных файлах на диске. Проблема начинается, когда журнал никогда не чистят и не архивируют — тогда он разрастается до десятков гигабайт и тормозит открытие самого журнала, а не базу в целом. Регулярная выгрузка раз в квартал снимает эту проблему полностью.

У нас всего 8 человек в компании, нужна ли вообще такая настройка?
Персональные логины нужны при любом размере компании, это вопрос получаса работы. А вот RLS имеет смысл, если среди этих 8 человек есть иерархия доступа к деньгам — например, директор и два бухгалтера, где один не должен видеть зарплату другого. Если у вас реально все имеют право видеть всё, можно ограничиться ролями и журналом без сложной настройки на уровне записей.

Как понять, что доступ в нашей 1С уже настроен небезопасно?
Три быстрых признака: несколько человек заходят под одним логином, RDP к серверу открыт напрямую в интернет без VPN, и никто не может сказать, когда в последний раз проверялись назначенные роли пользователей. Если хотя бы два пункта из трёх про вас — стоит заказать аудит, обычно он занимает один день и сразу показывает картину.