首页 > 安全 > 网络安全 >

Google架构安全白皮书

2017-02-20

Google架构安全白皮书。本文讲述了Google的技术架构中是怎样处理安全问题的。 这个全局设计是为了在Google整个信息处理的生命周期中保证信息安全。 其中包含服务的安全部署,数据的安全存储(包括用户隐私的保护),服务之间的安全通信,面向互联网用户的安全和私密通信。

Google架构安全白皮书。本文讲述了Google的技术架构中是怎样处理安全问题的。 这个全局设计是为了在Google整个信息处理的生命周期中保证信息安全。 其中包含服务的安全部署,数据的安全存储(包括用户隐私的保护),服务之间的安全通信,面向互联网用户的安全和私密通信,以及管理员的操作安全等等。Google内部使用这个架构来搭建其互联网服务,包括面向用户的服务(搜索,Gmail,相册服务)以及企业服务(G套件、Google云平台等)。本文会逐层讲解,从数据中心的物理安全开始,到架构软件和硬件的安全方案,以及在操作层面如何通过技术约束和流程管理来保证整个体系的安全。

\

安全的底层架构

这一章讲述Google怎样保证最底层架构的安全,包括机房的物理环境、为数据中心特制的硬件,以及每台服务器上运行的软件栈。

物理环境的安全

Google设计并建造自己的数据中心,其中包括了多层次的物理安防措施。这些数据中心只向极少数Google员工开放,并且部署了多种安防技术:生物信息识别、金属探测仪、摄像头、车辆拦截装置以及基于激光的入侵检测系统等。Google也会在一些第三方机房部署服务器,在这些地方,我们会在机房提供商的安全保障之上部署由Google控制的安全措施。比如,在这些地点我们会有独立的生物信息识别系统、摄像头和金属探测仪。

硬件设计和选址

Google的数据中心容纳数以千计的服务器,连在一个局域网络上。服务器的主板和网络设备都是Google自行研发设计的。我们会审查零件提供商的资质,小心挑选配件,同时和提供商合作来审查验证所有配件的安全属性。我们也设计芯片,其中包括一款硬件安全芯片,当前安装在Google所有的服务器和外设上,这些芯片可以在硬件层安全地鉴别、认证合法的Google设备。

安全的启动软件和机器识别

Google使用各种技术保证服务器启动正确的软件栈。我们在底层组件(包括BIOS/bootloader/内核/操作系统镜像)中使用了加密签名。这些签名在每一次启动或者更新的时候都会验证。所有这些组件都是Google控制、研发和优化过的。对于每一代新的硬件,我们都会持续加强安全。比如,在各代服务器设计中对于启动软件的信任,分别位于固件芯片、运行安全代码的微控制器,或上面提到的安全芯片中。

数据中心每台服务器都有自己的认证码,由它可以联系到硬件的信任源(root of trust),以及系统启动的软件。这个认证码可以用于服务器上低层的控制服务API调用的授权。

Google研发了更新服务器软件栈版本的自动化系统(包含安全补丁),还可以发现和诊断软硬件的问题,并且在必要的时候让某台机器停止服务。

安全的服务部署

基础硬件和软件讲完以后,现在我们继续讲怎样保障我们的架构中一个服务的部署是安全的。我们说的服务是指一个程序员写好的二进制的程序,需要运行在我们的服务器上。比如一个Gmail的SMTP服务,一个Bigtable的存储服务,或者一个Youtube的转码服务,甚至一个运行用户应用的AppEngine的沙盒。可能有上千台机器运行这个服务的多个拷贝,以扩展负载。这些服务由我们架构内一个集群编排服务Borg负责控制。

这一部分我们会看到,我们的架构不会假设服务之间存在任何信任关系。换句话说,这个架构从根本上的设计就是多租户的。

服务识别、完整性和隔离性

Google在应用层的服务间通信使用加密算法来识别和授权。在管理员和服务本身易于理解的抽象层面和粒度上,这保证了较强的访问控制。

Google不用内部网络分割或者防火墙作为主要的安全措施,但是我们的确在某些节点使用进出网络的包过滤,来防止伪造IP等网络威胁。这也帮助我们最大化网络的性能和可用性。

每一个运行在这个架构中的服务都有一个服务账号的认证身份。每个服务都有加密的凭证来在发起或者接受RPC调用的时候证明自己的身份。这些凭证可以保证客户端在和正确的服务器通信。

Google的所有代码都存储于一个核心代码库中,所有当前以及过去版本服务的代码都是可审计的。Google架构可以通过配置实现以下需求:一个服务的二进制代码必须由经过特定审核、提交和测试的源代码编译而来。这种代码审核需要至少一名除作者以外的工程师检查并批准,系统要求任何代码更改必须获得那个系统的负责人批准。这些要求限制了内部人员或者竞争对手恶意更改代码的能力,也方便从服务到代码回溯其更改路径。

我们有一系列的隔离和沙盒技术来保护一个服务免受同一主机上其他服务的影响。包括常用的Linux用户隔离,基于语言和内核的沙盒措施,以及硬件虚拟化等等。一般来说,任务的风险级别越高,我们就会使用越多层隔离措施,比如,当对用户数据做复杂文件格式转换的时候,或者运行用户提供的代码(比如Google AppEngine或者Google ComputeEngine)的时候。作为额外的安全边界,我们把一些比较敏感的服务(比如集群编排服务以及一些重要的管理服务)只部署在特定的机器上。

服务间访问控制

一个服务的作者可以使用架构所提供的访问管理功能来指定哪些服务可以与它通信。比如,一个服务的某些API可以只向特定白名单内的服务开放。这个服务可以配置好授权白名单的服务ID,而架构会保证这个访问限制的实施。

Google工程师在访问服务的时候也会被分配个人身份ID,所以服务也可以同样地允许或者拒绝他们的访问。所有这些ID(机器、服务、员工),都在一个架构所维护的全局命名空间中。下面将要讲到,终端用户的身份是独立维护的。

架构提供了一个丰富的身份管理工作流系统,功能包括批准链、日志以及提醒等等。比如,这些身份可以分配到不同的权限管理组中,这个组中的一个工程师可以提交一个更改,而另一个工程师(组管理员)需要批准这个更改。这个系统有很好的扩展性,负责架构中运行的上千个服务的访问管理流程。

除了自动的API级别的访问控制机制以外,架构也向服务提供了从中心ACL/组数据库读取的能力,以便服务在需要的时候可以实现自定制的细粒度的访问控制。

服务间通信的加密

除了前面提到的RPC认证授权能力以外,架构也提供加密功能保护RPC网络传输数据的隐秘性和一致性。为了把这些益处提供给其他应用层的协议(比如HTTP),我们把它们封装在内部RPC机制中。实际上,这种做法让应用层摆脱了对于网络路径安全的依赖。即使网络被监听,或者网络设备被攻破,加密的服务间通信仍然可以保证安全。

服务可以对每个RPC独立配置加密保护的级别。比如,对于价值较低的数据,只配置完整性级别的保护。为了防范比较复杂的攻击,比如在我们私有的WAN网络上监听,架构自动加密了在数据中心之间WAN上传送的所有RPC流量,而不需要每个服务对此做出明确的配置。我们也开始部署硬件加解密加速器,这可以让我们把默认的加密措施扩展到架构中所有数据中心的RPC流量。

终端用户的访问管理

Google服务大部分是为终端用户提供某种功能的。比如,用户在Gmail上存储邮件。用户和Gmail这样的应用的交互会涉及架构内的其他服务。比如,Gmail服务可能会调用Contacts服务的API来获取用户的通信录。

我们在上个部分看到,Contacts服务可以配置成只允许Gmail服务访问它的RPC接口(也可以包括其他Contacts服务愿意接受的服务请求)。但是,这个权限控制仍然是非常宽泛的。在这个控制范围里面,Gmail服务可以随时访问任何用户的通信录数据。

因为Gmail服务是代表某个终端用户调用Contacts服务的RPC,架构提供了一个功能,允许Gmail服务在调用RPC的时候附加一个“终端用户ticket”,这个ticket证明Gmail服务当前正在代表一个特定用户发出请求。这让Contacts服务可以保证只返回终端用户需要的数据。

架构中提供了一个中心用户身份认证服务,负责发放终端用户ticket。用户登录时,由这个中心服务认证并向用户的服务发放一个用户的身份证明,比如一个cookie或者OAuth令牌。接下来,从用户发出的每一个Google请求都会包含这个身份证明。

一个服务收到用户的身份证明以后,它会把证明传给中心认证服务完成认证。如果认证成功,中心服务会返回一个短时间有效的用户ticket,用于这个请求相关的RPC调用。在我们的例子中,Gmail服务获得了用户ticket,而它会把ticket传给Contacts服务。从此以后,任何下层的调用都会传递用户ticket,作为RPC调用的一个必要组成部分。

\

安全的数据存储

讨论到这里,我们已经讲述了怎样安全地部署服务。现在我们开始讨论如何实现安全的数据存储。

静态数据的加密

Google的架构提供了一系列的存储服务,比如BigTable和Spanner等等,以及一个中心的密钥管理服务。Google的大部分应用通过这些存储服务来间接访问物理存储。这些存储服务可以通过密钥管理服务获取密钥,在把数据写入物理设备之前加密数据。密钥服务支持自动的密钥更替,也提供了详细的审计日志,并且和前面提到的终端用户ticket整合,把密钥和特定的用户联系起来。

在应用层实现加密可以让架构隔离底层存储的潜在威胁(比如带有恶意代码的硬盘固件)。除此以外,架构也实现了更多层次的保护措施:我们打开了硬盘和SSD的硬件加密支持,小心追踪每块硬盘的生命周期,在一个加密的硬盘正式退出使用离开机房之前,我们会启动一个多步流程清理盘上的数据,包括两个独立的验证步骤。如果一块硬盘没办法通过这个清理步骤,它们会在现场被物理毁灭。

数据删除

Google删除数据的过程往往开始于将特定数据标记为“待删除”。而不是直接删除所有数据。这可以让我们有机会恢复误删的数据,无论删除是用户发起的、还是bug或者流程上的错误引起的。在把数据标记为“待删除”以后,数据的删除会根据服务相关的删除策略决定。当用户删除了整个账户以后,架构通知处理用户数据的服务-这个账户已经删除,各个服务会制定计划把被删用户的相关数据删除掉。

安全的Internet通信

在此之前,我们讲述了如何保证架构内部的服务安全。这一部分我们开始讲讲我们如何保证Internet和我们的服务之间的通信安全。

前面讲到,架构包含很多物理机,它们通过LAN和WAN互相连接,他们之间的通信安全不依赖网络的安全性。但是,我们的确会把架构内部和Internet隔离,使用一个私有的IP地址空间,以便我们能更加容易地实现更多的保护措施,比如只在Internet上只暴露一部分机器来防御DoS攻击。

Google前端服务

当一个服务需要向Internet开放的时候,它可以向一个架构服务(Google前端服务GFE)注册自身。GFE保证所有的TLS连接使用正确的证书在这一层终结,并遵循了各种最佳实践。GFE还会应用各种针对DoS攻击的保护措施(下文详述)。GFE然后把请求转发到相应的服务上,使用的是前面提到的RPC安全协议。

每个内部服务如果要对外发布,都会使用GFE作为前端的智能反向代理。这个前端为服务的域名提供了公网IP、DoS保护以及TLS的终结等功能。注意GFE在架构中的运行机制和其他服务一样,因此可以轻松扩展,以匹配请求的流量大小。

Dos保护机制

Google架构的规模让它可以轻易地吸收大部分DoS攻击。即便如此,我们也部署多层次的DoS保护措施,进一步减少了DoS攻击给GFE后端的服务带来的的风险。

在主干网把一个外部连接发送到我们的数据中心的时候,它经过多层硬件和软件的负载均衡。这些负载均衡器把外部流量的信息发送到架构内部一个中心DoS服务。如果中心DoS服务发现了一个DoS袭击正在发生,它可以配置负载均衡器针对攻击流量启动流量丢弃或者控制(throttle)。

在下个层次,GFE实例也会向中心DoS服务报告收到请求的信息,主要是负载均衡器无法获知的应用层信息。中心DoS服务就可以配置GFE节点启动流量丢弃或者控制。

用户认证

DoS保护的下一层防御来自于我们的中心身份认证服务。这个服务对外部用户的呈现就是Google登陆页。除了要求用户名和密码以外,这个服务也会基于风险评估,智能地要求用户提供其他信息。比如是否从同一设备登陆,或者是否在同一个地理位置登录。用户认证完成以后,认证服务发放用户身份相关的cookie或者OAuth令牌,用于接下来的调用。

用户也可以使用2FA认证,比如OTP或者防钓鱼的安全密钥来登陆。为了保证这些好处可以扩展到Google的服务以外,我们在FIDO联盟中和多个设备供应商制定了全球U2F开放标准。这些设备在市场上已经可以买到,其他主流的web应用也开始跟随我们实现U2F的支持。

运维安全

在此之前, 我们讲解了我们的架构的安全设计,也描述了一些安全操作的机制,比如RPC的访问权限控制。

现在我们讲讲如何安全地运维这个架构:架构软件的安全开发、保护员工电脑和身份证书的安全、以及如何抵御内部外部对于架构安全的威胁。

安全的软件开发

除了中心的代码控制,以及至少两个人审核代码的功能以外,我们也提供了一些代码库,他们可以防止开发人员引入某些类型的安全漏洞。比如,我们有一些库和框架可以消除web应用中的XSS漏洞。同时我们也开发了检查安全缺陷的自动化工具,包括模糊测试、静态代码分析以及web安全扫描器等工具。

作为最后一项,我们也会启动手工的安全审查,对于风险较低的功能,只需要快速的代码走查,而对于高风险的功能,我们会启动深入的设计和实现的审查。这些审查由一个团队负责,团队由web安全、密码学以及操作系统安全领域的专家组成。这个审查之后,安全库可能会增加新的功能,也可能产生新的模糊测试,这些都可以用于未来的产品中。

此外,我们也会运作一个安全漏洞奖励计划。任何人如果能发现我们架构或者应用中的bug并告知我们,都会得到奖励。我们已经在这个计划中发放了数百万美元的奖励。

Google也会投资大量的精力用于寻找0day安全漏洞,以及开源软件中其他的安全问题,并把解决方案回馈给开源社区。比如OpenSSL的心脏出血漏洞就是Google发现的,而且我们也是Linux KVM hypervisor最大的CVE提交者,也修复了最多的安全问题。

保证员工的设备和身份安全

我们对于保护员工设备和身份做了大量的投资,既避免它们免受攻击,也通过活动监控发现潜在的内部非法动作。这些关键投资用于保证架构的运维安全。

复杂的钓鱼威胁一直把我们的员工当做目标。为了防范这些威胁,我们替换了容易钓鱼的OTP 2FA设备,改用U2F兼容的安全密钥,用于员工的账户认证。

我们也大力投资,监控员工用于运维架构的客户设备。我们保证这些客户设备的操作系统镜像都是最新的,打好了最近的安全补丁,我们也控制可以安装的应用软件。此外,我们还有扫描用户安装程序、下载、浏览器插件以及web内容的系统,以保证客户设备的适用性。

我们不把公司的LAN当作访问控制的主要机制。我们采用应用级别的访问管理,这让我们可以把内部应用只向一些特定的用户开放,同时还要求他们使用被正确管理的设备,从特定的网络和特定的地理位置才可以访问。

减少内部威胁

我们对于拥有架构管理权限的员工,非常激进地限制和监控他的活动,并持续地缩减他的访问权限,用自动化的方法代替他特定的任务,以保证同样的任务可以用更加安全和受控的方式完成。

这些措施包含:要求至少两人批准一些动作、引入一些受限的API,可以在不暴露敏感信息的前提下完成调试。

Google员工对于最终用户的信息访问可以以日志的形式记录下来,这通过底层架构提供的钩子(hook)实现。Google的安全团队会持续监控访问的模式,调查异常事件。

入侵检测

Google拥有非常复杂的数据处理管线,它整合了基于主机的独立设备信号,来自架构内各个监控节点的基于网络的信号,以及架构服务的信号。在这些管线之上,运行着各种规则和AI,给运维安全工程师发出可能的事故警告。我们的事故调研和响应团队全年365天,每天24小时查看、研究并响应这些潜在事故。我们还会做RedTeam演习来提高检测和响应机制的有效性。

Google Cloud(GCP)的安全

在这一部分,我们会重点介绍我们的公共云平台GCP如何利用底层架构的安全措施。我们用GCE作为例子,详细描述一下在安全架构的基础之上特定服务的安全提升手段。GCE让用户可以在Google的架构内运行自己的虚拟机。GCE的实现包含了几个逻辑组件,其中主要是是管控平台和虚拟机平台。管控平台暴露了一些外部API接口,负责虚拟机创建和迁移等任务。这个平台在架构内部表现为各种服务,因此它自动获得了基础的安全功能,比如安全的启动链。每个服务都是在不同的内部服务账户下运行,因此每个服务都只被赋予了它RPC调用所需要的权限。

前面讲到,所有服务的代码都存储于Google的中心代码仓库,而且在代码和最终部署的二进制文件之间存在一个审计路径。

GCE的控制平台通过GFE服务暴露它的API,所以它利用到了架构的安全功能,比如DoS防护和集中管理的SSL支持。用户只要选择使用Google云负载均衡服务(构建于GFE之上),他运行于GCE虚拟机上的应用可以获得类似的保护,可以化解各种DoS攻击。GCE控制平台API的终端用户认证是用Google的中心身份认证服务提供的,包含了劫持检测等等安全功能。用户授权也是用中心的IAM服务完成的。

控制平台的网络流量,无论是GFE,还是在它后面的服务,抑或是服务之间的通信,只要跨不同的数据中心,都会被架构自动验证、加密。此外,架构的配置也允许在数据中心内部的控制平台流量被加密。

每一个虚拟机都有一个相关的虚拟机管理器服务。架构为这些服务提供两个身份,一个身份用于虚拟机服务实例自身的调用,另一个用于代表用户虚拟机发出调用。这让我们可以把VM发出的调用分成不同的信任机制。

GCE持久化的硬盘的静态数据会加密保护,采用的密钥来自于中心的密钥管理系统。这可以利用到自动化的密钥轮转以及对于密钥访问的中心审计等功能。

现在的用户可以选择VM之间的通信或者Internet上的通信是否采用明文传输,或者选择任何的加密方法。我们也针对WAN上VM之间的流量,逐步推出自动化的加密功能。前面提到过,所有架构内部控制层的WAN通信已经是加密的。未来我们计划前面提及的硬件加速网络加密来为数据中心内VM之间的LAN通信加密。

VM的隔离性是基于开源KVM栈的硬件虚拟化。我们对于KVM的实现又做了进一步加固,把一些控制和硬件模拟的层次移至一个内核之外较低权限的进程中。我们也对KVM核心的模块做了大量测试,包括模糊测试、金泰分析以及人工的代码Review。前面提过,KVM最近公开的漏洞修复大部分来自Google提交的代码。

最后,我们的运维安全控制对于保证数据的存取合规起到重要作用。作为GCP的一个部分,GCE在使用客户数据的时候必须遵循GCP的用户数据政策,也就是说,Google不会访问客户的任何数据,除非数据对用户提供服务绝对必要。

结语

我们讲了Google的架构设计怎样保证服务的构建、部署和运维都能在internet的规模上保证安全。这包括了面向客户的服务比如Gmail,也包括了企业服务。另外,我们的Google云服务都是构建于同一套基础架构之上的。

我们为了保证架构的安全做出了大量投资。有数百个工程师致力于Google架构的安全和隐私保护,其中不乏业界的知名人物。

我们看到架构的安全设计需要考虑各个层次,从物理层的配件、数据中心,到硬件验证,再到安全的软件启动,安全的服务间通信、安全的静态数据保护、Internet访问服务的控制,以及最后技术和人工运维流程的制定等等,缺一不可。

相关文章
最新文章
热点推荐