2017-05-15 Google 安全架构设计总览.md

• tags: tech
• date: 2017-05-15

Google 安全架构设计总览

Google 云平台 2017 年初发布了安全设计纵览：https://cloud.google.com/security/security-design/ 系统化的介绍了 Google 在安全方面所做的工作，本文参照原文以中文列出这个架构中的核心内容。

总结

Google 具有全球可扩展的技术架构来保证在 Google 的整个信息处理流程的安全性。这套架构包括：服务的安全部署、包括用户隐私在内的安全数据存储、服务之间的安全通信、面向 Internet 的安全通信、以及系统管理员的安全管理。Google 使用这套架构来构建网络服务，包括面向用户的 Gmail，Search，Photo 等。本文将从数据中心的物理层面到架构软件到人员组织管理各个层面逐次分析保证整个系统的安全性。

安全底层架构

这节讲述在数据中心专有硬件层，物理环境保证，与运行在每台设备上的底层软件栈。

物理环境的安全

• 自建数据中心，避免自然灾害
• 部署多种安防技术：生物识别、金属探测、视频监控、车辆管理、与光学入侵检测系统等
• 对于部署在第三方的设备 Google 具有完全的物理环境控制权，并部署上述安放设施

硬件的设计与供应商排查

• Google 的服务器与网络设置全部自行设计并严格审查零件的供应商，保证制造零件的安全性
• 专门设计了一款硬件用来校验 Google 设备的合法性，从硬件层面保证设备安全

安全的启动软件与设备认证

• 使用加密签名的底层组件，如：BIOS, bootloader, kernel, and base operating system image.
• 这些组件在每次启动系统时都会校验，并且组件全部由 Google 控制构建，并在每代硬件设计中持续改进
• 比如对软件的信任校验不同代的设备分别位于固件芯片、运行安全代码的微控制器，或上面提到的安全芯片中

安全的服务部署

这里的服务指的是应用程序的可执行文件，如 Gmail SMTP server, a BigTable storage server, a YouTube video transcoder, or an App Engine sandbox running a customer application。这些服务可能会被部署成千上万个副本来提升负载能力，它们都被 Borg 集群控制系统管理。在架构层面不会假设任何两个服务之间存在可信关系，也就是说架构被设计为一个多租户系统

服务的识别、完整性、与隔离性

• 在应用层做服务间通信加密处理，将系统管理与服务开发解耦并提供一个抽象层的访问控制
• 不依赖内网分割与防火墙，但确实在一些节点做包过滤已避免IP伪造等潜在的威胁，最大化网络的性能与可靠性
• 每个服务都有一个加密凭证来表明身份，需要使用这个身份来发起或接受 RPC 通信，同时不同服务也能根据凭证配置拒绝调用
• 对代码版库严格管理，代码 review 必须由开发者以外至少一名工程师批准才能通过，系统模块代码必须由该模块负责人批准同意才能提交
• 根据服务不同的风险等级对其进行不同层面的隔离，包括 Linux 用户隔离，基于语言和内核的沙盒措施，以及硬件虚拟化等等

服务间的访问控制

• 服务作者可以通过架构配置允许哪些服务访问它的 API，架构会自动处理白名单权限
• 工程师也会被分配一个独立 ID，使用这个 ID 来控制工程师的访问权限，这都在架构维护的一个独立的命名空间中
• 架构集成了访问批准链、日志、提醒等，一个 ID 可以分配到不同组中。如一个工程师提交修改需要另外两个工程师批准等
• 出 API 级别的控制外，架构也提供了从ACL／组数据库读取数据的能力以便服务自行实现权限控制

服务间的通信加密

• 架构做了 RPC 的加密，即使应用层摆脱了加密网络路径安全的依赖也保证了在内网被设备被攻破的情况下通信安全
• 可以根据动态根据保密级别选择不同的加密方法，比如 WAN 口上不同数据中心的 RPC 流量需要更强的加密措施

用户资料的访问管理

• 一些服务可能需要调用其他服务的数据，比如 Gmail 需要调用 Contact 的 API，通过上述架构能够实现权限管理但仍然很宽泛，Gmail 此时能读取所有用户的 Contact
• 因此在架构中增加了专门用户认证的服务用来发放 ticket，用户登录时从认证服务器取得身份信息，如 Cookie 或 OAuth，接下来的每个请求都会包含此身份信息

安全的数据存储

静态数据加密

• Google 大多应用通过 BigTable，Spanner 等存储服务进行存储，这些存储服务通过密钥中心在将数据写入物理存储前进行加密，同时密钥服务支持自动更新、日志审计等，并把密钥与上文提到到用户 ticket 关联
• 应用层加密可以避免潜在了物理威胁，比如含有恶意代码的硬盘。同时硬盘在离开机房时要进行严格的数据擦除，如果不能达标完成则这块硬盘会被物理销毁

数据删除

• 用户删除数据时通常只是把数据标记为“待删除”然后依据规定物理删除
• 如果用户直接删除账号那么架构会同时平台的每个服务有计划的将数据完全删除

安全的 Internet 通讯

架构中包含了大量的物理设备并使用网络连接，虽然架构见服务通信不依赖于网络安全，但是为了避免潜在的危险 Google 组建了私有网络并只向外爆漏了少量 IP 地址

Google 前端服务 （GFE）

• 服务需要接入 Internet 时需要想 GFE 注册，GFE 按照最佳实践处理了 https 证书一致性等问题，然后 GFE 与服务之间通过上文提到的安全 RPC 通信
• GFE 同时提供了公网IP、DoS保护以及TLS的终结等功能。GFE 也是架构上了一个服务因此可以轻松扩展，匹配最少流量

Dos 保护机制

• 外部连接发送到数据中心时会转到中心 DoS 服务，如果 DoS 服务发现袭击正在发生则配置负载均衡对攻击流量进行丢弃或阻塞
• GFE 同时也会检测并向 DoS 服务中心报告可疑流量

用户认证

• DoS 服务的下一层时用户中心服务，这个服务基于风险评估智能的要求用户提供其他信息比如统一设备，地理位置，非机器人识别等
• 鼓励2次认证避免比如钓鱼网站的威胁，Google 在 FIDO 联盟中和多个设备供应商制定了全球 U2F 开放标

运维安全

代码开发安全

• 除严格的代码审查外，开发了一些代码库避免某些类型的漏洞，比如 XSS，同时也开发了检查安全缺陷的自动化工具，包括模糊测试、静态代码分析以及 web 安全扫描器等工具
• 对于高危险的功能，会启用专门专家组进行审查并可能完善安全库用于将来的安全审查
• 运作有安全奖励计划，对发现漏洞作出奖励，同时投入大量精力寻找0day漏洞以及开源软件中的安全问题

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

• 对 LAN 网里的特定内容做访问限制，大多数服务进行二次认证操作避免钓鱼，一些高级别操作要求特定 IP 或特定设备管理
• 尽可能自动化的完成日常任务，是流程更加安全可控
• 对一些操作需要两人批准才能执行，引入受限 API，部署测试环境。对员工操作信息记录日志

入侵检测

• 做RedTeam演习来提高检测和响应机制的有效性

总结

本文讲了 Google 的架构设计怎样保证服务的构建、部署和运维都能在 internet 的规模上保证安全。这包括了面向客户的服务比如Gmail，也包括了企业服务。

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