Кирилл Рудик, Cloud X: Миграция в облако не означает автоматической защиты всех систем клиента

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

Кирилл Рудик, главный архитектор по кибербезопасности Cloud X, в интервью для Cyber Media рассказал, как меняется ландшафт облачных угроз, какие риски связаны с Kubernetes и cloud-native архитектурами и какие технологии уже в ближайший год могут стать стандартом де-факто в сфере облачной безопасности.

Cyber Media: Какие изменения в ландшафте атак на облачную инфраструктуру за последний год вы считаете наиболее критичными? И есть ли угрозы, которые особенно характерны именно для российского рынка?

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

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

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

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

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

Подавляющее большинство случаев — порядка 95–99% — по-прежнему связано с действиями клиента

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

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

На практике возникает несколько взаимосвязанных групп рисков:

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

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

Cyber Media: Классическая модель shared responsibility между клиентом и облачным провайдером по-прежнему остается источником инцидентов. Как эта модель изменилась к 2026 году, и в каких зонах ответственности сегодня чаще всего происходят ошибки — на стороне клиента или провайдера?

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

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

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

Cyber Media: Современные облачные платформы активно используют open-source компоненты и сторонние сервисы. Где проходит граница контроля провайдера, и какие подходы действительно работают, а какие остаются скорее декларацией?

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

Показательным примером стал инцидент с бэкдором в XZ Utils (CVE-2024-3094) — один из самых изощренных случаев атаки на цепочку поставок. Злоумышленник под псевдонимом «Jia Tan» в течение примерно 2,5 лет последовательно внедрялся в проект: с декабря 2021 года он вносил легитимные коммиты, а в сентябре 2022 года получил права мейнтейнера после ухода первоначального разработчика.

Для снижения подобных рисков провайдеры применяют многоуровневую стратегию работы с open-source компонентами, которая включает:

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

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

Cyber Media: Почему в динамичных средах вроде Kubernetes, контейнеров и serverless традиционные средства защиты теряют эффективность, и к каким принципам защиты рынок пришел к 2026 году?

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

• Периметр исчезает. Межсетевые экраны, настроенные на конкретные IP-адреса и порты, теряют эффективность. Граница безопасности смещается к рабочей нагрузке — контейнеру, pod, сервису или функции.
• Время жизни сокращается. В serverless-средах оно измеряется секундами или миллисекундами. Сбор логов и установка антивирусных агентов становятся малоэффективными: процессы, окружения и данные исчезают быстрее, чем завершается анализ.
• Скорость изменений растет. Частые релизы в парадигме CI/CD превращают ручные проверки безопасности в узкое место. Безопасность должна быть встроена в конвейер разработки и работать со скоростью кода.
• Сложность возрастает. Многослойные приложения, sidecar-контейнеры, service mesh и динамическая оркестрация делают традиционные системы обнаружения вторжений (NGFW, IDS/IPS) малоэффективными. Трассировка трафика классическими средствами становится затруднительной.
• Поверхность атаки расширяется. Помимо операционных систем и приложений защите подлежат конфигурация оркестратора (API-сервер, etcd), образы и реестры контейнеров, пайплайны сборки, политики service mesh, managed-сервисы и код инфраструктуры (IaC). Уязвимости могут возникать уже на этапе описания инфраструктуры, а традиционные сканеры обнаруживают их слишком поздно.

В ответ на эти изменения отрасль пришла к консенсусу относительно ключевых принципов защиты, которые легли в основу платформ Cloud-Native Application Protection Platform. Речь идет о применении принципа нулевого доверия — Zero Trust — для рабочих нагрузок, при котором ни один сервис не доверяет другому по умолчанию даже в пределах одного кластера. Существенную роль играет автоматизация проверок безопасности в DevSecOps: статический анализ кода (SAST), анализ зависимостей (SCA) и динамический анализ (DAST) встроены непосредственно в пайплайн разработки.

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

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

Cyber Media: Один из чувствительных вопросов — доступ администраторов облака к данным клиентов. Каков реальный объем этого доступа сегодня, и насколько такие технологии, как Confidential Computing, позволяют гарантировать, что даже провайдер не имеет доступа к данным?

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

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

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

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

Cyber Media: На фоне дефицита квалифицированных специалистов автоматизация и SOAR-подходы становятся ключевыми элементами защиты. Где проходит граница доверия к алгоритмам, и какие решения вы бы лично не стали полностью отдавать автоматике даже сейчас?

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

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

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

Практически это может выражаться в многоуровневой системе принятия решений:

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

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

Cyber Media: Если заглянуть на год вперед, какая технология в области облачной безопасности сегодня выглядит экспериментальной, но уже в ближайшее время может стать стандартом де-факто?

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

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

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