© 1995-2021 Компания «Инфосистемы Джет»
Защита контейнеров и сред контейнерной оркестрации
Информационная безопасность

Функциональные ИБ-требования для защиты контейнеров. Как выбрать оптимальное решение? Перечень Enterprise и Open Source инструментов для защиты.

Информационная безопасность Тема номера

5000 слов о защите контейнеров

26.10.2021

Посетителей: 112

Просмотров: 105

Время просмотра: 3.2 мин.

 

Функциональные ИБ-требования для защиты контейнеров.

 

Как выбрать оптимальное решение?

 

Перечень Enterprise и Open Source инструментов для защиты.

 

Часть 0. Введение

 

Популярность контейнеров и сред контейнерной оркестрации обладает и «обратной стороной»: указанные технологии становятся объектом интереса для совершения вредоносных действий, что подтверждается данными отчетов различных компаний:

 

  • согласно отчету «State of Kubernetes Security Report», подготовленному компанией Red Hat, 94% опрошенных сталкивались с инцидентами ИБ в средах контейнерной оркестрации за прошедшие 12 месяцев;
  • в отчете «Cloud Native Threat Report: Attacks in the Wild on the Container Supply Chain and Infrastructure» от Aqua Security приводится сводная информация о росте атак на среды контейнерной оркестрации: от 2516 во втором полугодии 2019 г. до 17 521 во втором полугодии 2020-го. Аналитики Aqua изучали данные, полученные с собственных honeypots.

 

В качестве примеров реализованных нападений рассмотрим топ-4 реальных атак, подготовленных Nautilus Team Aqua Security за 2020 г.:

 

  • Attacker Building Malicious Images Directly on Your Host: эксплуатация некорректно настроенного Docker API для сборки и запуска вредоносного образа на хосте;
  • TeamTNT: использование червя для кражи учетных данных AWS; 
  • Kinsing Malware Attacks Targeting Container Environments: запуск контейнера с вредоносным ПО Kinsing, который запускает майнер криптовалюты и пытается распространиться по ИТ-инфраструктуре;
  • Fileless Malware Executing in Containers: атаки, связанные с запуском вредоносного ПО в памяти контейнера, с целью обойти разные механизмы защиты, например статический анализ образа.

 

Но есть и хорошая новость! Технологии безопасности сред контейнерной оркестрации тоже не стоят на месте. И именно об этом мы и поговорим в нашей статье. В качестве объекта защиты будем рассматривать классический Kubernetes (его иногда называют «ванильным» — Vanilla Kubernetes) и приложения, которые на нем запущены. Вначале поговорим о возможных векторах атак и о том, на что следует обращать внимание при моделировании угроз. Затем — о подходах и практиках для защиты кластера. В следующей части рассмотрим возможность/целесообразность использования решений Open Source и Enterprise: какие они бывают, какие задачи решают, что у них общего и в чем разница. Поговорим о возможности использования штатных ИБ-механизмов кластера. Завершим статью перечнем выводов, который подведет итог всему, что было написано ранее.

 

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

 

Часть 1. Моделирование угроз

 

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


Для того чтобы понять, что может пойти не так, посмотрим на Kubernetes как на объект защиты — информационную систему, которая состоит из нескольких компонентов:

 

  • kube-apiserver: «сердце» Kubernetes. Принимает запросы от различных элементов кластера на создание/обновление/удаление сущностей с последующей записью в etcd. Координирует работу кластера.
  • kube-scheduler: «планировщик» Kubernetes. Выбирает наиболее оптимальный вариант размещения требуемой сущности на node.
  • etcd: «память» Kubernetes. Key-value-хранилище, которое содержит полную информацию о конфигурации кластера.
  • kube-controller-manager: «гарантия» Kubernetes. Содержит различные controllers, основная задача которых — контролировать и поддерживать заданные пользователем параметры сущностей, следить за согласованностью элементов и системы в целом.
  • kubelet: «исполнитель» Kubernetes. Принимает задачи по созданию сущностей на node, затем отправляет информацию о проделанной работе обратно kube-apiserver.
  • kube-proxy: компонент, отвечающий за реализацию сетевого взаимодействия контейнера (в том числе между контейнером и node).
  • container runtime: компонент, отвечающий за запуск контейнеров. Получает и исполняет задачи от kubelet.

Графически взаимодействие компонентов Kubernetes представлено на рис. 1.

 

Рис. 1. Концептуальная архитектура Kubernetes

 

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

 

Практически все компоненты Kubernetes, включая запущенные на нем приложения, могут быть использованы злоумышленником для начала/развития атаки. В качестве примера рассмотрим схему1«Kubernetes Security», Liz Rice & Michael Hausenblas., представленную на рис. 2.

 

Рис. 2. Примеры векторов атак на кластер Kubernetes

 

На ней приведены примеры векторов атак на кластер Kubernetes:

 

  • [1] Доступ к серверу. Kubernetes можно установить как на физической, так и на виртуальной машине под управлением ОС семейства *nix. Доступ к серверу, наличие уязвимостей могут быть использованы злоумышленником для совершения атаки.
  • [2] Доступ к kubernetes API (kube-apiserver). Злоумышленник может изменить существующую конфигурацию или создать сущность с повышенными привилегиями / минимальной конфигурацией безопасности, для того чтобы развить атаку.
  • [3] Доступ к kubelet API. Используя kubelet (например, если доступна анонимная аутентификация), атакующий может запускать команды внутри контейнера для получения информации. Это даст ему возможность извлечь token, который впоследствии он сможет использовать для взаимодействия с kube-apiserver с целью манипуляции. Кроме того, kubelet обладает недекларированными возможностями, о которых тоже важно знать при моделировании угроз.
  • [4] Escape через уязвимость, volume mount. Существует несколько возможностей реализации побега из контейнера на уровень node. Одним из самых опасных последствий может стать то, что права в контейнере и права на node будут идентичными, а при отсутствии корректных ИБ-настроек эти права будут привилегированными, в частности — root.
  • [5] Доступ к etcd API. В etcd хранится полная конфигурация кластера. Получив к ней доступ, злоумышленник как минимум может начать собирать данные и планировать атаку.
  • [6] Изменение/перехват трафика, инъекции (control plane). Влияние на трафик элементов control-plane способно привести к изменениям сущностей и созданию новых, что может потребоваться злоумышленнику для совершения атаки.
  • [7] Изменение/перехват трафика, инъекции (application). Приложение, запущенное в контейнере, остается приложением: оно подвержено угрозам точно так же, как приложения, не упакованные в контейнеры (например, реализация RCE с последующим получением доступа к node).

 

Приведенные выше примеры не являются исчерпывающими. Более подробную информацию о техниках и тактиках, используемых злоумышленниками при реализации атак на Kubernetes, можно получить из материалов Microsoft, которая адаптировала структуру MITRE ATT&CK и создала матрицу атак Kubernetes («Threat Matrix for Kubernetes») с описанием 10 техник от Initial Access до Impact и 45 тактик, реализующих указанные техники (рис. 3).

 

Рис. 3. Threat Matrix for Kubernetes

 

Кроме того, можно обратиться непосредственно к материалам MITRE, выпустившей собственную матрицу («Containers Matrix») несколько позже, чем это сделала Microsoft. Также много полезной информации можно получить из отчетов по анализу угроз самого Kubernetes, реализуемых рабочей группой SIG-Security (Security Special Interest Group). Последний из них был выпущен в 2019 г., ведутся работы по подготовке нового отчета в 2021 г. 

 

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

 

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

 

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

 

Часть 2. Защита кластера, подход

 

В предыдущем разделе было продемонстрировано, что каждую сущность Kubernetes (включая запущенные на нем приложения) можно рассматривать как объект атаки или как средство для реализации атак. Поэтому при формировании стратегии защиты кластера можно выделить 2 ключевых блока:

 

  • контроль информационной безопасности кластера (компоненты Kubernetes и Nodes кластера);
  • контроль информационной безопасности запускаемых приложений (приложения, запущенные в виде контейнеров на кластере). 

 

Рассмотрим каждый блок более детально.

 

1. Контроль информационной безопасности кластера

 

Задача этапа — подготовить «безопасную» платформу для запуска приложений, которые, в свою очередь, подвержены угрозам. Кластер состоит из набора nodes и системных компонентов Kubernetes. Необходимо выстроить корректное сетевое взаимодействие между nodes, внедрить процесс управления уязвимостями, характерными для nodes, реализовать мониторинг инцидентов ИБ и т.д. Вообще говоря, задачи мало отличаются от задач «классической информационной безопасности ИТ-инфраструктуры».

 

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

 

  • ограничение «прямого» доступа на nodes кластера;
  • реализация защищенного сетевого взаимодействия между nodes кластера;
  • отключение анонимной аутентификации для компонентов (например, kubelet);
  • использование RBAC для корректного распределения возможностей пользователей и системных учетных записей в кластере;
  • шифрование данных в etcd;
  • включение и настройка audit policy, для того чтобы собирать информацию о происходящем на кластере для последующей аналитики;
  • настройка resource quotas на потребление ресурсов (CPU, RAM) запущенными pod;

 

Существует достаточно много рекомендаций по безопасной настройке кластеров Kubernetes (hardening guide), и нужно выбрать то, что лучше всего подходит для достижения поставленных целей. Есть даже hardening guide от Агентства национальной безопасности США. Большинство настроек выполняются с использованием встроенных возможностей Kubernetes с минимальным использованием дополнительных (наложенных) средств защиты. Примером использования дополнительных механизмов защиты при обеспечении безопасности кластера могут быть решения Service Mesh, которые в том числе позволяют реализовать mTLS и «расширенные» возможности по реализации межсетевого экранирования.

 

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

 

2. Контроль информационной безопасности запускаемых приложений

 

Информационную безопасность запускаемых приложений следует обеспечивать сразу на нескольких «уровнях абстракции»:

 

  • уровень Image: статический анализ образов на наличие несоответствий требованиям ИБ; 
  • уровень Container: все, что связано с запущенными контейнерами, — от запускаемых процессов до устанавливаемых сетевых соединений.

 

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

 

Рис. 4. Жизненный цикл контейнеров и потребности ИБ

 

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

 

Кроме того, такой подход служит своего рода страховкой. Допустим, на этапах «Сбор требований» и «Создание образа» работы по ИБ не проводились, но в компании реализованы механизмы контроля запускаемых образов. Тогда на этапе «Запуск контейнера» произойдет ошибка, вызванная несоответствием требованиям по ИБ. Альтернативная ситуация такова: механизмы контроля запускаемых образов не реализованы, однако присутствует контроль сетевых соединений, устанавливаемых контейнерами. В этом случае можно блокировать попытку установления соединения, например, с C’n’C-сервером, инициируемую вредоносным ПО, попавшим в образ контейнера, даже с учетом того, что это ПО не было своевременно идентифицировано на этапе «Создание образа».

 

Лучше не рисковать и реализовать меры по ИБ на разных этапах жизненного контроля, для того чтобы на этапе n+1 в случае чего можно было отследить/проконтролировать то, что было пропущено на этапе n. Объединив уровни абстракции и ожидания от ИБ на различных этапах жизненного цикла контейнера, получим таблицу, описывающую общие функциональные требования к технологиям защиты сред контейнерной оркестрации с точки зрения приложений (табл. 1).

Таблица 1. Возможный перечень функциональных требований для защиты контейнеров (зеленым цветом указана применимость требования к образу (Image) или контейнеру (Container))

Потребность ИБГруппа требованийТребованиеУровень
ImageContainer
1.
  • Соответствие рекомендациям ИБ по написанию образа
  • Минимально допустимое количество уязвимостей
  • Отсутствие вредоносного ПО в образе
  • Отсутствие hardcoded-секретов
 
Compliance scans
Наличие встроенных проверок для оценки степени реализации hardening  
2.Возможность создания собственных проверок  
3.Vulnerability scansСканирование на наличие уязвимостей и вредоносного ПО  
4.Постоянное обновление данных об уязвимостях и вредоносном ПО  
5.Sensitive data scansИдентификация секретов в образах контейнеров  
6.
  • Запуск контейнеров из образов:

 

- Из доверенных реестров

- Не являющихся привилегированными

- Не содержащих «избыточные» Linux Capabilities

- Не содержащих hostPathMount и иные недопустимые параметры конфигурации по ИБ

- …

Image Startup Checks

Блокировки запуска образа на основе анализа конфигурационного файла

  
7.

Контроль наличия подписи образов у образов контейнеров

  
8.
  • Контроль запускаемого ПО внутри контейнера
  • Контроль сетевых соединений (East-West, North-South)
  • Контроль использования файловых ресурсов
  • Контроль потребляемых контейнером ресурсов node, на которой он запущен
  • Возможность блокировки нежелательных действий в режиме реального времени
  • Идентификация событий ИБ и инцидентов ИБ

Process Control

Контроль запускаемых процессов (white/black listing)

 

  
9.Network ControlКонтроль сетевого трафика (East/West)  
10.Контроль сетевого трафика (North/South)  
11.

Идентификация сканирования портов

  
12.File System ControlКонтроль целостности файлов  
13.Контроль доступа в директории  
14.Behavioral ModelСоздание поведенческой модели/профиля  
15.Автоматическое применение модели/профиля  
16.Alerting and Blocking (Runtime)Оповещение о нарушении политик  
17.Блокирование согласно политикам  

 

Помимо функциональных требований, важно помнить о блоке интеграционных. Например:

 

  • интеграция с инфраструктурными сервисами (служба каталогов, электронная почта);
  • интеграция с CI/CD-решениями для анализа уязвимостей и compliance-несоответствий в образах в процессе сборки, а также для анализа конфигурации сущности, запускаемой на Kubernetes в момент deploy, на предмет соответствия требованиям ИБ;
  • интеграция с Registry для анализа уязвимостей и compliance-несоответствий в образах при их хранении;
  • интеграция с SIEM-системами для передачи данных о событиях ИБ, инцидентах ИБ;
  • интеграция с системами ИТ-мониторинга для оценки количества потребляемых ресурсов и нагрузки на кластер, создаваемой средствами защиты;
  • интеграция с системами Secret Management для инъекции секретов в контейнеры в качестве файлов и/или переменных окружения;
  • интеграция с системами Task/Issue Tracking для постановки задач по устранению дефектов, идентифицированных при сканировании образов контейнеров.

 

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

 

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

 

Как можно реализовать защиту? Какие способы возможны? Чтобы ответить на эти вопросы, обратимся к следующему разделу.

Часть 3. Средства защиты, разница между решениями Enterprise и Open Source

 

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

 

Рис. 5. Способы защиты приложений

Штатные механизмы Kubernetes


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

 

  • Network Policy. Позволяет контролировать входящий (Ingress) и исходящий (Egress) трафик, если смотреть со стороны контролируемой сущности. Поддержка функционала зависит от используемого Container Network Interface (CNI). Большинство решений (Cilium, Calico, Canal и т.д.) обладают необходимым функционалом, исключение составляет Flannel.
  • Role based access control, RBAC. Возможно создание Roles и RoleBinding, которые описывают возможности (verb) сущности и объект, к которому применяются указанные возможности. Например, можно создать ServiceAccount, обладающий ограниченными возможностями применительно к Pod или иной сущности Kubernetes.
  • Audit Policy. О ней мы уже упоминали в разделе, посвященном безопасности кластера. Audit Policy может быть использована для сбора событий о происходящем на кластере для последующего анализа. Например, можно идентифицировать попытки exec в pod.
  • Security Context. Указывается в конфигурации Pod/Deployment/ReplicaSet и т.д. При помощи Security Context можно, например, ограничить возможность использования Linux Capabilities, управлять возможностью запуска привилегированных контейнеров, настроить применение Seccomp профиля для контейнера и т.д.
  • Resource Quotas. Ограничение ресурсов (CPU, Memory), потребляемых контейнером, что может быть использовано для противодействия DoS-атакам

 

У штатного ИБ-функционала Kubernetes есть ограничения: он не позволяет контролировать run time — то есть все, что происходит внутри запущенного контейнера (например, запуск какого-то процесса, который не должен был быть запущен, попытку чтения/записи информации из файла и т.д.). Для идентификации подобных действий рекомендуется использовать наложенные средства.

 

Анализируя возможности Kubernetes, важно помнить, что проект продолжает развиваться, появляются новые функции, а некоторые, наоборот, переходят в статус «deprecated» (отзыв функционала). Показательный пример — PodSecurityPolicy (PSP): механизм получил статус deprecated в версии 1.21, а в версии 1.25 он будет устранен полностью. Однако в релизе 1.22 взамен был добавлен функционал PodSecurity Admission в статусе Aplha2Отключены по умолчанию, могут быть bugs, не рекомендуется к использованию в production., который должен выполнять схожий с PSP функционал, но при этом быть удобней в использовании.

 

Open Source

 

Инструментов Open Source для защиты кластера очень много. Поэтому рассмотрим решения, которые, согласно данным отчета «State of Kubernetes Security Report» от Red Hat, используются наиболее часто:

 

  • KubeLinter. Позволяет проводить анализ YAML-манифестов Kubernetes на соответствие лучшим практикам, в том числе по информационной безопасности.
  • Open Policy Agent. При помощи OPA можно создавать политики и применять их с использованием Admission Controller. Если упростить, то процесс выглядит следующим образом: мы написали политику, которая анализирует конфигурацию pod на предмет наличия «securityContext: privileged: true». Пытаемся запустить pod, обладающий указанной конфигурацией, после чего OPA анализирует запрос и отклоняет его из-за наличия недопустимой конфигурации. OPA — крайне мощный инструмент, который можно использовать для контроля запускаемых сущностей. Но есть нюанс: политики пишутся на специфичном языке (REGO), в котором предстоит разобраться.
  • Kube-bench. Позволяет анализировать кластер на предмет соответствия конфигурации рекомендациям лучших практик (как правило, CIS Benchmark).
  • Kube-hunter. Идентифицирует некорректные настройки в кластере.
  • Terrascan. Выполняет статический анализ для идентификации недостатков в конфигурации при использовании подхода Infrastructure as Code.
  • Falco. Это инструмент создания политик для идентификации инцидентов в запущенных контейнерах. Например, он позволяет идентифицировать запуск процессов внутри контейнера. Перед использованием необходимо подготовить Falco Rules — набор правил, используемых для идентификации событий ИБ, или воспользоваться готовыми наборами.
  • Clair. Сканер уязвимостей в образах контейнеров.

 

Рассмотрим покрытие функциональных требований, указанных в табл. 1 (для упрощения сократим таблицу до уровня «Группа требований»), с использованием решений Open Source (табл. 2).

Таблица 2. Покрытие функциональных требований при помощи решений Open Source

 

 № Группа требованийImageContainer
1.Compliance scans
  • KubeLinter
  • Kube-bench
  • Terrascan
 
2.

Vulnerability Scans

  • Kube-hunter
  • Clair
 
3.Sensitive data scans
 
  • KubeLinter
 
4.Image Startup Checks
  • OPA
 
5.Process Control
 

 
  • Falco (Обнаружение)
6.Network Control
 

 
  • Falco (Обнаружение)
7.File System Control
 

 
  • Falco (Обнаружение)
8.Behavioral Model 
  • Отсутствует
9.Alerting and Blocking (Runtime) 
  • Результаты работы решений

Краткий обзор решений и информация о покрытии функциональных требований с их помощью приводят к следующим выводам:

 

  • большинство продуктов Open Source обладают одной общей чертой: они решают локальную и вполне конкретную задачу;
  • выполнить большинство требований при помощи Open Source можно, однако для этого потребуется сразу несколько продуктов, которые вместе образуют необходимый «функциональный комбайн».

 

Enterprise

 

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

Основные пользователи средства защиты:

 

  • Разработка, ИТ- и ИБ-специалисты. Решения подобного рода называют еще «Observability». Их основная задача — предоставить максимум информации о том, что происходит (или происходило) на кластере в определенный момент времени. Такие данные могут быть использованы для нужд безопасности, поиска ошибок в конфигурациях deployment, для оптимизации производительности работы приложения и т.д. Примеры: Luntry, Sysdig.
  • ИБ-специалисты. Решения, в большей степени сфокусированные на функционале по информационной безопасности, предоставляют множество возможностей по контролю запуска контейнеров, защите run time (в том числе в автоматическом режиме). Примеры: Aqua Enterprise, Prisma Cloud Compute Edition, Red Hat Advanced Security for Kubernetes (ex-StackRox).

 

Реализация защитных механизмов:

 

  • Kubernetes-native. Решения, которые не используют интрузивных подходов и, грубо говоря, предоставляют удобный интерфейс взаимодействия с существующими ИБ-возможностями Kubernetes, помогают автоматизировать некоторые задачи (например, автоматическую генерацию Network Policy для приложения). Примеры: Luntry, Red Hat Advanced Security for Kubernetes (ex-StackRox).
  • Иные. Решения, которые расширяют штатные возможности Kubernetes за счет собственных механизмов (например, позволяют контролировать запускаемые процессы в контейнерах). Примеры: Aqua Enterprise, Prisma Cloud Compute Edition, Sysdig.

 

Как может быть установлено средство защиты:

 

  • Гибридная установка / локальная установка. Есть решения, модули защиты которых можно установить в периметре компании, а остальные компоненты (консоль управления, база данных и т.д.) будут размещены в облаке. Однако существует и альтернативный вариант — полностью локальная установка в периметре компании. Примеры: Aqua Enterprise, Prisma Cloud Compute Edition, Sysdig.
  • Локальная установка. Решения, которые могут быть установлены только локально в периметре компании. Примеры: Luntry, Red Hat Advanced Security for Kubernetes (ex-StackRox).

Для того чтобы полноценно описать возможности решений (включая архитектурные особенности, интеграционные возможности, формат предоставления информации и т.д.), потребовалась бы отдельная статья. Тем более что, помимо общего функционала, у каждого из решений есть собственные особенности, которые делают его уникальным (например, vShield от Aqua Enterprise, WaaS от Prisma Cloud Compute Edition, «Машина времени» от Luntry и т.д.). Поэтому для общего понимания их возможностей рассмотрим функционал, имеющийся практически у всех представленных выше решений.

 

  • Image Security:

 

- сканирование образов и nodes на наличие уязвимостей и compliance-несоответствий;

- идентификация вредоносного ПО в образах контейнеров;

- формирование политик, на основании которых принимается решение о запуске контейнеров (альтернатива/дополнение — использование Admission Controller для контроля запускаемых контейнеров);

- идентификация конфиденциальной информации (паролей, ssh-ключей).

 

  • Container Security:

 

- контроль запуска процессов и системных вызовов внутри контейнера;

- контроль файловой системы: возможность указания объектов (файлов, папок), доступ к которым ограничивается;

- контроль сетевого взаимодействия за счет создания правил контроля исходящего и/или входящего трафика;

- профилирование контейнеров с последующим использованием созданной модели для реализации поведенческой аналитики и идентификации аномалий.

 

  • Monitoring and Audit:

 

- сбор информации о событиях, создаваемых в среде контейнеризации (как для контейнеров, так и для nodes);

- возможность интеграции с системами мониторинга элементов ИТ-инфраструктуры;

- возможность интеграции с системами мониторинга и корреляции событий ИБ.

 

По аналогии с решениями Open Source, взглянем на покрытие функциональных требований, указанных в табл. 1 (для упрощения сократим таблицу до уровня «Группа требований») с использованием Enterprise-решений (табл. 3):

Таблица 3. Покрытие функциональных требований при помощи enterprise-решений

 №Группа требованийImage Container
1.Compliance scans
  • Возможно
 
2.Vulnerability Scans
  • Возможно
 
3.Sensitive data scans
  • Возможно
 
4.Image Startup Checks
  • Возможно в том числе с использование Admission Controller
 
5.Process Control
 
  • Возможно (обнаружение, предотвращение)
6.Network Control
 
  • Возможно (обнаружение, предотвращение)
7.
File System Control
 
  • Возможно (обнаружение, предотвращение)
8.
Behavioral Model
 
  • Возможно 
9.
Alerting and Blocking (Runtime)
 
  • Возможно 

 

Представленные краткий обзор решений и информация о покрытии функциональных требований позволяют прийти к следующим выводам:

 

  • Большинство Enterprise-решений дают возможность реализовать все рассматриваемые функциональные требования. При этом можно совместить Enterprise-решения с решениями Open Source.
  • Enterprise-решения выполняют те же задачи, что и n отдельно взятых решений Open Source, однако имеют отличия: например, предоставляют возможность создать модели/профили для реализации поведенческой аналитики и идентификации аномалий, а также возможность предотвращать действия, противоречащие политикам ИБ в run time.

Что выбрать?

 

Перед тем как определиться с общим подходом к защите кластеров среды контейнерной оркестрации, рассмотрим одну популярную точку зрения: зачем нужны Enterprise-решения, если есть Open Source и можно сделать «все то же самое», но бесплатно? Ответ на этот вопрос достаточно простой — «количество»:

 

  • количество финансовых средств (размер бюджета), которые можно вложить в защиту сред контейнерной оркестрации;
  • количество решений, которые надо будет поддерживать (как было показано выше, решения Open Source, как правило, выполняют локальную задачу), что определяет количество специалистов, которые будут этим заниматься;
  • количество времени, которое надо будет потратить на доработку/интеграцию Open Source в ИТ- и ИБ-окружение компании (не всегда удобно ставить задачи json-файлами, и, скорее всего, потребуется консолидированный dashboard, где информация будет представлена в удобном для человека формате);
  • количество кластеров среды контейнерной оркестрации и количество команд, которые их используют, что в том числе может определять требования к масштабируемости, отказоустойчивости и т.д.

 

Ответы на эти вопросы помогут определить потребность и целесообразность использования решений Open Source и/или Enterprise. Например, для небольшой команды, поддерживающей один кластер и несколько приложений, использование Open Source целесообразно и уместно:

 

  • не надо расширять зону покрытия (устанавливать решения на новые кластеры, делать onboarding новых команд и т.д.);
  • не нужно адаптировать подход с учетом нужд множества команд;
  • не требуется генерировать многомерную отчетность;
  • отсутствует потребность в создании большого количества dashboard для руководства и т.д.

 

В таком сценарии потребуются интеграция и доработка Open Source, но такой работы будет немного и Open Source можно счесть «условно-бесплатным» («условно» — потому что время на доработку и адаптацию решений все же необходимо и оно не бесплатное).

 

И совсем другая история: много команд, несколько кластеров, десятки приложений. В таких масштабах количество доработки Open Source будет уже значительным, что превратит его из «условно-бесплатного» в «заказную доработку» за счет ресурсов имеющихся специалистов. Аналогичная ситуация получается и с поддержкой «уже доработанного» Open Source. В этом сценарии использование Enterprise-решений может быть целесообразным и оправданным, ведь они изначально создавались с учетом потребностей крупных организаций. Именно такой подход мы наблюдаем, например, при реализации проектов в крупнейших системно значимых банках. В этих случаях важно обеспечить работоспособность на больших масштабах (как с точки зрения размеров кластеров, так и с точки зрения команд разработки) и в условиях распределения ответственности за ИБ- и ИТ-функции, а также сохранить максимальную централизацию, что позволит упростить управление системой.

 

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

 

  • Штатные механизмы Kubernetes. Например, для разграничения доступа при помощи RBAC или обогащения систем мониторинга данными за счет Audit Policy, настройки ограничений на потребляемые ресурсы контейнерами
  • Использование решений Open Source. Для решения локальных задач, которые быстрее/удобнее/проще решить при помощи Open Source. Например, подпись образов контейнеров, создание OPA-политик для принятия решения о запуске контейнеров на основе анализа их конфигурации
  • Использование Enterprise-решений. В первую очередь для контроля run time, для контроля безопасности образов во время сборки (CI-процессы), во время хранения, а также для дополнительных проверок перед запуском контейнера (с использованием Admission Controller).

Часть 4. Выводы

 

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

 

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

 

Защита приложений — немного более сложная задача, что обусловлено увеличением количества абстракций, с которыми требуется работать: разные подходы для Image и для Container. Для того чтобы понять, в чем разница, можно воспользоваться жизненным циклом контейнера (от момента формирования требований и разработки образа до его запуска). Это позволит разобраться с тем, какие потребности есть у ИБ и как их можно реализовать.

 

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

 

  • использование штатных механизмов Kubernetes;
  • использование решений Open Source;
  • использование Enterprise-решений.

 

Универсального ответа на вопрос «А что лучше?» нет. Все зависит от конкретной ситуации. На наш взгляд, если среды контейнерной оркестрации в компании используются повсеместно, оптимальным вариантом будет совмещение всех трех сценариев: штатные механизмы — для корректного управления конфигурациями нагрузок (RBAC, Resource Quotas и т.д.); Open Source — для решения локальных задач (подпись образов, проверка конфигураций контейнеров перед запуском); и Enterprise-решения — для контроля runtime, анализа образов контейнеров в момент сборки и хранения и т.д.

 

Так получится реализовать защиту кластера, которая не является избыточной и соответствует потребностям компании.

Часть 5. Ссылки на используемые материалы

 

Ниже приведен перечень ссылок на материалы, которые упоминались в разделах статьи.

 

Введение

 

 

Моделирование угроз

 

 

Средства защиты, разница между решениями Enterprise и Open Source

 

Уведомления об обновлении тем – в вашей почте

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

В 1992 году Указом Президента Российской Федерации вместо существовавшей около 20 лет Государственной технической комиссии СССР была образована Государственная техническая комиссия при Президенте Российской Федерации (Гостехкомиссия России) — ...

Информационная безопасность - обзор основных положений. Часть 2

Руководящие документы по защите от несанкционированного доступа Гостехкомиссии при Президенте РФ  В 1992 году Гостехкомиссия при Президенте РФ опубликовала пять Руководящих документов, посвященных проблеме защиты от несанкционированного доступа ...

Интервью Алексея Комкова, Технического директора компании "Лаборатория Касперского"

Интервью Комкова Алексея, технического директора компании "Лаборатория Касперского" информационному бюллетеню "Jet ...

О контентной фильтрации (продолжение темы Jetinfo №8 (2006))

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

Программно-определяемые грузоперевозки

Еще недавно слово «аппаратный» было синонимом надежности и производительности. Каждая задача – на своем сервере. Все сетевые устройства непременно аппаратные, в массивных корпусах и с большим количеством лампочек.

Как реагировать на нарушения информационной безопасности

Цель настоящего документа – сформулировать ожидания Интернет-сообщества по отношению к группам реагирования на нарушения информационной безопасности (Computer Security Incident Response Teams, CSIRTs). Нет возможности определить набор ...

Обеспечение информационной безопасности в вычислительных комплексах на базе мэйнфреймов

Лет 30-40 назад информационные системы строились только на базе мэйнфреймов. Соответственно, архитектура информационной системы, как правило, была централизованной. Затем наступила эра малых машин, распределенных архитектур обработки ...

Доверенные центры как звено системы обеспечения безопасности корпоративных информационных ресурсов

Гостехкомиссия России: точка зрения на техническую защиту информации   Интервью советника председателя Гостехкомиссии России Арнольда Петровича Каландина бюллетеню Jet Info   Расскажите, пожалуйста, об истории и нынешнем статусе ...

Выбор широкополосных измерительных антенн в целях контроля эффективности защиты информации

В настоящее время на рынке представлено значительное количество измерительных антенн отечественных и зарубежных фирм-производителей

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня