Ruby on Rails - 使用不受信任的主机加密数据库内容和服务器客户端通信
我想实现一个 RoR 应用程序，将敏感信息存储在由不受信任的第三方托管的数据库中。基本功能包括：
1) 数据库内容加密
2) RESTful 范式下的安全用户会话支持
3）由第三方廉价托管的数据库。
4) 用于解密客户端和服务器数据库内容的密钥受到保护，免受第三方网络主机管理员的检查。
我会使用 SSL 进行加密的服务器-客户端通信。我是否可以实现一个解决方案，让我无法查看存储的用户数据（建立 RESTful 用户会话所需的数据元素除外）？驻留在第三方服务器上的代码是否可以受到保护或混淆？
作为一名开发人员，是否有一种设计实现可以让我诚实地向用户保证他们是唯一可以解密和查看其数据的人？我感觉这里的答案是“不”，但我想在承认失败之前我可以问问其他人。
请评论使用 RoR 和 RESTful 架构的最佳实践（或您的方法）。
谢谢！
I'd like to implement a RoR application that stores sensitive information in a database that is hosted by an untrusted third party. Essential functionality includes:
1) Database contents encrypted
2) Secure user session support under a RESTful paradigm
3) Database hosted by third party on the cheap.
4) Keys used to decrypt DB contents for client and server are protected from examination by third party web host admin.
I would use SSL for encrypted server-client communication. Can I implement a solution that keeps even me from being able to view stored user data, with the exception of data elements necessary to establish a RESTful user session? Can code that resides on the third party server be protected or obfuscated?
As a developer, is there a design implementation that allows me to honestly assure users that they are the only ones who can decrypt and view their data? I've got the feeling that the answer here is "no," but I thought I might ask others before admitting defeat.
Please comment on best practice (or your method) using RoR and RESTful architecture.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于（1），请查看 这个问题
对于（2），您可以使用 Devise 或 AuthLogic
对于 (3)， Heroku（共享主机）和 Webbynode（如果您更喜欢您的虚拟主机 - 您必须设置自己提高安全性）非常便宜。
对于（4），查看 StrongBox，我认为使其工作的一种方法是不存储数据库中的用户秘密（也许在用户登录时询问并将其存储在用户会话中，但我不知道这是否可能。）
For (1), take a look at this SO question
For (2), you can use Devise or AuthLogic
For (3), Heroku (shared hosting) and Webbynode (if you prefer your vhost -- you have to set up security yourself) are pretty cheap.
For (4), looking at StrongBox, I think one way to make it work would be to not store the user secret in your database (perhaps ask for it when user logs in and store it in user session, but I don't know if that's possible.)