如何以安全的方式存储我的客户的 API 密钥？

Question

我正在开发一项 SAAS 服务，允许我的客户连接第三方电子邮件工具（例如 MailChimp）。因此，我要求输入与所需服务关联的 API 密钥，以允许在他们的帐户上自动执行某些操作。

为此，我在他们的数据库中记录了他们的密钥 API，并且连接完成。但是从安全的角度来看，如果我的数据库被黑客入侵，尽管在安全方面采取了所有的倾向（准备好的请求等）......这些都是我的客户的 API 密钥，以及他们的电子邮件地址拥有可以检索、使用、转售的客户......因为我连接的工具本质上允许存储联系人、组织和发送电子邮件。

所以我想知道在不危及他们自己的帐户和客户数据（电子邮件等）的安全的情况下，让我的客户使用他们最喜欢的工具的 API 的最佳做法是什么。我知道目前在数据库中以明确的形式启动我的 Web 应用程序会很危险。

我想到了几个解决方案：

• 加密数据库中的 API 密钥，但我看不到如何测试它们（解密），因为它不像密码？

• 将 API 密钥存储在托管在其他地方的不同数据库中，但加密问题仍然存在......不是吗？

• 使用 OAuth 流：看起来很方便，但我想通过 API 连接的所有服务都不提供此功能，我什至不确定这是否真的适合我。

• 我打算在亚马逊网络服务上托管我的 SAAS，我看到它提出了一项名为“KMS”密钥管理存储的服务，但我不知道它是否真的再次适应了我的问题......

如果有人已经回答过这个问题，或者知道如何解决，我希望得到启发！

注意：对不起，我的英语不好，我是法国人。

Answer 1

您提到的所有解决方案都有些有效，并且组合很可能是最佳答案。您的应用程序需要访问这些 API 密钥，因此黑客实际上不可能完全控制您的应用程序而不获得对 API 密钥的控制权。完全控制是关键部分 - 你可以让他们更难获得。

加密

您需要使用 AES 之类的东西对它们进行加密，而不是散列它们。因为您需要能够解密它们并在您对第三方的请求中使用它们。这将帮助您防止，例如。数据库泄漏 - 如果有人得到你的数据库，他们将不得不破解加密才能得到他们（只要加密得到正确实施）。加密/解密密钥当然必须不在数据库中，否则整个事情没有意义:)

分离

不同的数据库也很有意义 - 如果有人转储您的主数据库，他们将无法访问 API 密钥数据库，并且必须更深入地了解应用程序才能访问该数据库（理想情况下将是一个完全独立的数据库服务器，只能从您的申请）。

解决方案的架构也很重要 - 您可以将一台服务器伪装成面向 Internet 的 Web 接口，并通过一些有限（尽可能）的 API 与不面向 Internet 的后端服务器通信以降低攻击面。然后只有后端服务器可以访问密钥数据库并执行对第 3 方的请求。现在攻击者必须跳过几台服务器才能接近密钥。

---

结合上述内容将确保您必须完全控制您的应用程序（及其所有部分）以获取密钥、加密密钥并绕过您可能设置的任何其他保护到位。