本文旨在梳理零信任架构中的安全理念、应用场景等。

info

本文之前在公众号上发过,这里补充完善一下

什么是零信任

随着产业数字化不断升级，企业资源逐渐向云端与移动端迁移，旧有边界防御的安全体系难以为继，在端、网、云协同办公环境的的安全需求下，“零信任”安全的概念日渐火热。

零信任（Zero Trust）既不是一门新技术也不是新产品，而是一种安全理念。

传统网络安全架构默认网络安全即是边界安全。通过在网络边界验证用户身份，如果用户验证通过即为“可信”，即可进入网络内部。此时已经接入的设备具备大量资源的网络访问能力，往往成为入侵的第一道跳板，如邮件IM钓鱼、社工间谍、利用IOT入侵、高级APT木马、员工失误等。

2010 年，著名研究机构 Forrester 的首席分析师 John 正式提出了零信任这个术语，明确了零信任架构的理念，该模型改进了耶利哥论坛上讨论的去边界化的概念，并提出三个核心的观点：

  1. 不再以一个清晰的边界来划分信任或不信任的设备
  2. 不再有信任或不信任的网络
  3. 不再有信任或不信任的用户

零信任摒弃边界概念，默认所有人、设备和访问请求均不可信任，将访问控制细粒到具体的人和设备，对其进行身份验证和细粒度的权限管控。可以说零信任实际上是一项网络安全战略计划，通过摒弃组织网络架构中的信任概念来阻止企业内部的数据泄露。

2013 年，国际云安全联盟（CSA）成立软件定义边界（SDP）工作组。SDP 作为新一代网络安全解决理念，其整个中心思想是通过软件的方式，在移动和云化的时代，构建一个虚拟的企业边界，利用基于身份的访问控制，来应对边界模糊化带来的粗粒度控制问题。

2014 年，谷歌基于内部项目 BeyondCorp 的研究成果陆续发布 6 篇相关论文，介绍零信任落地实践。BeyondCorp 的设计采用了零信任的思想，假设所有网络都不可信；以合法用户、受控设备访问为主；所有服务访问都要进行身份验证、授权加密处理。

2017 年，Gartner 在安全与风险管理峰会上发布持续自适应风险与信任评估（Continuous Adaptive Risk and Trust Assessment, CARTA）模型，并提出零信任是实现 CARTA 的初始步骤，后续两年又发布了零信任网络访问（Zero-Trust Network Access, ZTNA）市场指南（注：SDP 被 Gartner 称为 ZTNA）。

2018 年，Forrester 提出零信任拓展生态系统（Zero Trust eXtended, ZTX）研究报告，将视角从网络扩展到用户、设备和工作负载，将能力从微隔离扩展到可视化、分析、自动化编排，并提出身份不仅仅针对用户，还包括 IP 地址、MAC 地址、操作系统等。简言之，具有身份的任何实体包括用户、设备、云资产、网络分段都必须在零信任架构下进行识别、认证和管理。

2020 年，美国国家标准技术研究所（NIST）发布的《SP800-207: Zero Trust Architecture》标准对零信任架构 ZTA 的定义如下：利用零信任的企业网络安全规划，包括概念、思路和组件关系的集合，旨在消除在信息系统和服务中实施精准访问策略的不确定性。该标准强调零信任架构中的众多组件并不是新的技术或产品，而是按照零信任理念形成的一个面向用户、设备和应用的完整安全解决方案。

2021 年，美国总统拜登发布行政命令，向云技术的迁移应尽可能采用零信任架构，并要求所有政府部门在60天内制定实现零信任架构的计划。这是美国首次以行政命令的方式，明确要求用零信任迭代过时的联邦网络安全模型。

2022 年，美国国防部正式公布《零信任战略》。该战略指出，当前和未来的网络威胁和攻击推动了对超越传统边界防御方法的零信任方法的需求，国防部打算在2027财年之前实施战略和相关路线图中概述的独特的零信任能力和活动。

从旧有边界体系到现在的端、网、云混合办公体系，零信任架构愈发重要。

为什么要做零信任

为什么要做零信任？最本质的，是因为我们有一些重要的数据或者权限需要保护，而现有安全体系在云原生时代已无法提供足够的保护。用户个人隐私数据，员工薪资数据，修改密码的权限，关闭关键系统的权限等等都是被保护的对象。这些数据和权限最初是由基于边界安全（Perimeter Security）的网络接入控制来保护的，比如公司内网和VPN，当一台设备连入公司内网后，就继承了获取这些数据和权限的权利。在传统的 IT 安全模型中，一个组织的安全防护像是一座城堡，由一条代表网络的护城河守护着。在这样的设置中，很难从网络外部访问组织的资源。同时，默认情况下，网络内的每个人都被认为是可信的。然而，这种方法的问题在于，一旦攻击者获得对网络的访问权，并因此默认受到信任，那么组织的所有资源都面临着被攻击的风险。

后来，人们又开始引入基于IP的或者基于用户名密码的访问控制，以及更加细粒度的基于身份和角色（Identity and Role）的访问控制。但是这些已经无法满足在云原生环境下，具有复杂IT系统的企业的数据和权限保护要求。

相比之下，零信任基于这样一种信念：企业不应该自动地信任其边界内或外部的任何东西，而是在授予访问权限之前，对试图连接到IT系统的任何人和东西进行验证。

从本质上讲，零信任安全不仅承认网络内部和外部都存在威胁，而且还假定攻击是不可避免的（或可能已经发生）。因此，它会持续监控恶意活动，并限制用户只能访问完成工作所需的内容。这有效地防止了用户（包括潜在的攻击者）在网络中横向移动并访问任何不受限制的数据。

零信任架构的组件

接下来我们来盘一盘当一个组织从头开始构建的零信任架构所要进行的工作。

Untitled

端点和设备

端点和设备包括组织内或有权访问组织数据的任何设备、API 或软件服务。组织必须首先了解他们的全套设备、API 和服务。然后可以根据设备、API 和服务的现状实施符合组织现状的零信任策略。

接入设备管理

大多数零信任架构要求软件至少安装在一部分用户机器上。移动设备管理 (MDM) 是大多数组织跨其用户设备清单管理软件和配置的方式。

端点保护

端点保护软件安装在用户的机器上并扫描影响设备的已知威胁。端点保护软件还可用于强制遵守操作系统补丁和更新，避免机器受到常见系统漏洞的威胁。

资产盘点

端点保护软件和资产管理软件可用于跟踪所有已分发给用户的设备。应维护一份准确的设备列表，以跟踪哪些设备是有效的并且应该可以访问特定的应用程序。

还应在清单中检测和维护 API 和服务。可以利用网络扫描来识别可以通过内部或外部网络进行通信的新出现的 API 和软件服务。

网络

网络包括组织内的所有公共、专用和虚拟网络。组织必须首先了解他们现有的网络集并对其进行细分以防止横向移动。然后，可以创建零信任策略来精细控制用户、端点和设备可以访问的网络部分。

细分用户网络访问

用户通常可以使用 VPN 或在办公室网络中访问整个专用网络。零信任框架要求用户只能访问完成给定任务所需的特定网络部分。零信任网络解决方案允许用户远程访问本地网络，但具有基于用户、设备和其他因素的精细策略。

使用宽带互联网实现分支机构之间的连接

专用网络位置（例如数据中心和分支机构）之间的连接通常是使用多协议标签交换 (MPLS) 线路或电信提供商提供的其他形式的专用链路建立的。这些 MPLS 链路通常很昂贵，并且随着商品互联网的质量越来越高，组织可以通过安全隧道在互联网上路由流量，从而以一小部分成本提供相同级别的安全访问。

关闭所有向 Internet 开放的用于应用程序交付的入站端口

攻击者常常通过扫描网站/主机开放的端口扩大攻击面，零信任反向代理允许您在不打开任何入站端口的情况下安全地公开 Web 应用程序。应用程序的 DNS 记录是应用程序唯一公开可见的记录。DNS 记录受零信任策略保护。作为附加的安全层，可以使用零信任网络访问解决方案来利用内部/私有 DNS。

网络流量

互联网流量包括所有发往组织控制范围之外的网站的用户流量。这可以从业务相关任务到个人网站使用。所有出站流量都容易受到恶意软件和恶意网站的攻击。组织必须建立对发往 Internet 的用户流量的可见性和控制。

DNS 过滤

可以通过路由器配置或直接在用户机器上应用 DNS 过滤。它是保护用户免受已知恶意网站侵害的最快方法之一。

TLS 解密

有些威胁隐藏在 SSL 之后，仅通过 HTTPS 检查无法阻止。为了进一步保护用户，应该利用 TLS 解密来进一步保护用户免受 SSL 背后的威胁。

应用

应用程序包括存在组织数据或执行业务流程的任何资源。组织必须首先了解存在的应用程序，然后为每个应用程序建立零信任策略，或者在某些情况下阻止未经批准的应用程序。

应用资产盘点

大部分企业中都会存在一些影子资产，这些往往会成为攻击者的入口点或跳板。对于安全团队来说，了解他们在整个企业中使用的应用程序的完整清单至关重要。

应用程序的零信任策略实施

应用程序必须受到零信任策略的保护，该策略在验证和授权访问之前考虑用户身份、设备和网络环境。应用程序应具有执行最小特权的细化策略，尤其是对于包含敏感数据的应用程序。

保护应用程序免受第 7 层攻击

任何自托管应用程序都容易受到第 7 层攻击，包括 DDoS、代码注入、机器人等。安全团队的自托管web应用程序前部署 Web 应用程序防火墙和 DDoS 保护。

强制执行 HTTPS 和 DNSsec

任何自托管 Web 应用程序都应利用 HTTPS 和 DNSSec。这可以防止任何潜在的数据包嗅探或域劫持。

数据丢失防护和日志记录

到目前为止，一旦您建立了体系结构的所有零信任元素，您的体系结构将生成有关网络内部发生的事情的大量数据。此时，是时候实施数据丢失防护和日志记录了。这些是一组流程和工具，专注于将敏感数据保存在企业内部并标记任何潜在的数据泄漏机会。组织必须首先了解他们的敏感数据存在于何处。然后他们可以建立零信任控制来阻止敏感数据被访问和泄露。

建立记录和审查敏感应用程序流量的流程

安全 Web 网关解决方案具有将用户流量日志传递到 SIEM 工具的功能。安全团队应该定期检查发往敏感应用程序的流量日志。可以在 SIEM 中设置和调整针对异常或恶意流量的特定警报。

定义哪些数据是敏感数据及其存在的位置

这假设企业已经建立了安全 Web 网关或其他收集用户流量日志的方式。它应该提供对传输中、使用中和静态数据的可见性。

敏感数据因行业而异。例如技术公司关注保护源代码。确定公司的敏感数据及其存放位置非常重要。

敏感数据的准确定义和清单将为数据丢失防护工具的实施提供信息。

防止敏感数据离开您的应用程序

例如使用 DLP 解决方案检查用户流量和文件上传/下载是否有敏感数据。

敏感数据在众所周知的预定义列表（例如 姓名、身份证、手机号等）中可用，或者管理员可以手动配置特定模式。应该为敏感应用程序启用 DLP 控制，并且可以针对所有用户流量进行扩展。

识别 SaaS 工具中的错误配置和公开共享的数据

定期扫描saas应用程序，查找已知的安全配置错误和已公开共享的数据。持续监控开源代码托管平台，技术写作平台，检测是否存在saas凭证泄漏，敏感资产数据泄漏。

关键及时的威胁情报数据

汇总多家厂商的威胁情报数据，对接到内部的威胁情报库，自动加载到web安全网关中，及时拦截恶意攻击者，保护用户免受攻击。

各厂案例

Google BeyondCorp/BeyondProd

Google在经历了Aurora事件后就开始着手内部的零信任架构建设。

2014 年，谷歌基于内部项目 BeyondCorp 的研究成果陆续发布 6 篇相关论文，介绍零信任落地实践。

BeyondCorp 的目标是：摒弃企业特权网络并开创一种全新访问模式

在这种全新的无特权网络访问模式下，访问只依赖于设备和用户凭证，而与用户所处的网络位置无关，无论用户是在公司“内网”、家庭网络、酒店还是咖啡店的公共网络，所有对企业资源的访问都要基于设备状态和用户凭证进行认证、授权和加密。

这种新模式可以针对不同的企业资源进行细粒度的访问控制，所有谷歌员工都可以从任何网络成功发起访问，无需通过传统的 VPN 连接进入特权网络，除了可能存在延迟差异外，对企业资源的本地和远程访问用户体验基本一致。

2015年，Google公开了他们的架构Borg容器化（论文地址：https://research.google/pubs/pub43438/），Borg 是 Google 的集群管理系统，用于大规模调度和运行工作负载。Borg 是 Google 的首个统一容器管理系统，也是 Kubernetes 的灵感来源。Google 的基础架构将工作负载作为单独的微服务部署在容器中，并使用 Borg（容器编排系统）管理这些工作负载。这就是如今众所周知的“云原生”架构的灵感和模板。

Google 的基础架构在设计时就充分考虑了安全性，而不是后来才想起要添加安全功能。Google的基础架构假定其服务之间不应互相信任，也就是在Borg的过程中涉及了ALTS（在容器层上构建了一套基础设施安全层）， 默认开启加密mTLS、默认针对gRPC进行鉴权和授权以及默认身份绑定实体（人、机器、容器）等，同时Google为了提升安全性，把可信计算也加入了其中，为达到的目的就是保证整个身份体系中整个ALTS根证书的安全性。

2019年,Google发布白皮书BeyondProd: A new approach to cloud-native security,介绍了其最新的云原生安全模型。

BeyondProd 有意收回了 BeyondCorp 的概念。正如边界安全模型不再适合最终用户一样，BeyondCorp 也不再适用于微服务。对原始 BeyondCorp 论文的修改：“此模型的关键假设已不再成立：边界不再仅仅是企业 [数据中心] 的实际位置，并且边界内的领域不再是托管个人计算设备和企业应用 [微服务] 的安全可靠之处”。

于是正如 BeyondCorp 帮助google超越了基于边界的安全模型一样，BeyondProd 在生产环境安全性方面实现了类似的飞跃。BeyondProd 方法描述了一种云原生安全架构，该架构假定服务之间没有信任、隔离工作负载、验证是否仅部署了集中构建的应用、自动执行漏洞管理以及对重要数据强制执行有力的访问权限控制。基于 BeyondProd 架构，Google 开发了多个新的系统，以满足这些要求。

在用BeyondCorp实现开发环境（Corp Environment）的零信任时，Google以人为本，对员工进行身份管理和多因子认证。与此同时，建立了一套管理公司设备的流程，每个公司设备都配备TPM模块和操作系统完整性验证。这两项工作确保了正确的人用正确的设备提供可信的认证信息。最后，再利用这些认证信息对员工访问开发环境进行持续访问控制。

在用BeyondProd实现生产环境（Prod Environment）的零信任时，Google同样试图以人和流程作为信任的根本。BeyondProd面对的问题是，生产环境并不存在与人的直接交互，于是建立了一套把生产环境中的软件溯源到这些软件的开发者（Software Provenance)，从对开发者的认证和开发流程的加固开始，确保没有任何单人能够改变生产环境中的软件的行为（No Unilateral Change)。

接下来从2个Google零信任部署实例(BeyondProd)来看其建设逻辑：第一个是用户如何获取自己的数据，第二个是开发者如何通过修改源代码来改变生产环境中的数据访问行为。谷歌对这两个案例的数据访问控制都遵循零信任的原则。

用户访问自己的数据

当用户通过谷歌的服务访问自己的数据时，请求会通过用户和Google Front End(GFE)之间的加密连接（TLS）首先到达GFE。GFE转用更加高效和安全的协议和数据结构将用户请求分发到各个后端服务共同完成用户请求。例如TLS会被换为Application Layer TLS(ATLS)。面向用户的口令会被转换为更加安全的End User Context Ticket(EUC)。这些置换旨在根据实际请求降低内部连接和令牌的权限，使得特定的ATLS和EUC只能访问局限于此次请求的数据和权限。

Untitled

开发者改变软件数据访问行为

当开发者希望通过改变服务的代码来改变一个服务的数据和权限访问行为时（开发者无法获取生产主机的任意指令运行权限，如SSH）,该代码修改会经过一系列的流程来将对开发者及其团队的信任转化为对新的服务的信任：流程中所有涉及的人员均通过多因子认证来确立身份，代码修改会被一个或以上有审批权限的人评估，只有获得足够多的授权的代码才会被合并入中央代码库，中央代码库的代码会被一个同样受BAB保护的可信构建服务集中构建，测试和签名，构建后的软件会在部署环节通过目标服务的BAB策略认证（比如GMail的服务只能运行代码库特定位置的经过充分代码评估和测试的代码），软件运行时也会根据相应的BAB安全策略进行运行时隔离：不同BAB服务策略管辖的服务会被运行在不同的隔离区。

Untitled

为了实现整套流程，google实现了以下几项内部安全工具/服务

在边缘保护网络，Google Front End (GFE)，用于管理传输层安全协议 (TLS) 终止和传入流量政策

  • Google Front End (GFE)：终止与最终用户的连接，并为强制执行传输层安全协议 (TLS) 最佳做法提供一个中心点。即使重点已不再是基于边界的安全性，但 GFE 仍是保护内部服务免受拒绝服务攻击的重要策略部分。GFE 是用户连接到 Google 的第一个入口点；在基础架构中，GFE 还负责根据需要在区域之间平衡负载和重新路由流量,是将流量路由到适当微服务的边缘代理。

流量传输方面，自行开发了应用层传输安全 (ALTS)，用于远程过程调用 (RPC) 身份验证、完整性、加密和服务身份

  • 应用层传输安全 (ALTS)：用于远程过程调用 (RPC) 身份验证、完整性和加密。ALTS 是一种用于 Google 基础架构服务的相互身份验证和传输加密系统。身份通常绑定到服务，而不是绑定到特定的服务器名称或主机。这有助于实现跨主机的无缝微服务复制、负载平衡和重新调度。

在代码可信方面，使用适用于 Borg 的 Binary Authorization (BAB)，用于代码出处验证,主机完整性 (HINT)，用于机器完整性验证

  • 适用于 Borg 的 Binary Authorization (BAB)：一种部署时强制执行检查，用于确保代码在部署之前满足内部的安全性要求。BAB 检查包括由另一位工程师审核更改的内容、将代码提交到源代码库，以及在专用基础架构上以可验证的方式构建二进制文件。在基础架构中，BAB 会限制未经授权的微服务的部署。
  • 主机完整性 (HINT)：通过安全启动过程验证主机系统软件的完整性，并基于受支持的安全微控制器硬件运行。HINT 检查包括 BIOS、BMC、引导加载程序和操作系统内核上的数字签名验证。

用于跨服务强制执行一致政策的关卡，服务访问政策，用于限制服务之间的数据访问方式，最终用户上下文 (EUC) 标签，用于证明原始请求者的身份

  • 服务访问政策：限制服务之间的数据访问方式。当远程过程调用 (RPC) 从一项服务发送到另一项服务时，服务访问政策会定义访问接收服务数据所需的身份验证、授权和审核政策。这样会限制数据的访问方式、授予所需的最低访问权限级别，以及指定如何审核该访问权限。在 Google 的基础架构中，服务访问政策会限制一项微服务对另一项微服务数据的访问，并允许从全局级别分析访问控制措施。
  • 最终用户上下文 (EUC) 标签：这些标签由最终用户身份验证服务发出，并为服务提供用户身份（独立于其服务身份）。这些是受到完整性保护、集中发放、可转发的凭据，用于证明发出服务请求的最终用户的身份。这样可以减少服务之间的信任需求，因为通过 ALTS 的对等方身份通常不足以授予访问权限，此类授权决策通常也基于最终用户的身份。

简单、自动化、标准化的更改发布，Borg 工具，用于蓝绿部署

  • 用于蓝绿部署的 Borg 工具：此工具负责在执行维护任务时迁移正在运行的工作负载。除了现有的 Borg 作业之外，系统还会部署新的 Borg 作业，负载平衡器会逐渐将流量从一项作业转移到另一项作业。这样，在用户不知不觉中，系统就可以在不停机的情况下更新微服务。此工具用于在添加新功能时应用服务升级，以及在不停机的情况下应用重要的安全更新（例如，针对“心脏出血”Bug 和 Spectre/Meltdown 漏洞的安全更新）。对于影响 Google Cloud 基础架构的更改，会使用实时迁移来确保虚拟机工作负载不受影响。

工作负载之间进行隔离，gVisor，用于工作负载隔离

  • gVisor，用于工作负载隔离。gVisor 使用用户空间内核来拦截和处理系统调用，从而减少与主机和潜在攻击面的交互。此内核提供了运行应用所需的大部分功能，并限制应用可访问的主机内核表面。在 Google 的基础架构中，gVisor 是用于隔离同一主机上运行的内部工作负载和 Google Cloud 客户工作负载的几种重要工具之一。

Illumio

Illumio创立于2013年，与一众注重于端侧(身份与访问管理)的厂商不同，Illumio将产品定位在微分段(微隔离).

微分段（Micro-Segmentation，又称微隔离）技术是VMware在应对虚拟化隔离技术时提出来的，但引起广泛关注是自2016年起连续3年进入Gartner年度安全技术榜单。顾名思义，微分段是粒度更细的网络分段技术。它是在VLAN、VxLAN、VPC等技术基础上发展起来的，其核心能力聚焦于东西向流量的隔离上。

传统上，公司使用部署在网络边缘（主要是防火墙）的各种安全工具来保护其网络边界。主要重点是筛选网络和外部流量源之间的南北向流量。这些工具就像保护城堡的护城河，“城堡”（网络边界）内的居民天生就值得信任。

随着云的出现和自带设备（BYOD）等趋势，事情变得更加复杂。东西向流量、数据中心内和分布式系统之间的流量大幅增长。保护边界变得越来越困难，并且需要在组织需要保护的每个宝贵资产周围创建多个微边界。

这就是微分段的用武之地。它允许网络管理员在其分布式基础架构中创建安全的"孤岛"，并控制所有类型的用户对这些孤岛的访问，无论他们是从各种位置登录的外部人员、客户还是员工。

Illumio提供微分段解决方案Illumio Core.该方案实时检测检测横跨不同运算环境之间的工作负载可见性，根据工作负载的通信方式产生微分段策略，对每个主机中的本地状态实施防火墙规则。

Illumio Core包含兩大元件，分別是虚拟执行节点 (VEN) 及策略运算引擎 (PCE) 。

VEN是一种轻量级代理，安装在主机的客户操作系統 (Guest OS) 中，执行两个关键功能： 第一，收集有关工作负载的操作系统、接口、进程和流的信息并将其传输到PCE。每个VEN可作为一个可视点及传感器，检测违规行为。此功能为应用程式的行为设定安全基线并创建规则，以检测未经授权的连接和策略偏差。 第二，接收应用防火墙规则并对主机的第3层/第4层状态防火墙进行编程。VEN程式支持多个操作系统 (Windows、Linux、AIX、Solaris) 和容器，以及交换机、负载均衡器和安全架构内的混云 (公共、私有、混合) 环境。 PCE是从VEN收集所有遥测信息的大脑，通过实时应用程式关系图将其可视化，然后根据有关环境、工作负载和进程的上下文信息推荐最佳防火墙规则。这些规则被传输回VEN，可对每个主机的第3层/第4层防火墙进行编程。PCE可以通过Illumio的SaaS平台、本地和虚拟私有云中部署。

Untitled

2020年3月，Illumio聘请Bishop Fox，测试Illumio微分段场景下对红队横向移动行为的限制性。相应报告可见 https://www.illumio.com/resource-center/research-report/efficacy-micro-segmentation-assessment-report

报告中模拟了3个测试用例和一个对照组，并在第二个用例不断提高工作负载数量，用于验证微分段策略的有效性。红队攻击者通过ssh密钥进行横向，以获取pgsql数据库中的数据为目标。

对照组为扁平网络，允许每个主机彼此通信，没有任何过滤和拦截策略。

用例1启用了Illumio-VEN代理，进行了微分段(环境分离)。

用例2启用了Illumio-VEN代理，并设置了附加的微分段(应用程序隔离)。

用例3启用了Illumio-VEN代理，并且进行了基于层的微分段。

3种测试策略的不同点如下

环境分离可以理解为：生产主机只能与生产主机对话，而开发只能与开发对话等。

应用程序隔离是指同一应用程序和同一环境中的主机和工作负载之间可以进行通信，但不允许进行其他任何通信。

基于层的分段是最细粒度的微分段形式之一，只有在相同的环境、相同的应用程序、相同的应用程序层中的工作负载，才能相互通信。

相应测试结果如下图

Untitled

根据报告显示，与对照环境（扁平网络场景）相比，对于100个工作负载环境，攻击者分别需要300%（用例1）、450%（用例2）和950%（用例3）的时间来获得crown_jewels数据库。

该团队发现，尽管网络上发现的主机数量在不同的测试用例之间有所不同，但他们能够成功地枚举所有这些主机。然而，在对照环境测试和用例3之间，发现的服务数量线性减少了44%（从293个已识别的服务减少到130个）。

Snipaste_2023-01-04_11-41-02.png

简言之，微分段策略越紧（从对照测试，到用例1，再到用例2，再到用例3），当对手试图横向移动时，对他们造成的困难就越大。此外，只要在整个企业中一致地应用微分段策略，即便微分段的级别（策略的粒度）保持不变，也有显著的可度量的好处。

在2022年，Illumio又聘请Bishop Fox，测试Illumio微分段场景下对域环境下横向和C2行为的限制性。相应报告可见 https://www.illumio.com/resource-center/research-report/bishop-fox-ransomware-scenario-emulation-assessment ,这里不多做描述.

蔷薇灵动

蔷薇灵动是国内做微隔离比较有名的，也在国内有落地案例。

以光大银行全栈云微隔离建设实践案例为例，看看蔷薇灵动的方案。

中国光大银行（以下简称“光大银行”）成立于1991年8月，光大银行一直积极拥抱云计算技术，坚持从业务需求出发服务金融应用，不断建设发展云平台，目前已进入云平台3.0——全栈云平台建设阶段，并初步完成“双栈并举、一栈多芯”两地多中心分布式云化数据中心经建设，构建了全行级统一数字化基础设施体系。

项目前期，光大银行已建成了混合架构全栈云（生产云+开发测试云)，采用青云、华为云双架构，X86/ARM双技术栈。而随着容器平台的投产，容器网络中的IP地址已失去其本身的秩序，基于IP的静态策略自然不再有效。需要通过微隔离系统在云平台中建立逻辑边界，实现业务间互访控制，并通过微隔离系统的统一策略框架提升访问控制精细度和效率。由此开始，光大银行正式踏上了微隔离技术的探索之路。

蔷薇灵动针对行方提出的微隔离需求，进行了方案设计及验证，最终在现网生产环境成功交付。方案以蔷薇灵动蜂巢安全自适应微隔离平台为主体，利用蜂后安全计算中心（QCC）、蜂群安全守护容器（BDC）和蜂群安全管理终端（BEA）三大核心组件，完成对数据中心的跨地域、跨平台、跨集群统一管理。

项目实施以“五步法”为指引开展。所谓“五步法”，是指定义、分析、设计、防护和运维5个关键步骤，是蔷薇灵动总结出的一套微隔离实施方案。

Untitled

定义阶段，主要完成系统的部署和工作负载纳管。 首先，为满足光大银行近万点规模的统一管理需求，蔷薇灵动在计算中心的部署上进行了充分的性能和可用性保障设计，将一个多机计算中心集群分布部署于同城的两个双活数据中心中，实现了工作负载就近接入、双集群A/A备份的效果。其次，针对容器环境，采用了基于DaemonSet的“无代理”模式部署，通过自动化的守护容器部署，省去了在各节点安装Agent的繁冗，实现了光大银行“原生化部署运行”。

Untitled

分析阶段，主要对工作负载进行分组和标签化管理，并为安全策略与IP的解耦打下基础。 项目过程中，行方以微隔离实施为抓手，对已有的资产管理数据及现用的业务属性标签规范进行了梳理和优化，实现了高效的分组和标签化。例如，在云原生环境中，容器自身的标签体系被微隔离系统直接复用，通过容器Namespace的名称作为分组，并利用app label的键值作为各容器角色标识。

设计阶段，主要梳理出东西向访问的基线。 对于光大银行，业务容器上线时，业务需要提交应用的访问需求，这些信息可以从CMDB系统中直接获得。除此之外，在过去云平台中的防火墙、安全组中，运行着一些访问控制策略，这些策略经分析选择，也可通过工具自动化的导入微隔离系统。对于仍未覆盖的少部分策略，可以利用连接可视化分析能力，与业务部门逐条确认。

防护阶段，主要完成安全策略的下发与执行。 微隔离策略的下发并非“一蹴而就”，而是需要经过一定时间的效果仿真和试运行，因此专业微隔离系统通常具有多种策略生效模式，例如“仅定义不下发”的建设模式、“仅下发不阻断”的测试模式或“完全执行”的防护模式。光大银行的业务容器投产前会先后运行于开发、测试、投产验证和生产环境，而微隔离能力是在最初的开发环境便开始生效，不同环境可根据用户的需求灵活的选择策略生效模式。

至此，微隔离实施的主要工作已基本完成，系统将进入运维阶段。 目前，光大银行正在积极尝试将微隔离系统与ITSM、SOC等外部系统打通，实现智能化的策略变更和优化。

项目的几个点

  1. 通过“主机代理”的微隔离技术路线，实现了多云平台、容器平台、多集群的无差别统一纳管，做到了“基础架构无关”，也再次证明了“主机代理”微隔离技术路线在面对大型机构复杂环境时体现出的技术优越性。同时，方案创新性地通过守护容器（DaemonSet）的方式，将微隔离的策略执行点深植于云原生环境中，实现了专业微隔离能力向云原生的内嵌融合。
  2. 针对云内虚拟的工作负载，基于系统的“标签”体系，为工作负载在IP层之上建立起了一套脱离于基础设施、面向业务属性的、基于“身份”和“角色”的管理分层，从而应对云内资产高度动态、弹性的特点，实现了安全策略随工作负载迁移、扩缩容而动态自适应更新。
    • 跨云，跨平台，跨系统的管理视角，我理解就是把视图概括了云，数据中心，主机，应用程序，这几个细粒度。
  3. 通过API打通了微隔离和多套管理系统的数据通道，完成了管理和运行数据的对接，实现了自动化的策略运维能力，从而使得微隔离完全适应并符合用户DevSecOps的运行流程，安全策略能够随工作负载的生成而同步生效，微隔离系统真切成为了云内安全的基础设施。
    • 这里是对平台自动化能力的体现，通过策略配置自动生效，自动同步

安全风险

SDP

敲门包可逆

部分零信任解决方案为了支持不同平台会有多种客户端，不同的客户端可能会采用不同的敲门方式，甚至不同的敲门协议，如果存在http/grpc/websocket这种，可尝试中间人嗅探，并逆向敲门包，进行伪造，或重放。

UDP敲门SNAT漏洞

攻击者和合法用户都在同一栋大楼里上班，在公司同一个网段里，对外访问网络时需要SNAT源地址转换，对外敲门的访问IP在网关和SPA 敲门处理服务看来都是一样的，因此当零信任网关对合法用户放通访问端口的时候，攻击者也可以通过该端口对网关进行访问攻击。

解决方案主要有两种

  1. 改UDP敲门为TCP敲门，敲开后复用TCP连接进行通信，但会牺牲安全性，需要防范TCP syn ddos攻击。但是TCP的敲门稳定性更为优越，有利有弊吧。
  2. 敲开门后，访问网关携带身份信息，这是最有效的解决方案。

UDP放大DDOS

由于采用的UDP包进行窍门，因此就存在UDP放大攻击的风险，当响应包远远大于请求包时，便可利用进行ddos。

解决方案

  1. 将放大倍率小于1，不存在dos的优势。

网关

通用的web漏洞

很多网关其实就和常见的web应用一样，组件漏洞，通用漏洞都是可能存在的。

总结

业内许多厂家对于什么是零信任，有着不同的答案，这也导致各家不同的零信任观点，将大多数甲方整的云里雾里，直呼“不觉明厉”。对于零信任，不必太过拘泥于定义和理论，而是要把它跟实践相结合，从具体的要解决的问题和应用场景出发。

Source & Reference