NO.2 谷歌是如何实现的
谷歌 BeyondCorp:
从设计到部署
BeyondCorp, Design to Deployment at Google
译者:360 身份安全实验室
2018 年 11 月
前言
关于译者:360 身份安全实验室(360 ESG Identity Security Lab),是 360 企业安全
集团下属专注“零信任身份安全架构”研究的专业实验室。基于零信任安全理念,该团队利
用现代身份与访问管理技术,探索“企业物理边界正在瓦解、传统边界防护措施正在失效”
这一时代背景下的新型安全体系架构,推出“以身份为中心”的 360ID TrustAccess 身份
安全解决方案。同时,该团队大力投入对零信任安全和现代身份与访问管理技术的研究和产
品化,并结合行业现状,积极推动“零信任身份安全架构”在业界的落地实践。
关于 BeyondCorp:谷歌的 BeyondCorp 计划打造基于“零信任”模型的网络安全基础架
构,认证基于受信任的设备和用户而非网络本身。从 2014 年 12 月起,谷歌已经先后发表了
6 篇 BeyondCorp 相关论文,全面介绍 BeyondCorp 的架构和实施情况。
360 身份安全实验室对该系列论文进行翻译,将在近期陆续公开,供业界各位同仁参考、
交流。论文原文来自于谷歌官网,如有侵权,请联系删除。译文中难免出现错误或不妥之处,
敬请谅解并欢迎批评指正。联系邮箱:cairan@360.net;zhangliting@360.net。
版本信息
文档名称
版本 密级 创建人 创建日期
谷歌 BeyondCorp:从设计到部署
V1.0 公开
cr
2018.10
修订记录
修订日期 修订版本 修订内容
修订人
2018.11.5
V2.0
对部分译文、格式进行修正 cr,sy,zlt,zzz
©2018 360 企业安全集团 保留所有权利
1 / 13
谷歌 BeyondCorp:从设计到部署
谷歌 BeyondCorp 项目的目标是为了提高员工和设备访问企业内部应用的安全性。
与传统的边界安全模型不同,BeyondCorp 不基于物理位置或发起请求的网络位
置来授予用户访问服务和工具的权限;相反,访问策略的制定完全基于设备的信
息、状态和当前设备的使用者信息。BeyondCorp 模型默认内部网络和外部网络
都是不可信的,需要动态评估当前访问请求的安全等级,并确保此等级满足应用
的最低安全要求。
本文将介绍谷歌如何从传统的安全基础设施迁移到 BeyondCorp 模式,以及在迁
移过程中所面对的挑战和获得的经验教训。关于 BeyondCorp 的架构讨论,请参
见第一篇“BeyondCorp:一种新的企业安全方法”[1]。
概述
如图 1 所示,BeyondCorp 系统的关键组件包括信任引擎(Trust Inferer)、设
备清单服务(Device Inventory Service) 、访问控制引擎(Access Control
Engine)、访问策略(Access Policy)、网关(Gateways)和资源(Resources)。
BeyondCorp 所使用的各术语定义如下:
访问需求被划分为不同的信任等级(Trust Tiers),不同的等级代表着不
同的敏感度,等级越高,敏感度越高。
资源(Resources)代表所有访问控制将覆盖的应用、服务和基础设施。包括在
线知识库、财务数据库、链路层访问、实验室网络等等。需要为每个资源都
分配一个访问所需的最小信任等级。
信任引擎(Trust Inferer)是一个持续分析和标注设备状态的系统。该系
统可设置设备可访问资源的最大信任等级,并为设备分配对应的 VLAN。这些
数据都会记录在设备清单服务中。设备状态的变更或信任引擎无法接受到设
备的状态更新,都会触发其信任等级的重新评估。
访问策略(Access Policy)是描述授权判定必须满足的一系列规则,包含对
资源、信任等级和其他影响授权判定的因子的可编程式表示。
2 / 13
访问控制引擎(Access Control Engine)是一种集中式策略判定点,它为每
个网关提供授权决策服务。授权过程一般基于访问策略、信任引擎的输出结
果、请求的目标资源和实时身份凭证,并返回成功/失败的二元判定结果。
设备清单服务(Device Inventory Service)是 BeyondCorp 系统的中心,它
不断收集、处理和发布在列设备状态的变更。
网关(Gateways)是访问资源的唯一通道,如 SSH 服务器、Web 代理或支持
802.1x 认证的网络等。网关负责授权动作的强制执行,例如强制最低信任等
级或分配 VLAN。
图 1: BeyondCorp 系统的关键组件
BeyondCorp 的组件
通过使用下列组件,BeyondCorp 将各类现有系统组件、新系统及组件进行集
成,以便实现灵活而细粒度的信任决策。
设备(Device)和主机(Host)
要实现基于清单的访问控制,基本前提就是要建立清单库。根据环境和安全策略,
团队需要先针对设备和主机的定义达成一致。设备是物理或虚拟“计算机”,而
主机是指某特定时间点上设备状态的快照。例如,设备可能是一台笔记本电脑或
一部手机,而主机则是运行在该设备上的操作系统和软件的详细信息。设备清单
服务包含设备信息、运行于设备上的主机信息、以及对二者的信任评估。在下面
的章节中,根据不同的访问策略配置,“设备”既可能指代物理设备也可能指代
3 / 13
主机。建立基础清单库后,下述其余组件就可以按需部署,以提供安全性更高、
覆盖率更广、颗粒度更细、延迟性更低、灵活性更佳的基于清单的访问控制服务。
基于信任等级的访问
信任度可以划分为若干信任等级,并由信任引擎为每个设备分配信任等级,另外,
需要为每个资源都事先分配一个访问所需的最低信任等级,简称访问信任等级。
设备被分配的信任等级必须大于等于资源的访问信任等级才可访问该资源。简单
举一个婚庆餐饮公司的例子:送货员只需要查询婚礼的地址,这种访问请求所需
的信任等级较低,事实上,他们也并不需要访问更敏感的服务,比如账单系统,
这类系统一般会分配一个较高的访问信任等级。
分配完成访问请求所需的最低信任等级有几个优点:降低了高安全要求的设备相
关的运维成本(主要是与技术支持成本和生产力相关成本),同时也提高了设备
的可用性。如果允许设备访问更多高敏感数据,则需要更频繁地检测以确保设备
使用者确实“在场”,因此越是信任某个设备,其身份凭证有效期应该越短。因
此,按照潜在访问需求所需的最小信任等级来要求/限定设备所需的信任等级,
就意味着设备使用者在访问过程中受到干扰的程度会降到最小。比如,为了维持
较高的信任等级,就需要设备在几个工作日内必须完成操作系统最新升级包的安
装,而对于信任等级较低的设备,安装更新的时间窗口就可能稍微宽松些。
再举一个例子,一台由公司集中管理的笔记本电脑,由于在一段时间内没有连接
到网络,没有更新到最新状态。如果操作系统缺少几个非关键补丁,其信任等级
可能被降为中等,仅允许访问部分业务应用,而拒绝访问需要更高信任等级的业
务应用。但如果它缺少关键补丁,或者防病毒软件报告该设备已感染病毒,那就
只允许它连接补救服务。在最极端的情况下,一台明确的遗失或被盗设备会被拒
绝访问所有企业资源。
除了分配信任等级,信任引擎还通过标注设备可访问的 VLAN 来进行网络分段。
网络分段允许我们基于设备状态限制对诸如实验室和测试环境下的特定网络的
访问。当一个设备变得不可信时,可以将它分配到隔离网络,在设备恢复信任
之前仅提供有限的资源访问权限。
4 / 13
设备清单服务
设备清单服务(如图 2 所示)是一个不断更新的管道,能够从广泛的数据来源中
导入数据。系统管理数据源可能包括活动目录(Active Directory)、Puppet 和
Simian,其他设备代理、配置管理系统和企业资产管理系统也会向该管道输入数
据。带外(Out-of-band)数据源包括漏洞扫描系统、证书颁发机构和诸如 ARP 映
射表等网络基础设施单元。每个数据源都可以发送设备相关的完整数据或增量更
新数据。
图 2 设备清单服务
设备清单服务自实施初期,已经从超过 15 个数据源中吸收了数十亿的增量数据,
速度约 300 万条/天,总量超过 80TB。保留历史数据非常重要,因为这样才能更
好地了解特定设备的端到端生命周期、跟踪和分析总体趋势、执行安全审计和调
查取证。
数据类型
数据有两种主要的类型:观察数据和预设数据。
观察数据由程序产生,包括以下项目:
最近一次在设备上执行安全扫描的时间,及扫描结果
活动目录的最后同步策略和时间戳
操作系统版本和补丁等级
已安装的软件
预设数据通过 IT 运维手动维护,包括以下内容:
5 / 13
为设备分配的所有者
允许访问该设备的用户和组
分配的 DNS 和 DHCP
对特定 VLAN 的明确访问
在数据不足或客户端平台不可定制的情况下,就需要明确分配(比如打印机就
属于这种情况)。与观察数据所表现的易变性相比,预设数据通常是静态的。
通常需要分析许多来自不同来源的数据,用以识别潜在的数据冲突,而不要盲
目地相信单个或少量系统的数据真实性。
数据处理
数据格式的转换与统一
为了使设备清单服务保持最新状态,涉及几个处理阶段。首先,所有数据必须
转换成一种通用数据格式。一些数据源,比如来自于内部开发系统或开源解决
方案,可以通过改造在提交数据时主动发布给清单服务。而其他来源,特别是
那些第三方数据源,可能无法扩展以支持主动的变更发布,这种情况需要通过
定期轮询来获得更新。
数据关联
输入数据统一格式后,就进入数据关联阶段。在这个阶段,所有来自不同数据
源的数据都被聚合、关联到某一设备,当确定两条记录描述的同一设备时,就
将它们合并为单条记录。数据关联过程看似简单,但在工程实践中却相当复
杂,因为许多数据源之间并不具备数据关联所必须的重叠的“标识符”。
6 / 13
图 3 数据处理管道
例如,资产管理系统可能存储资产 ID 和设备序列号,而磁盘加密托管系统存储
硬盘序列号,证书颁发机构存储证书指纹,ARP 数据库存储 MAC 地址。这些数据
不具备一个重叠的“标识符”,难以确定来自这些独立系统中的增量是否描述的
是同一个设备,只有在清单报告代理同时报告几个或全部这些标识信息之后,这
些多源的、没有交集的记录才可能合并为单条记录。
如果再考虑到设备的全生命周期,相关的信息及其关联过程将更加一团糟,因为
硬盘、网卡、机箱和主板都有可能被替换,甚至会在设备之间交换。另外,如果
还存在人为的数据录入错误,情况会更加复杂。
信任评估
一组输入记录被关联合并,就会触发引擎进行重新评估。为了分配信任等级,评
估分析过程引用多种字段并聚合产生最终结果。信任引擎目前从不同的数据源引
用了数十个字段,包括针对特定平台的和平台无关的;随着系统的不断演化,还
有数百万个额外字段可供分析。例如,为了获得较高信任等级,可能需要一个设
备满足以下所有需求(或更多):
加密
成功执行所有的管理和配置代理
7 / 13