Пути защиты виртуальных контейнеров

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

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

• в виде контейнеров на платформе Docker;
• на базе скомпилированных runtime-контейнеров rkt в операционной среде CoreOS;
• в форме контейнеров обобщенного вида, созданных по нарождающемуся стандарту Open Container Initiative, в основе которого лежит знакомая технология Docker.

Нынешний уровень защиты виртуальных контейнеров

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

Хотя контейнеры появились значительно позже и их разработка велась с учетом прежних проблем, уровень защищенности ВМ значительно выше. Это объясняется следующими причинами:

• Приложения, исполняемые на одном хосте внутри отдельных ВМ, имеют более высокую степень изоляции друг от друга, чем при запуске в среде контейнеров.
• Уровень изоляции контейнеров от хоста также оказался ниже, чем у гипервизора ВМ. Для примера, если запущенный в контейнере процесс сумел получить root-права, то он автоматически получает привилегии root-уровня также и на хосте, в котором работает контейнер.
• Системы управления контейнерами еще не достигли того уровня зрелости, которым обладают средства управления ВМ. Из-за их ограниченных возможностей в системе могут появляться, например, просроченные или небезопасные образы контейнеров. Риск возникновения таких ситуаций значительно выше, если сравнивать со средой ВМ. Если на хосте появляются контейнеры, до этого скомпрометированные хакерами, то путь в рабочую прикладную среду для них в целом открыт.
• Уровень накопленного опыта ИТ-специалистов при работе с контейнерами еще ниже, если сравнивать с эксплуатацией ВМ и поддержкой работы приложений в традиционной среде. Еще не накоплен опыт по реализации процедур обновления в контейнерной среде, настройки приложений и ОС. Аналогичное можно сказать и в отношении опыта пресечения нарушений и защиты контейнеров: он также пока недостаточный.

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

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

Развитие систем защиты контейнеров

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

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

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

Для устранения этих ограничений VMware предложила использовать Photon OS — упрощенный, небольшой по размеру дистрибутив Linux для развертывания соответствующей вычислительной среды внутри контейнера. И второе решение — легковесный «микровизор» Photon Machine, созданный на базе гипервизора ESXi. Применение этих инструментов, по мнению VMware, позволяет добиться нормальной работы функции Instant Cloning: запуск новых ВМ за доли секунды. Вывод контейнеров из-под обслуживания должен происходить в том же темпе.

Этот способ предусматривает возможность индивидуального управления каждым контейнером. Оно осуществляется через ВМ, внутри которой работает контейнер, через VMware vCenter.

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

Clair — это продукт класса Open Source. Он позволяет осуществлять многоуровневую (layer-by-layer) проверку контейнеров на известные уязвимости. Управление процессом проверки ведется через API. Особая значимость этой системы в том, что контроль распространяется также на образы контейнеров, которые уже прошли проверку на отсутствие уязвимостей, но оказались пассивно скомпрометированы за счет выявления новых уязвимостей, о которых не было известно на момент проведения прежней проверки. Clair позволяет добавлять новые сервисы контроля и вести непрерывный мониторинг работающих контейнеров, отлавливая возникающие там опасности.

Twistlock — это пакет безопасности для контейнеров, разработанный Беном Бернстайном и Димой Стопелем, которые более 10 лет проработали в исследовательском подразделении Microsoft в Израиле, а также работали на спецслужбы Израиля. Он позволяет:

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

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

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

Создание безопасной среды для работы контейнеров. Это направление связано с использованием CoreOS — операционной системы, созданной на базе Linux и применяемой для построения гибко масштабируемых кластеров. На рынке контейнерной виртуализации она выступает главным конкурентом Docker. Ее нынешнее развитие также ведется в направлении развития собственных средств безопасности.

Так, в прошлом году была анонсирована система Distributed Trusted Computing (DTC). Это механизм криптографической проверки целостности всего комплекса программных средств, которые формируют контейнерную среду — начиная от аппаратных средств сервера до прикладных программ, запускаемых внутри контейнеров.

Применение DTC-серверов в контейнерном кластере реализуется через режим безопасной загрузки Secure Boot. Они осуществляют криптопроверку с целью подтверждения, что запущенные в работу экземпляры ОС не были изменены по сравнению с эталоном. Проверка затрагивает также вычислительную среду контейнера. В качестве эталонов для образов сохраненных контейнеров применяются ключи, хранящиеся в TPM-модулях (Trusted Platform Modules).

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

Недостатком системы DTC является то, что заказчику придется приобретать все элементы контейнерной экосистемы CoreOS (в отличие от Docker).

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

Особенность технологии Docker состоит в том, что она позволяет отделить приложение от инфраструктуры и работать с ней как с управляемым приложением. Наращивание безопасности для контейнеров на платформе Docker ведется в двух направлениях: развитие проекта Notary и создание набора инструментов Docker Content Trust, позволяющих применять авторизованные образы программ и создающих специальный механизм, который защищает пользователей от атак типа man-in-the-middle при установке обновлений.

Среди новых инициатив Docker, объявленных на недавней конференции Dockercon EU, можно выделить проект Project Nautilus, связанный с созданием системы сканирования и валидации образов, складируемых в реестре Docker Hub. Цель этой разработки — поиск путей для выявления уязвимостей в приложениях, размещаемых в оболочке контейнера.

Еще одним новым направлением в развитии систем защиты для Docker стало создание пользовательских пространств имен. Это позволяет повышать эффективность применения имеющихся средств защиты на этапе их взаимодействия с прикладными системами.

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

Развитие системы безопасности в Docker будет продолжаться также по пути совершенствования процедур аутентификации и авторизации. Цель этих работ — создать надежную поддержку для традиционных механизмов аутентификации и защиты данных: Kerberos, LDAP, Microsoft Active Directory, SASL.