正文
硬
件安全
对绝大多数公司而言都不会涉及这个章节，因为大多数公司也就顶多白牌服务器，而不是从主板到芯片全都自研。以前觉得华为、Apple这类公司用TC（可信计算）的概念还是用的比较多，但是感觉BAT都不玩这些，到后来分析iOS就一下明白了这个其实是由产品和服务所涉及的技术栈深度决定的，因为华为、Apple这类公司的产品线横跨硬件、OS和上层应用，而BAT等公司造轮子（自研）的范畴大多止于软件，所以很少涉及，甚至在这些公司早期的安全团队里大多数是由Web安全技能的人组成的业务驱动使然。
从描述上看，Google硬件到底层软件栈的安全设计跟iOS基本是一致的，都是基于可信的思路，上一层（软件）验证下一层（硬件/固件）的完整性，并区分唯一标识。用唯一标识+信任链来鉴别是否合法的硬件来源（而不是IDC提供商在机房里偷梁换柱换了台服务器）。
更上层的部分，例如引导程序、内核、启动镜像的完整性都是启动信任链的一般实现，有兴趣的同学可以参考一下iOS的设计与实现。硬件唯一标识会成为后面提到的全局访问控制体系的前提之一。
这里还有一条很重要的信息：Google在自己的生产网络引入了NAC（网络接入控制）机制，这个安全手段本来是为OA办公网络的终端管理场景设计的，目的是区分不信任的终端不能接入（相对可信）的公司网络。这样做可以想象几个场景：假如机房管理员从回收垃圾那儿找到了废弃的服务器，数据也没被删除，即便进入了机房重新插网线也接入不了网络；甚至进一步推测，第三方供应商跑到IDC接上自己的MacBook想用Nmap扫描一把估计也不行。
服务部署
Google在IDC内部服务治理上最大的不同是：不信任IDC内网（注明：尽管思路上可能有相似之处，但与G厂自家在办公网络的安全解决方案BeyondCorp不是一件事）。很多公司的IDC生产服务网络被设计为私有云模式（单租户），在安全上相对的信任IDC内网通信，通过2层/3层隔离或者类似IP白名单的方式来建立IDC内网的弱访问控制体系和信任模型。而Google则是天生设计成多租户（公有云）模式，把原本用于对终端用户（2C端）的认证鉴权机制完全用于IDC内网的服务间通讯，服务间通讯有完整的双向鉴权，是一个强访问控制体系。笔者推测这样做可能是有几方面的原因：
-
同一个服务的不同实例可能被部署为跨物理机、跨机架甚至跨IDC，与其它的服务实例混合部署，原来相对集中的通过IP的访问控制模型已经不太适用于完全分布式的架构，过于分散的多点对多点的ACL规则想象一下就头疼，于是就出现一个情况：要么访问控制很粗很大条效果不明显，要么很细但是规则几乎没法写。
-
第二个原因可能是由于server和服务实例规模数巨大引起的海量ACL条目难以维护的问题，干脆扔了，用完全的鉴权。
-
如果用传统的访问控制手段，例如VXLAN隔离、交换机ACL、主机iptables规则会无法维持一个巨大的弹性内部网络，服务扩容时都会受到阻碍，监控、调试和诊断都会更难。之前有同学提出通过主机安全agent动态生成白名单的内网隔离思路，现在Google则在这个问题上给出了自己的解，这也揭开了我在《互联网企业安全高级指南》中没有写出来的部分:)。本质上这是由规模量变到质变引发的问题，如果你的IDC内网只有几台机器真没必要那么做。Google也强调了自己有做网络隔离和防止IP欺骗，但没有把这个当成主要手段。
发布安全：Google的所有代码存储于一个集中的代码仓库，同时保留当前和过去的版本，每一个发布的二进制文件都能关联到构建时的源代码版本，这里暗示了Google有做白名单和完整性校验，其实Google和Amazon都有白名单，但这要求基础架构高度统一。发布时需要至少1人review同意（可以理解为在构建/发布系统中的workflow），任何对某个系统的更改需要系统的owner同意。统一的代码仓库，意味着发布的入口是唯一可控的，版本可唯一追溯，同时交叉的code review可以部分矫正一些内部的不良行为：例如开发人员安置后门，恶意彩蛋等。这实际上是Google研发文化的一部分，不一定是出于安全的原因，不过总而言之，安全是这个流程的受益者。
以前有boss问过我离职程序员安置后门程序如何检测的问题，海量Web下不具有webshell & sqli的特征，当初想到结对编程，交叉review，觉得有点理论化。Google给出了的解正好，防止钓鱼，同时防止内鬼，不只是简单的防外，而是防内外，覆盖整个价值链。
同一个机器间的服务隔离，主要通过：Linux原生的用户空间隔离（Android的appid的原理），程序语言和kernel的沙箱，以及硬件虚拟化手段。对于涉及用户提交代码或文件的高风险服务例如Google App Engine & Google Compute Engine会使用多层次隔离和纵深防御（如下图所示），另外对于集群管理和KMS等服务会使用专门的物理机。实际上一般情况下密钥管理会使用专有硬件HSM，至于集群管理服务使用专用机器推测一方面可能有一些完整性校验的安全强相关功能，另一方便可能跟集群管理服务本身的可用性要求及failover机制有关。
业内一直有HIDS（Host-based Intrusion Detection System，主机入侵检测）的技术路线之争，大规模容器时代即将到来，技术路线的选择更是迫在眉睫。业界的一种看法是私有云以Linux用户态为主，关注运维需求，软件兼容性和server本身的可用性需求；另一种则是内核态，以纯安全视角的强掌控型实现为主。从Google的实现里似乎也可以得到启示：G厂走的是公有云，天然多租户模式，使用了内核态路线。当然对于效仿者而言，前提是：
Google的内部服务访问控制可配置为特定的服务只允许指定的API或者指定的人才可以访问的模式，实现上通过Machine ID、Service ID、User ID放在一个全局命名空间来做访问控制的基础（注：2C端的访问控制是另外一套体系），支持Group对Group来做多对多的访问控制，同时提供了“two-party control”，即一个变更提交后需要由同group的另外一个管理员approve才能生效，这其实跟分布式事务中二阶段式提交是一个原理，为了保证最终一致性。Google在这些流程的问题上直接套用了工程理论。
Google自身的工程师访问内部API需要通过这种认证鉴权模式，实际上暗含了另外一个课题：数据安全。这部分在业界比较受重视，但需求往往比较抽象，而在实现方式上更是没有统一的标准，Google的这种方式貌似歪打正着，把2C的鉴权模式用在生产网络和后台系统，实际上是对原来运维通道获取数据途径的更进一步收敛，保留强审计和日志，这样一并连数据安全也算解决了一部分，虽然不是全部。
Google的内部服务提供全加密通讯的能力，例如HTTP封装成RPC，而RPC默认提供几种不同的加密强度：低价值数据只做完整性校验，高价值的用更强壮的加密等级，跨IDC传输流量自动加密。
最后举了一个Gmail服务访问联系簿（contacts服务）例子来说明RPC调用的鉴权细粒度，如果ACL设置为允许Gmail访问联系簿这种细粒度是不够的，因为用户A可以越权访问用户B的联系簿，水平权限的这类问题扫描器不容易覆盖，干脆在架构设计上一并解决：RPC请求带用户的ticket走一个内部的SSO（单点认证鉴权）以验证是否可以访问对应的数据，这样就相当于内部的API调用在用户这个细粒度上做了一次全流量的鉴权，从架构上避免了水平权限类的问题。再次回到安全架构的顶层设计，Google的思路就是把所有分散的鉴权点集中起来，在一个高度抽象的层次上做好一件事，最大程度的隔离。
数据安全
