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

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

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

После рассмотрения базовой технологии виртуальных машин и контейнеров в первом разделе, во втором разделе сравнивается состояние безопасности этих решений на основе трех ключевых показателей: размер доверенной вычислительной базы (TCB), количество и уровень распространенных уязвимостей и Обнаруженные воздействия (CVE) и типы сертификатов безопасности, которые были получены. Затем в третьем разделе рассматривается, как применить эти выводы для повышения безопасности в среде DevSecOps.

Обзор типов виртуализации

При аппаратной виртуализации виртуальные машины контролируются монитором виртуальной машины, чаще называемым гипервизором. Каждая виртуальная машина имитирует одно и то же базовое оборудование, но может иметь другую гостевую ОС. Гипервизор выделяет отдельное адресное пространство для каждой виртуальной машины, что гипервизор обеспечивает с помощью блока управления памятью ЦП (MMU).

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

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

VMware ESXi и Xen Project являются примерами гипервизоров типа 1, а VMware Desktop — примером гипервизора типа 2. Совсем недавно появились также гибридные гипервизоры, сочетающие в себе элементы Типа 1 и Типа 2. Например, KVM — это уровень виртуализации в ядре Linux, работающий в режиме ядра на «голом железе».

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

Гипервизоры типа 2 создают дополнительную задержку для приложений, работающих на виртуальных машинах, поскольку теперь существует три уровня программного обеспечения: гостевая ОС, гипервизор и хост-ОС. Однако при использовании гипервизора типа 2 не все приложения должны выполняться на виртуальных машинах гипервизора. Это имеет большое значение при настройке рабочей станции, например, когда рабочей станции Linux необходимо запускать небольшой процент своих приложений в ОС Windows.

В этом примере приложения Linux изначально работают вне гипервизора и с полной производительностью. Точно так же в системе реального времени приложения реального времени могут работать непосредственно в ОС реального времени (RTOS), в то время как только приложения, не работающие в реальном времени, подвергаются дополнительной задержке при работе на гипервизоре типа 2.

Гибридные гипервизоры стремятся получить лучшее из обоих подходов. Для встраиваемых систем реального времени INTEGRITY-178 tuMP от Green Hills Software использует комбинацию подходов Типа 1 и Типа 2, которые разделяют механизмы изоляции и виртуализации.

Как и в случае с гипервизором типа 1, основные механизмы разделения работают в режиме ядра на «голом железе». Для INTEGRITY-178 tuMP это микроядро с усиленным разделением, которое изолирует группы неядерного программного обеспечения в изолированные разделы. Однако остальная часть виртуализации, в основном аппаратное моделирование, выполняется в пользовательском режиме поверх ОСРВ INTEGRITY-178 tuMP.

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

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

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

Размер доверенной вычислительной базы

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

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

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

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

Общая цель состоит в том, чтобы свести к минимуму размер TCB и количество интерфейсов к нему, чтобы упростить проверку TCB. Если TCB можно сделать достаточно маленьким, можно формально оценить его безопасность. Формальная проверка использует математические доказательства для демонстрации правильности работы и является самой строгой формой оценки.

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

Цель сокращения TCB программного обеспечения до функций, необходимых для этих четырех основных политик безопасности, привела к концепции ядра разделения. Ядро с разделением делит память на разделы с помощью аппаратного блока управления памятью (MMU) и разрешает только тщательно контролируемую связь между разделами, не относящимися к ядру. Хотя почти все ядра пытаются обеспечить изоляцию, используя аппаратные функции, такие как MMU и MMU ввода-вывода (IOMMU), использование только аппаратных ресурсов не гарантирует изоляцию, не говоря уже о других требованиях безопасности.

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

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

TCB гипервизора типа 2 на самом деле является просто TCB основной ОС, поскольку гипервизор типа 2 работает в пользовательском пространстве. Если это ОС общего назначения, то TCB, вероятно, больше, чем гипервизор типа 1.

Однако, если операционная система предназначена для обеспечения безопасности, например, в виде разделительного ядра, то TCB в системе типа 2 может быть меньше, чем в гипервизоре типа 1. Точно так же гибридный гипервизор, построенный на ядре разделения, имеет размер TCB, равный размеру ядра разделения. Поскольку ядро ​​разделения разработано специально для минимизации TCB, оно имеет наименьший TCB среди всех решений виртуализации.

Для контейнеров, работающих поверх Linux, TCB на порядок больше, чем TCB гипервизора типа 1. Глядя только на количество уникального кода, используемого для виртуализации, контейнеры Linux используют весь интерфейс системных вызовов, который примерно в 10 раз больше, чем типичный интерфейс гипервызовов гипервизора.

Полный TCB включает в себя все части Linux, работающие в режиме ядра. Выпуск 5.11 (2021 г.) ядра Linux содержал более 30 миллионов строк кода, из них около 4 миллионов строк кода для основных функций, а остальные — для драйверов. Docker также может добавляться в TCB, потому что демон Docker обычно запускается от имени пользователя root.

Критические уязвимости обнаружены

База данных Common Vulnerabilities and Exposures (CVE) содержит список общеизвестных уязвимостей и уязвимостей информационной безопасности. Уязвимость — это уязвимость в коде, использование которой отрицательно сказывается на конфиденциальности, целостности или доступности. Количество сообщаемых уязвимостей увеличивается с каждым годом: в Национальной базе данных уязвимостей (NVD), поддерживаемой NIST, в 2021 году было зарегистрировано более 20 000 уязвимостей.

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

Многие встроенные системы нелегко обновить, и конечный пользователь может не знать всех программных компонентов в системе, не говоря уже о том, что нужно применять исправления. Даже при своевременной установке некоторые патчи не устраняют всю уязвимость. «Спектр» — это пример уязвимости, которая не была полностью устранена патчем, несмотря на то, что она была раскрыта в 2018 году.

Что касается решений виртуализации, системы на основе контейнеров имеют наибольшее количество CVE, поскольку контейнеры зависят от базовой ОС. Контейнеры обычно работают на ядре Linux, которое имеет очень большую кодовую базу с более чем 3400 обнаруженными уязвимостями.

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

Гипервизоры типа 1 также имеют значительное количество CVE. Например, Xen имеет более 600 уязвимостей в NVD, при этом в 2021 году было зарегистрировано около 20 CVE. Уязвимости гипервизора многочисленны и разнообразны, например, выход из виртуальной машины, гиперджекинг, отказ в обслуживании (DoS) и атаки по сторонним каналам. Некоторые из этих уязвимостей могут быть очень серьезными, поскольку после нарушения безопасности гипервизора злоумышленники могут получить доступ ко всем виртуальным машинам, всем приложениям и всем данным приложений внутри них.

Гибридные гипервизоры, основанные на разделенном ядре, работают намного лучше. Например, ни в многоядерном ядре разделения INTEGRITY-178 tuMP, ни в одноядерном ядре разделения INTEGRITY-178 не сообщалось об уязвимостях безопасности с момента его первого развертывания в 2002 году.

Сертификаты безопасности

Сертификация в соответствии с государственными стандартами безопасности является убедительным свидетельством уровня гарантии безопасности и функциональности продукта. Двумя широко используемыми сертификатами безопасности являются Common Criteria и Risk Management Framework.

Общие критерии

Надежность безопасности компьютерного оборудования и программных платформ может быть указана путем оценки в соответствии с « Общими критериями оценки безопасности информационных технологий » (ISO/IEC 15408). Цели оценки Common Criteria (TOE) обычно оцениваются по отношению к установленному правительством профилю защиты, который включает как функциональные требования, так и требования к обеспечению.

Оценки могут быть выполнены на разных уровнях глубины и строгости, называемых уровнями гарантии оценки (EAL), где EAL1 является наименее строгим, а EAL7 — наиболее строгим. Требования обеспечения безопасности и функциональные требования безопасности сгруппированы в профиль защиты, предназначенный для конкретного типа продукта.

Начиная с EAL2, каждый из этих EAL требует анализа уязвимостей до определенного уровня. EAL5 — это первый уровень защиты от злоумышленников с «умеренным» потенциалом, и только на уровне EAL6 устойчивость к атакам с проникновением повышается до «высокого» потенциала атаки.

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

Например, рассмотрим профиль защиты для операционных систем общего назначения (GPOS-PP). GPOS-PP не был разработан для конкретного уровня EAL, но в основном основан на требованиях EAL2. Дополнительные профили защиты были определены для улучшения некоторых аспектов системной безопасности ОС. Примеры включают профиль защиты контролируемого доступа (CAPP) и профиль защиты безопасности с метками (LSPP). Требования доверия для обоих этих профилей защиты указаны в EAL3.

Единственным государственным профилем защиты, когда-либо разработанным для высокой надежности или EAL6 и выше, который применяется к операционным системам или гипервизорам, является «Профиль защиты правительства США для ядер разделения в средах, требующих высокой надежности» (SKPP). Стандарт SKPP, определенный АНБ, был опубликован в 2007 году. Хотя сертификация коммерческих продуктов по стандарту SKPP в США была прекращена в 2011 году, официальные правительственные программы, которым требуется высокая надежность, по-прежнему требуют соблюдения целей безопасности в SKPP.

Принимая во внимание общие критерии, применяемые к средам оживления, некоторые версии Linux, которые включают в себя функции контейнера Linux, добавляют параметры безопасности SELinux и были сертифицированы для EAL4+ с CAPP и LSPP. Как упоминалось выше, в SELinux каждый год обнаруживается множество уязвимостей. Это неудивительно, учитывая, что CAPP и LSPP прямо заявляют, что эти профили защиты «подходят только для предполагаемого невраждебного и хорошо управляемого сообщества пользователей, которым требуется защита от угроз непреднамеренных или случайных попыток нарушения безопасности системы». Только начиная с EAL5 враждебные угрозы в той или иной степени устраняются.

Очень немногие гипервизоры типа 1 были сертифицированы по Common Criteria. Сертифицирована только VMware vSphere 5.0, и то на EAL4+, но не на профиль защиты, определенный правительством.

Ядро разделения INTEGRITY-178 и ОСРВ несколько раз были сертифицированы на соответствие требованиям EAL6+ и «Высокая надежность» с использованием SKPP. Никакая другая коммерческая операционная система или гипервизор не были сертифицированы на соответствие требованиям EAL6+ или High Robustness.

В рамках сертификации SKPP INTEGRITY-178 прошел независимый анализ уязвимостей и тестирование на проникновение со стороны АНБ, чтобы продемонстрировать, что он не позволяет враждебным и хорошо финансируемым злоумышленникам с высоким потенциалом атаки нарушать политики безопасности. Распространяя этот дизайн безопасности на многоядерные процессоры, INTEGRITY-178 tuMP продолжает соответствовать строгому набору функциональных требований и требований к гарантии SKPP. Решение гибридного гипервизора основывается на этом безопасном ядре, добавляя виртуализацию в изолированный раздел пользовательского пространства.

Система управления рисками

Система управления рисками (RMF) — это политика федерального правительства США и набор стандартов, разработанных Национальным институтом стандартов и технологий (NIST) для оценки и авторизации систем миссий. Обзорным документом является NIST SP 800-37, «Структура управления рисками для информационных систем и организаций: подход к жизненному циклу системы для обеспечения безопасности и конфиденциальности». Этот документ определяет шесть шагов: Категоризация информационных систем, Выбор элементов управления безопасностью, Внедрение, Оценка, Авторизация и Мониторинг.

Одним из самых сложных шагов является выбор элементов управления безопасностью. NIST SP 800-53 «Меры безопасности и конфиденциальности для федеральных информационных систем и организаций» содержит более 800 мер безопасности, многие из которых не применимы к встроенным системам. Программа должна пройти через все элементы управления RMF и определить, какие из них применимы.

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

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

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

Гибридный гипервизор INTEGRITY-178 tuMP не предлагает прямого руководства по соблюдению RMF. Вместо этого он предоставляет подробную информацию о достижении гораздо более строгих целей безопасности, определенных в SKPP. В результате INTEGRITY-178 tuMP обеспечивает безопасность выше и выше RMF.

Как использовать контейнеры более безопасно

Для организаций, которые хотят использовать контейнеры для реализации среды DevSecOps, проблема заключается в том, чтобы найти способ защитить контейнеры и базовую ОС. Некоторые среды DevSecOps пытаются улучшить безопасность контейнеров, используя «защищенные контейнеры», которые в основном полагаются на сканирование на наличие известных уязвимостей и соблюдение политики безопасности.

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

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

SELinux эффективно предотвращает использование некоторых уязвимостей контроля доступа, таких как уязвимость RunC (CVE-2019-5736), позволяющая контейнерам в решении Docker получать привилегии root на хост-компьютере. Однако SELinux — это лишь частичное решение, потому что 1) SELinux не защищает от других типов уязвимостей в ядре Linux или конфигурации безопасности ядра и 2) SELinux имеет свои собственные уязвимости, 15 из которых были обнаружены только в 2021 году.

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

Запуск внутри виртуальной машины удаляет Linux и механизм выполнения контейнера из TCB, но есть потеря производительности при запуске виртуализации ОС поверх аппаратной виртуализации. Если виртуальная машина, на которой размещаются контейнеры, работает на гипервизоре типа 1, вы поменяли массивный TCB на большой TCB и по-прежнему подвержены атакам на основе гипервизора.

Более безопасным решением является запуск контейнеров в разделе усиленного микроядра разделения, такого как INTEGRITY-178 tuMP. Другие разделы могут содержать приложения с разными уровнями безопасности. Запуск системы контейнеров в разделе защищает контейнеры от приложений, работающих в других разделах, и наоборот.

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

Вывод

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

Разделяя требования к изоляции и виртуализации, микроядро разделения INTEGRITY-178 tuMP создает критически важный для безопасности гипервизор реального времени для обеспечения максимальной безопасности и оптимизации производительности системы. Ядро разделения представляет наименьшую поверхность атаки и может быть полностью оценено на предмет изоляции, свойств безопасности и правильности.

Уровень виртуализации микроядра находится за пределами TCB и используется только для тех приложений, которые в нем нуждаются, оставляя высоконадежные приложения для запуска непосредственно в RTOS. INTEGRITY-178 tuMP соответствует требованиям профиля защиты ядра разделения, определенного NSA, для обеспечения высокой надежности.

Безопасная система может использовать контейнеры в качестве платформы упаковки и доставки программного обеспечения для DevSecOps, если другое решение обеспечивает изоляцию. Контейнеры Linux и Docker могут работать поверх уровня виртуализации ОСРВ INTEGRITY-178 tuMP, в то время как микроядро разделения обеспечивает сертифицированную изоляцию.