Распространение контейнеризации: эффект Докера (часть 5)

Опубликовано: 6 Марта, 2023

Распространение контейнеризации: эффект Докера (часть 2)
Распространение контейнеризации: эффект Докера (часть 4)
Распространение контейнеризации: эффект Докера (часть 6)

Введение

В части 1 этой серии статей, состоящей из нескольких частей, я кратко объяснил, что такое контейнеры, некоторые преимущества использования контейнеров и сценарии, в которых они не являются лучшим выбором, а также некоторые общие сведения о том, как они работают. Во второй части мы обсудили популярные контейнерные решения, начиная с Docker. В части 3 мы начали говорить о безопасности контейнеров в целом и безопасности Docker в частности. Поскольку защита Docker также зависит от защиты базовой операционной системы хоста, в части 4 мы рассмотрели, как можно повысить безопасность хоста Linux с помощью SELinux, AppArmor и Grsec, которые являются общими механизмами безопасности Linux.

Докер Контент Траст

Летом 2015 года сотрудники Docker осознали, что у них та же проблема, что и у поставщиков облачных услуг: люди были в восторге от того, что они могли предложить, и хотели это использовать, но потенциальные клиенты колебались из-за опасений по поводу безопасности. Это побудило их сосредоточиться на повышении безопасности в выпуске Docker v1.8.

Образы контейнеров Docker могут поступать из одного из двух мест: с диска или из удаленного реестра. Существует ряд сертифицированных официальных репозиториев, в том числе собственный Docker Hub, а также те, которыми управляют Oracle, Canonical, RedHat и другие поставщики программного обеспечения/партнеры Docker. Компании также могут вести свои собственные реестры. Связь между Docker и реестрами шифруется с помощью TLS, и по умолчанию требуются сертификаты, которым доверяет общедоступная PKI. Внутренние корневые сертификаты ЦС компаний также могут быть добавлены в хранилище сертификатов.

Docker Content Trust (DCT) предназначен для управления программным обеспечением, работающим в вашей среде Docker, путем проверки источника ваших образов Docker с помощью цифровой подписи и защиты от атак «человек посередине» (MITM), атак повторного воспроизведения, и ключевой компромисс. Он основан на The Update Framework (UTF) и является частью механизма Docker.

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

Инфраструктура открытых ключей (PKI) является основой безопасности DCT. Закрытый ключ издателя образа используется механизмом Docker для подписи образа перед его загрузкой в удаленный реестр, а затем открытый ключ используется для подтверждения того, что образ не был подделан. В этом процессе DCT использует разные криптографические ключи, в том числе то, что называется ключом тегирования, автономным ключом (корневым) и ключом временной метки. Использование нескольких ключей позволяет восстанавливать данные при компрометации ключа, а также позволяет издателям удалять скомпрометированные ключи или менять ключи для защиты от необнаруженных компрометаций.

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

Издатели, которые хотят подписать свои коллекции контента, могут загрузить Notary — инструмент, интегрированный в DCT, для публикации и проверки контента.

Примечание:
Когда вы используете Docker Content Trust, ключи буквально являются «ключом» к вашей безопасности, поэтому важно создавать их резервные копии. Вы можете сохранить корневой ключ, который используется при создании новых ключей репозитория, на USB-накопителе или в другом безопасном месте. Хранение корневого ключа в автономном режиме обеспечивает его безопасность и позволяет уверенно создавать новый ключ репозитория, если он скомпрометирован, и это делает более ранние версии ключа репозитория недействительными.

Повышение безопасности Docker с помощью сторонних решений

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

Поворотный замок

Стороннее решение безопасности Docker, с которым я больше всего знаком, — это Twistlock, представляющий собой набор технологий управления уязвимостями, контроля доступа и защиты во время выполнения, специально созданных для защиты контейнеров и их содержимого. Полное раскрытие: один из основателей и генеральный директор компании — мой давний друг, который раньше работал с моим мужем в Microsoft над Windows Server и продуктами безопасности. Таким образом, я знаком с его опытом и широтой знаний. Соучредитель и технический директор также являются бывшими сотрудниками Microsoft.

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

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

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

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

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

Для выполнения всего этого Twistlock «Защитники» запускаются как привилегированные контейнеры в ОС хоста, наряду с контейнерами приложений. Именно Защитник отслеживает поведение во время выполнения, выявляет вредоносное поведение, предупреждает вас о ситуации и предпринимает действия для устранения проблемы.

В дополнение к этим средствам защиты от эксплойтов, неправильных конфигураций и компрометации, Twistlock имеет технологию контроля доступа, которая позволяет вам контролировать, какие и каким образом пользователи получают доступ к ресурсам Docker на предприятии, интегрируясь с каталогами LDAP (включая Microsoft Active Directory, конечно). Преимущество этого заключается в том, что вы можете применять политики доступа к ресурсам контейнера для пользователей и групп AD, а также при необходимости делать исключения из политик. Также нет крутой кривой обучения. Вы можете использовать или изменять существующие политики или создавать новые, что обеспечивает достаточную гибкость и возможность работать со специальными сценариями, созданными специально для вашей конкретной среды.

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

Резюме

Сделать контейнеры Docker более безопасными стало проще благодаря новым механизмам безопасности, встроенным в последние версии самого Docker, а также появлению сторонних решений, которые могут вывести безопасность Docker на более высокий уровень. В пятой части нашего взгляда на феномен контейнеров мы рассмотрели Docker Content Trust (DCT) и технологии безопасности Docker от Twistlock.

В следующий раз, в 6-м выпуске серии, мы немного поговорим о Kubernetes, решении Google для управления контейнерами, а также о вхождениях Microsoft в эту область: контейнерах Windows Server и контейнерах Hyper-V.

Распространение контейнеризации: эффект Докера (часть 2)
Распространение контейнеризации: эффект Докера (часть 4)