如您所知,带有环境变量的文件(通常具有带或不带文件名的扩展名.env
)通常不会被版本控制系统跟踪,以防止数据库密码等数据泄露。SLL 密钥和证书文件怎么样?我请你分别考虑本地开发、分期和制作的情况。
关于这个话题的思考过程
本土化发展模式
如果在本地开发模式下您使用自行颁发的(例如,使用mkcert)SSL 密钥和证书,那么通常我认为没有理由将它们排除在版本控制系统的跟踪之外。它似乎不包含任何敏感数据。
强制每个团队成员自己颁发证书的唯一可能原因是 mkcert 中可能缺少强制浏览器信任已颁发证书的命令。如果确实没有这样的命令,那么每个参与者都必须自己运行该命令mkcert
,这不仅会颁发密钥和证书,而且浏览器也会信任它们。在 Windows 上没有 mkcert 的情况下执行此操作并不容易(在我提出问题时我无法做到这一点)。
根据评论更新
正如@andreymal 评论的那样,
如果您将自行颁发的证书添加到受信任的浏览器中,那么泄露其私钥将允许攻击者发起中间人攻击,因此非常危险
我希望这不会成为在本地开发模式下仅使用 HTTP 协议(而不是 HTTPS)的理由。
生产
我不确定,但我认为生产模式的 SSL 密钥和证书是不应泄露的秘密信息。有一定的可能性,它们也可以使用浏览器开发者模式作为 CSS 或 JS 文件进行一般查看,但这又是一个假设。
与本地开发模式下每个团队成员都可以拥有自己的自行颁发的 SSL 密钥和证书不同,在生产模式下,每个人都会有一个密钥和一个证书(很可能由授权组织以可报销的方式颁发)。如果是这样,它们将不得不被排除在版本控制之外,并以其他方式在团队成员之间转移。
根据评论更新
有人提出这样的问题:如果理论上一两个生产服务器管理员知道就足够了,为什么团队成员应该了解生产 SSL?我的答案是:根据项目组装和部署的自动化的组织方式,有时在源代码文件中拥有 SLL 密钥和证书会很方便。
首先值得警惕的是,只有生产服务器的管理员才应该知道 SSL 密钥。我并不是说这是错误的,但在这种情况下,当只有一两个团队成员拥有 SSL 密钥和证书时,可能会出现问题。例如,管理员没有上班,但需要发布应用程序修补程序。或者应用程序运行所需的文件分散在团队成员中而不是组织在一起。
再说一次,我并不是说每个人都应该这样做,但我将项目收集在一个文件夹中,该文件夹中放置了应用程序在服务器上工作所需的所有内容,特别是 ssl 密钥、证书和环境变量文件:
因此,构建项目后,剩下的就是以一种或另一种方式将文件发送到 VPS 并docker compose build
在 VPS 上重新启动它。
我知道有各种各样的高级部署方法,特别是 GitHub 上的 CI/CD 或各种 AWS 工具。例如,您可以使用 AWS 组织环境变量的注入,而无需使用 .env 文件 - SSL 可能有类似的东西。但所有这些都将开发商与特定的供应商联系在一起。有时这是合理的,但当最初只有一个使用裸 Ubuntu 的 VPS 时,仍然必须有某种方法来有效地组织部署。
生产中的SSL私钥是一个非常机密的东西,其安全性保证了中间人攻击的不可能,正如评论中已经写的那样。版本控制系统不是需要这些东西的地方。
理想情况下,应用程序轮廓和 Web 服务器轮廓应该不同并且彼此分离。例如,应用程序位于您的位置,
/var/www
与 ssl 相关的所有内容都位于/etc/ssl
根本无法通过 http 直接访问的位置,并且 nginx、apache 或任何其他 Web 服务器从那里获取它。那些。整个事情应该与应用程序项目(站点/服务)分开存储。您可以通过高级方式管理此类配置,例如通过 docker 和kubernetes或puppet,或者手动或使用具有访问权限的专门授权的 DevOps 团队通过 ci/cd 脚本来管理。而开发者甚至可能没有sudo权限,只能写入项目文件夹。
您还可以在 Dev 和 Prod 上通过certbot使用 LetsEncrypt (如果不需要更可靠的 CA、Mintsifrah 等)。那么你就根本不需要考虑 ssl 了。
但无论如何,加密流量是 Web 服务器的任务,而不是其上运行的应用程序的任务。
顺便说一句,对于开发站,我们使用本地部署的 CA 颁发的证书,该证书的根证书被添加到所有工作 PC 上的域策略信任的证书中。这样就不需要手动添加一些东西来简化开发。
我认为规范的答案可能是:如果只有那些被允许查看密钥/证书的秘密部分的人被允许进入版本控制系统,并且您可以相对可靠地保证(在密钥的整个生命周期内)版本控制系统不会被未经授权的人和/或攻击者渗透,那么您可以存储它。当然,需要做一个审计系统,也许需要做一些渗透测试。同样的规则也适用:知道秘密的人越少,它(通常)保存得就越安全。
我认为@Pak Uula 回答了所有问题。