近日，Google发布了基础设施安全设计概述的文章，解释了如何在云中保护其自身的安全，以及公有云服务。
该安全设计思路包涵了六层安全，并透露了一些有趣的事情，比如曝光了“Google在设计定制芯片，包括目前部署在服务器上的硬件和周边设备上的安全芯片，这些芯片可在硬件层面安全地识别和验证合法的Google设备。
▲
同时，Google服务器使用各种技术来确保它们正在引导正确的软件堆栈。在低级组件(如BIOS，引导加载程序，内核和基本操作系统映像)上使用加密签名。这些签名可以在每次引导或更新期间验证。这些组件全部由Google控制，构建和强化。随着新一代硬件的发展，Google努力不断地提高安全性：例如，根据服务器设计的需要，将引导链的信任归功于锁定固件芯片，运行Google编写的安全代码的微控制器，或者上面提到的Google设计的安全芯片。
此外还透露了，Google在第三方数据中心中托管服务器时，所采用的安全措施。确保在数据中心运营商提供的安全层之上有由Google控制的物理安全措施。例如，在这些地点，我们可以操作独立的生物识别系统，照相机和金属探测器。
文中还提及，Google的应用程序在将数据写入磁盘之前如何加密数据，以使如恶意磁盘固件更难以访问数据。
也就是说，基础设施还实现了额外的保护层。在硬盘驱动器和SSD中启用硬件加密支持，并仔细跟踪每个驱动器的生命周期。在停用的加密存储设备可以物理地离开之前，它使用包括两个独立验证的多步骤过程来清洁。没有通过该擦拭程序的设备在内部用物理方法破坏(例如粉碎)。
此外，Google还具有用于扫描用户安装的应用程序、下载、浏览器插件和从Web浏览的内容以便在公司客户端上适用的系统。
如在公司LAN上不是我们授予访问权限的主要机制。相反，我们使用应用程序级访问管理控制，允许我们只在特定用户来自正确管理的设备和预期的网络和地理位置时公开内部应用程序。
Google使用的自动和手动代码审查技术来检测开发人员编写的软件中的错误。手动审核“由包括网络安全，密码学和操作系统安全专家的团队进行。同时，Google运行一个漏洞奖励计划，向任何能够发现并通知Google基础设施或应用程序中的错误的人员付给报酬，Google已经在这个计划中支付了几百万美元的奖金。
Google的源代码存储在中央存储库中，其中服务的当前版本和过去版本都是可审计的。此外，可以将基础设施配置为要求从特定的审查，检入和测试的源代码构建服务的二进制文件。此类代码审查需要至少一个除作者以外的工程师的检查和批准，并且系统强制该代码对任何系统的修改必须由该系统的所有者批准。这些要求限制内部人或对手对源代码进行恶意修改的能力，并且还提供从服务返回其源的取证跟踪。
文中还指出，Google的公有云在KVM虚拟机管理程序的自定义版本中运行虚拟机，它称“我们是最大的CVE和针对Linux KVM虚拟机管理程序的安全漏洞修复程序最大的提交者”。
上一页12下一页查看全文
内容导航
第1页：Google曝光其服务器都含自定义安全芯片
第2页：Google基础设施安全设计概述
《Google基础设施安全设计概述》的译文，已经在由作者@网路冷眼在看雪论坛上全文发布，全文如下：
本文档概述了Google的技术基础设施安全性是如何设计的。这种全球性的基础设施旨在通过Google的全信息处理生命周期提供安全性。此基础架构提供服务的安全部署，使用终端用户隐私保护的安全数据存储，服务之间的安全通信，通过互联网与客户的安全和私人通信以及管理员的安全操作。
Google使用此基础架构构建其互联网服务，包括搜索，Gmail和照片等消费者服务以及G Suite和Google Cloud Platform等企业服务。
我们将从我们的数据中心的物理安全开始，继续到如何保证基础设施的硬件和软件安全，最后描述技术限制和流程以支持运营安全。
▲Google基础设施安全层：从底层的硬件基础架构到顶层的操作安全性的各种安全层。每一层的内容在本文中详细描述。
安全低级基础设施
在本节中，我们将介绍如何保护基础架构的最低层，从物理场所到数据中心的特定硬件，以及在每台机器上运行的低级软件堆栈。
物理设施的安全
Google设计和构建自己的数据中心，其中包含多层物理安全保护。对这些数据中心的访问仅限于Google员工中的很小一部分。我们使用多个物理安全层来保护我们的数据中心地板，并使用生物识别、金属检测、摄像机、车辆障碍和基于激光的入侵检测系统等技术。 Google还在第三方数据中心内部托管了一些服务器，我们确保在数据中心运营商提供的安全层之上有由Google控制的物理安全措施。例如，在这些地点，我们可以操作独立的生物识别系统、照相机和金属探测器。
硬件设计与原型
Google数据中心由连接到局域网的数千台服务器计算机组成。服务器母板和网络设备均由Google自行设计。我们审查与我们合作的组件供应商，谨慎选择组件，同时与供应商合作，审计和验证组件提供的安全属性。我们还设计定制芯片，包括目前部署在服务器和外设上的硬件安全芯片。这些芯片可让我们在硬件层面安全地识别和验证合法的Google设备。
安全引导堆栈和机器身份
Google服务器机器使用各种技术来确保它们正在引导正确的软件堆栈。我们在低级组件(如BIOS，引导加载程序，内核和基本操作系统映像)上使用加密签名。这些签名可以在每次引导或更新期间验证。这些组件全部由Google控制、构建和强化。随着每一代新硬件的发展，我们努力不断地提高安全性：例如，根据服务器设计的生成，我们将引导链的信任归功于可锁定的固件芯片，运行Google编写的安全代码的微控制器，或者上面提到的Google设计的安全芯片。
数据中心中的每个服务器机器都有自己的特定标识，可以绑定到硬件根信任和计算机引导的软件。此身份用于验证机器上的低级管理服务的API调用。
Google已经创建了自动化系统，以确保服务器运行其软件堆栈(包括安全补丁)的最新版本，检测和诊断硬件和软件问题，并在必要时从服务中删除计算机。
安全服务部署
我们将继续描述我们如何从基本的硬件和软件到确保一个服务安全地部署在我们的基础设施上。“服务”是指开发人员写入并希望在我们的基础设施上运行的应用程序二进制文件，例如Gmail SMTP服务器，BigTable存储服务器，YouTube视频转码器或运行客户应用程序的App Engine沙盒。可能有数千台机器运行相同服务的副本以处理所需的工作负载规模。在基础设施上运行的服务由名为Borg的集群编排服务控制。
正如我们将在本节中看到的，基础设施不承担在基础设施上运行的服务之间的任何信任。换句话说，基础设施从根本上设计为多租户模式。
服务标识，完整性和隔离
我们在应用层使用加密认证和授权进行服务间通信。这在管理员和服务可以自然地理解的抽象级别和粒度上提供了强大的访问控制。
我们不依赖内部网络分段或防火墙作为我们的主要安全机制。虽然我们在我们的网络中的各个点使用入口和出口过滤，以防止IP欺骗作为另一个安全层。这种方法还有助于我们最大限度地提高网络的性能和可用性。
在基础架设施上运行的每个服务都具有关联的服务帐户身份。向服务提供加密凭证，在向其他服务发出或接收远程过程调用(RPC)时，可以使用该凭证来证明其身份。这些标识由客户端使用，以确保它们正在与正确的预期服务器通信，并由服务器限制对特定客户端访问方法和数据。
Google的源代码存储在中央存储库中，其中服务的当前版本和过去版本都是可审计的。此外，可以将基础设施配置为要求从特定的审查，检入和测试的源代码构建服务的二进制文件。此类代码审查需要至少一个除作者以外的工程师的检查和批准，并且系统强制该代码对任何系统的修改必须由该系统的所有者批准。这些要求限制内部人或对手对源代码进行恶意修改的能力，并且还提供从服务返回其源的取证跟踪。
我们有各种隔离和沙盒技术，用于保护服务不受在同一台机器上运行的其他服务的影响。这些技术包括正常的Linux用户分离，基于语言和基于内核的沙箱以及硬件虚拟化。一般来说，我们对更危险的工作负载使用更多的隔离层;例如，当对用户提供的数据运行复杂文件格式转换器时，或者为Google AppEngine或Google Compute Engine等产品运行用户提供的代码时。作为一个额外的安全边界，我们使非常敏感的服务，如集群协调服务和一些关键的管理服务，可以专门在专用计算机上运行。
服务间访问管理
服务的所有者可以使用由基础设施提供的访问管理特征来精确地指定哪些其他服务可以与其通信。例如，服务可能希望仅将一些API提供给其他服务的特定白名单。可以使用允许的服务帐户标识的白名单配置该服务，然后该基础设施自动实施此访问限制。
访问服务的Google工程师也会被授予单独的身份，因此可以类似地配置服务以允许或拒绝其访问。所有这些类型的身份(机器、服务和员工)都位于基础设施维护的全局名称空间中。如将在本文档稍后解释的，最终用户身份被单独处理。
基础设施为这些内部身份(包括审批链，日志记录和通知)提供了丰富的身份管理工作流系统。例如，可以通过允许两方控制的系统将这些身份分配给访问控制组，其中一个工程师可以向另一个工程师(也是该组的管理员)批准的组建议进行改变。该系统允许安全的访问管理过程扩展到在基础设施上运行的数千个服务当中。
除了自动API级访问控制机制，基础she设施还为服务提供从中央ACL和组数据库读取的能力，以便他们可以在必要时实现自己的定制的细粒度访问控制。
服务间通信的加密
除了前面部分讨论的RPC认证和授权功能之外，基础设施还为网络上的RPC数据提供加密隐私和完整性。为了向其他应用层协议(如HTTP)提供这些安全优势，我们将它们封装在我们的基础设施RPC机制中。实质上，这提供了应用层隔离并且消除了对网络路径的安全性的任何依赖。即使网络被窃听或网络设备被攻破，加密的服务间通信可以保持安全。
服务可以为每个基础设施RPC配置他们想要的加密保护级别(例如，仅为数据中心内的低价值数据配置完整性级别保护)。为了防止可能试图窃取我们的专用WAN链路的复杂对手，基础设施自动加密在数据中心之间通过WAN的所有基础设施RPC流量，而不需要服务的任何显式配置。我们已经开始部署硬件加密加速器，这将允许我们将此默认加密扩展到我们数据中心内的所有基础架构RPC流量当中。
最终用户数据的访问管理
典型的Google服务是为最终用户完成某项任务。例如，最终用户可以在Gmail上存储他们的电子邮件。最终用户与诸如Gmail之类的应用程序的交互跨越基础设施内的其他服务。因此，例如，Gmail服务可以调用由联系人服务提供的API来访问最终用户的地址簿。
我们已经在前面部分中看到，可以配置联系人服务，使得只允许来自Gmail服务(或来自联系人服务想要允许的任何其他特定服务)的RPC请求。
然而，这仍然是一个非常广泛的权限集。在此权限的范围内，Gmail服务可以随时请求任何用户的联系人。
由于Gmail服务代表特定最终用户向联系人服务发出RPC请求，因此基础设施提供了一项功能，可让Gmail服务将“最终用户权限故障单”作为RPC的一部分。此单据证明Gmail服务目前正代表该特定最终用户为请求提供服务。这使联系人服务能够实现保护措施，其中它仅返回故障单中指定的最终用户的数据。
基础设施提供发出这些“最终用户权限票据”的中央用户身份服务。最终用户登录由中央身份服务验证，然后中央身份服务向用户的客户端设备发出用户凭证，例如cookie或OAuth令牌。从客户端设备到Google的每个后续请求都需要提供该用户凭证。
当服务接收到最终用户凭证时，它将凭证传递给中央身份服务以进行验证。如果最终用户凭证正确验证，中央身份服务返回可用于与请求相关的RPC的短期“最终用户权限故障单”。在我们的示例中，获取“最终用户权限标签”的服务将是Gmail服务，这会将其传递给联系人服务。从那时起，对于任何级联呼叫，“最终用户权限票据”可以由呼叫服务作为RPC呼叫的一部分传递给被呼叫者。
▲服务标识和访问管理：基础结构提供服务标识，自动相互认证，加密的服务间通信和由服务所有者定义的访问策略的实施。
安全数据存储
到目前为止，在讨论中，我们已经描述了如何安全地部署服务。我们现在来讨论如何在基础设施上实施安全数据存储。
Encryption at Rest
Google的基础架构提供各种存储服务，如BigTable和Spanner，以及中央密钥管理服务。 Google的大多数应用程序通过这些存储服务间接访问物理存储。存储服务可以配置为使用来自中央密钥管理服务的密钥在将数据写入物理存储之前对数据进行加密。此密钥管理服务支持自动密钥轮换，提供广泛的审核日志，并与前面提到的最终用户权限标签集成，以将密钥链接到特定的最终用户。
在应用程序层执行加密允许基础设施将自身与较低级别的存储(例如恶意磁盘固件)的潜在威胁隔离。也就是说，基础设施还实现了额外的保护层。我们在硬盘驱动器和SSD中启用硬件加密支持，并仔细跟踪每个驱动器的生命周期。在停用的加密存储设备可以物理地离开我们的保管之前，它使用包括两个独立验证的多步骤过程来清洁。没有通过该擦拭程序的设备在内部用物理方法破坏(例如粉碎)。
删除数据
在Google上删除数据通常首先将特定数据标记为“计划删除”，而不是完全删除数据。这允许我们从无意的删除中恢复数据，无论是客户还是由于内部的错误或进程错误造成的。在被标记为“计划删除”之后，根据服务特定策略来删除数据。
当最终用户删除其整个帐户时，基础设施通知处理最终用户数据的服务已删除该帐户。然后，服务可以调度与已删除的最终用户帐户相关联的数据以进行删除。此功能使服务的开发人员能够轻松实现最终用户控制。
安全的互联网通信
在本文档中的这一点之前，我们已经描述了如何保护我们的基础设施上的服务。在本节中，我们将讨论如何确保互联网和这些服务之间的通信安全。
如前所述，基础设施包括通过LAN和WAN互连的大量物理机器，并且服务间通信的安全性不依赖于网络的安全性。然而，我们确实将我们的基础设施与互联网隔离为私有IP空间，以便我们可以更容易地实现额外的保护，例如防御拒绝服务(DoS)攻击，只需将机器的一部分直接暴露给外部互联网流量。
Google前端服务
当服务想要在因特网上可用时，它可以向称为Google前端(GFE)的基础设施服务注册自己。 GFE确保所有TLS连接都使用正确的证书和遵循最佳实践(如支持完全转发保密)。 GFE还应用于拒绝服务攻击的保护(我们将在后面更详细地讨论)。然后，GFE使用先前讨论的RPC安全协议转发对服务的请求。
实际上，任何选择向外部发布的内部服务都使用GFE作为智能反向代理前端。此前端提供其公共DNS名称，拒绝服务(DoS)保护和TLS终止的公共IP托管。请注意，GFE像任何其他服务一样在基础设施上运行，因此具有扩展以匹配传入请求卷的能力。
拒绝服务(DoS)保护
我们的基础设施规模庞大，使Google能够简单地消化掉许多DoS攻击。也就是说，我们有多层、多级DoS保护，进一步降低任何DoS对运行在GFE后面的服务的影响的风险。
在我们的骨干网向我们的一个数据中心提供外部连接之后，它通过几层硬件和软件进行负载平衡。这些负载平衡器将关于入站流量的信息报告给在基础设施上运行的中央DoS服务。当中央DoS服务检测到发生DoS攻击时，它可以配置负载均衡器以丢弃或限制与该攻击相关联的流量。
在下一层，GFE实例还将关于他们正在接收的请求的信息报告给中央DoS服务，包括负载平衡器没有的应用层信息。然后，中央DoS服务还可以配置GFE实例以丢弃或限制攻击流量。
用户验证
在DoS保护后，下一层防御来自我们的中央身份服务。此服务通常向最终用户显示为Google登录页面。除了要求简单的用户名和密码，该服务还智能地挑战用户基于风险因素的其他信息，例如他们是否从同一设备或过去的类似位置登录。在对用户进行身份验证后，身份服务会发出凭证，例如可用于后续呼叫的Cookie和OAuth令牌。
用户还可以选择在登录时使用第二个因素，例如OTP或防网络钓鱼安全密钥。为了确保这些好处超越Google，我们在FIDO联盟与多个设备供应商合作开发通用第二因子(U2F )开放标准。这些设备现已在市场上出售，其他主要的网络服务也跟随我们实施U2F支持。
操作安全
到目前为止，我们已经描述了如何在我们的基础设施中设计安全性，并且还描述了一些用于安全操作的机制，例如RPC上的访问控制。
我们现在转向描述我们如何安全地操作基础设施：我们安全地创建基础设施软件，我们保护我们员工的机器和凭据，我们防御内部人员和外部角色对基础设施的威胁。
安全软件开发
除了前面介绍的中心源代码控制和双方审查功能之外，我们还提供了防止开发人员引入某些类型的安全漏洞的库。例如，我们有消除Web应用程序中的XSS漏洞的库和框架。我们还有自动化工具，用于自动检测安全漏洞，包括模糊器、静态分析工具和Web安全扫描程序。
作为最后检查，我们使用手动安全审查，从快速分类到更低风险的功能，深入设计和实施审查最危险的功能。这些审核由包括网络安全、密码学和操作系统安全专家的团队进行。审查还可以产生新的安全库功能和新的模糊器，然后可以应用于其他未来的产品。
此外，我们运行一个漏洞奖励计划，我们向任何能够发现并通知我们基础设施或应用程序中的错误的人员付给报酬。我们已经在这个计划中支付了几百万美元的奖金。
在我们使用的所有开源软件中查找0天漏洞利用和其他安全问题上，Google还投入大量精力，并上传这些问题。例如，在Google上发现了OpenSSL Heartbleed错误，我们是CVE以及Linux KVM虚拟机管理程序的安全错误修复程序最大的提交者。
保持员工设备和证书安全
我们进行了大量投资，以保护我们员工的设备和凭证免受妥协，并监控活动以发现潜在的妥协或非法内部活动。这是我们投资的关键部分，以确保我们的基础设施安全运行。
复杂的网络钓鱼目标一直瞄准我们员工。为了防范这种威胁，我们已经替换了可疑的OTP第二个因素，强制使用我们员工帐户中与U2F兼容的安全密钥。
我们对我们的员工用于操作我们的基础设施的监控客户端设备进行了大量投资。我们确保这些客户端设备的操作系统映像是最新的安全补丁，我们控制可以安装的应用程序。此外，我们还具有用于扫描用户安装的应用程序、下载、浏览器插件和从Web浏览的内容以便在公司客户端上适用的系统。
在公司LAN上不是我们授予访问权限的主要机制。相反，我们使用应用程序级访问管理控制，允许我们只在特定用户来自正确管理的设备和预期的网络和地理位置时公开内部应用程序。(更多细节参见我们关于'BeyondCorp'的附加阅读。)
降低内部风险
我们积极主动地限制和监控已授予对基础设施管理访问权限的员工的活动，并通过提供可以以安全和受控的方式完成相同任务的自动化，持续努力消除对特定任务的特权访问的需要。这包括需要对某些操作进行双方批准，并引入有限的API，允许在不暴露敏感信息的情况下进行调试。
Google员工对最终用户信息的访问权限可以通过低级基础设施的挂钩记录。 Google的安全小组会主动监控访问模式并调查异常事件。
入侵检测
Google拥有先进的数据处理管道，将基于主机的信号集成到单个设备上，基于网络的信号来自基础设施中的各个监控点，以及来自基础设施服务的信号。基于这些管道建立的规则和机器智能为运维安全工程师警告可能的事件。我们的调查和事故响应小组每年365天全天24小时对这些潜在事件进行分类、调查和应对。我们进行红队(Red Team)练习来衡量和提高我们的检测和反应机制的有效性。
保护Google云端平台(GCP)
在本节中，我们强调我们的公共云基础设施，GCP，如何从底层基础设施的安全中受益。在本节中，我们将使用Google Compute Engine(GCE)作为示例服务，并详细描述我们在基础设施上构建的特定于服务的安全改进。
GCE使客户能够在Google的基础设施上运行自己的虚拟机。GCE实现包括几个逻辑组件，最显著的是管理控制平面和虚拟机本身。
管理控制平面公开外部API表面并协调虚拟机创建和迁移等任务。它作为基础设施上的各种服务运行，因此它自动获得基本完整性功能，如安全引导链。各个服务在不同的内部服务帐户下运行，以便每个服务都可以被授予只有在对控制平面的其余部分进行远程过程调用(RPC)时所需的权限。如前所述，所有这些服务的代码存储在中央Google源代码存储库中，并且在此代码和最终部署的二进制代码之间存在审计跟踪。
GCE控制平面通过GFE公开其API，因此利用了拒绝服务(DoS)保护和集中管理的SSL / TLS支持等基础设施安全功能。客户可以通过选择使用基于GFE构建的可选的Google Cloud Load Balancer服务来获得对在其GCE VM上运行的应用程序的类似保护，并可以减轻许多类型的DoS攻击。
对GCE控制平面API的最终用户认证是通过Google的集中身份服务完成的，该服务提供安全功能，例如劫持检测。授权使用中央云IAM服务完成。
从GFE到其后面的第一服务以及其他控制平面服务之间的控制平面的网络流量由基础设施自动认证并且每当它从一个数据中心传播到另一数据中心时被加密。此外，基础设施也被配置为加密数据中心内的一些控制平面业务。
每个虚拟机(VM)都使用关联的虚拟机管理器(VMM)服务实例运行。基础设施为这些服务提供两种身份。一个身份由VMM服务实例用于其自己的调用，一个身份用于VMM代表客户的VM进行的调用。这允许我们进一步对来自VMM的呼叫的信任进行分割。
GCE持久磁盘使用由中央基础设施密钥管理系统保护的密钥在静止时进行加密。这允许自动旋转和对这些键的访问的中央审计。
今天的客户可以选择是否将来自其VM的流量发送到其他VM或互联网，或者实施他们为此流量选择的任何加密。我们已开始推出自动加密，用于将客户虚拟机的广域网遍历跳转到虚拟机流量。如前所述，基础设施内的所有控制平面WAN流量都已加密。将来，我们计划利用之前讨论的硬件加速网络加密，以加密数据中心内的虚拟机之间的LAN流量。
提供给VM的隔离基于使用开源KVM堆栈的硬件虚拟化。我们通过将一些控制和硬件仿真栈移动到内核之外的非特权进程，进一步强化了我们的KVM的特定实现。我们还使用诸如模糊、静态分析和手动代码审查等技术广泛测试了KVM的核心。如前所述，大多数最近公开披露的漏洞已被上传到来自Google 的KVM。
最后，我们的运营安全控制是确保访问数据遵循我们的政策的关键部分。作为GoogleCloud Platform的一部分，GCE对客户数据的使用遵循GCP对客户数据政策的使用，即除非有必要向客户提供服务，否则Google不会访问或使用客户数据。
结论
我们已经描述了Google基础设施是如何设计的，以便在互联网规模上安全地构建、部署和运营服务。这包括Gmail等消费者服务和我们的企业服务。此外，我们的Google云端产品是建立在这个相同的基础设施之上。
我们在确保我们的基础设施服务方面投入了大量资金。我们有数百名专门用于安全和隐私的工程师，分布在所有Google产品中，包括许多获得认可的行业权威机构。
正如我们所看到的，基础设施的安全性是从物理组件和数据中心到硬件来源，然后到安全引导、安全服务间通信、安全数据静止，受保护的服务访问互联网以及我们为运营安全而部署的技术和人员流程。
本文转自d1net（转载）