2018年9月18日 NIC JACKSON
网络分割是限制网络入侵影响的一种高效策略。但是, 在诸如群集调度程序这样的现代环境中, 应用程序通常会在没有操作员干预的情况下启动和重新启动。这种动态资源调配会导致不断变化的 IP 地址和应用程序入口端口。使用传统的防火墙和路由方法对这些动态环境进行细分可以在技术上具有挑战性。
在这篇文章中, 我们将研究这种复杂性以及服务网格是如何成为现代动态环境中安全网络通信的潜在解决方案的。
动态环境
我们先来定义一下动态环境的含义。最简单的情况是, 动态环境是应用程序和基础结构经常发生更改的环境, 要么是通过手动个更改常规部署和基础结构，要么就是在没有操作员干预的情况下触发大小自动调整或实例自动替换。像 HashiCorp Consul或 Kubernetes 这样的调度程序展示了这种行为, 就像许多云提供商提供平衡自动缩放组的自动冗余功能。但是, 这种效果不仅限于云环境, 任何平台 (如 vSphere 配置在高可用模式下) 也可以归类为动态环境。
网络分割
我们还需要澄清为什么网络分割对网络安全有很高的价值。传统的网络分割主要是使用外围防火墙实现的。此方法的问题在于受信任区域是平坦的。它只需要一次入侵就能获得对网络的广泛访问, 而网络越大, 入侵检测的机会就越有限。
随着细粒度网络分割, 网络被分成许多较小的网络, 为的是在发生入侵的时候能减少爆炸半径,。此方法涉及开发并执行某规则集, 以控制特定主机和服务之间的通信。
每个主机和网络应该被分割和隔离在最低的水平, 这个是可以实际实现的。路由器或3层交换机使用诸如虚拟 LAN (VLAN) 或访问控制列表 (acl) 等措施将网络划分为不同的较小网络。网络防火墙则是为了过滤各小块网络之间的网络通信, 而基于主机的防火墙则主要负责过滤来自本地网络的通信来添加额外的安全性。
如果您在基于云的环境中运行, 则通过使用虚拟私有云 (VPC) 和安全组来实现网络细分。虽然交换机是虚拟化的, 但将入口规则和 acl 配置为分段网络的方法主要与物理基础结构相同。
服务细分
在网络细分涉及保护区域间的通信时, 服务分割确保同一区域中服务之间的通信安全。服务细分是一种更细化的方法, 尤其与多multi-tenanted环境 (例如, 在单个节点上运行多个应用程序的调度程序) 相关。
实现服务细分取决于您的操作环境和应用程序基础结构。服务细分通常通过软件防火墙的配置、软件定义的网络 (如应用调度程序使用的覆盖网络) 以及最近出现的通过利用服务网格来实现。
与网络分割一样, 应用最小特权原则, 只允许在有明确意图允许此通信的时候允许服务通信。
网络分割与动态环境问题
当我们试图在动态环境中实现此方法时, 存在许多问题:
应用程序部署与网络配置断开连接
当使用自动缩放组部署应用程序并创建新实例时, 通常会动态地从预先配置的块中分配 IP 地址。这个特定的应用程序很少会被孤立地运行, 需要访问在同一网络段中运行的服务, 以及潜在的另一个网络段。如果我们对网络安全采取了强硬的方法, 那么这两段之间就会有严格的路由规则, 这两个部分只允许预定义列表上的通信。除此之外, 我们还将在上游服务上配置主机级防火墙, 这将只允许特定的通信。
在静态的世界中, 当应用程序部署到已知位置时, 这是更简单的解决办法。可以在部署时更新路由和防火墙规则, 以启用所需的访问权限。
在动态的世界中, 存在断开连接的问题, 应用程序独立部署以配置网络安全和分配的 IP 地址, 甚至潜在的端口都是动态的。通常有一个手动更新网络安全规则的过程, 这会减慢部署速度。
在现代调度程序中调度应用程序
网络分割的目标是在逻辑上划分网络, 以减少爆炸半径。极限来说, 每个网络段只包含一对需要通信的服务。这就形成了服务细分的概念, 在这里我们管理对服务层的访问。随着服务级别的细分, 我们关注服务之间的交互, 而不管它们在网络上的位置。如果您在像 Kubernetes 或Consul这样的调度程序上运行应用程序, 利用覆盖网络是配置服务细分的常用方法。配置叠加比管理多个网络路由和防火墙规则要简单得多, 因为在应用程序位置发生变化时, 叠加通常会自动重新配置。我们需要考虑调度程序通常是更重要的基础结构部署的一部分。
在这种情况下, 我们还需要考虑调度程序内部的应用程序如何与其他网络服务通信。例如, 您有一个100节点群集, 一个应用程序实例需要与另一个网络段中的服务进行对话。在调度程序中运行的应用程序可以在100个节点中的任何一个上运行。这使得确定哪些 IP 应该列入白名单是有挑战性的。调度程序通常会动态地在节点之间移动应用程序, 这会导致一直产生更新路由和防火墙规则的需求。
现代环境由VMs、容器、无服务器功能、云数据存储等组成。这种复杂的基础结构对管理网络安全构成了重大挑战。
为了防火墙和路由规则配置网络级安全性, 以及为了覆盖网络配置调度程序级别安全性有助于提高整个系统的安全性。但是, 我们必须在两个独立的区域中管理安全配置。在操作上, 我们还有两种截然不同的方法来实现所需的配置。这两个要求大大提高了管理应用程序安全性的系统复杂性和操作开销。
这种复杂性的一个不幸的副作用可能是安全被放松了, 网络分割被简化为路由规则的块, 而不是绝对地址。整个群集被允许路由, 而不仅仅是运行特定应用程序的节点。从服务的角度来看, 对本地网络段应用太多的信任。从安全的角度来看, 这并不是最好的选择, 因为增加了应用程序的攻击面, 所以需要一种一致且集中的方法来管理和理解网络和服务细分。
基于意向安全的服务细分
解决复杂性和提高网络安全性的方法是, 删除配置基于位置的安全规则的需要, 并移动到基于意向的模型。基于意向的安全性构建了有关标识而不是位置的规则。例如, 我们可以定义一个意向, 说明前端服务需要与付款服务通信。
通过意图定义网络分割可以缓解传统网络分割的复杂性, 并允许更严格地控制网络安全规则。出于意向, 您在应用程序级别描述安全性, 而不是网络位置级别。
例如, 如果我们有以下基础结构:
为了启用 "服务 A" 到 "服务 B" 通信, 我们需要在两个段之间创建路由规则。必须创建防火墙规则, 以允许从 "服务 A" 实例进行访问。
此配置总共有9条规则:
- 9x 服务 A 和服务 B 之间的防火墙规则
考虑当 "服务 A" 实例被替换时的影响, 并记住这不仅是由于失败, 而且是持续集成。需要再次更新这些规则, 删除的实例详细信息将需要被删除, 并添加新的实例详细信息。
现在考虑通过基于意向的安全性来控制路由的方法。
此配置将导致单个意图:
- "服务 A" ➡️ "服务 B",
更改运行实例的比例或位置不会更改该简单规则。
使用服务网格可以实现基于意向的安全性。服务网格由一个中央控制平面组成, 它允许您通过使用意向而不是网络位置来集中配置网络和服务细分, 并且数据平面提供路由和服务发现。这两个组件一起几乎可以完全替换复杂路由和防火墙规则的要求。
使用基于身份的授权, 数据平面只允许由这些意图定义的服务之间的通信, 而且由于意图是由控制平面集中管理的, 因此单个更新会重新配置整个网络。
意图对传统网络分割的好处
服务意图大大简化了为服务通信提供安全服务的方法。无论我们的应用程序是在虚拟机中运行, 还是在调度程序上, 或者是云管理的数据存储区, 我们都可以采取集中的方法。
由于服务网格中的所有通信都是代理的, 所以网络路由规则被大大简化。可以将通信流限制为单个端口的端口, 或非常窄的范围和主机级防火墙, 只需要将其配置为允许在已知的代理端口上进行侵入。
在服务网格中, 连接通过相互 TLS 进行身份验证, 因此即使无管理应用程序获得对网络的访问权, 如果没有有效的标识和身份验证, 它将无法与在主机上运行的开放代理端口通信。
最后, 使用单一的集中规则定义服务安全性的概念更简单, 更易于实现。
我们认为, 服务细分是确保数据中心安全的重要步骤, 特别是在现代云环境中。我们最近引入了 "Consul Connect", 它增加了对Consul的分割能力, 使其成为一个完整的服务网格。你可以在这里阅读关于这一声明的更多信息https://www.hashicorp.com/blog/consul-1-2-service-mesh, 了解更多关于Consul的信息在这里https://www.consul.io/.