Хотя сама по себе технология контейнеризации — это не новое явление, за последние 3—5 лет её популярность возросла на фоне принятия методологии DevOps. Разработчики полюбили контейнеры за простоту и избавление от проблем совместимости. Однако для эффективного и безопасного перехода к микросервисной архитектуре необходимо обеспечить защиту среды контейнеризации и программных образов в совокупности. На рынке ИБ доступны две универсальных платформы, с помощью которых можно этого добиться: Aqua Cloud Native Security Platform и Prisma Cloud Compute Edition.
- Введение
- Принципы работы
- Риски, связанные с контейнерной технологией
- Сравнение платформ по защите контейнеров
- 4.1. Архитектура Aqua Cloud Native Security Platform и Prisma Cloud Compute Edition
- 4.2. Сравнение функциональности Aqua Cloud Native Security Platform и Prisma Cloud Compute Edition
- 4.3. Защита во время исполнения (runtime)
- 4.4. Сетевой экран веб-приложений (WAF) от Prisma Cloud Compute
- 4.5. Виртуальный патчинг от Aqua Security
- Выводы
Введение
Применение технологии контейнеризации для работы приложений прогрессирует заметными темпами, и согласно исследованию 451 Research ожидается, что в 2020 году скорость роста увеличится ещё на 40%. Gartner прогнозирует, что к 2022 году более 75% организаций будут использовать контейнерные технологии, а объём этого рынка составит 4,3 миллиарда долларов США.
Такой рост обусловлен переходом от виртуальных машин и монолитных приложений к микросервисной архитектуре, обладающей следующими преимуществами:
- Все зависимости — внутри контейнера. Это упрощает развёртывание приложения. Больше нет необходимости устанавливать дополнительные библиотеки и настраивать сторонние компоненты для корректной работы программы.
- Гарантированная воспроизводимость. Хранение внутри образа всех необходимых зависимостей, названий переменных и конфигурационных файлов гарантирует, что приложение, развёрнутое из этого образа, сможет запуститься.
- Небольшой размер образа. В отличие от образов виртуальных машин, размер которых порой исчисляется десятками гигабайт, правильно собранный образ контейнера может занимать всего лишь несколько килобайт.
- Небольшое потребление ресурсов. Вследствие того что контейнер представляет из себя лишь упакованное приложение, а нередко — и лишь один процесс, сильно уменьшается нагрузка на ресурсы «железа».
Все эти преимущества позволяют снизить операционные расходы на разработку и эксплуатацию приложений.
Рисунок 1. Визуальное представление работы контейнеров и виртуальных машин на сервере
Принципы работы
Перед тем как начать говорить об уязвимостях технологии контейнеризации, необходимо погрузиться в базовые принципы её работы.
Одно из самых известных в мире решений для контейнеризации — Docker. Для того чтобы упаковать приложение в образ Docker, необходимо составить т. н. «докер-файл». Он включает в себя описание используемых зависимостей, конфигурационные файлы, пароли, а также команды для сборки этого приложения.
Рисунок 2. Пример того, как может выглядеть докер-файл для простого приложения, написанного на языке Python
После написания докер-файла и запуска команды сборки образ Docker собирается и отправляется в реестр (registry). Реестр может быть как приватным (внутри организации), так и публичным (например, Docker Hub).
Рисунок 3. Архитектура работы Docker
Как правило, один контейнер представляет собой единственный процесс на хостовом сервере, и этого зачастую недостаточно для работы крупного корпоративного приложения. Приложение становится микросервисным, то есть состоящим из множества работающих вместе контейнеров.
Комплексное корпоративное приложение требует обеспечения отказоустойчивости, балансировки, контроля трафика, бесшовного обновления, автоматического восстановления и т. д. С этими задачами прекрасно справляются средства оркестровки: Kubernetes или OpenShift. Оркестратор состоит из рабочих (worker) нод, на которых исполняется продуктивное приложение, и мастер-ноды, которая обеспечивает централизованное управление системой.
Применение Docker, Kubernetes и микросервисов нашло своё успешное применение в DevOps на этапах тестирования публикуемого разработчиками кода, а также размещения в продуктивной среде.
Рисунок 4. Пример конвейерной последовательности («пайплайна») CI / CD
Риски, связанные с технологией контейнеризации
Несмотря на преимущества, которые даёт контейнеризация приложений, существует и ряд уязвимостей, которые не позволяют внедрить эту технологию повсеместно, без оглядки на безопасность.
Первый риск — развёртывание контейнера из уязвимого образа, т. е. такого, который содержит уязвимый пакет, вредоносную программу или открытые пароли. Подобный образ, например, может быть скачан из публичного реестра.
Рисунок 5. Верхнеуровневая схема атаки на сервер с помощью уязвимого образа
Рисунок 6. Сборка образа посредством импорта вредоносной программы, файла паролей, перечня уязвимых пакетов
Уязвимость может также содержаться в базовом образе. Согласно исследованиям компании Snyk, 10 самых популярных образов в Docker Hub содержат ошибки безопасности системных библиотек. Официальный образ Node.js включает в себя 580 уязвимых системных библиотек. Остальные образы из списка содержат не менее 30 общеизвестных программных изъянов.
Рисунок 7. Число уязвимостей в самых популярных образах на Docker Hub
Помимо образов Docker источником уязвимостей также может являться развёрнутый контейнер. Наличие вредоносного кода, уязвимостей ПО несёт риск того, что злоумышленнику удастся скомпрометировать развёрнутый контейнер, использовать его с повышенными привилегиями, получить доступ к ОС хостового сервера, а далее запустить дочерние вредоносные процессы, подключиться к сторонним ресурсам в интернете, получить доступ к файловой системе и распространить атаки на соседние контейнеры.
Риски для безопасности могут также скрываться в слабых настройках и уязвимостях компонентов Kubernetes. Для API-сервера это, например, — возможность анонимного доступа или осуществления неавторизованных запросов, отсутствие RBAC, использование небезопасных портов. Для хранилища Kubernetes (etcd) под слабыми настройками могут подразумеваться небезопасные методы подключения, возможность соединения без использования сертификатов.
Рисунок 8. Угрозы, исходящие от отсутствия мер защиты среды контейнеризации, и их последствия
К числу других проблем относится контроль событий контейнеров и хостов. В условиях, когда средний срок службы контейнера — несколько часов или даже минут, мониторинг текущих процессов может быть особенно сложной задачей.
Сравнение платформ по защите контейнеров
Проведём сравнение двух наиболее распространённых enterprise-решений такого рода, которые представлены на российском рынке: Aqua Cloud Native Security Platform (CSP) и Prisma Cloud Compute Edition (до покупки Palo Alto Networks имевшего название Twistlock).
Основная функциональность обеих платформ:
- Автоматическая проверка конфигурации на предмет соответствия лучшим практикам для сокращения риска компрометации.
- Контроль взаимодействия (firewall) между элементами контейнеризации (поды, сервисы) для сокращения риска распространения атаки.
- Проверка образов контейнеров в процессе разработки для сокращения риска развёртывания уязвимых образов в продуктивной среде.
- Проверка развёрнутых контейнеров на предмет наличия уязвимостей, открытых паролей, аномальной активности и несоответствия политикам безопасности для сокращения ущерба от атак и кражи паролей.
- Сбор и анализ событий, поступающих от контейнеров и хостов, для обеспечения контроля за инцидентами и эффективного реагирования.
Архитектура Aqua Cloud Native Security Platform и Prisma Cloud Compute Edition
Рисунок 9. Архитектура Aqua CSP
Обе платформы включают в себя два компонента, разворачиваемых в виде контейнеров: консоль управления (Twistlock Console и Aqua Console) и агент сканирования (Twistlick Defender и Aqua Enforcer).
В число функций консоли входят:
- предоставление интерфейса для интерактивного управления решением;
- интеграция со сторонними программными компонентами (SIEM, средство запуска CI / CD);
- сканирование образов контейнеров в реестре.
Агенты сканирования мониторит безопасность запущенных контейнеров во время их выполнения, чтобы обеспечить соблюдение политик, настроенных администратором системы с помощью пользовательского интерфейса на консоли. Агент также гарантирует, что только зарегистрированные и отсканированные образы будут работать на хостах, на которых установлен агент.
Обеим платформам требуется выход в интернет для подключения к собственным базам знаний. База знаний используется при сканировании образов, контейнеров и хостов на предмет уязвимостей и вредоносных программ, содержит чёрный список IP-адресов, актуальные оценки производительности («бенчмарки») и так далее.
С точки зрения архитектуры Aqua CSP отличается тем, что в ней есть два дополнительных компонента — Aqua Gateway и вынесенная за пределы консоли база данных. Aqua Gateway осуществляет взаимодействие между Aqua Console и Aqua Enforcer и размещается по одному компоненту на кластер, в случае если ваши сервисы размещены на разных кластерах. База данных содержит информацию, касающуюся конфигурации Aqua CSP (политики безопасности, роли и пользователи, параметры), и результаты аудита безопасности. Также в отличие от Prisma Cloud Compute, где БД размещена внутри консоли, Aqua позволяет вынести базу данных за пределы кластера на существующих серверах.
Сравнение функциональности Aqua Cloud Native Security Platform и Prisma Cloud Compute Edition
Сравнение функциональных возможностей двух платформ представлено в таблице ниже.
Таблица 1. Сопоставление Aqua Cloud Native Security Platform и Prisma Cloud Compute Edition
|
№ |
Параметр |
Aqua Cloud Native Security Platform |
Prisma Cloud Compute Edition |
|
1. |
Метод развёртывания |
Aqua Enforcer — контейнер на хост |
Twistlock Defender — контейнер на хост |
|
2. |
Варианты развёртывания |
Как в облаке, так и в локальной инфраструктуре (on-premise) |
|
|
3. |
Компоненты |
|
|
|
4. |
Организация взаимодействия компонентов кластера по SSL |
Всё взаимодействие между компонентами происходит по зашифрованному каналу. Взаимодействие контейнерной среды по SSL обеспечивается средствами оркестратора |
|
|
5. |
Возможность настройки использования TLS-сертификатов для шифрованного взаимодействия |
Сертификат выписывается внутренним УЦ решения для взаимодействия всех компонентов. Сертификаты для контейнерной среды настраиваются оркестратором |
|
|
6. |
Возможность написания правил для ограничения взаимодействия контейнеров |
|
|
|
7. |
Визуализация взаимодействия между компонентами (пространства имён, поды) |
Поддержка полной визуализации взаимодействия между компонентами кластера (-ов) в консоли управления |
|
|
8. |
Сканирование образов в реестрах на наличие уязвимостей |
|
|
|
9. |
Сканирование образа на наличие открытых паролей |
Сканирование на наличие критических данных внутри образов (приватные ключи, пароли) или в коде приложения |
|
|
10. |
Проверка цифровой подписи контейнера перед его развёртыванием на ноде |
Проверка хеш-суммы образа. Контейнер подписывается внутренним УЦ Aqua. Дополнительная подпись и проверка реализуются оркестратором |
Проверка хеш-суммы образа. Дополнительная подпись и проверка реализуются оркестратором |
|
11. |
Защита контейнеров от изменений. Контроль среды выполнения |
|
|
|
12. |
Поддержка протоколов автоматизации управления данными безопасности |
SCAP |
|
|
13. |
Наличие собственного хранилища секретов |
Встроенное хранилище секретов Aqua Secret Key Store; интеграция со сторонними Key Vault |
Интеграция со сторонними Key Vault |
|
14. |
Управление секретами и мониторинг доступа |
Назначение секретов на контейнеры, хосты; изменение, удаление, добавление через консоль управления; подставление или переназначение секретов во время выполнения (runtime) |
Только через сторонний Key Vault |
|
15. |
Поиск уязвимостей на хосте |
Сканирование хоста на уязвимости, вирусы аналогично контейнерам |
|
|
16. |
Профилирование контейнера |
Обучение модели на основе работы контейнера (поведенческой модели, в том числе и сетевого взаимодействия) в течение указанного периода. Создание профиля и применение его к другим контейнерам |
Обучение модели на основе работы контейнера в течение 24 часов |
|
17. |
Ограничение ресурсов контейнера (использование AppArmor, SELinux, cgroups) |
Контроль запуска контейнеров по критерию «запущены или нет»: Seccomp, SELinux, apparmor |
Контроль запуска контейнеров по критерию «запущены или нет»: SELinux, apparmor |
|
18. |
Проверка конфигурации k8s |
Встроенная проверка на различные требования (compliance): CIS (Docker CIS, Kubernetes CIS) |
|
|
19. |
Реализация POD security policy |
Реализуется только функциональностью Kubernetes |
|
|
20. |
Шифрование данных, хранящихся в etcd |
Реализуется только функциональностью оркестратора |
|
|
21. |
Протоколирование действий пользователей |
Осуществляется запись в журнал следующих событий:
|
|
|
22. |
Мониторинг чтения / записи файлов, атрибутов, директорий на хосте |
Поддерживается |
|
|
23. |
Отслеживание аномальной активности на хосте (например, брутфорс) |
Аудит всех действий на хосте, всех исполняемых процессов, использования команд и передаваемых аргументов, сетевых взаимодействий с участием хоста |
|
|
24. |
Реализация модели доступа RBAC |
Ролевая модель реализуется только по доступу к консоли управления. Есть возможность определять свои роли с настройкой доступов на чтение / изменение к определённым компонентам |
|
|
25. |
Управление сертификатами (PKI) |
Реализуется при помощи оркестратора |
|
|
26. |
Проверка на соответствие |
PCI, GDPR, HIPAA, NIST SP 800-190 |
PCI, GDPR, HIPAA, NIST SP 800-190 |
|
27. |
Поддерживаемые реестры образов (image registries) |
|
|
|
28. |
CI / CD |
GoCD, TeamCity, Bamboo, GitLab, Jenkins, CircleCI, Azure DevOps |
Jenkins plugin; Twistcli — плагин по интеграции через API к CI / CD. Доработок не требуется |
|
29. |
Реестры |
Docker Hub, Amazon ECR, Google GCR, CoreOS Quay, JFrog Artifactory, Azure ACR |
Docker Hub, Amazon ECR, Google GCR, IBM CCR, JFrog Artifactory, Azure ACR, OpenShift |
|
30. |
Хранилище паролей (Password Vault) |
CyberARK Password Vault, Conjur, AWS KMS, HashiCorp Vault, Azure |
HashiCorp, CyberARK, AWS KMS, Azure |
|
31. |
Active Directory / LDAP |
Поддержка интеграции с LDAP и AD FS |
|
|
32. |
Единый вход (SSO) |
SAML-based authentication, OpenID Connect, Google Apps, AD FS |
SAML-based authentication, OpenID Connect, AD FS |
|
33. |
SIEM и аналитика |
ArcSight, AWS CloudWatch, Datadog, Elasticsearch, Google SCC, Logentries, Loggly, Microsoft OMS, Splunk, Sumo Logic, Syslog, QRadar |
Потенциально — со всеми по Syslog. Нужна доработка коннекторов |
|
34. |
Система отслеживания ошибок |
Jira |
|
|
35. |
Обратная связь |
Slack, PagerDuty |
Slack |
Защита во время исполнения (runtime)
Функция защиты во время исполнения позволяет отследить аномальное поведение развёрнутых контейнеров на основе данных о процессах, сети, обращениях к файловой системе, системных вызовах, данных хоста. Это обеспечивает защиту от криптомайнеров, нежелательных процессов, распространения атаки по сети, нежелательного исходящего соединения, открытых портов, появления вредоносных программ, а также от нежелательных системных вызовов.
Кроме того, обе платформы позволяют обеспечить неизменность контейнера, при которой обновления будут проходить только через конвейер CI / CD, не допуская изменений, разрешённых во время выполнения. И у Aqua CSP, и у Prisma Cloud Compute есть функциональность снятия криптографического отпечатка нескольких слоёв в пределах образа для обеспечения целостности последнего.
Сетевой экран веб-приложений (WAF) от Prisma Cloud Compute
Рисунок 10. Верхнеуровневая схема работы Cloud Native Application Firewall (CNAF)
Отличительной особенностью Prisma Cloud Compute на фоне других решений является встроенный модуль межсетевого экранирования на уровне L7 для веб-приложений — Cloud Native Application Firewall (CNAF). Агент сканирования является в данном случае прокси-сервером HTTP, анализируя поступающие GET- и POST-запросы от клиентов. Для этого Twistlock Defender добавляет новое правило iptables, перенаправляя трафик от веб-приложения через себя. Если соединение защищено с помощью TLS, Defender расшифровывает трафик, проверяет содержимое, а затем повторно шифрует его.
Виртуальный патчинг от Aqua Security
Aqua CSP в свою очередь выделяется такой особенностью, как Aqua Vulnerability Shield (Aqua vShield) — функция виртуального патчинга. Это — запатентованная технология, использующая автоматический анализ уязвимостей для создания runtime-политик, которые могут обнаруживать и блокировать доступ к уязвимым компонентам в контейнерах приложения. Запуск vShield для найденной уязвимости позволит предотвратить её эксплуатацию до того, как разработчики выпустят исправление.
Выводы
Kubernetes не использует механизмы безопасности по умолчанию в силу того, что эти же механизмы, как правило, могут затруднять внедрение и перенос приложений. Технология не стала бы такой популярной и приятной в использовании, если бы первый запуск приложения в контейнерной среде сопровождался проблемами, вызванными чрезмерным контролем. И даже несмотря на то, что Kubernetes или OpenShift имеют в себе безопасные настройки, их использование остается трудоёмким и неконтролируемым для организаций со сложной микросервисной архитектурой и большим числом нод кластера.
Такие платформы, как Aqua Cloud Native Security Platform и Prisma Cloud Compute Edition, созданы для упрощения контроля безопасности контейнерной среды. Развернув дополнительно по одному агенту на каждую ноду, можно получить сразу несколько механизмов безопасности «из коробки», что существенно сокращает риски финансовых и репутационных потерь от атаки злоумышленника на развёрнутое в среде контейнеризации приложение. Выбор того или иного инструмента зависит от потребностей отдела безопасности и бизнеса, но тенденция такова, что с ростом перехода на контейнеры популярность подобных решений будет только расти.
