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

Прежде чем говорить о защите, необходимо понять, с какими компонентами системы взаимодействуют пользователи и где могут возникать уязвимости. Архитектура 1С неоднородна: в зависимости от того, как организован доступ, меняется и набор рисков.

Существует четыре основных варианта клиентского доступа, и каждый из них несет свой набор угроз.

Веб-клиент

Помимо базовых проблем безопасности, он уязвим к классическим угрозам веб-приложений: перехвату сессионных cookie, подделке запросов. Для защиты недостаточно просто развернуть веб-сервер — необходимо настраивать HTTPS и заголовки безопасности.

Тонкий клиент

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

Мобильный клиент

Особенность в том, что данные и токены авторизации могут сохраняться локально на устройстве для автономного режима. При потере устройства появляются риски компрометации этих данных. Для защиты используются политики управления мобильными устройствами (MDM), шифрование локальной базы и функция удаленной очистки устройства.

Толстый клиент

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

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

1. Вывод списка пользователей на форме ввода. Это значительно облегчает злоумышленникам проведение брутфорс-атак, так как логины заранее известны. Рекомендуется отключать отображение списка пользователей в настройках.
2. Слабая парольная политика. Часто идет в совокупности с предыдущей проблемой. Встречаются не только слабые, но и вовсе пустые пароли, в том числе для привилегированных учетных записей. Рекомендуется задавать жесткие требования к сложности паролей для локальных аккаунтов либо полностью переходить на доменную аутентификацию.
3. Использование устаревших версий платформы и СУБД. В старых релизах содержится значительное количество известных критических уязвимостей, для которых уже существуют готовые эксплойты. Необходимо внедрять практику регулярного обновления платформы и системного софта, а также непрерывно мониторить выход патчей безопасности.
4. Использование небезопасного стороннего кода. Чтобы избежать внедрения вредоносных модулей или появления скрытых уязвимостей, необходимо регулярно проводить код-ревью всех внешних доработок и подключать сканеры статического анализа для поиска уязвимостей в конфигурации.
5. Отсутствие контроля и логирования критичных действий. Без логов невозможно оперативно обнаружить виновника инцидента, реконструировать хронологию событий и оценить масштаб ущерба. Подробнее о том, какие события отслеживать, в разделе «Логирование и детектирование».

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

Безопасность должна строиться на принципе минимальных привилегий, однако на практике администраторы часто выдают избыточные права «с запасом», чтобы избежать конфликтов и жалоб пользователей. В результате такие права остаются в системе и не устраняются.

Кроме классических ролей, в 1С существует механизм разграничения прав доступа на уровне записей (RLS). В отличие от ролей, которые закрывают целые таблицы, RLS фильтрует конкретные строки данных на уровне СУБД. Условия ограничений пишутся разработчиком в конфигураторе, и в них может быть реализована сложная логика, которую необходимо анализировать, так как могут вскрываться конфигурации, которые трудно детектировать. Неправильная выдача прав и ошибки в настройке этих механизмов приводят к критическим проблемам:

• Сложная логика RLS может содержать скрытые логические ошибки, из-за которых пользователи получают доступ к информации, к которой не должны иметь доступа.
• Неправильно настроенные связанные объекты или битые ссылки позволяют обходить ограничения или вытягивать конфиденциальные метаданные.
• Уязвимостью могут стать избыточные права на изменение параметров сеанса со стороны клиента.
• Одна из самых серьезных угроз — обход ограничений через привилегированный режим. Если в коде конфигурации есть уязвимость, например небезопасный вызов экспортной процедуры, злоумышленник может инициировать выполнение кода в привилегированном режиме. В этом случае платформа 1С полностью отключает все проверки RLS, открывая прямой доступ к любым защищенным данным в обход всех запретов.