4

我正在构建一个系统，该系统需要通过安全的 Web 连接收集一些用户敏感数据，将其安全地存储在服务器上，以便以后自动解密和重用。系统还应允许用户通过*****ze网络查看某些部分的受保护数据（例如，）和/或完全更改它。系统应提供合理的安全级别。

我在考虑以下基础设施：

应用程序（Web）服务器 1

  1. 具有适当 TLS 支持的 Web 服务器，用于安全的 Web 连接。

  2. 使用公钥算法（例如 RSA）加密输入的用户敏感数据，并通过单向出站安​​全通道（例如 ssh-2）将其发送到App Server 2 ，而不会将其存储在App Server 1或DB Server 1的任何位置。

  3. 使用与用户密码相关的对称密钥算法对输入数据的某些部分（例如最后几个字母/数字）进行加密，并将其存储在DB Server 1上，供App Server 1在用户 Web 会话期间检索。

  4. 用户通过网络重新使用步骤 2 进行数据修改。

数据库服务器 1

  1. 存储不安全的非敏感用户数据。
  2. 存储在App Server 1上加密的部分敏感用户数据 （参见上面的步骤 3）

应用服务器 2

  1. 永远不要向App Server 1或DB Server 1发送任何内容 。
  2. 从App Server 1接收加密的用户敏感数据并将其存储在DB Server 2中。
  3. 根据本地计划从数据库服务器 2中检索加密的用户敏感数据，使用本地存储在应用服务器 2上的私钥（参见应用服务器 1，步骤 2）解密，并进行适当的密钥管理。

数据库服务器 2

  1. 存储加密的用户敏感数据（参见App Server 2，步骤 2）

如果应用程序（Web）服务器 1或数据库服务器 1或两者都受到威胁，那么攻击者将无法获取任何用户敏感数据（无论是否加密）。所有攻击者都可以访问众所周知的公钥和加密算法。然而，攻击者将能够修改网络服务器以获取当前登录的用户明文密码并解密存储在 DB 服务器 1 中的部分用户敏感数据（请参阅应用服务器 1，第 3 步），我认为这没什么大不了的。攻击者将能够（通过代码修改）在潜在攻击期间拦截用户通过 Web 输入的用户敏感数据。后来我认为这是一个更高的风险，但假设攻击者很难（是吗？）在没有人注意到的情况下修改代码，我想我不应该太担心它。

如果App Server 2和私钥被泄露，那么攻击者将可以访问所有内容，但App Server 2或DB Server 2不是面向 Web 的，因此应该不是问题。

这种架构有多安全？我对加密算法和安全协议如何工作的理解正确吗？

谢谢！

4

3 回答 3

3

我认为我不能给出适当的回应，因为我不确定您系统的目标是否明确。虽然我很感激你得到关于设计的反馈，但如果没有目的，这有点难。

我会建议你这样做：

首先有力地记录和分析您的威胁模型

您需要提出所有可能的攻击场景的固定硬线列表。您要防范的本地攻击者等？您还说“使用适当的密钥管理”之类的话；然而，这是最难做的事情之一。所以不要只是假设你能做到这一点；全面规划你将如何做到这一点，并具体链接到它将防止攻击的人。

你需要做一个威胁模型的原因是你需要确定你在哪些方面会受到攻击；因为会是这样。

我也会建议，虽然理论很好；在加密实施中也非常关键。不要只是假设你会正确地做事，你真的需要注意随机数的来源，以及其他类似的事情。

我知道这有点含糊，但我确实认为至少提出正式且强大的威胁模型会对您非常有帮助。

于 2009-09-21T01:46:40.457 回答
1

到现在为止还挺好。您正在走向一个非常安全的架构。还有其他需要考虑的问题，例如防火墙、密码策略、日志记录、监控和警报，但到目前为止您所描述的一切都非常可靠。如果数据足够敏感，请考虑对您的安全性进行第三方审计。

于 2009-09-21T01:38:26.363 回答
1

我不建议使用任何形式的公钥从您的 Web 服务器到您的应用服务器进行通信。如果你控制这两个系统只是一个常规的秘密加密系统。您知道应用服务器的身份，因此保持密钥安全不是问题。如果您需要更改或更新密钥，只需手动执行此操作，以防止其通过连接泄漏。

我最要注意的是从 DMZ 中的服务器（应该只是您的网络服务器）到驻留在网络内部的那些盒子的数据传输方向。合法域被破坏以向访问用户分发恶意软件变得越来越普遍。这很糟糕，但如果恶意软件转向您的网络，而不仅仅是向外发送给您的用户，那么您的业务将完全被淹没。

我也没有看到任何有关防止 sql 注入或系统加固/修补以防止恶意软件分发的信息。这应该是您的第一个也是最重要的考虑因素。如果安全性对您很重要，那么您的架构将能够灵活地对服务器间通信和频繁打补丁进行小规模定制。大多数网站，即使是主要的合法企业，即使受到损害，也永远不会修复其安全漏洞。如果您希望一开始就避免受到威胁，您必须​​不断修复安全漏洞并进行更改以防止出现漏洞。

为了防止成为恶意软件分发者，我建议对包含任何类型客户端脚本的媒体的服务方式制定严格的规则。客户端脚本可以在 JavaScript、ActiveX、Flash、Acrobat、Silverlight 和其他在客户端系统上执行的代码或插件中找到。必须存在提供该内容的策略，以便可以立即识别异常代码片段。我的建议是永远不要将客户端代码直接嵌入浏览器，但总是引用一些外部文件。我还建议整合志同道合的媒体，以便更好地控制资产并节省带宽，例如提供一个大型 JavaScript 文件而不是 8 个小文件。我还建议将所有此类媒体强制到外部内容分发系统上，该系统在其目录结构中引用您的域。这样媒体就不会直接从您的服务器提供，如果它直接从您那里提供，您可以快速将其识别为潜在恶意并需要进行安全审查。

于 2009-09-21T02:10:30.280 回答