Обзор публикации NIST SP 800-190 "Application Container Security Guide"

Руслан Рахметов, Security Vision

Друзья, в предыдущей публикации мы обсудили защиту технологий виртуализации в соответствии с рекомендациями специальной публикации NIST SP 800-125. При этом мы отмечали, что применение технологий виртуализации широко распространено в современных ОС, что позволяет предоставить безопасный, гибкий, автоматизируемый способ развертывания и запуска новых приложений, которые работают независимо и изолированно друг от друга благодаря технологии контейнеризации приложений. Темой сегодняшней статьи является специальная публикация NIST SP 800-190 "Application Container Security Guide" («Руководство по безопасности контейнеризованных приложений»), в которой описаны угрозы информационной безопасности при использовании технологий контейнеризации приложений и приводятся рекомендации по способам их нейтрализации.

В отличие от технологии полной виртуализации, при которой гипервизор управляет набором виртуализированных операционных систем, технология контейнеризации подразумевает создание для приложений виртуальной среды, в которой доступны только выделенные ресурсы ОС и данные самого приложения, при этом данные других приложений, которые работают на той же ОС, недоступны. В технологиях контейнеризации приложений также используется микросервисный подход, при котором создается набор контейнеров, содержащих несколько компонентов (сервисов) для функционирования одного приложения. Такое дробление обеспечивает гибкость и масштабируемость разработки и развертывания приложений, поскольку позволяет распределить и при необходимости реплицировать сервисы между разными приложениями, а независимость сервисов дает возможность использовать разные языки программирования и фреймворки при их создании. В отличие от виртуализации, где каждая виртуальная машина имеет свой жизненный цикл (т.е. может быть изменена или переконфигурирована), контейнеры существуют в неизменном состоянии, а при необходимости произвести модификацию контейнер удаляется и создается новый с требуемыми характеристиками; при этом все необходимые файлы для запуска контейнеризованных приложений хранятся в образах контейнеров (англ. container images). Аналогичный подход применяется и при работе контейнеров с данными: контейнеры не содержат необходимых данных внутри себя, вместо этого они обращаются к независимым хранилищам информации, которые не меняются при замене контейнера. При работе с контейнерами к хостовым ОС предъявляются некоторые требования, обеспечивающие работу контейнеризации, такие как изоляция пространства имен (недоступность файловой системы, сетевых интерфейсов, процессов одного контейнера для обращения из другого контейнера), выделение ресурсов (возможность задать определенные аппаратные характеристики для каждого контейнера), виртуализация файловой системы (дедупликация исполняемых контейнерами файлов, сохранение изменений с доступом к новым данным только для контейнера-инициатора).

Архитектура технологий контейнеризации состоит из пяти уровней:

1. Системы разработки, использующиеся для создания образов контейнеров и отправки их на тестирование и аккредитацию;

2. Системы тестирования и аккредитации, проверяющие и подписывающие содержимое образов контейнеров, с дальнейшей отправкой в реестр образов;

3. Реестры образов контейнеров, хранящие и передающие данные образы по запросу оркестратора;

4. Оркестраторы, конвертирующие образы в контейнеры и разворачивающие контейнеры на хостах;

5. Хосты, запускающие и останавливающие контейнеры по команде оркестратора.

Фазы жизненного цикла контейнера состоят из 3 этапов:

1. Создание, тестирование, аккредитация образа: компоненты контейнеризируемого приложения собираются и размещаются в образе контейнера. Создание образов выполняется с помощью инструментов автоматизации и управления созданием (например, Jenkins, TeamCity). Тестирование выполняется для проверки функциональности полученного образа, а аккредитация осуществляется силами команды кибербезопасности после проверки образа.

2. Хранение и получение образа: образы хранятся в централизованных репозиториях - реестрах образов, выполняющих также версионный контроль, тэгирование, каталогизацию. Реестры могут быть внутренними и внешними (например, Docker Hub, Google Container Registry).

3. Развертывание и управление контейнерами: данный этап выполняется оркестраторами (например, Kubernets, Docker Swarm) - программными инструментами для получения образов контейнеров из реестров, развертывания в контейнерах, управления запущенными контейнерами. При развертывании образа в контейнере сам образ остается неизменным, а его копия размещается внутри контейнера и запускается. Оркестратор отвечает за управление контейнерами - контроль состояния, перезапуск в случае ошибки, управление сетевым взаимодействием контейнеров. При обновлении приложения, свежая версия попадает в реестр образов, а оркестратор получает новый образ контейнера и замещает им предыдущий. При этом в небольших инфраструктурах оркестратора может не существовать, а хост будет сам запрашивать образ контейнера из реестра и управлять им.

В документе NIST SP 800-190 также приведен список указанных ниже киберрисков для различных аспектов технологии контейнеризации с указанием контрмер для их минимизации.

1. Киберриски образов контейнеров

1.1. Уязвимости в образах: при наличии уязвимости в образе, данная уязвимость «перекочует» в развернутый контейнер; при этом при первоначальном развертывании ПО в образе может не иметь известных уязвимостей, однако со временем уязвимости с высокой долей вероятности будут найдены и проэксплуатированы атакующими. Контрмерами будут интеграция процессов и инструментов контроля отсутствия уязвимостей на всех этапах жизненного цикла образов, обработка уязвимостей на всех уровнях образа (включая фреймворки и прикладное ПО), применение политик соответствия публикуемых приложений внутренним правилам контроля отсутствия уязвимостей.

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

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

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

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

2. Киберриски реестров

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

2.2. Устаревшие образы в реестрах: при хранении в реестрах устаревших образов с известными уязвимостями повышается вероятность того, что они будут развернуты в контейнерах. Контрмерами будут очистка реестров от старых образов и использование указания версии при именовании образов.

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

3. Киберриски оркестраторов

3.1. Неограниченный административный доступ: есть права администрирования предоставлены недостаточно гранулированно, то администраторы оркестраторов могут случайно или намеренно внести изменения в сторонние контейнеры. В качестве контрмеры можно применять модель разграничения доступа, предоставляемую оркестратором.

3.2. Неавторизованный доступ: оркестраторы зачастую используют встроенные механизмы аутентификации, что может привести к применению более простой парольной политики или появлению устаревших учетных записей. Контрмерами будет использование мультифакторной аутентификации администраторов, применение концепции единого входа (англ. single sign-on), а также шифрования данных в контейнерах.

3.3. Недостаточное разграничение сетевого межконтейнерного трафика: в системах контейнеризации трафик между контейнерами маршрутизируется через оверлейные виртуальные сети, управляемые оркестратором, что приводит к отсутствию контроля со стороны корпоративных сетевых средств защиты (например, IPS/IDS), а также чревато реализацией сетевых атак со стороны скомпрометированного контейнера в отношении соседних контейнеров, использующих ту же сеть. Для минимизации данного риска можно выделять специальные сети для передачи информации разного уровня конфиденциальности и разного назначения.

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

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

4. Киберриски контейнеров

4.1. Уязвимости в ПО контейнера: при уязвимостях, позволяющих атакующим выполнить «побег из контейнера» (англ. container escape), безопасность всего хоста и всех контейнеров на нем будет поставлена под угрозу. В качестве контрмеры следует применять процедуры процесса управления уязвимостями ко всем приложениям и компонентам контейнеров.

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

4.3. Небезопасные конфигурации контейнеров: при отсутствии разграничения на выполнение высокопривилегированных команд из контейнеров, хостовая ОС и соседние контейнеры могут быть скомпрометированы. Контрмерами будут применение вендорских рекомендаций по конфигурированию контейнеров, применение встроенных в ОС инструментов управления доступом, примените Linux-профилей seccomp для ограничения возможностей контейнеров повлиять на ОС.

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

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

5. Киберриски хостовых ОС

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

5.2. Разделяемое ядро ОС: при работе контейнеров они получают доступ к некоторым компонентам ядра хостовой ОС, что может привести к ее компрометации. Для исключения данного сценария не следует контейнеризованные и неконтейнеризованные приложения на одном хосте.

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

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

5.5. Подмена объектов файловой системы хостовой ОС: при некорректной конфигурации контейнеру может быть предоставлено право изменения объектов файловой системы хостовой ОС, что может привести к компрометации самой хостовой ОС и всех контейнеров на ней. В качестве контрмеры следует применять инструменты контроля попыток изменения объектов файловой системы хоста.