Ren*_*soo 5 hash database-security sensitive-data
我正在编写一个应用程序,主要目的是保持用户购买列表.
我想确保即使我作为开发人员(或任何完全访问数据库的人)也无法弄清楚某个人花了多少钱或者他已经购买了什么.
我最初想出了以下方案:
--------------+------------+-----------
user_hash | item | price
--------------+------------+-----------
a45cd654fe810 | Strip club | 400.00
a45cd654fe810 | Ferrari | 1510800.00
54da2241211c2 | Beer | 5.00
54da2241211c2 | iPhone | 399.00
user_hash(可能与盐渍等).如果有足够的用户,通过了解他的名字,几乎不可能知道特定用户花了多少钱.
这是明智的做法,还是我完全愚蠢?
问题是,如果某人已经拥有数据库的完全访问权限,那么他们将记录链接到特定的人只是时间问题。在数据库的某个位置(或应用程序本身),您必须在用户和项目之间建立关系。如果某人具有完全访问权限,那么他们将可以访问该机制。
绝对没有办法阻止这种情况。
现实情况是,通过完全访问,我们处于信任的位置。这意味着公司经理必须相信,即使您可以看到数据,您也不会对其采取任何行动。这就是道德等小事情发挥作用的地方。
也就是说,现在很多公司将开发人员和生产人员分开。目的是使开发人员不再直接接触实时(即真实)数据。这具有许多优势,其中安全性和数据可靠性是最重要的。
唯一真正的缺点是一些开发人员认为他们无法在没有生产访问权限的情况下解决问题。然而,事实并非如此。
制作人员将是唯一可以访问实时服务器的人。他们通常会受到更大程度的审查(犯罪历史和其他背景调查),这与您必须保护的数据类型相一致。
这一切的关键在于,这是一个人事问题;而不是真正可以通过技术手段解决的问题。
更新
这里的其他人似乎遗漏了这个难题中非常重要且至关重要的一块。也就是说,数据被输入系统是有原因的。这个理由几乎是普遍的,因此可以分享。在费用报告的情况下,输入该数据以便会计人员可以知道该向谁付款。
这意味着系统在某种程度上必须在数据输入人员(即销售人员)登录的情况下匹配用户和项目。
而且由于必须将这些数据绑定在一起,而无需所有相关方站在那里输入安全代码来“发布”数据,因此 DBA 绝对能够检查查询日志以找出谁是谁。而且无论您想在其中添加多少哈希标记,我都可以轻松添加。三重 DES 也救不了你。
归根结底,您所做的只是使开发变得更加困难,安全效益绝对为零。我怎么强调都不为过:向 dba 隐藏数据的唯一方法是 1. 该数据只能由输入该数据的人访问,或者 2. 该数据从一开始就不存在。
关于选项 1,如果唯一可以访问它的人就是输入它的人……那么,它就没有必要存在于公司数据库中。