![](https://habrastorage.org/storage2/93f/da8/7c1/93fda87c1fd8c078e6062e1ff673d1fd.jpg)
На фоне общей тенденции сегодняшней ИТ-индустрии перехода к виртуализированной инфраструктуре и облачным вычислениям, перед предприятиями остро встает вопрос о безопасности такого перехода. Основными причинами некоторой неопределенности в этом вопросе для российских ИТ-специалистов и специалистов по безопасности – это небольшой опыт работы с данными технологиями и, главное, отсутствие руководящих документов и стандартов уполномоченных государственных органов.
Сразу оговорюсь: российский стандарт разрабатывается. Он будет именоваться «Защита информации. Требования по защите информации в информационных системах, построенных с использованием технологии виртуализации. Общие положения». Проведение публичного обсуждения первой редакции указанного национального стандарта планируется провести в период с мая по июнь 2013 г. Ясно, что ждать его утверждения в ближайший год явно не приходится. В связи с этим, особую важность приобретают иностранные рекомендации, где опыт внедрения решений по виртуализации значительно шире.
Документ NIST SP 800-125 содержит наиболее общие рекомендации, на основе которых организациям можно и нужно разрабатывать свои политики безопасности.
Ввиду громоздкости документа для одного поста, здесь приведу только общие определения из «введения» и раздел «обзор безопасности виртуализации». Для желающих, ссылка на полную версию в формате docx.
Под катом много букв.
1 Введение
Виртуализация — симулирование программного обеспечения (ПО) и/или аппаратных средств, поверх которых работает другое ПО. Эту симулируемую среду называют виртуальной машиной (ВМ). Есть много форм виртуализации, отличающихся, прежде всего, вычислительной архитектурой. Эта работа фокусируется на форме виртуализации, известной как полная виртуализация. При полной виртуализации одна ОС или более и приложения, которые они содержат, запущены поверх виртуальных аппаратных средств. Каждый экземпляр ОС и её приложения, запущенные в отдельной ВМ, называется гостевой операционной системой. Гостевые ОС на хосте управляются гипервизором, который контролирует поток команд между гостевыми ОС и физическими аппаратными средствами, такими как ЦПУ, дисковое хранилище, память и сетевые адаптеры. Гипервизор может разделять ресурсы системы и изолировать гостевые ОС так, чтобы у каждой был доступ только к её собственным ресурсам, а также, возможно, доступ к общим ресурсам, таким как файлы на хостовой ОС. Некоторые гипервизоры работают поверх другой ОС, которая называется операционной системой хоста или хостовой ОС.
Есть две формы реализации полной виртуализации. Рисунок сравнивает их обобщенную архитектуру.
![](https://habrastorage.org/storage2/e6f/dae/94d/e6fdae94d94dbf8098a2b5a0c772c6e1.jpg)
В виртуализации «на железе» (bare metal), также известной как собственная или нативная (native) виртуализация, гипервизор работает непосредственно на используемом оборудовании без хостовой ОС. В другой форме полной виртуализации, известной как размещенная или хостированная (hosted) виртуализация, гипервизор работает поверх хостовой ОС;
2 Обзор безопасности виртуализации
Перенос вычислительных ресурсов в виртуализированную среду, на самом деле, имеет незначительное влияние на уязвимость ресурсов (на риски). Виртуализация может смягчить последствия успешной атаки, однако также, виртуализация может предоставить дополнительные векторы атак, что в целом увеличит вероятность проведения такой успешной атаки. Многие возможности виртуализации предлагают как выгоды, так и недостатки со стороны безопасности.
Этот раздел описывает последствия использования виртуализации для безопасности. В разделе 2.1 обсуждается изоляция гостевых ОС друг от друга, нижележащего гипервизора и хостовой ОС. Раздел 2.2 разъясняет цели и механизмы мониторинга гостевых ОС. Раздел 2.3 обсуждает управление образами и снимками.
2.1 Изоляция гостевых ОС
Гипервизор отвечает за выделение физических ресурсов (ЦПУ, память, хранилище) гостевым ОС. Он разделяет эти ресурсы, так что каждая гостевая ОС может иметь доступ только к своим ресурсам и не может посягать на ресурсы других ОС или любые другие ресурсы, не задействованные в виртуализации. Это предотвращает неавторизованный доступ к ресурсам, а также помогает предотвратить распространение вредоносного ПО от одной гостевой ОС до другой по средствам заражения файлов гостевой ОС или размещения вредоносного кода в области памяти гостевой ОС. Кроме того, разделение ресурсов может также уменьшить угрозу отказа в обслуживании (DoS), вызванную избыточным потреблением ресурсов разными гостевыми ОС над одним гипервизором.
Ресурсы могут быть разделены физически либо логически. При физическом разделении (partitioning), гипервизор назначает отдельные физические ресурсы каждой гостевой ОС, такие как разделы жестких дисков, дисковые драйверы, сетевые карты. Логическое разделение может представлять ресурсы одного хоста или нескольких как набор (pool) ресурсов одной категории безопасности, что позволяет множеству гостевых ОС разделять (share) одни физические ресурсы (например, процессоры) при посредничестве гипервизора. Физическое разделение налагает строгое ограничение на ресурсы каждой гостевой ОС, и неиспользуемые ресурсы одной гостевой ОС не могут быть использованы другой. Тем не менее, физическое разделение ресурсов обеспечивает более надежную защиту и более высокую производительность, чем логическое. Многие системы виртуализации снабжены обоими механизмами разделения.
Разделение ресурсов – важная составляющая изоляции гостевых ОС. Также изоляция включает ограничение коммуникаций гостевых ОС и доступ, который имеет каждая гостевая ОС к другой, к гипервизору и хостовой ОС (если она есть). Теоретически, гипервизоры могут обеспечить уровень логической изоляции сравнимый с физической, принимая участие во всех коммуникациях, имея полный контроль над каждой гостевой ОС. Если необходимо, гипервизоры могут разрешить некоторые взаимодействия гостевых ОС, например, позволить двум виртуальным машинам иметь общие файлы. Гипервизоры могут также динамически менять степень изоляции для каждой гостевой ОС, если необходимо, например, разрешая/запрещая сетевое взаимодействие в определенное время. Изоляция каждой гостевой ОС от других и ограничение доступных ресурсов и привилегий известна как помещение в песочницу.
Еще одно преимущество изоляции гостевых ОС друг от друга и от нижележащего гипервизора – это затруднение проведения атак по техническим каналам. Эти атаки используют физические свойства оборудования раскрывать информацию об использовании ЦПУ, доступе к памяти и другим ресурсам. Обычно, целью таких атак является вскрытие криптографических ключей, при этом требуется прямой физический доступ к хосту.
Атакующие могут предпринять попытку выйти за рамки скомпрометированной гостевой ОС, чтобы получить доступ к другим гостевым ОС, гипервизору или хостовой ОС. Если атакующий успешно проделывает это и получает доступ к гипервизору, то он получает доступ ко всем гостевым ОС гипервизора. Таким образом, гипервизор становится единой точкой отказа в плане безопасности (single point of security failure) для всех гостевых ОС. Один сбой в гипервизоре подвергает все гостевые ОС большому риску.
Гостевые ОС обычно не до конца изолированы друг от друга и от хостовой ОС, что позволяет некоторый функционал, не являющийся необходимым. К примеру, множество решений хостовой виртуализации обеспечивают механизмы, позволяющие гостевым ОС иметь доступ к файлам, директориям, буферу обмена и другим ресурсам хостовой ОС или других гостевых ОС. Эти коммуникационные механизмы могут послужить вектором атаки, распространяя вредоносное ПО или позволяя злоумышленнику получить доступ к частным ресурсам. Bare metal виртуализация не дает таких возможностей.
2.2 Мониторинг гостевых ОС
Гипервизор в любой момент времени имеет всю информацию о текущем состоянии каждой гостевой ОС. А раз так, гипервизор имеет возможность вести мониторинг каждой запущенной гостевой ОС, что называется интроспекцией (introspection). Интроспекция дает возможности аудита, недоступные в любом другом случае. Аудиту может быть подвергнут сетевой трафик, память, процессы и другие элементы гостевых ОС. Во многих продуктах гипервизоры могут объединять свои функции безопасности с внешними контролирующими элементами и обеспечивать их информацией, полученной с помощью интроспекции. Примеры: межсетевое экранирование, предотвращение вторжений и контроль доступа. Многие продукты также позволяют усилить политику безопасности с помощью защиты, основанной на гипервизоре, давая возможность не нарушать политику при миграции гостевых ОС с одного физического хоста на другой.
Мониторинг сетевого трафика особенно важен, когда в сеть объединены две гостевые ОС на одном хосте, либо гостевая ОС объединена с хостовой ОС. В отличие от традиционной ситуации, такой трафик не пройдет через сетевые устройства обеспечения безопасности, поэтому защита в рамках хоста должна быть задействована хотя бы для мониторинга трафика.
2.3 Управление образами и снимками
Создание образов (images) и снимков (snapshots) гостевых машин не имеет отношения к уязвимостям в гостевых ОС, сервисах и приложениях. Тем не менее, образы и снимки некоторыми способами влияют на безопасность, местами отрицательно, местами положительно.
Отметим, что одна из наибольших проблем безопасности, связанных с образами и снимками – это то, что они содержат важные данные (такие как пароли, персональные данные и т.п.) так же, как и любой жесткий диск. Так как образы или снимки легче перемещать, нежели физические носители, становится важным думать о безопасности информации, которую они содержат. Снимки подвержены большему количеству рисков, чем образы, потому что снимки помимо всего прочего содержат состояние RAM-памяти в тот момент времени, когда снимок был сделан, что может открыть доступ злоумышленнику даже к той информации, которая не хранится в постоянной памяти.
По мере того как растет использование серверной виртуализации и/или виртуализации рабочего места в организации, усложняется и управление образами. Некоторые продукты предлагают решения, способные проверять хранимые образы и обновлять их, если нужно, например, применяя патчи или внося конфигурационные изменения, но другие продукты не дают возможностей применять обновления другим способом, нежели запуская каждый нужный образ. Для таких продуктов, чем дольше образ не запускается и хранится, тем больше уязвимостей он будет содержать, когда будет запущен. Отслеживание состояния образов может стать значительной проблемой, особенно если пользователи и администраторы могут создавать их собственные образы. Такие образы могут быть не защищены должным образом, что, естественно, повышает риск компрометации.
Другая возможная проблема, связанная с ростом использования виртуализации, а конкретнее, с возрастанием числа образов – так называемое разрастание (sprawl). Нет ничего сложного, создать новый образ – обычно, это дело нескольких минут, не учитывая соображения безопасности – что ведет к созданию и запуску ненужных образов. Каждый дополнительный запущенный образ – новая потенциальная точка проникновения в систему для злоумышленника. Поэтому организации должны минимизировать создание, хранение и использование образов, в которых нет необходимости. Организации должны принять во внимание применение процессов, управляющих созданием, защитой, распространением, хранением, использованием, изъятием и уничтожением шаблонных образов, особенно для виртуализации серверов. Такое же внимание должно получить управление снимками. В некоторых случаях организации имеют политики, не позволяющие хранение снимков из-за риска распространения в системе вредоносного ПО, которое может храниться в снимке и позже быть загружено.
Файлы образов могут быть подвергнуты мониторингу для обнаружения неавторизованных изменений в них. Это может быть обеспечено вычислением криптографической контрольной суммы (или хэша) для каждого хранящегося файла и её последующей периодической проверки, а также определением инициатора любых изменений. Файлы образов также могут сканироваться на наличие руткитов (rootkit) и другого вредоносного ПО, которое при запуске скрывает свое существование от антивирусного ПО гостевой ОС.
В некоторых системах виртуализации гостевые ОС могут быть перемещены с одного компьютера на другой, когда необходимо. Например, когда хост нужно перезагрузить или выключить, когда хост частично вышел из строя или когда обнаруживается атака на гипервизор или хостовую ОС, либо когда такие атаки ожидаются. При серверной виртуализации гипервизор может быть способен перемещать свои гостевые ОС на другие хостовые компьютеры автоматически; в некоторых системах это может даже не требовать выключения или приостановки гостевых ОС. Что касается виртуализации рабочего места, то здесь обычно требуется вмешательство администратора. SAN (storage network), обеспечивающая такую миграцию или транспортный канал (для неё), должна быть полностью аутентифицирована и зашифрована для сохранения целостности ВМ и предотвращения утечек информации.
В случае виртуализации, охватывающей множество физических серверов, миграция гостевых ОС поддерживает балансировку нагрузки, благодаря возможности динамического контроля на любом промежутке времени за тем, на каком хосте какой виртуализированный сервер запущен. То есть, если конкретный хост сильно загружен, практически до полного истощения физических ресурсов, одна или несколько его гостевых ОС должны быть перенесены на менее загруженные машины. Этот механизм предотвращает проблему отказа в обслуживании, но чаще всего он используется просто для улучшения характеристик работы гостевых ОС.
Потенциальным недостатком использования миграции гостевых ОС является то, что в случае, если гостевая ОС скомпрометирована или содержит вредоносный код, но эта вредоносная активность еще не была обнаружена, то при миграции этой гостевой системы она может скомпрометировать другой хост. Та же проблема присутствует при конвертации скомпрометированной физической системы в виртуальную машину.
Заключение (от переводчика)
Для тех, кто не желает читать полную 25-страничную версию перевода, переводчик берет на себя ответственность сформулировать некое резюме ко всему документу.
Виртуализация — дополнительный технический уровень, предоставляющий на ряду с полезными для владельца функциями дополнительные векторы атаки для злоумышленника.
Гипервизор — единая точка отказа виртуальной инфраструктуры, главная проблема её защиты. Подавляющее большинство атак направлено именно на него.
Рекомендации по защите даются самые банальные:
- Отключайте ненужные функции где бы то ни было;
- Устанавливайте последние обновления и патчи;
- Синхронизируйтесь с доверенным сервером времени;
- Ограничьте доступ и защитите управляющие каналы (отдельная управляющая сеть либо шифрование, либо и то, и другое);
- Тщательный мониторинг;
- Тщательное планирование при развертывании.
Для того, чтобы получить более конкретные руководства, вплоть до описания галочек в интерфейсе, необходимо обращаться к рекомендациям и check-листам производителей ПО виртуализации: VMware, Microsoft, Citrix и др.