Эксперты «Инфосистемы Джет»: «Киберустойчивость становится вопросом корпоративного управления»

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

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

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

Директор центра компетенций мониторинга «Инфосистемы Джет» Петр Маскалюк
Фото: «Инфосистемы Джет»

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

Алексей Акопян: Компании уходят от модели, в которой ИТ-инфраструктура строится вокруг одного главного ЦОДа, единого кластера и единственной «правильной» схемы резервирования. Это наследие эпохи монолитов, где надёжность обеспечивалась за счёт связки площадок через метрокластеры и растянутые L2-сети.

Руководитель отдела систем мониторинга «Инфосистемы Джет» Алексей Акопян
Фото: «Инфосистемы Джет»

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

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

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

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

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

Из новых вызовов стоит отметить два. Первый — взрывной рост сложности. Когда сервис распределен по ЦОДам, контейнерам и облакам, найти сбой вручную нереально. Нужны средства корреляции и автоматизированного поиска причин. Интерес к AI/ML здесь перешёл в практическую плоскость: заказчики экспериментируют с open-source, наиболее востребованы поиск первопричины, корреляция событий и предиктивная аналитика.

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

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

Руководитель дирекции информационной безопасности «Инфосистемы Джет» Андрей Янкин
Фото: «Инфосистемы Джет»

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

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

• Отказ от доверия по умолчанию. Концепция Zero Trust перестала быть модным термином и стала практической необходимостью. При этом речь не идёт о попытке реализовать её «в идеале». Наиболее эффективны такие меры, как многофакторная аутентификация, контроль привилегированных пользователей, сегментация критических систем, управление идентификацией и контроль подрядчиков. Это необходимая база.
• Проверенный, но зачастую игнорируемый, принцип Secure by Default. Любая новая система должна вводиться в эксплуатацию уже с безопасными настройками: с выполненным харденингом операционных систем, выключенными ненужными сервисами, минимально необходимыми привилегиями, правильно настроенными средствами защиты и регулярной проверкой конфигурации. Практика расследований показывает, что злоумышленники гораздо чаще используют ошибки конфигурации, чем неизвестные уязвимости. А в условиях развития ИИ как инструмента ускорения взлома базовая ИБ-гигиена становится залогом выживания. Чуть расслабился — и уже взломан.
• Киберустойчивость инфраструктуры. Мы должны исходить из того, что отдельные компоненты могут быть скомпрометированы. Поэтому особое значение приобретают изолированные резервные копии, защищённые среды восстановления, сетевая изоляция Active Directory, виртуализации и системы резервного копирования, а также регулярная проверка возможности восстановления, а не только самого факта создания резервных копий.
• Автоматизация и неизменяемость инфраструктуры. Современные платформы всё чаще строятся на принципах Immutable Infrastructure, когда серверы и контейнеры не изменяются вручную, а автоматически пересоздаются из доверенных образов. Это уменьшает количество ошибок администрирования, исключает накопление небезопасных изменений и существенно снижает возможности злоумышленника закрепиться в инфраструктуре.

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

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

Алексей Акопян: Главное требование — способность отвечать не на вопрос «Что упало?», а «Почему это произошло и где именно в цепочке?». Заказчикам нужна сквозная видимость: от пользовательского запроса до конкретного вызова базы или микросервиса. Особенно остро это чувствуется в распределённых и микросервисных архитектурах, где один бизнес-процесс может проходить через десятки компонентов в разных средах.

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

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

Четвертое — проактивность. Всё больше компаний используют алертинг по SLO, механизмы выявления аномалий, предиктивную аналитику (заполнение диска, рост утилизации CPU/RAM, деградация латентности). Это помогает предотвращать инциденты до того, как они окажут влияние на пользователей.

Наиболее сложными для мониторинга остаются:

• Гибридные и мультиоблачные среды. Когда в одной организации одновременно живут on-premise (ЦОДы, гипервизоры, СХД, сети), частное облако, одно-два публичных облака со своими моделями доступа, форматами метрик и метаданных, API.
• Kubernetes и контейнерная среда. Каждый уровень абстракций генерирует тысячи метрик и гигабайты логов, из-за чего классический подход к мониторингу не работает.
• Legacy-системы. Как правило, это устаревшие бизнес-критичные системы, вмешательство в которые чревато серьёзными проблемами с производительностью или вообще отказами. Без REST API или с недокументированным API возможность инструментации отсутствует, в лучшем случае — логи или ограниченный SNMP.

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

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

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

 — Как меняется технологический стек для решения этих задач, в том числе и с точки зрения импортозамещения?

Алексей Акопян: Инструментарий мониторинга меняется вместе с инфраструктурой, подходами к разработке и эксплуатации. Какие-то продукты остаются востребованными в своих технологических доменах — тот же классический Zabbix для серверов, сети и СХД. Но для распределённых и контейнерных сред уже стали отраслевыми стандартами Prometheus, VictoriaMetrics, Loki — для K8s-проектов и OpenTelemetry — для приложений и микросервисных систем.

Технически это выглядит как разделение по слоям телеметрии. Метрики, логи и трейсы собираются через единые коллекторы — прежде всего OpenTelemetry Collector — нормализуются и дальше идут в специализированные хранилища: time-series-база для метрик, log storage для логов, trace backend для трассировки. Визуализация и алертинг, как правило, сводятся в единую точку — чаще всего в Grafana (или её аналоги). Параллельно меняется и сам способ управления мониторингом: дашборды, правила алертов и SLO оформляются как код и разворачиваются через те же практики IaC/GitOps, что и прикладная инфраструктура.

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

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

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

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

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

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

 — Расскажите об опыте вашей компании в данном направлении.

Петр Маскалюк: Наш центр мониторинга входит в топ-3 крупнейших коммерческих центров в России, СНГ и Восточной Европе. Мы работаем с более чем 90 тыс. хостов и 22 млн метрик в едином интерфейсе. Такая нагрузка позволяет видеть тренды раньше других и нарабатывать практики, которые трансформируются во внутреннюю базу знаний.

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

Алексей Акопян: Мы можем также рассказать о внедрении системы класса Application Performance Management на базе Proto Observability Platform в крупном банке.

Перед проектом стояла задача — обеспечить полную наблюдаемость бизнес-критичных приложений и внедрить практики observability непосредственно в процесс разработки и релизов. На основе Proto Observability Platform мы развернули систему класса APM, которая дала сквозную видимость всех компонентов и исключила «слепые зоны».

Что сделано:

• Поставили на мониторинг бизнес-критичные приложения, включая онлайн-банкинг, порядка 1 тыс. сервисов.
• Обеспечили стопроцентную наблюдаемость всех компонентов приложений и связанной с ними инфраструктуры — от кода до железа.
• Интегрировали observability в CI/CD и релизный процесс — качество релизов теперь оценивается по метрикам наблюдаемости до и после выкатки.

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

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

Алексей Акопян: Мы оцениваем текущий период как окно возможностей и для рынка ИТ в целом. Динамику будут определять три вектора.

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

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

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

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

Петр Маскалюк: Мы наблюдаем несколько ключевых тенденций.

• Происходит полная конвергенция ITOps и SecOps. Мониторинг и безопасность будут работать в единой связке, анализируя события в реальном времени. Это уже не гипотеза, а запрос от крупных заказчиков.
• Мониторинг обрастает бизнес-метриками. Бизнес хочет видеть не технические графики, а конверсию, проблемные зоны, потерянную выручку. APM-мониторинг внедряется всё чаще, хотя пока он дороже инфраструктурного из-за лицензий и сложности настройки.
• Гибридные и мультиоблачные среды усложняются, что требует от систем ещё большей производительности и гибкости. Мы уже видим, как стандарты вроде OpenTelemetry становятся обязательным фундаментом, без которого невозможно построить единую картину в гетерогенной среде.

 — Большое спасибо за беседу!