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

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

Начнём с того, почему контейнеры завоёвывают симпатии разработчиков и как использование контейнеризации меняет разработку в целом.

Фишки

Легковесность

По сравнению с виртуальными машинами и «железными» серверами контейнеры совершенно нетребовательны к ресурсам. Это позволяет запустить на одной машине значительно больше контейнеров, чем виртуалок. Разработчик может даже запустить на своём компьютере компоненты приложения в виде контейнеризированных микросервисов и ему не придётся дремать в ожидании отклика системы. Благодаря тому, что контейнеры совместно используют ядро системы, их запуск и остановка происходят значительно быстрее, чем перезапуск виртуальной машины.

Изоляция

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

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

Переносимость

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

Репозитории контейнеров

Появление стандарта Open Container Initiative привело к тому, что стало возможным создать публичные библиотеки образов контейнеров и сформировать мощную экосистему, объединившую контейнерные движки, облачные платформы и инструментальные средства для управления контейнерами, проверки безопасности и других задач.

Автоматизация

Использование контейнеров позволяет строить полностью автоматизированные цепочки непрерывной интеграции-развёртывания приложений (CI/CD), в которых «ручной» частью будет в основном написание кода. Тестирование, проверку качества кода, упаковку приложения в Docker-образ, размещения образа на Docker Hub и развёртывание его на хосте для выполнения можно выполнять без участия человека.

Угрозы, связанные с контейнерами

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

Совместное использование ядра

Как всегда, недостатки — обратная сторона преимуществ. Совместное использования ядра снижает избыточность контейнеров по сравнению с виртуальными машинами, но большее количество разрешённых сисколлов делает более тонким защитный барьер, а эксплуатация уязвимостей ядра позволяет атаковать сразу все контейнеры. Как тут не вспомнить про нашумевшие атаки Spectre и Meltdown, которые позволяют прочитать память чужого процесса или ядра из user-space.

Публичные репозитории

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

Примеры

В июне 2018 года 17 контейнеров с вредоносным кодом были удалены с портала Docker Hub, но до этого, в течение нескольких месяцев, их успели загрузить более миллиона раз.
В сентябре 2018 года на GitHub был опубликован пример атаки на установочные пакеты Python, в ходе которой файл setup.py модифицировался для запуска вредоносного кода при установке пакета. Поскольку как правило, этот файл используется только для добавления модуля, его содержимое мало кто проверяет.
В октябре 2018 года была опубликована информация о 12 вредоносных библиотеках, загруженных в каталог PyPi. Библиотеки содержали код для сбора данных, сохранения присутствия на заражённом хосте, запуска реверс-шелла и подмены адресов Bitcoin-кошельков адресом злоумышленника.
В ноябре 2018 года в одной из зависимостей библиотеки Event-Stream, используемой во многих крупных проектах, обнаружен вредоносный код, предназначенный для хищения криптовалюты и проведения атак на связанные с виртуальными средствами сервисы. Event-Stream – популярная библиотека, число ежедневных загрузок которой из репозитория NPM насчитывает около 2 млн.
В январе 2019 года сообщалось о критической уязвимости в модуле pickle популярной Python-библиотеки NumPy, используя которую можно получить возможность удалённого выполнения кода.

Таким образом, для компрометации приложения достаточно одной вредоносной библиотеки. Разумеется, уязвимости и вредоносные функции в популярных библиотеках – проблема не контейнеров как таковых, а технологии, которая обеспечивает быстрое распространение изменений в образах.

Рекомендации

Очевидно, что современный процесс разработки требуют нового подхода, подхода, при котором обеспечение безопасности будет интегрировано в цепочку CI/CD, превратив DevOps в DevSecOps.

По данным Gartner, в 2019 году

более 70% корпоративных процессов разработки будут содержать автоматизированную проверку уязвимостей и конфигураций open-source компонентов и коммерческих пакетов.
более 50% процессов CI/CD будут содержать обязательную встроенную проверку безопасности кода;
более 60% компаний будут использовать в разработке средства контроля версий и управления автоматизацией инфраструктуры.

Рассмотрим некоторые компоненты, которые должны присутствовать в процессе, чтобы слово «Sec» в его названии не было пустым звуком.

Интеграция проверок во все процессы

Проверка безопасности должна присутствовать на всех стадиях процесса разработки от создания кода до его контейнеризации и развёртывания.

Автоматизация проверок безопасности

Необходима по двум причинам:

Это уменьшит количество ошибок администрирования и неправильного конфигурирования.
Специалистам по безопасности не придётся вручную проверять код и менять настройки.

API для защитных функций

Реализация такой функциональности требует, чтобы защитная система предоставляла API для доступа ко всем возможностям. Так разработчики cмогут не только использовать систему для проверки, но и внедрить соответствующие вызовы в код.

Контроль доступа на основе ролей

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

Совместимость с Docker Registry API

В идеале защита должна поддерживать сканирование образов Docker в любом реестре, который поддерживает Docker Registry V2 API, чтобы обеспечить совместимость со всеми популярными реестрами.

Защита при миграции

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

В качестве примера защитного решения можно привести Deep Security Smart Check от Trend Micro, которое непрерывно сканирует образы в автоматическом режиме, выявляет уязвимости и вредоносные программы. Smart Check поддерживает контейнерные платформы Docker Trusted Registry, Amazon Elastic Container Registry, Azure Container Registry и Google Container Registry. Кроме того, продукт Trend Micro интегрируется с ведущими системами SIEM и такими инструментами оркестровки как Jenkins, Kubernetes, SumoLogic, Splunk.

Важная особенность Smart Check – соответствие всем требованиям регуляторов в части проверки критичных уязвимостей и протоколирования событий.

Внедрение в процессы DevOps средств обеспечения безопасности контейнеров на ранних стадиях разработки до запуска приложений позволит разрабатывать более надёжное и производительное ПО, а также

обнаружить вредоносные программы и библиотеки.
выявить уязвимости.
исправить ошибки до того, как образы передаются в инструменты оркестровки (например, Kubernetes).
предотвратить выполнение вредоносного кода и развёртывание уязвимого ПО.

По материалам https://habr.com/ru/company/trendmicro/blog/439986/