保护多个 Web 应用程序的数据库密码的最佳实践?

信息安全 Web应用程序 数据库 哈希公司保险库
2021-08-22 23:29:13

我正在升级一个“遗留”基础设施,其中使用了少数 PHP、Rails 和 Perl (CGI) 应用程序。从历史上看,这些应用程序是使用作为程序变量散布到所有源代码中的数据库凭据编写的。

我们正在讨论改变这种情况的方法。一项提案建议将所有数据库凭据移至 Apache/etc/apache2/envvars文件。另一个建议建议使用 Hashicorp 的保险库(不太完全理解这个野兽是如何工作的)。

envvars方法似乎更好,但我认为这意味着任何受感染的应用程序都可以完全访问任何其他应用程序的数据库凭据。我想知道一个更好的方法是否会包括对应用程序的某种分区(不好的例子,但它确实发生了)Bob 的受损“待办事项列表”不会通过 Apache 环境变量危及 HR 应用程序的凭据。

避难所……很奇怪。据我所知,它会在数据库中创建临时数据库凭据。我不完全了解它是如何工作的,所以我无法判断它是否合适。

保护 Web 服务器上的数据库凭据的最佳做法是什么?任何事情都比将它们留在源代码中要好,但是如果我们要在这里进行重大更改,我宁愿不必因为误解而再次这样做。我已经查看了此处此处的链接,对此几乎没有讨论。

2个回答

您可以使用许多工具/系统来保护生产机密。他们中的许多人将利用某种 KMS(密钥管理系统)和/或 HSM(硬件安全模块)来存储主密钥,应用程序可以使用这些主密钥来访问生产环境中的机密。查看一些出色的开源解决方案

例如,Lyft 的Confidant是一个秘密管理系统,将加密的有效负载存储在 DynamoDB 中。主密钥由 AWS KMS 管理和访问控制。HashiCorp Vault 也是一个不错的选择(但也许功能集太全面了)。它提供了类似的功能集以及更高级别的功能,例如自动 mysql DB 凭证轮换。您应该能够根据您的用例和生产设置进行选择。

Vault 是一个很好的解决方案,您希望管理凭据并确保它们的安全,因为它内置了完整的租约和日期/时间限制。

在这种情况下,您只是希望存储 dB 凭据 envars 是相当标准的,只是不要将 envar 文件提交到源代码控制。

还要记住,所有这些数据库都有绑定的接口,因此确保正确绑定到本地主机或同样受防火墙保护/过滤的固定 IP 范围同样重要。这样即使 dB PW 暴露,他们仍然无法远程访问。