1С перемещается в контур ИБ. Круглый стол экспертов
Переход с иностранных ERP на 1С принес в продакшен крупные, глубоко доработанные системы, от которых напрямую зависят финансовые, кадровые и производственные процессы. При этом во многих организациях 1С по-прежнему остается на периферии внимания ИБ. Мы предложили экспертам обсудить, как меняется роль 1С в инфраструктуре, какие риски накапливаются и что в ближайшие годы придется пересматривать в подходах к ее безопасности и надежности.
Эксперты:
- Петр Иванов, проректор по цифровому и технологическому развитию СВФУ
- Виталий Рыбалка, директор по развитию компании “ИТ-Экспертиза”
- Екатерина Соколова, менеджер продукта Postgres ProEnterprise для 1С
- Тимур Цыбденов, ведущий инженер и эксперт SafeERP компании “Газинформсервис”

Какие риски в инфраструктуре 1С сейчас недооцениваются и в ближайшие годы будут усиливаться? За счет чего это произойдет?
Петр Иванов, СВФУ
Основные риски 1С следующие:
- технический долг и небезопасный код аутсорсеров;
- иллюзия защиты периметром (открытые порты, нет сегментации);
- критические уязвимости платформы (в библиотеке стандартных подсистем много дыр, из-за отказа от лицензии 1С блокирует обновления);
- угрозы кадровым и производственным данным. С 1 марта 2026 г. приказ ФСТЭК России № 117 обязывает госорганы защищать, помимо прочего, бухгалтерские и кадровые системы.
Риски усилятся из-за накопления кастомного кода, старых версий и увеличения штрафов за утечки. Вывод: 1С – ядро бизнеса, но защита осталась вчерашней. Нужны сегментация, контроль кода и обновления.
Виталий Рыбалка, "ИТ-Экспертиза"
Ключевыми рисками в работе решений на платформе 1С является низкий контроль за безопасностью и качеством кастомизируемого кода, внедряемого в процессе работы. На сегодня только небольшое количество организаций применяют технологии DevSecOps при доработке и кастомизации решений на платформе. На сегодня основной вектор атак на системы на платформе 1С кроется в эксплуатации плохо спроектированных решений по управлению полномочиями и настройках механизмов безопасности платформы.
Екатерина Соколова, Postgres Pro
Беспокойство вызывают риски утечек и манипулирования данными 1С в обход приложения на уровне СУБД, а также сложности с восстановлением данных в случае сбоя. Можно до бесконечности наращивать безопасность самой ERP-системы, но если СУБД – слабое звено безопасности, то злоумышленник всегда найдет брешь и использует в своих целях.
Никуда не исчезают и риски, вызванные человеческим фактором: часто нехватка знаний основ кибербезопасности у работников приводит к большим проблемам, пользователи не осознают последствия своих действия. Недооценивается важность использования правильных утилит для бэкапов, отказоустойчивых кластеров.
Тимур Цыбденов, "Газинформсервис"
Риск – увеличение числа целевых атак на системы 1С с применением искусственного интеллекта. На текущий момент количество таких инцидентов невелико, однако угрозы будут нарастать с каждым годом. Во-первых, умный фишинг и социальная инженерия: ИИ позволяет создавать крайне правдоподобные и персонализированные фишинговые атаки. Во-вторых, автоматизация разведки и поиска уязвимостей. В-третьих, ИИ активно используется для создания и модификации вредоносных программ. Эти векторы станут ключевыми в ближайшие годы.
Как за последние годы изменилась наблюдаемость 1С-систем? Что мы научились видеть, чего раньше не видели, какие слепые зоны остаются?
Петр Иванов, СВФУ
За последние годы наблюдаемость 1С-систем совершила рывок от хаотичного сбора логов к рентгеновскому сквозному контролю всего стека технологий – от оборудования до бизнес-логики. Мы научились видеть полный путь выполнения запроса в разрезе "пользователь – портал – сервер – БД – смежные системы". Анализ технологического журнала и аудит действий пользователей теперь доступны в режиме реального времени, без ручного вмешательства и долгой настройки. Внедрение процентилей (95-й, 75-й) позволяет выявлять аномалии медленных запросов, а не просто смотреть на среднюю температуру по больнице.
Но что-то все равно остается скрытым. Слепые зоны – это безопасность прикладного кода, который до сих пор часто остается черным ящиком для мониторинга. Сохраняются также разрозненные данные интеграций, практически не поддающиеся единому контролю.
Виталий Рыбалка, "ИТ-Экспертиза"
За последние годы наблюдаемость систем 1С совершила качественный скачок, превратившись из закрытой экосистемы в прозрачный элемент корпоративной безопасности. Сама платформа доработала системы логирования и поддержку OTEL, появились партнерские решения. Если раньше 1С часто воспринималась как черный ящик с проприетарными логами, непонятными для внешних ИБ-специалистов, то сегодня ситуация кардинально изменилась. В частности, наше решение "Умный мониторинг" позволяет собирать и анализировать все логи (ТЖ и ЖР 1С).
Слепые зоны:
- Активность толстого клиента вне сервера. Мониторинг практически бессилен против компрометации данных, извлеченных из локального кэша на рабочей станции пользователя.
- Маскирование под системными учетными записями. Если интеграции или фоновые задания работают под единой системной записью с избыточными правами, SIEM-системе крайне трудно вычленить действия конкретного человека или процесса-инициатора.
- Сложные логические атаки. Подмена реквизитов в коде самописного модуля может выглядеть как легитимное обновление метаданных. Стандартные правила корреляции часто не могут отличить кривой код разработчика от целенаправленной закладки злоумышленника.
- Ограниченность статического анализа. SAST не видит уязвимостей, возникающих на стыке интеграций или при некорректных настройках прав доступа в самой ОС или СУБД.
Екатерина Соколова, Postgres Pro
Рынок начал видеть узкие места в безопасности ERP-систем не только в них самих, но и на уровне баз данных. Появившиеся встроенные в СУБД инструменты аудита позволяют выявлять несанкционированное предоставление доступа, нелегитимное подключение и прочие нарушения.
За последние годы на рынке появилось много графических систем мониторинга и управления СУБД. Это, с одной стороны, позволяет минимизировать влияние человеческого фактора, а с другой – контролировать работу системы с точки зрения ИБ. Но этих возможностей пока недостаточно, они активно развиваются.
Можно ли ожидать появления типовых архитектур безопасной 1С или сохранится разнообразие решений?
Виталий Рыбалка, "ИТ-Экспертиза"
Ожидать появления универсальной для всех организаций архитектуры безопасной 1С не стоит, так как среда 1С по своей природе глубоко кастомизируема. Различия в масштабах бизнеса, моделях развертывания (On-Premise или IaaS/PaaS/SaaS) и требованиях регуляторов предопределяют сохранение разнообразия подходов. Малый бизнес продолжит делегировать безопасность облачным провайдерам, в то время как крупные корпорации вынуждены выстраивать собственные сложные эшелонированные системы защиты.
Петр Иванов, СВФУ
Ожидать стоит не единого стандарта, а кристаллизации типовых архитектурных шаблонов – сегментации, аутентификации, аудита. Для объектов критической инфраструктуры и гостайны будет тиражироваться подход с защищенным программным комплексом и полной изоляцией (например, 1С:Предприятие 8.3z), включающие в себя сертифицированные средства защиты информации. Полное единообразие маловероятно из-за разнообразия отраслей, масштабов и глубины доработок конфигураций. Сохранится баланс: общие принципы безопасности плюс гибкая реализация под конкретные процессы, риски и требования регуляторов.
Тимур Цыбденов, "Газинформсервис"
Создать типовые решения безопасности вряд ли получится – слишком трудно подвести единую платформу под разные бизнес-модели. С учетом того, что ERP-системы будут относиться к объектам КИИ, а также на фоне формирования общих стандартов кодирования и безопасности, унификация подходов для схожих задач становится вполне реальной и перспективной. В связи с этим основной акцент будет сделан на решения, предоставляющие комплексную кибербезопасность.
Екатерина Соколова, Postgres Pro
Типовые решения будут строиться вокруг СУБД на основе PostgreSQL и будут включать отказ от прав суперпользователя у роли 1С. Иметь неограниченные права небезопасно, это ведет к росту рисков мошенничества. Обязательными элементами безопасности СУБД для 1С также станут: ограничение доступа к схеме public, ограничение прав на просмотр каталога данных даже для пользователя, выполняющего резервное копирование, расширенный аудит событий безопасности, прозрачное защитное преобразование (TDE).
Какие решения в аспекте ИБ для систем на базе 1С, которые сегодня кажутся правильными, через несколько лет могут оказаться ошибочными?
Тимур Цыбденов, "Газинформсервис"
Опираться в защите 1С исключительно на SIEM и SAST. Традиционный SIEM бессилен против сложных целевых атак, которые маскируются под обычную активность, и не приспособлен к атакам с применением ИИ – для их выявления потребуется обрабатывать огромные массивы данных с помощью новых подходов. То же касается и SAST: анализаторы с трудом справляются с кодом, написанным ИИ, и не обнаруживают новые типы уязвимостей. SIEM и SAST останутся важными базовыми элементами безопасности, но полагаться только на них не стоит.
Петр Иванов, СВФУ
- Изоляция только за периметром без защиты на уровне приложений;
- ставка лишь на встроенные средства платформы без внешнего мониторинга;
- статичное управление доступом без анализа поведения пользователей;
- ручные обновления и аудит вместо автоматизации.
Эти подходы перестанут работать из-за роста облачных архитектур, усложнения интеграций и целевых атак, требующих адаптивной сквозной защиты. Без эволюции в сторону непрерывного контроля и автоматизации компания рискует пропустить инцидент.
Екатерина Соколова, Postgres Pro
Полагаю, что для оптимизации работы будут удаляться дублирующие решения. Также будет автоматизироваться защитная реакция на типовые угрозы. При этом старые угрозы никуда не исчезнут.
Виталий Рыбалка, "ИТ-Экспертиза"
- Исключительное доверие механизму RLS (Row-Level Security). Сегодня использование RLS на уровне платформы 1С считается золотым стандартом ограничения доступа к записям. Однако это решение имеет две скрытые проблемы, которые скоро станут критичными. Во-первых, уязвимость перед обходом платформы. RLS работает только внутри приложения. Если злоумышленник скомпрометирует учетную запись администратора СУБД или ОС, он получит прямой доступ к таблицам, полностью минуя все ограничения RLS. Во-вторых, проблема масштабируемости. При росте объемов данных (ERP, корпоративные системы) RLS создает колоссальную нагрузку на производительность СУБД. Возможно, в будущем компаниям придется идти на компромисс между сложными правилами RLS и быстродействием.
- Изоляция безопасности 1С от общекорпоративного контура. Многие компании до сих пор строят безопасность в пузыре – свои парольные политики, локальные учетные записи и обособленный аудит внутри 1С. Почему это станет ошибкой? Изоляция мешает видеть комплексные атаки. Без интеграции с едиными системами IDM/IGA и централизованными SIEM невозможно оперативно выявить атаку, которая началась с офисного ПК и постепенно движется к ядру бизнес-логики. В будущем 1С, не включенная в общий SOC организации, станет главным слепым пятном для ИБ-департамента.
- Восприятие СУБД как пассивного хранилища.
- Ставка на ручной аудит кода и честное слово разработчика.
Как будет меняться роль СУБД в контуре 1С: останется ли просто местом хранения данных или станет элементом контроля безопасности?
Екатерина Соколова, Postgres Pro
Контроль безопасности должен охватывать все элементы информационной системы, в том числе и СУБД. При этом нельзя защитить данные в базах только внешними инструментами. Особенно это касается систем, содержащих персональные данные и значимые объекты КИИ. Мы как вендор постоянно повышаем безопасность своей СУБД, которая уже включает встроенные утилиты для защиты данных – маскирование, ограничение прав пользователей, аудит действий в СУБД, позволяющий избегать мошеннических операций внутри системы, и многое другое.
Тимур Цыбденов, "Газинформсервис"
СУБД постепенно становится центральным узлом контроля безопасности в системах 1С. Ключевыми факторами этого процесса выступает, с одной стороны, развитие российских продуктов с усиленной защитой (Jatoba, Postgres Pro Enterprise, Tantor), а с другой – активное применение на уровне баз данных технологий: построчное разграничение доступа (RLS), прозрачное шифрование данных (TDE), а также системы аудита и мониторинга событий безопасности.
Виталий Рыбалка, "ИТ-Экспертиза"
Изменения неизбежны. Вот вероятные вектора развития.
- Необходимость нефальсифицируемого следа. Логи СУБД невозможно уничтожить или подделать, даже если злоумышленник полностью скомпрометировал сервер приложений 1С или учетную запись администратора платформы.
- Усиление прикладных механизмов. Комплексная защита информационных систем – например, не только RLS.
- Регуляторное давление. Требования ФСТЭК России (например, приказ № 64) диктуют необходимость глубокого аудита и контроля целостности именно на уровне СУБД.
Петр Иванов, СВФУ
Роль СУБД в контуре 1С кардинально меняется: она перестает быть просто пассивным хранилищем данных и становится активным элементом контроля безопасности. Современные требования (защита персональных данных, объектов критической инфраструктуры) вынуждают использовать встроенные механизмы СУБД:
- разделение привилегий на уровне таблиц,
- прозрачное шифрование,
- строковое разграничение доступа,
- детальный аудит запросов.
Это позволяет перекрыть риски, которые не видит платформа 1С – например, прямой доступ к базе в обход прикладной логики.
Насколько сегодня применимы практики безопасной разработки к среде 1С?
Петр Иванов, СВФУ
Практики безопасной разработки для 1С применимы частично. Платформа не поддерживает современные инструменты анализа и автоматизированные конвейеры напрямую. Компании адаптируются: ручное ревью кода, кастомные линтеры, контроль версий, валидация данных. Внедрение практики безопасной разработки и анализа конфигураций отстает из-за нехватки специализированных утилит. С увеличением объема кастомного кода эти методики станут обязательными, но потребуют перестройки процессов и разработки инструментов под особенности платформы.
Тимур Цыбденов, "Газинформсервис"
Практики безопасной разработки уже сейчас активно внедряются не только в крупном, но и в среднем и малом бизнесе – компании видят ценность подхода, несмотря на ограниченность ресурсов. Этому способствуют и ужесточающиеся требования регуляторов. Статический анализ кода стал стандартом в процессе разработки. Но наиболее частой причиной атак остаются не столько уязвимости в коде, сколько ошибки конфигурации платформы, поэтому все большую популярность набирают сканеры безопасности платформы 1С.
Виталий Рыбалка, "ИТ-Экспертиза"
Поскольку мировые SAST-/DAST-инструменты не поддерживают язык 1С из коробки, для реализации DevSecOps используются отечественные и решения Open Source. BSL Language Server и BSL Analyzer позволяют проводить глубокий статический анализ кода в реальном времени прямо в среде разработки (например, VS Code). Результаты анализа можно передавать в SonarQube и встраивать в сборочные конвейеры через Jenkins, создавая Quality Gates.
Автоматизированный контроль помогает находить специфические для платформы уязвимости (небезопасный динамический код: использование операторов; "Выполнить" или "Вычислить"), логические ошибки (жестко заданные в коде пароли, обход проверок прав доступа и смешение латиницы/кириллицы в именах переменных) и проблемы интеграции (некорректные вызовы методов и нарушение совместимости типов).
Екатерина Соколова, Postgres Pro
Актуальность безопасной разработки для среды 1С сегодня крайне высока, ведь решения 1С являются цифровой кровеносной системой многих российских компаний. Однако внедрение РБПО – сложный процесс, требующий глубокой трансформации. Компании необходимо выстроить сквозные процессы и описать их в регламентах и инструкциях, внедрить инструменты безопасности в инфраструктуре разработки, обучить команды. Ключевой документ – руководство по безопасной разработке ПО, в котором должны быть описаны цели разработчика в области РБПО, роли участников процессов, перечень применяемых регламентов. Компания должна самостоятельно пройти все этапы: анализ соответствия стандарту, разработка плана внедрения, закупка инструментов, обучение, внутренний аудит и сбор подтверждающих артефактов. И только после такой масштабной подготовки можно выходить на аудит органа по сертификации. Именно поэтому сертификаты пока получили крупные и зрелые ИТ-компании, и их немного.
Источник: Информационная безопасность.
Больше новостей читайте в сообществе SAPLAND в ВК и телеграм-канале SAPLAND: Новости экосистемы.
