2010年，Forrester分析师John Kindervag提出了“零信任模型”（Zero Trust Model)。零信任模型的核心思想是: 网络边界内外的任何东西, 在没经过验证之前都不予信任。必须要摒弃“网络边界”的想法，将注意力集中在网络中四处流通的数据包上。在“零信任”的发展过程中，国内外各厂商纷纷提出自己的方法和见解，其中最成功的莫过于谷歌的BeyondCorp体系。从2014年12月起，谷歌共在《;login:》杂志上发表了6篇BeyondCorp相关的论文，全面介绍BeyondCorp的架构和谷歌从2011年至今的实施情况。本文基于谷歌的6篇论文提炼梗概，帮助你在5分钟之内了解BeyondCorp是什么。
首先，我们来看一下BeyondCorp建立的目标：让每位谷歌员工都可以在不借助VPN的情况下通过不受信任的网络顺利开展工作。这意味着需要摈弃对企业特权网络(企业内网)的依赖并开创一种全新的安全访问模式。在这种全新的无特权内网访问模式下, 访问只依赖于设备和用户身份凭证，而与用户所处的网络位置无关。因此，BeyondCorp在实施过程中始终遵循：
1) 发起连接时所在的网络不能决定你可以访问的服务；
2) 服务访问权限的授予以我们对你和你的设备的了解为基础；
3) 对服务的访问必须全部通过身份验证, 获得授权并经过加密。
图：BeyondCorp组件图和访问数据流
参照组件图，我们总结了BeyondCorp组网的几个特点：
1. 企业应用程序和服务不再对公网可见
整个BeyondCorp对外暴露的组件只有访问代理(AP, Access Proxy), 单点登录(SSO)系统和在谷歌大楼中的RADIUS组件, 以及间接暴露的访问控制引擎组件。其中访问代理和访问控制引擎组件共同组成前端访问代理(GFE), 集中对访问请求进行认证和授权。BeyondCorp系统通过DNS CNAME方式, 将访问代理组件暴露在公网中, 所有对企业应用或服务的的域名访问, 都指向了访问代理, 由访问代理集中进行认证, 授权和对访问请求的转发。
2. 企业内网的边界消失
发起连接的设备或终端所在网络位置和IP地址不再是认证授权的必要因素。无论设备或终端在哪里, 是在谷歌大楼内, 还是在家里, 或者在机场, 所有对企业应用或服务的访问请求, 都必须经过一个逻辑集中访问代理组件的认证和授权。
3. 基于身份, 设备, 环境认证的精准访问
只有公司的设备清单数据库组件中的受控设备(公司购买并管控), 并且用户必须在用户/群组数据库组件中存在, 才能通过认证; 然后经过信任推断组件的计算后, 才会获得相应的授权。
4. 仅对特定应用，而非底层网络授予访问权限
BeyondCorp的使命就是替代VPN, 最终用户设备获得授权仅仅是对特定应用的访问。
5. 提供网络通信的端到端加密
用户设备到访问代理之间经过TLS加密, 访问代理和后端企业应用之间使用谷歌内部开发的认证和加密框架 LOAS(Low Overhead Authentication System)双向认证和加密。
谷歌整个系统的改造历时6年，此处罗列其中几个关键点：
1）安全识别设备
BeyondCorp 使用了“受控设备”的概念——由企业采购并管理可控的设备，只有受控设备才能访问企业应用。此外，所有受控设备都需要一个唯一标识，此标识同时可作为设备清单数据库中对应记录的索引值。实现方法之一是为每台设备签发特定的设备证书。
2）安全识别用户
BeyondCorp跟踪和管理用户数据库和用户群组数据库中的所有用户，用户/群组数据系统与谷歌的HR流程紧密集成。使用SSO单点登录,在经过用户/群组合法性验证后，生成短时令牌(short-lived tokens), 用来作为对特定资源授权流程的一部分。
3）消除基于网络位置的信任
部署无特权网络: 谷歌办公大楼内部的所有客户端设备默认都被分配到这个网络中。无特权网络只能连接互联网、有限的基础设施服务(如，DNS、DHCP 和 NTP)、以及诸如 Puppet 之类的配置管理系统。接入到这个无特权网络后, 并不能直接访问企业内网的应用, 必须经过代理网关的认证授权后, 才能访问企业应用。
使用802.1x认证分配到动态VLAN网络: 只有通过802.1x认证的设备才能被动态的分配到无特权网络, 然后下一步再进行访问代理的认证; 没有通过802.1x认证的设备只能被分配到补救网络或访客网络中。
4）将应用和工作流公网化
面向公网的访问代理提供全局可达性, 负载均衡, 访问控制检查, 应用健康检查和DDoS防护。在通过访问控制检查后, 访问代理会将请求转发给后端应用。
公共的DNS记录: 谷歌的所有企业应用均对外提供服务，使用CNAME将企业应用指向面向互联网的访问代理。
5）实现基于设备清单的访问控制
对设备和用户的信任推断: 每个用户和/或设备的访问级别可能随时改变。通过查询多个数据源, 能够动态推断出分配给设备或用户的信任等级, 这一信任等级是后续授权的关键参考信息。
访问控制引擎(ACE): 访问代理中的访问控制引擎, 基于每个访问请求, 为企业应用提供服务级的细粒度授权。授权判定基于用户, 用户组, 设备证书, 设备清单数据库中的设备属性进行综合判定。地理位置和网络位置在BeyondCorp安全模型中, 已经不是认证授权的必选项, 而是根据需要做判定的一个可选项。
访问控制引擎的消息管道: 通过消息管道向访问控制引擎源源不断地推送信息，这个管道动态地读取对访问控制决策有用的信息，包括证书白名单、设备和用户的信任等级，以及设备和用户清单库的详细信息。
缔盟云实验室小结：
有关BeyondCorp效果
1）BeyondCorp 如今已融入大部分谷歌员工的日常工作，针对谷歌的核心基础架构提供基于用户和设备的身份验证与授权服务
2）IAP(Cloud Identity-Aware Proxy) 已经商用: 在谷歌内部，已经能够将在BeyondCorp 工作中所学到的东西应用到其他项目和服务中。其中最显著的就是最近为谷歌云平台(Google Cloud Platform,即 GCP) 增加的新服务(比如：基于身份识别的访问代理 IAP)
有关BeyondCorp缺点
历时时长: 从2011到2017, 历时6年, 才完成大部分的企业应用的系统改造。
仅仅对Web系统有较好的支持: 对企业采购第三方软件, 远程桌面, UDP协议之类的软件支持, 需要做较大的改
造或者体验上的牺牲。
不支持BYOD: 仅仅是受控设备即企业采购并可管理的设备, 才能纳入到BeyondCorp的安全管理体系。
作为一个著名的零信任安全案例, BeyondCorp实践的理念已经融入到大部分谷歌员工的日常工作, 在零信任安全领域具有教科书级的意义。值得注意的是，BeyondCorp是一个零信任安全模型, 并不是一个产品。所以, 它只是在谷歌公司内部实践, 谷歌没有将整个BeyondCorp的安全能力抽象成一个产品, 仅仅抽象一部分能力做成了商业化的产品(IAP)在GCP上发布。
参考资料：
1. BeyondCorp 官网 https://cloud.google.com/beyondcorp
2. 概览: “以全新方式保障企业安全” https://research.google/pubs/pub43231/
3. Google是怎么做到的: “从设计到在Google部署” https://research.google/pubs/pub44860/
4. Google的前端基础架构: “Access Proxy简介” https://research.google/pubs/pub45728/
5. 迁移至BeyondCorp: 在提升安全性的同时保持工作效率 https://research.google/pubs/pub46134/
6. 人的因素: “用户体验” https://research.google/pubs/pub46366/
7. 保护端点: “构建运行良好的机组” https://research.google/pubs/pub47356/
本文为缔盟云实验室原创文章，转载请注明出处。
