【发布时间】:2020-04-05 03:42:57
【问题描述】:
我觉得我在这里问了错误类型的问题,因为它在 30 秒内无法通过 Google 搜索。请告诉我。
无论如何,我的environment.ts 和environment.prod.ts 都设置了用于后端和第三方服务的url 和api 密钥。但是我读到将 API 密钥保留在那里并不安全。我应该把它们放在哪里?如果确实在其他地方,最简单的方法是什么?
【问题讨论】:
我觉得我在这里问了错误类型的问题,因为它在 30 秒内无法通过 Google 搜索。请告诉我。
无论如何,我的environment.ts 和environment.prod.ts 都设置了用于后端和第三方服务的url 和api 密钥。但是我读到将 API 密钥保留在那里并不安全。我应该把它们放在哪里?如果确实在其他地方,最简单的方法是什么?
【问题讨论】:
如果我正确理解了您的问题,那么您将在此处查看两个潜在的关键误用点:
开发人员在开发应用程序时可能会意外使用生产密钥 - 这很容易通过将密钥存储在 CI 管道中(假设您有一个)并将正确的密钥注入到正确的环境配置中来解决.一些可能感兴趣的工具:Octopus、Hashicorp Vault。然后,开发人员将仅在其代码库中拥有开发密钥。请记住——如果你使用的是版本控制系统——仅仅删除你的生产代码并添加一个新的提交是不够的——有tools可以让你搜索你的提交历史以查找意外暴露的秘密,所以你必须换钥匙
用户可以对您的应用程序进行反向工程并从代码中提取密钥。这个更难解决,因为它在很大程度上取决于操作系统、版本以及您如何处理机密。通常,您希望完全避免在您的应用中存储秘密,而是在验证用户身份时获取它们。之后 - 您将利用您的目标操作系统 secure local store 功能(请记住,即使是 does not guarantee 100% protection)。对于第 3 方访问,请考虑通过您的服务器代理请求以隐藏密钥更多灵感可以在 here
UPD 为了澄清您对用户交互的担忧,请考虑以下简化的工作流程:
1) 用户向您的后端/authorise端点发出未经身份验证请求,该端点将检查用户名、密码并返回token1(最好JWT)
2) 您的应用将此 token1 存储在设备上的本地存储中 - 这是用户可以访问的唯一秘密,并且特定于该用户
3) 您的用户使用 token1 向您的/3rd-party-api-proxy
4) 您的服务器将验证步骤 3 中的 token1,并使用您从未公开的 token2 向第 3 方发出实际请求。
5) 您的第 3 方请求成功,您将数据返回给用户。
通过此流程,您的 token2 永远不会暴露,并且您始终知道哪个用户请求访问 3rd 方 API(您可以添加日志记录、审核等)。互联网上有很多关于如何构建这个东西的文章,我在这里只是概述了非常基本的概念,希望这能给你一些思考。
【讨论】: