跳转至

BeyondCorp -以全新方式保障企业安全

翻译:lmowen

作者

Rory Ward是一名谷歌爱尔兰的站点可靠性工程经理。他曾经就职于Valista@爱尔兰,AOL@硅谷,Netscape,KIVA,General Magic,以及Retix@洛杉矶。他持有爱尔兰都柏林城市大学的计算机应用理学士学位。roryward@google.com

Betsy Beyer是一位纽约技术作家,专长于谷歌SRE软件的虚拟化方向。她曾负责为谷歌数据中心以及硬件操作团队提供文章。在搬到纽约之前,Betsy曾是斯坦福大学的技术写作讲师。她持有斯坦福大学和杜兰大学的学位。bbeyer@google.com

简介

目前,事实上每个公司都通过使用防火墙来实现边界安全管控。然而,这种安全模型是有问题的,因为当该边界被攻入后,攻击者会拥有对公司私有内部网络相对容易的访问权限。而随着公司采用移动和云技术,边界区域变得越来越难以实施。谷歌正在采取一种不同的方法来实现网络安全。我们正在移除私有内部网络的需求,并公司应用转向互联网。

企业从IT基础设施的早期就已经使用边界安全来保护和管控内部资源的访问。边界安全模型经常被比作一座中世纪城堡:一堵有厚墙的堡垒,四周有护城河,有严密的守卫,设有唯一的单点进出口。任何位于城墙之外的东西都被认为是危险的,而认为墙内任何东西都是可信的。任何人都经过了吊桥便具备使用城堡内所有资源的权利。

当所有的员工都在公司大楼里工作时,边界安全模型是很适用的。然而,随着移动办公的出现,和激增各种移动办公设备,以及越来越多地使用基于云的服务,新型攻击向量已经出现,将传统的范式扩展到再非单点。边界安全模型的关键假设不再成立:边界不再只代表企业的物理位置,而且边界内也不能继续被认为是个人计算机和企业应用存在的绝对安全场所。

当大多数企业认为内部网络是一个安全的环境时,谷歌的经验证明这种观念是错误的。相反,我们应该假设内部网络和公众一样充满危险,并基于这个假设构建所有企业应用。

Google的BeyondCorp方案目标正在转向一种新的模式,不再使用私有企业网络。相反,访问仅依赖于设备和用户证书,而不管用户的网络位置——无论是企业办公地、家庭网络还是酒店,或者咖啡店。对企业资源的所有访问都经过完全认证、完全授权,以及基于设备状态和用户证书进行完全加密。我们可以加强细粒度的访问控制,用以访问不同等级的企业资源。因此,所有谷歌员工都可以成功地在任何网络环境下工作,而不需要传统的VPN连接到所谓的私有网络中。企业本地访问与远程访问之间,除了可能的网络延迟不同之外,用户体验几乎一致。

BeyondCorp的主要构成

BeyondCorp由许多协作的组件构成,用以确保仅恰当授权过的设备和用户才允许访问所需的企业应用。下面描述每个组件(见图1)。

图1 BeyondCorp组件与访问流

安全地设备识别

设备资产数据库

BeyondCorp使用“受控设备”这样一个概念,指的是企业采购和主动管理的设备。只有受控设备才能访问公司应用程序。一套围绕着设备跟踪和采购的流程是该模型运转起设备库资产数据库是的基石。一个设备的整个生命周期中,谷歌持续跟踪对它进行的任何变更。该信息被监控、分析,并可用于BeyondCorp的其他部分。因为谷歌有多个资产数据库,元-资产数据库用于合并和规范来自这些多个源的设备信息,并使这些信息可用于BeyondCorp的下游组件。由于这个元-资产的存在,我们有能力知道所有那些需要访问我们的企业设备。

设备识别

所有受控设备都需要以唯一的方式识别并对应到设备资产数据库中的记录。一种实现此唯一标识的办法是每个设备都需要配备唯一标识的设备证书。要想得到证书,一个设备必须存在于设备资产数据库中,并且状态正常。证书存储于硬件或可信平台模块(TPM)软件上,或者其他合格的证书仓库。设备鉴权流程验证证书仓库的有效性,并且只有被认为足够安全的设备可以被归类为受控设备。这些检查也与证书更新一同定期更新而强制执行。一旦安装,证书用于企业服务的所有通信。证书用于唯一标识设备,但它不仅是单方面地授予访问权限;相反,它被用作关联设备的一组信息的密钥。

安全地用户识别

用户与组数据库

BeyondCorp还跟踪和管理用户与用户组数据库中的所有用户。这个数据库系统与Google的人力资源流程紧密的关联着,而Google的人力资源流程正是负责管理所有用户的工作分类、用户名和组成员资格。当员工加入公司,改变角色或责任,或离开公司,这个数据库被更新。该系统告知BeyondCorp关于需要接入我们企业用户的所有恰当/相关信息。

单点登录系统

一个外部化的单点登录(SSO)系统是集中式的用户身份验证门户,该门户为请求访问我们企业资源的用户验证主要和次要因素凭证。通过对用户和群组数据库进行验证后,SSO系统生成临时令牌,该令牌可以作为特定授权过程的一部分。

移除信任网络

部署无私有网络

为使本地和远程访问相同,BeyondCorp定义和部署一个无私有网络,非常类似外部网络但使用私有地址空间。无私有网络仅连接到因特网、有限的基础设施服务(例如,DNS、DHCP和NTP),以及 配置管理系统,如Puppet。所有设备都被被分配给这个网络中,即使其物理位置位于谷歌大厦内。在这个网络和谷歌的其他部分之间存在着一个严格管理的ACL(访问控制列表)。

有线/无线网络802.1x接入认证

对于有线和无线接入,Google都基于802.1x认证使用RADIUS服务器将设备分配至向适当的网络。我们使用动态的而非静态的VLAN分配。这种方法意味着,对于已验证的设备我们使用RADIUS服务器通知交换机适当的VLAN分配,而不是依赖于交换机/端口静态配置。受控设备提供证书作为802.1x握手协议的一部分,并被分配到无私有网络,而企业网络中未识别和非受控的设备的设备则被分配到后补网络或者访客网络中。

外部化应用程序和工作流

面向Internet的访问代理

谷歌的所有企业应用程序都同时面向外部和内部客户端,通过面向Internet的访问代理,强制执行客户端和应用程序之间的加密。访问代理为每个应用程序配置并提供公共的功能,比如全局可达性、负载均衡、访问控制检查、应用程序健康检查和拒绝服务保护。该代理在完成访问控制检查后(下方详述),将适当的请求代理发给后端应用程序。

公共DNS入口

谷歌所有的企业应用程序都对外可达,注册在公共DNS中,并伴有一个CNAME通过面向因特网的接入搭理指向该应用程序。

实施基于资产的访问控制

基于设备和用户的信任推理

对单个用户或者单个设备的访问级别可以随着时间的推移而改变。通过询问多个数据源,我们能够动态地推断配给设备或用户的信任级别。接下来访问控制引擎(下方详述)可以使用该信任级别作为其决策过程的一部分。例如,没有升级到最新操作系统补丁包的设备可能被降级信任级别。一类特定的设备,如特定型号的手机或平板电脑,可能被分配特定的信任级别。用户若从新的地理位置访问应用程序可能会被分配一个不同的信任级别。我们同时使用静态规则和启发式规则来确定这些信任级别。

访问控制引擎

访问代理中的访问控制引擎基于每个访问请求为企业级应用程序提供服务级别授权。授权决策对于用户、用户所属的组、设备证书,以及来自设备资产数据库中的记录做出断言。如果需要,访问控制引擎也可以执行基于位置的访问控制。对用户和设备推断的信任水平也包含在授权决策中。例如,谷歌的bug跟踪系统可以仅限于全职工程师使用工程设备才能访问。对财务应用的访问,可以限制仅金融操作组中的全职和兼职雇员使用受控的非工程设备访问。访问控制引擎也可以以不同的方式限制应用程序的各个功能部分。例如,在我们的bug跟踪系统中,与更新或搜索相同的bug跟踪系统比较,查看一个条目需要不那么严格的访问控制。

管道输入访问控制引擎

访问控制引擎不间断的从一个管道中获取信息,这个管道正是用来动态地提取用于做出访问决策的有用信息。该信息包括证书白名单、设备和用户的信任级别,以及关于设备和用户的资产细节以及其他各种因素。

端到端的例子

应用

对于这个例子,让我们假设一个应用程序将被BeyondCorp采用。工程师们使用的该应用程序进行审查源代码,注释代码,更新代码,以及经审稿人批准,提交代码。应用程序codereview.corp.google.com, 只限于全职和兼职的工程师使用任何受控设备可访问

配置面向Internet的访问代理

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的应用负责人提出了一个更加具体的规则,包括两种方式:对具有最高信任级别的受控设备,以及对具有最高信任级别的全职和兼职工程师。

工程师访问网络

如果网络处于企业办公地外的物理区域:工程师使用谷歌提供的笔记本电脑访问任何WiFi网络。例如,这个网络可能是机场的有限门户的WiFi网络,或者是咖啡店的WiFi。不需要设置VPN就能连接到企业网络。

如果网络位于企业办公地内的物理区域:一名工程师访问使用谷歌提供的笔记本或台式机访问企业网络。笔记本在802.1x握手协议中提供其设备证书给RADIUS服务器。由于提供了有效的证书,笔记本被在无私有网络中分配到一个地址。如果设备不是公司提供的笔记本,或者它的证书过期了,设备将被在补充网络中分配一个地址,仅具有非常有限的访问权限。

任意网络访问应用程序

一名工程师使用公司授予的笔记本电脑访问应用codereview.corp.google.com。其过程你可以参考图1中的流程。

  1. 请求被指向访问代理。笔记本提供其设备证书。
  2. 访问代理不能识别用户并重定向到SSO系统。
  3. 工程师提供他/她的双因素身份认证凭据,由SSO系统认证和颁发令牌,并被重定向回访问代理。
  4. 访问代理现在具有设备证书(标识设备)和SSO令牌(标识用户)。
  5. 访问控制引擎执行指定授权检查,该检查由应用codereview.corp.google.com所配置。

这个授权检查是在每一个请求上进行的:

a. 用户被确认属于工程组内成员
b. 用户被确认拥有足够的信任级别
c. 该设备被确认是状态正常的受控设备
d. 该设备被证实具有足够的信任级别。
e. 如果所有这些检查通过,则请求被传递到适当的后台完成服务。
f. 如果上述检查中的任何一项失败,则拒绝该请求。

通过这种方法,我们在基于每个请求基础上执行丰富的服务等级认证和授权检查

迁移至BeyondCorp

像世界上几乎所有其他企业一样,谷歌维护着一个客户端和应用程序之前的私有网络。这一范式对公司日常工作至关重要的基础设施来说,产生了显著的意义。而公司的所有组成部分都将迁移至BeyondCorp,一次性将所有网络用户和所有应用程序都迁移到BeyondCorp环境将会对业务连续性带来较大的风险。因为这个原因,谷歌投入了大量的成本来进行分阶段迁移,并且成功地实现了零生产力的影响将大部分网络用户组织转移到BeyondCorp。以下部分,如图2所示,详细说明我们所做的一些工作。

图 2 迁移至BeyondCorp

工作流验证

谷歌使用的所有应用程序都需要通过访问代理。BeyondCorp发起审查和检验这些应用程序,完成的任务范围覆盖从简单的(例如,支持HTTPS流量)到更困难的(例如,SSO集成)。每个应用程序都需要一套访问代理配置,并且在许多情况下,配置特定的访问控制引擎。每个应用程序都经过了以下阶段:

  1. 从私有网络直接访问和通过VPN外部访问。
  2. 从私有网络直接访问,以及外部和非私有网络访问代理通过访问代理访问。在这种情况下,我们使用分开的DNS。内网DNS直接指向应用程序和外部DNS指向访问代理。
  3. 所有外部、私有网络或非私有网络都通过访问代理访问

工作职能分析

通过梳理整个公司的工作职能,并参照工作流验证,我们能够排定用户群体进行迁移的优先级。那个时候我们能够基于对用户工作流和BeyondCorp能力的透彻理解而从财务、销售、法务或工程师团队中选择用户。

浅谈VPN的使用

随着越来越多的应用程序可以通过访问代理访问,我们开始主动限制用户使用VPN,具体采用以下策略:

  1. 我们限制了只有被证明实在有必要的用户才可使用VPN的访问。
  2. 我们监控了VPN的使用,并删除了未在定义的周期内使用VPN用户的访问权限。
  3. 我们监控VPN活跃用户的使用情况。如果他们所有的工作流程均可通过访问代理完成,我们强烈建议用户放弃他们的VPN访问权限。

流量分析管道

我们把用户转移到非私有网络时,仅当我们确定(或非常接近确定)他们所有的工作流程都可以从这个网络上获得时,这点很重要。为了建立相对的确定度,我们建立了流量分析管道。作为这个管道的输入,我们从公司的每个交换机捕获了采样的NetFlow数据。然后这部分数据被用于和对在非私有网络和公司网络的其余部分之间网络的标准ACL进行比对分析。这个分析使我们能够识别出通过ACL的总交通量,以及一个没能通过ACL的有序列表。然后,未通过流量可以附加到特定的工作流和/或特定的用户和/或特定的设备。我们接着逐步解决未通过的清单,使之在BeyondCorp环境中发挥作用。

非私有网络模拟

为了增加流量分析管道,该管道使用采样交换机的数据,我们也模拟了非私有网络行为监控器在公司的流量,通过安装在所有连接到谷歌网络的用户设备上的流量监视器。这个流量监视器基于每个设备针对非私有网络和公司的网络检查所有传入和传出流量,并记录了没有通过的流量。监控器有两种模式:

  1. 记录模式:捕获不合格的流量,但仍然允许说设备访问。
  2. 强制模式:捕获并丢弃不合格的流量

迁移策略

有了流量分析管道和非私有网络模拟,我们定义了已经分阶段执行了迁移策略,包括以下内容:

  1. 通过工作职能,工作流或位置信息识别潜在候选集
  2. 在记录模式下操作模拟器,识别出连续30天达到99.9%个合格流量设备的那些用户
  3. 为连续30天达到99.9%个合格流量设备的那些用户开启强制模式。如有必要,用户可以将模拟器恢复到记录模式。
  4. 在将模拟器在强制模式下成功运行30天后,将该情况记录进设备资产库中。
  5. 除了在候选集合中包含之外,在模拟器的强制模式下30天的成功操作提供了一个非常强烈的信号,当下一个802.1x认证请求由RADIUS服务器服务时,设备应该被分配给非私用网络。

例外处置

除了自动化将用户和设备进行网络迁移之外,我们也尽可能地为用户提供了一个简单暂时免除此迁移的例外申请流程。我们维护了一张在BeyondCorp环境中尚未合格的工作流程的列表。用户可以搜索这些列表,并以合理的审批后,标明自己和自己的设备作为某个工作流的合法存在。当该工作流最终合格时,其用户被通知进行迁移。

完成BeyondCorp

谷歌企业向BeyondCorp的迁移正在进行中,它所需要的大部分工作已经完成。我们的迁移工具和策略允许我们主动地将用户、设备和工作流移到BeyondCorp,而且并不影响到日常生产力。

我们预期到工作流长尾效应该还需要一些时间来完全实现向BeyondCorp的迁移。例如,使用专有协议来与服务器通讯的胖客户端应用程序就将是一个挑战。