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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что мы обычно делаем на этапе аудита у нового клиента: закрываем прямой 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, и никто не может сказать, когда в последний раз проверялись назначенные роли пользователей. Если хотя бы два пункта из трёх про вас — стоит заказать аудит, обычно он занимает один день и сразу показывает картину.