安全地存储数据

Posted 2023-02-22

【中文标题】安全地存储数据

【英文标题】：Securely storing data

【发布时间】：2012-02-01 16:49:17

【问题描述】：

我了解大部分安全存储数据的概念，包括将数据存储在仅允许来自应用程序的连接、用于加密的密钥对等的单独服务器上。但是，我仍然不了解如何分离服务器使它更加安全。

例如，假设我有一个经过强化和安全的 Web 服务器，它从用户输入中捕获数据以进行存储。数据被加密并通过数据库查询或网络服务提交到数据库服务器。 db 服务器只允许来自 web 服务器的连接，并以加密形式存储数据。因此，如果有人访问数据库，则数据一文不值。

但是，如果有人访问网络服务器，他们将可以访问数据库以及加密算法和密钥，不是吗？既然如此，为什么还要将数据放在不同的服务器上，因为数据的传输只是另一个潜在的攻击点？

有没有办法隐藏网络服务器上的连接信息和加密算法，这样如果它被泄露，就无法访​​问数据库服务器？混淆是不够的，我不认为。欢迎任何想法。

谢谢 布赖恩

【参考方案1】：

在我的大多数设置中，Web 服务器位于防火墙的 DMZ 中，而数据库位于防火墙后面。我永远不想将数据库服务器放在防火墙之外。这种额外的安全级别使某人更难在未经授权的情况下获取数据。

顺便说一句，网络上的任何 Web 服务器都不应被视为“强化和安全”。如果它对公众开放，它可以被黑客入侵。这只是他们想尝试多努力的问题。

您的假设是正确的，即如果有人将网络服务器入侵到可以以管理员身份登录的程度，他们就可以读取和写入数据库。但这并不意味着您应该通过将数据库放在 Web 服务器上来进一步削弱您的设置。您需要更多安全性，而不是更少。

编辑：

始终考虑安全性中的层。将关键部分分成单独的层。这有两件事。它使犯罪分子有更多的问题需要解决，并为您提供更多的检测和响应时间。

因此，在您的场景中，访问 Web 服务器是一层，然后您可以调用第二层的加密服务器（在防火墙后面，这是另一层），加密服务器可能是唯一允许的机器与数据库服务器的交互，这是另一层。

分层使其更安全。但是，它们也增加了负担，减慢了响应时间。因此，请根据您的实际需求保持您的解决方案平衡。

【讨论】：

是的。但是，如果他们访问网络服务器，他们就不能从那里连接到数据库吗？

你的“顺便说一句”评论正是我所关心的。 Web 服务器上是您与数据库的连接设置，以及任何密钥和加密算法。似乎对 Web 服务器的访问也会暴露您的数据库服务器。

如果有人入侵到他们获得对网络服务器的管理员登录访问权限，是的。但是为什么通过将数据库放在网络服务器上来让它更容易呢？有了分离，他们必须获得比没有分离更大的控制权。

这几乎就像你在说“我的前门锁很容易被撬开，一旦进去他们就可以得到我的银行信息，那我为什么要把钱放在银行里呢？”安全始终在层中完成。

数据库具有由连接到它的用户定义的访问级别。您可以从“安全”服务器设置您的数据库访问权限，以使该用户无法删除您的数据。这为您提供了另一层保护，以防您的 Web 服务器受到威胁。此外，将 Web 服务器与 DB 服务器分开不仅关乎安全性，还关乎可维护性、可用性和可扩展性。

【参考方案2】：

这里的问题是密钥位于面向公众的服务器上，这可能会遭到破坏 - 即使服务器本身已“加固”，您的应用程序中也可能存在漏洞，使攻击者可以访问密钥或数据。

为了提高您的安排的安全性，您可以只将处理加密数据的代码（连同密钥）移动到只能由网络服务器访问的安全机器上，并且只能通过非常受限的 API（即裸所需的最小值）。记录每个操作以发现异常行为，这可能是试图提取秘密数据的征兆。

【讨论】：

这是一个很好的建议。请记住，最佳实践架构实际上会使用三台服务器，一个没有应用程序逻辑的 Web 服务器，一个包含所有代码的应用程序服务器，以及一个数据库服务器。 Web 服务器是唯一可以与应用程序服务器对话的东西，而应用程序服务器是唯一可以与数据库对话的东西。如果层之间的所有交互都尽可能少（正如@SimonJ 建议的那样）并且在层之间进行相互身份验证（2-way auth SSL），那么您对数据库的攻击比如果他们是同一个地方的。

【参考方案3】：

人们在设计安全性的方式中存在一定程度的神奇思维和民间传说，您是对的：将数据单独存储在不同的服务器上并不一定会使事情变得更安全，除非您已经完成了各种操作还有其他的东西。

管理密钥是其中很重要的一部分；在 Web 应用程序的上下文中执行此操作是一个单独的主题，我不知道有任何强大的 php 解决方案。你是对的——如果你的 web 应用程序需要能够解密某些东西，它需要访问密钥，如果 web 应用程序被破坏，攻击者也可以访问密钥。

这就是为什么我倾向于使用公钥加密，并将面向公众的网络服务器视为“只写” - 即网络服务器使用公钥加密，存储在数据库中，并且永远无法解密它；只有一个单独的进程（在公共互联网上不可用）可以使用私钥对其进行解密。这样，您可以将信用卡详细信息存储在您的数据库中，并且只有对卡收费的应用程序才有私钥解密它；此应用程序在安全的环境中运行，无法从 Internet 访问。

其次，存在多个级别的危害 - 例如，攻击者可能会获得对您服务器文件系统的只读访问权限。如果该文件系统包含数据库，他们可以获取数据文件，将其还原到他们控制的服务器，并使用解密密钥窃取您的私人数据。如果数据库在单独的服务器上运行（无法从 Internet 访问），则此攻击路线将变得不可能。

一种攻击路线让您敞开的事实并不意味着您无法防御其他攻击。

【讨论】：

出色的信息，包括那里和其他答案。这让我意识到分离数据是不够的。加密/解密功能也必须分开，如 Neville 所述，将 Web 服务器保留为“只写”。感谢大家的洞察力！

【参考方案4】：

从安全角度来看，将数据库放入单独的服务器并没有真正的帮助。如果身份验证令牌被泄露，游戏就结束了。

然而，将数据库 AND 数据访问层 (DAL) 与业务逻辑和表示分开是有意义的。这样一来，如果应用服务器落入不法之徒之手，数据库访问将仅限于特定的 DAL 操作，如果实施得当，这将大大有助于消除数据的危害。

除此之外，将数据存储分离到单独的服务器中并没有太大的安全优势。