Контейнеры для приложений: риски безопасности и ключевые решения по защите

Контейнеры для приложений: риски безопасности и ключевые решения по защите

Хотя сама по себе технология контейнеризации — это не новое явление, за последние 3—5 лет её популярность возросла на фоне принятия методологии DevOps. Разработчики полюбили контейнеры за простоту и избавление от проблем совместимости. Однако для эффективного и безопасного перехода к микросервисной архитектуре необходимо обеспечить защиту среды контейнеризации и программных образов в совокупности. На рынке ИБ доступны две универсальных платформы, с помощью которых можно этого добиться: Aqua Cloud Native Security Platform и Prisma Cloud Compute Edition.

 

 

 

  1. Введение
  2. Принципы работы
  3. Риски, связанные с контейнерной технологией
  4. Сравнение платформ по защите контейнеров
    1. 4.1. Архитектура Aqua Cloud Native Security Platform и Prisma Cloud Compute Edition
    2. 4.2. Сравнение функциональности Aqua Cloud Native Security Platform и Prisma Cloud Compute Edition
    3. 4.3. Защита во время исполнения (runtime)
    4. 4.4. Сетевой экран веб-приложений (WAF) от Prisma Cloud Compute
    5. 4.5. Виртуальный патчинг от Aqua Security
  5. Выводы

 

Введение

Применение технологии контейнеризации для работы приложений прогрессирует заметными темпами, и согласно исследованию 451 Research ожидается, что в 2020 году скорость роста увеличится ещё на 40%. Gartner прогнозирует, что к 2022 году более 75% организаций будут использовать контейнерные технологии, а объём этого рынка составит 4,3 миллиарда долларов США.

Такой рост обусловлен переходом от виртуальных машин и монолитных приложений к микросервисной архитектуре, обладающей следующими преимуществами:

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

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

 

Рисунок 1. Визуальное представление работы контейнеров и виртуальных машин на сервере

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

 

Принципы работы

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

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

 

Рисунок 2. Пример того, как может выглядеть докер-файл для простого приложения, написанного на языке Python

 Пример того, как может выглядеть докер-файл для простого приложения, написанного на языке Python

 

После написания докер-файла и запуска команды сборки образ Docker собирается и отправляется в реестр (registry). Реестр может быть как приватным (внутри организации), так и публичным (например, Docker Hub).

 

Рисунок 3. Архитектура работы Docker

 Архитектура работы Docker

 

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

Комплексное корпоративное приложение требует обеспечения отказоустойчивости, балансировки, контроля трафика, бесшовного обновления, автоматического восстановления и т. д. С этими задачами прекрасно справляются средства оркестровки: Kubernetes или OpenShift. Оркестратор состоит из рабочих (worker) нод, на которых исполняется продуктивное приложение, и мастер-ноды, которая обеспечивает централизованное управление системой.

Применение Docker, Kubernetes и микросервисов нашло своё успешное применение в DevOps на этапах тестирования публикуемого разработчиками кода, а также размещения в продуктивной среде.

 

Рисунок 4. Пример конвейерной последовательности («пайплайна») CI / CD

 Пример конвейерной последовательности («пайплайна») CI / CD

 

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

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

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

 

Рисунок 5. Верхнеуровневая схема атаки на сервер с помощью уязвимого образа

 Верхнеуровневая схема атаки на сервер с помощью уязвимого образа

 

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

 Сборка образа посредством импорта вредоносной программы, файла паролей, перечня уязвимых пакетов

 

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

 

Рисунок 7. Число уязвимостей в самых популярных образах на Docker Hub

 Число уязвимостей в самых популярных образах на 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

 Архитектура 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.

Компоненты

  • Aqua Server — центральный компонент управления Aqua Security Platform;
  • Aqua Gateway — обеспечивает взаимодействие между компонентом управления и Aqua Enforcer, а также отправку событий в сторонние системы (SIEM, IRP);
  • Aqua Enforcer — обеспечивает защиту среды выполнения контейнеров, хостов, виртуальных машин и лямбда-функций;
  • PostgreSQL DB — база данных, используемая компонентами Aqua;
  • Aqua CyberCenter — облачная служба данных киберразведки от лучших мировых сервисов: NVD, Mitre, CVSS, Red Hat
  • Twistlock Console — основной компонент управления. Выполняет сканирование образов. Поставляется с внутренней базой данных без возможности использования внешней БД;
  • Twistlock Defender — обеспечивает защиту среды выполнения контейнеров и хостов;
  • Twistlock Intelligence Stream — облачная служба данных киберразведки от лучших мировых сервисов: NVD, Mitre, CVSS, Red Hat

4.

Организация взаимодействия компонентов кластера по SSL

Всё взаимодействие между компонентами происходит по зашифрованному каналу. Взаимодействие контейнерной среды по SSL обеспечивается средствами оркестратора

5.

Возможность настройки использования TLS-сертификатов для шифрованного взаимодействия

Сертификат выписывается внутренним УЦ решения для взаимодействия всех компонентов. Сертификаты для контейнерной среды настраиваются оркестратором

6.

Возможность написания правил для ограничения взаимодействия контейнеров

  • Функциональность списков контроля доступа (ACL), сетевого экрана для создания правил взаимодействия контейнеров, хостов, виртуальных машин;
  • функциональность объединения групп контейнеров, хостов, виртуальных машин в сервис с возможностью обучения сетевого взаимодействия внутри него (или между сервисами), а также автоматического создания правил и карты сетевого взаимодействия;
  • утилита Kube-hunter, позволяющая проводить простые тесты на проникновение и эмулировать атаки на кластер Kubernetes с составлением отчёта
  • Функциональность списков контроля доступа (ACL), сетевого экрана для создания правил взаимодействия контейнеров, хостов;
  • обучение сетевого взаимодействия контейнеров и хостов, составление карты взаимодействия и предложения автоматических правил;
  • функциональность брандмауэра веб-приложений (WAF)

7.

Визуализация взаимодействия между компонентами (пространства имён, поды)

Поддержка полной визуализации взаимодействия между компонентами кластера (-ов) в консоли управления

8.

Сканирование образов в реестрах на наличие уязвимостей

  • Сканирование на уязвимости, наличие критических данных внутри контейнеров (приватные ключи, пароли), вирусы;
  • сканирование хостов на наличие образов / контейнеров, не хранящихся ни в одном репозитории;
  • сканирование библиотек исходного кода приложения на наличие уязвимостей с использованием CTI Feeds (Aqua CyberCenter);
  • применение техник виртуального патчинга на время устранения найденной уязвимости или ожидания патча от вендора
  • Сканирование на уязвимости, наличие критических данных внутри контейнеров (приватные ключи, пароли), вирусы;
  • сканирование хостов на наличие образов / контейнеров, не хранящихся ни в одном репозитории;
  • сканирование библиотек исходного кода приложения на наличие уязвимостей;
  • возможность определения собственных типов уязвимостей и импорта MD5-сумм бинарных файлов

9.

Сканирование образа на наличие открытых паролей

Сканирование на наличие критических данных внутри образов (приватные ключи, пароли) или в коде приложения

10.

Проверка цифровой подписи контейнера перед его развёртыванием на ноде

Проверка хеш-суммы образа. Контейнер подписывается внутренним УЦ Aqua. Дополнительная подпись и проверка реализуются оркестратором

Проверка хеш-суммы образа. Дополнительная подпись и проверка реализуются оркестратором

11.

Защита контейнеров от изменений. Контроль среды выполнения

  • Защита от изменений при помощи хеширования содержимого каждого образа;
  • защита от изменений согласно определённым политикам среды выполнения;
  • запрет на выполнение;
  • запрет доступа к файлам, режим «только чтение»;
  • запрет исполнения команд ОС;
  • запрет подключения с определённых IP-адресов;
  • запрет повышения привилегий, использования учётной записи «root»;
  • запрет доступа к определённым пакетам ОС;
  • запрет на сканирование портов, блокировка ненужных портов;
  • запрет использования нестандартных базовых образов

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.

Протоколирование действий пользователей

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

  • действия в консоли,
  • действия, связанные с Container Engine,
  • действия внутри контейнера (имя пользователя, имя контейнера, имя образа, ID процесса),
  • события, связанные с найденными уязвимостями,
  • действия, связанные с использованием Docker API или команд на контейнере, хосте,
  • действия, связанные с использованием LambdaFunction,
  • события по политикам Host Runtime,
  • действия на хостах,
  • события успешных / неуспешных попыток входа,
  • действия пользователей в оркестраторе

22.

Мониторинг чтения / записи файлов, атрибутов, директорий на хосте

Поддерживается

23.

Отслеживание аномальной активности на хосте (например, брутфорс)

Аудит всех действий на хосте, всех исполняемых процессов, использования команд и передаваемых аргументов, сетевых взаимодействий с участием хоста

24.

Реализация модели доступа RBAC

Ролевая модель реализуется только по доступу к консоли управления. Есть возможность определять свои роли с настройкой доступов на чтение / изменение к определённым компонентам

25.

Управление сертификатами (PKI)

Реализуется при помощи оркестратора

26.

Проверка на соответствие

PCI, GDPR, HIPAA, NIST SP 800-190

PCI, GDPR, HIPAA, NIST SP 800-190

27.

Поддерживаемые реестры образов (image registries)

  • Amazon EC2 Container Registry;
  • Google Cloud Platform Container Registry;
  • Azure CR;
  • Cloud Foundry Registry;
  • Harbor;
  • Docker;
  • CoreOS Quay;
  • JFrog Artifactory;
  • OpenShift Container Registry;
  • Red Hat Atomic Registry;
  • Sonatype Nexus Repository OSS;
  • любой другой реестр, поддерживающий API
  • Amazon EC2 Container Registry;
  • Google Cloud Platform Container Registry;
  • Harbor;
  • Docker;
  • JFrog Artifactory;
  • Sonatype Nexus Repository OSS

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)

 Верхнеуровневая схема работы 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, созданы для упрощения контроля безопасности контейнерной среды. Развернув дополнительно по одному агенту на каждую ноду, можно получить сразу несколько механизмов безопасности «из коробки», что существенно сокращает риски финансовых и репутационных потерь от атаки злоумышленника на развёрнутое в среде контейнеризации приложение. Выбор того или иного инструмента зависит от потребностей отдела безопасности и бизнеса, но тенденция такова, что с ростом перехода на контейнеры популярность подобных решений будет только расти.

Anti-Malware Яндекс ДзенПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

RSS: Новые статьи на Anti-Malware.ru