半透明数据库 [英] Translucent Databases
问题描述
我正在建立一个内含健康信息的应用程序。这个应用程序将面向消费者，对我来说是新的。我想要一个方法，使隐私问题完全放心。当我审查在公开可访问的数据库中保护敏感数据的方法时，我经常遇到数据库半透明的概念。有关于此主题的原始图书，以及关于此主题的精彩教程。
$ b $我的关注是，我看到很少的信息，关于这个想法，我会考虑非常现代的编程网站（像这样）。似乎没有一篇关于维基百科的想法的文章。没有关于这个问题的主题，没有最近的教程或文章的主题。为了简洁，这个想法是系统的某些用户清楚了某些数据，而其他用户被加密地禁止访问该数据，即使他们有管理员访问。
我已经在提供半透明数据访问的原型数据库上做了大量工作。我遇到了一个相当大的问题：要真正的半透明，可以没有密码恢复的机制。如果管理员可以重置用户密码，则他们可以简单地访问用户数据。为了真正地半透明，用户必须永远不会松动密码。
我们使用强加密保护我们日常生活中的私人数据的人（技术人员可以肯定）在使用这些强大的加密系统时被用于解决这个问题。如果blowfish这个词是你的日常词典的一部分，这是一件事，而是一个以消费者为中心的网站？我担心用户不会愿意用真正的数据库半透明隐藏真正加密为你的概念。我害怕以我忘记了密码开头的支持电话，结束于我说我没有什么可以为你做的。
我的问题：我应该在我的应用程序中实现这个方法吗？有没有其他开源应用程序，沿着这条路线，我可以比较数据库设计（esp使用PHP / MySQL）？我任何人追求这些真正安全，但真的不方便的功能集？还有另一个数据库安全模型是更受欢迎和现代的，我错过了？数据库半透明是一个时尚或合理的数据库设计方法，我应该拥抱？虽然我总是欣赏讨论，我更喜欢在我的设计中可以利用的客观答案。
在最近类似的事情，并打击同样的问题。我正在考虑实现的解决方案如下：
- 注册后，为用户创建一个唯一的安全这可以加密他们的数据。
- 使用用户密码加密此密钥AES并将其存储在数据库中。
此时，您仍然处于如果用户忘记密码的情况，
- 创建代表您的组织的公钥/私钥对，并将公钥存储在服务器上。 li>
- 将密钥的私有部分分成几个组件，并将每个组成部分分配给在公司持续成功中有重大利益（最好是财务）的人（例如您公司的董事）。这样做，任何两个或任何三个人可以在一起，恢复完整的私人密钥，当需要时。
- 当用户注册并使用密码加密密钥时，使用组织公钥加密密钥，并将其存储在某个地方。
- 创建一个密码重置表单，其中记录了重置用户密码的请求，以及用户是他们说他们是谁的证据（例如挑战/响应）。
- 在数据库中记录这些重置请求（可选择使用公钥加密）。
- 每小时/天/周/月一次，获取必要的密钥持有人一起使用它们的组合键来处理累积的重置请求，解密成功证明他们是他们是谁的用户的密钥。
这里有很多挑战和考虑。我对这些内容有几点想法，但也会对其他人的意见感兴趣：
- 如何安全地分割密钥多个人，所以没有人可以解密存储的密钥。
- 如果主密钥真正落入错误的手中，如何最小化将暴露的密钥数量。 li>
- 如何确保如果（天堂禁止）您的密钥持有人失去了他们的密钥，那么（a）没有数据暴露的风险，（b）没有突然的
- 如何成功验证有人真的是他们说他们没有让这是一个明显的洞在你的整个安全方法。
您在这个领域实现的任何事情都会降低半透明数据库方法的安全性，毫无疑问，但这可能是一个值得妥协的结果，具体取决于您的数据。
I am building an application with health information inside. This application will be consumer-facing with is new for me. I would like a method to put privacy concerns completely at ease. As I review methods for securing sensitive data in publicly accessible databases I have frequently come across the notion of database translucency. There is the original book on the subject and an excellent tutorial on the subject from Oriellynet.
My concern is that I have seen very little information regarding this idea on what I would consider very-modern programming sites (like this one). There does not seem to be an article about the idea on wikipedia. No questions on the subject here, and no very recent tutorials or articles on the subject. To be uber-brief, the idea is that certain data is clear to some users of the system, while other users a cryptographically prevented from accessing that data, even if they have administrator access.
I have done substantial work on a prototype database that provides translucent data access. I have run across a considerable problem: To be truly translucent, there can be no mechanism for password recovery. If an administrator can reset a users password, then they can briefly gain access to a users data. To be truly translucent, the user must never loose the password.
Those of us who use strong encryption to protect private data in our daily lives (technorati to be sure) are used to this problem when using these kinds of strong encryption systems. If the word "blowfish" is part of your daily lexicon that is one thing, but a website that is consumer focused? I am concerned that users will not be willing to wrap their mind around the "truly encrypted just for you" notion implicit with true database translucency. I am afraid of the support call that begins with "I lost my password" and ends with me saying "There is nothing that I can do for you".
My question: Should I implement this method in my application? Are there other open source applications that have gone down this route that I can compare database designs with (esp using php/MySQL)? I anyone else pursuing these kind of truly secure, but really inconvenient feature sets? Is there another database security model that is more popular and modern that I have missed? Was database translucency a fad or a legitimate database design method that I should embrace? While I always appreciate discussion I would prefer objective answers that I can leverage in my design.
So, I've been looking at something similar to this recently, and hit upon the same issue. The solution I'm considering implementing is as follows:
- Upon registration, create a unique, secure (long) key for the user and use this to encrypt their data.
- Encrypt this key with the user's password using e.g. AES and store it in the database.
At this point, you're still in the situation where if the user forgets their password, they've had it.
- Create a public/private key pair representing your organisation, and store the public key on the server.
- Split the private portion of the key into several components and give each to people (e.g. directors of your company) who have a significant stake (preferably financial) in the continued success of your company. Do this such that any two, or any three people can get together and restore the full private key when required. Encrypt each person's key with their own password.
- When a user registers, as well as encrypting their key with their password, encrypt it with the organisational public key and store it somewhere.
- Create a password reset form which records a request to reset the password of a user, along with some proof that the user is who they say they are (e.g. challenge/response).
- Record these reset requests (optionally encrypted using the public key again) in the database.
- Once per hour/day/week/month, get the requisite key-holders together, and use their combined keys to process the accrued reset requests, decrypting the keys of users who successfully proved they are who they say they are.
There are lots of challenges and considerations in this. I've got a few thoughts on most of these, but would be interested in others opinions too:
- How to split the key safely between multiple people so that no one person can decrypt the stored keys.
- How to minimise the number of keys that would be exposed if the 'master keys' genuinely fell into the wrong hands.
- How to make sure that if (heaven forbid) your key-holders lost their keys, then (a) there's no risk of exposure of the data, and (b) there's no risk that suddenly the ability to reset passwords is lost forever.
- How to successfully validate that someone really is who they say they are without making this a glaring hole in your whole security approach.
Anything you implement in this area WILL reduce the security of the translucent database approach, without a doubt, but this may be a worthwhile compromise depending on the nature of your data.
这篇关于半透明数据库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
