ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Изобретение относится к обеспечению доверенных облачных сервисов вычисления и данных для устройства (или устройств) и, в частности, к обеспечению сервисов криптографически защищенного и конфиденциального хранения, обработки или анализа для данных резервной копии, например данных синтетической полной резервной копии.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
Согласно уровню техники, относящегося к некоторым традиционным системам, вычислительные устройства традиционно исполняли приложения и сервисы данных локально по отношению к устройству. В таком случае, при осуществлении доступа к данным, их обработке, сохранении, кэшировании и т.д., данные могут переноситься на устройство по локальным шинам, интерфейсам и другим каналам данных, однако пользователю устройства не нужно беспокоиться о вмешательстве или раскрытии пользовательских данных, если само устройство не потеряно или не украдено.
Кроме того, с развитием онлайновых и облачных сервисов приложения и сервисы все больше переходят к сетевым провайдерам, которые полностью или частично осуществляют данный сервис от имени устройств. В таком случае, пользователя(ей) устройства (или устройств) может интересовать, кто может осуществлять доступ к, или, что хуже, перехватывать, данные пользователя при их выгрузке в сервис, при их хранении или обработке сервисом или при их возвращении с сервиса. Короче говоря, когда данные устройства пользователя покидают домен физического владения и поступают в сетевую среду, удаленную от пользователя, естественно, возникает вопрос небрежного или злонамеренного обращения третьих лиц с данными или их вмешательства в данные. Соответственно, желательно увеличить доверие, безопасность и конфиденциальность для облачных сервисов и манипуляции данными в связи с облачными сервисами, или даже на предприятии, где данные покидают одну область управления и поступают в другую.
Например, в настоящее время пользователи могут подключать внешний привод к первичному устройству, например локальному персональному компьютеру (ПК) или другому устройству, и создавать синтетическую полную резервную копию данных первичного устройства. Как следует из самого названия, синтетическая полная резервная копия - это синтезированная резервная копия, созданная на основании данных самой последней полной резервной копии, например, стандартной или синтетической, и любых подразумеваемых последующих инкрементных или дифференциальных резервных копий.
Традиционно, это физическое владение реконструируемой копией данных на внешнем приводе защищает от потери важных данных, хранящихся на первичном устройстве. Например, подключив внешний привод или диск, например устройство флэш-памяти или другой внешний жесткий диск, через кабель USB и т.п., пользователь устройства может быть уверен в том, что данные можно реконструировать в случае потери первичного устройства. Таким образом, если первичное устройство оказывается в каком-либо катастрофическом состоянии, которое препятствует доступу к его данным или приводит к безвозвратному нарушению или уничтожению данных, данные можно восстановить с внешнего привода или диска, находящегося в собственности пользователя. Однако, конечно, если первичное устройство и внешний привод оба повреждены в одной и той же катастрофе (например, землетрясении), проблема возвращается.
Развитие ферм сетевого хранения, где могут храниться терабайты данных (с возможностью увеличения в будущем до петабайтов, экзабайтов и т.д. данных) открыло возможность имитировать локальный сценарий в облаке с разделением первичного устройства и внешнего хранения. Облачное хранение данных резервной копии также позволяет большому количеству устройств хранить свои данные резервной копии без необходимости в отдельном хранилище для каждого устройства. В этой связи вместо того, чтобы сохранять данные резервной копии путем подключения вторичного устройства хранения к первичному устройству кабелем, благодаря облачному хранению, данные резервной копии передаются на и сохраняются провайдером облачных сервисов, который управляет хранением данных резервной копии от имени устройства.
Однако, как указано выше, сохраняется проблема, связанная с тем, что ни облачный сервис, ни провайдер сетевого хранения не способны эффективно решать проблемы и удовлетворять потребности в безопасности, конфиденциальности и целостности данных резервной копии, хранящихся в облаке. Короче говоря, пользователи требуют увеличения доверия в том, что их данные остаются защищенными и конфиденциальными при передаче физического управления хранилищем, и это препятствие является существенной причиной, по которой предприятия и потребители отказываются осуществлять резервное копирование важных данных через сетевые сервисы и решения третьих лиц.
Вышеописанные недостатки современных устройств и сервисов резервного копирования данных призваны всего лишь предоставить обзор некоторых проблем традиционных систем, и не призваны быть исчерпывающими. Другие проблемы, присущие уровню техники, и соответствующие преимущества некоторых из различных неограничительных вариантов осуществления можно будет лучше понять, обратившись к нижеследующему подробному описанию.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Данное краткое изложение сущности изобретения призвано помочь составить базовое или общее представление о различных аспектах иллюстративных, неограничительных вариантов осуществления, представленных ниже в более подробном описании и прилагаемых чертежах. Однако это изложение сущности изобретения не призвано служить обширным или исчерпывающим обзором. Напротив, единственной целью этого изложения сущности изобретения является представление в упрощенном виде некоторых концепций, связанных с некоторыми иллюстративными неограничительными вариантами осуществления, предваряющее нижеследующее более подробное описание различных вариантов осуществления.
Сетевые сервисы данных, включающие в себя методики поискового шифрования для данных резервной копии в облаке, которые можно хранить, обрабатывать, восстанавливать или к которым можно осуществлять доступ, обеспечены с возможностью распределения доверия между множественными сущностями во избежание единичной точки компрометации данных. В одном варианте осуществления, генератор ключей, провайдер криптографической технологии и провайдер облачных сервисов обеспечены как отдельные сущности, что позволяет издателям данных резервной копии конфиденциально (в шифрованном виде) публиковать данные провайдеру облачных сервисов, и позволяет авторизованным абонентам избирательно осуществлять доступ к шифрованным данным резервной копии на основании информации идентификации абонента, закодированной в запросах доступа.
В одном варианте осуществления, операционное синтетическое полное резервное копирование поддерживается с помощью шифрованных данных в качестве сервиса данных в режиме криптографической защиты в соответствии с требованиями целостности и конфиденциальности, предъявляемыми к внешнему или удаленному хранению потенциально важных данных. В одном варианте осуществления, поддерживаемые методики хранения включают в себя резервное копирование, защиту данных, восстановление в аварийных ситуациях и аналитику на вторых копиях данных первичного устройства. Некоторые примеры экономичных криптографических методик, которые можно применять для облегчения установления высокого уровня доверия к безопасности и конфиденциальности данных резервной копии, включают в себя, но без ограничения, шифрование с сохранением размера, поисковое шифрование или доказательство применения, слепые идентификационные признаки, доказательство восстановимости и т.д.
Другие варианты осуществления и различные неограничительные примеры, сценарии и реализации более подробно описаны ниже.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Ниже приведено более подробное описание различных неограничительных вариантов осуществления со ссылкой на прилагаемые чертежи, в которых:
фиг.1 - блок-схема общей среды для обеспечения одного или нескольких вариантов осуществления сервисов резервного копирования;
фиг.2 - блок-схема общей среды для обеспечения одного или нескольких вариантов осуществления сервисов резервного копирования, включающих в себя доказательство применения;
фиг.3 - блок-схема общей среды для обеспечения одного или нескольких вариантов осуществления сервисов резервного копирования, включающих в себя слепое определение идентификационных признаков;
фиг.4 - логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для поддержания данных синтетической полной резервной копии для заданного набора данных на основании шифрованных данных и метаданных и данных секрета;
фиг.5 - логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для поддержания данных синтетической полной резервной копии согласно варианту осуществления;
фиг.6 - логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для восстановления элементов данных согласно варианту осуществления для поддержания данных синтетической полной резервной копии;
фиг.7 - логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для обеспечения сервисов резервного копирования, включающих в себя доказательство применения;
фиг.8 - логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для сервисов резервного копирования, включающих в себя слепые идентификационные признаки;
фиг.9 - логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для сервисов резервного копирования, включающих в себя перезапуск приложения в режиме готовности в зависимости от локальных данных;
фиг.10 - иллюстративная неограничительная блок-схема инфраструктуры или экосистемы доверенных облачных сервисов согласно варианту осуществления;
фиг.11 - логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для публикации данных согласно экосистеме доверенных облачных сервисов;
фиг.12 - логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для оформления подписки на данные согласно экосистеме доверенных облачных сервисов;
фиг.13 - схема иллюстративной экосистемы, демонстрирующая разделение центра для генерации ключей, провайдера криптографической технологии и провайдера облачных сервисов в доверенной экосистеме;
фиг.14 - другая архитектурная схема, демонстрирующая дополнительные преимущества доверенной экосистемы для осуществления облачных сервисов для предприятий;
фиг.15 - другая блок-схема, демонстрирующая согласование разных провайдеров хранения через уровень абстрагирования хранения согласно экосистеме доверенных облачных сервисов;
фиг.16 - блок-схема, демонстрирующая дополнительные аспекты хранения в связи с сервисом абстрагирования хранения, который абстрагирует детали хранения различных провайдеров хранения;
фиг.17 - другая блок-схема, демонстрирующая различных участников экосистемы доверенных облачных сервисов;
фиг.18 - схема, представляющая некоторые уровни иллюстративной, неограничительной реализации доверенной системы облачных вычислений, разные части которой могут обеспечиваться разными субъектами или одним и тем же субъектом;
фиг.19-20 - логические и структурные блок-схемы, соответственно, демонстрирующие иллюстративный/ую неограничительный/ую процесс и/или систему для публикации документов приложению цифрового сейфа с предоставлением издателю возможности управления избирательным доступом к данным посредством динамического связывания;
фиг.21-22 - логические и структурные блок-схемы, соответственно, иллюстративного/ой, неограничительного/ой процесса и/или системы для оформления подписки на данные согласно сценарию цифрового сейфа;
фиг.23 - схема иллюстративной неограничительной реализации экосистемы доверенных облачных сервисов с использованием шаблона цифрового эскроу для реализации защищенной экстрасети предприятия посредством одного или нескольких центров обработки данных;
фиг.24 - логическая блок-схема, демонстрирующая другой иллюстративный неограничительный сценарий на основе экосистемы доверенных облачных сервисов, в котором абоненту предоставляется избирательный доступ к шифрованным данным, сохраненным провайдером облачных сервисов;
фиг.25 - другая логическая блок-схема, демонстрирующая, что ответ приложения можно подстраивать под абонента на основании мандата пользователя;
фиг.26 - другая логическая блок-схема, демонстрирующая сценарий защищенной выгрузки записи, который можно реализовать для одной стороны или нескольких сторон;
фиг.27 - еще одна логическая блок-схема, демонстрирующая иллюстративную неограничительную реализацию ролевого опроса хранилища поисково-шифрованных данных, обеспеченного экосистемой доверенных облачных сервисов, например, для автоматического поиска, осуществляемого одной стороной;
фиг.28 - блок-схема реализации экосистемы доверенных облачных сервисов между предприятием, центром для генерации ключей и провайдером облачных сервисов согласно одному или нескольким сценариям;
фиг.29 - логическая блок-схема, демонстрирующая сценарий кооперации нескольких сторон, где предприятие предоставляет внешнему предприятию доступ к некоторым своим шифрованным данным;
фиг.30 - логическая блок-схема, демонстрирующая сценарий автоматического поиска, осуществляемого несколькими сторонами среди множественных предприятий;
фиг.31 - блок-схема реализации экосистемы доверенных облачных сервисов между множественными предприятиями, центром для генерации ключей и провайдером облачных сервисов согласно одному или нескольким сценариям;
фиг.32 - схема, демонстрирующая иллюстративную неограничительную технологию краевой вычислительной сети (ECN), которую можно реализовать для доверенного облачного сервиса;
фиг.33 - блок-схема, демонстрирующая один или несколько дополнительных аспектов центра для генерации ключей согласно экосистеме доверенных облачных сервисов;
фиг.34-35 - схемы, демонстрирующие включение валидизации, например, доказательства владения данными, в обеспечение доверенных сервисов данных согласно варианту осуществления;
фиг.36 - блок-схема, демонстрирующая иллюстративную валидизацию данных сервиса данных согласно экосистеме доверенных сервисов;
фиг.37-38 - схемы, демонстрирующие включение верификации, например доказательства восстановимости, в обеспечение доверенных сервисов данных согласно варианту осуществления;
фиг.39 - блок-схема, демонстрирующая иллюстративную валидизацию данных сервиса данных согласно экосистеме доверенных сервисов;
фиг.40 - блок-схема, демонстрирующая обеспечение нескольких разных оверлеев или вертикалей цифрового эскроу для издателей и абонентов для использования на основании набора различных условий, применимых к использованию сервиса, независимо от обеспечения самого сервиса;
фиг.41 - блок-схема, представляющая иллюстративные неограничительные сетевые среды, в которых можно реализовать различные описанные здесь варианты осуществления; и
фиг.42 - блок-схема, представляющая иллюстративную неограничительную вычислительную систему или операционную среду, в которой можно реализовать один или несколько аспектов описанных здесь различных вариантов осуществления.
ПОДРОБНОЕ ОПИСАНИЕ
Обзор
Согласно рассмотрению, приведенному в разделе «Предшествующий уровень техники», данные резервной копии, отправляемые на сетевой сервис, могут создавать дискомфорт в отношении конфиденциальности, возможности вмешательства и т.д., например, при передаче данных с устройства пользователя на сетевое приложение, сервис или хранилище данных, пользователь нуждается в достаточной гарантии того, что никакое злонамеренное третье лицо не сможет ему навредить. По определению, пользователь теряет управление данными. Таким образом, желательно повысить доверие, чтобы издатели и/или владельцы данных резервной копии желали передать физическое управление своими данными резервной копии, веря, что их данные останутся конфиденциальными и нетронутыми, находясь в сети, за исключением случаев, когда издатели и/или владельцы осуществляют доступ к ним, или доверяя тому, кому предоставлены привилегии после верификации на основании идентификации запрашивающего.
Как описано ниже в ряде неограничительных вариантов осуществления, методики для поддержания операционного внешнего синтетического полного резервного копирования посредством шифрованных данных обеспечены в порядке обеспечения сетевых сервисов резервного копирования данных. Большинство серверов и сервисов продукции предприятия обеспечивает возможность реализации традиционного синтетического полного резервного копирования, и многие серверы, например Microsoft Exchange, реализуют эту возможность на сайтах заказчика в виде кластерной непрерывной репликации (CCR) и резервной непрерывной репликации (SCR). Однако с помощью CCR и SCR, как упомянуто в разделе "Предшествующий уровень техники", управление данными не передается третьим лицам как в случае, когда провайдер облачных сервисов или провайдер других сервисов данных осуществляет хранение.
Обеспечение описанных здесь сервисов резервного копирования данных предусматривает различные комбинации и перестановки методик хранения и криптографии, которые обеспечивают экономичные, а также защищенные и конфиденциальные решения. Например, различные дополнительные варианты осуществления, более подробно описанные ниже, реализуют метод защиты данных, именуемый 'синтетическим полным резервным копированием' посредством криптографических методов, которые включают в себя шифрование с сохранением размера, поисковое шифрование и криптографический метод, именуемый «доказательством применения». Такие варианты осуществления допускают новые бизнес-сценарии для сторонней облачной защиты данных, восстановления в аварийных ситуациях или аналитики, которые в настоящее время не удается реализовать без нарушения требований заказчиков к конфиденциальности или безопасности.
В этой связи, для устранения барьеров доверия, которые окружают традиционное обеспечение сетевых сервисов, предусмотрена экосистема или инфраструктура доверенных облачных сервисов вычисления и данных, которая позволяет добиться вышеуказанных целей, а также других преимуществ, обозначенных в различных описанных ниже вариантах осуществления. Термин “облачные” сервисы, в общем случае, означает, что сервис осуществляется не локально на устройстве пользователя, но доставляется с одного или нескольких удаленных устройств, доступных через одну или несколько сетей. Поскольку от устройства пользователя не требуется понимать детали того, что происходит на одном или нескольким удаленных устройствах, с точки зрения устройства пользователя сервис выглядит как доставляемый из “облака”.
В одном варианте осуществления, система содержит генератор ключей, который генерирует информацию ключей для публикации данных или оформления подписки на них. Провайдер криптографической технологии, реализованный независимо от генератора ключей, реализует поисковый(е) алгоритм(ы) шифрования/дешифрования на основании информации ключей, генерируемых генератором ключей. Кроме того, провайдер сетевых сервисов, реализованный независимо от генератора ключей и провайдера криптографической технологии, обеспечивает сетевой сервис в отношении данных, зашифрованных провайдером криптографической технологии.
В одном варианте осуществления, предусмотрено хранилище данных, которое открывает избирательно доступные, например, для поиска шифрованные данные, в котором, по меньшей мере, один издатель публикует данные, представляющие ресурс(ы) хранилищу данных. Обеспечивая разделение возможности злоупотребления доверием, первый независимый субъект осуществляет генерацию информации криптографических ключей. Второй независимый субъект, в свою очередь, осуществляет шифрование опубликованных данных до сохранения на основании информации криптографических ключей, генерируемой первым независимым субъектом. Затем совокупностью сетевых или облачных сервисов осуществляют избирательный доступ к шифрованным данным для данного запроса к сетевому сервису на основании динамически связанных выбранных привилегий, предоставленных издателем(ями) или владельцем(ами) ресурса(ов).
В других вариантах осуществления, в хранилище данных хранятся избирательно доступные шифрованные данные, причем абонент(ы) подписывае(ю)тся на указанное подмножество шифрованных данных. Первый независимый субъект генерирует информацию криптографических ключей на основании информации идентификации, связанной с абонентом(ами), и второй независимый субъект осуществляет дешифрование указанного подмножества на основании информации криптографических ключей, сгенерированной первым независимым субъектом. Сетевой(ые) сервис(ы) отвечает(ют) на запросы абонента(ов) и предоставляют избирательный доступ к шифрованным данным на основании динамически связанных выбранных привилегий, предоставленных издателями или владельцами указанного подмножества.
В этой связи, термины «издатель» и «абонент», в общем случае, означают того, кто публикует или подписывается на данные доверенного облачного сервиса, соответственно. Однако на практике, в зависимости от отрасли промышленности или применения экосистемы доверенных облачных сервисов и шаблона цифрового эскроу, издатели и абоненты будут играть более конкретные роли. Например, в контексте данных резервной копии всей системы, обычно лишь малая группа абонентов будет иметь привилегии доступа к данным резервной копии. Например, в контексте данных резервной копии, аудитор хранилища шифрованных данных резервной копии может иметь определенные возможности на основании роли аудитора данных резервной копии, чтобы удостоверяться в выполнении определенных требований, например частоты резервного копирования, без предоставления доступа к самому контенту.
Дополнительные детали этих и других иллюстративных, неограничительных вариантов осуществления и сценариев приведены ниже.
ЗАЩИЩЕННОЕ И КОНФИДЕНЦИАЛЬНОЕ ХРАНЕНИЕ И ОБРАБОТКА
РЕЗЕРВНЫХ КОПИЙ
Как упомянуто, ряд методов защиты данных применяются в связи с резервным копированием данных совместно с инструментами, позволяющими третьим лицам обеспечивать сервисы, одновременно поддерживая безопасность и доверие. В нижеследующем описании, прежде всего, приведен краткий обзор методов синтетического полного резервного копирования. Многие серверы предприятия, например сервер Exchange от Microsoft, обеспечивают возможность извлекать полные, инкрементные и дифференциальные резервные копии. Дифференциальная резервная копия (иногда для краткости именуемая дифференциалом) содержит изменения, внесенные после последнего полного резервного копирования, и инкрементная резервная копия (иногда для краткости именуемая инкрементом) содержит изменения, внесенные после самого последнего полного или инкрементного резервного копирования.
Например, для сервера Exchange полная резервная копия представляет собой копию базы данных Exchange (EDB), и инкремент и дифференциал представляет собой журнальную запись. В порядке другого примера, в системах резервного копирования на ленточных накопителях эти полные и дифференциальные или инкрементные резервные копии хранятся на ленте и восстанавливаются при необходимости, в какое время с ленты восстанавливается самая последняя полная резервная копия. После этого, при наличии дифференциала, именно он восстанавливается с ленты и применяется к недавно восстановленной полной резервной копии. При наличии инкрементов именно они восстанавливаются с ленты и последовательно применяются к полной резервной копии для своевременного обновления данных.
В некоторых более современных системах резервного копирования на дисковых накопителях, периодически создаваемые полные резервные копии (иногда для краткости именуемые «полными») и последующие инкременты переносятся с первичного сервера (действующего сервера) на сервер, где резервные копии хранятся на дисковых накопителях, а не на ленте. Поскольку инкременты поступают в виде записей, они применяются к полной резервной копии, которая поддерживается на сервере резервного копирования (или “вторичном сервере”), для своевременного обновления данных. Этот механизм поддержания удаленной обновленной копии именуется 'синтетическим полным резервным копированием'. В самых современных системах непрерывной защиты данных (CDP), синтетическое полное резервное копирование поддерживается за счет организации потока модификаций на первичном сервере на сервер резервного копирования и применения этих модификаций на этом сервере для обеспечения непрерывного обновления копии, хранящейся на сервере резервного копирования.
Двумя показателями эффективности синтетического полного резервного копирования являются «параметр точки восстановления» [Recovery Point Objective] (RPO) и «параметр времени восстановления [Recovery Time Objective] (RTO). RPO - это верхняя граница объема данных, который может быть утрачен вследствие потери первичного сервера по какой-либо причине. RTO - это верхняя граница времени между отключением первичного сервера от сети по какой-либо причине и подключением к сети вторичного сервера с полной функциональностью. Синтетическое полное резервное копирование обеспечивает значительно лучший RTO, чем предыдущие механизмы на ленточных накопителях, поскольку инкрементные записи уже применены к резервной копии (“воспроизведены”). В типичном сценарии предприятия может существовать несколько тысяч записей, сгенерированных после последнего полного резервного копирования, на применение (“повторное воспроизведение”) которых может уйти несколько часов (или даже дней), прежде чем вторичная копия будет доведена до обновленного состояния. Поэтому синтетическое полное резервное копирование позволяет значительно улучшить RTO. RPO также улучшается, поскольку возможную потерю данных трудно точно оценить, пока не гарантировано отсутствие пропущенных или поврежденных записей. Используя постобработку на вторичном сайте, это можно сделать, повторно воспроизводя записи в порядке поддержания синтетического полного резервного копирования.
Обычно синтетическое полное резервное копирование поддерживается на вторичном сайте, что позволяет переносить копию обратно на первичный сайт после восстановления сайта после любого отказа, приведшего к потере первичной копии. Синтетическое полное резервное копирование также можно поддерживать для обеспечения сервиса практически мгновенного восстановления, размещая эту копию в порядке сервиса восстановления из вторичного центра в случае отказа первичного центра. Синтетическое полное резервное копирование также обеспечивает восстановление с высоким уровнем дискретизации объектов в этой базе данных. Например, для Exchange это предусматривает извлечение сообщений, заданий или календарных элементов из EDB. Это может происходить вследствие случайных или злонамеренных удалений на первичном сайте или по причине необходимости в организации потока элементов обратно на первичный центр для восстановления “в режиме готовности”, когда первичный сервер возвращается в рабочее состояние и восстанавливается после отказа, приведшего к потере данных. В этой связи, сервис делается доступным пользователям, и они могут отправлять и получать электронную почту, пока их данные возвращаются в потоковом режиме из вторичной копии.
Помимо возможностей защиты данных и восстановления в аварийных ситуациях, синтетическое полное резервное копирование также можно использовать для решения широкого круга аналитических задач, от промышленной разведки до обнаружения вторжения. Ряд сервисов также могут выполняться в отношении вторичной копии для постобработки данных для ряда приложений, которые включают в себя, но без ограничения, eDiscovery, Compliance, Governance, Security и BI. Однако, по причинам защиты данных и восстановления в аварийных ситуациях, обычно требуется содержать вторичный сервер в удаленном месте, чтобы вторичный сервер мог пережить отказы независимо от первичного сервера. Кроме того, заботы об эксплуатации можно переложить на внешнюю организацию. Провайдер облачных сервисов, например, может обеспечивать облачный сервис резервного копирования, который выполняет все эти приложения, избавляя предприятие от необходимости нести расходы и заботиться о поддержании множественных копий своих данных предприятия, и необходимости тратить ресурсы развития на реализацию.
Как упомянуто в разделе "Предшествующий уровень техники", поддержание важных данных предприятия на удаленном сайте, находящемся во владении сервисной организации, может подвергать эти данные различным рискам, от нарушений конфиденциальности до потери данных. Как описано здесь для различных вариантов осуществления, защита конфиденциальности предусматривает шифрование данных прежде чем они покинут центр обработки первичных данных. Однако это не защитит от потери или повреждения данных на вторичном сайте. Кроме того, традиционное шифрование данных препятствует любой постобработке этих данных для поддержания синтетического полного резервного копирования, для осуществления административных операций в рамках этого синтетического полного резервного копирования и для доступа к этой копии для реализации сервисов, некоторые из которых кратко описаны выше.
На фиг.1 показана блок-схема общей среды для обеспечения одного или нескольких вариантов осуществления описанных здесь сервисов резервного копирования. В общем случае, вычислительное(ые) устройство(а) 100 (например, заказчик резервного копирования) находи(я)тся в первой области управления 110, вычислительное(ые) устройство(а) 120 (например, провайдеры облачных сервисов) находи(я)тся во второй области управления 130, вычислительное(ые) устройство(а) 160 находи(я)тся в третьей области управления 190, и провайдер криптографической технологии 180 обеспечен в третьей области управления 196. Каждое из вычислительных устройств 100, 120, 160 может включать в себя процессор(ы) P1, P2, P3, соответственно, и хранилище M1, M2, M3, соответственно. В этой связи, как описано согласно различным неограничительным вариантам осуществления, предусмотрены методы обеспечения шифрованных данных резервной копии 140 в облаке, позволяющие восстанавливать эти элементы 150 из облака и объявлять набор аналитических сервисов 170 поверх шифрованных данных синтетической полной резервной копии 145, которые поддерживаются в облаке на основании локального набора данных 105 из устройства или устройств 100.
Как описано более подробно ниже, различные криптографические методы включены в обеспечение сервисов резервного копирования, которые могут предоставлять пользователям сервиса сильные гарантии конфиденциальности и неаннулирования. Благодаря объединению криптографических методов с методами защиты данных, синтетическое полное резервное копирование можно поддерживать как удаленный сервис, и поверх данных синтетической полной резервной копии можно реализовать многоуровневые приложения таким образом, чтобы владелец этих данных и предприятие-заказчик (“заказчик”) мог детально регулировать типы операций, которые может осуществлять субъект, где хранятся данные, или провайдер или оператор облачных сервисов (“CSP”). Кроме того, многие из этих операций CSP может осуществлять от имени заказчика, не изучая и не наблюдая фактического содержания данных, над которыми осуществляются операции. Наконец, заказчик может выявлять случаи, когда CSP нецелесообразно удаляет или изменяет данные, или перемещает данные во вторичное или третичное хранение низкой производительности.
Как упомянуто, ряд криптографических методов объединяются с сервисами резервного копирования для придания заказчику уверенности в передаче управления данными резервной копии, например, для повышения безопасности и конфиденциальности.
Например, поисковое шифрование - это способ шифрования, когда важные метаданные копируются из данных до их шифрования. В порядке неограничительного примера, в случае электронной почты Exchange, данные представляют собой сообщение, содержащее вложения, и важные метаданные могут включать в себя выбранные свойства программного интерфейса приложения обмена сообщениями (MAPI) и полнотекстовый индекс. Например, данные шифруются, например, с использованием усовершенствованного стандарта шифрования (AES), тогда как шифрование метаданных сопровождается генерацией шифрованных индексов. В результате, шифрованные данные и индексы может передавать другой субъект, который является не полностью доверенной, например, CSP. Последующий избирательный доступ к шифрованным данным, объединенным с индексами, может осуществляться владельцем этих данных, заказчиком, отправляющим шифрованный запрос на CSP (или другим авторизованным абонентам). Следовательно, CSP может применять шифрованные запросы к шифрованным индексам и возвращать соответствующие шифрованные данные, однако CSP не получает никакой информации о содержании данных, метаданных, запросов или результатов (если он не авторизован заказчиком).
Доказательство владения и доказательство восстановимости - это криптографические методы, где “прувер” (в данном случае CSP, обеспечивающий хранение резервных копий) и “верификатор” (заказчик) могут участвовать в протоколе, где верификатор может эффективно определять, остались ли данные, которыми он владеет, нетронутыми, и можно ли их легко возвратить от обработчика данных, CSP. Эти методы эффективны в отношении производительности сети и операций, осуществляемых CSP, поэтому стоимость проданных товаров (COGS) CSP остается относительно неизменной, и время выполнения протокола достаточно коротко.
Другим криптографическим методом, который можно интегрировать в обеспечение сервисов данных резервного копирования, является доказательство применения. Доказательство применения, аналогично доказательству владения, позволяет верификатору убедиться в том, что синтетическое полное резервное копирование надлежащим образом поддерживается прувером, CSP.
В отношении доказательства применения, когда инкрементные резервные копии переносятся в потоковом режиме с первичного сайта на удаленный вторичный сайт, который может быть размещен на стороне, возможно, в облаке, предполагается, что удаленный субъект, в соответствии со своим соглашением об уровне сервиса (SLA), немедленно применит инкременты к копии, хранящейся на вторичном сайте, для поддержания синтетической полной резервной копии. Однако этот удаленный субъект на вторичном сайте может по своему выбору не применять эти записи, возможно по недосмотру, а возможно вследствие необходимости сохранять низкую стоимость товаров, например, она может принять решение применить записи в более позднее время, в течение периодов более низкой загруженности сервера.
Следствием этой задержки в применении записей будет ухудшение RTO, т.е. верхней границы времени, необходимого для восстановления сервиса на вторичном сайте в случае отказа первичного сайта, если отказ первичного сервера/сайта произошел в течение этого временного окна. Кроме того, будет ухудшаться RPO, т.е. верхний предел объема данных продукции, которые могут быть потеряны в любой момент в случае исчезновения первичного сервера/сайта. Причина в том, что если записи не применяются, в отсутствие механизма доказательства применения, владелец или заказчик резервной копии данных не знает о существовании проблемы наблюдения до тех пор, пока не станет слишком поздно исправлять, что приводит к потере данных продукции.
В неограничительном примере Exchange, инкрементные резервные копии имеют вид записей транзакций, которые являются последовательностями записей; полезные данные можно надлежащим образом шифровать, и метаданные могут быть видимыми оператору вторичного/облачного сайта, что позволяет ему воспроизводить записи для поддержания синтетического полного резервного копирования. Обновляемая база данных Exchange (EDB) представляет собой 4-уровневое дерево B+, концевые вершины которого содержат данные продукции. Верификатор знает, как будет выглядеть целевая EDB после применения любых записей. Выделение физических страниц может осуществляться произвольно, на основании используемого распределителя, но существует детерминистическое отображение входного формата записи журнальной записи, в логическое дерево B+.
Верификатор также, возможно, имеет встроенную информацию в полезных данных шифрованной записи, которые могут храниться в деревьях B+. В таком случае, доказательство применения предусматривает, что верификатор, или владелец данных, направляет вызов пруверу, или субъекту, отвечающему за поддержание синтетических полных резервных копий. В конце взаимодействия верификатор выясняет, были ли применены записи.
На фиг.2 показана блок-схема общей среды для обеспечения одного или нескольких вариантов осуществления сервисов резервного копирования, включающих в себя доказательство применения. В этой связи, верификатор 200 (например, владелец данных или заказчик резервного копирования) выдает криптографический вызов 220 пруверу 210 (например, провайдеру сервиса резервного копирования данных), который вычисляет 212 результат как функцию доказываемого применения данных модификации и криптографического вызова. Возвращается ответ 230 на вызов, который позволяет верификатору 200 верифицировать 202 модификации (например, записи транзакций инкремента), примененные на основании ответа на вызов.
Слепые идентификационные признаки представляют криптографический метод другого рода, который расширяет сетевые методы дедупликации, например метод определения идентификационных признаков Рабина (Rabin), которые обычно используются для минимизации обмена избыточными данными по сети. В различных описанных здесь вариантах осуществления, применяется определение идентификационных признаков, благодаря чему, участник протокола, например, CSP в случае хранения данных резервной копии, не знает фактического содержания данных, которыми он распоряжается.
Для некоторого дополнительного контекста, касающегося слепых идентификационных признаков, любой обмен большими объемами данных по глобальным сетям (WAN), включая поддержание синтетического полного резервного копирования, потребует методов “дедупликации” по проводной линии связи или удостоверения в том, что ненужные данные не передаются по проводной линии связи. Это осуществляется путем определения идентификационных признаков сегментов данных с последующим обменом идентификационными признаками, благодаря чему, отправители знают, что то, что имеют они, получатели не имеют. Кроме того, получатели знают, какие данные они должны запрашивать у отправителей. Репликацию сервиса распределенных файлов (DFS-R) можно использовать для оптимизации обменов данными в таких сценариях, как резервные копии для филиалов и распределенные файловые системы в WAN.
В случае Exchange имеет место значительная дупликация данных, и возможно, что до 50% или более данных на проводной линии связи могут быть дубликатами в любое данное время. Идентификационные признаки можно получать на уровне блоков или на уровне объектов, например электронной почты, календарных элементов, заданий, контрактов и т.д. Идентификационные признаки можно кэшировать на центрах обработки первичных и вторичных данных. Таким образом, в случае отказа на центре обработки первичных данных, вторичные данные можно восстановить для центра обработки первичных данных совместно с идентификационными признаками. Шифрование данных на центре обработки первичных данных тем не менее должно позволять оператору центра обработки вторичных данных видеть идентификационные признаки, несмотря на то, что они скрыты. Этого можно добиться, например, сохраняя идентификационные признаки как ключевые слова/метаданные с поисковым шифрованием, чтобы кроме авторизованных субъектов/агентов в центре обработки вторичных данных, никакой другой субъект не мог обнаружить шаблоны.
Применительно к сервисам данных резервного копирования, при отправке полной или инкрементной резервной копии, центр обработки первичных данных может проверять каждый элемент/сегмент/блок в записях, или EDB, и принимать во внимание локальную копию идентификационных признаков. При наличии совпадения, центр обработки первичных данных заменяет элемент/сегмент/блок идентификационным признаком. Термин “слепые идентификационные признаки” употребляется здесь ввиду манеры применения определения идентификационных признаков. В одном варианте осуществления, выбор криптографических технологий для достижения слепого определения идентификационных признаков включает в себя криптографический метод сохранения размера.
На фиг.3 показана блок-схема общей среды для обеспечения одного или нескольких вариантов осуществления сервисов резервного копирования, включающих в себя слепое определение идентификационных признаков. С помощью слепых идентификационных признаков абонент 300 данных резервной копии и провайдер 310 сервиса резервного копирования данных проводят обмен идентификационными признаками, чтобы понять, в качестве посредника, который уже располагает сегментами данных на соответствующих локальных и резервных копиях резервируемого набора данных. В результате обмена 320 идентификационными признаками определяется 302 сокращенный набор данных модификации для передачи в качестве дедуплицированных данных модификации 330 провайдеру 310 сервиса резервного копирования данных, который затем применяет 340 данные модификации на основании избирательного доступа к дедуплицированным данным модификации и любых слепых идентификационных признаков.
Таким образом, возникает ряд сценариев, основанных на обеспечении сервисов резервного копирования со стороны CSP, на основании вышеописанной инфраструктуры и соответствующих криптографических методов, начиная с сервисов хранения и вычисления и заканчивая сервисами связи и сотрудничества. Более крупные предприятия-заказчики имеют значительные возможности вычисления и хранения в своих нынешних центрах обработки данных предприятия, и инерция принятия облачных сервисов может быть высокой. Кроме того, заказчики имеют опыт и навык работы с центром обработки данных, желая использовать преимущества эксплуатационных расходов (OPEX) и капитальных вложений (CAPEX), и, таким образом, заботятся о своих важных коммерческих данных, перемещая их из помещения в облако.
Для этого класса заказчиков, в различных вариантах осуществления, предусмотрен набор приложений, действующих с участием заказчика, владеющего и оперирующего своими существующими серверами, например сервером Exchange. Затем вторая копия данных делегируется провайдеру облачных сервисов с целью защиты данных, архивации, согласования, управления, решения правовых вопросов и пр. Таким образом, CSP имеет необходимые навыки, технологии и повышение эффективности от роста масштабов производства, чтобы уберечь эти данные от потери или раскрытия данных, и может облегчать выполнение приложений поверх этой второй копии. Частные случаи иллюстративных продуктов и сервисов, которые могут предлагаться заказчику на основании поддержания синтетического полного резервного копирования, включают в себя поддержку судебного процесса, мониторинг и надзор, готовность сервиса, навигацию по данным и т.д.
В отношении поддержки судебного процесса, компания является ответчиком, существует ряд субъектов, которые необходимы судебному процессу для осуществления поисков по историческим записям электронной почты. Эти субъекты включают в себя внутренний судебный персонал, HR, менеджеров, внешнего адвоката, их внешнего партнера поддержки судебного процесса и адвоката противоположной стороны. Существуют особые правила объема, определяющие, кто какой поиск может осуществлять. В современных сценариях поддержки судебного процесса трудно ограничить объемы. Поэтому для любого лица, участвующего в поддержке судебного процесса, имеется возможность просмотра электронной почты, выходящей за пределы объема. В случае электронной почты обмен результатами поисков обычно осуществляется в форме файлов персональной таблицы хранения (PST), что составляет дополнительный риск, поскольку эти файлы могут неумышленно или умышленно передаваться неавторизованным лицам.
Напротив, когда вторая копия хранится удаленно, например, в облаке посредством CSP, и поддерживается посредством синтетического полного резервного копирования, единственный доверенный субъект на предприятии, например главный юрисконсульт, может предоставлять каждому действующему лицу конкретные секреты, которые будут ограничивать их возможности запроса необходимыми рамками. Данные, хранящиеся в облаке и защищенные посредством поискового шифрования и защищенной от подделки аудиторской записью, обеспечивают более высокий уровень защиты, который препятствует ненадлежащему доступу к электронной почте. Необходимость в обмене файлами PST исключается, поскольку все задействованные лица обращаются непосредственно к облаку для запросов, и партнером поддержки судебного процесса является только субъект, экспортирующий таргетированный контент для преобразования в теговый формат файлов изображения (TIFF) для ведения дела.
В отношении мониторинга и надзора за удаленной копией данных резервной копии, любая достаточно крупная корпорация должна осуществлять предупредительный мониторинг электронной почты своей организации с различными целями. Эти цели могут включать в себя законность/согласование, а также цели управления, например, мониторинг IP-утечек, плагиата, нецензурных выражений и т.д. Обычно программное обеспечение мониторинга и надзора отслеживает либо первичные серверы, либо вторую копию, которая резервируется или архивируется. Проблема мониторинга первичных серверов состоит в дополнительной нагрузке и без того нагруженных серверов продукции. Кроме того, поскольку администраторы могут случайно или намеренно изменить или удалить данные на первичных серверах, решение состоит в согласованном захвате данных и переносе их во вторую копию, где программное обеспечение мониторинга и надзора непрерывно сканирует входящую электронную почту в поисках шаблонов. Однако во многих структурах предприятия имеется локальный административный доступ к этим вторым копиям, в результате чего находчивый администратор может изменять или удалять информацию в обход механизмов обнаружения и предотвращения вмешательства.
Напротив, поддержание синтетического полного резервного копирования со стороны CSP преимущественно помещает вторую копию в другую область управления. Подходящие криптографические методы, например поисковое шифрование с открытым ключом (PEKS) и доказательство владения (POP) могут гарантировать, что даже тайный сговор между администратором предприятия и работником CSP не позволит им положительно идентифицировать именно тот элемент, который они хотят изменить. Программное обеспечение мониторинга и надзора выполняется на удаленном сайте или в облаке и ищет элементы, имеющие конкретные заранее определенные ключевые слова, с помощью ранее обеспеченных секретов.
В отношении готовности сервиса, в случае возникновения на первичном центре любого отказа, приводящего к потере данных, для восстановления извлекается самая последняя резервная копия, и сервис перезапускается. Для определенных классов серверов конечному пользователю важнее иметь возможность пользоваться сервисом, чем иметь доступ ко всем своим данным. Поэтому серверы, например Exchange, реализуют возможность, именуемую «готовностью», позволяющую перезапускать почтовые сервисы Exchange сразу после восстановления из аварийного состояния. В этом случае, пользователь может отправлять и принимать электронную почту, тогда как в фоне, содержимое его почтового ящика переносится в потоковом режиме из второй резервной копии.
В сценариях облачного резервного копирования полоса пользуется большим спросом, и восстановление данных из облака на предприятии может занимать слишком много времени, если оно находится на критическом пути восстановления. Решение, аналогичное готовности, представляет собой “готовность сервиса”, позволяющее клиентскому программному обеспечению, например в Exchange или Outlook, передавать в потоковом режиме секреты в некотором порядке на удаленный сайт, или в облаке, и позволяющее CSP отправлять соответствующие шифрованные сообщения обратно на предприятие. Его можно реализовать в двух фазах - первая отправляет суррогаты сообщений (заголовки без тела); вторая запрашивает фактическое тело и вложения, когда пользователь пытается непосредственно осуществить доступ к сообщению. Для вышеописанных сценариев резервного копирования готовность реализуется таким образом, чтобы не компрометировать конфиденциальность заказчика.
В отношении навигатора данных, в типичном сценарии сотрудничества на предприятии или управления записями, возможно наличие множественных дубликатов документов в репозитории. Например, группа сотрудников может обмениваться слайдом PowerPoint с отдельными модификациями по электронной почте. В результате получается сбивающий с толку набор версий, которые конечный пользователь должен каким-то образом возвратить инженеру, чтобы определить, какая версия является наиболее релевантной или самой последней.
Когда вторая шифрованная копия хранится в облаке, сервис может работать над массивом шифрованных данных посредством поискового шифрования, где CSP предоставляются только конкретные секреты, которые позволяют CSP понимать ID сообщений, переговорные потоки выполнения и ID анонимных документов. Таким образом, когда пользователь отправляет секрет, соответствующий конкретному документу, сервис CSP способен обходить репозиторий и возвращать наилучшее совпадение. Это может занимать диапазон от самой последней до всей иерархии версий.
Таким образом, как описано согласно различным вариантам осуществления, синтетическое полное резервное копирование можно реализовать для любого сервера/сервиса, который поддерживает полные и инкрементные резервные копии. В этом разделе Exchange используется в качестве иллюстративного сценария, однако следует понимать, что поддерживаются данные резервной копии любого рода. Соответственно, хотя настоящий вариант осуществления рассматривается применительно к данным Exchange, описанные здесь варианты осуществления не ограничиваются данными сообщения. Для поддержания синтетического полного резервного копирования выполняются следующие этапы.
1. Извлечение полной резервной копии: программный агент инициирует полное резервное копирование на первичном сервере Exchange, вызывая программные интерфейсы приложения (API) резервного копирования либо расширяемого движка хранения (ESE), либо сервиса теневого копирования тома (VSS). Это обеспечивает копию EDB, файлов потоковой базы данных (STM) и записей в резервируемой группе хранения.
2. Подготовка полной резервной копии: программный агент обходит EDB, STM и записи, и данные продукции шифруются в режиме сохранения размера. Структурные метаданные шифруются с использованием поискового шифрования. Генерируются криптографические секреты, благодаря чему удаленный субъект, поддерживающий синтетическое полное резервное копирование, может использовать секреты для обхода записей или EDB.
3. Перенос полной резервной копии: EDB, STM и записи переносятся на вторичный сайт в режиме сетевой оптимизации.
4. Сохранение базовой линии полного резервного копирования: вторичный сайт сохраняет этот вновь принятый набор в качестве базовой линии для последующих операций синтетического полного резервного копирования. Полное резервное копирование обычно повторяется после определенных событий, например восстановления или дефрагментации в автономном режиме.
5. Инкрементное резервное копирование: после полного резервного копирования программный агент выполняет извлечение инкремента из Exchange с использованием API резервного копирования либо ESE, либо VSS. Это обеспечивает копию всех записей, сгенерированных после последнего полного или инкрементного резервного копирования.
6. Подготовка инкрементной резервной копии: программный агент обходит записи, и данные продукции шифруются в режиме сохранения размера, тогда как структурные метаданные шифруются в поисковом режиме.
7. Перенос инкрементной резервной копии: записи переносятся на вторичный сайт в режиме сетевой оптимизации.
8. Доступ к записи инкремента: после переноса инкрементной резервной копии, например сразу после, субъект на вторичном сайте использует секреты, которые предоставлены ей вне полосы, благодаря чему, вторичный сайт может осуществлять доступ к структурным метаданным EDB, STM и записей, обходить записи и применять их к EDB.
9. Применение [“воспроизведение”] записи: после осуществления доступа к записи инкремента, например сразу после, записи применяются к EDB с целью их обновления.
10. Восстановление элемента: для восстановления элемента, или потока элементов, из вторичной копии, поддерживаемой посредством синтетического полного резервного копирования, программный агент на центре обработки вторичных данных принимает секрет, который используется для извлечения элемента (например, сообщения, календарного элемента, задания, контракта и т.д.) из EDB для восстановления обычно в центр обработки первичных данных.
11. Аналитика/восстановление: получатель элемента, или потока элементов, из предыдущего набора является авторизованным субъектом, который имеет доступ к симметричным ключам, которые использовались для шифрования данных продукции, и способен использовать элементы для приложений в пределах от восстановления до аналитики.
Соответственно, в соответствии с вышеописанными методиками, ниже описан ряд вариантов осуществления. На фиг.4 показана логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс на стороне сервиса для поддержания данных синтетической полной резервной копии для заданного набора данных на основании шифрованных данных и метаданных и данных секрета. На этапе 400 вычислительное устройство в первой области управления принимает от вычислительного устройства во второй области управления шифрованные данные, сформированные путем шифрования данных полной резервной копии для заданного набора данных вычислительного устройства во второй области управления согласно алгоритму поискового шифрования на основании информации криптографических ключей. На этапе 410 вычислительное устройство в первой области управления принимает шифрованные метаданные, сформированные путем анализа данных полной резервной копии и шифрования выхода анализа на основании информации криптографических ключей. На этапе 420 принимаются данные секрета, позволяющие осуществлять видимый, или избирательный, доступ к шифрованным данным. На этапе 430 сервис резервного копирования поддерживает данные синтетической полной резервной копии для заданного набора данных на основании шифрованных данных, шифрованных метаданных и данных секрета.
На фиг.5 показана логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс на стороне заказчика для поддержания данных синтетической полной резервной копии согласно варианту осуществления. На этапе 500 инициируется полное резервное копирование первичных данных, хранящихся в памяти вычислительного устройства в первой области управления, для формирования данных полной резервной копии для использования при поддержании данных синтетической полной резервной копии для первичных данных удаленным вычислительным устройством во второй области управления. На этапе 510, на основании обхода первичных данных, генерируется структурные метаданные, которые описывают первичные данные. На этапе 520 первичные данные и структурные метаданные шифруются для формирования шифрованных данных и шифрованных метаданных согласно методу(ам) поискового шифрования на основании информации криптографических ключей, принятой от генератора ключей, который генерирует информацию криптографических ключей. На этапе 530, на основании информации криптографических ключей, генерируются криптографические секреты, позволяющие обходить шифрованные данные, указанные в криптографических секретах.
На фиг.6 показана логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для восстановления элементов данных согласно варианту осуществления для поддержания данных синтетической полной резервной копии. На этапе 600 запрашивается восстановление элемент(ов) данных набора данных абонентского(их) вычислительного(ых) устройства (или устройств) сервиса данных резервного копирования, который поддерживает данные синтетической полной резервной копии, соответствующие набору данных в поисково-шифрованном формате для сервиса синтетического полного резервного копирования сервисом данных резервного копирования. На этапе 610 элемент(ы) данных принимаются в поисково-шифрованном формате. На этапе 620, на основании информации криптографических ключей, используемых для шифрования набора данных, доступного абонентскому(им) устройству(ам), элемент(ы) данных набора данных восстанавливаются в памяти абонентского(их) вычислительного(ых) устройства (или устройств).
На фиг.7 показана логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для обеспечения сервисов резервного копирования, включающих в себя доказательство применения. На этапе 700 данные модификации (например, записи транзакций, представленные как полная или инкрементная резервная копия) шифруются для формирования шифрованных данных модификации, представляющих набор модификаций набора данных вычислительного устройства в первой области управления согласно алгоритму поискового шифрования на основании информации криптографических ключей, принятой от генератора ключей, который генерирует информацию криптографических ключей. На этапе 710 шифрованные данные модификации передаются на вычислительное устройство во второй области управления для обновления данных синтетической полной резервной копии, хранящихся на вычислительном устройстве во второй области управления. На этапе 720 доказывается, что вычислительное устройство во второй области управления применило набор модификаций к данным синтетической полной резервной копии для обновления данных синтетической полной резервной копии по соглашению с сервисом резервного копирования.
На фиг.8 показана логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для обеспечения сервисов резервного копирования, включающий в себя вышеописанное слепое определение идентификационных признаков. На этапе 800 данные модификации шифруются для формирования шифрованных данных модификации, представляющих набор модификаций набора данных вычислительного устройства в первой области управления согласно алгоритму поискового шифрования на основании информации криптографических ключей, принятой от генератора ключей, который генерирует информацию криптографических ключей. На этапе 810 сегмент(ы) данных, представленный(е) в наборе данных, снабжаются идентификационными признаками для формирования идентификационных признаков, заменяющих фактические данные модификации, где определяется, что соответствующий сегмент данных представлен в локальном наборе идентификационных признаков, представляющих сегменты данных набора данных. На этапе 820 шифрованные данные модификации передаются на вычислительное устройство во второй области управления для обновления данных синтетической полной резервной копии, хранящихся на вычислительном устройстве во второй области управления.
На фиг.9 показана логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для обеспечения сервисов резервного копирования, включающий в себя восстановление после отказа для быстрого перезапуска приложения. На этапе 900 после отказа (ошибки, удаления, изменения и т.д.) данных набора данных абонентского устройства восстановление элемента(ов) данных набора данных запрашивается с сервиса данных резервного копирования, который поддерживает данные синтетической полной резервной копии, соответствующие набору данных в поисково-шифрованном формате для сервиса синтетического полного резервного копирования сервисом данных резервного копирования. На этапе 910 часть элемента(ов) данных принимается в шифрованном формате от сервиса данных резервного копирования и перезапускает приложение абонентского устройства на основании использования части элемента(ов) данных. На этапе 920 после перезапуска принимаются все оставшиеся данные элемента(ов) данных, еще не принятые абонентским устройством.
Как описано выше, согласно различным вариантам осуществления, независимые методы защиты данных и криптографии объединяются таким образом, чтобы улучшать и модифицировать друг друга в порядке поддержки для обеспечения объединенных решений, в настоящее время не доступных потребителям, предприятиям, экосистемам и социальным сетям.
ВСПОМОГАТЕЛЬНЫЙ КОНТЕКСТ ДЛЯ ЭКОСИСТЕМЫ ДОВЕРЕННЫХ
ОБЛАЧНЫХ СЕРВИСОВ
Как описано выше, независимые методы защиты данных и криптографии по-разному объединяются для повышения конфиденциальности, доверия и безопасности в отношении данных резервной копии, например, хранящихся как синтетическая полная резервная копия на удаленном сайте, например, поддерживаемом CSP. Хотя общая экосистема описана ниже применительно к общему сервису данных или сетевому сервису, такой общий сервис данных или сетевой сервис можно использовать для любого одного или нескольких из вышеописанных сценариев для сохранения данных резервной копии на удаленном сайте.
Шаблон цифрового эскроу предусмотрен для сетевых сервисов данных, включающих в себя методы поискового шифрования для данных, хранящихся в облаке, распределения доверия между множественными субъектами во избежание компрометации единичного субъекта. В одном варианте осуществления, генератор ключей, провайдер криптографической технологии и провайдер облачных сервисов обеспечены как отдельные субъекты, позволяющие издателю данных конфиденциально (в шифрованном виде) публиковать данные провайдеру облачных сервисов, и затем избирательно открывать шифрованные данные абонентам, запрашивающим эти данные, на основании информации идентификации абонента, закодированной в информации ключей, сгенерированных в ответ на запросы абонентов.
В отношении алгоритма(ы) поискового шифрования/дешифрования, схема поискового шифрования с открытым ключом (PEKS), реализуемая одним или несколькими провайдерами криптографической технологии, генерирует, для любого данного сообщения W, секрет TW, так что TW позволяет проверять, получен ли данный шифротекст шифрованием W, причем TW не раскрывает никакой дополнительной информации об открытом тексте. Согласно различным вариантам осуществления, описанным ниже, схемы PEKS можно использовать для приоритизации или фильтрации шифрованных данных, например шифрованных сообщений, на основании ключевых слов, содержащихся в данных, например тексте сообщения. Таким образом, получателю данных может предоставляться выборочный доступ к частям шифрованных данных, относящихся к ключевому(ым) слову(ам) за счет выпуска возможностей (которые криптографы иногда называют “секретами”) для соответствующего(их) ключевого(ых) слова или слов. Таким образом, шифрованные данные можно проверять на эти ключевые слова, но при этом гарантируется, что у абонента нельзя получить никакой дополнительной информации, кроме той, что допускается возможностями абонента.
В целях исключения неоднозначного толкования, хотя PEKS раскрыт как алгоритм для реализации поискового шифрования в одном или нескольких из раскрытых здесь вариантов осуществления, очевидно, что существует ряд альтернативных алгоритмов для обеспечения поискового шифрования. Некоторые иллюстративные неограничительные альтернативы PEKS, например, включают в себя Oblivious RAM. Таким образом, употребляемый здесь термин “поисковое шифрование” не ограничивается каким-либо одним методом и, таким образом, относится к широкому кругу механизмов шифрования или комбинаций механизмов шифрования, которые обеспечивают избирательный доступ к подмножеству шифрованных данных на основе функциональных возможностей поиска или запроса по шифрованным данным.
В необязательном порядке, валидизация и/или верификация результатов может быть предоставлена абонентам и издателям данных в экосистеме как дополнительное преимущество. Валидизация позволяет удостовериться в том, что элементы данных, принятые в результате запроса подписки для подмножества данных, составляют правильный набор элементов, т.е. что фактически было принято правильное подмножество данных, которое должно было быть принято. Метод в области криптографии представляет собой доказательство владения данными (PDP); однако, в целях исключения неоднозначного толкования, PDP является всего лишь иллюстративным алгоритмом, который можно реализовать, и можно использовать другие алгоритмы, достигающие таких же или аналогичных целей. Доказуемое или доказательство владения данными это тема о том, как часто, эффективно и безопасно удостоверяться в том, что сервер хранения надежно хранит потенциально большие сторонние данные своих клиентов. Сервер хранения считается недоверенным в отношении безопасности и надежности.
Верификация результатов обеспечивает дополнительный механизм проверки содержания самих элементов, т.е. гарантирования того, что элементы, принятые в связи с запросом подписки, не были подделаны неавторизованным субъектом. Примером верификации в области криптографии является доказательство владения данными (PDP); однако, в целях исключения неоднозначного толкования, PDP является всего лишь иллюстративным алгоритмом, который можно реализовать, и можно использовать другие алгоритмы, достигающие таких же или аналогичных целей. Другим методом, известным в области криптографии, является доказательство восстановимости (POR); однако, в целях исключения неоднозначного толкования, POR является всего лишь иллюстративным алгоритмом, который можно реализовать, и можно использовать другие алгоритмы, достигающие таких же или аналогичных целей. POR является компактным доказательством со стороны провайдера сервисов или держателя данных (прувера), предоставляемым клиенту (верификатору), того, что целевой F не тронут в том смысле, что клиент может полностью восстановить файл F, и что никакого вмешательства не произошло.
В качестве дополнительной возможности, экосистема может реализовать представления анонимного мандата, благодаря чему, издатели могут выгружать информацию о самих себе в режиме анонимности, не раскрывая критические детали, и абоненты могут быть ограничены в своих возможностях, что не позволяет им открывать или обеспечивать доступ к критическим деталям, выгружаемым издателем. Таким образом, издатель или абонент может взаимодействовать с системой, открывая третьим лицам ровно столько информации, сколько они желают.
Традиционные web-сервисы были ограничены статическими клиент-серверными конфигурациями и статически заданной пользовательской политикой доступа к данным web-сервиса. Однако, когда предусмотрено много издателей и абонентов согласно постоянно меняющимся и развивающимся сложным деловым и другим взаимоотношениям, такая традиционная модель web-сервисов не позволяет обеспечить достаточной гибкости или защищенности. Соответственно, в различных вариантах осуществления, предусмотрено динамическое связывание, позволяющее издателям и/или владельцам данных и контента изменять привилегии доступа к шифрованному контенту на основании того, кем является/являются абонент(ы), на основании их возможности(ей) и на основании предмета их поиска, например, на основании ключевого(ых) слова (или слов), используемого(ых) в запросе данных. Таким образом, то, к чему абонент может избирательно получать доступ, динамически изменяется в соответствии с изменениями привилегий доступа, производимыми издателями и/или владельцами, поскольку возможности абонента закодированы в информации ключей, обеспечиваемой генератором ключей в оперативном режиме. Таким образом, абонентские привилегии задаются для данного запроса на момент генерации ключей для запроса и, таким образом, всегда отражают текущую политику в отношении запроса от абонента.
Аналогично, администратору сервера доверенного облачного сервиса может быть разрешено просматривать журнал активности и транзакций данных, обрабатываемый сервером, но также может быть запрещено видеть имена заказчиков или информацию кредитных карт. Таким образом, идентификация абонента может быть основанием для ограничения типа данных, к которым абонент может осуществлять доступ.
Различные неограничительные варианты осуществления доверенной экосистемы представлены здесь применительно к формированию доверительных отношений для облачного сервиса; однако представленное здесь формирование доверительных отношений в экосистеме является гораздо более общим и не ограничивается применением к облачным сервисам. Напротив, описанные здесь варианты осуществления аналогично применимы к разным серверам или участникам в центрах обработки данных предприятия. Таким образом, в то время, как данные могут никогда не покидать данный субъект, описанные здесь методики формирования доверительных отношений в равной степени применимы к случаю, когда разные процессы на предприятии выполняются в отдельных областях управления. В отсутствие возможности наблюдения всех процессов на предприятии могут возникать аналогичные вопросы недоверия, как если бы участники были внешними по отношению к предприятию. Например, сервер на предприятии может быть взломан, несмотря на то, что он находится под управлением администратора, или администратор может быть невнимательным или злонамеренным.
Помимо применения к шифрованным данным в облаке различные методики согласно изобретению также можно применять к данным, хранящимся на портативном компьютере или другом портативном устройстве, поскольку портативный компьютер может быть потерян или украден. В таком случае, устройство может попасть в руки излишне любопытных или злонамеренных субъектов; однако методы, идентичные описанным здесь, которые применяются для защиты данных в облаке, также можно применять для защиты данных на серверах или портативных компьютерах. В случае шифрования локальных данных, не имея надлежащего абонентского мандата, вор не сможет понять локальных шифрованных данных, не будучи способен предъявить правильной роли или возможностей для доступа к данным.
На фиг.10 показана блок-схема инфраструктуры или экосистемы доверенных облачных сервисов согласно варианту осуществления. Система включает в себя доверенное хранилище данных 1000 для хранения поисково-шифрованных данных 1010, причем результаты запросов абонента подвергаются валидизации и/или верификации. В этой связи, сетевые сервисы 1020 могут быть построены поверх защищенных данных 1010, что позволяет издателям данных удерживать управление над возможностями, предоставляемыми абонентами 1040, запрашивающим данные, например, через сетевой(ые) сервис(ы) 1020. Издатели 1030 сами могут быть абонентами 1040, и наоборот, и владельцы 1050 данных также могут быть издателями 1030 и/или абонентам 1040. В качестве примера некоторых общих ролей и соответствующих наборов возможностей, которые могут быть заданы, особыми разновидностями издателей 1030 и абонентов 1040 являются администраторы 1060 и аудиторы 1070.
Например, администраторы 1060 могут представлять собой особый набор разрешений над данными 1010, которые помогают поддерживать функционирование доверенного хранилища данных 1000, и аудиторские субъекты 1070 могут помогать поддерживать целостность определенных данных в объеме аудита. Например, аудитор 1070 может подписаться на сообщения данных 1010, содержащие оскорбительные ключевые слова, в каковом случае аудитор 1070, если это разрешено согласно предоставленным возможностям, будет извещен о сообщениях данных 1010, содержащих такие оскорбительные ключевые слова, но не будет способен читать другие сообщения. В этой связи, можно построить большое количество сценариев на основании способности помещать данные издателя в цифровое эскроу, что позволяет передавать ключи, обеспечивая избирательный доступ к этим данным.
Например, издатель аутентифицируется в экосистеме и указывает набор документов для выгрузки в экосистему. Документы шифруются согласно алгоритму поискового шифрования на основании информации криптографических ключей, принятой от отдельного генератора ключей, который генерирует информацию криптографических ключей. Затем шифрованные данные передаются провайдеру сетевых сервисов для хранения шифрованных данных, благодаря чему шифрованные данные становятся избирательно доступными, согласно динамическому связыванию выбранных привилегий, предоставленных запрашивающему устройству на основании информации идентификации запрашивающего устройства. Отделение провайдера криптографической технологии от хранилища шифрованных данных дополнительно ограждает шифрованные данные от дополнительной компрометации.
В этой связи, на фиг.11 показана логическая блок-схема, демонстрирующая иллюстративный неограничительный способ для публикации данных согласно экосистеме доверенных облачных сервисов. На этапе 1100 издатель аутентифицируется в системе (например, издатель входит с использованием имени пользователя и пароля, мандата Live ID и т.д.). На этапе 1110, информация ключей генерируется генератором ключей, например, центром для генерации ключей, что описано ниже в одном или нескольких вариантах осуществления. На этапе 1120 отдельный провайдер криптографической технологии шифрует набор документов издателя на основании информации ключей. На этапе 1130 шифрованные документы выгружаются с возможностями на провайдер сетевых сервисов, например, провайдер сервисов хранения, благодаря чему шифрованный(е) документ(ы) становятся избирательно доступными с использованием динамического связывания выбранных привилегий, предоставленных на основании информации идентификации запрашивающего устройства (абонента).
На абонентской стороне, например, абонент аутентифицируется в экосистеме и указывает запрос на подмножество данных, например, запрос на подмножество документов, содержащих данное ключевое слово или множество ключевых слов. В ответе на запрос подмножества поисково-шифрованных данных от, по меньшей мере, одного абонентского устройства, компонент генерации ключей генерирует информацию криптографических ключей на основании информации идентификации, связанной с абонентским устройством. Затем подмножество шифрованных данных дешифруется как функция привилегий, предоставленных абонентскому устройству, указанному в информации криптографических ключей.
На фиг.12 показана логическая блок-схема, демонстрирующая иллюстративный неограничительный способ оформления подписки на данные согласно экосистеме доверенных облачных сервисов. На этапе 1200 способ оформления подписки на данные включает в себя аутентификацию абонента (например, абонент входит с использованием имени пользователя и пароля, мандата Live ID и т.д.). На этапе 1210 абонент делает запрос данных. На этапе 1220 информация ключей генерируется независимым субъектом генерации ключей на основании запроса абонента, причем возможности абонента могут быть заданы в информации ключей. На этапе 1230, подмножество данных издателя дешифруется на основании возможностей, заданных в информации ключей. Например, дешифровать данные может CSP. На этапе 1240 подмножество данных издателя делается доступным абоненту, например, абонент получает возможность загружать, просматривать, обрабатывать, изменять и т.д. данные на основании динамически задаваемых возможностей, предоставленных владельцем/издателем. В необязательном порядке, технология, используемая для шифрования, дешифрования и генерации ключей, может обеспечиваться отдельным провайдером криптографической технологии, но поддерживаться любым участником.
В одном варианте осуществления, информация идентификации абонентского устройства включает в себя роль абонента. Например, роль аудитора или роль администратора или другую заранее указанную роль издатели/владельцы могут использовать как основание для ограничения или предоставления доступа к различным участкам хранилища поисково-шифрованных данных.
На фиг.13 показана схема иллюстративной экосистемы, демонстрирующая разделение центра 1300 для генерации ключей (CKG), провайдера 1310 криптографической технологии (CTP) и провайдера 1320 облачных сервисов (CSP), что исключает возможность компрометации единичным субъектом в доверенной экосистеме. В этой связи, заказчик(и) 1330 включает(ют) в себя издателей и/или абонентов данных. В необязательном порядке, CKG 1300 может быть построен на основании опорного программного обеспечения, программного обеспечения с открытым исходным кодом, и/или комплекта разработки программного обеспечения (SDK), например, предоставленного CTP 1310, снабжающего стороны строительными блоками для самостоятельного создания таких компонентов, или может довольствоваться сторонними реализациями таких компонентов экосистемы. В одном варианте осуществления, SDK предоставляется CTP 1310 и может использоваться одним или несколькими участниками для поддержки или реализации CKG 1300, абстрагирования вычисления и хранения (CSA), более подробно описанного ниже, и/или библиотек криптографических клиентов. В необязательном порядке, SDK может распределяться на субъект, обеспечивающий CKG 1300, из CTP 1310.
В общем случае, каждый из CKG 1300, CTP 1310 или CSP 1320 может делиться на подкомпоненты в зависимости от данной реализации, однако общее разделение сохраняется для поддержания доверия. Например, субъекты 1301 CKG, например, доставка 1302 открытого главного ключа (MPK), загрузчик 1304 клиентских библиотек, экстрактор 1306 секретного ключа, верификатор доверия 1308 или другие подкомпоненты, могут обеспечиваться по отдельности, в подмножествах, или совместно, в виде объединенного компонента. Субъекты 1311 CTP, например, клиентское приложение для кодирования и декодирования 1312, альтернативные методы шифрования 1314, приложение для сопряжения с CKG 1316, другие криптографические строительные блоки 1318 и т.д., также могут обеспечиваться по отдельности, в подмножествах, или совместно. Кроме того, CSP 1320 можно рассматривать как большое количество отдельных провайдеров сервисов, например, CSP 1322, 1326, поддерживающих сервис хранения 1324 и хостинг сервисов 1328, соответственно, или такие сервисы могут обеспечиваться совместно.
Очевидно, что CKG, или экземпляр(ы) CKG, находящиеся в распоряжении одного или нескольких участников доверенной экосистемы, не обязаны быть единым монолитным субъектом. Напротив, CKG может делиться на несколько (избыточных) субъектов, которые сообща генерируют ключи, чтобы работа могла продолжаться, даже если небольшое подмножество участников действует в автономном режиме. В одном варианте осуществления, в необязательном порядке, множество участников, в целом, может быть доверенным, даже если небольшое их подмножество скомпрометировано нарушителем, или по иной причине стало недоступным или недоверенным.
На фиг.14 показана другая архитектурная схема, демонстрирующая дополнительные преимущества доверенной экосистемы для осуществления облачных сервисов для предприятий 1400. Например, предприятия 1400 могут включать в себя различные организации 1402, 1404, 1406, 1408. Различные организации 1402, 1404, 1406, 1408 в этой схеме иллюстрируют, что организации могут брать на себя большую или меньшую ответственность в отношении реализации политики для использования системы или генерации ключей. Например, организация 1402 реализует свою собственную политику 1412, но использует централизованный генератор ключей 1422, тогда как организация 1404 предпочитает реализовать свой собственный генератор ключей 1424 и свою собственную политику 1414. Организация 1406 также реализует свою собственную политику, но прибегает к помощи стороннего CKG 1426, тогда как организация 1408 предпочитает прибегать к помощи стороннего провайдера 1418 политик и независимого CKG 1428.
В этой связи, для публикации данных, издатель 1440 получает 1435 открытые параметры для данных шифрования на основании выхода CKG 1422. На основании открытых параметров, данные шифруются устройством 1440 издателя на этапе 1445 с использованием независимого провайдера криптографической технологии. Шифрованные данные выгружаются на сервис 1450 абстрагирования хранения, который скрывает семантику хранения в связи с сохранением шифрованных данных одним или несколькими CSP 1470, например CSP 1472, 1474, 1476 или 1478. На абонентском устройстве 1460 запрос данных приводит к генерации личного секретного ключа 1465 на CKG 1422. Личный секретный ключ 1465 включает в себя информацию, которая позволяет абонентскому устройству 1460 избирательно осуществлять доступ к поисково-шифрованным данным путем дешифрования данных на этапе 1455. Опять же, сервис 1450 абстрагирования хранения скрывает семантику восстановления данных из CSP 1470. Кроме того, привилегии, предоставленные абонентскому устройству 1460, являются текущим набором привилегий вследствие динамического связывания возможностей, предоставленных издателями/владельцами.
Из фиг.14 явствует, что множественные владельцы данных, предприятия либо потребители, могут участвовать в описанной здесь доверенной экосистеме для установления доверительных отношений. В таком случае, каждый владелец может распоряжаться или управлять своим собственным CKG (например, CKG 1424 организации 1404), чтобы запросы данных переправлялись на соответствующие CKG для сбора необходимых ключей от совладельцев запрашиваемых данных.
На фиг.15 показана другая блок-схема, демонстрирующая согласование разных провайдеров хранения через уровень абстрагирования хранения 1510. С помощью доверенной экосистемы, настольные компьютеры 1530, 1532, имеющие клиентские приложения 1540, 1542, соответственно, могут публиковать данные или подписываться на них, как описано выше, инициируя запрос центру 1520 для генерации ключей на информацию ключей для использования в шифровании или дешифровании данных. Аналогично, сервисами 1544, 1546, 1548 в экосистеме также могут быть издатель и/или абонент. В этой связи, для осуществления хранения или извлечения данных посредством любого из личного облачного хранилища 1500, хранилища 1502 сервисов данных SQL или простого web-сервиса хранения 1504 и т.д., сервис 1510 абстрагирования хранения, как следует из названия, абстрагирует от клиентов конкретные детали конкретного хранения репозитория или репозиториев.
В этой связи, в целях исключения неоднозначного толкования, фиг.15 применима к различным ситуациям. В одной ситуации, фиг.15 охватывает дезинтермедиацию провайдеров хранения (абстрагирование их от индивидуалов) с помощью сервиса абстрагирования хранения, также иногда именуемую абстрагированием вычисления и хранения (CSA). Кроме того, фиг.15 охватывает сценарии, где данные сегментируются и/или рассредотачиваются (например, для создания избыточности) по множественным скрытым провайдерам хранения, которые могут относиться к одному или разным типам, что позволяет реконструировать исходные данные, даже если один (или небольшое количество) из скрытых провайдеров хранения ненамеренно или намеренно удалит или изменить свои копии данных.
На фиг.16 показана блок-схема, демонстрирующая дополнительные аспекты хранения в связи с сервисом абстрагирования хранения 1610, включающим в себя серверную операционную систему (ОС) 1614, и сервисом хранения 1612, который абстрагирует детали хранения личного облачного хранилища 1600, хранилища 1602 данных SQL, хранилища 1604 простого web-сервиса хранения и т.д. Клиентами могут быть настольные компьютеры 1650 или 1652, имеющие клиентские приложения 1640 и 1642, соответственно. Центр 1620 для генерации ключей может включать в себя приложение 1622 генератора ключей, выполняющееся на серверной ОС 1624. В этой связи, организация 1630, имеющая архивную директорию 1636, серверную ОС 1634 и сервис 1632 маркеров доступа (STS), может быть издателем или абонентом в экосистеме. В этой связи, формат переноса хранилища (STF) - это стандартный формат обмена, который можно использовать для обмена шифрованными данными и метаданными между репозиториями. Например, организация 1630 может пожелать переносить данные электронной почты между провайдерами 1600, 1602 или 1604 сервисов хранения, в каковом случае можно использовать STF.
На фиг.17 показана другая блок-схема, демонстрирующая различных участников в доверенной экосистеме 1720. Как упомянуто, преимущественно, предприятия 1700 могут выгружать хранение и поддержание томов данных с места эксплуатации на провайдеры облачных сервисов хранения, лучше приспособленные для манипулирования такими томами, в то же время, поддерживая комфорт в том, что данные не будут дешифрованы не тем абонентам, поскольку предприятие поддерживает управление возможностями, заданными над шифрованными данными. Например, организация 1702 может пользоваться коллаборативным приложением 1712, например SharePoint. В этой связи, организация 1702 может задавать домен цифрового эскроу, или доверенный домен, для данных SharePoint. Политику 1732 и CKG 1734 можно реализовать посредством первого центра обработки данных 1730, который задает защищенное пространство, задавая информацию криптографических ключей 1745 для доверенного домена.
Затем, другая организация 1704, например, ведущая себя как издатель 1714, может дешифровать данные на основании информации ключей, полученной от CKG 1734, при этом компонент 1742 абстрагирования вычисления и хранения второго центра 1740 обработки данных манипулирует деталями сохранения поисково-шифрованных данных в третьем 1750 центре обработки данных, например, на CSP 1752. С другой стороны, когда абонент 1716 организации 1704 запрашивает данные, информация личного или секретного ключа доставляется абоненту 1716 в порядке извлечения 1765. Затем, на основании информации личного ключа, которая включает в себя возможности, заданные для абонента, данные, запрошенные абонентом, дешифруются на этапе 1775, с учетом привилегий абонента, и, опять же, уровень абстрагирования 1742 манипулирует деталями нижележащего хранения 1752.
На фиг.18 показана схема, представляющая некоторые уровни иллюстративной, неограничительной реализации доверенной системы облачных вычислений, разные части которой могут обеспечиваться разными субъектами или одним и тем же субъектом. В нижней части стека уровней располагаются математические и криптографические библиотеки 1886, используемые для реализации алгоритмов шифрования/дешифрования. Абстрагирование определений различных криптографических схем можно обеспечивать на среднем уровне 1884 между детализированными библиотеками 1886 и фактической реализацией поисковых криптографических схем 1882. Уровни 1882, 1884 и 1886 совместно образуют более крупный уровень 1880 криптографических сервисов, который, при объединении с уровнем абстрагирования 1860 для программного обеспечения в качестве экосистемы сервисных приложений (SaaS), составляет основу реализации доверенного цифрового эскроу 1870 и хранения для него. Уровень абстрагирования 1860 содержит основной язык, используемый для реализации шаблона цифрового эскроу, а именно, команды, например, SetUp(), Encrypt(), Extract(), Decrypt() и т.д.
Поверх уровня абстрагирования 1860 находится уровень 1850, который связывает различные технологии отдельных платформ (например, SDS, Azure, Backup/Archive, RMS, STS и т.д.). Поверх уровня 1850, который связывает различные технологии отдельных платформ, располагаются различные приложения SaaS, использующие доверенное цифровое эскроу 1800. Иллюстративный, неограничительный пример показывает, что приложения 1800 цифрового эскроу могут быть реализованы одиночной компанией 1810 или партнерами 1830, или сообща. Например, компания 1810 может реализовать такие сервисы, как высокопроизводительное вычисление (HPC), eDiscovery и Legal Discovery 1814, сервисы Live 1816 (например, DBox), резервное копирование/архивирование в качестве сервиса 1818, аудиторская запись - бизнес-процесс и мониторинг 1820 или другие облачные сервисы 1822. В свою очередь, партнеры 1830 могут реализовать такие сервисы, как eLetterOfCredit 1832, HPC в качестве сервиса для вертикалей 1834, сервисы eHealth, защищенная экстрасеть 1838, согласование 1840, поддержка судебного процесса 1842 и т.д.
СЦЕНАРИИ НА ОСНОВЕ ЭКОСИСТЕМЫ ДОВЕРЕННЫХ ОБЛАЧНЫХ СЕРВИСОВ
В верхней половине фиг.9 кратко перечислены типы приложений, которые могут быть реализованы в облаке благодаря повышенному доверию, обусловленному разделением генератора ключей, провайдера криптографической технологии и провайдера облачных сервисов. В этой связи, обеспечив такую экосистему доверенных облачных сервисов, можно реализовать совокупность многофункциональных сервисов и сценариев, которые пользуются одним или несколькими из описанных здесь преимуществ доверенной экосистемы.
Например, на фиг.19 приведена логическая блок-схема иллюстративного неограничительного процесса для публикации документов приложению цифрового сейфа с предоставлением издателю возможности управления избирательным доступом к данным посредством динамического связывания, как описано выше. На этапе 1900, устройство аутентифицируется (например, устройство входит с помощью имени пользователя и пароля, парольного мандата, биометрического мандата, мандат Live ID и т.д.). На этапе 1910 происходит выгрузка документа(ов) и ввод тегов. Теги передаются агенту эскроу на этапе 1920, и, в ответ, от агента эскроу принимаются хэшированные теги. В этой связи, теги могут обеспечиваться вышеупомянутым образом или, альтернативно, могут автоматически извлекаться из полезной информации (записи, документа), например, путем полнотекстового индексирования. На этапе 1930 клиент шифрует документы с помощью информации ключей издателя, и документ(ы) поступает(ют), провайдер защищенного цифрового облачного хранения совместно с возможностями для абонентов в отношении документа(ов). На этапе 1940 провайдер защищенного цифрового облачного хранения отправляет шифрованный блоб на сервис хранения, например, в связи с уровнем абстрагирования хранения.
Фиг.20 иллюстрирует фиг.19 применительно к различным участникам доверенной экосистемы, причем этапы фиг.19 указаны в схеме. В этой связи, начиная с мандата 2000 клиента 2010, выполняется этап 1900. Затем этап 1910 выполняется на клиенте 2010. Затем, этап передачи тегов агенту эскроу 2020 и приема хэшированных тегов, представленный на этапе 1920. Затем клиент 2010 шифрует документы и отправляет их на сервис 2030 цифрового сейфа, как показано на этапе 1930. Наконец, шифрованный блоб передается на сервис хранения 2040, как представлено на этапе 1940. Затем абоненту может быть предоставлен доступ к подмножеству пользователя, если возможности, переданные с документом(ами), или выгруженные позднее, разрешают это.
На фиг.21 показана логическая блок-схема иллюстративного, неограничительного процесса для оформления подписки на материалы, помещенные в цифровой сейф. На этапе 2100, абонент аутентифицируется, и устройство-клиент отправляет теги агенту эскроу, который, в ответ, отправляет обратно хэшированные теги на этапе 2110. Затем клиент отправляет хэшированные теги на сервис цифрового сейфа на этапе 2120, и хэшированные теги интерпретируются для определения, на этапе 2130, уполномочен ли клиент выполнять, полностью или частично, свой поисковый запрос с помощью сервиса хранения.
На фиг.22 представлены этапы фиг.21, применительно к участникам, аналогичным показанными на фиг.11: клиенту 2210 и его мандату 2200 для этапа 2100, клиенту 2210 и агенту эскроу 2220 для этапа 2110, клиенту 2210 и сервису цифрового сейфа 2230 для этапа 2120 и сервису 2230 цифрового сейфа и сервису хранения 2240 для этапа 2130.
На фиг.20 и 22, агентом эскроу 2020, 2220 может быть CKG или компонент CKG. Альтернативно, агентом эскроу 2020, 2220 может быть экземпляр CKG, находящийся в распоряжении отдельного участника, благодаря чему, агент эскроу 2020, 2220 является доверенным субъектом, который выполняет шифрование/дешифрование от имени клиента. В этой связи, компромиссы, касающиеся конструкции, и взаимоотношения участников могут определять функцию и область действия агента эскроу 2020, 2220. Например, для тонких клиентов, передающих клиентские функции доверенному прокси-сервису, может потребоваться осуществлять большие объемы обработки.
На фиг.23 показана иллюстративная неограничительная реализация доверенных облачных сервисов с использованием шаблона цифрового эскроу для реализации защищенной экстрасети предприятия посредством одного или нескольких центров обработки данных. Как упомянуто, доверенная вычислительная экосистема может включать в себя центр 2300 для генерации ключей, реализованный отдельно от провайдера 2310 криптографической технологии (CTP), который обеспечивает опорные реализации для использования в реализации криптографических методов, согласующихся с экосистемой, которые реализуются отдельно от одного или нескольких провайдеров облачных сервисов (CSP) 2320. В иллюстративной неограничительной реализации защищенной экстрасети, 2380 указывает, что предприятие поддерживает общественный репозиторий 2370 (например, SharePoint) и репозиторий 2360 приложений конструирования или анализа для использования в связи с документами в общественном репозитории 2370. Коммерческое программное обеспечение 2340 (например, Sentinel) может отслеживать производительность приложения или сервера и т.п. для компьютера, имеющего рабочий стол 2350.
В этой связи, в экосистеме доверенных облачных сервисов, когда абонент, с использованием настольного компьютера 2350, ищет в хранилище избирательно доступную и зашифрованную информацию, сервис 2330 маркеров доступа может доставлять некоторую информацию для идентификации абонента 2382, и CKG 2300 может консультироваться через интерфейсы уровня CKG 2302 первого центра обработки данных, обозначенные 2384. CKG 2300 возвращает информацию ключей, которую затем можно использовать для избирательного доступа к данным, обозначенного 2386, поддерживаемым сервисом данных 2324, через сервис абстрагирования хранения 2322. Таким образом, данные любого типа можно обобществлять в масштабах предприятия и избирательно согласно ролям абонентов на предприятии.
На фиг.24 показана логическая блок-схема, демонстрирующая другой иллюстративный неограничительный сценарий на основе экосистемы доверенных облачных сервисов, в котором абоненту предоставляется избирательный доступ к шифрованным данным, сохраняемым посредством CSP, например, на предприятии. Первоначально абонентское устройство не получает никаких привилегий доступа к шифрованным данным. Однако, запрашивая некоторые или все шифрованные данные, например, путем взаимодействия с приложением, на этапе 2400, приложение автоматически связывается с соответствующим STS для получения требований (в терминологии криптографии) на этапе 2410. На этапе 2420, приложение связывается с CKG для получения информации ключей, которая кодирует информацию о возможностях для абонента (возможности иногда именуются секретами в терминологии криптографии, хотя термин «возможности» не ограничивается контекстом, в котором обычно встречается термин «секрет»). Наконец, приложение предоставляет CSP информацию ключей на этапе 2430, которая разрешает поиски или запросы по шифрованным данным в объеме, отвечающем возможностям абонента.
На фиг.25 показана другая логическая блок-схема, демонстрирующая, что ответ приложения можно подстраивать под абонента на основании информации регистрации. Например, на этапе 2500, приложение принимает информацию ID пользователя. На этапе 2510 приложение получает соответствующие требования от STS. На этапе 2520, на основании одной или нескольких ролей, взятых на себя пользователем, связанным с информацией ID пользователя, впечатления можно регулировать в соответствии с привилегиями/ограничениями для этих ролей. Например, впечатления пользователя, создаваемые при представлении обзора шифрованных данных компании финансовому директору компании, могут и должны отличаться от впечатлений пользователя, создаваемых при представлении обзора шифрованных данных компании служащему отдела корреспонденции. На фиг.25 применима схема к сценариям входа одного или одновременно нескольких лиц.
На фиг.26 показана другая логическая блок-схема, демонстрирующая сценарий защищенной выгрузки записи, который можно реализовать для одной стороны или нескольких сторон. На этапе 2600 приложение принимает запись и ключевые слова, например, обеспеченные или указанные пользователем устройства с приложением. На этапе 2610 приложение получает открытый главный ключ (MPK) и применяет алгоритм(ы) шифрования с открытым ключом и поиском по ключевому слову (PEKS). Приложение может, в необязательном порядке, кэшировать MPK. На этапе 2620 приложение вводит шифрованную запись в репозиторий CSP, например, через уровень абстрагирования хранения.
На фиг.27 показана еще одна логическая блок-схема, демонстрирующая иллюстративную неограничительную реализацию ролевого опроса хранилища поисково-шифрованных данных, обеспеченного экосистемой доверенных облачных сервисов, например, для автоматического поиска, осуществляемого одной стороной. На этапе 2700 приложение принимает или инициирует конъюнктивный запрос. На этапе 2710 приложение получает соответствующие требования от STS. Например, STS отображает роль(и) пользователя в соответствующую(ие) группу(ы) запросов и возвращает множество законных запросов для данной(ых) роли(ей). На этапе 2720 приложение подает фильтрованное требование и запрос, что позволяет эффективно подавать требование(я), которое(ые) соответствует(ют) запросу, а не все требования. В необязательном порядке, CKG возвращает приложению требование(я) секрета (или отвергает требования). На этапе 2730 приложение выполняет требования секрета на удаленных индексах. На основании обработки удаленных индексов, результаты принимаются и могут представляться приложением пользователю, например, с использованием специализированного представления на основании роли(ей) пользователя.
На фиг.28 показана блок-схема реализации экосистемы доверенных облачных сервисов между предприятием 2820, CKG 2810 и CSP 2800, в которой вышеописанные этапы, показанные на фиг.24-27, указаны теми же условными обозначениями. Сценарии начинаются с того, что пользователь 2824 идентифицирует себя приложению 2822. STS 2826 действует для установления доверия 2830 в связи с обменом информацией с CKG 2810, возвращая информацию ключей приложению 2822 для использования в шифровании или дешифровании данных от CSP 2800 в зависимости от целей сценария.
На фиг.29 показана логическая блок-схема, демонстрирующая сценарий кооперации нескольких сторон, где предприятие предоставляет внешнему предприятию доступ к некоторым своим шифрованным данным. Например, производитель может предоставить поставщику доступ к некоторым своим данным, хранящимся в доверенном облаке, или наоборот. В этой связи, на этапе 2900, STS предприятия 2 указывается как провайдер ресурсов, и приложение предприятия 1 переходит к получению требований для доступа к ресурсам, обеспечиваемым провайдером ресурсов в облаке. На этапе 2910 STS предприятие 1 указывается как провайдер идентификации. В этой связи, приложение получает требования для роли или набора ролей, заданных абонентом на предприятии 1, с помощью провайдера идентификации. На этапе 2920 приложение выявляет требования на основании допустимых ресурсов, управляемых предприятием 2, и на основании разрешений/возможностей, заданных ролью(ями) абонентской сущности. Хотя на фиг.29 показан только один STS, следует отметить, что в цифровом эскроу или федеративном оверлее доверия может существовать несколько STS провайдера идентификации и/или несколько STS провайдера ресурсов.
На фиг.30 показана логическая блок-схема, демонстрирующая сценарий автоматического поиска, осуществляемого несколькими сторонами, например, среди множественных предприятий, например, предприятия 1 и предприятия 2. На этапе 3000 конъюнктивный запрос принимается или инициируется приложением предприятия 1 для выполнения. На этапе 3010 приложение получает соответствующие требования от STS провайдера ресурсов (предприятия 2). Провайдер ресурсов, в необязательном порядке, может быть указан в теге организации. STS может, в необязательном порядке, осуществлять отображение роли пользователя в группы запросов, чтобы множество законных запросов возвращалось для роли пользователя. На этапе 3020 приложение подает фильтрованное требование и запрос на основании роли пользователя, что позволяет эффективно подавать требования, которые соответствуют запросу, а не все требования. В необязательном порядке, CKG возвращает приложению возможности (например, требования секрета), или же CKG отвергает требования. На этапе 3030 приложение выполняет требования секрета на удаленных индексах. На основании обработки удаленных индексов, результаты принимаются и могут представляться приложением пользователю, например, с использованием специализированного представления на основании роли(ей) пользователя.
Согласно фиг.27 и 30, способ включает в себя этап, на котором принимают конъюнктивный запрос или иначе инициируют конъюнктивный запрос. В этой связи, в необязательном порядке, конъюнктивные запросы также могут быть криптографически защищены, чтобы ни один получатель секрета (или возможности), будь то клиент или провайдер сервисов, не мог разложить конъюнктивный запрос и определить его составные части.
На фиг.31 показана блок-схема реализации экосистемы доверенных облачных сервисов среди предприятий 3120, 3130, CKG 3110 и CSP 3100, в которой вышеописанные этапы, показанные на фиг.20-21, указаны теми же условными обозначениями. Например, пользователь 3124 может идентифицировать себя приложению 3122. STS 3126 предприятия 3120 и STS 3132 предприятия 3130 кооперируются для установления доверия 3130 в связи с обменом информацией с CKG 3110, возвращая информацию ключей приложению 3122 для использования в шифровании или дешифровании данных из CSP 3100 в зависимости от целей сценария.
Фиг.32 иллюстрирует иллюстративную неограничительную технологию краевой вычислительной сети (ECN), которую можно реализовать для доверенного облачного сервиса. В этой связи, совокупность узлов динамического вычисления 3270, 3272, 3274, 3276 динамически выделяется для формирования объема вычислительных ресурсов в связи с набором доверенных облачных компонентов, действующих независимо друг от друга. Например, центр 3220 для генерации ключей, сервис абстрагирования хранения 3210, организацию 3230 и организацию 3240 можно реализовать указанным образом для охвата многоорганизационных коммерческих или других сценариев, например, описанных выше. Центр 3220 для генерации ключей включает в себя генератор 3222 ключей и серверную ОС 3224. Сервис абстрагирования хранения 3210 включает в себя компонент 3212 сервиса хранения и серверную ОС 3214. Организация 3230 включает в себя STS 3232, AD 3236 и серверную ОС 3234. Организация 3240 включает в себя STS 3234, AD 3246 и серверную ОС 3244. Серверные ОС 3214, 3224, 3234, 3244 совместно реализуют ECN между серверами. Любой провайдер хранения или абстрагирования 3202 можно использовать для хранения данных, например, можно использовать сервисы данных SQL. Таким образом, один или несколько настольных компьютеров 3250, 3252 могут публиковать данные или подписываться на них через клиентские приложения 3260, 3262, соответственно.
На фиг.33 показана блок-схема, демонстрирующая один или несколько дополнительных аспектов центра для генерации ключей 3310 согласно экосистеме доверенных облачных сервисов. Первоначально, набор вычислительных устройств, например настольных компьютеров 3360, 3362 и соответствующих клиентских приложений 3370, 3372, или сервисы или серверы 3374, 3376, 3378 и т.д., являются потенциальными издателями и/или абонентами облачных сетей 3350 доставки контента. Однако до удовлетворения запросов от любого из набора вычислительных устройств, центр для генерации ключей первоначально действует как хранитель доверия для издателей, шифрующих данные на основании открытого ключа и передающих личные ключи абонентам данных на основании их возможностей.
В иллюстративном неограничительном взаимодействии, первоначально подается 3300 запрос от вычислительного устройства, и держатель CKG 3310 запрашивает экземпляр CKG 3310 у фабрики 3302 CKG на этапе 3380. Затем, на этапе 3382, осуществляется аутентификация 3304 пользователя. Затем можно применять любой биллинг 3384 с учетом пользования с помощью биллинговой системы 3306 для использования фабрики 3302 CKG. Затем, на этапе 3386, фабрика 3302 CKG материализует абонентский CKG, который может включать в себя компонент 3312 доставки MPK, загрузчик 3314 клиентских библиотек, экстрактор 3316 секретного ключа и валидатор/верификатор 3318 доверия.
Компонент 3312 доставки MPK доставляет MPK в CDN 3350 на этапе 3388. Загрузчик 3314 клиентских библиотек загружает на запрашивающие клиенты криптографические библиотеки, которые можно использовать в связи с шифрованием публикуемых данных или дешифрованием данных, на которые подписано устройство. Затем, клиент делает запрос на извлечение данного набора документов на основании информации ключей, принятой от экстрактора 3316 секретного ключа, который действует совместно с верификатором доверия 3318, который может подтвердить, что абонент располагает определенными возможностями на основании верификации идентификационного признака STS абонента на этапе 3394, например, осуществляя связь с разными STS 3320, 3322, 3324, 3326 организаций, участвующих в запросе. Как и в других вариантах осуществления, может быть предусмотрен сервис абстрагирования хранения 3340 для абстрагирования деталей хранения сервисов 3330 базы данных (например, SQL).
На фиг.34 показана блок-схема иллюстративного неограничительного варианта осуществления доверенного хранилища 3400, включающего в себя поисково-шифрованные данные 3410 с валидизацией и/или верификацией, в связи с доставкой сетевых сервисов 3420. В этом варианте осуществления, абонент 3440 или приложение, используемое абонентом 3440, может запрашивать, в порядке запроса доступа к определенным частям шифрованного хранилища 3400, чтобы доказательство валидизации пробегало по элементам, возвращаемым из запроса, для подтверждения, что фактически принятые элементы являются также элементами, которые должны были быть приняты. В этой связи, на фиг.34 показано сочетание методов поискового шифрования с методами валидизации. В необязательном порядке, система также может быть объединена с идентификацией на основе требований и управлением доступом, согласно описанным здесь другим вариантам осуществления. В этой связи, шаблон цифрового эскроу, также именуемый федеративным оверлеем доверия, согласно описанным здесь другим вариантам осуществления, может органично объединяться с более традиционными системами аутентификации на основе требований.
Согласно фиг.34, доверенное хранилище данных 3400 или провайдер сервисов, или держатель хранилища данных осуществляет этап доказательства, тогда как владелец данных (например, абонентское устройство) осуществляет валидизацию. Хранилище данных 3400 является доверенным, поскольку пользователи могут быть уверены в том, что оно обеспечивает сильные гарантии, хотя понятно, что в действительности эти данные находятся в распоряжении физических субъектов, и некоторые участники являются не полностью доверенными.
На фиг.35 показана логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для оформления подписки, включающий в себя этап валидизации. На этапе 3500, от абонентского устройства принимается подмножество поисково-шифрованных данных. На этапе 3510, информация криптографических ключей генерируется из экземпляра генерации ключей, который генерирует информацию криптографических ключей на основании информации идентификации абонентского устройства. На этапе 3520, подмножество шифрованных данных дешифруется как функция возможностей, предоставленных абонентскому устройству, указанному в информации криптографических ключей. На этапе 3530, элементы, представленные в подмножестве, могут проходить валидизацию (например, доказательство владения данными), и к данным осуществляется доступ на этапе 3540.
Во многих случаях желательно иметь возможность выполнять PDP/POR над шифрованными данными без необходимости дешифровать их. В необязательном порядке, информация ключей, необходимая для PDP, может кодироваться в метаданных, защищенных посредством поискового шифрования. Хотя это эффективный способ управления ключами, используемыми для PDP/POR, заметим, что существует много высокоценных сценариев, где PDP/POR может осуществляться на шифрованных данных без необходимости осуществлять доступ к содержанию открытого текста.
На фиг.36 представлен иллюстративный неограничительный протокол вызова/ответа валидизации, в котором верификатор 3600 (например, владелец данных) выдает криптографический вызов 3620 пруверу 3610 (например, провайдеру сервисов данных). Приняв вызов 3620, прувер 3610 вычисляет ответ как функцию данных и вызова 3612. Затем ответ 3630 на вызов возвращается верификатору 3600, который осуществляет вычисление для проверки или доказательства, что данные не были изменены 3602.
Валидизация, в целом проиллюстрированная на фиг.36, известна как личное PDP, хотя стоит заметить, что существует также “открытая” версия, где третье лицо снабжается ключом (“открытым” ключом), что позволяет третьему лицу действовать как верификатор согласно аналогичному протоколу, без необходимости знать что-либо о фактических данных. POR, пример верификации, отличается от PDP тем, что оно обеспечивает доказательство того, что данные подлежат восстановлению (несмотря ни на какие повреждения/модификации), но, как проиллюстрировано ниже на фиг.30, базовый протокол один и тот же, хотя структура документов и фактические алгоритмы отличаются. Различные реализации доверенной экосистемы объединяют поисковое шифрование и POR/PDP для усовершенствования системы и укрепления доверия. В этой связи, до передачи данных провайдеру сервисов, данные подвергаются поисковому шифрованию, и постобработка данных может включать в себя POR и/или PDP.
Кроме того, метод “дисперсии данных” может, в необязательном порядке, дополнять один или несколько из вышеприведенных вариантов осуществления, если необходимо предоставить еще более сильные гарантии. Благодаря дисперсии данных, данные распределяются по нескольким провайдерам сервисов для повышения устойчивости к “массовым противозаконным действиям” или катастрофической потере на любом отдельном провайдере сервисов. С использованием описанных здесь механизмов доверия, эта дисперсия осуществляется таким образом, чтобы затруднить для независимых провайдеров сервисов участие в сговоре и повреждение данных. Это принципиально аналогично вышеописанному варианту осуществления распределенного CKG.
На фиг.37 показана блок-схема другого иллюстративного неограничительного варианта осуществления доверенного хранилища 2500, включающего в себя поисково-шифрованные данные 2510 с валидизацией и/или верификацией, в связи с доставкой сетевых сервисов 2520. В частности, на фиг.37 показан компонент 3750 верификации для проверки, не были ли элементы, возвращенные абонентам 2540, подделаны или иным образом непреднамеренно изменены. Вышеупомянутое PDP является неограничительным примером верификации.
На фиг.38 показана логическая блок-схема, демонстрирующая иллюстративный неограничительный процесс для оформления подписки, включающий в себя этап валидизации. На этапе 3800 подмножество поисково-шифрованных данных принимается от абонентского устройства. На этапе 3810 информация криптографических ключей генерируется из экземпляра генерации ключей, который генерирует информацию криптографических ключей на основании информации идентификации абонентского устройства. На этапе 3820 подмножество шифрованных данных дешифруется как функция возможностей, предоставленных абонентскому устройству, указанному в информации криптографических ключей. На этапе 3830 контент элементов, представленных в подмножестве, можно верифицировать (например, посредством доказательства восстановимости), и к данным осуществляется доступ на этапе 3840.
На фиг.39 представлен иллюстративный неограничительный протокол вызова/ответа верификации, в котором верификатор 3900 (например, владелец данных) выдает криптографический вызов 3920 пруверу 3910 (например, провайдеру сервисов данных). Приняв вызов 3920, прувер 3910 вычисляет ответ как функцию данных и вызова 3912. Затем ответ на вызов 3930 возвращается верификатору 3900, который осуществляет вычисление для проверки или доказательства, что данные подлежат восстановлению 3902.
На фиг.40 показана блок-схема, демонстрирующая неограничительный сценарий, где множественные, независимые федеративные оверлеи доверия или цифровые эскроу могут существовать рядом друг с другом, или один поверх другого в многослойном подходе. В этом сценарии, существует доверенное хранилище данных 4000, имеющее поисково-шифрованные данные 4010, на которых можно объявлять различные сетевые сервисы 4020. Например, сетевые сервисы 4020 могут включать в себя доставку программного обеспечения текстового редактора в качестве облачного сервиса. В порядке геораспределения или, иначе, в необязательном порядке, можно обеспечить множественные оверлеи/эскроу 4032, 4034, 4036, настроенные на разные приложения/вертикали/потребности согласования/требования к самостоятельному субъекту, так что издатели 2530 или абоненты 4050 выбирают, явно или неявно, правильный оверлей/эскроу, в котором участвовать, например, на основании набора требований или области юрисдикции/ местожительства. Оверлей, таким образом, может изменяться, но скрытые сервисы из облака могут оставаться одними и теми же, не усложняя доставку самого по себе базового сервиса.
Здесь описан ряд иллюстративных, неограничительных вариантов осуществления, которые иллюстрируют доставку доверенных сервисов данных. Эти варианты осуществления на самостоятельны, но допускают объединение друг с другом в случае необходимости. Кроме того, любой из вышеописанных вариантов осуществления можно расширить несколькими альтернативными способами. Например, в одном варианте осуществления, доверенные сервисы данных предусматривают срок действия и аннулирование секретов или возможностей для повышения безопасности доступа к данным. В другом необязательном варианте осуществления, уровень управления правами встраивается в обеспечение доверенных сервисов данных, например, для сохранения прав, присоединенных к контенту в порядке шифрования/дешифрования, или для предотвращения действий в отношении данных, охраняемых авторским правом, в цифровом эскроу, которые легче распознать или обнаружить вне подозрений. Соответственно, любые комбинации или перестановки описанных здесь вариантов осуществления следует считать находящимися в объеме изобретения.
ИЛЛЮСТРАТИВНАЯ НЕОГРАНИЧИТЕЛЬНАЯ РЕАЛИЗАЦИЯ
Иллюстративная реализация шаблона цифрового эскроу именуется федеративным оверлеем доверия (FTO). В Приложении A приведены некоторые дополнительные неограничительные детали реализаций FTO.
В этой связи, шаблон цифрового эскроу является просто примером многих возможных шаблонов и вариаций. Кроме того, этот шаблон (который предусматривает участие издателей, абонентов, администраторов и аудиторов - и, возможно, других особых ролей, описанных выше) является шаблоном более высокого уровня по отношению к шаблону FTO, который осуществляет разделение CTP, CSP, CKG и т.д., наподобие отделения церкви от государства, для поддержания доверия. Также могут существовать множественные независимые FTO и DEP, которые могут сосуществовать, не мешая друг другу, и даже не зная о существовании друг друга. Кроме того, возможно наложение шаблонов DEP и FTO на облачное хранение без кооперации с провайдером сервисов облачного хранения, или даже узнавания о существовании набора сервисов, независимых от сервисов данных в облаке.
В частности, FTO представляет собой набор сервисов, который не зависит от сервисов данных в облаке. Эти сервисы эксплуатируются сторонами, отличными от оператора сервисов данных, и способны обеспечивать сильные гарантии, касающиеся конфиденциальности, обнаружения вмешательства и неаннулирования для данных, находящихся в ведении облачных сервисов.
Любой партнер может построить и поддерживать эти оверлейные сервисы, например, посреднический сервис, сервис валидизации, сервис абстрагирования хранения и т.д. Эти партнеры могут по своему выбору принять опорную реализацию или построить свою собственную реализацию на основании общедоступных форматов и протоколов.
В силу открытого характера форматов, протоколов и опорных реализаций, было бы целесообразно поддерживать разделение управления между сторонами, например, операторами FTO и владельцами данных.
Хотя шифрование является элементом этого решения, координация сервисов, которые консолидированы между разными сторонами, также является частью этого решения. Хотя традиционные методы шифрования незаменимы для многих сценариев, они препятствуют осуществлению многих сценариев, например, обнаружения вмешательства, неаннулирования, формирования доверительных отношений за счет привлечения множественных (недоверенных) сервисов, поиска в репозиториях данных и т.д.
ВСПОМОГАТЕЛЬНЫЙ КОНТЕКСТ
Для некоторого дополнительного неограничительного контекста, как описано выше, доверенный набор облачных предложений обеспечивает экосистему приложений для облака, построенного на доверии. Различные термины, употребляемые здесь, включают в себя: CKG-центр для генерации ключей, субъект, в распоряжении которого находится центр генерации ключей для множественных абонентов, например, распоряжаться CKG может Microsoft, VeriSign, Fidelity, самостоятельный субъект, предприятие, субъект согласования и т.д. В этой связи, многоабонентность является необязательной (например, желательной, но не обязательной). Другие термины включают в себя: CTP-провайдер криптографической технологии, субъект, который обеспечивает технологии шифрования для использования в доверенной экосистеме, например, компании, которые могут быть CTP, включают в себя Symantec, Certicom, Voltage, PGP Corp, BitArmor, предприятие, Guardian, самостоятельный субъект и т.д.
Кроме того, термин CSP-провайдер облачных сервисов это субъект, который обеспечивает облачные сервисы, в том числе хранение. Ряд компаний может обеспечивать такие сервисы данных. CIV-валидатор облачного индекса это второй репозиторий для удостоверения возвращаемых индексов. CSA-абстрагирование вычисления и хранения абстрагирует серверное приложение хранения. STF-формат переноса хранилища это универсальный формат для переноса данных/метаданных между репозиториями.
В этой связи, как упомянуто, некоторый(е) сценарий(и) предприятия включает(ют) в себя инженерную экстрасеть, использующую технологии или приложения сервиса данных, конструкторский и инженерный анализ, задание взаимоотношений производителя и поставщика(ов) в связи с данными и т.д. Таким образом, обеспечивается уникальная экосистема для целого ряда сценариев за счет распределения доверия между множественными субъектами, что не допускает существования 'сверх' доверенного субъекта или единичной точки компрометации.
В отношении некоторого вспомогательного контекста, касающегося поискового шифрования, пользователь обычно имеет или получает 'возможности' или 'секреты' для ключевого(ых) слова (или слов), после чего отправляет запрос с использованием 'возможностей', представляющих его серверу. Сервер 'комбинирует' возможности и индексы для отыскания релевантных документов или данных. Затем пользователю предоставляется доступ только к документам, составляющим результат поиска (хотя пользователь может иметь доступ не только к этим документам).
Как упомянуто, никакой отдельно взятый алгоритм не следует рассматривать в порядке ограничения, налагаемого на описанное здесь обеспечение хранилища поисково-шифрованных данных, однако ниже в общих чертах обрисованы некоторые теоретические основы иллюстративного неограничительного алгоритма и приведена базовая схема для шаблона поискового симметричного шифрования (SSE):
• Сообщение: m
• Ключевые слова: w 1 ,…,w n
• PRF: H
• Генерация ключа эскроу
• Выбрать случайное S для H
• Шифрование
• Выбрать случайный ключ K
• Выбрать случайное r фиксированной длины
• Для 1 ≤ i ≤ n
Вычислить ai = HS(wi)
Вычислить bi = Hai(r)
Вычислить ci = bi ⊕ flag
Вывести (EK(m), r, c1,...,cn)
• генерация секрета или возможности для w
• d = HSj(w)
• Тестирование для w
• Вычислить p = Hd(r)
• Вычислить z = p ⊕ ci
• Вывести “истина”, если z = flag
• Дешифровать EK(m) для получения m
Хотя, опять же, никакой из описанных здесь вариантов осуществления не рассматривается в порядке ограничения, ниже приведена базовая схема шаблона шифрование с открытым ключом с поиском по ключевому слову (PEKS).
Шифрование с открытым ключом
a. PKE = (Gen, Enc, Dec)
Шифрование на основе идентификации
b. IBE = (Gen, Enc, Extract, Dec)
c. Генерация главных ключей
i. (msk, mpk) = IBE.Gen()
d. Шифрование m для ID
i. c = IBE.Enc(mpk, ID, m)
e. Генерация секретного ключа для ID
i. sk = IBE.Extract(msk, ID)
f. Дешифрование
i. m=IBE.Dec(sk, c)
g. Сообщение: m
h. Ключевые слова: w 1 ,…,w n
i. Генерация ключей эскроу
i. (msk, mpk) = IBE.Gen()
ii. (pk,sk) = PKE.Gen()
j. Шифрование
k. Для 1≤i≤n
i. ci = IBE.Enc(mpk, wi, flag)
l. Возвратить (PKE.Enc(pk,m),c1,…,cn)
m. Генерация возможности или секрета для w
i. d = IBE.Extract(msk, w)
n. Тестирование для w
o. Для 1≤i≤ n
i. z = IBE.Dec(d, ci)
ii. Вывести “истина”, если z = flag
Дешифровать EK(m) для получения m
ИЛЛЮСТРАТИВНЫЕ СЕТЕВЫЕ И РАСПРЕДЕЛЕННЫЕ СРЕДЫ
Специалисту в данной области техники очевидно, что различные варианты осуществления способов и устройств для инфраструктуры доверенных облачных сервисов и связанные с ними варианты осуществления, описанные здесь, можно реализовать в связи с любым компьютером или другим клиентским или серверным устройством, которое может быть обеспечено как часть компьютерной сети или в распределенной вычислительной среде и может быть подключено к хранилищу данных любого рода. В этой связи, различные описанные здесь варианты осуществления можно реализовать в любой компьютерной системе или среде, имеющей любое количество блоков памяти или запоминающих устройств и любое количество приложений и процессов, выполняющихся на любом количестве запоминающих устройств. Эта среда включает в себя, но без ограничения, среду, где компьютеры-серверы и компьютеры-клиенты обеспечены в сетевой среде или в распределенной вычислительной среде, имеющей удаленное или локальное хранилище.
На фиг.41 показана неограничительная схема иллюстративной сетевой или распределенной вычислительной среды. Распределенная вычислительная среда содержит вычислительные объекты 4110, 4112 и т.д., и вычислительные объекты или устройства 4120, 4122, 4124, 4126, 4128 и т.д., которые могут включать в себя программы, способы, хранилища данных, программируемые логические устройства, и т.д., представленные приложениями 4130, 4132, 4134, 4136, 4138. Очевидно, что объекты 4110, 4112 и т.д., и вычислительные объекты или устройства 4120, 4122, 4124, 4126, 4128 и т.д., могут содержать разные устройства, например, КПК, аудио/видео устройства, мобильные телефоны, MP3-плееры, портативные компьютеры и т.д.
Каждый из объектов 4110, 4112 и т.д. и вычислительных объектов или устройств 4120, 4122, 4124, 4126, 4128 и т.д. может осуществлять связь с одним или несколькими другими объектами 4110, 4112 и т.д. и вычислительными объектами или устройствами 4120, 4122, 4124, 4126, 4128 и т.д., посредством сети связи 4140, прямо или косвенно. Хотя на фиг.41 показан один элемент, сеть 4140 могут содержать другие вычислительные объекты и вычислительные устройства, которые обеспечивают сервисы для системы, показанной на фиг.41, и/или могут представлять множественные взаимосвязанные сети, которые не показаны. Каждый объект 4110, 4112 и т.д. или 4120, 4122, 4124, 4126, 4128 и т.д. также может содержать приложение, например приложения 4130, 4132, 4134, 4136, 4138, которые могут использовать API, или другой объект, программное обеспечение, программно-аппаратное обеспечение и/или оборудование, пригодное для связи с или реализации доверенного облачного вычислительного сервиса или приложения, обеспеченного согласно различным вариантам осуществления.
Существует ряд систем, компонентов и сетевых конфигураций, которые поддерживают распределенные вычислительные среды. Например, вычислительные системы могут быть соединены друг с другом проводными или беспроводными системами, локальными сетями или глобальными сетями. В настоящее время, многие сети подключены к интернету, который обеспечивает инфраструктуру для широко распределенных вычислений и охватывает большое количество различных сетей, хотя любую сетевую инфраструктуру можно использовать для иллюстративных средств связи, присущих методам, описанным в различных вариантах осуществления.
Таким образом, можно использовать разнообразные сетевые топологии и сетевые инфраструктуры, например, клиентско-серверную, одноранговую или смешанную архитектуры. В клиентско-серверной архитектуре, в частности, в сетевой системе, клиент обычно представляет собой компьютер, который осуществляет доступ к обобществленным сетевым ресурсам, обеспечиваемым другим компьютером, например, сервером. Как показано на фиг.41, в порядке неограничительного примера, компьютеры 4120, 4122, 4124, 4126, 4128 и т.д. можно рассматривать как клиенты, и компьютеры 4110, 4112 и т.д. можно рассматривать как серверы, причем серверы 4110, 4112 и т.д. обеспечивают сервисы данных, например, прием данных от компьютеров-клиентов 4120, 4122, 4124, 4126, 4128 и т.д., хранение данных, обработку данных, передачу данных на компьютеры-клиенты 4120, 4122, 4124, 4126, 4128 и т.д., хотя любой компьютер может считаться клиентом, сервером или обоими сразу, в зависимости от обстоятельств. Любое из этих вычислительных устройств может обрабатывать данные или запрашивать сервисы или задания, которые могут предусматривать улучшенное формирование профиля пользователя и связанные с этим методы, описанные здесь для одного или нескольких вариантов осуществления.
Сервером обычно является удаленная компьютерная система, доступная по глобальной или локальной сети, например, интернету или посредством беспроводных сетевых инфраструктур. Клиентский процесс может быть активным в первой компьютерной системе, и серверный процесс может быть активным во второй компьютерной системе, которые осуществляют связь друг с другом с помощью среды связи, таким образом, обеспечивая распределенную функциональность и позволяя множественным клиентам пользоваться возможностями сбора информации, которыми располагает сервер. Любые объекты программного обеспечения, используемые в соответствии с формированием профиля пользователя, могут обеспечиваться автономно или распределяться по множественным вычислительным устройствам или объектам.
В сетевой среде, где сетью/шиной связи 4140 является интернет, например, серверы 4110, 4112 и т.д., могут быть web-серверами, с которыми клиенты 4120, 4122, 4124, 4126, 4128 и т.д. осуществляют связь по любому из разнообразных известных протоколов, например, протоколу передачи гипертекстовых файлов (HTTP). Серверы 4110, 4112 и т.д. также могут выступать в качестве клиентов 4120, 4122, 4124, 4126, 4128 и т.д., что может служить характеристикой распределенной вычислительной среды.
ИЛЛЮСТРАТИВНОЕ ВЫЧИСЛИТЕЛЬНОЕ УСТРОЙСТВО
Как упомянуто, различные описанные здесь варианты осуществления применяются к любому устройству, в котором может быть желательно реализовать инфраструктуру доверенных облачных сервисов или отдельные ее части. Поэтому следует понимать, что карманные, портативные и другие вычислительные устройства и вычислительные объекты всех видов можно использовать в связи с различными описанными здесь вариантами осуществления, т.е. везде, где устройство может обеспечивать те или иные функции в связи с инфраструктурой доверенных облачных сервисов. Соответственно, удаленный компьютер общего назначения, описанный ниже на фиг.42, является лишь одним примером, и варианты осуществления изобретения можно реализовать с любым клиентом, имеющим возможность взаимодействия по сети/шине.
Хотя это не требуется, любой из вариантов осуществления можно частично реализовать посредством операционной системы, для использования разработчиком сервисов для устройства или объекта, и/или включить в прикладное программное обеспечение, которое выполняется в связи с действующим(и) компонентом(ами). Программное обеспечение можно описать в общем контексте компьютерно-выполняемых инструкций, например, программных модулей, выполняемых одним или несколькими компьютерами, например, клиентскими рабочими станциями, серверами или другими устройствами. Специалистам в данной области техники очевидно, что сетевые взаимодействия можно осуществлять на практике посредством ряда конфигураций компьютерной системы и протоколов.
На фиг.42, таким образом, приведен пример подходящей среды вычислительной системы 4200, в которой можно реализовать один или несколько из вариантов осуществления, хотя, как следует из вышесказанного, среда вычислительной системы 4200 является лишь одним примером подходящей вычислительной среды и не призвана налагать каких-либо ограничений ни на объем использования, ни на функциональность какого-либо из вариантов осуществления. Вычислительную среду 4200 также не следует рассматривать как имеющую какую-либо зависимость или требование, связанное с каким-либо одним или комбинацией компонентов, представленных в иллюстративной операционной среде 4200.
Согласно фиг.42, иллюстративное удаленное устройство для реализации одного или нескольких вариантов осуществления может включать в себя вычислительное устройство общего назначения в виде карманного компьютера 4210. Компоненты карманного компьютера 4210 могут включать в себя, но без ограничения, процессор 4220, системную память 4230 и системную шину 4221, которая подключает различные компоненты системы, в том числе системную память, к процессору 4220.
Компьютер 4210 обычно включает в себя ряд компьютерно-считываемых носителей, которые могут представлять собой любые доступные носители, к которым компьютер 4210 может осуществлять доступ. Системная память 4230 может включать в себя компьютерные запоминающие устройства в форме энергозависимой и/или энергонезависимой памяти, например, постоянной памяти (ПЗУ) и/или оперативной памяти (ОЗУ). В порядке примера, но не ограничения, память 4230 также может включать в себя операционную систему, прикладные программы, другие программные модули и программные данные.
Пользователь может вводить команды и информацию в компьютер 4210 через устройства ввода 4240. Монитор или иного рода устройство отображения также подключен к системной шине 4221 через интерфейс, например, выходной интерфейс 4250. Помимо монитора, компьютеры также могут включать в себя другие периферийные устройства вывода, например, громкоговорители и принтер, которые могут быть подключены через выходной интерфейс 4250.
Компьютер 4210 может действовать в сетевой или распределенной среде с использованием логических соединений с одним или несколькими другими удаленными компьютерами, например удаленным компьютером 4270. Удаленный компьютер 4270 может представлять собой персональный компьютер, сервер, маршрутизатор, сетевой ПК, равноправное устройство или другой общий сетевой узел, или любое другое удаленное устройство потребления и передачи медиа, и может включать в себя какие-либо или все элементы, описанные выше применительно к компьютеру 4210. Логические соединения, указанные на фиг.42, включают в себя сеть 4271, например локальную сеть (LAN) или глобальную сеть (WAN), но также могут включать в себя другие сети/шины. Такие сетевые среды получили широкое распространение в виде домашних, офисных, корпоративных компьютерных сетей, интрасетей и интернета.
Как упомянуто выше, хотя иллюстративные варианты осуществления были описаны в связи с различными вычислительными устройствами, сетями и рекламными архитектурами, основные концепции можно применять к любой сетевой системе и любому вычислительному устройству или системе, в которой желательно обеспечить доверие в связи с взаимодействиями с облачным сервисом.
Существуют разные пути реализации одного или нескольких из описанных здесь вариантов осуществления, например, соответствующий API, инструментарий, код драйвера, операционная система, управление, автономный или загружаемый объект программного обеспечения и т.д., который позволяет приложениям и сервисам использовать инфраструктуру доверенных облачных сервисов. Варианты осуществления можно рассматривать с точки зрения API (или другого объекта программного обеспечения), а также объекта программного обеспечения или оборудования, который обеспечивает указание сервисов платформы согласно одному или нескольким из описанных вариантов осуществления. Различные описанные здесь реализации и варианты осуществления могут иметь аспекты, воплощенные полностью в оборудовании, частично в оборудовании и частично в программном обеспечении, а также в программном обеспечении.
Слово “иллюстративный” используется здесь в смысле «служащий примером, экземпляром или иллюстрацией». В целях исключения неоднозначного толкования, раскрытое здесь изобретение не ограничивается такими примерами. Кроме того, никакой(ую) аспект или конструкцию, описанный(ую) здесь как “иллюстративный(ая)”, не следует рассматривать как имеющий(ую) приоритет или преимущество над другими аспектами или конструкциями, а также в смысле отрицания эквивалентных иллюстративных структур и методов, известных специалисту в данной области техники. Кроме того, в той степени, в которой термины “включает в себя”, “имеет”, “содержит” и другие аналогичные слова употребляются в подробном описании или формуле изобретения, в целях исключения неоднозначного толкования, такие термины следует понимать во включительном смысле аналогично термину “содержащий” в качестве открытого переходного слова, без отрицания каких-либо дополнительных или иных элементов.
Как упомянуто, различные описанные здесь методы можно реализовать в связи с оборудованием или программным обеспечением или, при необходимости, их комбинацией. Употребляемые здесь термины “компонент”, “система” и т.п. в равной степени относятся к компьютерному субъекту, в частности, к оборудованию, сочетанию оборудования и программного обеспечения, программному обеспечению или выполняющемуся программному обеспечению. Например, компонентом может быть, но без ограничения, процесс, выполняющийся на процессоре, процессор, объект, выполнимый модуль, поток выполнения, программа и/или компьютер. В порядке иллюстрации, компонентом может быть как приложение, выполняющееся на компьютере, так и компьютер. Один или несколько компонентов могут размещаться в процессе и/или потоке выполнения, и компонент может располагаться на одном компьютере и/или распределяться между двумя или более компьютерами.
Вышеупомянутые системы были описаны в отношении взаимодействия между несколькими компонентами. Очевидно, что такие системы и компоненты могут включать в себя эти компоненты или указанные подкомпоненты, некоторые из указанных компонентов или подкомпонентов и/или дополнительные компоненты, и согласно различным перестановкам и комбинациям вышеперечисленного. Подкомпоненты также можно реализовать как компоненты, подключенные с возможностью связи к другим компонентам, а не входящие в состав родительских компонентов (в иерархическом порядке). Дополнительно, следует заметить, что один или несколько компонентов можно объединять в один компонент, обеспечивая совокупную функциональность, или делить на несколько отдельных подкомпонентов, и любой один или несколько промежуточных уровней, например, уровень управления, можно предусмотреть для подключения с возможностью связи к таким подкомпонентам для обеспечения объединенной функциональности. Любые описанные здесь компоненты также могут взаимодействовать с одним или несколькими другими компонентами, конкретно не описанными здесь, но, в общем случае, известными специалистам в данной области техники.
В связи с вышеописанными иллюстративными системами, способы, которые можно реализовать согласно раскрытому изобретению, можно лучше понять, обратившись к логическим блок-схемам, приведенным на различных фигурах. Хотя в целях простоты объяснения, способы показаны и описаны в виде последовательности блоков, очевидно, что заявленное изобретение не ограничивается указанным порядком следования блоков, поскольку некоторые блоки могут выполняться в другом порядке и/или одновременно с другими блоками, в отличие от указанного и описанного здесь. В случае, когда непоследовательный, или разветвленный, процесс иллюстрируется посредством логической блок-схемы, очевидно, что можно реализовать различные разветвления, последовательности выполнения и порядки следования блоков, которые позволяют добиться такого же или аналогичного результата. Кроме того, не все проиллюстрированные блоки могут потребоваться для реализации описанных ниже способов.
Хотя в некоторых вариантах осуществления проиллюстрированы действия со стороны клиента, следует понимать, в целях исключения неоднозначного толкования, что можно вести рассмотрение со стороны соответствующего сервера, или наоборот. Аналогично, при практическом осуществлении способа, можно обеспечить соответствующее устройство, имеющее хранилище и, по меньшей мере, один процессор, приспособленное для практического осуществления этого способа посредством одного или нескольких компонентов.
Хотя различные варианты осуществления были описаны в связи с предпочтительными вариантами осуществления, представленными на различных фигурах, следует понимать, что можно использовать другие аналогичные варианты осуществления или модификации, и что описанный вариант осуществления можно дополнять для осуществления той же функции без отхода от нее. Кроме того, один или несколько аспектов вышеописанных вариантов осуществления можно реализовать на совокупности микросхем или устройств обработки, и хранение можно аналогично осуществлять на совокупности устройств. Таким образом, настоящее изобретение не подлежит ограничению каким-либо одним вариантом осуществления, но подлежит рассмотрению в рамках и объеме, указанных нижеследующей формулой изобретения.
Изобретение относится к защищенному и конфиденциальному хранению и обработке резервных копий. Технический результат заключается в повышении безопасности хранения данных. В способе принимают, посредством по меньшей мере одного вычислительного устройства в первой области управления от по меньшей мере одного вычислительного устройства во второй области управления, шифрованные данные, сформированные путем шифрования данных полной резервной копии для заданного набора данных по меньшей мере одного вычислительного устройства во второй области управления согласно по меньшей мере одному алгоритму поискового шифрования на основе информации криптографических ключей, принимают, посредством по меньшей мере одного вычислительного устройства в первой области управления от по меньшей мере одного вычислительного устройства во второй области управления, шифрованные метаданные, сформированные путем анализа данных полной резервной копии и шифрования выхода анализа на основании информации криптографических ключей, принимают данные секрета, позволяющие осуществлять видимый доступ к шифрованным данным, заданным по меньшей мере одним криптографическим секретом данных секрета, и поддерживают данные синтетической полной резервной копии для заданного набора данных на основании шифрованных данных, шифрованных метаданных и данных секрета. 3 н. и 12 з.п. ф-лы, 42 ил.
1. Способ управления данными резервной копии, содержащий этапы, на которых
принимают 400, посредством по меньшей мере одного вычислительного устройства в первой области управления от по меньшей мере одного вычислительного устройства во второй области управления, шифрованные данные, сформированные путем шифрования данных полной резервной копии для заданного набора данных по меньшей мере одного вычислительного устройства во второй области управления согласно по меньшей мере одному алгоритму поискового шифрования на основе информации криптографических ключей,
принимают 410, посредством по меньшей мере одного вычислительного устройства в первой области управления от по меньшей мере одного вычислительного устройства во второй области управления, шифрованные метаданные, сформированные путем анализа данных полной резервной копии и шифрования выхода анализа на основании информации криптографических ключей,
принимают 420 данные секрета, позволяющие осуществлять видимый доступ к шифрованным данным, заданным по меньшей мере одним криптографическим секретом данных секрета, и
поддерживают 430 данные синтетической полной резервной копии для заданного набора данных на основании шифрованных данных, шифрованных метаданных и данных секрета.
2. Способ по п.1, дополнительно содержащий этап, на котором
принимают 400 шифрованные данные инкремента, сформированные путем шифрования данных инкрементной резервной копии для заданного набора данных согласно по меньшей мере одному алгоритму поискового шифрования на основании информации криптографических ключей.
3. Способ по п.2, в котором на этапе приема 400 принимают шифрованные данные инкремента, сформированные из по меньшей мере одной записи, сгенерированной по меньшей мере одним вычислительным устройством во второй области управления, причем эта по меньшей мере одна запись генерируется после самой последней операции полного резервного копирования или инкрементного резервного копирования.
4. Способ по п.2, дополнительно содержащий этап, на котором
принимают 400 шифрованные метаданные инкремента, сформированные путем анализа данных инкрементной резервной копии и шифрования выхода анализа на основании информации криптографических ключей.
5. Способ по п.2, дополнительно содержащий этап, на котором
принимают 400 данные секрета инкремента, позволяющие осуществлять видимый доступ к шифрованным данным инкремента, заданным по меньшей мере одним криптографическим секретом данных секрета инкремента.
6. Способ по п.5, дополнительно содержащий этап, на котором
осуществляют доступ 1240 к шифрованным данным инкремента и шифрованным метаданным инкремента с помощью данных секрета.
7. Способ по п.1, дополнительно содержащий этапы, на которых
принимают 600 запрос на восстановление по меньшей мере одного элемента данных из заданного набора данных,
принимают 610 по меньшей мере один секрет для извлечения по меньшей мере одного элемента данных из шифрованных данных.
8. Способ публикации данных резервной копии, содержащий этапы, на которых
инициируют 500, посредством по меньшей мере одного вычислительного устройства в первой области управления, полное резервное копирование первичных данных, хранящихся в памяти по меньшей мере одного вычислительного устройства, для формирования данных полной резервной копии, причем данные полной резервной копии используются для поддержания данных синтетической полной резервной копии для первичных данных по меньшей мере одним удаленным вычислительным устройством во второй области управления,
генерируют 510 структурные метаданные на основании обхода первичных данных,
шифруют 520 первичные данные и структурные метаданные для формирования шифрованных данных и шифрованных метаданных согласно по меньшей мере одному алгоритму поискового шифрования на основании информации криптографических ключей, принятой от генератора ключей, который генерирует информацию криптографических ключей, и
генерируют 530 по меньшей мере один криптографический секрет на основании информации криптографических ключей, позволяющий совершать обход шифрованных данных, заданных по меньшей мере одним криптографическим секретом.
9. Способ по п.8, в котором на этапе шифрования 520 шифруют первичные данные в режиме сохранения размера.
10. Способ по п.8, в котором на этапе генерации 530 по меньшей мере одного криптографического секрета разрешают по меньшей мере одному удаленному вычислительному устройству использовать по меньшей мере один криптографический секрет для обхода шифрованных метаданных.
11. Способ по п.8, в котором на этапе генерации 530 по меньшей мере одного криптографического секрета разрешают по меньшей мере одному удаленному вычислительному устройству использовать по меньшей мере один криптографический секрет для обхода шифрованных данных.
12. Способ по п.8, дополнительно содержащий этап, на котором
передают 710 шифрованные данные и шифрованные метаданные провайдеру сетевых сервисов, включающему в себя по меньшей мере одно удаленное вычислительное устройство.
13. Способ по п.8, дополнительно содержащий этап, на котором
передают 710 по меньшей мере один криптографический секрет провайдеру сетевых сервисов, включающему в себя по меньшей мере одно удаленное вычислительное устройство.
14. Способ по п.8, дополнительно содержащий этап, на котором
передают 710 шифрованные данные провайдеру сетевых сервисов, включающему в себя по меньшей мере одно удаленное вычислительное устройство, применяющее по меньшей мере один алгоритм для сокращения дублирования данных, хранящихся как на по меньшей мере одном вычислительном устройстве, так и на по меньшей мере одном удаленном устройстве.
15. Способ оформления подписки на данные резервной копии, содержащий этапы, на которых
запрашивают 900 восстановление по меньшей мере одного элемента данных из набора данных по меньшей мере одного абонентского вычислительного устройства из сервиса данных резервного копирования, доступного через по меньшей мере одну сеть, который поддерживает данные синтетической полной резервной копии, соответствующие набору данных в поисково-шифрованном формате для сервиса синтетического полного резервного копирования сервисом данных резервного копирования,
принимают 910 по меньшей мере один элемент данных в поисково-шифрованном формате, и
на основании информации криптографических ключей, используемых для шифрования набора данных, доступного по меньшей мере одному абонентскому устройству, восстанавливают 920 по меньшей мере один элемент из набора данных в памяти по меньшей мере одного абонентского вычислительного устройства.
| Приспособление для точного наложения листов бумаги при снятии оттисков | 1922 |
|
SU6A1 |
| СПОСОБ ЗАПИСИ, СПОСОБ УПРАВЛЕНИЯ И УСТРОЙСТВО ДЛЯ ЗАПИСИ | 2000 |
|
RU2242805C2 |
| Приспособление для точного наложения листов бумаги при снятии оттисков | 1922 |
|
SU6A1 |
| Способ обработки целлюлозных материалов, с целью тонкого измельчения или переведения в коллоидальный раствор | 1923 |
|
SU2005A1 |
