Модель «клиентского шифрования» набирает популярность

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

На протяжении некоторого времени эта схема работала без «побочных эффектов», но это время прошло. Череда взломов крупных и хорошо защищенных (по крайней мере, мы так думаем) сервисов продемонстрировала, что непреодолимой защиты не существует. Но это только часть проблемы.

Если рассматривать опасность с точки зрения потенциального «пятна контакта» – пользователей, чьи данные могут оказаться под угрозой похищения, то наибольшую угрозу будет представлять даже не взлом какого-то конкретного сервиса, а компрометация сервис-провайдера, услугами которого он пользуется. Ведь далеко не все сервисы располагают собственным аппаратным обеспечением – многие сервисы, в свою очередь, являются клиентами AWS, Azure и так далее. Максима про яйца и корзины очень доходчиво поясняет рискованность такого подхода. Если взлом сервиса раскрывает данные его клиентов, то взлом провайдера раскрывает данные всех сервисов, которые пользуются его услугами. Например, когда был взломан веб-сервис поддержки клиентов Zendesk, потенциально могли быть раскрыты данные всех его партнеров, в частности Twitter, Tumblr и Pinterest.

О корзинах и матрешках


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

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

Именно по такому принципу работает система безопасности файлообменного сервиса Mega – последнего проекта Кима Доткома и облачного сервиса SpiderOak. Оба они конкурируют с Dropbox, но SpiderOak был запущен гораздо раньше Mega, хотя и не привлекал такого внимания. Именно сотрудники SpiderOak разработали Crypton – open-source проект, который предоставляет готовый набор инструментов для внедрения этого типа шифрования в приложения.

Дай человеку удочку...


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

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

Впрочем, пока что фреймворк не рекомендуется использовать для «боевых» систем – он еще не прошел полный экспертный анализ. Однако в ближайшее время анализ будет завершен, и платформа будет доступна разработчикам.

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

Впрочем, Crypton – это не единственная попытка разграничить контроль над данными в веб-приложениях. Компания Least Authority предлагает инструменты для шифрования данных, хранимых в облаке Amazon S3. Другая компания, Unhosted, предлагает разделять веб-приложение и хранилище данных. Скажем, пакет офисных веб-приложений может размещаться на одном сервере, но хранить данные на другом, желательно – принадлежащем другой организации. Если будет взломан сервер на котором размещены приложения, данные пользователей будут в безопасности.

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

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

Впрочем, разработчики Crypton осознают трудность стоящей перед ними задачи, и не пытаются откусить больше чем смогут проглотить. В частности, обеспечение надежного шифрования исключительно средствами браузера – непростая задача, с которой сталкивались еще разработчики Cryptocat. Основные усилия направлены на затруднение несанкционированного доступа к удаленному серверу и информации, которая будет там храниться, а не защиту пересылаемых данных от перехвата. Другой потенциальной проблемой может быть унификация. Если Crypton станет де-факто стандартом, то обнаружение уязвимости в его протоколе подвергнет опасности всех, кто им пользуется. Но это же относится ко всем open-source библиотекам, которые используются во множестве программных продуктов.

Crypton – еще не продукт и не платформа. Пока. Но это может быть решением давно назревшей проблемы, и он наверняка привлечет внимание.

Комментарии (0)


Добавление комментариев доступно только зарегистрированным пользователям. Используйте свою существующую учетную запись для авторизации. Если у Вас еще нет учетной записи на сайте ее можно создать пройдя несложную процедуру регистрации. Кстати, для входа на сайт, наравне с учетной записью на cloudzone.ru, можно использовать аккаунт из следующих популярных сервисов: Яндекс, Facebook, Google и LinkedIn