Журнал "Information Security/ Информационная безопасность" #2, 2026

извлеченных из локального кэша на рабочей станции пользователя. 2. Маскирование под системными учет- ными записями. Если интеграции или фоновые задания работают под единой системной записью с избыточными пра- вами, SIEM-системе крайне трудно вычленить действия конкретного чело- века или процесса-инициатора. 3. Сложные логические атаки. Подмена реквизитов в коде самописного модуля может выглядеть как легитимное обнов- ление метаданных. Стандартные правила корреляции часто не могут отличить кри- вой код разработчика от целенаправ- ленной закладки злоумышленника. 4. Ограниченность статического ана- лиза. SAST не видит уязвимостей, воз- никающих на стыке интеграций или при некорректных настройках прав доступа в самой ОС или СУБД. Екатерина Соколова, Postgres Pro Рынок начал видеть узкие места в без- опасности ERP-систем не только в них самих, но и на уровне баз данных. Появившиеся встроенные в СУБД инструменты аудита позволяют выявлять несанкционированное предоставление доступа, нелегитимное подключение и прочие нарушения. За последние годы на рынке появи- лось много графических систем мони- торинга и управления СУБД. Это, с одной стороны, позволяет минимизи- ровать влияние человеческого фактора, а с другой – контролировать работу системы с точки зрения ИБ. Но этих возможностей пока недостаточно, они активно развиваются. Виталий Рыбалка, "ИТ-Экспертиза" Ожидать появления универсальной для всех организаций архитектуры без- опасной 1С не стоит, так как среда 1С по своей природе глубоко кастомизи- руема. Различия в масштабах бизнеса, моделях развертывания (On-Premise или IaaS/PaaS/SaaS) и требованиях регуля- торов предопределяют сохранение раз- нообразия подходов. Малый бизнес про- должит делегировать безопасность облачным провайдерам, в то время как крупные корпорации вынуждены выстраивать собственные сложные эше- лонированные системы защиты. Петр Иванов, СВФУ Ожидать стоит не единого стандарта, а кристаллизации типовых архитектурных шаблонов – сегментации, аутентификации, аудита. Для объектов критической инфра- структуры и гостайны будет тиражиро- ваться подход с защищенным программ- ным комплексом и полной изоляцией (например, 1С:Предприятие 8.3z), вклю- чающие в себя сертифицированные сред- ства защиты информации. Полное едино- образие маловероятно из-за разнообразия отраслей, масштабов и глубины доработок конфигураций. Сохранится баланс: общие принципы безопасности плюс гибкая реа- лизация под конкретные процессы, риски и требования регуляторов. Тимур Цыбденов, "Газинформсервис" Создать типовые решения безопасно- сти вряд ли получится – слишком трудно подвести единую платформу под разные бизнес-модели. С учетом того, что ERP- системы будут относиться к объектам КИИ, а также на фоне формирования общих стандартов кодирования и без- опасности, унификация подходов для схожих задач становится вполне реаль- ной и перспективной. В связи с этим основной акцент будет сделан на реше- ния, предоставляющие комплексную кибербезопасность. Екатерина Соколова, Postgres Pro Типовые решения будут строиться вокруг СУБД на основе PostgreSQL и будут включать отказ от прав супер- пользователя у роли 1С. Иметь неогра- ниченные права небезопасно, это ведет к росту рисков мошенничества. Обяза- тельными элементами безопасности СУБД для 1С также станут: ограничение доступа к схеме public, ограничение прав на просмотр каталога данных даже для пользователя, выполняющего резервное копирование, расширенный аудит событий безопасности, прозрачное защитное преобразование (TDE). Тимур Цыбденов, "Газинформсервис" Опираться в защите 1С исключительно на SIEM и SAST. Традиционный SIEM бессилен против сложных целевых атак, которые маскируются под обычную активность, и не приспособлен к атакам с применением ИИ – для их выявления потребуется обрабатывать огромные массивы данных с помощью новых под- ходов. То же касается и SAST: анализа- торы с трудом справляются с кодом, написанным ИИ, и не обнаруживают новые типы уязвимостей. SIEM и SAST останутся важными базовыми элемен- тами безопасности, но полагаться только на них не стоит. Петр Иванов, СВФУ l Изоляция только за периметром без защиты на уровне приложений; l ставка лишь на встроенные средства платформы без внешнего мониторинга; l статичное управление доступом без анализа поведения пользователей; l ручные обновления и аудит вместо автоматизации. Эти подходы перестанут работать из- за роста облачных архитектур, услож- нения интеграций и целевых атак, тре- бующих адаптивной сквозной защиты. Без эволюции в сторону непрерывного контроля и автоматизации компания рискует пропустить инцидент. Екатерина Соколова, Postgres Pro Полагаю, что для оптимизации работы будут удаляться дублирующие решения. Также будет автоматизироваться защит- ная реакция на типовые угрозы. При этом старые угрозы никуда не исчезнут. Виталий Рыбалка, "ИТ-Экспертиза" 1. Исключительное доверие механизму RLS (Row-Level Security). Сегодня исполь- зование RLS на уровне платформы 1С считается золотым стандартом ограниче- ния доступа к записям. Однако это реше- ние имеет две скрытые проблемы, кото- рые скоро станут критичными. Во-первых, уязвимость перед обходом платформы. RLS работает только внутри приложения. Можно ли ожидать появле- ния типовых архитектур безопасной 1С или сохра- нится разнообразие реше- ний? Какие решения в аспекте ИБ для систем на базе 1С, которые сегодня кажутся правильными, через несколько лет могут ока- заться ошибочными? • 27 БЕЗОПАСНОСТЬ И НАДЕЖНОСТЬ 1С www.itsec.ru Рисунок: Гротек