Шифрование пользовательских данных в App Engine - PullRequest
4 голосов
/ 18 мая 2011

Я пишу веб-приложение и приложение для Android, которое позволяет пользователям хранить и получать доступ к некоторым потенциально конфиденциальным данным. Передача этих данных через RPC уже защищена с помощью SSL. В настоящее время я храню этот фрагмент данных в свойстве Text без какого-либо шифрования. Сейчас я ищу способы лучше защитить хранилище данных.

Вопрос 1 : Существуют ли общие рекомендации или советы по шифрованию данных для хранения в App Engine?

Одна из моих идей заключалась в том, чтобы переключить свойство в поле Blob, передавать только зашифрованные данные по проводам и выполнять дешифрование и шифрование на клиентах (в Javascript и на Android).

Что касается ключа шифрования, я просто использую адрес электронной почты зарегистрированного пользователя, предоставленный UserService. Адрес электронной почты пользователя известен только тогда, когда пользователь вошел в систему, и конфиденциальный объект не имеет ссылки на адрес электронной почты пользователя & mdash; только идентификатор пользователя.

Вопрос 2 : Имеет ли адрес электронной почты пользователя смысл в качестве ключа шифрования? Если нет, то каковы другие известные варианты ключей шифрования?

Ответы [ 2 ]

8 голосов
/ 18 мая 2011

Я не уверен, что вы получите массу пользы от этого.Передача данных через SSL, безусловно, хорошая идея.Если вы храните пользовательские данные в незашифрованном виде, кто-то все равно должен получить доступ к вашему хранилищу данных, прежде чем он сможет что-то захватить.Если вы шифруете данные на основе свойств пользовательского объекта, вы должны раскрыть эту связь в коде шифрования / дешифрования на стороне клиента, так что это по сути общедоступно.Кто-то, кто получает доступ к вашему хранилищу данных и вашему источнику App Engine, может все еще расшифровать, это просто сложнее.

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

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

0 голосов
/ 18 мая 2011

Изменение свойства на Blob действительно хорошая идея, в этом случае шифрование и дешифрование будет простым. Используйте некоторую библиотеку по умолчанию для шифрования данных. Переходя к следующему пункту: использование электронной почты в качестве ключа шифрования - действительно плохая идея. Вам следует использовать User_id, который доступен в объекте пользователя, который действительно уникален.

...