当我公司以前的开发人员必须存储敏感的用户数据（例如医疗记录）时，他们做了以下事情。我怀疑它的优点。
A 中的非敏感数据，B 中的医疗记录，C 中的A 和B 之间的映射。A) 与医疗记录 (B) 联系起来。我们自己的后端代码调用C 将A 和B 数据绑定在一起以供用户显示。我认为这种代码的普遍存在使拆分数据库的好处无效：如果黑客访问我们的系统，他可以调用我们的逻辑。
我缺少上述系统的哪些好处（或者有更好的方法来保护此类数据）？
【问题讨论】：
我会说，一旦您的系统 遭到破坏并且攻击者超过了访问权限，那么数据库只是时间问题。它正在做的至少可能是延迟入侵者的意图 - 但成本（在维护、性能、项目清晰度等方面）可能超过收益。
我确信有足够的信息让一个有决心的人决定 X、Y 和 Z 数据库是链接的 - 除非你混淆了数据库名称、表名和其他结构指标。
理想情况下，您应该寻求使您的系统无法渗透，除此之外的所有其他事情都是缓解措施，治疗症状而忽视问题（您已被利用），必须单独考虑权衡看情况。
根据我的经验和意见，像这样拆分数据库是一种奇怪的人为设计的安全方法，我发现它非常愚蠢。
【讨论】：
在回答“拆分数据库是一种合法的安全措施”这一普遍问题时，隔离确实是一种众所周知的、有用的实现安全的工具。它的好处是否超过它的缺点（通常是额外的复杂性）在很大程度上取决于具体情况，我不知道你的系统情况的答案。
例如，假设有人想在您的数据之上构建一个分析应用程序。将映射数据完全排除在图片之外将非常有用。如果分析应用程序遭到破坏，地图信息不会受到威胁。
针对下面的一些 cmets，即使在您的系统的特定情况下，“破坏系统”等同于一次破坏所有数据库并不是一个定论。假设攻击者利用了您应用程序中的 SQL 注入漏洞。如果映射数据是独立的且经过强化的（例如，对访问映射的代码进行额外控制），那么隔离可能是公开非关联数据和关联数据之间的区别。
并不是说它对您的系统来说是一个好的设计。只是试图解释可能涉及到这一点的不同类型的理由。
我在类似情况下使用相同的隔离策略。在我的例子中，“数据库”是配置存储库。所有的 preprod 配置都放在一个 repo 中，而生产配置放在一个单独的 repo 中。所有开发人员都可以访问 preprod 存储库，但只有发布工程师可以访问 prod 存储库。理由是我想要进行深度防御：虽然我当然可以对各个 repo 文件夹实施访问控制，但我宁愿让生产配置简单地通过网络对所有未经授权的员工进行访问。
【讨论】：
是的，将数据拆分到不同的存储区有助于提高安全性。正如 James Anderson 所写，大多数数据库系统都允许您对各个表授予不同的权限。
但是，大多数安全分析都会寻找最薄弱的环节；我怀疑您最薄弱的环节是否是您的数据库拆分方式。所以，除非你已经确定了一大堆其他事情——密码管理是一个显而易见的事情，SQL 注入攻击另一个——充其量，数据库设计是毫无意义的；在最坏的情况下，它会增加导致错误的应用程序的复杂性；大多数安全漏洞来自错误。
这也可能导致一种错误的安全感——“我们有安全保障，我们拆分了我们的数据库”，或者对保护“非敏感”数据采取漫不经心的态度。
哦，如果您确定用户的登录凭据是“不敏感的”，那么您基本上是在让攻击者选择简单地冒充系统的合法用户在他们侵入您的“不敏感”后窃取您的数据“ 数据存储。
【讨论】：
在大多数重要的 DBMS 系统上，您可以控制表（有时甚至是行级别）的访问。
因此，将敏感数据存储在单独的表中是限制对机密数据的访问的有效方法。
虽然没有什么可以保护您免受获得 root 权限的黑客的攻击（正如其他海报所指出的那样）。但是这种策略将保护您免受系统内未经授权的用户获得访问权限，以及通过扩展获得他们的用户名和密码的黑客。由于欺骗低级别员工提供密码详细信息仍然是最常见的“攻击”之一，因此值得这样做。
最大的“如果”是您真的可以将您的用户分成“有权访问”和“访问受限”组吗？
【讨论】：