Юрий Чернышов, к.ф.-м.н., доцент УНЦ «Искусственный интеллект» УрФУ, руководитель исследовательского центра 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

Компания Innostage, первый кибериспытанный интегратор России в области цифровой безопасности, и UDV Group, российский разработчик решений для эффективного и безопасного использования современных технологий, подвели итоги участия в XIV ежегодной конференции «Информационная безопасность АСУ ТП КВО». Мероприятие прошло 3—4 марта в Москве при участии ФСТЭК России, ФСБ России и отраслевых регуляторов, собрав более 750 руководителей и ведущих специалистов по ИБ и АСУ ТП из ключевых отраслей промышленности.

На объединенном стенде Innostage и UDV Group основной акцент был сделан на готовности партнеров к реализации сложных инфраструктурных проектов по импортозамещению и защите АСУ ТП на объектах КИИ «под ключ». Собственная экспертиза Innostage в этой области подтверждена более чем 190 проектами различного уровня сложности для предприятий ТЭК, металлургии, химпрома и транспорта. Экспертиза UDV Group, в свою очередь, обеспечивается современными технологическими решениями, позволяющими не только контролировать промышленный трафик, но и управлять версиями проектов ПЛК, что критически важно для устойчивости производств.

Участие в конференции «Информационная безопасность АСУ ТП КВО» стало логичным продолжением стратегического партнерства компаний Innostage и UDV Group, закрепленного меморандумом о сотрудничестве на форуме Kazan Digital Week 2025.

В основе подхода Innostage к защите промышленных объектов — объединение компетенций ИТ, ИБ и АСУ ТП в единую команду, обеспечение сквозной наблюдаемости и непрерывности технологических процессов, а также масштабирование единых стандартов безопасности на все площадки заказчика. Именно такой системный подход позволяет создавать по-настоящему киберустойчивые АСУ ТП. Технологическим фундаментом этого подхода выступают решения UDV Group, чья платформа базируется на комплексной киберзащите промышленных предприятий: от глубокого анализа промышленного трафика и контроля целостности проектов ПЛК до централизованного управления безопасностью на всех уровнях АСУ ТП. Флагманское решение компании, UDV DATAPK Industrial Kit 3.0, сертифицированное ФСТЭК России по 4 уровню доверия, объединяет модули обнаружения аномалий на базе машинного обучения, контроля версий и аудита изменений, обеспечивая тем самым сквозную наблюдаемость и непрерывность технологических процессов без риска влияния на работу контроллеров.

На полях XIV конференции «Информационная безопасность АСУ ТП КВО» руководитель отдела технической поддержки продаж UDV Group Денис Назаренко представил доклад «Групповой портрет АСУ ТП в кибер-ландшафте», собравший широкий интерес профессионального сообщества. В своем выступлении эксперт предложил аудитории аналитический срез текущего состояния промышленной кибербезопасности, основанный на реальных данных и многолетнем опыте реализации проектов на объектах КИИ. Основной акцент был сделан на переходе от точечной защиты к формированию целостного «портрета» защищаемого объекта: от анализа типовых уязвимостей и векторов атак до поведенческих особенностей промышленного оборудования в условиях растущего санкционного давления и активного импортозамещения. Доклад Дениса Назаренко наглядно продемонстрировал, что построение киберустойчивости сегодня невозможно без глубокого понимания ландшафта угроз и адаптации стратегий защиты под индивидуальные особенности технологических процессов предприятий.

В течение двух дней работы конференции руководитель направления по работе с партнерами автоматизации Innostage Дмитрий Буканов и руководитель отдела технической поддержки продаж UDV Group Денис Назаренко проводили для гостей стенда демонстрации интегрированного подхода на базе продукта UDV DATAPK Industrial Kit и UDV ITM. Посетители могли вживую оценить подходы и практические решения для реализации крупных инфраструктурных проектов — начиная с проблем определения категории значимости объектов КИИ и заканчивая совместными с производителями решений по автоматизации комплексными испытаниями, в том числе на действующих объектах без прерывания технологического процесса.

Ключевыми темами обсуждения на стенде Innostage и UDV Group стали практические аспекты категорирования объектов КИИ, импортозамещения, применение и настройка наложенных средств защиты без технологических пауз, аудит и харденинг (ужесточение мер защиты) инфраструктуры, пентесты и контролируемые кибератаки на АСУ ТП, а также построение центров мониторинга (SOC) для промышленных предприятий с привлечением экспертизы Innostage SOC CyberART.

«Мы подтвердили ключевой тезис, с которым шли на конференцию: рынку сегодня нужны не отдельные продукты, а системные интеграторы с доказанной способностью реализовывать масштабные инфраструктурные проекты с полным циклом ответственности. Запрос на „тяжелую“ интеграцию, где нужно соединить требования ФСТЭК, импортозамещение ПЛК и ПАКов, внедрение средств защиты и постоянный мониторинг, был очевиден в каждом диалоге с заказчиками. Особый интерес вызывала наша экспертиза в реализации комплексных проектов защите АСУ ТП на действующих объектах без остановки технологических процессов — это именно то, что отличает реальный опыт от теоретических знаний. Наше партнерство с UDV Group позволяет закрывать эти потребности наиболее эффективно, объединяя технологическую экспертизу вендора с интеграционной мощью, методологией и отраслевым опытом Innostage», — прокомментировал итоги мероприятия Дмитрий Буканов, руководитель направления по работе с партнерами автоматизации Innostage.

«Мы шли на мероприятие с целью поделиться результатами своего большого исследования рынка защиты АСУ ТП, основной задачей которого было выявление «болей» и проблем команд, отвечающих за защиту технологического сегмента. Нам было важно рассказать про результаты нашей работы и услышать обратную связь от участников мероприятия. Выступление вызвало позитивный отклик среди аудитории, что подтверждает корректность сделанных выводов и актуальность выявленных проблем. Основной инсайт исследования: вендору необходимо проявлять гибкость в своих решениях (а не только в цене) для того, чтобы заказчик мог их интегрировать без масштабной трансформации своих технологических процессов. В этом подходе мы абсолютно солидарны с позицией команды Innostage», - прокомментировал итоги мероприятия руководитель отдела технической поддержки продаж Денис Назаренко.  

О компании Innostage:

Innostage — российский интегратор сервисов и решений в области цифровой безопасности, первый в стране, подтвердивший статус кибериспытанного (2024). Входит в топ-3 поставщиков ИБ в ТЭК России и топ-8 крупнейших игроков рынка (TAdviser). Команда компании насчитывает более 1300 специалистов. В составе Innostage работает специализированный центр мониторинга и реагирования на киберугрозы — Innostage SOC CyberART (Центр противодействия киберугрозам Innostage КиберАрт).

О компании UDV Group:

UDV Group — российский разработчик высокотехнологичных решений, обеспечивающих киберустойчивость предприятий любых отраслей и масштабов. Ключевыми направлениями компании являются: разработка решений в области кибербезопасности, исследования и внедрения проектов в области цифровой трансформации и информационной безопасности, услуги аудита и консалтинга по вопросам ИБ и технической поддержки. UDV Group входит в Топ-50 крупнейший ИБ компаний России по мнению аналитических центров CNews и TAdviser. Продукты UDV Group входят в реестр отечественного ПО и имеют сертификаты соответствия ФСТЭК России, успешно внедряются в России с 2014 г.

Описание объекта закупки — самая уязвимая часть ИТ-госзакупок. Именно здесь закладываются многие будущие проблемы: жалобы, предписания ФАС, возврат процедур на доработку и срыв сроков. Что в 2026 г. нужно знать сотрудникам контрактной службы и ИT-специалистам при составлении ТЗ?

Ошибки в ТЗ редко выглядят как откровенные нарушения — чаще это формально корректные действия, которые, однако, не выдерживают проверки практикой правоприменения. С каждым годом правила описания ИТ-товаров заметно усложняются. Обязательное применение Каталога товаров, работ и услуг (КТРУ) в закупках согласно Федеральному закону «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» от 05.04.2013 № 44-ФЗ (далее — закон № 44-ФЗ), ограничения на дополнительные характеристики, корректная работа с классификатором ОКПД 2, национальный режим, заключающийся в том числе в новых требованиях ст. 33 закона № 44-ФЗ — все это требует от закупочной службы и ИТ-специалистов не только знания норм, но и понимания логики их применения. Простого следования интерфейсу Единой информационной системы в сфере закупок (ЕИС) или привычных подходов недостаточно. 

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

В ИТ-закупках по закону № 44-ФЗ заказчик работает только с ЕИС, не обращаясь к ПП № 145 

Первый шаг к одной из самых распространенных ошибок в ИТ-закупках по закону № 44-ФЗ обычно такой: заказчик формирует описание объекта закупки, заходит в ЕИС, выбирает нужную позицию КТРУ и ориентируется исключительно на характеристики и формулировки, соответствующие данному коду. На этом многие останавливаются — и именно в этом ошибка. Ее суть в том, что заказчик ориентируется на формулировки и подсказки ЕИС, но не проверяет требования Постановления Правительства РФ «Об утверждении Правил формирования и ведения в единой информационной системе в сфере закупок каталога товаров, работ, услуг для обеспечения государственных и муниципальных нужд и Правил использования указанного каталога» от 08.02.2017 № 145 (далее — ПП № 145) которое регулирует порядок применения КТРУ. В результате в описание объекта закупки добавляются характеристики, которые согласно закону добавлять нельзя.

В чем нормативная логика? Каталог товаров, работ и услуг используется при закупках по закону № 44-ФЗ и охватывает большую часть ИТ-товаров. Для каждой позиции КТРУ установлен обязательный набор характеристик, которыми заказчик должен пользоваться при описании объекта закупки. В ПП № 145 прямо говорится:

• если позиция есть в КТРУ, то заказчик обязан использовать характеристики из каталога;
• добавлять дополнительные характеристики можно только в тех случаях, когда это прямо разрешено правилами применения КТРУ.

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

Где именно возникает ошибка? Формально п. 5 Правил применения КТРУ допускает включение дополнительных характеристик при наличии обоснования. Именно на эту норму чаще всего и ссылаются заказчики. Но в правилах имеется важная оговорка, которую многие не дочитывают до конца. Пункт 5 устанавливает исключение: дополнительные характеристики нельзя указывать при закупке товаров, занимающих позиции 191—361 в приложении № 2 к Постановлению Правительства РФ «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» от 23.12.2024 № 1875 (далее — ПП № 1875), если к этим товарам применяется соответствующая защитная мера в виде ограничения. А в этот перечень попадает значительная часть радиоэлектронной продукции, в том числе базовые ИТ-товары.

Типовой пример из практики — монитор. Если заказчику нужно купить монитор, он заходит в ЕИС и выбирает позицию КТРУ «Монитор, подключаемый к компьютеру». В карточке позиции система показывает набор характеристик, а в поле «Указание дополнительных характеристик запрещено» сообщает: «нет».

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

Однако делать это не следует. Почему? В ОКПД 2 монитор имеет код 26.20.17. Если открыть приложение № 2 к ПП № 1875, то можно увидеть, что этот товар входит в упомянутый перечень (позиции 191—361) и занимает в нем позицию 201. Значит, монитор относится к товарам, для которых п. 5 Правил применения КТРУ не работает. Для него действует исключение: дополнительные характеристики указывать нельзя, даже если ЕИС это технически позволяет.

Почему заказчики ошибаются? Причина проста: заказчик видит интерфейс ЕИС и доверяет ему, не дочитывает п. 5 Правил применения КТРУ до конца, не сверяет позицию КТРУ с приложением № 2 к ПП № 1875. В итоге в ТЗ появляются характеристики, которые формально нарушают требования ПП № 145. Это квалифицируется как неправильное описание объекта закупки и становится основанием для жалобы.

Чрезмерно детальное описание товара при работе с ОКПД 2

Еще одна типовая ошибка возникает в закупках как по закону № 44-ФЗ, так и по Федеральному закону «О закупках товаров, работ, услуг отдельными видами юридических лиц» от 18.07.2011 № 223-ФЗ (далее — закон № 223-ФЗ). Она связана с классификацией товара по ОКПД 2, но, по сути, это все та же проблема работы с характеристиками, только в другой плоскости. В отличие от ситуации с КТРУ, здесь заказчик часто получает больше свободы, чем способен корректно использовать. И именно эта свобода становится причиной нарушения.

В чем логика действий заказчика? КТРУ и ПП № 145 существенно ограничивают его в описании объекта закупки. Набор характеристик фиксирован, добавить что-либо помимо этого можно далеко не всегда. Но реестр КТРУ, при всей его наполненности все же не охватывает ИТ-номенклатуру на 100%. В таких случаях заказчик действует по-другому:

• при закупках по закону № 44-ФЗ выбирает код ОКПД 2, для которого КТРУ не применяется;
• по закону № 223-ФЗ изначально работает только с ОКПД 2, поскольку использовать КТРУ там необязательно.

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

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

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

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

Заведомый уход от КТРУ через «приблизительный» код ОКПД 2

Следующая распространенная ошибка в закупках по закону № 44-ФЗ — сознательный уход от применения КТРУ. Формально она выглядит менее критично, чем прямое нарушение правил каталога, но на практике именно такие действия чаще всего становятся предметом разбирательств в ФАС.

Согласно общему правилу, если товар присутствует в КТРУ, заказчик обязан использовать соответствующую позицию каталога. Это прямо следует из ПП № 145: совпадает «сущность» товара по ОКПД 2, позиция присутствует в каталоге, значит, применяется КТРУ — без вариантов.

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

Вместо того чтобы работать в рамках каталога, некоторые заказчики подбирают приблизительный код ОКПД 2, изменяют наименование товара так, чтобы формально оно не совпадало с позицией КТРУ, и заявляют, что нужного товара «в каталоге нет». В результате КТРУ исключается из логики закупки, а описание товара строится с нуля.

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

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

Почему такие закупки быстро выявляются? Поставщики видят, что товар по сути есть в КТРУ, код ОКПД 2 подобран искусственно, характеристики скопированы из технического паспорта конкретного изделия, предложить эквивалент невозможно. В таких случаях участники направляют запросы, а затем подают жалобы в ФАС. Антимонопольная служба сопоставляет описание закупки с каталогом и рынком и, как правило, приходит к выводу о неправомерном уходе от КТРУ.

Почему ошибка кажется незначительной, но таковой не является? Напомним, что за неверный выбор кода ОКПД 2 предусмотрены сравнительно небольшие штрафы. Именно поэтому некоторые заказчики считают, что риск минимален. Но в реальности последствия серьезнее: закупка признается проведенной с нарушениями, ФАС выдает предписание изменить техническое задание, процедура возвращается на доработку или отменяется, сроки срываются и закупку приходится начинать заново.

Игнорирование ч. 1.1 ст. 33 закона № 44-ФЗ при описании объекта закупки

В закупках по закону № 44-ФЗ есть норма, которую по праву можно назвать базовой для всех, кто работает с техническими заданиями, — ст. 33 «Правила описания объекта закупки». Это действительно настольный документ для закупочной службы и ИТ-специалистов. Именно здесь закреплены принципы, в соответствии с которыми заказчик должен формировать описание товара. С 2025 г. в этой статье появилось ключевое дополнение — часть 1.1, и ее игнорирование сегодня порождает целый пласт новых нарушений.

Что именно изменилось? Часть 1.1 ст. 33 прямо устанавливает: если в отношении товара действуют меры национального режима — запрет, ограничение или преимущество в соответствии с п. 1 ч. 2 ст. 14 закона № 44-ФЗ, — то при описании объекта закупки указываются характеристики товара российского происхождения. Это принципиальный момент. Закон больше не ограничивается запретом на указание брендов или стран происхождения. Он требует от заказчика активного действия: описание товара должно быть сформировано так, чтобы под него подходил товар российского происхождения.

На практике это означает следующее:

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

Это и есть главное нововведение 2025 г. в описании объекта закупки.

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

Почему это нарушение принципиально важно? Соблюдение ч. 1.1 ст. 33 — это не формальность и не рекомендация. Это фундаментальная норма, которая связывает национальный режим и техническое задание в единую конструкцию. Если заказчик ее игнорирует, закупка становится уязвимой для жалоб. ФАС оценивает, подходит ли под ТЗ российский товар, и при отрицательном ответе закупка признается проведенной с нарушениями.

Вывод здесь простой: в 2026 г. описание объекта закупки по закону № 44-ФЗ должно начинаться не с абстрактных характеристик и не с привычного оборудования, а с ответа на вопрос: какой российский товар соответствует потребности заказчика. Если товар подпадает под запреты, ограничения или преимущества, заказчик обязан формировать ТЗ исходя именно из российского аналога. Отступление от этого правила — одна из самых критичных ошибок новой практики, потому что она напрямую противоречит ст. 33 закона № 44-ФЗ и целям национального режима.

* * *

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

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

В 2026 г. ключевая задача заказчика — не просто описать нужный товар, а сделать это в рамках действующих правил: проверить применимость КТРУ, корректно выбрать ОКПД 2, провести анализ реестров, учесть требования национального режима и ч. 1.1 ст. 33 закона № 44-ФЗ. Это зона совместной ответственности контрактной службы и ИТ-специалистов, где ошибка на одном этапе почти всегда тянет за собой всю закупку.

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

Дмитрий Битченков, руководитель направления разработки технической и проектной документации компании «ГИГАНТ Компьютерные системы», преподаватель дисциплины «Документирование в сфере закупок» РТУ МИРЭА.

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

Как эффективнее всего искать бэкдоры, которые не являются файлами и используют встроенные инструменты системы?

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

Мониторинг цепочек выполнения процессов. Осуществляется с использованием EDR-систем. Ключевые индикаторы: запуск powershell.exe или cscript.exe из офисных приложений или почтовых клиентов; использование системных утилит для сетевой активности.

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

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

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

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

Дополнительные учетные данные. Злоумышленник заранее создает резервные наборы учетных данных (логины/пароли, сертификаты, API-ключи) и размещает их в различных частях системы. Обнаружение и удаление одного бэкдора не гарантирует устранения всех методов доступа.

Персистентность через подписки на события. Например, настройка подписки Windows Event Forwarding для выполнения скрипта при определенном событии (например, вход пользователя). Это не требует изменения файлов на диске и сложно для детектирования.

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

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

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

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

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

• Ожидаете ли вы наступления «ИИ-зимы» на глобальном рынке в масштабах, сравнимых с «крахом доткомов», или в этот раз все пройдет значительно мягче?

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

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

• Может ли «ИИ-зима» повлиять на происходящее в сегменте ИИ на российском рынке или у нас действуют собственные, более сильные ограничения?

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

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

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

Автор: Сергей Воронин, руководитель направления инженерных систем компании «ГИГАНТ Компьютерные системы»

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

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

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

Ошибки на старте, которые дорого обходятся позже

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

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

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

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

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

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

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

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

Например, интегратор может подсказать, что вместо того, чтобы строить ЦОД «на вырост», лучше определить реальный горизонт расширения и разбить его на удобные модули. Если требуется 100 кВт, не стоит ставить две крупные кондиционерные установки «на весь объем» - при низкой загрузке они будут работать некорректно. Рациональнее разбить систему на модули, например по 25 кВт, и подключать их по мере роста нагрузки. Аналогично и с электропитанием: модульные ИБП позволяют увеличивать мощность постепенно, добавляя силовые модули внутри одной платформы. Так можно избежать переплат за лишнюю мощность и наращивать ЦОД постепенно. 

Электроснабжение ЦОДа: принципы проектирования, уровни резервирования и типичные ошибки

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

В инженерной практике опираются на стандарты Tier I—IV, и в России чаще всего выбирают Tier III — оптимальный баланс стоимости и надежности. Этот уровень предполагает резервирование всех ключевых компонентов по схеме n+1, что обеспечивает работу системы при отказе одного элемента. Tier IV требует уже двух независимых контуров электроснабжения, полностью дублирующих друг друга, поэтому встречается редко и главным образом на коммерческих площадках, где простои критичны для выручки. В Москве такие объекты уже есть: годовые плановые остановки там измеряются буквально несколькими часами.

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

Охлаждение как фундамент стабильности ЦОДа: какие технологии работают лучше всего

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

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

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

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

Что определяет надежность будущего ЦОДа

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

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

Что касается пиковых нагрузок, то здесь подход довольно прагматичный. Инженерные системы проектируют исходя из полной, стопроцентной нагрузки оборудования - без «скидок» на усреднение или ожидаемый коэффициент спроса. Да, и электроснабжение, и охлаждение имеют допустимую перегрузочную способность и могут кратковременно работать выше номинала, но рассчитывать на это как на норму невозможно. В исключительных случаях допускается проектирование с нижними коэффициентами, когда заказчик четко понимает, что его оборудование никогда не будет работать на 100% - например, останется в диапазоне 70—80% от номинала. Но это скорее исключение, чем правило: надежный ЦОД всегда проектируют под полный тепловой и электрический профиль нагрузки, чтобы он оставался стабильным при любых скачках потребления и внешних условиях. И здесь возникает другая важная тема - выбор формата самого ЦОДа. Когда известно, как объект будет вести себя под максимальной нагрузкой и в самых тяжелых климатических условиях, становится понятно, какой тип площадки вообще имеет смысл строить. Для одних проектов логично идти в капитальное строительство, для других наоборот, критичны сроки ввода и ограничения по площадке, и именно поэтому в России стабильно востребованы модульные и контейнерные ЦОДы. 

Модульные и контейнерные форматы: практическая необходимость, а не компромисс

Модульные и контейнерные ЦОДы в России стабильно востребованы - но не из-за моды и не из-за «нового формата». Их выбирают тогда, когда классическое строительство либо невозможно, либо невыгодно по срокам, либо неоправданно по масштабу. Главный фактор здесь - скорость: такие решения позволяют развернуть рабочий ЦОД в разы быстрее, чем капитальное здание, а для многих проектов именно время запуска определяет успех. Когда бизнесу нужно ввести мощности не через 18 месяцев, а через 3—4, альтернатив просто нет.

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

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

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

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

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

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

Главные технологические векторы, которые сформируют рынок ЦОДов

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

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

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

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

Что такое киберсталкинг и почему он опасен

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

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

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

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

Проблема в том, что законодательство пока не поспевает за реальностью. В России самого понятия «киберсталкинг» в законах нет, и дела квалифицируются по смежным статьям — «угроза», «клевета», «незаконный сбор сведений о частной жизни». За рубежом подход более точечный: в Великобритании действует Protection from Harassment Act, а в ряде штатов США введены отдельные нормы именно за cyberstalking.

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

Следы, которые выдают преследователя

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

Иван Бурмистров. Пресейл-инженер UDV Group

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

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

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

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

OSINT против киберсталкера: когда открытые источники работают на защиту

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

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

Сергей Носков. Начальник отдела проактивной кибербезопасности компании «Газинформсервис»

Современные OSINT-технологии эффективно выявляют анонимные аккаунты сталкеров через:

• Перекрестную корреляцию: поиск одного никнейма/телефона/email через сотню платформ с помощью инструментов типа Sherlock.
• Обратный поиск по изображениям: анализ аватарок и фото через Google Images/Yandex для нахождения цифровых следов.
• Лингвистическую экспертизу: ИИ сравнивает стилистику письма с известными образцами подозреваемого.
• Анализ метаданных: извлечение GPS-координат и данных устройства из EXIF-данных фотографий.
• Граф-анализ связей: выявление скрытых аккаунтов через общие социальные связи и паттерны активности.

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

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

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

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

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

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

Самодеятельность жертв: где заканчивается интуиция и начинается риск

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

Сергей Носков. Начальник отдела проактивной кибербезопасности компании «Газинформсервис»

Жертвы киберсталкинга часто совершают роковые ошибки, пытаясь вычислить преследователя:

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

Правильная стратегия:

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

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

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

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

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

Анонимность и защита цифрового профиля

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

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

Иван Бурмистров. Пресейл-инженер UDV Group

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

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

Командная работа: кто помогает жертве киберсталкинга

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

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

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

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

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

Заключение

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

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

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

Цифровая платформа гибкой занятости Ventra Go! выпустила функциональность для компаний - представителей сегмента среднего и малого бизнеса (СМБ).

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

“В отличие от основного личного кабинета для крупных розничных сетей, где реализована возможность управления распределенными торговыми точками, лимитами и отчетностью, для сегмента малых предприятий мы оставили только ключевое, необходимое для создания быстрого заказа услуг исполнителей” — комментирует директор по маркетингу Ventra Go! Анна Ларионова.

Среди компаний СМБ особенно востребованы услуги работников в популярных категориях: работа в  торговом зале, сборка заказов, помощь на кассе, разгрузка/погрузка и др. Всего на платформе зарегистрировано более 2 млн исполнителей, готовых выйти на смену и выполнить задание.

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

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

“Мы видим растущий запрос среднего и малого бизнеса на временный персонал, который может в моменте закрыть потребность в рабочей силе. Мы даем возможность заказчикам из СМБ быстро решить проблему необходимых рабочих рук здесь и сейчас — исполнители выйдут на задание оперативно, за 24 часа. Платформа берет на себя весь процесс взаимодействия с подработчиками и гарантирует клиентам высокое качество временного персонала” — комментирует директор по маркетингу Ventra Go! Анна Ларионова.

О Ventra Go!

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

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

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

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

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

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

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

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

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

От инженерного фундамента к целевым ИБ-ролям внутри компании

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

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

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

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

Обучение ИБ через бизнес-контекст, последствия решений и наставничество

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

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

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

Ключевую роль в этом процессе играет наставник. Именно он передает тот контекст, которого нет в документации: знание архитектуры, «тонких мест», исторических ограничений и причин принятых решений. Наставник показывает, как действовать в условиях неполной информации, делится опытом прохождения риск-комитетов и разбора инцидентов, а также помогает выстраивать коммуникацию с бизнесом и смежными подразделениями. Однако эффективное наставничество - это значительная нагрузка на опытных специалистов. Чтобы система работала, роль наставника должна быть формализована: включена в KPI и должностные обязанности, выделено специальное время (например, 15-20% рабочей недели), а его вклад - материально и карьерно мотивирован. В противном случае высок риск выгорания наставников и формального отношения к обучению.

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

Типовые ошибки и баланс обучения в ИБ-командах

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

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

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

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

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

Прогресс ИБ-инженера при этом важно оценивать путем сочетания объективных показателей (метрик) и субъективной оценки развития компетенций инженера. В качестве объективных метрик могут рассматриваться: время на закрытие смоделированного инцидента; количество и критичность выявленных уязвимостей в тестовой среде; результаты регулярных аудитов защищенности сегмента, за который отвечает стажер; и, наконец, структурированная обратная связь (оценка 360°) от наставников, коллег из смежных команд и внутренних «заказчиков». 

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

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

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

Как удерживать выращенных ИБ-специалистов и не терять их после обучения

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

Заключение

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

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

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

Кадровый дефицит в ИТ-отрасли по разным оценкам составляет 150—200 тысяч специалистов. Для его сокращения компании взаимодействуют с вузами, обучают молодых специалистов на местах. Но если ранее они это делали по собственной инициативе и по финансовым возможностям, то с 1 июня 2026 года будут обязаны отчислять на эти цели не менее 3% от средств, сэкономленных за счет льгот. Соответствующее постановление правительства касается аккредитованных ИТ-компаний. Эксперты рассказали «Телеспутнику» о возможной эффективности такой инициативы и рисках, которых опасается отрасль.

Ключевые моменты эффективности

Практическую эффективность нововведения для ИТ-компаний в краткосрочной перспективе директор по персоналу ГК «КОРУС Консалтинг» Дарья Цирулева оценила на 5—6 баллов из 10.

«Обязательные отчисления в размере 3% от средств, сэкономленных за счет льгот, сами по себе не способны существенно сократить кадровый дефицит в отрасли, который по разным оценкам составляет 150—200 тысяч специалистов. Подготовка ИТ-кадров — это долгий цикл: от начала обучения до выхода на рынок проходит несколько лет, но это в том случае, если речь идет о junior-специалистах. А рынок испытывает наибольший дефицит в сегменте middle+ и senior — на их подготовку требуется больше времени», — пояснила Дарья Цирулева.

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

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

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

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

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

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

Эффективность нововведения неоднозначна, полагает HR -директор цифровой платформы для организации командировок и управления расходами «Ракета» Ксения Коскова.

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

Участие бизнеса в образовательном процессе — полезная и нужная практика, однако текущие формальные критерии аккредитации рискуют сместить фокус с содержательной работы на «гонку за баллами», создавая неравные условия для компаний разного размера, предупредила руководитель программ обучения ИТ-экосистемы «Лукоморье» (ООО «РТК ИТ плюс») Анастасия Горелова. Привлечение практиков из компаний, реализация проектов, стажировки и мастер-классы — лучший способ дать студентам актуальные знания и помочь им с профессиональным самоопределением. Ключевой проблемой становится механизм учета этого взаимодействия в рамках аккредитации: когда каждая активность требует строгого документального подтверждения, она теряет гибкость и практический смысл, возникает риск «бумажной гонки» для выполнения формального норматива, в данном случае — тех самых 3 %, что может негативно сказаться на качестве самого образовательного контента, полагает эксперт.

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

Аккредитация: госсподдержка или соцконтракт?

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

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

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

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

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

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

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

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

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

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

Ольга Луценко, ведущий эксперт по ИБ компании UDV Group, дала комментарий, в котором оценила исследование рынка ИБ-аудита 

Согласны ли вы с тем, что за 2025 год рост рынка ИБ-аудита превысил 25% и достиг 25 млрд руб., ? Есть ли у вас собственные цифры?

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

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

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

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

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

Какие сегменты все чаще идут за ИБ-аудитом?

С точки зрения отраслевой структуры спроса, сегодня основными заказчиками ИБ-аудита остаются субъекты критической информационной инфраструктуры — прежде всего в контексте изменений и практики применения 187-ФЗ. Одновременно мы видим рост интереса со стороны государственных организаций и органов местного самоуправления, что связано с реформированием подзаконной базы в области обеспечения ИБ госсектора, включая требования приказа ФСТЭК № 117 и планируемые изменения в перечнях мер. Именно эти сегменты в ближайшие годы, по нашему мнению, будут формировать основной спрос и поддерживать дальнейший рост рынка ИБ-аудита.

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

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

1 Таможенные сборы: рост без альтернатив

С 1 января 2026 года вступила в силу новая редакция постановления правительства о ставках и базе для исчисления таможенных сборов за выпуск товаров. Если кратко - государство пересмотрело «потолок» сборов для наиболее чувствительных категорий импорта. Для товаров, включенных в Приложение 1, таможенный сбор при импорте теперь составляет 73 860 рублей за декларацию. Для сравнения: ранее максимальный размер сбора не превышал 30 000 рублей. Под действие новых ставок попали ключевые товарные группы - коды ТН ВЭД 84, 85, 90, 91 и 95. Это оборудование, электроника, приборы, оптика, часы, а также отдельные категории промышленных и потребительских товаров. Фактически именно те позиции, на которых держится импорт для промышленности, ИТ и сервисных компаний. Важно понимать - речь идёт не о разовой мере, а о зафиксированном тренде. Таможенные сборы всё активнее используются как инструмент регулирования, и встраивать этот фактор в экономику поставок теперь нужно заранее, а не постфактум.

2 Сертификация: упрощения формально действуют, требования - ужесточаются

На первый взгляд, регулятор сохраняет лояльность. Постановление №1277 продлевает упрощённый порядок до 1 сентября 2026 года. Он по-прежнему применяется к запасным частям, комплектующим, компонентам и сырью для ремонта ранее выпущенной в России продукции, а также к единичным экземплярам товаров для собственного использования декларантом.

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

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

Вывод: как проходить таможенное оформление быстрее и без нарушений

-Заранее проверяйте применимые требования - ТР ТС / ТР ЕАЭС, профильные ГОСТы - и сразу определяйте корректный формат подтверждения соответствия: сертификат, декларация или протокол испытаний. Ошибка на этом этапе почти гарантирует задержку при выпуске.

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

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

-Используйте механизм предварительного рассмотрения документации (pre-submission) в аккредитованных органах и лабораториях. Такая проверка снижает количество итераций и уточнений уже на этапе ввоза.

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

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

3 СПОТ: новый уровень предварительного контроля

В 2026 году в системе таможенного регулирования появляется принципиально новый элемент - Система подтверждения ожидания поставки товаров (СПОТ). Правительство утвердило концепцию её создания и план реализации распоряжением от 10 ноября 2025 года № 3213-р. Документ уже опубликован, а значит - вопрос не в «если», а в «когда». Для участников ВЭД это означает поэтапный переход к новой модели контроля импорта товаров из государств - членов ЕАЭС.

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

4 Повышенные ставки и пересмотр тарифов: учитывать заранее

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

Вывод: как минимизировать издержки законно

-Заранее согласуйте с финансами сценарии расчета полной стоимости владения (COGS): цена товара, логистика, прогноз таможенных платежей, НДС и курсовые риски. Это снижает вероятность пересмотра бюджета уже после ввоза.

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

Используйте таможенные режимы, позволяющие снизить налоговую нагрузку: таможенный склад (bonded warehouse), переработка на таможенной территории, временный ввоз, а также режим реимпорта при возврате товаров.

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

-Фиксируйте в контракте порядок индексации и распределения рисков по таможенным платежам - кто и в каком объёме несёт расходы при изменении ставок или базы расчета.

5 Цифровизация и «умное» таможенное администрирование

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

Вывод:  как проходить таможенное оформление быстрее и без нарушений

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

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

-Контролируйте цифровые форматы - файл-фактуры, электронные инвойсы, EDI-пакеты. Данные в электронных каналах должны полностью совпадать с сопроводительными документами.

-Заранее согласовывайте с брокером шаблоны EAD, CMR и транспортных документов - единый формат снижает риск отклонений и дополнительных запросов.

-Используйте преддекларацию и электронную предрегистрацию (pre-lodgement) - подача декларации до прибытия груза ускоряет выпуск при корректных данных.

-Внедрите внутреннюю верификацию данных - сверку серийных номеров, кодов, наименований и стоимости в ERP-системе до передачи информации брокеру.

-Используйте статус уполномоченного экономического оператора (УЭО) или работайте с УЭО-партнёром - это снижает количество проверок в цифровых контурах контроля.

6 Обязательная маркировка ввозимых товаров

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

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

Вывод: как легально пройти требования по маркировке

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

-Фиксируйте на стороне поставщика формат маркировки - товар должен поступать уже промаркированным либо вместе с корректными данными для нанесения маркировки на складе в Российской Федерации.

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

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

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

7 Эксперимент с импортозамещением ИТ-оборудования

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

Вывод: как работать легально с зарубежным ИТ-оборудованием

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

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

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

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

Заключение

Таможенное регулирование в 2026 году стало более требовательным, цифровым и прогнозируемым - при условии, что участник ВЭД работает системно. Фокус сместился с формального оформления на качество подготовки: документов, данных, сертификации и финансовых расчётов. 

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

Автор: Николай Нагдасев, ведущий специалист UDV Group

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

Введение

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

Линейный цикл реагирования vs реальная инфраструктура

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

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

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

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

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

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

Проблема №1: обнаружение построено без связи с критичностью активов

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

Проблема №2: анализ инцидентов не стандартизирован и зависит от конкретного инженера

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

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

Проблема №3: реагирование не синхронизировано между ИТ, ИБ и технологами

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

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

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

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

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

Проблема №4: локализация основана на ручных действиях, а не инженерных процедурах

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

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

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

Проблема №5: мониторинг не обеспечивает полноту данных для реагирования

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

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

Проблема №6: нет инженерной обратной связи - поэтому инциденты повторяются

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

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

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

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

Один сценарий - два результата: что дает зрелость процессов

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

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

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

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

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

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

Реагирование как культура инженерии

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

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