Crossing Boundaries: Evolution from DMZ in Google Cloud

《超越外围：从谷歌云的隔离区进化》 内容 03 09 全方位多层深度防御策略，适用于谷歌云 执行摘要 云范式转变：从边界到无处不在的控制 结论与战略建议 执行摘要 我们的分析得出结论，云中的非军事区（DMZ）是一种技术和哲学上的反模式。它未能利用云本身的安全能力，同时引入了不必要的复杂性和一种虚假的安全感。 企业从本地IT基础设施演变而来时，通常会部署一个非军事区（DMZ）这份白皮书探讨了在现代云架构中使用传统隔离区（DMZ）的适宜性，以及——具体而言——在使用谷歌云服务时的适用性。 现代方法 云防火墙，用于网络边界控制和基于IP的微分段 Kubernetes应用程序级微分段网络策略 必须在DMZ的安全意图和其历史实施之间做出关键区分。DMZ方法是在一个具有特定限制的传统世界中设计的，这些限制与本地数据中心相关。将这种方法提升并转移到软件定义的云环境中，从根本上误解了云网络和安全的本质。 •虚拟专用云（VPC）服务控制防止数据外泄 这个组合允许创建比任何传统DMZ实现更精细、可扩展和有效的安全策略。它与零信任模型相一致，并且是保障高价值工作负载的既定现代最佳实践。谷歌云本身的情况就是一个例证。金融服务业参考架构, 一个行业领域安全与合规至关紧要。 在这里，我们解释了DMZ的核心安全原则——将不受信任的流量与敏感的后端隔离开——通过多层次、与网络拓扑无关、云原生深度防御策略更好地实现。这种现代模式用细粒度、基于身份感知的普遍控制代替了网络边界的脆弱、基于位置信任，并将这些控制织入云平台的架构中。 采用这种现代策略将导致更优越的安全态势、更高的运营效率、更强的架构灵活性和未来创新的更坚实基础。 遗产DMZ范式：意图与局限性 要理解为什么传统的隔离区（DMZ）对于谷歌云来说不是一个合适的安全模型，我们首先必须分析其原始目的和潜在假设。隔离区是针对其时代的问题的一个合适且有效的解决方案。 在本地N层架构中DMZ的作用 The 多层次架构这是一种基础模式，逻辑上将应用程序划分为不同的功能层。最常见的是：表示层、应用（或业务逻辑）层和数据层。在传统的本地数据中心中，这些逻辑层部署到物理服务器或虚拟机（VM），并组织成不同的网络段。 非军事区（DMZ）作为保护该架构的主要安全机制而出现。根据定义，它是一个物理或逻辑子网络——通常被称为“边界网络”、“屏蔽子网”或“网络区域”——位于一个组织的内部、受信任的网络和外部、不受信任的网络（如互联网）之间。其目的是将组织的面向外部的服务（如Web服务器、邮件服务器或API网关）暴露给互联网，同时将它们与安全网络隔离开来，安全网络中驻有敏感的应用服务器和数据库。 该模型的安全性由以下因素加强：网络防火墙这充当着区域间的看门人。在常见的双防火墙设计中，第一个（外部）防火墙控制来自互联网到DMZ的流量，第二个（内部）防火墙控制来自DMZ到受信任内部网络的流量。这形成了一层层的防御；攻击者要想获取受信任区域中的“珍宝”，必须在攻破第二道更加严格的防火墙后才能得手。 非军事区的安全价值因此完全源于其能够加强边界交通检查关于这些粗粒度网络区域。这是一个从根本上解决的方法。网络拓扑. 值得注意的是，在这些传统网络中，外围防火墙限制了流量。在区域之间（又称南北）但同一区域（又称东西）内机器之间的流量通常不受限制。唯一限制基于IP的东西向流量的机制是，在允许流量返回同一区域之前，强制所有出站流量通过边界防火墙；或者额外在每个操作系统上部署和管理防火墙。 其次，内部用户和设备本身是可信的。 在安全边界内“信任”的假设成为了一个可以被利用的脆弱点，通常被用来将初始立足点扩展成全面的突破。此模型无法应对内部威胁或成功绕过初始边界防御的复杂攻击。信任被放在了网络上，非身份或行为它上面运行的作业量。 挑战基于边界的信任核心原则 建筑反模式：“将DMZ迁移至云端” The foundational philosophy of the DMZ model is that of a可防御的周界如果一个服务器位于内部网络中，它相对于位于防火墙周边区的服务器来说，本质上是更加可信的。这种模式存在两个关键的缺陷： 任何仅仅通过创建“DMZ子网”来在云中实施传统DMZ的提案，都代表了对云环境的基本误解。这种方法不仅效率低下，它还是一个架构反模式，未能利用云的原生优势，没有解决现代威胁，并提供了一种虚假的安全感。 首先，尽管南北交通（进入或离开网络的交通）在周边进行检查，东西向交通（在区域内横向移动的交通）通常受到的审查要少得多。一旦攻击者成功地攻陷了安全区内的某一台机器——例如，在非军事区的网络服务器——他们往往有权自由地在该区域内探测和攻击其他机器。 核心问题在于将云子网等同于传统的网络子网。在谷歌云中，VPC是一种全局资源，提供一个单一的、私有的通信空间，可以覆盖所有谷歌云区域。子网是区域资源，旨在在全球VPC中按区域组织和管理IP分配。它们不是安全边界。是的，可以在这些子网之间实施传统的防火墙配置，但在云的范式下这样做是多余的。 关键的区别在于，谷歌云中的安全控制与网络拓扑是分离的。VPC防火墙规则不会在子网边界应用；它们是每个虚拟机（VM）实例的虚拟网络接口上强制执行的状态规则。这意味着位于同一子网的两个VM可以通过防火墙规则完全隔离，而位于不同子网或甚至不同区域的两个VM则可以自由通信。因此，“安全”子网与“不安全”的DMZ子网的概念变得毫无意义。工作负载的安全态势由其附带的策略定义，而不是它所属的IP范围。. 这种在每个虚拟机之间控制交通的能力被称为微细分而不是将交通分割成只有区域间控制的区域，我们反而控制每台机器之间的交通，并且默认这样做。事实上，谷歌网络默认在每个虚拟机上应用“拒绝所有来自任何地方”的入站规则。谷歌的最佳实践是随后根据与虚拟机或特定服务帐户关联的标签应用额外的防火墙规则。这比基于IP的防火墙的传统方法更受欢迎。 这种微分段化方法并不仅限于云。例如，VMware在其NSX平台上集成了类似的分布式防火墙功能。 最终，“提升和迁移”DMZ架构将一个基于拓扑的安全模型强加到一个无拓扑感知的平台。这导致了一个更复杂、更难扩展且成本更高的架构，其安全性不如云原生服务所能实现。正确的做法不是复制旧的实施方式，而是利用云的优越工具能力，实现原始意图——隔离公共服务和保护敏感的后端。 通常，试图通过强制所有流量通过一对虚拟防火墙设备（网络虚拟设备，或NVA）在云端复制DMZ，是一种反模式。这种方法重新引入了云分布式架构旨在消除的瓶颈和单点故障。它增加了路由复杂性，在设备和额外的出口费用方面造成了显著的成本，并通过迫使流量通过集中的瓶颈点来降低性能。 云范式转变：从边界到无处不在的控制 从本地数据中心向云端的转变不仅仅是地点的变化；这是一种根本的建筑范式转变。物理硬件和网络布线的局限性被软件定义的基础设施所提供的灵活性所取代。这一新的现实要求安全思维的演变，从静态边界的脆弱概念转向全面的、以身份为基础的动态控制模型。 包含横向移动和微分段 谷歌云的软件定义全球网络 谷歌云网络的基础是VPC这是一个与传统的物理网络深深不同的构建。在谷歌云的背景下，VPC（虚拟专用云）和网络这两个词往往可以互换使用。 微分段是网络安全零信任在网络和应用层的关键组成部分。它是指将云环境划分为小的、细粒度的安全区域——甚至细到单个工作负载或容器——然后定义明确的策略来控制这些区域间的流量。 作为一个孤立的全球资源，谷歌云VPC提供子网、IP地址、路由和网络服务。资源我们-在不同的地理区域，例如一个网络服务器在中央1欧洲-西2然后是一个数据库在可以像在同一机架内一样，使用私有IP地址相互通信。 在一个具有平坦DMZ的传统建筑中，如果单个网络服务器被入侵，攻击者通常可以扫描整个DMZ子网，识别其他易受攻击的系统，并扩大他们的控制范围。DMZ模型假定横向移动既可能又可能发生，因此依赖于其边界的保护。微分段默认防止这种横向移动。被入侵的网络服务器存在于自己的微分段中，该策略明确指出它只能与特定的后端服务和协议进行通信。它被阻止，例如，尝试连接端口22（SSH）至其他网络服务器上或者数据库服务器 这个全球网络架构根本改变了建筑的可能性。它消除了复杂站点间VPN或对等区域网络的需求。在这个全球VPC中的子网纯粹是用于IP地址管理和逻辑组织的区域结构。安全作为软件定义的网络叠加层在此网络中实施，并在资源级别强制执行，使其独立于底层网络拓扑这种抽象是更现代、更有效的安全模型的关键推动力。 端口5432在. 这种方法有效地将攻击面从整个网络区域缩减到单个工作负载。它减少了渗透的影响，降低了轻微入侵升级为灾难性事件的概率。 拥抱零信任 零信任安全模型应运而生，成为失败的网络边界方法的合理继任者。它是对一个攻击者已进入网络的世界以及基于网络位置的信任是一种危险假设的直接回应。零信任的核心原则很简单：永不相信，永远核实这意味着默认情况下，无论用户、设备或应用是否在传统企业网络内部，都不可信。 全方位多层深度防御策略，适用于谷歌云 在谷歌云中，强大的安全态势并非通过单一的大型控制，如DMZ来实现。相反，它是通过组合多个互补的安全服务来构建的。这种多层次防御策略提供了针对各种威胁的全面保护，从网络级别的入侵到复杂的数据泄露攻击。 以下是保护托管在谷歌云上的现代应用程序所需的核心网络安全能力。 云防火墙 & 分层策略 Kubernetes 工作负载微分段 与传统数据中心外围防火墙仅提供南北向保护不同，谷歌云防火墙在网络的每一个网络接口提供状态化流量控制。因此，每个设备都位于自己的微范围内这允许进行极其细粒度的控制。例如，不是通过一条允许“web子网”到“app子网”所有流量的大范围规则，可以定义一条只允许foo-web-server-sa 现代工作负载并非以服务器为中心。如今，应用程序通常是容器化的，Kubernetes是容器托管和编排的黄金标准。这带来了额外的流量分段挑战，因为防火墙只对底层虚拟机的网络接口应用策略，而不会对在平台上运行的Pod应用策略。 foo网络服务器-sa从具有服务账户的虚拟机（VMs）给虚拟机foo-app-server-sa TCP端口8080使用服务账户在例如，这将安全策略与工作量身份联系起来，这是迈向零信任模型的基础步骤。 为了详细说明：应用程序托管在容器中。在Kubernetes中，容器部署的基本单位是Pod。Pod有自己的IP地址，但它们是短暂的，只存在于覆盖网络中。这产生了一个新的东西向考虑：集群中不断变化的Pod之间的流量。 这也意味着我们不再需要依靠基于IP地址的规则来处理谷歌云内部的流量。这在云环境中至关重要，因为在云中，工作负载通常是短暂的和弹性的，IP地址是动态的和短暂的。 这个挑战它假定东西向交通基本不受控制，并试图通过迫使东西向交通经过南北方向的边界来降低风险。这导致了一些反模式。 这种分布式、身份感知且可集中管理的防火墙系统消除了对专用瓶颈的需求；防火墙直接构建在网络本身的结构中。 反模式1 — 分离集群以模拟非军事区 在这，我们为前端和后端服务创建各自的集群。我们将前端集群视为传统的网络隔离区（DMZ），将后端集群视为可信任区域。 它存在几个不理想的原因： 1. 它允许每个集群中舱体之间的东西向自由交通，不会阻止集群内的横向移动。一个被破坏的前端服务可能成为攻击另一个前端服务的潜在攻击向量。 2.它强制所有前端到后端的流量穿越VPC网络，而不是停留在集群内部。这增加了额外的延迟和路由复杂性。 3.它创建了重复的集群，从基础设施角度和运营成本角度来看都是浪费且昂贵的。 Kubernetes并非为了这种方式而被构建。它被设计成应用程序的所有相关服务应驻留在同一个集群中，并利用Kubernetes原生机制来提供适当的网络安全隔离。 反模式2——每个租户分离的集群 这可以