一. 背景介绍
Google在2014年之前就预测到互联网和内网的安全性是一样危险的，因为
* 一旦内网边界被突破的话，攻击者就很容易的访问企业的一些内部应用，由于安全意识的问题导致企业会认为我的内部很安全，我就对内部的应用进行低优先级别的处理，导致大量内部的安全问题存在。
* 现在的企业越来越多的应用移动和云技术，导致边界保护越来越难。所以Google干脆一视同仁，不分内外部，用一样的安全手段去防御。
二. 详细技术分析(2014年的规划)
Google在2014年写了一篇文章，专门介绍BeyondCorp安全模型的设计思路。
## 1. BeyondCorp的设计思路
BeyondCorp是由许多相配合的组件构成，以确保只能经过身份验证的设备，并且用户是被授权的情况下才能适当的访问所需要的企业应用程序。它的安全架构图如下:
下面详细介绍一下他们的组件:
1. 标识安全设备
设备清单数据库
BeyondCorp使用的是被管理的设备模式，也就是说设备会由企业获得并且主动管理。说白了就是只有管理设备才可以访问企业应用。一个设备的跟踪和获得存储在设备清单数据库中是这个模型的一个基石。设备必须有生命周期的管理，Google跟踪对所有设备所做的更改，信息会被监控、分析并且提供给BeyondCorp的其他组成部分。Google拥有多个设备库存的数据库，meta库存数据库主要是合并和规范设备信息，保持多个源是一致的，并且把这些信息提供给BeyondCorp的下游组件，拥有了这个Meta库存数据库的话，我们就知道搜有设备需要访问我们的企业的所有信息。
设备标识
所有被管理的设备必须在设备清单数据库中拥有唯一的标识。要做到唯一标识这一点的方法就是给每台设备使用特定的设备证书。要获得证书，设备必须同时存在并且在设备清单数据库中是正确的。证书存储在硬件或者软件的可信平台模块(TPM)或者证书存储区中。一个设备需要在证书存储区去验证有效性，只有一个设备被认为足够安全才可以归类为被管理的设备。证书定期更新检查会被强制执行。这个证书一旦安装了就会在企业中所有的服务中使用，作为合法通讯的依据。
2. 标识安全用户
用户和组数据库
BeyondCorp也在用户数据库和组数据库中跟踪和管理所有的用户。并且这个数据库和Google的人力资源流程进行紧密相互集成。如果用户进入公司后，改变角色和责任或者离开公司，数据库都会更新这些记录。BeyondCorp只允许用户访问所有合适的信息。
单点登录(SSO)
SSO系统是一个集中化的用户认证Portal，主要是验证用户请求访问企业资源的时候进行双因素(2FA)验证。同时这个用户在通过用户数据库和组数据库的验证后，SSO会产生一个短暂的令牌去授权访问特定的资源。
3. 网络可信
无特权网络部署
BeyondCorp定义和部署了一个非常类似一个非特权网络的外部网络，等同于本地和远程都可以访问。无特权网络只连接到Internet上，使用有限的基础设备服务(例DNS,DHCP和NTP)以及类似Puppet管理配置系统。所有客户端只允许访问这个指定的位于Google大楼的网络中。并且这个非特权网络和其他Google的网络有严格的网络的ACL限制。
802.1x来认证有线和无线的网络访问
有线和无线的接入，Google使用的是基于802.1x的Radius服务器来做认证，并且分配到合适的网络的。使用动态Vlan分配方式而不是静态分配。这种方法意味着，使用Radius服务器来开启VLAN分配的开关来验证设备，而不是依赖交换机/端口的静态配置。被管理的设备提供证书来作为802.1x捂手的一部分。而无法识别或者未被管理的设备被分配到一个补救和客户网络。
4. 外部化应用程序和工作流
面向Internet的访问代理服务器
所有Google企业暴露在外部和通过面向互联网访问代理服务器的内部客户端必须强制使用加密措施。另外可以在面向互联网的代理服务器上设置WAF来保证基础的应用类安全，来防御恶意公司。同时访问代理还应该具备全球可达性、负载均衡、访问控制检查、应用健康检查和拒绝服务类攻击。通过了代理服务器的访问控制检查后才可以把这个请求转发到后端。
公共DNS条目
所有的暴露在外部的Google企业应用程序使用的CNAME和公共DNS全部指向面向Internet的访问代理服务器。
5. 实现访问控制
可信的访问控制
可以访问Google企业应用的单个用户或者单个设备可能会随着时间而改变。通过查询多个数据库，Google可以推断出信任的级别分配和设备和用户。例如，未更新最新的OS补丁的设备会导致信任级别的下降。另外手机和平台或者端脑的具体型号也会被分配一个特定的信任级别。用户从一个新的设备来访问的时候回导致分配另外一个可信的级别。Google采用静态的规则和启发式来进行这些信任级别的确认。
访问控制引擎
在访问代理服务器作为每一个请求的基础需要提供服务级别的授权操作。访问控制引擎还可以基于位置的访问控制，访问控制引擎可以设置强制访问位置的策略。同时还可以设置访问Google的bug跟踪系统只允许使用工程师设备的全职工程师。访问财务的系统可以设置成是财务组的全职人员，并且这个人员是非工程师的设备。访问控制引擎还可以使用不同的方式来限制可以访问应用的限制。例如你只能访问Bug跟踪系统的条目或者对更新或者搜索做不太严格的访问控制。
访问控制流水线
访问控制引擎可以对客户端提取有用的信息。这些信息包括证书白名单，可信用户和设备的信任级别以及设备和用户的相关信息。
6. End-End例子
应用
对于这个例子来说，我们假设这个应用要采取BeyondCorp安全模式。仅限于管理设备中的全职和兼职的工程师去访问代码review.corp.google.com应用，只允许进行任何源代码、代码注释、代码更新、提交代码的权限。
配置面向Internet的代理服务器
codereview.corp.google.com的owner要为这个域名配置访问代理。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的owner提供两种特定的规则:
a) 被管理设备拥有最高的信任级别
b) 全职和键值工程师的最高信任级别
工程师访问网络
访问者的网络位于企业物理建筑之外：Google提供的笔记本员工可以从任何网络访问。例如机场的wifi网络、咖啡厅的WiFi都是允许的。这里没有要求进行建设VPN的连接到企业内部网络。
访问者的网络位于企业无力之内: Google提供笔记本或台式机访问企业网络。笔记本电脑提供设备证书作为802.1x的握手协议。由于提供了一个有效的证书，笔记本电脑会在无特权网络中配置一个地址。如果该设备不是公司发行的笔记本网络，或者它的证书已经过期，设备会被分配一个非常有限的访问控制权限的网络。
不分网络的访问应用
工程师访问codereview.corp.google.com要经过如下的步骤:
a) 请求被重定向到访问代理，笔记本电脑需要提供它的设备证书；
b) 访问代理无法识别用户，进而重定向到了SSO系统；
c) 工程师提供了2FA双因素的身份认证凭据，SSO通过验证过办法一个令牌，并重定向回访问代理；
d) 访问代理目前用户标识用户的设备证书，设备标识，SSO令牌等信息；
e) 在每次请求的时候检查访问review.corp.google.com的访问控制引擎的特权:
用户被确认为工程师组里面；
用户被确认用户足够的信任级别；
被管理的设备被表示为常见设备；
被管理的设备被确认为拥有足够权限级别的；
如果这些检查通过，请求会发送到合适的后端服务上；
如果检查失败，则拒绝这个请求。
7. 迁移到BeyondCorp
就像世界上其他普通的公司一样，Google为客户和应用程序保持了多年的特权网络。这种模式会产生大量的安全问题。所以Google决定讲所有的组件全部迁移到BeyondCorp。为每一个网络用户和每个应用程序迁移到BeyondCorp环境都不是一搓而就的，而是经过了令人置信的冒险的，并且还会有也许连续性的风险。下面介绍已经完成的工作:
工作流程确认
所有Google的应用全部迁移到访问代理上，所有的程序必须经过BeyondCorp的主动审查，从简单的方法例如支持HTTPS流量到复杂的SSO整合。每个应用程序都经过了如下的阶段:
从特权网络和外部VPN可以访问；
从特权网络和外部和非授权的网络通过access proxy访问。在这种情况下，我们需要拆分DNS,内部 DNS直接指向应用，外部访问指向访问代理；
通过外部、特权网络和非特权网络通过访问代理访问
工作职能分析
通过工作职能来进行工作流的确认，能够确认哪些用户优先迁移到组。因为Google选择了财务、销售、法务和工程师组作为试运行。
削弱VPN的访问
越来越多的应用程序变成经过访问代理来访问了，我们开始强制要求用户禁止使用VPN，我们采取了如下的技术措施:
先明确有哪些访问VPN的用户；
对于一个明确过了时间段限定外的用户进行监控，并且删除权限；
对于使用VPN的用户的监控，如果他们的工作流可以通过访问代理访问了，我们强烈建议用户放弃使用
的VPN访问权限
流量分析管道
我们要把用户迁移到无特权网络中并且所有的工作流在这个区域是可用的。需要进行确认是否准确，所以Google建立一个流量分析的管道。使用NetFlow采集每一个数据。Google可以分析出来哪些设备通过了访问控制列表，哪些没有通过访问控制列表。未通过的设备是否可以访问工作流。
非特权网络仿真模式
为了确认流量分析管道有效性，Google抽样了交换机的数据，并且通过安装在Google网络中所有用户的设备进行流量监控模拟了非特权网络的行为。
监控有两种模式:
记录模式: 捕获不合法的流量，但仍然允许流量离开该设备
强制模式: 捕获并丢弃不合格的流量
迁移策略
当流量分析和非特权仿真模拟执行之后，实施下面的分阶段迁移计划:
确认候选人的地址、工作流或者工作职能；
操作模拟器记录模式，识别用户并且在30天的时间确认有>99.9%的有符合条件流量进入；
激活仿真强制模式，确保所有的用户和设备符合>99.99%的符合条件的流量，如果有需要，用户可以恢
复到记录模式；
成功的执行30天后，开启设备记录入库操作；
开始对802.1x进行改造
异常处理
除了从特权网络到非特权网络尽可能的自动化对用户和设备进行迁移。Google也设计了一个简单的过程可以申请临时不用这个迁移。Google维护了对没有实施工作流的列表。用户可以通过这些工作流进行搜索、进行正确的审批、标识用户和设备作为工作流的活动用户。当工作流合格后，对用户进行迁移通告。
完成