`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Обновления матрицы угроз Kubernetes 2021 года: что нужно знать

+22
голоса

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

Предлагаем вашему вниманию публикацию, подготовленную специалистами компании Integrity Vision, которая давно занимается решениями для защиты информации, приложений и бизнес-систем на всех уровнях.

Боковое движение — конечная точка контроллера доступа

Задача

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

Начиная с версии 3, Helm не использует серверный компонент Tiller, а использует учетные данные пользователя для отправки объектов Kubernetes на сервер API.

Лучшая практика для смягчения последствий

Основная область для настройки элементов управления безопасностью: Other — Helm

Организации могут смягчить эту угрозу, обеспечив обновление до последней версии Helm для развертывания приложений Kubernetes.

Как RHACS помогает

RHACS использует три метода развертывания.

  • Оператор RHACS

  • Helm 3

  • Файлы YAML

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

Рассмотрим новые методы для матрицы угроз.

Первоначальный доступ — открытые чувствительные интерфейсы

Задача

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

Лучшая практика для смягчения последствий

Основная область для настройки средств контроля безопасности: Kubernetes.

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

Как RHACS помогает

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

 что нужно знать

Выполнение — sidecar инъекция

Задача

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

Sidecar-контейнеры — это вторичные контейнеры в pod, которые поддерживают основной контейнер в выполнении его рабочих задач. Например, service mesh используют архитектуру sidecar и выступают в качестве прокси для основного контейнера. Поскольку sidecar контейнеры могут использовать существующие возможности основного контейнера, злоумышленники будут использовать эту конструкцию и скрывать вредоносную деятельность внутри sidecar контейнера.

Лучшая практика для смягчения последствий

Основные области для настройки средств контроля безопасности: Kubernetes and Other — Tooling

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

Значительная часть защиты от программных инъекций с помощью sidecar контейнеров также может быть обеспечена в процессе сканирования контейнеров и обеспечения использования правильных образов контейнеров во время выполнения.

Как RHACS помогает

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

RHACS организует ваши deploymentы и оценивает их риск комплексно. Одни и те же угрозы, которые злоумышленник может использовать в одном контейнере, будут оцениваться для всех контейнеров. Оба контейнера в pod будут контролироваться при группировке угроз, и RHACS предупреждает о нарушениях политики и аномальной активности процессов.

 что нужно знать

Стойкость — вредоносный admission controller

Задача

Kubernetes имеет множество типов admission controllerов; однако один контроллер может изменять объекты Kubernetes после разрешения пользователем. Мутирующие admission controllerы, как следует из названия, могут изменять объект Kubernetes. Используя MutatingAdmissionWebhook, злоумышленники могут изменить ранее определенные объекты Kubernetes, чтобы получить доступ в кластере или изменить разрешения контейнеров. Эти изменения могут произойти без ведома пользователя, если он не следит активно за нагрузкой и настройками своих контейнеров.

Лучшая практика для смягчения последствий

Основная область для настройки средств контроля безопасности: Kubernetes.

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

Как RHACS помогает

RHACS содержит встроенные политики, такие как монтирование конфиденциальных директорий, secretов и любых изменений в ваших рабочих нагрузках, которые могут быть использованы. Вы можете настраивать и создавать политики в соответствии с вашими рабочими нагрузками и кластерами, устанавливая известное поведение рабочих нагрузок. Если MutatingAdmissionWebhook злонамеренно изменяет ваши рабочие нагрузки, нарушая одну из этих политик, будет инициировано нарушение политики, которое блокирует изменение с помощью admission controllerа RHACS (в режиме enforcement).

RHACS предоставляет вам видимость управления RBAC кластера, позволяя вам минимизировать любые попытки создания вредоносных объектов, таких как MutatingAdmissionWebhook.

 что нужно знать

Доступ к учетным данным — доступ к управлению идентификацией учетных данных

Задача

Различные облачные провайдеры имеют управляемые идентификаторы, используемые для выделения ресурсов, таких как кластеры Kubernetes или виртуальные машины. Служба метаданных экземпляров (IMDS) предоставляет информацию о текущих запущенных экземплярах виртуальных машин. Эта информация доступна внутри виртуальной машины, и если злоумышленник получит доступ внутрь контейнера, он сможет воспользоваться доступом и получить токен идентификации. Затем злоумышленник может использовать эти маркеры для получения более широкого доступа к облачным ресурсам организации.

Лучшая практика для снижения рисков

Основные области для настройки средств контроля безопасности: Kubernetes + облачный провайдер

IMDS — это REST API, доступный по-известному, немаршрутизируемому IP-адресу. Поскольку информация доступна только изнутри виртуальной машины, ваши контейнеры не должны иметь доступ к этой информации. Во-первых, предотвратите доступ к контейнеру, используя принципы наименьших привилегий, контекстов безопасности и контейнеров без прав root. Затем настройте сетевые политики для блокирования внутреннего адреса REST API и убедитесь, что ваши контейнеры не могут монтировать какие-либо персистентные данные с хоста.

Как помогает RHACS

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

 что нужно знать

Боковое движение — отравление CoreDNS

Задача

Kubernetes использует сервер системы доменных имен (DNS) под названием CoreDNS. CoreDNS является основной службой DNS, поставляемой с Kubernetes, и может быть настроен с помощью файла под названием core file. CoreDNS использует configmap для настройки и распространения конфигурации на любые другие podы CoreDNS. Такая архитектура обеспечивает вектор атаки, когда злоумышленники пытаются изменить core file и изменить поведение DNS кластера.

Лучшая практика для смягчения последствий

Основные области для настройки средств контроля безопасности: Kubernetes + облачный провайдер

Любой тип доступа к службе DNS кластера представляет собой серьезную угрозу. Обычно CoreDNS располагается в namespace kube-system и в configmap, которая может быть использована для его настройки. Это означает, что злоумышленнику потребуется доступ kube-admin к вашему кластеру или привилегированный доступ через уязвимый контейнер. В этом случае пользователям необходимо использовать принцип наименьших привилегий. Следует применять функции контроля RBAC и контекста безопасности.

Configmap также имеют свойство неизменяемости, которое делает невозможным изменение configmap без ее удаления. Хотя это представляет собой проблему для обновлений, это означает, что злоумышленники не смогут внести какие-либо изменения в configmap без того, чтобы вы об этом сразу же узнали.

Как RHACS помогает

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

В качестве дополнительной меры RHACS будет отслеживать оповещение о любом аномальном поведении, которое вы зададите, включая ресурсы kube-system. Это не только отличные средства контроля, позволяющие злоумышленникам не получить доступ к вашему кластеру, но и любые изменения или модификации сетевых возможностей также будут немедленно обнаружены и оповещены.

 что нужно знать

Боковое движение — ARP Poisoning и IP Spoofing

Задача

Модульный подход Kubernetes к функциональности привел к появлению множества сетевых интерфейсов контейнеров (Container Network Interfaces, CNI), претендующих на предоставление сетевой функциональности вашим контейнерам. Хотя по умолчанию часто используется CNI Kubenet, большинство облачных провайдеров имеют свои собственные рекомендованные CNI, и вы также можете установить предпочитаемый CNI в своих кластерах.

Для объединения podов в сеть на каждом узле создается мост (cbr0), к которому различные podы подключаются с помощью veth-пар. Поскольку podы подключены через мост, в кластере возможно выполнение ARP poisoning. Для выполнения таких действий злоумышленнику все равно потребуются повышенные привилегии; с такими привилегиями возможны некоторые атаки на сетевом уровне, например, подмена DNS.

Лучшая практика для смягчения последствий

Основные области для настройки средств контроля безопасности: Kubernetes + облачный провайдер

Убедитесь, что вы используете предпочтительный CNI вашего облачного провайдера — это простой способ ограничить уязвимости, которые могут возникнуть из-за неправильной конфигурации. ARP poisoning и IP spoofing происходят с привилегированным доступом на хосте на уровне контейнера. Убедитесь, что контексты безопасности настроены должным образом, специфические возможности Linux отброшены, а контейнеры не содержат избыточного сетевого инструментария.

Как RHACS помогает

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

 что нужно знать

Сбор — образы из приватного реестра

Microsoft добавила технику сбора в своем новом обновлении, используя первоначальную технику сбора, разработанную MITRE. Техника состоит из тактик, используемых злоумышленниками для сбора данных с кластера или через кластер.

Задача

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

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

Лучшая практика для смягчения последствий

Основные области для настройки средств контроля безопасности: Kubernetes и другие — Инструментарий

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

Как помогает RHACS

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

Интеграция сканера RHACS в ваш конвейер CI обеспечивает корреляционный рабочий процесс между этапами сборки-развертывания и выполнения каждого контейнера. Такая интеграция снижает вероятность того, что злоумышленник сможет внедрить код в ваши контейнеры без предупреждения.

Напомним, что Red Hat является партнером Integrity Vision.

Почему RHACS — это важный компонент безопасности

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

«Мы имеем общее видение в вопросе информационной безопасности с Red Hat, которая является нашим партнером. И уверены, что комплексный подход при выборе средств безопасности обеспечивает целостную защиту информации и снижает риски для владельцев бизнеса», отметил Богдан Шавло, пре-сейл інженер IT-компанії Integrity Vision.

Про AI-рішення Microsoft та AWS мовою бізнесу від практиків Сrayon — 8 і 9 грудня

+22
голоса

Напечатать Отправить другу

Читайте также

 
 

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT