В 2026 году государство признало ERP-системы объектом критической информационной инфраструктуры. Это означает новый уровень ответственности, другие сроки и дополнительные вопросы от регулятора.

Еще недавно вопрос безопасности ERP лишь изредка всплывал на совещаниях по ИБ, но всегда, что называется, были задачи поважнее. ERP была больше внутренним инструментом и не воспринималась как инфраструктура, которая может однажды оказаться под прицелом регулятора.

В 2026 г. распоряжение Правительства РФ № 360-р закрепило перечень типовых отраслевых объектов критической информационной инфраструктуры, и в этот перечень для ряда секторов впервые явно вошли корпоративные системы управления предприятием. Если ваша ERP обслуживает финансы, закупки, производство или логистику в организации из затронутых отраслей, то она больше не является исключительно вашим внутренним делом. В глазах государства она теперь является инфраструктурой, от которой зависят критические процессы предприятия, – сбой в ней может грозить большими рисками.

Почти одновременно с этим изменился и подход к категорированию. После выхода ПП № 1762 компании обязаны соотносить свою инфраструктуру не только с внутренней оценкой критичности, но и с отраслевыми перечнями. Раньше компания сама решала, насколько система важна, но теперь есть внешний ориентир, отклонение от которого нужно обосновывать. А с 1 марта 2026 г. приказ ФСТЭК России № 117 перевел защиту объектов КИИ в режим непрерывного мониторинга: регулятор теперь хочет видеть живой процесс контроля и готовность продемонстрировать его в любой момент.

Когда компания впервые сталкивается с новой нормативной реальностью, то задается вполне человеческими вопросами: нас это вообще касается? Кто у нас за это отвечает? Что именно показать проверяющему, если он придет завтра? Честные ответы нередко только больше путают, потому что требования закона и реальная эксплуатация ERP различаются. А задачу перевода одного в другое никто перед ИТ-командой специально не ставил.

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

Среди всех объектов КИИ ERP занимает особое место по сложности защиты, потому что системы управления предприятием строились в логике эффективности, а не безопасности. Большинство ERP-платформ появились задолго до того, как безопасность кода стала обязательным атрибутом разработки. В итоге в кодовых базах накапливались небезопасные паттерны: динамические SQL-запросы, прямой доступ к базам данных без авторизации, отсутствие проверки полномочий при вызове критичных функций. Уязвимости намеренно не создавались, но их никто и не искал. Аргумент "ну до сих пор же ничего не случилось" звучал достаточно убедительно.

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

Если говорить о российском корпоративном рынке, то примерно 60% крупных учетных и управленческих систем работают на двух платформах – SAP и 1С. Обе попали в фокус новых требований, но проблемы у них разные.

SAP традиционно использовался крупными промышленными, энергетическими и транспортными предприятиями – именно теми, кто сегодня оказался в ядре регулирования КИИ. Главной сложностью здесь является унаследованная запутанность. Кодовая база накапливалась годами: сотни Z-разработок, тысячи транспортных запросов, роли, которые кочуют из проекта в проект вместе с людьми, и RFC-соединения, о назначении которых уже никто точно не помнит. При этом поддержка вендора для многих стала недоступной, что дополнительно усложняет контроль над актуальностью патчей.

У 1С история другая, но исход похожий. Платформа с годами стала рабочим пространством, которое меняется под каждую бизнес-задачу: здесь доработали, там расширили, добавили внешнюю обработку, подключили интеграцию. Эта гибкость – главное конкурентное преимущество 1С и одновременно растущая поверхность атаки. Каждое изменение потенциально вносит новые уязвимости, а отследить их в живой развивающейся системе без специализированного инструмента практически невозможно. Отдельного внимания заслуживают компании, которые прямо сейчас находятся в процессе миграции с SAP на 1С в рамках импортозамещения: в переходный период риски обеих платформ существуют одновременно.

Логичным следующим шагом для любой ИБ-службы становится поиск готового инструмента. И здесь обнаруживается еще одна ловушка: классические системы статического анализа кода (SAST) умеют работать с Java, .NET, Python, но не с ABAP и не со встроенным языком 1С. Специфика этих платформ попросту выходит за пределы их компетенции. Альтернативы с открытым исходным кодом формально могут частично закрыть задачу, но создают другую проблему: после 2024 г. для объектов КИИ рекомендовано использовать российское ПО из реестра Минцифры, и выбор сужается.

Но даже если найти подходящий инструмент для анализа кода, он закроет лишь одну из пяти критичных зон ERP. Параллельно нужен контроль ролей и полномочий, выявление конфликтов разделения обязанностей – ситуаций, когда один человек может и согласовать, и провести финансовую операцию, – мониторинг настроек безопасности платформы, проверка полноты журналирования и отслеживание всех активных интеграций. Теоретически можно собрать пять разных инструментов под каждую задачу. Но на практике это быстро превращается в зоопарк: разные интерфейсы, разные методологии, пробелы на стыке ответственности между вендорами и отсутствие единой картины. Когда приходит проверка ФСТЭК России, нужен целостный ответ на вопрос: в каком состоянии защищенность вашей ERP прямо сейчас?

Ответ на него предполагает не просто поддержку ERP в списке технологий, а глубокое понимание внутренней логики платформ – ролевых моделей, механизмов интеграций, связи технических настроек с бизнес-процессами. Чтобы построить такую экспертизу, нужны годы работы именно с этими системами, а не с ERP вообще. Именно этим путем с 2012 г. шла команда SafeERP. Платформа изначально создавалась как специализированное решение для защиты корпоративных систем – SAP и 1С.

Для SAP модуль Security Suite [1] в едином интерфейсе позволяет проверять ABAP-код, включая каждый транспортный запрос перед переносом в продуктивную зону, анализировать ролевую модель, выявлять конфликты разделения обязанностей, контролировать RFC-соединения и параметры безопасности платформы. Это непрерывный процесс контроля – именно то, чего требует приказ № 117.

Рис. 1. Соответствие SafeERP рекомендациям ФСТЭК России и требованиям КИИ для SAP

Для 1С Extension Module [2] анализирует код из нескольких источников: репозитория Git, базы 1С, продуктивной базы 1С и файловой системы. Принципиальная особенность – автоматическое отделение кода вендора от собственных доработок: компания видит риски именно в своем коде и не тонет в стандартных уязвимостях платформы. Дополнительно имеется контроль ролей и профилей безопасности, параметры журналирования и контроль профилей безопасности. Для компаний, которые сейчас мигрируют с SAP на 1С, это особенно важно: SafeERP позволяет одновременно контролировать обе платформы без смены инструмента.

Рис. 2. Соответствие SafeERP рекомендациям ФСТЭК России и требованиям КИИ для 1С (корпоративные системы)

 

Выводы и рекомендации

ERP уже нельзя защищать набором разрозненных ручных действий и ежегодным аудитом. Нужен системный подход, чтобы видеть состояние защищенности непрерывно и уметь доказать ее наличие. Практический первый шаг – честно ответить себе на несколько вопросов: попадает ли ваша ERP в периметр КИИ по отраслевым перечням? Кто отвечает за контроль ее безопасности? Все ли критичные действия журналируются? Когда последний раз проверялся пользовательский код? Актуальна ли карта ролей и полномочий? Есть ли понимание всех активных интеграций?

Если хотя бы на половину из них нет быстрого и уверенного ответа, то это и есть повод начать выстраивать системную защиту. SafeERP – инструмент, который помогает пройти этот путь для SAP и 1С. И он умеет говорить одновременно на языке регулятора и на языке реальной жизни вашей системы.

SafeERP – комплексное решение для защиты ERP систем на платформах SAP и 1С, которое сочетает анализ кода, контроль настроек и мониторинг безопасности. Включено в реестр российского ПО Минцифры. Разработчик – "Газинформсервис".

Журнал "Information Security/ Информационная безопасность" #2, 2026 / СПЕЦПРОЕКТ: БЕЗОПАСНОСТЬ И НАДЕЖНОСТЬ 1С

Запросите демо SafeERP и узнайте, что реально происходит внутри вашей системы.