Контейнеризация стала стандартом, но традиционная сетевая безопасность не видит трафик внутри Kubernetes: IP-адреса эфемерны, а контейнеры живут меньше минуты. Эксперты в студии AM Live обсудили, как защитить контейнерную инфраструктуру с учётом требований 117-го приказа ФСТЭК России.
- 1. Введение
- 2. В чём секрет популярности контейнеризации?
- 3. Проблемы сетевой безопасности в Kubernetes
- 4. Как атакуют контейнеры и Kubernetes?
- 5. Требования ФСТЭК России: приказ № 117
- 6. Как строить защиту Kubernetes?
- 7. Выводы
Введение
Контейнеризация и Kubernetes стали стандартом для современных ИТ-инфраструктур — по мировым данным, более 80 % компаний используют контейнеры в продуктиве. Однако с переходом на микросервисную архитектуру традиционные подходы к сетевой безопасности перестали работать: внутри кластера трафик не виден для классических межсетевых экранов, а IP-адреса стали временным атрибутом. При этом регулятор в лице ФСТЭК России уже ввёл требования по защите контейнерных сред, игнорировать их больше нельзя.
Эксперты вендоров, разработчиков платформ контейнеризации и крупных заказчиков собрались в студии AM Live, чтобы обсудить, что изменилось в сетевой безопасности с приходом Kubernetes, какие угрозы возникают внутри контейнерной среды и как строить защиту с учётом требований 117-го приказа ФСТЭК России.
Рисунок 1. Эксперты в студии AM Live
Участники эфира:
- Константин Аксёнов, директор департамента разработки Deckhouse, «Флант».
- Павел Коростелёв, руководитель направления стратегического маркетинга, «Код Безопасности».
- Виталий Медведев, директор по ИБ (CISO), ГК «Медси».
- Николай Панченко, руководитель направления защиты рантайма, «Т-Банк».
- Дмитрий Шарапов, управляющий директор по информационной безопасности, ДОМ.РФ.
- Евгений Тарелкин, ведущий эксперт, «Код Безопасности».
Ведущий и модератор эфира — Илья Шабанов, генеральный директор «АМ Медиа».
В чём секрет популярности контейнеризации?
Виталий Медведев назвал два ключевых драйвера популярности контейнеризации: удобство и экономия вычислительных ресурсов. Контейнеры упаковывают приложение со всеми зависимостями, обеспечивая кросс-платформенность. Экономический драйвер — контейнеризация позволяет использовать «железо» более эффективно, чем виртуализация.
Константин Аксёнов отметил, что Kubernetes даёт возможность описывать инфраструктуру как код и управлять ею из Git. Вся экосистема Cloud Native Foundation предоставляет огромный набор инструментов для запуска любых нагрузок — от баз данных до очередей. Разработчикам удобнее поставлять софт заказчикам через контейнер.
Константин Аксёнов, директор департамента разработки Deckhouse, «Флант»
Николай Панченко добавил, что контейнеры — это виртуализация внутри одной операционной системы и защищать их нужно иначе. Но в этом есть и плюсы: можно использовать эшелонированный подход, усиливая защиту внутри контейнерной среды. Это более эффективно с точки зрения безопасности.
Павел Коростелёв упомянул концепцию иммутабельной инфраструктуры: контейнеры живут недолго, и в случае проблем их проще пересоздать, чем чинить, что повышает стабильность всей системы.
Кроме того, можно сравнительно просто перенести нагрузку со своей площадки в облако, чему способствует декларативное описание инфраструктуры. Проще и масштабирование — оно происходит на уровне кода, процессом занимается сама платформа, и при этом она предоставляет больше инструментов, чем платформа виртуализации.
Дмитрий Шарапов отметил, что главный драйвер перехода на контейнеризацию — это скорость вывода продуктов на рынок. Микросервисная архитектура позволяет обновлять сервисы незаметно для клиента, в отличие от монолита.
Евгений Тарелкин обратил внимание на динамику роста российского рынка контейнеризации. Согласно представленной статистике, рынок измеряется в миллиардах рублей и, по мнению аналитиков, будет расти очень динамично в ближайшие годы.
Евгений Тарелкин, ведущий эксперт, «Код Безопасности»
Эксперт отметил, что хотя текущие цифры нельзя назвать скромными, по сравнению с рынком виртуализации они меньше. При этом наблюдается массовое доминирование отечественных вендоров: доля зарубежных решений сильно уменьшается от года к году. Через три-четыре года, по прогнозам, рынок вырастет более чем в три раза — к 2030 году цифры станут огромными.
Рисунок 2. Рынок контейнеризации
Евгений подчеркнул, что этот рост будет завязан на регуляторику, поскольку государство продвигает отечественное ПО для защиты критических сфер — банковского сектора, медицины, логистики. Однако драйверов может быть много: не только регуляторика, но и экономика, которая заставляет компании искать более эффективные решения, а также возможность лёгкого развёртывания в облаках.
В первом опросе выяснилось, насколько широко зрители используют контейнеризацию:
- Пока не используют контейнеры — 34 %.
- Используют контейнеры для отдельных систем — 32 %.
- Пилотируют и готовятся к внедрению — 16 %.
- Большая часть приложений уже работает в контейнерах — 11 %.
- Используют только в разработке и тестировании — 7 %.
Рисунок 3. Насколько широко вы используете контейнеризацию?
Проблемы сетевой безопасности в Kubernetes
Павел Коростелёв объяснил, что в Kubernetes происходит смешение защиты приложений и инфраструктуры. Инфраструктура описывается как код, и безопасник перестаёт видеть, что происходит внутри кластера. Сетевые пакеты уходят в оверлей, а IP-адрес становится временным атрибутом.
Для сетевика Kubernetes выглядит как чёрный ящик с непонятной структурой. Видно только трафик, который выходит за пределы кластера (север — юг), а то, что происходит внутри (восток — запад), невидимо. При этом по умолчанию все контейнеры в рамках кластера видят друг друга — нужно целенаправленно запрещать нежелательные взаимодействия.
Рисунок 4. Проблемы гибридной сетевой инфраструктуры
В кластере есть две основные сущности: андерлей (underlay) — физическая сеть, IP-адресация узлов (нод), которую видит сетевик, — и оверлей (overlay), виртуальная сеть, в которой живут контейнеры и поды. Оверлей работает поверх андерлея и обеспечивает связность между контейнерами на разных узлах.
Для сетевого администратора, который смотрит на физические интерфейсы, оверлейный трафик выглядит как непонятный поток пакетов: неясно, какие именно контейнеры и как взаимодействуют внутри. IP-адреса в оверлее — это временные атрибуты, они не привязаны к конкретному устройству и могут меняться каждую минуту.
Рисунок 5. Сетевая инфраструктура внутри оверлея
Эксперт выделил три основные задачи сетевой безопасности в Kubernetes:
- Обеспечение прозрачности — понимание того, какие сервисы взаимодействуют и как именно.
- Обеспечение изоляции — разграничение доступа между приложениями разного уровня критической значимости.
- Обнаружение аномалий — выявление подозрительных взаимодействий между микросервисами.
Чтобы понять, что происходит внутри, и обеспечить изоляцию, нужно использовать инструменты уровня платформы: CNI-плагины, сетевые политики, Service Mesh. Традиционные средства сетевой безопасности, работающие на уровне IP-адресов и физических интерфейсов, здесь не работают — они просто не видят трафик внутри оверлея.
Илья Шабанов привёл интересную статистику. По данным компании Sysdig, которая собирает телеметрию с миллионов контейнеров по всему миру, в 2025 году 60 % контейнеров жили всего одну минуту или меньше. Если усреднить, то время жизни контейнера составляет около минуты. Это кардинально меняет правила игры для сетевой безопасности, потому что IP-адреса становятся эфемерными сущностями.
Сетевик, привыкший оперировать статичными IP-адресами и сегментами, не может быть уверен на 100 %, что у него внутри контейнера живёт на данный момент, и не может контролировать трафик привычными способами. Именно поэтому традиционные подходы к сетевой безопасности в Kubernetes просто не работают.
Николай Панченко уточнил, что понимание приходит, когда разбираешься в уровнях абстракции Kubernetes — подах, контейнерах, сервисах. Если привязываться не к IP-адресам, а к логическим сущностям, всё становится понятнее. В его компании перешли на L7-политики, что позволяет сетевикам управлять доступом на уровне приложений и DNS-имён. CNI-плагины дают возможность контролировать взаимодействие оверлея и андерлея, а инструменты обеспечения видимости (observability) на базе eBPF позволяют построить полную карту взаимодействия всех сервисов во времени, если настроить сбор логов.
Во втором опросе зрители рассказали, как организована сетевая защита Kubernetes в их компании (мультивыбор):
- Используют NGFW — 32 %.
- Используют собственные или опенсорсные инструменты — 16 %.
- Используют вендорские наложенные средства защиты — 11 %.
- Используют Kubernetes NetworkPolicy (CNI) — 7 %.
- Используют Service Mesh — 3 %.
- Ничего не делают — 21 %.
- Kubernetes отсутствует — 46 %.
Рисунок 6. Как организована сетевая защита Kubernetes в вашей компании?
Как атакуют контейнеры и Kubernetes?
Виталий Медведев описал последствия компрометации. Если злоумышленник скомпрометировал под, ему нужно подумать, как выбраться на уровень ноды. В 2025 году было всего несколько критических уязвимостей, позволяющих осуществить побег из контейнера, но они существовали. Если скомпрометирована рабочая нода (worker), злоумышленник видит все поды внутри неё и может использовать сервис-аккаунт ноды для дальнейшего перемещения.
Если же скомпрометирована мастер-нода — это критическая ситуация, злоумышленник получает полный контроль над кластером. Виталий отметил, что если вредоносный код уже сидит в образе, то решить проблему пересозданием скомпрометированного пода не удастся — вредонос развернётся снова.
Павел Коростелёв подчеркнул, что задача хакера — найти уязвимость, которую можно проэксплуатировать. В случае с Kubernetes скорость изменения контейнерной среды кратно выше, чем в традиционной инфраструктуре, что создаёт дополнительные риски.
Илья Шабанов привёл данные исследований: согласно отчёту Unit 42, почти в каждом пятом расследовании эксфильтрация данных начиналась в течение первого часа после компрометации. Это означает, что скорость детектирования и реагирования критически важна, и именно сетевые политики позволяют выиграть это время. Без них злоумышленник выйдет к соседним сервисам практически мгновенно.
Илья Шабанов, генеральный директор «АМ Медиа»
Константин Аксёнов описал векторы атак на контейнерную инфраструктуру. Первый и наиболее опасный вектор — атака на цепочку поставок, когда вредоносный код зашивается в образ контейнера, а затем разворачивается в продуктиве.
Второй вектор — атака на конвейер CI / CD: если разработчик или внешний подрядчик получает доступ к GitLab или другому репозиторию и коммитит небезопасный код, который сразу уходит в продуктив, это может привести к компрометации.
Третий вектор — когда злоумышленник уже попал внутрь контейнера через известную уязвимость и пытается выйти за его пределы. Здесь появляется специфическая для Kubernetes атака через сервис-аккаунт: если у пода слишком широкие права, можно создать новый под с расширенными привилегиями и получить доступ к тому, что не разрешено обычному поду. Также возможна подмена DNS для обхода сетевых политик.
Николай Панченко добавил, что существуют атаки на уровне процессора и «железа», о которых большинство безопасников даже не подозревают. Через специальные контроллеры в обход ядра или путём прямой атаки на процессор злоумышленник может захватить всю физическую машину, а если это виртуализация — все виртуальные машины на ней. В таком случае нарушается изоляция между зонами критической значимости и злоумышленник получает доступ ко всем данным на устройстве. Единственный способ защиты — правильное проектирование архитектуры с учётом изоляции на уровне «железа».
Требования ФСТЭК России: приказ № 117
Павел Коростелёв рассказал о новых требованиях к защите государственных информационных систем (ГИС) и иных информационных систем государственных органов (ИСГО). В приказе № 117 и обновлённых методических рекомендациях появился целый блок требований по защите контейнеризации. Теперь объектом защиты становится не сетевой хост и не среда виртуализации, а среда контейнеризации. Нужно контролировать доступ администраторов, целостность всех компонентов, включая образы контейнеров.
При этом в приказе № 117 есть меры, которые напрямую к среде контейнеризации не относятся, но очень сильно влияют на всю инфраструктуру. Это меры по межсетевому экранированию (МСЭ-1, МСЭ-3) и организации «демилитаризованной зоны» (МСЭ-2). МСЭ-1 говорит о необходимости выделять сегменты и фильтровать трафик между ними. МСЭ-2 требует организации DMZ не только с интернетом, но и между двумя произвольными системами разного уровня критической значимости — если системы относятся к разным классам, они должны взаимодействовать только через DMZ.
Также есть мера ЗКС.2, которая требует использования атрибутов безопасности: нужно ориентироваться не на IP-адрес, который легко подделать, а на атрибут, однозначно идентифицирующий сетевой хост. Следует помнить и о мерах СОВ-1 и СОВ-2 — обнаружение вторжений между сегментами.
Павел Коростелёв, руководитель направления стратегического маркетинга, «Код Безопасности»
Павел также отметил, что в мере МСЭ-1 есть усиление: для первого класса необходимо реализовывать микросегментацию, когда сеть делится на большое количество атомарных сегментов и между ними всеми должна стоять система обнаружения вторжений. Всё это вместе создаёт весьма интересную картину: нужно очень внимательно следить за сегментацией и в традиционной сети, и в среде виртуализации, и в среде контейнеризации.
Вдобавок средства, которыми это делается, должны быть сертифицированы по профильным классам. Как в случае с сертифицированной операционной системой — недостаточно просто её использовать, нужны дополнительные сертифицированные средства для сетевой безопасности.
Павел также подчеркнул важность проверяемости сегментации: нужно не просто один раз всё настроить, а иметь средство, которое в любой момент может показать, что сегментация реально работает. При продаже в энтерпрайз часто рекламируется не функциональность защиты, а функциональность аудита, потому что когда приходят служба внутреннего контроля или иные аудиторы, им нужно быстро продемонстрировать, что ты соответствуешь требованиям.
Дмитрий Шарапов отметил, что 117-й приказ — это серьёзный вызов для многих организаций, которые раньше не сталкивались с требованиями к ГИС. Теперь необходимо аттестовывать всю инфраструктуру, а это может потребовать серьёзных архитектурных изменений.
Дмитрий Шарапов, управляющий директор по информационной безопасности, ДОМ.РФ
Виталий Медведев добавил, что перед CISO не стоит вопрос, выполнять требования или нет. Вопрос в том, как их выполнить с наибольшей пользой для бизнеса. Один из подходов — вынести аттестованный модуль в отдельный кластер, что проще и эффективнее.
В третьем опросе зрители назвали задачи сетевой безопасности контейнерной инфраструктуры, которые для них наиболее актуальны (мультивыбор):
- Сегментация и изоляция приложений — 82 %.
- Выявление аномальной сетевой активности — 58 %.
- Видимость и контроль сетевого трафика — 53 %.
- Контроль взаимодействия контейнеров с внешней инфраструктурой — 47 %.
Рисунок 7. Какие задачи сетевой безопасности контейнерной инфраструктуры для вас наиболее актуальны?
Как строить защиту Kubernetes?
Николай Панченко пояснил, как строится сегментация в Kubernetes на практике. На первом этапе изолируют пространства имён (namespaces) друг от друга, чтобы контейнеры в одном пространстве не могли атаковать соседние приложения. Управление лейблами и селекторами позволяет контролировать доступ на уровне подов — но при этом важно понимать, что сетевые политики могут быть как уровня пространства имён, так и уровня кластера в целом (cluster-wide).
В последнем случае политики позволяют задать общие правила для всех пространств имён сразу — например, доступ к DNS или к системным сервисам. Это даёт возможность не прописывать одни и те же правила в каждом пространстве вручную, а управлять ими централизованно.
Отдельный важный момент: у пользователей забирают возможность назначать лейблы на пространство имён, даже если они им владеют. Это позволяет контролировать атаки через сервис-аккаунты и не даёт злоумышленнику подменить лейбл, чтобы обойти сетевые политики. Вся защита строится на понимании того, как работает конкретная нагрузка: куда она может ходить, от кого может получать трафик.
Николай Панченко, руководитель направления защиты рантайма, «Т-Банк»
Ключевым элементом здесь является глубокая интеграция с CNI: нужно понимать, как работает конкретный CNI-плагин, на какие селекторы или лейблы он реагирует, как настраивается. В разных CNI есть разные варианты настройки, позволяющие реализовать микросегментацию.
При этом микросегментация — дорогостоящий процесс с точки зрения производительности. Если вы хотите скорости, то работайте на уровне пространства имён. Если хотите качества, с микросегментацией почти на уровне «точка — точка», то используйте возможности CNI с контролем лейблов для каждого пода.
Виталий Медведев рассказал об инструментах обеспечения видимости — сборе и корреляции данных о трафике внутри контейнерной среды и за её пределами. Только так можно получить единую картину движения данных. Он отметил, что для этого существуют как опенсорсные инструменты (например, Falco), так и коробочные решения вроде CSM / CSD, которые позволяют обеспечивать видимость внутри контейнеров.
Есть также специализированные разработки класса Container Security, которые на рынке уже более восьми лет. Изначально это были инструменты именно для сетевой безопасности контейнеров, потом появились комбайны, которые добавили рантайм-защиту. В базовом Kubernetes видимость «из коробки» не очень удобна: можно разграничить трафик через CNI-плагины, но полноценной картины движения данных не получишь. Однако с помощью опенсорсных или коробочных решений этого можно добиться.
Виталий Медведев, директор по ИБ (CISO), ГК «Медси»
При этом важно не ограничиваться только Kubernetes, потому что хочется видеть трафик и за пределами кластера — в классической инфраструктуре. Микросервисы часто обращаются к базам данных, которые находятся не в Kubernetes, а на обычных серверах. Поэтому приходится обращаться к решениям, которые позволяют объединить видимость внутри контейнерной среды с видимостью в традиционной инфраструктуре и получить единую картину.
Евгений Тарелкин представил планы развития продукта vGate. Компания отходит от концепции накладного СЗИ и позиционирует продукт как межсетевой экран и средство обнаружения вторжений для виртуальной, контейнерной и облачной сред. В версии 5.3, которая выйдет в ноябре 2026 года, появится поддержка защиты контейнеров, облачных сред на базе OpenStack и мультиарендности.
vGate закрывает требования по межсетевому экранированию и обнаружению вторжений, а также поддерживает сегментацию на всех уровнях — физическом, виртуальном, контейнерном и облачном. Компания идёт к созданию единой системы сегментации, которая закроет все задачи заказчика.
Рисунок 8. Дорожная карта vGate на 2026–2028 гг.
Финальный опрос показал, как, по мнению зрителей, должна строиться сетевая безопасность контейнерной инфраструктуры:
- Подход зависит от архитектуры и критической значимости систем — 47 %.
- Нужна единая система защиты для контейнеров, виртуальных машин и физической инфраструктуры — 17 %.
- Достаточно Kubernetes NetworkPolicy (CNI) — 12 %.
- Нужна связка Kubernetes NetworkPolicy + NGFW — 7 %.
- Нужны вендорские накладные средства защиты — 6 %.
- Затруднились ответить — 11 %.
Рисунок 9. Как должна строиться сетевая безопасность контейнерной инфраструктуры?
Выводы
Сетевая безопасность контейнерной инфраструктуры оказалась не просто технической темой, а полноценным вызовом для индустрии, требующим пересмотра привычных подходов. Старые методы здесь не работают, а новые требуют не только инструментов, но и перестройки мышления.
Безопасность в Kubernetes невозможна без понимания архитектуры. Нельзя просто поставить «коробку» на периметре и надеяться, что она защитит. Нельзя сегментировать по IP-адресам, которые меняются каждую минуту. Нельзя оставлять пространства имён открытыми по умолчанию. Всё, что работало в монолитной и виртуализированной инфраструктуре, требует переосмысления. Это касается не только технических решений, но и организационных процессов — взаимодействия между разработчиками, DevOps-инженерами и безопасниками.
Регуляторика больше не догоняет технологии, а идёт с ними в ногу. 117-й приказ ФСТЭК России вводит требования по защите контейнерных сред. Контейнеры стали настолько значимыми, что государство обратило на них внимание. Для одних компаний это станет драйвером развития, для других — серьёзным вызовом, требующим аттестации и архитектурных изменений.
Рынок находится в начальной стадии формирования. Вендоры только начинают выпускать продукты для защиты контейнеров, заказчики наращивают компетенции, регулятор уточняет требования. Впереди большой путь, и те, кто начнёт его раньше, получат преимущество.
Разговор о сетевой безопасности Kubernetes — это разговор о зрелости компании. Готовность вкладываться в архитектуру, обучение и правильные инструменты определяет, сможет ли организация безопасно использовать современные технологии или останется заложником устаревших подходов.
Телепроект AM Live еженедельно приглашает экспертов отрасли в студию, чтобы обсудить актуальные темы российского рынка ИБ и ИТ. Будьте в курсе трендов и важных событий. Для этого подпишитесь на наш YouTube-канал.
