在负载均衡器和 EC2 目标之间使用 HTTPS 有什么好处?

在负载均衡器和 EC2 目标之间使用 HTTPS 有什么好处?

我花了一些时间重构 AWS 中的负载平衡 Web 应用程序,以使其成为端到端 HTTPS,CloudFront->ALB->EC2。这主要是为了好玩,看看我是否可以做到。经过很多努力才使其工作正常,我现在想知道是否值得升级生产基础设施以以这种方式工作。目前在生产中,它只是前端和 CloudFront 与 ALB 之间的 HTTPS,但在 ALB 与 EC2 之间是纯 HTTP。

在应用程序负载均衡器和 EC2 之间使用 HTTPS 是否有任何实际好处。

我原本希望它能实现端到端的 HTTP/2,但我无法让它在 EC2 上运行,所以那部分必须是 HTTP1.1

有关设置的一些细节。

EC2 正在运行 IIS,Win2022。我有一个带有 UserData 的启动模板,可以对它们进行完全配置,包括为 IIS 创建自签名 SSL。

ALB 和 CloudFront 显然使用 ACM 作为证书。

该设置似乎很稳定,但我对为支持 ALB->EC2 HTTPS 而引入的复杂性并不完全满意。这意味着它现在有额外的 http 绑定用于健康检查,而不是只使用单个绑定用于流量和健康检查。

部署管道也变得更加复杂,需要额外的步骤来检索 SSL 证书以将其应用于 IIS 站点。

一个潜在的好处是,网站本身知道它正在通过安全连接运行,因此默认情况下会正确生成自引用 URL。不过,我找到的解决方法主要是通过手动更新应用程序代码中的服务器变量。

使用端到端 HTTPS 似乎被认为是一种良好做法,但我并不完全清楚为什么。除非这样做有一些特定的好处,否则我不想改变生产系统。

答案1

使用端到端 HTTPS 似乎被认为是一种很好的做法,但我并不完全清楚为什么。

现代安全思维是,您不认为您自己的网络/数据中心比您的 WAN 或常规互联网更值得信赖。

传统上,人们会在数据中心内(在您自己的网络的“安全”边界内)允许更宽松的安全标准。内部系统和用户都值得信任,隐含地期望它们是安全的,并且永远不会被滥用或恶意攻击。例如,人们只为跨越“安全”内部网络的边界和边界的连接添加了 TLS。

您当前的配置是在负载均衡器上终止 TLS,并使用纯 HTTP 进行负载均衡器和后端服务器之间的通信,这符合传统的世界观和安全概念。

如今越来越流行的安全理念是“零信任”和“无处不在的加密”,它抛弃了安全可信的内部网络/系统/用户的概念,而是在任何地方都应用同样严格的安全级别。

在云环境中,您没有自己的物理网络,但可能与云提供商的所有其他客户共享资源。
您希望云提供商没有恶意,并且可以信任不会窃听您的通信。您希望并期望您的(内部)流量的逻辑分离是强大的,并且您的数据也不能被其他客户拦截,但您在这方面获得的保证要少得多。
您可以通过不隐式信任(虚拟)内部网络的安全性并严格应用 TLS 加密来控制这些风险,对于从负载平衡器到应用程序服务器的流量,对于访问数据库的应用程序等。等等。


作为现实世界的类似物:

您的家位于封闭式社区,有安全围栏和门卫保护。也许您甚至有一个业主协会,负责审查潜在的新住户,并且只允许“合适的人”成为你的新邻居。

晚上以及离开家时您需要锁上前门吗?

在传统安全思维中:晚上你不需要锁门,因为你在封闭式社区里很安全,所有“坏人”都会被围栏和保安挡在外面。
而且你的邻居也不会是爱管闲事、随便闯进你家的人。

在现代安全思维中:是的当然,你会锁上前门,因为当(毫无疑问)围栏被破坏和/或警卫无法阻止“坏人”进入时,坏人就不能轻易进入每一户人家,而是仍然需要撬锁或强行进入,这样既可以延迟他们不必要的进入,增加被发现的几率,又可以减少他们可以入室盗窃的房屋数量。

相关内容