Прозрачность образов влечёт… О системе мониторинга безопасности контейнеров в Runtime

Прозрачность образов влечёт… О системе мониторинга безопасности контейнеров в Runtime

Сейчас большинство разработчиков приложений используют контейнеры для развёртывания инфраструктуры, выбирая этот способ по ряду факторов — портативность, возможность масштабирования, отказоустойчивость, гибкость в процессах доработки и эффективность. Контейнеризация уже прочно вошла в процесс DevOps, но известно, что образ любого контейнера может содержать ошибки и уязвимости, которые могут привести к угрозам работы всего сервиса. Поэтому крайне важно вовремя отследить, какие образы используют сервисы компании и насколько они безопасны. 

Когда в процесс DevOps необходимо включить Security?

При разработке ПО приложений чаще всего используются сторонние библиотеки (зависимости), но ключевой вопрос безопасности — насколько им можно доверять. В распоряжении разработчиков огромное количество различных ресурсов, но не все они лишены уязвимостей. Например, в популярных Java-библиотеках или криптографических пакетах до сих пор часто встречаются:

• Уязвимость Log4j (CVE-2021-44228) сохраняет в логах строчку, которая может загрузить и запустить из системы вредоносный скрипт злоумышленника, что приведёт к полному захвату приложения и сервера. 
• Уязвимость SpringFramework (CVE-2021-22698) даёт возможность дистанционного запуска вредоносного кода (RCE). 
• Уязвимость OpenSSL Heartbleed (CVE-2014-0160) даёт возможность перехватывать информацию, защищённую шифрованием SSL/TLS. Злоумышленники могут украсть секреты, данные пользователей, информацию из электронной почты и документов, не оставив никаких следов. 

Кроме того, активно развивается тенденция общего технического усложнения всех процессов — с появлением новых прогрессивных инструментов оценки защищённости уязвимости также становятся более изощрёнными. 

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

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

Но возникает вопрос, как правильно организовать и технически реализовать мониторинг контейнеров в Runtime, особенно если это сложная инфраструктура с большим количеством компонентов? В этой статье на примере опыта «Дзена» расскажем, как была реализована эта задача с помощью доработанных инструментов Opensource. 

Контекст

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

Поэтому перед нашей командой автоматизации ИБ стояла задача обеспечить их необходимыми инструментами контроля. Нам надо было создать удобные технические решения, которые закрыли бы вопросы по инвентаризации сервисов — сколько и каких сервисов запущено, какие они имеют компоненты и лицензии компонентов, и по работе с уязвимостями — быстрому поиску, приоритизации и устранению. Мы сразу решили, что будем создавать собственное решение на базе Opensource. 

Рисунок 1. Для понимания, как данное решение было встроено в классическую модель организации инструментов DevSecOps, уточним, что с помощью данной разработки мы работаем сразу на четырёх этапах процесса — Release, Deploy, Operate и Monitor

Для понимания, как данное решение было встроено в классическую модель организации инструментов DevSecOps, уточним, что с помощью данной разработки мы работаем сразу на четырёх этапах процесса — Release, Deploy, Operate и Monitor (рис. 1). На этапе Release происходит анализ контейнеров и пакетов, на этапе Deploy — отслеживание зависимостей, а в Operate — анализ уже запущенных контейнеров, что позволяет реализовать механизм оперативного обнаружения уязвимых зависимостей и контейнеров. И всё это, по сути, и складывается в систему Monitor. 

Наша реализация на Opensource

Сначала надо было составить представление, из каких компонентов состоит сервис, и для этого нам потребовалось создать Software Bill of Materials (SBOM) — структурированный список компонентов программного обеспечения, используемых в контейнерах, и мы выбрали формат CycloneDX. В качестве инструмента для создания SBOM было выбрано решение Trivy, которое позволяет выявить известные уязвимости в компонентах для последующего анализа и реагирования на потенциальные угрозы. 

Чтобы предоставить аналитикам ИБ удобный инструмент для сканирования на уязвимости и управление рисками, сначала мы выбрали платформу для анализа компонентов Dependency-Track. Почему выбор пал на это решение? 

Dependency-Track — это интеллектуальная платформа, которая позволяет выявлять и снижать риски в цепочке поставок программного обеспечения. Она применяет уникальный и очень выгодный подход, используя возможности и спецификации программного обеспечения (SBOM). Кроме того, платформа имеет встроенные инструменты для выявления уязвимых компонентов — National Vulnerability Database (NVD), Sonatype OSS Index, GitHub Advisories, Snyk, OSV, VulnDB (Risk Based Security). 

Однако в процессе тестирования оказалось, что Trivy сканирует собственные SBOM на уязвимости лучше, чем это делают сторонние решения, в том числе Dependency-Track. Поэтому мы кастомизировали данные решения: сделали ещё один плагин для выявления уязвимых компонентов для Dependency-Track на базе Trivy — Trivy-REST. Этот инструмент предоставляет REST API для взаимодействия с Trivy, обеспечивая возможность автоматизированного сканирования компонентов и получения результатов анализа.  

Одновременно с этим был также создан собственный сканер, который включает в себя планировщик для выполнения следующих задач:

• автоматическое создание SBOM новых Docker-образов;
• автоматическая отправка SBOM всех Docker-образов в Dependency-Track.

В итоге у нас получилась следующая архитектура решения — рис. 2.

Рисунок 2. Архитектура решения

Механика процесса

• Сканер периодически запрашивает список запущенных в облаке образов, обеспечивая актуальность данных мониторинга.
• Сканер получает информацию по каждому образу из registry. В качестве уникального идентификатора образов служит хеш-сумма (Digest).
• Сканер посредством Trivy создаёт SBOM в формате CycloneDX и сохраняет его в базу данных.
• Также сканер посредством другого планировщика создаёт проект в Dependency-Track и отправляет SBOM. Отправляются как новые SBOM, так и уже существующие. Поскольку база уязвимостей периодически обновляется, следует пересканировать уже существующие образы. 
• Dependency-Track, используя Trivy-REST, анализирует компоненты.

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

Рисунок 3. Последовательность взаимодействия внутри системы

Какой эффект?

Благодаря собранному решению удалось добиться следующих результатов.

• Актуальность данных. Регулярное сканирование контейнеров и создание SBOM позволяет всегда получать самую последнюю информацию о составе контейнеров и их уязвимостях.
• Автоматизация процесса. Использование планировщиков обеспечивает непрерывный мониторинг безопасности, устраняя необходимость вручную запускать процессы сканирования и анализа.
• Наглядность. Dependency-Track предоставляет удобный интерфейс для анализа безопасности контейнеров с централизованным доступом к информации об уязвимостях. Это облегчает процесс принятия решений о приоритетности той или иной уязвимости в составе приложения и позволяет оперативно реагировать на критически важные.
• Универсальность. Так как SBOM достаточно собрать один раз, то облако довольно быстро проверяется на уязвимости при добавлении новых образов.

Отметим, что данная система мониторинга безопасности контейнеров в Runtime может быть легко и в любой момент интегрирована в процессы обеспечения безопасности. Даже если приложение уже функционирует, подобная сквозная автоматизированная система позволит увеличить эффективность взаимодействия между командами ИБ и разработки, особенно в части приоритизации задач по устранению уязвимостей.