Российский бизнес все чаще сталкивается не только с атаками как таковыми, но и с их «второй фазой» - шантажом и попытками монетизации инцидентов. При этом однозначно оценить масштаб проблемы сложно: компании крайне редко выносят такие случаи в публичное поле. По оценке Аналитического центра компании UDV Group, рост интереса злоумышленников к вымогательству нельзя напрямую связывать только с ужесточением регулирования и штрафами за утечки.

«Компании публично крайне редко признают факты вымогательства, поэтому достоверно оценить динамику сложно. При этом нельзя однозначно утверждать, что именно штрафы за утечки стали ключевым драйвером для злоумышленников. Скорее это один из дополнительных рычагов давления наряду с угрозами раскрытия факта взлома, остановки инфраструктуры, публикации внутренней переписки и других последствий», — отмечают эксперты UDV Group.

На практике сценарии давления становятся все более комплексными: злоумышленники комбинируют угрозы раскрытия данных, остановки процессов и репутационного ущерба. Это создает для бизнеса ситуацию, в которой решение о реакции на инцидент приходится принимать в условиях высокой неопределенности.

При этом поведение компаний, столкнувшихся с шантажом, остается в значительной степени скрытым от рынка. Те, кто идет на выплату, почти никогда не подтверждают это публично. Однако накопленный практический опыт позволяет сделать важный вывод: выплата выкупа редко закрывает проблему.

«Здесь важно понимать, что те, кто соглашается на такие условия, почти никогда не говорят об этом публично, поэтому полную картину рынка увидеть сложно. При этом из непубличных кейсов, о которых известно от коллег, можно сделать неприятный вывод: выплата выкупа обычно не решает проблему, а, наоборот, показывает злоумышленникам, что на компанию можно давить и дальше. В результате они нередко возвращаются уже с новыми требованиями и большими суммами», — подчеркивают эксперты UDV Group.

Вместо этого компании все чаще рассматривают альтернативные стратегии реагирования, в центре которых - управляемость ситуации и снижение долгосрочных рисков. Один из ключевых подходов - переход к контролируемой публичности.

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

Однако публичность - лишь часть комплексного ответа. Не менее важно быстро локализовать инцидент и объективно оценить его масштаб. Практика показывает, что злоумышленники часто намеренно преувеличивают уровень своего доступа, создавая у бизнеса ощущение полной компрометации инфраструктуры.

В этих условиях критическую роль играет качественное расследование инцидента. Даже при наличии собственной команды ИБ целесообразно привлекать внешних специалистов с опытом реагирования: независимая экспертиза позволяет точнее определить границы атаки и выявить скрытые риски.

Отдельный блок задач связан с правовыми и коммуникационными обязательствами. При риске утечки персональных данных компания должна действовать строго в рамках регуляторных требований, включая уведомление Роскомнадзора. Параллельно важно своевременно информировать контрагентов, сотрудников и другие затронутые стороны, чтобы минимизировать возможные последствия и координировать дальнейшие действия.

UDV Group: после инцидента в приоритете управляемость и готовность к кризису

Далее ключевой задачей становится оперативное усиление защиты. Это может включать смену учетных данных, пересборку прав доступа, замену сертификатов, а также временное ограничение работы отдельных систем. В ряде случаев контролируемый простой становится более безопасной стратегией, чем попытка сохранить полную операционную активность в условиях компрометации.

В итоге ключевой вывод выходит за рамки конкретных сценариев реагирования: даже зрелые компании не застрахованы от подобных инцидентов. Человеческий фактор, уязвимости нулевого дня и развитие инструментов атак, включая использование ИИ, сохраняют высокий уровень неопределенности.

В этих условиях устойчивость бизнеса определяется не только уровнем превентивной защиты, но и готовностью к кризисным сценариям - отработанными процессами реагирования, коммуникации и восстановления.

Российский разработчик UDV Group представил новый релиз своего продукта для контроля версий и централизованного хранения проектов ПЛК - UDV DATAPK Version Control 3.1.

UDV DATAPK Version Control — это первое и на сегодняшний день единственное на рынке РФ специализированное решение для хранения версий проектов ПЛК и отслеживания изменений в них. Продукт решает ключевые инженерные задачи в работе с ПЛК ведущих зарубежных и российских производителей (Siemens, Schneider Electric, Allen Bradley, Овен, Регул, ТРЭИ и других) в одном окне, помогая обеспечивать непрерывность технологического процесса:

• отслеживание изменений в проектах ПЛК, сравнение версий и отображение различий - система фиксирует, кто, когда и что именно менял в проекте;
• централизованное хранение версий - инженеры всегда знают, где лежат актуальные проекты;
• быстрое восстановление - при возникновении сбоя в производственном процессе можно быстро отследить цепочку изменений и восстановить последнюю рабочую версию проекта.

Улучшенный контроль версий ПЛК в релизе 3.1 позволяет видеть не только кто и когда внес изменения, но и конкретные блоки и теги в проекте, которые были отредактированы, а также сопоставлять версии проекта ПЛК в репозитории и на самом контроллере, чтобы убедиться, что на ПЛК загружена именно та версия, которая считается эталонной.

Кроме того, в UDV DATAPK Version Control 3.1 появился ряд обновлений, делающих работу с решением удобнее. Теперь инженер может задать тип проекта ПЛК, чтобы избежать версионирования временных файлов, возникающих при открытии/закрытии среды разработки, а также - быстро скачать актуальную версию десктоп-приложения продукта и логи для облегчения обновления и обслуживания.

“UDV DATAPK Version Control дает предприятию не просто замену иностранного продукта, а собственный рабочий контур для управления проектами ПЛК. И это не архив и не классический бэкап. У предприятия появляется единая точка хранения, понятная история правок, сравнение версий и быстрый путь возврата к рабочей конфигурации после сбоя или ошибки. Для АСУ ТП сегодня это уже не дополнительная функциональность, а фундаментальный элемент безопасности и непрерывности технологического процесса, который должен находиться в предсказуемой и управляемой среде.” - прокомментировал директор Лаборатории кибербезопасности UDV Group Владислав Ганжа.

Алексей Колодка, директор по работе с государственными заказчиками «ГИГАНТ Компьютерные системы» рассказал о том, насколько сложно российским компаниям внедрять рекомендации ФСТЭК по защите сетевого периметра, какие средства автоматизации для этого существуют и есть ли на рынке отечественные инструменты, способные полноценно реализовать все требования регулятора. 

— Насколько сложными в реализации российскими компаниями являются рекомендации, предложенные ФСТЭК?

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

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

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

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

— Какие средства автоматизации могут использовать компании для удовлетворения требований данных рекомендаций?

На российском рынке за последние годы уже сформировался достаточно зрелый набор решений, которые позволяют компаниям выполнять рекомендации ФСТЭК по защите периметра. Крупные отечественные вендоры, такие как Positive Technologies, «Код Безопасности», UserGate и другие, сегодня закрывают значительную часть необходимых задач. Это важный момент: у российских компаний в целом есть из чего выбирать, и рынок уже способен предложить инструменты для реализации требований регулятора.

При этом нужно понимать, что универсального продукта, который в одиночку закроет все требования ФСТЭК, сейчас не существует. Выполнение таких рекомендаций строится не вокруг одного решения, а вокруг комплексной модели защиты, когда компания использует сразу несколько взаимосвязанных средств безопасности. В отдельных случаях могут применяться UTM-платформы, которые объединяют несколько функций в одном контуре, но даже они не снимают потребности в многоуровневой защите.

Если говорить о ключевых классах решений, которые необходимы для выполнения рекомендаций, то в первую очередь речь идет о современных NGFW - межсетевых экранах нового поколения. Это базовый элемент защиты периметра. Далее - средства IDS/IPS для выявления и предотвращения вторжений, сканеры уязвимостей для регулярной проверки инфраструктуры, а также системы класса SIEM для мониторинга и анализа событий информационной безопасности.

Кроме того, для защиты внешних сервисов и веб-ресурсов требуются специализированные решения - например, WAF для защиты веб-приложений и средства противодействия DDoS-атакам. Отдельное значение имеет и контроль доступа: без него невозможно выстроить полноценную защищенную архитектуру и обеспечить соблюдение требований регулятора на практике.

Таким образом, основной путь выполнения рекомендаций ФСТЭК - это не покупка одного «волшебного» продукта, а выстраивание комплексной эшелонированной защиты из нескольких классов решений. Именно за счет сочетания этих инструментов компании могут привести свою инфраструктуру в соответствие с новыми рекомендациями регулятора.

— Есть ли на российском рынке инструменты, которые могут полноценно реализовать все рекомендации ФСТЭК по защите сетевого периметра? 

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

Компания ITKey, российский разработчик и поставщик решений для построения корпоративной облачной инфраструктуры, объявляет о выходе релиза KeyStack 2026.1 - одного из наиболее технологически значимых обновлений платформы. Новая версия сочетает актуальный OpenStack Epoxy с набором собственных промышленных доработок, ориентированных на безопасность, масштабируемость и эксплуатационную устойчивость распределенных инфраструктур.

KeyStack - это облачная платформа для построения частных и публичных облаков в корпоративном и государственном сегменте. В версии 2026.1 продукт выходит на новый уровень зрелости: впервые на российском рынке коммерческий дистрибутив объединяет актуальный релиз OpenStack и готовые enterprise-функции «из коробки», ранее доступные только при значительных доработках.

Ключевой особенностью релиза стало использование OpenStack Epoxy как базового слоя. Это обеспечивает прямой passthrough GPU для AI/ML-нагрузок без оверхеда виртуализации, поддержку OVN Southbound Relay для построения масштабируемых SDN-сетей между географически распределенными ЦОД, а также возможность обновления платформы без остановки сервисов (SLURP).

Дополнительно платформа получила ряд собственных доработок, усиливающих контроль, наблюдаемость и безопасность инфраструктуры. В KeyStack 2026.1 реализован сквозной аудит с передачей реального IP-адреса пользователя в SIEM, детализированная история операций в AdminUI с возможностью фильтрации и экспорта, централизованный планировщик задач, а также механизм резервного копирования с автоматической проверкой восстановления и SHA256-валидацией.

«KeyStack 2026.1 - это переход от набора инструментов к целостной платформе, где безопасность, масштабируемость и эксплуатация заложены на уровне архитектуры. Мы фактически убрали необходимость доработок OpenStack под требования enterprise-сегмента и сделали их частью продукта по умолчанию», - отметил Алексей Шарандин, руководитель продукта KeyStack.

Отдельное внимание в релизе уделено построению отказоустойчивых распределенных инфраструктур. Поддержка OVN SB Relay позволяет управлять сетью тысяч узлов как единой системой, а интеграция с Prometheus, Grafana и AlertManager расширяет возможности мониторинга и автоматической оптимизации ресурсов.

С точки зрения информационной безопасности платформа реализует комплексный подход secure-by-default. В систему встроены механизмы автоматической ротации mTLS-сертификатов и учетных данных, контроль выполнения задач через whitelist, а также сквозной аудит в формате CADF. Это снижает риски утечек данных, несанкционированных действий и ошибок эксплуатации без усложнения управления системой.

Новая функциональность ориентирована на крупные организации с распределенной инфраструктурой и повышенными требованиями к надежности и защите данных - банки, государственные структуры, телеком-операторы, ритейл и промышленные предприятия. Для них обновление означает снижение совокупной стоимости владения за счет NFVi-подхода, сокращение операционных затрат и повышение устойчивости сервисов.

«Мы видим, что ключевой запрос рынка - это не просто облачная платформа, а управляемая и предсказуемая инфраструктура. В этом релизе мы сделали акцент на устранении эксплуатационных рисков: автоматизировали рутинные операции, обеспечили контроль целостности данных и повысили прозрачность всех действий в системе», - добавил Максим Куликов, владелец продукта KeyStack.

Среди практических эффектов внедрения KeyStack 2026.1 - возможность запуска AI-моделей на GPU в виртуальных машинах без выделения физической инфраструктуры, построение отказоустойчивых сетей между ЦОД без дополнительного оборудования, обновление платформы без простоев и гарантированное восстановление данных при авариях.

Релиз KeyStack 2026.1 уже доступен для российских компаний.

Андрей Скороходов, руководитель исследовательских проектов UDV GROUP рассказывает о реальных возможностях искусственного интеллекта в SOC, где AI может заменить первую линию, а где без человека не обойтись. 

Какие задачи первой линии SOC сегодня действительно лучше всего автоматизируются с помощью AI/ML — триаж алертов, дедупликация, приоритизация инцидентов или первичный контекстный анализ?

Прежде всего автоматизация с ML/AI хорошо интегрируется в процесс приоритезации или триажа инцидентов, поиска аномальных или связанных событий из различных источников. Кроме того, современные LLM модели могут достаточно хорошо справляться с помощью аналитикам как при общем анализе с использованием собственных знаний модели или базы знаний SOC, так и при формировании рекомендаций Заказчику или обогащении инцидента. Также решения с ML/AI могут успешно применяться для формирования отчетов, например, выполняя часть рутинной работы аналитика по сбору и анализу информации. 

Насколько высок риск «уверенных ошибок» AI в SOC, когда модель ошибочно подтверждает легитимную активность как атаку, и как это влияет на нагрузку второй линии?

Риск ложных срабатываний моделей ML все еще достаточно велик, и без ограничивающих и корректирующих механизмов это естественным образом будет создавать дополнительную нагрузку на аналитиков, без учета того, что при таких частых сработках пропадет доверие к моделям и потребуется выделение отдельного ресурса для постоянной перепроверки. Можно сказать, что это обратная сторона медали использования моделей, когда за производительность приходится расплачиваться качеством. С другой стороны, если, например, модель обучена на нормальном поведении и выявляет аномальные события, это даст повышенную нагрузку на аналитиков, но позволит выявить атаки, не описанные статичными правилами. В любом случае, увеличение или снижение нагрузки на аналитиков будет напрямую зависеть от качества реализации ML/AI модуля.

Какие типы инцидентов и источники логов остаются принципиально сложными для AI без участия человека, несмотря на развитие LLM и UEBA?

Основная сложность заключается в большом разнообразии программного обеспечения и собственно источников событий, их синхронизации, а также в огромном потоке обрабатываемых событий, не везде программное обеспечение настроено на достаточный уровень логирования и т.д. Поэтому инциденты, оставляющие очень небольшой след в различных источниках, распределенные атаки или атаки, развивающиеся в течение длительного времени, все еще трудно детектировать при помощи представленных на рынке решений.

Как меняются требования к навыкам L1-аналитиков в SOC при внедрении AI: смещение в сторону контроля качества, обучения моделей и работы с false positive?

С применением технологий ML/AI аналитик хоть и не должен будет выполнять привычную работу, однако это не снимет с него требований к глубокому пониманию предметной области, в противном случае он не сможет качественно проверить результаты работы моделей. С другой стороны, при правильном построении процесса, за счет освобождения от рутинных операций у аналитика появится больше времени для улучшения своих навыков в предметной области.

При каких условиях AI может частично заменить первую линию SOC, а где его роль остается вспомогательной, а не замещающей?

AI уже при нынешнем развитии технологий может заменить первую линию SOC, оставив за аналитиками роль контролирующего органа. Что касается сложных комплексных инцидентов, растянутых во времени атак, здесь в ближайшее время все равно решение будет за человеком. 

Цифровая платформа гибкой занятости Ventra Go! раскрыла результаты премии Ventra Go! Retail Awards. Сервис публикует рейтинг уже второй год подряд.

Награда отмечает достижения ритейл-брендов в построении эффективной и уважительной культуры работы с гибким персоналом.

Как были выявлены победители премии

• На платформе Ventra Go! зарегистрировано 2 млн+ исполнителей, которые каждый день выходят на подработку в 300+ брендов. После завершения каждого задания исполнители могут поставить «звезды» — оценки и написать комментарий.

• В рамках Премии 2026 были проанализированы 610 000 оценок и 397 000+ отзывов и комментариев исполнителей, что втрое больше, чем в 2025 году. Были изучены отзывы исполнителей, которые ежедневно берут подработку в 25 000+ торговых точках.
  
• Лидеры были отфильтрованы по рейтингу — так появился шорт-лист из 12 брендов, чьи сильные стороны высоко оценили временные исполнители.

• Пять победителей 2025 года стали лауреатами 2026, среди них: Азбука вкуса, Улыбка радуги, Лента, Золотое Яблоко, О’КЕЙ.

В номинации «Безусловное признание» оценивался суммарный рейтинг по всем критериям. Лидером по количеству высоких оценок в Москве стал SPAR, в регионах в этой же категории одержал победу О’КЕЙ.

В номинации «Внимательное отношение» стал лидером RMixed (MAAG, ECRU, VILET и DUB). Торговые точки получили высокие оценки исполнителей за персональное внимание со стороны директоров магазинов.

В номинации «Быстро и четко» временные работники выделили АШАН, так как в их торговых точках директора магазинов быстро подтверждают выполнение заданий, а исполнители могут сразу получить деньги за подработку.

В номинации «Культура гибкой занятости», в которой оценивалась теплое и уважительное отношение к временным работникам, больше всего баллов набрала Азбука вкуса.

Ритейл-бренд Лента получил номинацию «Самый стабильный». Исполнители отмечали высокий темп подработки и поддержку со стороны команды торговых точек.

Сеть Снежная Королева удостоена номинации «Модное место». Временные работники часто отмечали в отзывах, что им нравится особый стиль магазинов и команда, которая разбирается в модных трендах.

В номинации «Лучшая атмосфера» исполнители отметили Улыбку радуги, в отзывах чаще всего указывали возможность прикоснуться к миру эстетики и красоты.

А четче всего, по мнению исполнителей, задачи формулировали директора Золотого Яблока. Поэтому бренд уже второй год подряд становится лидером в номинации «Ответственный подход».

В номинации «Лучший онбординг» больше всего высоких оценок набрал бренд Подружка. В этих магазинах исполнители отметили подробных инструктаж перед выходом на задание.

«Открытием года» стал новый партнер Ventra Go! — Спортмастер. Исполнители оценили понятные задачи и отзывчивую команду, в которую хочется возвращаться.

В номинации «Самый ожидаемый» стал бренд Чижик. Про возможность выполнения заданий в этой сети исполнители интересуются чаще всего.

«Ventra Go! Retail Awards — уникальная премия. Это единственная награда, которая вручается на основе оценок работников, ежедневно выходящих на подработку в ритейл-бренды. Таким образом, лауреаты премии — компании, которые создают комфортные условия для работы, заботятся о временном персонале и тем самым развивают культуру гибкой занятости в стране», — комментирует директор по маркетингу цифровой платформы гибкой занятости Ventra Go! Анна Ларионова.

О Ventra Go!

Ventra Go! — лидер рынка цифровых платформ гибкой  занятости, топ-5 рынка HR Tech России (Smart Ranking).  Ventra Go! объединяет более 300 брендов (крупнейшие ритейл-сети, e-com, HoReCa) и более 2 млн исполнителей, гарантируя первым быстрое закрытие потребности в проверенном временном персонале, а вторым — ежедневные выплаты и возможность решать, где и когда они хотят работать. Платформа представлена во всех регионах РФ.

• GMV* 8,1 млрд рублей, х2 раза рост YoY
• Инвестиции 700 млн рублей от фонда ВИМ Инвестиции
• Топ-20 бесплатных приложений в категории «Бизнес» в РФ.

Подробности о том, как мировой рынок электроники столкнулся с кризисом из-за чипов памяти, читайте в материале РИАМО.

Технологические гиганты из Китая, изготавливающие смартфоны, резко увеличат стоимость товаров в марте из-за роста цен на чипы памяти. Этот рост станет самым большим за последние пять лет, причем похожие тенденции сегодня наблюдаются на всем мировом рынке электроники.

Что известно о росте цен на китайские смартфоны

О том, что технологические гиганты из Китая, изготавливающие смартфоны, резко увеличат стоимость товаров в марте из-за роста цен на чипы памяти, в конце минувшего февраля агентству «Цайлянь» сообщили источники в области отраслевых поставок. По словам источников, ожидаемое увеличение цен в сфере может стать самым большим за последние пять лет.

Нынешняя стоимость закупки микросхем памяти для телефонов увеличилась более чем на 80%, если сравнивать с тем же периодом в 2025 году. При этом признаков уменьшения роста пока нет. Цены увеличатся на такие бренды, как OnePlus, Oppo, Xiaomi, Vivo и Honor — стоимость может вырасти уже в начале марта.

Значительное увеличение цены на чипы отражает уменьшение мирового предложения и восстановление спроса в области потребительской экономики. Циклы изготовления полупроводников будут и дальше давить на розничные рынки, считают эксперты.

С чем связан глобальный кризис из-за чипов памяти

Сегодня рынок памяти буквально «съедает» искусственный интеллект (ИИ), говорит в беседе с РИАМО директор по производству компании «Торговый Баланс М», кандидат физико-математических наук Михаил Рыжков. Стремительное развитие и массовое внедрение ИИ привели к взрывному росту числа дата-центров по всему миру.

А дата-центр — это, по сути, огромная фабрика по хранению и обработке данных, где чипы памяти являются одним из ключевых ресурсов, объясняет эксперт. В итоге крупнейшие производители (например, Samsung Electronics, SK Hynix и Micron Technology) переориентируют мощности в пользу поставок для ИИ-инфраструктуры.

«Это логично: маржинальность выше, контракты крупнее, спрос стабильно растет. Но есть и обратная сторона — это резкое сокращение предложения для массового рынка, а из этого, естественно, следует стремительный рост цен».

Михаил Рыжков, директор по производству компании «Торговый Баланс М», кандидат физико-математических наук.

При этом подобная переориентация происходит не только на рынке памяти, но и процессоров и других компонентов микроэлектроники, так как для нормальной работы ИИ нужны не только память, но и электронные «мозги». Сформировавшийся дефицит компонентов уже привел к резкому росту цен: по отдельным позициям стоимость микросхем памяти уже выросла на десятки процентов, а в некоторых сегментах — почти вдвое, отмечает гендиректор компании «ГИГАНТ Компьютерные системы» Сергей Семикин.

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

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

В целом текущая ситуация на рынке подталкивает как компании, так и частных пользователей к более прагматичному подходу: покупать технику тогда, когда она действительно необходима, и выбирать решения, которые дают понятную практическую ценность, заключает Сергей Семикин.

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

Когда технологии не работают: эффект отсутствия процессов

Сложные ИБ-инструменты не дают ожидаемого эффекта в тех случаях, когда они внедряются в среду с незрелыми или неформализованными процессами. Проблема здесь, как правило, не в качестве технологий, а в отсутствии операционной модели, которая должна обеспечивать их работу.

Характерный пример — внедрение полнофункционального SIEM-решения для покрытия распределенной или филиальной инфраструктуры. Инвестиции существенные, проект формально реализован, система развернута. Однако через год эксплуатации она продолжает работать в базовой конфигурации и фактически не влияет на уровень защищенности. Причина обычно лежит не в инструменте, а в отсутствии регламентированной операционной схемы: не определены роли и зоны ответственности, не закреплено, кто обрабатывает алерты первой линии, как осуществляется эскалация, в какие сроки происходит закрытие инцидентов. В результате поток событий накапливается, часть алертов остается без обработки, а критичность определяется на уровне субъективного решения специалиста.

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

Почему инструменты «включили и забыли» перестают работать

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

Первая распространенная ошибка — подход «включили и забыли». Система информационной безопасности не является статичным оборудованием, которое можно установить и эксплуатировать без изменений. Любое решение требует регулярного тюнинга и адаптации. Инфраструктура компании развивается: появляются новые сервисы, меняются схемы взаимодействия, трансформируется архитектура. Одновременно эволюционирует и ландшафт угроз — появляются новые техники атак и способы обхода защитных механизмов. Если инструмент не адаптируется к этим изменениям, его эффективность постепенно снижается.

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

Еще одна типовая ошибка — отсутствие формализации и документирования. На практике часто система или отдельный процесс держатся на компетенции одного специалиста. В моменте это может работать эффективно, однако при увольнении или длительном отсутствии сотрудника инструмент фактически остается без владельца. Технология продолжает функционировать, но операционная логика ее использования теряется. Такая зависимость от персонального опыта создает управленческий риск.

Зрелая модель предполагает закрепленные роли, задокументированные процедуры и возможность воспроизводимости процессов независимо от конкретного исполнителя.

Как зрелость процессов влияет на требования к инструментам и архитектуре

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

Если компания развита технологически, ее потребности становятся сложнее. Однако при выборе инструментов ключевой вопрос — не «что умеет продукт», а «для какой задачи и в каком процессе он будет использоваться».

На примере SIEM это особенно заметно. Цель системы — не агрегировать события и демонстрировать корреляцию по базовым правилам, а выявлять инциденты, критичные именно для конкретной инфраструктуры, с учетом значимости активов и сценариев атаки. Без четкого понимания процессов SIEM превращается в хранилище логов с минимальным прикладным эффектом.

Компании, которые только формируют процессную модель, нередко приобретают решения с максимально широким функционалом «на вырост». Логика понятна: лучше закрыть потенциальные потребности заранее. Однако без четко описанных сценариев использования и закрепленных ролей значительная часть возможностей остается невостребованной. Инструмент оказывается технически мощным, но не встроенным в операционную модель.

Именно зрелость процессов меняет логику выбора. Когда команда понимает, какие задачи решает, какие сценарии должны поддерживаться и какие показатели надо контролировать, требования к инструменту становятся конкретными. Архитектура при этом становится гибкой и сервис-ориентированной: замена одного компонента — антивируса, средства мониторинга или другого элемента — не разрушает систему, потому что процессы остаются стабильными. В такой модели инструменты выбираются под задачи и процессы, а не наоборот.

Почему распределение ролей важнее сложности инструментов

Процессы информационной безопасности почти всегда пересекают несколько подразделений. ИТ отвечает за инфраструктуру и доступность сервисов, производственные или бизнес-направления — за прикладные системы и технологические сегменты, ИБ — за выявление угроз и ограничение распространения атак. На границах этих зон и возникают основные риски.

Типичная ситуация: аппаратная платформа формально относится к зоне ответственности ИТ, но фактически часть оборудования размещена в закрытом технологическом контуре и обслуживается другим подразделением. В результате общие политики управления операционными системами, обновлениями и конфигурациями, принятые в ИТ, в этом сегменте не применяются. Цепочка управления и контроля там иная. Это напрямую влияет на безопасность. Процедуры ИБ, встроенные в ИТ-процессы, не «наследуются» в технологическом сегменте, а формируются заново или не формируются вовсе. Возникает разрыв между архитектурной моделью и фактической эксплуатацией.

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

Какие метрики действительно отражают зрелость процессов

Определить зрелость процессов только по наличию регламентов невозможно. Формально описанный процесс может существовать на бумаге, но не работать на практике. Реальную картину дают операционные и результативные метрики.

Если говорить о процессе управления инцидентами, стандартный набор показателей делится на две группы. К операционным относятся время обнаружения, реагирования и восстановления, количество инцидентов в работе и их распределение по критичности. Эти метрики показывают загрузку и темп работы команды. Метрики эффективности отражают качество процесса. Это процент ложных срабатываний, доля инцидентов, закрытых в рамках SLA, количество повторных инцидентов и процент случаев, по которым проведен анализ коренных причин.

Ключевыми индикаторами зрелости можно считать несколько показателей.

1. Среднее время обнаружения. Насколько быстро команда понимает, что инцидент действительно происходит.
2. Среднее время реагирования, то есть интервал от обнаружения до фактического сдерживания или остановки атаки.
3. Количество повторных инцидентов. Если схожие сценарии регулярно воспроизводятся, значит первопричина не устранена. Зрелая модель предполагает не только закрытие инцидента, но и изменение конфигураций, политик или настроек средств защиты для предотвращения повторения.

Четвертый показатель более стратегический — время, необходимое атакующему для достижения критической цели внутри инфраструктуры. Он отражает эффективность эшелонированной защиты и количество барьеров на пути атаки. Оценивать его целесообразно проактивно, через пентесты и киберучения, не дожидаясь реального инцидента.

Именно динамика этих метрик, а не их разовое значение, позволяет судить о том, что процесс развивается и становится зрелым. Однако сами по себе метрики не повышают устойчивость — они лишь фиксируют состояние системы. Возникает практический вопрос: какие управленческие и инженерные шаги позволяют улучшать эти показатели без постоянного расширения технологического стека?

Как повысить эффективность команды без усложнения технологического ландшафта на примере процесса управления инцидентами

Первый элемент — формализация сценариев реагирования. Задача не должна звучать абстрактно как «расследовать инцидент». Для типовых ситуаций (заражение вредоносным ПО, компрометация учетной записи, попытка несанкционированного доступа и т.д.) должна быть зафиксирована согласованная последовательность действий. Фактически речь идет о чек-листах: изолировать хост, собрать артефакты, проверить хеши, зафиксировать события, инициировать восстановление. Такой подход снижает зависимость от субъективной интерпретации и позволяет отслеживать выполнение каждого шага.

Второй практикой является обязательный разбор инцидентов. Приоритет — анализ причин: где именно произошел сбой, почему информация не была замечена, на каком этапе нарушена логика контроля. Цель — устранение процессных и процедурных пробелов, а не поиск виновных. В большинстве случаев корректировка процессов дает больший эффект, чем установка дополнительного сенсора.

Третья практика — регулярные киберучения и тренировки. Они позволяют проверить работоспособность сценариев, оценить готовность команды и выявить узкие места без наступления реального инцидента. Такой формат дает объективную картину задержек, несогласованности действий и проблем эскалации. В результате корректировки вносятся проактивно, а не в условиях кризиса.

Эти практики усиливают управляемость без расширения технологического стека. В зрелой модели сначала настраивается дисциплина исполнения и воспроизводимость процессов, и только затем принимаются решения о расширении инструментов. Игнорирование этой последовательности и приводит к одной из самых распространенных управленческих ошибок — масштабированию ИБ за счет новых решений при сохранении прежней организационной модели.

Ошибки масштабирования: когда инструменты подменяют процессы

Одна из самых распространенных ошибок — попытка решить организационный хаос технологическим способом. Если в компании не выстроен процесс управления инцидентами, отсутствуют закрепленные роли и понятная эскалация, появление нового инструмента не устранит эти пробелы. Например, руководство видит, что команда не справляется с потоком событий, и принимает решение внедрить SIEM или EDR, рассчитывая, что система «сама найдет и расследует» угрозы.

Фактически же без предварительной настройки операционной модели новый инструмент становится еще одним источником данных. Появляется дополнительная консоль, новый поток алертов и еще больше событий, которые необходимо анализировать. При отсутствии распределенной ответственности и регламентированных сценариев обработки нагрузка на команду только возрастает.

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

Заключение: три принципа, чтобы инструменты усиливали процессы, а не подменяли их

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

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

Второй принцип — инструмент не компенсирует управленческие проблемы. Конфликт полномочий, размытые зоны ответственности или отсутствие регламентов не устраняются внедрением новой платформы. Более того, сложное решение в такой среде способно усилить напряжение, добавив новые точки контроля и споров. Управленческие вопросы должны быть решены до масштабирования технологического ландшафта.

Третий принцип — простота как индикатор зрелости. Зрелость не измеряется количеством экранов в центре мониторинга или объемом внедренных решений. Она определяется тем, насколько короткой и понятной является цепочка действий от обнаружения угрозы до ее нейтрализации. Архитектура и инструменты должны сокращать эту цепочку, делать процессы прозрачными и воспроизводимыми.

В конечном счете технология должна усиливать уже выстроенные процессы, а не подменять их. Там, где есть дисциплина, распределенная ответственность и понятная логика действий, инструменты действительно дают эффект. Там, где этого нет, они лишь усложняют картину, не повышая уровень реальной защищенности.

Российский производитель ИТ-оборудования «ГИГАНТ Комплексные системы» и компания РЕД СОФТ, разработчик системного программного обеспечения, сообщают о полной совместимости высокопроизводительной рабочей станции ГКС-777 с операционной системой РЕД ОС. Успешно завершенный комплекс тестирований открывает заказчикам возможность формировать унифицированные автоматизированные рабочие места, сочетающие максимальную производительность оборудования с технологической независимостью программной платформы.

Специалистами компаний было проведено углубленное тестирование, подтвердившее стабильную работу рабочей станции ГКС-777 под управлением операционной системы РЕД ОС. Проверка охватила широкий спектр функций, включая корректную работу высокоскоростных интерфейсов ввода-вывода, поддержку дискретных графических адаптеров последних поколений, а также функционирование многоканальных систем хранения данных.

Ключевым преимуществом совместимости является использование БСВВ (BIOS) ГИГАНТ, разработанной производителем оборудования и зарегистрированной в Едином реестре российского программного обеспечения Минцифры РФ. Это гарантирует высокий уровень аппаратной совместимости на системном уровне, обеспечивает безопасную загрузку операционной системы и полное соответствие требованиям к защите информации для государственных информационных систем.

Благодаря высокой производительности и гибкости конфигурации ГКС-777 тандем с РЕД ОС позволяет решать задачи любой сложности. Модель поддерживает процессоры Intel Core 12, 13 и 14 поколений, оперативную память DDR5 объемом до 192 ГБ, а также до двух высокоскоростных накопителей M.2 2280 PCIe 4.0 и до четырех 2,5-дюймовых SSD или HDD. Наличие широкого набора портов (USB Type-C Gen2, USB Type-A, DisplayPort, HDMI, RJ-45 2,5 Гбит/с) и возможность установки опционального модуля Wi-Fi с Bluetooth обеспечивают гибкость подключения периферии и интеграции в инфраструктуру заказчика.

«Интеграция РЕД ОС с рабочей станцией ГКС-777 обеспечивает высокий уровень производительности при решении ресурсоемких задач. Подтвержденная совместимость позволяет нашим совместным клиентам строить унифицированные автоматизированные рабочие места с гарантированной аппаратной поддержкой и полным технологическим суверенитетом», — подчеркнул РЕД СОФТ.

«Главная идея ГКС-777 заключалась в создании решения, которое закрывает максимально широкий спектр задач — от офисных рабочих мест до профессиональной обработки тяжелых графических и инженерных файлов. Благодаря подтвержденной совместимости с РЕД ОС наша платформа становится еще более привлекательной для заказчиков, которые требуют не только высокой производительности, но и полного суверенитета программно-аппаратного комплекса. Пользователь получает именно тот функционал, который ему нужен, с возможностью дальнейшего масштабирования и готовностью к работе сразу после включения», — отметил Яков Сотников, технический директор компании «ГИГАНТ Комплексные системы».

Совместимость ГКС-777 с РЕД ОС дает заказчикам готовую импортонезависимую платформу, полностью соответствующую требованиям регуляторов. Внесение рабочей станции в Реестр промышленной продукции Минпромторга и наличие отечественного BIOS в реестре Минцифры гарантируют прозрачность технологической базы и надежность оборудования при построении государственных информационных систем и критической инфраструктуры. Гарантийная поддержка устройства составляет 12 месяцев с возможностью расширения до 60 месяцев.

Юрий Чернышов, к.ф.-м.н., доцент УНЦ «Искусственный интеллект» УрФУ, руководитель исследовательского центра UDV Group рассказал о сложностях обнаружения причины изменения поведения модели, о методах, которые подходят для анализа безопасности и о том, как оценивается устойчивость модели в условиях реального применения.

— Какие индикаторы помогают заметить ранние признаки отравления данных на этапе подготовки датасета?

Почти все, кто имеет практический опыт внедрения и использования проектов, включающих анализ данных и машинное обучение, уже в курсе, что подобные системы очень неустойчивы, чувствительны к внешним помехам. Причина этого не в том, что у разработчиков недостаточная экспертиза (хотя встречаются и такие случаи), а в том, что при обучении модели применяются наборы данных, которые не могут содержать все возможные ситуации при будущей эксплуатации. Да это и невозможно, поскольку всегда на практике имеет место так называемый «сдвиг в данных» (data shift) из-за меняющейся инфраструктуры, условий эксплуатации, поведения пользователей и пр. Поэтому очень сложно при обнаружении изменения поведения модели понять - что же является истинной причиной: сдвиг в данных, сбой датчика, помехи в сети передачи данных, некачественная модель ML, незначительная перегрузка инфраструктуры или это просто «шум» в рамках статистической погрешности. И за этими вариантами всегда сложно разглядеть атаку через отравление данных. Индикаторы для диагностики изменения традиционные: всесторонний статистический анализ характеристик данных, как по параметрам получения и обработки, так и по семантике. Но для принятия мер при обнаружении отклонения в поведении модели на основе данных необходима комплексная инфраструктура, включающая мониторинг оборудования, параметров данных и модели, метрик инференса (промышленного использования).

— Какие методы анализа позволяют выявлять бэкдор-активность в уже обученной модели?

Для анализа безопасности модели ИИ подходят все те же методы, применяемые при тестировании безопасности программного обеспечения: мониторинг, фаззинг, анализ взаимодействия с внешними компонентами. Сложность заключается в том, что невозможно понять логику работы модели, как это делается при анализе кода программного обеспечения, поскольку эта логика модели ИИ распределена по миллионам (как в случае с глубоким машинным обучением) или по миллиардам (как в случае с LLM) параметров. Поэтому применяется анализ модели ИИ как «черного ящика», анализируя вход и выход, оценивая параметры работы и потребление ресурсов. Исторический анализ параметров работы модели позволяет сформировать паттерны нормального поведения и анализировать в будущем отклонения от этих паттернов.

— Как оценивается устойчивость модели к adversarial-примерам в условиях реального применения?

Самый лучший способ для подобного анализа это red teaming, в том числе и с применением автоматизированных средств проверки: фаззинг, подбор проверяющих сэмплов, создание для модели критических условий для функционирования (ddos атака). Если есть возможность оценивать устойчивость в лабораторных условиях, то эффективным является схема генеративных состязательных сетей (GAN), в которых есть генератор, создающий сэмплы, и дискриминатор, пытающийся различить настоящие сэмплы и созданные генератором. При этом генератор и дискриминатор постоянно конкурируют друг с другом, генератор учится все лучше «обманывать», а дискриминатор — все лучше выявлять факт подделки.

— Какие техники усложняют попытки извлечения модели через API (model extraction)?

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

— Какие меры повышают защищенность датасетов от подмены, injection-атак и несанкционированных правок?

Наличие защищенных наборов данных - серьезная задача, без которой невозможно создавать качественные, надежные и полезные системы ИИ. Зачастую набор данных ценится даже больше, чем модель, обученная на его основе. Поэтому компании-разработчики систем ИИ так ценят свои наборы данных, защищают их наравне с программным кодом. Меры, защищающие наборы данных (датасеты) от злонамеренного искажения, такие же, как и при защите программного кода: требуется контролировать версионирование и доступ к изменениям, проводить тестирование и анализ характеристик после изменений.

— Какие механизмы мониторинга лучше всего подходят для отслеживания аномалий в поведении ИИ-модели?

Существует множество способов мониторить работу сложного устройства или системы, какой из них наиболее эффективен — сильно зависит от самой системы. Можно анализировать низкоуровневые параметры (трафик, потребление ресурсов оборудования), можно анализировать вход и выход модели ИИ (текст промпта и сгенерированный ответ), потребление токенов. Но на мой взгляд наиболее эффективно анализировать влияние применения модели на бизнес-процесс — если в бизнес-процессе появились отклонения (изменилась продолжительность звонков, частота отправки писем, поменялась бизнес-логика процесса, перестал компилироваться код и пр.), то скорее всего случился сбой в работе ИИ-модели и необходимо проводить расследование, в том числе с применением анализа низкоуровневых событий в инфраструктуре и ПО.

Владимир Кудряшов, директор сервисного департамента компании “ГИГАНТ Компьютерные системы”

Давайте честно: офисный принтер обычно остается незаметной частью инфраструктуры. О нем вспоминают лишь в двух случаях — когда устройство монотонно шумит где-то рядом с рабочим столом или когда внезапно отказывается работать в самый неподходящий момент, например в минуту, когда нужно срочно распечатать договор или комплект документов для совещания.

На протяжении многих лет печатная техника в компаниях обслуживалась по простому сценарию: пока устройство работает — о нем не думают, а если возникает поломка — вызывают мастера. Такой подход казался экономичным, но по мере роста цифровой инфраструктуры стало очевидно, что он формирует скрытые издержки: простои сотрудников, неожиданные расходы на ремонт и постоянное «тушение» возникающих проблем.

Одновременно меняется и сам подход к управлению корпоративной ИТ-инфраструктурой. Все больше организаций переходят к сервисной модели эксплуатации систем — когда ключевой задачей становится не устранение отдельных поломок, а обеспечение стабильной и предсказуемой работы сервисов. Этот подход уже давно применяется для серверов, рабочих мест и облачных платформ и постепенно распространяется на печатную инфраструктуру.

Поэтому сегодня принтеры все чаще рассматриваются не как отдельные офисные устройства, а как полноценный элемент ИТ-ландшафта компании.

Современный сервис печати — это уже не эпизодический визит инженера с набором инструментов. Это выстроенный процесс обслуживания с мониторингом, регламентными работами, контролем SLA и прозрачной экономикой эксплуатации. Такой подход все чаще применяется в корпоративной печатной инфраструктуре.

 От хаоса к системе

Но почему многие компании продолжают работать по старой схеме? Во многих организациях печатная техника долгое время остается своего рода «слепым пятном» ИТ-инфраструктуры. Принтеры устанавливаются в разных подразделениях, обслуживаются эпизодически и редко рассматриваются как полноценный элемент технологического контура. Пока устройства работают, о них практически не вспоминают, а при поломке проблему решают по привычному сценарию — вызывают специалиста.

На первый взгляд такой подход кажется удобным и экономичным. Но при более детальном анализе оказывается, что он приводит к накоплению скрытых издержек: простои сотрудников, бесконечные счета за «внезапные» запчасти и хаотичная закупка расходных материалов.

Если посчитать совокупную стоимость эксплуатации печатной инфраструктуры за год — включая ремонты, простои оборудования и трудозатраты ИТ-команды — нередко оказывается, что модель «ремонта по факту» обходится значительно дороже, чем кажется.

При этом многие ИТ-руководители продолжают защищать эту модель. Чаще всего звучат три аргумента: «у нас мало поломок», «мы платим только за фактический ремонт» и «у нас есть проверенный мастер». На практике эти аргументы во многом иллюзорны: они не учитывают потери от простоя сотрудников, непредсказуемость расходов и зависимость от конкретного специалиста без формально закрепленных сроков реагирования.

В таких условиях печатная инфраструктура начинает жить собственной жизнью: используются разные модели устройств, расходные материалы закупаются несистемно, а обслуживание происходит только после возникновения проблем. В результате ИТ-служба вынуждена постоянно реагировать на инциденты — фактически «тушить пожары», вместо того чтобы управлять инфраструктурой.

Чем сервис отличается от разового вызова мастера

Чтобы понять, почему сервисная модель дает другой результат, важно сравнить ее с традиционным подходом.

Классическая модель обслуживания печатной техники строится вокруг инцидента: устройство ломается — вызывается специалист, который устраняет проблему. Однако по мере роста требований к стабильности бизнес-процессов компании начинают переходить к другой логике — когда ключевой задачей становится предотвращение простоев.

В управляемой модели обслуживание становится постоянным процессом, встроенным в ИТ-инфраструктуру компании.

Разница между этими подходами проявляется в нескольких принципиальных моментах.

Во-первых, появляется формализованный уровень сервиса. Сроки реакции на инциденты и восстановления оборудования фиксируются в контракте через SLA. Это делает обслуживание предсказуемым и позволяет заранее определить ответственность сторон.

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

Иногда такие системы способны предсказать будущую поломку. Например, в одном из проектов мониторинг зафиксировал рост ошибок захвата бумаги и аномальный профиль работы термофиксатора за девять дней до возможной остановки МФУ. Инженер заменил узел в рамках планового обслуживания без остановки работы пользователей. При реактивной схеме тот же инцидент мог привести к 4-8 часам ожидания специалиста и нескольким дням простоя юридического отдела.

Третье отличие — централизованное управление заявками. Вместо разрозненных звонков различным подрядчикам компании получают единое окно взаимодействия с сервисной службой, где все обращения фиксируются и контролируются.

Наконец, сервисная модель делает эксплуатацию печатной техники более прозрачной с экономической точки зрения. Организация получает данные о загрузке устройств, объемах печати и стоимости одного отпечатка.

По сути, сервисный контракт ориентирован не на оплату часов работы инженеров, а на обеспечение стабильной работы печатной инфраструктуры.

 Где здесь экономия?

Один из главных вопросов, который возникает у руководителей и финансовых директоров, — где именно формируется экономический эффект.

Хорошо это видно на простом примере. Представим, что принтер выходит из строя в момент подготовки отчетности или сделки. В реактивной модели восстановление может занять от нескольких часов до нескольких дней: нужно найти специалиста, диагностировать проблему и дождаться поставки запчастей.

В сервисной модели с подменным фондом устройство обычно заменяется или восстанавливается в течение нескольких часов.

Даже при консервативной оценке один такой инцидент может стоить компании десятки тысяч рублей. Если несколько сотрудников не могут работать из-за остановки принтера в течение рабочего дня, прямые потери рабочего времени могут достигать 40 тыс. рублей. С учетом вызова специалиста и запчастей итоговая сумма легко достигает 80-100 тыс. рублей за один инцидент.

Косвенные потери могут оказаться еще выше — например, штрафы за срыв сроков отчетности или потерянная сделка. В результате одна поломка в критический момент иногда сопоставима по стоимости с годовым сервисным контрактом для целого отдела.

При этом сервисная модель позволяет существенно снизить простои. По данным проектов сервисных провайдеров, профилактическое обслуживание и мониторинг могут снижать простои печатной техники на 15-20% и одновременно продлевать срок службы оборудования на 25-30%.

 Как компании переходят на сервисную модель: пример из практики

Как эти принципы работают на практике, показывает пример внедрения сервисной модели в одной из компаний.

Организация с численностью более 300 сотрудников использовала парк из 57 печатающих устройств разных производителей. Часть техники работала более восьми лет, а обслуживание происходило по привычной схеме — по мере поломок. Финансовый директор компании изначально скептически относился к идее фиксированного сервисного контракта.

Первым этапом стал аудит печатной инфраструктуры. Анализ показал неожиданную картину: совокупные расходы на ремонты, расходные материалы и простои сотрудников превышали потенциальную стоимость сервисного контракта примерно на 35%.

После этого компания запустила пилотный проект: 24 устройства были переведены на сервисную модель на три месяца. Были внедрены мониторинг оборудования, централизованная система учета заявок и подменный фонд техники.

Уже в первый месяц системные администраторы практически перестали получать звонки сотрудников по вопросам печати.

Через шесть месяцев компания получила измеримые результаты: общий бюджет на обслуживание печатной техники снизился примерно на 20%, среднее время устранения инцидентов сократилось с шести часов до 45 минут, а количество обращений в ИТ-службу уменьшилось почти на 70%. После этого руководство приняло решение распространить сервисную модель на все три офиса компании.

Заключение. Печать как часть ИТ-стандарта

Один из заметных трендов последних лет — постепенное включение печатной инфраструктуры в общий контур сервисного управления ИТ. Принтеры все чаще рассматриваются как управляемые активы — наравне с рабочими станциями, сетевой инфраструктурой и серверными системами.

Когда печатная инфраструктура становится управляемой, компании получают дополнительный инструмент — аналитику печати. Данные о том, кто, что и в каком объеме печатает, помогают оптимизировать парк оборудования, контролировать расходы и повышать уровень безопасности.

Практика показывает, что после внедрения систем аналитики часто обнаруживается неравномерная загрузка техники: часть устройств перегружена, а часть простаивает. Перераспределение нагрузки позволяет снизить расходы на эксплуатацию.

Дополнительный эффект дает настройка политик печати — например, двусторонняя печать или монохромный режим по умолчанию, которые способны сократить объем печати на 15-25%.

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

Накопленные данные помогают компаниям принимать стратегические решения — например, определять процессы, где наиболее целесообразен переход на электронный документооборот.

В результате печать постепенно превращается из вспомогательной функции в управляемый элемент ИТ-инфраструктуры — с понятными метриками, прозрачной экономикой и более предсказуемой работой сервисов.

Ограничения рынка и санкционное давление быстро показали: зрелую систему информационной безопасности больше нельзя просто «закупить». Сегодня её приходится выстраивать — инженерно, последовательно и с расчётом на долгую эксплуатацию. Для ИТ-директоров российских компаний этот сдвиг становится ключевым вызовом.

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

Какие ошибки на старте начинают проявляться через один—два года эксплуатации? И какие принципы позволяют сохранить устойчивость ИБ в долгосрочной перспективе? Об этом — в колонке Николая Нагдасева, ведущего специалиста департамента кибербезопасности UDV Group.

Три кита зрелой системы информационной безопасности

На практике все эти вопросы сводятся к одному: что делает систему ИБ управляемой и устойчивой не в теории, а в реальной эксплуатации? Опыт крупных российских компаний показывает, что при всём разнообразии отраслей и ИТ-ландшафтов принципы построения зрелой системы ИБ во многом совпадают.

Если говорить упрощённо, в таких организациях зрелая система информационной безопасности опирается на три базовых элемента.

Первый элемент — люди, их компетенции и выстроенные вокруг них процессы. Речь идёт не просто о наличии специалистов по ИБ, а о том, как организованы отдельные процессы: безопасность сетевого периметра, антивирусная защита, мониторинг, управление уязвимостями, реагирование на инциденты и т.д. За каждым процессом стоят конкретные зоны ответственности и понятные правила взаимодействия между ИБ, ИТ и бизнесом. Без этого компания быстро скатывается в реактивную модель с постоянным «тушением пожаров».

Второй элемент — архитектура и документы. Это инженерная основа системы: инвентаризация активов, модели угроз, сетевая сегментация и понимание потоков данных. Политики и регламенты по ключевым направлениям ИБ формализуют единые правила игры и позволяют связать отдельные меры в целостную систему. Без этой основы безопасность перестаёт быть управляемой и начинает фрагментироваться.

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

С чего начинать построение ИБ, если весь стек внедрить невозможно

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

С архитектурной точки зрения базовым шагом остаётся сегментация сети и выстраивание эшелонированной защиты. Задача — изолировать наиболее критичные активы и снизить риск распространения атак внутри инфраструктуры. С технической стороны средства защиты логично рассматривать по слоям. Базовый слой включает антивирусную защиту, межсетевое экранирование, резервное копирование, защиту веб-приложений, безопасность удалённого доступа и двухфакторную аутентификацию для критичных и ресурсов, доступных из сети интернет. Сегодня к этому минимуму в полной мере относятся инструменты для сканирования уязвимостей внешнего периметра и критичных систем, а также использование SIEM-функциональности для централизованного анализа событий безопасности.

Следующий уровень напрямую зависит от зрелости компании и готовности процессов. Здесь появляются системы управления привилегированным доступом, платформы управления инцидентами и собственный или внешний SOC.

Все остальные меры не являются универсальными. Их необходимость определяется спецификой бизнеса, отраслевыми требованиями и регуляторными ограничениями, и именно с этой точки зрения их стоит рассматривать при проектировании системы ИБ.

К чему приводят архитектурные компромиссы в проектах по построению ИБ

Ограничения рынка почти неизбежно приводят к архитектурным компромиссам, и их последствия, как правило, проявляются не сразу, а через год—два эксплуатации.

Одна из наиболее частых ошибок — внедрение точечных решений без учёта общей архитектуры системы безопасности. Формально задачи закрываются, но на практике компания получает набор слабо связанных инструментов, которые сложно сопровождать и ещё сложнее развивать. Это увеличивает операционную нагрузку и снижает управляемость системы ИБ. Ситуацию усугубляет дефицит специалистов. Нередко решения оказываются внедрёнными, но не обеспеченными ресурсами для полноценной эксплуатации. В результате средства защиты не дают ожидаемого эффекта, а инвестиции в ИБ фактически не работают. Чтобы этого избежать, архитектуру системы безопасности необходимо проектировать с учетом реальных возможностей эксплуатации и заранее продумывать связность решений, как минимум на уровне мониторинга и управления.

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

В долгосрочной перспективе ключевая задача — не допустить превращения ИБ в разрозненный набор решений с высокой операционной нагрузкой. Иначе рост эксплуатационных затрат будет сопровождаться снижением реального уровня защищённости.

Как выстраивать приоритеты между предотвращением, мониторингом и реагированием

В условиях ограниченных ресурсов важно не пытаться развивать все направления одновременно, а выстраивать последовательную логику. Начинать стоит с предотвращения. Предотвращение — стратегическая цель, но достигается она через вполне прикладные меры: сегментацию сети, своевременное обновление систем, харденинг и регулярное устранение уязвимостей. Эти действия снижают вероятность инцидентов ещё до этапов обнаружения и реагирования.

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

Следующий приоритет — логирование и мониторинг. Без централизованного сбора и анализа событий предотвращение фактически работает вслепую. Мониторинг создаёт основу для уверенного обнаружения угроз и позволяет видеть, что реально происходит в инфраструктуре.

Обнаружение логически вытекает из мониторинга и зависит от качества данных и процессов анализа. Уже на этой базе становится возможным управляемое и воспроизводимое реагирование на инциденты.

Почему наблюдаемость становится базовым требованием зрелой ИБ

Прозрачность и наблюдаемость инфраструктуры сегодня перестают быть дополнительной функцией и становятся базовым признаком зрелой системы информационной безопасности. В условиях ограниченных ресурсов именно понимание того, что происходит в инфраструктуре, позволяет сохранять управляемость и принимать обоснованные решения. Движение в эту сторону логично начинать с инвентаризации. Она может быть не идеальной, но должна охватывать все критичные активы и связанные с ними элементы инфраструктуры. Важно понимать, какие системы обеспечивают ключевые бизнес-процессы, где они размещены и от каких компонентов зависят.

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

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

Для ИТ-директора при дефиците инструментов и специалистов критично держать под контролем два блока данных: перечень критичных бизнес-процессов и обеспечивающих их систем, а также сводный статус выполнения базовых мер защиты — обновлений, закрытия уязвимостей, охвата двухфакторной аутентификацией, выявленных инцидентов и выполнении технических мер по защите информации.

Какие процессы ИБ стоит автоматизировать в первую очередь

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

В первую очередь это касается управления инцидентами. На этапе анализа автоматизация ускоряет обогащение инцидентов контекстом за счёт данных из внутренних систем и средств защиты. На этапе реагирования она позволяет сократить время реакции и повысить точность и воспроизводимость действий — от блокировки учётных записей и обновления правил фильтрации до изоляции скомпрометированных узлов.

Почему без правильной эксплуатации система ИБ неизбежно деградирует

Зрелость информационной безопасности определяется не наличием отдельных средств защиты, а тем, насколько устойчиво и предсказуемо выстроены процессы управления информационной безопасностью компании. Именно на этапе эксплуатации чаще всего возникают проблемы, которые со временем подтачивают систему ИБ. Инфраструктура постоянно меняется: появляются новые сервисы, обновляются ИТ-системы, меняются конфигурации. Если система информационной безопасности не развивается синхронно с этими изменениями, возникают обходы политик, устаревшие регламенты и неактуальные настройки средств защиты. Формально ИБ существует, но всё хуже отражает реальное состояние инфраструктуры.

Чтобы этого избежать, необходим регулярный контроль и тестирование безопасности, прежде всего для точек входа в инфраструктуру, ресурсов доступных из сети Интернет и критичных информационных систем. Такой контроль позволяет выявлять расхождения между требованиями и фактическими настройками до того, как они приведут к инциденту. Не менее важна жёсткая связка ИБ с процессами изменения ИТ-инфраструктуры. Любые внедрения, миграции и обновления должны проходить оценку с точки зрения ИБ и соответствия действующим политикам. Дополняют эту модель регулярные тренировки по реагированию на инциденты, максимально приближённые к реальным сценариям. Они помогают поддерживать навыки команды и выявлять слабые места в процессах и технологиях, которые не всегда видны при формальном анализе.

Какие принципы стоит зафиксировать, чтобы система ИБ оставалась устойчивой

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

Первый принцип — технологическая автономия и отказ от жёсткой зависимости от одного вендора. Архитектура ИБ должна учитывать ограничения поставок, изменения условий поддержки и возможный уход решений с рынка. Монолитные экосистемы могут ускорять внедрение, но в долгосрочной перспективе вендор-лок увеличивает риски для устойчивости системы.

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

Отдельного внимания требует готовность к инцидентам. В компании должен существовать понятный план реагирования, а его эффективность необходимо регулярно проверять на практике — через учения и тренировки, приближённые к реальным сценариям.

Наконец, устойчивость невозможна без измеримости. Метрики состояния защищённости позволяют объективно оценивать эффективность мер ИБ, управлять рисками и обосновывать инвестиции как внутри ИТ, так и на уровне бизнеса и руководства.

Заключение

В условиях ограничений рынка устойчивость информационной безопасности определяется не набором продуктов, а качеством инженерных решений и зрелостью эксплуатации. Зрелая ИБ — это баланс между предотвращением и обнаружением, автоматизацией и ручной экспертизой, архитектурной гибкостью и операционной простотой, который невозможно купить или зафиксировать раз и навсегда. Для ИТ-директора сегодня важно выстроить не «идеальную», а управляемую систему ИБ, способную сохранять устойчивость в реальной эксплуатации — при изменениях инфраструктуры, дефиците ресурсов и нестабильных внешних условиях.

ФКУ "Центр по обеспечению деятельности Казначейства России" объявило о проведении открытого конкурса на право заключения контракта по оказанию комплексных услуг в сфере информационно-технологической инфраструктуры для нужд Федерального казначейства.

21 февраля Центр по обеспечению деятельности Казначейства России (ЦОКР) разместил соответствующий тендер сразу на нескольких площадках: ЕИС "Закупки" и на АО "Единая электронная торговая площадка" ("Росэлторг"). Дата окончания срока подачи заявок - 18 марта 2026 г. Дата подведения итогов определения поставщика - 23 марта. Срок исполнения контракта: с момента подписания и до 30 ноября 2028 г.

Согласно технической документации, целью конкурса является привлечение квалифицированных специалистов, которые помогут восстановить работу сложных технических устройств с программным обеспечением. Исполнителю также нужно будет обеспечить и поддерживать работу компьютерных и телекоммуникационных систем. Эти системы включают в себя различные компоненты, такие как ОЗ1, КР1, КР2, КР3 и КР4 (условные обозначения различного оборудования и конфигураций вычислительных и телекоммуникационных ресурсов, используемых в государственных закупках для классификации и разделения функционала систем и инфраструктуры).

Проект предполагает выполнение работ поэтапно, с четким распределением обязательств по различным временным интервалам (периоды 11-18, 21-37). Это позволит подрядчику эффективно планировать и вести мероприятия, обеспечив бесперебойную поддержку критически важной инфраструктурной составляющей органов федеральной власти.

Оценка заявок происходит по двум основным показателям: стоимость контракта (60%) и квалификация участника (40%). Такое разделение критериев подчеркивает стремление заказчика привлечь опытных исполнителей, обладающих необходимым уровнем компетенций и ресурсной базы для качественного оказания услуг.

Финансирование проекта предусмотрено в трехлетнем периоде: наибольшая доля расходов приходится на 2028 г. - 4,1 млрд руб., промежуточным этапом станет реализация плана в 2027 г. - 3,5 млрд руб.

Начальник отдела эксплуатации централизованной инфраструктуры филиала ФКУ "ЦОКР" по обеспечению услугами в области информационных технологий Лидия Чепурнова сообщила корреспонденту ComNews, что данная закупка является продолжением проекта, запущенного в Федеральном казначействе в 2024 г., который предполагает полный переход ИТ-инфраструктуры ведомства на отечественные аппаратные решения через предоставление их в сервис, а также обеспечение бесперебойной работы оборудования, которое находится в собственности ведомства после окончания гарантии.

Лидия Чепурнова отметила, что заказчик оценивал различные подходы для реализации проекта: "Выбор предоставления оборудования в сервис с поэтапной оплатой позволит равномерно распределить финансовую нагрузку во время всего жизненного цикла оборудования и избежать единовременных больших капитальных затрат. Проект реализует комплексный подход в области импортонезависимости инфраструктуры информационных систем Федерального казначейства, тем самым обеспечивая бесперебойное функционирование бюджетной системы РФ".

Лидия Чепурнова сообщила, что на данном оборудовании будут размещаться ключевые государственные информационные системы, оператором которых является Федеральное казначейство:
- Единая информационная система в сфере закупок;
- ГИИС "Электронный бюджет";
- Государственная информационная система о государственных и муниципальных платежах;
- Государственная автоматизированная информационная система "Управление";
- Государственная информационная система "Торги";
- Государственная информационная система о государственных (муниципальных) учреждениях;
И другие информационные системы ведомства.

"Такой подход позволяет последовательно повышать импортонезависимость государственных информационных систем, неукоснительно выполняя указы президента №166 от 30.03.2022 и его изменения "О мерах по обеспечению технологической независимости и безопасности КИИ РФ" и №309 "О национальных целях развития РФ на период до 2030 г. и на перспективу до 2036 г.". Обоснование начальной максимальной цены контракта произведено в строгом соответствии со ст.22 44-ФЗ, с использованием метода сопоставимых рыночных цен", - подчеркнула Лидия Чепурнова.

Нехватка ИТ-специалистов

Директор по продажам ООО "Стахановец" Артем Жадеев посетовал, что специалистов нужного уровня очень не хватает: "Это одна из главных причин, по которой заказчики обращаются к крупным подрядчикам. Раньше подготовкой инженеров занимались иностранные компании, ушедшие из России. Теперь готовить кадры приходится самостоятельно, и это долгий процесс. Найти уже готового мастера высокого класса очень сложно, на это могут уйти месяцы. Держать в штате всех возможных специалистов на все случаи жизни для государственного учреждения просто невыгодно. Это требует огромных расходов на зарплату и постоянное обучение. Именно поэтому побеждают в таких конкурсах компании, у которых уже есть готовая команда профессионалов, способная решать самые разные задачи без задержек".

Опытный исполнитель

С октября 2014 г. на портале госзакупок у ФКУ "Центр по обеспечению деятельности Казначейства России" насчитывается 427 размещенных конкурсов на закупку с начальной максимальной ценой контракта от 100 млн руб. Из них 394 конкурса уже завершены, и поставщики услуг определены.

Член Ассоциации антимонопольных экспертов, член рабочей группы по государственным и корпоративным закупкам при Общественном совете ФАС России Марина Максимова отметила, что с учетом масштаба начальной (минимальной) цены контракта, значительного размера обеспечения заявки и жестких неценовых квалификационных требований, в реальности претендовать на победу и просто участие в таком конкурсе сможет лишь крупный и профессиональный игрок рынка, имеющий достаточный финансовый, организационный и технологический ресурс.

Руководитель практики правовых исследований и взаимодействия с государственными органами юридической компании "Инноправо" Сергей Афанасьев отметил, что в рассматриваемом конкурсе заказчик действует в рамках строго формализованной модели оценки, закрепленной постановлением правительства РФ от 31 декабря 2021 г. №2604: "Итоговый рейтинг заявки считается по формуле, где приоритетный вес отдается критерию предложенной цены, однако почти половина (0,4) веса отведена критерию опыта и квалификации участника и его деловой репутации: количество сопоставимых исполненных договоров по 44-ФЗ и 223-ФЗ за последние пять лет, их совокупная стоимость и максимальная цена одного контракта и, что немаловажно, без висящих неустоек, что фактически отсекает случайных игроков и формирует пул проверенных добросовестных поставщиков. Такой баланс позволяет одновременно обеспечивать экономию бюджетных средств и снижать риски срыва контрактов за счет отбора опытных исполнителей".

Жизнь без отраслевого стандарта

На вопрос, существуют ли отраслевые нормы или рекомендации относительно оптимального выбора поставщиков услуг по сопровождению оборудования со специальным программным обеспечением, руководитель направления разработки технической документации ООО "ГКС" ("Гигант - Компьютерные системы") Дмитрий Битченков ответил, что отраслевого стандарта нет, и это основная сложность для заказчика, в связи с чем рынок формирует эти критерии на ходу: "В ИТ‑сопровождении обычно опираются на практики ITSM, например процессы инцидентов, проблем, изменений, а также на подтверждаемую систему управления качеством и ИБ (ISO/IEC 20000, ISO/IEC 27001, ISO 9001 - в российских закупках часто встречаются их ГОСТ-эквиваленты). Сертификаты ISO (документы, которые подтверждают, что продукция, услуга или система управления компании соответствуют международным стандартам, установленным Международной организацией по стандартизации - ISO) показывают, что у компании есть система. Но дальше нужно оценивать реальную зрелость процессов. В штате компании-интегратора должны быть инженеры с подтвержденным опытом по конкретным дистрибутивам - Astra Linux, RED OS, "Альт", системам виртуализации, например на базе KVM, и оркестрации, а также лаборатория для воспроизведения инцидентов".

Ключевая тенденция

Директор по развитию ООО "Веб3 Технологии" (Web3 Tech) Кирилл Антонов рассказал, что ключевая тенденция на рынке оказания услуг по поддержке и восстановлению работоспособности специализированных ИТ-решений - переход от реактивного подхода "ремонт по факту отказа" к сервисной модели управления жизненным циклом (Lifecycle Services): "Заказчики все чаще закупают не разовые работы, а измеримую эксплуатацию с целевыми показателями: доступность, время реакции, время восстановления, качество изменений. В результате растет роль постоянного мониторинга, предупреждающего обслуживания, регламентных обновлений и превентивной замены компонентов до наступления критических отказов, а также стандартизации конфигураций и ведения эталонных сборок для снижения вариативности и аварийности".

Показательная закупка

Советник юридической компании "Инноправо" Артем Костюков считает, что эта закупка показательна еще и с точки зрения последних новелл в сфере госзакупок: "Конкурс проводится уже в логике перехода к электронным, или цифровым, контрактам, которые формируются и заключаются в ЕИС на основе извещения, протокола и структурированных заявок. По итогам конкурса проект контракта автоматически собирается в системе из данных заявки победителя и протокола, подписывается сторонами усиленной электронной подписью и практически без ручного дублирования уходит в реестр контрактов, что снижает риск технических ошибок, ускоряет старт исполнения и делает всю цепочку - от оценки заявок по постановлению №2604 до исполнения обязательств - полностью прослеживаемой в цифровом контуре".

Артем Костюков подчеркнул, что для таких сложных ИТ-закупок, как поддержка и ресурсы ЦОДа, это особенно важно: "Цифровой контракт напрямую связывает опыт и показатели участника, оцененные по конкурсу, с реальными ключевыми показателями эффективности исполнения и облегчает последующий контроль, в том числе при применении одностороннего отказа или неустоек. Кроме того, согласно общему курсу последних изменений 44-ФЗ на цифровизацию и сокращение бумажной нагрузки, теперь участникам закупок разрешено вместо громоздких пакетов скриншотов и копий из всевозможных реестров лицензий прикладывать ссылки на записи в государственных реестрах и ЕИС".

Под защитой

Марина Максимова пояснила, что интересы заказчика защищаются через обеспечение заявки и исполнения контракта, подробные условия ответственности (штрафы, пени, условия расторжения), поэтапную приемку и оплату, а также право одностороннего отказа при существенных нарушениях и последующее включение недобросовестного исполнителя в реестр. "Техническое задание хоть и объемное в данном конкурсе, однако для такого ИТ‑проекта критично четко и в деталях прописать порядок реагирования на инциденты, взаимодействие при авариях и киберугрозах, требования к защите данных и многое другое", - подчеркнула она.

Игорь Юрин, технический директор (CTO) компании «ГИГАНТ Компьютерные системы», рассказал о росте спроса на инфраструктуру дата-центров в 2026 году, драйверах увеличения мощностей и перспективах развития локальных ЦОД.

— Наблюдаете ли вы рост спроса со стороны заказчиков? Продолжится ли он в 2026 году и как сильно?

По итогам 2025 года мы фиксируем устойчивый и системный рост спроса на инфраструктуру дата-центров. Он проявляется как в сегменте модульных ЦОДов, так и в проектах по наращиванию вычислительных мощностей внутри корпоративных площадок. Заказчики — промышленность, телеком, госсектор, крупные корпоративные структуры — активно инвестируют в собственные ИТ-мощности, поскольку цифровые сервисы, аналитика и ИИ-нагрузки становятся не вспомогательным, а базовым элементом бизнеса. Речь идет уже не о точечном расширении, а о стратегическом планировании инфраструктуры на 3-5 лет вперед.

В 2026 году мы ожидаем сохранения двузначных темпов роста рынка. Драйверы остаются прежними — развитие ИИ, рост требований к хранению и обработке данных, импортонезависимость технологического стека и перераспределение нагрузок в сторону локальных инфраструктур. По нашей оценке, спрос продолжит расти заметно выше средних темпов ИТ-рынка в целом.

— С чем связан резкий рост мощностей и продолжится ли он в ближайшие годы?

Резкий рост мощностей в 2025 году обусловлен сразу несколькими факторами. Во-первых, это кратный рост вычислительных нагрузок, связанных с внедрением ИИ-моделей, аналитических платформ и сервисов обработки больших данных. Во-вторых, усиливается тренд на консолидацию и модернизацию устаревшей инфраструктуры — заказчики переходят к более плотным конфигурациям стоек и более энергоемким архитектурам. В-третьих, заметно ускорился цикл принятия решений: бизнес стремится заранее зарезервировать мощности, чтобы не столкнуться с дефицитом ресурсов.

Мы считаем, что рост мощностей продолжится в ближайшие годы. Однако он станет более структурированным: рынок перейдет от экстенсивного масштабирования к более точному планированию с учетом энергоэффективности, плотности размещения и совокупной стоимости владения. Устойчивый спрос на высокоплотные решения и модульные архитектуры сохранится.

— Насколько активно в дальнейшем будет развиваться тренд на локальные дата-центры?

Тренд на локальные дата-центры будет развиваться активно и, по сути, станет одним из ключевых архитектурных направлений рынка. Заказчики все чаще стремятся приблизить вычислительные ресурсы к источнику данных — это снижает задержки, повышает управляемость и позволяет обеспечить непрерывность бизнес-процессов. Особенно это актуально для промышленности, распределенных сетей, телеком-инфраструктуры и проектов с жесткими требованиями к времени отклика.

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

Согласно исследованию «Солар», передача конфиденциальной информации от сотрудников российских компаний в зарубежные ИИ‑сервисы, такие как Chat GPT, выросла в 30 раз. Насколько серьёзна эта угроза и как бизнесу защитить свои данные? Своим мнением с «Телеспутником» поделились Алексей Колодка, директор по продажам компании «ГИГАНТ Компьютерные системы» и Ярослав Якимов, директор по развитию технологий искусственного интеллекта GS Labs.

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

По его словам, многие даже не задумываются, какие данные передают и как это может навредить организации. Низкий уровень осведомлённости о киберрисках усугубляет ситуацию — в компаниях редко разъясняют ценность конфиденциальной информации и риски использования западных сервисов.

При этом эксперт призывает не демонизировать ИИ сервисы. Он поясняет, что данные, отправленные в чат, как правило, не покидают серверы платформы и не становятся автоматически достоянием конкурентов. Однако риск возникает при обучении моделей — информация может быть использована для улучшения алгоритмов, что теоретически создаёт потенциальную уязвимость.

Эксперт обращает внимание на отсутствие в большинстве российских компаний регламентов по работе с искусственным интеллектом. Руководство зачастую даже не знает, что сотрудники применяют ИИ в рабочих процессах.

«Без этого нельзя предъявлять сотруднику какие-либо претензии или обвинять его в утечке чувствительной информации», — подчёркивает Алексей Колодка.

Он считает, что внедрение чётких правил и инструкций — первоочерёдная мера для предотвращения утечек как персональных данных, так и коммерческой тайны.

Что касается перехода на отечественные аналоги, такой массовой тенденции пока не наблюдается, отмечает эксперт. Западные сервисы остаются более функциональными и удобными для решения многих задач. Тем не менее, по словам коммерческого директора, российские разработки активно развиваются. В перспективе их возможности будут расти, что позволит бизнесу безопаснее и эффективнее внедрять ИИ технологии в свои процессы, резюмировал эксперт.

Эту логику развивает и Ярослав Якимов. По его мнению, корень проблемы лежит не столько в небрежности сотрудников, сколько в изменении самой культуры труда.

По словам эксперта, ИИ-сервисы стали тем, чем «всего 10 лет назад были Dropbox, мессенджеры и личные почты». Объем задач на сотрудников растет, отмечает эксперт, особенно на фоне кризиса найма «дополнительных рук», и они ищут пути оптимизации своей работы — и бизнес здесь всегда проигрывает гонку удобства.

«Пока в компании не появятся правила использования интеллектуальных помощников, не произойдет их легализация и встраивание в бизнес-процессы, руководители так и будут бороться с последствиями, а не с причиной», — подчеркивает Ярослав Якимов.

Также эксперт подчёркивает, что нынешние тенденции вскрывают слабость классической иерархии: сотрудник с ИИ получает интеллектуальное усиление, которое часто превосходит возможности его руководителя уследить за результатами. Особенно, если через «сарафанное радио» сотрудник распространит идею использовать подобные сервисы между своими коллегами. И даже запреты, по мнению Якимова, на использование таких инструментов перестают работать — остается только управление через правила, доверие и прозрачность. Это системный сдвиг в модели управления, а не временный тренд, резюмирует Якимов.

Итоговым решением, по мнению эксперта, должен стать переход на верифицированные решения — либо развёрнутые на собственных мощностях компании, либо предоставляемые отечественными провайдерами с полным контролем за использованием данных.

Катастрофы в ИТ не ограничиваются отказом одного сервера или ошибкой администратора. Современная инфраструктура — распределенная, нагруженная и завязанная на десятки сервисов, без которых бизнес останавливается. Чтобы минимизировать простои и потери, компании выстраивают системный подход к Disaster Recovery. Cyber Media разбирает, как правильно планировать RTO и RPO, проверять резервные копии и тестировать готовность инфраструктуры к сбоям.

Почему DR стал критичнее, чем когда-либо

Современный бизнес крепко завязан на цифровые сервисы. Даже кратковременный сбой в одной системе может парализовать десятки процессов — от онлайн-продаж до бухгалтерии. Простои уже не воспринимаются как мелкая неприятность: каждая минута реально бьет по доходам и репутации.

Инфраструктура компаний стала сложнее: микросервисы, распределенные базы данных, гибридные облака. Без продуманного DR-плана восстановление даже одного узла превращается в сложный квест. Основные вызовы сегодня:

• консистентность данных между распределенными хранилищами;
• зависимости между микросервисами;
• готовность критичных ресурсов без перегрузки инфраструктуры;
• тестирование DR-процессов на реальные сценарии сбоев.

Требования к скорости восстановления и потере данных растут с каждым годом. RTO и RPO уже давно не формальность: компании реально измеряют, сколько минут сервис может быть недоступен и сколько данных допустимо потерять.

Экономическая цена простоев впечатляет: это и потерянный доход, и штрафы за SLA, и удар по доверию клиентов. Disaster Recovery перестал быть «страховкой на всякий случай» — это ключевой элемент стабильности современной компании.

Формирование DR-стратегии: от классификации систем до выбора уровней защиты

Построение DR-стратегии начинается с трезвого понимания, что именно в вашей инфраструктуре критично для бизнеса. Не все сервисы одинаково важны, и правильная классификация — это не просто список «важно/не важно». Это детальный анализ: какие сервисы останавливаются мгновенно при отказе, какие могут пережить короткий простой без серьезного ущерба, а какие связаны с цепочками зависимостей, где сбой в одном узле приведет к каскадным отказам.

Федор Маслов. Менеджер продукта UDV DATAPK Industrial Kit
Требования к RPO и RTO формируются при разработке стратегии по защите данных и опираются на критичность бизнес-процессов, обеспечиваемых защищаемыми системами. В первую очередь, владельцы бизнеса должны определить критичность бизнес-процессов, далее — выявить максимально допустимое время их остановки. Затем — сформировать списки ИТ-сервисов и систем, реализующих эти бизнес-процессы, и определить максимально допустимый временной период потери данных в этих сервисах, его последствия. Помимо этого, необходимо определить требования к сроку хранения данных как на стороне как бизнеса, так и со стороны регуляторов, поскольку длительный срок хранения, в совокупности с RPO, продиктует требования к СХД для резервных копий и реплик данных, а это, в свою очередь, непосредственно повлияет на бюджет системы СРК, что также может оказать обратное влияние на требования к RPO. Понимание данных метрик и факторов позволит организациям точно определить необходимые RTO и RPO, а также уложиться в бюджет.

Ключевой момент — баланс между доступностью и стоимостью. Многие компании стараются «застраховать все», создавая активные и резервные контуры для каждого сервиса. Результат? Перегруженные ресурсы, низкая эффективность и дорогостоящие простои при переключении. Опытные ИБ-специалисты используют подход, при котором ресурсы распределяются с прицелом на реальную нагрузку, а резервные контуры активируются по мере необходимости.

И наконец, DR-стратегия должна быть живой, а не статичной. Это не бумажная схема, которую подписали и забыли. Каждая новая интеграция, обновление микросервисов или изменение архитектуры требует пересмотра приоритетов, RTO/RPO и схем распределения нагрузки.

Резервные копии: как проверять, что они действительно восстановятся

Наличие резервных копий — это базовый элемент любой DR-стратегии, но наличие бэкапов само по себе ничего не гарантирует. Большинство проблем возникает не из-за отсутствия копий, а из-за того, что они не проходят проверку и не готовы к реальному восстановлению.

Для критичных систем важно иметь минимальный набор тестов, которые проверяют не только наличие файлов, но и их пригодность. Это включает:

• контроль целостности;
• тестовое развертывание;
• восстановление на стендах, имитирующих продакшн.

Такой подход позволяет выявить скрытые проблемы на раннем этапе и не получить неприятный сюрприз во время настоящего сбоя.

Федор Показаньев. Руководитель направления виртуализации и СРК «Софтлайн Решения» (ГК Softline)
Критичность систем определяет подход к организации их восстановления. У каждой системы должна быть инструкция, описывающая восстановление после инцидентов и регламентирующая действия специалистов. Для Mission Critical систем должен быть организован тестовый контур, где специалисты могут регулярно проводить учения по восстановлению системы.

Несмотря на трудоемкость данного процесса, именно такая практика обеспечивает бизнесу гарантии консистентности данных и оперативной готовности команды к действиям в нештатных ситуациях.

В итоге, резервные копии из «страховки на бумаге» превращаются в реально работающий инструмент Disaster Recovery, который позволяет бизнесу уверенно справляться с любыми сбоями.

Infrastructure Redundancy: построение активных и резервных контуров

Построение устойчивой инфраструктуры — это не просто наличие резервного оборудования. В современных распределенных системах важно правильно организовать активные и резервные контуры, чтобы они реально работали, а не лежали «холодными» до момента сбоя.

Одним из ключевых решений является выбор архитектуры: active-active или active-passive. В active-active оба контура работают параллельно, обеспечивая высокую доступность и равномерное распределение нагрузки. Это снижает риски простоев, но увеличивает стоимость и сложность управления. В active-passive один контур работает в нормальном режиме, а резерв включается только при сбое. Такая схема проще и дешевле, но требует тщательного тестирования переключений, чтобы не столкнуться с неожиданными проблемами.

Федор Показаньев. Руководитель направления виртуализации и СРК «Софтлайн Решения» (ГК Softline)
Оптимальным решением будет использование облачных ресурсов по модели Pay as you go. Данный подход позволяет оплачивать исключительно фактически потребленные ресурсы, исключая расходы за «нагрев воздуха». При сохранении собственной инфраструктуры в качестве резервного контура, ее можно эффективно задействовать для размещения некритичных сервисов, песочниц, лабораторий и т. д., обеспечивая тем самым максимальное использование всех доступных ресурсов.

С точки зрения архитектуры и эксплуатации стоит учитывать несколько практических моментов:

• Использовать географически разнесенные кластеры, чтобы сбой в одном дата-центре не парализовал весь сервис.
• Подключать резервные ресурсы к реальному трафику, даже частично, чтобы они «не застывали» в простое.
• Настроить автоматическое распределение нагрузки между основным и резервным контуром с возможностью быстрого перераспределения при сбое.
• Регулярно проверять время переключения и нагрузку на резервные контуры в реальных сценариях, включая высокие пики и нестандартные нагрузки.

Такой подход позволяет построить инфраструктуру, которая реально готова к сбоям, минимизирует простой и экономит ресурсы, не снижая доступности критичных сервисов.

Вызовы микросервисов и распределенных данных: как восстанавливать консистентно

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

Особую сложность создают распределенные хранилища. Данные могут быть размазаны по разным кластерам и регионам, и в момент восстановления важно сохранить согласованность между ними. Даже небольшие расхождения в состоянии сервисов могут вызвать ошибки, потерю транзакций или некорректное поведение приложений.

Федор Маслов. Менеджер продукта UDV DATAPK Industrial Kit
Регулярная автоматизированная проверка возможности восстановления, соблюдение правила 3-2-1-1-0, а также верификация резервных копий и реплик машин на предмет целостности посредством механизмов СРК позволяют свести к нулю возможность возникновения таких ситуаций.

Для работы с этими вызовами существует ряд проверенных практик, которые помогают поддерживать консистентность и минимизировать риски:

• Idempotency — повторная обработка запроса не изменяет результат, что предотвращает дублирование данных.
• Distributed transactions — распределенные транзакции с гарантией атомарности для критичных операций.
• Versioning — хранение версий данных и схем, чтобы корректно обрабатывать откаты и изменения.
• Event sourcing — фиксация всех событий, которые изменяют состояние системы, для точного воспроизведения данных при восстановлении.

Использование этих практик позволяет построить систему, которая восстанавливается корректно даже при сложных сбоях, минимизирует риск неконсистентных данных и делает микросервисную архитектуру управляемой в плане Disaster Recovery.

Тестирование DRP: как проверять план, чтобы тесты отражали реальные сбои

Наличие DR-плана — это только половина дела. Настоящая проверка его эффективности начинается с тестирования. Многие компании ограничиваются формальными проверками или «проверкой на бумаге», но это не отражает реальных условий. Чтобы план сработал, нужно моделировать реальные сбои и оценивать, как система и команда реагируют на них.

Существует несколько основных типов DR-тестов: tabletop, partial failover и full failover. Tabletop — это «столовые» упражнения, где команда обсуждает сценарий сбоя и свои действия, без воздействия на продакшн. Partial failover включает переключение только части систем или сервисов на резервный контур, чтобы проверить готовность без полного отключения. Full failover — полное переключение всех сервисов на резерв, максимально приближенное к настоящему инциденту.

Федор Маслов. Менеджер продукта UDV DATAPK Industrial Kit
Конечно, при отработке катастрофичных сценариев, необходимо, в первую очередь, учитывать принципиальную возможность восстановления. При этом, ключевой метрикой всегда будет оставаться скорость восстановления обеспечивающих бизнес-процесс систем и сервисов, а также скорость возврата к исходному состоянию после восстановления ранее утерянных сервисов (failback).

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

Практические рекомендации для моделирования реальных инцидентов:

• Сетевые разрывы — отключение сегментов сети или имитация отказа маршрутизаторов.
• Потеря узла — выключение одного или нескольких серверов в кластере.
• Отказ хранилища — имитация сбоя СХД или блоков данных.
• Деградация производительности — нагрузочные тесты на узлах, чтобы увидеть, как система ведет себя при снижении ресурсов.

Только регулярные и реалистичные тесты позволяют убедиться, что DR-план не просто существует, а реально защищает бизнес от непредвиденных сбоев и помогает команде действовать быстро и слаженно в критических ситуациях.

Заключение

Не стоит относиться к Disaster Recovery, как к «страховке на бумаге». В современном бизнесе любая минута простоя — это не только финансовые потери, но и удар по репутации, доверию клиентов и внутренним процессам. Настоящая устойчивость бизнеса строится на продуманной, проверяемой и адаптивной DR-стратегии. Компании, которые действуют заранее, тестируют сценарии отказа и держат сервисы под контролем, получают уверенность в работе систем и минимизируют последствия любых катастроф.

г. Москва, 24 марта 2026 г.

Рабочая станция ГИГАНТ ГКС-777 успешно прошла испытания на совместимость с операционной системой Astra Linux Special Edition. По итогам тестирования оборудование получило официальный сертификат в рамках программы технологического партнерства Ready for Astra, подтверждающий корректную и стабильную работу аппаратной платформы под управлением отечественной ОС.

Испытания проводились совместно с разработчиком операционной системы - «Группой Астра». Тестирование выполнялось в соответствии с программой-методикой испытаний, разработанной специалистами Astra Linux, и было направлено на проверку полной функциональности оборудования при работе под управлением операционной системы. В ходе испытаний использовались версии Astra Linux Special Edition 1.7 и 1.8.3.UU1.

В качестве тестовой платформы применялась рабочая станция ГИГАНТ ГКС-777 на базе материнской платы ГКС-МП-777. Конфигурация также включала базовую систему ввода-вывода ГИГАНТ версии 3.

В рамках испытаний была проверена корректность загрузки операционной системы, работа оборудования в различных режимах BIOS, функционирование сетевых интерфейсов Ethernet и Wi-Fi, поддержка видеовыходов HDMI и DisplayPort, работа портов USB и аудиоподсистемы, а также стабильность функционирования интегрированного графического адаптера Intel UHD Graphics 770 и поддержка многомониторного режима. Отдельное внимание уделялось корректности работы драйверов и взаимодействию операционной системы с основными аппаратными компонентами платформы.

По результатам испытаний рабочая станция ГИГАНТ ГКС-777 продемонстрировала стабильную работу под управлением Astra Linux Special Edition. На актуальных версиях операционной системы подтверждена корректная работа ключевых аппаратных компонентов и интерфейсов, что позволило получить официальный сертификат совместимости.

«Подтверждение совместимости с Astra Linux - важный этап развития нашей линейки рабочих станций. Для заказчиков это означает, что оборудование ГИГАНТ ГКС-777 изначально готово к работе в инфраструктурах на базе отечественных операционных систем. Совместное тестирование позволяет заранее выявить возможные технические нюансы и обеспечить стабильную работу решения в реальных условиях эксплуатации», - отметил Яков Сотников, технический директор компании «ГИГАНТ Комплексные системы».

Программа технологического партнерства Ready for Astra объединяет разработчиков программного обеспечения и производителей оборудования для обеспечения корректной интеграции российских ИТ-решений. В рамках программы проводится тестирование аппаратных платформ, программных продуктов и инфраструктурных решений на совместимость с операционной системой Astra Linux.

«Развитие российского рынка рабочих станций требует не просто адаптации существующих решений, а создания технологических интеграций на глубоком уровне — от взаимодействия с BIOS до стабильной работы каждого аппаратного компонента под управлением отечественной ОС. Совместимость Astra Linux с рабочей станцией ГИГАНТ ГКС-777 демонстрирует, как российская операционная система может стать надёжной основой импортонезависимых решений в области высокопроизводительных рабочих мест. Программа Ready for Astra создана именно для того, чтобы заказчики получали не просто формальный сертификат, а реально проверенный технологический комплекс, готовый к эксплуатации в инфраструктурах с повышенными требованиями к безопасности и стабильности», — прокомментировал Михаил Геллерман, директор управления операционных систем «Группы Астра».

Подтверждение совместимости рабочей станции ГИГАНТ ГКС-777 с Astra Linux расширяет возможности применения решения в государственных организациях и коммерческих структурах, реализующих проекты по переходу на отечественное программное обеспечение. Использование сертифицированных аппаратно-программных сочетаний позволяет сократить сроки внедрения, снизить риски интеграции и обеспечить стабильную работу ИТ-инфраструктуры в соответствии с требованиями информационной безопасности.

Подробнее:

О компании «ГИГАНТ Комплексные системы»

Компания «ГИГАНТ Комплексные системы - ведущий российский разработчик и производитель клиентского оборудования и программных решений, выпускает моноблоки, мини-ПК и рабочие станции, которые включены в Реестр Минпромторга, а также могут легко адаптироваться под специфические требования. Качество сборки проходит контроль на каждом этапе - от входного контроля комплектующих до финального тестирования готового устройства. Все изделия полностью соответствуют требованиям Технических регламентов Таможенного союза (ТР ТС 004/2011, ТР ТС 020/2011) и прошли сертификацию для работы с российскими ОС, средствами защиты информации и офисными пакетами. Также компания «ГИГАНТ Комплексные системы» разработала собственную базовую систему ввода-вывода (BIOS) ГИГАНТ, которая внесена в реестр Минцифры РФ, что подтверждает высокий уровень контроля и безопасности.

О «Группе Астра»

«Группа Астра» — один из лидеров российского ИT-рынка, ведущий производитель инфраструктурного ПО. По данным рейтинга TAdviser, компания входит в топ-5 самых быстрорастущих компаний России. По версии Forbes, «Группа Астра» входит в топ-15 самых дорогих компаний Рунета. В экосистеме вендора свыше 35 продуктов и сервисов, которые комплексно закрывают потребности заказчиков в стеке инфраструктурного программного обеспечения: сертифицированная операционная система Astra Linux, система управления базами данных (СУБД) Tantor, средства резервного копирования и восстановления данных RuBackup, система управления корпоративной почтой RuPost, служба каталога ALD Pro, программное обеспечение для создания инфраструктуры виртуальных рабочих мест Termidesk и др. По оценкам независимых аналитиков Strategy Partners, в 2024 году «Группа Астра» стала безоговорочным лидером среди российских разработчиков: флагманский продукт — ОС Astra Linux — занимает 76% рынка российских операционных систем, а доля компании в сегменте отечественного инфраструктурного ПО оценивается в 21%.

UDV Group выпустила новую версию системы зонтичного мониторинга распределенных автоматизированных и информационных систем различного назначения, в том числе АСУ ТП UDV ITM 1.9.

Ключевая задача UDV ITM — давать полную информацию о ресурсах системы для оценки эксплуатационных характеристик и предупреждения возможных сбоев в работе. В качестве сервера мониторинга используется зарекомендовавшее себя на рынке решение на базе Zabbix. Решение особенно востребовано на крупных промышленных предприятиях.

Версия UDV ITM 1.9 направлена на повышение удобства и безопасности использования, стабильной работы с новыми версиями Zabbix и PostgeSQL, а также - расширение возможностей установки на ведущих российских операционных системах, таких как Astra Linux, РЕД ОС и Альт СП.

Ключевые обновления релиза:

• добавлена удобная сортировка и ранжирование объектов мониторинга по количеству проблем;
• ключевая информация о состоянии ИТ-услуг теперь отображается в интерфейсе (актуальный статус, история проблем и показатели SLA);
• реализован функционал контроля выполнения работ по ликвидации проблем, а также удобный просмотр и анализ списка проблем и формирование отчетов.

“Скорость выявления проблем и их устранения напрямую влияет на размер возможного ущерба от инцидента, поэтому в релизе UDV ITM 1.9 мы сконцентрировались на удобстве специалистов: на 80% сократили время на поиск проблемных узлов сети и в 2 раза уменьшили количество ручных операций по получению подробной информации о состоянии ИТ-сервисов.

Комплексный мониторинг ИТ-инфраструктуры, оборудования, приложений и сервисов - это фундамент кибербезопасности бизнеса, поэтому с каждым новым релизом мы улучшаем не только удобство, но и защищенность решения. В релизе UDV ITM 1.9 добавлена поддержка последних версий Zabbix и PostgeSQL для корректной и защищенной работы.” - прокомментировала новый релиз менеджер по развитию продукта UDV ITM Алена Макаревич.

Михаил Пырьев, менеджер продукта UDV NTA компании UDV Group

Видимость сети сегодня стремительно переходит из дополнительной меры контроля в обязательную практику информационной безопасности. Под видимостью понимается способность компании отслеживать, анализировать и контролировать реальные взаимодействия между устройствами, сервисами и сегментами инфраструктуры, опираясь на фактические сетевые данные, а не на разрозненные события и предположения.

Эта тема становится всё более критичной по двум причинам. Во-первых, корпоративные сети перестали быть статичными: компании используют облачные сервисы, выносят инфраструктуру подрядчикам, работают из распределенных офисов и через удалённый доступ. Во-вторых, злоумышленники действуют не только точнее, но и проще. Появление ИИ-помощников и языковых моделей существенно снизило технический порог входа. Сегодня значительная часть подготовки атаки — сбор информации, анализ инфраструктуры, подбор уязвимостей и формирование сценариев вторжения — может быть автоматизирована. Базы знаний атакующих постоянно пополняются, а генеративные модели позволяют формировать специализированные методы вторжения под конкретную инфраструктуру. По оценкам экспертов, до 80-90% этапов планирования и разведки уже выполняются с использованием таких инструментов.

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

Почему видимость сети сложно получить на практике

Одна из ключевых причин заключается в эволюции архитектуры сети. Большинство корпоративных инфраструктур развивались годами с приоритетом на поддержку бизнес-процессов, масштабирование сервисов и обеспечение непрерывности работы. По мере развития часть решений отклонялась от первоначальных проектных схем, появлялись новые сегменты, временные подключения становились постоянными, а отдельные элементы инфраструктуры выносились за пределы основного контура. В результате фактическая структура сети со временем начинает отличаться от документированной, что усложняет понимание реальной топологии и затрудняет определение точек мониторинга, способных дать целостную картину сетевых взаимодействий.

Эта проблема усиливается тем, что контроль сети часто выстраивается на уровне ядра, но не обеспечивает полноценной видимости внутри сегментов. Компания может видеть межсегментные потоки — какие группы устройств взаимодействуют между собой, — но при этом не иметь понимания того, что происходит внутри конкретного сегмента. В результате фиксируются агрегированные связи между зонами, но теряется контекст конкретных взаимодействий. Кроме того, даже при установке точек съема трафика на уровне ядра не всегда зеркалируется весь необходимый поток. Причина может быть в некорректной настройке зеркалирования, например, отметили не все vlan или подсети или установили оптические сплиттеры не на всех требуемых линиях из-за отсутствия актуальной маркировки кабельной инфраструктуры или понимания логики маршрутов сетевых потоков. В итоге аналитик получает не целостную картину, а частичную выборку трафика. События фиксируются, сигналы поступают, но связать их в единую цепочку невозможно: непонятно, как именно трафик проходил внутри сегмента, какие узлы участвовали во взаимодействии и где сформировалась ключевая точка развития активности.

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

Однако и в такой конфигурации задача не сводится к выбору правильных точек контроля. Даже при распределенном размещении сенсоров компания по-прежнему рискует видеть происходящее фрагментарно, Чтобы выйти за пределы отдельных событий и понять, как именно развивалась активность внутри инфраструктуры, требуется инструмент, способный объединять сетевые взаимодействия.

Инструменты, обеспечивающие связность сетевых событий

Эту задачу решают системы анализа сетевого трафика. Они не просто фиксируют отдельные события, а связывают разрозненные сетевые взаимодействия в единую последовательность и позволяют восстановить логику происходящего внутри инфраструктуры. Такой подход дает возможность перейти от самого факта инцидента к пониманию того, как он развивался и какие узлы в нем участвовали.

В основе этой связности лежит хранение детализированных сетевых взаимодействий. Система фиксирует не только сам факт соединения, но и его параметры: IP- и MAC-адреса, используемые протоколы и переданные команды, сегменты сети, роли узлов. За счет этого аналитик может вернуться к любому моменту во времени и восстановить маршрут атаки — понять, где началась активность, как она перемещалась между сегментами и какие системы оказались затронуты.

Второй важный механизм — это не просто сопоставление событий по времени, а их структурирование в независимые цепочки активности. Если система получает только отдельные события, их действительно можно выстроить в хронологию. Однако в реальной инфраструктуре в один и тот же момент времени одно устройство может взаимодействовать с десятками других. Поэтому ключевая задача — взять единый поток сетевых данных и разделить его на связанные сценарии, основываясь на сетевом контексте: адресах, ролях узлов, направлениях трафика, протоколах и характере взаимодействия. Только тогда можно понять, какие соединения относятся к одному сценарию активности, а какие — к другому. Именно такое «распараллеливание» временного потока позволяет отделить фоновую легитимную работу от потенциально вредоносной цепочки действий и увидеть развитие атаки как последовательность связанных шагов, а не как набор совпадающих по времени событий.

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

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

Почему наличие инструментов еще не гарантирует понимание сети

Даже когда в компании появляются инструменты анализа трафика, целостная картина складывается не автоматически. Все зависит от охвата и того, какие данные реально попадают в анализ. Если контроль ограничен внешним периметром, а внутренняя часть сети остается вне зоны видимости, то и результат будет частичным: видны отдельные эпизоды, но не видно, как активность развивалась внутри инфраструктуры.

Похожая проблема возникает, когда вместо полноценного анализа трафика используются только агрегированные данные телеметрии, такие как NetFlow или IPFIX. Такой статистики достаточно, чтобы увидеть направления сетевых соединений и объёмы переданных данных, но её недостаточно для понимания содержимого обмена и команд, переданных по протоколам. В результате фиксируется сам факт соединения и его параметры, но остаётся неясным, какие именно данные передавались, какие действия выполнялись и как развивалась активность внутри этого сеанса.

Дальше включается контекст. Если сетевые данные не связаны с информацией об активах и их владельце, аналитик вынужден работать с абстрактными адресами и вручную выяснять, что это за узел и насколько он критичен. Это увеличивает время реакции и повышает риск ошибочных решений.

И наконец, важны процессы. Если нет ответственного владельца, который превращает данные трафика в понимание происходящего, разные команды будут видеть разные фрагменты одной и той же сети. Как в известной притче о слепых мудрецах, каждый из которых ощупывает разную часть слона и делает собственный вывод о его природе, так и команды, «ощупывая» только свою часть сети, приходят к несовместимым представлениям об инфраструктуре. А без актуальной модели сети невозможно правильно выбрать точки контроля и приоритетные зоны — даже при наличии сильных инструментов.

Как выстраивать видимость сети на практике

Даже при сложной и фрагментированной инфраструктуре понимание того, что происходит в сети, можно выстраивать постепенно — главное, не пытаться «охватить все сразу». Первый шаг здесь — назначить владельца процесса. Пока ответственность размазана между ИТ, сетевой командой и ИБ, прозрачности не появится: решения будут стоять, данные будут собираться, но работать с ними будет некому. Это типовая ситуация, когда инструменты внедрены, а человека, который понимает, что именно нужно контролировать, где искать отклонения и как разбирать инциденты, просто нет. Поэтому видимость начинается не с технологий, а с конкретного владельца и его зоны ответственности.

Следующий шаг — обновить модель сети. На практике схемы устаревают очень быстро: появляются новые устройства, меняются маршруты, добавляются подрядчики, переносятся сервисы, а документация остается прежней. Поэтому перед настройкой мониторинга важно зафиксировать текущее состояние сети: какие сегменты действительно существуют, какие из них являются критичными, как устроены межсегментные связи и через какие точки осуществляется доступ — в том числе удаленный. Это не формальность и не бюрократия, а основа для того, чтобы не ошибиться с зонами контроля и не собирать данные «мимо» реальных процессов.

Дальше необходимо определить ключевые зоны, с которых имеет смысл начинать. С точки зрения практики и экономики первым шагом чаще всего становится ядро сети — именно там видно межсегментное взаимодействие и основные маршруты движения трафика. Это дает базовую картину: кто с кем общается, какие потоки существуют и как они распределяются по инфраструктуре. Следующий приоритет — серверный сегмент, поскольку именно здесь как правило расположены критичные сервисы, данные и системы, от доступности которых напрямую зависит бизнес. Отдельного внимания требует DMZ и все, что связано с внешними входами: точки удаленного доступа, шлюзы, узлы на стыке внутренних и внешних коммуникаций. Эти зоны требуют повышенного внимания, поскольку именно через них злоумышленники чаще всего переходят во внутреннюю инфраструктуру.

Когда ключевые зоны определены, подключаются технологии анализа трафика — не как «еще одна система», а как инструмент, позволяющий связать события между собой. Важно не просто фиксировать отдельные сигналы, а иметь возможность выстраивать цепочки действий, видеть последовательность взаимодействий и возвращаться к их истории. Для этого система должна уметь накапливать и сопоставлять метаданные и детали сетевых взаимодействий, а не ограничиваться временем и IP-адресами. Иначе снова получится мониторинг «точками», без понимания причин и последствий.

И только после того как сформировано базовое понимание структуры сети и логики межсегментных взаимодействий, имеет смысл расширять область контроля — в сторону пользовательского сегмента, коммутаторов доступа и отдельных площадок. Этот этап обычно идет последним, поскольку он самый объемный и затратный. Если начинать с него, легко утонуть в данных и так и не получить целостного понимания происходящего. Гораздо эффективнее выстраивать контроль поэтапно: начинать с ядра сети и критичных сегментов, а затем расширять покрытие там, где это действительно дает практический эффект.

Заключение: контроль начинается с видимости

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

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

Именно в этом их практическая ценность. Анализ трафика становится не инструментом «на всякий случай», а основой для осознанных решений: где необходимо немедленное вмешательство, а где дополнительных действий не требуется. В условиях распределенных сетей и целевых атак это уже не вопрос зрелости ИБ, а вопрос жизнеспособности бизнес-процессов в условиях постоянных атак.

Компания «ГИГАНТ Комплексные системы», производитель клиентского оборудования, и компания РЕД СОФТ, российский разработчик системного программного обеспечения, официально сообщают о полной совместимости своих технических решений. Платформа ГИГАНТ в совместимости с операционной системой РЕД ОС образует систему, подходящую для формирования современной информационной среды.

Специалистами компаний было проведено тестирование, подтвердившее стабильную работу портативного компьютера ГКС-727 под управлением операционной системы РЕД ОС. Тестирование охватило как базовые функции ввода-вывода, так и работу периферийных устройств.

Ключевое преимущество совместимости является использование BIOS ГИГАНТ, разработанной производителем оборудования и зарегистрированной в реестре Министерства цифрового развития, связи и массовых коммуникаций РФ. Это гарантирует высокую степень аппаратной совместимости и безопасную загрузку операционной системы, что важно для защиты информации.

Компьютер поддерживает оперативную память DDR5 объемом до 64 ГБ, что позволяет запускать ресурсоемкие приложения. Наличие современных интерфейсов, таких как USB Type-C, DisplayPort и HDMI, а также возможность установки двух накопителей PCIe 4.0 и 2.5" обеспечивает гибкость подключения и хранения данных.

Совместимость дает заказчикам готовую платформу, полностью соответствующую требованиям регуляторов и потребностям современного бизнеса.

Алексей Колодка, коммерческий директор компании «ГИГАНТ Компьютерные системы» рассказал об основных угрозах для безопасности баз данных, базовых уровнях защиты, о том, для чего нужен мониторинг и аудит, как защититься от внутренних угроз и о тенденциях в сфере безопасности баз данных в ближайшей перспективе.

—  Назовите наиболее критичные угрозы безопасности баз данных, которые актуальны сегодня?

Если говорить о критичных угрозах для безопасности баз данных, то в первую очередь их корректно разделить на две большие категории — внешние и внутренние. В каждой из них есть свои повторяющиеся и наиболее опасные сценарии.

С точки зрения внешних угроз сегодня наиболее актуальны кибератаки на базы данных. Это самый распространенный вектор атак за последние годы. В первую очередь стоит выделить SQL-инъекции — они по-прежнему активно используются злоумышленниками для получения несанкционированного доступа к данным. Также крайне существенной угрозой остаются DDoS-атаки. Их количество ежегодно растет с высокой динамикой, и все чаще объектом воздействия становится не только сетевая инфраструктура в целом, но и сами базы данных, что напрямую влияет на доступность сервисов и устойчивость бизнеса.

Если говорить о внутренних угрозах, то основным источником риска остается человек — сотрудник организации. Именно человеческий фактор является ключевой угрозой для безопасности баз данных. Внутри этой категории можно выделить отдельные подвиды рисков. Прежде всего это злоупотребление привилегиями, когда сотрудник обладает избыточными или неограниченными правами доступа к базам данных. Такая ситуация может привести к утечке информации — как по умышленным причинам, так и по неосторожности. В ряде случаев это перерастает в промышленный шпионаж, когда коммерческая тайна и чувствительные данные могут быть выведены за пределы компании. Основной проблемой здесь является отсутствие должного контроля со стороны IT-блока и подразделений информационной безопасности за действиями привилегированных пользователей.

— Какие современные методы шифрования и управления ключами вы рекомендуете для критически важных баз данных, и в каких случаях шифрование может создавать дополнительные риски?

При обсуждении шифрования данных в СУБД важно понимать, что защита инфраструктуры и баз данных должна выстраиваться комплексно. В первую очередь можно выделить три базовых уровня защиты.

Первый уровень — физическая безопасность. Речь идет о защите серверов и оборудования, организации закрытого периметра и контроле физического доступа.

Второй уровень — контроль доступа. Необходимо четко понимать, каким сотрудникам и в каком объеме предоставляются права к базам данных, и постоянно контролировать этот процесс, чтобы минимизировать риски утечек.

И третьим, ключевым элементом защиты является шифрование данных. На сегодняшний день это один из основных методов обеспечения безопасности баз данных.

Существует несколько подходов к шифрованию, каждый из которых имеет свои плюсы и минусы. Симметричное шифрование предполагает использование одного ключа как для шифрования, так и для расшифровки данных. Этот метод отличается высокой скоростью работы и минимальной нагрузкой на систему, что делает его привлекательным с точки зрения производительности. Однако его критическим недостатком является необходимость безопасной передачи и хранения ключа. В случае компрометации ключа злоумышленник получает полный доступ ко всем зашифрованным данным.

Асимметричное шифрование использует два ключа — один для шифрования и другой для дешифрования. Даже если злоумышленник получает доступ к ключу шифрования, без ключа дешифрования он не сможет работать с данными. С точки зрения безопасности этот метод выглядит более устойчивым, однако его серьезным недостатком является снижение производительности и высокая нагрузка на вычислительные ресурсы.

На практике все чаще применяются гибридные схемы шифрования, которые сочетают оба подхода. Это позволяет найти баланс между скоростью обработки данных и уровнем безопасности, что особенно актуально при работе с большими объемами информации.

Также важно учитывать, на каком уровне реализуется шифрование. Современные СУБД поддерживают встроенные механизмы шифрования на уровне базы данных, при которых доступ к данным возможен только после корректной аутентификации. Альтернативой является шифрование на уровне приложений. Его преимущество — полный контроль над процессом и возможность использования любых криптографических алгоритмов, однако такой подход может существенно снизить производительность системы.

Отдельно стоит отметить прозрачное шифрование данных. Оно удобно в эксплуатации и относительно просто внедряется, но требует значительных вычислительных ресурсов и грамотного управления ключами.

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

— Как правильно организовать мониторинг и аудит базы данных, чтобы своевременно обнаруживать подозрительную активность и избежать информационного шума?

Для начала важно понять, зачем вообще нужны мониторинг и аудит баз данных. База данных — это динамическая сущность, которая постоянно изменяется и требует контроля как с точки зрения производительности, так и с точки зрения безопасности. Мониторинг и аудит позволяют обеспечить надежность, устойчивость и защищенность информационной системы.

Цель мониторинга — поддержание работоспособности базы данных, выявление нештатных ситуаций и сбор статистики.
 Цель аудита — оценка состояния базы данных с точки зрения уязвимостей, корректности настроек доступа и соблюдения требований информационной безопасности.

Оба процесса строятся по схожей логике и включают несколько этапов.
 На этапе подготовки определяются цели мониторинга или аудита, изучается документация и архитектура базы данных. Далее осуществляется сбор данных о текущем состоянии системы. После этого проводится анализ полученной информации и формируются нормативные требования. Следующий этап — подготовка отчетов, отражающих текущее состояние и выявленные отклонения. Завершающим шагом становятся рекомендации по устранению проблем.

В современных условиях невозможно эффективно реализовать эти процессы без автоматизации. Для задач аудита целесообразно использовать решения класса DAM и DBF, которые в автоматическом режиме отслеживают доступ к базам данных, фиксируют подозрительную активность и позволяют оперативно ее купировать без создания лишнего информационного шума.

Мониторинг также должен быть максимально автоматизирован, чтобы не тратить ресурсы сотрудников и использовать вычислительные возможности инфраструктуры для оперативного выявления проблем и обеспечения стабильной работы пользователей.

—  Как эффективно защититься от внутренних угроз при работе с базами данных?

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

Поскольку основной источник внутренних угроз — это пользователь, обладающий избыточными правами, принцип минимально необходимого доступа должен соблюдаться максимально строго. Контроль и регулярный пересмотр прав доступа позволяют существенно снизить риск утечек.

Неотъемлемой мерой является шифрование данных, которое снижает вероятность несанкционированного распространения информации даже при ошибках сотрудников. Важную роль играет журналирование всех действий пользователей и их постоянный анализ, что позволяет оперативно выявлять аномальное поведение и ограничивать доступ до наступления инцидента.

Также необходимо обеспечивать физическую безопасность инфраструктуры, регулярно обновлять системы, использовать сложные пароли и обеспечивать их своевременную смену. Это снижает риски, связанные с вредоносным программным обеспечением и компрометацией учетных данных.

Дополнительно рекомендуется максимально ограничивать использование внешних носителей и внешних источников доступа без регламентации. Это помогает защитить внутренний контур и предотвратить проникновение вредоносного кода извне.

—  Какие тенденции в области безопасности баз данных вы видите в ближайшие годы?

Основные тенденции, наблюдавшиеся в прошлом году, сохранятся и в ближайшей перспективе. В первую очередь будет продолжаться усиление мер информационной безопасности, так как киберугрозы становятся все более значимыми и напрямую влияют на устойчивость бизнеса и инфраструктуры.

Вторая ключевая тенденция — развитие автоматизации и мониторинга баз данных. Рост объемов данных и требований со стороны бизнеса приводит к увеличению нагрузки на инфраструктуру и росту затрат на вычислительные ресурсы. Чтобы оптимизировать расходы и не увеличивать бюджет на инфраструктуру, компании все чаще внедряют автоматизированные решения, которые позволяют оптимизировать работу баз данных, выполнять резервное копирование и повышать эффективность использования ресурсов.

Именно сочетание усиленной кибербезопасности и глубокой автоматизации сегодня формирует основные направления развития защиты баз данных.

Троянские программы уже не те «старые знакомые» из старых плейбуков по кибербезопасности. Сегодня это гибкие, модульные и часто автономные инструменты, которые умеют маскироваться под легитимный трафик, встраиваться в цепочки поставок и незаметно жить в инфраструктуре месяцами. Cyber Media разбирает, почему современные трояны стали опаснее, чем когда-либо, и как они трансформировали цифровую преступность.

Что такое современные трояны и почему они не похожи на классические

Раньше троян ассоциировался с чем-то простым — файлом, который тихо подбрасывал в систему вредоносный модуль. Сегодня же это полноценная многоуровневая платформа. По сути, «классический троян» умер, а вместо него появились гибридные инструменты, которые одновременно и дропперы, и бэкдоры, и мини-центры управления.

Олег Скулкин. Руководитель BI.ZONE Threat Intelligence
В 2025 году мы не фиксируем принципиально новых методов маскировки, а наблюдаем лишь развитие уже известных подходов. Злоумышленники по-прежнему маскируют вредоносные файлы под различные документы, используют соответствующие иконки и такие приемы, как двойные расширения, например, .pdf.exe. Все также применяются техники DLL hijacking (замена легитимного DLL-файла на вредоносную библиотеку), включая DLL side-loading (распространение вредоносной библиотеки DLL вместе с легитимным приложением, которое ее выполняет). Продолжается эксплуатация 0-day-уязвимостей в популярных инструментах — например, в кампании группировки Paper Werewolf использовалась уязвимость CVE-2025-8088.

Современные трояны не стремятся быстро заразить и разрушить — наоборот, им крайне важно остаться незамеченными. Это уже не одиночный файл, а экосистема модулей, которая подтягивает нужный функционал по мере развития атаки. В начале — минимальный набор для выживания и первичного доступа, потом — тихие обновления, добавление инструментов для разведки, фиксации в системе, скрытого взаимодействия с командным сервером.

При этом все это упаковано так, чтобы не «шуметь»: подмена процессов, работа через легитимные API, маскировка трафика под облачные сервисы — стандартная практика. А еще многие трояны стали «леденяще терпеливыми»: они могут неделями ничего не делать, пока не появится нужный триггер или команда снаружи.

Олег Скулкин. Руководитель BI.ZONE Threat Intelligence
Злоумышленники активно применяют polyglot-файлы, которые по-разному интерпретируются различными программами. Такой тип файлов использовал кластер Rainbow Hyena. Кроме того, не теряет актуальности применение стеганографии. Один из свежих примеров — фишинговая кампания Lone Wolf, где вредоносная нагрузка незаметно размещалась внутри изображения, а ярлык запускал цепочку действий, извлекающую и активирующую спрятанный загрузчик. Такой подход позволяет злоумышленникам передавать вредоносные компоненты в виде визуально безвредных файлов и обходить первичные механизмы анализа.

Именно поэтому сегодня троян — это не просто вредонос, а тихий оператор на стороне злоумышленника. А значит, и обнаруживать его приходится не по очевидным артефактам, а по микропаттернам поведения, которые сложно заметить без зрелого мониторинга.

Главные векторы проникновения: от фишинга до атак на ИТ-подрядчиков

Трояны не «взламывают дверь», они спокойно заходят через те же входы, которыми пользуются сотрудники. И если раньше основным способом заражения был массовый фишинг, то теперь злоумышленники действуют точнее, аккуратнее и куда изобретательнее.

Социальная инженерия и таргетированный фишинг все еще остаются королями проникновения. Только подход изменился: вместо сомнительных писем «от банка» приходят идеально вылизанные сообщения от имени внутреннего сервис-деска, подрядчика или реального сотрудника. Троян маскируется под документ, обновление или полезную утилиту — и попадает на рабочую станцию буквально в один клик. Чем более персональным выглядит письмо, тем выше шанс, что цель ничего не заподозрит.

Не менее популярный путь — компрометация сайтов и «drive-by» загрузки. Здесь жертве даже не нужно ничего скачивать: достаточно зайти на зараженный ресурс, чтобы браузер получил вредоносный скрипт или загрузчик. Внешне все выглядит как нормальный рабочий процесс, а в фоне уже разворачивается первый модуль трояна.

Семен Рогачев. Руководитель отдела реагирования на инциденты Бастион
Признак использования Living-off-the-Land тактик — запуск инструментов, являющихся частью ОС, так называемых LOLBAS или GTFOBins, для реализации действий атакующими. Чаще всего они используются для выполнения кода и скачивания полезной нагрузки.
Основные признаки использования подобных тактик — аномальные аргументы командной строки, передаваемые компонентам операционной системы. Например, в случае, если атакующий использует PowerShell, высока вероятность, что вредоносный сценарий будет содержать в себе Base64-кодирование или команды -ExecutionPolicy Bypass, -EncodedCommand, IEX и их аналоги. При использовании Living-off-the-Land тактик может использоваться несколько LOLBAS, поэтому аномальные цепочки процессов, например, Word, запускающий mshta, который, в свою очередь, порождает процесс PowerShell, также могут являться признаком использования Living-off-the-Land тактик.

Самый неприятный вектор — supply chain-атаки. ИБ-специалисты их особенно не любят, потому что здесь практически нечего «предъявить» сотруднику: он устанавливает обновление от легитимного поставщика, а вместе с ним — аккуратно встроенный троянский компонент. Поставщика могут взломать, подменить пакеты или внедрить вредоносный код в цепочку сборки. Компания получает вредонос «с доверенным сертификатом», а обнаружить подмену можно только через детальный анализ поведения и контроль целостности.

В итоге современные трояны редко «проламывают защиту лбом». Им гораздо удобнее маскироваться под работу, рутину или привычные действия. И именно это делает их попадание в инфраструктуру таким опасным — заражение выглядит как обычный рабочий день.

Как трояны маскируются: обход EDR, живучесть, персистентность

Современные трояны это минимум шума, максимум контроля над собственной «невидимостью». Их цель — не прорваться, а раствориться в инфраструктуре так, чтобы их было невозможно отличить от нормальной системной активности.

Один из ключевых приемов — маскировка сетевой коммуникации. Вредоносные модули прячут трафик за популярными облачными сервисами, используют системные API и даже вписывают свои пакеты в легитимный бизнес-трафик. Некоторые идут дальше и используют стеганографию: команды передаются внутри изображений, аудио или других медиафайлов, которые выглядят абсолютно безобидно.

Чтобы оставаться как можно менее заметными, трояны работают по принципу «low and slow»: никаких всплесков активности, только постепенные, тщательно дозированные операции. Плюс к этому многие семейства обзавелись автономным режимом — им не требуется постоянная связь с C2-сервером, что значительно уменьшает сетевой шум.

Кирилл Левкин. Проджект менеджер MD Audit (ГК Softline)
Основные механизмы контроля — это в первую очередь строгая проверка целостности артефактов (SBOM, контроль хэшей, сравнение версий), мониторинг изменений в репозиториях и автоматизированный анализ зависимости на предмет появления новых подозрительных библиотек. Важную роль играет контроль сборочных сред: воспроизводимые сборки, разделение сред разработки и продакшена, мониторинг действий сервисных аккаунтов. Аномалии в последовательности CI/CD-процессов, появление новых pipeline-шагов или неожиданные скрипты в образах контейнеров — типичный сигнал о компрометации. В крупных компаниях работает модель Zero Trust для всех элементов цепочки DevOps.

При этом авторы уделяют особое внимание защите от анализа. Вот лишь часть техник, которые встречаются сегодня:

• Антипесочница. Троян запускается только при определенных условиях среды, проверяет тайминги, загрузку системы, наличие виртуализации.
• Антиотладка. Отслеживание breakpoint’ов, проверка дебаггеров, переключение в иной код-путь при попытке анализа.
• Антифорензика. Удаление временных файлов, подмена артефактов, шифрование или перезапись собственных модулей.

Такая комбинация делает современные трояны не просто скрытными, а живучими. Они умеют существовать в инфраструктуре месяцами, подстраиваясь под рабочие процессы и маскируясь под легитимные службы. И именно поэтому их поиск все чаще становится охотой на поведенческие аномалии, а не на традиционные сигнатуры.

Почему инцидент с трояном часто замечают слишком поздно

Главная проблема современных троянов — не в том, что они мощные, а в том, что они встроены в логическую последовательность атаки и отлично умеют подстраиваться под нормальную работу инфраструктуры. Поэтому момент заражения редко выглядит как событие, на которое хочется немедленно реагировать.

Во многих случаях троян используется как инструмент подготовки, а не финального удара. Он собирает служебную информацию, проверяет конфигурации, анализирует доступность критичных узлов — все это выглядит как обычная активность рабочей станции или сервера. Отдельно ни одно действие не вызывает подозрений, но в совокупности оно позволяет злоумышленнику понять, куда двигаться дальше.

Алексей Варлаханов. Руководитель отдела прикладных систем Angara Security
Чаще всего остаются незамеченными при стандартном мониторинге следующие встроенные модули современных троянов:

• Кейлоггеры, криптоджекинговые модули (скрытая майнинг-деятельность), а также браузерные и криптостилеры, которые работают внутри легитимных процессов.
• Модули обхода двухфакторной аутентификации и сбора учетных данных, интегрированные как часть системных служб.
• Отложено загружающиеся дропперы и RAT-модули, которые проявляют себя только при специфических условиях и часто скрываются от стандартных средств мониторинга.

Далее начинается движение по инфраструктуре — но не агрессивное, а основанное на наблюдении и возможностях среды. Троян может использовать доступы, которые уже есть у пользователя, проверять соседние узлы осторожными, редко повторяющимися запросами, постепенно накапливать необходимые привилегии. Для системы мониторинга это напоминает поведение администратора, который «ходит» по сети, а не попытку прямого взлома.

Параллельно выполняется и еще одна важная задача — формирование базы разведданных для будущих действий. Это может быть:

• сбор токенов и ключей доступа;
• выгрузка конфигураций сервисов;
• изучение сервисных учеток;
• поиск систем, где проще всего закрепиться.

Проблема в том, что такой трафик и такие операции обычно разбросаны по времени. Они выглядят как фон, а не как инцидент. SOC видит сотни похожих действий каждый день, и вредонос прячется именно среди них.

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

Как защититься: практические рекомендации для ИБ-команды

Защита от современных троянов — это не про установку «еще одного агента». Противодействие должно быть системным и строиться на реальном поведении инфраструктуры.

Первый шаг — жесткий контроль привилегий и сегментация. Чем меньше прав у стартовой точки заражения, тем меньше у трояна возможностей для lateral movement. Ограниченные роли, временные токены, отдельные зоны для сервисных систем — технически сужают маршрут злоумышленника.

Вторая опора — полноценное логирование и корреляция событий. Важно видеть не отдельные логи, а цепочки: что происходило до и после, какие паттерны повторяются, где поведение пользователя отклоняется от нормы. Троян оставляет мелкие следы — задача мониторинга собрать их в картину.

Третий элемент — анализ поведения. Сигнатуры и IOC остаются вспомогательными. Реально работают поведенческая телеметрия, профилирование рабочих станций и выявление аномалий в активности сервисов. Троян может маскироваться под системный процесс, но редко умеет точно копировать естественные паттерны работы.

Михаил Пырьев. Менеджер продукта UDV NTA

Надежными индикаторами работы C2‑инфраструктуры троянов являются:

• Использование туннелирования DNS. Достаточно старый, но популярный способ эксплуатации уязвимости логики протокола. Опытным взглядом возможно заметить частые запросы к доменам с динамической генерацией имен (DGA), либо использование редких доменов верхнего уровня (TLD), но для выявления сложных паттернов потребуется аналитика с использованием механизмов машинного обучения.
• Периодические TLS‑сессии с малым объемом данных. Регулярные подключения к одному и тому же внешнему IP или домену с минимальной передачей данных, например, 100—300 байт, может быть характерным признаком beaconing‑поведения трояна.
• Скрытые каналы в HTTP/HTTPS трафике. Использование нестандартных HTTP‑заголовков, кодирования в URI или теле запроса, например, base64‑команды в параметрах GET/POST, могут свидетельствовать о скрытой передаче данных на C2-сервера.

Использование современных технологий анализа сетевого трафика поможет своевременно выявить и локализовать активность трояна в инфраструктуре, а также убедиться в отсутствии распространения угрозы.

И наконец, зона, которая долго казалась «чужой» для ИБ, но теперь стала критичной, — поставщики и подрядчики. Supply chain-атаки не редкость, поэтому в чек-лист защиты теперь входит аудит обновлений, контроль целостности, проверка источников пакетов, политика использования стороннего ПО. Иногда самый опасный троян попадает не через сотрудника, а через «официальное» обновление от давно знакомого вендора.

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

Куда развивается ландшафт троянских программ

В ближайшие годы трояны будут становиться еще более автономными и «самодостаточными». Уже сейчас появляются вредоносные модули с элементами ИИ, которые могут самостоятельно выбирать цели внутри сети, подбирать оптимальные техники скрытности и адаптироваться к защитным мерам без постоянных команд от оператора.

Параллельно усиливается связка троянов с руткитами и ботнет-архитектурами. Это превращает зараженные машины не просто в точки доступа, а в устойчивые, глубоко спрятанные элементы инфраструктуры злоумышленника — почти мини-узлы управления в корпоративной сети.

Если смотреть вперед, то в 2026—2027 годах будут наблюдаться два тренда:

• появление гибридных троянов, которые могут переключаться между ролями (разведка, персистентность, управление, прокси) в зависимости от ситуации;
• усиление атак на цепочки поставок, где вредонос внедряется в процесс сборки или доставки обновлений и выглядит как часть обычного релиза.

Трояны становятся не инструментом атаки — а платформой. И именно в этом их главная угроза будущего.

Заключение

Современные трояны — это не про «страшные истории», а про зрелую дисциплину защиты. Они показывают, насколько уязвимы привычные процессы: обновления, доступы, взаимодействие с подрядчиками, фоновые сервисы. И именно поэтому фокус смещается с охоты за отдельными образцами вредоносного ПО на управление рисками в инфраструктуре: контроль окружения, прозрачность событий, проверенные поставщики и архитектура, которая не дает вредоносу свободы действий.

Трояны меняются, но и ИБ-команды сегодня куда лучше вооружены: есть инструменты, телеметрия и практики, которые позволяют ловить даже очень скрытные вещи. Главное — использовать их не ради «галочки», а как часть постоянной, живой работы по укреплению безопасности.

Backdoor-механизмы сегодня это тонкие, адаптивные скрытые входы, которые могут прятаться в облачных сервисах, CI/CD-процессах и даже в штатных инструментах ОС. Cyber Media разбирает, как эволюционируют бэкдоры, какие техники используют злоумышленники и почему их обнаружение становится все сложнее.

Что такое backdoor

Backdoor — это не магический портал в систему, а вполне приземленный технический «черновой» вход, который позволяет обойти проверки, аутентификацию и логирование. По сути, это скрытая дверца, о существовании которой знает только тот, кто ее установил. Причем дверца может быть где угодно: в бинаре, конфиге, микросервисе, образе контейнера или даже в процессе разработки, спрятанная в виде «вспомогательного скрипта сборки».

Для злоумышленника бэкдор — это страховка. Он может потерять фишинговый доступ, его веб-шелл могут удалить, учетку — заблокировать. Но если где-то в инфраструктуре осталась малозаметная закладка, то злоумышленник все равно вернется.

Почему бэкдоры становятся более специализированными и модульными? Потому что универсальные инструменты давно перестали работать. Современные системы логирования ловят аномальные процессы, EDR умеет анализировать поведение, а DevSecOps-пайплайны стали куда жестче к «левой» активности. Поэтому злоумышленники переходят к минималистичным, почти хирургическим бэкдорам: один выполняет только команду запуска нужного процесса, другой отвечает за связь с C2, третий — маскируется под сервис мониторинга. Вместе они создают модульную экосистему, которую сложно заметить и еще сложнее собрать в единую картину угрозы.

Такие бэкдоры не шумят, не светятся и обычно живут в тех местах, куда аналитики смотрят в последнюю очередь — в CI, в крошечных вспомогательных контейнерах или в давно забытых крон-триггерах. И именно это делает их такими опасными.

Классические и современные типы бэкдоров

Когда-то все было просто: бэкдор — это отдельный файл, спрятанный в системе. Скомпилированный бинарь в /tmp, подозрительный PHP-скрипт в каталоге веб-сервера, измененный SSH-дев — классика жанра. Их находили так же просто: антивирус ругался на сигнатуру, SOC замечал подозрительный хэш, а администратор — странный файл, которого «точно не было вчера».

Но времена файловых закладок уходят, как и романтика поиска «того самого» исполняемого файла. Технические команды стали создавать многоступенчатые журналы, EDR научился видеть лишние процессы, а контейнеризация убрала часть старых укрытий. И злоумышленники адаптировались.

Дмитрий Калинин, руководитель департамента по работе с уязвимостями и инцидентами ИБ Бастион.
Наиболее опасными признаны аппаратные бэкдоры, которые вшиваются в BIOS|UEFI или прошивки какого-либо оборудования. Их практически невозможно обнаружить, они не оставляют в логах никаких следов. Опасность таких бэкдоров в том, что они могут доставляться по схеме Supply Chain, т. е. при атаке на поставщика. На втором месте по опасности и незаметности стоит отметить бэкдоры, встраиваемые в компоненты системы. Не так давно появилась информация о таком бэкдоре для системы Linux — Plague, который маскируется под легитимный модуль PAM, отвечающий за аутентификацию пользователей. В результате Plague позволяет обходить системную аутентификацию, а также перехватывать логины и пароли пользователей.

Сегодня бэкдор — это уже не обязательно файл. Он может быть «распылен» по системе в виде конфигурации, триггера или цепочки системных механизмов. Типичные примеры новой архитектуры:

• Fileless-механики, которые живут в PowerShell, WMI, cron или systemd-юнитах.
• Маскировка под сервисы, когда закладка выглядит как обычный health-check или мониторинговый агент.
• Инъекция в доверенные процессы, чтобы выглядеть как часть самой системы.
• Зависимость или артефакт CI/CD, попадающий в прод через цепочку сборки.

Современный бэкдор мало похож на классический «подкинутый файл». Он не требует места на диске, может пережить перезапуск, умеет прятаться в системных инструментах и почти не оставляет следов.

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

Маскировка под легитимность: облака, микросервисы и API

Современные бэкдоры больше не прячутся в тени — они прикидываются частью нормальной инфраструктуры. И делают это так правдоподобно, что на них легко махнуть рукой: «да это же что-то из DevOps оставили». Злоумышленники отлично понимают, что облака и микросервисы перегружены легитимным шумом, и именно этот шум стал идеальной средой для сокрытия закладок.

Как злоумышленники используют популярные облачные платформы

Облачные провайдеры давно превратились в универсальную транспортную прослойку. Злоумышленники пользуются этим не хуже инженеров:

• запускают командные серверы в serverless-функциях, которые выглядят как обычные обработчики событий;
• прячут C2-трафик за CloudFront / CDN, маскируя его под доставку статического контента;
• используют обычные storage-бакеты как каналы обмена командами — «положи файл, забери команду»;
• маскируют управление доступом под IAM-ролями, созданными «для тестирования» или «для мониторинга».

Снаружи все выглядит вполне легитимно: сервисы как сервисы, API как API. И только внимательный анализ активности показывает, что некоторые вызовы ведут не к бизнес-логике, а к скрытому управляющему каналу.

Имитация микросервисной коммуникации, ложные health-checkи и подмена метрик

Микросервисная инфраструктура работает как большой муравейник: миллионы запросов, постоянная синхронизация, сервисы проверяют друг друга на живость. В такой среде спрятать бэкдор — почти искусство.

Олег Скулкин, руководитель BI.ZONE Threat Intelligence
Нередко киберпреступники маскируют свое вредоносное ПО под вполне легитимные исполняемые файлы. В частности, они могут выдавать вредоносный компонент за официальный бинарный файл облачного сервиса. Например, кластер Core Werewolf называл вредоносные файлы как OneDrive.exe и использовал такую же иконку приложения. Кроме того, атакующие активно используют облачные платформы для доставки вредоносных программ, хранения похищенной информации и организации каналов управления. Так, кластер Fair Werewolf применял в ВПО для связи с управляющими серверами такие сервисы, как Yandex Cloud, Microsoft Graph и Dropbox. Что касается микросервисов, то встречались случаи, когда вредоносные компоненты закреплялись внутри Docker-контейнеров, что усложняло их обнаружение.

Самые популярные техники:

• Имитация service-to-service вызовов.Закладка общается с C2 так же, как микросервисы между собой — через внутренний API-шлюз или service mesh. На графах это выглядит как еще один «малозаметный» сервис.
• Фальшивые health-checkи.Бэкдор отправляет регулярные проверки состояния, которые никто не анализирует вручную. На самом деле эти проверки включают команды или передают данные.
• Подмена метрик и логов.Закладка пишет в Prometheus или ELK как «обычный компонент», но часть метрик используется как скрытый канал. Например, увеличение «времени отклика» может быть сигналом C2.

В результате закладка превращается в естественный элемент инфраструктуры. Она выглядит как сервис мониторинга, вспомогательный API или компонент оркестрации — ничто не выдает ее до тех пор, пока кто-то не начнет смотреть вглубь очень неудобных аномалий.

Современная маскировка — это не про прятки. Это про умелую имитацию жизни внутри архитектуры, которая сама по себе уже хаотична. И именно благодаря этому такие бэкдоры живут дольше всех.

Supply chain и CI/CD: внедрение бэкдоров на этапе разработки

Атаки на цепочки поставок стали способом проникновения еще до того, как продукт вообще попадет в прод. Вместо того чтобы ломиться через периметр, злоумышленники заходят в самое сердце разработки — в зависимости, скрипты сборки, артефактные репозитории и автоматические обновления. CI/CD дает им идеальную среду: все, что прошло через пайплайн, автоматически считается «чистым». Этим и пользуются.

Олег Скулкин, руководитель BI.ZONE Threat Intelligence
Вредоносный код особенно легко внедрить на этапах, связанных с зависимостями, автоматизацией сборки и подготовкой программного решения, поскольку именно там разработчики часто полагаются на доверенные процессы и внешние источники. Подмененная библиотека или пакет может незаметно попасть в проект при обновлении зависимостей, например, NPM или PyPI.

Аналогично компрометация CI/CD-пайплайна позволяет злоумышленнику встроить вредоносный код прямо в процесс сборки. Отдельная зона риска — подготовка контейнерных образов: изменения в базовом образе или на стадии build могут распространиться на все последующие версии продукта.

В итоге формируется атака на цепочку поставок, которую довольно сложно обнаружить, когда проект уже собран и готов к поставке клиентам. На этапе написания кода риски ниже благодаря ревью и статическому анализу, однако недостаточный контроль зависимостей остается серьезной проблемой.

Опасность этих техник в том, что они полностью проходят под флагом доверия: билд успешен, хэши совпадают, артефакты подписаны. Снаружи все выглядит как «еще один релиз». А внутри уже живет бэкдор, доставленный самой же системой, которую должны были защищать.

Fileless-бэкдоры: когда искать нечего

Безфайловые бэкдоры — это та категория угроз, которая вызывает у аналитиков особое раздражение. С ними буквально нечего искать: ни бинарей, ни подозрительных скриптов, ни артефактов на диске. Все живет в оперативной памяти или в штатных механизмах системы, которые и так работают 24/7. Такие закладки похожи на арендатора, который использует вашу мебель, вашу посуду и ваши ключи — и поэтому остается практически невидимым.

Злоумышленники давно поняли, что проще не добавлять что-то свое, а переиспользовать то, что уже встроено в систему. Поэтому в ход идут PowerShell, WMI, планировщики задач, системные демоны и любые средства автоматизации, которые принято считать «нормальными» и не требующими лишнего внимания.

Ольга Луценко, консультант по информационной безопасности UDV Group
Основной метод поиска таких бэкдоров — поведенческий анализ и поиск аномалий, поскольку сигнатурные способы в данном случае неэффективны:

• Мониторинг цепочек выполнения процессов. Осуществляется с использованием EDR-систем. Ключевые индикаторы: запуск powershell.exe или cscript.exe из офисных приложений или почтовых клиентов; использование системных утилит для сетевой активности.
• Анализ сетевой активности. Необходимо выявлять аномальные соединения для легитимных процессов. Например, установка внешних соединений служебными процессами вроде svchost.exe или msdtc.exe. Для полного анализа требуется инспектирование TLS-трафика для верификации содержимого соединений с внешними сервисами.
• Контроль целостности конфигурации. Регулярный мониторинг изменений в областях персистентности: задачи Планировщика, службы Windows, подписки WMI, автозагрузка. Любые изменения должны сверяться с эталонными конфигурациями.

Постоянство обеспечивается через те же легитимные механизмы: автостарт сервисов, задания планировщика, обновляющиеся конфиги или даже встроенные политики. По журналам такая активность выглядит как штатная работа системы, а EDR часто видит лишь «нормальный» системный процесс, который делает «нормальные» вещи — только в нужный момент он выполняет команду, которой там быть не должно.

Fileless-бэкдоры опасны именно своей естественностью. Они не похожи на внедренный объект — они выглядят как часть операционки. И если классические бэкдоры можно поймать хэшами или сканерами, то здесь охотнику приходится искать не файловую аномалию, а поведенческую — ту самую крошечную деталь, которая не вписывается в ритм системы.

Вторичные и «резервные» бэкдоры: план B злоумышленника

Хороший атакующий никогда не полагается на один бэкдор. Он всегда оставляет запасной маршрут — редко используемый, но готовый включиться в тот момент, когда основной канал найдут и отключат. Это не просто подстраховка, а целая философия устойчивости доступа: «даже если все сгорит, я все равно смогу вернуться».

Такие резервные механизмы обычно устроены так, чтобы полностью раствориться в инфраструктуре и не подавать признаков жизни. Они не общаются с C2 постоянно, не держат сетевые соединения и не делают ничего, что могло бы вызвать тревогу SOC. Работают они только по сигналу — или по заранее предусмотренному условию, которое почти невозможно заметить без глубокого поведенческого анализа.

Ольга Луценко, консультант по информационной безопасности UDV Group
Речь идет о механизмах обеспечения персистентности. Они крайне разнообразны и часто остаются нетронутыми после первичного реагирования:

• Дополнительные учетные данные. Злоумышленник заранее создает резервные наборы учетных данных (логины/пароли, сертификаты, API-ключи) и размещает их в различных частях системы. Обнаружение и удаление одного бэкдора не гарантирует устранения всех методов доступа.
• Персистентность через подписки на события. Например, настройка подписки Windows Event Forwarding для выполнения скрипта при определенном событии, например, вход пользователя. Это не требует изменения файлов на диске и сложно для детектирования.
• Модификация учетных записей. Использование таких техник, как Skeleton Key, когда для учетной записи создается два работающих пароля, или создание скрытых клонов учетных записей с идентичными привилегиями.
• Компрометация инфраструктуры доверия. Наиболее опасный сценарий — компрометация домена Kerberos. Получив его хэш, злоумышленник может в любой момент сгенерировать билет доступа к любой системе в домене, даже после полного удаления бэкдоров с конечных точек.
• Компрометация резервных копий. Внедрение вредоносного кода в образы резервных копий. Процедура восстановления системы из такой резервной копии приводит к повторному заражению.

Опасность таких закладок в том, что они существуют в режиме ожидания и не оставляют активного шума. Даже если команда нашла и убрала основной бэкдор, инфраструктура может содержать множество маленьких «якорей», которые сработают позже. А когда они срабатывают, атака начинается как будто заново — будто злоумышленник просто взял ключи, которые все это время тихо лежали под ковриком.

Как защититься: рекомендации для SOC, разработчиков и облачных команд

Защита от бэкдоров — это не про один инструмент или регламент. Это постоянная рутина, в которой SOC, разработчики и облачные инженеры работают как единая команда. И чем раньше в цепочке разработки включается безопасность, тем меньше шансов, что где-то внутри появится тихая и умная закладка.

Первое, что важно — не доверять тишине. Большинство современных бэкдоров не шумят, не создают файлов, не генерируют ошибки и не висят в метриках. Поэтому фокус защиты смещается в сторону контроля целостности, прозрачности процессов и очень внимательного наблюдения за поведением инфраструктуры.

Укрепить защиту помогают такие практики:

• Регулярный аудит и контроль целостности.Проверка конфигов, артефактов, зависимостей и контейнеров, автоматическое сравнение с эталонами, верификация хэшей и проверка подписей.
• Логирование и мониторинг CI/CD.Фиксация всех шагов сборки, отслеживание изменений в pipeline, контроль «всплывающих» шагов, проверка прав сервис-аккаунтов, логирование всех операций в registry.
• Отслеживание аномалий микросервисной коммуникации.Неожиданные сервис-to-service вызовы, нестандартные health-check, странные всплески внутренних API — все это признаки потенциальных скрытых каналов.
• Периодический threat hunting на «скрытые входы».Поиск старых cron-заданий, забытых сервисных аккаунтов, странных systemd-юнитов, неактивных или редко вызываемых серверлес-функций, подозрительных IAM-ролей и любых механизмов, которые могут быть резервным бэкдором.

Для SOC важно смотреть глубже, чем на сигнатуры. Для разработчиков — понимать, что безопасность начинается с зависимостей и пайплайна. Для облачных команд — что легитимный сервис может быть идеальным укрытием для злоумышленника.

Хорошая новость в том, что бэкдоры не какая-то дивная магия. Они всего лишь пытаются быть частью вашей инфраструктуры — и чем лучше вы знаете свою систему, тем сложнее им скрываться.

Заключение

Бэкдоры больше не выглядят как один спрятанный файл — они становятся распределенными, модульными и удивительно «естественными» для инфраструктуры. Именно поэтому защита от них требует не только инструментов, но и внимательности к деталям: поведения сервисов, изменениям в CI/CD, мелким аномалиям, которые раньше казались шумом. Чем лучше команды понимают свой технологический ландшафт, тем меньше пространства остается для скрытых входов. В итоге побеждает тот, кто знает свою инфраструктуру глубже, чем злоумышленник, пытающийся в ней спрятаться.

Ведущий поставщик облачной инфраструктуры ActiveCloud и веб-студия CSF реализовали проект по миграции и комплексной оптимизации интернет-магазина UPS-MAG.ru группы компаний «Спектр». В рамках проекта веб-система на базе 1С-Битрикс была переведена в облачную инфраструктуру ActiveCloud, проведен глубокий технический аудит, выполнена оптимизация серверной и прикладной логики. В результате удалось устранить критические сбои в работе сайта, повысить его доступность до 99,4% и ускорить генерацию карточки товара более чем в 10 раз — с 20+ секунд до 1,5 секунд.

ГК «Спектр» работает на рынке с 2009 года и специализируется на поставках электротехнического оборудования, систем гарантированного и бесперебойного электропитания, встраиваемых компьютерных решений и программно-аппаратных комплексов. Интернет-магазин UPS-MAG.ru является важным b2b-каналом продаж компании и обслуживает клиентов по всей территории Российской Федерации. Через цифровую платформу формируются заказы, ведется работа с партнерами, генерируются выгрузки для маркетплейсов и обеспечивается постоянное обновление товарного каталога.

К моменту старта проекта сайт функционировал нестабильно. Заказчик регулярно сталкивался с замедлением работы страниц, различными сбоями в работе сайта, трудностями в индексации со стороны поисковых систем и повышенной нагрузкой от внешних автоматизированных сервисов, запрашивающих данные сайта. Дополнительные сложности создавали некорректно работающие механизмы кеширования, устаревшая версия 1С-Битрикс, избыточные модули из маркетплейса и отсутствие прозрачного инструмента контроля утилизации серверных ресурсов. Проект был размещен на стороннем shared-хостинге, что не позволяло гарантировать производительность и изолированность вычислительных мощностей. В результате любое пиковое увеличение нагрузки приводило к сбоям и падению сайта.

Для определения стратегии развития официальный партнер ActiveCloud выполнил комплексный технический аудит. Специалисты проанализировали результаты Bitrix-тестирования, скорость генерации ключевых страниц, структуру инфоблоков, шаблонов и кастомной логики, состояние базы данных, а также реализацию AJAX-механик (Asynchronous JavaScript and XML, технология, которая позволяет обновлять данные на веб-странице без ее полной перезагрузки) и некешируемых элементов. Отдельное внимание уделили анализу серверного окружения и выявлению узких мест, влияющих на производительность. По итогам аудита была сформирована приоритетная дорожная карта работ, направленных на нормализацию всех аспектов функционирования веб-системы — от инфраструктуры до прикладной логики.

Оптимальным решением стала миграция проекта в облачную инфраструктуру ActiveCloud с разворачиванием специализированной среды BitrixVM и подключением системы мониторинга Zabbix. Выбор был сделан в пользу хостинга CloudServer. Это облачное решение обеспечило необходимую производительность и при этом было сопоставимо по стоимости с VPS (Virtual Private Server, виртуальный частный сервер). Облачная модель позволила выделить гарантированные ресурсы CPU и RAM, обеспечить масштабируемость и внедрить постоянный контроль нагрузки в режиме реального времени.

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

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

В результате интернет-магазин перешел из режима аварийного реагирования в предсказуемый эксплуатационный режим. Полностью устранены критические серверные ошибки, обеспечена стабильная генерация выгрузок для маркетплейсов и корректная индексация поисковыми системами. Производительность ключевых страниц выросла кратно, что напрямую повлияло на пользовательский опыт и внутренние процессы работы сотрудников.

«Для любого проекта на 1С-Битрикс фундаментом стабильности является корректно подобранная инфраструктура и прозрачный контроль утилизации ресурсов. В данном случае мы последовательно прошли путь от аудита до полной нормализации серверного и прикладного уровней. Перевод в облако ActiveCloud позволил обеспечить гарантированные ресурсы, внедрить мониторинг и перейти к системной оптимизации. Сегодня проект работает стабильно и развивается уже в плановом режиме», — прокомментировала Алена Кириленко, ведущий специалист по продаже ActiveCloud.

По словам партнера по разработке, сотрудничество с ActiveCloud стало логичным продолжением многолетнего взаимодействия. «Мы работаем с ActiveCloud почти 10 лет и хорошо понимаем инфраструктурные возможности друг друга. Для клиента было важно получить надежную площадку и оперативную инженерную поддержку. В рамках проекта нам удалось совместно выстроить устойчивую архитектуру и добиться предсказуемой производительности», — отметил Евгений Прупас, руководитель проектов CSF.

«Наш интернет-магазин — это важный канал продаж компании, через который проходит работа с партнерами и клиентами по всей стране. Сбои в его работе могут напрямую влиять на бизнес-показатели, что для нас недопустимо. Благодаря совместной работе ActiveCloud и CSF мы не просто устранили технические проблемы — мы получили стабильный, быстрый и прогнозируемый инструмент. Сегодня карточка товара загружается за 1,5 секунды вместо 20, а доступность сайта достигла 99,4%, что очень важно для бесперебойной работы с клиентами», — прокомментировал Александр Буланьков, руководитель департамента гарантированного электропитания ГК «Спектр».

В дальнейшем команда сосредоточится на развитии проекта: оптимизации логики подбора аналогов товаров, внедрении динамических методов подгрузки графики, доработке пользовательских сценариев и повышении безопасности обработки конверсионных форм. Проект развивается по спринтовой модели, с акцентом на производительность, стабильность и планомерное масштабирование.

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

Практический ИИ в компании: RAG-агент и управление коммуникациями

Привет, друзья! 👋

Готовы разобраться, как ИИ ускоряет техподдержку и увидеть стек технологий под капотом?

26 марта 2026г. (четверг) приглашаем на встречу технических специалистов в формате живого общения!

Что вас ждет:

✔️Демонстрация двух работающих ИИ-решений, которые уже активно применяются в ежедневных задачах.

✔️Детальный разбор технических сценариев: работа RAG-системы на внутренней базе знаний и автоматизированная проверка соблюдения регламентов корпоративной коммуникации.

В программе:

📌 Принципы работы RAG-систем: векторный поиск, генерация ответов из корпоративных данных.

📌 Санитизация (очистка) чувствительных данных.

📌 Архитектурные решения: векторные БД, ИИ-оркестрация, масштабирование.

📌 Живая демонстрация полного рабочего цикла ИИ-системы.

📌 Битва мнений "за" и "против" ИИ в рабочих процессах.

Для кого: инженеры, архитекторы, техлиды и менеджеры, исследующие практическое применение ИИ

Спикеры:

💬 Дмитрий Шмелёв, эксперт по ИИ-решениям, ITKey

💬 Александр Блинов, главный архитектор по поддержке продаж, ITKey

🗓 Когда: 26 марта 2026, 18:00 (сбор гостей с 17:30)

📍 Где: Москва, ул. Садовая-Каретная, 22, стр. 1, 5 этаж (м. «Цветной бульвар») или

▶️Онлайн-трансляция

Для участия в любом формате необходимо пройти регистрацию.

ЗАРЕГИСТРИРОВАТЬСЯ (https://www.itkey.com/invite)

До встречи на мероприятии!

💌 Команда ITKey