что такое безопасность на основе виртуализации
Защита ресурсов системы безопасности на основе виртуализации
Безопасность на основе виртуализации (VBS) использует функции виртуализации оборудования для создания безопасной среды, в которой может размещаться ряд функций безопасности. Выполнение этих приложений безопасности внутри VBS обеспечивает значительно повышенную защиту от уязвимостей в операционной системе и предотвращает использование вредоносных эксплойтов, пытающихся отменить защиту.
VBS использует гипервизор Windows для создания этого виртуального безопасного режима, а также для обеспечения ограничений, которые защищают критически важные ресурсы системы и операционной системы или защищают активы безопасности, например учетные данные пользователя, прошедшего проверку подлинности. Благодаря повышению уровня защиты, предоставляемого VBS, даже если вредоносная программа получает доступ к ядру ОС, возможные эксплойты могут быть значительно ограничены и храниться, так как гипервизор может препятствовать выполнению кода или доступу к секретам платформы.
Дополнительные сведения о VBS см. в статье безопасность на основе виртуализации (VBS).
VBS изменяет модель доверия
хотя vbs значительно улучшает безопасность платформы, vbs также изменяет границы доверия на Windows компьютере. с помощью VBS Windows гипервизор управляет многими аспектами базового оборудования, которые обеспечивают базу данных для безопасности VBS secure енвиромнент. гипервизор должен предположить, что Windows ядро может стать скомпрометировано вредоносным кодом, и поэтому необходимо защитить ключевые ресурсы системы от работы с кодом, работающим в режиме ядра, так, чтобы компромизе активы безопасности.
Основные сведения о процессоре MSRs
Одна область жизненно важных системных ресурсов, которую низкоуровневая оболочка должна защищать от вредоносного использования, является регистром для конкретной модели процессора или MSRs. Современные процессоры поддерживают большое количество функций MSRs, многие из которых управляют ключевыми аспектами поведения процессора. MSRs может быть прочитана из кода режима ядра или записана в него (то есть CPL0). Изменение параметров, контролируемых MSRs, может позволить вредоносному коду в режиме ядра изменить поведение системы и позволить злоумышленнику получить контроль, нарушая безопасность. Кроме того, многие файлы MSRs содержат данные о работе системы, такие как трассировка или диагностические данные, которые также можно использовать для отображения или вычисления ресурсов безопасности. Таким образом, гипервизор должен обнаруживать и защищаться от несанкционированного использования любых систем MSRs, которые могут нарушить безопасность VBS.
Доступ к MSRs осуществляется через индекс, который является уникальным идентификатором MSR. Исторически многие MSRs были установлены как архитектурные. то есть их присутствие и функция остаются согласованными по архитектуре для нескольких поколений процессоров. В этом случае известно, что известный MSR с документированным индексом MSR и определением можно использовать для управления известным опубликованным набором возможностей. Однако существует также пакет MSRs, который зависит от процессоров, и бывают случаи, когда индексы MSR были переназначены с течением времени, которые переопределяются для ссылки на новые наборы элементов управления. Это очень проблематично для программного обеспечения на уровне системы, так как трудно кодировать и поддерживать знания об этих элементах управления в широком доступном коммерческом программном обеспечении.
Защита доступа к MSRs
Чтобы обеспечить надежную платформу безопасности, необходимо защитить MSRs от неправильного использования вредоносного кода режима ядра. Для этого гипервизор отслеживает и контролирует доступ ко всем файлам MSRs. Гипервизор поддерживает список известных индиЦиес MSR и позволяет только коду в режиме ядра получить доступ к MSRs или конкретным битам в MSRs, которые считаются приемлемыми и признанными надежными. Гипервизор блокирует доступ к любому MSR, который неизвестен гипервизору, или любому MSR, который известен с помощью опубликованного в нем определения, чтобы представлять угрозу безопасности. В некоторых случаях может быть разрешен частичный доступ.
когда низкоуровневая оболочка блокирует доступ к MSR, она регистрирует событие в журнале Windows системы в Просмотр событий, указывая сведения о предпринятом доступе.
Учитывая большое количество функций, контролируемых MSRs, невозможно предсказать побочные эффекты, препятствующие доступу MSR к программному обеспечению, которое его инициировало. Хорошо написанное программное обеспечение должно правильно обработать ошибки и случаи сбоев, однако это не всегда так.
Просмотр событий доступа к MSR
Гипервизор блокирует доступ к определенному пакету MSRs только при включении и запуске VBS. чтобы определить, блокирует ли гипервизор доступ к MSR, просмотрите журнал Windows системного журнала для события с идентификатором 12550 из Microsoft-Windows-Hyper-V-гипервизора. Сведения о записи журнала событий будут содержать следующие сведения:
Идентификатор: 12550 Описание: Hyper-V обнаружен доступ к ограниченному MSR Дополнительно
Поддерживаемые версии Windows
поддержка Windows безопасности на основе виртуализация включена в версии Windows, начиная с Windows 10 и Windows Server 2016.
Управление приложениями в Защитнике Windows и защита целостности кода на основе виртуализации
Относится к:
Windows 10 включает набор технологий оборудования и ОС, которые при совместной настройке позволяют предприятиям «заблокировать» Windows 10, чтобы они вели себя как мобильные устройства. В этой конфигурации Защитник Windows application Control (WDAC) используется для ограничения устройств для запуска только утвержденных приложений, в то время как ОС закалена при атаках памяти ядра с помощью целостности кода с защитой гипервизора (HVCI).
Политики WDAC и HVCI — это мощные средства защиты, которые можно использовать отдельно. Однако, когда эти две технологии настроены для совместной работы, они представляют сильную возможность защиты для Windows 10 устройств.
Использование WDAC для ограничения устройств только авторизованных приложений имеет эти преимущества перед другими решениями:
Почему мы больше не используем бренд Device Guard
Когда мы изначально продвигали device Guard, мы делали это с определенными обещаниями безопасности. Несмотря на отсутствие прямых зависимостей между WDAC и HVCI, мы намеренно фокусировались на обсуждении состояния блокировки, достигнутого при их совместном использовании. Однако, так как HVCI опирается на Windows на основе виртуализации, он имеет требования к совместимости драйвера оборудования, прошивки и драйвера ядра, которые некоторые старые системы не могут соответствовать. Это в заблуждение многих людей, предполагая, что если системы не могут использовать HVCI, они не могут использовать WDAC либо.
У WDAC нет определенных требований к оборудованию или программному обеспечению, кроме Windows 10, что означает, что клиентам было отказано в преимуществах этой мощной возможности управления приложениями из-за путаницы в устройстве Guard.
С момента первоначального выпуска Windows 10, мир стал свидетелем многочисленных атак взлома и вредоносных программ, в которых только управление приложениями могло бы полностью предотвратить атаку. В этой связи мы сейчас обсуждаем и заявляем WDAC как независимую технологию в нашем стеке безопасности и дали ему свое имя: Защитник Windows Application Control. Мы надеемся, что это изменение поможет нам лучше общаться с вариантами принятия управления приложениями в ваших организациях.
Device Guard: Что это такое и как включить или отключить
К примеру, если хакер взломал и получил доступ к Windows 10, то он мог получить и доступ к хэшу, который используется для шифрования учетных записей, так как хэш храниться в локальной ОЗУ без защиты. В Credential Guard хэш храниться в виртуальном контейнере, и даже, если система будет скомпрометирована, то хакер не получит доступ к этому хэшу.
Ограничение на использование Device Guard
Как включить и отключить Device Guard
В групповых политиках перейдите «Конфигурация компьютера» > «Административные шаблоны» > «Система» > «Device Guard» > справа выберите «Включить средство обеспечения безопасности на основе виртуализации«.
Ошибка несовместимости с Credential Guard сторонних виртуальных машин
Иногда, пользователи могут видеть ошибку «VMware Workstation и устройства Device/Credential Guard несовместимы. VMware Workstation можно запустить после отключения Device/Credential Guard» при использовании сторонних виртуальных машин как VirtualBox или VMware Workstation.
Способ 1. В этом случае нужно отключить несколько компонентов как Aplication Guard, Hyper-V и песочница Windows. Также, посмотрите не включен ли Credential Guard в групповых политиках, указанном выше способом.
Способ 2. Если выше способ не помог и виртуальные машины выдают ошибку на несовместимость Credential Guard, то откройте редактор реестра и перейдите по пути:
Если после перезапуска Windows, ошибка появляется, то запустите командную строку от имени администратора и введите:
Если хотите вернуть команду по умолчанию, то введите bcdedit /set hypervisorlaunchtype auto
Безопасность Виртуализации. Часть 1
Перевод статьи «Virtualization Security» за авторством Terry Komperda.
За короткое время виртуализация оказала огромное влияние на сферу IT и сетевые технологии, она уже поспособствовала огромной экономии затрат и окупаемости вложений для дата-центров, предприятий и Облака. Что кажется менее значительным и сильно отстает от реальности — это понимание виртуализации и виртуализированных сред с точки зрения безопасности. Некоторые люди считают, что виртуализация является более безопасной, чем традиционные среды, так как они слышали об изоляция между виртуальными машинами (ВМ) и потому что они раньше не слышали о каких-либо успешных атаках на гипервизоры. Другие считают, что новые виртуальные среды нуждаются в безопасности так же, как традиционные физические среды, поэтому применяют тот же многолетний подход к безопасности. Наиболее важным фактором является то, что новая среда более сложная. Виртуальные подходы, добавленные к уже существующим сетям, создают новую сеть, которая требует иного подхода к безопасности. Помимо обычных мер следует применять и специальные меры безопасности для виртуализации. В этом документе мы рассмотрим различия, проблемы, трудности, риски, вызванные применением виртуализации, а также предоставим дельные рекомендации и практические советы, чтобы убедиться, что после применения виртуализации сеть останется такой же защищенной.
Виртуализация развивается и планирует задержаться здесь надолго. Хотя ее концепция известна уже более пятидесяти лет, эта технология будет по-прежнему расти и совершенствоваться в сферах, существующих повсеместно и планирующих развивать себя и дальше. Более того, половина всех серверов сегодня работают на Виртуальных Машинах. IDC предсказывает, что 70% всех рабочих нагрузок будет работать и на ВМ к 2014 году. Что действительно должно идти в ногу с технологическим прогрессом из-за широкомасштабного применения — это обеспечение безопасности компонентов виртуализации и виртуальных сред. Давайте рассмотрим некоторые выгоды в плане безопасности, существующие благодаря использованию виртуализации.
3. ПРЕИМУЩЕСТВА В СФЕРЕ БЕЗОПАСНОСТИ ПРИ ПРИМЕНЕНИИ ВИРТУАЛИЗАЦИИ
4. ПРОБЛЕМЫ И РИСКИ В ОБЛАСТИ БЕЗОПАСНОСТИ ПРИ ИСПОЛЬЗОВАНИИ ВИРТУАЛИЗАЦИИ
Теперь, когда мы познакомились с плюсами виртуализации, можно обратить внимание на некоторые из проблем и рисков.
Несмотря на множество проблем, описанных выше, не стоит считать виртуализацию заведомо небезопасной — все зависит от развертывания и примененных мер безопасности. Слабая политика безопасности, а также отсутствие обучения, могут стать куда более веской причиной возникновения проблем и уязвимостей, что в свою очередь приведет к большому риску. Теперь, когда мы знаем о проблемах с безопасностью при использовании виртуализации, самое время взглянуть на типовые атаки.
Ниже приведены некоторые типы атак, типичные для виртуализации:
5.1 Отказ от Обслуживания (DoS)
Успешная DoS-атака может стать причиной выключения гипервизора. Это может привести к возможности добавить лазейку для доступа к ВМ в обход гипервизора.
5.2 Неконтролируемое перемещение между ВМ
Если в гипервизоре образуется дыра в безопасности и ее находят, пользователь, вошедший на ВМ, может перепрыгнуть на другую ВМ и получить доступ к хранящейся на ней информации.
5.3 Перехват трафика хоста
Уязвимости на гипервизоре позволяют отслеживать системные вызовы, файлы подкачки и следить за памятью и активностью дисков.
6. ПРИМЕНЕНИЕ ТРАДИЦИОННЫХ ПОДХОДОВ К БЕЗОПАСНОСТИ ФИЗИЧЕСКИХ СРЕД К ВИРТУАЛИЗАЦИИ
Многие из проблем и атак, с которыми можно столкнуться при виртуализации, можно решить путем использования уже существующих сотрудников, процессов и технологий. Но, что нельзя защитить с помощью имеющихся решений — это виртуальные матрицы, состоящие из гипервизоров, систем управления и виртуальных свичей. Ниже приведены некоторые традиционные подходы к виртуализации и связанные с ними недостатки:
6.1 Межсетевые экраны
Некоторые IT группы отправляют трафик между ВМ на стандартные межсетевые экраны, которые будут проверять трафик и отправлять его обратно на виртуальные машины. Традиционные межсетевые экраны были созданы до виртуализации и устанавливались в дата центрах и на предприятиях, и, следовательно, они не созданы с учетом виртуальной инфраструктуры и связанных с ней систем управления. Это может привести к установке вручную и администрированию, которое затем может привести к ошибкам. Стандартные межсетевые экраны также не обеспечивают должную безопасность при перемещении ВМ.
6.2 Обнаружение проникновений на основе сети/Системы предотвращения вторжений
Эти устройства не работают, когда на хосте находится несколько виртуальных машин. Это главным образом происходит из-за того, что системы IDS/IPS не могу контролировать трафик между виртуальными машинами. Также они не могут получить доступ к любой информации при переносе приложений.
6.3 Ограничение числа ВМ на хост/Назначение на физические NIC
Такой подход не только ограничивает число виртуальных машин на хосте, но также назначает физический сетевой адаптер для каждой виртуальной машины. Хотя это и может стать безопасным подходом и имеет хорошие намерения безопасности, такой подход не позволяет компании получить все выгоды и окупаемость инвестиций от технологии виртуализации.
6.4 Сети VLAN
Сети VLAN широко используются: неважно идет ли речь в невиртуализированных средах или о средах с хорошей степенью виртуализации. Проблема здесь заключается в том, что количество VLAN растет, становится все сложнее управлять сложностями, связанными с доступом к контрольным таблицам, а также управлять вопросами совместимости политики сетевой безопасности между невиртуальными и виртуальными аспектами окружающей среды.
6.5 Агентные антивирусные подходы
Это влечет за собой загрузку полной копии антивирусного ПО на каждой ВМ. Такой подход может обеспечить хорошую защиту, но станет причиной огромных затрат на все копии антивирусного ПО для всех виртуальных машин в среде. Это полнофункциональное ПО может также негативно влиять на память, хранение и активность процессора, поскольку повышает использование оборудования, поэтому ведет к уменьшению производительности.
Несмотря на указанные выше недостатки применения традиционной модели безопасности, 60% респондентов указали, что они пользуются традиционными решениями для обеспечения безопасности и защиты виртуальных сред. Виртуальные среды динамичных и быстро меняются. Традиционным подходам будет сложно в одиночку со всем справиться, перемещаться и изменяться должным образом. Другой подход состоит в том, чтобы сохранить хорошие аспекты текущего подхода к безопасности, и в то же время посмотреть на следующие советы и рекомендации для виртуализации.
Безопасность виртуальной инфраструктуры
Виртуализация принесла в мир настольных компьютеров и серверных систем множество новых и перспективных возможностей, которые были с энтузиазмом восприняты большинством пользователей. Технологии виртуализации представляют собой целую концепцию, существенно изменяющую подход к ИТ-инфраструктуре и позволяющую увеличить ее эффективность и гибкость за счет одновременного запуска нескольких виртуальных систем на одной физической. На данный момент виртуализация применяется на самых различных уровнях абстракции программных и аппаратных систем, начиная от виртуализации приложений и заканчивая виртуализацией систем хранения данных (СХД).
Помимо этих моментов, существуют еще несколько причин, заставляющих многие компании и домашних пользователей с осторожностью использовать платформы виртуализации, такие как лицензионные ограничения, совместимость ПО и оборудования и прочие. На данный же момент, безопасность виртуальных машин является ключевой проблемой в их использовании и находится в центре внимания ИТ-сообщества. К примеру, за 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 года.
В начале 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 атак, основанных на только что найденных уязвимостях, от которых пока не выпущено средство защиты.
Способы защиты виртуальной инфраструктуры
При использовании парка виртуальных машин в пределах инфраструктуры компании необходима точно такая же их защита, как и физических серверов. Все традиционные меры и политики безопасности, применимые к ним, требуется использовать и в виртуальной инфраструктуре. Кроме того, поскольку сервер с платформой виртуализации является наилучшей точкой для получения доступа злоумышленников к целевым системам в виртуальных машинах, нужно уделить особенное внимание его защите и обновлениям.
Заключение
В последнее время безопасность является одним из ключевых факторов при принятии решения об использовании технологий виртуализации. В условиях необходимости защиты конфиденциальной информации виртуальные машины требуют повышенного внимания, хотя они и, напротив, могут использоваться для обеспечения безопасности (например, для изоляции критически важных систем друг от друга). В то же время, виртуализация сама по себе, как еще не опробованная технология, таит в себе множество опасностей. Как было показано, вредоносное ПО, использующее виртуализацию, может в ближайшем будущем являться угрозой не только для организаций, но и для конечных пользователей. Поэтому при использовании виртуализации необходимо грамотно спланировать стратегию защиты виртуальной инфраструктуры.
Простая развертываемость виртуальных систем требует постоянного контроля, поскольку «забытые» и необновляемые системы могут являться точкой проникновения злоумышленников во внутреннюю сеть компании. К тому же, нельзя забывать об инсайдерских угрозах — необходимо правильно разграничивать права доступа персонала к информационным ресурсам, содержащих виртуальные системы. В больших масштабах нужно использовать специализированное ПО для контроля за ИТ-инфраструктурой и средства обнаружения вторжений.
Большое количество уязвимостей, найденных за последнее время в платформах виртуализации, говорит о том, что внимание хакеров к виртуальным системам в дальнейшем будет только расти. Поэтому, безусловно, необходимо тщательно следить за обновлениями платформ, точно так же, как и за обновлениями операционных систем.