读零信任网络：在不可信网络中构建安全系统19Google的BeyondCorp.png

1. 概述

1.1. 基于用户身份而不是网络位置的访问控制体系，用于控制对应用、数据和服务的访问

1.2. Google的全新网络安全模型完全抛弃了特权网络的概念，访问授权仅仅依赖于用户和设备的凭证，而与用户和设备所在的网络位置无关，用户无论使用公司内网、家庭网络还是酒店或咖啡店的网络，都不会影响访问请求的授权结果

1.3. 在新的安全模型中，所有对企业资源的访问都要基于设备状态和用户凭证进行认证、授权和加密，并且可以针对不同的企业资源进行细粒度的访问控制

1.4. BeyondCorp由许多相互协作的组件构成，通过这些组件之间的协作，确保只有经过严格认证的设备和用户才能被授权访问所需的企业应用

1.5. 当需要在不同的策略中做出权衡和选择时，务必把零信任的核心动机和设计原则牢记于心

2. 安全地识别设备

2.1. 使用设备清单库和设备证书安全地标识和追踪所有受控设备

2.2. 设备清单库

• 2.2.1. 使用了“受控设备”的概念，即由企业采购并妥善管理的设备

• 2.2.2. 只有“受控”设备才能访问企业应用

• 2.2.3. 以设备清单库为基础的设备追踪和采购流程是BeyoundCorp安全模型的基石之一

• 2.2.4. BeyondCorp会追踪所有受控设备，在设备的生命周期内发生的任何变更都会被记录下来，这些信息被持续监控和分析追踪，同时提供给BeyondCorp的其他组件

• 2.2.5. 只要建立起元设备清单库，就能够掌握访问企业应用资源的所有设备信息

2.3. 设备身份

• 2.3.1. 所有受控设备都要具备唯一的标识，用于索引设备清单库里相关设备的信息

• 2.3.2. 为每台设备签发专用的设备证书是其中一种实现方式

• 2.3.3. 只有在设备清单库中登记在册且信息正确的设备才可以获得设备证书，这些证书需要保存在硬件或软件模式的可信平台模块（TPM）中，或者保存在可靠的系统证书数据库中

• 2.3.4. 设备自身以及设备证书的存储方式是否安全可靠需要进行验证，只有被认为足够安全的设备才能被归类为受控设备

• 2.3.5. 当证书定期更新时，也需要重新验证设备的安全可靠性

• 2.3.6. 验证通过的设备，其安装的证书就可以用于后续的企业应用访问过程

• 2.3.7. 虽然证书可以唯一地标识设备，但仅凭设备证书并不能获得访问权限，证书只是获取该设备相关信息的一把钥匙

3. 安全地识别用户

3.1. 单点登录（SSO）系统是BeyondCorp的集中式用户认证门户，它负责对请求访问企业资源的用户进行双因子认证，用户认证需要使用用户数据库和群组数据库

3.2. 用户认证成功之后，SSO系统会生成短时令牌，它可以作为特定资源访问授权过程的一部分

4. 访问代理

4.1. Google的所有企业应用都通过面向互联网的访问代理开放给外部和内部客户端，该代理对客户端和企业应用之间的通信数据进行强制加密处理

4.2. 访问代理可以基于每一个应用进行配置，同时提供了很多通用特性

• 4.2.1. 全局访问可达、负载均衡、访问控制检查、应用安全检查以及抗拒绝服务攻击等

• 4.2.2. 完成访问控制检查后，访问代理将访问请求转发给后端应用

5. 实施基于清单库的访问控制

5.1. 随着时间的推移，授予某个用户或设备的访问权限级别也可能会发生变化

5.2. BeyondCorp能够通过查询多个不同的数据源，动态推断用户或设备的信任等级

5.3. 信任等级是后续访问控制引擎执行授权判定的关键参考信息

• 5.3.1. 如果某个设备没有安装最新的操作系统安全补丁，那么其信任等级会被降低

• 5.3.2. 某一类特定设备，比如特定型号的移动电话或平板电脑，可以被分配特定的信任等级

• 5.3.3. 从新的地理位置访问企业应用的某个用户，会被分配不同的信任等级

• 5.3.4. BeyondCorp同时使用了静态规则和启发式动态规则来确定用户或设备的信任等级

5.4. 授权的判定因素

• 5.4.1. 用户的信息、用户所在的群组、设备证书以及设备清单库中获取的设备属性

• 5.4.2. 用户和设备的信任等级

• 5.4.3. 如果有必要，访问控制引擎也可以执行基于地理位置的访问控制

  • 5.4.3.1. 访问控制引擎还可以通过不同的方式来限制应用程序的各部分

6. 使用和扩展GFE

6.1. GFE（Google前端）

6.2. 为了评估策略，传统的做法是在每个后端应用上集成设备信任评估服务，但是这种做法会显著降低产品安装和更换的效率

6.3. 通过前端的访问代理提供集中化的策略强制执行机制，用来处理粗粒度的企业安全策略

6.4. BeyondCorp利用Google现有的前端（GFE）架构作为访问策略强制执行的逻辑中心

• 6.4.1. 因为所有的访问请求都汇集到这个逻辑中心进行处理，所以自然就可以在此基础上扩展GFE的功能，比如自助服务开通、认证、授权和集中式日志记录等

6.5. 访问代理通过引入认证和授权策略处理机制对GFE进行了扩展

• 6.5.1. 访问代理需要对发起访问请求的用户和设备进行认证，才能做出正确的授权判定

• 6.5.2. 访问代理集成Google的身份提供者服务完成用户身份认证

  • 6.5.2.1. 访问代理支持多种第三方认证机制（包括OpenID Connect、OAuth等）也支持一些定制化协议

• 6.5.3. 访问代理完成用户认证之后，将用户凭证的相关信息从访问请求中去除，然后再将访问请求转发至后端服务

  • 6.5.3.1. 确保后端服务无法通过访问代理重放访问请求（或用户凭证）

  • 6.5.3.2. 访问代理对后端服务透明

    6.5.3.2.1. 后端服务可以在访问代理的数据流之上叠加自身的认证逻辑，并且也避免了将不必要的Cookie和用户凭证暴露给后端业务

• 6.5.4. 集中的访问控制列表（ACL）引擎，支持远程过程调用服务（PRC）查询

• 6.5.5. 专用的访问控制列表表示语言，使其同时兼顾可读性和可扩展性

• 6.5.6. BeyondCorp的做法是由访问代理完成集中式的粗粒度应用访问授权，由后端应用各自实现自身的细粒度授权

• 6.5.7. 后端应用把访问控制逻辑委托给前端执行

  • 6.5.7.1. 后端应用需要适当的机制来确保前端访问代理转发的访问流量的确已经通过了认证和授权检查

  • 6.5.7.2. 后端应用接收到的只是在加密通道中传输的HTTP请求

• 6.5.8. BeyondCorp采用了Google内部开发的认证和加密框架LOAS（Low Overhead Authentication System，低开销认证系统），它可以支持访问代理和后端应用之间的双向认证和通信加密

• 6.5.9. 后端能够信任访问代理在访问请求中插入的任何元数据（通常以HTTP消息头的形式）

  • 6.5.9.1. 在反向代理和后端应用之间使用自定义协议额外插入元数据并不是什么新方法

  • 6.5.9.2. 访问代理和后端应用的双向认证机制可以确保元数据的不可欺骗性

• 6.5.10. BeyondCorp就是采用这种方式实现了设备信任等级向后端应用的传递，后端应用可以根据信任等级进行相应的处理

7. 多平台设备认证面临的挑战

7.1. 准确地识别设备至少需要以下两个组件

• 7.1.1. 某种形式的设备标识

• 7.1.2. 可以跟踪任何指定设备最新状态的设备清单库

7.2. 以适当的设备信任替代基于网络位置的信任，所以每个设备都必须有一个一致的、不可克隆的标识，关于设备安装的软件、所属用户和位置的相关信息必须整合到设备清单库中

7.3. 台式机和笔记本电脑使用X.509证书，对应的私钥存储在操作系统的证书库中

• 7.3.1. 密钥的安全存储是现代操作系统的标准功能，它确保通过访问代理与服务器通信的命令行工具（以及守护进程）能够匹配正确的设备标识

• 7.3.2. 由于TLS要求客户端提供拥有私钥的密码学证明，而且设备标识存储在诸如可信平台模块（Trusted Platform Module, TPM）这类安全硬件中，因此就能确保设备标识的不可欺骗性且不可克隆性

7.4. 移动设备的认证可以不依赖证书

• 7.4.1. 移动操作系统本身就可以提供安全性高的设备标识

• 7.4.2. IOS设备可以使用Vender标识符（identifierForVender,IDFV）

• 7.4.3. 安卓设备可以使用企业移动管理软件（EMM）提供的设备ID

8. 迁移到BeyondCorp

8.1. Google投入了大量资源分阶段地进行迁移，在不影响公司生产力的情况下，成功地将大批网络用户迁移到了BeyondCorp

8.2. 部署无特权网络

• 8.2.1. 该网络虽然使用私有地址空间，但是其用户体验与外部网络非常相似

• 8.2.2. 无特权网络只提供互联网访问、受限的基础网络服务（如DNS、DHCP和NTCP等）以及Puppet这类配置管理服务

• 8.2.3. Google办公区域中的所有客户端设备都被分配到这个无特权网络，对无特权网络与Google其他网络的访问通过严格的ACL进行限制

8.3. 工作流迁移赋能

• 8.3.1. Google的所有应用都要迁移到BeyondCorp，并最终通过访问代理进行访问

• 8.3.2. 在特权网络中直接访问，在外网可以通过VPN访问

• 8.3.3. 在特权网络中直接访问，在外网和无特权网络中通过访问代理访问

• 8.3.4. 在外网、特权网络和无特权网络均通过访问代理访问

8.4. 减少VPN的使用

• 8.4.1. 积极劝阻用户使用VPN

• 8.4.2. 只有经证实确有需要的用户才能使用VPN访问

• 8.4.3. 监控VPN的使用，如果用户在一段时期内未使用过VPN，就取消其VPN访问权限

• 8.4.4. 监控VPN的使用，如果用户在一段时期内未使用过VPN，就取消其VPN访问权限

8.5. 流量分析管道

• 8.5.1. 只有确信（或接近确信）用户的工作流都可以从无特权网络中获取到，才能将用户迁移至无特权网络

• 8.5.2. 从公司的每个交换机中采集网络流的样本，作为流量分析管道的输入

• 8.5.3. 基于ACL分析无特权网络与公司其他网络之间的网络流量，识别命中ACL的流量

• 8.5.4. 对于没有命中ACL的“逃逸”流量，将其关联到特定的工作流和/或特定的用户（特定的设备）上

• 8.5.5. 逐步解决这些“逃逸”流量的问题，以使它们能够在BeyondCorp环境下工作

8.6. 模拟无特权网络

• 8.6.1. 作为补充，除了通过交换机采样流量并进行流量分析外，我们还利用安装在Google用户设备上的流量监视器，模拟了整个公司的无特权网络行为

• 8.6.2. 流量监视器有两种工作模式

  • 8.6.2.1. 日志记录模式

    8.6.2.1.1. 捕获“逃逸”流量，但仍允许上述流量流出设备

  • 8.6.2.2. 强制执行模式

    8.6.2.2.1. 捕获和丢弃“逃逸”流量

8.7. 迁移策略

• 8.7.1. 根据工作职责、（和/或）工作流程、（和/或）地理位置识别潜在的可迁移候选人集合

• 8.7.2. 在日志记录模式下运行模拟器，识别连续30天合格流量大于99.9%的用户和设备

• 8.7.3. 如果在这段时间内用户和设备的合格流量大于99.99%，则为这些用户和设备启动强制执行模式

  • 8.7.3.1. 如有必要，用户可以将模拟器恢复到日志记录模式

• 8.7.4. 强制执行模式成功运行30天后，将其记录在设备清单库中

• 8.7.5. 如果用户和设备在可迁移对象候选人集合中，并且在模拟器强制执行模式下成功工作了30天，就可以把用户和设备迁移到无特权网络了

8.8. 豁免处理

• 8.8.1. 允许用户在迁移过程中请求临时豁免

• 8.8.2. 维护一个未完成BeyondCorp赋能、尚未达到迁移标准的工作流列表

• 8.8.3. 用户可以搜索该工作流列表，经过审批后，将他们自身以及设备标注为特定工作流的活跃用户

• 8.8.4. 该工作流完成BeyondCorp赋能之后，相关用户会收到通知，并再次进入可迁移候选人名单

9. 经验教训

9.1. 沟通

• 9.1.1. 安全基础设施的根本性改变可能会对整个公司的生产力产生负面影响，因此与用户充分沟通这种改变带来的影响、可能出现的问题以及可能的补救措施十分重要

• 9.1.2. 沟通不足可能导致的问题

  • 9.1.2.1. 问题发生时，用户感到惊讶和疑惑

  • 9.1.2.2. 补救措施效果差

  • 9.1.2.3. IT支持人员的工作超出负荷

• 9.1.3. 过度沟通可能导致的问题

  • 9.1.3.1. 不愿改变的用户会倾向于高估变化带来的影响，并企图寻求不必要的豁免

  • 9.1.3.2. 当出现有危险的变化时，用户会认为是正常现象

  • 9.1.3.3. Google的企业基础设施在许多互不相关的方面同时开展工作，用户很容易将应用访问相关的问题与其他正在进行的项目问题混淆，这也会降低补救措施的效率，增加技术支持人员的工作负荷

9.2. 工程师需要支持

• 9.2.1. 迁移能否成功很大程度上取决于团队在访问代理上配置后端服务的难易程度，因此后端服务的配置上线应当以减轻开发人员的开发负担为目标，要把异常情况的出现维持在最低限度

• 9.2.2. 沙箱在大部分情况下都非常有用，比如在对X.509证书或底层TLS库进行重大变更之后，需要确保客户端TLS连接能成功进行时，可以使用沙箱进行验证

9.3. 数据质量和相关性

• 9.3.1. 资产管理的数据质量问题非常关键，它可能会导致用户设备无意中失去对企业资源的访问权限

• 9.3.2. 拼写错误、标识错误和信息丢失都是常见的数据质量问题，导致此类问题出现的原因有很多，可能是采购团队接收资产并将其添加至系统时的人为失误，也可能是制造商工作流程的失误

• 9.3.3. 改进工作流程，并增加自动输入验证功能，以便于在数据录入时发现并减少人为错误

• 9.3.4. 准确的信任评估需要设备清单库提供高精度的数据，这会迫使人们高度关注设备清单库中的数据质量

• 9.3.5. 零信任架构设备信任评估使数据的精确性达到前所未有的水平，也带来了一定的安全价值

9.4. 稀疏数据集

• 9.4.1. 设备清单库的上游数据源不一定有重叠的设备标识符

  • 9.4.1.1. 新设备也许有资产标签，但是没有主机名

  • 9.4.1.2. 在设备生命周期的不同阶段，硬盘序列号可能与不同的主板序列号相关联

  • 9.4.1.3. MAC地址可能发生冲突