Тема месяца

Подготовлено

Виртуализация

Успевают ли технологии безопасности за виртуализацией?

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

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

Больше компонентов – больше угроз

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

Количество уязвимостей увеличивается

Источник: IBM, 2009

Существуют вредоносные программы, которые позволяют взять полное управление над системой во время ее работы. Как пример можно привести руткиты SubVirt, Vitriol, BluePill. Часть из них использует новейшие технологии аппаратной виртуализации. А поскольку этот вредоносный код работает вне операционной системы, то нет никакой возможности обнаружить его средствами защиты самой ОС.

Реальные угрозы в виртуальной сети

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

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

Организационное деление сети

Источник: IBM, 2009

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

Установка обновлений не всегда возможна

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

Виртуальная машина – набор файлов

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

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

Политика безопасности не может полагаться на местоположение сервера

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

При использовании технологий Live Migration нужно представлять себе, что по пути из одного ЦОДа в другой сетевой трафик может быть под атакой «человек посередине». И если данные передаются в открытом виде, то злоумышленник может сделать с ними все что угодно, обойдя сложные системы защиты и контроля доступа.

Где ждать угрозы?

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

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

Иван Бобров:

Главное преимущество использования виртуализации – рост динамики бизнеса и сокращение временных затрат

На вопросы CNews ответил руководитель отдела продаж комплексных решений департамента по работе с крупными корпоративными заказчиками Microsoft Россия Иван Бобров.

CNews: Каковы в целом ваши ожидания относительно дальнейшего развития глобального рынка виртуализации и его российского сектора?

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

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

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

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

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

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

В чем смысл?

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

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

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

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

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

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

Каждое звено в этой цепочке контроля должно быть полноценным. Нет смысла контролировать гипервизор и при этом не контролировать средство его управления, 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 необходимо производить дискреционное и/или мандатное разграничение доступа администраторов и процессов ко всем ресурсам. При этом для каждого администратора должна создаваться изолированная программная среда.

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

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

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

Источник http://www.cnews.ru/reviews/free/virtualization/article/virt2.shtml
Источник Источник Источник Источник http://lib.itsec.ru/articles2/Oborandteh/zashita-sistem-virtyalizacii