Container security

Безопасность контейнеров: Что необходимо знать о стандартах NIST

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

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

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

К счастью, появляются передовые практики обеспечения безопасности контейнерной инфраструктуры. Национальный институт стандартов и технологий (NIST), подразделение Министерства торговли США, опубликовал «Специальную публикацию NIST 800–190: Руководство по безопасности контейнеров приложений»: свод руководящих принципов (https://www.nist.gov/publications/application-container-security-guide), которые могут служить полезной отправной точкой и основой для аудита безопасности. В нем разбираются проблемы безопасности и стратегии смягчения последствий для каждого уровня контейнерного стека. Темы включают в себя сканирование на уязвимости, использование контейнерных хостовых ОС, и использование надежной аутентификации и авторизации.

Вот ключевые лучшие практики обеспечения безопасности контейнерной инфраструктуры в руководящих принципах NIST.

Образы контейнеров: Время для отражения

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

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

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

Оркестрация безопасности: Заблокируйте это

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

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

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

Содержат сами контейнеры

В дополнение к образам контейнеров и приложениям в них, сами контейнеры потенциально могут стать проблемами безопасности. Одна из наиболее серьезных проблем возникает, когда среды развёртывания контейнеров, которые запускают контейнеры и управляют ими (такие продукты, как containerd, CRI-O и rkt) сами содержат уязвимости. NIST предупреждает что, если их не устранять вовремя, такие уязвимости могут привести к сценариям «container escape», когда злоумышленник потенциально может получить доступ к другим контейнерам или к операционной системе хоста, поэтому администраторы хостов должны сделать установку обновлений безопасности высокоприоритетной задачей.

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

Заблокируйте операционную систему

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

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

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

Оперативные вопросы: Автоматизация является ключевой

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

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

Угрозы безопасности и смягчение последствий постоянно эволюционируют, и ни один ресурс не может дать все ответы. Тем не менее, руководство по безопасности контейнерных приложений NIST (https://www.nist.gov/publications/application-container-security-guide) предлагает прочную основу и структуру политики безопасности для контейнерных сред. Его стоит прочитать всем, кто занимается созданием, развертыванием, управлением и обслуживанием контейнеров и контейнерных приложений, и обязательно нужно прочитать профессионалам в области безопасности по мере перехода отрасли к следующему этапу ИТ.