Контейнеры — наименее безопасное окружение. Если не считать все остальные

Контейнеры — наименее безопасное окружение. Если не считать все остальные

Большинство статей про контейнерную безопасность начинается с постулатов о повсеместном применении контейнеров для построения инфраструктуры компаний (по моей оценке, их распространённость в России в среднем достигает около 70%); в них описываются основные методики оценки векторов атак (по матрице MITRE ATT&CK или стандарту NIST 800-190) и минимально необходимый набор технологий защиты.

Я как человек, который уже шесть лет работает с контейнерами, уверен, что всё это вы уже знаете, а вот каких ошибок можно избежать в работе с контейнерами разработчикам, blue team, вендорам — об этом расскажу с точки зрения разных ролей.

КОНТЕЙНЕРЫ И ЗЛОУМЫШЛЕННИКИ

По данным исследования Red Hat, 94% ИT-специалистов сталкивались хотя бы с одним инцидентом безопасности, связанным с контейнерами. Половина DevOps-инженеров и специалистов по ИБ даже откладывали развёртывание приложений из-за проблем с безопасностью.

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

Представим типичную схему действий хакера над инфраструктурой контейнеризации с точки зрения классического cyber kill chain:

«Наиболее передовая часть инфраструктуры компании, скорее всего, уже переведена или изначально тестировалась для имплементации на контейнерах → специалисты по ИБ вряд ли успели позаботиться об их защите → изначально целиться буду в них» (рис. 1).

Рисунок 1. Этапы cyber kill chain

РАЗВЕДКА И ВООРУЖЕНИЕ

Атакующий всегда ищет способы проникнуть в организацию, чтобы перейти к следующим шагам. Разведку, первоначальный этап доступа к контейнерам, можно выполнить путём сканирования любого общедоступного приложения, созданного разработчиками компании и запущенного на её мощностях. В качестве демонстрационного примера можно выбрать типичное веб-приложение с формами, комментариями, слабой защитой от внедрения SQL-кода или реализации XSS — межсайтового выполнения сценариев. Если же мы хотим получить пример, специфичный для контейнерной среды, то включённый SSH в одном контейнере кластера вполне подойдёт. Злоумышленнику совсем не обязательно иметь прямой доступ к управляющим элементам среды контейнеризации, чтобы проникнуть в инфраструктуру: многие атаки начинаются именно с классических сценариев эксплуатации уязвимостей в ПО. 

ДОСТАВКА НАГРУЗКИ

Доставка инструментов и вредоносного кода в контексте использования контейнеров ещё острее поднимает вопрос безопасности цепочек поставок. Помимо классических способов с использованием туннелей, активно развиваются атаки с компрометацией публичных репозиториев (например, вредоносных образов docker hub, пакетов PyPi). Отсутствие поддержки таких подходов, как принцип zero trust, на деле может привести к тому, что отделы эксплуатации (DevOps) компании будут использовать непроверенный образ из публичных репозиториев, который изначально был подготовлен злоумышленником для будущей разведки, что может привести к рискам утечки конфиденциальной информации и доступу к инфраструктуре по сторонним каналам (рис. 2). 

Рисунок 2. Интерфейс PT Container Security при работе с уязвимостями образов

ЭКСПЛУАТАЦИЯ И ИСПОЛНЕНИЕ КОДА

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

Однако усложняется не только инфраструктура. Контейнеризация позволяет делать приложения модульными и выносить часть функций в отдельные сервисы (контейнеры). Как правило, такие сервисы служат для повышения доступности и конфиденциальности данных (например, реализация подхода сервисных сетей — Service Mesh). Но ошибки конфигураций могут привести как к повышению рисков компрометации инфраструктуры внешним атакующим, так и к рискам непреднамеренного раскрытия конфиденциальной информации (некорректные правила маршрутизации трафика между сервисами). Что же касается атак через сторонние сервисы, атакующий может проникнуть через вспомогательный контейнер (который находится рядом с основным и использует ресурсы хранилища и сети совместно с другими контейнерами в кластере), внедрив дополнительный контейнер, чтобы запустить вредоносный код и скрыть свою активность, или запустив код в уже существующем сервисном контейнере.

ЗАКРЕПЛЕНИЕ В ИНФРАСТРУКТУРЕ И ИЗВЛЕЧЕНИЕ ДАННЫХ

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

Наиболее актуальным примером таких действий для контейнерной среды является, например, использование контроллеров Kubernetes, таких как DaemonSets или Deployments, — так постоянное количество контейнеров атакующего всегда гарантированно работает в одном или всех узлах кластера. Злоумышленники также часто используют возможности нарушения изоляции контейнеров для сохранения данных на узлах (возможность hostPath-монтирования, которая позволит связать файл или директорию узла с контейнером), для обхода сетевой изоляции в контейнерах (hostNetwork), для доступа к управляющим процессам на узле (hostPID). Такие действия позволяют атакующему закрепиться на базовом узле контейнеризации, оставаясь невидимым для классических средств защиты.

К отдельному классу атак на контейнеры стоит отнести атаки на API Kubernetes для доступа к учётным данным. Одним из примеров таких атак является использование вредоносных контроллеров Validating Admission Webhook (отвечает за перехват и проверку API-запросов) — оно может быть использовано для перехвата конфиденциальной информации, такой как запросы к kube-API, а также для записи секретов.

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

КАК РАЗРАБОТЧИКАМ ПОЛЮБИТЬ КОНТЕЙНЕРЫ?

Так, может, проще отказаться от контейнеров совсем? Зачем разработчику технология, для нормальной работоспособности которой необходимо иметь огромное количество компетенций, внедрять отдельные, специфичные только для данного домена инструменты защиты, даже платные (об этом поговорим позже), добавляя в вакансии новый пункт на и без того дефицитном рынке? Даже один из создателей Kubernetes заявил, что контейнерная среда настолько сложная, что просто необходимо что-то с этим делать. Но ведь можно и не внедрять. Можно подождать 10 лет — не исключено, что появится замена контейнерам, ещё более изолированная среда, более легковесная и безопасная. 

Однако есть уверенность, что смена парадигмы и новая разновидность инфраструктуры появятся ещё нескоро, а значит, жить придётся с уже морально устаревшими для определённых сценариев подходами. Например, на базе контейнеров построены такие сервисные модели, как SaaS и PaaS, а также инструменты доставки ПО, такие как бессерверные вычисления (serverless).

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

• возможность внедрять декларативный формат для описания процесса установки и настройки, что сводит к минимуму затраты времени и ресурсов для новых разработчиков, подключённых к проекту;
• подготовка сервисов для развёртывания на современных облачных платформах устраняет необходимость в серверах и системном администрировании;
• минимизация расхождения между средой разработки и средой выполнения позволяет использовать непрерывное развёртывание (continuous deployment) для максимальной гибкости;
• масштабирование без существенных изменений в инструментах, архитектуре и практике разработки;
• внедрение подхода к безопасности как к коду (security as a code), что позволяет декларативно указывать настройки безопасности для конкретного микросервиса;
• возможности реализации механизмов микросегментации и нулевого доверия на уровне отдельных компонентов внутри системы, что сильно повышает уровень безопасности систем.

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

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

Или, например, WebAssembly — открытый стандарт, который определяет формат двоичных инструкций. Он позволяет создавать портируемые исполняемые файлы из исходников, написанных на различных языках программирования. Изначально созданный под безопасный запуск legacy-приложений в браузере, он развился настолько, что в этом году Docker объявил о поддержке WebAssembly; сейчас он рассматривается как «преемник» контейнеров и следующий логический шаг в развёртывании инфраструктуры. Учитывая, что рантайм Wasm по умолчанию работает в режиме песочницы и следит за безопасным доступом к памяти, а его capabilities-based-модель гарантирует, что Wasm-приложение имеет доступ только к тому, к чему ему явно разрешено иметь доступ, переход на WebAssembly-контейнеры выглядит для меня неизбежным. Даже Соломон Хайкс (один из соучредителей корпорации Docker) писал: «Если бы Wasm+WASI существовали в 2008 году, нам бы не пришлось создавать Docker. Вот насколько они важны. WebAssembly на сервере — будущее компьютерных технологий».

Однако пока такие технологии только развиваются, в контейнерах нужные инструменты уже доступны разработчикам «из коробки» — остаётся их настроить. Например, использование компонентов Linux Security Module (AppArmour, SELinux, Seccomp) для повышения изоляции процессов, управление привилегиями процессов в контейнерах через Linux Kernel Capabilities, управление лимитами на вычислительные ресурсы, использование трассировки и телеметрии для мониторинга контейнеров.

КАК К НИМ ОТНОСИТЬСЯ ЗАЩИТНИКАМ?

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

Есть распространённое мнение, что порог входа в безопасность контейнеров весьма высок. Оно имеет место, однако большинство функций безопасности контейнеров имеют под собой основание технологии защиты ядра Linux, и сообщество уже разработало стандарты и практики построения безопасности контейнеров и их инфраструктуры. К таким стандартам можно отнести бенчмарки (NIST 800-190, CIS Kubernetes Benchmark и др.), описывающие рекомендации по харденингу (сокрытию) инфраструктуры. Как правило, это открытые стандарты, и есть открытые имплементации, позволяющие их частично автоматизировать. 

Помимо непосредственных рекомендаций, разрабатываются и специализированные фреймворки для защиты цепочек поставки, такие как Sigstore, Google SLSA, а также процессы контроля целостности ПО (например, The Upgrade Framework). 

Разработка таких стандартов и решений по защите объединена в рамках сообщества Cloud Native Compute Foundation (CNCF — часть Linux Foundation) и призвана покрыть все аспекты работы с контейнерами от разработки и безопасности до размещения в облаке. От себя рекомендую ознакомиться с проектом сообщества CNCF Cloud Native Interactive Landscape — собранная в рамках этого проекта информация ориентирована на компании, которые только начинают свой путь в мир инфраструктуры для cloud-native-приложений, и призвана познакомить их с множеством имеющихся решений с открытым исходным кодом и не только. В нашем случае наибольший интерес представляет блок Security & Compliance, демонстрирующий многообразие аспектов и различных инструментов для защиты облаков и контейнеров, что доказывает актуальность проблемы (рис. 3.).

Рисунок 3. CNCF Secuirity & Compliance

Почему я вообще об этом упоминаю? Positive Technologies верит в opensource и считает его помощником, а не препятствием. Мы приняли для себя стратегию активного участия в opensource, создали группу, которая занимается вопросами участия разработчиков в открытых проектах и создания наших собственных проектов.

Мы в команде продукта по защите контейнерных сред — PT Container Security — активно поддерживаем эту инициативу. Мы никогда не скрывали, что используем проекты с открытым кодом для реализации функций продукта (например, что мы используем библиотеку syft для сбора software bill of material (SBOM) в образах контейнеров, но оперируем своими БДУ). В рамках сервиса для защиты среды исполнения контейнеров основным сенсором событий рантайма контейнеров для нас является проект Cilium Tetragon, который поставляет события безопасности в нашу подсистему детектирования угроз; в ней в виде детекторов описаны наиболее актуальные атаки на среды контейнеризации. 

Важно отметить нашу политику в отношении этих проектов: мы не просто бесплатно используем данные технологии, а активно участвуем в их развитии. В послужном списке команды PT Container Security уже есть принятые Pull Request, так что мы можем в том числе считать себя причастными к релизу 1.0 данного проекта (рис. 4).

Рисунок 4. Вклад команды PT Container Security в развитие OpenSource

ПОЗИЦИЯ ВЕНДОРОВ

Тут могу рассказать на примере Positive Technologies. Продукт для защиты контейнерных сред от Positive Technologies, PT Container Security, — это результат стратегии развития сервисов компании и экспертизы по части Kubernetes и Docker. Я лично в рамках другого продукта компании — PT Sandbox — переводил вместе с командой наши микросервисы в контейнеры. Страшно вспомнить, но у Kubernetes актуальной версией тогда была 1.8, то есть 6 лет назад, — тогда не было и половины текущих средств для управления и защиты контейнеров! А вот атаки уже были.

В 2023 году мы представили рынку коммерческую версию продукта PT Container Security.

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

Рисунок 5. Видение процесса безопасной разработки. Версия Positive Technologies

Что будет дальше, увидим, но прогнозирую, что контейнеры ещё надолго с нами!