信息来源：FreeBuf

声明：截至2017年1月，文章符合Google现状。但Google可能会不断的改进升级安全策略导致实际情况有所出入。

小编导读：安全团队多数时候是独立于业务团队的存在，类似于主机agent、WAF、DDOS等安全产品，都是力求“独立”成产品的。而Google和大多数公司不同，他们的安全能力是内嵌在基础设施里，由基础设施透明提供的。安全工程师参与设计、开发和实现，并检验基础设施所提供的安全能力。业内曾说，安全的本质上是信任问题，你总得信任点什么。而Google用自己的做法告诉大家，它可以不信任到什么程度。

每个公司的基因都有所差异，不见得所有的做法我们都能学习，但是，知道世界上有这么一家公司，是这么实现的，一定对开拓视野和思路是有所帮助的。

笔者英文并不太优秀，但是这次也是一字一句的硬啃下来了，只因为相信，这是一篇值得精读多遍的真正好文。

CIO级摘要

Google拥有全球规模的技术基础设施，用于提供信息处理全生命周期的安全能力。包括：安全的发布、用户隐私保护、数据安全存储、服务之间（内部）的安全交互、互联网通信安全、运维安全 

Google自身的服务使用了这些基础架构，即包括像Google搜索引擎、Gmail和照片等2C（面向普通用户）的业务，也包括G Suite和Google Cloud等2B（面向企业）的业务 

这套基础设施提供从数据中心的物理安全开始，自底向上，逐层涵盖到硬件、软件、操作规范等方面 

Google投入大量的资源保护这些基础设施（包括大量的资金和几百名工程师，分布Google所有的产品和服务中），其中不少人是行业的权威专家 

小编导读：这一段其实主要是Google说自己如何厉害，如果你是第一遍看本文的话，可以跳过去，看完了再回过头来看看总结比较合适。

概述

本文简要介绍了Google基础设施是如何设计安全特性的。该基础设施的使命就是在Google整个信息处理生命周期中提供安全性，包括安全的发布服务、安全存储用户隐私数据、在Google多个服务之间安全的交互数据、保障用户和服务之间的互联网流量安全、安全的运维管理操作。

Google使用此基础设施构建自己的服务，包括搜索、Gmail、照片等（面向普通用户的）服务，也包括G Suite、Google Cloud Platform等（面向企业）的服务。

我们将从数据中心的物理安全开始，逐层介绍硬件和软件等底层设计是如何保障安全的，最后一直到技术规范和运维流程，如何保障运维操作等方面的安全。

底层基础设施安全

这一节，我们会详细的从基础设施的最底层开始介绍，从机房的物理安全，到安全定制加固过的硬件，再到底层的软件引导栈。

机房物理安全

Google自己设计数据中心，在数据中心里包含了多级的安全保护措施，并限制了只有非常少的Google员工才有权限访问。包括：生物识别、金属探测、监控摄像头、路障、激光检测。当Google跟第三方数据中心合作时， Google要求合作方在原有数据中心安全措施的基础上，必须额外增加完全由Google自主控制的生物识别、摄像头监控和金属探测等机制。

小编导读：

多数公司还没有自建数据中心的能力，即便能自己建设，也往往无法避免要跟第三方合作。此时，机房的安全管理水平可能参差不齐。如果机房管理员监守自盗（也可能是被钓鱼攻击、社工，甚至是商业间谍去应聘），走到机柜面前，插上显示器鼠标键盘，或者U盘，甚至拔走一块硬盘，想想就不寒而栗……Google显然不能接受这种情况的发生，所以，他们通过各种安全措施确保可以接触自己服务器的人是可信的。

硬件安全

每个Google的数据中心都是由数千台接入到本地网络的服务器组成的。所有的服务器主板、网络设备都由Google自行设计。Google谨慎的选择每一个组件的供应商，精心挑选组件，并且和供应商一起审计、确认该组件所提供的安全属性是符合要求的。Google还自行设计芯片，包括一个硬件的安全芯片，该芯片被部署在服务器以及外围设备上，用于在硬件层面识别合法的Google自有设备。

小编导读：坊间传言，某大型企业被国家级对手盯上的时候，他们采购的设备在物流过程中被掉包了，于是进驻机房后，变成对手的跳板，进入内网。Google从硬件开始不信任，服务器、路由器、交换机统统自己设计，有自己的加密芯片才是合法的设备。不合法的设备可能直接被踢出网络。而多数企业还苦苦挣扎在自有资产都盘点不清楚，网络准入仅仅在办公环境的交换机上才会开启NAC。大名鼎鼎的Hacking Team被入侵好像就是从一个嵌入式设备开始的。Google显然对此又有所防范了。

引导栈安全加固与机器身份识别

Google服务器使用多种技术来确保运行的软件引导栈是合法受信的。我们使用加密签名的方式，对底层组件，诸如BIOS、bootloader、内核、操作系统镜像进行签名。这些签名在每一次启动、更新的时候会被校验。而每一个上述组件都是完全由Google控制的（Google自行构建、加固），每一代硬件都会提升和加强安全能力。例如，在不同年代的服务器设计中，Google通过一个可以被锁定的固件芯片（firmware）、微处理器或者上述提到的安全芯片，来确保引导链的信任根是安全的。（均由Google自行编码或者设计实现）

数据中心里的每一台服务器都有它独特定制的身份标识（与硬件信任根绑定）。这个标识在底层的服务管理API调用中，会被用作源和目标的鉴权依据。

Google还实现了全自动化的系统，确保每一个服务器上运行的软件栈（包括安全补丁）都能升级到最新、检测硬件和软件的故障、或者在必要的情况下将其从踢出网络。

小编导读：传说中的Bootkit、Rootkit ，不知道是不是破坏了完整性之后就不能运行呢？其实，因为Google所有的发布基本上都是通过Borg平台（一个非常厉害的集群管理服务）。在集中管理的情况下，如果自动加上签名和认证机制，那么理论上服务器是可以白名单运行所有的任务的。黑客getshell之后，下载和安装一个木马，不知道跑不跑的起来哦……

服务发布安全

这一节，我们从硬件和软件的基本安全，过渡到描述“服务”是怎么样安全发布的。本文的 “服务”指的是由开发者编写的，运行在我们的基础设施上的应用程序，例如：Gmail 的SMTP服务程序、BigTable存储服务程序、YouTube视频转码程序、或者一个用来运行用户程序的App Engine沙箱。它们可能会在数千台机器运行相同的的副本。这些服务都运行在一个叫做Borg的集群调度系统上（也是Google的基础设施之一）。

如上所述，基础设施并没有赋予服务和服务之间任何的信任。换句话说，我们的基础设施设计出来就是提供给多租户模式使用的。

小编导读：相比多数企业，内网很多API完全没有鉴权机制（顶多IP白名单隔离），一旦黑客拿到shell，这一台机器沦陷了不说，跟它在一个内网里的所有服务，面临的威胁才更大。而Google说，抱歉，所有内网API我都会在基础设施上帮你鉴权。

服务标识，完整性和隔离

Google内部的服务之间，仍然使用加密认证和授权机制来保障安全。在管理员和服务易于理解的前提下，提供了很强的访问控制能力。

尽管Google也的确在网络入口和出口过滤了一些内容，避免IP欺骗之类的攻击。但Google并没有把网络的隔离作为主要的安全手段，这样的思路让我们可以最大化的保障网络的性能和可靠性。

小编导读：在公司网络规模不大的时候，隔离的确是一个比较简单易行的思路。但网络规模大起来，内网的隔离和网络性能、可用性的矛盾就会激增。Google通过前面描述的RPC鉴权机制，不再依赖网络隔离，是一个非常值得学习的做法。

每一个运行服务都拥有一个服务标识。向其它服务发起RPC调用或者接收RPC返回信息的时候，需要提供基于这个标识的加密凭据。这些标识对于client端来说，可以确保和自己通信的远程服务端是可信的，对于server端而言，则可用来限制仅有受信的client才能发起请求，或者只能访问特定的方法。

Google的源代码都存储在一个中心仓库中，确保当前和历史版本的源代码均可被审计。基础设施可以要求代码必须经由特定的代码审核、签入、测试，才能被构建成二进制版本。代码审核必须由至少1名作者之外的其他工程师执行，并且需要系统的负责人同意，才能提交修改动作到代码里。这些要求，限制了内部员工或者外部黑客提交恶意代码的能力，并且也为源代码的追溯取证提供了必要信息。

小编导读：听闻Google的开发工程师入职之后，需要学习很久的编码规范。如果考取了公司内的Readability认证，那么发布的时候，可以挑选一位工程师，等他看完代码提交“look good to me”，就可以申请上线了。如果不幸还没考取到Readability认证，那么就需要别的小伙伴审核后，提交“Approve”才能继续流程。Approve是需要为代码开发者背书的，如果谁总写出有漏洞的代码，不知道是不是会比较难找到帮自己背书的小伙伴呢……

在同一台服务器上运行多个服务的时候，我们用了很多隔离和沙箱技术，来保护它们之间互不干扰。这些技术包括普通的Linux用户空间、语言和基于内核的沙箱以及硬件的虚拟化。一般而言，对于高风险的服务，我们会用更多层的隔离手段(比如转化用户提交的数据需要做复杂的格式转换的时候，或者在GAE（Google App Engine）、GCE（Google Compute Engine）中运行用户提交的代码时)。对于特别敏感的服务，例如集群管理、密钥管理服务，我们也会专机专用，作为额外的一层加固手段。

小编导读：虽然Google对自己的虚拟化、沙箱的隔离比较有信心，但是在高危App和核心敏感服务上，也是会乖乖的专机专用哦。纵深防御理念发挥到极致。

内部服务的访问控制管理

服务的负责人可以使用基础设施特别提供的访问控制管理功能，精确的限制哪些服务可以和自己的服务进行通信。例如，让特定的API只能被白名单范围的服务访问，只要配置白名单服务的标识，基础设施就会自动实现这些功能。

Google的工程师访问这些服务，也同样需要独立的身份标识，做类似的配置，基础设施就可以自动实现对特定的人允许或者拒绝访问的能力。所有这些身份标识（机器、服务、员工）都在一个全局的命名空间里，由基础设施进行维护。本文的后续部分会进一步解释，普通用户的凭据会有单独的处理方式。

小编导读：机器、服务、员工，都有自己的ID。通过这些ID组成一个一个的user group，然后一个group可以对另一个group进行特定的访问。这里的权限管理据说复杂到Google内部员工也会吐槽，但是它们带来的好处是显而易见的。

基础设施提供了丰富的工作流管理系统来支持这些身份标识的管理工作，包括审批链、日志、告警等功能。例如，通过本系统可以设置需要双人批准（均为群组管理员）后，方能让某些身份标识访问特定的群组。本系统可以为基础设施上数以千计规模的服务提供安全的访问控制能力。

为了自动化实现API级别的访问控制，基础设施还允许从数据库里读取ACL列表、群组信息，以便系统负责人在必要的情况下，灵活运用访问控制能力设计规则。

小编导读：相比之下，多数企业的内网操作根本无法关联到自然人，机器和服务顶多精确到IP，Google的这个设计简直是太精妙了。每一个身份请求内部服务（数据）的时候，都可以被唯一的追溯。

内部服务之间的加密通信

基础设施除了提供前面讨论的认证、授权能力之外，也在网络上提供了隐私加密能力和RPC数据的完整性保护能力。为了提供这些能力给到一些类似于HTTP之类的应用，我们会把它们封装在RPC内。从本质上来说，RPC这样的机制给了应用层天然的隔离防御能力，并抛弃了对网络信道的安全依赖。内部服务之间的通讯加密，可以在网络被中间人劫持，或者网络设备被攻陷的时候，仍然是安全的。

每一个RPC的加密级别是可配置的（例如，对低敏感、低价值的数据，可以选择在机房内部通讯的时候，仅仅做完整性的检查）。为了对抗高级别的攻击方（比如有能力在公网上监听Google流量和隐私的对手），基础设施在所有跨机房的网络流量上，强制加密通讯。这个特性无需任何配置。Google也开始部署硬件加速器，打算让数据中心内部的通信也默认加密。

小编导读：跨机房自动加密，机房内打算全加密，还在实施中。想想我们有多少公司全站HTTPS都没做到，更别说跨机房（内网专线）的加密了。且不说别的，MySQL、Redis、Memcache之类的内网通讯默认就是明文的啊。默默的想了一下成本，Google是不是在这方面出过什么事才会这么狠心呢……

用户数据的访问管理

典型的Google服务是为终端用户提供某种功能的。例如，一个终端用户可能在Gmail里保存邮件。终端用户在使用Gmail的时候，会跟其它服务产生交互（比如联系人服务），以便访问这个用户的地址簿。

如前所述，我们已经知道Contacts（联系人）服务，会被配置成仅仅接受Gmail（或者其它指定服务）的RPC请求了。

但是，这仍然是一个非常宽松的权限管理级别，在此状态下，Gmail服务可以随时请求任意用户的全部联系人数据。

所以，当Gmail发起RPC请求到Contacts（联系人），要求查询某个特定的终端用户的数据时，基础设施要求Gmail出示终端用户权限票据（end user permission ticket），作为RPC请求的一部分。该票据证明了Gmail正在为某个特定的终端用户提供服务，也确保了Contacts（联系人）服务只会为合法票据所代表的用户提供对应数据的安全能力。

基础设施利用票据（end user permission tickets）提供特定用户识别服务。一个终端用户的登录被专门的认证服务验证通过后，会得到一个认证凭据（例如Cookie、OAuth token），保存在客户端设备上。该设备发起的每一个子请求，都需要携带本凭据。

当一个服务收到用户的认证凭据时，它会转发给到专门的认证服务校验。校验通过会返回一个短时间内有效的“终端用户权限票据”，以便于RPC请求时携带。在上文提到的例子中，就是Gmail服务拿到了这个票据，可以发给Contacts服务。此刻起，该票据就可以被调用方携带在RPC请求里，并且被处理方使用了。

小编导读：这个理念，相当于所有的数据请求都必须经过一个集中的地方，而每一次请求都要携带合法票据，在验证票据的时候，可能就把大量潜在的越权漏洞给堵住了。而由于数据都只经过同一个地方，那么发现异常的窃取数据、或者封堵打击，也就变的容易。

数据存储安全

通过上面的讨论，我们已经描述了Google如何安全的发布服务。现在开始讨论我们如何在基础设施上实现数据存储的安全。

静态加密

Google的基础设施提供了多种存储服务，类似于BigTable和Spanner，以及特定的密钥管理服务。多数Google的应用不直接访问物理存储，而是通过存储服务替代。存储服务在实际写入物理硬盘之前，可以被配置为使用密钥（从特定的密钥管理服务中获取）完成加密数据。密钥管理服务支持自动轮换，提供精确的审计日志，并且与前面提到的权限票据关联到特定的用户。

实施应用层的加密可以让基础设施避免被潜在的底层存储攻击，比如说一个恶意的硬盘固件。也就是说，基础设施也实现了额外的保护层。我们在物理硬盘、SSD的整个生命周期都启用硬件加密。在一块硬盘被废弃或者更换前，它会被一个多步骤的流程进行清理（包括2条独立验证的方法并行）。没有通过这个擦除程序的磁盘会直接物理销毁（比如粉碎）。

小编导读：不写磁盘IO，调用远程存储服务接口。接口封装成RPC，天然拥有了加密、鉴权的能力，而一旦检测到数据写入完成，短期内没什么访问的动作，存储服务就自动开始给加密。看描述Google担心硬盘厂商写入一个恶意的木马到硬盘固件里，这下好了，都加密了，但更换硬盘的时候依然要安全擦鞋和物理损坏，Google到底都经历过一些什么？

数据删除

在Google，数据的删除通常是打上一个删除标记，表示该数据“即将被删除”，而不是真正的移除数据实体。这允许我们有机会从不小心的删除误操作中恢复数据，不管用户发起的还是由于bug导致的。当数据被标记为“即将被删除”后，这个数据会被按服务预先配置的策略进行处理。

当一个终端用户删除了他的帐号实体，基础设施会通知服务处理该请求，找出该帐号关联的相关数据进行移除。

小编导读：忽然想起那个GitLab的误操作案例……

Internet通信安全

介绍到这一节，我们已经描述了Google的服务在我们的基础设施上是如何被加固的。这一节我们会转过来描述，我们的服务在Internet上的通讯，是如何加固的。

正如此前所讨论的，基础设施连接了大量的物理设备，包括局域网和互联网，并且服务之间的通讯并不依赖网络本身的安全。但是，Google仍然把基础设施的IP地址配置内网，以便于跟互联网隔开。这样我们可以更容易的实现一些额外的防护，比如规避拒绝服务攻击的威胁。因为我们可以只暴露很少的一部分机器到外部的互联网上。

Google 前端服务

当一个服务希望把自己提供给Internet访问时，它得去基础设施的GFE（Google Front End）上进行注册。GFE确保所有的终端与自己的连接都正确的使用了TLS连接，用了正确的证书，并且遵循正确的安全策略。GFE还提供了拒绝服务防御能力（后文会讨论）。GFE收到互联网的请求后，通过前面介绍过的RPC安全协议转发到内部。

事实上，所有的内部服务要将自己发布到外网，都会使用GFE做为智能反向代理。GFE提供了公网域名的公网IP，拒绝服务防御能力，TLS连接。值得一提的是，GFE也是运行在基础设施上的，像其它服务一样，GFE可以处理海量规模的请求。

小编导读：不去代理上注册，都没法对外开服务，天然又解决了高危端口对外暴露的问题。别指望扫描Google的SSH端口然后破解密码了，有的Google工程师写了几年代码压根没登录过服务器，当然，他们的SSH服务也是经过代理中转的，而且是用证书认证的，证书时效性很短，颁发证书还需要双因子认证。

拒绝服务防御

从规模和体量上来说，Google比较容易化解拒绝服务攻击。我们有多层级联的拒绝服务防御手段，以缓解或者阻止拒绝服务对GFE后方的服务的风险。

在骨干网传递外部请求到数据中心时，它会经过多层硬件和软件的负载均衡。这些负载均衡设备会上报入流量的信息给基础设施上的DoS处理服务。当DoS处理服务检测到攻击时，它可以要求负载均衡设备丢弃或者限制与攻击相关的请求。

在下一层，GFE实例也会上报请求的信息给到DoS处理服务，包括一些负载均衡无法识别的应用层的信息。GFE同样可以接受DoS处理服务的指令丢弃与攻击相关的请求。

小编导读：一般的DDOS防御方案，是旁路一份流量，检测到有攻击了就把流量牵引过来。可Google这个描述是不需要，反正交换机路由器、服务都是自己写的，每一层都上报一些日志，帮助判断是否有攻击。而每一个设备也都可以接收指令清洗、丢弃、限制特定的请求。所以Google说自己的拒绝服务防御是多层次的，靠负载均衡就能扛很大的流量。人家代理也很多，打死1个代理节点，似乎对全局来说完全感知不到，攻击者也会知难而退吧。

用户认证

讨论完了拒绝服务防御，下一层防御来自我们的中央认证服务。这个服务对于终端用户而言，通常展现为登录页面。除了询问简单的用户名和密码，该服务也会智能的根据用户的其它信息（比如是否从一个已知的安全设备、历史相似登录地点），判断风险等级并对应的做出风险控制的挑战确认。通过鉴定后，认证服务会派发一个认证凭据（比如cookies、OAuth Token）以便后续的请求携带。

用户也可以在登录时选择类似于OTP或者防钓鱼的安全证书服务做二次验证。为了把这些安全能力提供给Google以外的公司，我们还跟FIDO（安全密码联盟）共同协定了U2F（通用二次认证）开放标准。现在这些设备也可以在市场上买到，并且主流的web站点也跟随我们实现了对U2F的支持。

运维安全

说到这里，我们已经描述了安全是如何被设计到基础设施里的，并且也介绍了一些类似于RPC请求的访问控制安全机制。

现在我们来介绍一下我们是如何安全的运营基础设施的：怎么安全的写出基础设施软件，怎么保护雇员的机器和认证凭据，以及如何从内部和外部对抗基础设施的威胁。

安全开发

除了中央源码控制和双人review机制，我们还为一些典型的安全漏洞提供了库和框架，开发者直接调用就可以自动规避这些典型漏洞。例如，我们提供了防止XSS漏洞的web库文件和框架。我们也提供了一些自动化的安全漏洞检测工具，包括fuzzer、静态代码扫描工具和Web漏洞扫描器。

针对不同的风险我们有不同的应对方式，作为终极大招，我们也使用人工审计来解决快速的风险分类，到深度的安全设计和实现上的安全问题。这些审查是由一个包含了Web安全、加密算法、运维安全等各方面的专家团组成的。人工安全检查出来的结果，往往被封装成新的安全库特性，或者设计新的fuzzer，以便在未来用于其它产品。

除此之外，我们还运营了一个漏洞奖励计划，为任何发现我们的基础设施或者应用程序的漏洞报告者提供现金奖励。我们已经在此计划里支付了数百万美金。

Google也投入大量的努力来寻找我们所使用的开源软件的0day漏洞。例如，OpenSSL的心脏滴血漏洞是由Google发现并报告的，同时Google也是CVE漏洞最多的提交者，也是为Linux KVM 提交最多安全bug补丁的厂商。

小编导读：简单总结就是，咱用封装好的库，框架，写了代码就是健壮，还有各种自动化的fuzzer、代码白盒审计、web黑盒审计工具，实在不行我还有人肉，人肉完了又自动化实现检查。要这都给漏了我就现金收漏洞，已经花了好几百万美金了，想想Project Zero这种团队，就感觉挖个Google的漏洞实在是不容易。而这个过程，似乎正是SDL的完美实践啊。终于知道为什么Google可以为一个XSS漏洞开出那么高的价钱了。

保护雇员设备和认证凭据的安全

为了保护员工设备和凭据免受入侵、窃取和其它非法内部活动，Google在这方面投入了大量资金，这也是Google确保自身基础设施安全运行的重要组成部分。

一直以来，针对Google员工的高端复杂钓鱼攻击总是持续不断，为了对抗这种攻击，Google强制员工帐号OTP口令认证方式更换成了支持 U2F 的安全密钥（OTP毕竟还是存在被钓鱼攻击的风险的）。

Google投入大量的资金来监控用于操作基础设施的客户端设备。确保操作系统更新到了安全的补丁包，限制允许安装的软件。我们还扫描办公设备中，员工安装的app程序、下载的文件，浏览器的扩展和所浏览的web页面内容。

Google并不使用信任局域网某个网段的方式来授予访问权限。取而代之的是，Google用应用级别的访问管理控制手段，来把内部的应用开放给合适的用户，并且仅允许他们从合法受控的设备，和安全可信的网络（和物理位置）。（更详细的描述可以阅读BeyondCorp相关的文章）

小编导读：Google说自己的员工长期遭受到高级钓鱼的威胁，肯定所言非虚，稍微上点年纪的安全从业人员应该还记得一个著名的IE漏洞。另外，听说Google会监控开发机的键盘输入，如果你不小心在facebook、linkedin上输入了内部的工作密码，马上就会收到一封邮件要求改密码。

内部风险控制

我们严格限制并严密监控那些被赋予了基础设施管理员权限的Google员工。持续的评估一些特殊任务所需要的最小权限，鼓励自动化的安全可控的方式来完成工作。这些手段包括双人审批机制、在debug时使用受限的（脱敏的）API接口。

Google雇员访问终端用户的信息会被基础设施底层的Hook记录日志，安全团队据此监控异常数据，并对可疑的问题展开调查。

小编导读：能自动化的就不给你开手工查询的权限。实在要debug，还得把数据脱敏。历史上，某些厂商调试的时候把敏感信息写在log里，被黑客下载走了，当时还觉得debug这种场景很难杜绝，然而Google说，我们可以脱敏的情况下debug啊。

入侵检测

Google拥有成熟的数据处理管道，可以很好的集成每一台设备的主机、网络、服务的检测日志。内置在这些管道上的安全策略会及时的向运维安全人员发出告警。Google的应急响应团队实施365天24小时的全天候待命。同时，Google内部也经常实施红蓝军对抗，以不断的衡量和提高检测能力。

小编导读：这个基本上等于没说，但是由于Google有这么丰富的底层API提供log，所以可以做的入侵策略应该非常厉害。真实的红蓝对抗看来的确是入侵检测的标配。不知道是不是该同情一下在Google内部扮演蓝军的团队，都这么严密，怎么玩呢？

Google云平台安全

在这一节，我们重点介绍我们的公共云基础设施，GCP，是如何从底层基础设施继承安全能力的。以GCE（Google Compute Engine）为例，我们详细介绍基础设施为它赋予了哪些安全能力。

GCE允许用户在Google的基础设施上运行自己的虚拟机。它是由多个逻辑组件组成的，尤其是管理所用的控制面板和虚拟机本身。

其中，管理控制面板会暴露一些外部API接口并对虚拟机创建迁移等进行任务管理。由于它运行在一些基础设施上，所以它自然继承了基础设施的底层安全能力：比如安全的引导栈。不同的服务会运行在不同的服务帐号下，所以每一个服务都只会被赋予它发起RPC请求时必须的最小化的权限。正如此前介绍过的，这些服务都存储在一个中央的Google源码仓库，它们是可审计的，并且二进制是被安全的发布的。

GCE控制面板是通过GFE对外提供API的，所以它又集成了GFE的DDOS防御特性，以及天然继承了SSL/TLS的加密特性。用户可以选择Google云负载均衡服务的选项来缓解多种拒绝服务攻击。

用户在登录GCE控制面板的时候，是通过Google的认证服务校验的（提供类似于劫持检测的安全能力），授权服务则由中央的IAM服务实施。

控制面板的流量，包括GFE转发给其后的服务，和跨机房之间的所有流量，都由基础设施自动实施认证和加密。除此之外，也可以配置控制面板的一些特定流量在机房内部也必须加密。

每一个虚拟主机实例，都会有一个与之关联的虚拟主机的管理服务同时运行。基础设施会给这2个服务独立的ID。一个ID是给VMM服务实例自身调用，另一个用来代表VM的身份。这使得我们可以区分那些请求是从可信的VMM来的。

GCE的将数据持久化写入的磁盘会自动调用一个基础设施的中央密钥管理系统，在空闲时自动加密。这些密钥是自动轮换的，并且支持对密钥访问记录进行审计。

如今，用户可以选择是否把流量从他们的虚拟主机发送到互联网上其它的虚拟主机，或者通过加密的方式传送这些流量。我们已经开始推出广域网之间的VM流量自动加密的机制。如前所述，基础设施在所有广域网之间的流量传输都已经是加密过的了。未来，我们也计划通过硬件加密加速器，把所有在局域网之间的流量也进行加密，这一点之前也提过了。

给VM提供隔离能力是在硬件层面的虚拟化技术实施的，主要使用了开源的KVM。我们未来会自己给KVM做一些定制化加固的实现，包括将一些控制代码和硬件模拟代码移动到内核之外的低权限进程中。我们也已经使用包括fuzzing、静态代码扫描和人工代码审计等方式仔细的对KVM的核心代码进行了检测。之前提到了，现在Google是KVM提交漏洞最多的厂商。

最后，我们的运维安全控制是确保上述数据遵从安全策略的重要组成部分。做为Google Cloud Platform的一部分，GCE使用的用户数据同样遵从相同的安全策略，Google不会访问和使用用户的数据，除非必须为用户提供某种支持。

小编导读：这个例子，把前面讲过的内容都串起来了。Google想强调的是，只要跑在它的基础设施上，就自动继承了很多安全性。而KVM这种开源的东西，Google还投入大量的精力去挖掘漏洞并报告给厂商。所以，Google明显是在暗示只有自己的云服务才是安全的……

总结

我们已经介绍了Google基础设施是怎么样被设计成安全的构建、发布和运维服务的。包括为用户提供的服务（例如Gmail），也包括为企业提供的服务。除此之外，我们的Google云也是在同样的基础设施之上完成的。

我们投入重金加固这些基础设施。Google拥有数百名专注于安全和隐私的工程师，遍布在所有Google产品里，包括一些专业领域里的权威都在其列。

正如我们看到的，基础设施的安全性是从物理组件和数据中心开始，到硬件原型，到加固的安全启动引导链，到内网服务交互加固，到静态数据加密，内网服务之间的安全管理和终端用户访问时的安全管理，以及对于人和技术的流程管理。

小编导读：Google反复的强调，是想说黑客试图攻击的每一个角落，都有对应的安全加固和应对。并且这些应对的办法是固化在基础设施平台里，可以服务于全球规模级别的数据中心和每一个服务的。很多公司的管理会有长尾，那么Google有没有呢？可能也会有，但是据说YouTube收购后，花了几年时间才融入，此前一直跟Google的服务完全隔离。

小编后记

Google关键思路总结：

1. 开发安全：Code Review、双人审批、Fuzzer/静态代码扫描/安全框架&库/Web扫描器/人工代码审计
2. 人员安全：U2F取代OTP，监控办公设备（打补丁、限制装软件、监控行为）
3. 风控流程：Debug时脱敏、自动化代替人工、最小化权限、底层Log的风控体系
4. 入侵检测：红蓝军对抗、24*365响应
5. 前端代理：GFE统一支持TLS，须注册才能对Internet提供服务，可转发内部RPC鉴权
6. 拒绝服务：GFE、负载均衡等设备上报信息并接收丢弃、限制等清洗指令
7. 静态加密：存储服务替代硬盘，底层全盘加密，更换硬盘时安全擦除（双重保险），物理销毁
8. 安全删除：标记后删除（策略可配置）
9. 认证：U2F（不仅自己用还推广给行业里）
10. 登录保护：根据风控策略判断是否需要应答挑战
11. 用户数据：必须携带票据
12. 内部服务交互：默认用RPC鉴权（ID的信任来自于硬件芯片），加密传输
13. 安全引导链：硬件开始的不信任，信任根来自定制的硬件芯片，BIOS、Bootloader、Kernel、OS层层签名
14. 定制硬件：服务器、交换机、路由器统统自己设计
15. 物理安全：不到1%的Google员工必须通过多重检查才能进入机房，合作机房也需要Google自行掌控

可能为了鼓励更多人去用自家的云服务，Google祭出了安全大旗，连续发了好几篇paper。看完之后，第一时间感觉到它对于甲方安全团队价值巨大，于是赶紧逐字翻译并梳理了一些值得借鉴的地方。如果大家英文水平好的话，强烈推荐阅读原文和参考链接。我们需要学习的地方还很多。理解的不对的地方也请大家指正。

感谢被我骚扰的几位Google同学。另外，我们团队长期招人，欢迎大家推荐或者自荐。一起打造一流的安全能力。