我了解大部分安全存储数据的概念，包括将数据存储在仅允许来自应用程序的连接、用于加密的密钥对等的单独服务器上。但是，我仍然不了解如何分离服务器它更安全。
例如，假设我有一个经过强化和安全的 Web 服务器，它从用户输入中捕获数据以进行存储。数据被加密并通过数据库查询或网络服务提交到数据库服务器。db 服务器只允许来自 Web 服务器的连接，并以加密形式存储数据。因此，如果有人访问数据库，则数据一文不值。
但是，如果有人访问 Web 服务器，他们将可以访问数据库以及加密算法和密钥，不是吗？既然如此，为什么还要将数据放在不同的服务器上，因为数据的传输只是另一个潜在的攻击点？
有没有办法隐藏网络服务器上的连接信息和加密算法，这样如果它被泄露，就无法访问数据库服务器？混淆是不够的，我不认为。欢迎任何想法。
谢谢布赖恩
人们为安全而设计的方式有一定的神奇思维和民间传说，你是对的：将数据单独存储在不同的服务器上并不一定会让事情变得更安全，除非你做过各种各样的其他事情也。
管理密钥是其中很重要的一部分；在 Web 应用程序的上下文中执行此操作是一个单独的主题，我不知道有任何强大的 PHP 解决方案。你是对的——如果你的 web 应用程序需要能够解密某些东西，它需要访问密钥，如果 web 应用程序被破坏，攻击者也可以访问密钥。
这就是为什么我倾向于使用公钥加密，并将面向公众的网络服务器视为“只写” - 即网络服务器使用公钥加密，存储在数据库中，并且永远无法解密它；只有一个单独的进程（在公共互联网上不可用）可以使用私钥对其进行解密。这样，您可以将信用卡详细信息存储在您的数据库中，并且只有向卡收费的应用程序才有私钥解密它；此应用程序在安全的环境中运行，无法从 Internet 访问。
其次，存在多个级别的危害——例如，攻击者可能会获得对服务器文件系统的只读访问权限。如果该文件系统包含数据库，他们可以获取数据文件，将其还原到他们控制的服务器，并使用解密密钥窃取您的私人数据。如果数据库在单独的服务器上运行（无法从 Internet 访问），则此攻击路线将变得不可能。
一条攻击路线让您敞开心扉这一事实并不意味着您无法抵御其他攻击。
在我的大多数设置中，Web 服务器位于防火墙的 DMZ 中，而数据库位于防火墙后面。我永远不想将数据库服务器放在防火墙之外。这种额外的安全级别使某人更难在未经授权的情况下获取数据。
顺便说一句，网络上的任何 Web 服务器都不应被视为“加固和安全”。如果它可供公众使用，它可能会被黑客入侵。这只是他们想尝试多努力的问题。
您的假设是正确的，如果有人将网络服务器入侵到可以以管理员身份登录的程度，他们就可以读取和写入数据库。但这并不意味着您应该通过将数据库放在 Web 服务器上来进一步削弱您的设置。您想要更多的安全性，而不是更少。
编辑：
始终考虑安全性的各个层次。将关键部分分成单独的层。这有两件事。它使犯罪分子有更多的问题需要解决，并为您提供更多的检测和响应时间。
因此，在您的场景中，对 Web 服务器的访问是一层，然后您可以为第二层调用加密服务器（在防火墙后面，这是另一层），并且加密服务器可能是唯一允许与数据库服务器，这是另一层。
层使其更安全。但是，它们也增加了负担，减慢了响应时间。因此，请根据您的实际需求保持您的解决方案平衡。
这里的问题是密钥位于可能会被泄露的面向公众的服务器上 - 即使服务器本身已“加固”，您的应用程序中也可能存在漏洞，使攻击者可以访问密钥或数据。
为了提高您安排的安全性，您可以只将处理加密数据的代码（连同密钥）移动到只能由 Web 服务器访问的安全机器上，并且只能通过非常受限的 API（即最低限度是需要）。记录每个操作以发现异常行为，这可能是试图提取秘密数据的征兆。
从安全角度来看，将数据库放入单独的服务器并没有真正的帮助。如果身份验证令牌被泄露，那么游戏就结束了。
但是，将数据库AND数据访问层 (DAL) 与业务逻辑和表示分离是有意义的。这样一来，如果应用程序服务器落入不法之徒之手，数据库访问将仅限于特定的 DAL 操作，如果实施得当，这将大大有助于使数据免受危害。
除此之外，将数据存储分离到单独的服务器中并没有太多的安全优势。