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

Question

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

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

因此，我想知道什么是最佳实践，可以让我的客户使用他们最喜欢的工具的 API，而不危及他们自己的帐户和客户数据（电子邮件等）的安全。我知道目前在数据库中使用这些清晰的数据启动我的网络应用程序是危险的。

我想了几个解决方案：

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

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

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

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

如果有人已经必须回答这个问题，或者知道如何解决它，我想得到启发！

注意：抱歉我的英语不好，我是法国人。

Answer 1

您提到的所有解决方案都有些有效，组合很可能是最佳答案。您的应用程序需要访问这些 API 密钥，因此黑客实际上不可能完全控制您的应用程序而不控制 API 密钥。完全控制是关键部分——你可能会让接近它们变得更加困难。

加密

您需要使用 AES 之类的方法对它们进行加密，而不是对其进行哈希处理。因为您需要能够解密它们并在向第三方发出的请求中使用它们。这将帮助您防止，例如。数据库泄漏 - 如果有人获取您的数据库，他们将必须破解加密才能获取它们（只要正确实施加密）。加密/解密密钥当然必须不在数据库中，否则整个事情就没有意义了:)

分离

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

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

结合上述内容将确保人们必须获得对您​​的应用程序（及其所有部分）的完全控制才能获取密钥、加密密钥并绕过您可能采取的任何其他保护措施。