半透明的数据库[英] Translucent Databases

本文是小编为大家收集整理的关于半透明的数据库的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

我正在构建一个带有健康信息的应用程序.对于我来说,此应用程序将与之面对消费者.我希望一种将隐私问题完全放松的方法.当我审查用于在公共数据库中确保敏感数据的方法时,我经常遇到数据库半透明的概念.那里有原始书关于该主题的原始书

我的问题:我应该在应用程序中实现此方法吗?是否还有其他开源应用程序已经沿着这条路线进行了,我可以将数据库设计与(ESP使用PHP/MySQL)进行比较?我还有其他人追求这类真正安全但确实不便的功能集吗?还有我错过的另一个数据库安全模型吗?数据库的半透明是我应该接受的FAD或合法数据库设计方法吗?虽然我一直很感激讨论,但我希望我可以在设计中利用客观答案.

推荐答案

所以,我一直在研究与此类似的东西,并遇到了同样的问题.我正在考虑实施的解决方案如下:

此时,您仍处于用户忘记密码的情况.

  • 创建代表您组织的公共/私钥对,并将公共密钥存储在服务器上.
  • 将密钥的私人部分分为几个组成部分,并将每个人(例如,贵公司的董事)提供给您公司持续成功的人(最好是财务).这样做以使任何两个人或任何三个人都可以在需要时聚在一起并恢复完整的私钥.使用自己的密码加密每个人的密钥.
  • 当用户注册并使用密码加密密钥时,请使用组织公钥对其进行加密并将其存储在某个地方.
  • 创建一个密码重置表格,该表单记录了重置用户密码的请求,以及一些证明用户是他们说的人(例如,挑战/响应).
  • 在数据库中记录这些重置请求(再次使用公共密钥进行加密).
  • 每小时/日/周/月一次,将必要的钥匙持有人聚集在一起,并使用其组合键处理应计重置请求,解释了用户的钥匙,这些用户的钥匙成功证明了他们是他们说的.<<<<<<<<<<<<<./li>

其中有很多挑战和考虑因素.我对其中的大多数有一些想法,但也会对他人感兴趣:

  • 如何在多个人之间安全地将密钥拆分,以便没有人可以解密存储的钥匙.
  • 如何最大程度地减少"主钥匙"真正落入错误的手中的键数量.
  • 如何确保如果(天堂禁止)您的钥匙持有人丢失了钥匙,那么(a)没有暴露数据的风险,并且(b)没有风险突然丢失了重置密码的能力永远.
  • 如何成功验证某人真正是他们所说的人,而他们在整个安全方法中都没有使这一巨大的漏洞.

您在此领域实施的任何事情都会毫无疑问地降低半透明数据库方法的安全性,但这可能是根据数据的性质而值得的妥协.

其他推荐答案

我应该在应用程序中实现此方法吗? 就像生活中的其他事物一样,也有一项折衷:)可能更安全,但很难建造.

是否还有其他开源应用程序已经沿着此路线进行了,我可以将数据库设计与(ESP使用PHP/MySQL)?

不知道,我想工具在那里自己要做:)

是否有人追求这类真正的安全,但真正不便的功能集?

是的,但是似乎仍然处于不成熟状态,就像您描述的有关丢失密码的问题.

是否还有另一个我错过的数据库安全模型?

基本上有两种数据库连接.一个选项为用户提供一个真实的数据库帐户,另一个选项是使用单个登录数据库.在网络上映之前,客户/服务器世界中有两个模型的支持者,但是在网络开发人员中,单登录方法领先.

是数据库的半透明是我应该接受的FAD或合法数据库设计方法吗?

不要这样认为,例如,UNIX密码数据库是基本半透明数据库的一个很好的示例;)

在这里有东西可以阅读链接文本a>

其他推荐答案

RE:半透明数据库.我想您可以使用指纹.烧伤受害者或最终失去指纹的人呢?糟糕.值得一小部分用户吗?

熟悉 hipaa ,尤其是在技术方面. 请记住,除了Skynet*之外,没有系统真正安全,看看发生了什么!人类负责.当您在一家医疗公司工作时,您会签署NDA,表明您不会释放您所学到的任何信息作为职责的一部分,因为这是机密的. 会有人重置人们的密码.就是这样,因为并非每个人都在技术上都有能力,而这就是它现在保持的方式. 您只需要实施安全性以及HIPAA所说的.

  • 实际上,还有另一个真正安全的系统:它是从网络和电力上插入的,并且已关闭.

本文地址:https://www.itbaoku.cn/post/597653.html

问题描述

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.

其他推荐答案

Should I implement this method in my application? Well like other things in life, there is a trade off :) It's probably more secure but harder to built.

Are there other open source applications that have gone down this route that I can compare database designs with (esp using php/MySQL)?

Don't know, I guess the tools are there to do it yourself :)

Is anyone else pursuing these kind of truly secure, but really inconvenient feature sets?

Yes, but it seems like it's still in an immature state, like your problem you describe concerning lost passwords.

Is there another database security model that is more popular and modern that I have missed?

Basically there are two kinds of database connections. One option gives users a real database account, the other is to use single sign-on to the database. Prior to the web coming along, there were proponents of both models in the client/server world, but amongst web developers the single sign-on method is leading.

Was database translucency a fad or a legitimate database design method that I should embrace?

Don't think so, the UNIX password database, for instance, is a great example of a basic translucent database ;)

here something to read link text

其他推荐答案

Re: translucent databases. You could, I suppose, use fingerprints. What about burn victims, or people who end up losing their fingerprints? Oops. Is it worth that small percentage of users?

Familiarize yourself with HIPAA, especially when it comes to technology. Remember that no system is truly secure, except Skynet*, and look what happened with that! Humans are in charge. When you work in a medical company, you sign an NDA indicating that you won't release any of the information you learn as part of your duties because it is confidential. There will be someone to reset people's passwords. That's the way it is, because not everyone is technologically competent, and that's the way it stays for now. You only have to implement security as well as HIPAA says.

  • in truth, there is another truly secure system: it is unplugged from both the network and the electricity, and it is turned off.