Защита сред контейнеризации от А до Я

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

Чем выгодна контейнеризация в разработке и эксплуатации

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

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

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

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

Контейнеры прекрасно вписались в современную методологию непрерывной интеграции и развертывания (CI/CD, continuous integration, continuous delivery), помогающую выпускать обновления приложений быстрее и с меньшим числом ошибок. Этот подход предусматривает короткий цикл разработки, параллельную работу команд над одним кодом, автоматизацию рутинных действий. Применение контейнеризации в конвейере CI/CD тоже повышает эффективность этого конвейера: система CI/CD использует образы контейнеров в качестве шаблонов и доставляет сборку в виде готового к развертыванию образа. Принципиальным моментом является то, что обновление поставляется в виде нового образа, а не разворачивается внутри существующего и эксплуатируемого контейнера. В результате ускоряются подготовка и отладка релиза, снижаются требования к инфраструктуре разработчика и заказчика, повышается стабильность работы и облегчается масштабирование приложения.

Если грамотно внедрить требования контейнерной безопасности в процесс разработки и сборки, то это существенно продвинет организацию на пути к полноценной реализации методологии DevSecOps.

Основные угрозы в контейнерной инфраструктуре

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

Всем перечисленным уже активно пользуются злоумышленники. Например, в публичном репозитории Docker Hub были обнаружены 1650 образов контейнеров, содержащих вредоносное ПО. В другом подобном случае вредоносные образы оставались незамеченными около года. Известны вредоносные кампании, использующие Docker API, чтобы создавать зловредные контейнеры на атакованных системах, отключать системы мониторинга и заниматься майнингом. В другой атаке мишенью стали кластеры Kubernetes с неверно настроенной PostgresSQL. Другая часто встречающаяся проблема — в репозиториях могут подолгу сохраняться необновленные образы контейнеров, содержащие известные уязвимости наподобие Log4shell. Также разработчики регулярно забывают в контейнерах API-ключи и другие секреты.

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

Контейнеры и защита традиционными средствами безопасности

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

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

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

А как же защита штатными средствами?

Все ключевые поставщики сред контейнеризации активно работают над повышением безопасности своих продуктов. С помощью штатных средств Kubernetes, например, можно настраивать квоты ресурсов, политику логирования, внедрять RBAC (role based access control), реализуя принцип наименьших привилегий. Несмотря на это, есть целые классы задач ИБ, которые не могут быть решены штатными инструментами, это, например, контроль процессов внутри запущенного контейнера, анализ на уязвимости, контроль соответствия ИБ-политикам и лучшим практикам и многое другое.

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

Как защита контейнеров становится частью DevSecOps

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

Фаза исследования — защита операций с VCS и реестром. На ранних этапах цикла разработки создатели ПО выбирают компоненты, в том числе контейнеризованные, которые будут применяться в приложении. Система безопасности должна проверять образы из реестра на актуальность, анализировать конфигурационные файлы (IaC — в частности, Dockerfile) на наличие ошибок, небезопасных настроек. Базовые образы, которые стали использоваться в разработке, должны быть проверены на уязвимости, ВПО, наличие секретов и тому подобное. Благодаря этому разработчики значительно снижают свои риски, связанные с компрометацией цепочки поставок.

Фаза создания и тестирования — защита операций Continuous Integration. Здесь необходимо убедиться, что в образ не попали секреты, уязвимые версии библиотек, ВПО, что все поддающиеся анализу ИБ-аспекты соответствуют уровню требований регуляторов и самой организации. Сборка приложения не может успешно завершиться, если часть политик нарушена. Это делается при помощи интеграции системы контейнерной безопасности с платформой CI/CD, будь то Jenkins, Gitlab или CircleCI. Наряду со статическим и динамическим тестированиями приложения на безопасность (appsec), эта мера является ключевым моментом, отличающим DevSecOps от других подходов к разработке.

Фаза доставки и развертывания — защита на уровне Continuous Delivery. Образы, передаваемые в эксплуатацию, должны быть проверены на целостность, а также полностью соответствовать принятым политикам. Если ситуация требует сделать исключение (например, опубликована уязвимость, но еще нет патча), то оно всегда должно быть документированным и ограниченным во времени.

Фаза выполнения — защита оркестратора и самих запущенных контейнеров. Контроль запуска и работы контейнеров. На этой фазе минимизируются риски, связанные с уязвимостями среды выполнения или ее неверной настройкой. Что еще важнее, только здесь можно выявить различные аномалии в работе приложения, такие как избыточно большая вычислительная нагрузка или неожиданные коммуникации с другими контейнерами и сетью в целом. На этом этапе также отслеживаются безопасные настройки самого оркестратора и доступа к нему. Для системы контейнерной безопасности тут критичны нативная работа с оркестратором Kubernetes или Openshift. При этом нельзя оставлять без защиты и саму ОС на хосте.

Для того чтобы работать на этих этапах, сама система контейнерной безопасности должна быть многокомпонентной. На иллюстрации изображены основные части системы Kaspersky Container Security и их взаимосвязь с платформой контейнеризации и платформой CI/CD.

Какие меры защиты принимать для каждого компонента контейнерных сред?

Рассмотрим более детальный список мер защиты, которые нужно применить к каждому компоненту системы контейнеризации, чтобы назвать безопасность комплексной.

Центральным элементом системы защиты является детальная проверка образов. Система безопасности должна интегрироваться с ключевыми реестрами (DockerHub, GitLab Registry, JFrog Artifactory и прочими), как публичными, так и корпоративными, и регулярно сканировать используемые образы в соответствии с политиками организации. Каждая проверка из списка сама по себе важна, но профиль риска и специфика приложений в каждой организации свои, поэтому можно, например, допустить эксплуатацию образов с уязвимостями низкой критичности. Также, в зависимости от принятых политик безопасности, ключевыми могут быть, например, рекомендации CIS Kubernetes или различные базы уязвимостей.

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

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

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

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

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

Работу ИБ-специалистов упростят интеграция с SIEM-системой и уже используемыми каналами оповещений о найденных проблемах, возможность регулярного автоматического сканирования всех образов по обновляемой базе уязвимостей (NVD или БДУ), функциональность для временного принятия ИБ-рисков, а также детальное логирование административных событий в системе защиты сред контейнеризации.

Особые требования российских заказчиков

Отечественные IT-компании активно внедряют контейнерные решения уже много лет, и потребность в их защите только растет. Российские регуляторы накладывают достаточно современные и жесткие требования по информационной безопасности, в том числе по оперативному устранению известных уязвимостей. В связи с этим решение контейнерной безопасности должно отслеживать уязвимости не только по таким известным западным источникам, как NVD, но и в БДУ, поддерживаемой ФСТЭК. При этом за последний год резко вырос интерес к решениям open source, а также отечественным разработкам, входящим в Реестр отечественного ПО. Система контейнерной безопасности должна поддерживать базовые образы, основанные на отечественных ОС. Kaspersky Container Security удовлетворяет этим требованиям, уже сегодня поддерживая образы на базе Astra Linux и РЕД ОС.

Как реализована защита в Kaspersky Container Security

Наше решение для контейнерной безопасности изначально создавалось для всесторонней защиты контейнерной инфраструктуры, поэтому его компоненты защищают весь жизненный цикл, от разработки контейнеризованного приложения до его повседневной эксплуатации. Выделенный сканер работает с образами контейнеров и обеспечивает статическую защиту, а агент KCS, работающий как отдельный контейнер под управлением оркестратора, обеспечивает защиту узлов в среде выполнения (рантайме) и среды оркестрации в целом. При этом центральный компонент Kaspersky Container Security обеспечивает интеграцию этих частей и дает интерфейс управления.

Платформа обладает высокой производительностью и способна эффективно защищать кластеры K8s с сотнями узлов (нодов).

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