什么时候适合 SSL 加密数据库连接?

信息安全 加密 tls 网络服务器 数据库
2021-09-06 10:53:27

假设我有一个我设置的 Web 服务器,然后是一个数据库服务器。

但是,它们在本地通信并且位于防火墙后面。在我看来,这里不需要 SSL,对吧?

使用 SSL 加密数据库连接的唯一时间是在与位于其他地方的数据库服务器远程通信的服务器中存在的 Web 服务器之间,对吗?

在提倡使用 SSL 保护数据库连接之前,我已经看到了安全指南,但对于何时使用它却含糊其辞。

4个回答

看起来这个问题的前两个答案或多或少都强烈建议打开 SSL,但我想提出一个不同的推理角度(尽管我不建议不要打开 SSL)。

评估您是否需要 SSL 的两个关键点是 (a) SSL 保护您免受什么攻击和 (b) 线程模型是什么:列举潜在威胁。

SSL/TLS 保护客户端(在本例中为您的 Web 服务器)和服务器(在本例中为您的数据库服务器)之间的信息传输不被中间网络上的任何人篡改和窃听(包括能够访问那些两台机器)。

要评估 SSL 是否有用,您需要假设攻击者能够执行 SSL 旨在保护您免受攻击的攻击。也就是说,攻击者需要能够嗅探网络或任何一台机器上的数据包。

  • 如果有人能够从数据库服务器嗅探数据包,他们很可能拥有对该服务器的 root/admin 访问权限。在那个阶段使用 SSL/TLS 没有任何区别。

  • 如果有人能够在网络服务器和数据库服务器(不包括那些机器)之间的网络上嗅探数据包,则使用 SSL/TLS 将阻止他们查看/更改应用程序内容。如果您认为这有可能,请打开 SSL缓解这种情况的一种方法是在 Web 服务器上使用两个网卡:一个连接到外部世界,一个连接到 DB 服务器所在的内部 LAN(没有其他机器,或者您可以将它们都视为一台更大的机器)。构成整个网络农场或集群的这个网络(不管你想怎么称呼它)将在物理上是分开的,并且只有一个来自外部的入口点:网络服务器本身(反向代理头节点的原理相同)。

  • 如果有人能够在头节点(Web 服务器)本身上嗅探数据包,他们很可能在那里具有 root 访问权限(由机器上的非 root 用户运行的进程,不应该能够读取包不适合他们)。在这种情况下,无论如何你都会遇到大问题。

    我在这里怀疑的是,在这种情况下,启用 SSL 是否真的能保护你很多。

    在 Web 服务器上具有 root 访问权限的人将能够读取您的应用程序配置,包括数据库密码,并且应该能够合法地连接到数据库服务器,即使使用 SSL。

    相反,如果您确实假设这可以保证使用 SSL(因为可能更难查看进程实际执行的操作,而不仅仅是查看网络,即使您对计算机具有 root 控制权),这意味着您还希望转向 localhost 通信(例如,如果您的 Web 服务器上有其他服务,或者在 DB 服务器和 Web 服务器都在同一台机器上的情况下)。

过于谨慎不一定是坏事,但是您必须将问题放在攻击者可以针对安全措施 (SSL) 保护您的内容进行攻击时还可以做什么的背景下提出问题,以及一旦处于这个位置,这种安全措施是否会阻止他们实现目标。

我认为那里的窗口实际上很窄(假设您的后端网络在物理上确实是安全的,而不仅仅是通过许多机器之间的某些防火墙)。

当包含数据库服务器和客户端的本地网络可能包含其他进程时,您应该加密两者之间的连接。

这几乎总是如此,因为即使您假设本地网络是不可穿透的(您不应该如此),除了数据库客户端和服务器之外,通常还有

  1. 需要能够登录并修复问题或进行更新的管理员
  2. 需要抓取没有敏感数据的文件并将它们移动到其他地方的日志收集器
  3. 需要复制数据库内容以进行异地备份或将大型低敏感性表提供给数据挖掘系统的复制器
  4. 需要检查其他人是否还活着的监视器

其中,只有复制器需要访问包含敏感数据的表,但这些过程中的任何一个都可能被 IT 部门内的不良行为者破坏。

加密所有携带敏感数据的渠道可以让诚实的人保持诚实,为您提供深度防御,并在出现问题时帮助您缩小搜索范围。

请记住,与您的服务器在同一网络上的任何人都可能能够嗅探流量或执行中间人攻击。SSL 应该防止这种情况发生,假设它设置正确。您还应该在数据库服务器上设置防火墙,并且只允许来自受信任 IP 地址的连接。

我的建议是打开它,然后仅当您认为它会导致性能(或其他)问题时才将其关闭。这样,您就大大减少了攻击向量。

实际上,通过网络进行 SSL 加密的开销将是最小的,尤其是与处理 SQL 查询的负载相比时。通过优化查询和服务器性能配置,您将获得比禁用 SSL 更高的性能。

假设我有一个我设置的 Web 服务器,然后是一个数据库服务器......在本地通信并且在防火墙后面

撇开这种架构在可用性方面很糟糕的事实不谈……

  • 您是否信任“防火墙后”的所有人和一切?
  • 你相信你的防火墙是完美的吗?
  • 您能否预测您将永远不需要远程连接来支持更高的可用性、迁移您的数据中心或执行备份?
  • dbms 的默认身份验证机制是否如此安全以至于无法被破坏?
  • 您是否有确保数据库凭据不会受到损害的部署过程?

如果您对其中任何一个的回答不是肯定的,那么您可能会受益于使用适当配置的 SSL 连接的额外保证。即使不依赖持久连接,性能成本也可以忽略不计(尽管通过持久隧道路由流量也可以完全消除这一点)。归结为简单地确定配置 SSL 的成本(几个小时的工作)是否超过了责任。