Конфиденциальность облачных вычислений за счёт использования резервных сетевых хранилищ

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

Проблемы конфиденциальности облачных вычислений

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

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

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

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

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

Протокол

Общее описание

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

1. На вход системы хранения предоставляется файл, разбитый на множество сегментов.
2. Подразумевается, что провайдер будет следовать условиям протокола, хотя и может пытаться просматривать полученные элементы данных.
3. Используемый сервис хранения и обработки данных в облаке имеет большую клиентскую базу.
4. У пользователя есть малозатратный механизм аутентификации, используемый для контроля доступа к данным.
5. Протокол подразумевает наличие управляющего узла, который будет распределять сегменты данных между провайдерами облачных хранилищ. Далее (C&C от англ. Command & Control).
6. C&C узел получает доступ к публичным ключам провайдера, а так же обрабатывает входные и запрашиваемые данные.
7. Подразумевается, что C&C узел не скомпрометирован
8. Пользователь ведет учет любых невыполненных запросов, отправленных на C&C узел и отклоняет любой незапрошенный ответ.

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

Клиент передает на вход C&C узла свои данные. Затем управляющий узел разбивает их на сегменты, которые впоследствии распределяются между доступными облачными хранилищами и передаются туда через смешанную криптографическую сеть (mix-net). Обратный процесс происходит по схожему сценарию, за исключением того, что помимо сегментов данных, запрашиваемых клиентом, на управляющий узел приходят ложные элементы. Этот механизм усложняет перехват истинных сегментов. Далее управляющий узел отбрасывает элементы, чьи идентификаторы не совпадают с табличными значениями и, используя записи «ID элемента — ID соседнего элемента», выстраивает сегменты в исходном порядке. После этого полученные данные передаются пользователю.

Схема работы протокола

Схема подразумевает использование смешанной криптографической сети в облаке и агентов-обработчиков. Агенты поддерживают отношения формата «один к одному» с облачными хранилищами. Каждый агент имеет ID, который, в принципе, не должен позволять С&С узлу обнаружить этого агента. Далее необходимо сконфигурировать облачный сервис, который может работать в режиме широковещания, подобно IRC каналу. В дальнейшем будем называть такой сервис IRC-узел. Подробная схема приведена ниже:

Протокол для хранения данных

Пусть D — фрагмент данных, который нужно разделить и загрузить в облачные хранилища. Некоторый пользователь U отправляет данные D на С&С узел, шифруя их открытым ключом С&С узла K_C&C.

U → C&C : {store−full, Auth, IDD, D} KC&C

• store-full — командна, предписывающая управляющему узлу сохранить данные в облако
• Auth — информация, аутентифицирующая право пользователя на владение данных D
• IDD — идентификатор данных D
• D — данные
• KC&C — ключ шифрования всего сообщения для его передачи от пользователя C&C узлу

Данное сообщение игнорируется узлом С&С при переотправке. Занятый идентификатор выделенный для входных данных можно переиспользовать только после удаления этих данных.

С&С узел производит разделение данных на сегменты, генерируя последовательность H = <D_S,R_S>, где

• DS = {di | i = 1,...,n} — разбиение данных D на n фрагментов d_i
• RS = {< di, di+1 >| i = 1,...,n-1} — список пар соседних элементов

Последовательность R_S указывает, каким образом соотносятся сегменты оригинальных данных, без этой информации собрать исходные данные невозможно. В результирующей последовательности H = {d1, d2, ..., dn} каждому элементу данных d_i присваивается идентификатор ID_di . Далее, С&С узел распределяет эту последовательность между провайдерами облачных хранилищ, сопоставляя идентификатор каждого провайдера соответствующему элементу данных.

(CSx,...,CSy) → (d1,...,dn)

• CSx - идентификатор провайдера Sx (предполагается, что система использует несколько провайдеров для большей надежности)
• di - фрагмент данных

Доставка фрагментов данных происходит через смешанную криптографическую сеть на IRC узел. С&С узел должен сохранять таблицу соответствий между элементами данных и облачными сервисами, на которые эти элементы были отправлены. Более того, необходимо обеспечить уникальность всех идентификаторов фрагментов данных, причем каждый идентификатор должен быть выбран таким образом, чтобы нельзя было по двум таким идентификаторам определить принадлежность этих элементов к одним и тем же исходным данным. Одно из условий успешной работы алгоритма подразумевает большое количество пользователей и большой трафик, что приведет к тому, что большую часть сообщений, отправленных в случайном порядке и от разных пользователей, будет невозможно упорядочить и соотнести друг с другом. Таким образом, при эффективной передаче таблиц соответствия, открытость данных для перехвата не приведёт к их утере: потенциальный злоумышленник может видеть, что фрагмент c идентификатором X направлен в облачное хранилище с идентификатором Y, но не имеет возможности связать конкретный фрагмент с исходными данными D или с определенным пользователем. Наконец, использование смешанных сетей приведет к тому, что идентификатор провайдера сетевого хранилища будет неотличим от идентификатора фрагмента данных.

Формат MIX-NET

Предполагаем, что имеется набор из n независимых сетевых узлов {m1,...,mn}. Каждый из них исполняет роль облачного сервиса, и их публичные ключи шифрования и адреса известны С&С узлу. Рассмотрим маршрут сообщения от узла B к узлу А в сети с одним агентом m₁ :

• B → m1 : {Rm, m1, A, {Ra, A, store, di, CSj}KA}Km1 - сообщение от узла В агенту m₁ , зашифрованное с использованием ключа K_m1
• m1 → A : {Ra, A, store, di, CSj} KA - сообщение от узла m₁ узлу А, зашифрованное с использованием ключа K_A

расшифровка обозначений:

• Rm , Ra - одноразовые случайные числа, отбрасываемые узлом получателем в момент получения
• store - команда, предписывающая облачному хранилищу сохранить полученный элемент данных d_i
• CSj - параметр, указывающий на узел-получатель и ассоциированное с ним облачное хранилище

Случайные числа R_{m ,} R_a используются в качестве защиты от отправки идентичных сообщений. Рекурсивно применяя данную схему инкапсуляции, можно получить смешанную сеть с произвольным количеством узлов.

IRC узел

IRC узел получает большое количество фрагментов данных в общем случае от большого количества С&С узлов (в противном случае нет смысла в mix-net сетях). В каждом сообщении содержится параметр CS_j , идентифицирующий агента, который должен обработать данный фрагмент. IRC узел отправляет поочерёдно все сообщения в широковещательном формате агентам.

Агент хранения

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

Возвращение данных пользователю

Когда пользователь U запрашивает сохраненные данные D, на C&C узел приходит следующее сообщение:

U → C&C : {retrieve−full, Auth, IDD } KC&C

• retrieve−full - команда, предписывающая управляющему узлу вернуть данные D пользователю U

Далее управляющий узел через IRC узел обращается к каждому облачному хранилищу, где находятся фрагменты данных. Заметим, что при запросе конкретного фрагмента данных, не нужна аутентификация пользователя. Однако просто запустить процесс сохранения данных в обратную сторону не представляется возможным, так как в этом случае злоумышленник сможет сопоставить идентификатор хранилища с его адресом. Вместо этого С&С узел отправит команду «поиск фрагментов данных» на каждый IRC узел и передаст ему идентификаторы всех фрагментов. Чтобы усложнить потенциальному злоумышленнику анализ передаваемой информации, IRC узел дополнит список запрашиваемых идентификаторов фальшивими, которые в дальнейшем будут отброшены.

Затем агенты облачных хранилищ предадут запрошенные сегменты, а так же случайные фрагменты данных, не относящиеся к данным пользователя. Фальшивые данные будут переданы, даже если агент хранения не найдет у себя фрагментов, соответствующих запрашиваемым идентификаторам. Данные из облачных хранилищ через соответствующих агентов передаются обратно на IRC узел через смешанную сеть (MIX-NET).

IRC узел в свою очередь отправляет найденные фрагменты на С&С узел опять же через MIX-NET.

∀i|IRC → C&C : mix({CSj , return−part, IDdi , di }) - сообщение от IRC узла C&C узлу, содержащее i-й фрагмент данных

• mix({...}) — сообщение, переданное через смешанную сеть
• return−part - команда, предписывающая IRC узлу вернуть данные d_i управляющему узлу (C&C)

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

C&C → U : {U, return−full, IDD , D} KU

• return−full - команда, предписывающая C&C узлу вернуть восстановленные данные D пользователю U

Вычисления в облаке

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

U → C&C : {process−cnc, operation, Auth, IDD , Nu } KC&C

• process−cnc — команда, предписывающая С&C произвести операцию operation над данными D

Аналогично предыдущему пункту, необходимые данные передаются из облачных хранилищ на управляемый узел, собираются воедино и перенаправляются вычислительным облачным провайдерам. С&C узел, опираясь на формат данных, выбирает оптимальное количество облачных вычислительных узлов.

C&C → CPj : mix({{CPj , process−cp, operation, D, Kpc , Nc } Kcpj })

• CPj — один из используемых вычислительных узлов
• KPc — симметричный ключ шифрования результата вычислений
• Kcpj — открытый ключ шифрования вычислительного узла
• process−cp — команда, предписывающая CPj произвести операцию operation над данными D

После вычислений результат отправляется обратно на управляющий узел через смешанную сеть (MIX-NET). А C&C узел в свою очередь пересылает результат пользователю:

CPj → C&C : mix({{result−cnc, Dresult , Nc } KPC })

C&C → U : {U, result−user, Dresult , Nu } KU

Литература

1. Zhao G, Rong C, Jaatun MG, Sandnes F Reference deployment models for eliminating user concerns on cloud security.
2. Chen Y, Paxson V, Katz RH What’s new about cloud computing security? Technical Report UCB/EECS-2010-5
3. Jaatun MG, Nyre ÅA, Alapnes S, Zhao G A Farewell to, Trust: An Approach to Confidentiality Control in the Cloud.
4. Zhao G, Rong C, Jaatun MG, Sandnes F Deployment Models: Towards Eliminating Security Concerns from Cloud Computing.
5. Jensen M, Schwenk J, Gruschka N, Iacono LL On Technical Security Issues in Cloud Computing.
6. Martin G Jaatun , G Zhao , Athanasios V Vasilakos , Åsmund Ahlmann Nyre, Stian Alapnes, Yong Tang The design of a redundant array of independent net-storages for improved confidentiality in cloud computing