谷歌BeyondCorp系列论文（二）：从设计到部署
前言
随着企业大规模的采用移动互联网和云计算技术，传统的采用防火墙建立的“城堡”安全模式，变得越来越不安全。2014年12月起，Google先后发表6篇BeyondCorp相关论文，论文提供了一种新的安全模式，设备和用户只能获得经过验证的资源，构建软件定义安全的雏形。另外，论文也介绍了BeyondCorp的架构和实施情况，为传统网络架构迁移至BeyondCorp架构提供依据参考。
为推动国内安全技术和理论与国际同步，在国内传播国际优秀实践，中国云安全联盟秘书处组织专家翻译BeyondCorp相关论文，供大家学习参考。特别感谢CSA大中华区SDP工作组与奇安信身份安全实验室对本次翻译工作的贡献及支持！
本文档一共由BeyondCorp的六篇论文组合而成：
[1] BeyondCorp：一种新的企业安全方案
[2] 谷歌BeyondCorp：从设计到部署
[3] BeyondCorp：访问代理
[4] 迁移到BeyondCorp：提高安全性的同时保持生产力
[5] BeyondCorp ：用户体验
[6] BeyondCorp：构建健康机群
该系列论文将定期向大家推送，敬请关注“云安全联盟CSA”公众号。
【第二篇】谷歌BeyondCorp：从设计到部署
谷歌BeyondCorp项目的目标是为了提高员工和设备访问企业内部应用的安全性。与传统的边界安全模型不同，BeyondCorp不基于物理位置或发起请求的网络位置来授予用户访问服务和应用的权限；相反，访问策略的制定完全基于设备的信息、状态和当前设备的使用者信息等等。BeyondCorp模型默认内部网络和外部网络都是不可信的，需要动态评估当前访问请求的安全等级，并确保此等级满足应用的最低安全要求。
本文将介绍谷歌如何从传统的安全基础设施迁移到BeyondCorp模式，以及在迁移过程中所面对的挑战和获得的经验教训。关于BeyondCorp的架构讨论，请参见第一篇“BeyondCorp：一种新的企业安全方案”[1]。
概述
BeyondCorp系统的关键组件包括信任引擎（Trust Inferer）、设备清单服务(Device Inventory Service)、访问控制引擎(Access Control Engine)、访问策略(Access Policy)、网关（Gateways）和资源(Resources)，如图1所示，BeyondCorp所使用的各术语定义如下：
l 访问需求被划分为不同的信任等级（Trust Tiers），不同的等级代表着不同的敏感度，等级越高，敏感度越高。
l 资源(Resources)代表所有访问控制机制将覆盖的应用、服务和基础设施。包括在线知识库、财务数据库、链路层访问、实验室网络等等，需要为每个资源都分配一个访问所需的最小信任等级。
l 信任引擎（Trust Inferer）是一个持续分析和标注设备状态的系统。该系统可设置设备可访问资源的最大信任等级，并为设备分配对应的VLAN，这些数据都会记录在设备清单服务中。任何设备状态的更新，或者信任引擎无法接收到设备的状态更新消息，都会触发对其信任等级的重新评估。
l 访问策略(Access Policy)是描述授权判定必须满足的一系列规则，包含对资源、信任等级和其他影响授权判定的因子的程序式表示。
l 访问控制引擎(Access Control Engine)是一种集中式策略判定点，它为每个访问网关提供授权决策服务。授权过程一般基于访问策略、信任引擎的输出结果、请求的目标资源和实时的身份凭证信息，并返回成功/失败的二元判定结果。
l 设备清单服务(Device Inventory Service)是BeyondCorp系统的中心，它不断收集、处理和发布所有在列设备状态的变更。
l 网关（Gateways）是访问资源的唯一通道，如SSH服务器、Web代理或支持802.1x认证的网络等。网关负责对授权决策进行强制执行，例如强制最低信任等级或分配VLAN。
图1: BeyondCorp系统的关键组件
BeyondCorp的组件
通过使用下列组件，BeyondCorp将各类已有系统组件、新系统组件进行集成，以便实现灵活而细粒度的信任判定。
设备（Device）和主机(Host)
要实现基于清单的访问控制，基本前提就是要建立清单库。基于环境和安全策略，团队需要先针对设备和主机的定义达成一致。设备（device）是物理或虚拟“计算机”，而主机（host）是指某特定时间点上设备状态的快照。例如，设备可能是一台笔记本电脑或一部手机，而主机则是运行在该设备上的操作系统和软件的详细信息。设备清单服务包含设备信息、运行于设备上的主机信息、以及对二者的信任评估。在下面的章节中，根据不同的访问策略配置，“设备”既可能指代物理设备也可能指代主机。建立基础清单库后，其余组件就可以按需部署，以提供安全性更高、覆盖率更广、颗粒度更细、延迟性更低、灵活性更佳的基于清单的访问控制服务。
基于信任等级的访问
信任度可以划分为若干信任等级，并由信任引擎为每个设备分配信任等级，另外，需要为每个资源都事先分配一个访问所需的最低信任等级，简称访问信任等级。设备被分配的信任等级必须大于等于资源的访问信任等级才可访问该资源。简单举一个婚庆餐饮公司的例子：送货员只需要查询婚礼的地址，这种访问请求所需的信任等级较低，事实上，他们也并不需要访问更敏感的服务，比如账单系统，这类系统一般会分配一个较高的访问信任等级。
分配访问信任等级有几个优点：降低了高安全要求的设备相关的运维成本（主要是与技术支持和生产力相关的成本），同时也提高了设备的可用性。如果允许设备访问更多高敏感数据，则需要更频繁地检测以确保设备使用者确实“在场”，因此越是信任某个设备，其身份凭证有效期应该越短。因此，按照潜在访问需求所需的最低信任等级来要求/限定设备所需的信任等级，就意味着设备使用者在访问过程中受到干扰的程度会降到最小。比如，为了维持较高的信任等级，就需要设备在几个工作日内必须完成操作系统最新升级包的安装；而对于信任等级需求较低的设备，安装升级包的时间窗口就可以稍微宽松些。
再举一个例子，一台由公司集中管理的笔记本电脑，由于在一段时间内没有连接到网络，因此没有更新到最新状态。如果操作系统缺少几个非关键补丁，其信任等级可能被降为中等，仅允许访问部分业务应用，而被拒绝访问需要更高信任等级的业务应用。但如果它缺少关键补丁，或者防病毒软件报告该设备已感染病毒，那就只允许它连接补救服务。在最极端的情况下，一台明确的遗失或被盗设备会被拒绝访问所有企业资源。
除了分配信任等级，信任引擎还通过标注设备可访问的VLAN来进行网络分段。网络分段允许我们基于设备状态来限制对诸如实验室和测试环境的特定网络的访问权限。当一个设备变得不可信时，可以将它分配到隔离网络，在设备恢复信任之前仅提供有限的资源访问权限。
设备清单服务
设备清单服务（如图2所示）是一个不断更新的数据管道，能够从广泛的数据来源中导入数据。系统管理数据源可能包括活动目录（Active Directory）、Puppet和Simian，其他设备代理、配置管理系统和企业资产管理系统也会向该管道导入数据。外部（Out-of-band）数据源包括漏洞扫描系统、证书颁发机构和诸如ARP映射表等网络基础设施单元。每个数据源都可以发送设备相关的完整数据或增量数据。
图2 设备清单服务
BeyondCorp设备清单服务自实施初期，已经从超过15个数据源中吸收了数十亿的增量数据，速度约300万条/天，总量超过80TB。保留历史数据非常重要，因为这样才能更好地了解特定设备的端到端生命周期、跟踪和分析总体趋势、执行安全审计和调查取证。
数据类型
数据有两种主要的类型：观察数据和预设数据。
观察数据由程序产生，包括以下项目：
l 最近一次在设备上执行安全扫描的时间,及扫描结果
l 活动目录的最后同步策略和时间戳
l 操作系统版本和补丁等级
l 已安装的软件
预设数据通过IT运维手动维护，包括以下内容：
l 为设备分配的所有者
l 允许访问该设备的用户和组
l 分配的DNS和DHCP
l 对特定VLAN的显式访问权限
在数据不足或客户端平台不可定制的情况下，就需要明确分配（比如打印机就属于这种情况）。与观察数据所表现的易变性相比，预设数据通常是静态的。通常需要分析许多来自不同来源的数据，用以识别潜在的数据冲突，而不要盲目地相信单个或少量系统的数据真实性。
数据处理
数据格式的转换与统一
为了使设备清单服务保持最新状态，涉及几个处理阶段。首先，所有数据必须转换成一种通用数据格式。一些数据源，比如内部自研系统或开源解决方案，可以通过系统改造，在提交数据时主动发布给清单服务。而其他来源，特别是那些第三方数据源，可能无法扩展或改造，难以支持主动的变更发布，这种情况需要通过定期轮询来获得更新。
数据关联
当输入数据格式统一后，就进入数据关联阶段。在这个阶段，所有来自不同数据源的数据都被聚合、关联到某一设备，当确定两条记录描述的是同一设备时，就将它们合并为单条记录。数据关联过程看似简单，但在工程实践中却相当复杂，因为许多数据源之间并不具备数据关联所必须的重叠的“标识符”。
图3 数据处理管道
例如，资产管理系统可能存储资产ID和设备序列号，而磁盘加密托管系统存储硬盘序列号，证书颁发机构存储证书指纹，ARP数据库存储MAC地址。这些数据不具备一个重叠的“标识符”，难以确定来自这些独立系统中的增量是否描述的是同一个设备，只有在清单报告代理同时报告几个或全部这些标识信息之后，这些多源的、没有交集的记录才可能合并为单条记录。
如果再考虑到设备的全生命周期，相关的信息及其关联过程将更加一团糟，因为硬盘、网卡、机箱和主板都有可能被替换，甚至会在设备之间交换。另外，如果还考虑人为的数据录入错误，情况会更加复杂。
信任评估
一组输入记录一旦完成关联合并，就会触发引擎进行重新评估。为了分配信任等级，评估分析过程引用多种字段并聚合产生最终结果。信任引擎目前从不同的数据源引用了数十个字段，包括针对特定平台的和平台无关的；随着系统的不断演化，还有数百万个额外字段可供分析。例如，为了获得较高信任等级，可能需要一个设备满足以下所有（或更多）需求：
l 加密
l 成功执行所有的管理和配置客户端程序（agents）
l 安装最新的操作系统安全补丁
l 从所有输入源中获得的数据状态一致
这种信任等级预计算减少了必须被推送到网关的数据量，以及在为访问请求做授权判定时所需的计算量。这一步也确保所有的执行网关都使用了一致的数据集合。在这个阶段，我们甚至可以对非活跃设备修改信任等级。比如在以前，我们会预先拒绝所有可能受到Stagefright[2]漏洞影响的设备的访问权限，即便它们还没发起实质性的访问请求。预计算同样为我们提供了一个实验框架，在此框架中可以对变更进行预验证，以及在不影响整个公司的情况下，对策略或信任引擎进行小幅度的局部调整和验证。
当然，预计算也有它的局限性，还不能完全依赖它。比如，访问策略可能要求进行实时的双因子认证，或者限制来自某已知恶意网段的访问请求。策略或设备状态变更与网关真正执行这个变更之间的延迟并不是什么大问题，因为更新延迟通常在1秒以内。事实上更本质的问题是，并不是所有的信息在预计算阶段都能够获取。
特殊处理
信任引擎对于设备信任等级的分配有最终决定权。信任评估还需要考虑设备清单服务中已存在的特殊处理。通过特殊处理，允许对通用访问策略进行覆盖和重写。特殊处理主要为了降低策略变更或新策略的生效延迟。比如，由于安全扫描设备可能尚未升级，检测不出某种零日攻击，但可以通过特殊处理立即阻止某台可能遭受零日攻击的设备；同样，可以采用特殊处理，允许将某台不可信设备连接到实验室网络。物联网设备安装和维护设备证书可能并不可行，同样可以通过特殊处理，直接为其分配适合的信任等级以确保正常访问。
部署
首次上线
BeyondCorp上线的第一阶段包含一部分网关和初步的元清单服务，这些服务仅由少数几个数据源构成，主要是一些预设数据。最初实现的访问策略模拟了谷歌已有的基于IP的边界安全模型，并将这个策略集应用到不可信设备上，为来自特权网络的设备保留不变的访问权限。这种策略能够确保在系统完善之前，能安全地部署系统的一些组件，而不会影响用户的平滑使用。
与此同时，BeyondCorp团队也在设计、开发并持续迭代一个规模更大、延迟更低的元清单解决方案。这个设备清单服务从超过15个数据源收集数据，根据正在主动生成数据的设备数量，每秒钟可能有30至100个不等的数据变更。设备清单服务主要提供的是企业设备的信任资格标注和强制授权。随着元清单解决方案的成熟，可以获得更多的设备信息，能够逐步地依靠信任等级分配，逐步替代基于IP的策略。在验证了低信任等级设备的工作流后，对更高信任等级的访问进行细粒度限制，并逐步迈向最终目标：随着时间的推移，有序扩大设备和企业资源的信任等级分配范围，并基于信任等级进行访问控制。
考虑到前文提到的从不同来源关联数据的复杂性，BeyondCorp采用x.509证书作为固定的设备标识符。x.509证书提供了两个核心功能：
l 如果证书发生变化，即使所有其他标识符都保持相同，设备也被标记为不同设备。
l 如果证书安装在不同的设备上，关联逻辑会发现证书冲突以及与辅助标识不匹配，随即做出反馈，降低设备信任等级。
证书并未降低数据关联的必要性，其本身也不足以获得访问权限。但它确实能提供一个基于密码学的GUID，访问网关还可将其用于流量加密，并持续、唯一地标识设备。
移动设备
谷歌一直力图使移动设备成为主流平台，移动设备必须能够完成与其他平台相同的任务，因此也需要相同的访问等级。与其他平台相比，在移动平台上部署信任等级访问模型更容易。移动设备的特点是没有太多传统遗留通信协议和访问方法，因为几乎所有通信都是基于HTTP的。安卓设备使用加密的安全通信，允许在设备清单中识别设备。值得一提的是，由于API也位于与访问控制引擎集成的访问代理之后，因此原生应用程序与通过Web浏览器访问的资源都能通过相同的授权机制进行保护。
遗留（legacy）平台和第三方平台
为了支持遗留平台和第三方平台，我们需要采用比移动设备更广泛的访问方法。为此任意TCP和UDP流量，我们通过SSH隧道和客户端SSL/TLS代理技术提供的隧道通信。 而网关只允许符合访问控制引擎中策略的隧道业务通过。RADIUS[3]是一个特例：它与设备清单服务集成，但它从信任引擎接收的是VLAN的分配结果，而不是信任等级的分配。在网络连接时，RADIUS使用802.1x认证的证书来作为设备标识符，通过信任引擎分配的结果，动态设置VLAN。
避免干扰用户
在部署BeyondCorp的过程中，面临的最大挑战之一是如何在不干扰用户的情况下完成如此大规模的任务。为了制定策略，需要先确认现有的工作流。从现有的工作流中，可以确定：
l 哪些工作流，可以与无特权网络兼容
l 哪些工作流允许进行超出预设的访问或哪些工作流允许用户绕过已经存在的限制
为了确认工作流，我们采用双管齐下的模式。一方面，开发了一个模拟管道，它可以检查IP级元数据，将流量划分到服务，并在模拟环境中应用了我们预期的网络安全策略；另一方面，将安全策略转换为每个平台本地防火墙配置语言。在企业网络上，这种手段可以很好的记录流量元数据，这些流量是访问谷歌企业服务所必须的，稍有差池，迁移到无特权网络后，这些服务很可能无法访问。在此过程中，我们还有一些令人惊讶的意外发现，比如那些早就应该下线的服务，却不明就里的仍在运行。
收集了这些数据之后，通过与服务所有者合作，将他们的服务迁移到支持BeyondCorp的网关。有些服务很容易迁移，但还有些服务则比较困难，需要一些特殊处理机制。不过，这种情况都明确指定了责任人，确保服务所有者能在限定期限内消除例外。随着越来越多的服务进行了更新和改造，越来越多的用户在不执行任何例外处理的情况下也可以正常工作很长一段时间，此时，就可以将用户的设备分配到一个无特权的VLAN。通过这种方法进行过渡，用户使用不兼容BeyondCorp的应用不会感到不太方便；迁移压力基本都在服务提供者和应用程序开发人员身上，这可以促使他们正确地配置相关服务。
特殊处理增加了BeyondCorp生态系统的复杂性，随着时间的推移，“为什么我的访问被拒绝了？”这个问题的答案已经不那么明了。基于清单数据和实时请求数据，需要非常明确地判断特定请求在特定时间点失败或成功的原因。回答上述问题的第一步是与终端用户建立沟通（警告其潜在的问题，以及如何进行自我修复或联系支持），并培训IT运维人员。此外，还开发了一种服务，它可以分析信任引擎的决策树和影响设备信任等级分配的事件的时间顺序，从而提出补救措施。有些问题用户可以自己解决，不需要权限更高的支持人员。拥有额外访问路径的用户通常能够自我修复，例如，如果用户认为他的笔记本电脑信任评估不当,但手里还有一只信任等级足够的手机，我们可以将诊断请求转发给这个手机进行评估。
挑战和经验教训
数据质量及相关性
资产管理的数据质量问题可能导致设备无意中失去对企业资源的访问权限。拼写错误、标识错误和信息丢失都是常见问题。此类问题可能由于采购团队收到资产并将其添加至系统时的人为失误，也可能是由于制造商工作流程的失误导致。数据质量问题也经常发生在设备维修过程中，主要原因在于替换设备的零部件或在设备之间交换某个部件。这些问题可能会破坏设备记录，除非人工检查这些设备，否则很难修复这些记录上的差错。例如，单条设备记录可能实际上包括两个不同设备的数据，要自动修复和分离数据甚至需要调整设备硬件的资产标签甚至主板序列号。
这时最有效的解决方案是通过本地工作流程改进并增加自动输入验证，以便在输入时发现并减少人为错误。复式记账法有一定帮助但是并不能发现所有错误。做出准确的信任评估需要设备清单库提供高精度的数据，所以这又迫使人们不得不重新关注设备清单库中的数据质量。这种数据的精确性要求是前所未见的，也带来了前所未有的价值。比如，我们能精确地知道终端信息，安装最新补丁的情况，进而提高整个系统安装最新补丁的百分比。
稀疏数据集
如前所述，上游数据源未必有重叠的设备标识符。以下列举一些潜在的场景：新设备可能有资产标签，但没有主机名；在设备生命周期的不同阶段，硬盘序列号可能与不同的主板序列号相关联，又或者MAC地址可能会发生冲突。一组简单的启发式算法可以将大部分增量与数据源某个子集相关联，但为了将精度提高到接近100％，需要一组非常复杂的启发式算法来处理看似无穷无尽的边缘情况。一小部分数据不匹配的设备，可能会使数百甚至数千名员工无法使用他们工作中的必需应用。为了减少这种情况的发生，监控并验证各种综合数据可能的情况，精细设计和验证信任评估路径，最终确保符合预期的信任等级评估结果。
管道延迟
由于设备清单服务从几个不同的数据源中获取数据，所以每个源可能都需要一个特定的实施方案。自研系统或基于开源系统的数据源很容易扩展，以便异步地向我们现有管道发布增量。对于其他来数据源必须定期轮询，这需要在轮询频率和由此产生的服务器负载之间取得平衡。尽管将变更信息传递到网关通常不到一秒，但是对于轮询的场景，一些变更可能需要几分钟才能获悉。此外，串行处理本身也会增加时延。因此，需要采用流式处理。
沟通
对安全基础设施的根本性改变可能会对整个公司的生产力产生负面影响。与用户沟通改变的潜在影响、会出现的问题和可能的补救措施十分重要，但是很难找到过度沟通和沟通不足之间的平衡点。沟通不足会让用户感到惊讶和困惑，造成补救措施效果差，IT支持人员的工作也会超负荷。过度沟通也有问题：不愿改变的用户会倾向于高估变化带来的影响并企图寻求不必要的豁免。过于频繁的沟通也会让用户对潜在的影响判断出现偏差，由于谷歌的企业基础设施在许多互不关联的方面同时开展工作，用户很容易将访问相关的问题与其他正在进行的项目问题混淆，这也会降低补救措施的效率，增加支持人员的操作负荷。
灾难恢复
正因BeyondCorp基础设施的组成是非常复杂的，而灾难性的失败甚至会导致支持人员无法访问恢复所需的工具和系统，因此BeyondCorp系统中构建了各种故障保护系统。除了监测信任等级分配的潜在或明显的变化，我们已经利用了现有的一些灾难恢复实践，以确保在发生灾难性紧急情况时，BeyondCorp仍能发挥作用。BeyondCorp的灾难恢复协议基于最小依赖关系，并允许极少的一部分特权维护人员重放清单变更的日志记录，以便恢复到设备清单和信任评估工作以前的良好状态。我们也有能力在紧急情况下细粒度地变更访问策略以确保维护人员启动恢复流程。
下一步
与任何大项目一样，我们在部署BeyondCorp时面临的挑战，有些是预期内的，而有些在意料之外。在谷歌，越来越多的团队正在寻找新的、有趣的方式来整合系统，并提供更详细、更有层次的防护以对抗恶意攻击者。在没有牺牲易用性的前提下，BeyondCorp已经大幅改善了谷歌的安全态势，同时还提供了一个灵活的基础设施，能够基于策略进行授权决策而不受具体技术限制。BeyondCorp在谷歌自身的系统和规模内已取得了相当大的成功，也欢迎其他组织基于这些原则和流程进行部署和完善。
参考文献：
[1] Architectural discussion of BeyondCorp: http://research .google.com/pubs/pub43231.html.
[2] Stagefright: https://en.wikipedia.org/wiki/Stagefright _(bug).
[3] RADIUS: https://en.wikipedia.org/wiki/RADIUS.
转自于微信公众号-云安全联盟CSA
云深互联
云深互联， 取名自古诗：“只在此山中，云深不知处”，旨在通过新一代SDP（软件定义边界）网络隐身技术，使应用程序“隐身”于互联网之中，只对授权用户可见，让黑客无从发起攻击，从而有效保护企业数据资产，让每一家企业数据安全上云，实现高效地互联互通。云深互联成立于2012年，已经成功服务不同行业的500强企业及政府单位，覆盖金融 、能源 、交通 、制造 、地产 、教育、零售等领域。成功获得晨兴资本、IDG资本、达晨创投等一系列知名投资机构数亿元融资。
