我正在一个单独的项目中徘徊,并将我的连接字符串和几个 API 密钥添加到一个私有的 github 存储库中。
我认为这是私人的,所以它必须是安全的,但我不知道这是否是好的做法?最近,我创建了环境变量并将配置保留在本地 PC 上。但是,它仍然存在于 Git 历史记录中。
我应该费心删除它还是我只是偏执
?确保源代码中没有存储密钥是有意义的。你是否偏执完全取决于你。像所有安全问题一样,它归结为一个风险问题,您可以通过某人获得您的钥匙的可能性以及某人获得您的钥匙的影响来衡量。
首先看可能性,这将要求您与某人共享存储库。鉴于它是一个私有的GitHub存储库,基本上您正在寻找三个选项: 1. 您在合作者 2. 您公开回购 3. 您转让回购的所有权
现在考虑影响,关键是什么?有权访问密钥的人可以做什么?这对您来说是否是一种经济损失,即他们可以像您一样查询收费服务。或者数据丢失,他们可以从服务中获取您的信息吗?
在考虑了您需要决定的可能性和影响后,您是否可以接受这一点?对于大多数人来说,如果可能性低,影响低,那么他们就会接受。如果可能性很高,影响很大,那么他们就不能接受。归结为个人选择的灰色地带是中间地带。
如您所见,我们(StackOverflow社区(无法告诉您是偏执狂还是您有真正的问题。但是,我希望上述信息能帮助您为自己做出明智的决定。
如果您决定对此做点什么,您有两种选择:
- 重写存储库的 git 历史记录。通过重写 git 历史记录,您可以从存储库的历史记录中删除 API 密钥,而不会丢失项目中其他可能有用的历史记录。
这意味着有人从您的 git 历史记录中获取密钥的可能性会急剧下降。
- 更改 API 密钥。大多数服务将提供某种重新生成密钥的方法。如果没有,您可以联系服务支持并告诉他们存在密钥泄露的风险,然后他们应该为您更改密钥。
这意味着有人获得钥匙的影响几乎为零。
TL;DR:如果可以从HTML代码,代理等中轻松找到这些密钥,请不要打扰。
我反对将保护API密钥作为一般安全准则的想法。首先,让我们区分"密钥"和"秘密":
- 密钥:从客户端访问某些服务;
- 机密:从服务访问某些服务。
除此之外,它们几乎相同。通常,它们的寿命有限,可以旋转,并且不是人类可读的。尽管应严格控制机密,但其他 API 密钥并非如此,因为客户端根本不是安全环境。
要获得对服务器的访问权限,您需要利用漏洞,或从社会工程中获取管理员访问权限,等等。它不能保证成功。但是,您始终可以从其二进制文件或代码中找出客户端应用或网页的工作方式。此外,在网页上可以找到纯文本的另一个地方"保护"跟踪密钥有什么意义?如果可以从 Charles 代理轻松获得应用程序中的 AWS 密钥,为什么要对应用程序中的 AWS 密钥执行相同的操作?