БДУ ФСТЭК 2025: новые угрозы для Kubernetes и контейнеров - что закрыто, что нет

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

Мы прошлись по свежим угрозам из обновлённого БДУ и отобрали те, которые напрямую касаются Kubernetes и смежных сред. Дальше - попытка честно разложить их по двум колонкам: что у нормально настроенного кластера уже закрыто, а где реально нужна новая мера.

Что появилось в БДУ

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

• Эксплуатация уязвимостей контейнерной изоляции - побеги из контейнера через уязвимости runc, container runtime, ядра Linux.
• Компрометация цепочки поставки образов - внедрение вредоносного кода в базовые образы, реестры, CI/CD-пайплайны.
• Атаки на API-сервер Kubernetes - несанкционированный доступ через незащищённый kube-apiserver, злоупотребление RBAC.
• Горизонтальное перемещение между неймспейсами - использование слабых сетевых политик для движения между изолированными средами.
• Компрометация secrets - доступ к секретам Kubernetes через атаки на etcd или через избыточные права сервис-аккаунтов.
• Denial-of-service через resource exhaustion - злоупотребление отсутствием лимитов для вытеснения легитимных нагрузок.

Это не полный список, но основные векторы, на которых сосредоточены новые угрозы.

Что уже закрыто - и чем именно

Побег из контейнера через runtime. Если платформа работает на актуальном ядре с seccomp-профилями и AppArmor, а runtime регулярно обновляется - угроза известная и в большинстве случаев закрытая. Deckhouse и похожие дистрибутивы поставляют hardened-конфигурацию out of the box. Где это не так - вопрос не новый, а просто теперь он прописан в БДУ с идентификатором.

Несанкционированный доступ к kube-apiserver. Если apiserver закрыт сетевым периметром и принимает только авторизованные подключения - базовая угроза уже адресована. То же касается включённого аудит-лога: событие несанкционированного доступа фиксируется, SIEM это видит.

DoS через resource exhaustion. Для кластеров с настроенными LimitRange и ResourceQuota на уровне неймспейсов - угроза в значительной степени снята. Не полностью: приоритеты и PriorityClass добавляют ещё один слой, и не у всех он настроен, но сам контроль лимитов в сознательно настроенном кластере обычно есть.

Что реально требует новых мер

Компрометация цепочки поставки образов. Это - наиболее неприятный блок. Угроза предполагает, что вредоносный код попадает в базовый образ или в зависимость до того, как образ попадает в реестр. Если нет систематической проверки подписей образов при деплое (admission webhook + cosign verify), если нет сканирования на уязвимости в пайплайне - эта угроза в модели угроз есть, а компенсирующей меры нет. У большинства клиентов, которых мы видели на аудитах, поверхностное сканирование образов есть, а верификации подписей при деплое - нет.

Горизонтальное перемещение через слабые сетевые политики. NetworkPolicy в Kubernetes - это opt-in механизм. Без явно заданных политик весь трафик между подами в кластере открыт. Это не проблема, которую закрывает что-то «по умолчанию» - нужны явные политики deny-all + allow-listed. Если проект завозился без этого требования с самого начала, добавление политик задним числом - трудоёмкая работа, потому что нужно инвентаризировать все реальные потоки.

Атаки через избыточные права сервис-аккаунтов. Минимизация прав для сервис-аккаунтов (принцип least privilege в RBAC) декларируется везде, но на практике очень часто сервис-аккаунты создаются с широкими правами «чтобы работало» и потом не пересматриваются. Новые угрозы БДУ прямо называют это вектором. Нужен периодический аудит RBAC и желательно - OPA/Gatekeeper-политики, запрещающие создание сервис-аккаунтов с правами cluster-admin.

Доступ к секретам через etcd. Если etcd не зашифрован at-rest (encryption at rest для Secrets), а резервные копии etcd хранятся без дополнительной защиты - это живой вектор. Kubernetes умеет шифровать secrets в etcd через EncryptionConfiguration, но это не включено по умолчанию, и на старых кластерах часто не включено вообще.

Практический вопрос: что с этим делать

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

Минимальный путь - пройтись по новым угрозам БДУ и для каждой зафиксировать: либо «закрыто, вот чем именно», либо «не закрыто, вот планируемая мера». Это delta-обновление модели угроз, не переписывание с нуля. Для тех, кто работает на Deckhouse или RedOS Kubernetes - часть «закрыто» будет длинная, потому что там hardening-профиль идёт в комплекте. Для кастомных кластеров на ванильном Kubernetes или на платформах без сертификации - картина обычно хуже.

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