Виртуальные машины снижают уязвимость системы

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Евелев Юрий Евгеньевич, Чернокнижный Геннадий Михайлович

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

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Евелев Юрий Евгеньевич, Чернокнижный Геннадий Михайлович

ON THE VULNERABILITY OF VIRTUAL MACHINE MONITORS

The article is devoted to virtualization problems security. Vulnerabilities of well-known virtual machine monitors are shown. Examples of exploits are given. VMsafe technology and its abilities to increase the protection system effectiveness in view of security vendors are considered

Текст научной работы на тему «Уязвимости мониторов виртуальных машин»

Контекст и идентификация понятий

С информативностью понятий связана также проблема их идентификации в базах данных и знаний. В работе [4] показано, что визуализация знаний возможна только в определенном контексте. Точно так же любой текст или человеческий диалог всегда строится с учетом контекста, благодаря чему достигается компактность при сохранении точности передаваемого смысла высказываний. В естественном языке говорящий (или пишущий) должен всегда быть уверен в том, что слушатель или читатель правильно понимает контекст, для чего делаются соответствующие вводные предложения в начале текста или диалога. Если же требуется использовать один и тот же объект в разных контекстах, то к идентификатору объекта добавляется идентификатор контекста. В рассмотренном выше примере студенческого сообщества, если высказывание делается в контексте группы, то для идентификации экземпляра достаточно фамилии; в контекстах более высокого уровня к фамилии добавляется номер курса, факультета, университета и т.д.

В последнее время идет активный процесс формализации знаний в стандарте Глобальной семантической сети (Semantic Web, SW). Для каждой предметной области в SW формируются онтологии, т.е. документы, подготовленные на OWL или других языках и содержащие описание классов объектов, отношений между ними и свойств. С использованием онтологий создаются документы, содержащие факты, относящиеся к заданной предметной области. Информативность таких документов можно оценивать с применением данного подхода. В частности, может быть разработан модуль в среде популярного редактора онтологий Protégé (http://protege.stanford.edu), вычисляющий информативность понятий с целью контроля создаваемых онтологий и выявления ошибок. Еще одно применение данного подхода возможно при создании и поддержке крупных баз данных, в которых иногда происходят нарушения целостности данных вследствие переполнения индексов. Разрядность индекса не должна быть меньше информативно -сти соответствующей ему сущности.

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

1. Рассел С., Норвиг П. Искусственный интеллект: Современный подход. – 2-е изд. Пер. с англ. – М.: Вильямс, 2006. – 1408 с.

2. Богданов И. В. Учебная информация и единицы ее измерения // Труды СГУ. – Вып. 44. -Гуманитарные науки. Психология и социология образования. – М.: Изд-во СГУ, 2002.

3. Бессмертный И.А. Семантическая паутина и искусственный интеллект // Научно-технический вестник СПбГУ ИТМО. – 2009. – № 6(64). – С. 77-82.

4. Bessmertny I.A. Knowledge Visualization Based on Semantic Network // Programming and Computer Software. – 2010. – V. 36. – № 4. – Р. 197-204.

Бессмертный Игорь Александрович – Санкт-Петербургский государственный университет информационных

технологий, механики и оптики, кандидат технических наук, доцент, igor_bessmertny@hotmail.com

УЯЗВИМОСТИ МОНИТОРОВ ВИРТУАЛЬНЫХ МАШИН Ю.Е. Евелев, Г.М. Чернокнижный

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

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

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

Основные угрозы при использовании виртуализации

Угрозы при использовании виртуальных машин можно разделить на «старые» и «новые». Под старыми угрозами понимаются традиционные угрозы, присущие любой IT-инфраструктуре. Это уязвимости операционных систем, уязвимости исполняемых программ и др. Под новыми угрозами понимаются уязвимости гипервизора (программного или аппаратного) и уязвимости менеджмента (управления) сложной виртуальной инфраструктурой:

– захват гостевой машины;

– вывод из строя виртуальной машины;

– компрометация управления ВМ;

– запуск неавторизованных ВМ;

– изменение разделения ресурсов – процессор, память, приоритеты;

– организационные проблемы – разделение полномочий, политики информационной безопасности (ИБ), разграничение доступа.

Таким образом, при использовании виртуализации количество возможных уязвимостей возрастает, а традиционные угрозы (вирусы, DoS / DDoS атаки, переполнение буферов, SQL-injection, XSS, утечки информации) остаются. Основные недостатки виртуальных машин с точки зрения ИБ сводятся к следующему:

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

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

– Возможность разрастания неизвестных ВМ. В ходе работы с виртуальной инфраструктурой постоянно создаются новые ВМ, удаляются старые, некоторые ВМ теряются по тем или иным причинам (например, Live Migration). В этом случае происходит разрастание ВМ. Дабы оградиться от этого недостатка, необходим грамотный менеджмент виртуальной сети;

– Сложно контролировать ВМ, возможно появление неуправляемых, неизвестных ВМ;

– Динамическое перемещение (Live Migration);

– Перемещение ВМ в менее защищенные машины, сети;

– Атаки методом повтора операций и повторного использования данных;

– Проведение повторяющихся операций внутри ВМ может привести к повторяющимся криптографическим атакам;

– Воровство: ВМ – это файлы, очень просто украсть всю систему или несколько систем;

– Атаки на гипервизор. Гипервизор – это программа. Уязвимости программ были и будут всегда. В случае ограниченного финансирования необходимо четко расставить приоритеты между дополнительными функциями гипервизора и его безопасностью. Дополнительные функции увеличивают функционал гипервизора, но это и новые строки кода, а значит, и новые уязвимости [1].

Проблема безопасности виртуальной инфраструктуры может быть условно разделена на две составляющие:

1. безопасность виртуальных машин;

2. безопасность платформы виртуализации.

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

сти по прослушиванию незащищенного трафика другими ВМ, контролируемыми злоумышленниками, и ввести в заблуждение системных администраторов [2].

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

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

Уязвимости программных средств виртуализации

Уязвимости продуктов VMWare перечислены ниже.

1. Уязвимость из-за ошибки в проверке входных данных в драйвере «HGFS.sys» из пакета VMware Tools. Атакующий может передать специально сформированные данные, что приведет к выполнению произвольного кода с повышенными привилегиями на гостевой Windows-системе.

2. Уязвимость из-за ошибки в проверке входных данных в «vmware-authd». Атакующий может передать специально сформированные данные, что приведет к выполнению произвольного кода с повышенными привилегиями на гостевой Linux-системе.

3. Уязвимость из-за ошибки в проверке входных данных в сервисе управления Openwsman при обработке «Content-Length» заголовков. Атакующий может получить привилегии «root» на целевой системе.

4. Уязвимость из-за ошибки в проверке входных данных в VMware VIX API. Атакующий может передать специально сформированные данные, что приведет к выполнению произвольного кода на хосто-вой системе.

Уязвимости продуктов SUNORACLE Virtual Box. В Virtual Box, как и в любом другом программном продукте, есть множество уязвимостей. Выделенная в данной работе уязвимость связана с уровнем привилегий в системе и позволяет локальному злоумышленнику выполнить вредоносные действия с повышенными привилегиями на целевой системе. Уязвимость существует из-за ошибки в проверке входных данных в драйвере VBoxDrv.sys при обработке определенных IOCTL. Атакующий может передать специально сформированные данные, что приведет к выполнению произвольного кода с привилегиями ядра.

Пример эксплойта: #include #include

int main(int argc, char **argv) <

HANDLE hDevice; DWORD cb;

char szDevice[] = "\\.\VBoxDrv"; if ( (hDevice = CreateFileA(szDevice, GENERIC_READ| GENERIC_WRITE, 0, 0,

printf("Device %s succesfully opened!
", szDevice); >

printf("Error: Error opening device %s
",szDevice); >

if (!DeviceIoControl(hDevice, 0x228103,

printf("Error in Devicelo . bytes returned %#x
",cb); >

Уязвимости MS Virtual PC. Основной уязвимостью остается ошибка в управлении памятью на уровне монитора виртуальных машин (Virtual Machine Monitor). Она позволяет обходить такие защитные механизмы, как предотвращение выполнения данных (DEP), безопасная обработка исключений и рандомизация адресного пространства (ASLR) и может быть использована для повышения уровня привилегий или удаленно для выполнения кода. В своем блоге Microsoft отказывается признавать данную брешь уязвимостью, называя ее лишь способом более легкой эксплуатации уже имеющихся уязвимостей.

Уязвимости XEN. Одна из основных уязвимостей данного продукта позволяет локальному злоумышленнику обойти ограничения безопасности на целевой системе. Уязвимость существует из-за ошибки в проверке входных данных в Xen pygrub. Эксплуатирование уязвимости приведет к обходу механизма аутентификации на целевой системе. Пример эксплойта: xm create -c guest

press space bar to stop the grub count down press e to edit

select the kernel line and press e

Append a "1" to the end of the kernel line and press retur

press "b" to boot

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

1. Из-за ошибки в проверке входных данных при обработке DR7 регистра отладки. Атакующий из вне гостевой системы может установить определенные точки останова, что приведет к краху гипервизора. Успешное эксплуатирование уязвимости, возможно, потребует использование гипервизорa HVM;

2. Из-за того, что доступ к регистру CR4 неправильно проверяется. Атакующий из вне гостевой системы может выполнить действия, приводящие к краху DomU или Dom0 доменов [3].

Вендоры безопасности и SECURITY API на примере VMSafe

В 2008 году компания VMware анонсировала технологию VMsafe. Реализацию VMsafe на данный момент можно увидеть только в программном пакете VMware vSphere, выпущенном в мае 2010 года. По своей сути, VMsafe – это технология, позволяющая сторонним разработчикам получить доступ к гипер-визору VMware и фактически представляющая собой набор API интерфейсов. Эти интерфейсы доступны по умолчанию в VMware vSphere, использовать этот набор API могут только ВМ управляемые решением по ИБ. Появление этой технологии позволило VMware, не проходя самостоятельного пути по созданию комплекса средств защиты, привлечь к обеспечению ИБ инфраструктур виртуализации, построенных на VMware vSphere, лидеров рынка ИБ.

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

Согласно официальной информации компании VMware, преимущества решений c использованием технологии VMSafe включают:

– Better Security – улучшение возможностей по обеспечению безопасности, появление новых возможностей мониторинга инфраструктуры не имеющих аналогов в физической инфраструктуре;

– Better isolation – улучшение изоляции гостевых операционных систем;

– Better correlation – улучшение возможностей по корреляции событий;

– Better enforcement across the infrastructure – решения, которые поддерживают технологию VMsafe, могут быть легко введены в эксплуатацию, так как такие решения обычно поставляются в виде виртуальных устройств (virtual appliance) и позволяют потратить меньше времени на их внедрение;

– Better scalability – улучшение возможностей масштабируемости инфраструктуры, сохраняя все правила и политики.

Работа с VMsafe может осуществляться в 2 режимах:

1. Kernel-mode – обработка в гипервизоре.

2. VM-mode – обработка внутри ВМ.

Для соблюдения политики безопасности необходимо настраивать политики виртуальных коммутаторов (vSwitch) на хостах таким образом, чтобы они были одинаковы – VLAN ID, имена Port Groups и т.п. Все это нужно поддерживать в актуальном состоянии. Технология Distributed vSwitch позволяет объединить несколько хостов VMware ESX Server одним виртуальным коммутатором, что дает множество новых возможностей.

– Появляется возможность централизованного назначения политик для такого коммутатора, что устранит ошибки в конфигурации и обеспечит задание параметров VLAN, групп портов и Security из единой точки интерфейса;

– Distributed vSwitch позволяет корректно работать механизму VMware Fault Tolerance, чтобы «теневая» копия ВМ имела идентичные сетевые политики на другом сервере, и в случае отказа основной ВМ мгновенно заменяла ее в действующем сетевом окружении. Таким образом, получаем не просто отказоустойчивый кластер, а безопасный отказоустойчивый кластер;

– Появляется возможность перезагружать коммутатор, не перезагружая хост ESX. Это необходимо для того, чтобы при изменении числа портов у коммутатора, не перезагружать хост ESX.

В контексте безопасности VMware продукт VMsafe Distributed vSwitch занимает отдельное место. На каждом сервере VMware ESX появляется еще одна ВМ «Security VM», подключенная к распределенному виртуальному коммутатору и выполняющая функции обеспечения сетевой безопасности для виртуальных машин сервера. Это может быть IDS/IPS-система, Firewall и т.п. – а может и все вместе. При этом защищающая ВМ назначает политики защищаемой ВМ. При миграции работающей ВМ за счет технологии VMware VMotion эти политики «переезжают» на другой хост-сервер ESX.

Данная модель говорит о том, что в виртуальной инфраструктуре VMware отпадает необходимость в установке агентов ПО для безопасности внутри ВМ, а управление политиками безопасности данных систем становится гораздо проще [4].

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

1. Грам В. Технологии виртуализации и повышение эффективности функционирования корпоративных предложений // Копьютерра [Электронный ресурс]. – Режим доступа: http ://offline.computerra.ru/2009/06.html, своб.

2. Черняк Л. Виртуализация серверов стандартной архитектуры // Открытые системы [Электронный ресурс]. – Режим доступа: http://www.osp.ru/os/list/2009/04.html, своб.

3. Keir T. Virtualization: The Executive Summary // [Электронный ресурс]. – Режим досту-па:http://www.pcworld.com/businesscenter/article/215199/virtualization_the_executive_summary.html, своб.

4. Причины выбрать Vmware // [Электронный ресурс]. – Режим доступа: http://www.vmware.com/ru/virtualization/why-choose-vmware.html, своб.

Евелев Юрий Евгеньевич – Санкт-Петербургский государственный инженерно-

экономический университет (ИНЖЭКОН), студент, evelev@xakep.ru

Чернокнижный Геннадий Михайлович – Санкт-Петербургский государственный инженерно-

1.10. Эффекты виртуализации

Экспертиза современных продуктов и недавние исследования раскрывают некоторые интересные возможности развития МВМ и требования, которые они предъявят к технологиям виртуализации.

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

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

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

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

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

Повышенная мобильность ВМ значительно изменила способы их применения. Такие проекты, как Collective и Internet Suspend/Resume, демонстрируют возможность перемещения всей вычислительной среды пользователя по локальной и территориально-распределенной сети. Доступность высокоемких недорогих сменных носителей, например, жестких дисков USB , означает, что потребитель может захватить свою вычислительную среду с собой, куда бы он ни направлялся.

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

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

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

Гибкая обработка отказов. Виртуальные разделы можно настроить так, чтобы обеспечить автоматическую обработку отказов для одного или нескольких приложений. Благодаря средствам обеспечения высокой степени работоспособности, заложенным сейчас в платформы на базе процессоров Intel® Itanium® 2 и Intel® Xeon™ MP, требуемый уровень услуг часто можно обеспечить, предусмотрев аварийный раздел на той же платформе, где работает основное приложение . Если требуется еще более высокий уровень работоспособности, аварийный раздел можно разместить на отдельной платформе.

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

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

Размещение средств безопасности за пределами ВМ – привлекательный способ изоляции сети. Доступ к сети предоставляется ВМ после проверки, гарантирующей, что она, с одной стороны, не представляет угрозы, а с другой – неуязвима для нападения. Управление доступом к сети на уровне ВМ превращает виртуальную машину в мощный инструмент борьбы с распространением злонамеренного кода.

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

Гибкость управления ресурсами, которую обеспечивают МВМ, может сделать системы более стойкими к нападениям. Возможность быстро тиражировать ВМ и динамически адаптироваться к большим рабочим нагрузкам станет основой мощного инструмента, позволяющего справиться с нарастающими перегрузками из-за внезапного наплыва посетителей на Web -сайте или атаки типа "отказ в обслуживании".

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

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

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

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

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

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

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

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

Очень важно обеспечить безопасность виртуальной машины для выполняемых приложений. It’s important to keep your virtual machine (VM) secure for the applications that you run. Для защиты виртуальных машин можно применить одну или несколько служб или функций Azure, которые обеспечивают безопасный доступ к виртуальным машинам и безопасное хранение данных. Securing your VMs can include one or more Azure services and features that cover secure access to your VMs and secure storage of your data. Из этой статьи вы узнаете, как обеспечить защиту своих виртуальных машин и приложений. This article provides information that enables you to keep your VM and applications secure.

Антивредоносная программа Antimalware

Спектр современных угроз, с которыми сталкиваются пользователи облачных сред, расширяется быстро, что вынуждает искать средства эффективной защиты, обеспечивающие соответствие требованиям к безопасности и нормативным требованиям. The modern threat landscape for cloud environments is dynamic, increasing the pressure to maintain effective protection in order to meet compliance and security requirements. Антивредоносное ПО Майкрософт для Azure предоставляет бесплатную защиту в реальном времени, которая помогает обнаруживать и устранять вирусы, шпионское ПО и другие вредоносные программы. Microsoft Antimalware for Azure is a free real-time protection capability that helps identify and remove viruses, spyware, and other malicious software. Вы можете настроить предупреждения, уведомляющие о попытках установки или запуска известных вредоносных или нежелательных программ на виртуальной машине. Alerts can be configured to notify you when known malicious or unwanted software attempts to install itself or run on your VM. Она не поддерживается на виртуальных машинах под управлением Linux или Windows Server 2008. It is not supported on VMs running Linux or Windows Server 2008.

Центр безопасности Azure Azure Security Center

Центр безопасности Azure позволяет предотвращать и обнаруживать угрозы на виртуальных машинах, а также реагировать на эти угрозы. Azure Security Center helps you prevent, detect, and respond to threats to your VMs. Центр безопасности предоставляет встроенные функции мониторинга безопасности и управления политиками для подписок Azure, помогает выявлять угрозы, которые в противном случае могли бы оказаться незамеченными, и взаимодействует с широким комплексом решений по обеспечению безопасности. Security Center provides integrated security monitoring and policy management across your Azure subscriptions, helps detect threats that might otherwise go unnoticed, and works with a broad ecosystem of security solutions.

Доступ к JIT Центру безопасности можете применить в развертывании вашей виртуальной машины, чтобы блокировать входящий трафик на виртуальные машины Azure, снизить уязвимость к атакам и обеспечить удобный доступ к виртуальным машинам, когда это необходимо. Security Center’s just-in-time access can be applied across your VM deployment to lock down inbound traffic to your Azure VMs, reducing exposure to attacks while providing easy access to connect to VMs when needed. Если включен режим JIT и пользователь запрашивает доступ к виртуальной машине, Центр безопасности проверяет, какие разрешения есть у пользователя для нее. When just-in-time is enabled and a user requests access to a VM, Security Center checks what permissions the user has for the VM. Если у пользователя есть правильные разрешения, запрос разрешается и Центр безопасности автоматически настраивает группу безопасности сети, которая разрешает передачу входящего трафика через выбранные порты на ограниченный период времени. If they have the correct permissions, the request is approved and Security Center automatically configures the Network Security Groups (NSGs) to allow inbound traffic to the selected ports for a limited amount of time. После истечения этого времени центр безопасности восстанавливает прежнее состояние групп безопасности сети. After the time has expired, Security Center restores the NSGs to their previous states.

Шифрование Encryption

Для повышения уровня безопасности и соответствия требованиям виртуальных машин Windows и Linux содержимое виртуальных дисков в Azure можно зашифровать. For enhanced Windows VM and Linux VM security and compliance, virtual disks in Azure can be encrypted. Виртуальные диски на виртуальных машинах Windows шифруются в неактивном состоянии с помощью Bitlocker. Virtual disks on Windows VMs are encrypted at rest using BitLocker. А виртуальные диски на виртуальных машинах Linux шифруются в неактивном состоянии с помощью dm-crypt. Virtual disks on Linux VMs are encrypted at rest using dm-crypt.

В Azure за шифрование виртуальных дисков плата не взимается. There is no charge for encrypting virtual disks in Azure. Криптографические ключи хранятся в хранилище ключей Azure с применением защиты программного обеспечения. В качестве альтернативы можно импортировать или создать ключи аппаратных модулей безопасности (HSM), сертифицированных по стандартам уровня 2 FIPS 140-2. Cryptographic keys are stored in Azure Key Vault using software-protection, or you can import or generate your keys in Hardware Security Modules (HSMs) certified to FIPS 140-2 level 2 standards. Эти криптографические ключи используются для шифрования и расшифровки виртуальных дисков, подключенных к виртуальной машине. These cryptographic keys are used to encrypt and decrypt virtual disks attached to your VM. Вы сохраняете контроль над этими криптографическими ключами и можете проводить аудит их использования. You retain control of these cryptographic keys and can audit their use. Субъект-служба Azure Active Directory предоставляет безопасный механизм для выдачи этих криптографических ключей при включении и отключении виртуальных машин. An Azure Active Directory service principal provides a secure mechanism for issuing these cryptographic keys as VMs are powered on and off.

Хранилище ключей и ключи SSH Key Vault and SSH Keys

Секреты и сертификаты могут моделироваться как ресурсы и предоставляться решением Key Vault. Secrets and certificates can be modeled as resources and provided by Key Vault. Создать хранилища ключей для виртуальных машин Windows можно с помощью Azure PowerShell, а для виртуальных машин Linux — с помощью Azure CLI. You can use Azure PowerShell to create key vaults for Windows VMs and the Azure CLI for Linux VMs. Вы также можете создать ключи для шифрования. You can also create keys for encryption.

Политики доступа к хранилищу ключей предоставляют доступ отдельно к ключам, секретам и сертификатам. Key vault access policies grant permissions to keys, secrets, and certificates separately. Например, можно предоставить пользователю доступ только к ключам, но не предоставить разрешения на секреты. For example, you can give a user access to only keys, but no permissions for secrets. Тем не менее разрешения на доступ к ключам и секретам или сертификатам находятся на уровне хранилища. However, permissions to access keys or secrets or certificates are at the vault level. Другими словами, политика доступа к хранилищу ключей не поддерживает разрешения на уровне объектов. In other words, key vault access policy does not support object level permissions.

При подключении к виртуальным машинам необходимо использовать шифрование с открытым ключом, чтобы обеспечить более высокий уровень безопасности при входе на виртуальные машины. When you connect to VMs, you should use public-key cryptography to provide a more secure way to sign in to them. Этот процесс предполагает обмен открытыми и закрытыми ключами с использованием команды Secure Shell (SSH), что позволяет аутентифицировать себя, не вводя имя пользователя и пароль. This process involves a public and private key exchange using the secure shell (SSH) command to authenticate yourself rather than a username and password. Пароли подвержены атакам методом подбора, особенно на виртуальных машинах с подключением к Интернету, таких как веб-серверы. Passwords are vulnerable to brute-force attacks, especially on Internet-facing VMs such as web servers. С помощью пары ключей Secure Shell (SSH) можно создавать виртуальные машины Linux, использующие ключи SSH для проверки подлинности, что позволяет обойтись без использования паролей для входа. With a secure shell (SSH) key pair, you can create a Linux VM that uses SSH keys for authentication, eliminating the need for passwords to sign-in. Кроме того, с помощью ключей SSH можно подключаться с виртуальной машины Windows к виртуальной машине Linux. You can also use SSH keys to connect from a Windows VM to a Linux VM.

Управляемые удостоверения для ресурсов Azure Managed identities for Azure resources

Распространенная проблема при создании облачных приложений — управление учетными данными в коде для проверки подлинности в облачных службах. A common challenge when building cloud applications is how to manage the credentials in your code for authenticating to cloud services. Обеспечение безопасности учетных данных является важной задачей. Keeping the credentials secure is an important task. В идеальном случае учетные данные никогда не передаются на рабочие станции разработчиков и не проверяются после изменения в системе управления версиями. Ideally, the credentials never appear on developer workstations and aren’t checked into source control. Azure Key Vault позволяет обеспечить безопасное хранение учетных данных, секретов, а также других ключей, но для их получения код должен выполнять проверку подлинности в Key Vault. Azure Key Vault provides a way to securely store credentials, secrets, and other keys, but your code has to authenticate to Key Vault to retrieve them.

Функция управляемых удостоверений для ресурсов Azure в Azure Active Directory решает эту проблему. The managed identities for Azure resources feature in Azure Active Directory (Azure AD) solves this problem. Функция предоставляет службам Azure автоматически управляемое удостоверение в Azure AD. The feature provides Azure services with an automatically managed identity in Azure AD. Удостоверение можно использовать для проверки подлинности в любой службе, которая поддерживает проверку подлинности Azure AD, включая Key Vault, при этом не сохраняя каких-либо учетных данных в коде. You can use the identity to authenticate to any service that supports Azure AD authentication, including Key Vault, without any credentials in your code. Код, выполняющийся на виртуальной машине, может выполнить запрос на получение маркера из двух конечных точек, доступных только на виртуальной машине. Your code that’s running on a VM can request a token from two endpoints that are accessible only from within the VM. Дополнительные подробные сведения об этой службе см. в статье c общими сведениями об управляемых удостоверениях для ресурсов Azure. For more detailed information about this service, review the managed identities for Azure resources overview page.

Политики Policies

С помощью политик Azure можно определить требуемое поведение виртуальных машин Windows и Linux вашей организации. Azure policies can be used to define the desired behavior for your organization’s Windows VMs and Linux VMs. С помощью политик организация может обеспечить выполнение различных норм и правил во всей организации. By using policies, an organization can enforce various conventions and rules throughout the enterprise. Обязательные для выполнения стандарты поведения помогают снизить риск, что способствует успешной деятельности организации. Enforcement of the desired behavior can help mitigate risk while contributing to the success of the organization.

Управление доступом на основе ролей Role-based access control

С помощью управления доступом на основе ролей (RBAC) вы можете распределить обязанности внутри команды и предоставить пользователям виртуальной машины доступ на уровне, который им необходим для выполнения поставленных задач. Using role-based access control (RBAC), you can segregate duties within your team and grant only the amount of access to users on your VM that they need to perform their jobs. Вместо того чтобы предоставлять всем неограниченные разрешения для виртуальной машины, можно разрешить только определенные действия. Instead of giving everybody unrestricted permissions on the VM, you can allow only certain actions. Вы можете настроить управление доступом для виртуальной машины на портале Azure с помощью Azure CLI или Azure PowerShell. You can configure access control for the VM in the Azure portal, using the Azure CLI, orAzure PowerShell.