在部署中如何添加用户机密而无需将其存储在源代码控制中

问题描述

在开发应用程序时，通常需要使用用户机密来实现功能。由于安全问题，这些凭据不应存储在源代码控制中。相反，它们需要由用户手动创建或通过部署脚本生成，其值与源代码分开保存。

用户希望了解在部署环境中安全地管理和访问这些用户机密的最佳方法。在确保敏感信息保持安全且在需要时对应用程序可访问的情况下，有哪些推荐的选项和最佳做法？

具体而言，用户想要了解以下问题：

1. 用于安全地存储和管理用户机密的常见策略或工具有哪些？
2. 在部署或运行时，如何安全地访问这些机密？
3. 是否有推荐的技术或模式，可以自动化机密管理和部署过程，同时最小化暴露敏感信息的风险？

本文将为您提供处理部署场景中用户机密的最佳实践、工具和技术的指导和见解。

解决方案

请注意以下操作可能因版本差异而略有不同，如果您使用的是特定云服务提供商的解决方案，需要查阅相应文档。

使用安全保管库（Secret Vault）

当前处理此问题的常用做法是使用安全保管库。这些库有不同的变体，例如 Azure Key Vault、HashiCorp Vault 或 AWS Secrets Manager。

您可以调用这些保管库来按需获取机密信息。这样做有助于实现“按需”获取机密信息，避免将其存储在配置文件中。

您的部署工具可能具有“敏感变量”功能（即不可检索或查看的变量）。但您也可以调用一般保管库来获取机密信息，因为保管库提供了一些额外功能，使在处理机密信息时更加方便。通常，这些保管库都提供 API 以便在部署和运行时访问机密信息（可能会受到某些服务限制）。

总结一下：
1. 处理机密的常见策略是使用安全保管库，而非将其存储在配置文件或源代码控制中。
2. 每个保管库都有关于访问的最佳做法，因此在选择解决方案时，请遵循其指南。通常可以通过权限控制（例如，IP 限制）来锁定访问。
3. 机密保管库的一个关键模式是定期（自动地）轮换机密信息。

请注意，实施安全措施，应用最小权限原则以及监视对机密信息的访问以便检测可疑活动，可以提高安全性。

针对.env文件的最佳实践

对于本地开发环境，您可以遵循以下最佳实践来处理 .env 文件：

1. 不要将 .env 文件提交到源代码控制中，只提交一个不包含机密信息的 env.template 文件。
2. 在本地开发时，将 env.template 复制到未跟踪的 .env 文件，并填写相关信息。
3. 在部署时，根据部署工具或从机密保管库中获取敏感变量，添加 .env 文件。

有些人可能会提交加密版本的 .env 文件，这种情况下，您仍然可以根据每个环境的情况替换其中的机密信息。

这样的做法有助于保持开发环境和部署环境的一致性，并确保机密信息的安全性。

希望本文能为您提供有关在部署中处理用户机密的最佳实践和技术的详细信息。如有任何进一步的问题，请随时提问。