Угрозы виртуализированной среды сегодня: что может сказать AMD?

дата:

 

Введение

Как все вы, наверное, уже знаете, за последние пару лет мы столкнулись с растущим числом и масштабом атак, вызванных уязвимостями оборудования. Наиболее печально известны уязвимости Meltdown и Spectre, обнаруженные в процессорах Intel.

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

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

Что это такое

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

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

  • Secure Encrypted Virtualization (SEV) - их первая попытка, которая была анонсирована в 2016 году. Он отделяет виртуальные машины от гипервизора, чтобы защитить их, если последний когда-либо будет скомпрометирован. Таким образом, если гипервизор попытается прочитать информацию гостевой ОС, все, что он получит, будет зашифрованными данными.
  • SEV-ES (Encrypted State) - следующий запуск, анонсированный в 2017 году. Предполагается, что он завершит защиту гостевой ОС, зашифровав все содержимое регистров процессора. Таким образом, регистры процессора, активно используемые виртуальной машиной, находятся вне поля зрения гипервизора.
  • SEV-SNP (Secure Nested Paging) – наконец, последнее поколение, выпущенное в этом же году. Он выводит на стол аппаратные функции безопасности, чтобы следить за целостностью оперативной памяти гостевой ОС. Эта технология служит контрмерой против таких атак, как воспроизведение данных, переназначение памяти и т. д. (Подробнее здесь и ниже).

В VMware vSphere 7 Update 1 появилась новая поддержка технологии SEV-ES (Encrypted State), которая позволяет увеличить ваши шансы против любой потенциальной уязвимости, связанной с доступом к данным внутри процессора, если она когда-либо возникнет. Для работы требуется процессор AMD EPYX 7xx2 (или более поздней серии, конечно) и виртуальное оборудование виртуальной машины 18 (удобно представленное в VMware vSphere 7 Update 1).

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

Поэтому, чтобы избежать каких-либо сбоев, единственным необязательным выбором является максимально изолировать гипервизор от виртуальных машин на аппаратном уровне. Это называется доверенной средой выполнения (TEE).


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

Первое поколение процессоров EPYC было способно обрабатывать не более 15 ключей шифрования. Сейчас их уже больше 500.

Один из них идет к самому гипервизору, остальные-к гостевой операционной системе.


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

Ключи работают очень просто:

  • Гостевая ОС отправляет запрос на центральный процессор (естественно, должен поддерживаться SEV) для получения ключа шифрования оперативной памяти;
  • SEV-ES расширяет его на регистрах центрального процессора;
  • Вуаля, гостевая ОС может использовать память и регистры, не позволяя гипервизору или другим виртуальным машинам (которые также изолированы внутри процессов VMX) читать ее содержимое.

Конечно, гостевая ОС также должна иметь поддержку SEV-ES (именно поэтому никогда не помешает ознакомиться с сопроводительной документацией).

Единственным огромным недостатком в этом случае является то, что после того, как вы решили использовать технологию SEV-ES, это нет-нет для остальных: vMotion, моментальные снимки памяти, целостность гостевой системы, горячее добавление, приостановка и возобновление, отказоустойчивость или горячее клонирование теперь отсутствуют в таблице. Почему? Для работы этих решений гипервизору потребуется прямой доступ к оперативной памяти гостевой ОС.

В то же время, я не могу не упомянуть, что это ограничение не от AMD (который утверждает, что SEV-ES полностью совместим с динамической миграцией и т. д.), а ограничение реализации от VMware.


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

С другой стороны, однако, недавнее решение vSphere with Tanzu даже не использует vMotion для машин с виртуализированными контейнерами приложений: они просто выключаются на одном хосте и запускаются на другом. Как вы сами видите, у Северов здесь есть будущее.

Вы также можете работать с поддержкой SEV-ES для виртуальных машин в пакетном режиме, применяя ее для тысяч виртуальных машин через интерфейс PowerCli (пользователи контейнеров Tanzu, обратите внимание). Тем не менее, поскольку официальная информация VMware о командлетах SEV-ES еще не опубликована, все, что нам нужно сделать, - это подождать.

Не так давно, кстати, VMware выпустила интересное видео, освещающее первую реализацию SEV-ES в VMware vSphere 7 Update 1:

Подведем итоги.

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