Неполное руководство по обеспечению безопасности контейнерной среды

(Эта статья представляет собой набор рекомендаций и советов по обеспечению безопасности контейнерных сред. Также есть ранее опубликованная статья об усилении защиты K8S.)

https://hackernoon.com/how-to-harden-k8s-based-on-the-recent-updated-nsas-kubernetes-hardening-guide

И понимание того, как контейнеры создают уникальные проблемы безопасности

Все мы знаем, что запуск облачных контейнеров включает в себя гибкость вращения приложений вверх и вниз для пользователей — или то, что мы называем «[WORA (написать один раз, запустить везде)] (https://www.yourdictionary.com/write-once). -run-anywhere)» и улучшенную интеграцию с DevOps. Они также обеспечивают экономичную инфраструктуру по сравнению с монолитными приложениями, работающими на серверах или виртуальных машинах.

Различные компании, большие или малые, ищут способы запуска своих бизнес-приложений с помощью этой технологии. В результате внедрение контейнерных приложений находится на рекордно высоком уровне. Согласно опросу Cloud Native Computing Foundation (CNCF):

Принятие Kubernetes среди постоянно расширяющегося сообщества облачных разработчиков приближается к 100 %, а это означает, что те, кто инвестирует в облачные решения, заинтересованы в будущем и с нетерпением ждут его.

Ландшафт угроз контейнера

Когда мы изучаем недавние данные, опубликованные Shodan,, 243 469 кластеров K8S  общедоступны. Кроме того, эти  кластеры Kubernetes также выставили порт 10250, используемый kubelet в качестве настройки по умолчанию. В результате злоумышленники могли сканировать Интернет и находить эти кластеры с минимальными усилиями.

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

Чем больше данных хранится в контейнерах, тем выше интерес к кибератакам, направленным на такие приложения. Согласно отчету VMware «[Опрос состояния Kubernetes] (https://hello-tanzu.vmware.com/state-of-kubernetes-2022/) 2022», 97 % организаций обеспокоены безопасностью Kubernetes.

Redhat также предоставляет аналогичные данные в своем «[отчете о состоянии безопасности Kubernetes за 2022 год] (https://www.redhat.com/en/resources/state-kubernetes-security-report)», в котором говорится, что 94% респондентов сталкивались с инцидентом безопасности в своих средах Kubernetes и контейнерах за последние 12 месяцев.

Исследователь безопасности Akamai Ларри Кэшдоллар запустил захватывающий, но тревожный эксперимент, настроив автономный Docker в качестве приманки Dock, чтобы увидеть, как часто и какие атаки будут регистрироваться. Результат пугает. Он специально настроил приманку так, чтобы она выглядела как уязвимый облачный экземпляр.

:::предупреждение

Всего за 24 часа приманка была использована в ЧЕТЫРЕХ различных киберпреступных кампаниях!

Атаки на контейнеры и Kubernetes распространены, и организациям трудно защитить себя. Между тем, предприятия трансформируются, и, несмотря на проблемы с безопасностью, они помещают в них все больше и больше данных.

3 Основные проблемы безопасности в контейнерах

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

1# Неверная конфигурация

Согласно прогнозу Gartner на основе их анализа, к 2025 году 99 % сбоев в обеспечении безопасности в облаке будут связаны с ошибками клиентов. Как вы понимаете, контейнеры часто развертываются в очень динамичных средах. Таким образом, любая неправильная конфигурация, независимо от настроек доступа, сети или других связанных параметров, может привести к скрытой дыре в безопасности для пользователей, но не для киберпреступников.

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

Такие мелкие ошибки могут привести к дорогостоящим проблемам. Когда мы оглядываемся на сентябрь 2021 года, опубликованный Palo Alto Networks, вредоносная программа Siloscape является первой известной вредоносной программой для контейнеров Windows и сильно запутанной вредоносной программой, нацеленной на K8S. . По данным той же исследовательской группы, основная цель Siloscape — открыть лазейку из плохо сконфигурированных кластеров K8S. В результате вредоносное ПО может в дальнейшем запускать вредоносные контейнеры.

2# Образы уязвимых контейнеров

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

Что, если кто-то загрузит предустановленное вредоносное ПО в образы и поместит его в общедоступный репозиторий? Когда кто-то развернул эти образы, вредоносное ПО будет работать в нулевой день без каких-либо действий со стороны злоумышленников. Это особый тип атаки на цепочку поставок.

В 2020 году была обнаружена ошибка (CVE-2020–15157) в программном обеспечении среды выполнения Containerd для полного управления жизненным циклом контейнера. Злоумышленники могут использовать это, создавая специально созданные образы контейнеров для кражи токена хоста, который они втянули в проект. К тому времени, когда они получат токен, они могут замаскироваться под автора и взять в заложники облако. проект.

Еще один пример того, как злоумышленники используют образы вредоносных контейнеров, иллюстрирует Team Nautilus, группа по исследованию угроз из [Aqua Security] (https://blog.aquasec.com/supply-chain-threats-using-container-images). Они обнаружили пять образов контейнеров в Docker Hub, которые использовались для майнинга криптовалюты и как часть атаки на цепочку поставок, специально нацеленной на облачные среды.

3# уязвимости нулевого дня (+ известные CVE)

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

Самый тревожный пример из этой категории — “Azurescape», найденный Palo Alto Networks. Подобно Siloscape, Azurescpe — первая известная уязвимость, позволяющая пользователю общедоступной облачной службы «сбежать» из среды (Microsoft Azure).

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

[Отчет Sysdig за февраль] (https://sysdig.com/blog/2022-cloud-native-security-usage-report/#vulnerabilities) об использовании облачных технологий и систем безопасности показал, что 75 % контейнеров содержат уязвимости высокой степени опасности. Однако в отчете также подчеркивается, что некоторые респонденты заявили, что готовы пойти на эти риски, чтобы двигаться быстрее и быстрее выпускать приложения.

Рекомендации по обеспечению безопасности контейнеров

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

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

0# Непрерывное улучшение

В первую очередь для обеспечения безопасности контейнеров необходимо внедрить методы обеспечения безопасности в конвейер CI/CD и весь процесс сборки, хранения и развертывания образов контейнеров, который включает:

• Статическое тестирование безопасности приложений (SAST);

• Надежное хранение образов контейнеров,

• Сканирование уязвимостей для контейнеров и образов;

• Обеспечение доверия к содержимому изображения.

Глубокоэшелонированная защита (DiD) в контейнерах

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

Следует придерживаться многоуровневого подхода. Для начала сюда входят:

• Конфигурация облачной платформы

• Вычислительный хост (физический или виртуальный)

• Операционная система

• Кластер K8S

• Время выполнения контейнера

• Пространство имен

• Код приложения

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

1# Управление доступом на основе ролей (RBAC)

RBAC — это передний край обороны в Kubernetes. Это позволяет пользователю контролировать, кто может получить доступ к API и их разрешениям. Официальный документ Kubernetes содержит подробное описание [управления доступом на основе ролей (RBAC)] (https://kubernetes.io/docs/reference/access-authn-authz/rbac/). Хотя RBAC включен по умолчанию, просто его включения недостаточно. Политики авторизации следует тщательно обрабатывать и применять должным образом.

Советы. Всегда используйте RBAC с принципом наименьших привилегий.

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

2# Сравнительный анализ и исправление

Как указано выше, неправильная конфигурация является основным источником атак, связанных с контейнерами. Таким образом, чтобы обнаружить эти неправильные конфигурации, нам нужно что-то для сравнения. Центр интернет-безопасности (CIS) является фактическим стандартом среди различных источников передового опыта, контрольных показателей и руководств по усилению защиты, [Центр интернет-безопасности (CIS)] (https://www.cisecurity.org/ ) является стандартом де-факто.

https://www.cisecurity.org/benchmark/kubernetes

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

В конце концов, мы не можем предполагать, что кластер, предоставленный облачным провайдером, полностью защищен. Помимо бенчмаркинга K8S, который является наиболее сложным для специалистов по кибербезопасности, CIS также обеспечивает аналогичную проверку для физических серверов, особенно Linux. CIS имеет тест для независимого от дистрибутива Linux и один тест специально для Debian, Centos, Red Hat и многих других дистрибутивов.

https://www.cisecurity.org/benchmark/distribution_independent_linux/

3# Управление безопасностью в облаке

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

Отдельный элемент управления безопасностью, определенный Gartner для этой области, называется «Управление состоянием облачной безопасности» (CSPM). Изначально CSPM поддерживал вас. в обнаружении и визуализации инвентаризации активов IaaS и PaaS. Но его можно расширить, чтобы помочь вам сэкономить время и свести к минимуму риски для всего вашего стека безопасности облака/контейнера. Согласно Gartner, CSPM должен включать в себя следующие возможности:

• Непрерывная визуализация конфигураций

• Обнаружение активов, классификация и оценка рисков

• Стандартное исправление неправильной конфигурации и ведение журнала

• Отчеты о соответствии стандартам безопасности (например, PCI DSS, HIPAA, SOC 2…)

4# Сканирование IAC

IaC расшифровывается как Infrastructure-as-code, что относится к технологии и процессам, используемым для управления и предоставления инфраструктуры с помощью кода. Хотя IaC не имеет прямого отношения к контейнерам, обычно он поставляется с DevOps. IaC упрощает процессы DevOps, такие как экспертная оценка, контроль версий, автоматизация и доставка CI/CD.

IaC включает объявления ресурсов, входные и выходные переменные, конфигурации и параметры. IaC обычно основан на JSON, YAML или HCL, и один файл может содержать все ресурсы и конфигурации, необходимые для развертывания всей инфраструктуры, включая:

• вычислить,

• хранилище,

• сети,

• управление доступом к удостоверениям,

• безопасность и многое другое.

Помимо операционной эффективности, IaC можно использовать для автоматизации процессов безопасности и их интеграции с DevOps в рамках перехода к DevSecOps. Однако IaC — это двусторонний меч.

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

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

Эти инструменты могут отделить такие проблемы безопасности, как:

• образ Docker, инициированный для запуска от имени пользователя root,

• манифест Kubernetes, который запрашивает привилегированный доступ узла к файловой системе, или

• сценарий Ansible/Terraform, который настраивает корзину S3 с открытым доступом.

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

Заключительные слова

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

Эти две цели по-прежнему конкурируют за равное внимание в пространстве контейнеров. Хотя наличие контейнеров на картинке способствовало масштабируемости и гибкости, они также увеличивали общую сложность.

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

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

Спасибо за чтение. Да пребудет с вами информационная безопасность🖖.