【问题标题】:Using an HSM or Key vault service like Azure Key Vault使用 HSM 或 Key Vault 服务,例如 Azure Key Vault
【发布时间】:2020-05-04 18:21:05
【问题描述】:

我首先要说我理解希望使数据尽可能安全。

我有一个应用程序,我想加密所有可用于识别数据库中某人的个人信息。

所以我读到将密钥与数据存储在同一台服务器上是很糟糕的。好的,单独的服务器,没问题。然后我读到将密钥放在应用服务器上的代码中(远离数据)是很糟糕的。人们说存储加密密钥的正确方法是使用 HSM 或像 Azure Key Vault 这样的 Key Vault。好的,我同意这一点,但如果我的 代码 可以访问 HSM 或 Azure Key Vault(它需要拥有它才能解密或访问所有数据......

如果我的代码从应用服务器被盗(这就是为什么将密钥存储在代码本身中会不安全) 为什么攻击者不能使用我的代码用来解密来自 HSM 的数据的相同方法或密钥库?

假设仅将密钥存储在代码本身内部是不安全的。拥有可以解密代码中数据的方法或函数有什么不同?这基本上会告诉攻击者如何从保险库中获取密钥,不是吗?

使用 HSM 或 Keyvault 可防止的额外向量或层是什么?

我不介意支付和实施额外的层。我真的很好奇,因为我真的看不出有什么区别。

【问题讨论】:

    标签: database security encryption cryptography hsm


    【解决方案1】:

    我认为您的问题主要是关于保护软件与硬件密钥管理解决方案中的密钥。以下链接提供了有关它们差异的有用信息:

    Usage of software/hardware-backed Android Keystore and possible security/usability drawbacks

    https://www.itprotoday.com/iaaspaas/software-vs-hsm-protected-keys-azure-key-vault

    【讨论】:

      【解决方案2】:

      如果我正确理解了您的问题,那是因为应用程序永远不会看到实际的加密密钥。 HSM 只公开原始加密操作,但从不公开密钥本身。

      因此,攻击者需要登录到您的“应用服务器”才能执行操作,这(希望)相对容易撤销/拒绝。如果您拥有可用于代码本身的密钥,那么他们可以继续使用任何现有加密数据上的密钥,直到在轮换新密钥后重新加密为止。这也有相关的保证困难,例如你怎么知道攻击者在轮换发生时没有操纵某些数据

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2019-12-01
        • 2019-06-09
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多