АТТЕСТАЦИЯ ХОСТА, СОДЕРЖАЩЕГО ДОВЕРИТЕЛЬНУЮ СРЕДУ ИСПОЛНЕНИЯ Российский патент 2019 года по МПК G06F21/57 G06F9/455 H04W12/10 

УРОВЕНЬ ТЕХНИКИ

Предпосылки и соответствующая область техники

[0001] Взаимное соединение вычислительных систем способствовало созданию распределенных вычислительных систем, таких, как так называемые ʺоблачныеʺ вычислительные системы. В этом описании ʺоблачное вычислениеʺ может представлять собой системы или ресурсы для обеспечения возможности повсеместного, удобного, осуществляемого по требованию сетевого доступа к совместно используемому пулу конфигурируемых вычислительных ресурсов (например, сетей, серверов, систем хранения, приложений, служб и т.д.), которые могут предоставляться и освобождаться с меньшими усилиями управления или взаимодействия поставщиков услуг. Облачная модель может быть составлена из различных характеристик (например, самообслуживание по требованию, широкий сетевой доступ, объединение ресурсов, быстрая приспособляемость, измеряемая услуга и т.д.), моделей услуг (например, программное обеспечение как услуга (ʺSaaSʺ), платформа как услуга (ʺPaaSʺ), инфраструктура как услуга (ʺIaaSʺ)) и моделей развертывания (например, частное облако, облако сообщества, общественное облако, гибридное облако и т.д.).

[0002] Облачные приложения и приложения удаленных услуг являются общепринятыми. Такие приложения размещаются на общественных и частных удаленных системах, таких как облака, и, как правило, предлагают набор веб-сервисов для двусторонней коммуникации с клиентами.

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

[0004] Эта угроза актуальна для арендаторов (тенантов), которые приводят в действие свои рабочие нагрузки на общественном облаке или у поставщика услуг: в то время как арендатор может доверять поставщику услуг как институту, он не хочет расширять это доверие на сотрудников поставщика услуг, которые могут быть злонамеренными по личной криминальной инициативе или будучи подкупленными или нанятыми внешними взломщиками, или чьи учетные данные могут быть украдены внешним взломщиком с использованием одного из многих видов атак, включая ʺфишингʺ (выуживание конфиденциальной информации). Но это также актуально для внутренней деятельности предприятия: собственные IT-сотрудники предприятия могут также стать объектом кражи их учетных данных или могут оказаться злонамеренными по другим причинам. В современной практике, IT-персонал с привилегиями для задействования хостинг-структуры имеет широкий и почти неограниченный доступ ко всем рабочим нагрузкам.

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

[0006] Таким образом, может быть полезным обеспечивать возможность автоматизированных рабочих процессов управления как виртуализованных рабочих нагрузок, так и структуры, при защите рабочих нагрузок от IT-персонала, который задействует структуру. Проблема состоит в том, что в современной практике системы управления виртуальными машинами (VMM) играют активную роль в обеспечении и управлении виртуальными машинами (VM), и, аналогично, системы управления структурой (FM) играют активную роль в обеспечении и управлении структурой, но сделать их частью ʺдоверительной вычислительной базыʺ, фундаментом, на котором построено доверительное вычисление, может быть проблематичным по меньшей мере по двум причинам: системы управления являются большими и сложными и, как таковые, обычно не могут быть сделаны или стать безопасными, и арендатор не хочет расширять доверие по отношению к оперативному персоналу поставщика услуг, который управляет VMM и FM.

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

КРАТКАЯ СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

[0009] Это краткое изложение сущности изобретения приведено, чтобы ввести подборку концепций в упрощенной форме, которые дополнительно описаны ниже в подробном описании. Это краткое изложение сущности изобретения не предназначено для идентификации ключевых признаков или существенных признаков заявленного изобретения, а также не предназначено для использования в качестве помощи при определении объема заявленного изобретения.

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

[0012] Фиг. 1 иллюстрирует блок обработки, связанный с устройством защиты;

[0013] Фиг. 2 является блок-схемой, которая в общем виде представляет иллюстративные компоненты системы, выполненной в соответствии с аспектами изобретения, описанного в данном документе;

[0014] Фиг. 3 является блок-схемой, иллюстрирующей пример вычислительного устройства, реализующего методы, описанные в настоящем документе, в соответствии с одним или более вариантами осуществления;

[0015] Фиг. 4 иллюстрирует пример множества виртуальных доверительных уровней в соответствии с одним или более вариантами осуществления;

[0016] Фиг. 5 иллюстрирует примерную систему, реализующую множество виртуальных доверительных уровней в соответствии с одним или более вариантами осуществления;

[0017] Фиг. 6 является блок-схемой последовательности операций, иллюстрирующей примерный процесс для обеспечения виртуального безопасного режима для виртуальной машины в соответствии с одним или более вариантами осуществления;

[0018] Фиг. 7 является блок-схемой последовательности операций, иллюстрирующей способ установления доверия для хоста;

[0019] Фиг. 8 является блок-схемой последовательности операций, иллюстрирующей другой способ установления доверия для хоста; и

[0020] Фиг. 9 является блок-схемой последовательности операций, иллюстрирующей другой способ развертывания зашифрованного объекта на доверительном объекте.

ПОДРОБНОЕ ОПИСАНИЕ

[0021] Варианты осуществления настоящего изобретения могут реализовать модель, используемую для автоматизации операций управления на виртуальных машинах (VM), таких как развертывание и миграция. В частности, варианты осуществления могут определить, что хост удовлетворяет определенным требованиям политики. Когда хост удовлетворяет определенным требованиям политики, хосту может быть выдан сертификат, который хост может использовать для выполнения различных действий развертывания. В частности, по меньшей мере одним из требований может быть то, что хост содержит доверительную среду исполнения (ТЕЕ). Многие различные ТЕЕ могут быть использованы совместно или альтернативно. В одном варианте осуществления, это может быть реализовано в виде функций, исполняющихся в ядре VM хоста. В другой реализации, это может исполняться в гипервизоре. В других вариантах осуществления, это может быть реализовано в виде отдельного адресного пространства, созданного гипервизором с использованием возможностей отображения памяти процессора. В других вариантах осуществления, это может быть реализовано в виде отдельной зоны исполнения, созданной процессором (например, TrustZone архитектуры ARM, появляющейся возможности SGX, описанной Intel Corporation, Санта-Клара, шт. Калифорния, или технологии модуля доверительной платформы (TPM)). Эти различные реализации могут предложить сходные функциональные возможности, такие как способность выполнять криптографические операции, хранить учетные данные, подтверждать целостность кода или данных и защищать секреты. Однако они могут отличаться по свойствам безопасности, которые они предлагают. Некоторые варианты осуществления могут содержать доверительную среду исполнения (ТЕЕ) с использованием функциональных возможностей, упоминаемых здесь как виртуальный безопасный режим (VSM), который описан ниже более подробно.

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

[0023] Детали иллюстрируются ниже со ссылкой на чертежи.

[0024] На фиг. 1, блок 120 обработки может быть соединен с устройством 122 защиты аппаратных средств. Устройство 122 защиты может быть способно генерировать и безопасно хранить криптографические ключи, которые могут быть использованы для защиты различных аспектов компьютера 110. В одном варианте осуществления, устройство 122 защиты может содержать устройство защиты на модуле доверительной платформы (TPM) или тому подобное.

[0025] В данном документе часто используется термин ʺмодуль доверительной платформыʺ (TPM). ТРМ хорошо известны специалистам в данной области техники. Использование термина ТРМ, однако, не предназначено для ограничения аспектов изобретения, описанного в настоящем документе, исключительно устройствами, которые соответствуют одной или более версиям стандартов для реализации TPM. Напротив, этот термин используется в качестве одного примера компонента безопасности, который может быть использован в соответствии с аспектами изобретения, описанного в настоящем документе.

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

[0027] 1. Защищенная память (упоминаемая как ʺэкранированные местоположенияʺ во многих приложениях TPM). Устройство защиты может включать в себя память, запись в которую может осуществлять только устройство защиты. Эта память может быть использована для хранения измерений, для запечатывания и распечатывания, для других криптографических функций, а также для различных других функций.

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

[0029] 3. Средство для выполнения аттестации. Устройство защиты может иметь процессор или другие схемы, которые могут быть использованы для создания доверительных сообщений о каких-либо активах, контролируемых устройством защиты. Некоторые примерные активы, контролируемые устройством защиты, могут включать в себя криптографический объект, запечатанный блоб, состояние платформы, с которой ассоциировано устройство защиты, или тому подобное.

[0030] Хотя устройства защиты часто представляются как отдельные дискретные компоненты, это не является обязательным. Например, в одной реализации, программно-аппаратное средство (ʺпрошивкаʺ), связанное с процессором, может быть использовано в качестве устройства защиты.

[0031] Когда термин ТРМ используется в данном описании, то следует понимать, что могут быть использованы альтернативные реализации других устройств защиты (в том числе те, которые упомянуты здесь в описании), не отступая от объема аспектов изобретения, описанного в настоящем документе.

[0032] С помощью виртуальной машины, пользователю может быть желательным иметь гарантии в отношении целостности виртуальной машины и среды хостинга. На фиг. 2 представлена блок-схема, которая в общем виде представляет иллюстративные компоненты системы, сконфигурированной в соответствии с аспектами изобретения, описанного в настоящем документе. Компоненты, показанные на фиг. 2, являются иллюстративными и не предназначены, чтобы быть полностью включенными компонентами, которые могут быть необходимы или включены. Кроме того, количество компонентов может отличаться в других вариантах осуществления без отклонения от объема аспектов изобретения, описанного в настоящем документе. В некоторых вариантах осуществления, компоненты, описанные в связи с фиг. 2, могут быть включены в другие компоненты (показанные или не показанные) или помещены в подкомпоненты без отклонения от объема аспектов изобретения, описанного здесь. В некоторых вариантах осуществления, компоненты и/или функции, описанные в связи с фиг. 2, могут быть распределены по множеству устройств.

[0033] Со ссылкой на фиг. 2, система 200 может включать в себя хост 230, службу 235 распределения ключей и другие компоненты (не показаны). Хост 230 может быть пригодным для хостинга одной или более виртуальных машин 208-210, которые могут быть связаны с VHD 205-207. Хост 230 может размещать (хостировать) одну или более виртуальных машин (например, гостевые виртуальные машины 208-210). Виртуальная машина может быть ассоциирована с одним или более VHD (например, одним или более VHD 205-207). Гостевые виртуальные машины 208-210 могут мигрировать между хостами, в отличие от ʺкорневойʺ VM 231, которая обеспечивает функциональные возможности операционной системы для хоста 230. Хост 230 может включать в себя гипервизор 215 и дискретный модуль 261 доверительной платформы или другое устройство защиты.

[0034] Гипервизор 215 является компонентом, который создает виртуальную среду, в которой могут работать виртуальные машины 208-210 и корневая VM 231. Гипервизор 215 может быть реализован в программном обеспечении, программно-аппаратных средствах, аппаратных средствах, комбинации двух или более из указанных выше или тому подобного. Гипервизор 215 может исполняться непосредственно на аппаратных средствах хоста 230 или может исполняться в среде операционной системы, размещенной на хосте 230.

[0035] В одной реализации, гипервизор 215 может управлять одним или несколькими виртуальными TPM (vTPM) 220-222. Каждый vTPM может быть ассоциирован с виртуальной машиной (например, одной из виртуальных машин 208-210). В этой реализации, гипервизор 215 может хранить данные, представляющие vTPM, в защищенной памяти гипервизора 215, которая не доступна для компонентов вне гипервизора 215. Для получения доступа к vTPM, взломщику может потребоваться получить контроль над самим гипервизором 215. В другой реализации, хост 230 может управлять vTPM 220-222. В этой реализации, пользователи и процессы с привилегиями администратора могут иметь доступ к vTPM 220-222. В еще одной реализации, служба, внешняя по отношению к хосту 230, может управлять vTPM 220-222. В еще одной реализации, как проиллюстрировано посредством vTPM, показанных пунктирными линиями на фиг. 2, vTPM могут быть реализованы в VSM 265 корневой VM 231.

[0036] В одной реализации, служба 235 распределения ключей может быть размещена внешним образом по отношению к хосту 230.

[0037] Ключи, используемые для дешифрования vTPM, могут распространяться различными путями. Например, в одной реализации, ключ может быть распределен в любое время после того, как известно, что состояние хоста удовлетворяет политике. Например, после конфигурирования хоста 230 в состоянии, которое удовлетворяет политике, состояние одного или нескольких регистров ТРМ может быть подписано посредством ТРМ 261 и послано в службу 235 распределения ключей. После его получения, служба 235 распределения ключей может немедленно или в любое время после этого послать хосту 230 ключ, зашифрованный или упакованный таким образом, что хост 230 может только дешифровать ключ, когда хост 230 находится в состоянии, которое удовлетворяет политике. Шифрование ключа таким способом может включать в себя шифрование ключа открытым ключом ТРМ хоста, а также запечатывание (изоляцию) в состоянии, которое удовлетворяет политике (как измеряется посредством ТРМ хоста).

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

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

[0040] Решения, приведенные выше, могут быть применены для защиты машины, которые либо не имеют устройства защиты, либо имеют более старую версию устройства защиты. Например, некоторые машины могут не иметь ТРМ вообще. Другие машины могут иметь TPM, но модуль TPM может быть реализован в соответствии со старым стандартом ТРМ. Некоторые операционные системы могут не исполняться, если только они не имеют доступа к ТРМ, реализованного в соответствии с определенной версией или выше.

[0041] Для исправления таких платформ, как описанные выше, платформа может быть сконфигурирована с гипервизором. Гипервизор может быть тогда использован для исполнения операционной системы в виртуальной среде. Когда операционная система запрашивает доступ к ТРМ, гипервизор может предоставить виртуальный ТРМ соответствующей версии. Гипервизор может защищать виртуальный ТРМ, так что только гипервизор может изменять защищенную память виртуального TPM. Что касается операционной системы, то виртуальный модуль TPM выглядит точно так же, как дискретный физический ТРМ.

[0042] Кроме того, начальный секрет, используемый для создания виртуального TPM, может быть введен с помощью клавиатуры или другого устройства ввода, считан с USB или другого устройства внешнего хранения, которое отсоединяется после того, как начальный секрет использован, и т.п.

[0043] Одним из преимуществ указанного способа для защиты машин является то, что быстродействующие аппаратные средства машины (например, CPU) могут быть использованы для выполнения функций vTPM. Это может значительно ускорить криптографические функции машины.

[0044] Если ТРМ более старой версии доступен на машине, этот ТРМ более старой версии может быть использован для предоставления доказательств того, что машина находится в состоянии, в котором машине позволено получать доступ к ключу vTPM. Хотя это может быть не столь же идеальным, как иметь ТРМ новой версии TPM на машине и использовать этот ТРМ новой версии для получения доступа к ключу vTPM, это может быть лучше, чем решения без использования ТРМ.

[0045] Рассмотрим теперь исходную ситуацию с набором VM 208, 209 и 210, уже существующих в среде центра обработки данных. Ключи для шифрования защищены модулями виртуальных доверительных платформ (vTPM) 220, 221 и 222, соответственно.

[0046] Виртуальные машины 208-210 могут быть предоставлены через центр обработки данных одному или более арендаторам. Арендатор может быть ассоциирован с одной или более из виртуальных машин 208-210. Экранированные виртуальные машины хранятся в системе 250 хранения центра обработки данных, но в рамках модели угроз, рассматриваемой здесь, арендатор не доверяет механизму контроля доступа системы 250 хранения, так как сотрудник поставщика услуг с правами администратора может обойти эти элементы управления.

[0047] Арендатор может включать пользователя, компанию или любой другой объект, который имеет права на доступ к одной или более виртуальных машин. ʺАрендаторамиʺ (тенантами) в многопользовательской среде могут быть отдельные предприятия, как обычно предполагается для VM. Но они также могут быть отделами в пределах предприятия или пользователями или отдельными приложениями - любым типом группировки, которая должна поддерживаться отдельно от других группировок. В некоторых случаях предприятие может управлять более слабой изоляцией таких контейнеров, разрешая работу пользователей, отделов и приложений в рамках предприятия, но использовать более сильную изоляцию VM для защиты от других потенциально враждебных объектов.

[0048] В одном сценарии, VM 208, 209 и 210 развернуты на одном из хостов 230 в структуре. В вариантах осуществления, показанных здесь, ʺхостʺ представляет собой платформу виртуализации. Хост, в некоторых проиллюстрированных примерах, включает в себя гипервизор 215, развернутый на аппаратных средствах (проиллюстрирован как сервер 251), плюс VM 231 хоста, которая развернута на гипервизоре 215. Тем не менее, следует понимать, что хосты также могут быть реализованы другими способами. Например, иногда хост может быть реализован в гипервизоре 215, без VM хоста. Таким образом, ʺхостʺ, как используется здесь, относится просто к платформе виртуализации, в любой форме, которая может быть создана. Действие развертывания может осуществляться арендатором с использованием портала управления самообслуживания, представленного посредством VMМ 253, или арендатором, действующим через интерфейс программирования или другой интерфейс. В другом варианте сценария, действие может быть предпринято автоматизированной функцией VMМ 253, например, развертывание по заданному арендатором графику или операция обработки отказа в ответ на отказ хоста. В другом варианте сценария, действие может предприниматься оперативным персоналом поставщика услуг, чтобы облегчить оперативные задачи, такие как обслуживание хоста или распределение ресурсов. Защита VM 208, 209 и 210 не основана на доверии к идентификации действующего субъекта (актора), инициирующего действие, потому что система допускает действия, выполняемые оперативным персоналом поставщика услуг или автоматизированной FM 254, и даже в случае действия, инициированного арендатором, существует возможность того, что злонамеренный сотрудник перехватывает и компрометирует или фальсифицирует такое действие.

[0049] После того, как экранированная VM развернута на хосте, хост дешифрует ее, как показано не-заштрихованной версией VM 208, 209 и 210, показанных на фиг. 2. В типичном сценарии, виртуальный накопитель на жестком диске (VHD) VM зашифрован, например, с использованием механизма Microsoft BitLocker, доступного от Microsoft Corporation, Редмонд, шт. Вашингтон, и имеет свой ключ шифрования, защищенный, как описано в общих чертах выше, виртуальным ТРМ (например, vTPM 220, 221 и 222), во многом тем же путем, как зашифрованный физический накопитель на жестком диске имеет свой ключ, защищенный физическим ТРМ. В физическом случае, накопитель на жестком диске и физический TPM оба принадлежат одному и тому же физическому компьютеру и статически задействованы и являются взаимно доверительными в силу своего физического совместного размещения на физической машине, но в случае виртуальной машины, которая может быть развернута на любой физической машине, виртуальный TPM представляет собой программное обеспечение + конструкция данных, которая сама является зашифрованной. Таким образом, дешифрование экранированной VM начинается с того, что хост 230 дешифрует vTPM 220, 221 и 222, а оттуда - гостевую VM, продолжающую измерения в vTPM для извлечения ключей, чтобы начать процесс дешифрования данных. Для того чтобы сделать это, хост должен извлечь ключ, чтобы разблокировать vTPM 220, 221 и 222. В этом случае хост дешифрует данные экранированного vTPM, чтобы обеспечить исполнение vTPM. ТРМ VM (vTPM, открытого из хоста) используется кодом внутри VM, чтобы дешифровать данные.

[0050] Термин ʺвиртуальный накопитель на жестком дискеʺ, как используется здесь, приведен только в качестве примера. В других альтернативах, другие виртуальные устройства хранения данных, такие как виртуальный гибкий диск, виртуальное твердотельное хранилище или другие виртуальные среды для чтения и записи, виртуальный CD-ROM, виртуальный DVD или другие виртуальные носители могут быть использованы взамен без отклонения от объема аспектов изобретения, описанного здесь. Термин ʺвиртуальное устройство храненияʺ предназначен для включения любого типа виртуального устройства хранения, включая, например, упомянутые выше.

[0051] Виртуальное устройство хранения может включать в себя или быть ассоциировано с метаданными, которые предназначены для использования гипервизором 215. В некоторой реализации (описано более подробно ниже), эти метаданные могут быть скрыты и не доступны для просмотра виртуальной машиной, хостируемой гипервизором 215. Это представление исключает метаданные, предназначенные для использования гипервизором 215. В этих реализациях, виртуальная машина, с использованием vTPM, может только зашифровывать или дешифровать то, что находится в представлении.

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

[0053] Со ссылкой на фиг. 2, система 200 может быть размещена в общественном или частном облаке. ʺОблакоʺ - это термин, который опирается на идею, состоящую в том, что вычисление, программное обеспечение, доступ к данным, хранение и другие ресурсы могут быть предоставлены объектами, связанными с некоторой сетью, не требуя от пользователей знать местоположение или другие детали о вычислительной инфраструктуре, которая поставляет эти ресурсы.

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

[0055] Чтобы гарантировать, что политики удовлетворены, в одной реализации, арендатор может потребовать, чтобы все или части накопителей 205, 206 и 207 на жестких дисках, ассоциированных с виртуальными машинами 208, 209 и 210, соответственно, были зашифрованы с помощью секретного ключа. Зашифрованный виртуальный накопитель на жестком диске может только быть незашифрованным, если секретный ключ известен. Без виртуального накопителя на жестком диске, ассоциированного с ней, виртуальная машина может быть не в состоянии исполняться.

[0056] Что касается политики и политик, то следует понимать, что операции в данном документе могут быть применены к одной или нескольким политикам, независимо от того, используется ли термин ʺполитикаʺ или термин ʺполитикиʺ. Например, запечатанный ключ может быть распечатан, если хост соответствует любой одной из набора допустимых политик (или в некоторых случаях, когда хост соответствует всем или определенному поднабору политик). Аналогичным образом, служба распределения ключей может предоставить ключ для доступа к vTPM, если гипервизор предоставляет доказательства того, что состояние хоста удовлетворяет любому из набора приемлемых политик (или когда состояние хоста удовлетворяет всем или некоторым поднаборам политик). Например, гипервизор может предоставить эти доказательства путем предоставления аттестации (удостоверения) состояния хоста посредством ТРМ хоста. В некоторых вариантах осуществления, одна такая политика, которая может быть реализована, представляет собой политику, определяющую, что хост делает определенные запросы сертификата, используя безопасную подсистему хоста, такую как VSM 265, или что хост может выполнять обработку с помощью безопасной подсистемы хоста. Как уже отмечалось, подробная информация о VSM приведена ниже.

[0057] В одной реализации, секретный ключ, который может быть использован для дешифрования VHD, может быть тем же самым ключом, который обеспечивается службой 235 распределения ключей. В этой реализации, vTPM 220-222 могут не потребоваться. После того, как секретный ключ получен из службы 235 распределения ключей, этот ключ может быть использован для дешифрования VHD.

[0058] В другой реализации, секретный ключ, который может дешифровать VHD виртуальной машины, может быть запечатан на vTPM, который ассоциирован с виртуальной машиной. Запечатывание может использовать один или более регистров vTPM. Набор регистров может быть выбран таким образом, чтобы обеспечить соблюдение выбранной арендатором политики. Когда ключ запечатан через vTPM, ключ может быть получен только из vTPM, если регистр(ы), используемый(е) для запечатывания ключа, включают в себя те же данные, которые они включали, когда ключ был запечатан.

[0059] Кроме того, vTPM может быть защищен таким образом, что только хост, владеющий корректным ключом k для vTPM, сможет получить к нему доступ. vTPM может быть защищен с помощью ключа k, и KDS может послать ключ k хосту внутри запечатанного блоба. Запечатанный блоб может быть построен таким образом, что TPM будет только дешифровать его, если выбранный набор регистров PCR имеет желательные значения. В одной реализации, KDS использует стандартизованные форматы TPM для достижения этого, а хост использует TPM для дешифрования ключа k с использованием операции распечатывания (разблокирования) в ТРМ.

[0060] Операция разблокирования может быть выполнена хостом 230 на основе распределения ключей, как описано ниже. Если операция разблокирования выполняется службой 235 распределения, хост может передать службе 235 распределения ключей данные, измеренные посредством ТРМ 261, в упаковке, подписанной посредством ТРМ. Если операция разблокирования выполняется хостом 230, хост может использовать ранее распределенный ключ, который может быть разблокирован только на хосте 230, если хост 230 находится в состоянии (как измерено с помощью ТРМ 261), которое удовлетворяет политику.

[0061] Если все регистры находятся в корректном состоянии (это означает, что хост 230 находится в состоянии, совместимом с политикой), то разблокирование будет успешным, и хост 230 будет снабжен ключом для дешифрования vTPM виртуальной машины или ключом для дешифрования VHD непосредственно. В данный момент виртуальная машина может загружаться, так как vTPM доступен для разблокирования ключа, необходимого для дешифрирования VHD виртуальной машины. Если состояние vTPM после загрузки находится в соответствии с политикой арендатора, будет происходить разблокировка. Когда виртуальная машина разблокирована, она может также стремиться выполнить аттестацию на основе ее текущего состояния vTPM. Эта аттестация позволяет виртуальной машине демонстрировать свое соответствие с политиками арендатора ресурсам других арендаторов.

[0062] В данный момент достигаются следующие цели:

[0063] 1. С помощью аттестации, выполняемой посредством исполнения виртуальной машины, арендатор удостоверяется, что виртуальная машина находится в соответствии с установленными арендатором политиками виртуальной машины;

[0064] 2. Ввиду запечатывания ключа, который шифрует VHD виртуальной машины, арендатор удостоверяется, что содержание VHD не было изменено; и

[0065] 3. Ввиду ТРМ хоста и аттестации хоста, арендатор удостоверяется, что виртуальная машина исполняется на хосте, который соответствует установленным политикам для хостов.

[0066] Для того, чтобы также защитить от модификации компоненты VM (например, VHD, состояния устройства, память VM и т.д.) во время выполнения, политика целостности кода может быть реализована на хосте.

[0067] В альтернативной реализации, вместо выполнения службой 235 распределения ключей операции запечатывания, служба 235 распределения ключей может просто предоставить ключ для дешифрования VHD. Например, хост 230 может передать службе 235 распределения ключей данные, измеренные посредством ТРМ 261, в упаковке, подписанной посредством TPM, и служба 235 распределения ключей может реагировать путем предоставления хосту ключа для дешифрования VHD.

[0068] В одной реализации, служба 235 распределения ключей может управляться арендатором. В другой реализации, служба 235 распределения ключей может управляться хостером (например, оператором облака, которое приводит в действие хост 230). В первой реализации, арендатор сохраняет полный контроль над ключами, необходимыми для дешифрования vTPM (и через него, виртуальной машины), но, возможно, должен будет нести бремя поддержания соединения с хостером, чтобы позволить виртуальным машинам загружаться. Во второй реализации, арендатор может позволить хостеру (например, отдельной части организации хостера) исполнять службу 235 распределения ключей. В одной реализации, это может быть сделано таким образом, что по меньшей мере два объекта в организации хостера обязаны взаимодействовать для получения доступа к ключу k vTPM арендатора.

[0069] Из-за обстоятельств, которые препятствуют доверию к VMM 253 или ее операционному персоналу, в типичных вариантах осуществления, VMM 253 не имеет критичной для безопасности роли в обеспечении ключей, чтобы разблокировать экранированные VM 208, 209 и 210. Но очень полезным для автоматизированных и эффективных операций, а также для обеспечения операций самообслуживания для арендатора, является то, что VMM 253 может организовать операции. Одна модель некоторых вариантов осуществления изобретения, которая сочетает эти требования, выглядит следующим образом:

[0070] 1. VMM 253 развертывает гостевую VM (например, VM 208) на соответствующем хосте 230, обычным способом, не делая ничего критичного для безопасности в отношении развертывания ключей. VMM 253 может выполнять свои обычные операции по управлению с нормальными соображениями и действиями, такими как планирование, оптимизация размещения и распределения ресурсов, без существенного изменения в связи с защищенным характером VM 208 (некоторые незначительные расширения обсуждаются ниже). VM 208 содержит, как часть ее метаданных, зашифрованный vTPM 220, а также ключ 255 защиты для vTPM 220, зашифрованного в соответствии с требованиями для безопасных операций, но все эти метаданные обрабатываются вместе как часть стандартных операций развертывания без специальной связанной с безопасностью обработки посредством VMM.

[0071] 2. Когда хост 230 обнаруживает, что это экранированная VM (не все VM экранированы), он обращается к KDS 235, чтобы получить ключ, чтобы разблокировать vTPM 220. В качестве части этого запроса 256, хост включает сертификат 257 аттестации, предоставленный службой аттестации хоста (HAS) 258, показывающий, что он является действительным хостом, который соответствует политике поставщика услуг. Например, хост может предоставить сертификат аттестации хоста, указывающий, что хост запросил сертификат с использованием подсистемы защиты хоста. KDS 235 проверяет, что сертификат 257 аттестации удовлетворяет требованиям политики. Затем он дешифрует мастер-ключ vTPM, который зашифрован ключом KDS, и повторно шифрует его одним или несколькими открытыми ключами хоста и переносит его защищенным образом в соответствующее программное обеспечение безопасности на хосте. Это может быть открытым ключом хоста или ТЕЕ внутри хоста. Хост использует доставленный мастер-ключ vTPM, чтобы разблокировать vTPM, и предоставляет vTPM в качестве услуги для гостевой VM, которая может извлечь из vTPM ключи, необходимые для начала процесса дешифрования экранированной VM 208. Криптографически надежное сообщение посылается инфраструктурой безопасности, подтверждающей успех или неудачу операции. Ни один из этих этапов не связан с VMM 253.

[0072] 3. В конце процесса, критичного для безопасности, который дешифрует VM 208, VMM 253 продолжает нормальные операции по развертыванию и конфигурированию. VMM 253 уведомляется об успехе или неудаче операции, что является ценной информацией для нормальных операций эксплуатации и обрабатывается посредством VMM 253, как и все другие уведомления, но так как VMM 253 не является доверительной, то предусмотрительный арендатор также будет подтверждать прием защищенного сообщения.

[0073] Как видно из этого описания, VMM 253 не принимает участия в критичных для безопасности операциях, таких как аттестация хоста и распределение ключей. VMM 253 обеспечивает автоматизированную координацию, но безопасность обеспечивается инфраструктурой безопасности и не является уязвимой по отношению к операциям VMM 253.

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

Применение модели для других операций VM

[0075] В течение жизненного цикла VM 208, VMM 253 координирует много операций помимо развертывания. Те же самые доверительные отношения и та же модель операции и управления ключами применяются во всех этих сценариях, с редкими специальными соображениями.

Миграция VM от хоста к хранилищу

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

[0077] 1. VMM 253 принимает обычные решения и отсылает обычные инструкции на VM 231 хоста, чтобы приостановить или отключить VM 208.

[0078] 2. Хост 230 делает то, что требуется, чтобы защитить VM 208 во время этой операции. Это может включать в себя шифрование других артефактов VM, таких как метаданные, описывающие VM 208, и состояние процессора и содержимое памяти и файлов виртуальной памяти, и тот же механизм переноса ключей используется для этих других артефактов. Для получения дополнительной информации на одном из примеров того, как это может быть достигнуто, см. раздел под названием ʺГарантии виртуальной машиныʺ ниже.

[0079] 3. Когда этот процесс защиты завершен, хост 230 приостанавливает или отключает VM 208 со всеми ее зашифрованными данными и необходимыми ключами, защищенными посредством vTPM 220, который, в свою очередь, зашифрован и защищен, VMM 253 продолжает нормальный процесс хранения и нормальное управление сохраненным контентом. Например, VMM 253 может вызвать сохранение экранированной VM 208 в системе 250 хранения.

[0080] Подобно тому, как в процессе развертывания VM, VMM 253 находится полностью вне критичных для безопасности операций: VMM 253 не только не участвуют в процессе шифрования и обмене ключами, но и хранимые ею данные защищены с помощью шифрования, и она не принимает участия в подтверждении успешной защиты VM 208.

Миграция VM на другой хост

[0081] Современные платформы виртуализации поддерживают несколько форм миграции VM с одного хоста на другой: прямая миграция поддерживает исполнение VM без прерывания. Непрямая миграция связана с прерыванием обслуживания, но имеет менее жесткие относящиеся к среде требования. Такая миграция может быть сделана различными способами, основанными на характере платформы виртуализации и систем хранения и сетевых систем. VMM 253 понимает формы миграции, которые можно сделать в данной структуре, и знает, как инициировать и координировать подобные действия. Для миграции экранированных VM, одна модель некоторых вариантов осуществления изобретения, которая комбинирует эти требования, выглядит следующим образом:

[0082] 1. VMM 253 принимает обычные решения о типе и месте назначения миграции, а затем инструктирует хост-источник 230 инициировать миграцию к выбранному целевому хосту 259.

[0083] 2. Хост-источник 230 вступает в защищенный диалог с KDS 235, чтобы инициировать шифрование VM 208 и ее vTPM 220 и обмен требуемыми ключами, и целевой хост 259 выполняет защищенный запрос на KDS 235 для получения ключей для разблокирования vTPM 220 VM 208. VHD 208 обеспечивает шифрование не только самого VHD 205, но может гарантировать, что другие артефакты VM, такие как состояние памяти исполняемого процесса и файлов страниц и тот же механизм переноса ключей могут быть использованы для этих других артефактов, таких, как метаданные, описывающие VM, а также состояние процессора и содержимое памяти и файлов виртуальной памяти, и тот же механизм переноса ключей используется для этих других артефактов.

[0084] 3. После того, как имеется соглашение о ключах, хосты 230 и 259 сигнализируют, что они готовы приступить к миграции, и VMM 253 посылает обычные команды на хосты 230 и 259 для типа миграции, которая должна быть выполнена. В некоторых вариантах осуществления, VMM 253 выдает инструкции на инициирующий хост, и этот хост берет на себя все остальное, так что VMM не участвует в деталях миграции - но может дублировать проверку с владельцами кода миграции. В то время как предшествующее подразумевает поэтапный процесс, в некоторых методах миграции, таких, как прямая миграция, шифрование и миграция действуют вместе, выполняя постепенное шифрование объектов. Таким образом, операции могут не разделяться на отдельные этапы, исполняемые последовательно, как описано здесь. Например, операции могут перемежаться так, что шифрование и миграция выполняются для сегментов операции в соответствии с требованиями процедуры миграции с использованием стандартных процедур, хорошо известных специалистам в данной области техники. Таким образом, различные альтернативы могут вводиться для реализации миграции в пределах объема вариантов осуществления настоящего изобретения.

[0085] Как указано выше, имеется минимальное изменение в координации VMM, и VMM 253 не принимает участия в каких-либо критичных для безопасности рабочих процессах. Безопасное уведомление об успехе или неудаче осуществляется с помощью защищенной инфраструктуры, в то время как VMM 253 получает обычные уведомления и реагирует на них обычным способом.

Обход отказа внутри кластера

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

[0087] Если VM, составляющие кластер приложений, экранированы, то ключи доступны на целевой системе, когда происходит обход отказа. Если все системы активны, ключи предоставлены на хосты во время первоначального развертывания, и никакой специальной обработки не требуется во время обхода отказа. Но в активно-пассивной конфигурации существует несколько опций. Например, можно рассматривать такой обход отказа как миграцию, при этом целевой хост 259 выполняет тот же тип запроса доставки ключа, как описано выше, но введение действий, таких как распределение ключей во время обхода отказа, могло бы снизить доступность и быстроту реагирования. В некоторых реализациях, ключи предоставляются вместе с VM на все релевантные хосты в кластере, активные или нет, с использованием процесса развертывания, описанного выше. Это позволяет программному обеспечению управления кластером выполнять операцию обхода отказа с использованием обычных методов управления или контроля, с участием или без участия VMM 253, не оказывая влияния на то, как выполнена защита VM. Такое выполнение защищает VM как от VMM 253, так и программного обеспечения управления кластером, таким же образом, как и в сценариях развертывания и миграции, описанных выше.

Миграция в другой центр обработки данных

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

[0089] - Если два центра обработки данных совместно используют службы безопасного хостинга, такие как HAS 258 и KDS 235, перекрестная миграция центров обработки данных комбинирует операции по управлению и безопасности таким же образом, как и в случае миграции, описанном выше, хотя физическая миграция артефактов может использовать другие методы, как обычно используется для переносов на большие расстояния.

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

[0091] - Если две службы безопасного хостинга не имеют доверительного отношения, арендатор или служба поддержки извлекает VM 208 и ее соответствующие ключи и переносит их на целевой центр обработки данных в процессе, аналогичном тому, как исходная VM была перенесена в центр обработки данных, как описано ниже.

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

Создание арендатором экранированных VM на основе частных артефактов

[0093] Арендатор может создать экранированную VM из обычных незащищенных артефактов, но полезным для арендатора является иметь возможность защитить артефакты с самого начала, пройдя через подходящий процесс создания VM в частной вычислительной среде и шифрования VM и ее VHD с помощью стандартных инструментов, таких как Microsoft BitLocker, в рамках этой частной среды. Эти защищенные артефакты могут затем переноситься в центр обработки данных поставщика услуг и сохраняться в библиотеке хранения VM с использованием обычных механизмов передачи файлов и запускаться в качестве VM с помощью VMM 253. Для обеспечения возможности запуска экранированной VM, ключ защиты арендатора переносится к поставщику услуг и предоставляется в KDS 235. В одном варианте осуществления, арендатор снабжается открытым ключом KDS поставщика услуг во время процесса предоставления учетной записи или в другое подходящее время, используя безопасный перенос. Ключ защиты VM хранится в защищенной иерархии хранения vTPM, который, в свою очередь, защищен с помощью открытого ключа KDS. После переноса к поставщику услуг, эта экранированная компоновка VM, защищенная таким образом, может быть дешифрована посредством KDS и с этого времени обрабатываться с использованием методов, описанных в данном документе.

Создание арендатором экранированных VM на основе шаблонов

[0094] В облачных вычислениях является общепринятым, что поставщик услуг предлагает галерею шаблонов, обеспечиваемых поставщиком услуг, независимыми поставщиками программного обеспечения (ISV), системными интеграторами и другими сторонними поставщиками. Такой шаблон представляет собой полное или частичное определение VM, которая еще не адаптирована к требованиям арендатора и еще не снабжена идентификацией учетной записи, паролями администратора, программным обеспечением или другими конфиденциальными данными. Такое обобщение системы и ее последующая специализация могут быть сделаны с помощью утилиты Microsoft sysprep или другой соответствующей утилиты, в комбинации с другими инструментами, такими как диспетчер загрузки.

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

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

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

[0098] При создании экранированных VM из шаблона является общепринятым, что каждая VM защищена уникальным ключом, но этапы проверки подлинности и шифрования или повторного шифрования (перешифрования) занимают определенное количество времени, и для создания крупномасштабных приложений может быть полезным избежать этой задержки для каждой из VM, особенно во время автоматического предоставления VM в ответ на увеличение нагрузки. Чтобы защитить VM от других арендаторов и поставщика услуг, но избежать задержки для каждой VM, могут выполняться этапы проверки подлинности и шифрования или перешифрования без специализации шаблона, чтобы создать шаблон, который зашифрован ключом, специфическим для арендатора, что позволяет создавать экранированные VM из этого шаблона без трудоемких криптографических задач для каждой экранированной VM.

[0099] Для того, чтобы защитить эту виртуальную машину и любые секреты, которые арендатор вводит в VM, от персонала поставщика услуг, отношение между VMM и безопасной инфраструктурой следует модели, используемый в других местах в вариантах осуществления изобретения: арендатор создает определение задачи, которое включает в себя информацию, необходимую для создания, и защищает это определение задачи с помощью цифровой подписи, шифрования или комбинации шифрования и подписи, и это защищенное определение задачи переносится на VMM 253, которая не может дешифровать или изменить его, и защищенное определение задачи переносится в безопасный процесс, который запрашивает от KDS 235 ключ, чтобы разблокировать определение задачи способом, используемым в вариантах осуществления изобретения, и центральная задача проверки подлинности и шифрования или дешифрования и шифрования выполняется с помощью безопасного процесса как атомарная задача, которая не может быть прервана или модифицирована посредством VMM 253. VMM 253 выполняет другие полезные задачи до и после безопасного создания обычным способом, например, верификацию и загрузку учетной записи арендатора, сохранение экранированной VM, развертывание VM и уведомление арендатора о результатах операции. Сообщение, подтверждающее завершение задачи, является доверительным, поскольку оно содержит информацию, которая известна только безопасному процессу, и подписано цифровой подписью с помощью безопасного процесса с использованием сертификата, корнем которого является секретный ключ провайдера услуг, и, таким образом, защищено от несанкционированного вмешательства со стороны персонала поставщика услуг.

[00100] Арендатору может понадобиться развернуть и извлечь экранированную VM для исполнения в частном облаке или у другого поставщика услуг. Если арендатор имеет центр обработки данных с аналогичной хостинг-структурой для защиты VM со службами безопасного хостинга, то может быть использован перенос между центрами обработки данных, как описано выше. Если поставщик услуг и арендатор установили доверительное отношение, перенос может протекать, как описано выше. Если они этого не делают, то арендатор может запросить, чтобы VM была зашифрована обычным способом, и мастер-ключ vTPM был зашифрован ключом, принадлежащим арендатору, это позволяет переносить VM с помощью обычных механизмов переноса данных и открывать арендатором. Этот подход реализуется, когда ассоциация между VM и открытым ключом арендатора является безопасной и защищенной от несанкционированного вмешательства, чтобы предотвратить попытки взломщика имитировать арендатора, подставляя другой открытый ключ и извлекая мастер-ключ vTPM. Некоторые известные методы существуют для криптографической защиты этой ассоциации: открытый ключ арендатора может быть включен в метаданные VM, которые зашифрованы и защищены посредством vTPM и, следовательно, доступны для KDS или проверенного хоста, но не для взломщика; в качестве альтернативы, ID арендатора может быть защищен таким образом, и таблица перекодировки доступна в KDS для идентификации открытого ключа арендатора из ID арендатора. В одной реализации, метаданные VM включают в себя мастер-ключ vTPM, зашифрованный открытым ключом арендатора, что позволяет переносить VM к арендатору с помощью простого механизма переноса данных без участия KDS или других услуг, связанных с безопасностью.

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

Метод поддержки

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

Предоставление, конфигурирование и аттестация хостов

[00103] Безопасность виртуальных машин зависит от целостности хоста, который должен исполнять только корректное программное обеспечение без каких-либо вредоносных программ, таких как ʺруткитыʺ (программные средства, скрывающие последствия взлома), и без каких-либо старых версий программного обеспечения с уязвимостями и должны иметь корректные настройки конфигурации и корректные политики. Эти хосты, как правило, предоставляются и конфигурируются с обычными системами управления структурой (например, FM 254), и в соответствии с моделью угрозы некоторых вариантов осуществления настоящего изобретения FM-254 не является частью доверительной вычислительной базы, по тем же причинам, как обсуждалось для VMM 253: FM 254 является большой и сложной системой, а арендатору нежелательно расширять доверие на обслуживающий персонал, работающий на FM 254. Некоторые варианты осуществления настоящего изобретения не требуют замены существующего FM 254 на специальные инструменты или методы - такое изменение может быть обременительным для IT-персонала поставщика услуг, который пользуется существующими процессами, основанными на существующих инструментах, и в любом случае было бы сложно предотвращать использование многообразия существующих инструментов и интерфейсов. Ввиду этого, некоторые варианты осуществления настоящего изобретения основаны не на попытках предотвратить неверные конфигурации или компрометацию. Скорее всего, эти варианты основаны на обнаружении неверно сконфигурированного или скомпрометированного хоста, на исключении такого неверно сконфигурированного или скомпрометированного хоста из хостинг- структуры и на подтверждении успешных и нескомпрометированных операций.

[00104] Когда хост 230 получает экранированную VM 208 и делает запрос 256 на KDS 235, чтобы получить ключ vTPM, он включает сертификат 257 аттестации, чтобы продемонстрировать, что он соответствует определенным политикам. Например, сертификат аттестации может указывать, что хост 230 является известным членом структуры, и что он исполняет корректное программное обеспечение, и что действуют корректные политики, релевантные для безопасности. Система обычно не подтверждает надежным образом свою собственную целостность. Чтобы получить этот сертификат аттестации, хост 230 делает запрос 260 к службе аттестации хоста (HAS). Этот запрос может включать в себя несколько фрагментов информации, которые являются релевантными для доверия к целостности хоста. В одном варианте осуществления, запрос включает в себя информацию, такую как одна или более из следующих:

[00105] - Ключ, который получен из физического модуля доверительной платформы (TPM) 261 хоста 230, такой как ключ подтверждения. Этот ключ сравнивается со списком известных ключей сервера, который был предоставлен при поставке сервера 251 центру обработки данных. Список ключей сервера содержится в декларации, которая поставляется защищенным образом, параллельно с поставкой сервера. Возможны альтернативные способы идентификации.

[00106] - Измерения программного обеспечения, включенного в процесс загрузки, как предоставляется модулем 462 унифицированного расширяемого интерфейса прошивки (UEFI) или другим программным обеспечением загрузки и подписывается посредством ТРМ 261.

[00107] - Сертификат, который идентифицирует, что запрос исходит из защищенной подсистемы программного обеспечения хоста. Различные способы реализации таких защищенных подсистем известны специалистам в данной области техники. В одном варианте осуществления, эта подсистема может быть реализована в виде функций, исполняющихся в ядре VM хоста. В другой реализации она может исполняться в гипервизоре. В других вариантах осуществления она может быть реализована в виде отдельного адресного пространства, созданного гипервизором с использованием возможностей отображения памяти процессора. В других вариантах осуществления она может быть реализована в виде отдельной зоны исполнения, созданной процессором (такой как TrustZone архитектуры ARM или появляющаяся возможность SGX, описанная Intel). Эти различные реализации могут предложить сходные функциональные возможности, такие как способность выполнять криптографические операции, хранить учетные данные, подтверждать целостность кода или данных и защищать секреты способом, сходным с vTPM. Они могут отличаться по уровню безопасности, которую они предлагают. Варианты осуществления настоящего изобретения могут работать в различных реализациях, так как варианты осуществления изобретения зависят от функциональных возможностей, а не от уровня безопасности.

[00108] - Сертификат подписания политик целостности кода хоста, включая обеспечиваемую гипервизором целостность кода (HCVI) 263 и AppLocker (они защищают VM от вторжения хостом). В качестве альтернативы, варианты осуществления могут рассматривать другие механизмы виртуализации, которые не имеют VM хоста. Например, HVCI и AppLocker (от Microsoft Corporation, Редмонд, шт. Вашингтон) являются примерами проверки целостности кода хоста. В качестве альтернативы могут быть использованы и другие альтернативные варианты.

[00109] - Открытый ключ компонента программного обеспечения безопасности, чтобы позволить HAS 258 устанавливать безопасную связь с хостом.

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

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

[00112] HAS 258 сравнивает эту информацию со спецификациями в политике 264 аттестации, и если она совпадает с политикой 264, то возвращает сертификат 257 аттестации, подписанный посредством HAS 258. Если информация хоста не соответствует политике 264, и, таким образом, если хост некорректно сконфигурирован или скомпрометирован, то служба аттестации обнаруживает это и отказывается предоставить сертификат 257 аттестации, что означает, что хост 230 не получает ключ 255, чтобы разблокировать vTPM 220 и, следовательно, VM 208.

[00113] Таким образом, варианты осуществления настоящего изобретения допускают стандартный набор инструментальных средств FM для предоставления и конфигурирования хостов. Целостность хостов контролируется посредством HAS 258 и подтверждается сертификатом 257 аттестации. Этот сертификат 257 аттестации используется посредством KDS 235 для того, чтобы обеспечить возможность развертывания и миграции экранированных VM под управлением VMM 253, и как VMM 253, так и FM 254 уведомляются об успехе и неудаче и обрабатывают эти результаты в соответствии со стандартными политиками и процедурами управления, например, реагирующими на неудачу аттестации хоста путем помещения VM 208 на другой хост, который соответствует политике 264.

[00114] FM 254 и VMM 253 могут принимать другие меры по изоляции или реабилитации хоста 230 при обнаружении неудачи аттестации и возможной компрометации. Например, поставщик услуг может иметь политику, чтобы принимать решение, что делать с известным хостом, который, как ожидалось, пройдет аттестацию, но позже терпит неудачу в аттестации: осторожный подход заключался бы в ʺпостановке на карантинʺ хоста и отказе в разрешении соединяться с сетью или хостинг-структурой; более практичным подходом могло быть исключение его из хостинга, но сохранение в сети для устранения неполадок и смягчения их последствий.

[00115] Таким образом, разделение ответственности между FM 254 и службой безопасного хостинга может работать таким же образом, как разделение между VMM 253 и службой безопасного хостинга, с аналогичными преимуществами: FM 254 обеспечивает автоматизацию и координацию управления структурой, для экономической эффективности, скорости и надежности, но критичные для безопасности аспекты структуры обеспечиваются службами безопасного хостинга и не подвергается воздействию FM 254 или персонала, уполномоченного для работы.

Изменения в VMM для полной поддержки экранированных VM

[00116] Операции VMM 253 не требуют существенных изменений относительно ранее существовавших VMM для поддержки операций на экранированных VM, но незначительные изменения могут быть введены, чтобы способствовать использованию арендаторами и поставщиком услуг. Например, безопасный хостинг-процесс вводит возможность новых типов отказов, таких как неудача аттестации хоста и, как следствие, неудача развертывания VM или миграции на этот хост. Как это имеет место с другими видами отказов, VMM 253 должна понимать такие сообщения об отказе и должна предпринимать корректирующие действия, такие как поиск другого хоста для развертывания, сообщение об отказе персоналу поставщика услуг для реабилитации, уведомление арендатора об отказе, если автоматическая реабилитация не представляется возможной, или если имеет место ухудшение качества услуг или невыполнение соглашений об уровне обслуживания, включение события в отчеты и исключение отказавшего хоста из будущих действий, пока он не будет восстановлен.

[00117] VMM 253 может также представлять, в пользовательских интерфейсах и интерфейсах программирования, опции для обеспечения защиты в выгрузке VM, создании и извлечении рабочих процессов. И VMM 253 может предоставлять средства, чтобы позволить поставщику услуг присоединять различные цены для экранированных VM машин и интегрировать подобные коммерческие вопросы.

[00118] В некоторых вариантах осуществления настоящего изобретения, эти полезные функции не являются критическими для безопасности, поскольку защита VM опирается на безопасную инфраструктуру хостинга, а не на недоверительную VMM. Если VMM или ее база данных скомпрометированы, операционная эффективность и уровни обслуживания в центре обработки данных могут быть снижены, но безопасность VM не будет скомпрометирована.

Размещение экранированных VM на хостах с поддержкой безопасности

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

[00120] В течение аналогичного переходного периода, некоторые VM могут быть экранированы, а другие нет, потому что их рабочие нагрузки не считаются достаточно чувствительными, чтобы оправдывать усилия или затраты на защиту, или потому, что арендатор еще не прошел через процесс или политику переходного периода для защиты всех рабочих нагрузок.

[00121] При такой среде гетерогенных хостов и гетерогенных рабочих нагрузок, VMM 253 требует управления размещением защищенных рабочих нагрузок на хостах с поддержкой безопасности, таких как хост 230, чтобы избежать обреченных на неудачу размещений, где VM 208 будет терпеть неудачу при запуске. Кроме того, незащищенные рабочие нагрузки могут быть предпочтительно размещены на обычных хостах, чтобы оптимизировать использование ресурсов поставщика услуг и позволить поставщику услуг взимать более высокие цены за защищенное исполнение, если желательно. Типичные VMM согласуют широкий спектр потребностей в ресурсах с характеристиками хостов и используют политику для руководства размещением для оптимального использования ресурсов или других коммерческих целей. Добавление функциональной возможности защиты к этому списку характеристик и включение ее в принятие решения о размещении является очевидным. VMM 253 поддерживает эти атрибуты в своем реестре хостов в центре обработки данных. На практике это будет включать в себя механизм обнаружения, чтобы идентифицировать хосты с этой возможностью. Этот реестр должен быть связан с HAS 258: может быть известно, что хост имеет аппаратные возможности, но если он в какой-либо момент не проходит процесс аттестации, возможно, потому что он был скомпрометирован, он временно удаляется из списка хостов с обеспечиваемой защитой.

[00122] Но так как VMM 253 и ее операционный персонал не являются доверительными, это размещение делается таким образом, что сохраняет защиту, несмотря на возможность того, что сотрудник поставщика услуг с привилегиями администратора может иметь возможность изменить базу данных реестра хостов в VMM 253 или скомпрометировать алгоритм принятия решения о размещении. Автоматизированное управление реестром и алгоритм размещения играют важную роль в надежных и эффективных операциях в центрах обработки данных, но не играют роли в защите рабочих нагрузок. Должно быть очевидно из приведенного выше описания, что это принято во внимание: если VMM 253 скомпрометирована и вынуждена развернуть экранированную VM на недействительном хосте, то хост не сможет принять участие в процессе распределения ключей с KDS и не будет способен разблокировать и загрузить экранированную VM, поэтому никакие данные арендатора не будут скомпрометированы.

Реакция на изменения политики в хостах

[00123] В различное время политики безопасности на хостах, такие как политика подтверждения целостности кода (CI) (иногда называемая здесь как обеспечиваемая гипервизором политика целостности кода (HVCI)), нуждаются в изменении. Например, рассмотрим обновления программного обеспечения как управляемые посредством FM 254: поставщик услуг может быть уведомлен о том, что новая версия драйвера была выпущена, поскольку в предыдущей версии было обнаружено, что она имеет уязвимость по безопасности. В этом случае, новая версия должна быть добавлена в список разрешенного программного обеспечения, а предыдущая версия должна быть добавлена в список запрещенного программного обеспечения. В таких случаях может быть важным, что политика CI обновляется в то же самое время, что и обновление драйвера: если драйвер обновляется первым, прежде чем политика была обновлена, драйвер не получит разрешение на исполнение, и система может функционировать некорректно. Если этот процесс не управляется корректным образом, то широко распространенное обновление программного обеспечения может блокировать весь центр обработки данных. По этой причине, обновление программного обеспечения и обновление политики координируются. В одной реализации, обновление политики упаковывается и распространяется в виде обновления программного обеспечения (ʺпатчʺ, заплата), и отношение старшинства определяется так, что обычное программное обеспечение внесения исправлений будет развертывать обновление политики перед обновлением программного обеспечения, и в конечном итоге запускать перезагрузку, требуемую, чтобы сделанные обновления политики 264 и драйвера вступили в силу. Опираясь на существующее программное обеспечение внесения исправлений, FM может с выгодой использовать существующую автоматизацию, такую как координация ʺскользящего обновленияʺ по диапазону хостов, чтобы избежать распространенных прерываний обслуживания или прямой миграции VM на другой хост до обновления и перезагрузки каждого хоста.

[00124] Но есть еще одно изменение, которое координируется: HAS 258 подтверждает, что действует правильная политика CI, так что опять же, если политика 264 аттестации не обновляется, чтобы распознать и разрешить обновленную политику CI, сервер 251 не пройдет аттестацию и не будет допущен к участию в структуре. Процесс начинается с определения патча и обновленной политики CI на основе полученной информации. Затем новая политика CI добавляется к политике 264 аттестации. Затем патч откачивается на серверы в некотором управляемом порядке. И, в конечном счете, когда все серверы обновлены, и HAS 258 больше не принимает запросы на аттестацию со старой политикой CI, старая политика CI может быть удалена из политики 264 аттестации. Этот процесс находится под контролем IT-персонала поставщика услуг, который утверждает обновления и планирует их применение. Технология поддерживает упорядоченный и безопасный процесс, но не устраняет потребность в контроле управления персоналом.

[00125] В некоторых вариантах осуществления настоящего изобретения, управление этими изменениями с обычными инструментами FM отделена от безопасности центра обработки данных, которая обеспечивается инфраструктурой безопасности. Сотрудничество является ценным для плавной и эффективной работы, но компромиссом систем управления, чтобы не подвергать VM компрометации.

Отчетность о состоянии, связанном с безопасностью, и отказах

[00126] В некоторых вариантах осуществления настоящего изобретения, VMM 253 находится полностью вне критичных для безопасности операций: VMM 253 не только не участвуют в процессе шифрования и обмена ключами, она также не участвует в подтверждении успешной защиты экранированной VM 208. Защищенное развертывание может терпеть неудачу по ряду причин, связанных с безопасностью: хост 230 может не пройти аттестацию, так как он был скомпрометирован или из-за того, что политика 264 изменилась после первоначального развертывания, HAS 258 или KDS 235 могут быть скомпрометированы или могут выйти из строя. VMM 253 будет получать уведомление об этом отказе и будет сообщать об этом так же, как она обрабатывает обычные отказы, не связанные с безопасностью. Но VMM 253 не является доверительной, чтобы сообщать об отказах, связанных с безопасностью, так как злонамеренный администратор VMM мог бы фальсифицировать сообщение об успешном выполнении, даже если защита потерпела отказ из-за компрометации. Таким образом, в то время как VMM 253 выполняет негарантированный отчет, который полезен для повседневных операций, служба безопасного хостинга также посылает уведомление о событии отказа, которое посылается в доверительную систему отчетности о событиях. Это подтверждающее сообщение является криптографически надежным и подписывается инфраструктурой безопасности хоста 230 и KDS 235.

Разделение привилегий между несколькими IT-сотрудниками

[00127] В то время как некоторые варианты осуществления настоящего изобретения исключают системы общего управления (VMM 253 и FM 254) из любой роли в обеспечении безопасности центров обработки данных, HAS 258 и KDS 235, напротив, в некоторых вариантах осуществления, играют важную роль. В частности, HAS 258, в некоторых проиллюстрированных примерах, является источником доверия в хостах: если политика аттестации скомпрометирована, чтобы допускать вредоносное программное обеспечение на хосте, вся модель безопасности может потерпеть неудачу.

[00128] Таким образом, HAS 258 и KDS 235 защищены от компрометации. Так как одна из угроз, которая может рассматриваться, представляет собой угрозу злонамеренного администратора с доступом к хостам, VMM 253 или FM 254, привилегии администратора для HAS 258 и KDS 235 отделены от таковых для общих администраторов хоста или структуры. В частности, HAS 258 и KDS 235 не управляются посредством VMM 253 или FM 254. Кроме того, рекомендуется, чтобы они не присоединялись к тому же домену или лесу (набору несмежных деревьев), что и хосты.

[00129] Такое разделение привилегий помогает гарантировать, что успешная атака требует сговора между обычным администратором и специальным, высоко привилегированным администратором, ответственным за политику аттестации.

[00130] Таким образом, общая архитектура системы и, в частности, HAS 258 и KDS 235 могут быть сконструированы таким образом, что они не требуют какого-либо общего управления между HAS 258 и KDS 235, с одной стороны, и хостами, FM-254 и VMM 253, с другой стороны. Они не должны находиться в том же самом домене или лесу.

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

Расширения

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

Специфический для арендатора мастер-ключ KDS

[00133] В одной реализации, KDS 235 защищает ключи vTPM, зашифровывая их мастер-ключом, принадлежащим KDS 235. Но ключ vTPM также может быть зашифрован отдельным мастер-ключом для каждого арендатора, чтобы усилить защиту и изоляцию или для удовлетворения нормативным требованиям соответствия. Мастер-ключ KDS 235 может быть защищен посредством ТРМ, но также может быть желательным хранить специфические для арендатора ключи в аппаратном модуле безопасности (HSM), поскольку это обеспечивает безопасный обмен ключами между средой арендатора и HSM поставщика услуг, и для инициированного арендатором удаления мастер-ключа, среди других преимуществ.

[00134] Если структура использует или поддерживает специфические для арендатора мастер-ключи, некоторые варианты осуществления настоящего изобретения предусматривают и поддерживают это, обеспечивая разделение автоматизации управления от критичных для безопасности функций. Никаких существенных изменений не требуется при взаимодействии между VMM 253, FM 254, HAS 258, KDS 235 или хостами. Для удобства работы, VMM 253 должны обеспечивать незначительные функции операционной поддержки, такие как отражающие идентификацию арендаторов в отчетности и уведомлениях, а также должны распознавать и обрабатывать дополнительные условия отказа, такие как несогласованные ID арендатора.

[00135] В вариантах осуществления, операции VM, описанные выше, используют одно существенное изменение для поддержки использования HSM: VM 208 и ее метаданные включают в себя ID арендатора, доступный в незашифрованном виде для хоста 230, так что хост может включать ID арендатора в запрос освобождения ключа, который он передает в KDS 235. По меньшей мере в некоторых вариантах осуществления, эта ассоциация между VM 208 и ID арендатора позволяет автоматизировать управление и/или обеспечивает удобные функции, такие как пользовательские интерфейсы и отчеты, но не является критичной для безопасности и не должна быть защищена от фальсификации, поэтому если подставляется ложный ID арендатора, то предоставляется неверный ключ шифрования, и vTPM 220 не может быть дешифрован.

Поддерживаемые арендатором ключи

[00136] Варианты осуществления системы могут быть настроены таким образом, что арендаторы несут ответственность за исполнение KDS 235, возможно, в их собственном центре обработки данных, и службы безопасного хостинга поставщика услуг выходят на арендатора всякий раз, когда им нужен ключ для выполнения операции VM. В другом варианте осуществления, арендатор может заключить договор со сторонним поставщиком, чтобы задействовать KDS 235 от имени арендатора, изолированным от поставщика услуг хостинга.

[00137] Варианты осуществления настоящего изобретения могут быть легко расширены для поддержки такого сценария. KDS 235 будет использовать ID арендатора, который хранится в открытом виде с VM 208, и отыскивать сетевой адрес в таблице перекодировки. Опять же, эта ассоциация между VM 208 и ID арендатора позволяет автоматизировать управление, обеспечивает удобные функции, такие как пользовательские интерфейсы и отчеты, но не обязательно является критичной для безопасности: если взломщик подставляет недействительный ID арендатора, то KDS 235 будет обращаться к KDS некорректного арендатора и извлекать недействительные ключи или вообще ничего.

[00138] Даже при извлечении ключа vTPM 255 от арендатора, необходимость верификации целостности хоста остается, что может быть сделано с использованием HAS 258. Хотя возможно, что арендатор предоставляет HAS 258 для проверки подлинности некоторых аспектов конфигурации хоста, другие аспекты конфигурации хоста не доступны для арендатора, как, например, идентифицирующие ключи известных серверов. Поэтому одна реализация использует два этапа: сначала безопасный диалог между хостом 230, HAS 258 и KDS 235 происходит, как описано здесь, чтобы подтвердить работоспособность хоста 230 и выпустить первый ключ, необходимый для разблокирования VM 208, и затем KDS 235 или хост 230 обращается к службе арендатора, чтобы извлечь ключ завершения, возможно, включая информацию аттестации. При доставке ключа как поставщика услуг, так и арендатора, VM может быть дешифрована.

[00139] Рассмотрение следующих вопросов может быть принято во внимание при такой реализации:

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

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

Комплексная политика в KDS

[00142] При принятии решения выпустить ключ 255 vTPM, KDS 235 просматривает только сертификат 257 аттестации хоста: если хост является действительным и целостным, она выпускает ключ.

[00143] Варианты осуществления настоящего изобретения могут быть легко расширены для реализации более сложной политики, чтобы определить, следует ли выпустить ключ, что учитывает другую информацию о запросе 256, VM 208 и арендаторе. Например, система поддерживает перенос VM на другое оборудование, с которым поставщик услуг имеет доверительное отношение. Но арендатору может понадобиться ограничить такие перемещения, по соображениям национального суверенитета данных или соответствия другим нормативным требованиям или исходя из осторожности в принципе. Такие политики могут быть реализованы через автоматическую систему политики, или могут включать в себя подтверждение человеком рабочих процессов.

[00144] KDS 235 может поддерживать такие политики, требуя только, чтобы достаточное количество метаданных об операции VM предоставлялось с запросом 256, как обсуждалось в случае поддерживаемых арендатором ключей - в самом деле, цели и реализации по существу одинаковы. Но так как KDS 235 работает на многопользовательском оборудовании поставщика услуг, целостность политики защищается с криптографической стойкостью. Рекомендуемая реализация состоит в том, что арендатор, или привилегированный администратор поставщика услуг, подписывают политики, а KDS 235 верифицирует сертификат подписи по отношению к известным сертификатам арендатора или поставщика услуг.

[00145] VMM 253 может включать в себя расширения, чтобы позволять арендатору вводить политику и представлять сообщения об отказе, когда операция VM запрещена политикой.

Обобщение на другие сценарии

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

Другие объекты, которые могут нуждаться в безопасном переносе секретов

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

[00148] Например, в некоторой сфере интересов, такой как распределенная службы приложений, арендаторам может потребоваться защитить сетевую связь с использованием IPsec или других технологий. Эти технологии требуют переноса ключей на компонентные системы. Есть много способов сделать это, но управление безопасным переносом этих ключей обычными методами является затруднительным или громоздким, особенно в виртуальной среде, где масштабы и конфигурация службы приложений часто изменяются, например, в ответ на изменения в нагрузке трафика. А использование инструментов управления, таких как VMM 253, чтобы автоматизировать конфигурацию сети и распределение ключей, подвергает систему компрометации злонамеренными администраторами. Варианты осуществления настоящего изобретения, использующие vTPM для защиты ключей шифрования VM, могут быть обобщены для защиты любого типа ключа или другого секрета, что дает возможность использовать варианты осуществления настоящего изобретения, чтобы надежно автоматизировать распределение таких секретов.

[00149] Примерами элементов расширения к этому сценарию являются (а) механизм, который требует надежной доставки ключей, сертификатов или других секретов на компоненты в распределенной системе, (b) служба безопасности с функциями, аналогичными таковым в HAS 258 и KDS 235, (с) система автоматизации управления с функциями, аналогичными VMM 253, и (d) взаимодействие между ними по схеме, проиллюстрированной выше, где система управления координирует процессы, но не участвует в критичных для безопасности операциях.

Другие сценарии, которые требуют проверяемого или секретного переноса данных

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

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

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

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

[00154] Такие данные конфигурации могут принимать различные формы, такие, как бинарные файлы в некотором проприетарном формате, XML-файлы или JSON-файлы. Независимо от формата, их безопасность и целостность могут быть защищены с использованием криптографической технологии, а ключи защищаются и распространяются с использованием схем, описанных выше.

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

[00156] Элементами расширения для этого сценария являются: (а) механизм, который использует криптографическую технологию для подтверждения подлинности или сохранения конфиденциальной информации при доставке к компонентам в распределенной системе, (b) безопасное обслуживание с функциями, аналогичными таковым для HAS 258 и KDS 235, (с) система автоматизации управления с функциями, аналогичными VMM 253, и (d) взаимодействие между ними, следуя схемам, проиллюстрированным выше, где система управления координирует процессы, но не участвует в критичных для безопасности операциях.

Защита контейнеров иных, чем VM

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

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

[00159] Другим примером является файловая служба или служба хранения, которая содержит информацию от множества арендаторов, организованную и управляемую в группировках, которые могут называться ʺучетной записью храненияʺ.

[00160] Другим примером является служба базы данных, которая содержит информацию от множества арендаторов, организованную и управляемую в контейнерах, называемых базами данных.

[00161] Службы, такие как указанные выше, часто развертываются в распределенных, ʺмасштабируемыхʺ конфигурациях с множеством серверов, часто VM, взаимодействующими при обработке нагрузки, под контролем инфраструктуры управления.

[00162] Информация, содержащаяся в таких контейнерах, возможно, заслуживает такой же защиты, как VM, описанные выше. Варианты осуществления настоящего изобретения могут быть применены таким же образом, как и для экранированных VM. Роль VMM 253 играет эквивалентная система управления, которая развертывает и управляет упрощенными контейнерами, такими как диспетчер задач в системе хостинга приложений, ʺброкерʺ для RDS, или распределенная система управления базами данных для баз данных, и как в случае VMM 253, во многих случаях, диспетчер контейнера и его операционный персонал не будут доверительными (отметим, что диспетчер контейнера и хостинг контейнера не ограничены одной VM хоста, но могут быть и, вероятно, будут распространяться на множество VM). Роль хоста 230 в случае VM играет экземпляр машины, физическая машина и/или VM, которая может участвовать в таком же безопасном обмене с KDS 235, как и в случае VM, хотя технические детали аттестации могут отличаться, так как ʺхостʺ в данном случае не выводит свою целостность непосредственно из физического ТРМ или UEFI, а выводит ее из целостности VM. При применении вариантов осуществления настоящего изобретения к таким упрощенным контейнерам, система управления ключами может не быть vTPM, так как в современной практике экземпляр машины может иметь только один ТРМ, виртуальный или нет. Подобный механизм защиты может быть определен для защиты ключей для каждого контейнера, в свою очередь, защищая свою информацию через vTPM гостевой OS. И методом шифрования может быть не шифрование всего объема подобно Microsoft BitLocker, а более тонко гранулированный метод шифрования, применяемый на файловом уровне к набору файлов или к другому контейнеру, подобному папке ʺМои документыʺ в случае RDS или базе данных в случае сервера базы данных. Специфика механизма защиты зависит от конкретной среды. Модели, изложенные в настоящем документе, остаются в силе, с системой управления, обеспечивающей автоматизацию без участия в критичной для безопасности работе, и службой безопасного хостинга, предоставляющей гарантии, и ʺдоверительная вычислительная базаʺ для контейнеров ведет вниз через VSM 266 гостя, к VSM хоста 265, к аппаратным функциям.

[00163] Элементами расширения для этого сценария являются: (а) механизм для защиты информации в таких контейнерах, которые требуют безопасного распределения ключей, сертификатов или других секретов на компоненты в распределенной системе, (b) служба безопасности с функциями, аналогичными таковым в HAS 258 и KDS 235, (с) система автоматизации управления с функциями, аналогичными VMM 253, и (d) взаимодействие между ними, следуя модели, проиллюстрированной выше, где система управления координирует процессы, но не участвует в критичных для безопасности операциях.

VSM

[00164] Виртуальный безопасный режим (VSM) для виртуальных машин обсуждается ниже. Гипервизор реализует виртуальный безопасный режим, который создает множество различных виртуальных доверительных уровней, доступных для виртуальных процессоров виртуальной машины. Различные средства защиты доступа к памяти, такие как способность чтения, записи и/или исполнения памяти, могут быть ассоциированы с различными участками памяти (например, страницами памяти) для каждого виртуального доверительного уровня. Виртуальные доверительные уровни организованы в виде иерархии, в которой более высокий виртуальный доверительный уровень является более привилегированным, чем более низкий виртуальный доверительный уровень, и программы, исполняющиеся на более высоком виртуальном доверительном уровне, способны изменять средства защиты доступа к памяти более низкого виртуального доверительного уровня. Число виртуальных доверительных уровней может варьироваться и может варьироваться для различных виртуальных машин, а также для различных виртуальных процессоров в той же виртуальной машине.

[00165] На фиг. 3 показана блок-схема, иллюстрирующая примерное вычислительное устройство 300, реализующее методы, описанные в настоящем документе, в соответствии с одним или более вариантами осуществления. Вычислительное устройство 300 может представлять собой любое из множества различных типов устройств. Например, вычислительное устройство 300 может представлять собой настольный компьютер, серверный компьютер, ноутбук или нетбук, планшетный компьютер или компьютер в виде записной книжки, мобильную станцию, развлекательное устройство, приставку, коммуникативно связанную с дисплейным устройством, телевизор или другое дисплейное устройство, сотовый или другой беспроводной телефон, игровую консоль, автомобильный компьютер, носимый компьютер и т.д.

[00166] Вычислительное устройство 300 включает в себя гипервизор 302, также упоминаемый как гипервизор, а также один или несколько компонентов 304. Гипервизор 302 управляет доступом к функциональным возможностям, обеспечиваемым компонентами 304. В качестве альтернативы, гипервизор 302 может работать на операционной системе хоста (не показана), и в этом случае операционная система хоста управляет доступом к функциональным возможностям, обеспечиваемым компонентами 304.

[00167] Компонентами 304 может быть множество различных компонентов процессора, компонентов ввода/вывода (I/O) и/или других компонентов или устройств. Например, компоненты 304 могут включать в себя один или несколько процессоров или процессорных ядер, один или более компонентов памяти (например, энергозависимой и/или энергонезависимой памяти), один или несколько устройств хранения (например, оптические и/или магнитные диски, устройства флэш-памяти), один или несколько компонентов связи (например, адаптеров проводных и/или беспроводных сетей), их комбинации и т.д. Хотя иллюстрируются как часть вычислительного устройства 300, однако один или несколько компонентов 304 (например, одно или несколько устройств хранения данных) могут быть реализованы внешними по отношению к вычислительному устройству 300. Различные компоненты или модули, исполняющиеся на вычислительном устройстве 300, в том числе гипервизор 502, могут получать доступ к функциональной возможности, предоставляемой компонентами 304, прямо и/или косвенно через другие компоненты или модули.

[00168] Гипервизор 302 позволяет виртуальной машине 306 исполняться вычислительном устройстве 300. Одна виртуальная машина 306 проиллюстрирована в вычислительном устройстве 300, хотя в качестве альтернативы множество виртуальных машин могут исполняться на вычислительном устройстве 300. Виртуальная машина относится к программной реализации физического вычислительного устройства (или другой машины или системы), которая может исполнять программы аналогично физическому вычислительному устройству. Виртуальная машина включает в себя один или более виртуальных компонентов, которые аналогичны (но являются программными реализациями) компонентов 304. Операционная система, а также другие приложения могут исполняться, используя виртуальные компоненты, как если бы они использовали компоненты 304, включая исполнение на виртуальных процессорах или ядрах виртуальных процессоров, доступ к виртуальной памяти и т.д. Операционной системе и другим приложениям, исполняющимся в виртуальной машине 306, не требуется иметь знания, и, как правило, они не имеют знания о том, что они исполняются в виртуальной машине.

[00169] Виртуальная машина 306 включает в себя операционную систему 312, одно или несколько приложений 314 и один или несколько виртуальных компонентов 316. Операционная система 312 работает или исполняется на одном или нескольких виртуальных процессорах или процессорных ядрах, включенных в качестве одного или нескольких компонентов 316, и управляет исполнением приложений 314.

[00170] Гипервизор 302 включает в себя модуль 322 управления виртуальной машиной (VM) и модуль 324 виртуального безопасного режима (VSM). Модуль 322 управления виртуальной машиной управляет отображением виртуальных компонентов 316 на компоненты 304, включая планирование виртуальных процессоров или процессорных ядер для исполнения на физических процессорах или процессорных ядрах. Модуль 324 виртуального безопасного режима управляет виртуальным безопасным режимом для виртуальной машины 306, обеспечивая различные виртуальные доверительные уровни для виртуальных компонентов 316, как описано более подробно ниже. Виртуальный доверительный уровень является средой исполнения для виртуального процессора, и каждый виртуальный процессор может войти или выйти из виртуального доверительного уровня независимо от каких-либо других виртуальных процессоров. Хотя показаны как два отдельных модуля, следует отметить, что функциональные возможности модулей 322 и 324 могут быть объединены в один модуль (например, функциональные возможности модуля 324 виртуального безопасного режима могут быть включены в модуль 322 управления VM).

[00171] Модуль 324 виртуального безопасного режима делает несколько различных виртуальных доверительных уровней (VTL) доступными для виртуальных процессоров (одного или нескольких виртуальных компонентов 316) виртуальной машины 306, когда виртуальный безопасный режим задействован для виртуальной машины 306. Виртуальный безопасный режим может быть задействован или блокирован различным образом, например, в ответ на запросы от программы (например, загрузчика виртуального безопасного режима), исполняющейся на виртуальном процессоре, в ответ на настройки конфигурации гипервизора 302, в ответ на вводы, обеспечиваемые администратором или пользователем вычислительного устройства 300, и т.д. Вычислительное устройство 300 может дополнительно включать в себя множество виртуальных машин, и виртуальный безопасный режим может быть задействован или блокирован для различных виртуальных машин независимо друг от друга. Таким образом, в любой данный момент времени виртуальный безопасный режим может быть задействован для одной или нескольких виртуальных машин вычислительного устройства 300 и блокирован для одной или нескольких других виртуальных машин вычислительного устройства 300.

[00172] Гипервизор 302 обеспечивает механизм, с помощью которого операционная система 312 может обнаружить наличие поддержки виртуального безопасного режима, а также другую информацию о виртуальном безопасном режиме, такую как количество поддерживаемых виртуальных доверительных уровней. В качестве примера, гипервизор 302 может сообщать о наличии поддержки виртуального безопасного режима и количестве виртуальных доверительных уровней через виртуальный регистр (например, через лист CPUID), который может быть считан операционной системой 312.

[00173] Операционная система 312 и гипервизор 302 управляют хранением и доступом к памяти, которая состоит из нескольких блоков или частей, которые упоминаются как страницы памяти (или просто страницы). Память может быть, например, любым типом памяти, адресуемой CPU (центральным процессором) памяти, такой как энергозависимая память (например, RAM) или энергонезависимая память (например, флэш-память). Различным программам могут быть выделены страницы памяти, и эти программы могут быть приложениями 314, программами операционной системы 312 или другими компонентами или модулями.

[00174] Операционная система 312 и гипервизор 302 могут предоставлять различные типы доступа к страницам памяти с помощью программы, такие как доступ для чтения, доступ для записи и доступ для исполнения. Если доступ для чтения (также упоминается как разрешение на чтение) предоставлен для страницы памяти, то содержимое страницы памяти разрешено считывать (например, с помощью конкретных одной или нескольких программ). Если доступ для записи (также упоминается как разрешение на запись) предоставлен для страницы памяти, то разрешено записывать контент на страницу памяти (например, с помощью конкретной одной или нескольких программ). Если доступ для исполнения (также упоминаемый как разрешение на исполнение) предоставлен для страницы памяти, то код, сохраненный в (также упоминается как хранимый на) странице памяти, может исполняться.

[00175] Вычислительное устройство 300 использует виртуальную память, которая является адресным пространством, которое отображается на другое адресное пространство (например, физическую память). Приложению назначается виртуальное пространство памяти, в котором исполняется код приложения, и хранятся данные. Диспетчер памяти (например, процессора) управляет отображением адресов виртуальной памяти в виртуальном пространстве памяти на адреса в другом пространстве памяти. При отображении адресов виртуальной памяти из адресного пространства виртуальной памяти в другое пространство памяти, выполняется преобразование адресов. Таблица преобразования адресов используется для выполнения этого отображения и может быть использована для реализации методов, описанных в настоящем документе.

[00176] На фиг. 4 показан пример нескольких виртуальных доверительных уровней в соответствии с одним или более вариантами осуществления. Виртуальный процессор 402, который может представлять собой виртуальный компонент 316, показанный на фиг. 3, может исполняться в любом количестве (х) различных виртуальных доверительных уровней 404 (0), 404 (х). Виртуальные доверительные уровни 404 включены как часть виртуального безопасного режима, предоставляемого модулем 324 виртуального безопасного режима согласно фиг. 3. В одном или нескольких вариантах осуществления настоящего изобретения виртуальный процессор 402 может работать в двух различных виртуальных доверительных уровнях, упоминаемых как нормальный режим (например, VTL 0) и безопасный режим (например, VTL 1).

[00177] Каждый виртуальный доверительный уровень имеет ассоциированный с ним набор средств защиты 406 доступа к памяти. Различные виртуальные доверительные уровни могут иметь различные наборы средств защиты доступа, и набор средств защиты доступа виртуального доверительного уровня может быть использован для ограничения того, какая память может быть доступной, и/или каким образом память может быть доступной, когда виртуальный процессор работает в этом виртуальном доверительном уровне.

[00178] Каждый виртуальный доверительный уровень также имеет ассоциированное с ним состояние 408 виртуального процессора. Состояние виртуального процессора относится к различным настройкам различных регистров, значениям конфигурации и т.д. виртуального процессора 402. Отдельное состояние 408 виртуального процессора поддерживается для разных виртуальных доверительных уровней, препятствуя одному виртуальному доверительному уровню получать доступ к состоянию процессора другого виртуального доверительного уровня. Хотя некоторые состояние виртуального процессора поддерживается отдельно для различных виртуальных доверительных уровней (также упоминаемых как частное состояние процессора), другое состояние процессора (также упоминаемое как совместно используемое состояние процессора) может совместно использоваться множеством виртуальных доверительных уровней, как описано более подробно ниже.

[00179] Каждый виртуальный доверительный уровень также имеет ассоциированную с ним подсистему 410 прерываний. Подсистема прерываний обращается к многочисленным различным модулям, программам, настройкам и т.д. для управления прерываниями для виртуального процессора 402. Отдельные подсистемы 410 прерываний поддерживаются для разных виртуальных доверительных уровней, обеспечивая возможность управления прерываниями безопасным образом на одном виртуальном доверительном уровне и препятствуя программам, исполняющимся на другом (например, более низком, как описано более подробно ниже) виртуальном доверительном уровне, генерировать неожиданные прерывания или маскировать прерывания.

[00180] Виртуальные доверительные уровни организованы в виде иерархии, причем более высокий виртуальный доверительный уровень является более привилегированным, чем более низкий виртуальный доверительный уровень, а более низкий виртуальный доверительный уровень является менее привилегированным, чем более высокий виртуальный доверительный уровень. Программа, исполняющаяся на виртуальном процессоре 402, работающем на виртуальном доверительном уровне, который является более привилегированным, чем другой виртуальный доверительный уровень, может ограничить доступ к ячейкам памяти программам или устройствам, которые работают в этом другом виртуальном доверительном уровне. Программа, исполняющаяся на виртуальном процессоре 402, может также опционально изменять средства защиты доступа к памяти для виртуального доверительного уровня, на котором работает виртуальный процессор 402. Однако программа, исполняющаяся на виртуальном процессоре 402, работающем на виртуальном доверительном уровне, который является менее привилегированным, чем другой виртуальный доверительный уровень, не может ограничить доступ к ячейкам памяти программам или устройствам, которые работают в этом другом виртуальном доверительном уровне. В одном или нескольких вариантах осуществления, виртуальные доверительные уровни маркированы целочисленными значениями (например, 0, 1, 2 и т.д.), при этом виртуальные доверительные уровни, имеющие большие целочисленные значения, являются более высокими виртуальными доверительными уровнями, чем виртуальные доверительные уровни, имеющие меньшие целочисленные значения. В качестве альтернативы, виртуальные доверительные уровни, имеющие меньшие целочисленные значения, могут быть более высокими виртуальными доверительными уровнями, чем виртуальные доверительные уровни, имеющие большие целочисленные значения, или могут быть использованы другие методы маркировки (например, буквы, другие знаки или символы и т.д.).

[00181] В одном или нескольких вариантах осуществления, средства защиты доступа к памяти реализованы на постраничной (для каждой страницы памяти) основе. Каждая страница памяти имеет ассоциированные средства защиты доступа к памяти, и средства защиты доступа к памяти для страницы памяти могут быть изменены независимо от средств защиты доступа к памяти других страниц памяти. Средства защиты доступа к памяти также не зависят от какого-либо требования, что отдельные страницы или диапазоны смежных адресов имеют такие же средства защиты доступа к памяти. Хотя в настоящем документе делается ссылка на средства защиты доступа к памяти, реализованные на постраничной основе, следует отметить, что средства защиты доступа к памяти в качестве альтернативы могут быть реализованы и в других группах или блоках адресов памяти, таких как части страниц памяти, множество страниц памяти, диапазоны адресов и т.д.

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

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

[00184] Со ссылкой на фиг.3, физический процессор, который является компонентом 304, назначает пространство памяти виртуальной машины для виртуального процессора, который является виртуальным компонентом 316, и поддерживает таблицу преобразования адресов. Таблица преобразования адресов отображает адреса в пространстве памяти виртуальной машины, которое назначено виртуальной машине 306, на адреса в пространстве физической памяти (физической памяти, которая является компонентом 304). То, какой адрес пространства физической памяти отображается на конкретный адрес в пространстве памяти виртуальной машины в любой данный момент времени, может изменяться и управляется диспетчером памяти (например, частью физического процессора). Диспетчер памяти может изменить отображения, позволяя множеству различных виртуальных процессоров совместно использовать пространство физической памяти и/или позволяя пространству памяти виртуальной машины быть большим, чем пространство физической памяти, с использованием любого из различных общедоступных и/или проприетарных методов.

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

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

[00187] Фиг. 5 иллюстрирует примерную систему 500, реализующую множество виртуальных доверительных уровней в соответствии с одним или более вариантами осуществления. Примерная система 500 включает в себя два виртуальных процессора: виртуальный процессор 502 и виртуальный процессор 504. Виртуальные процессоры 502 и 504 могут, каждый, представлять собой виртуальный компонент 316 согласно фиг.3 и/или виртуальный процессор 402 согласно фиг.4.

[00188] Виртуальные процессоры 502 и 504 реализуют два различных виртуальных доверительных уровня, именуемые как VTL 0 и VTL 1. Каждый виртуальный доверительный уровень каждого виртуального процессора имеет свою собственную локальную подсистему прерываний, проиллюстрированную как усовершенствованный программируемый контроллер прерываний (APIC) 506 (контроллер прерываний для VTL 0 виртуального процессора 502), APIC 508 (контроллер прерываний для VTL 1 виртуального процессора 502), APIC 510 (контроллер прерываний для VTL 0 виртуального процессора 504) и APIC 512 (контроллер прерываний для VTL 1 виртуального процессора 504). В любой момент времени, виртуальные процессоры 502 и 504 могут работать на тех же самых или различных виртуальных доверительных уровнях. Таким образом, несколько виртуальных процессоров могут работать на различных виртуальных доверительных уровнях одновременно.

[00189] Система 500 поддерживает запись средств защиты 514 доступа к памяти для VTL 0, а также запись средств защиты 516 доступа к памяти для VTL 1. Гипервизор (например, модуль 324 виртуального безопасного режима согласно фиг.3) поддерживает средства защиты 514 и 516 доступа к памяти. Для каждого доступа к адресу страницы памяти из виртуального процессора 502 или 504 при исполнении на VTL 0, гипервизор проверяет средства защиты 514 доступа к памяти VTL 0 для страницы памяти, которая включает в себя адрес получения доступа. Если средства защиты 514 доступа к памяти VTL 0 указывают, что доступ разрешен, то затем используется отображение 518 гостевой физической на физическую память системы, чтобы отображать адрес на адрес памяти физической памяти 520 системы, и запрошенный доступ выполняется. Отображение 518 гостевой физической на физическую память системы представляет собой, например, таблицу преобразования адресов, которая отображает адреса в пространстве памяти виртуальной машины (гостевые физические адреса или GPA) на адреса в пространстве физической памяти (физические адреса системы или SPA), как обсуждалось выше. Однако, если средства защиты 514 доступа к памяти VTL 0 указывают, что доступ не разрешен, то запрашиваемый доступ отклоняется (не выполняется). Поскольку запрошенный доступ отклонен, никакого отображения адреса на адрес памяти физической памяти 520 не требуется выполнять.

[00190] Аналогично, для каждого доступа к адресу страницы памяти из виртуального процессора 502 или 504 при исполнении на VTL 1, гипервизор проверяет средства защиты 516 доступа к памяти VTL 1 для страницы памяти, которая включает в себя адрес получения доступа. Если средства защиты 516 доступа к памяти VTL 1 указывают, что доступ разрешен, то используется отображение 518 гостевой физической на физическую память системы, чтобы отображать адрес на адрес памяти физической памяти 520 системы, и запрошенный доступ выполняется. Однако, если средства защиты 516 доступа к памяти VTL 1 указывают, что доступ не разрешен, то запрашиваемый доступ отклоняется (не выполняется). Поскольку запрошенный доступ отклонен, никакого отображения адреса на адрес памяти физической памяти 520 не требуется выполнять.

[00191] Многообразные различные средства защиты доступа к памяти могут быть идентифицированы в качестве средств защиты 514 и 516 доступа к памяти. Например, средства защиты доступа к памяти могут включать в себя следующие средства защиты: Отсутствие доступа (адреса на странице памяти не могут считываться, записываться или исполняться). Только чтение, без исполнения (адреса на странице памяти могут считываться, но не могут записываться или исполняться). Только чтение, с возможностью исполнения (адреса на странице памяти могут считываться или исполняться, но не могут записываться). Чтение/запись, без исполнения (адреса на странице памяти могут считываться или записываться, но не могут исполняться). И чтение/запись, с возможностью исполнения (адреса на странице памяти могут считываться, записываться или исполняться).

[00192] Эти различные средства защиты доступа к памяти поддерживают многообразные различные сценарии использования. Например, при исполнении на VTL 1, средство защиты доступа памяти VTL 0 для страницы памяти может быть установлено на ʺотсутствие доступаʺ. Эта настройка помещает страницу памяти в ʺбезопасныйʺ режим, делая страницу памяти недоступной для программ, исполняющихся на виртуальных процессорах 502 и/или 504 на VTL 0. В качестве другого примера, при работе на VTL 1, VTL 0 средство защиты доступа к памяти для страницы памяти может быть установлено в положение ʺтолько чтение, с возможностью исполненияʺ. Эта настройка помещает страницу памяти в режим, в котором она может считываться и исполняться программами, исполняющимися на виртуальных процессорах 502 и/или 504 в VTL 0, но не может изменяться программами, исполняющимися на виртуальных процессорах 502 и/или 504 в VTL 0. Таким образом, различные целостности кода или другие программы безопасности могут сохраняться в памяти страниц в VTL 1 и исполняться программами в VTL 0, при обеспечении того, что эти программы, исполняющиеся в VTL 0, не могут изменять программы.

[00193] Дополнительные устройства также могут быть опционально ассоциированы с конкретным виртуальным доверительным уровнем. Любые дополнительные устройства, которые получают доступ к страницам памяти (например, выполняют прямой доступ к памяти (DMA)), могут быть ассоциированы с виртуальным доверительным уровнем. Система 500 включает в себя, например, устройства 522 и 524. Устройство 522 ассоциировано с VTL 0, и устройству 522 разрешено получать доступ к страницам памяти в соответствии со средствами защиты 514 доступа к памяти VTL 0, аналогично виртуальным процессорам 502 и 504, работающим в VTL 0. Аналогично, устройство 524 ассоциировано с VTL 1, и устройству 524 разрешено получать доступ к страницам памяти в соответствии со средствами защиты 516 доступа к памяти VTL 1, аналогично виртуальным процессорам 502 и 504, работающим в VTL 1.

[00194] В одном или более вариантах осуществления, каждое устройство 522 и 524 инициализируется для работы на самом низком виртуальном доверительном уровне (например, VTL 0). Виртуальный процессор 502 или 504 может конфигурировать устройство, ассоциируемое с активным VTL или, опционально, с любым VTL более низкого уровня. Виртуальный процессор 502 или 504 может конфигурировать устройство, ассоциируемое с конкретным VTL, различными способами, например, путем активирования вызова (например, функции), открываемого гипервизором 302.

[00195] Модуль 324 виртуального безопасного режима согласно фиг. 3 поддерживает запись того, какие устройства ассоциированы с какими виртуальными доверительными уровнями. Модуль 324 обновляет запись, чтобы отражать изменения в том, какие виртуальные доверительные уровни ассоциированы с какими устройствами. Модуль 324 виртуального безопасного режима также поддерживает запись того, на каком виртуальном доверительном уровне каждый виртуальный процессор 502 и 504 работает в любой момент времени. Виртуальные процессоры 502 и 504 могут переключаться с одного виртуального доверительного уровня на другой различными способами, и каждый раз, когда такое переключение происходит, указание на переключенный виртуальный доверительный уровень включается в запись, поддерживаемую модулем 324.

[00196] В проиллюстрированной примерной системе 500, средства защиты 514 и 516 доступа к памяти для различных виртуальных доверительных уровней реализуются отдельно, и общее отображение 518 памяти совместно используется всеми виртуальными доверительными уровнями. Альтернативно, средства защиты 514 и 516 доступа к памяти могут быть реализованы как часть отображения 518 памяти. В таких ситуациях, может быть реализовано одно отображение 518 памяти, которое включает в себя средства защиты доступа к памяти для всех виртуальных доверительных уровней, или, в качестве альтернативы, отдельные отображения памяти (аналогичные отображениям 518 памяти), причем каждое отображение памяти включает в себя средства защиты доступа к памяти для отличающегося виртуального доверительного уровня.

[00197] Со ссылкой на фиг. 3, в одном или нескольких вариантах осуществления, виртуальные процессоры виртуальной машины 306 инициализируются для работы на одном виртуальном доверительном уровне, таком как VTL 0. С только одним виртуальным доверительным уровнем, виртуальная машина 306 может также ссылаться на виртуальный безопасный режим, не задействованный для виртуальной машины 306. Для работы на более высоком виртуальном доверительном уровне, виртуальная машина 306 задействуется для одного или нескольких более высоких виртуальных доверительных уровней (также упоминается как задействование виртуального безопасного режима для виртуальной машины 306). После того, как более высокий виртуальный доверительный уровень задействован, программа, исполняющаяся на более высоком виртуальном доверительном уровне, может изменять средства защиты доступа к памяти для более низкого виртуального доверительного уровня.

[00198] В одном или более вариантах осуществления, один или несколько более высоких виртуальных доверительных уровней могут задействоваться для виртуальной машины 306 в множество различных моментов времени. Например, один или несколько более высоких виртуальных доверительных уровней могут быть задействованы для виртуальной машины 306 при создании виртуальной машины 306 и/или загрузки гипервизора 302, после того, как виртуальная машина 306 была загружена и работает уже в течение пороговой величины времени (например, несколько минут или часов) и т.д.

[00199] На фиг. 6 представлена блок-схема последовательности операций, иллюстрирующая пример процесса 600 для инициирования виртуального безопасного режима для виртуальной машины в соответствии с одним или более вариантами осуществления. Процесс 600 осуществляется с помощью программы, исполняющейся в виртуальной машине, и гипервизора, таких как программа, исполняющаяся в виртуальной машине 306 согласно фиг. 3, и гипервизора 302 согласно фиг. 3, и может быть реализован в программном обеспечении, программно-аппаратных средствах, аппаратных средствах или их комбинации. Процесс 600 показан в виде набора действий и не ограничивается порядком, показанным для выполнения операций различных действий. Процесс 600 является примерным процессом для инициирования виртуального безопасного режима для виртуальной машины, дополнительные описания инициирования виртуального безопасного режима для виртуальной машины включены здесь со ссылкой на различные фигуры.

[00200] В процессе 600, программа, исполняющаяся в виртуальной машине, загружает изображение виртуального безопасного режима в память (действие 602). Программу можно рассматривать как исполняющуюся на самом низком виртуальном доверительном уровне (даже при том, что виртуальный безопасный режим еще не инициирован). Виртуальный доверительный уровень, на котором исполняется программа, также упоминается как запускающий виртуальный доверительный уровень. В одном или нескольких вариантах осуществления, изображение виртуального безопасного режима загружается в память программой (которая может называться загрузчиком виртуального безопасного режима), копирующей или иным образом размещающей изображение виртуального безопасного режима в страницы памяти виртуального пространства памяти виртуальной машины. Изображение виртуального безопасного режима относится к коду и данным (например, объектному коду, который может исполняться процессором), которые, при исполнении, реализуют виртуальный безопасный режим.

[00201] Гипервизор также уведомляется (например, с помощью программы, которая загружает изображение виртуального безопасного режима) о страницах памяти, в которые загружается изображение виртуального безопасного режима. Гипервизор может уведомляться различными способами, например, загрузчиком виртуального безопасного режима, активирующим вызов, открываемый гипервизором (также называемый гипервызовом) и предоставляющий в качестве параметра гипервызова указание страниц памяти, в которые загружено изображение виртуального безопасного режима. Гипервызов может быть, например, гипервызовом HvLoadVsmImage().

[00202] В ответ на уведомление страниц памяти, в которые загружено изображение виртуального безопасного режима, гипервизор делает эти страницы памяти недоступными для запускающего виртуального доверительного уровня (действие 604). Гипервизор также делает эти страницы памяти недоступными для виртуальных доверительных уровней (если таковые имеются), которые являются более низким уровнем, чем запускающий виртуальный доверительный уровень. Страницы памяти могут быть сделаны недоступными различными способами, например, устанавливая средства защиты доступа к памяти для страниц памяти как ʺотсутствие доступаʺ для запускающего виртуального доверительного уровня (и любых виртуальных доверительных уровней, которые являются более низким уровнем, чем запускающий виртуальный доверительный уровень).

[00203] Кроме того, гипервизор подготавливает изображение виртуального безопасного режима (действие 606). Подготовка изображения виртуального безопасного режима относится к установке гипервизора в состояние, чтобы быть способным исполнять и верифицировать изображение виртуального безопасного режима. Эта подготовка может включать в себя запись различного внутреннего состояния относительно местоположения (например, страницы памяти), где хранится изображение виртуального безопасного режима, а также генерацию хэш-значения изображения виртуального безопасного режима. При первом входе на виртуальный доверительный уровень более высокого уровня после того, как виртуальный доверительный уровень более высокого уровня был инициирован на виртуальном процессоре, виртуальный процессор, как ожидается, будет исполняться в четко определенном состоянии. Это позволяет гарантировать, что первоначальная программа или программы, исполняющиеся на виртуальном доверительном уровне более высокого уровня, работают корректным образом. Первоначальная программа или программы, которые исполняются на виртуальном доверительном уровне более высокого уровня, могут использовать эту информацию, когда они выполняют самозагрузку своей среды исполнения на виртуальный доверительный уровень более высокого уровня.

[00204] Хеш-значение изображения виртуального безопасного режима может быть сгенерировано с использованием любой из множества общедоступных и/или проприетарных функций хэширования, такой как любой из семейства алгоритмов безопасного хеширования (SHA). Хеш-значение может быть хеш-значением изображения виртуального безопасного режима по всем страницам памяти, или в качестве альтернативы, набором хэш-значений каждой из страниц памяти, в которые загружена по меньшей мере часть изображения виртуального безопасного режима. Хеш-значение может быть использовано, например, с помощью гипервизора, чтобы затем верифицировать, что изображение виртуального безопасного режима не изменяется после загрузки в память. Другое использование хеш-значения состоит в том, чтобы послать его в ТРМ для добавления к состоянию регистра PCR, так что ТРМ может аттестовать конфигурацию программного обеспечения VTL.

[00205] Гипервизор затем задействует целевой виртуальный доверительный уровень на запускающем виртуальном процессоре (действие 608). Целевой виртуальный доверительный уровень относится к виртуальному доверительному уровню, более высокому, чем запускающий виртуальный доверительный уровень. Запускающий виртуальный процессор относится к виртуальному процессору, исполняющему загрузчик виртуального безопасного режима. В одном или нескольких вариантах осуществления гипервизор задействует целевой виртуальный доверительный уровень на запускающем виртуальном процессоре в ответ на гипервызов, открытый гипервизором, активированным загрузчиком виртуального безопасного режима. Гипервызовов может быть, например, гипервызовом HvEnableVtl().

[00206] Гипервизор затем задействует целевой виртуальный доверительный уровень на других виртуальных процессорах в виртуальной машине (действие 610). В одном или нескольких вариантах осуществления, гипервизор задействует целевой виртуальный доверительный уровень на других виртуальных процессорах в ответ на гипервызов, открытый гипервизором, активированным загрузчиком виртуального безопасного режима. Загрузчик виртуального безопасного режима может обеспечивать, в качестве параметра гипервызова, идентификатор виртуального процессора, на котором должен быть задействован целевой виртуальный доверительный уровень, или, в качестве альтернативы, гипервызов может указывать на задействование целевого виртуального доверительного уровня на всех остальных виртуальных процессорах в виртуальной машине. Загрузчик виртуального безопасного режима может также опционально обеспечить первоначальный контекст виртуального процессора, используемого для целевого виртуального доверительного уровня других виртуальных процессоров, на которых задействуется целевой виртуальный доверительный уровень. Гипервызов может быть, например, гипервызовом HvEnableVtl().

[00207] В вариантах осуществления, в которых реализованы три или более виртуальных доверительных уровня, действия 608 и 610 могут повторяться для каждого задействуемого дополнительного виртуального доверительного уровня более высокого уровня. Для каждого виртуального доверительного уровня более высокого уровня, гипервызовы, открытые гипервизором, активируются загрузчиком виртуального безопасного режима (или другой программой, исполняющейся в виртуальном доверительном уровне более низком, чем задействованный целевой виртуальный доверительный уровень).

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

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

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

[00211] В альтернативном варианте осуществления, гипервизор запускает виртуальный CPU в VTL высшей привилегии, и код там запускает более низкие уровни VTL. Это продолжается по сходным линиям, но может быть более простым, так как, в некоторых вариантах осуществления, более высокий уровень VTL может быть доверительным, чтобы не повреждать более низкие уровни VTL.

[00212] Со ссылкой на фиг. 4, виртуальный процессор 402 может изменить активный виртуальный доверительный уровень множеством различных способов. Переключение или изменение с более низкого виртуального доверительного уровня на более высокий виртуальный доверительный уровень также упоминается как вход на более высокий виртуальный доверительный уровень, и переключение или изменение с более высокого виртуального доверительного уровня на более низкий виртуальный доверительный уровень также упоминается как выход из более высокого виртуального доверительного уровня.

[00213] В одном или нескольких вариантах осуществления, виртуальный процессор 402 может выполнять переключение или изменение с более низкого виртуального доверительного уровня на более высокий виртуальный доверительный уровень в ответ на возникновение одного или более событий, таких как вызов виртуального доверительного уровня, прерывание для более высокого виртуального доверительного уровня, ловушка (например, чтобы позволить более высокому виртуальному доверительному уровню обрабатывать определенные типы отказов, таких как отказы страниц, для более низких виртуальных доверительных уровней), или перехват на более высокий виртуальный доверительный уровень. Вызов виртуального доверительного уровня относится к конкретной одной или нескольким инструкциям (например, конкретной последовательности инструкций), исполняемым для перехода от текущего виртуального доверительного уровня на более высокий виртуальный доверительный уровень. Прерывание для более высокого виртуального доверительного уровня относится к получению прерывания для (позиционирования прерывания) более высокого виртуального доверительного уровня, чем текущий виртуальный доверительный уровень. Перехват на более высокий виртуальный доверительный уровень относится к операции получения доступа к защищенному адресу или защищенному компоненту более высокого виртуального доверительного уровня, такому как регистр более высокого виртуального доверительного уровня, I/O-порт, ассоциированный с более высоким виртуальным доверительным уровнем, или страница памяти, ассоциированная с более высоким виртуальным доверительным уровнем.

[00214] Некоторое состояние процессора виртуального процессора 402 совместно используется между различными виртуальными доверительными уровнями и упоминается как совместно используемое состояние процессора. Совместно используемое состояние процессора не требуется изменять при смене активного виртуального доверительного уровня, повышая эффективность изменения виртуальных доверительных уровней. Однако другое состояние процессора виртуального процессора 402 не является совместно используемым для различных виртуальных доверительных уровней и также упоминается как частное состояние процессора. Частное состояние процессора, показанное как состояние 408 виртуального процессора, изменяется при изменении активного виртуального доверительного уровня.

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

[00216] В одном или нескольких вариантах осуществления, частное состояние процессора включает в себя регистр указателя инструкции (или счетчик программы) и регистр указателя стека. Частное состояние процессора для активного виртуального доверительного уровня сохраняется гипервизором при изменении активного виртуального доверительного уровня и заменяется частным состоянием процессора для виртуального доверительного уровня, на который происходит смена. Частное состояние процессора для виртуального доверительного уровня, на который происходит смена, может быть состоянием по умолчанию/инициализации (если виртуальный доверительный уровень не был ранее введен) или ранее сохраненным частным состоянием процессора для виртуального доверительного уровня (сохраненным перед последним выходом виртуального процессора 402 из виртуального доверительного уровня).

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

[00218] В одном или нескольких вариантах осуществления, виртуальный процессор 402 может переключаться с одного виртуального доверительного уровня только к следующему более высокому виртуальному доверительному уровню. Например, виртуальный процессор 402 может переключиться от VTL 0 на VTL 1, от VTL 1 на VTL 2, от VTL 2 на VTL 3 и т.д., но не от VTL 0 на VTL 3. Альтернативно, виртуальный процессор может переключаться от одного виртуального доверительного уровня на любой более высокий виртуальный доверительный уровень. Например, в вызове виртуального доверительного уровня, виртуальный процессор 402 может задать, на какой более высокий виртуальный доверительный уровень должно быть выполнено переключение, что позволяет выполнить переключение от VTL 0 на VTL 3.

[00219] После переключения от более низкого виртуального доверительного уровня на более высокий виртуальный доверительный уровень, виртуальный процессор 402 может переключаться или переходить обратно на более низкий виртуальный доверительный уровень (выйти из более высокого виртуального доверительного уровня) в ответ на множество различных событий. В одном или нескольких вариантах осуществления, виртуальный процессор 402 выполняет одно или несколько действий (например, выполняет одну или несколько операций, обрабатывает прерывания и т.д.), а затем возвращается на более низкий виртуальный доверительный уровень. Виртуальный процессор 402 возвращается на более низкий виртуальный доверительный уровень путем исполнения конкретных одной или более инструкций (например, конкретной последовательности инструкций) для перехода от текущего виртуального доверительного уровня к более низкому виртуальному доверительному уровню. Эти инструкции опционально сохраняются на странице памяти, упоминаемой как страница кода выхода из виртуального доверительного уровня, что позволяет гипервизору извлекать кодовую последовательность для переключения между виртуальными доверительными уровнями. В одном или нескольких вариантах осуществления, виртуальный процессор 402 возвращается на более низкий виртуальный доверительный уровень, из которого был выполнен вход на активный виртуальный доверительный уровень, хотя, в качестве альтернативы, виртуальный процессор 402 может вернуться на другой виртуальный доверительный уровень.

[00220] Для совместно используемого состояния процессора, состояние процессора не меняется при изменении виртуальных доверительных уровней, что обеспечивает прохождение информации между виртуальными доверительными уровнями с использованием совместно используемого состояния процессора. Для частного состояния процессора, каждый виртуальный доверительный уровень имеет свой собственный экземпляр состояния процессора (например, регистры), к которому может быть получен доступ только посредством этого виртуального доверительного уровня. Гипервизор управляет сохранением и восстановлением такого состояния процессора (например, содержимым регистров) при переключении между виртуальными доверительными уровнями. При входе в виртуальный доверительный уровень 404, частное состояние процессора является тем же самым (например, регистры содержат те же значения), что и когда виртуальный процессор 402 последний раз работал на этом виртуальном доверительном уровне 402.

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

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

[00223] В таблице I представлены примеры регистров, которые являются совместно используемым состоянием процессора (перечислены в качестве типа ʺсовместно используемоеʺ в таблице I), и примеры регистров, которые являются частным состоянием процессора (перечислены в качестве типа ʺчастноеʺ в таблице I). Регистры, показанные в таблице I, являются примерами для процессоров архитектуры Х64. Следует понимать, что эти регистры являются примерами, что не все архитектуры процессоров включают в себя все эти регистры, и что различные архитектуры процессоров могут включать в себя различные (но опционально аналогичные) регистры.

Таблица I

Тип Регистры Совместно
используемое Rax, Rbx, Rcx, Rdx, Rsi, Rdi, Rbp
CR2
R8-R15
DR0-DR6
XCRO(XFEM)
X87 состояние с плавающей точкой
ХММ состояние
AVX состояние Частное RIP, RSP
RELAGS
CR0, CR3, CR4
DR7
IDTR, GDTR
CS, DS, ES, FS, GS, SS, TR, LDTR
TSC

[00224] В одном или нескольких вариантах осуществления, гипервизор также поддерживает различные регистры состояния машины (MSR), которые также упоминаются как виртуальные регистры, некоторые из которых являются совместно используемым состоянием процессора, и некоторые из которых являются частным состоянием процессора. Таблица II иллюстрирует примеры MSR, которые являются совместно используемым состоянием процессора (перечислены в качестве типа ʺсовместно используемоеʺ в таблице II), и примеры MSR, которые являются частным состоянием процессора (перечислены в качестве типа ʺчастноеʺ в таблице II). Регистры в таблице II, которые имеют префикс ʺHV_X64ʺ, относятся к регистрам в программном обеспечении виртуализации Hyper-V®, доступном от Microsoft Corporation, Редмонд, шт. Вашингтон, в то время как регистры в таблице II, которые не имеют префикса ʺHV_ X64ʺ, относятся к стандартным регистрам архитектуры X64. MSR, показанные в таблице II, являются примерами для виртуальных машин, работающих на процессорах архитектуры Х64. Следует понимать, что эти MSR являются примерами, что не все виртуальные безопасные режимы должен включать в себя все эти MSR, и что различные архитектуры процессоров могут включать в себя различные (но опционально аналогичные) регистры. Кроме того, классификация каждого MSR также приведена только для примера, и может быть различной в разных вариантах осуществления.

Таблица II

Тип Регистры Совместно
используемое HV_X64_MSR_TSC_FREQUENCY
HV_X64_MSR_VP_INDEX
HV_X64_MSR_VP_RUNTIME
HV_X64_MSR_RESET
HV_X64_MSR_TIME_REF_COUNT
HV_X64_MSR_GUEST_IDLE
HV_X64_MSR_DEBUG_DEVICE_OPTIONS
HV_X64_MSR_BELOW_1MB_PAGE
HV_X64_MSR_STATS_PARTITION_RETAIL_PAGE
HV_X64_MSR_STATS_VP_RETAIL_PAGE
MTRRʹs
MCG_CAP
MCG_STATUS Частное SYSENTER_CS, SYSENTER_ESP, SYSENTER_EIP, STAR, LSTAR, CSTAR, SFMASK, EFER, CERNEL_GSBASE, PAT, FS.BASE, GS.BASE
HV_X64_MSR_HYPERCALL
HV_X64_MSR_GUEST_OS_ID
HV_X64_MSR_REFERENCE_TSC
HV_X64_MSR_APIC_FREQUENCY
HV_X64_MSR_EOI
HV_X64_MSR_ICR
HV_X64_MSR_TPR
HV_X64_MSR_APIC_ASSIST_PAGE
HV_X64_MSR_NPIEP_CONFIG
HV_X64_MSR_SIRBP
HV_X64_MSR_SCONTROL
HV_X64_MSR_SVERSION
HV_X64_MSR_SIEFP
HV_X64_MSR_SIMP
HV_X64_MSR_EOM
HV_X64_MSR_SINT0 - HV_X64_MSR_SINT15

[00225] Дополнительно, как обсуждалось выше, виртуальные доверительные уровни 404 имеют отдельные подсистемы прерываний, при этом каждый виртуальный доверительный уровень 404 имеет свою собственную подсистему 410 прерываний. Отдельные подсистемы 410 прерываний позволяют программам, исполняющимся на виртуальном доверительном уровне, отправлять межпроцессорные прерывания безопасным образом между виртуальными процессорами без помех со стороны более низких виртуальных доверительных уровней. Отдельные подсистемы 610 прерываний также позволяют подсистеме прерываний виртуального доверительного уровня безопасно принимать прерывания от устройств, ассоциированных с этим же виртуальным доверительным уровнем без помех со стороны программ на более низких виртуальных доверительных уровнях. Отдельные подсистемы 410 прерываний также позволяют каждой подсистеме 410 прерываний иметь безопасное средство таймера, которое не может испытывать помехи от программ на более низких виртуальных доверительных уровнях. Отдельные подсистемы 410 прерываний также позволяют подсистеме 410 прерываний принимать уведомления при приеме прерываний для (прерываний, нацеленных на) более низкого виртуального доверительного уровня, чтобы обеспечить скооперированное планирование прерываний между виртуальными доверительными уровнями.

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

[00227] В ответ на прием прерывания, нацеленного на более высокий виртуальный доверительный уровень, чем активный виртуальный доверительный уровень, гипервизор может предпринимать множество различных действий. В одном или нескольких вариантах осуществления, MSR управления перехватом (например, HV_X64_MSR_VSM_INTERCEPT_CTL MSR) включает в себя настройку выхода из VTL прерывания, которая определяет действие, которое необходимо принять. Если настройка выхода из VTL прерывания имеет одно значение (например, указывая всегда выход), то гипервизор переключает активный виртуальный доверительный уровень на более высокий виртуальный доверительный уровень, и подсистема 410 прерываний более высокого виртуального доверительного уровня обрабатывает прерывание. Однако, если настройка выхода из VTL прерывания имеет другое значение (например, указывая проверку прерываемости), то гипервизор переключает активный виртуальный доверительный уровень на более высокий виртуальный доверительный уровень, только если состояние процессора более высокого виртуального доверительного уровня указывает на то, что более высокий виртуальный доверительный уровень может быть прерван. В качестве альтернативы, настройка выхода из VTL прерывания может поддерживаться в других местоположениях, например в качестве страницы управления активного виртуального доверительного уровня (или более высокого виртуального доверительного уровня).

[00228] В качестве альтернативы, действие, которое следует предпринять, может определяться различными способами. Например, гипервизор может обеспечить механизм, позволяющий более высокому виртуальному доверительному уровню обозначать конкретные вектора прерываний, которые будут вызывать переключение активного виртуального доверительного уровня на более высокий виртуальный доверительный уровень для обработки прерывания с помощью подсистемы 410 прерываний более высокого виртуального доверительного уровня. В качестве альтернативы, разнообразные другие критерии состояния могут быть применены гипервизором, и гипервизор может переключить активный виртуальный доверительный уровень на более высокий виртуальный доверительный уровень для обработки прерывания с помощью подсистемы 410 прерываний более высокого виртуального доверительного уровня, только если критерии состояния удовлетворены активным виртуальным доверительным уровнем.

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

[00230] Следует отметить, что могут возникать ситуации, в которых желательно, чтобы более высокий виртуальный доверительный уровень получал уведомление, когда более низкому виртуальному доверительному уровню послано прерывание. Это может быть желательным, например, в ситуациях, когда программа более высокого виртуального доверительного уровня желает разрешить виртуальному процессору возвратиться на более низкий виртуальный доверительный уровень для обработки прерывания. В одном или нескольких вариантах осуществления предусмотрено средство уведомления о прерывании для облегчения уведомления более высокого виртуального доверительного уровня, когда более низкому виртуальному доверительному уровню послано прерывание. Это средство уведомления о прерывании может быть обеспечено различными способами, такими как MSR управления (например, HV_X64_MSR_VTL_CTL MSR). Это средство уведомления о прерывании может препятствовать более высокому виртуальному доверительному уровню задерживать обработку прерывания для более низкого виртуального доверительного уровня на длительный период времени.

[00231] При использовании средства уведомления о прерывании, в ответ на прием прерывания, нацеленного на более низкий виртуальный доверительный уровень, чем активный виртуальный доверительный уровень, гипервизор оценивает частное состояние процессора и состояние подсистемы 410 прерываний более низкого виртуального доверительного уровня, чтобы определить, может ли прерывание быть представлено в подсистему 410 прерываний более низкого виртуального доверительного уровня. Если из-за различного частного состояния процессора или состояния подсистемы 410 прерываний, прерывание не может быть представлено в подсистему 410 прерываний более низкого виртуального доверительного уровня, то прерывание маркируется как ожидающее, и никакое дальнейшее действие над прерыванием не выполняется. Однако, если прерывание может быть представлено в подсистему 410 прерываний более низкого виртуального доверительного уровня, то гипервизор поддерживает запись прерывания для последующей доставки в подсистему 410 прерываний более низкого виртуального доверительного уровня, как было описано выше, и генерирует прерывание в активном виртуальном доверительном уровне. Прерывание, генерируемое на активном виртуальном доверительном уровне (например, прерывание для вектора прерывания, указанного в HV_X64_MSR_VTL_CTL MSR) приводит к тому, что программа, исполняющаяся на активном виртуальном доверительном уровне, принимает решение, как реагировать на прерывание. Программа может вызвать выход гипервизора из более высокого виртуального доверительного уровня, позволяя более низкому виртуальному доверительному уровню обрабатывать прерывание, нацеленное на более низкий виртуальный доверительный уровень. Однако гипервизору не требуется выходить из более высокого виртуального доверительного уровня, или программа может задержать выход гипервизора из более высокого виртуального доверительного уровня на различные величины времени.

[00232] Кроме того, как обсуждалось выше, гипервизор может переключиться на более высокий виртуальный доверительный уровень в ответ на перехват в более высокий виртуальный доверительный уровень. В одном или нескольких вариантах осуществления, гипервизор позволяет более высокому виртуальному доверительному уровню указывать конкретные ресурсы или компоненты, которые блокированы и недоступны для программ в более низких виртуальных доверительных уровнях. Гипервизор может позволить более высокому виртуальному доверительному уровню заблокировать и сделать недоступными, например, конкретные средства управления доступом к порту ввода/вывода (I/O), средства управления доступом к MSR, средства управления доступом к памяти и/или регистрам управления. Более высокий виртуальный доверительный уровень может указывать (например, с помощью различных настроек MSR или другими способами), какие конкретные средства управления доступом к порту I/O, средства управления доступом к MSR, средства управления доступом к памяти и/или регистрам управления заблокированы. В ответ на выполнение попытки (например, с помощью программы или устройства) получения доступа к ресурсу или компоненту, заблокированному более высоким виртуальным доверительным уровнем, генерируется перехват на более высокий виртуальный доверительный уровень. В ответ на перехват, гипервизор переключает виртуальный процессор на более высокий виртуальный доверительный уровень (или, альтернативно, на самый высокий виртуальный доверительный уровень, поддерживаемый виртуальным процессором).

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

[00234] В одном или нескольких вариантах осуществления, в ситуациях, в которых виртуальный процессор 402 включает в себя три или более виртуальных доверительных уровня, вместо поддержки вложенности средств безопасного перехвата, гипервизор предоставляет единый набор MSR управления доступом, которые являются совместно используемыми по всем виртуальным доверительным уровням. Программы в виртуальных доверительных уровнях, которые желают использовать MSR управления доступом, могут взаимодействовать, используя свои собственные определенные интерфейсы, или, в качестве альтернативы, программа на самом высоком виртуальном доверительном уровне может эмулировать поддержку средств перехвата для более низких виртуальных доверительных уровней (например, более высокий виртуальный доверительный уровень вводит безопасный перехват в более низкий виртуальный доверительный уровень). В качестве альтернативы, вложенность средств безопасного перехвата может поддерживаться гипервизором, и отдельные MSR управления доступом могут быть использованы для различных виртуальных доверительных уровней.

[00235] Разнообразные другие MSR поддерживаются гипервизором. Ниже приведены примеры нескольких MSR, которые могут поддерживаться гипервизором. Перечислены конкретные поля для MSR. Следует принимать во внимание, однако, что эти MSR являются примерами, и что другие регистры, битовые макеты для регистров, поля и т.д. могут быть использованы в качестве альтернативы.

[00236] В таблице III показан пример HV_X64_MSR_VTL_CTL MSR, который доступен для каждого более высокого виртуального доверительного уровня (всех, кроме виртуального доверительного уровня самого низкого уровня) на каждом виртуальном процессоре. Каждый более высокий виртуальный доверительный уровень имеет свой собственный экземпляр HV_X64_MSR_VTL_CTL MSR, за исключением VTL 0. HV_X64_MSR_VTL_CTL MSR управляет различными атрибутами того, как VSM работает на более высоком виртуальном доверительном уровне.

Таблица III

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

[00237] Таблица IV иллюстрирует пример HV_X64_MSR_VTL_CALL MSR, который используется для идентификации страницы GPA, на которую должна отображаться кодовая страница вызова VTL. HV_X64_MSR_VTL_CALL MSR является совместно используемым по всей виртуальной машине. Существует один экземпляр HV_X64_MSR_VTL_CALL MSR в виртуальной машине для каждого виртуального доверительного уровня (за исключением самого высокого виртуального доверительного уровня). Когда HV_X64_MSR_VTL_CALL MSR задействован, то адрес, указанный в поле GPA кодовой страницы, перекрывается кодовой страницей вызова виртуального доверительного уровня (страницей управления, используемый для двунаправленной связи между гипервизором и программами, работающими в виртуальном доверительном уровне, как описано выше).

Таблица IV

Поле Описание GPA
кодовой страницы Номер гостевой физической страницы, куда отображать кодовую страницу вызова VTL Непривилегированный доступ Если установлено в одно значение (например, 1), то позволят непривилегированным (всем, кроме самого низкого виртуального доверительного уровня) программам инициировать вызов VTL. Если установлено на другое значение (например, 0), попытки инициировать вызов VTL непривилегированными программами приводят к исполнению. Отображается Указывает, отображается (задействована) ли кодовая страница вызова VTL.

[00238] Таблица V иллюстрирует пример HV_X64_MSR_VTL_STATUS MSR, который предоставляет информацию о статусе виртуального доверительного уровня виртуального процессора. HV_X64_MSR_VTL_STATUS MSR предназначен для отдельного виртуального процессора, и имеется один экземпляр HV_X64_MSR_VTL_STATUS MSR на каждый виртуальный доверительный уровень виртуального процессора.

Таблица V

Поле Описание VTL+1
Статус разделения Указывает текущий статус виртуальной машины следующего по высоте виртуального безопасного уровня. VTL+1
Задействован Указывается, задействован ли следующий по высоте виртуальный доверительный уровень для виртуального процессора. Текущий VTL Указывает текущий виртуальный доверительный уровень виртуального процессора.

[00239] Таблица VI показывает пример HV_X64_MSR_VTL_EXIT MSR, который используется для идентификации страницы GPA, на которую следует отображать кодовую страницу выхода из виртуального доверительного уровня. HV_X64_MSR_VTL_EXIT MSR совместно используется по всей виртуальной машине. Существует один экземпляр HV_X64_MSR_VTL_EXIT MSR в виртуальной машине для каждого виртуального доверительного уровня (за исключением самого низкого виртуального доверительного уровня). Когда HV_X64_MSR_VTL_EXIT MSR задействован, то адрес, указанный в поле GPA кодовой страницы выхода из VTL, перекрывается кодовой страницей выхода из виртуального доверительного уровня.

Таблица VI

Поле Описание Кодовая страница GPA выхода из VTL Номер гостевой физической страницы, куда отображать кодовую страницу выхода из VTL. Отображается Указывает, отображается (задействована) ли кодовая страница выхода из VSM.

[00240] Таблица VII иллюстрирует пример HV_X64_MSR_VSM_INTERCEPT_CTL MSR, который управляет тем, какие типы перехватов будут запускать вход в более высокий виртуальный доверительный уровень. HV_X64_MSR_VSM_INTERCEPT_CTL MSR предназначен для индивидуального виртуального процессора и совместно используется виртуальными доверительными уровнями виртуального процессора (хотя HV_X64_MSR_VSM_INTERCEPT_CTL MSR не доступен в самом низком виртуальном доверительном уровне).

Таблица VII

Поле Описание Выход из VTL безопасного прерывания Определяет поведение, когда принято прерывание, которое нацелено на более высокий виртуальный доверительный уровень. Одно значение (например, 0) указывает на то, чтобы всегда выполнять выход, другое значение (например, 1) указывает на обусловленный выход (указывает проверку прерываемости). GPA исключение Определяет, если нарушения GPA доступа в более низком виртуальном доверительном уровне должны быть перехвачены и вызывают вход в более высокий виртуальный доверительный уровень. MSR доступ Определяет, если доступы к MSR на более низком виртуальном доверительном уровне должны быть перехвачены и вызывают вход на более высокий виртуальный доверительный уровень. Если это разрешено (например, установлено в 1), то конкретные MSR, которые запускают перехваты, определяются настройкой HV_X64_MSR_VSM_MSR_CTL MSR. I/O-порт Определяет, если доступы к I/O-портам на более низком виртуальном доверительном уровне должны быть перехвачены и вызывают вход на более высокий виртуальный доверительный уровень. Если это разрешено (например, установлено в 1), то конкретные I/O-порты, которые запускают перехваты, определяются настройкой
HV_X64_MSR_VSM_IOPORT_CTL0 MSR и
HV_X64_MSR_VSM_IOPORT_CTL1 MSR.

[00241] Таблица VIII иллюстрирует пример _X64_MSR_VSM_IOPORT_CTL MSR, который контролирует, какие доступы к I/O-порту запускают перехват в высший (или более высокий) виртуальный доверительный уровень. Могут быть включены два HV_X64_MSR_VSM_IOPORT_CTL MSR, имеющие такие же поля и упоминаемые как HV_X64_MSR_VSM_IOPORT_CTL0 MSR и HV_X64_MSR_VSM_IOPORT_CTL1 MSR. Эти два MSR предназначены для индивидуального виртуального процессора, и каждый совместно используется виртуальными доверительными уровнями виртуального процессора (хотя эти два MSR не доступны в самом низком виртуальном доверительном уровне).

Таблица VIII

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

[00242] Таблица IX иллюстрирует пример HV_X64_MSR_VSM_MSR_CTL MSR, который контролирует то, какие доступы к MSR вызывают запуск перехвата в более высокий виртуальный доверительный уровень. HV_X64_MSR_VSM_MSR_CTL MSR предназначен для индивидуального виртуального процессора и совместно используется виртуальными доверительными уровнями виртуального процессора (хотя HV_X64_MSR_VSM_MSR_CTL MSR не доступен на самом низком виртуальном доверительном уровне).

Таблица IX

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

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

[00244] Кроме того, следует отметить, что виртуальные доверительные уровни, реализованные с использованием методов, обсужденных в настоящем документе, не зависят от каких-либо колец защиты или других механизмов защиты, реализуемых с помощью физических процессоров вычислительного устройства 300. Методы, описанные здесь, не зависят от физической архитектуры процессора и, таким образом, могут быть реализованы в любом числе различных архитектур процессоров. Кроме того, методы, обсуждаемые здесь, могут поддерживать любое количество виртуальных доверительных уровней, включая различные количества виртуальных доверительных уровней для различных виртуальных процессоров, на тех же самых и/или различных виртуальных машинах.

[00245] Следует также отметить, что один или несколько виртуальных процессоров вычислительного устройства 300 могут поддерживать исполнение кода в множестве разных режимов, включая по меньшей мере режим ядра (также упоминаемый как ядерный режим, режим супервизора или супервизорный режим) и режим пользователя (также упоминаемый как пользовательский режим). Методы, рассмотренные в настоящем документе, не зависят от любого такого режима, которым код выполняется в виртуальном процессоре. Средства защиты доступа к памяти, обсуждаемые здесь, применяются на основе виртуального доверительного уровня, на котором работает виртуальный процессор, и применяются независимо от того, исполняется ли виртуальный процессор код в режиме ядра или в пользовательском режиме. Таким образом, даже если виртуальный процессор исполняет код в режиме ядра, то средства защиты доступа к памяти для виртуального доверительного уровня могут быть изменены только с помощью модуля виртуального безопасного режима, основанного на активном виртуальном доверительном уровне, как описано выше (работает ли виртуальный процессор в режиме ядра или в пользовательском режиме, не имеет значения). Хотя дополнительные средства защиты могут быть предоставлены виртуальным процессором на основе режима (например, пользовательского режима или режима ядра), в котором он исполняет код, эти средства защиты не зависят от средств защиты доступа к памяти, описанных здесь, которые применяются на основе виртуального доверительного уровня.

[00246] Таким образом, методы, описанные здесь, обеспечивают среду, которая является более привилегированной, чем операционная система, работающая в режиме ядра. Например, при работе в VTL 1, средство защиты доступа к памяти VTL 0 для страницы памяти может быть установлено в положение ʺотсутствие доступаʺ, и данные или код могут быть сохранены в странице памяти. Эта настройка помещает страницу памяти в ʺбезопасныйʺ режим, что делает страницу памяти недоступной для программ, работающих в VTL 0. Таким образом, даже если операционная система работает в режиме ядра, данные или код, хранящийся в памяти страницы, недоступны для операционной системы, если операционная система работает в VTL 0.

[00247] Однако методы, описанные здесь, могут быть использованы в сочетании с виртуальными процессорами, поддерживающими различные режимы исполнения или кольца защиты. Например, виртуальный процессор может иметь свой собственный режим ядра и пользовательский режим в VTL 1 и иметь свой собственный режим ядра и пользовательский режим в VTL 0. Таким образом, одно адресное пространство в VTL 1 не может получить доступ к другому в VTL 1, если это не разрешено делать в режиме ядра VTL 1. Однако режим ядра VTL 0 все еще не может получить доступ к любому адресному пространству в VTL 1 (предполагается, что страницы памяти адресного пространства в VTL 1 были маркированы как таковые).

[00248] Следующее обсуждение теперь относится к ряду способов и действий способов, которые могут быть выполнены. Хотя действия способа могут быть обсуждены в определенном порядке или проиллюстрированы на блок-схеме как происходящие в определенном порядке, никакого конкретного упорядочения не требуется, если не оговорено особо, или требуется, поскольку одно действие зависит от другого действия, завершаемого перед выполнением данного действия.

[00249] На фиг. 7 иллюстрируется способ 700. Способ 700 может быть реализован в вычислительной среде и включает в себя действия для установления доверия для хоста. Способ 700 включает в себя прием службой аттестации хоста от хоста, развернутого на физической машине, верифицируемой индикации определенных характеристик, которым удовлетворяет хост (действие 702). Например, фиг. 2 иллюстрирует хост 230, посылающий запрос 260, который принимается посредством HAS 258. Запрос может включать верифицируемое подтверждение некоторых характеристик хоста.

[00250] Способ 700 дополнительно включает в себя попытку определить из индикации определенных характеристик, что хост удовлетворяет определенным требованиям (действие 704). Например, HAS 258 может попытаться верифицировать подтверждение в запросе 260.

[00251] Если хост удовлетворяет определенным требованиям, включая по меньшей мере удовлетворение требования, что хост содержит доверительную среду исполнения (ТЕЕ), служба аттестации хоста выдает хосту сертификат, который хост может использовать для аутентификации одного или нескольких объектов, имеющих доверительное отношение со службой аттестации хоста (действие 706). Таким образом, как показано на фиг. 2, HAS 258 выдает сертификат 257, который может быть использован хостом 230 для получения различных ключей или других привилегий.

[00252] Способ 700 может быть практически реализован, когда определенные требования дополнительно включают в себя требование, связанное с модулем доверительной платформы (TPM) на физической машине, реализующей хост. Например, варианты осуществления изобретения могут требовать, чтобы ТРМ был установлен на физической машине, реализующей хост, и/или чтобы ТРМ использовался определенным способом или для конкретных целей. В качестве альтернативы или дополнительно, определенные требования дополнительно включают в себя требования, связанные с функциональной возможностью ARM TrustZone и/или Intel SGX.

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

[00254] Способ 700 может дополнительно включать в себя, как результат неудачи в определении того, что хост верифицируемым образом удовлетворяет определенным требованиям, уведомление диспетчера виртуальных машин (VMM), что хост не доступен для развертывания гостевых виртуальных машин.

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

[00256] Способ 700 может быть практически реализован, когда определенные требования дополнительно содержат требование о том, что должна быть обеспечена верифицируемая индикация того, что хост включает в себя корректное подтверждение политики обеспечиваемой гипервизором целостности кода (HVCI).

[00257] Способ 700 может быть практически реализован, когда определенные требования дополнительно содержат требование о том, что хост должен находиться в определенном географическом местоположении. Например, некоторым объектам может быть желательным ограничить то, где виртуальные машины могут быть развернуты по таким причинам, как политические причины, причины соответствия политике или по другим причинам. Это может включать в себя то, когда хост не находится в конкретном географическом местоположении. В частности, требование может состоять в том, что хост находится в конкретном географическом местоположении, которое не является некоторым исключенным географическим положением. Таким образом, способ 700 может быть практически реализован, когда определенные требования дополнительно содержат требование о том, что хост не должен располагаться в конкретном географическом местоположении.

[00258] Способ 700 может быть практически реализован, когда определенные требования дополнительно содержат требование о том, что хост должен быть связан с безопасной сетью. В вариантах осуществления, безопасная сеть может быть охарактеризована одним или более свойствами, такими как физическая и/или логическая изоляция, нахождение в пределах данного физического здания, защита с использованием Kerberos (технологии аутентификации и шифрования с открытым ключом), защита с использованием защиты доступа к сети, защита от атак подслушивания с использованием известных методов и защита от атак путем повтора перехваченных данных с использованием известных методов. Способ 700 может быть практически реализован, когда определенные требования дополнительно содержат требование, выбранное из группы, состоящей из соответствия политике безопасной загрузки, отсутствия отладчика загрузки, отсутствия отладчика ядра, отсутствия функциональных возможностей отладки и предопределенной конфигурации программного обеспечения в пред-OS стеке загрузки.

[00259] Способ 700 может дополнительно включать в себя создание доверительного отношения между службой аттестации хоста и службой распределения ключей, из которой хост может получать ключи путем представления сертификата.

[00260] Способ 700 может быть практически реализован, когда способ выполняется в среде, где служба аттестации хоста реализуется в среде с системой управления структурой, где система управления структурой сконфигурирована для администрирования по меньшей мере одним из операционной системы хоста, конфигурации хоста, белых списков HVCI, списков аннулирования HVCI, белых списков UEFI или списка аннулирования UEFI. В некоторых таких вариантах осуществления другая служба аутентификации и/или авторизации используется для аутентификации администраторов службы аттестации хоста, чем та, которая используется для аутентификации администраторов системы управления структурой. Такое разделение администрирования может помочь предотвратить компрометацию безопасности ʺвнутри-заданияʺ, требующую сговора администраторов, чтобы осуществить какую компрометацию.

[00261] Способ 700 может быть практически реализован так, что способ выполняется в среде, где служба аттестации хоста реализуется в среде с диспетчером виртуальных машин, где диспетчер виртуальных машин сконфигурирован для развертывания экранированных гостевых виртуальных машин на хосте, но при этом диспетчер виртуальных машин не способен дешифровать экранированные гостевые виртуальные машины. Таким образом, виртуальные машины могут быть развернуты посредством VMM, но при этом сохраняться в секрете от VMM. В некоторых таких вариантах осуществления, способ 700 может быть практически реализован в среде, где другая служба аутентификации используется для аутентификации администраторов службы аттестации хоста, чем та, которая используется для аутентификации администраторов диспетчера виртуальных машин. Вновь, это может помочь предотвратить компрометацию безопасности вследствие сговора для любой такой компрометации. В некоторых вариантах осуществления, может быть использована та же служба аутентификации, но с другой конфигурацией безопасности. Например, одна служба аутентификации может обеспечить нормальную систему аутентификации на основе пароля и систему на основе смарт-карты.

[00262] На фиг. 8 проиллюстрирован способ 800. Способ 800 может быть практически реализован в вычислительной среде. Способ включает в себя действия для установления доверия для хоста. В способе, хост, реализованный с использованием физической машины, посылает верифицируемое указание определенных характеристик хоста в службу аттестации хоста (действие 802).

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

[00264] Способ 800 может быть практически реализован, когда определенные требования дополнительно содержат требование, относящееся к модулю доверительной платформы (TPM) на физической машине, реализующей хост. В качестве альтернативы или дополнительно, определенные требования дополнительно включают в себя требование, относящееся к функциональной возможности ARM TrustZone и/или Intel SGX.

[00265] Способ 800 может быть практически реализован, когда определенные требования дополнительно содержат требование о том, что корректный и надежный отчет унифицированного расширяемого интерфейса прошивки (UEFI) должен быть обеспечен для физической машины, на которой реализован хост.

[00266] Способ 800 может быть практически реализован, когда определенные требования дополнительно содержат требование о том, что должна быть предоставлена верифицируемая индикация, что хост включает в себя корректное подтверждение политики обеспечиваемой гипервизором целостности кода (HVCI).

[00267] Способ 800 может быть практически реализован, когда определенные требования дополнительно содержат требование, что хост должен быть расположен в конкретном географическом положении. Это может включать в себя то, что хост не находится в конкретном географическом местоположении. В частности, требование может состоять в том, что хост находится в конкретном географическом местоположении, которое не является некоторым исключенным географическим положении. Таким образом, способ 800 может быть практически реализован, когда определенные требования, дополнительно содержат требование о том, что хост не должен быть расположен в конкретном географическом местоположении.

[00268] Способ 800 может быть практически реализован, когда определенные требования дополнительно содержат требование о том, что хост должен быть связан с безопасной сетью.

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

[00270] На фиг. 9 проиллюстрирован способ 900. Способ 900 может быть реализован в вычислительной среде и включает в себя действия для развертывания зашифрованного объекта на доверительном объекте. Способ 900 включает в себя, на доверительном объекте, в котором доверительный объект удостоверен полномочным органом в результате предоставления верифицируемой индикации некоторых характеристик доверительного объекта, удовлетворяющего определенным требованиям, прием зашифрованного объекта от недоверительного объекта, где недоверительный объект не удостоверен полномочным органом (действие 902). Способ 100 дополнительно включает в себя, на доверительном объекте, использование доверительных учетных данных от полномочного органа, чтобы получить ключ от службы распределения ключей, где служба распределения ключей удостоверена полномочным органом (действие 904). Способ дополнительно включает в себя, с использованием ключа, дешифрование зашифрованного объекта, чтобы обеспечить возможность разворачивания зашифрованного объекта на доверительном объекте (действие 906).

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

[00272] Способ 900 может быть практически реализован, когда определенные требования содержат требование, относящееся к модулю доверительной платформы (TPM) на физической машине, реализующей доверительный объект. В качестве альтернативы или дополнительно, определенные требования дополнительно включают в себя требование, относящееся к функциональной возможности ARM TrustZone и/или Intel SGX.

[00273] Способ 900 может быть практически реализован, когда определенные требования содержат требование, что доверительный объект должен быть реализован с использованием физической машины, имеющей корректный и достоверный отчет UEFI.

[00274] Способ 900 может быть практически реализован, когда определенные требования содержат требование, что доверительный объект включает в себя корректное подтверждение политики обеспечиваемой гипервизором целостности кода (HVCI).

[00275] Способ 900 может быть практически реализован, когда определенные требования содержат требование, что доверительный объект должен физически находиться в конкретном географическом местоположении. Это может включать в себя то, что доверительный объект не находится в конкретном географическом местоположении. В частности, требование может состоять в том, что доверительный объект находится в конкретном географическом местоположении, которое не является некоторым исключенным географическим местоположением. Таким образом, способ 900 может быть практически реализован, когда определенные требования содержат требование, что доверительный объект не должен быть физически расположен в конкретном географическом местоположении.

[00276] Способ 900 может быть практически реализован, когда определенные требования содержат требование, что доверительный объект должен быть связан с безопасной сетью.

[00277] Способ 900 может быть практически реализован, когда зашифрованный объект является терминальным сервером для развертывания на доверительном объекте.

[00278] Способ 900 может быть практически реализован, когда зашифрованный объект содержит информацию о преобразовании сети для развертывания на доверительном объекте.

[00279] Способ 900 может быть практически реализован, когда зашифрованный объект содержит конфиденциальные данные (например, прайс-листы, стратегию компании, конфиденциальную персональную информацию и т.д.) для развертывания на доверительном объекте.

[00280] Способ 900 может быть практически реализован, когда зашифрованный объект содержит конфигурационные данные, используемые для конфигурации доверительного объекта или других объектов для развертывания на доверительном объекте.

[00281] Способ 900 может быть практически реализован, когда зашифрованный объект развернут с множеством других зашифрованных объектов как часть развертывания модели службы.

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

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

[00284] Физические считываемые компьютером носители хранения включает в себя RAM, ROM, EEPROM, CD-ROM или другие хранилища на оптических дисках (например, CD, DVD и т.д.), хранилища на магнитных дисках или другие магнитные устройства хранения или любой другой носитель, который может использоваться для хранения требуемого средства программного кода в форме исполняемых компьютером инструкций или структур данных и к которым может обращаться универсальный или специализированный компьютер.

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

[00286] Кроме того, при достижении различных компонентов компьютерной системы, средства программного кода в форме исполняемых компьютером инструкций или структур данных могут быть перенесены автоматически из считываемых компьютером носителей передачи на физические считываемые компьютером носители хранения (или наоборот). Например, исполняемые компьютером инструкции или структуры данных, полученные по сети или по каналам данных, могут быть буферизованы в RAM в модуле сетевого интерфейса (например, ʺNICʺ), а затем в конечном итоге перенесены в RAM компьютерной системы и/или менее энергозависимые считываемые компьютером физические носители хранения на компьютерной системе. Таким образом, считываемые компьютером физические носители хранения могут быть включены в компоненты компьютерной системы, которые также (или даже в первую очередь) используют среды передачи.

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

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

[00289] В качестве альтернативы или в дополнение, функциональные возможности, описанные здесь, могут быть выполнены, по меньшей мере частично, с помощью одного или более логических компонентов аппаратных средств. Например, и без ограничения, иллюстративные типы логических компонентов аппаратных средств, которые могут быть использованы, включают в себя программируемые пользователем вентильные матрицы (FPGA), программно-ориентированные интегральные схемы (ASIC), программно-ориентированные стандартные продукты (ASSP), однокристальные системы (SOC), сложные программируемые логические устройства (CPLD) и т.д.

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

Изобретение относится к автоматизации операций управления на виртуальных машинах. Техническим результатом изобретения является обеспечение безопасного сетевого взаимодействия. Для этого служба аттестации верифицирует индикацию, полученную от хоста, причем индикация, относящаяся к хосту, содержит доверенную среду исполнения (ТЕЕ). После успешной верификации служба аттестации выдает сертификат, который может быть использован хостом для аутентификации объектов, имеющих доверительное отношение со службой аттестации. 2 н. и 7 з.п. ф-лы, 9 ил., 9 табл.

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

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

осуществляют попытку определить из индикации конкретных характеристик, что хост удовлетворяет конкретным требованиям; и

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

2. Компьютерно-реализуемый способ по п. 1, в котором конкретные требования дополнительно содержат требование, относящееся к модулю доверительной платформы (TPM) на физической машине, реализующей хост.

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

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

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

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

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

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

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

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

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

(а) требования, относящегося к модулю доверительной платформы (ТРМ) на физической машине, реализующей хост,

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

(d) требования, что хост должен находиться в конкретном географическом местоположении, и

(e) требования, что хост должен быть связан с безопасной сетью.