Безопасность изолированной среды. Защита сред контейнеризации от А до Я

Безопасность изолированной среды. Защита сред контейнеризации от А до Я

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

ВЫГОДЫ КОНТЕЙНЕРИЗАЦИИ

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

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

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

УГРОЗЫ В КОНТЕЙНЕРНОЙ ИНФРАСТРУКТУРЕ

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

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

Систематизируем возможные угрозы в единую таблицу 1.

Таблица 1. Схема угроз элементам системы контейнеризации

 
ЗАЩИТА ТРАДИЦИОННЫМИ СРЕДСТВАМИ

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

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

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

ЗАЩИТА ШТАТНЫМИ СРЕДСТВАМИ

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

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

ЗАЩИТА КОНТЕЙНЕРОВ СТАНОВИТСЯ ЧАСТЬЮ DEVSECOPS

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

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

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

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

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

ЗАЩИТА ДЛЯ КАЖДОГО КОМПОНЕНТА

Детальный список мер защиты выглядит так (таблица 2):

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

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

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

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

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

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

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

ОСОБЫЕ ТРЕБОВАНИЯ РОССИЙСКИХ ЗАКАЗЧИКОВ

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