В cloud-native-среде безопасность давно не ограничивается защитой периметра. Уязвимость может появиться в IaC-шаблоне, попасть в контейнерный образ, пройти через CI/CD и проявиться уже в продакшене. Чем больше сервисов, зависимостей и автоматизации, тем сложнее контролировать всю цепочку отдельными ручными проверками.
Тема очень сложная, поэтому когда я наткнулся на большой англоязычный материал о cloud-native-безопасности в публичном репозитории Security Technical Advisory Group, то сразу решил его перевести. Ну и немного (много) подсократить, чтобы осилить самое главное.
Вместо дословного перевода собрал практическое саммари: какие риски возникают на этапах разработки, сборки, развертывания и эксплуатации (runtime) и какими механизмами их закрывают — от DevSecOps и защиты цепочки поставки до Zero Trust и политик для работающих нагрузок.
Также про эту тему мы рассказываем в курсе «Основы безопасной разработки в облаке» — с практическими примерами и разбором реальных сценариев.
Разработка
Многие проблемы в cloud-native-системах появляются задолго до продакшена — в IaC-шаблонах, манифестах, конфигурациях контейнеров и обычном коде. Поэтому чем раньше команда увидит ошибку, тем дешевле и проще будет ее исправить.
Проверки лучше встраивать прямо в привычный процесс разработки: запускать в IDE, при создании pull request и в CI. Тогда разработчик сразу видит, какое правило нарушено, где возникла проблема и что нужно изменить до слияния.
В первую очередь тестами стоит раскрыть критичные для бизнеса, часто меняющиеся и уже ставшие ошибочными части системы. Расставить в порядке приоритета, какие части системы и на какие уязвимости проверять, помогает модель угроз.
Среды разработки, тестирования и продакшена тоже нужно разделять. Это позволяет проверять приложения, образы и инфраструктурные изменения без риска для рабочей системы.
А перед слиянием все изменения должны проходить ревью другим сотрудником: даже небольшая правка манифеста или сетевой политики может заметно изменить поверхность атаки.
Одних проверок до сборки недостаточно. IaC, манифесты и код должны проходить единый набор тестов в пайплайне: на небезопасные настройки, лишние привилегии, уязвимые образы и слишком широкие сетевые правила.
После развертывания проводят smoke-тесты работающей системы. Если найденная ошибка может повториться, ее исправление закрепляют автоматическим тестом, чтобы следующие изменения не вернули дефект.
Примеры инструментов для shift-left security:
Pre-commit hooks — pre-commit с хуками для Terraform (tflint, Checkov), Helm, Kubernetes-манифестов. Проверки запускаются локально перед коммитом.
IDE-интеграция — плагины вроде Snyk для VS Code, Trivy в JetBrains показывают уязвимости прямо в редакторе.
Policy-as-Code в PR — Conftest + Open Policy Agent (OPA) для проверки манифестов Kubernetes в CI/CD.
Smoke-тесты после развертывания:
k6 — проверяет доступность эндпойнтов, время ответа, коды состояния.
Regression-тесты — автоматические тесты для найденных багов (например, проверка отсутствия cluster-admin в default namespace).
Распространение
На этапе распространения из спецификаций собирают артефакты — прежде всего образы контейнеров и виртуальных машин. Вместе с базовыми слоями и сторонними пакетами в них могут попасть уязвимости или вредоносное ПО, поэтому нужно сканировать образы до развертывания и проверять их целостность. Если требуется конфиденциальность, артефакты можно дополнительно шифровать. Если они оказались скомпрометированы, связанные ключи подписи нужно отозвать.
CI/CD-инфраструктуру необходимо защищать отдельно: изолировать проекты с разным уровнем конфиденциальности, запускать привилегированные сборки на выделенных серверах, своевременно устанавливать обновления безопасности и защищать криптографические ключи с помощью HSM или инструментов управления ключами в облаке. Метаданные о прохождении этапов пайплайна можно подписывать, а подпись — проверять на следующих стадиях.
Критичные уязвимости, недоверенная подпись или нарушение политик должны автоматически блокировать распространение образа. Сканирование продолжают и после релиза: новые CVE могут появиться уже у работающей версии.
При этом одного отчета недостаточно: результаты проверки должны приводить к исправлениям, а политики пайплайна не должны допускать в продакшен образы, которые не соответствуют требованиям безопасности.
Отдельно проверяют сами образы и манифесты приложений. Для образов задают минимально необходимые права пользователя, доступ к ресурсам и ограничения на уровне ядра. Манифесты сканируют в CI/CD, чтобы заранее выявить конфигурации, способные привести к небезопасному развертыванию.
Сканирование образов и артефактов:
Trivy — сканирует образы контейнеров и VM на уязвимости (OS-пакеты, библиотеки, CVE). Интегрируется в CI/CD и регистры (Harbor, ECR, ACR).
Grype — альтернатива от Anchore, сканирует образы и файловые системы, поддерживает SBOM.
Clair — сканер уязвимостей для Docker/OCI-образов, часто используется с Quay или Harbor.
Подпись и проверка целостности:
Sigstore (Cosign) — подписывает образы контейнеров keyless-методом (без долгосрочных ключей) или GPG. Проверка подписи перед деплоем через admission controller (например, Kyverno, Gatekeeper).
Notary — Docker Content Trust для подписи образов, встроен в Docker Registry v2.
SBOM (Software Bill of Materials) — Syft генерирует SBOM для образов, который можно подписать и проверить в пайплайне.
Политики и блокировка небезопасных образов:
OPA Gatekeeper / Kyverno — admission controller для Kubernetes, проверяет образы на подпись, CVE-рейтинг, разрешенные регистры.
Falco — runtime security для обнаружения аномалий в работающих контейнерах (дополняет pre-deploy-сканирование).
Сканирование манифестов:
Kubesec — анализирует Kubernetes-манифесты на небезопасные настройки (privileged, hostPath, capabilities).
Datree — policy engine для манифестов, проверяет best practices и compliance (PCI-DSS, SOC 2).
Polaris — проверяет манифесты на security, efficiency, reliability (open source от Fairwinds).
Развертывание
Перед запуском проводят финальную проверку: проверяют подпись и целостность образа, отсутствие вредоносного ПО и критических уязвимостей, привилегии контейнера, уязвимости хоста и соблюдение политик безопасности для приложения и сети.
Наблюдаемость и реагирование
После запуска приложение должно записывать в журналы данные об аутентификации, авторизации, действиях и сбоях. Поскольку контейнеры недолговечны, средства реагирования должны быстро собирать и анализировать данные, необходимые для расследования инцидента.
Финальная проверка перед запуском:
OPA Gatekeeper / Kyverno — admission webhook для Kubernetes, проверяет подпись образов (через Cosign), блокирует образы с HIGH/CRITICAL CVE, запрещает privileged-контейнеры и hostPath.
Falco — проверяет runtime-поведение при старте (неожиданные syscalls, сетевые подключения, изменения файлов).
Kubewarden — WebAssembly-based policy engine, альтернатива OPA с поддержкой Rust/Go-политик.
Наблюдаемость и централизованное логирование:
Loki + Promtail — легковесная альтернатива ELK, интегрируется с Grafana. Собирает логи из контейнеров и подов Kubernetes.
Fluentd / Fluent Bit — unified logging layer, парсит и отправляет логи в Elasticsearch, S3, Loki или SIEM.
Vector — современная альтернатива Fluentd с меньшим потреблением ресурса, поддерживает метрики и трейсы.
Audit logging и security events:
Kubernetes Audit Logs — встроенный механизм для логирования всех API-запросов (кто, когда, что изменил). Настраивается через audit policy в kube-apiserver.
Falco — детектирует аномалии runtime (exec в контейнер, чтение sensitive-файлов, подозрительные сетевые соединения). Логи отправляются в Loki/Elasticsearch.
Tetragon — eBPF-based security observability от Cilium, трекинг процессов, файлов, сети на уровне ядра.
Инструменты для расследования инцидентов:
Sysdig Inspect — открытая утилита для анализа Sysdig captures (системные вызовы, сеть, файловая активность).
KubeSec + kube-bench — проверка соответствия CIS Kubernetes Benchmark, аудит конфигурации кластера.
OpenTelemetry — трейсинг распределенных запросов (помогает понять путь атаки через микросервисы).
SIEM и корреляция событий:
Wazuh — open source SIEM + XDR, интегрируется с Kubernetes audit logs, Falco, host-level monitoring.
Elastic Security (ELK) — SIEM на базе Elasticsearch, поддерживает detection rules для Kubernetes и контейнеров.
Среда выполнения
На этапе выполнения безопасность строится вокруг трех областей:
вычислительных ресурсов;
управления доступом;
хранения данных.
Контейнеры работают на общем ядре хоста, поэтому для узлов рекомендуется использовать специализированную ОС только для чтения с отключенными лишними сервисами. Нагрузки с разным уровнем чувствительности не следует запускать на одном ядре ОС.
Специализированные ОС для контейнерных хостов:
Flatcar Container Linux — immutable OS, автообновления, минимальный attack surface. Fork CoreOS, поддерживает ignition-конфиги.
Bottlerocket — от AWS, read-only root filesystem, API-driven-управление, автоматические security updates.
Talos Linux — Kubernetes-native OS, без SSH/shell по умолчанию, управляется через gRPC API, immutable infrastructure.
Hardening хостов:
kube-bench — проверяет соответствие CIS Kubernetes Benchmark для узлов и control plane.
Linux Security Modules — AppArmor / SELinux для mandatory access control, ограничение syscalls и capabilities контейнеров.
gVisor — user-space kernel для контейнеров, изоляция на уровне syscall (runtime class в Kubernetes).
Kata Containers — lightweight VM для каждого пода, hardware-level-изоляция вместо shared kernel.
Управление доступом (RBAC и Zero Trust):
OPA (Open Policy Agent) — fine-grained authorization policies для Kubernetes и микросервисов.
Istio / Linkerd — service mesh с mTLS между сервисами, authorization policies на L7.
Calico / Cilium — NetworkPolicy на L3/L4/L7, microsegmentation, eBPF-based enforcement.
Хранение данных и secrets management:
HashiCorp Vault — динамические секреты, rotation, encryption-as-a-service, аудит доступа.
External Secrets Operator — синхронизация секретов из Vault/AWS Secrets Manager/Azure Key Vault в Kubernetes Secrets.
Sealed Secrets — шифрование Kubernetes Secrets в Git (GitOps-friendly).
SOPS — шифрование YAML/JSON с KMS (AWS/GCP/Azure), интегрируется с ArgoCD/Flux.
Оркестрация
Оркестратор состоит из нескольких компонентов, которые относятся либо к плоскости управления, либо к плоскости данных. В сложных системах может появляться еще один уровень управления, который следит за состоянием нескольких независимых плоскостей управления кластерами.
Безопасность оркестратора влияет на весь кластер и на приложения во время работы. Основные риски связаны с доступом к API оркестратора, изменением хранилища ключей и значений, компрометацией панелей управления, перехватом трафика плоскости управления и приложений, а также неправомерным использованием API.
Чтобы снизить эти риски, оркестратор нужно настраивать по рекомендациям безопасности. Важно также отслеживать изменения исходных настроек во время работы, ограничивать административный доступ к плоскости управления, разделять обязанности и выдавать только минимально необходимые права.
Политики безопасности
Оркестратор должен ограничивать права, с которыми среда выполнения запускает контейнеры. Для этого используют политики и механизмы управления более высокого уровня, которые не дают обходить заданные требования безопасности.
Запросы и ограничения ресурсов
Ошибочная или вредоносная нагрузка может исчерпать ресурсы узла или всего кластера. Причиной может стать форк-бомба, майнинг, неконтролируемое потребление памяти или неудачно настроенное автомасштабирование. Запросы и лимиты ресурсов на уровне объектов, реализованные через cgroups, помогают не допустить такого сценария.
Анализ журналов аудита
Журналы аудита помогают выявлять компрометацию, злоупотребления и ошибки конфигурации. Их анализ и сопоставление лучше автоматизировать, а сами события — обогащать контекстом, чтобы на их основе можно было быстро принимать решения и запускать реагирование.
Важно включить аудит API и отслеживать действия, которые представляют интерес для команд безопасности и администраторов кластера. Журналы нужно сразу передавать в хранилище, недоступное с учетными данными уровня кластера, чтобы злоумышленник не мог удалить следы активности. Систему оповещений следует регулярно настраивать, чтобы снизить число ложных срабатываний и риск пропустить реальный инцидент.
Аутентификация плоскости управления
Компоненты плоскости управления должны взаимодействовать с взаимной аутентификацией и проверкой сертификатов. Сертификаты нужно регулярно обновлять, а закрытый ключ центра сертификации — защищать особенно тщательно.
Можно использовать встроенный центр сертификации оркестратора (ЦС) или внешний. Внешний ЦС требует отдельной инфраструктуры и дополнительных ресурсов на поддержку, поэтому такой вариант стоит выбирать только при понятной необходимости.
Контроль работающих нагрузок
После запуска нужно следить за процессами, системными вызовами, изменениями файлов и сетевой активностью. Seccomp ограничивает доступные системные вызовы, а использование «песочницы» добавляет еще один уровень изоляции от ядра хоста.
Связи между микросервисами лучше задавать явно, а остальные — блокировать по умолчанию. Сетевые политики ограничивают внутрисетевой трафик, а Service Mesh может использовать workload identity, mTLS и авторизацию каждого запроса вместо доверия к IP-адресу.
Работающую среду нужно продолжать сканировать и после релиза: безопасная на момент сборки зависимость позже может получить новую CVE. SBOM помогает быстро найти затронутые нагрузки, а приоритет исправления определяют по наличию эксплойта, доступности компонента извне и по тому, используется ли уязвимый код в приложении.
Hardening оркестратора (Kubernetes):
kube-bench — проверяет соответствие CIS Kubernetes Benchmark для control plane и worker nodes.
kubescape — сканирует кластер на misconfiguration, RBAC-проблемы, NSA/CISA hardening guidelines.
Polaris — аудит безопасности и best practices для запущенных workloads.
RBAC и least privilege:
rbac-lookup — обратный поиск: кто имеет доступ к ресурсу.
kubectl-who-can — быстрая проверка: кто может выполнить действие (например, kubectl who-can delete pods).
OPA Gatekeeper — запрещает создание ClusterRoleBindings с избыточными правами.
Политики безопасности (Pod Security):
Kyverno — Kubernetes-native policy engine, enforce/audit/mutate режимы. Замена Pod Security Policies (PSP, deprecated).
OPA Gatekeeper — Rego-based policies для блокировки privileged pods, hostPath, hostNetwork.
Kubewarden — WebAssembly-based альтернатива OPA с меньшим overhead.
Запросы и лимиты ресурсов:
ResourceQuota + LimitRange — встроенные Kubernetes-объекты для namespace-level limits.
Goldilocks — рекомендует оптимальные requests/limits на основе VPA (Vertical Pod Autoscaler).
Kubernetes VPA — автоматически подстраивает requests/limits по метрикам.
Анализ журналов аудита:
Kubernetes Audit Logs — включается через --audit-policy-file в kube-apiserver, записывает все API-запросы.
Falco — runtime security, детектирует аномалии (exec в контейнер, чтение /etc/shadow, подозрительные network connections). Интегрируется с Kubernetes audit logs.
Wazuh — SIEM, коррелирует с Kubernetes audit events + Falco alerts + host logs.
Loki + Promtail — централизованное хранение audit logs, immutable storage (S3/GCS).
Аутентификация плоскости управления:
cert-manager — автоматическая rotation сертификатов для Kubernetes control plane и приложений (Let's Encrypt, Vault, внешний CA).
Vault PKI — внешний CA для выпуска и rotation сертификатов control plane.
Встроенный Kubernetes CA — kubeadm автоматически обновляет сертификаты (kubeadm certs renew), но требует мониторинга expiry.
Контроль работающих нагрузок:
Seccomp — ограничивает syscalls контейнеров (встроенный механизм Kubernetes, профили в /var/lib/kubelet/seccomp).
gVisor — user-space kernel, sandbox для контейнеров, блокирует опасные syscalls.
Falco — runtime detection: мониторит syscalls, file access, network activity.
Tetragon — eBPF-based observability, трекинг процессов, файлов, сети на уровне ядра.
Сетевые политики и Service Mesh:
Cilium — eBPF-based NetworkPolicy с L3/L4/L7-фильтрацией, API-aware policies (HTTP/gRPC).
Calico — NetworkPolicy + GlobalNetworkPolicy для multi-cluster, поддержка BGP.
Istio — service mesh с mTLS, authorization policies (AuthorizationPolicy), workload identity (SPIFFE).
Linkerd — легковесный service mesh, автоматический mTLS, policy на L7.
Сканирование runtime и SBOM:
Trivy Operator — сканирует запущенные образы в кластере, создает VulnerabilityReports.
Dependency-Track — открытая платформа для управления SBOM и отслеживания уязвимостей компонентов.
Хранение данных
В cloud-native-среде хранилища подключаются к нагрузкам как тома или доступны через API. В обоих случаях нужно защищать и интерфейс работы с данными, и control plane: использовать аутентификацию, авторизацию и шифрование трафика. Оркестратору и сервисным брокерам для этого выдают отдельные учетные записи с минимальными правами.
Данные шифруют при передаче и на диске, а ключи хранят отдельно — в KMS или HSM. В публичном облаке можно использовать ключи под управлением клиента, в том числе CMK и BYOK.
Реплики, снапшоты, кеш и резервные копии должны наследовать те же правила доступа и шифрования, что и оригинальные данные. Копия в другом кластере или регионе не должна быть защищена слабее исходного хранилища.
Persistent volumes подключают только к разрешенным namespace и нагрузкам. Одной изоляции по namespace, UID и GID недостаточно: привилегированный контейнер может получить доступ к чужому тому. Поэтому политики должны определять, кто может монтировать том, на каких узлах и с какими правами.
Для контроля целостности используют хеши и контрольные суммы, а доступность обеспечивают с помощью репликации и кодирования со стиранием (erasure coding).
Шифрование данных:
LUKS (Linux Unified Key Setup) — шифрование дисков на уровне блочного устройства, поддерживается всеми major Linux distros.
dm-crypt — kernel-level encryption для block devices, используется под LUKS.
Rook — cloud-native storage orchestrator для Ceph, автоматическое шифрование PVs, интеграция с KMS.
Longhorn — distributed block storage для Kubernetes, encryption at rest через LUKS, snapshot/backup в S3.
Управление ключами (KMS/HSM):
HashiCorp Vault — Transit Secrets Engine для encryption-as-a-service, интеграция с AWS KMS/Azure Key Vault/GCP KMS.
Barbican — OpenStack Secrets Management Service, поддержка PKCS#11 HSM.
External KMS для Kubernetes — шифрование etcd Secrets через AWS KMS, Azure Key Vault, GCP KMS (envelope encryption).
Cloud provider KMS — AWS KMS (CMK, BYOK), Azure Key Vault (Managed HSM), GCP Cloud KMS (Cloud EKM).
Контроль доступа к Persistent Volumes:
Kyverno — политики для ограничения PVC по namespace, StorageClass, Access Modes.
OPA Gatekeeper — запрет привилегированных pods с hostPath или PVC из чужих namespaces.
StorageClass RBAC — Kubernetes RBAC для контроля того, кто может создавать PVC определенных StorageClass.
CSI (Container Storage Interface) — драйверы с поддержкой encryption, access control, snapshot (например, AWS EBS CSI, Ceph CSI).
Snapshot и backup с наследованием политик:
Velero — backup/restore Kubernetes resources и PVs, поддержка encryption (Restic integration), immutable backups в S3/GCS/Azure.
Kasten K10 — enterprise backup (free tier доступен), snapshot encryption, cross-cluster restore с сохранением RBAC.
Stash — backup-оператор для Kubernetes, encryption через Restic, backup в S3/GCS/Azure/MinIO.
Контроль целостности:
dm-verity — read-only integrity checking для block devices (используется в Android, ChromeOS).
IMA (Integrity Measurement Architecture) — Linux kernel subsystem для измерения и проверки целостности файлов.
Checksums в storage backends — Ceph (CRC32c), MinIO (SHA-256), ZFS (SHA-256), Btrfs (CRC32c/SHA-256).
Репликация и erasure coding:
Ceph — distributed storage с erasure coding (k+m scheme), triple replication, CRUSH maps для fault domains.
MinIO — S3-compatible object storage с erasure coding (EC:4, EC:6, EC:8), bitrot protection.
Rook-Ceph — Ceph orchestrator для Kubernetes, автоматическое управление репликацией и EC.
Longhorn — block storage с configurable replica count (default 3), snapshot/backup replication.
Оценка и моделирование угроз
Одних результатов сканеров и формального соответствия стандартам недостаточно. Риски нужно оценивать с учетом конкретной архитектуры, данных и сценариев использования. При харденинге у компонентов оставляют только необходимые порты, пакеты, функции и права, а любое изменение образа или конфигурации проверяют заново.
Модель угроз должна охватывать весь жизненный цикл приложения:
репозитории и CI/CD;
зависимости и реестры образов;
среды разработки и тестирования;
оркестратор и работающие нагрузки;
хранилища и внешние сервисы.
Сначала команда описывает компоненты, потоки данных, внешние зависимости и границы доверия. Данные классифицируют по чувствительности: от этого зависят места хранения, маршруты передачи и необходимые меры защиты.
Для систематизации сценариев можно использовать STRIDE.
Вот несколько типичных сценариев для cloud-native-среды:
кража учетных данных;
подмена образов, конфигураций или сертификатов;
повышение привилегий и выход на хост;
утечка данных через скомпрометированную нагрузку;
уничтожение следов атаки;
отказ узла или сервиса из-за исчерпания ресурсов.
Модель угроз нужно обновлять вместе с архитектурой: новые сервисы, зависимости, права и маршруты трафика меняют поверхность атаки.
Фреймворки для моделирования угроз:
OWASP Threat Dragon — open source threat modeling tool, поддержка STRIDE, диаграммы DFD (Data Flow Diagrams), экспорт в JSON.
Threagile — agile threat modeling как код (YAML), автоматическая генерация отчетов, CI/CD integration.
Microsoft Threat Modeling Tool — бесплатный инструмент с STRIDE-анализом, шаблоны для cloud-native-архитектур.
IriusRisk Community Edition — threat modeling platform с библиотеками угроз для Kubernetes, AWS, Azure.
STRIDE-анализ для cloud-native:
Spoofing — кража service account tokens, подмена контейнерных образов, MITM на незашифрованном трафике.
Tampering — модификация ConfigMaps/Secrets, изменение образов в registry, подмена сертификатов.
Repudiation — отключение audit logs, удаление следов через compromised pod.
Information Disclosure — утечка через /metrics, чтение Secrets из etcd, доступ к PVs других namespaces.
Denial of Service — fork bomb, исчерпание CPU/memory через отсутствие limits, DDoS на ingress.
Elevation of Privilege — container escape через kernel exploit, privilege escalation через misconfigured RBAC.
Hardening и attack surface reduction:
CIS Benchmarks — best practices для Docker, Kubernetes, Linux hosts (проверяются через kube-bench, Lynis).
Lynis — security auditing tool для Linux/Unix-хостов, проверяет hardening, unnecessary services, kernel parameters.
Docker Bench for Security — автоматизированная проверка Docker daemon, images, containers по CIS Docker Benchmark.
Distroless images — минимальные образы без shell, package managers, лишних утилит (только runtime + app).
Инструменты для анализа attack surface:
KubeScape — сканирует Kubernetes на RBAC overprivileges, exposed services, network policies gaps.
Peirates — Kubernetes penetration testing tool, симулирует атаки (service account theft, pod escape, lateral movement).
kube-hunter — penetration testing для Kubernetes, ищет misconfiguration и уязвимости из perspective атакующего.
Threat intelligence и CVE tracking:
Trivy + VEX (Vulnerability Exploitability eXchange) — фильтрует CVE по exploitability (есть ли публичный exploit).
CISA KEV (Known Exploited Vulnerabilities) — каталог активно эксплуатируемых CVE, можно интегрировать в приоритизацию патчей.
Dependency-Track — SBOM management, автоматическая корреляция с NVD/OSV/GitHub Advisory Database.
Threat modeling как код (GitOps):
Threagile — описываете архитектуру в YAML, tool генерирует отчет с рисками и mitigation.
PlantUML + Threat Modeling — диаграммы в коде, можно встроить в CI для проверки изменений архитектуры.
Mermaid.js — рисуете DFD в Markdown, храните в Git рядом с IaC.
Threat intelligence и ATT&CK
Технические индикаторы Threat intelligence: IP-адреса, домены, URL, хеши и сигнатуры — помогают находить уже известную инфраструктуру и инструменты атакующего. Но они быстро меняются, поэтому одних сигнатур недостаточно.
Поведенческие индикаторы показывают саму цепочку атаки: первоначальный доступ, выполнение кода, закрепление, повышение привилегий, разведку, перемещение между сервисами и воздействие.
MITRE ATT&CK for Containers помогает проверить, какие этапы этой цепочки система уже видит. Например, загрузку образа из неизвестного реестра, получение избыточных прав или массовые запросы к API кластера.
Поэтому обнаружение лучше строить не только на технических, но и на поведенческих индикаторах и на понимании тактик атакующего.
MITRE ATT&CK для контейнеров и Kubernetes:
MITRE ATT&CK for Containers — матрица тактик и техник для контейнерных атак (Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, etc.).
Atomic Red Team — библиотека тестов для проверки detection coverage по ATT&CK (включая Kubernetes techniques).
Caldera — adversary emulation framework от MITRE, автоматизирует атаки для проверки защиты.
Threat intelligence feeds (technical indicators):
AlienVault OTX (Open Threat Exchange) — community threat intelligence, IP/domain/hash IOCs, бесплатный API.
MISP (Malware Information Sharing Platform) — open source TIP (Threat Intelligence Platform), интеграция с SIEM, автоматический импорт feeds.
Yara — pattern matching для malware signatures, можно использовать в CI для сканирования образов.
Falco rules — community-driven behavioral rules для Kubernetes (например, обнаружение miners, reverse shells).
Behavioral detection (TTPs):
Falco — runtime security, детектирует поведенческие индикаторы (exec в контейнер, чтение /etc/shadow, outbound connections к C2).
Tetragon — eBPF-based observability, трекинг process execution, file access, network activity (можно строить TTPs).
Sysdig Secure — коммерческий (есть free tier), MITRE ATT&CK mapping для Kubernetes events.
Wazuh — SIEM со встроенными MITRE ATT&CK mappings, detection rules для Kubernetes audit logs.
Инструменты для проверки detection coverage:
Simulator — симулятор Kubernetes-атак для проверки SIEM rules и Falco policies.
kube-hunter — penetration testing, проверяет exploitable misconfigurations.
Peirates — Kubernetes adversary emulation, симулирует TTPs (token theft, privilege escalation, lateral movement).
Реагирование на инциденты
Но обычные сценарии реагирования в cloud-native-среде работают не всегда. Изоляция узла не остановит нагрузку, если оркестратор запустит ее на другом сервере. А состояние контейнера и следы атаки могут исчезнуть после перезапуска.
Поэтому инструменты наблюдаемости и форензики должны работать с подами, контейнерами, узлами и namespace. Логи, сетевые события, снимки файловой системы и другие доказательства нужно автоматически сохранять вне кластера до пересоздания нагрузки.
План реагирования должен включать локализацию скомпрометированных сервисов, отзыв учетных данных, блокировку недоверенных образов и восстановление из проверенных резервных копий. Его стоит заранее отрабатывать на киберучениях.
После инцидента найденный сценарий добавляют в модель угроз, правила обнаружения и регрессионные проверки. Резервные копии при этом должны храниться отдельно от основной инфраструктуры, быть защищены от изменения и регулярно проходить тест восстановления.
Принципы безопасности
Безопасные настройки по умолчанию
Безопасность лучше закладывать в архитектуру и базовую конфигурацию системы. Безопасный вариант должен быть самым простым, а переход к более рискованным настройкам должен требовать явного действия.
Новые компоненты должны автоматически наследовать защитные политики. Исключения нужно оформлять отдельно, контролировать и регулярно пересматривать. При этом платформа должна позволять вернуть систему в безопасное состояние и понятно объяснять действующие ограничения.
Минимальные привилегии
В cloud-native-среде принцип минимальных привилегий распространяется на весь стек: процессы и контейнеры, системные вызовы и файловые системы, артефакты и пайплайны и т. д.
При выборе компонентов нужно проверять, требуют ли они root, привилегированный режим или широкий доступ к хосту. Такие нагрузки стоит ограничивать или запускать в изолированной среде.
На разных уровнях для этого используют cgroups, seccomp, rootless-контейнеры, сетевые политики и контроль доступа к артефактам. SELinux и AppArmor дополнительно ограничивают доступ к ресурсам хоста, выход из контейнера и повышение привилегий.
Чем меньше прав получает каждый компонент, тем меньше поверхность атаки и радиус поражения после компрометации.
Разделенная ответственность
При переносе системы в облако нужно заранее определить зоны ответственности. Провайдер защищает инфраструктуру и управляемые компоненты платформы, а клиент отвечает за конфигурацию сервисов, доступы, данные, приложения и собственные политики безопасности.
Безопасность цепочки поставки
В cloud-native-системе недостаточно проверить только готовый образ. Защищать нужно весь путь артефакта — от исходного кода и сторонних зависимостей до сборки, реестра и развертывания.
На каждом этапе важно подтвердить:
происхождение компонентов;
целостность артефакта;
доверенность среды сборки;
прохождение обязательных проверок.
Результаты сборки и проверок по возможности подтверждают криптографически.
SBOM
SBOM показывает, из каких библиотек, пакетов и инструментов собрано приложение. Если в одной из зависимостей появляется уязвимость, по нему можно быстро найти затронутые нагрузки и проследить проблему по дереву компонентов.
SBOM лучше создавать во время сборки в формате SPDX или CycloneDX. Готовый образ стоит проверить повторно, чтобы сравнить заявленный состав с тем, что действительно попало в артефакт.
Подтверждение этапов
Для ключевых шагов цепочки создают аттестаты артефактов (attestations) — подписанные подтверждения того, что операция прошла в доверенной среде и по заданным правилам. Перед развертыванием система проверяет подпись артефакта, SBOM и подтверждения обязательных этапов.
Контроль зависимостей и поставщиков
В цепочку поставки входят не только код и образы, но и компоненты самого CI/CD: плагины, раннеры и внешние сервисы. Их уязвимости и доступные исправления тоже должны попадать в общий контур контроля.
SBOM, CVE, VEX и аттестаты артефактов лучше хранить в единой системе для быстрого поиска. На основе этих данных платформа может автоматически заблокировать развертывание, не выдать нагрузке workload identity или изолировать ее от доверенных сервисов.
GitOps
GitOps делает Git источником актуального состояния инфраструктуры: декларативная конфигурация хранится в репозитории, а контроллер приводит реальную среду к описанному состоянию.
Так команда получает историю изменений, автоматическую проверку политик и возможность быстро восстановить известную конфигурацию. Ручные правки в обход пайплайна видны как расхождение с репозиторием и могут быть автоматически отменены.
При этом GitOps-пайплайн получает и широкие права. Что плохо: если его скомпрометировать, атакующий сможет изменить инфраструктуру или доставить вредоносный код в продакшен.
Поэтому нужно:
защищать основную ветку и принимать изменения только через pull request, ревью и обязательные проверки;
запрещать секреты в Git и автоматически находить их в коммитах;
подписывать критичные изменения и запрещать переписывание истории;
использовать отдельные сервисные аккаунты с короткоживущими ключами;
регулярно обновлять Git-серверы, контроллеры и компоненты пайплайна;
ограничивать право отключать проверки, удалять аудит, менять политики и повышать привилегии.
Критичные действия нужно отдельно журналировать. При такой настройке инфраструктура остается воспроизводимой, а нарушения политик обнаруживаются до применения изменений.
Архитектура Zero Trust
Zero Trust исходит из того, что пользователь, сервис или устройство не заслуживает доверия только потому, что уже находится внутри сети. Каждый запрос проверяется по идентичности, состоянию участника и действующим политикам.
Для этого система должна:
Подтверждать идентичность каждого участника.
Поддерживать взаимную аутентификацию сервисов.
Защищать трафик от чтения и подмены.
Через цепочку аттестации платформа может проверить состояние компонентов — от инфраструктуры и оркестратора до конкретной нагрузки. Перемещение атакующего ограничивают с помощью микросегментации, сетевых политик, Service Mesh и mTLS.
Комплаенс
Требования регуляторов и отраслевых стандартов лучше учитывать еще при проектировании. Тогда необходимые контроли сразу попадают в архитектуру, CI/CD и процессы эксплуатации, а подготовка к аудиту требует меньше ручной работы.
NIST, CIS Benchmarks, OpenS, CAP и другие машиночитаемые наборы правил помогают проверять конфигурации и безопасные настройки по умолчанию. Но они не учитывают бизнес-логику, маршруты данных и внешние интеграции, поэтому прохождение чек-листа не заменяет моделирование угроз.
Каждое требование нужно связать с конкретными компонентами и механизмами защиты. Сбор доказательств для аудита лучше автоматизировать: сохранять логи, результаты проверок, подписи и аттестаты артефактов, которые подтверждают, что контроль действительно сработал.
Послесловие
Cloud-native-безопасность не складывается из одного сканера или защиты периметра. Нужна связанная система: проверки в CI/CD, контроль цепочки поставки, политики оркестратора, наблюдение за работающими нагрузками и заранее подготовленный процесс реагирования.
И хоть сами причины атак остаются знакомыми (известные уязвимости, слабые учетные данные и ошибки конфигурации), меняются точки входа. Ими становятся то образы, то пайплайны и оркестраторы, то облачные сервисы. Поэтому защиту нужно встраивать в весь жизненный цикл приложения — от первого коммита до работы в продакшене.
Главный вывод: в cloud-native-среде безопасность работает только тогда, когда становится частью самой платформы и ежедневного процесса разработки. Чем раньше система проверяет изменения и чем меньше решений остается на ручной контроль, тем ниже риск пропустить уязвимость до продакшена.
До следующей статьи, коллеги. А пока что можете изучить наш пул сервисов для безопасности облака.
