Мониторинг на базе AIOps и информационная безопасность: тренд на сближение

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

В 2026 году такая модель перестает соответствовать масштабу задач. Растущая сложность инфраструктуры, ускорение атак и ужесточение требований регуляторов формируют запрос на единый контур наблюдаемости, в котором события мониторинга и безопасности обрабатываются совместно. Последние исследования и отчеты ведущих аналитических агентств, вендоров и отраслевых изданий (IDC, ISG, LogicMonitor, IBM, Motadata, APM Digest) фиксируют сближение AIOps и ИБ как самостоятельный рыночный тренд 2026 года.

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

AIOps и ИБ: факторы, формирующие тренд на объединение

Ускорение бизнес-процессов и цифровых сервисов

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

Смещение угроз внутрь периметра

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

Экономика инцидентов

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

Регуляторная повестка

В 2025–2026 годах российское регулирование в области информационной безопасности прошло через наиболее масштабные изменения с момента принятия 187-ФЗ в 2017 году. С 1 сентября 2025 года вступили в силу поправки, внесенные федеральными законами № 58-ФЗ и № 325-ФЗ: уточнены категории субъектов КИИ, закреплены требования к применяемому программному обеспечению и порядок информирования о компьютерных инцидентах.

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

Последствия фрагментированного мониторинга

Разделение AIOps и ИБ на независимые системы приводит к ряду измеримых последствий.

Атаки маскируются под проблемы производительности. Исследование ISG Research, опубликованное в марте 2026 года, приводит типовой сценарий: AIOps-платформа фиксирует скачок использования памяти в продакшене, XDR — подозрительное боковое перемещение в том же кластере. Поскольку системы не обмениваются контекстом, SOC обрабатывает события как два независимых инцидента, и на установление связи уходит около 45 минут. По оценке ISG, характерные режимы сбоя при разделенной архитектуре — задержка корреляции, насыщение алертами при общей первопричине и конфликтующие действия команд: ITOps может перезапустить хост для восстановления производительности, в то время как SOC требует его изоляции для сохранения данных расследования.

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

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

Дублирование затрат. Параллельные агенты сбора данных, отдельные хранилища телеметрии, независимые команды интеграции и поддержки. По данным LogicMonitor, 96% организаций сохраняют или увеличивают бюджеты на observability и одновременно ужесточают требования к обоснованию ROI и совокупной стоимости владения.

Архитектура объединенного контура AIOps и ИБ

Технически сближение AIOps и ИБ реализуется на трех уровнях.

Слой сбора телеметрии

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

Аналитический слой

ML-движок AIOps-платформы обрабатывает события инфраструктуры и безопасности в едином графе зависимостей. Аномалии метрик сопоставляются с поведением учетных записей, изменения сетевого трафика — с обращениями к базам данных и API. Root Cause Analysis выполняется с учетом обеих категорий событий.

По данным LogicMonitor, внедрение AIOps-корреляции сокращает объем алертов, передаваемых операторам, на 80–95%. При расширении движка на ИБ-события эффект распространяется на SOC: аналитик получает приоритизированный поток инцидентов с предварительно собранным контекстом.

Слой реагирования

Инциденты, выявленные AIOps-платформой, передаются в SIEM, SOAR и ITSM с обогащенным контекстом. Runbook-сценарии разрабатываются совместно командами ITOps и SecOps. Agentic AI применяется для автоматизации первичной диагностики, локализации скомпрометированных компонентов и подготовки данных для расследования.

Функции AIOps в контуре ИБ

Объединенная архитектура расширяет набор задач, решаемых AIOps-платформой.

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

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

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

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

Российская специфика

Требования к объектам КИИ

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

Совместимость с отечественным стеком

Российские AIOps-платформы должны обеспечивать работу на Astra Linux, Alt Linux, с СУБД на базе PostgreSQL, поддерживать отечественное сетевое оборудование и функционировать в изолированных контурах без доступа к внешним ресурсам. Эти требования также распространяются на интеграцию с российскими SIEM и компонентами SOC.

Гибридная модель внедрения

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

Платформа Artimate реализует данный сценарий: интеграция выполняется поверх Zabbix, Пульта, wiSLA, внешнего SIEM и других систем без замены существующего стека. Обработка событий выполняется единым ML-движком, регуляторные требования закрываются на уровне отдельного продукта.

Прогноз развития до 2029 года

По оценке ISG Research, к 2029 году на унифицированные SecOps-платформы, обрабатывающие observability- и security-телеметрию единым движком, будет приходиться 35% новых внедрений. ScienceLogic и Gartner фиксируют активизацию M&A-сделок между AIOps-, observability- и ИБ-вендорами, что отражает запрос корпоративного сегмента на консолидированный контур ITOps, DevOps и SecOps.

Развитие Agentic AI определяет следующий этап автоматизации. В горизонте 2027–2028 годов ожидается расширение применения автономных агентов для рутинных сценариев на стыке ITOps и SecOps: локализация скомпрометированных компонентов, изоляция учетных записей, запуск playbook, формирование отчетов для регулятора. Полная автономия сохраняется как стратегический ориентир, доля сценариев с допустимым уровнем автоматизации увеличивается поэтапно.

Никита Гладких, руководитель аналитической AIOps-платформы Artimate

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

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

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

FAQ

Чем AIOps отличается от SIEM?

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

Заменяет ли AIOps SOC?

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

Как интегрировать существующие ИБ-инструменты с AIOps без полной миграции?

Интеграция выполняется через стандартные интерфейсы: syslog, REST API, OpenTelemetry, вебхук. AIOps-платформа размещается поверх действующего стека, принимает события из SIEM для корреляции и возвращает обогащенные инциденты обратно в SIEM и ITSM.