前言
随着企业大规模的采用移动互联网和云计算技术，传统的采用防火墙建立的“城堡”安全模式，变得越来越不安全。2014年12月起，Google先后发表6篇BeyondCorp相关论文，论文提供了一种新的安全模式，设备和用户只能获得经过验证的资源，构建软件定义安全的雏形。另外，论文也介绍了BeyondCorp的架构和实施情况，为传统网络架构迁移至BeyondCorp架构提供依据参考。
为推动国内安全技术和理论与国际同步，在国内传播国际优秀实践，中国云安全联盟秘书处组织专家翻译BeyondCorp相关论文，供大家学习参考。
本文档一共由BeyondCorp的六篇论文组合而成：
[1] BeyondCorp：一种新的企业安全方案
[2] 谷歌BeyondCorp：从设计到部署
[3] BeyondCorp：访问代理
[4] 迁移到BeyondCorp：提高安全性的同时保持生产力
[5] BeyondCorp ：用户体验
[6] BeyondCorp：构建健康机群
该系列论文将定期向大家推送，敬请关注“云安全联盟CSA”。
目录
【第五篇】BeyondCorp ：用户体验
BeyondCorp系列论文的前几篇讨论了在实践过程中我们如何解决各个方面的技术挑战[1-3]。在迁移过程中，除了技术因素，还要考虑人的因素：在整个迁移过程中，必须始终将用户牢记于心，为最终用户尽可能地提供无缝的体验。当出现问题时，我们希望用户知道如何解决，去哪里寻求帮助。本文将讨论谷歌员工在BeyondCorp模型中的工作体验，从新员工入职、新设备配置，到遇到问题时如何处理。
创造无缝的新员工体验
对于许多新员工来说，BeyondCorp模型这个概念是相当陌生的：他们习惯了通过VPN、公司专属WiFi、和其他特权环境来访问他们日常工作所需的资源。BeyondCorp上线之初，许多新员工继续向我们的IT服务台团队（内部称为技术站Techstop）请求VPN访问。用户过去习惯性地认为如果不在办公室的时候需要工作，就要经过复杂的IT设置，需要VPN。BeyondCorp架构师原本以为用户不在办公室，有远程访问需求时，会尝试直接访问内网资源，并发现可以成功访问。这样看上去非常完美：无需用户申请访问配置，无需技术站的支持负担，简直就是双赢。然而事与愿违，（远程访问需要申请VPN权限的）用户习惯根深蒂固。
●新员工入职培训
显然，在用户开始谷歌的IT之旅时，就应该让其尽早了解这种新的访问模式，因此我们在新员工入职培训时就开始介绍BeyondCorp。在培训中，我们有意避免去讲解模型的技术细节，而是关注最终的用户体验。我们强调用户不需要VPN，可以“自动”获得远程访问权限；用户无需改变他们的工作流就可以在办公室、家里、飞机上，或咖啡馆工作。通过培训，我们向用户展示了BeyondCorp的谷歌浏览器（Chrome）扩展程序，作为BeyondCorp访问模型中最常见的面向用户的方式（有关扩展的更多细节，请参见下面章节“BeyondCorp扩展”）；我们还展示了在BeyondCorp中代表连接“正确”的图标（参见图2）。只要有“正确”连接标识，用户就可以通过任何网络连接访问他们需要的绝大多数工具和资源。
●新设备安装配置
当用户初次使用公司账号密码登录其公司设备时，其访问设置将被自动配置。为了实现这种无缝的入职体验，清单进程和平台管理工具在后台工作，以配置新的租用设备并进行初始化。如“谷歌BeyondCorp：从设计到部署”[1]中所述，我们根据大量的数据来判定设备的信任等级，包括观察数据（最近安全扫描时间，补丁级别，安装软件等）和预设数据（分配的所有者，VLAN等）。为了解决这种判定的复杂性，我们的清单团队遵循自动配置流程，以确保首次登录时正确信任新租用设备。验证必要的用户账密后，我们会自动将自定义Chrome扩展程序推送到用户设备。从用户的角度看，只要能够看到扩展中的绿色图标，他们就可以访问企业资源。通过在新员工培训中讲解BeyondCorp的Chrome扩展，基本消除了新员工困惑，并且可以支持新员工的远程访问请求。
减少VPN使用
尽管新员工在培训中了解了BeyondCorp，但毕竟他们在入职谷歌的头几天中可是接受了大量的信息冲击，让每个人都能回忆起培训中的每个细节不太现实。于是我们修改了VPN申请流程和工具来强调在培训中讲解的BeyondCorp概念。
默认情况新员工没有访问VPN网关的权限，他们必须通过在线申请门户来申请VPN访问权限。在此门户上，我们明确提醒用户BeyondCorp是自动化配置的，他们在请求VPN访问之前应尝试直接访问他们需要的资源。
如图1中的流程图所示，如果用户跳过这个警告，我们还会对用户通过VPN隧道访问的服务进行自动分析。如果用户在过去45天内没有访问过任何一个BeyondCorp模式不支持的企业服务，我们就会向他们发送电子邮件，邮件中会解释，由于他们访问的所有公司资源都是通过BeyondCorp支持的，因此他们的VPN访问权限将在30天后到期，除非他们访问BeyondCorp不支持的服务。我们在VPN访问权限失效前7天会再发送一个通知，然后在第7天结束后取消用户对VPN网关的访问许可。这种自动化流程使我们主动剔除对传统访问基础架构的不必要使用，并最终完全拒用VPN基础设施。
图1：自动分析和取消员工的VPN使用
借用项目
实现BeyondCorp自动配置还带来了一个意外好处，为用户改进了其他方面的技术体验。其中一项最明显的改进是我们的借用笔记本电脑项目。像许多现代公司一样，我们员工的工作方式非常灵活，可以在办公桌、会议室、休息室或家中自由工作。移动设备（特别是笔记本电脑）对其生产力至关重要。为了处理忘带、遗失或被窃的情况，我们提供了一种自助式借用笔记本电脑程序，可以让用户尽快恢复正常工作。
使用遍布全球的自助式谷歌Chromebook笔记本电脑借用站，任何用户都可以将借用的笔记本电脑临时注册为自己的工作电脑，最长可达5天。从拿到笔记本到开启工作状态可能就几分钟时间，这样简单的流程让用户受益良多。借用设备开通足够简单，所需支持服务也随之减少，技术站的资源就可以释放出来处理其他问题。当用户归还设备或借用时间到期时，系统会自动撤销其证书，并降低其信任等级，为下一个用户重新借用做好准备。
BeyondCorp的Chrome浏览器扩展程序
通过或多或少地消除对VPN客户端的需求，我们可以通过Chrome扩展程序这个单一入口来封装几乎所有的访问需求——无论是远程访问还是本地访问。Chrome扩展程序会自动管理用户的代理自动配置（Proxy Auto-Config，PAC）文件，明确将一些特定访问场景路由到访问代理[2]。当用户连接到网络时，该扩展程序会自动下载最新的PAC文件并显示“正确”连接的绿色图标。浏览器根据PAC文件中的规则自动将企业服务的访问请求路由到访问代理。这使得内部开发人员可以不用明确配置客户端访问入口参数的情况下部署企业内部Web服务：客户端访问入口配置要求开发人员在公网DNS中配置CNAME指向访问代理，访问代理就会自动处理用户身份认证和授权。
由于BeyondCorp扩展程序将所有流量路由到访问代理，用户将无法访问那些访问代理不可达的设备。另外，扩展必须下载正确的PAC文件，以便准确路由业务流量。这种设置可能在某些场景下可能会出现问题，比如有强制验证门户的网络连接的场景，或用户需要访问本地网络上与设备而不希望通过访问代理进行路由。我们需要对用户解释这些问题并提供补救方法，最好不要增加技术站的支持负担。Chrome扩展程序的认证状态图标（如图2所示）提示了进一步排除故障的方法信息。
图2 Chrome扩展中表示身份认证状态的图标
当出现问题的时候
当出现故障或用户遇到复杂的边界情况时，会发生什么？通过假设用户会遇到的问题，确定常见场景，制定计划尽可能顺利地解决这些问题。让用户能够理解问题，并在可能的情况下自我修复，这是我们一贯的首要目标。
●可以自我修复的问题
强制验证门户
因为我们是一家拥有许多差旅员工的全球性公司，当他们在机场、酒店和咖啡馆办公时经常会遇到强制验证门户。这些门户网页通常在私有网络的默认网关上，当用户连接到这样的网络时，BeyondCorp Chrome扩展程序会尝试下载PAC文件，但是强制门户网页会阻拦PAC文件的下载。
要解决此问题，当扩展程序检测到网络状态变化时，我们都会确定设备是否位于强制门户之后：通过尝试访问，正常情况下应返回HTTP 204的空页面。如果我们收到HTTP 204以外的任何内容（最可能出现的是HTTP 302），就认为该设备需要先通过强制验证门户的认证。这种情况下，Chrome扩展程序会直接使用内置的预定义PAC文件，并警示用户。
当用户碰到强制验证门户的场景，可以点击Chrome扩展程序图标，我们会告知他们在连接机场或酒店的网络的时候碰到强制验证门户的这个问题很常见。BeyondCorp的工作不会受到影响，只需要将BeyondCorp的设置更改为“Off:Direct”即可，当用户完成强制门户验证后，浏览器扩展即可成功下载最新PAC文件。这个简单的流程允许用户在最短时间内完成自我修复，没有增加技术站的负担。
本地网络设备
用户还经常尝试访问私有网络中的设备，比如许多谷歌员工就会使用公司笔记本电脑来执行配置连接家庭打印机或其他网络设备等任务。但由于BeyondCorp配置通过访问代理来路由所有连接，所以启用BeyondCorp扩展后，连接就会失败。与强制验证门户的情况类似，解决方案是将BeyondCorp设置更改为“Off:Direct”。但不同的是，我们无法轻松检测到此故障状态。因为通常情况下，这种场景下的用户有一个激活的并且功能正常的互联网连接，因此从BeyondCorp扩展程序的角度来看，一切正常，用户可以通过BeyondCorp访问所有的企业资源，没有理由发出警报。
为了弄清楚在这种情况下如何有效地与用户交互，我们进行了一次典型的用户体验测试：工程师把公司笔记本电脑带回家，想用它来更改家里打印机的设置，两台设备通过IP地址连接。用户连接到家庭网络，BeyondCorp扩展成功连接，下载最新的PAC文件，并配置浏览器代理。当用户在新建的浏览器Tab标签页中输入打印机的IP地址时，对私有网络的访问流量一起重定向到了访问代理。网络请求失败，用户得到错误提示。
我们将解决问题的关键点放到最终的错误页面上，并提出了一个解决方案：通过访问代理展示错误页面。我们创建了一个自定义HTTP 502错误提示页面，以便在某些场景下将警示信息插入到错误页面中。具体来说，特别是针对用户试图访问RFC1918或RFC6598约定的地址时，我们返回的HTTP 502错误提示页面可以明确给出提示，用户就会知道如果他们在访问本地网络设备如家用路由器或打印机时（两个最常见情况），需要将BeyondCorp扩展修改为“Off:Direct”。通过这种方式，我们能够基于现有的基础设施和流程，让用户自行修复问题。
自定义代理设置
我们的海外员工有时需要配置一些自定义代理来测试广告。如果用户安装了多个扩展，每个扩展都试图配置代理，那么这些扩展就会相互冲突，这可能会使用户感到困惑，并影响他们访问企业资源。
我们用两种解决方案来处理这种情况。首先，我们将海外的代理配置直接集成到BeyondCorp扩展程序中。当用户有业务需求要从特定位置对外访问时，他们可以从支持国家的下拉菜单中选择该位置。这为用户提供了一个单独扩展来满足他们管理最常见的业务代理服务器的需求。
此外，当用户有合理需求运行额外的代理管理扩展时，他们的BeyondCorp图标将从绿色变为红色。然后我们给他们一个选项，将状态更改为Off：System Alternative并告知他们何时应该使用此设置。同样，这个过程允许用户进行自我修复，提高他们的工作效率并减少对我们支持团队的咨询的工作量。
复杂问题解决：门户
对于上述简单问题，可以通过自定义错误页面或Chrome扩展程序让用户可以快速地进行自我修复。然而对于一些看似正常的访问失败场景，用户和支持团队都会迫切需要知道被拒绝的原因。后端基础设施中的ACL逻辑复杂、层级多，无论对用户还是支持团队而言，想要理解这特定决策背后的逻辑都有困难。即使是一个经验丰富的SRE工程师，也可能需要花费很多时间查询许多内部服务，来找出一个403错误页面的原因。考虑到访问代理每天可能产生的403错误页面的数量级（仅HTTP/S就有约12M/天），人工参与故障排除是不可规模化的，也是不切实际的。
为了方便诊断和解决更复杂的BeyondCorp访问问题，我们设计了一个门户网站来帮助用户和支持团队。我们不只是用一串通用错误代码来告诉用户他们的访问被拒绝，而是解释他们被拒绝的原因以及如何解决这个问题。门户是独立的，而不是直接集成到访问代理服务器中，因为它使用的是更细粒度的ACL，取决于最终用户当前信任级别。由于访问代理默认是公开的，所以我们需要限制攻击者从403错误页面中获得的信息量。
●架构
门户大致分为前端和后端，两者之间采用API进行通信。
前端是一个交互式Web服务。它根据用户的输入内容向后端API发出请求。
后端可以查询参与访问决策的多个基础设施服务。这个过程会绕开各种缓存层，这样用户就可以接收到最新信息。
前端和后端之间的API也可以用于其他用途，比如批处理、分析，或者将输出能力嵌入到其他工具中。
●解释引擎
除了查询和表示ACL外，门户还需要有效地向用户展示这些信息。针对这些被拒请求的响应报文细节，我们构建了一个解释引擎（Explanation Engine）来进行错误诊断。它通过递归遍历负责提供授权决策的子系统来完成操作。
例如，访问代理的ACL可能要求设备完全可信才能访问一个特定的URL。在查询这个ACL后，解释引擎会和设备推断管道交互，并获取访问此资源的必要条件，然后将这个信息发送至前端，并翻译成通俗语言，用户就可以通过访问门户来找出他们当前状态存在何种问题以及如何解决这些问题。
●为ACL定义ACL
虽然解释引擎可以提供有效信息，但它可能会暴露敏感数据。它会暴露受保护系统存在问题的ACL，泄露用户账号和设备状态信息，而这些信息都会为潜在攻击者所用。为这些数据定义ACL非常棘手，因为我们需要在工具易用性和保护敏感信息之间实现平衡。
根据用户和设备请求故障诊断信息，我们可以使用不太具体的信息替换输出中的敏感信息。在极端的情况下，我们可以将敏感信息替换为联系技术站的提示信息。这样技术站和SRE工程师就可以通过验证用户的身份并以用户的名义查看相关信息，在帮助用户的同时不泄露敏感信息。
图3 当BeyondCorp阻止请求后展现的错误页面
●访问拒绝登录页
一旦门户开发完成，即可将门户集成到访问代理，向用户展示错误消息。当用户遇到HTTP 403错误时，他们可以一键返回到门户，查看所有相关错误细节（参见图3）。然后，门户会向后端重新发送访问请求，并解释导致问题的原因。
例如，如果一个资源要求特定群组成员才可访问，门户会提供群组名和到群组管理系统的超链接，这样用户就可以申请访问权限。门户在后台查询后端的访问控制列表服务来判断该资源的授权要求，与用户当前的归属组信息进行比较，门户前端将比较结果转换为通俗语言（参见图4）。这一切都发生在几秒钟之内，远远快于用户猜测什么是“组成员问题”或寻求帮助。
图4 面向员工的访问拒绝错误故障排除指引
将这个流程直接集成到我们的错误消息中，允许用户可以无缝地完成这个过程——并且完全通过自助服务。
●临时的故障排除
尽管我们期望大多数用户通过错误页面访问到门户，但是我们还提供了一个独立页面来支持更多临时的故障排除。前端门户的登录页面是根据用户身份和访问设备自定义的，它会显示用户及其名下设备的信息，并突出可能导致拒绝访问的问题。我们允许最终用户主动访问这个工具来了解其名下设备的全局视图和潜在访问问题，用户就能一步到位地解决他们任何设备上的问题。去外地出差或者演示之前，使用这个能力进行设备信任度自查非常方便。
●支持赋能
门户前端也使技术站能够快速地执行详细的故障诊断，提供立即可执行的方案，大大缩短了解决问题的时间。例如，为了解释一个403错误页面，技术人员就可以使用门户登录页面查询特定的用户名或设备标识，锁定到某个特定设备，确认它是否是一个完全可信的公司设备。如果不是，系统会给出设备不可信的具体原因，以及技术人员该如何解决这个问题（参见图5）。
图5 面向服务台的访问被拒绝错误故障排除指引
未来目标
除了当前的功能外，门户还提供了进一步实现自动化的可能。我们计划在将来持续检查潜在的拒绝访问问题，并会在这些问题真正出现前，告知用户如何自助解决问题的方法。同时，对于不能自我修复的重大问题，会启动自动通知到技术站采取补救措施。我们还希望扩大我们可以自动解决的问题范围，而无需人为干预。
聚焦经验
尽管BeyondCorp迁移在多个技术领域困难重重，但它也给予了我们足够的空间可以重新评估用户支持体验。通过关注迁移期间和迁移后的用户体验，我们可以使用户能够轻松地使用复杂的网络模型。专门设计的工具使出现在用户侧的组件变得清晰易用。这些支持界面的意义是为了允许用户尽可能地自我修复，从而节省用户时间，释放出支持团队的资源。当用户需要其他帮助时，我们提供有效工具和信息，使技术站发挥最优价值。
对于绝大多数用户来说，BeyondCorp是完全透明的。当谷歌员工担心他们自己的业务流程时，BeyondCorp模型负责处理全部的访问逻辑问题。当用户的确有问题时，我们会快速有效地介入，在合适的时间给他们提供正确的信息协助他们恢复正常。然后我们退回二线，让他们专注于他们最擅长的事情。
参考文献：
[1] B. Osborn, J. McWilliams, B. Beyer, and M. Saltonstall,“BeyondCorp: Design to Deployment at Google,” ;login:, vol.41, no. 1 (Spring 2016), pp. 28–35:
[2] L. Cittadini, B. Spear, B. Beyer, and M. Saltonstall,“BeyondCorp Part III: The Access Proxy,” ;login:, vol. 41,no. 4 (Winter 2016), pp. 28–33:
[3] J. Peck, B. Beyer, C. Beske, and M. Saltonstall, “Migratingto BeyondCorp: Maintaining Productivity While Improving Security,” ;login:, vol. 42, no. 2 (Summer 2017), pp. 49–55:
相关阅读