安全存储敏感信息

信息安全 应用安全 加密
2021-08-14 21:31:46

我知道已经有一些关于此的问题，但我只是想知道是否有人可以查看我的设计计划，看看是否存在任何巨大的安全漏洞。我正在制作一个 Web 应用程序，它可以安全地存储敏感信息，然后可以由有权访问它的工作人员检索。

我有两台服务器——一个主服务器和一个解密服务器。主服务器存储加密数据、验证用户、输出 HTML 等。解密服务器只存储部分私钥，当部分密钥与存储在主服务器上的另一半组合时进行解密。当然，一切都是通过 SSL 完成的，即使在两台服务器之间也是如此。两台服务器之间将存在其他限制，例如仅限于这两个 IP 地址以及将解密次数限制为一定数量（例如，每 15 秒一次，其他所有内容都会排队 - 如果队列到达，则自毁一定数量并需要管理员干预）。

我正在寻找的功能是让匿名用户能够通过网站将新数据加密到数据库中，所有员工都能够更新现有条目，特权员工能够解密存储的数据。

使用的键和散列摘要

编辑 - 为清楚起见，只有两种类型的键。两者都是不对称的。为了简单起见，我更改了这篇文章并简单地将它们称为 key1 和 key2。Key2 将被异或成两部分，key2a 和 key2b，它们再次组合以创建 key2。Key1是对key2进行加密的密钥加密密钥。Key2 用于解密敏感信息。

  • 主服务器：

    • 用于身份验证的用户密码哈希，存储在数据库中。
    • Key1 - 密钥加密密钥临时存储在 RAM 中，并永久存储在管理员的个人计算机和/或闪存驱动器上，位于完全不同的位置和网络
    • key2a 密钥 - 存储在由上述密钥加密密钥 (key1) 加密的数据库中的部分私钥。
    • 上面两个私钥的两个公钥都以纯文本形式存储在数据库中。

  • 解密服务器

    • Key2b 密钥 - 上述部分私钥的另一半

  • 密钥生成：

    • 密钥加密密钥 (key1) 基本上可以在任何地方生成，可能在管理员自己的 PC 上。
    • 另一个密钥对 (key2) 由主服务器生成，每个要加密的信息都有一个。

加密过程如下：

  • 生成一个新的 key2 私钥和公钥对（每个敏感数据不同的密钥对）
  • 信息使用key2的公钥加密并存储在数据库中
  • 然后将 Key2 的私钥异或成两部分（key2a 和 key2b）。
  • key2a 使用 key1 的公钥加密并存储在数据库中
  • key2b 被发送到解密服务器
  • 解密服务器将 key2b 存储在其数据库中并发送回插入 ID
  • 插入存储在主数据库中的 ID

解密过程：

  • key1（密钥加密密钥）存储在 memcache（或 redis）中。管理员必须手动上传此密钥。它将在他们自己的计算机上生成。它临时存储在 RAM 中（直到服务器停机）并离线永久存储在管理员的计算机或闪存驱动器上。
  • 使用自己的用户名和密码进行身份验证的非管理员员工
  • 如果他们有权限，他们可以从内存缓存服务器检索 key1
  • key1 解密存储的半私钥 key2a
  • key2a 和加密数据连同各自的插入 ID 一起发送到解密服务器
  • 解密服务器然后结合 key2a 和 key2b 来创建 key2
  • Key2 然后解密信息并将其发送回用户
  • 对于密钥轮换，解密的信息然后使用加密过程中概述的新 key2 对重新加密

完整的密钥轮换（从解密服务器启动）

我不确定这是否有必要，但这是我的想法。让我感到不舒服的一件事是，解密服务器的所有数据都将暂时未加密（至少在内存中）。同样，我必须让这台服务器免费访问来自主服务器的加密数据和密钥，这也可能会打开另一罐蠕虫病毒，如果这台服务器遭到入侵，基本上游戏就会结束。我也在下面的一个问题中解决了这个问题：

  • 解密服务器登录到主服务器并请求完整转储所有加密数据
  • 在解密服务器上生成一个新的key1密钥加密密钥对
  • 所有加密数据均使用旧密钥解密1
  • 为上一步中的每条解密数据生成一个新的 key2 对，并使用此密钥重新加密数据。这些被异或到新的 key2a 和 key2b 中。
  • 使用新密钥 1 重新加密的新密钥 2a
  • 新加密的数据数组、新的 key2a 和各自的 id 被发送回主服务器并直接存储到数据库中
  • 在主服务器上，新的 key1 被保存到内存缓存中
  • key1 也需要以某种方式发送给管理员，以便他们可以在 memcache 服务器出现故障时重新启动它。由于管理员应该拥有旧密钥 1，也许用旧密钥 1 加密新密钥 1，然后简单地通过电子邮件将其发送给管理员就足够了。

我不确定的几件事：

  • 使用 memcache 存储私钥加密密钥是否足够安全？如果没有，我对其他想法持开放态度。
  • 对于密钥轮换，定期轮换所有密钥（包括 key1 和所有密钥 2）是一种很好的做法，正如我在上面的“完整密钥轮换”部分中概述的那样，或者只是在使用时轮换 key2，因为每个密钥都是不同的 key2一块加密数据？

编辑 :: 要回答 DW 下面的问题，我不确定如何创建威胁模型，但我假设您基本上想知道我要保护什么。老实说，我不确定。从本质上讲，我希望只有授权的工作人员能够获得解密的数据，所以无论这需要什么，这都是我想要保护的。如果其中任何一个服务器受到威胁，我希望影响完全减轻或至少最小化。例如，如果有人要破解解密服务器，他们仍然需要加密数据和部分解密密钥。如果有人要入侵主服务器，他们将需要密钥加密密钥，如果服务器出现故障，该密钥将从内存中删除；如果服务器还在，

2个回答

有两种标准方法。

  1. 选项 1：将私钥存储在文件系统上。您只需将私钥存储在需要访问私钥的每台服务器上的文件系统中（可能具有文件系统权限以限制谁可以访问它）。您可以将其视为“不要出汗”选项。

  2. 选项 2：硬件安全模块 (HSM)。 您使用加密硬件安全模块 (HSM) 来生成和存储私钥。私钥由 HSM 生成，永远不会离开 HSM。签名和解密操作由 HSM 执行，而不是在软件中执行。

如何在这两种方法之间进行选择？第一个便宜又简单；它的主要缺点是，如果任何服务器受到威胁，那么您的私钥就是烤面包。HSM 更昂贵，尽管它们提供更高的保证：如果您的服务器被黑客入侵，黑客可能能够解密一些以前记录的流量或签署他们选择的一些消息，只要他们有权访问服务器，但他们没有t 学习私钥。将私钥存储在文件系统上意味着内部人员可能会窃取私钥；HSM 可防止内部人员窃取私钥。

听起来您提出了一个复杂的方案，试图部分解决在文件系统中存储私钥的一些问题，但我并不真正理解您的方案。我承认，虽然我并不真正理解你的提议或你想要完成的事情，但我对这样的计划是否有意义持怀疑态度。我过去对它们的经验是它们没有提供太多额外的安全性。他们主要提供了默默无闻，这掩盖了缺乏额外的安全性。我不知道这是否真的是对您的特定提案的准确总结。如果您想对您的特定提案进行更明智的分析，我建议您仔细描述 (a) 您试图防范的威胁以及您的威胁模型是什么，

我认为你的方案过于复杂。我看不出它提供了哪些安全优势。

  1. 如果攻击者破坏了 memcache 服务器，攻击者可以解密每个密文。（攻击者从 memcache 内存中学习 key1。然后攻击者可以学习存储的加密 key2a 并使用 key1 对其进行解密。然后攻击者可以将其与密文一起发送到解密服务器，这将有助于为您解密。 )

  2. 如果攻击者破坏了任何验证用户密码的机器，攻击者可以解密每个密文。攻击者只需修改身份验证逻辑，说“是的，密码没问题！”，然后攻击者就拥有了启动解密过程所需的所有访问权限。

  3. 如果攻击者攻破了管理员的机器，攻击者会学习到key2，这足以解密所有的加密数据。

基本上，与仅将密钥明文存储在单个服务器上并使用它进行解密相比，我没有看到明显的优势，而没有所有这些扭曲。

当然，我可能缺少一些东西。但这是你应该自己做的那种分析，然后再让别人分析你的方案。

一般建议：如果你想设计一个加密方案，那么清楚你想要实现的目标是非常重要的。这通常意味着，您需要了解安全目标（您要保护什么？）和威胁模型（系统需要抵抗哪些类型的攻击？）。明确地说明这一点通常很有帮助。然后，当您认为自己的方案可能是一个好主意时，下一步就是对其进行分析：对于威胁模型允许的每个威胁，它是否实现了您的安全目标？如果您不知道自己要达到什么目标，或者如果您不知道对手可能会做什么，那么您设计安全方案的可能性不大。

其它你可能感兴趣的问题
上一篇创建安全的软件开发环境 下一篇可以从操作系统安装 BIOS 恶意软件吗？