零信任（一）简史与 BeyondCorp

零信任其实是一种安全理念：“永不信任，始终验证”。

零信任系列分为两篇：

1. 历史 + BeyondCorp
2. NIST 架构 + 总结与思考

本篇是 历史 + BeyondCorp

历史

发展历史其实没那么重要，橘友们当做故事看就好了，我也是复制粘贴的。

// ctrl+c from 资料 1

零信任的最早雏形源于 2004 年成立的耶利哥论坛，其成立的使命正是为了定义无边界趋势下的网络安全问题并寻求解决方案，提出要限制基于网络位置的隐式信任，并且不能依赖静态防御。

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

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

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

2014 年，谷歌基于内部项目 BeyondCorp 的研究成果陆续发布 6 篇相关论文，介绍零信任落地实践。BeyondCorp 采用了零信任的思想，设计理念如下：

1. 所有网络都不可信；
2. 以合法用户、受控设备访问为主
3. 所有服务访问都要进行身份验证、授权加密处理

同年，CSA 发布了《SDP 标准规范 V1.0》英文版（中文版于 2019 年发布）

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 的定义如下：利用零信任的企业网络安全规划，包括概念、思路和组件关系的集合，旨在消除在信息系统和服务中实施精准访问策略的不确定性。该标准强调零信任架构中的众多组件并不是新的技术或产品，而是按照零信任理念形成的一个面向用户、设备和应用的完整安全解决方案。

// crtl+v

里面有很多的术语，我先总结一下：

• ZT：即零信任
• ZTN：即零信任网络
• ZTA：即零信任安全架构
• ZTNA：即零信任网络访问，Gartner 嘴里的 SDP
• SDP：即软件定义边界，构建 ZTN 最复杂的方案
• BeyondCorp：我感觉也不是用完全体的 SDP 实现的
• NIST 草案：定义了 SIM 以及指导架构设计
  • SDP：这个就是软件定义边界
  • IAM：即身份管理系统
  • MSG：微隔离

似懂非懂？这太正常了。

从整个发展历史来看，其实最有价值的还是 BeyondCorp 的六篇论文和 NIST 的架构设计，这也是为什么这个系列主要说的是这两个内容。

我的预期是看完 BeyondCorp 之后，橘友们对零信任概念以及实现有了基本了解，看完 NIST 的架构之后，对落地能有自己的思考。最后还有我的思考与总结，向橘友们分享一下我的想法。

BeyondCorp

在开始之前，我想先和大家说一个我自己的结论：零信任其实包含了办公网零信任和生产网零信任。如果这么去理解的话，BeyondCorp 其实指的是办公网零信任。

BeyondCorp 六篇论文分为以下几个主题：

1. BeyondCorp 简介
2. 方案的设计与落地
3. 深入介绍重要组件
4. 迁移的方式与挑战
5. 解决用户体验问题
6. 自身的安全性保障

我十分推荐大家去看看论文（见资料 2），光看主题就可以感受到谷歌分享技术的诚意。

是什么？

首先橘友们最关心的肯定是这个 BeyondCorp 到底是什么。

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

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

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

这一大段是摘自谷歌关于 BeyondCorp 那 6 篇论文里的第 1 篇。这里的重点我已经帮大家标记出来了。那么，这些话显然是很虚的 ，确实有很多公司自称在认真做安全建设，大谈前沿概念，实际上是在吹牛* 。所以我们接下来看看他们是怎么实现这些目标的。

怎么实现？

我觉得这个才是我们比较关心的。

这个是我画的 BeyondCorp 架构图，我把它分为 3 个大块：

1. 红框：接管流量
2. 绿框：执行策略
3. 黄框：信息收集

也就是图里的这三个虚线框围住的部分。我们先不看他们各个模块之间的交互，先看一下各个模块是做什么用的。

接管流量

首先来看这个红色的框：

• 外网：这个就不用说了，就是非公司的网络，比如在家或者在咖啡厅之类的地方，发起的访问。
• 特权网络：说白了就是公司的办公网，为什么叫有特权呢？因为一般我们认为如果你是通过办公网来访问或者通过 VPN 来访问的，那么你就是自己人了，内网很多系统对于来源是办公网的，可能都没有加访问控制甚至都不需要登录就可以直接使用。那实际上办公网就是有特权的，所以叫特权网络。
• 无特权网络：这个要对比与特权网络来理解。知道特权网络的含义后，那么无特权网络自然就是，就算你位于办公网，发起的访问也没有特权，该登录还是要登录，不让访问的还是不能访问。这就是所谓的无特权网络。
• 访问代理：这个其实就是一个 7 层的代理，可以类比为 Nginx（据我所知，目前很多公司都有一个前置的 Nginx 集群，也可能魔改过）。它是可以被外网直接访问到的，谷歌把办公网应用 cname 到访问代理，直接对公网暴露。这里我把访问代理和网关分开来画了，实际上他们是集成的。
• 网关：网关是访问资源的唯一通道，所以这个代理的真正职能其实是网关来完成的，替代用户向应用发起访问。还有一点需要注意的是，它与应用之间的通信是加密的。
• SSO：这是提供统一认证的地方，所有应用接入 SSO 做认证和权限划分，虽然应用内部的权限划分还是由应用 owner 自己来设计，但是需要在 SSO 上配置，由 SSO 来完成权限管理。
• RADIUS：对于有线和无线访问，不再依赖交换机/端口的静态配置，而是使用 RADIUS（谷歌使用基于 802.1x 认证的 Radius）来通知交换机，将认证后的设备分配到对应的的 VLAN。

执行策略

接下来来看一下绿框部分：

• 访问控制引擎：访问代理的咨询对象，它会告诉访问代理，对于本次请求你应该怎么处理，比如放过还是拦截还是其他执行动作。
• 访问控制策略：包含了所有管控的逻辑。比如跳二次认证、拒绝访问。那橘友们可能会想为什么不把访问代理和访问控制引擎集成在一起呢。因为访问代理它不一定只给 BeyondCorp 使用，因为通常的方案是用业务那边负载均衡直接加功能得到的，所以其实业务本身也会用到。如果强耦合的话会很混乱，既有业务功能，也有安全功能，每次变更就会变得更加危险。
• 异步策略：这是用来实施强制措施的。比如踢出登录态、风险或者威胁推送、网络隔离等等。

信息收集

接下来来看一下黄框部分：

• 信任引擎：是用来做信任等级计算的
• 信任等级：资源有等级，设备也有等级。比如给访问来源设定了几个不同级别的信任等级（外包员工、正式员工等等）；对于资源来说，就是比如办公网应用啊什么打印机啊这种的，他们的等级是可以根据防护等级或者安全等级来划分。类似的，还有人员相关的信息，谷歌这部分是与 HR 系统集成的。然后每次设备信息发生变动都会重新计算一次设备等级。这种离线计算的模式有很多优点，比如....。那么它的缺点是并不是所有的信息都可以使用预计算的，这也是为什么会有一些必要的静态策略存在的原因。
• 资产清单：资产清单说起来是非常简单的，就是设备的一切信息。但是做起来相当麻烦。首先这部分数据量是非常大的，比如所有者、设备的硬件信息（甚至是硬盘、网卡、主板的编号）、操作系统信息，包括证书、操作系统版本和补丁等等，数据量一大各种问题就随之而来，比如延迟、存储、同步问题如何解决。其次是所有来自不同数据源的数据都需要聚合、关联到某一设备。那么如何进行关联就是一个非常棘手的事情。最后考虑到人为的数据录入错误，情况还会更加复杂。所以这块的工作说起来简单做起来踩到的坑却非常非常多，谷歌花费了很多年的时间才实现基于资产清单的策略。
• 证书：设备证书的第一个作用是标识设备的唯一 ID，第二是在 Radius 那边做认证，第三是它会透传给后面的网关，网关用设备提供的证书，用来与应用通信加密。

上面这些组件看起来相当复杂，可能不太直观，我举个例子吧。

比如我的电脑被偷了，我去找 IT 报备。IT 在 IT 部门的资产库中，打个标，表明此设备已丢失。然后资产清单在定期轮训 IT 资产库的时候，将这个丢失的信息同步过来。信任引擎在进行定期计算的时候，发现这个设备丢失了，于是把这个设备的信任等级降至最低。那么访问控制引擎在做判断的时候，由于设备安全等级非常低，所以大部分应用都不允许访问，引导到丢失设备的提示页去。

完整架构

最后我们再来整体地看一下这个流程，我举两个例子：

1. 一名工程师在公司发起对代码库的访问。首先，连入公司的 wifi，Radius 要求设备提供证书，通过之后，在无特权网络上分配一个地址。接着工程师访问代码库，请求指向访问代理，笔记本电脑提供设备证书。这一步通常会涉及到客户端的改造，比如浏览器，需要安装一个插件，这个插件会在访问办公网应用的时候，自动提交证书。接下来，访问代理无法识别用户，重定向到单点登录系统。工程师登录，由 SSO 进行身份认证，颁发令牌，并重定向回访问代理，访问代理现在持有设备证书和标识用户的登录令牌，就继续往后走。就这次请求，向访问控制引擎咨询应该如何处理。假设访问控制引擎同意，那么网关会使用刚才拿到的证书，访问应用，它们之间的流量是加密的。
2. 一名工程师在家发起对代码库的访问。这个也就是我们常说的员工在外网访问。工程师用公司的电脑，连到自己家的 wifi，然后访问办公网应用，同样，浏览器插件会自动提交设备证书。接下来的过程与第一个例子一模一样。

再看一个更加具体的例子：

codereview.corp.google.com 这个是谷歌的一个办公网应用，我们看下 DNS 解析记录：

可以看到 codereview.corp.google.com 直接在在公共 DNS 中注册，CNAME 指向访问代理。

访问会跳到 SSO：

解决了什么问题？

那么到这里我们对谷歌实现 BeyondCorp 整体有了一个比较清楚的了解。不过其实更重要的是要知道它解决了什么问题，我们才会去考虑我们到底要不要跟风做这么一个东西，盲目地追逐新概念其实是很危险的。

只关注边界安全，一旦边界被突破则畅通无阻

在传统的安全方案中，几乎所有企业都会采用防火墙来增强边界安全。这种安全模型可以类比成我们的公司。守卫森严，每个出入口都有保安并且要求刷卡，似乎门禁能被突破的可能性很低。而根据墨菲定律，只要一件事它有发生的概率，那么随着时间的推移它就一定会发生。所以这种安全模型是存在问题的：一旦边界被突破，攻击者可以畅通无阻地访问企业的内部特权网络。从我个人体验来说，护网也好，红蓝对抗也好，感觉从办公网被突破的概率是非常大的，反而是生产网不太容易被突破。

边界不再由企业的物理位置决定

当所有员工都只在办公大楼中工作时，边界安全模型确实很有效；然而，随着移动办公的出现、办公使用的设备种类激增，边界变得越来越复杂。

另外，现在很多公司都在上云，云服务的使用越来越广泛，那么所谓的“边界”其实不再由企业的物理位置决定。定义边界越来越复杂和困难，那么基于边界的防守也就越来越容易出现疏漏。

难以平衡效率与安全性

连入 VPN 时需要认证，访问办公系统时再需要认证，可能还需要二次认证，对体验和研发效能影响较大。并且这种流程是对应用捆绑，每个人要用都必须这么来，实际上并不是所有人在所有时候进行的操作，都需要二次认证。

现在研发流程提效的问题在每个公司都很受关注，如果安全成了提效的最大阻碍，出师无名，就很难推行了。

可以得到那些经验？

那么还有一部分是比较值得说的就是这个经验。谷歌那 6 篇论文不仅说了他们是如何做的，还说了非常多落地经验，实在是业界良心。不过实在是太多了，而且很多经验如果没有参与落地的话，橘友们不会直接接触到，也没啥感觉。

“不仅仅是解决技术层面的问题”

这里的经验其实不仅是技术层面的，也有运营、运维等等。当然，还有很多这样的经验，篇幅关系我就不一一列出了。

• 分阶段上线实施是迁移能成功的关键
• 资产管理的数据质量问题可能导致设备无意中失去对企业资源的访问权限
• 假设企业内部网络与公共互联网一样充满危险，并基于这种假设构建企业应用
• 着手迁移到一个类似 BeyondCorp 的模型之前，需要来自公司高层及其他负责人的支持
• 在部署 BeyondCorp 的过程中，面临的最大挑战之一是如何在不干扰用户的情况下完成如此大规模的任务
• 为了避免出现海量问询，需要尽量减少员工困惑，并在无需技术人员人工干预的情况下能够对常见问题进行回答
• 为了防止临时例外变成常态甚至颠覆 BeyondCorp 的基本目标，只有给出明确计划时，我们才允许进行临时的例外放行
• 灾难性的突发事件甚至可能导致支持人员都无法访问恢复所需的工具和系统，因此 BeyondCorp 系统中构建了各种故障保护系统
• 团队还组织内部宣传活动来提高大家对 BeyondCorp 的认识，比如推出了电脑贴纸、标识和口号，还在办公室张贴随处可见的文章

“前人的经验不但可以教会我们应该做什么，也可以提醒我们不要做什么”

其实前人的经验不但可以教会我们应该做什么，也可以提醒我们不要做什么。

• 不要盲目地相信单个或少量系统的数据真实性
• 沟通不足会让用户感到惊讶和困惑，造成补救措施效果差，IT 支持人员的工作也会超负荷
• 过度沟通也有问题：不愿改变的用户会倾向于高估变化带来的影响并企图寻求不必要的豁免
• 一下子将每个网络用户和每个应用都迁移到 BeyondCorp 环境，对业务连续性来说非常危险
• 一开始只打算支持 HTTP 协议是完全不够的，随着项目的推进， 不得不为更多的协议提供支持
• 例外处理增加了 BeyondCorp 生态系统的复杂性，随着时间的推移，“为什么我的访问被拒绝了?” 这个问题的答案已经不那么明了
• 尽管新员工在培训中了解了 BeyondCorp，但他们在入职头几天中可是接受了大量的信息冲击，让每个人都能回忆起培训中的每个细节不太现实

最后这一点，各位在入职的前几天应该是非常感同身受的。似乎我们所有的流程或者是培训，都默认你会记住他们给的知识点。但是这就和以前老师布置作业一样，每个老师都说自己布置了一点点作业，每个老师都一点点，其实加起来可能就变得很多。

结尾

谷歌 BeyondCorp 的介绍就到此结束啦。还有很多很多的细节，再次推荐各位去看看谷歌的这六篇论文（见资料 2），非常值得研读。

这里放上我整理的思维导图（此图较大），起到一个总结的作用：

其实我感觉，学习一个新的技术项目，最好的办法就是投入时间去参与它的落地过程，否则还是有点云，因为很多事情不参与是没有切身体会的。

我最近在做办公网零信任的建设，如果你有相关经验或者问题，非常欢迎联系我，我们可以交换一下建设经验，提升彼此的安全水位，开门造车，合作共赢。

资料

1. 《网络安全先进技术与应用发展系列报告 零信任技术》
   • 公众号后台回复：bt-1
2. BeyondCorp 中文版论文
   • 公众号后台回复：bt-2

以零信任，重建信任
我们下一篇见！