Контейнеризация и безопасность

Почему контейнеры так популярны?

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

Более половины всех приложений в мире в той или иной степени контейнеризована. По оценке компании Gartner, контейнеры и Kubernetes (открытое программное обеспечение для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями) использует около 70% компаний. Такой впечатляющий рост за последние 4-5 лет, прежде всего, обусловлен переходом от виртуальных машин и монолитных приложений к микросервисной архитектуре, обладающей такими преимуществами, как:

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

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

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

• Небольшое потребление ресурсов – так как контейнер представляет из себя лишь упакованное приложение, а нередко – и всего лишь один процесс, сильно уменьшается нагрузка на ресурсы компьютера.

• Контейнеры прекрасно соответствуют современной методологии непрерывной интеграции и развертывания (CI/CD – continuous integration, continuous delivery), помогающей выпускать обновления приложений быстрее и с меньшим числом ошибок. Данный подход предусматривает короткий цикл разработки, параллельную работу команд над одним кодом, автоматизацию рутинных действий. Применение контейнеризации в конвейере CI/CD тоже повышает его эффективность. Важно, что обновление поставляется в виде нового образа, а не разворачивается внутри существующего и эксплуатируемого контейнера, в результате чего ускоряются подготовка и отладка релиза, снижаются требования к инфраструктуре разработчика и заказчика, повышается стабильность работы и облегчается масштабирование приложения.

Риски и угрозы, связанные с технологией контейнеризации

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

Первый риск – развёртывание контейнера из уязвимого образа, содержащего уязвимый пакет, вредоносную программу или открытые пароли. Подобный образ, например, может быть скачан из публичного реестра. Например, совсем недавно в публичном репозитории Docker Hub были обнаружены порядка 1650 образов контейнеров, содержащих вредоносный софт. Уязвимость может также содержаться в базовом образе. По данным исследования компании Snyk, 10 самых популярных образов в Docker Hub содержали ошибки безопасности системных библиотек. А официальный образ Node.js включает в себя 580 уязвимых системных библиотек.

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

Риски для ИБ могут также скрываться и в слабых настройках и уязвимостях компонентов Kubernetes. Для API-сервера это, например, — возможность анонимного доступа или осуществления неавторизованных запросов, отсутствие RBAC, использование небезопасных портов. Для хранилища Kubernetes под слабыми настройками могут подразумеваться небезопасные методы подключения, возможность соединения без использования сертификатов.

Вот, например, как видит основные угрозы для контейнеров лаборатория Касперского поэлементно – для: 1) образов, 2) реестра образов, 3) оркестратора, 4) контейнеров, 5) ОС хоста:

Сложности защиты контейнеров традиционными средствами ИБ

Многие подходы, уже давно успешно применяемые для защиты виртуальных машин, не годятся для контейнеров. Например, внутри контейнера обычно невозможно запустить агент EDR-решения, как это обычно делается на виртуальных машинах. Более того, происходящее в контейнере не полностью доступно для анализа обычным системам защиты на хост-системе. Поэтому внутри контейнера весьма затруднительно обнаружить вредоносный софт. Так же сложно применять к контейнеризованным приложениям и межсетевые экраны для защиты веб-приложений (WAF). Мало того, поскольку трафик между контейнерами часто передается при помощи виртуальной сети на уровне оркестратора, то и он может быть недоступен инструментам сетевой безопасности.

Даже на ОС хоста неадаптированный агент защиты может привести к резкому падению производительности или к нестабильности развернутых контейнерных приложений. Безопасность кластера должна быть обеспечена на хосте с учетом конкретной примененной среды оркестрации и характера контейнерных нагрузок.

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

Защита защиты контейнеров штатными средствами и DevSecOps

Производители сред контейнеризации постоянно работают над повышением безопасности своих решений. Например, с помощью штатных средств Kubernetes можно настроить квотирование ресурсов, политику логирования, внедрить ролевой метод доступа (RBAC, role based access control), основанный на наименьших привилегиях. Но все равно остаются многие классы задач ИБ, которые не решаются с помощью только штатных инструментов защиты – контроль процессов внутри запущенного контейнера, анализ на уязвимости, контроль соответствия ИБ-политикам и лучшим практикам и т.п.

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

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

• Этап создания и тестирования. Здесь необходима уверенность, что в образ контейнера не попали «бэкдоры» и «люки», уязвимые версии библиотек, вредоносы, а также, что учтены все требования регуляторов и самой организации. Сборка приложения не может успешно завершиться, если часть ИБ-политик нарушена. Это делается при помощи интеграции системы контейнерной безопасности с платформой CI/CD, например, CircleCI, Jenkins или Gitlab.

• Этап доставки и развертывания. Образы, передаваемые в эксплуатацию, должны быть проверены на целостность и полностью соответствовать принятым ИБ-политикам. Если есть исключения, как правило, связанные с отсутствием патча на недавно обнаруженную уязвимость, то такие исключения должны быть документированными и ограниченными во времени.

• Этап выполнения. Здесь должны быть минимизированы (или исключены) риски, связанные с уязвимостями самой среды выполнения или ее неверной настройки. Здесь и только здесь можно выявить различные аномалии в работе самого приложения – слишком высокая вычислительная нагрузка, непредусмотренные коммуникации с другими контейнерами и сетью в целом и пр. На этом этапе также проверяется безопасность настроек самого оркестратора и доступа к нему.

Меры защиты для компонентов контейнерной среды

В заключение хотелось бы отметить, что в общем-то меры защиты из приведенной выше матрицы можно реализовать и отдельно, каждую — с помощью своего инструмента или же просто ручными настройками. Но такой подход, скорее всего, приведет к очень большим трудозатратам и вряд ли окажется эффективным. Следует использовать комплексные защитные решения, интегрированные как с платформой контейнеризации и конвейером CI/CD, так и с используемым в компании ИБ-инструментарием. Кстати, именно таких комплексных отечественных решений и не хватает российским разработчикам.

Автор: Попов Алексей Юрьевич, Эксперт-преподаватель Академии Информационных Систем, автор методик по управлению проектами, бизнес-тренер.