前言
随着企业大规模的采用移动互联网和云计算技术，传统的采用防火墙建立的“城堡”安全模式，变得越来越不安全。2014年12月起，Google先后发表6篇BeyondCorp相关论文，论文提供了一种新的安全模式，设备和用户只能获得经过验证的资源，构建软件定义安全的雏形。另外，论文也介绍了BeyondCorp的架构和实施情况，为传统网络架构迁移至BeyondCorp架构提供依据参考。
为推动国内安全技术和理论与国际同步，在国内传播国际优秀实践，中国云安全联盟秘书处组织专家翻译BeyondCorp相关论文，供大家学习参考。
本文档一共由BeyondCorp的六篇论文组合而成：
[1] BeyondCorp：一种新的企业安全方案
[2] 谷歌BeyondCorp：从设计到部署
[3] BeyondCorp：访问代理
[4] 迁移到BeyondCorp：提高安全性的同时保持生产力
[5] BeyondCorp ：用户体验
[6] BeyondCorp：构建健康机群
该系列论文将定期向大家推送，敬请关注“云安全联盟CSA”。
【第三篇】BeyondCorp：访问代理
本文将详细介绍BeyondCorp前端基础设施——访问代理（Access Proxy, AP）的实现，关注其实施过程中遇到的挑战,以及设计和上线中学到的经验教训。此外，对于我们正在开展的，旨在提高员工访问内部应用时使用体验的项目，本文也有所涉及。
向BeyondCorp模型迁移过程中（之前在“BeyondCorp：一种新的企业安全方案”[1]和“谷歌BeyondCorp：从设计到部署”[2]中有讨论），有许多难题需要解决，比如，如何将公司策略应用到所有内部服务就是一个重大挑战。传统方法通常要把每个业务后端与设备信任引擎集成，以便进行应用级策略的评估，然而，这种方法会明显降低产品发布和迭代的速度。
为了解决这个问题，谷歌通过前端访问代理（AP）作为中心化的策略强制执行点，实现粗粒度的公司安全策略。访问代理的设计具有足够的通用性，基于同一套代码我们实现了不同逻辑的网关。目前，访问代理已支持Web代理和SSH网关组件[2]。由于AP是员工访问内部HTTP服务的唯一机制，所有内部服务都需要迁移到AP的后面。
事实证明，我们一开始只打算支持HTTP协议是完全不够的，随着项目的推进，不得不为更多的协议（其中多数都需要端到端加密,如SSH）提供解决方案。支持这些协议通常需要对客户端进行改造，以确保AP准确识别设备。
结合访问代理（AP）和集中的访问控制引擎（Access Control Engine, ACE）（共享的ACL评估系统）主要有两个好处：一是所有请求都途经同一个日志记录点，便于更有效地进行流量分析；二是能够更迅速、更统一地改变执行策略。
目录
BeyondCorp的前端基础设施
任何大规模部署的现代Web应用程序都会采用前端基础设施——通常是负载均衡和/或HTTP反向代理的组合，企业Web应用也不例外，前端基础设施为策略执行点的部署提供了理想位置。因此，谷歌的前端基础设施对于BeyondCorp访问策略的强制执行至关重要。
谷歌前端基础设施的主要组件是HTTP/HTTPS反向代理集群，即谷歌前端服务（Google Front Ends, GFEs）[3]。GFE有很多优点，例如负载均衡和TLS卸载服务。这样Web应用的后端可以专注于服务请求的具体内容，而几乎不必考虑请求的路由细节。BeyondCorp将GFE作为访问策略强制执行的逻辑中心。通过逻辑上的集中，带来请求的汇集，在此基础上就可以自然而然地扩展GFE的功能，比如自助服务开通、认证、授权和集中式日志记录。扩展后的GFE即访问代理（AP）。下文将详细阐述访问代理提供的具体服务。
扩展后的GFE特性：产品需求
GFE有一些内置功能，并不是专门为BeyondCorp设计的但可以为BeyondCorp所用：如，为后端提供负载均衡服务、通过GFE实现TLS卸载。AP通过引入认证和授权策略扩展了GFE。
认证
为了正确处理一个授权请求，AP需要识别发出请求的用户和设备。在多平台环境中，设备认证面临许多挑战，将在后文的“多平台身份认证的挑战”中进行详细讨论，本节重点介绍用户认证。
AP通过集成谷歌的身份提供服务（Identity Provider, IdP）完成用户身份认证。如果要求后端服务必须修改它们自身的身份认证机制才能迁移到AP,不具备伸缩性，所以AP需要支持一系列的认证机制,包括：OpenID Connect、OAuth和一些定制化协议。
AP还需要处理不能提供用户凭证的请求场景，例如，一个软件管理系统试图下载最新的安全补丁，这种情况下，AP可以禁用用户认证。
当AP认证用户后，将用户凭证相关信息从请求中去除后再转发至后端服务，这样做至关重要，有两点原因：
确保后端不能通过访问代理重放请求（或凭证），进行重放攻击。
代理对后端服务透明。这样做的好处在于后端业务可以独立于访问代理的数据流叠加自身的认证逻辑，并且也避免了将cookie和用户凭证不必要的暴露给后端业务。
授权
以下两个设计推动BeyondCorp中授权机制的实施：
一个可通过远程过程调用（Remote Procedure Calls, RPC）查询的集中访问控制列表（Access Control List, ACL）
采用领域特定语言（domain-specific language, DSL）表达访问控制列表（ACL），使其同时兼顾可读性和可扩展性
以服务形式提供ACL评估能够保证多种前端网关的一致性（如RADIUS网络访问控制基础设施、AP和SSH代理）。
集中式授权有好有坏。好处是，通过集中策略执行点，由前端访问代理负责授权可以将后端开发者从处理授权的细枝末节中解放出来，并且一致性更强。坏处是，代理可能无法执行细粒度策略，细粒度授权还是要交由后端处理更好（例如，“用户A被授权去修改资源B”）。
从过去的实践经验来说，将AP提供的粗粒度、集中式授权与后端实现的细粒度授权结合对于前后端来说都是最佳选择。这种方法不会导致重复工作，因为针对特定应用的细粒度策略通常与前端基础设施所执行的企业级策略相互独立。
代理和后端之间的双向身份认证
因为后端业务将访问控制逻辑完全交由前端的AP进行，迫切需要适当的机制确保后端业务能信任AP转发的业务流量已经通过了认证和授权。这种机制尤其重要，因为TLS握手和传输在前端代理就终结了，前端代理是通过另外的加密通道传输HTTP请求给后端业务。
为满足上述要求，需要一个能够建立加密通道的双向认证机制----举个例子：一种可能的实现是基于TLS双向证书认证和企业公钥基础设施。BeyondCorp采用了内部开发的认证和加密框架LOAS(Low Overhead Authentication System, 低开销认证系统 )，它可以对代理和后端之间的所有通信进行双向认证和加密。
前端和后端之间进行双向认证和加密的一个好处是，后端可以信任AP插入的任何元数据（通常以HTTP消息头的形式）。在反向代理和后端之间额外插入元数据、使用自定义协议（比如， Apache JServe 协议）并不是什么新方法,但AP的双向认证机制，确保了元数据的完整性。
采用此方法的另一个好处是，当AP逐渐部署了更多新功能时，后端可以通过简单地解析相应的消息头，获取AP插入的新功能数据，并选择所需信息。使用这个功能可以将设备的安全等级传递到后端，后端可据此调整服务内容。
ACL语言
将领域特定语言（domain-specific language, DSL）用于表述ACL是解决集中式授权挑战的关键。这种语言支持静态编制ACL（有助于提高性能和可测试性），同时减少了策略表述和具体实现之间的逻辑鸿沟。这一策略提高了了以下各方的职责分离：
安全策略团队：负责对访问策略进行抽象和静态编制
清单管道团队：根据发起访问请求的用户和特定设备，负责提供对资源的访问决策的具体实例化（请参阅“谷歌BeyondCorp：从设计到部署”[2]了解关于清单管道的更多细节）
访问控制引擎团队：负责评价和执行安全策略
ACL语言语义上采用首次匹配（first-match）模型，和传统防火墙规则比较类似。虽然这种模型存在一些极端情况（例如，规则之间会相互覆盖），但好在这些情况已经众所周知，安全团队理解起来还是相对容易。当前采用的ACL结构包括两大部分：
全局规则：通常是粗粒度的，影响所有服务和资源。例如，“安全等级低的设备不允许提交源代码”。
针对特定服务的规则：专属于某个服务或主机，通常包括和用户有关的断言。例如，“群组G中的所有厂商允许访问Web应用A”。
以上结构基于一个假设，即服务所有者可以识别应用策略的URL地址范围，除非请求对象不在URL中指定而在报文主体中指定（可以通过修改AP来处理这种情况）。不可避免地，针对特定服务的规则规模会越来越大，因为访问代理会对越来越多的服务负责，而这些服务都需要特定的ACL规则。
全局规则在处理一些特殊的安全状况（例如，员工离职）和应急响应（例如，浏览器漏洞利用或设备被盗）时具有极大的便利性。比如，这种机制曾帮助我们成功处置Chrome浏览器某个第三方插件的0Day漏洞风险,通过创建一条全新的高优先级规则，使用老版本的Chrome浏览器时将会被重定向到一个带有更新指南的页面，该规则30分钟内就在整个公司完成部署和强制执行，最终，存在漏洞的浏览器的数量急剧减少。
集中式日志记录
为了进行必要的事件响应和取证分析，所有请求日志必须进行持久化存储。AP提供了一个理想的日志记录点。日志记录主要包括部分请求头、HTTP响应码、调试或重构访问决策和ACL评估过程所需的元数据，一般包括访问请求的设备标识和用户标识。
访问代理的特性：运维弹性
自助服务开通
一旦访问代理准备就绪，企业应用的开发人员和所有者就可以着手配置通过代理的服务访问模式。
当谷歌逐渐从网络层开始限制用户对公司资源的访问，访问代理就成为了能在迁移过程中保持服务正常运行的最快方案。显然，单个团队无法支撑对AP配置的全部更改，因此将AP配置过程结构化，使用户可以更为便利地使用自助服务。用户保留了他们自己的配置片段的所有权，而AP团队保留构建配置系统的所有权，可以校对、测试、灰度发布（金丝雀发布）和更新配置。
这种设置有几个主要好处：
解放了AP团队，让他们不再需要根据每个用户请求持续修改配置
鼓励服务所有者拥有他们的配置片段（并为其编写测试）
确保开发速度和系统稳定性之间的平衡
仅仅只需几分钟就可以在AP后设置一个服务，用户也可以在不请求AP团队支持的情况下迭代自己的配置片段。
多平台身份认证的挑战
目前，已经理清了BeyondCorp前端在服务侧的情况，包括了其实现及由此带来的困难和挑战。现在将采用类似方法来梳理BeyondCorp中客户端方面的情况。
准确的设备识别至少需要以下两个组件：
某种形式的设备标识
能追踪任何指定设备最新状态的清单数据库
BeyondCorp的目标之一是以适当的设备信任替代基于网络的信任。每个设备都必须有一个一致的、不可克隆的标识，设备的软件、用户和位置的相关信息必须集成到清单数据库中。正如在前两篇BeyondCorp论文中所说，构建和维护设备清单库可能面临着诸多挑战。下面几个小节将更详细地描述与设备认证相关的挑战和解决方案。
台式机和笔记本电脑
台式机和笔记本电脑使用x.509证书，以及系统证书库中对应的私钥。密钥存储是现代操作系统的标准功能，它确保了通过AP与服务器通信的命令行工具（和守护进程）可以与正确的设备标识匹配。由于TLS要求客户端提供拥有私钥的加密证明，而且设备标识存储在类似可信平台模块（Trusted Platform Module, TPM）的安全硬件中，这能确保标识的不可欺骗性且不可克隆性。
但这种实现方式有一个主要缺点：证书验证提示通常会影响用户体验。幸好大多数浏览器都支持通过策略配置或插件扩展自动提交证书。但如果客户端提供了无效证书，服务器拒绝TLS握手,此时也会对用户有所影响。TLS握手失败，浏览器会显示特定的错误消息，且大多不可定制。为了提升用户体验，AP可以接受没有有效客户端证书的TLS会话，但必要时会按需弹出一个HTML拒绝页面。
移动设备
上述解决证书提示问题的策略，在几个主流移动平台中都无需考虑。移动设备的认证可以不依赖证书，因为移动操作系统本身就可以提供安全性高的设备标识。比如，ios设备可以使用苹果的Vendor标识符（Identifier For Vendor, IDFV），安卓设备使用企业移动管理（EMM）应用提供的设备ID。
一些特殊情况和例外
虽然在过去的几年中已经将绝大多数Web应用程序迁移到访问代理，但是仍然有些特殊的用例，要么自身无法与访问代理模式兼容，要么需要经过特殊处理才能兼容。
非HTTP协议
有些谷歌企业应用程序使用了非HTTP协议，这些协议需要端到端加密。为了通过AP为这些协议提供服务，需要将它们封装在HTTP请求中。
幸好有现成的ProxyCommand工具，因此在TLS上将SSH业务封装成HTTP流量并不难。我们开发了一个类似Corkscrew的本地代理，不同之处在于我们使用了WebSockets进行封装。虽然WebSockets和HTTP CONNECT请求都能兼容AP的ACL评估，但WebSockets本身能从浏览器继承用户和设备的身份凭据，这一点比CONNECT机制更占优势。
对于gRPC和TLS流量，最终选择使用HTTP CONNECT请求进行封装。封装有个很明显的缺点，它会给传输带来性能损失（虽然可以忽略不计）。但封装有一个重要优势，它能够将设备标识和用户标识分离，在协议栈的不同层来实现。这种方案缘于基于清单库的访问控制是一个相对新的概念，虽然通常现有协议支持用户认证（例如，LOAS和SSH都支持），但要扩展到支持设备认证并不容易。
在封装CONNECT请求的TLS层执行设备认证，就不需要重写应用来识别设备证书。以SSH为例：客户端和服务器之间能够使用SSH证书来进行用户认证，但是SSH原本并不支持设备认证。此外，不能通过修改SSH证书来传递设备身份，因为SSH客户端证书默认是可移植的：一个SSH证书可以用在多个设备上。类似于HTTP的处理方式，CONNECT封装确保了用户认证和设备认证的良好分离。使用TLS客户端证书来认证设备的时候，也可以使用用户名和密码的方式来认证用户。
远程桌面
在Chrome代码库中公开可用的Chrome远程桌面[5]，是谷歌BeyondCorp主要使用的远程桌面解决方案。虽然HTTP的封装协议可以满足很多使用场景，但还有些专门用于远程桌面的协议，它们对通过AP后可能产生的额外延迟格外敏感，需要单独考虑。
为了确保请求得以授权，Chrome远程桌面在连接建立的交互流程中引入了基于HTTP的授权服务器。这个服务器位于Chromoting客户端和Chromoting主机之间充当第三方授权服务器，同时也帮助两个实体共享密钥，与Kerberos协议工作方式类似。
我们将授权服务器作为AP的一个简化的后端服务来实现，并为其配置特殊的ACL。这种实现效果还不错：通过AP带来的额外延迟仅在每个远程桌面会话发起时发生一次，并且也确保了访问代理能对每个会话创建请求都实施ACL。
第三方软件
第三方软件通常比较麻烦，因为它可能无法提供TLS证书，也可能其实现逻辑假设网络总是直连的。为了适配这些软件，我们设计了一种可以自动建立点到点加密隧道（使用TUN设备）的方案。软件对隧道无感知，就像是直连到服务器一样。理论上来看，隧道建立机制与远程桌面方案类似：
客户端运行辅助程序来建立隧道
服务端同样运行辅助程序作为AP的后端
AP执行访问控制策略并且协助会话信息和加密密钥在客户端和服务端的辅助程序之间交换
经验教训
ACL很复杂
推荐下面的最佳实践来减少ACL相关的困难：
确保语言的通用性。AP的ACL改变了无数次，而且还持续不断地增加新信息（如，用户和组）。因此需要定期更新可用功能，并且确保语言自身不会妨碍这些更新。
尽早启动ACL。原因有两个方面：
确保用户尽快了解ACL以及访问被拒绝的可能原因。
确保开发者尽快开始调整代码来满足AP的要求。例如，为了处理用户和设备认证，我们甚至重新开发了软件来替换cURL。
完善自助服务。正如前面提到的，单个服务配置团队无法支撑多个团队。
建立能将数据从AP传递给后端的机制。正如前面提到的，AP能够安全地将额外数据传递给后端，允许其能够进行细粒度的访问控制。尽早规划所需要的功能。
紧急情况
事先充分测试，充分准备，以应对意外紧急情况。尤其注意以下两类紧急事件：
产品类紧急事件：由于服务访问的逻辑链路上关键部件的中断或失灵造成的紧急事件。
安全类紧急事件：由于迫切需要授权/撤回特定用户和/或资源的访问造成的紧急事件。
产品类紧急事件
为了确保AP在大多数宕机期间还能存活,请根据SRE最佳实践进行设计和运维[3]。为了避免可能出现的数据源中断，需要定期对所有数据进行快照以便能本地访问。此外，还需要设计不依赖于AP本身的AP修复路径。
安全类紧急事件
安全紧急事件比产品紧急事件更为敏感，因为在设计时往往容易被忽略。在用户撤销/设备撤销/会话撤销时均需考虑到ACL推送频率和TLS问题。
用户撤销相对简单：作为撤销过程的一部分，已撤销的用户将自动添加到特殊组，通过一条靠前的ACL全局规则（请参阅上面的“ACL语言”）确保这些用户访问任何资源的权限都被禁止。会话令牌（例如，OAuth和OpenID Connect令牌）和证书有时候会泄露或丢失，同理也需要撤销。
正如第一篇BeyondCorp论文中所说[1]，除非收到设备清单管道的状态上报，否则设备标识不可信。这意味着即使丢失CA密钥（意味着不能撤销证书）也不会失控，因为直到被列入清单管道的目录中，新的证书才可信。
由于上述特性，我们决定彻底忽略证书撤销过程: 如果怀疑证书相应的私钥丢失或者泄露，不再发布证书撤销列表（certificate revocation list, CRL），而是降低证书的清单信任等级。清单本质上就是可信设备标识的白名单，并且不依赖于CRL。这种方法的主要缺点是它可能会带来额外延迟。不过通过在清单和访问代理服务器之间设计快速传播通道，可以相对容易地解决这种延迟。
为了保证执行策略的及时可达，需要一个ACL的标准快速推送机制。ACL超出一定规模后,必须要将部分ACL定义过程委托给服务所有者,这就会导致一些不可避免的错误。虽然单元测试和冒烟测试通常可以发现明显错误，但逻辑错误会通过安全措施渗透，并进入生产阶段。工程师必须具备快速回滚ACL变更的能力，才能恢复丢失的访问权限、锁定意外的访问权限。引用之前Chrome插件的0Day漏洞为例，快速推送ACL是应急响应团队的关键能力，通过快速推送自定义ACL可以强制用户进行更新。
工程师需要支持
迁移到BeyondCorp不可能一蹴而就，需要多个团队之间的协调和沟通。在大型企业中，将整个迁移任务委托给单个团队是不可能的。迁移很可能涉及一些不能向后兼容的变更，这需要得到管理层的强大支持。
迁移的成功很大程度上取决于团队在访问代理背后配置服务的难易程度。以减轻开发人员的开发负担为目标，要把异常情况的出现维持在最低限度。提供合理的默认设置，为常见用例撰写指南和文档。使用沙箱应对更高级和更复杂的变化，比如可以创建一个访问代理的单独实例，负载均衡器会忽略这个实例，但开发人员还可以访问（如临时覆盖其DNS配置）。沙箱在大部分情况都非常有用，比如在对x.509证书或底层TLS库进行重大变更之后，需要确保客户端TLS连接能成功进行。
展望未来
虽然BeyondCorp的前端实现在很大程度上是相当成功的，但仍然有一些问题尚未解决。首当其冲的，就是台式机和笔记本使用证书进行身份认证，而移动设备则使用设备标识。证书的轮换仍然很痛苦，因为出示一个新的证书需要重启浏览器才能确保现有的套接字已经关闭。
为了解决上述问题，计划将台式机和笔记本电脑同样采用移动设备的方式，以消除对证书的需求。构建一个桌面设备管理器来处理这种迁移，该桌面管理器看起来与移动设备管理器非常相似。它将提供一个通用的标识，以设备-用户-会话-ID（DUSI）的形式出现，DUSI会在所有浏览器和工具间共享，也许会使用一个通用OAuth令牌授予守护进程来实现。一旦迁移完成，不再需要通过证书验证台式机和笔记本电脑，并且在各类操作系统中的所有的控制都可以持续使用DUSI。
结论
作为BeyondCorp的核心组件，访问代理的部署实施考虑了谷歌特有基础设施架构和用例。访问代理的最终设计实践与常见网站可靠性工程（Site Reliability Engineering, SRE）最佳实践一致，并且已证明其具有较高的稳定性及伸缩性——在部署过程中，访问代理已经完成了几个量级的增长。
任何想要实现类似BeyondCorp安全模型的组织都可以采用类似访问代理设计和部署的解决方案。希望本文分享的谷歌如何解决多平台认证、特殊案例和例外等挑战的解决方案，以及在这个项目中所学到的经验，可以帮助其他组织能以最小的代价实现类似项目。
参考文献：
[1] R. Ward and B. Beyer, “BeyondCorp: A New Approach to Enterprise Security,” login:, vol. 39, no. 6 (December 2014):
[2] B. Osborn, J. McWilliams, B. Beyer, and M. Saltonstall, “BeyondCorp: Design to Deployment at Google,” login:, vol. 41,no. 1 (Spring 2016):
[3] B. Beyer, C. Jones, J. Petoff, and N. Murphy, eds., Site Reliability Engineering (O’Reilly Media, 2016).
[4] Apache JServer Protocol:
[5]
相关阅读