security - 我应该如何存储由其他应用程序使用 Google Cloud KMS 生成的访问 token ?

标签 security encryption google-cloud-platform google-cloud-kms google-secret-manager

我正在构建一个 Node.js 应用程序,该应用程序从我需要访问的另一个应用程序接收长期访问 token 。我不想将这些访问 token 直接存储在数据库中,因为任何有权访问这些 token 的人基本上都可以用它做任何他们想做的事情。

我对 Cloud KMS 和此类系统总体来说是新手,但最近花了几个小时来学习它。这似乎是解决我的问题的理想解决方案,但我不完全确定应该遵循什么策略来存储这些访问 token :

  1. 我是否应该在 Cloud KMS 中存储加密 key 并将该加密 key 与 NPM 软件包(如 this one)一起使用将访问 token 存储在我的数据库中?
  2. 我应该将访问 token 直接存储在 KMS 中吗?我的假设是我将拥有一个 key 存储并且 key 每 14 天轮换一次。每当我收到访问 token 时,我只需对其进行加密并将其存储在 KMS 中。我只将密文存储在数据库中。当我需要从 KMS 访问访问 token 时,我使用密文对其进行解密。

以上哪项是使用 KMS 的正确方法?如果是选项 2,我还有其他问题:

  • 我可以使用单个 key 加密大量访问 token ,还是需要为每个访问 token 创建一个新 key ?
  • 如果我需要修改在 KMS 中加密的访问 token ,我可以简单地修改它还是需要销毁旧版本并再次加密?

感谢您的帮助!

最佳答案

我认为你最好的选择是使用 Node.js API provided by Google加密 token 并将生成的密文存储在数据库中。

当应用程序从其他应用程序接收到 token 时,它会使用 API 对其进行加密,并与数据库中的内容进行比较以查看其是否有效,这样纯文本 token 只有所有者才知道。

Can I encrypt a large number of access tokens with a single key or do I need to create a new key for every access token?

您可以使用相同的 key 加密任意数量的 token 。为每个 token 创建 key 很快就会变得难以管理,除非它们的 key 本身被泄露(很难想象只存储在 Google 中),否则不会有重大风险。

If I ever need to modify the access token encrypted at KMS, can I simply modify it or do I need to destroy the old version and encrypt again?

KMS 不会存储您的数据(无论是加密的还是纯文本的),它只是存储您加密或解密数据所需的 key 。

按照只存储加密版本的 token 的方法,当您需要修改一个 token 时,应该是这样的:

  • 客户端向您发送需要撤销的 token 。
  • 您的应用程序对其进行加密并将其与数据库中存储的 token 进行比较
  • 新 token 已生成(我理解是由您的客户端应用程序生成的?)
  • 它会发送到您的应用程序并对其进行加密
  • 旧版本的 token 已替换为新版本的 token
  • 客户端现在可以使用新 token ,因为它与之前的 token 具有相同的有效性。如果它尝试使用旧 token ,因为它不再位于数据库中,它将无法工作。

关于 key 轮换,当发生这种情况时,新 token 将使用新 key 进行加密。旧 token 仍然无法加密,因为您的旧 key 仍在 KMS 上,只是不再用于加密。 但是,如果您销毁了加密它们的 key ,那么它们将无法恢复。

关于security - 我应该如何存储由其他应用程序使用 Google Cloud KMS 生成的访问 token ?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48786660/

相关文章:

ruby-on-rails - 每次我尝试部署时,我都会得到 - (gcloud.preview.app.deploy) 错误响应 : [4] DEADLINE_EXCEEDED

c# - ASP.NET 和中间人

php - 在 PHP 中存储密码的哈希值

security - Tomcat 7.0.52 APR 1.1.29 native TLS 协议(protocol) session 重新协商安全漏洞 TLS SSL 中间人 CVE-2009-3555

JavaScript WebCrypto API unwrapKey

heroku - 在 Heroku 上使用 Google 的 TextToSpeech API

php - 限制对Docker容器内容的访问

c - 如何在 c 中使用 tiny-aes 128 库?

java.security.InvalidKeyException : Illegal key size - After Windows OS security patch

go - 在数据存储中存储长文本