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

Широкое применение модели программирования с непрерывной интеграцией (CI) удачно сочетается с Docker, и его популярность взмыла вверх. На сегодня в собственных «официальных» репозиториях (https://docs.docker.com/docker-hub/repos/) хранятся сотни тысяч готовых образов Docker. И в этом кроется самая большая проблема безопасности контейнера Docker: целостность образа и настроек.

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

Недавно было обнаружено 17 различных образов Docker (https://www.bleepingcomputer.com/news/security/17?backdoored-docker-images-removed-from-docker-hub/), содержащих обратные оболочки (reverse shell), программы захвата ключа безопасности или программу криптомайнинга Monero. Эти образы были удалены из репозиториев. В каждом случае были найдены способы обеспечить безопасность Docker и управляемых контейнеров, но для этого требуется дополнительная обработка.

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

Какие здесь возникают препятствия? Один вариант — присутствие вредоносной программы, но возможны и ошибки в настройках образов или внесение несанкционированных изменений в рабочей среде. В частности, встречаются неправильно составленные файлы настроек. Примером может служить разрешение входа root по SSH с известным набором предварительно подготовленных ключей. Это проблема файла настроек, однако некоторые разработчики используют данный прием в своих предварительных образах. Случайные репозитории образов следует считать вовсе смертельно опасными, но даже «официальные» репозитории не проверяются достаточно надежно. Мы рассмотрим «модели с нулевым доверием» (https://www.gartner.com/smarterwithgartner/gartner-top-10?security-projects-for-2018/).

Существуют еще проблемы с исправлениями, а также необходимыми обновлениями исходных файлов образа и узла, на котором размещен Docker. Запросы и обновления часто обрабатываются с помощью инструментов, уже используемых разработчиками, в том числе средствами управления Kubernetes или Mesos. Puppet, Chef и даже Jenkins могут быть настроены для управления и анализа парка контейнеров, даже в производственной среде и после этапа разработки. Направить в Docker запрос относительно компонентов и статуса образа — хорошо известная процедура.

Предпочтение моделей с наименьшим и нулевым доверием

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

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

Необходимо строго контролировать административное доверие, чтобы предотвратить изменения образов известными или неизвестными лицами. Иногда изменения вносятся, чтобы исправить ошибки, а иногда в образы вводится код для майнинга Monero.

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

Абсолютный сетевой контроль с проверкой подлинности

Вы не увидите хеши Monero, покидающие ваши контейнеры, если не отслеживаете их. Защита контейнеров означает абсолютный контроль мест назначения сетевого трафика как на узле контейнера, так и в инфраструктурах контейнера, в том числе экземплярах объектов контейнера, которые обмениваются данными с другими экземплярами. Требуется только выход в Интернет, чтобы обналичить Monero (https://getmonero.org/), нарушить или подорвать инфраструктуру и сетевые коммуникации парка контейнеров.

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

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

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

Как сохранить целостность контейнера Docker

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

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

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

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

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

Целостность контейнеров

Исследователи и аналитики подчеркивают важность целостности контейнеров и манифестов образа (https://www.forrester.com/report/Ten+Basic+Steps+To+Secure+Software+Containers/-/E-RES136406) и необходимость рассмотреть каждый элемент в цепочке поставки контейнеров. Диспетчеры журналов могут быть полезны при поиске места, где возникла проблема, но профилактические меры начинаются с определения и закрепления ответственности. Docker предоставляет проанализированные базовые контейнеры, но, как уже отмечалось, не всегда их отслеживает хорошо. Соответствующие возможности встроены в некоторые сторонние приложения, использующие собственные источники целостности контейнеров и методы создания отпечатков. Статические анализаторы кода, приложения, исследующие программный код в поисках ошибок лицензирования и настроек, обладают разнообразными возможностями интеграции с производственными инфраструктурами кода.

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

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

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

Сокращение направлений атаки

Еще один очень важный фактор — принять во внимание не только узел, но и направление атаки для каждого элемента в цепочке поставки. Даже универсальные и подписанные образы могут быть настроены неправильно или по устаревшим шаблонам. Последние «облачные» экземпляры узла не обязательно инспектируются в поисках шагов блокировки и необходимых исправлений (вспомните о Spectre, Meltdown и других).

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

Такие организации, как Twistlock, AquaSecurity, Zscaler и другие, выбирают различные подходы к программированию и инфраструктурам развертывания (часто между средствами безопасности наблюдается значительное сходство). Компоненты мониторинга трафика и брандмауэры в этих продуктах эффективны, как и специфические средства подготовки образов и развертывания. Использование инструментов управления ключами, их последующее принудительное применение и обработка исключений может быть непростой задачей, но это защищает от заражения образов, вредоносных программ и позволяет избежать различий в настройках.

Как говорится, менеджеры по продажам видят число 106 там, где инженеры видят 10-6; специалисты по безопасности должны протянуть цепь между этими двумя крайностями. Провисание цепи означает облегченные образы. Натянутая цепь означает контроль и мониторинг сети. Тонкий контроль репозиториев, в том числе разрешений, ключей и иерархии полномочий, поможет гарантировать, что цепь не заржавеет. А затем мы выстроим новую цепь.