如何将个人身份与他的个人资料分开？ [英] How to separate a person's identity from his personal data?

问题描述

我想确保即使我作为一名开发人员（或任何人完全以
访问数据库）无法弄清某人
花了多少钱或他已经买了多少钱。

我最初想出了以下计划：

 
 -------------- + --- --------- + ----------- 
 user_hash | item |价格
 -------------- + ------------ + ----------- 
 a45cd654fe810 |脱衣舞俱乐部| 400.00 
 a45cd654fe810 |法拉利| 1510800.00 
 54da2241211c2 |啤酒| 5.00 
 54da2241211c2 | iPhone | 399.00 
 

• 用户使用用户名和密码登录。


• From密码计算 user_hash （可能与salting等）。
  
• 使用散列通过正常的SQL查询访问用户数据。 / li>
  

如果有足够的用户，只要知道他的名字，就几乎不可能知道特定用户花了多少美元b $ b钱。

这是一个明智的做法，还是我完全愚蠢？ 解决方案

问题是，如果某人已经拥有对数据库的完全访问权限，那么将这些记录与特定人员进行关联只是时间问题。在数据库的某个地方（或应用程序本身），你必须建立用户和项目之间的关系。如果有人拥有完全访问权限，那么他们将有权访问该机制。

绝对没有办法防止这种情况发生。

现实情况是，通过完全访问，我们处于信任的位置。这意味着即使您可以看到数据，公司经理也必须相信，您不会以任何方式采取行动。这就是伦理这样的小事情发生的地方。现在，很多公司将开发和生产人员分开。目的是将开发从直接接触实时（即真实）数据中移除。这在安全性和数据可靠性处于堆顶时具有许多优势。

唯一的缺点是一些开发人员认为他们无法在没有生产权限的情况下解决问题。但是，这是不正确的。

然后制作人员将是唯一可以访问活动服务器的人员。他们通常会受到更大程度的审查（犯罪历史和其他背景调查），与您必须保护的数据类型相符。

所有这一切这是一个人事问题;而不是真正能够用技术手段解决的问题。

---

更新

其他这里似乎缺少了一个非常重要和重要的难题。也就是说，出于某种原因正在将数据输入到系统中。这个理由几乎普遍，所以它可以共享。在费用报告的情况下，输入该数据以便会计知道谁应付款。

这意味着系统在一定程度上必须在没有数据录入人员（即：销售人员）登录的情况下匹配用户和项目。

并且因为这些数据必须联系在一起，键入安全代码以释放数据，然后DBA将绝对能够查看查询日志以确定谁是谁。无论您想要投入多少个散列标记，我都可以轻松添加。三重DES不会为您节省。

在这一天结束时，您所做的一切都是让开发变得更加困难，绝对不会带来安全方面的好处。我无法强调这一点：从dba隐藏数据的唯一方法是：1.只有 的数据才能被输入该数据的人访问，或者2.为了不存在于第一位。

关于选项1，如果唯一能够访问它的人是进入它的人..好吧，这没有意义在公司数据库中。

I'm writing an app which main purpose is to keep list of users purchases.

I would like to ensure that even I as a developer (or anyone with full access to the database) could not figure out how much money a particular person has spent or what he has bought.

I initially came up with the following scheme:

    --------------+------------+-----------
    user_hash     | item       | price
    --------------+------------+-----------
    a45cd654fe810 | Strip club |     400.00
    a45cd654fe810 | Ferrari    | 1510800.00
    54da2241211c2 | Beer       |       5.00
    54da2241211c2 | iPhone     |     399.00

• User logs in with username and password.
• From the password calculate user_hash (possibly with salting etc.).
• Use the hash to access users data with normal SQL-queries.

Given enough users, it should be almost impossible to tell how much money a particular user has spent by just knowing his name.

Is this a sensible thing to do, or am I completely foolish?

解决方案

The problem is that if someone already has full access to the database then it's just a matter of time before they link up the records to particular people. Somewhere in your database (or in the application itself) you will have to make the relation between the user and the items. If someone has full access, then they will have access to that mechanism.

There is absolutely no way of preventing this.

The reality is that by having full access we are in a position of trust. This means that the company managers have to trust that even though you can see the data, you will not act in any way on it. This is where little things like ethics come into play.

Now, that said, a lot of companies separate the development and production staff. The purpose is to remove Development from having direct contact with live (ie:real) data. This has a number of advantages with security and data reliability being at the top of the heap.

The only real drawback is that some developers believe they can't troubleshoot a problem without production access. However, this is simply not true.

Production staff then would be the only ones with access to the live servers. They will typically be vetted to a larger degree (criminal history and other background checks) that is commiserate with the type of data you have to protect.

The point of all this is that this is a personnel problem; and not one that can truly be solved with technical means.

---

UPDATE

Others here seem to be missing a very important and vital piece of the puzzle. Namely, that the data is being entered into the system for a reason. That reason is almost universally so that it can be shared. In the case of an expense report, that data is entered so that accounting can know who to pay back.

Which means that the system, at some level, will have to match users and items without the data entry person (ie: a salesperson) being logged in.

And because that data has to be tied together without all parties involved standing there to type in a security code to "release" the data, then a DBA will absolutely be able to review the query logs to figure out who is who. And very easily I might add regardless of how many hash marks you want to throw into it. Triple DES won't save you either.

At the end of the day all you've done is make development harder with absolutely zero security benefit. I can't emphasize this enough: the only way to hide data from a dba would be for either 1. that data to only be accessible by the very person who entered it or 2. for it to not exist in the first place.

Regarding option 1, if the only person who can ever access it is the person who entered it.. well, there is no point for it to be in a corporate database.

这篇关于如何将个人身份与他的个人资料分开？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！