ERP как объект КИИ: что отвечать регулятору и как выстроить защиту
Автор: Петухов Олег Анатольевич, эксперт по информационной безопасности, руководитель юридической компании ЛЕГАС
Сайт: legascom.ru
E-mail: petukhov@legascom.ru
С 2026 года ERP‑системы официально отнесены к объектам критической информационной инфраструктуры (КИИ). Это меняет подход к их защите: теперь от компаний требуют не разовых аудитов, а непрерывного контроля и готовности в любой момент подтвердить регулятору состояние защищённости. В статье разбираем, кого касаются новые требования, какие риски возникают на практике и что сделать прямо сейчас, чтобы снизить регуляторные и операционные риски.
Что изменилось в регулировании
Ключевые нормативные акты, которые задают новые правила игры:
Распоряжение Правительства РФ № 360‑р - закрепило включение ERP‑систем в перечень типовых отраслевых объектов КИИ для ряда секторов. Если ваша ERP управляет финансами, закупками, производством или логистикой в такой отрасли, она подпадает под регулирование.
Постановление № 1762 - обязывает компании соотносить внутреннюю оценку критичности с отраслевыми перечнями. Отклонение от перечня нужно обосновывать.
Приказ ФСТЭК России № 117 (с 1 марта 2026 г.) - переводит защиту КИИ в режим непрерывного мониторинга. Регулятор ожидает видеть не «бумажную» безопасность, а живой процесс контроля, который можно продемонстрировать по запросу.
Раньше компания сама определяла критичность ERP. Теперь есть внешний ориентир, и размытость в оценке превращается в риск: при проверке придётся объяснять, почему система не отнесена к КИИ или почему меры защиты не соответствуют уровню значимости объекта.
Почему ERP - особый объект для защиты
ERP проектировались под эффективность и гибкость, а не под требования ИБ. В результате в них накопились типовые уязвимости:
динамические SQL‑запросы;
прямой доступ к базам данных без должной авторизации;
вызовы критичных функций без проверки полномочий.
Эти проблемы - не результат злого умысла, а следствие многолетней эволюции системы под бизнес‑задачи. При этом в «живой» ERP сложно отследить, что именно менялось: конфигурации, пользовательский код, интеграции. Отсюда - типичные пробелы, которые становятся критичными при проверке:
неясно, все ли критичные действия журналируются;
нет полной карты внешних соединений и интеграций;
неизвестно, когда и кем проверялся пользовательский код;
роли и полномочия могут быть неактуальными, а конфликты разделения обязанностей - не выявлены.
Особенности защиты SAP и 1С
На российском рынке около 60 % крупных учётных и управленческих систем работают на SAP и 1С - обе платформы попали в фокус требований КИИ, но проблемы у них разные.
SAP. Чаще встречается на крупных промышленных, энергетических и транспортных предприятиях - именно в тех секторах, где регулирование КИИ наиболее строгое. Основные сложности:
унаследованная запутанность: множество Z‑разработок, RFC‑соединений, ролей, история которых теряется;
отсутствие вендорской поддержки у многих компаний, что усложняет контроль актуальности патчей.
1С. Главная особенность - высокая кастомизация под каждую задачу. Гибкость платформы одновременно является и преимуществом, и растущей поверхностью атаки: каждое изменение может добавлять новые уязвимости, а контролировать их без специализированных инструментов практически невозможно.
Особую зону риска создают проекты миграции с SAP на 1С: в переходный период уязвимости обеих платформ существуют одновременно, а периметр контроля расширяется.
Проблемы с инструментами анализа
Многие компании пытаются закрыть риски с помощью классических SAST‑решений (статический анализ кода), но они не работают с ABAP (SAP) и встроенным языком 1С. Получается, что инструмент, подходящий для Java, .NET или Python, не закрывает специфику ERP‑платформ.
Дополнительные ограничения:
после 2024 года для объектов КИИ рекомендовано использовать российское ПО из реестра Минцифры - выбор инструментов сужается;
попытка собрать «зоопарк» из нескольких решений (отдельно для анализа кода, контроля ролей, журналирования, интеграций и т. д.) приводит к фрагментарной картине: разные интерфейсы, методологии, пробелы на стыках.
В итоге при проверке ФСТЭК компании сложно дать целостный ответ: «В каком состоянии защищённость нашей ERP прямо сейчас?»
Пять критичных зон контроля для ERP в КИИ
Чтобы выстроить реальную, а не формальную защиту, нужно одновременно контролировать:
Код и доработки - пользовательские обработки, расширения, внешние интеграции.
Роли и полномочия - актуальность прав, выявление конфликтов разделения обязанностей (например, когда один сотрудник может и согласовать, и провести платёж).
Настройки безопасности платформы - параметры аутентификации, лимиты, политики паролей.
Журналирование - полнота фиксации критичных действий, хранение и защита логов.
Интеграции - все активные соединения с внешними системами, их назначение и уровень доверия.
Закрывать эти зоны нужно не разрозненно, а как единую систему: технические настройки должны быть увязаны с бизнес‑процессами и требованиями регуляторов.
С чего начать: практические шаги
Первый этап - не покупка инструмента, а честный аудит текущего состояния. Ответьте на ключевые вопросы:
Попадает ли ваша ERP в периметр КИИ по отраслевым перечням?
Кто официально отвечает за контроль её безопасности?
Все ли критичные действия полноценно журналируются?
Когда последний раз проверяли пользовательский код на уязвимости?
Актуальна ли карта ролей и полномочий, выявлены ли конфликты разделения обязанностей?
Есть ли полная и актуальная карта активных интеграций?
Если хотя бы на половину вопросов нельзя ответить быстро и уверенно - это сигнал к тому, что нужно выстраивать системный процесс защиты.
Важные организационные моменты
Экспертиза. Нужны специалисты, которые понимают не только ИБ, но и внутреннюю логику конкретной ERP‑платформы (ролевые модели, механизмы интеграций, связь настроек с бизнес‑логикой). Такие кадры редки, а их подготовка требует времени.
Непрерывность контроля. Защита не должна сводиться к ежегодному аудиту. Приказ ФСТЭК № 117 требует именно непрерывного мониторинга - значит, нужны процессы и инструменты, которые фиксируют изменения и отклонения в реальном времени.
Доказательная база. Регулятору важно не просто наличие мер, а возможность подтвердить их реализацию: журналы, отчёты, результаты проверок, протоколы устранения уязвимостей.
Юридическая компания ЛЕГАС оказывает сопровождение по вопросам отнесения ERP‑систем к объектам КИИ, категорирования, выстраивания процессов непрерывного контроля, подготовки документации для проверок ФСТЭК, а также структурирования требований к защите SAP и 1С с учётом специфики бизнес‑процессов и требований делопроизводства.
