Защита систем виртуализации

Защита систем виртуализации

Защита систем виртуализации
Тем, кому наскучили штампы о реальном и виртуальном

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

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

В чем смысл?

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

Поскольку реализация системы защиты виртуальных решений на аппаратной базе связана с рядом сложностей технического характера, концепция «точки опоры», или «правильного старта», сводится некоторыми разработчиками к самому факту наличия аппаратного компонента, причем даже не строго определенного. Здесь СЗИ НСД – это отдельное средство защиты информации, а не основа защитного комплекса: предлагается при необходимости устанавливать какие-либо средства доверенной загрузки ОС и разграничения доступа на компьютеры, на которых развернуты те или иные компоненты защиты, если не предполагается защищать их организационными мерами. В чем смысл компонента безопасности, который можно и вовсе не устанавливать? В чем смысл аппаратной базы, если она никак не связана с тем, базой чего она называется?

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

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

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

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

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

Защищаемая инфраструктураи требования к защите

Рассмотрим особенности защиты виртуальной инфраструктуры (VMware vSphere 4.1, VMware vSphere 4.0 и VMware Infrastructure 3.5) по требованиям к защищенности информации в АС до класса 1В включительно.

Система защиты должна обеспечивать защищенность всех компонентов среды виртуализации: ESX-серверов и самих виртуальных машин, серверов управления vCenter, дополнительных серверов со службами VMware (например, VMware Consolidated Backup).

Управление системой защиты удобно осуществлять централизованно, например с сервера управления виртуальной инфраструктурой. Доступ к инструментам управления системой защиты должен быть только у администраторов безопасности, от администраторов виртуальной инфраструктуры эти инструменты должны быть скрыты.

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

Защита ESX-серверов

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

Доверенная загрузка ESX-серверов

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

Контроль целостности гипервизора, Service Console и модулей защиты

Во время старта сервера АМДЗ проверяет целостность BIOS и физического оборудования сервера. После этого должна начинаться проверка целостности файлов гипервизора, управляющей консоли Service Console и модулей защиты (эти модули устанавливаются в Service Console и предназначены для контроля запуска ВМ). В случае успеха обеих проверок ги-первизор и Service Console загружаются в штатном режиме вместе с уже проверенными дополнительными модулями защиты.

Защита виртуальных машин

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

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

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

Контроль целостности файлов в ВМ

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

Разграничение доступа

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

Защита элементов управления виртуальной инфраструктурой

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

Защита дополнительных серверов со службами VMware, например VMware Update Manager, осуществляется аналогично серверу с vCenter, если они установлены на физическом сервере, или аналогично ВМ, если эти службы установлены на виртуальной машине.

Модули управления системой защиты устанавливаются на сервер с vCenter, что позволяет управлять всей системой защиты централизованно и анализировать журналы со всех ESX-серверов.

Доверенная загрузка vCenter

Перед загрузкой ОС и vCenter АМДЗ производит идентификацию/аутентификацию администраторов и детально журна-лирует все попытки загрузки операционной системы и vCenter.

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

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

В vCenter необходимо производить дискреционное и/или мандатное разграничение доступа администраторов и процессов ко всем ресурсам. При этом для каждого администратора должна создаваться изолированная программная среда.

Строить воздушные замки или разрушать их?

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

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

Безопасность виртуальной инфраструктуры

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

Многие компании, в том числе и российские, уже сейчас внедряют технологии виртуализации серверов и настольных систем, сталкиваясь при этом с немалым количеством проблем. В то время как технически в виртуализации нет ничего сложного, и в перспективе затраты на ее внедрение полностью окупают себя в течение небольшого времени (один-два года), убедить руководителей компаний начать полномасштабный виртуализационный проект очень трудно. Хотя использование виртуальных машин сейчас очень «модно», организации видят в них большой источник проблем, который вызывает недоверие. Основными моментами, которые беспокоят компании при внедрении виртуализации, являются:

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

Помимо этих моментов, существуют еще несколько причин, заставляющих многие компании и домашних пользователей с осторожностью использовать платформы виртуализации, такие как лицензионные ограничения, совместимость ПО и оборудования и прочие. На данный же момент, безопасность виртуальных машин является ключевой проблемой в их использовании и находится в центре внимания ИТ-сообщества. К примеру, за 9 месяцев 2007 года в программном обеспечении VMware было найдено 22 уязвимости, что почти в полтора раза больше, чем за предыдущие два года в сумме. Платформа виртуализации состоит из множества компонентов (DHCP-сервер, NAT Device и прочие), каждый из которых становится потенциальной целью хакеров.

Подходы к безопасности виртуальных систем

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

Угрозы технологий виртуализации

Ниже будут приведены примеры новых видов угроз, которые несут собой технологии виртуализации. Нужно учитывать, что в цепочке объектов, нуждающихся в защите, появляется также платформа виртуализации, необходимо убедиться в ее соответствии современным стандартам безопасности, а также своевременно устанавливать на нее все необходимые обновления. Вендоры платформ крайне заинтересованы в повышении уровня безопасности своих продуктов и их сертификации, например, платформа VMware ESX Server на данный момент сертифицирована по уровню безопасности CCL2 (Common Criteria Level 2) и ведется работа по сертификации виртуальной инфраструктуры VI3 на соответствие уровню CCL4, а продукты компании XenSource уже соответствуют уровню CCL5.

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

Руткиты Blue Pill и SubVirt

Blue Pill (имя которого, кстати, взято из фильма «Матрица») представляет собой средство получения контроля над компьютером (руткит), которое основывается на технологиях виртуализации и нацелено на операционную систему Windows Vista. На данный момент Blue Pill использует технологию виртуализации AMD-V (бывшая Pacifica), которая присутствует во всех последних процессорах компании AMD, но не существует препятствий к его портированию на платформы Intel с технологией Intel VT (бывшая Vanderpool). Blue Pill был разработан Джоанной Рутковской (Joanna Rutkowska) и впервые продемонстрирован на Black Hat Briefings 3 августа 2006 года.

Механизм работы руткита выглядит следующим образом:

• вредоносный код проникает в целевую систему
• затем происходит незаметная виртуализация хостовой системы, которая превращается в гостевую на данном компьютере, а Blue Pill действует как гипервизор, при этом не требуется перезагрузка операционной системы
• все необходимые руткиту интерфейсы для взаимодействия с внешней средой «прячутся» за пределами этой системы, а ПО для обнаружения вторжений не может найти руткит, поскольку он расположен вне операционной системы

В начале 2007 года вокруг Blue Pill разгорелись ожесточенные споры, в которых одна группа исследователей доказывала, что его обнаружение возможно, а другая говорила о том, что эти техники не всегда точны и требуют специфического подхода вплоть до 50-процентной нагрузки на процессор. На данный момент разработчики Blue Pill говорят о том, что возможно лишь обнаружение используемых на компьютере технологий виртуализации, но не самого руткита. В свете того, что в ближайшее время значительно увеличится количество пользователей, применяющих виртуализацию, обнаружение руткита становится весьма проблематичным. В 2007 году Джоанна Рутковская и Александр Терешкин опубликовали исходный код Blue Pill, и теперь любой желающий может попробовать свои силы в написании вредоносной системы.

Компания Microsoft совместно с Мичиганским университетом (University of Michigan) в прошлом году также разработала руткит SubVirt, поражающий операционные системы Windows и Linux тем же способом, что и Blue Pill. В отличие от Blue Pill, этот руткит может быть более просто обнаружен, поскольку не может быть установлен «на лету» и вносит некоторые изменения в структуру диска, что делает возможным обнаружение руткита при проверке диска на другом компьютере. Также SubVirt эмулирует аппаратные компоненты, отличающиеся от реального «железа», что позволяет просто обнаружить виртуализацию.

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

Внутренние и внешние угрозы в виртуальной инфраструктуре

Несмотря на то, что в целом виртуальная машина в отношении ее поведения в пределах ИТ-инфраструктуры компании мало чем отличается от физического сервера, существуют несколько специфических особенностей платформ виртуализации, которые могут привести как к угрозе несанкционированного доступа извне, так и к инсайдерским (внутренним) атакам. Простая переносимость виртуальных систем на другие физические платформы и популярность использования виртуальных машин по модели SaaS (Software as a Service) приводят к тому, что критически важные системы со всеми конфиденциальными данными могут быть украдены путем копирования виртуальной машины на обычную флэш-карту за несколько минут. Далее эта виртуальная машина может использоваться злоумышленником на любом компьютере.

Помимо этого, виртуальная машина может использоваться для незаконного распространения информации, упакованной в готовую к использованию «коробку». Достаточно лишь запустить виртуальную машину и получить доступ к нелегальной информации или сервису. Многие, наверное, помнят виртуальную машину VMware под названием Melinda Gates c нелегальным KMS (Key Management Server) для Windows Vista, позволявшую производить незаконную активацию некоторых изданий Vista. Также компании Microsoft пришлось запретить виртуализацию изданий Vista Home и Home Premium по причине возможности нелегального распространения мультимедиа-контента в виртуальной машине.

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

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

Кроме того, особенности реализации внутреннего и внешнего сетевого взаимодействия платформами виртуализации часто приводят к тому, что создается угроза для большого количества систем при получении контроля над одной из виртуальных машин. Например, на платформах VMware ESX Server и VMware Server есть возможность создать виртуальный коммутатор (Virtual Switch), к которому присоединяются виртуальные сетевые адаптеры хостовой и гостевых систем. Однако в VMware Server эти коммутаторы работают как «хабы», что создает угрозу перехвата трафика с одной из взломанных машин, подключенных к коммутатору, сетевой адаптер которой работает в promiscuous mode (режим, когда сетевая карта принимает все входящие пакеты, а не только адресованные ей).

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

На платформе ESX Server по умолчанию виртуальный коммутатор работает как физический, у которого, к тому же, есть возможность настраивать режим promiscuous mode для групп портов, что очень полезно при использовании IDS (Intrusion Detection System) системы для защиты виртуальных машин в пределах сервера виртуализации. Эта IDS может быть также виртуальной машиной и распространяться как шаблон виртуальной машины, Virtual Appliance.

Внедренные платформы виртуализации и потенциальная опасность

За последние пару месяцев сразу две компании, VMware и XenSource, объявили о скором выпуске платформ виртуализации, которые будут поставляться вместе с физическими серверами и записываться во флэш-память или жесткий диск сервера (VMware ESX 3i и XenExpress OEM). Уже в следующем году компания Microsoft начнет поставки Windows Server 2008 со встроенным в нее гипервизором Viridian для поддержки виртуализации. Все это означает, что в скором времени технологии виртуализации будут занимать довольно большую нишу в сфере серверных систем и внимание хакеров к ним значительно повысится. Тем не менее, многие пользователи на этот момент не будут знать о том, как правильно защищать виртуальные системы. Это может породить большие финансовые потери для компаний, для которых необходим высокий уровень безопасности.

Например, в платформе VMware ESX 3i используется старая версия Open Source утилиты BusyBox, сочетающей в себе несколько программ для Unix-подобных ОС, которая была разработана Денисом Власенко для внедренных систем. Использование старой версии утилиты обусловлено лицензионными соображениями. Многие аналитики говорят о том, что VMware фактически доверяет безопасность платформы одному человеку.

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

Способы защиты виртуальной инфраструктуры

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

Все виртуальные системы, к которым может быть осуществлен доступ, не должны быть «unmanaged» и должны поддерживаться в соответствии с корпоративными стандартами безопасности. Также необходимо внимательно следить за развертыванием виртуальных машин на серверах компании и не позволять уязвимой системе работать в ее ИТ-среде. Для контроля этого фактора могут использоваться такие системы, как продукты семейства System Center компании Microsoft. Помимо этого, ниже приведен ряд рекомендаций для поддержания виртуальной инфраструктуры в безопасном состоянии:

1. Контролируйте защиту данных не только внутри виртуальных машин, но и сами образы виртуальных систем. Часто системные администраторы уделяют большое внимание защите файлов внутри гостевой системы, однако напрочь забывают о защите файлов сервера виртуализации. В свете того, что существуют переносные винчестеры емкостью до 1 ТБ, злоумышленник может записать на него целую виртуальную инфраструктуру с множеством связанных виртуальных машин, с которой он может разбираться уже дома.
2. Используйте специализированные решения для защиты серверов виртуализации. К сожалению, на данный момент их не так много, но в ближайшем времени они, несомненно, появятся. В качестве примера можно привести проект sHype компании IBM.
3. Для критически важных машин в пределах серверов виртуализации можно использовать системы обнаружения или предотвращения вторжений (Intrusion Detection/Prevention Systems, IDS/IPS). Работа этих систем зачастую завязана на физическое расположение компьютеров, что усложняет работу по защите виртуальной инфраструктуры ввиду легкой переносимости виртуальных машин на другое оборудование.
4. Для распространения конфиденциальной информации в виртуальных машинах используйте специализированные защищенные платформы виртуализации, например продукт VMware ACE. Они позволяют шифровать содержимое дисков виртуальных машин, защищая их паролем, и применять к ним различные политики безопасности. Продукт VMware ACE очень удобен для массового развертывания и управления парком защищенных виртуальных клиентских окружений. Схема развертывания пакетов виртуальных машин с помощью VMware ACE представлена ниже:

Заключение

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

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

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

Источник Источник Источник Источник http://lib.itsec.ru/articles2/Oborandteh/zashita-sistem-virtyalizacii
Источник Источник http://www.ixbt.com/cm/virtualization-security.shtml