За все время существования облачных сервисов произошло несколько больших сбоев в работе, которые оказались серьезной угрозой для пользовательских данных. В книге приводится пример двух длительных сбоев в работе облачного провайдера Amazon S3 в 2008 году, первый длительностью 2,5 часа в Феврале, и второй - 8 часов в Июле того же года. Даже несмотря на то, что AWS (Amazon Web Services) является наиболее зрелым облачным провайдером, такие длительные сбои возможны и в таких случаях безопасность и сохранность данных пользователей стоит под вопросом.

На международной конференции по информационной безопасности (RSA conference) в Марте 2016 года организация Cloud Security Alliance (CSA) выделила 12 самых серьезных угроз облачной безопасности [10] :

1. Утечка данных

2. Взлом учетных записей и обход аутентификации

3. Кража учетных записей

4. Уязвимость используемых систем

5. Кража учетных записей

6. Инсайдеры-злоумышленники

7. Целевые кибератаки

8. Перманентная потеря данных

9. Недостаточная осведомленность

10. Злоупотребление облачными сервисами

11. DDoS-атаки

12. Совместные технологии, общие риски

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

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

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

1.2 Блокчейн и децентрализация - будущее облачного хранилища данных

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

Рисунок 2 Централизованная и распределенная сеть.

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

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

Один из соучредителей проекта децентрализованного хранилища данных SIA Дэйвид Ворик (David Vorick) в своем блоге рассказывает о случае длительного выхода из строя сервиса Amazon S3. Первая версия SIA была выпущена в день выхода их строя Amazon S3, что в результате не позволило пользователям скачать новый релиз продукта SIA. SIA является децентрализованной облачной платформой для хранения данных, которая стремится конкурировать с существующими системами хранения данных. Вместо аренды хранилища у централизованного провайдера, пиры (peers) на SIA арендуют хранилище друг у друга. SIA сама только хранит в блокчейне контракты хранения, сформированные между сторонами, определяя условия их договоренности [11], [42]. Продолжая рассказ о случае отказа в работе Amazon S3 28 февраля 2017 года Дейвид утверждает, что децентрализованные системы невосприимчивы к такому типу простоя. Это происходит по причине того, что нет центральной системы, нет единого ПО, управляющего системой, нет главного узла, который выдавал бы неисправные или злонамеренные команды. По настоящему децентрализованная система не может быть выведена из строя из-за ошибочных действий одного человека, так как она разработана с расчётом на то, что несколько участников сети могут внезапно атаковать ее с полной силой в любое время. И вправду существующий проект децентрализованного хранилища основанного на технологии Блокчейн SIA работает именно по такому принципу. На сегодняшний день у SIA 85 хостов, работающих под управлением различных операционных систем, как Windows, OS X, многих разновидностей Linux и FreeBSD. Хосты находятся на 4 континентах и в свою очередь работают с 6 различными версиями (v1.0.0, v1.0.1, v1.0.3, v1.0.4, v1.1.0, v1.1.1), все за совершенно разными сетевыми настройками. Все это координируется с помощью блокчейна, который сам по себе очень трудно снести, но даже если злоумышленнику удастся сбить работу блокчейна, узлы смогут продолжить загрузку и скачивание через существующие контракты [12]. У каждого человека свой контракт с различными хостами и схемами резервирования данных для каждого релиза сервиса. По мнению Дэйвида длительный простой в работе возможен только при очень тщательно спланированной аттаке, что по мнению автора является практически невозможным. Дэйвид Ворик подчеркивает, что предпосылкой децентрализованной сети является отсутствие единой точки отказа. И на самом деле цель концепции децентрализованного хранилища состоит в том, что одновременно десятки вещей могут пойти не так, но данные проблемы не должны вызывать заметных замедлений или простоев в работе, не подвергая риску ничьи данные, ни деньги [13].

Также, одним из многообещающих проектов децентрализованного хранилища на основе технологии блокчейн является Storj. Шон Вилкинсон и Джим Лоури (Shawn Wilkinson, Jim Lowry) в работах «Metadisk: Blockchain-Based Decentralized File Storage Application» и «Storj A Peer-to-Peer Cloud Storage Network» представили полное описание децентрализованной сети Storj и пользовательского интерфейса Metadisk, который позволяет загрузку и скачивание файлов из сети Storj [14]. Storj является проектом c открытым исходным кодом, стремящимся показать, что приложения облачного хранения могут быть более децентрализованными, более безопасными и тем самым более эффективными. В рамках проекта Storj создана сеть из пользователей, которые сдают свободное место на своем жестком диске и получают вознаграждение в виде криптовалюты. Storj - это реестр, который создает распределенную сеть для формирования и исполнения контрактов хранения между пирами. Storj позволяет узлам в сети согласовывать контракты, передавать данные, проверять целостность и доступность удаленных данных, извлекать данные и платить другим узлам за предоставленное место для хранения [15]. Проект был впервые представлен в 2014 году, выпустив свой первый документ (Whitepaper, 2014) и до выхода из бета-версии в 2017 году количество пользователей превысило 300 тысяч. Второй документ был выпущен основателями проекта в 2016 году с поправками в отношении кодирования и резервирования данных, беря во внимание, что на данный момент в системе Storj используется простое зеркалирование, как способ резервирования. С выходом второго документа учредителям компании Storj было объявлено, что в будущем в систему будет внедрена схема резервирования данных посредством удаляющего кодирования по Риду-Соломну, что судя по многочисленным источникам, включая Erasure Coding for Cloud Storage Systems: A Survey (Jun Li and Baochun Li), является наиболее эффективным способом резервирования, обеспечивающую наименьшую вероятность потери данных [16]

Наряду с проектами SIA и Storj существует так же и немало обещающий проект MaidSafe. Как и Storj и SIA, данный проект состоит из двух составляющих - распределенной децентрализованной сети и клиентского приложения. MaidSafe также является проектом с открытым исходным кодом и полное его описание приведено его соучредителями Ником Ламберт и Бенджамином Боллен в документах «The SAFE Network a New, Decentralised Internet». Ник и Бенджамин в своем документе подчеркивают 3 главные характеристик, которые облачного хранения, которые стали возможными в случае использования технологии Блокчейн [17] :

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

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

3. Низкая стоимость хранения. Стоимость хранения в хранилище, основанном на блокчейне значительно ниже, чем хранение в традиционном облачном хранилище.

Система MaidSAFE, как и Storj и SIA, явяется полностью децентрализованной, лишенной центрального сервера, пиринговой сетью, которая создана из пользователей, предоставляющих свободное место собственных жестких дисков, и тех, кто за это место готов заплатить криптовалютой SafeCoin. Узлы в сети SafeNetwork не только хранят данные, но и выполняют особые операции по поддержанию целостности узлов-соседей и частей данных. SafeNetwork подразумевает создание групп близких узлов-соседей и «круги движения» для поддержания непрерывной доступности файлов при прекращении работы одного из узлов. Все узлы в группе подчиняются особым правилам-алгоритмам, что существенно снижает недобросовестное поведение, так как попытки несанкционированного доступа к определенному узлу контролируется узлами-соседями. При выходе из строя одного из узлов-соседей, данные будут восстановлены и далее переданы одному из надежных узлов из «кругов движения». На Рисунке 3. Представлена схема динамической среды сети SafeNetwork, в которой серым обозначены узлы из «кругов движения», в то время как узлы B, D, F и L являются узлами-соседями и узел I вышел из сети и заменен узлом L.

Рисунок 3 Узлы динамической децентрализованной сети SafeNetwork

Посредством соблюдения правил формируется ранг каждого узла и при понижении своего статуса узел может быть исключен из сети. SafeNetwork использует собственный алгоритм деления и шифрования на клиентской стороне, а также авторизации пользователей: SelfEncryptingData и SelfAuthentication. Децентрализованное хранилище обеспечивает защищенность данных в аспекте трех проблем облачного хранения: конфиденциальности, путем алгоритмов шифрования и авторизации: SelfEncryptingData и SelfAuthentication; доступность, посредством поддержания избыточности и создания групп соседей-узлов; и целостность путем проверок данных прямо из облака и соблюдения правил сети всех узлов-соседей.

Выводы

В рамках данной главы были выявлены проблемы и угрозы современных решений облачного хранения в отношении защищенности данных. В первом разделе данной главы была рассмотрена книга “Cloud Computing and Privacy” автора Tim Mather, в которой рассмотрены главные проблемы традиционных облачных хранилищ с точки зрения конфиденциальности, целостности и доступности данных:

· Использование провайдером облачной услуги слабых механизмов аутентификации пользователей и недостаточно безопасного контроля авторизации.

· Многие провайдеры облачных услуг используют ненадежные методы шифрования данных или вовсе их не шифруют.

· Облачные инфраструктуры могут не поддерживать методы проверки целостности данных.

· Из-за центализованности хранения информации традиционные облачные хранилища становятся уязвимыми к атакам на уровне сети типа «отказ в обслуживании» - DDoS

· Не существует поставщика облачной услуги, который гарантирует пять «девяток» времени безотказной работы (99,999%)

Также в первом параграфе описаны 12 главных угроз облачного хранения, которые были оглашены на ежегодной конференции по информационной безопасности, которые вытекают из проблем, описанных в книге “Cloud Computing and Privacy” автора Tim Mather:

· Утечка данных

· Взлом учетных записей и обход аутентификации

· Кража учетных записей

· Уязвимость используемых систем

· Кража учетных записей

· Инсайдеры-злоумышленники

· Целевые кибератаки

· Перманентная потеря данных

· Недостаточная осведомленность

· Злоупотребление облачными сервисами

· DDoS-атаки

· Совместные технологии, общие риски

Второй раздел объясняет понятия блокчейна и децентрализации в отношении облачного хранения, а также рассматривает документы существующих решений, как SIA, Storj и MaidSafe.

Глава 2. Анализ модели децентрализованного хранилища, основанного на блокчейне

В рамках данной главы будут рассмотрены инструменты и методы обеспечения информационной безопасности в децентрализованном хранилище данных на основе блокчейна. Первый раздел главы содержит описание процесса обработки данных до их распространения в децентрализованную сеть и рассматривает блокчейн как хранилище метаданных. Второй раздел раскрывает методы обеспечения конфиденциальности, целостности и доступности данных в децентрализованном хранилище на блокчейне. И в свою очередь последний параграф 2.3. содержит сравнительную характеристику двух систем: традиционного облачного хранилища - Dropbox и децентрализованного хранилища на блокчейне - Storj.

2.1 Данные

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

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

Для обеспечения наибольшей безопасности данных следующие шаги должны быть пройдены:

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

2. Деление на части. Зашифрованные файлы делятся на части (shards), либо несколько файлов объединяются для создания одной шарды.

3. Распространение файлов. Файлы в случайном порядке распространяются по сети, наряду с 3 копиями каждого шарда (3 копии хранимых файлов - является стандартом индустрии)

Процесс деления файлов приказан на схеме ниже:

Рисунок 4 Процесс шифрования и деления данных

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

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

2.1.1 Блокчейн - хранилище метаданных

Хранение самих файлов в блокчейне невозможно, так как такой блокчейн достиг бы огромных размеров и сравнительно быстро, его смогли бы обрабатывать только очень мощные компьютеры. Известная проблема “раздутие блокчейна” (“blockchain bloat”) состоит в том, что с ростом транзакций, растет число записей и блокчейн становится настолько большим, что становится очень трудным дальнейшее скачивание и добавление новых записей. Данная проблема решается путем хранения в блокчейне только маленького количества информации о транзакции хранения. Метаданные содержат ключевую информацию о хранимых данных: хэш файла и местоположение резервных копий данных.

Рисунок 5 Запись метаданных в блокчейн

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

Перспективы развития

С ростом использования модели децентрализованного хранилища на блокчейне, возможен переход на такой блокчейн, который хранит корень дерева Меркла. Дерево Меркла - особый способ хранения большого количества данных, которая объединяет части данных в блоки, далее хэширует блоки, затем получившиеся в результате новые хэши объединяются и хэшируются до тех пор, пока не получится корневой хэш. Именно данный корневой хэш и предполагается хранить в блокчейне. Дерево Меркла по своей сути представляет собой бинарное дерево, где каждый блок всегда состоит из двух блоков или хэшей [18]. Используя такой блокчейн, который хранит в себе корневой элемент большого количества элементов данных, позволит доказательство существования миллиона файлов из одной транзакции. Примерная схема блокчейна, хранящего в себе, корневой элемент дерева Меркла показана на Рисунке 4.

Рисунок 6 Блокчейн, хранимый корневой элемент дерева Меркла

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

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

Рисунок 7 Схема модели традиционного облачного хранилища

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

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

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

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

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

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

· Шифрованием данных до трансфера в сеть;

· Делением данных на части;

· Использованием реестра записи транзакций - блокчейна для записи проведенных операций с данными;

· Отказом от третьей доверенной стороны, имеющей контроль над данными пользователей.

Рисунок 8 Модель децентрализованного хранилища данных на блокчейне

Доступность и целостность. В то время как безопасность данных поддерживается с помощью шифрования на стороне пользователя, в то время как целостность и доступность данных поддерживается проверкой на восстановление фалов (proof-of-retrievability) [19]. Проверка на восстановление является наиболее надежным математическим методом проверки состояния данных «прямо из облака». Доказательства восстановимости данных гарантируют существование определенных частей файла на удаленном хосте. В ходе доказательства о хранении, один узел предоставляет другому уникальный хэш хранимого файла, с помощью чего проверяется проводились ли какие-либо итерации с файлом [20]. Таким образом, второй узел может убедиться в целостности и доступности файла. В случае, если источник данных не проходит проверку восстановимости, данные могут быть восстановлены из ближайшего узла, хранящего одну из 3 копий нужного файла.

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

Рисунок 9 Проверка восстановимости данных

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

2.3 Сравнение Dropbox и Storj

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

Критерии сравнения:

1. Одноранговое подключение - Как подключаются одноранговые узлы, где хранятся данные пользователя, как пользователи обмениваются сообщениями и какие сообщения обмениваются?

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

2. Шифрование - Происходит ли шифрование данных и связи между узлами? Какой криптографический алгоритм используется?

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

3. Доверие и целостность. - Как устанавливается доверие между пирами? Как файлы и связь между пирами защищены от несанкционированного доступа и умышленных атак?

Данный критерий определяет уровень доверия между пирами, а также существование механизмов проверки целостности данных на предмет каких-либо несанкционированных итераций с файлами.

4. Схема оплаты - Является ли система бесплатной или платной? Кому платят пиры и при каких обстоятельствах?

Чем система дешевле, тем больше шансов, что пользователь выберет именно данную систему.

5. Справедливость - Как распределяется файловая нагрузка между участниками сети?

Распределение файлов между пирами должно производится сбалансированно, так как перегрузка файлами одного из узла сети нежелательна, так как может привести к проблеме одиночной точки отказа.

6. Отказоустойчивость и доступность - Каким образом гарантируется непрерывная доступность файлов в любое время?

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

7. Предоставление услуг - Является ли система только библиотекой или также и специализированным программным клиентом?

Данный критерий характеризует простоту использование пользовательского интерфейса, а также возможность построения своего приложения поверх данной система для продвинутых пользователей.

8. Доступность исходного кода - Имеет ли данная система открытый или закрытый исходный код?

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

9. Пользовательская база - Сколько пользователей на данный момент имеет система? Предназначена ли система только для частных пользователей или предприятий?

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

10. Состояние - В каком состоянии находится система? Доступна ли она для использования?

Система должна быть доступна для использования или, по крайней мере, доступной в ближайшем будущем.

2.3.1 Dropbox

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

Подключение к сети хранения: Dropbox не является пиринговой системой в отличии от Storj, а системой типа клиент-сервер. Данные хранятся в облаке Amazon S3.

Шифрование: Данные пользователей шифруются с помощью криптографического алгоритма AES-256, загрузка и скачивание файлов также зашифрованы. Критическим моментом является тот факт, что все ключи дешифрования Dropbox хранит на своих серверах, тем самым администраторы имеют представление о хранимых данных.

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

Схема оплаты: Dropbox использует модель Freemium, в которой базовое использование является бесплатным, но больше места для хранения можно получить, оформив платную подписку:

· Dropbox Basic - бесплатно - 2 ГБ

· Dropbox Pro - 10 евро / месяц - 1 ТБ

· Dropbox для бизнеса - 12 евро / месяц - неограниченно

Справедливость: Критерии справедливости не применимы к Dropbox, так как все пользовательские файлы хранятся на серверах системы Dropbox.

Отказоустойчивость и доступность: Серверы Dropbox являются уязвимыми местами в связи с «централизованностью» хранения.