Исследователи из Массачусетского технологического института представили проект CryptDB, в рамках которого предпринята попытка решения проблемы безопасного хранения данных в БД, обслуживаемых в облачных сервисах и других неподконтрольных системах. Основная проблема при хранении важной информации в неподконтрольных СУБД связана с возможностью утечки данных в процессе взлома сервиса или в результате неправомерных действий администраторов. Для решения этой проблемы в CryptDB обеспечена поддержка шифрования, при которой данные на стороне СУБД никогда не фигурируют в открытом виде, а все передаваемые в CУБД запросы содержат только зашифрованные данные, в том числе в условных блоках. При использовании CryptDB, в процессе выполнения SQL-запросов все действия производятся только с зашифрованными данными, т.е. пользователь может отправить SQL-запрос к СУБД и получить результат без расшифровки информации на стороне сервера (данные будут расшифрованы на оборудовании клиента). Для обеспечения сохранения конфиденциальности информации используется многоуровневая система шифрования, при которой разные данные размещаются на разных вложенных криптографических уровнях, каждый из уровней имеет свой ключ и поддерживает ограниченный набор простейших операций над зашифрованными данными. Для скрытия данных на каждом уровне используются свои методы гомоморфного шифрования, при которых данные необратимо искажаются, но сохраняется возможность совершения определённых математических операций, которые дадут аналогичные результаты, что и операции над исходными данными (можно использовать зашифрованные данные для сравнения, сортировки, сложения и т.д. без предварительной расшифровки, например, выполняется условие decrypt(crypt(A) + crypt(B)) = A + B). Манипуляции над зашифрованными данными накладывают ограничения на возможность выполнения вычислений внутри запроса (невозможны операции сравнения для вычисляемых значений, например, нельзя использовать "salary > age*2+10", но можно "salary > age" или "salary > 10"), тем не менее поддерживаются большинство агрегатных функций и стандартных типов данных, таких как integer и varchar/text. CryptDB реализован в виде прокси, не требующего модификации кода СУБД. Для выполнения криптографических операций на стороне СУБД используется набор дополнительных функций (UDF, user-defined functions). Прокси состоит из двух частей: специальной библиотеки на языке С++ и модуля на языке Lua. Библиотека содержит реализацию парсера запросов и системы шифрования/расшифровки запросов, которые видоизменяют транзитный запрос, зашифровывая или расшифровывая данные и подставляя UDF-функции для выполнения вычислений и сравнений. Lua-модуль служит для прозрачной передачи запросов и приёма результатов от библиотеки на C++. CryptDB поддерживает связывание по цепочке ключей шифрования и паролей пользователей СУБД. При такой схеме работы доступ к данным могут получить только пользователи, пароли которых привязаны к ключам шифрования. Администратор СУБД, даже получив каким-то образом ключи шифрования, которые на фигурируют на сервере, не сможет получить доступ данным, не зная паролей владельцев этих данных. Использование привязки ключей к паролям пользователей требует наличия в базе 11-13 уникальных аннотаций схем данных для защиты содержимого около 20 полей, а также правки 2-7 строк кода в web-приложении. В отличие от других подобных разработок, разработчикам CryptDB удалось обеспечить неплохую производительность: по сравнению с обычным MySQL использование CryptDB повышает нагрузку всего на 15-26%. При работе phpBB скорость выполнения операций замедлилась всего на 14.5%, при выполнении тестового набора TPC-C скорость замедлилось на 26%. Размер хранимых на диске данных при этом вырос примерно на 20%. CryptDB выполнен в роли надстройки, способной работать с любыми СУБД MySQL 5.1 и PostgreSQL 9, не требуя модификации кода СУБД. Код CryptDB доступен через Git-репозиторий проекта (git clone -b public git://g.csail.mit.edu/cryptdb). Источник: http://www.opennet.ru/opennews/art.shtml?num=32610 Дата: 20/12/2011 22:31
Что? Скули теперь не будут так актуальны? Не, реальнэ. Ведь если введут эту систему, то эт просто пипец
Херня это всё, как зашифруеться так и расшифруеться на стороне хакера. пока внедрят лет 7-10, за это время стопятсот раз систему нах пошлют
Херня какая-то. Какой смысл хранить данные в БД в зашифрованном виде, если данные всё равно расшифровываются. Не важно где на стороне сервера или клиента. ИМХО лишний слой который жрёт ресурс. Или топикстартер не адекватный перевод выложил. Использование индивидуального ключа или сертифа пользователя для шифрования данных тема не новая, и часто используется. Давно известный прием шифрования данных открытыми ключами (симметричное шифрование ENCODE и DECODE), в качестве ключей используется хэш пароля пользователя. Это всё легко выясняется конечно но кидов путать добрая фишка. А вообще лучше использовать хранимые процедуры с грамотно настроенным к ним доступом пользователей. Ничего лучше чем SSL пока нет, для СУБД типа SQL