Kubernetes-аудит после Wiz и Prisma: как живут без CNAPP в 2026

Если коротко — плохо живут.

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

С чего всё началось

В 2022–2024 западные CNAPP-платформы закрыли доступ для российских компаний. Wiz, Prisma Cloud, Lacework, Orca — все они либо ушли сами, либо отвалились после санкций. Кто работал с этими инструментами, тот помнит — это была основная рабочая лошадка для аудита Kubernetes в облаке.

Для Сбера, Яндекса, Т-банка это, конечно, неприятно, но не критично. У них собственные команды по 20+ человек, которые без особого напряжения собрали свой стек на коленке из OPA, Falco, Trivy и пары собственных контроллеров.

А вот для всех остальных — банков второго эшелона, финтеха, госкомпаний — стало больно. Команда безопасности из 1–3 человек, K8s в проде, аудит ФСТЭК через три месяца. Wiz был — Wiz кончился. Что показывать аудитору?

Как это выглядит сейчас, если честно

Поговорил с парой знакомых из таких команд. Картинка примерно одинаковая:

• kubectl get pods --all-namespaces -o yaml и глазами

• какие-то bash-скрипты, которые написал бывший сотрудник, и теперь никто не помнит, что они проверяют

• OPA/Kyverno стоит, но это admission control — он блокирует на входе, а не отвечает на вопрос «что у вас сейчас в кластере и почему»

• Trivy в CI прогоняется, отчёты складываются куда-то в S3 и больше их никто не открывает

• надежда, что аудитор не спросит про привилегированные ServiceAccount

Спросит. Особенно после марта 2026.

Что изменилось с Приказом №117

1 марта 2026 года вступил в силу Приказ ФСТЭК №117. Он заменил Приказ №17, по которому большинство госорганизаций жили с 2013 года. Это не косметическое обновление — в №117 впервые контейнеризация и микросервисная архитектура выделены в отдельную группу мер защиты (всего таких групп стало 18 против прежних 14).

Что это значит на практике для тех, у кого K8s в проде и кто работает с гос- или регулируемыми системами:

• сканировать активы (включая контейнеры) надо не реже раза в месяц, критические уязвимости — устранить за 24 часа

• привилегированный доступ — отдельный контроль, регистрация всех действий обязательна

• показатели эффективности защиты (Кзи раз в полгода, Пзи раз в два года) надо отправлять регулятору с доказательной базой

Без какого-то инструмента, который выдаёт документ, всё это превращается в ад с экселями. Который, к слову, аудитор может не принять.

Параллельно жив Приказ №21 для коммерческих обработчиков ПДн и ГОСТ Р 57580 для финсектора — там тоже есть свои контроли, которые формулируются в терминах привилегий, сегментации и анализа уязвимостей. Если ты банк второго эшелона — №117 на тебя не распространяется, но контролы УПД и АНЗ из №21 и 57580 формулируют ровно те же требования другими словами.

Что я смотрел, прежде чем сесть писать своё

Очевидный вопрос — а что, нельзя взять open source? Можно. И я брал.

• Kubescape — хорош. Гоняет проверки по NSA/CISA, MITRE ATT&CK, выдаёт списки несоответствий. Но фреймворки западные. Маппинга на ФСТЭК нет и не будет.

• kube-bench — CIS Benchmark, очень узкая задача (хардненинг control plane). Полезно, но это одна десятая того, что нужно для аудита.

• Trivy — отличный сканер CVE, я его в итоге внутрь и затащил как библиотеку. Но это сканер образов, не аудит кластера.

• Polaris — best practices конфигов. Помогает в CI, но это не compliance.

• Kaspersky Container Security (из реестра Минцифры) — runtime-защита и сканирование образов. CSPM/posture-management с graph-based детекцией там нет. Плюс цена.

• НОТА КУПОЛ.Контейнеры — новый игрок, зарегистрирован в ноябре 2024. По публичной информации — тоже скорее runtime-защита.

Каждый из этих инструментов делает свою часть хорошо. Но ни один не отвечает на главный вопрос инженера ИБ из средней компании: «как мне сгенерировать документ, который примет аудитор ФСТЭК?»

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

Что я пишу

Инструмент называется ShieldOps. CLI-сканер Kubernetes, без агента, без SaaS, без облака — запускается локально на машине инженера или в CI.

shieldops scan --kubeconfig ~/.kube/config --output report.html

Что происходит под капотом:

1. Сбор инвентаря. Через client-go читаются pods, deployments, statefulsets, serviceaccounts, roles, rolebindings, clusterrolebindings, secrets, configmaps, services, networkpolicies. Только read API — никакого admission, никакого webhook, ничего, что могло бы повлиять на кластер.

2. Граф. Всё это укладывается в PostgreSQL как граф с типизированными рёбрами:

• USES_SA — pod использует ServiceAccount

• BOUND_TO_ROLE — SA забинден на роль

• MOUNTS_SECRET — pod монтирует секрет

• EXPOSED_VIA — pod достижим через сервис/ingress

• CAN_REACH — сетевая достижимость

Получается компактная модель кластера, на которой удобно искать цепочки.

3. Детекторы. Вот тут начинается интересное. Я ищу не отдельные нарушения, а именно цепочки, которые по отдельности выглядят как «ну, бывает», а вместе складываются в attack path.

Например, один pod с privileged: true — это просто warning. Бывает у legitimate workloads (storage, network plugins). Но если этот же pod монтирует cluster-admin ServiceAccount, и имеет hostNetwork, и к нему есть LoadBalancer — это уже не warning. Это сценарий, в котором компрометация одного пода даёт компрометацию всего кластера через 30 секунд.

Сейчас в MVP реализовано три таких комбинации:

• internet_exposed_pod_with_cve — pod, доступный снаружи + критический CVE в образе

• cluster_admin_sa_in_pod — ServiceAccount с cluster-admin, смонтированный в работающий pod

• secret_in_internet_exposed_pod — секрет, смонтированный в pod, достижимый из интернета

Каждое срабатывание выдаёт текстовое описание attack path: что куда смонтировано, что куда торчит, что в образе.

4. CVE. Trivy подключён как Go-библиотека, без отдельного бинаря и без демона. Сканит образы из spec пода, тянет данные из своей БД.

5. Отчёт. HTML с группировкой по pod, с разделом «маппинг на контроли» — пока черновой, перепишу после консультации с аудитором (об этом ниже).

Первый прогон на живом кластере

Тестовый стенд на Proxmox, три ноды, конфигурация близкая к продовой (есть Prometheus, Loki, пара бэкендов и фронт). Получилось:

• 221 asset собрано

• 88 рёбер в графе после построения

• 2 finding: оба про секреты, смонтированные в Prometheus pod, который оказался доступен через NodePort. Никто не помнил, что NodePort там вообще есть — открыли когда-то для отладки, забыли закрыть.

Это, на самом деле, типичный сценарий. Не «хакеры взломали», а «забыли». Граф находит «забыли» довольно эффективно.

Compliance-маппинг — отдельный сюжет

Самая сложная часть — не сканер, а маппинг находок на контроли. У меня есть черновой маппинг на УПД.4, УПД.13, АНЗ.1 (это терминология Приказа №17, она же повторяется в №21). Для №117 структура другая, и часть формулировок поменялась — переписываю.

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

Чего здесь нет и не будет

Чтобы сразу снять ожидания: ShieldOps — это не

• runtime-защита (Falco, Tetragon делают это лучше)

• admission controller (OPA/Kyverno делают это лучше)

• SIEM или SOAR

• replacement для Trivy в CI (он там и так работает, я просто переиспользую его БД)

Это снимок состояния кластера на момент скана + интерпретация в терминах compliance. Один артефакт, который кладёшь на стол аудитору.

Стек и статус

Go 1.24, client-go, PostgreSQL, Trivy как библиотека. MVP работает, репозиторий открыт: github.com/bigAboo80/shieldops.

Что в роадмапе:

• завершить маппинг на №117 (и оставить совместимость с №17 для тех, кто на старой редакции до сентября 2026)

• маппинг на ФСТЭК 21

• PDF-экспорт (для предъявления аудитору HTML-отчёта недостаточно, нужен подписываемый PDF)

• delta-отчёты — что изменилось с прошлого скана, какие риски устранены, какие появились

ЦБ ГОСТ Р 57580 — отдельная тема, не уверен, что попадёт в ближайшую итерацию. Если ты из банка и тебе это нужно — тоже напиши, обсудим.

Вопрос к читателям

Я пишу это в первую очередь чтобы понять, насколько проблема реальная, а не воображаемая. Если ты работаешь в безопасности и у тебя есть Kubernetes — мне важно услышать ответы на три вопроса:

1. Как ты сейчас проводишь аудит K8s-кластера? Что используешь?

2. Что показываешь регулятору на проверке? Документ от руки в Word, отчёт из какого-то инструмента, скриншоты?

3. Что изменилось у тебя после ухода Wiz/Prisma/Lacework? Заменили или просто перестали делать?

Можно в комментариях, можно в личку. 15–20 минут разговора по этим трём вопросам помогут мне сильно больше, чем месяц самостоятельных размышлений. Я не пытаюсь ничего продать — продавать пока нечего, инструмент в OSS.

Если хочешь попасть в early-access на коммерческие фичи (PDF, delta-отчёты, расширенный compliance-пак) — тоже напиши, добавлю в список.

---

Теги: kubernetes, security, devsecops, fstek, cloud native, compliance