Защита баз 1С: разграничение прав в конфигурации и в СУБД, журналирование действий, вынос в отдельный сегмент сети

Обеспечение безопасности информационных баз 1С — задача, выходящая за рамки установки пароля на вход. Данные в системе критичны для непрерывности бизнес-процессов, поэтому защита должна быть комплексной и учитывать архитектуру самой системы.

Рассмотрим четыре ключевых уровня, каждый из которых требует внимания, а в совокупности формирует защищенную среду.

1. Конфигурационный уровень — настройки прав в самом приложении, роли, ограничения на уровне записей, которые отфильтровывают данные для каждого пользователя

2. Уровень СУБД — сервер баз данных, где физически хранятся таблицы и где существуют свои механизмы аутентификации, шифрования и аудита, полностью независимые от логики 1С.

3. Сетевой уровень — инфраструктура доступа: кто, откуда и по каким протоколам может подключиться к серверам, кластеру и непосредственно к базам.

4. Уровень журналирования — система фиксации событий, которая при правильной настройке позволяет обнаружить атаку на ранней стадии.

Вопросы настройки прав непосредственно на стороне СУБД требуют отдельного рассмотрения. В статье расскажем, как разграничение прав в конфигурации сочетается с изоляцией СУБД на сетевом уровне и аудитом действий. А также покажем, как эти уровни взаимодействуют, где возникают уязвимости и как выстроить комплексную защиту.

Разграничение прав в конфигурации

Механизм разграничения доступа в «1С:Предприятие 8» строится на двух компонентах: ролях — разрешенные действия над объектами метаданных — и ограничении на уровне записей (механизм RLS), которое фильтрует данные внутри одного объекта через условия, подставляемые в SQL-запросы.

Однако в RLS есть тонкие места, которые важно учитывать.

• Привилегированный режим. Код, выполняющийся в этом режиме, игнорирует проверки RLS. Если разработчик оставляет флаг «Привилегированный» у отчета или обработки, пользователь через такой объект получает все данные без ограничений. Особенно опасно, когда привилегированный код изменяет движения регистров или предопределенные данные — это искажает учетную логику.

• Подмена параметров сеанса. Условия RLS часто опираются на параметры сеанса текущего пользователя или организации. При наличии прав на программное изменение этих параметров пользователь может подменить их и получить доступ к чужим данным.

• Ошибки в шаблонах ограничений. Условия RLS могут содержать логические ошибки. Например, ограничение прописано для таблицы документа, но не для виртуальной таблицы регистра, к которой обращается отчет. Формально RLS работает, но данные фильтруются не полностью.

• Утечка через связные объекты. Пользователь может иметь запрет на справочник «Контрагенты», но имеет доступ к документу, где эти контрагенты выбираются. Через реквизиты документа или связанные отчеты можно реконструировать данные из запрещенного справочника.

RLS требует строгого контроля привилегированного режима, параметров сеанса и регулярного аудита шаблонов. Но даже при идеальной настройке RLS не защищает от прямого обращения к СУБД, поэтому следующий уровень — журналирование действий.

Журналирование действий

В платформе «1С:Предприятие» существует два основных механизма сбора событий.

Журнал регистрации фиксирует действия пользователей: вход в систему, открытие, проведение и запись объектов. Он включен по умолчанию, но хранится в файлах на диске сервера и при наличии прав администратора может быть очищен или изменен.

Технологический журнал — более низкоуровневый механизм. Он дает информацию о работе платформы: исключения, вызовы COM-объектов, время выполнения и текст запросов к СУБД. Это позволяет выявлять подозрительные SQL-запросы, попытки SQL-инъекций и уязвимости платформы. По умолчанию технологический журнал выключен и требует отдельной настройки.

Оба механизма полезны, но у них есть общая проблема: злоумышленник может выполнить вредоносный код, не оставляя явных следов. Разберем это подробнее.

Классические схемы атак на 1С обычно подразумевают запуск внешней обработки через меню «Файл — Открыть». Да, это событие будет зафиксировано в журнале регистрации. Поэтому злоумышленники могут действовать иначе.

Первый способ: запуск до авторизации. Если в системе настроены веб-сервисы с атрибутом «Аутентификация не требуется» и снятым безопасным режимом, то злоумышленник может обратиться к такому сервису напрямую, минуя форму входа. В коде сервиса может быть вызов внешней обработки или выполнение произвольного кода. При этом в журнале регистрации не появится записи о входе пользователя — сервис выполнился анонимно.

Второй способ: исполнение кода через легитимные объекты. Представим, что злоумышленник имеет доступ к записи в любой справочник или константу, но не имеет прав на запуск внешних обработок. Он может записать вредоносный код в виде строки Base64 в обычный реквизит справочника «Номенклатура» или в константу «КраткоеНаименованиеОрганизации». А затем запустить легальный отчет, который использует эти данные в своих расчетах, но из-за уязвимости в коде исполняет их как команды. С точки зрения журнала регистрации, произошло два безопасных события: пользователь изменил справочник (обычная рабочая операция) и запустил отчет (обычный рабочий отчет). Вредоносный код остался невидимым.

Третий способ: через XDTO-десериализацию. На уязвимых веб-сервисах, которые принимают XML-запросы и без проверок создают объекты, можно подсунуть сформированный пакет, который при десериализации выполнит произвольный код. Эта техника аналогична уязвимостям в Java и .NET и крайне плохо отслеживается штатными средствами.

Четвертый способ: фоновые задания. Злоумышленник с административными правами может создать задание, которое вызывает внешнюю обработку или выполняет вредоносный код. Отследить такие задания можно через консоль администрирования серверов 1С или внешние системы мониторинга.

Чтобы журналирование стало реальным инструментом безопасности, необходимо:

• настроить централизованный сбор логов (в СУБД или внешнюю систему) с оповещениями по критическим событиям: входы в нерабочее время, неудачные попытки аутентификации, изменение прав пользователей;

• включить и настроить технологический журнал для мониторинга подозрительных запросов и исключений;

• использовать механизмы аудита на уровне СУБД, которые нельзя отключить без прав администратора ОС;

• регулярно просматривать список фоновых заданий и проверять нестандартные или новые задания.

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

Сетевая сегментация

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

Почему это важно? Кластер 1С и СУБД имеют собственные протоколы управления, которые не всегда требуют жесткой аутентификации. Достаточность сетевого доступа к порту 1540 (RAS — Remote Administration Server) кластера 1С при отсутствии пароля администратора позволяет злоумышленнику создать новую информационную базу, загрузить в нее вредоносную конфигурацию и выполнить код на сервере. Для этого не нужны учетные данные пользователей, нужен только сетевой доступ.

Веб-клиент — еще одна точка входа. По умолчанию он показывает список пользователей в выпадающем списке, что дает злоумышленнику словарь логинов для атаки подбором паролей. В старых версиях платформы (до 8.3.16) не было ограничений на количество попыток входа, что делало такую атаку тривиальной. Если пароль подобран к учетной записи с правами на загрузку внешних обработок, снова становится возможным выполнение кода на сервере.

Как организовать защиту на сетевом уровне:

• Разместить сервер СУБД в отдельном сегменте VLAN. Разрещить доступ к нему только для сервера 1С и для ограниченного круга администраторов. Рабочие станции не должны иметь прямого доступа к портам СУБД.

• Изолировать сервер 1С. Порты 1540, 1541, 1560 должны быть доступны только для серверов приложений и администраторских машин. При использовании веб-клиента веб-сервер рекомендуется разместить в зоне DMZ с ограниченным доступом к кластеру.

• Запретить выход в интернет для сервера баз данных — критичное правило. Это защищает от атак шифровальщиков и исключает возможность отправки похищенных данных наружу.

• Разрешать только строго определенные соединения. Например, от IP-адресов серверов 1С к IP-адресу СУБД по порту 1433, все остальное блокировать.

Сетевая изоляция не решает проблему инсайдеров и не закрывает уязвимости в коде, но она сокращает поверхность атаки. Злоумышленник не может использовать уязвимости в кластере или СУБД, если он физически не имеет к ним доступа.

Заключение

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

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

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

Безопасность 1С — это непрерывный процесс, требующий регулярного аудита, мониторинга и пересмотра политик по мере изменения бизнес-процессов и ландшафта угроз.

Автор: Екатерина Мясоедова, младший инженер по безопасности приложений, УЦСБ