Защита виртуализации от а до я

Автор: Сидорова Мария, Заместитель руководителя направления "Защита виртуализированных инфраструктур" компании Код Безопасности

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

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

26 июня 2009 года, на очередной встрече VMware User Group Russia, было принято решение о создании отдельной группы, которая сконцентрируется на вопросах информационной безопасности. VMware Security Group Russia представляла собой некоммерческое объединение российских специалистов, занимающихся вопросами обеспечения информационной безопасности инфраструктур виртуализации. Группа объединяла десятки специалистов из Москвы, Санкт-Петербурга, Красноярска и Тюмени и вела самостоятельную деятельность по популяризации вопросов правильного построения систем информационной безопасности для виртуальных инфраструктур и развития этого рынка. В феврале 2010 года группа расширила сферу своих интересов в части других производителей платформ виртуализации и сменила название на Virtualization Security Group Russia.

К этому времени на Западе уже были описаны методы взлома самых популярных на тот момент платформ виртуализации и сформулированы актуальные специфические угрозы, среди которых выделяли:

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

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

Сделаем небольшое лирическое отступление. Около 8 лет назад сообщества по виртуализации и информационной безопасности активно обсуждали появление руткита Blue Pill (предшественник  Red Pill, был разработан для определения программной виртуализации), впервые представленного на Black Hat – 2006 Джоанной Рутковска. Для того чтобы приблизиться к пониманию того, как это работает, давайте вспомним понятие колец защиты, которые реализуют аппаратное разделение системного и пользовательского уровней. Традиционно семейство микропроцессоров x86 обеспечивало четыре режима колец защиты, однако затем появились неформальные понятия – «кольцо-1» и «кольцо-2». Кольцо-1 – это режим, который появился благодаря разработке компаниями Intel и AMD технологии аппаратной виртуализации. Режим назван так для того, чтобы подчеркнуть, что у большинства гипервизоров больше привилегий, чем у ядра операционной системы, обычно работающего в кольце-0. Гипервизор осуществляет координацию использования имеющихся аппаратных ресурсов несколькими операционными системами аналогично тому, как сами операционные системы осуществляют распределение ресурсов между несколькими задачами. Кольцо-2 (System Management Mode) – это самый привилегированный режим выполнения на процессорах архитектуры x86 (если о его поддержке заявлено производителем). Исполнение кода именно в этом режиме и использовала Джоанна Рутковска. Дело в том, что в отличие от руткитов предыдущего поколения режима ядра, Blue Pill не требуется компрометировать что-либо в коде или данных ядра. Blue Pill поддерживает и гнездовую виртуализацию, проще говоря, вы можете запустить Blue Pill, а затем уже внутри виртуальной машины, созданной Blue Pill, запустить другой гипервизор. Любопытным моментом является то, что атаки на этом уровне после 2007 года стали практически невозможными (я говорю практически, так как ничего совершенно невозможного в области информационной безопасности не бывает, к тому же злоумышленники чаще всего идут по кратчайшему пути) благодаря тому, что производители оборудования стали выделять специальную область памяти для хранения исполняемого кода в этом режиме. Код System Management Mode записывается в специально отведенную область памяти System Management Memory, недоступную для операционной системы и прикладных программ и имеет полный и неограниченный доступ абсолютно ко всем ресурсам системы. Для обслуживания событий, связанных с этим режимом, предусмотрено прерывание System Management Interrupt, которое не зависит от остальных прерываний и имеет наивысший приоритет. Для хранения адреса процедуры обработки аппаратного прерывания System Management Interrupt не используется ни один из векторов стандартной таблицы, адрес хранится в специальных регистрах процессора. После 2007 года еще несколько раз появлялась информация об атаках на гипервизоры, но авторы отмечали, что эти атаки требуют доступа к сильно защищенной области памяти System Management Memory и поэтому были опробованы на оборудовании, выпущенном ранее 2007 года. В настоящее время для осуществления подобных атак необходимо найти дополнительную уязвимость в работе процессора, которая позволит получить доступ к System Management Memory. А это является очень нетривиальной задачей, не правда ли? Осенью 2007 года работы по разработке нового поколения Blue Pill были поддержаны Phoenix Technologies. Phoenix, которая работает над новым решением в области виртуализации – HyperSpace, была заинтересована в использовании нового Blue Pill для тестирования различных идей и новых технологий виртуализации.

Какие выводы из этого можно сделать? В некоторых случаях виртуализация действительно снижает угрозы безопасности. Например, известно, что виртуальные коммутаторы нечувствительны к некоторым атакам, присущим физическим коммутаторам, к примеру – атакам подмены адресов. Однако виртуализация предоставляет и новые возможности, на сегодняшний день недоступные для физических инфраструктур, которые и могут быть использованы для усиления функций защиты. Известно две таких технологии, направленные на повышение уровня защищенности виртуальных сред: VMware VMSafe (VMware vSphere) и Xen Introspection Project (XenSource). Это технологии, позволяющие сторонним разработчикам получить доступ к гипервизору и фактически представляющие собой набор API-интерфейсов. При этом если о VMSafe написано и сказано очень много, то о Xen Introspection Project нам мало что известно (и это не удивительно, т.к. технология Xen Introspection Project – это фактически усилия только сообщества Xen.org). В 2008 году компания VMware анонсировала технологию VMsafe и партнерскую программу с производителями средств защиты информации. Появление этой технологии позволило VMware, не проходя самостоятельного пути по созданию комплекса средств защиты, привлечь к обеспечению информационной безопасности инфраструктур виртуализации, построенных на VMware vSphere, лидеров рынка информационной безопасности. Реализацию VMsafe мы смогли увидеть только в мае 2009 года, когда появился VMware vSphere. В декабре 2009 года на российском рынке уже были представлены решения, работающие с этой технологией: Reflex VMC, Check Point VPN-1 VE, Trend Micro Core Protection for Virtual Machines, McAfee VirusScan Enterprise for Offline Virtual Images, IBM Virtual Server Security, Stonegate IPS, HyTrust Appliance. Однако у этой технологии был один большой минус – отсутствие процедуры подписи кода, который работает с VMsafe. Другими словами, никакой процедуры проверки легальности виртуальной машины, которая работает с другими виртуальными машинами на уровне гипервизора, на тот момент не существовало. Например, злоумышленнику, разобравшись с API VMsafe, не составляло труда собрать свою виртуальную машину, которая будет способна работать с этим интерфейсом и выполнять действия, необходимые злоумышленнику. Спустя несколько лет программа была закрыта. Ей на смену пришли решения по безопасности, разработанные самой компанией VMware. Для партнеров остался доступным только интерфейс для работы с антивирусным программным обеспечением и защитой от вредоносных программ.

Первый российский продукт для защиты виртуализированных инфраструктур появился в середине 2009 года. Продукт называется vGate R2 и является разработкой компании «Код Безопасности». Компания делает ставку на решение по контролю доступа администраторов к инфраструктуре. Затем в связи с возрастающим интересом к продуктам по защите виртуализированных инфраструктур на российский рынок свои продукты вывели и западные компании, среди которых IBM, HP, Check Point и другие. В настоящее время на российском рынке представлено более десятка специализированных решений.

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

18 февраля 2013 года ФСТЭК России выпустила проект приказа № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных», в котором впервые в российской практике указала меры по защите информации, обрабатываемой в виртуальной среде. Сейчас этот приказ находится на регистрации в Министерстве юстиции России, поэтому пока финальная версия приказа нам недоступна. Однако в Интернете можно найти информацию о нескольких версиях проекта этого приказа и 10 мерах по защите информации, обрабатываемой в виртуальной среде, которые, по последней информации, в нем приведены. Итак, это:

  1. Идентификация и аутентификация субъектов доступа и объектов доступа в виртуализированной инфраструктуре, в том числе администраторов управления средствами виртуализации.
  2. Управление доступом субъектов доступа к объектам доступа в виртуализированной инфраструктуре, в том числе внутри виртуальных машин.
  3. Регистрация событий безопасности в виртуализированной инфраструктуре.
  4. Управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуализированной инфраструктуры, а также по периметру виртуализированной инфраструктуры.
  5. Доверенная загрузка серверов виртуализации, виртуальной машины (контейнера), серверов управления виртуализацией.
  6. Управление перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных.
  7. Контроль целостности виртуализированной инфраструктуры и ее конфигураций.
  8. Резервное копирование данных, резервирование технических средств, программного обеспечения виртуализированной инфраструктуры, а также каналов связи внутри виртуализированной инфраструктуры.
  9. Реализация и управление антивирусной защитой в виртуализированной инфраструктуре.
  10. Разбиение виртуализированной инфраструктуры на сегменты (сегментирование виртуализированной инфраструктуры) для обработки персональных данных отдельным пользователем и (или) группой пользователей.

В тексте проекта приказа мы несколько раз встречаем термин «контейнер». Что же такое контейнеры? Это способ виртуализации на уровне операционной системы, при котором все виртуальные среды разделяет одно ядро операционной системы. При этом количество одновременно запущенных контейнеров на одном физическом сервере может быть значительно больше, чем в случае с виртуализацией на основе гипервизора. Однако стоит отметить, что при использовании контейнеров возникают некоторые ограничения, например, невозможность одновременного запуска контейнеров Windows и Linux на одном сервере.

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

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

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


Другие статьи
Поделиться:
 
Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.