Безопасность 1С в контуре ИБ: риски, наблюдаемость и векторы защиты
Автор: Петухов Олег Анатольевич, эксперт по информационной безопасности, руководитель юридической компании ЛЕГАС
Сайт: legascom.ru
E-mail: petukhov@legascom.ru
Переход компаний с иностранных ERP‑систем на 1С привёл к тому, что в продакшене закрепились крупные, глубоко доработанные решения - от них зависят ключевые бизнес‑процессы: финансовые, кадровые, производственные. При этом во многих организациях безопасность 1С остаётся на периферии внимания службы ИБ. В статье разбираем, какие риски сегодня недооценивают, как изменилась наблюдаемость систем и какие подходы к защите скоро перестанут работать.
Ключевые риски безопасности 1С
Сегодня основные угрозы для 1С связаны не столько с самой платформой, сколько с особенностями её эксплуатации и кастомизации:
Технический долг и небезопасный код. Значительная часть рисков формируется за счёт кастомного кода, который внедряют аутсорсеры или внутренние разработчики. При этом практики DevSecOps применяют лишь немногие организации.
Иллюзия периметровой защиты. Открытые порты, отсутствие сегментации и упрощённые представления о безопасности создают уязвимые места.
Уязвимости платформы и проблемы с обновлениями. В библиотеке стандартных подсистем встречаются критические дыры. Отказ от лицензии нередко блокирует получение обновлений, что дополнительно повышает риски.
Угрозы данным. Утечки и манипуляции с кадровыми и производственными данными - одна из главных опасностей. С 1 марта 2026 года приказ ФСТЭК России № 117 обязывает госорганы защищать, в том числе, бухгалтерские и кадровые системы.
Человеческий фактор. Недостаток знаний по кибербезопасности у сотрудников, ошибки в настройке прав, неправильное использование утилит для бэкапов и отказоустойчивых кластеров - частые причины инцидентов.
Рост целевых атак с применением ИИ. Умный фишинг, автоматизация разведки и создание вредоносного ПО - векторы, которые будут усиливаться в ближайшие годы.
Риски будут нарастать из‑за накопления кастомного кода, использования устаревших версий и увеличения штрафов за утечки данных.
Наблюдаемость 1С‑систем: прогресс и слепые зоны
За последние годы мониторинг 1С существенно эволюционировал: от хаотичного сбора логов к сквозному контролю всего технологического стека - от оборудования до бизнес‑логики. Сейчас можно в реальном времени отслеживать полный путь выполнения запроса в разрезе «пользователь - портал - сервер - БД - смежные системы», анализировать технологический журнал и действия пользователей без ручного вмешательства. Использование процентилей (например, 95‑го и 75‑го) помогает выявлять аномалии, а не ориентироваться на усреднённые показатели.
Тем не менее остаются значимые слепые зоны:
Активность толстого клиента вне сервера. Данные из локального кэша на рабочей станции пользователя практически не поддаются контролю.
Маскирование под системными учётными записями. Если интеграции или фоновые задания работают под единой записью с избыточными правами, SIEM‑системам сложно определить инициатора действий.
Сложные логические атаки. Подмена реквизитов в самописном модуле может выглядеть как легитимное обновление. Стандартные правила корреляции не всегда отличают ошибку разработчика от закладки злоумышленника.
Ограниченность статического анализа. SAST‑инструменты не видят уязвимостей на стыке интеграций или при некорректных настройках прав доступа в ОС и СУБД.
Архитектурные подходы: возможна ли унификация?
Единой типовой архитектуры безопасной 1С ожидать не стоит: среда глубоко кастомизируема, а требования бизнеса и регуляторов сильно различаются. Малый бизнес чаще делегирует безопасность облачным провайдерам, крупные корпорации строят собственные эшелонированные системы защиты.
Вместо универсального стандарта будут развиваться типовые архитектурные шаблоны: сегментация, аутентификация, аудит. Для объектов критической инфраструктуры и гостайны актуальны решения с полной изоляцией и сертифицированными средствами защиты (например, 1С:Предприятие 8.3z).
Перспективные элементы безопасной архитектуры для 1С включают:
использование СУБД на базе PostgreSQL;
отказ от прав суперпользователя для роли 1С;
ограничение доступа к схеме public;
контроль прав даже для пользователей, выполняющих резервное копирование;
расширенный аудит событий безопасности;
прозрачное шифрование данных (TDE).
Подходы, которые скоро перестанут быть эффективными
Некоторые текущие практики защиты в ближайшие годы могут стать недостаточными:
Опора только на SIEM и SAST. Эти инструменты важны, но не справляются со сложными целевыми атаками и кодом, созданным с помощью ИИ.
Изоляция за периметром без защиты на уровне приложений. Такой подход не закрывает риски прямого доступа к данным.
Ставка только на встроенные средства платформы. Без внешнего мониторинга и интеграции с корпоративными системами ИБ остаются слепые зоны.
Статичное управление доступом. Для выявления аномалий нужен поведенческий анализ.
Ручные процессы. Обновления, аудит и реакция на угрозы должны быть автоматизированы.
Отдельно стоит выделить риски чрезмерного доверия к RLS (Row‑Level Security): он работает только внутри приложения и не защищает от прямого доступа к СУБД. Кроме того, при росте объёмов данных RLS может существенно снижать производительность.
Также ошибкой становится изоляция безопасности 1С от общекорпоративного контура. Без интеграции с IDM/IGA и централизованными SIEM невозможно оперативно выявлять комплексные атаки. В будущем 1С, не включённая в общий SOC организации, станет главным уязвимым местом.
Роль СУБД в защите 1С
СУБД перестаёт быть просто хранилищем данных и становится активным элементом контроля безопасности. Современные требования (в том числе защита персональных данных и объектов КИИ) диктуют необходимость использовать встроенные механизмы СУБД:
разделение привилегий на уровне таблиц;
прозрачное шифрование;
строковое разграничение доступа;
детальный аудит запросов.
Это позволяет перекрывать риски, которые не видны на уровне платформы 1С - например, прямой доступ к базе в обход прикладной логики. Регуляторное давление (например, приказ ФСТЭК № 64) усиливает необходимость глубокого аудита и контроля целостности на уровне СУБД.
Практики безопасной разработки для 1С
Практики безопасной разработки в среде 1С применимы, но требуют адаптации. Платформа не поддерживает современные инструменты анализа и автоматизированные конвейеры «из коробки», поэтому компании используют ручные проверки, кастомные линтеры, контроль версий и валидацию данных.
Для статического анализа кода применяют отечественные и Open‑Source‑решения: BSL Language Server и BSL Analyzer. Их можно интегрировать в среду разработки (например, VS Code) и передавать результаты в SonarQube, встраивая проверки в сборочные конвейеры (Jenkins) через Quality Gates.
Автоматизированный контроль позволяет находить уязвимости, характерные для 1С: небезопасный динамический код (использование операторов «Выполнить» или «Вычислить»), логические ошибки (жёстко заданные пароли, обход проверок прав), проблемы интеграции.
Внедрение практик безопасной разработки - это масштабная трансформация: компании должны выстроить сквозные процессы, описать их в регламентах, внедрить инструменты, обучить команды и подготовить документацию для сертификации. Поэтому сегодня такие сертификаты есть преимущественно у крупных и зрелых ИТ‑компаний.
Юридическая компания ЛЕГАС помогает структурировать и оформлять материалы по информационной безопасности и защите данных, включая подготовку документов для регуляторов, анализ рисков и описание процессов безопасной разработки под требования делопроизводства и юриспруденции.
