Контейнеризация активно развивается, а вместе с ростом популярности множатся и угрозы: атаки с использованием ИИ и человеческие ошибки в настройках доступа становятся главными вызовами для безопасности. Эксперты обсудили, как защищать контейнерные среды сегодня и чего ждать в ближайшем будущем.
- 1. Введение
- 2. Угрозы для контейнерных сред
- 3. Слабые места в контейнеризации
- 4. Какие специализированные наложенные средства помогут усилить защиту Kubernetes?
- 5. Как будет меняться ландшафт угроз для контейнерных сред?
- 6. Выводы
Введение
Контейнеризация активно вытесняет традиционные модели развёртывания приложений, и вместе с этим растёт число инцидентов, связанных с безопасностью контейнерных сред. Атаки на цепочки поставок, автоматизация взломов с использованием искусственного интеллекта, ошибки конфигурации доступа и уязвимости на уровне зависимостей формируют актуальную картину угроз. В этих условиях перед специалистами встаёт вопрос выбора эффективных методов и инструментов защиты.
В рамках эфира AM Live эксперты ведущих российских компаний обсудили, какие угрозы для контейнерных сред выходят на первый план в 2026 году и какие подходы к защите демонстрируют реальную эффективность. Дискуссия затронула как практические аспекты внедрения средств безопасности, так и перспективные направления развития отрасли.
Рисунок 1. Эксперты в студии AM Live
Участники эфира:
- Солтан Текеев, старший SRE в направлении KSPM сервиса Security Deck, Yandex Cloud.
- Станислав Проснеков, глава DevOps-департамента, Luntry.
- Никита Ладошкин, руководитель разработки PT Container Security, Positive Technologies.
- Алексей Крылов, менеджер продукта Deckhouse Kubernetes Platform по направлению информационной безопасности, «Флант».
Ведущий и модератор эфира — Руслан Иванов, директор департамента продуктового развития гибридных и частных облаков, Cloud.ru.
Угрозы для контейнерных сред
Станислав Проснеков считает, что за последние годы на первый план вышли два основных вектора угроз — атаки на цепочки поставок и автоматизация с использованием искусственного интеллекта. По его мнению, этот тренд будет только усиливаться из-за роста доступности инструментов, а последствия могут быть разрушительными: если раньше злоумышленнику приходилось выстраивать цепочки атак вручную, то теперь необходимость в этом отпадает.
Алексей Крылов напомнил о старой, но до сих пор не решённой проблеме хранения секретов: пароли по-прежнему оказываются в репозиториях. Он уверен, что универсального решения здесь нет — это комплексная задача, и теперь роботы подбирают ключи к инфраструктуре гораздо быстрее людей.
Солтан Текеев обратил внимание, что часто забывают о базовых вещах — некорректных конфигурациях, настройках по умолчанию и попытках сделать попроще, например, когда выдаются слишком широкие роли. Именно эти, казалось бы, мелочи становятся главной проблемой.
Никита Ладошкин добавил, что использование LLM превращает злоумышленника в банду джунов-хакеров — не самых умных, но очень настойчивых. По его словам, защищать теперь придётся абсолютно всё: от этапа пайпов до рантайма (от сборки и компиляции до среды выполнения).
Никита Ладошкин, руководитель разработки PT Container Security, Positive Technologies
Ошибки конфигурации доступов
Солтан Текеев уверен, что безопасность всей системы определяется её самым слабым звеном. Он рассказал, что проведённые исследования, в том числе других компаний, подтверждают: простейшие некорректные конфигурации приводят к наиболее катастрофичным последствиям. Их легко допустить и сложно заметить пользователям, тогда как атакующие находят такие ошибки без труда — чаще всего это типовые проблемы.
Станислав Проснеков сослался на исследование, согласно которому порядка 80 % проверенных кластеров содержали роли с избыточными привилегиями. По его словам, проблема усугубляется тем, что по умолчанию отключены журналы аудита, а их включение и анализ для малого и среднего бизнеса — слишком затратная задача, требующая полноценного центра безопасности (SOC). Кроме того, сами роли часто неочевидны, и проконтролировать их не всегда под силу даже самому пользователю.
Станислав Проснеков, глава DevOps департамента, Luntry
Стоит ли использовать ИИ для помощи в настройках?
Солтан Текеев: «Применять ИИ для настройки безопасности — вариант лучше, чем ничего не делать, но комплексному подходу он всё же уступает».
Станислав Проснеков: «Автоматизированная проверка ИИ-агентом — штука полезная: и явные ошибки найдёт, и настройки поправит. Это точно лучше, чем сидеть без ничего. Вот только даже минимальной уверенности в безопасности такой подход не даёт».
Никита Ладошкин: «ИИ создаст базу и сэкономит время, но перепроверять за ним придётся. Без этого никак».
Алексей Крылов: «ИИ-агент принесёт пользу, только если его обучить на качественных данных. А это процесс трудоёмкий. Даже если вдруг появится идеальный агент, доверять ему на 100 процентов нельзя.
Оптимальная стратегия — объединить его с инструментом комплаенса: пусть агент проводит первичную проверку, а комплаенс-система контролирует, не допустил ли он ошибок».
В первом опросе зрители поделились, используют ли они технологии контейнеризации в своей организации:
- Дорабатывают на базе open source — 47 %.
- Используют ванильный — 35 %.
- Используют российский коммерческий — 31 %.
- Используют зарубежный коммерческий — 7 %.
- Собираются внедрять в ближайшее время — 7 %.
- Нет и не планируют — 0 %.
Рисунок 2. Используете ли вы технологии контейнеризации в вашей организации?
Слабые места в контейнеризации
Алексей Крылов рассказал, что уязвимости берутся не только из кода, который пишут разработчики, но и из зависимостей, которые они подключают. На момент сборки приложения этих уязвимостей может не быть — они обнаруживаются позже, когда продукт уже доставлен клиентам.
Если критическая уязвимость обнаруживается в одной из зависимостей, под удар попадают все, кто использует эту версию программного обеспечения. Иногда проблема требует переписывания кода, на что уходят недели, и всё это время клиенты остаются уязвимыми. Кроме того, разработчик может подключить новую библиотеку, не подозревая о лицензионных ограничениях или закладках, которые сработают позже.
В итоге всё упирается в три фактора: человеческий фактор (навыки разработчиков), неизвестные уязвимости и время, которое становится критическим для конечного клиента.
Алексей Крылов, менеджер продукта Deckhouse Kubernetes Platform по направлению информационной безопасности, «Флант»
Станислав Проснеков добавил, что уязвимости могут скрываться не только в коде, но и в самой среде исполнения. Даже если используются опенсорсные образы, в них тоже периодически всплывают интересные находки. Поэтому контроль необходим не только за исходным кодом и зависимостями, но и за средой, в которой всё это работает.
Что означает риск нарушения изоляции контейнера?
Солтан Текеев пояснил, что сам факт нарушения изоляции контейнера — уже критическая проблема, поскольку безопасность контейнерных сред строится именно на изоляции. Благодаря ей достигается эффективность и оптимальная утилизация ресурсов, но если изоляция нарушается, следом рушатся и другие защитные механизмы.
Побег из контейнера позволяет злоумышленнику двигаться дальше — например, добраться до секретов и выйти в облако. Причём чаще всего причина кроется не в сложных уязвимостях, а в банальных некорректных конфигурациях: что-то примонтировали неправильно — и вот уже можно достать учётные данные.
Бывает и так, что сам контейнер изолирован, но внутри него хранится ненужный токен с избыточными правами, и этого достаточно, чтобы стены начали рушиться.
Солтан Текеев, старший SRE в направлении KSPM сервиса Security Deck, Yandex Cloud
Во втором опросе зрители поделились, что они используют для безопасности контейнерных сред в своей компании:
- Встроенные функции + наложенные средства (open source) — 48 %.
- Встроенные функции коммерческих платформ + наложенные средства — 29 %.
- Встроенные функции коммерческих платформ — 13 %.
- Затруднились ответить — 15 %.
- Считают это ненужным — 3 %.
Рисунок 3. Что вы используете для безопасности контейнерных сред в своей компании?
Какие специализированные наложенные средства помогут усилить защиту Kubernetes?
Солтан Текеев: «Стандартный джентльменский набор — политики (policy agent) и рантайм-защита, если до неё доросли. Но важно следить не только за самим Kubernetes, но и за тем, что его окружает. Можно защитить кластер, но если окружение остаётся открытым — толку мало. Хорошо, когда это интегрированное решение».
Станислав Проснеков: «К этому обязательно нужно добавить журналы аудита, контроль поведения субъектов и регулярный анализ всей модели привилегий. Это необходимый минимум. Без него защита времени выполнения просто не имеет смысла».
Никита Ладошкин: «Не пропускать неподписанные образы в кластер. Внедрение подписи станет хорошим дополнением к той базе, которую уже озвучили коллеги».
Алексей Крылов: «Ко всему перечисленному обязательно добавляем управление секретами. И важна не просто подпись образов, а контроль целостности — как самих образов, так и конфигураций».
Как на практике организовать контроль сборки и поставки контейнеров?
Солтан Текеев считает, что начинать выстраивание безопасности следует с непрерывного CI/CD-процесса. Когда базовый пайплайн отлажен и работает, в него можно интегрировать инструменты безопасности. Например, подпись образов — хороший вариант, но только если ключ не хранится у разработчика, за которым нет контроля.
Руслан Иванов добавил, что по сути речь идёт о полноценном DevSecOps-конвейере: от компонентного анализа, SAST, DAST и фаззинга (тестирования ПО при помощи случайных, некорректных или неожиданных входных данных) до процессов РБПО.
Руслан Иванов, директор департамента продуктового развития гибридных и частных облаков, Cloud.ru
Солтан Текеев подчеркнул, что это модульный подход — выстраивать защиту можно поэтапно, шаг за шагом. И это полезно не только для безопасности, но и для ускорения разработки и эксплуатации. Первый и главный шаг — построить базовый CI/CD, чтобы собирать и доставлять контролируемые образы.
Отвечая на вопрос о том, как оперативно проверять образы на соответствие политикам безопасности, Станислав Проснеков пояснил: на старте используем SAST — проверяем код и исходники, а также собранный Docker-образ перед подписью (чтобы не пропустить зависимости). Затем те же образы перепроверяются в рантайме. Если ресурсов недостаточно, можно ограничиться проверкой на этапе сборки и хранения. Что касается заимствованного программного обеспечения, его следует прогонять через пайплайны на этапе загрузки в реестр.
В третьем опросе выяснилось, какие функции безопасности контейнерных сред, по мнению зрителей, необходимы в первую очередь:
- Управление правами доступа — 95 %.
- Управление секретами — 78 %.
- Управление уязвимостями — 65 %.
- Контроль целостности — 65 %.
- Реестр доверенных приложений — 35 %.
- Мониторинг времени выполнения — 35 %.
- Контроль трафика — 31 %.
Рисунок 4. Какие функции безопасности контейнерных сред необходимы вам в первую очередь?
Как будет меняться ландшафт угроз для контейнерных сред?
Станислав Проснеков: «Главная угроза этого года — использование автоматизации и искусственного интеллекта для злонамеренных действий. Специфических механизмов защиты пока нет. Это не новый класс угроз, а новый способ эксплуатации старых, который позволяет ускорить и упростить атаки.
Всё, что мы можем сделать, — внедрять стандартные практики, закрывать все домены защиты и делать это максимально правильно. Да, это усложнит работу, но другого пути нет.
Что касается уязвимостей, искусственный интеллект приведёт к появлению истинно полиморфных вредоносных программ. Они не просто дописывают себя, как раньше, а адаптируются под среду быстро, качественно и через множество итераций. Те, кто до сих пор не защищает среду выполнения, будут вынуждены это делать и мониторить аномалии».
Солтан Текеев: «Если посмотреть на рынок, где-то наши решения пока отстают, но в целом CNAPP-подход становится стандартом. Речь идёт о защите не просто Kubernetes, а всей платформы целиком. В этом направлении будут улучшения, и важны решения, покрывающие всю платформу — будь то облако, интеграция с внутренними платформами или готовая платформа».
Алексей Крылов: «ИИ спровоцирует появление нового класса уязвимостей и способов их эксплуатации — не только за счёт скорости и масштабов, но и за счёт нахождения совершенно новых типов уязвимостей. Время на их обнаружение в продуктах сократится.
При этом всё уже описано в документах: есть ГОСТ 56939–2024 по безопасной разработке и два приказа ФСТЭК — №117 и №239, которые регламентируют защиту контейнерных сред и задают вектор развития».
Никита Ладошкин: «Разработка с использованием искусственного интеллекта ускоряет процессы, но одновременно повышает количество ошибок и уязвимостей. Сейчас мы находимся на подъёме контейнеризации, эта сфера активно развивается. До превращения контейнеров в стандарт ещё далеко — пройдёт лет 5–10, прежде чем это станет нормой».
Финальный опрос показал, планируют ли зрители усиливать защиту контейнерных сред после эфира:
- Будут расширять текущие меры защиты — 57 %.
- Сомневаются, считают это избыточным для себя — 18 %.
- Планируют запуск нового проекта в 2026 году — 12 %.
- Пока не видят практической пользы — 9 %.
- Ничего не поняли из того, о чём говорили эксперты — 4 %.
Рисунок 5. Планируете ли вы усиливать защиту контейнерных сред после эфира?
Выводы
Безопасность контейнерных сред в 2026 году — это уже не опция, а базовая необходимость для любой организации, использующей современную разработку. Разговор с экспертами подтвердил главный тезис: серебряной пули, способной раз и навсегда закрыть все вопросы, не существует. Защита — это всегда комплексная история, требующая внимания на всех этапах жизненного цикла приложения: от написания кода и сборки образа до его работы в кластере.
И если раньше главными врагами были конкретные уязвимости и ошибки в коде, то сегодня ландшафт угроз смещается в сторону автоматизации атак с помощью искусственного интеллекта и банальных, но оттого не менее опасных, некорректных конфигураций. Искусственный интеллект в руках злоумышленников превращает одиночек в банду, способную атаковать по всем фронтам одновременно. В этих условиях защищать приходится действительно всё: цепочки поставок, права доступа, секреты в репозиториях и саму изоляцию контейнеров.
Зрители и эксперты сошлись во мнении: основа безопасности — это управление доступом и секретами. Однако технологии — лишь половина дела. Внедрение даже самых продвинутых CNAPP-решений, сканеров уязвимостей и систем подписи образов не даст результата без выстроенных процессов и культуры DevSecOps. Ключевым становится не просто использование инструментов, а их интеграция в пайплайны разработки и постоянный контроль.
Рынок контейнеризации в России продолжает развиваться, и, судя по опросу, большинство компаний не собирается останавливаться на достигнутом, планируя расширять меры защиты. Это вселяет оптимизм: от осознания проблем отрасль постепенно переходит к их системному решению. Впереди — эра зрелых платформ и стандартизации подходов, где безопасность станет не тормозом, а неотъемлемой частью высокой скорости разработки.
Телепроект AM Live еженедельно приглашает экспертов отрасли в студию, чтобы обсудить актуальные темы российского рынка информационной безопасности и информационных технологий. Будьте в курсе трендов и важных событий. Для этого подпишитесь на наш YouTube-канал. До новых встреч!
