Безопасность контейнеров и облачной инфраструктуры

17 мин чтения·Для руководителя разработки и лидера безопасности

Контейнеры и облачная инфраструктура создают риски, которые традиционные подходы к безопасности приложений не покрывают. Docker-образ содержит уязвимую версию системной библиотеки, унаследованную от базового образа. Хранилище объектов открыто на чтение всем желающим, потому что разработчик настроил это «временно для теста». У сервисного аккаунта в облаке права администратора на весь проект, хотя он использовался только для одной задачи.

Эти ошибки конфигурации — первое, что ищут атакующие. Их не нужно «взламывать» в классическом смысле: достаточно найти открытый ресурс и воспользоваться им. Хорошая новость — их же первыми находят автоматические инструменты, если внедрить регулярное сканирование.

Лидер безопасности — сотрудник, который берёт на себя вопросы информационной безопасности в команде как дополнительную зону ответственности, — должен выстроить этот процесс. Задача руководителя — убедиться, что процесс работает, и знать, что именно проверять.

Почему это важно для бизнеса

Контейнеры скрывают уязвимости. Когда команда берёт стандартный базовый образ (Node, Python, Java), вместе с ним приходит целый дистрибутив Linux с сотнями пакетов. Любой из этих пакетов может содержать известные уязвимости. Компания не писала этот код — но отвечает за безопасность всего, что работает в её инфраструктуре.

Настройки облака по умолчанию не безопасны. Российские облачные провайдеры — Yandex Cloud, VK Cloud, Cloud.ru, Selectel — как и их зарубежные аналоги, оптимизируют настройки по умолчанию под скорость запуска, а не под безопасность. Разработчик, который разворачивает ресурс быстро и без глубокого знания политик доступа, почти наверняка оставит что-то открытым.

Маленькие команды не проверяют конфигурацию дважды. В стартапе никто не делает code review для Terraform-конфигурации. Изменения в инфраструктуре уходят сразу в продакшн. Автоматическое сканирование — единственная страховочная сетка.

Kubernetes добавляет сложность. Настройки Kubernetes по умолчанию разработаны для быстрого старта, а не для безопасной работы. Без явной настройки политик безопасности любой pod в кластере может взаимодействовать с любым другим, а контейнеры работают с правами root.

Интернет сканируется непрерывно. Автоматические боты обходят весь интернет и находят открытые базы данных, публичные хранилища объектов и незащищённые API за считаные часы после их появления. Ошибочно открытый ресурс будет обнаружен — вопрос только когда.

Безопасность контейнеров

Принципы построения безопасных образов

Команда должна следовать этим правилам при создании Docker-образов. Это не разовая акция, а стандарт, который лидер безопасности закрепляет как обязательный.

Минимальные базовые образы. Alpine Linux вместо полного Ubuntu/Debian — во много раз меньше пакетов, во много раз меньше потенциальных уязвимостей. Образы «distroless» от Google идут ещё дальше: в них только приложение и его зависимости, без shell, без пакетного менеджера — даже если атакующий проникнет в контейнер, у него не будет инструментов для дальнейших действий.

Фиксированные версии образов. Тег latest означает «что угодно в данный момент» — образ меняется без предупреждения. Для воспроизводимых и контролируемых сборок используются явные версии: python:3.12.3-alpine3.19, а не python:latest.

Запрет на запуск от имени root. Процессы в контейнере, работающие от имени root, при определённых конфигурациях могут получить доступ к хост-системе. Каждый образ должен создавать непривилегированного пользователя и запускать приложение от его имени.

Многоэтапные сборки. Инструменты сборки (компиляторы, тестовые зависимости) не должны попадать в продакшн-образ. Многоэтапные сборки оставляют в финальном образе только то, что нужно для работы приложения.

Секреты не в образах. Пароли, API-ключи и сертификаты не должны быть встроены в Dockerfile или образ. Они передаются через переменные окружения или механизмы управления секретами (Пассворк, Vault) в момент запуска контейнера.

Сканирование образов на уязвимости

Выстроить сканирование — одна из первых задач лидера безопасности в области контейнерной безопасности.

Что должно происходить: каждый Docker-образ, прежде чем попасть в продакшн, проверяется на известные уязвимости. Если найдены критические — деплой блокируется. Если найдены важные (high) — создаётся задача с конкретным дедлайном.

Инструменты:

Trivy (open-source, Apache 2.0) — стандартный инструмент для сканирования контейнерных образов. Проверяет пакеты ОС, зависимости языков программирования и конфигурационные файлы. Легко встраивается в любой CI/CD пайплайн. Для небольших команд без выделенной ИБ-функции — оптимальный выбор.

Luntry — российская платформа безопасности контейнеров. Сканирование образов, анализ времени выполнения (runtime security), контроль политик для Kubernetes. Подходит компаниям с требованиями к российским средствам защиты информации.

PT Container Security (Positive Technologies) — российское решение корпоративного класса. Глубокий анализ образов, обнаружение угроз в runtime, интеграция с российскими SIEM-системами. Сертифицировано ФСТЭК России.

Для большинства компаний начать стоит с Trivy в CI/CD — это бесплатно и решает основную задачу. При наличии требований к сертифицированным СЗИ или необходимости глубокого runtime-мониторинга — рассматривать Luntry или PT Container Security.

Как должен выглядеть процесс:

Разработчик отправляет код на сборку
CI/CD система собирает Docker-образ
Автоматически запускается сканирование
Если найдены уязвимости критического уровня — сборка падает, деплой не происходит
Разработчик получает отчёт: что найдено, в каком пакете, есть ли исправленная версия
После устранения — повторная сборка и повторное сканирование

Сканирование нужно запускать не только при сборке, но и по расписанию для уже развёрнутых образов: новые уязвимости появляются в известных пакетах постоянно, даже если код приложения не менялся.

Реестр образов

Тянуть образы напрямую с Docker Hub без проверки — это риск. Нужен приватный реестр с контролем доступа.

Что должен обеспечивать реестр:

Автоматическое сканирование при загрузке образа
Контроль доступа: только CI/CD-сервисные аккаунты могут загружать образы, разработчики — только скачивать
Неизменяемые теги: нельзя перезаписать существующий тег (защита от подмены образа)
Журнал всех операций загрузки и скачивания
Политики хранения: автоматическое удаление устаревших неподписанных образов

Для российской инфраструктуры: реестр разворачивается на собственных серверах (Harbor, Nexus) или используется как сервис в рамках Yandex Cloud (Yandex Container Registry), VK Cloud или других провайдеров.

Подписание образов

После атак на цепочку поставок программного обеспечения (supply chain attacks) стал актуален вопрос: откуда в продакшн попал этот образ и был ли он изменён после сборки?

Подписание образов (с помощью Cosign или аналогичных инструментов) решает три задачи:

Образ не был изменён после сборки
Он был создан именно вашим CI/CD-пайплайном, а не подброшен извне
В продакшн можно развернуть только подписанные образы

Лидер безопасности настраивает подписание как часть CI/CD и политику в кластере Kubernetes или реестре, которая блокирует запуск неподписанных образов.

Мониторинг времени выполнения

Сканирование образов перехватывает известные уязвимости. Но что происходит, когда контейнер уже запущен?

Инструменты runtime security отслеживают поведение запущенных контейнеров и сигнализируют об аномалиях:

В контейнере запустилась shell-сессия (атакующий получил интерактивный доступ)
Процесс пытается прочитать системные файлы, к которым не должен иметь доступа
Контейнер устанавливает соединение с нетипичными внешними адресами
Запустился процесс, похожий на майнер криптовалюты
Попытка повышения привилегий

Для российских компаний с требованиями к средствам защиты — Luntry или PT Container Security с их runtime-возможностями. Для компаний без жёстких требований к сертификации — open-source Falco (Apache 2.0), де-факто стандарт в этой области.

Безопасность Kubernetes

Если приложение работает в Kubernetes — Deckhouse, Штурвал, Nova, Yandex Managed Kubernetes, VK Cloud Kubernetes или другой платформе — нужна отдельная настройка безопасности кластера.

Почему настройки по умолчанию небезопасны

Kubernetes проектировался для быстрого запуска, а не для безопасности «из коробки». Дефолтная конфигурация разрешает контейнерам работать от root, позволяет любым pod'ам общаться между собой, не ограничивает потребление ресурсов и даёт сервисным аккаунтам избыточные права.

Вектор атаки прост: злоумышленник компрометирует один сервис → выходит за пределы контейнера → движется по кластеру → получает доступ к другим сервисам или данным. Каждый из этих шагов можно заблокировать правильной конфигурацией.

Ключевые компоненты безопасности Kubernetes

Политики безопасности pod'ов (Pod Security Standards). Kubernetes разделяет политики на три уровня:

Privileged — без ограничений, только для системных компонентов
Baseline — блокирует наиболее опасные настройки, подходит большинству приложений
Restricted — максимальная безопасность: запрет root, только чтение корневой файловой системы, минимальные привилегии

Для продакшн-приложений нужен как минимум Baseline, для чувствительных данных — Restricted. Лидер безопасности настраивает это на уровне namespace.

RBAC (управление доступом на основе ролей). В Kubernetes RBAC контролирует, кто может делать что с объектами кластера. Самая распространённая ошибка — дать сервисному аккаунту приложения права cluster-admin «для удобства». Это означает, что скомпрометированное приложение получает полный контроль над кластером.

Принцип: каждый сервисный аккаунт имеет только те права, которые нужны для его конкретной задачи. Лидер безопасности должен провести аудит существующих прав и устранить избыточные.

Сетевые политики. По умолчанию все pod'ы в кластере могут общаться между собой. Сетевые политики ограничивают это: фронтенд может обращаться только к API, API — только к базе данных, база данных изолирована от интернета.

Kubernetes Secrets — это не шифрование

Встроенные Kubernetes Secrets хранятся в base64-кодировании. Любой, у кого есть доступ к etcd или к API с нужными правами, прочитает их без усилий. Нужно либо включить шифрование etcd в покое, либо подключить внешний менеджер секретов (Пассворк через External Secrets Operator).

Ограничения ресурсов. Каждый контейнер должен иметь явно заданные лимиты CPU и памяти. Без них один контейнер может потребить все ресурсы узла, что используется в атаках типа DoS. Майнер криптовалюты, запущенный через скомпрометированный образ, без лимитов уничтожит производительность всего кластера.

Аудит кластера

Для проверки конфигурации Kubernetes существуют специализированные инструменты:

Kubescape — сканирует кластер против фреймворков безопасности NSA/CISA, MITRE ATT&CK и бенчмарков CIS. Выдаёт конкретный список проблем с приоритетами и инструкциями по исправлению.

kube-bench — проверяет соответствие кластера CIS Kubernetes Benchmark, де-факто стандарту конфигурации безопасности Kubernetes.

Аудит кластера стоит запускать при первоначальной настройке, после крупных изменений и не реже раза в квартал.

Российские платформы Kubernetes

При выборе платформы для оркестрации контейнеров в российской инфраструктуре:

Deckhouse (Flant) — российская корпоративная платформа управления Kubernetes. Включает набор встроенных политик безопасности, мониторинг, управление сертификатами.

Штурвал — российская платформа на базе Kubernetes, сертификация ФСТЭК.

Nova — ещё одно российское решение для enterprise.

Yandex Managed Kubernetes / VK Cloud Kubernetes — управляемые сервисы от крупных российских облачных провайдеров.

Для значимых объектов критической информационной инфраструктуры (КИИ) выбор платформы должен учитывать требования 187-ФЗ и приказа ФСТЭК № 239.

Безопасность облачной инфраструктуры

Облачные провайдеры предоставляют инфраструктуру — безопасность конфигурации остаётся ответственностью заказчика. Это «модель разделённой ответственности»: провайдер отвечает за физическую безопасность и гипервизор, вы — за всё, что настраиваете сами.

Наиболее опасные ошибки конфигурации

Ошибка	Риск	Как возникает
Публичный доступ к хранилищу объектов	Утечка данных	Разработчик открыл доступ «временно для теста»
Избыточные права IAM/сервисных аккаунтов	Повышение привилегий	Права `*` или `admin` «для удобства»
Незашифрованные хранилища	Кража данных при утечке	Шифрование по умолчанию не включено
Открытые порты в группах безопасности	Несанкционированный доступ	SSH/RDP открыт на весь интернет при отладке
СУБД с публичным IP	Утечка базы данных	БД с публичным адресом и слабым паролем
Отсутствие журналирования	Невозможность расследования	Аудит API-вызовов не включён
Неиспользуемые ключи доступа	Компрометация учётных данных	Ключи уволившегося сотрудника не отозваны
Отсутствие MFA на административных аккаунтах	Захват аккаунта	Root/admin без второго фактора

Принципы безопасности облачных ресурсов

Минимальные привилегии. Каждый сервисный аккаунт, каждая роль IAM должны иметь только те права, которые нужны для конкретной задачи. Начинать с нулевого доступа и добавлять только необходимое — не наоборот.

Шифрование везде. Шифрование хранилищ данных в покое включается при создании ресурса. Все передачи данных — только по TLS. Включить «шифрование по умолчанию» в настройках аккаунта — это минутное действие, которое защищает все будущие ресурсы.

Закрытый доступ по умолчанию. Базы данных — только в приватных подсетях без публичного IP. Административный доступ — только через VPN или бастион-хост. Хранилища объектов — закрытые по умолчанию, публичный доступ только там, где он нужен явно (например, статический сайт).

Полное журналирование. Логи API-вызовов и действий в облачной консоли включаются с первого дня. Расследовать инцидент без журнала невозможно.

Теги на всех ресурсах. Метки environment, owner, project помогают понять, что за ресурс, кто за него отвечает, к какому проекту он относится. Ресурсы без тегов — кандидаты на забытые «призраки».

Сетевая архитектура

Стандартная трёхуровневая модель подсетей, которую нужно реализовать в любом облаке:

Публичные подсети — только балансировщики нагрузки и NAT-шлюзы. Единственная точка входа из интернета
Приватные подсети — серверы приложений. Нет публичного IP, только исходящий трафик через NAT
Подсети баз данных — базы данных. Вообще нет доступа в интернет, только из приватных подсетей приложений

Это не теория — это стандарт, и его отсутствие означает, что атакующий, получивший доступ к одному компоненту, может напрямую атаковать базу данных.

Российские облачные провайдеры

При выборе и настройке облачной инфраструктуры:

Yandex Cloud — инструменты безопасности включают Identity and Access Management, Cloud Logging, Security Groups, Smart Web Security (WAF + анти-DDoS), Yandex Managed Databases в приватных подсетях.

VK Cloud — аналогичный набор: IAM, группы безопасности, управляемые СУБД, мониторинг.

Cloud.ru (SberCloud) — корпоративная платформа с акцентом на compliance для крупного бизнеса и государственных структур.

Selectel — надёжный российский провайдер с гибкими настройками сети и хранилищ.

Все перечисленные провайдеры работают в российской юрисдикции и подходят для размещения персональных данных (152-ФЗ, 242-ФЗ).

Аудит облачной конфигурации

Ручная проверка конфигурации облака при наличии десятков ресурсов — нереалистична. Нужны инструменты автоматического аудита.

ScoutSuite (open-source, NCC Group) — сканирует конфигурацию облака и формирует HTML-отчёт с группировкой по сервисам и уровням критичности. Поддерживает несколько провайдеров. Для российских провайдеров поддержка ограничена, но принципы применимы.

Prowler (open-source) — специализированный инструмент аудита для AWS, проверяет соответствие бенчмаркам CIS, требованиям различных стандартов. При использовании Yandex Cloud или VK Cloud — проводить аудит через собственные инструменты провайдера или в ручном режиме по чек-листам.

Встроенные инструменты провайдеров:

Yandex Cloud Security — рекомендации по безопасности в консоли
VK Cloud — Security Center с проверками конфигурации
Cloud.ru — собственный набор инструментов контроля безопасности

Аудит конфигурации должен проводиться не реже раза в квартал. Критические находки (публичный доступ к хранилищам, открытые порты администрирования) — устраняются в течение 24 часов.

Работа с результатами сканирования

Когда Trivy сообщает о 50 уязвимостях, а аудит конфигурации находит 200 проблем, нужна система приоритизации.

Приоритеты устранения

Приоритет	Критерий	Срок устранения
P1 — Критический	Активно эксплуатируется ИЛИ публичный ресурс с известным эксплойтом	В течение 24 часов
P2 — Высокий	Высокая критичность, лёгкая эксплуатация, влияние на продакшн	В течение недели
P3 — Средний	Средняя критичность, требует определённых условий	В течение месяца
P4 — Низкий	Низкая критичность, защита вглубь	В ближайшее плановое окно
Принять риск	Очень низкий риск, нет исправления, есть компенсирующие меры	Задокументировать и принять

Избегайте ложной безопасности

Не все находки — реальные проблемы. Перед постановкой задачи на устранение стоит убедиться, что:

Уязвимость применима к вашей конфигурации (не все CVE эксплуатабельны в любом контексте)
Ресурс не намеренно публичный (статический сайт — это нормально)
Это не известное исключение (задокументировать и подавить повторные оповещения)

Ложные срабатывания добавляются в исключения с обязательным комментарием — почему это не проблема. Иначе исключения накапливаются и скрывают реальные риски.

Распространённые ошибки

Сканирование без исправления. Запустить Trivy, получить 50 критических уязвимостей, не сделать ничего — хуже, чем не сканировать. Создаётся ложное ощущение контроля при реальном его отсутствии.

Тег latest в продакшне. Образ меняется без предупреждения. Сегодня Node 20.12, завтра — Node 21 с breaking changes. Версии должны быть фиксированными и контролируемыми.

Игнорирование обновлений базовых образов. Код приложения не менялся, но базовый образ шестимесячной давности содержит 20 новых CVE. Образы нужно пересобирать регулярно, даже без изменений в коде.

«Временный» admin-доступ. Разработчику нужно отладить проблему → получил полные права → никто не отозвал. Создавать минимальные права сразу, не «расширять для удобства».

Отключение сканирования для разблокировки деплоя. Сканер нашёл проблему, срочно нужно задеплоить, сканирование отключили. Теперь не видно ни текущих, ни новых уязвимостей. Правильное решение — добавить известную проблему в исключения с документированием, не отключать сканирование.

Ежегодный аудит вместо непрерывного. Конфигурация изменяется ежедневно. Аудит раз в год перед проверкой регулятора — не мониторинг, а фиксация состояния на конкретную дату.

Kubernetes Secrets без шифрования. Base64 — это кодирование, не шифрование. Всё содержимое Kubernetes Secrets читается любым, у кого есть доступ к etcd или соответствующие права API.

Типичный инцидент (обезличенный кейс)

Российская онлайн-торговая компания использовала облачный Kubernetes. Один из разработчиков ради удобства установил сервисному аккаунту тестового сервиса права администратора в облаке. Тестовый сервис содержал уязвимость в сторонней библиотеке (незакрытый CVE в зависимости, сканирование не проводилось). Атакующие воспользовались уязвимостью, получили токен сервисного аккаунта и через него — доступ к объектному хранилищу с резервными копиями базы данных клиентов. Итог: утечка данных, уведомление Роскомнадзора, репутационный ущерб.

Два изменения предотвратили бы инцидент: регулярное сканирование образов и ограничение прав сервисного аккаунта.

См. также

Управление секретами — где хранить ключи от облака
Логирование и мониторинг — как замечать подозрительную активность
Поверхность атаки — что из облака доступно снаружи

Что дальше

Контейнеры сканируются, облачная конфигурация проверена, сетевой доступ ограничен. Поверхность атаки существенно сократилась.

Следующий шаг: безопасность логирования и мониторинга — как выстроить централизованный сбор событий, настроить оповещения об аномалиях и выполнить обязательства перед регуляторами по уведомлению об инцидентах.

Почему это важно для бизнеса​

Безопасность контейнеров​

Принципы построения безопасных образов​

Сканирование образов на уязвимости​

Реестр образов​

Подписание образов​

Мониторинг времени выполнения​

Безопасность Kubernetes​

Почему настройки по умолчанию небезопасны​

Ключевые компоненты безопасности Kubernetes​

Аудит кластера​

Российские платформы Kubernetes​

Безопасность облачной инфраструктуры​

Наиболее опасные ошибки конфигурации​

Принципы безопасности облачных ресурсов​

Сетевая архитектура​

Российские облачные провайдеры​

Аудит облачной конфигурации​

Работа с результатами сканирования​

Приоритеты устранения​

Избегайте ложной безопасности​

Распространённые ошибки​

Типичный инцидент (обезличенный кейс)​

См. также​

Что дальше​