拆分数据库是一种合法的安全措施吗？

Question

当我公司的先前开发人员必须存储敏感用户数据（例如，医疗记录）时，他们会执行以下操作。我怀疑它的优点。

1. 有数据被认为是“不敏感”（用户登录，个人资料信息）和“敏感”（用户医疗记录）。
2. 有三个数据库。 A中的不敏感数据，B中的医疗记录以及A中B与C之间的映射。
3. 黑客必须破解所有三个数据库，以便将用户（A）与医疗记录（B）联系起来。

我们自己的后端代码调用C将A和B数据绑定在一起以供用户显示。我认为这个代码的无处不在使分割数据库的好处失效：如果黑客访问我们的系统，他可以调用我们的逻辑。

我遗漏了上述系统的哪些好处（或者有更好的方法来保护这些数据）？

Answer 1

我会说，一旦您的系统遭到入侵并且攻击者超过访问权限的阈值，那么数据库只是时间问题。 所做的事情至少可能会延迟入侵者的意图 - 但成本（在维护，性能，项目清晰度等方面）可能会超过收益。

我确信会有足够的信息让某个坚定的人决定X，Y和Z数据库是否相关联 - 除非您混淆数据库名称，表名和其他结构指标。

理想情况下，您应该寻求使您的系统难以理解，除了缓解之外的所有其他事情，忽视问题（您已被利用）的症状处理，其中必须权衡取舍这种情况。

根据我的经验和意见，像这样分割数据库是一种奇怪的人为安全方法，我发现这是非常愚蠢的。

Answer 2

在回答一般性问题“将数据库拆分成合法的安全措施”时，隔离确实是实现安全性的众所周知的有用工具。它的好处是否超过它的缺点（通常是额外的复杂性）是非常具体的情况，我不知道你的系统的答案。

假设有人想要在您的数据之上构建分析应用程序。将映射数据完全排除在图片之外是非常有用的。如果违反了分析应用程序，则映射信息不会有风险。

回应下面的一些评论，即使在你的系统的特定情况下，“违反系统”等于立刻违反所有数据库也不是定局。假设攻击者利用应用程序中的SQL注入漏洞。如果映射数据是分离的并且是硬化的（例如，访问映射的代码的额外控制，那么）隔离可以是暴露未关联数据和关联数据之间的区别。

并不认为它对您的系统来说是一个很好的设计。只是试图解释可以进入的各种理由。

我在类似情况下使用相同的隔离策略。在我的例子中，“数据库”是配置存储库。所有的preprod配置都在一个repo中，生产配置在一个单独的repo中。所有开发人员都可以访问preprod repo，但只有发布工程师才能访问prod repo。理由是我需要深入防御：虽然我当然可以在各个repo文件夹上实现访问控制，但我宁愿让生产配置对所有未经授权的员工来说都是网络无法访问的。

Answer 3

是的，将数据拆分到不同的商店可以帮助提高安全性。正如James Anderson所写，大多数数据库系统允许您为各个表授予不同的权限。

然而，大多数安全性分析寻找最薄弱的环节;我怀疑你最薄弱的环节是你的数据库拆分方式。所以，除非你已经确定了一大堆其他东西 - 密码管理显而易见，SQL注入攻击另一个 - 充其量，数据库设计毫无意义;在最坏的情况下，它会增加导致错误的应用程序的复杂性;大多数安全漏洞都来自漏洞。

它还可能导致错误的安全感 - “我们在安全方面受到保护，我们分离了我们的数据库”，或者对保护“非敏感”数据采取了傲慢的态度。

哦，如果您认为用户的登录凭据“不敏感”，那么您基本上只允许攻击者模仿系统的合法用户，一旦他们渗透您的“非敏感”，就会窃取您的数据“ 数据存储。

Answer 4

在大多数严肃的DBMS系统上，您可以控制表格访问（有时甚至是行级别）。

因此，将敏感数据存储在单独的表中是限制对机密数据的访问的有效方法。

虽然没有什么可以保护你免受黑客攻击（正如其他海报所指出的那样）。但是，此策略将保护您免受系统内未授权用户的访问，并通过扩展来获取其用户ID和密码的黑客。由于欺骗低级别员工提供密码详细信息仍然是最常见的“攻击”之一，这非常值得。

大“if”是否真的可以将您的用户分为“有权访问”和“限制访问”群组？