国际大厂 Google 安全策略——【译】BeyondCorp 一种新的企业安全方法（BeyondCorp A New Approach to Enterprise Security） - 哈喽比特

1388次阅读 | 发布于4年以前

前文介绍

本文是对于 Google 相关安全策略的中文翻译，方便大家了解 Google 的相关安全策略。

如果大家有兴趣阅读原文，可以通过BeyondCorp A New Approach to Enterprise Security进行访问。

BeyondCorp 一种新的企业安全方法（正文内容）

实际上每一个公司现在都使用防火墙来强制保证网络边界安全。然而，这个安全模型是存在问题的，因为，当网络边界被攻破时，攻击者可以相对简单的访问公司的内网。当公司采用移动设备和云技术时，网络边界会变得越来越难以保证。Google 正在采用一个不同的方法来保证网络安全。我们舍弃了内网的要求，而是把我们的企业应用搬到了互联网上。

从早前的IT基础设施开始，企业就开始使用网络边界来保护和限制内部资源的访问。网络边界安全模型经常和中世纪城堡相比较：一座厚墙的城堡，被护城河包围，唯一的出入口有重兵把守。城外的任何东西都认为是危险的，而城内的任何东西都认为是安全可靠的。任何穿过吊桥进入城堡访问资源都得到了授权。

当一个企业的所有的员工只在公司办公时，网络边界安全模型能够很好的运转。然而，在移动员工队伍来临的情况下，被许多员工使用的设备的浪潮，和基于云服务的增长，另一种攻击方式已经出现，而且这种新的攻击方式正在想传统领域扩展。这个模型的管家假设已经不再成立：网络边界已经不仅仅局限于企业的物理位置，并且位于网络边界内的也不再是一个安全可靠的地方，可以用于托管个人电脑和企业应用。

然而，大多数的企业都假设内网是一个放置企业应用的安全的环境，Google 的经验已经证明，这个结论是错误的。所以，我们应该假设内部网络和外网一样充满危险，构建企业应用也应该基于这个假设。

Google BeyondCorp 方案是使用一个新的废除内部特殊办公网络的模型。取代特殊办公网络模型的是，只依赖设备和用户证书而不是用户网络位置——例如在公司网络、家中网络、在酒店活着在咖啡厅来进行访问控制。所有对企业资源的访问都是认证过的完全合法的，并且基于设备状态和用户证书加密过的。我们可以对不同的企业资源实施细粒度的访问控制。因此，所有 Google 的员工可以在任意网络下进行办公，并且不需要一个传统的 VPN 来连接到内部网络。除了一些潜在的差异，在本地和远端访问企业数据的用户体验实际上几乎完全相同。

BeyondCorp 的主要组件

BeyondCorp 是由许多合作的组件组成，保证只有合适的经过认证多设备和用户才可以通过认证访问到必要的企业应用。每一个组件都会在下面进行描述（见图片1）。

安全地识别设备

设备清单数据库

BeyondCorp 使用“受管理设备”的概念，用来表示由企业生产并且受到企业控制的设备。只有受管理设备才可以访问企业应用。围绕设备清单数据库的设备跟踪和采购流程是此模型的基石之一。当设备在有效的生命周期内时，Google 保证对设备变化的跟踪。信息会受到监控、分析，会在 BeyondCorp 的其他部分发挥价值。因为 Google 有许多的清单数据库，所以元数据库可以用来从多个来源合并和标准化设备信息，并且让这些信息在 BeyondCorp 的下游组件中发挥价值。在这里有了这些元数据，我们就有了需要访问我们企业的所有设备信息了。

设备识别

所有的设备都需要通过某种特定的方式来进行特定标记，并且将标记记录到设备清单数据库。有一种特定的来完成标记的方式就是使用设备证书来区分每一个设备。为了收到证书，设备必须在当前正确的存储在设备清单数据库中。这个证书是存储到名字叫做TPM（授信平台模块）的硬件或软件，或者一个合理的证书存储中。设备认证过程会认证设备证书存储的有效性，只有通过认证的设备我们才认为是一个受管理设备。由于证书会定期更新，所以这些检查也是强制的。一旦安装过后，这个证书会使用在与企业服务的所有通信中。虽然证书可以唯一地识别设备，单它不是单向访问权限。它是作为一个关于这个设备信息的一个密钥。

安全定义用户

用户和组织数据库

BeyondCorp 也使用用户数据库和组织数据库来追踪和管理所有的用户。这个数据库系统已经与 Google 的包含所有用户的工作分类、用户名与组成员身份等 HR 流程深度整合。当员工加入公司时，就会改变角色和责任，当离开公司时，这些数据库也会更新。这些系统告诉 BeyondCorp 关于需要访问企业的用户所有的合理信息。

单点登录系统

对于外部来说，单点登录系统是一个集中用户认证的入口，在用户请求访问企业资源时，用于认证主要和第二因子证书。在使用用户数据库和组织数据库验证用户后，单点登录系统会生成一个短生命周期的可以用来作为访问部分特定资源的认证凭证。

从网络中移除互信

基于无特权网络（Unprivileged Network）

为了让本地访问和远端访问保持一致，即使是在一个私有的地址空间里，BeyondCorp 也定义和依赖与外部网络非常相似的无特权网络。无特权网络只能连接到互联网、受限的基础服务（如 DNS、DHCP 和 NTP 等）和像 Puppet 一样的配置管理系统。所有的客户端设备在 Google 大楼中时，都会分配到此网络上。在这个网络和 Google 的其他部分网络之间，有一个严格的管理 ACL（访问管理清单）。

802.1x 有线和无线网络访问认证

不论是有线网络还是无线网络访问， Google 都是使用基于802.1x认证的 RADIUS 服务来分配设备到合适的网络上。我们使用动态而不是静态的 VLAN 分配策略。这个方法意味着，相比依赖静态的控制器/端口的配置方式，我们使用 RADUIS 服务来通知控制器给已经认证的设备分配合适的 VLAN。受管理的设备提供他们的设备证书作为 802.1x 握手的一部分，然后被分配到无特权网络中，如果是企业网络中的不识别的或者不受管理的设备，就把他们分配到修复网络或者访客网络中。

外部应用和工作流

面向网络的访问代理

在 Google 所有的企业应用都是通过在客户端和应用之间强制加密的面向网络的访问代理暴露给内部和外部的客户端。每个应用都配置了访问代理，并且有共同的特征如全球可达性、负载均衡、访问控制检查、应用健康检查和拒绝服务攻击保护。这个代理在经过了访问控制检查（描述见下文）后，把请求委托给了后端的合适的应用。

公共 DNS 入口

所有的 Google 企业应用都对外暴露，并且在公共的 DNS 中注册，CNAME 将应用程序指向面向网络的访问代理。

实施基于清单的控制

用户和设备授信

每个用户或者设备的访问级别是可以根据时间变化的。在访问多个数据源时，我们可以实现动态的推断每个用户或者设备的信任级别。这个信任级别可以在访问控制引擎（描述见下文）中作为它的决策过程中的一部分来使用。例如，一个设备没有更新最新的操作系统补丁，它可能就会导致被降低到一个更低的信任级别。一类特定的设备，例如特定的电话或者平板，可能就会有一个特定的信任级别。用户从新的地点访问应用可能会有一个不同的信任级别。我们同时使用静态规则和启发算法来确定信任的级别。

访问控制引擎

带有访问代理的访问控制引擎在请求企业应用之前提供了服务级别的基本认证。这个认证决策对用户、用户所属组、设备证书和来自设备清单数据库中的设备信息进行断言。如果需要的话，访问控制引擎也可以强制基于地理位置的访问控制。用户与设备的信任级别推断也包含认证决策。例如， Google bug 跟踪系统的访问权限可以限制为使用工程师设备的全职工程师。财务应用的访问权限可以限制为使用受管理的非工程师设备的在财务操作组的全职和兼职员工。访问控制引擎也可以通过不同的方式来限制同一个应用的不同部分。例如，查看 bug 跟踪系统的入口可能就比更新或者查找同一个 bug 跟踪系统需要更少的访问控制。

进入访问控制引擎的管道

访问控制引擎不断的从运行中的可以获取数据来帮助进行访问决策的管道中收集反馈。除了其他因素外，包含证书白名单的信息、用户和设备的信任级别和设备与用户的清单详情。

端到端示例

应用

在这个例子中，我们假设已经有一个应用被放入 BeyondCorp 中。这个应用被工程师用来审计代码、评论代码、更新代码和当审计者同意时，提交代码。这个应用 codereviw.corp.google.com 被限制为只有全职和兼职工程师使用任意受管理设备才可以访问。

配置面向网络的访问代理

codereview.corp.google.com 的拥有者为这个服务配置了访问代理。这个配置指定了后端的地址和每个后端最大的通信量。codereview.corp.google.com 这个域名已经在公共的 DNS 服务中进行了注册，它的 CNAME 指向了访问代理。例如：

$ dig @8.8.8.8 codereview.corp.google.com

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 codereview.corp.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12976
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;codereview.corp.google.com.  IN   A

;; ANSWER SECTION:
codereview.corp.google.com.  21599  IN CNAME
accessproxy.l.google.com.
accessproxy.l.google.com.    299   IN   A   74.125.136.129
;; Query time: 10 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Aug 20 19:30:06 2014
;; MSG SIZE rcvd: 86

配置访问控制引擎

访问控制引擎提供了默认的规则：限制只有全职工程师使用受管理设备可以访问。codereview.corp.google.com 的拥有者在两个方面提供了指定的更多的授权访问的规则：最高信任级别的受管理设备，和有着最高信任级别的全职以及兼职的工程师。

一个工程师访问网络

如果网络是位于企业管理的物理建筑的外面：通过一个 Google 提供的笔记本电脑，一个工程师访问任意的 WiFi 网络。例如，这个网络可能是使用便携设备或者咖啡厅的WiFi所组成的机场的 WiFi 网络。我们不需要打开一个 VPN 来连接到公司网络。

如果网络是位于企业管理的物理建筑的里面：通过一个 Google 提供的笔记本电脑或者桌面端，工程师访问企业网络。笔记本像 RADIUS 服务提供了它的设备证书用于 802.1x 的握手。只要提供了有效的证书，笔记本电脑就会被在无特权网路中分配一个地址。如果这个设备不是公司发行的电脑，或者说证书已经过期了，这个设备就会被分配一个有许多限制访问权限的修复网络的地址。

访问应用，不考虑网络

从一个公司发布的笔记本电脑上的网络，工程师可以访问 codereview.corp.google.com。你可以查图 1 来作为流程的参考。

请求直接到达访问代理。笔记本提供了它的设备证书。
访问大礼没有识别出用户，因此直接重定向到了 SSO 系统。
工程师提供了他的主要因子和第二因子身份认证因素，通过了 SSO 系统的认证，获得了一个凭证，从定向回到访问代理。
访问代理目前拥有识别设备的设备证书、识别用户的 SSO 的凭证。
访问控制引擎执行配置给 codereview.corp.google.com 的指定的认证检查。这个认证检查是关于每一个请求： a. 这个用户已经被工程师组确认。 b. 这个用户已经确认拥有足够的信任级别。 c. 这个设备已经确认过是一个有良好记录的受管理设备。 d. 这个设备已经确认拥有足够的信任级别。 e. 如果所有的检查都通过了，这个请求可以通过，并且可以访问到合适的后端服务。 f. 如果上述检查失败了，那么这个访问会被拒绝。

使用这种方法，我们可以对每个请求进行丰富的服务级别身份验证和授权检查。

向 BeyondCorp 迁移

就像世界上所有其他企业一样，Google 在很多年中都有一个为了它的客户端和应用的无特权网络。这种模式的产生对企业的日常工作至关重要。当所有的公司组件都将迁移到 BeyondCorp 时，一次性移动所有网络中的用户和所有应用到 BeyondCorp 环境对于业务连续性来说都是一个难以置信的风险。正是由于整个原因，Google 在分阶段迁移方面花费了大量的资源，才成功的将许多组中的网络用户零影响地迁移到 BeyondCorp 中。下面的部分，表示图2，详细说明了我们做的工作。

![图片2]()(https://)

工作流程资格

在 Google 中使用的所有应用都需要通过访问代理来工作。BeyondCorp 主动的检查和授权所有应用，让完成任务从复杂（例如 SSO 整合）变得简单（例如支持 HTTPS 通信）。每一个应用都需要一个访问代理的配置，并且，在许多情况下会在访问控制引擎中有特定的内容。每一个应用都经过了以下阶段：

可以从特权网络直接访问或者在外部通过一个 VPN 访问。
可以通过特权网络直接访问或者从外网和无特权网络通过一个访问代理进行访问。在这个场景下，我们使用分布式 DNS。内部名称服务器直接指向应用，而外部名称指向访问代理。
外网、特权和无特权网络都通过访问代理进行访问。

工作职能分析

通过检查整个公司的工作职能和根据工作流程资格来分析此信息，我们可以对迁移到用户组进行优先级排序。因此，我们可以选择在那个时间点上，对整个工作流以及对 BeyondCorp 的能力非常理解的来自财务、销售、法务或者工程师团队的网络用户。

减少 VPN 的使用

越来越多的引用可以通过访问代理进行访问是，我们开始积极地阻止使用 VPN 的用户，采用以下策略：

我们限制了 VPN 的访问，只有被证实的需求的用户才可以使用。
我们监控了 VPN 的使用情况，并且删除了特定时间端内没有使用过 VPN 的用户的使用权限。
我们监控了 VPN 的使用和活跃的 VPN 用户。如果所有的工作流都一块通过访问代理实现，我们积极地鼓励用户放弃VPN 访问权利。

流量分析管道

当我们确定（或者几乎确定）用户所有的工作流在无特权网络中可以正常使用时，我们把用户迁移到无特权网络就非常重要了。为了确定一个相对的程度，我们建立了一个流量分析管道。作为整个管道的输入，我们从公司的每一个开关的净流量进行数据取样。然后，根据非特权网络和公司其他网络之间的规范 ACL 来分析这些数据。这些分析能够让我们确定通过了 ACL 的总流量，和一个没有通过 ACL 的流量有序列表。没有通过 ACL 的流量可以关联到特定的工作流或者特定的用户或者特定的设备。然后，我们逐步浏览没有通过的列表，使其在 BeyondCorp 环境中运行。

无特权网络模拟器

为了增加从开关中使用抽象的流量分析管道，我们也在整个公司通过连接到 Google 网络的安装了流量监控的用户设备来模拟非特权网络中的行为。这个流量监控检测作为每一个设备的基础服务，检查所有输入和输出流量，根据 ACL 规范来验证非特权网络和公司其他网络的流量，记录没有通过验证的流量。这个监控有两种模式：

记录模式：捕获不合格的流量，但是仍然允许这部分流量离开设备。
强制模式：捕获和丢弃不合格的流量。

迁移策略

有了流量分析管道和非特权模拟器，我们根据以下内容确定和分阶段实施迁移策略：

通过工作职能或者工作流或者地理位置来定义潜在的候选集合。
在记录模式下操作模拟，定义用户和设备在持续的 30 天间有超过 99.9% 的合格流量。
激活模拟器的强制模式，定义用户和设备在持续的 30 天间有超过 99.9% 的合格流量。
在操作模拟器到强制模式成功 30 天后，将当前情况记录到设备清单中。
除了包含在候选集中之外，在模拟器的执行模式中成功操作30天提供了一个非常强烈的信号，即当 RADIUS 服务器为下一个 802.1x 认证请求提供服务时，应将设备分配给非特权网络。

异常处理

除了尽可能的将我们的用户和设备从特权网络自动迁移到非特权网络上以外，我们也在这次迁移中实现了一个简单的流程让用户可以暂时的不迁移。我们包含一个已知的没有完成 BeyondCorp 迁移的工作流清单。用户可以在正常的允许等级中使用这些工作流程，标记他们和他们的设备作为特定工作流的活跃用户。当这个工作流最终完成迁移时，这些用户就会收到通知，并且再次被选中需要进行迁移。

完成 BeyondCorp 迁移

Google 企业向 BeyondCorp 的迁移正在进行汇总，它需要的主要的工作流已经完成了。我们的迁移工具和战略允许我们再不影响日常的生产情况下，主动地迁移用户、设备和工作流到 BeyondCorp 中。

我们预计使用了很长一段时间的工作流需要花费一些实践才能迁移到 BeyondCorp 中。例如，使用特点协议与服务端进行交互的重客户端应用就会是一个挑战。我们调研了许多方式来让这些应用接入 BeyondCorp ，也许通过认证服务来进行匹配。

随着我们向 BeyondCorp 迁移，我们打算发布后续文章来解释为什么和 Google 如何迁移到 BeyondCorp 上，旨在鼓励其他的企业实施相似的策略。

总结

本文主要通过介绍了在 BeyondCorp 项目中各个组成部分和相关的作用，以及 Google 公司相关的迁移策略和方式，让我们大家对整个项目有了一个大概的了解。

论文后续还有几篇文章，更加详细的讲述了 BeyondCorp 相关的产品。我也会持续的进行更新，欢迎大家关注。

作者介绍与转载声明

黄珏，2015年毕业于华中科技大学，目前任职于美团基础研发平台大象业务部，独立负责大象 Web SDK 的开发与维护。

本文未经作者允许，禁止转载。