Безопасная обработка данных виртуальной машиной
Изобретение относится к исполнению виртуальной машины. Технический результат – улучшение манипулированием экземпляром виртуальной машины. Система для исполнения экземпляра виртуальной машины содержит среду исполнения, выполненную с возможностью создания экземпляра виртуальной машины. Экземпляр виртуальной машины содержит блок авторизации экземпляра для приема учетных данных для авторизации экземпляра, причем учетные данные для авторизации экземпляра однозначно связаны с экземпляром виртуальной машины. Блок ключа данных выполнен с возможностью генерирования запроса ключа данных, основываясь на учетных данных для авторизации экземпляра, связанных с экземпляром виртуальной машины. Блок расшифрования выполнен с возможностью расшифрования элемента данных, основываясь на ключе данных. Система сервера ключей выполнена с возможностью выпуска ключей экземпляру виртуальной машины. Блок предоставления авторизации экземпляра выполнен с возможностью предоставления учетных данных для авторизации экземпляра экземпляру виртуальной машины. 6 н. и 9 з.п. ф-лы, 5 ил.
ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Изобретение относится к исполнению виртуальной машины. Изобретение дополнительно относится к выпуску ключей для экземпляра виртуальной машины.
УРОВЕНЬ ТЕХНИКИ
В последнее время облачное вычисление стало важным принципом. При облачном вычислении вычислительные ресурсы могут арендоваться в виде товара. В типовой модели облачного вычисления облачный провайдер обеспечивает виртуальные серверы, работающие на физических серверах. В данном случае, виртуальный сервер может обеспечивать подобные функциональные возможности, что и физический сервер для удаленного пользователя. Множество виртуальных серверов могут выполняться на единственном физическом сервере, так что может требоваться меньше физических серверов. Провайдеры услуг могут предоставлять один или несколько образов виртуальной машины, которые могут выполняться на облачных серверах в виде одного или нескольких экземпляров виртуальной машины.
Защита данных является важной для облачного вычисления. Шифрование потенциально играет важную роль для обеспечения защиты данных. Например, шифрованная файловая система может выполняться поверх файловой системы виртуальной машины. Кроме того, услуга Amazon S3, предоставляемая компанией Amazon Web Services, г. Сиэтл, шт. Вашингтон, США, обеспечивает шифрование на стороне сервера (SSE), делающее возможным хранение данных виртуальной машиной в зашифрованном виде.
Шифрование образа диска является методом, целью которого является защита данных в состоянии покоя, т.е. когда питание системы отключено и злоумышленник каким-то образом получил доступ к ее дискам или другому внешнему хранилищу, то, что обычно называется как «атака с выключением». Подобная атака может выполняться на виртуальных машинах (VM) с одним важным отличием: она может выполняться даже без физического доступа к системе. Если злоумышленник сумеет скомпрометировать хост виртуализации или гипервизор (локально или удаленно), тогда он может продолжить атаковать ее гостей VM. Система, названная виртуальной машиной на основе ядра (Linux KVM), позволяет системному администратору защищать гостей, которые не выполняются посредством шифрования своих образов дисков, и требуют идентификационную фразу шифрования или ключ для своего запуска.
Система виртуальных личных данных Porticor (Porticor Virtual Private Data system) (Porticor LTD, г. Рамат-ха-Шарон, Израиль) применяет технологию гомоморфного шифрования с разделенным ключом, в которой каждый объект данных, такой как диск или файл, шифруется уникальным ключом, который разделяется на два: главный ключ и конкретный ключ. Главный ключ является общим для всех объектов данных и находится во владении владельца приложения; тогда как второй конкретный ключ является разным для каждого объекта данных и хранится службой управления виртуальным ключом. Когда приложение обращается к хранилищу данных, обе части ключа используются для динамического шифрования и расшифрования данных.
US 2010/0211782 A1 описывает паттерн цифрового депонирования, предусмотренный для сетевых услуг передачи данных, включающих в себя методы шифрования с возможностью поиска для данных, хранимых в облаке, распределение доверия по многочисленным субъектам, чтобы избежать единственной точки компрометации данных. В одном варианте осуществления каждый из генератора ключей, провайдера криптографической технологии и провайдера облачных услуг обеспечивается в виде отдельных субъектов, позволяя издателю данных издавать данные конфиденциально провайдеру облачных услуг и затем выставлять зашифрованные данные селективно подписчикам, запрашивающим эти данные, основываясь на идентификационной информации подписчика, кодированной в информации ключа, сгенерированной в ответ на запросы подписчика, например, роль подписчика.
US 2011/0296201 A1 описывает способ и устройство, выполненные с возможностью обеспечения доверенного исполнения виртуальных машин (VM) на сервере виртуализации, например, для исполнения VM на сервере виртуализации. Физические многоядерные центральные процессоры (CPU) могут быть выполнены с аппаратной доверенной привязкой. Сама доверенная привязка может быть выполнена с возможностью управления сеансовыми ключами, используемыми для шифрования/расшифрования инструкций и данных, когда VM (или гипервизор) исполняется на одном из ядер CPU. Когда имеет место контекстный переключатель из-за исключительной ситуации, доверенная привязка меняет местами сеансовый ключ, используемый для шифрования/расшифрования содержимого памяти и кэша, распределенного для VM (или гипервизора).
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Было бы полезным иметь улучшенное манипулирование экземпляром виртуальной машины. Чтобы обеспечить лучшее решение этой проблемы, согласно первому аспекту изобретения предложена система, содержащая среду исполнения для создания экземпляра виртуальной машины, которая содержит:
блок авторизации экземпляра для приема учетных данных для авторизации экземпляра, причем учетные данные для авторизации экземпляра однозначно связаны с экземпляром виртуальной машины;
блок ключа данных для генерирования запроса ключа данных, основываясь на учетных данных для авторизации экземпляра, связанных с экземпляром виртуальной машины; и
блок расшифрования для расшифрования элемента данных, основываясь на ключе данных.
Учетные данные для авторизации экземпляра обеспечивают экземпляру виртуальной машины путь идентифицировать себя, так как учетные данные для авторизации экземпляра однозначно связаны с экземпляром виртуальной машины. Таким образом, запрос ключа данных может распознаваться как исходящий от экземпляра виртуальной машины, и, таким образом, субъект, внешний по отношению к экземпляру виртуальной машины, может определить, основываясь на запросе, может ли ключ данных выпускаться для экземпляра виртуальной машины, и, например, какой ключ данных из множества доступных ключей данных может выпускаться для экземпляра виртуальной машины.
Экземпляр виртуальной машины может дополнительно содержать блок учетных данных пользователя для получения учетных данных пользователя, связанных с пользователем или группой пользователей. Таким образом, экземпляр виртуальной машины имеет как учетные данные для авторизации экземпляра, связанные с экземпляром виртуальной машины, так и учетные данные пользователя, связанные с пользователем или группой пользователей. Блок ключа данных может быть выполнен с возможностью генерирования запроса, дополнительно основываясь на учетных данных пользователя. Это позволяет приемнику запроса идентифицировать как экземпляр виртуальной машины, так и пользователя, так что приемник запроса может определить, предоставлять ли конкретный ключ данных, основываясь на обоих субъектах. Альтернативно, блок расшифрования может быть выполнен с возможностью расшифрования элемента данных, дополнительно основываясь на учетных данных пользователя. Таким образом, учетные данные пользователя могут использоваться вместе с ключом данных для расшифрования данных. В обоих случаях экземпляру виртуальной машины необходимы как учетные данные пользователя, так и учетные данные для авторизации экземпляра, чтобы получить доступ к элементу данных в его незашифрованном виде.
Блок авторизации экземпляра может быть выполнен с возможностью выдачи запроса учетных данных для авторизации экземпляра, причем запрос указывает по меньшей мере один атрибут, который является характерным для экземпляра виртуальной машины. Это позволяет экземпляру виртуальной машины активно запрашивать учетные данные для авторизации экземпляра. По меньшей мере одним атрибутом, например, может быть набор атрибутов, которые вместе однозначно идентифицируют экземпляр виртуальной машины.
Система может дополнительно содержать блок владельца экземпляра для регистрации кода авторизации, связанного с экземпляром виртуальной машины, на сервере ключей и для предоставления кода авторизации экземпляру виртуальной машины; причем упомянутый по меньшей мере один атрибут содержит код авторизации. Это позволяет блоку владельца контролировать возможности расшифрования экземпляра виртуальной машины.
Блок владельца экземпляра может быть выполнен с возможностью посылки инструкции, содержащей код авторизации, среде исполнения виртуальных машин. Среда исполнения может быть выполнена с возможностью создания экземпляра виртуальной машины и предоставления кода авторизации экземпляру виртуальной машины в ответ на прием данной инструкции. Это позволяет владельцу экземпляра вызывать создание средой исполнения экземпляра виртуальной машины с возможностями расшифрования, ассоциированными с кодом авторизации.
Блок владельца экземпляра и среда исполнения могут быть реализованы на двух отдельных аппаратных субъектах, соединенных посредством сети. Система позволяет улучшить доверие к экземпляру виртуальной машины, который эксплуатируется блоком владельца экземпляра из удаленного расположения по сети, посредством контролирования кода авторизации, предоставленного экземпляру виртуальной машины и/или ключей данных, выпущенных для экземпляра виртуальной машины.
Блок ключа данных может быть выполнен с возможностью включения в запрос ключа данных кода, который указывает на положение запроса в последовательности запросов, выданных экземпляром виртуальной машины. Это позволяет обнаруживать незаконную копию экземпляра виртуальной машины, так как когда два экземпляра виртуальной машины используют одни и те же учетные данные для авторизации экземпляра, это может быть обнаружено кодом, указывающим на положение запроса в последовательности запросов, выданных экземпляром виртуальной машины. В частности, может обнаруживаться не строго увеличивающееся положение в последующих запросах.
Экземпляр виртуальной машины может быть выполнен с возможностью хранения ключа данных и данных, расшифрованных с использованием ключа данных, в энергозависимой памяти и/или стирания ключа данных и данных, расшифрованных с использованием ключа данных, после использования. Это предотвращает то, что ключ данных и/или элемент данных будут сохраняться в постоянной памяти и/или будут присутствовать в памяти в течение более длительной продолжительности, чем необходимо.
Согласно другому аспекту изобретения, предложена система сервера ключей для выпуска ключей для экземпляра виртуальной машины, причем система сервера ключей содержит
блок идентификации экземпляра для идентификации экземпляра виртуальной машины, основываясь на по меньшей мере одном атрибуте, который является характерным для экземпляра виртуальной машины;
средство определения (определитель) авторизации экземпляра для определения учетных данных для авторизации экземпляра и однозначного связывания учетных данных для авторизации экземпляра с экземпляром виртуальной машины;
блок предоставления авторизации экземпляра для предоставления учетных данных для авторизации экземпляра экземпляру виртуальной машины;
средство приема (приемник) запроса ключа данных для приема запроса ключа данных от экземпляра виртуальной машины, причем запрос ключа данных содержит компонент авторизации экземпляра, связанный с учетными данными для авторизации экземпляра;
блок авторизации данных для определения того, авторизован ли экземпляр виртуальной машины для приема ключа данных, основываясь на компоненте авторизации экземпляра; и
блок предоставления ключа данных для предоставления ключа данных экземпляру виртуальной машины, если экземпляр виртуальной машины авторизован на прием ключа данных.
Система сервера ключей может контролировать распределение ключа данных экземпляру виртуальной машины. Из-за атрибута, который является характерным для экземпляра виртуальной машины, и последующего выпуска учетных данных для авторизации экземпляра, которые однозначно связываются с экземпляром виртуальной машины, аутентификация экземпляра виртуальной машины выполняется более безопасно, а также процесс авторизации. Кроме того, «незаконные» экземпляры виртуальной машины могут представляться бесполезными, так как им не могут быть даны учетные данные для авторизации экземпляра, так что они не могут генерировать действительный запрос ключа данных. Блок авторизации данных может использовать одну или несколько политик для определения того, авторизован ли экземпляр виртуальной машины на прием ключа данных. Такая политика может указывать, что разрешено и что не разрешено, может быть статичной или динамичной, и может зависеть от свойств данных, вышеупомянутых атрибутов и упомянутых в другом месте ассоциированных пользователей и/или расположения. По меньшей мере одним атрибутом, например, может быть набор атрибутов, которые вместе однозначно идентифицируют экземпляр виртуальной машины.
Система сервера ключей может дополнительно содержать приемник запроса учетных данных экземпляра для приема запроса учетных данных для авторизации экземпляра от экземпляра виртуальной машины, причем запрос указывает атрибут, который является характерным для экземпляра виртуальной машины; и блок проверки достоверности экземпляра для верификации достоверности экземпляра виртуальной машины, основываясь на атрибуте. Это позволяет самому экземпляру виртуальной машины запрашивать учетные данные для авторизации экземпляра виртуальной машины. Используя атрибут, который является характерным для экземпляра виртуальной машины, становится возможным идентифицировать экземпляр виртуальной машины для системы сервера ключей.
Блок проверки достоверности экземпляра может быть выполнен с возможностью выполнения верификации достоверности экземпляра виртуальной машины, дополнительно основываясь на атрибуте, указывающим на расположение экземпляра виртуальной машины, или блок авторизации данных выполнен с возможностью выполнения определения того, авторизован ли экземпляр виртуальной машины на прием ключа данных, дополнительно основываясь на расположении экземпляра виртуальной машины. Это позволяет выполнять мониторинг расположения экземпляра виртуальной машины и запрещать учетные данные для авторизации экземпляра или ключ данных для экземпляра виртуальной машины, который не находится в надлежащем расположении. Расположение экземпляра виртуальной машины, например, может представлять собой расположение физического устройства, содержащего процессор и/или память и/или запоминающее устройство, на котором исполняется экземпляр виртуальной машины.
Запрос ключа данных может дополнительно указывать на учетные данные пользователя, которые связаны с пользователем или группой пользователей экземпляра виртуальной машины. Блок авторизации данных может быть выполнен с возможностью выполнения определения того, авторизован ли экземпляр виртуальной машины на прием ключа данных, дополнительно основываясь на указании учетных данных пользователя, принятых с запросом ключа данных, и политике доступа к данным, защищенным ключом данных. Таким образом, ключ данных предоставляется только авторизованному экземпляру виртуальной машины и только если экземпляр виртуальной машины обладает соответствующими учетными данными пользователя.
Система сервера ключей может содержать блок записи для записи информации, относящейся к передачам данных, касающимся запросов авторизации, учетных данных и/или ключей данных. Такая информация записи может использоваться для выполнения анализа прошедших событий, обнаружения любых возможных паттернов, указывающих, например, на злоупотребление.
Согласно другому аспекту, изобретение предусматривает образ виртуальной машины, способный реализоваться в виде экземпляра виртуальной машины, причем образ виртуальной машины содержит:
код инструкции, вызывающий прием экземпляром виртуальной машины учетных данных для авторизации экземпляра, причем учетные данные для авторизации экземпляра однозначно связаны с экземпляром виртуальной машины;
код инструкции, вызывающий генерирование экземпляром виртуальной машины запроса ключа данных, основываясь на учетных данных для авторизации экземпляра, связанных с экземпляром виртуальной машины; и
код инструкции, вызывающий расшифрование экземпляром виртуальной машины элемента данных, основываясь на ключе данных.
Согласно еще одному аспекту, изобретение предусматривает способ исполнения экземпляра виртуальной машины, причем способ содержит, посредством экземпляра виртуальной машины:
прием учетных данных для авторизации экземпляра, причем учетные данные для авторизации экземпляра однозначно связаны с экземпляром виртуальной машины;
генерирование запроса ключа данных, основываясь на учетных данных для авторизации экземпляра, связанных с экземпляром виртуальной машины; и
расшифрование элемента данных, основываясь на ключе данных.
Согласно еще одному аспекту, изобретение предусматривает способ выпуска ключей для экземпляра виртуальной машины, содержащий
идентификацию экземпляра виртуальной машины, основываясь на по меньшей мере одном атрибуте, который является характерным для экземпляра виртуальной машины;
определение учетных данных для авторизации экземпляра, и однозначное связывание учетных данных для авторизации экземпляра с экземпляром виртуальной машины;
предоставление учетных данных для авторизации экземпляра экземпляру виртуальной машины;
прием запроса ключа данных от экземпляра виртуальной машины, причем запрос ключа данных содержит компонент авторизации экземпляра, связанный с учетными данными для авторизации экземпляра;
определение того, является ли экземпляр виртуальной машины авторизованным на прием ключа данных, основываясь на компоненте авторизации экземпляра; и
предоставление ключа данных экземпляру виртуальной машины, если экземпляр виртуальной машины авторизован на прием ключа данных.
Согласно еще одному аспекту, изобретение предусматривает компьютерный программный продукт, содержащий инструкции, вызывающие выполнение процессорной системой любого способа, изложенного в данном документе.
Для специалиста в данной области техники понятно, что два или более из вышеупомянутых вариантов осуществления, реализаций и/или аспектов изобретения могут быть объединены любым образом, который считается полезным.
Модификации и изменения системы, экземпляра виртуальной машины, системы сервера ключей, способов и/или компьютерного программного продукта, которые соответствуют описанным модификациям и изменениям системы, могут осуществляться специалистом в данной области техники на основе настоящего описания.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Эти и другие аспекты изобретения очевидны из чертежей и разъясняются ниже в данном документе со ссылкой на них. На чертежах подобные элементы обозначены одинаковыми ссылочными позициями.
Фиг.1 представляет блок-схему среды исполнения, в которой может исполняться экземпляр виртуальной машины.
Фиг.2 представляет блок-схему системы сервера ключей.
Фиг.3 представляет блок-схему образа виртуальной машины.
Фиг.4 представляет блок-схему последовательности операций способа исполнения экземпляра виртуальной машины.
Фиг.5 представляет блок-схему последовательности операций способа выпуска ключей экземпляру виртуальной машины.
ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ
Виртуальная машина может рассматриваться как изолированная установка гостевой операционной системы в нормальной главной операционной системе или выделенный гипервизор. Например, виртуальная машина может быть реализована посредством или эмуляции программных средств или виртуализации аппаратных средств. Как эмуляция программных средств, так и виртуализация аппаратных средств могут быть реализованы вместе. Программные средства, исполняющиеся в виртуальной машине, могут ограничиваться ресурсами и абстракциями, обеспечиваемыми виртуальной машиной - она не может нарушить свою виртуальную среду. Хотя первоначально виртуальные машины имели своей целью обеспечение эффективного изолированного дублирования реальной машины. Однако текущее использование виртуальных машин включает в себя виртуальные машины, которые не имеют прямого соответствия с любыми реальными аппаратными средствами.
Экземпляр виртуальной машины может иметь определение типа, включающее в себя, например, образ виртуальной машины, который определяет данные, содержащиеся в виртуальной машине при запуске исполнения виртуальной машины. Фактическая виртуальная машина, когда она исполняется в среде исполнения, может отличаться от определения типа виртуальной машины термином экземпляр виртуальной машины.
Фиг.1 иллюстрирует аспекты системы для исполнения экземпляра 10 виртуальной машины. Система может содержать среду 11 исполнения, которая контролирует исполнение экземпляра 10 виртуальной машины. Среда 11 исполнения может быть выполнена с возможностью контролирования исполнения множества экземпляров 10 виртуальной машины, которые могут работать на распределенной компьютерной системе. Система может содержать создателя 15 экземпляра, который может быть частью среды 11 исполнения, как показано на фиг.1, или он может быть выполнен в виде блока, отдельного от среды 11 исполнения. Создатель 15 экземпляра может создавать экземпляр 10 виртуальной машины, например, основываясь на образе виртуальной машины (не показан), который определяет код инструкции виртуальной машины. Создатель 15 экземпляра, возможно вместе с образом виртуальной машины, может действовать для создания одного или нескольких экземпляров 10 виртуальной машины таким образом, что экземпляр 10 виртуальной машины включает в себя несколько кодов инструкции. Коды инструкции, которые вместе являются ответственными за конкретную функциональную возможность, могут упоминаться как блок. Такие блоки могут логически размещаться в программных модулях; однако, они также могут быть разделены на множество программных модулей.
Экземпляр 10 виртуальной машины может содержать блок 1 авторизации экземпляра, выполненный с возможностью приема учетных данных для авторизации экземпляра. Эти учетные данные для авторизации экземпляра могут создаваться вне экземпляра виртуальной машины авторизованным субъектом. Кроме того, учетные данные для авторизации экземпляра могут однозначно связываться с экземпляром 10 виртуальной машины. Это означает, что одни и те же учетные данные для авторизации не предоставляются никакому другому экземпляру 10 виртуальной машины.
Экземпляр виртуальной машины может дополнительно содержать блок 2 ключа данных, выполненный с возможностью генерирования запроса ключа данных, основываясь на учетных данных для авторизации экземпляра, связанных с экземпляром 10 виртуальной машины. Например, учетные данные для авторизации могут быть включены в запрос, или подтверждение того, что виртуальная машина обладает учетными данными для авторизации, может быть включено в запрос. Запрос может дополнительно указывать один или несколько элементов данных, например, элементов контента или защищенных элементов истории болезни, причем эти элементы данных могут быть зашифрованными. Запрос может влечь за собой запрос ключа данных для одного или нескольких элементов данных.
Блок 2 ключа данных может быть дополнительно выполнен с возможностью приема ключа данных, который может посылаться экземпляру 10 виртуальной машины в ответ на запрос.
Экземпляр виртуальной машины может дополнительно содержать блок 3 расшифрования, выполненный с возможностью расшифрования элемента 7 данных, основываясь на ключе данных. Например, элемент 7 данных извлекается из внешней базы данных в зашифрованном виде. Способ, посредством которого экземпляр виртуальной машины получает доступ к зашифрованному элементу 7 данных, может быть любым известным для специалиста в данной области техники. Например, зашифрованный элемент 7 данных может извлекаться посредством интерфейса базы данных или посредством файловой системы. Может использоваться любой подходящий алгоритм шифрования.
Экземпляр 10 виртуальной машины может дополнительно содержать блок 4 учетных данных пользователя, выполненный с возможностью получения учетных данных пользователя, ассоциированных с пользователем или группой пользователей, и при этом блок 2 ключа данных выполнен с возможностью генерирования запроса, дополнительно основываясь на учетных данных пользователя, или блок 3 расшифрования выполнен с возможностью расшифрования элемента 7 данных, дополнительно основываясь на учетных данных пользователя. В любом случае, это добавляет способ аутентификации пользователя к способу аутентификации виртуальной машины, описанному выше. Учетные данные пользователя могут использоваться для обеспечения того, что только авторизованные пользователи могут получить доступ к защищенным данным. Учетные данные для авторизации экземпляра могут использоваться для обеспечения того, что такой авторизованный доступ происходит только через авторизованные экземпляры виртуальной машины. Таким образом, неавторизованные (и потенциально злонамеренные) экземпляры виртуальной машины, даже если они сумеют получить учетные данные пользователя, не могут использоваться для получения неавторизованного доступа к защищенным данным, из-за отсутствия учетных данных для авторизации экземпляра.
Блок 1 авторизации экземпляра может быть выполнен с возможностью выдачи запроса учетных данных для авторизации экземпляра, причем запрос указывает на по меньшей мере один атрибут, который является характерным для экземпляра виртуальной машины. Например, запрос может посылаться на сервер, который является ответственным за предоставление учетных данных для авторизации экземпляра. Атрибут может указывать, например, время создания экземпляра или идентификатор (ID) процесса, адрес сети и другие виды параметров, которые (вместе) могут идентифицировать экземпляр виртуальной машины. «По меньшей мере одним атрибутом, который является характерным для экземпляра виртуальной машины» может быть набор значений, которые вместе являются характерными или уникальными для идентификации экземпляра виртуальной машины.
В одной примерной реализации система может включать в себя блок 5 владельца экземпляра для регистрации кода авторизации, связанного с экземпляром 10 виртуальной машины в системе 6 сервера ключей, и предоставления кода авторизации экземпляру 10 виртуальной машины. Блок 1 авторизации экземпляра может быть выполнен с возможностью включения атрибута, указывающего код авторизации в запросе учетных данных для авторизации экземпляра.
Блок 5 владельца экземпляра может быть выполнен с возможностью посылки инструкции, содержащей код авторизации, среде 11 исполнения виртуальных машин, и при этом среда 11 исполнения выполнена с возможностью создания экземпляра 10 виртуальной машины и предоставления кода авторизации экземпляру 10 виртуальной машины в ответ на прием инструкции. Например, блок 5 владельца экземпляра может быть выполнен с возможностью посылки инструкции, содержащей код авторизации, блоку 13 контроля среды 11 исполнения, как указано стрелкой 14. Блок 13 контроля затем взаимодействует с создателем 15 экземпляра для создания экземпляра 10 виртуальной машины и обеспечения его с кодом авторизации. Альтернативно, блок 5 владельца экземпляра может быть выполнен с возможностью посылки кода авторизации блоку 1 авторизации экземпляра в экземпляре 10 виртуальной машины, как указано стрелкой 12 на фиг.1.
Среда 11 исполнения альтернативно может быть выполнена с возможностью предоставлять учетные данные для авторизации экземпляра экземпляру 10 виртуальной машины автоматически, когда она создает экземпляр 10 виртуальной машины, и согласовывать с системой 6 сервера ключей то, какие использовать учетные данные для авторизации экземпляра.
Блок 2 ключа данных может быть выполнен с возможностью включения в запрос ключа данных кода, который указывает на положение запроса в последовательности запросов ключей данных, выдаваемых экземпляром 10 виртуальной машины. Посредством использования нумерации запросов ключа, может быть обнаружено, когда больше субъектов, например, более одного экземпляра виртуальной машины, используют одни и те же учетные данные для авторизации экземпляра. Код может содержать, например, порядковый номер. Этот порядковый номер может шифроваться, либо хеш-код или подпись порядкового номера может использоваться, например, для повышения защищенности.
Экземпляр 10 виртуальной машины может быть выполнен с возможностью сохранения ключа данных и/или данных, расшифрованных с использованием ключа данных, в энергозависимой памяти и/или стирания ключа данных и данных, расшифрованных с использованием ключа данных, после использования. Таким образом, защищенные данные не хранятся внутри среды 11 исполнения больше того времени, которое необходимо для немедленного использования. Если снова необходим элемент 7 данных, может снова запрашиваться ключ данных.
Фиг.2 иллюстрирует систему 6 сервера ключей для выпуска ключей для экземпляра 10 виртуальной машины. Система 6 сервера ключей и/или среда 11 исполнения могут быть реализованы на одной и той же или отдельной серверной системе.
Система сервера ключей может содержать средство 32 выпуска учетных данных экземпляра, содержащее модули, ответственные за выпуск учетных данных для авторизации экземпляра. Кроме того, система сервера ключей содержит средство 31 выпуска ключа данных, содержащее модули, ответственные за выпуск ключей данных. Это изображено на фиг.2. Однако это только примерная неограничивающая архитектура реализации системы 6 сервера ключей.
Система 6 сервера ключей может содержать блок 20 идентификации экземпляра, выполненный с возможностью идентификации экземпляра 10 виртуальной машины, основываясь на по меньшей мере одном атрибуте, который является характерным для экземпляра 10 виртуальной машины. Например, система сервера ключей может вести таблицу, которая содержит один или несколько представительных атрибутов для каждого экземпляра 10 виртуальной машины.
Системе 6 сервера ключей может дополнительно содержать определитель 21 авторизации экземпляра, выполненный с возможностью определения учетных данных для авторизации экземпляра. Например, средство определения (определитель) 21 авторизации экземпляра может быть выполнено с возможностью генерирования учетных данных для авторизации экземпляра, например, используя генератор псевдослучайных чисел, в частности криптостойкий генератор псевдослучайных чисел. Учетные данные для авторизации экземпляра, например, могут указывать криптографический ключ. Определитель авторизации экземпляра может быть выполнен с возможностью однозначного связывания учетных данных для авторизации экземпляра с экземпляром 10 виртуальной машины. Это может быть реализовано, например, посредством вышеупомянутой таблицы. Другие реализации, такие как использование базы данных, являются известными для специалиста в данной области техники.
Система 6 сервера ключей может содержать блок 22 предоставления авторизации экземпляра, выполненный с возможностью предоставления учетных данных для авторизации экземпляра экземпляру 10 виртуальной машины. Например, учетные данные доставляются экземпляру 10 виртуальной машины, используя протокол передачи данных.
Система 6 сервера ключей может дополнительно содержать средство приема (приемник) 23 запроса ключа данных, выполненное с возможностью приема запроса ключа данных от экземпляра 10 виртуальной машины. Запрос ключа данных может содержать компонент авторизации экземпляра, связанный с учетными данными для авторизации экземпляра. Этот компонент может иметь любой подходящий вид, такой как отдельный элемент данных или конкретное преобразование другого элемента данных запроса, такого как криптографическая подпись.
Система 6 сервера ключей может дополнительно содержать блок 24 авторизации данных, выполненный с возможностью определения того, является ли экземпляр 10 виртуальной машины авторизованным на прием ключа данных, основываясь на компоненте авторизации экземпляра. Эта функциональная возможность может обеспечивать верификацию криптографического ключа, связанного с компонентом авторизации экземпляра.
Система 6 сервера ключей может дополнительно содержать блок 25 представления ключа данных, выполненный с возможностью предоставления ключа данных экземпляру 10 виртуальной машины, если экземпляр 10 виртуальной машины авторизован на прием ключа данных, что определяется блоком 24 авторизации данных.
Система 6 сервера ключей может дополнительно содержать приемник 27 запроса учетных данных экземпляра, выполненный с возможностью приема запроса учетных данных для авторизации экземпляра от экземпляра 10 виртуальной машины. Запрос может указывать атрибут, который является характерным для экземпляра 10 виртуальной машины.
Система 6 сервера ключей может дополнительно содержать блок 28 проверки достоверности экземпляра, выполненный с возможностью верификации достоверности экземпляра 10 виртуальной машины, основываясь на указании атрибута, принятого приемником 27 запроса учетных данных экземпляра.
Блок 28 проверки достоверности экземпляра может быть выполнен с возможностью выполнения верификации достоверности экземпляра 10 виртуальной машины, дополнительно основываясь на атрибуте, указывающем на расположение экземпляра 10 виртуальной машины. Кроме того, блок 24 авторизации данных может быть выполнен с возможностью выполнения определения того, является ли экземпляр 10 виртуальной машины авторизованным на прием ключа данных, дополнительно основываясь на расположении экземпляра 10 виртуальной машины.
Запрос ключа данных может дополнительно указывать учетные данные пользователя, которые связаны с пользователем или группой пользователей экземпляра 10 виртуальной машины. Кроме того, блок 24 авторизации данных может быть выполнен с возможностью выполнения определения того, является ли экземпляр 10 виртуальной машины авторизованным на прием ключа данных, дополнительно основываясь на указании учетных данных пользователя, принятых с запросом ключа данных, и на политике доступа к данным, защищенным ключом данных.
Система 6 сервера ключей может дополнительно содержать блок 29, 30 записи для записи информации, относящейся к передаче данных, касающейся запросов авторизации, учетных данных и/или ключей данных. Запись может выполняться средством 32 выпуска учетных данных экземпляра и также средством 31 выпуска ключа данных. Это может выполняться единым блоком записи или двумя отдельными блоками 29, 30 записи.
Фиг.3 иллюстрирует компоненты образа 100 виртуальной машины. Образ 100 виртуальной машины может обеспечивать определение виртуальной машины. Среда 11 исполнения может быть выполнена с возможностью создания экземпляра 10 виртуальной машины, основываясь на образе 100 виртуальной машины. Образ виртуальной машины может содержать код 101 инструкции, вызывающий прием экземпляром 10 виртуальной машины учетных данных для авторизации экземпляра, причем учетные данные для авторизации экземпляра однозначно связаны с экземпляром 10 виртуальной машины; код 102 инструкции, вызывающий генерирование экземпляром 10 виртуальной машины запроса ключа данных, основываясь на учетных данных для авторизации экземпляра, связанных с экземпляром 10 виртуальной машины; и/или код 103 инструкции, вызывающий расшифрование экземпляром 10 виртуальной машины элемента данных, основываясь на ключе данных. Данный образ 100 виртуальной машины может быть расширен и/или модифицирован специалистом в данной области техники, основываясь на описании и фигурах, относящихся, между прочим, к экземпляру 10 виртуальной машины в настоящем раскрытии.
Фиг.4 иллюстрирует способ исполнения экземпляра виртуальной машины. Виртуальная машина может выполнять следующие этапы во время своего исполнения:
- прием 201 учетных данных для авторизации экземпляра, причем учетные данные для авторизации экземпляра однозначно связаны с экземпляром виртуальной машины;
- генерирование 202 запроса ключа данных, основываясь на учетных данных для авторизации экземпляра, связанных с экземпляром виртуальной машины; и/или
- расшифрование 203 элемента данных, основываясь на ключе данных.
Фиг.5 иллюстрирует способ выпуска ключей экземпляру виртуальной машины. Способ может содержать следующие этапы:
- идентификации 301 экземпляра виртуальной машины, основываясь на по меньшей мере одном атрибуте, который является характерным для экземпляра виртуальной машины;
- определения 302 учетных данных для авторизации экземпляра и однозначного связывания учетных данных для авторизации экземпляра с экземпляром виртуальной машины;
- предоставление 303 учетных данных для авторизации экземпляра экземпляру виртуальной машины;
- приема 304 запроса ключа данных от экземпляра виртуальной машины, причем запрос ключа данных содержит компонент авторизации экземпляра, связанный с учетными данными для авторизации экземпляра;
- определения 305 того, является ли экземпляр виртуальной машины авторизованным на прием ключа данных, основываясь на компоненте авторизации экземпляра; и/или
- предоставления 306 ключа данных экземпляру виртуальной машины, если экземпляр виртуальной машины авторизован на прием ключа данных.
Эти способы могут быть расширены и/или модифицированы специалистом в данной области техники, основываясь на описаниях и фигурах настоящего раскрытия. Кроме того, способы и системы, описанные в данном документе, могут быть реализованы, по меньшей мере частично, в виде продукта компьютерной программы.
Методики, описанные в данном документе, могут использоваться для рассмотрения одной или нескольких проблем, относящихся к обеспечению безопасности виртуальных машин, например, при облачных вычислениях. Например, может исключаться фатальность единственной точки неблагоприятного исхода, например, посредством обеспечения встроенного разделения разбиения выполняемых функций и безопасности. Защита может быть сделана более ориентированной на данные и более мелкоструктурной. Кроме того, может быть улучшено управление ключами.
Неавторизованный доступ к экземпляру виртуальной машины или потеря или кража образа виртуальной машины может привести к существенной бреши конфиденциальности ассоциированных данных без контроля, оставшегося у владельца данных, который передал вычисления «облаку». Эта проблема может быть уменьшена, использованием методик, описанных в данном документе. Данные могут шифроваться, и может обеспечиваться способ запроса экземпляром виртуальной машины ключа для зашифрованных объектов данных у внешней службы ключей. Это может разделять ответственность на две стороны вместо ситуации, в которой безопасность зависит от стойкости отдельной стороны, которая имеет доступ как к данным, так и к ключам, такой как пользователь облака и/или облачный провайдер с его средой исполнения для виртуальных машин.
Способ динамического получения ключей расшифрования данных экземпляром облачной виртуальной машины может включать в себя этапы: 1) экземпляр облачной виртуальной машины получает уникальный идентификатор и авторизацию, 2) экземпляр облачной виртуальной машины запрашивает ключ для зашифрованного объекта данных в службе ключей, 3) служба ключей обрабатывает запрос, оценивает то, авторизована ли виртуальная машина, и в случае положительной оценки отвечает ключом для объектов данных.
Методики, описанные в данном документе, позволяют данным оставаться в зашифрованном виде почти постоянно, тогда как ключи расшифрования сохраняются где-либо в другом месте. Ключи для расшифрования данных могут выпускаться только заданным авторизованным виртуальным машинам. Данные могут быть доступны в незашифрованном виде только в момент, когда они обрабатываются. Расшифрованные данные могут быть удалены, как только они больше не являются необходимыми. Ключи выпускаются на временной основе и могут сохраняться только в памяти, и нет необходимости хранить их постоянно. Такое воздержание от постоянного хранения может осуществляться средой 11 исполнения.
Ниже представлено несколько вариантов осуществления. Эти варианты осуществления изображены в виде последовательностей обмена передачами данных, обозначенными посредством нескольких таблиц взаимодействия, показанных ниже. Таблицы взаимодействия используют следующую систему обозначения: «источник – [сообщение(параметр, …)] → пункт назначения». Эта система обозначений означает, что субъект «источник» посылает сообщение типа, указанного «сообщением» и с параметрами «параметр, …» другому субъекту «пункт назначения», который принимает сообщение. Такая передача сообщения может принимать вид сообщения, вызова веб-службы, вызова API (интерфейса прикладного программирования) или любого другого протокола передачи данных.
Могут шифроваться объекты данных, которые должны использоваться в экземпляре виртуальной машины. Объекты данных могут быть данными любого типа, такими как числовые и текстовые значения, ячейки базы данных, файлы и даже файловые системы. Когда эти объекты данных должны использоваться, запрашивается правильный ключ расшифрования экземпляром виртуальной машины у сервера ключей. Этот сервер может хостироваться независимо от экземпляра виртуальной машины, чтобы повысить безопасность. Таблица 1 иллюстрирует разные этапы, которые могут быть включены в систему шифрования для виртуальных машин.
| Таблица 1 |
| Создание экземпляра, персонализация, извлечение ключа диаграммы взаимодействия |
| 1. serviceProvider –[createInstance()]→ cloudManagementServer 2. cloudManagementServer –[createInstance(VMimage)]→ cloudServer 3. VMinstance –[personalisationRequest(VMinstanceAttributes, f(VMimageKey))]→ keyServer 4. keyServer –[personalizationResponse(VMinstanceIdentity, VMinstanceKey)]→ VMinstance 5. VMinstance –[keyRequest(dataID, h(VMinstanceKey))]→ keyServer 6. keyServer –[keyResponse(dataKey)]→ VMinstance |
Обычно serviceProvider (провайдер услуг) может предоставлять интерфейс человеку или субъекту, контролирующему создание новых экземпляров. serviceProvider, таким образом, выдает команду на cloudManagementServer (сервер управления облаком) создать экземпляр. cloudManagementServer может хостироваться третьей стороной, например, которая предоставляет вычислительные ресурсы в качестве услуги. cloudServer (облачный сервер) может представлять собой серверную систему, на которой исполняется виртуальная машина (VM). VMinstance означает экземпляр виртуальной машины, и VMimage означает образ виртуальной машины. Этапы 1 и 2 в таблице 1 создают и запускают экземпляр виртуальной машины из образа виртуальной машины. Этапы могут инициироваться провайдером услуг, который инструктирует cloudManagementServer на создание образа виртуальной машины на cloudServer. Образ виртуальной машины (VMimage) содержит приложение провайдера услуг. Результатом этапов 1 и 2 является выполняющийся экземпляр образа на облачном сервере.
Этапы 3 и 4 персонализируют и авторизуют экземпляр виртуальной машины. Так как образ виртуальной машины может создаваться много раз, что приводит к многочисленным идентичным экземплярам, этапы 3 и 4 обеспечивают персонализацию, которая используется для дифференциации безопасности между экземплярами. Это применяется, в частности, к серверу ключей, который должен точно знать, какому экземпляру он посылает ключи расшифрования. Он может принимать меры в ответ на опасности, такие как неавторизованное создание образов виртуальной машины злонамеренным своим человеком или посторонним. Это уменьшает опасность того, что взломщик останется необнаруженным. VMinstance посылает на этапе 3 набор из одного или нескольких атрибутов, которые однозначно идентифицируют VMinstance для keyServer (сервер клюей). Набор атрибутов может включать в себя, в необязательном порядке, идентификационную информацию образа, используемого для создания VMinstance. VMinstance дополнительно посылает на этапе 3 ключ VmimageKey (ключ образа VM), который связан с VMimage (при этом f обозначает любую заранее заданную функцию), на keyServer. На этапе 4 keyServer отвечает необязательным указанием идентификатора экземпляра и ключа экземпляра (VMinstancekey). Как описано выше в данном документе, эти идентификатор и ключ могут быть заменены любыми подходящими учетными данными для авторизации образа виртуальной машины.
Чтобы персонализировать экземпляр виртуальной машины, экземпляр включает в себя несколько атрибутов, которые потенциально могут использоваться для дифференциации экземпляра от других экземпляров. Примерные атрибуты для идентификации экземпляра включают в себя общий адрес протокола Интернета (IP), ID образа, используемый для запуска экземпляра, и ID экземпляра. Авторизация экземпляров может гарантировать, что только законные экземпляры получают доступ к ключам расшифровки данных. С целью авторизации экземпляры используют, например, ключ образа виртуальной машины. На этапе 3 ключ используется для подписи запроса персонализации, где f() представляет, в данном случае, функцию подписания. Эта подпись является частью набора атрибутов, характерных для экземпляра виртуальной машины. Сервер ключей в необязательном порядке верифицирует, что ключ авторизованного образа используется как часть процесса авторизации экземпляра VM. Он также выполняет некоторые проверки для других предоставляемых атрибутов. Атрибуты делают возможным практическую персонализацию, так как они позволяют выполнять различение между виртуальными машинами. Атрибуты также могут использоваться в процессе авторизации для авторизации экземпляра VM после ключа образа. Если верификации и проверки являются положительными, сервер ключей отвечает на этапе 4 идентификатором для экземпляра, подлежащим использованию в последующих взаимодействиях, и ключом экземпляра для доказательства того, что он авторизован, и для практического использования для обеспечения безопасности (например, подписания, аутентификации, расшифрования и т.д.) последующих взаимодействий. Идентификатор экземпляра и ключ экземпляра служат в качестве учетных данных для авторизации в последующих запросах. Также могут использоваться другие виды учетных данных для авторизации.
Этапы 5 и 6 извлекают ключ данных, чтобы сделать возможным расшифрование данных. Экземпляр виртуальной машины запрашивает ключ для конкретного объекта данных посредством идентификации его посредством dataID. Экземпляр виртуальной машины также представляет ее учетные данные для авторизации, которые, например, содержат идентификатор экземпляра и подпись, созданную из ключа экземпляра (обозначенного h() на этапе 5). Сервер ключей оценивает запрос и после положительной оценки отвечает на запрос ключом данных.
Если экземпляр виртуальной машины получил ключ расшифрования, он может расшифровывать объект данных и обрабатывать его. Экземпляр должен удалить расшифрованные данные, когда они больше ему не нужны.
Экземпляр может быть сконфигурирован на хранение всех ключей и расшифрованных данных в памяти и предотвращение того, чтобы они были переписаны на диск посредством использования особенностей, предусмотренных операционной системой. Кроме того, должно быть ограничено время существования ключа и данных. Должен истечь срок действия расшифрованных данных и ключей данных, когда они больше не являются необходимыми. Ключи экземпляра уничтожаются после того, как экземпляр прекращает выполнение.
В модификации на этапе 5, этап включает в себя учетные данные пользователя для пользователя экземпляра виртуальной машины для дополнительного контроля доступа к ключам расшифрования, основываясь на зависимой от пользователя авторизации, так что этап 5 в таблице 1 выше заменяется на:
5. VMinstance –[keyRequest(dataID, h(VMinstanceKey), h(userKey))]→ keyServer
Это дополнительно ограничивает распределение ключей расшифрования авторизованным пользователя конкретной виртуальной машины и, по существу, повышает безопасность и доверие. В частности, зависимая от пользователя авторизация хорошо соответствует многим случая, когда данные ассоциируются с конкретными пользователями. Ключ расшифрования тогда распределяется только экземплярам VM, если такой авторизованный пользователь ассоциируется с экземпляром VM.
Данные могут ассоциироваться с конкретными пользователями различным образом. Может обеспечиваться прямая ассоциация между идентификатором пользователя и данными, так как пользователь является объектом данных, или так как пользователем является назначенный пользователь данных согласно политике, руководящей данными. Ассоциации данные-пользователь также могут быть косвенными посредством использования ролей и атрибутов. Таким образом, пользователь, имеющий конкретную роль, может быть авторизован на доступ к данным, обеспечиваемый сервером ключей. В случае ассоциаций данные-пользователь на основе роли и на основе атрибута, вместо единственного пользователя, группа пользователей может ассоциироваться с данными.
Пользователи могут ассоциироваться с экземпляром VM посредством аутентификации на экземпляре VM. Например, пользователь может выполнить логический вход на веб-сайт, хостируемый на экземпляре виртуальной машины. Такие сеансы аутентификации могут быть короткоживущими или долгоживущими. Когда пользователем выполнен логический выход, или когда завершается сеанс аутентификации другими средствами, такими как истечение срока, тогда экземпляр VM удаляет ключи, ассоциированные с этим пользователем, которые он получил от сервера ключей. Это практически завершает зависимую от пользователя авторизацию.
Зависимая от пользователя авторизация задействует включение учетных данных пользователя (изображенных как h(userKey) в примере выше), таких как подпись, основанная на ключе пользователя, маркер аутентификации или утверждение аутентификации. Такие учетные данные могут быть получены как часть процесса аутентификации пользователя.
В другой модификации зависимая от пользователя авторизация также включает в себя зависимый от пользователя ключ данных. В одном варианте осуществления экземпляр VM принимает на этапе 6 dataKey (ключ данных) в зашифрованном виде и расшифровывает этот зашифрованный dataKey с помощью зависимого от пользователя ключа, который приводит к ключу для расшифрования данных. В другом варианте осуществления это предоставляется серверу ключей. Отдельный сервер ключей может быть ответственным за управление зависимыми от пользователя ключами.
Другой пример предотвращает, например, прямую атаку на образ виртуальной машины, например, неавторизованное клонирование, кражу или неавторизованное создание экземпляра. Явная авторизация вводится как часть создания/запуска экземпляра виртуальной машины из образа. Последующие этапы 0-3 могут заменить этапы 1-3 в таблице 1 выше:
| Таблица 2 |
| Авторизация экземпляра диаграммы взаимодействия |
| 0. serviceProvider –[registerInstance(authorizationCode)]→ keyServer 1. serviceProvider –[createInstance(authorizationCode)]→ cloudManagementServer 2. cloudManagementServer –[createInstance(VMimage, authorizationCode)]→ cloudServer 3. VMinstance –[personalisationRequest(VMinstanceAttributes, VMimageKey, authorizationCode)]→ keyServer |
Этап 0 предварительно авторизует экземпляр, который должен быть запущен провайдером услуг, который регистрирует код авторизации на сервере ключей. Этапы 1 и 2 затем создают экземпляр. Все эти этапы включают в себя authorizationCode (код авторизации). Этот код авторизации создается провайдером услуг, например, посредством генерирования случайным образом кода авторизации. Код авторизации предоставляется образу виртуальной машины при создании, например, облачным сервером. На этапе 3 этот код авторизации включается в запрос персонализации, после которого сервер ключей верифицирует, что код авторизации, полученный от экземпляра виртуальной машины, идентичен коду авторизации, принятому непосредственно от провайдера услуг. Только если эти коды идентичны, сервер ключей выпускает учетные данные для авторизации экземпляра. Этот пример также может улучшить так называемый гипервизор, чтобы разрешать прохождение параметра authorizationCode с интерфейса управления на экземпляр виртуальной машины.
Более простая альтернатива не использует authorizationCode, но вместо этого принимает во внимание заранее заданное максимальное количество времени T между этапом 0 и этапом 3, измеряемое сервером ключей для предположения, что создание экземпляра является законным и авторизованным.
В варианте serviceProvider также может полностью предотвратить дальнейшие реализации образа виртуальной машины посредством явной сигнализации серверу ключей не персонализировать новые экземпляры посредством следующего взаимодействия:
| Таблица 3 |
| Образы блокировки диаграммы взаимодействия |
| а. serviceProvider –[lock(VMimage)]→ keyServer |
В улучшенном примере обеспечивается дополнительная защита от неавторизованного клонирования выполняющихся экземпляров виртуальной машины. Это улучшение включает в себя включение порядкового номера на этапе 5 таблицы 1:
| Таблица 4 |
| Порядковые номера диаграммы взаимодействия |
| 5. VMinstance –[keyRequest(dataID, sequenceNumber)]→ keyServer |
Данный этап 5 содержит включение указания порядкового номера экземпляром виртуальной машины в запросах ключа на сервер ключей. Экземпляр VM увеличивает или иным образом обновляет порядковый номер после каждого запроса таким образом, который является совместимым с соответствующим порядковым номером, реализованным в сервере ключей. Сервер ключей может верифицировать, что порядковые номера от экземпляра принимаются в строго возрастающем порядке. Это позволяет серверу ключей обнаруживать клонированный экземпляр, который не может предположить порядковые номера, используемые подлинником и, поэтому, будет обнаружен, если он предпримет попытку запросить ключи.
В другом улучшенном примере клонирование выполняющихся экземпляров виртуальной машины предотвращается явным блокированием экземпляров после их выполнения. Это включает в себя следующие дополнительные этапы:
| Таблица 5 |
| Экземпляры блокировки диаграммы взаимодействия |
| b. serviceProvider –[lock(VMinstance)]→cloudManagementServer c. cloudMangementServer –[lock(VMinstance)]→ cloudServer |
Этапы b и c могут вызываться в любой момент времени, например, непосредственно после этапов 1 и 2 таблицы 1. Инструкция блокировки посылает сигнал на облачный сервер (управления) не разрешать никаких будущих инструкций для выполнения снимка выполняющегося экземпляра, например, администратором облачного провайдера, провайдера услуг и возможным злонамеренным посторонним лицом.
Сервер ключей может быть выполнен с возможностью записи некоторых видов взаимодействий или даже всех взаимодействий, например, регистраций экземпляров, запросов персонализации и запросов ключа. Сервер ключей может предлагать доступ к этому журналу записей для провайдера услуг, что способствует прозрачности и трассируемости. Сервер ключей также может автоматически анализировать журналы записей в отношении паттернов и отклонений от нормального состояния, которые могут подсказывать атаки и попытки атак. Наконец, сервер ключей может предложить выполняемое с чьей-либо помощью или автоматизированное средство для контролирования провайдерами услуг того, как их приложения выполняются на облаке. В альтернативном примере сервер ключей ведет запись на удаленном сервере записи вместо ведения записи локально. В этом альтернативном варианте осуществления относящиеся к записи функциональные возможности могут предлагаться этим сервером записи. Функциональные возможности записи могут защитить целостность информации регистрации, чтобы гарантировать, что информация записи не была подделана.
В другой примерной модификации сервер ключей обеспечивается с дополнительной функциональной возможностью, чтобы сделать возможной трассируемость и контролирование доступа к объекту данных и использования с учетом расположения экземпляра виртуальной машины и данных. Это делает возможным, среди прочего, совместимость с некоторыми законодательствами о конфиденциальности (EU Privacy Directive), например, Директивой Европейского Союза о конфиденциальности, которая диктует, что данные хранятся и обрабатываются только в некоторых странах и/или юрисдикциях.
Например, сервер ключей отслеживает информацию о расположении объектов. Это может быть реализовано верификацией или запросом информации о расположении запрашивающего экземпляра виртуальной машины. Другим примером является то, что сервер ключей обрабатывает запросы ключа, так что он принимает на обработку только запросы ключа, которые происходят из некоторых расположений, т.е. экземпляров виртуальной машины, которые имеют известное и разрешенное расположение для рассматриваемых данных. То, где данные могут использоваться, может быть выражено в политиках. Расположением экземпляра VM, например, может быть географическое расположение сервера, на котором хостируется экземпляр VM.
Могут использоваться разные способы для получения сервером ключей информации о расположении виртуальной машины и/или данных:
- (Статическая) база данных с расположениями экземпляров виртуальной машины и серверов, которые хостируют экземпляры. Экземпляр и/или сервер может идентифицироваться, например, по его IP-адресу.
- Привязка (динамически) информации о расположении к экземпляру виртуальной машины (или объекту данных) посредством механизма, подобного сертифицированной маркировки во времени, которая может быть выпущена Доверенным органом определения расположения в облаке. Например, Доверенным органом определения расположения может быть контроллер управления в облачной инфраструктуре, который управляет информацией о расположении всех экземпляров виртуальной машины и/или данными в облаке.
- Сервер ключей регулярно (например, один раз в день) принимает несколько сертифицированных отметок расположения от объектов данных с деревом аутентификации, указывающим путь объекта в облаке. Например, дерево аутентификации может вычисляться с использованием хеш-дерева с корнем, и он является верифицируемым другой стороной.
Данный пример позволяет получить верифицируемую подлинность и разрешимость расположения объекта в облаке. Первые два способа могут быть объединены с этапом 3 (персонализация) или этапом 5 (запрос ключа) таблицы 1, чтобы информировать сервер ключей о расположении запрашивающего экземпляра виртуальной машины для получения эффективной и безопасной реализации.
В другом примере экземпляр VM не генерирует и не выдает запрос на учетные данные для авторизации экземпляра, основываясь на атрибутах. Вместо этого, на сервер ключей подается инструкция от другого субъекта на выдачу учетных данных для авторизации экземпляра:
| Таблица 6 |
| Конфигурирование авторизации, выполняемое пользователем-администратором |
| 3. administrator –[authorizationCredentialRequest(attributes) ]→ keyServer 4. keyServer –[authorizationCredentialResponse (authorizationCredential)]→ administrator 4a. administrator –[provisionAuthorizationCredential (authorizationCredential)]→ VMinstance |
Здесь этапы 3, 4 и 4a по таблице 6 могут заменить, например, этапы 3 и 4 по таблице 1. Сообщения, первоначально обозначенные как personalizationRequest/personalizationResponse (запрос персонализации/ответ на запрос персонализации), были переименованы здесь в authorizationCredentialRequest/authorizationCredentialResponse (запрос учетных данных для авторизации/ответ на запрос учетных данных для авторизации). Администратор может обратиться к серверу ключей через портал и запросить учетные данные для авторизации для нового экземпляра виртуальной машины. Как часть этого запроса, администратор может создать или ввести некоторые подробности, такие как уникальный идентификатор для нового экземпляра (обозначенного «атрибутами» в вышеупомянутой таблице 5 взаимодействия). После обработки запроса сервер ключей может создать уникальный код, который посылается администратору. Код служит цели учетных данных для авторизации. Администратор затем конфигурирует экземпляр виртуальной машины на этапе 4a учетными данными для авторизации, чтобы авторизовать экземпляр виртуальной машины.
Хороший пример учетных данных для авторизации экземпляра, используемых в вышеописанных схемах, содержит ключ экземпляра. Держатель ключа экземпляра, полученного от сервера ключей, использует ключ экземпляра для доказательства того, что экземпляр VM обладает ключом, и, таким образом, что экземпляр VM авторизован. Посылка ключа или других учетных данных в незашифрованном виде может вводить слабое место в системе обеспечения безопасности. Поэтому ключ экземпляра или другие учетные данные экземпляра могут защищаться цифровым образом при использовании. Например, эта защита может выполняться посредством ключевой хеш-функции. Согласно одному варианту, ключом экземпляра не является симметричный ключ, но секретный ключ с необязательным сертификатом. Экземпляр может использовать секретный ключ для доказательства, что он действительно является экземпляром, для сервера ключей посредством подписания запроса, такого как, например, запросы ключа данных. В другом варианте учетные данные для авторизации не представляют собой ключ, но программный маркер или утверждение, т.е. заявление, подписанное сервером ключей, который авторизует экземпляр и который может быть представлен серверу ключей позже. В другом варианте, учетные данные для авторизации реализуются набором ключей на основе атрибутов. В таком случае, экземпляр получает набор ключей, где каждый ключ связан с конкретным атрибутом, таким как роль. Экземпляр затем представляет поднабор ключей серверу ключей, например, в запросе ключа данных. Представленные ключи используются сервером ключей для эффективной обработки запросов, делая возможным большую степень детализации, чем единственный ключ на экземпляр.
Применение методик, описанных в данном документе, может быть в области облачных вычислений и, конкретно, в применениях, которые требуют более сильной защиты данных, таких как облачные применения в здравоохранении, которые включают в себя персональные данные о состоянии здоровья (PHI).
Может быть предложен способ защиты данных при облачных вычислениях, включающий в себя шифрование объектов данных, с этапом, когда экземпляр виртуальной машины посылает запрос ключа серверу ключей, и, если экземпляр виртуальной машины авторизован, тогда сервер ключей отвечает ключом расшифрования для зашифрованного объекта данных. Этот способ может быть расширен прежде всего на персонализацию и авторизацию экземпляра виртуальной машины этапом, когда экземпляр виртуальной машины посылает запрос персонализации серверу ключей, и сервер ключей отвечает персонализированным идентификатором и ключом авторизации. Способ может быть расширен на включение зависимой от пользователя авторизации этапом, когда запрос ключа включает в себя учетные данные пользователя, и сервер ключей оценивает авторизацию пользователя в отношении данных, для которых запрашивается ключ. Способ может быть расширен на предотвращение кражи и неавторизованного создания копий образа виртуальной машины этапом, когда пользователь облака предварительно авторизует новый экземпляр виртуальной машины посредством регистрации его на сервере ключей, и сервер ключей верифицирует присутствие авторизации перед обработкой дальнейших запросов от экземпляра виртуальной машины. Способ может быть расширен на предотвращение клонирования экземпляров виртуальной машины этапом, когда персонализированный экземпляр виртуальной машины включает в себя порядковый номер в запросе ключа, и сервер ключей верифицирует, что порядковые номера являются строго монотонно увеличивающимися перед ответом на запрос ключа. Способ может быть расширен на предотвращение клонирования и выполнения снимков в состоянии покоя этапом, когда пользователь облака посылает запрос блокирования облачному серверу на запрещение постоянного хранения или копирования экземпляра виртуальной машины. Способ может быть расширен на отслеживание и контролирование операций экземпляров виртуальной машины этапом, когда сервер ключей записывает операции виртуальной машины, такие как регистрации экземпляра, запросы персонализации и запросы ключа. Способ может быть расширен на предотвращение перемещения объектов данных, использование или выполнение доступа вне разрешенной зоны расположения этапом, когда сервер ключей получает информацию о расположении экземпляра виртуальной машины и использует эту информацию при оценке для возврата запрашиваемого ключа.
Как часть определения/оценки системой 6 сервера ключей того, должен ли запрос ключа данных быть принят на обработку, оценка опасности может выполняться для определения законности запроса (например, если экземпляр не запрашивает бессмысленное количество ключей данных кроме его регулярного паттерна, который может указывать на тот факт, что он был скомпрометирован). Он использует свою запись для этого.
Понятно, что изобретение также применимо к компьютерным программам, в частности компьютерным программам на носителе или в нем, предназначенным для осуществления изобретения на практике. Программа может быть в виде исходного кода, объектного кода, промежуточного источника кода и объектного кода, такого как частично скомпилированный вид, или в любой другом виде, подходящем для использования при реализации способа согласно изобретению. Также понятно, что такая программа может иметь многочисленные разные архитектурные разработки. Например, программный код, реализующий функциональные возможности способа или системы согласно изобретению, может быть подразделен на одну или несколько подпрограмм. Многочисленные разные пути распределения функциональных возможностей между этими подпрограммами очевидны для специалиста в данной области техники. Подпрограммы могут храниться вместе в одном исполняемом файле, образуя независимую программу. Такой исполняемый файл может содержать исполняемые компьютером инструкции, например, инструкции процессора и/или инструкции интерпретатора (например, инструкции интерпретатора Java). Альтернативно, одна или несколько или все из подпрограмм могут храниться в по меньшей мере одном файле внешней библиотеки и связываться с основной программой или статически, или динамически, например, на этапе выполнения. Основная программа содержит по меньшей мере один вызов на по меньшей мере одну из подпрограмм. Подпрограммы также могут содержать вызовы друг друга. Вариант осуществления, относящийся к компьютерному программному продукту, содержит исполняемые компьютером инструкции, соответствующие каждому этапу обработки по меньшей мере одного из способов, изложенных в данном документе. Эти инструкции могут подразделяться на подпрограммы и/или храниться в одном или нескольких файлах, которые могут связываться статически или динамически. Другой вариант осуществления, относящийся к продукту компьютерной программы, содержит исполняемые компьютером инструкции, соответствующие каждому средству по меньшей мере одной из систем и/или продуктов, изложенных в данном документе. Эти инструкции могут подразделяться на подпрограммы и/или храниться в одном или нескольких файлах, которые могут связываться статически или динамически.
Носитель компьютерной программы может представлять собой любой субъект или устройство, способное переносить программу. Например, носитель может включать в себя запоминающую среду, такую как, например, постоянное запоминающее устройство (ROM), компакт диск (CD-ROM) или полупроводниковое ROM, или магнитную записывающую среду, например, флеш-накопитель или жесткий диск. Кроме того, носитель может быть передаваемым носителем, таким как электрический или оптический сигнал, который может передаваться по электрическому или оптическому кабелю или посредством радиосредства или других средств. Когда программа воплощена в такой сигнал, носитель может состоять из такого кабеля или другого устройства или средства. Альтернативно, носителем может быть интегральная схема, в которую внедрена программа, причем интегральная схема выполнена с возможностью выполнения относящегося способа или использования при выполнении его.
Необходимо отметить, что вышеупомянутые варианты осуществления иллюстрируют, а не ограничивают изобретение, и специалист в данной области техники может разработать многочисленные альтернативные варианты осуществления без отступления от объема прилагаемой формулы изобретения. В формуле изобретения любые ссылочные позиции, размещенные между круглыми скобками, не должны толковаться как ограничивающие формулу изобретения. Использование глагола «содержать» и его спряжений не исключает присутствие элементов или этапов кроме тех, которые изложены в формуле изобретения. Упоминание элемента в единственном числе не исключает присутствие множества таких элементов. Изобретение может быть реализовано посредством аппаратных средств, содержащих несколько отдельных элементов, и посредством запрограммированного соответствующим образом компьютера. В формуле изобретения на устройство, перечисляющей несколько средств, несколько из этих средств могут воплощаться одним и тем же элементом аппаратных средств. Простой факт, что некоторые меры излагаются в взаимно разных зависимых пунктах формулы изобретения, не указывает на то, что объединение этих мер не может использоваться для получения преимущества.
1. Система для исполнения экземпляра виртуальной машины, содержащая:
компьютер, запрограммированный для приведения в действие среды исполнения для создания экземпляра виртуальной машины, функционирующего на компьютере, причем экземпляр виртуальной машины содержит:
блок авторизации экземпляра для приема учетных данных для авторизации экземпляра, созданных вне экземпляра виртуальной машины, причем учетные данные для авторизации экземпляра однозначно связаны с экземпляром виртуальной машины;
блок ключа данных, чтобы генерировать запрос ключа данных, основываясь на учетных данных для авторизации экземпляра, связанных с экземпляром виртуальной машины, и принимать ключ данных; и
блок расшифрования для расшифрования элемента данных, основываясь на ключе данных.
2. Система по п.1, в которой экземпляр виртуальной машины дополнительно содержит блок учетных данных пользователя для получения учетных данных пользователя, связанных с пользователем или группой пользователей, и в которой блок ключа данных выполнен с возможностью генерирования упомянутого запроса, дополнительно основываясь на учетных данных пользователя, или блок расшифрования выполнен с возможностью расшифрования элемента данных, дополнительно основываясь на учетных данных пользователя.
3. Система по п.1, в которой блок авторизации экземпляра выполнен с возможностью выдачи запроса учетных данных для авторизации экземпляра, причем данный запрос указывает по меньшей мере один атрибут, который является характерным для экземпляра виртуальной машины.
4. Система по п.3, дополнительно содержащая блок владельца экземпляра для регистрации кода авторизации, связанного с экземпляром виртуальной машины, на сервере ключей и для предоставления кода авторизации экземпляру виртуальной машины; причем упомянутый по меньшей мере один атрибут указывает код авторизации.
5. Система по п.4, в которой блок владельца экземпляра выполнен с возможностью посылать инструкцию, содержащую код авторизации, среде исполнения виртуальных машин, при этом среда исполнения выполнена с возможностью создавать экземпляр виртуальной машины и предоставлять код авторизации экземпляру виртуальной машины в ответ на прием данной инструкции.
6. Система по п.1, в которой блок ключа данных выполнен с возможностью включать в запрос ключа данных код, который указывает на положение упомянутого запроса в последовательности запросов, выдаваемых экземпляром виртуальной машины.
7. Система по п.1, в которой экземпляр виртуальной машины выполнен с возможностью хранить ключ данных и/или данные, расшифрованные с использованием ключа данных, в энергозависимой памяти и/или стирать ключ данных и данные, расшифрованные с использованием ключа данных, после использования.
8. Система сервера ключей для выпуска ключей для экземпляра виртуальной машины, содержащая
блок идентификации экземпляра для идентификации экземпляра виртуальной машины, основываясь на по меньшей мере одном атрибуте, который является характерным для экземпляра виртуальной машины;
средство определения авторизации экземпляра, чтобы определять учетные данные для авторизации экземпляра и однозначно связывать учетные данные для авторизации экземпляра с экземпляром виртуальной машины;
блок предоставления авторизации экземпляра для предоставления учетных данных для авторизации экземпляра экземпляру виртуальной машины;
средство приема запроса ключа данных для приема запроса ключа данных от экземпляра виртуальной машины, причем запрос ключа данных содержит компонент авторизации экземпляра, связанный с учетными данными для авторизации экземпляра;
блок авторизации данных для определения того, авторизован ли экземпляр виртуальной машины принимать ключ данных, основываясь на компоненте авторизации экземпляра; и
блок предоставления ключа данных для предоставления ключа данных экземпляру виртуальной машины, если экземпляр виртуальной машины авторизован принимать ключ данных.
9. Система сервера ключей по п.8, дополнительно содержащая
средство приема запроса учетных данных экземпляра для приема запроса учетных данных для авторизации экземпляра от экземпляра виртуальной машины, причем этот запрос указывает атрибут, который является характерным для экземпляра виртуальной машины; и
блок проверки достоверности экземпляра для верификации достоверности экземпляра виртуальной машины, основываясь на данном атрибуте.
10. Система сервера ключей по п.8, в которой блок авторизации данных выполнен с возможностью осуществления упомянутого определения того, авторизован ли экземпляр виртуальной машины принимать ключ данных, дополнительно основываясь на расположении экземпляра виртуальной машины; или блок проверки достоверности экземпляра выполнен с возможностью осуществления упомянутой верификации достоверности экземпляра виртуальной машины, дополнительно основываясь на атрибуте, указывающем на расположение экземпляра виртуальной машины.
11. Система сервера ключей по п.8, в которой
запрос ключа данных дополнительно указывает учетные данные пользователя, которые связаны с пользователем или группой пользователей экземпляра виртуальной машины, и
блок авторизации данных выполнен с возможностью осуществления упомянутого определения того, авторизован ли экземпляр виртуальной машины на прием ключа данных, дополнительно основываясь на указании учетных данных пользователя, принятом с запросом ключа данных, и политике доступа к данным, защищенным ключом данных.
12. Машиночитаемый носитель, на котором сохранен образ виртуальной машины, приспособленный для реализации в виде экземпляра виртуальной машины, причем образ виртуальной машины содержит:
код инструкции, предписывающий экземпляру виртуальной машины принимать учетные данные для авторизации экземпляра, созданные вне экземпляра виртуальной машины, причем учетные данные для авторизации экземпляра однозначно связаны с экземпляром виртуальной машины;
код инструкции, предписывающий экземпляру виртуальной машины генерировать запрос ключа данных, основываясь на учетных данных для авторизации экземпляра, связанных с экземпляром виртуальной машины, и принимать ключ данных; и
код инструкции, предписывающий экземпляру виртуальной машины расшифровывать элемент данных, основываясь на ключе данных.
13. Способ исполнения экземпляра виртуальной машины, содержащий этапы, на которых посредством экземпляра виртуальной машины:
принимают учетные данные для авторизации экземпляра, созданные вне экземпляра виртуальной машины, причем учетные данные для авторизации экземпляра однозначно связаны с экземпляром виртуальной машины;
генерируют запрос ключа данных, основываясь на учетных данных для авторизации экземпляра, связанных с экземпляром виртуальной машины, и принимают ключ данных; и
расшифровывают элемент данных, основываясь на ключе данных.
14. Способ выпуска ключей для экземпляра виртуальной машины, содержащий этапы, на которых:
идентифицируют экземпляр виртуальной машины, основываясь на по меньшей мере одном атрибуте, который является характерным для экземпляра виртуальной машины;
определяют учетные данные для авторизации экземпляра и однозначно связывают учетные данные для авторизации экземпляра с экземпляром виртуальной машины;
предоставляют учетные данные для авторизации экземпляра экземпляру виртуальной машины;
принимают запрос ключа данных от экземпляра виртуальной машины, причем запрос ключа данных содержит компонент авторизации экземпляра, связанный с учетными данными для авторизации экземпляра;
определяют, является ли экземпляр виртуальной машины авторизованным принимать ключ данных, основываясь на компоненте авторизации экземпляра; и
предоставляют ключ данных экземпляру виртуальной машины, если экземпляр виртуальной машины авторизован принимать ключ данных.
15. Машиночитаемый носитель, на котором сохранены инструкции, предписывающие процессорной системе выполнять способ по п.13.
