Цели аудита безопасности Docker и контейнерных сред: как выстроить системный подход

Цель аудита безопасности Docker формулируется как измеримый результат, привязанный к этапу жизненного цикла и к конкретной зоне риска: изоляции контейнеров, правам root внутри контейнера, безопасности образов, работе с секретами или конфигурации Docker daemon. Формулировка «проверить безопасность контейнеров» не отвечает на вопросы: что именно смотрим, чем измеряем, кто отвечает за устранение и когда повторяем проверку.

Рабочая цель содержит четыре элемента: объект проверки, критерий прохождения, инструмент и периодичность. Пример: доля Dockerfile с инструкцией USER, задающей непривилегированного пользователя, равна 100%; проверка линтером на каждой сборке; владелец - команда платформы. Такая запись превращает пожелание в задачу, которую можно закрыть или провалить.

Пять направлений покрывают большинство практических рисков контейнерной среды: изоляция, права внутри контейнера, образы, секреты и Docker daemon. Ниже разобрано каждое, показано, как связать цели с этапами разработки, CI/CD и продакшна, и как свести всё в чек-лист. Общий разбор того, как формулировать измеримые цели для инфраструктуры, есть в статье Цели аудита безопасности: практический разбор для DevOps и системных администраторов.

Почему разовые проверки не работают: необходимость системного аудита

Разовый аудит фиксирует состояние на конкретную дату. За месяц образы пересобираются, базы уязвимостей пополняются, кто-то добавляет --privileged для диагностики и забывает убрать, секрет на время демо попадает в переменную окружения контейнера. Через квартал отчёт прошлой проверки описывает уже другую инфраструктуру.

Системный подход опирается на цикличность и непрерывное совершенствование: проверка, устранение отклонений, повторная проверка. Именно эта идея лежит в основе оценки процессов разработки безопасного ПО и обеспечивает устойчивость к новым угрозам (Зависит от цели. Оценка процессов разработки безопасного ПО).

Смысл регулярной проверки шире формального контроля требований. Задача внутреннего аудита - увидеть, насколько эффективно работает система управления, где есть риски и что можно улучшить (О программе «Внутренний аудитор системы менеджмента безопасности движения»). Для контейнерной среды это означает не только поиск отклонений, но и оценку того, успевает ли команда за изменениями.

Готовые шкалы зрелости помогают не изобретать структуру заново. OWASP SAMM включает 15 практик, разделённых на пять бизнес-функций: Governance, Design, Implementation, Verification и Operation. OWASP DevSecOps Maturity Model описывает практики интеграции безопасности в разработку и CI/CD. Synopsys BSIMM построен на данных 130 организаций и состоит из четырёх доменов, каждый из которых включает три практики с тремя уровнями покрытия (Зависит от цели. Оценка процессов разработки безопасного ПО). Практическая польза от этих моделей в том, что они задают горизонт планирования: целевой уровень фиксируется на год-три, а не на одну проверку.

Ключевые направления аудита безопасности Docker

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

Изоляция контейнеров: сети, тома, пространства имён

Изоляция определяет, что контейнер видит из хоста и от соседних сервисов. Проверка начинается с сетевого режима. Стандартная bridge-сеть подходит для одиночных контейнеров, пользовательская bridge-сеть даёт отдельный сегмент с резолвингом имён контейнеров по имени сервиса и изоляцию групп: приложение из одной сети не увидит контейнеры из другой. Различия стандартной и пользовательской bridge-сети, назначение драйверов и сетевых команд подробно разобраны в чек-листе (Чек-лист «Контейнеры: сеть, тома и публикация портов»).

• Список сетей и драйверов: docker network ls, затем docker network inspect по каждой сети, чтобы увидеть подключённые контейнеры и пересечения групп.
• Отказ от host-сети и режима --net=container:... для сервисов, которым не нужен прямой доступ к интерфейсам хоста.
• Тома: определите, где нужен именованный том (данные, переживающие пересоздание контейнера), где bind-mount (каталог хоста), где tmpfs (данные в памяти, на диск не пишутся).
• tmpfs применяют для временных файлов и промежуточных секретов, чтобы содержимое не осело в слое образа или на диске.
• Права на смонтированные каталоги: проверьте владельца и режим; каталог, доступный на запись группе docker, даёт лишние возможности.
• Резервное копирование томов и проверка восстановления: цель фиксирует не факт наличия бэкапа, а успешное восстановление.
• Публикация портов: EXPOSE в Dockerfile только документирует порт, наружу его открывают -p (явное сопоставление) и -P (проброс всех EXPOSE-портов на случайные порты хоста). Фактическую картину показывают docker ps и проверка доступности через curl.

Работа с root внутри контейнера: риски и ограничения

Процесс, запущенный от root внутри контейнера, при эксплуатации уязвимости приложения даёт атакующему больше возможностей. В классической конфигурации uid 0 в контейнере совпадает с uid 0 на хосте, поэтому удачный выход из изоляции сразу даёт максимальные права. Ограничения ставятся несколькими независимыми мерами.

• Инструкция USER в Dockerfile: приложение работает от отдельного пользователя с uid вне нулевого диапазона.
• Переопределение на запуске: docker run --user 1000:1000 для образов, которые вы не контролируете.
• Rootless-режим Docker daemon: и демон, и контейнеры работают от непривилегированного пользователя хоста.
• User namespaces (userns-remap в daemon.json): uid внутри контейнера отображается в другой uid на хосте.
• Capabilities: запуск с --cap-drop ALL и добавление только необходимого через --cap-add вместо стандартного набора.
• Запрет --privileged, --pid=host, --ipc=host и монтирования docker.sock внутрь контейнера.
• Флаг --security-opt no-new-privileges:true блокирует повышение прав через setuid-бинарники.
• Корневая файловая система только для чтения (--read-only) с отдельными writable-томами для данных.

Проверки для отчёта простые и проверяемые: наличие USER в каждом Dockerfile, отсутствие --privileged в манифестах и скриптах запуска, ограниченный список cap_add, доля контейнеров, работающих от uid 0.

Безопасность образов Docker: сканирование и управление уязвимостями

Образ переносит уязвимости базового слоя и пакетов приложения в каждый запущенный контейнер. Аудит строится вокруг сканирования, обновления баз и контроля происхождения артефактов.

• Сканирование образов: Trivy и Clair проверяют слои образа и установленные пакеты по базам уязвимостей. Docker Bench for Security проверяет конфигурацию хоста и daemon, дополняя сканеры образов.
• Минимизация: distroless или alpine-базы без компиляторов и пакетных менеджеров в финальном слое, многоэтапная сборка.
• Фиксация версии: ссылка на образ по digest вместо тега latest, чтобы обновление базы оставалось управляемым событием.
• Доверенные реестры: образы тянутся из внутреннего или проверенного источника, сторонние образы перед использованием сканируются.
• Свежесть: правило пересборки базового образа, например не реже одного раза в 30 дней, и внеплановая пересборка при выходе критического патча.
• Подписи: проверка подписи образа перед развёртыванием, чтобы в продакшн попадали только ожидаемые артефакты.

Цель формулируется количественно: количество уязвимостей уровня CRITICAL в образе, попавшем в реестр, равно нулю; доля образов с зафиксированным digest равна 100%. Возраст базового образа измеряется в днях и сравнивается с установленным порогом.

Контроль секретов: где хранить и как проверять

Типовые утечки выглядят одинаково в разных командах: пароли и токены в ENV и ARG в Dockerfile, в .env, попавшем в контекст сборки, в командной строке при сборке и запуске, в слоях образа (пароль остаётся видимым в docker history), в переменных окружения контейнера, которые читаются через docker inspect и /proc.

• Секреты передают на этапе запуска, а не встраивают в образ: Docker secrets, внешнее хранилище вроде Vault или облачного менеджера секретов, монтирование файла секрета только для чтения.
• В CI секреты подставляются из защищённого хранилища пайплайна и маскируются в логах сборки.
• Токены доступа к реестру вместо пароля: список personal access tokens доступен постранично через API (List personal access tokens), запросы аутентифицируются по схеме OAuth 2.0 Bearer Token (Docker Hub API 2-beta, схема аутентификации). Управление политиками организации ограничено лимитом в 100 политик на организацию (Update policy), поэтому правила доступа стоит держать компактными.
• Проверки: поиск секретов в слоях образа сканером, аудит переменных окружения работающих контейнеров, ротация и отзыв неиспользуемых токенов.

Метрики направления: число секретов, обнаруженных в образах за период, равно нулю; доля действующих токенов с истёкшим сроком жизни равна нулю.

Аудит Docker daemon: конфигурация и доступ

Кто получил доступ к Docker daemon, тот управляет всеми контейнерами и может смонтировать корень хоста. Это главный аргумент в пользу отдельного направления аудита.

• Сокет /var/run/docker.sock: владелец root, режим 660, состав группы docker пересматривается, поскольку членство в ней равно административным правам на хосте.
• Удалённый доступ: API не публикуется на 0.0.0.0:2375 без TLS, для внешних подключений используется защищённый порт с сертификатами и проверкой клиента.
• daemon.json: userns-remap, no-new-privileges, live-restore, ограничения default-ulimits, настроенный log-driver для сбора событий.
• Журнал событий daemon и его выгрузка во внешнее хранилище: действия с контейнерами не должны теряться при компрометации хоста.
• Регулярная проверка конфигурации: Docker Bench for Security прогоняет набор правил и выдаёт список отклонений с указанием пункта.
• Обновления: версия Docker Engine и ядра хоста входят в область аудита, часть уязвимостей закрывается только обновлением.

Формулирование целей аудита для разных этапов жизненного цикла

Одна и та же зона риска даёт разные цели на разных этапах. Разработка отвечает за то, что попадает в образ. CI/CD отвечает за то, что попадает в реестр. Продакшн отвечает за то, что работает сейчас. Шаблон записи цели одинаков: объект, критерий, инструмент, периодичность или триггер, владелец. Как связать такие цели с общим планом проверок и отчётом, показано в материале Комплексный аудит безопасности IT-инфраструктуры: практический план для DevOps и администраторов.

Цели аудита на этапе разработки

• Доля Dockerfile с непривилегированным USER равна 100%. Инструмент: линтер Dockerfile (hadolint) в pre-commit-хуке или проверка в CI.
• Ноль секретов в образах и в истории сборки. Инструмент: сканер секретов локально и в пайплайне.
• Базовый образ выбран из доверенного реестра, зафиксирован по digest и собран из минимального набора пакетов. Инструмент: ревью Dockerfile и манифеста сборки.
• Каждый образ проходит сканирование Trivy перед пушем: критерий - отсутствие CRITICAL-уязвимостей, для которых доступно исправление.
• Ноль инструкций, требующих привилегий: запрет --privileged и монтирования docker.sock в шаблонах запуска для разработки.

Цели аудита в CI/CD

• Автоматическое сканирование каждого собираемого образа, доля сборок с отчётом равна 100%. Инструменты: Trivy в шаге пайплайна, Clair как сервис сканирования реестра.
• Блокировка сборки при обнаружении секретов или уязвимости CRITICAL с доступным патчем.
• Проверка подписи образа перед деплоем: в продакшн попадают только подписанные артефакты.
• Сборка SBOM и сохранение отчёта рядом с артефактом, чтобы через месяц можно было ответить, какие версии библиотек вошли в релиз.
• Прогон Docker Bench for Security на эталонном хосте раннера после изменения конфигурации.

OWASP DevSecOps Maturity Model описывает практики интеграции безопасности в разработку и CI/CD и выделяет пять областей: Build and Deployment, Culture and Organization, Implementation, Information Gathering, Test and Verification, каждая из которых разложена по пяти уровням зрелости (Зависит от цели. Оценка процессов разработки безопасного ПО). Такая шкала помогает выбрать один-два достижимых шага вместо попытки закрыть все практики сразу.

Цели аудита в продакшне

• Ежемесячный аудит хостов через Docker Bench for Security с планом устранения отклонений и повторной проверкой.
• Мониторинг аномального поведения контейнеров: запуск интерактивной оболочки, обращения к docker.sock из контейнера, нехарактерные сетевые соединения. Инструмент: Falco или аналогичный runtime-сенсор.
• Контроль свежести: доля контейнеров, чей образ старше 30 дней, равна нулю; время до пересборки после выхода критического патча не превышает 7 дней.
• Инвентаризация привилегий: ноль контейнеров с --privileged, host-сетью и смонтированным docker.sock.
• Ротация секретов и токенов доступа к реестру по расписанию, отзыв неиспользуемых.

Инструменты для аудита безопасности Docker: сравнение и выбор

Три инструмента закрывают разные точки контроля: конфигурацию хоста, артефакт до попадания в реестр, содержимое реестра. Методологическую рамку дают OWASP SAMM, DSOMM и BSIMM, они не заменяют сканеры, а задают последовательность шагов и целевой уровень зрелости. Назначение инструментов приведено по постановке задачи; конкретные параметры запуска и формат отчётов проверяйте в официальной документации, поскольку использованные источники их не раскрывают.

Порядок выбора простой. Для быстрой оценки состояния хостов нужен Docker Bench for Security. Для встраивания проверок в сборку подходит Trivy. Для непрерывного контроля реестра выбирают Clair как сервис. Как эти проверки сочетаются с общим алгоритмом аудита, включая оценку рисков и шаблон отчёта, описано в материале Аудит безопасности: пошаговое практическое руководство для администраторов.

Как превратить цели в измеримые метрики и KPI

Цель становится управляемой, когда её можно посчитать. Принцип SMART разбирает формулировку на части: конкретность, измеримость, достижимость, relevance (значимость для задачи) и ограничение по времени. Практический перевод выглядит так: вместо «повысить безопасность образов» ставится «снизить число CRITICAL-уязвимостей в образе до нуля в течение 14 дней с момента обнаружения».

Метрика без владельца и порога не работает. Для каждой строки таблицы фиксируются ответственный, порог срабатывания и действие при выходе за порог: например, при доле контейнеров от root выше нуля запускается задача на исправление с приоритетом выше обычных доработок.

Учёт регуляторных требований: Приказ ФСТЭК №21 и другие стандарты

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

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

Приказ регулирует защиту персональных данных, а не аудит Docker как таковой, поэтому его положения применяются косвенно и требуют перевода на язык контейнерных проверок. Международные компании чаще ориентируются на ISO 27001 и PCI DSS. Отличия аудита на соответствие этим стандартам от технического аудита конфигураций разобраны в статье Аудит безопасности IT-инфраструктуры: виды, классификация и выбор подхода.

Пример чек-листа целей аудита для вашей инфраструктуры

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

1. Разработка. В 100% Dockerfile задан непривилегированный USER. Инструмент: hadolint. Метрика: доля файлов с USER.
2. Разработка. В образах нет секретов и токенов. Инструмент: сканер секретов в pre-commit. Метрика: число находок за период, целевое значение ноль.
3. Разработка. Базовый образ зафиксирован по digest и входит в список доверенных. Инструмент: ревью Dockerfile. Метрика: доля образов с digest.
4. CI/CD. Каждый образ сканируется до публикации в реестр. Инструмент: Trivy или Clair. Метрика: доля сборок с отчётом, целевое значение 100%.
5. CI/CD. Сборка блокируется при секретах и при CRITICAL-уязвимостях с доступным патчем. Инструмент: правила пайплайна. Метрика: число инцидентов, дошедших до реестра.
6. CI/CD. В продакшн попадают только подписанные образы. Инструмент: проверка подписи в шаге деплоя. Метрика: доля развёртываний с проверенной подписью.
7. Реестр. Токены доступа выданы персонально, лишние отозваны. Инструмент: API реестра для списка токенов. Метрика: число неиспользуемых токенов, целевое значение ноль.
8. Хосты. Сокет docker.sock доступен только root и группе docker, состав группы пересматривается. Инструмент: проверка прав файла. Метрика: число пользователей вне согласованного списка.
9. Хосты. API daemon не опубликован без TLS. Инструмент: аудит daemon.json и слушающих портов. Метрика: число хостов с открытым небезопасным портом, целевое значение ноль.
10. Хосты. Проверка конфигурации по расписанию. Инструмент: Docker Bench for Security. Метрика: доля хостов с пройденной проверкой за месяц.
11. Продакшн. Ноль контейнеров с --privileged, host-сетью и смонтированным docker.sock. Инструмент: инвентаризация запущенных контейнеров. Метрика: число нарушений.
12. Продакшн. Аномальное поведение контейнеров отслеживается. Инструмент: runtime-сенсор (Falco). Метрика: время реакции на событие.
13. Продакшн. Образы обновляются по регламенту. Метрика: средний возраст базового образа в днях.
14. Процесс. Отчёты аудита сохраняются и пересматриваются. Метрика: доля отклонений, закрытых в срок.

Разумный порядок адаптации: сначала закрыть критичные для конкретной инфраструктуры пункты, затем расширять охват. Если в проде нет привилегированных контейнеров, начните с доступа к daemon. Если есть внешние подключения, приоритет у TLS и токенов реестра.

Заключение: от целей к системному снижению рисков

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

Стартовый набор шагов: снять инвентаризацию хостов и запущенных контейнеров, прогнать Docker Bench for Security на продовых хостах, просканировать образы в реестре Trivy или Clair, зафиксировать ноль привилегированных контейнеров как метрику и включить сканирование в пайплайн. Дальше расширяйте охват: секреты, подписи, SBOM, требования регуляторов. Общая стратегия проверок и актуальный набор инструментов собраны в руководстве Практическое руководство по аудиту безопасности IT-инфраструктуры: стратегии и инструменты на 2026 год.