知识卡片

Google为落地零信任建立的专用基础设施证明其代价高昂

普通读书笔记卡

内容

零信任安全模型此前一直停留在理论层面,不是因为方法本身巧妙与否,而是 受制于边界安全”降低应用系统复杂度和网络传输性能损耗”这个真实存在的 合理性——要落地零信任,就必须付出额外的复杂度和性能代价。Google论文 给出的证据是:为了达成前述几条安全原则,Google为此专门研发了一整套内部 工具,而不是靠人工流程或简单配置就实现的。为抵御DDoS、保证所有流量走 TLS,建了边缘代理Google Front End;为让身份只来源于服务本身,建了双向 认证+传输加密系统Application Layer Transport Security;为消除服务间 默认信任,建了管理认证鉴权审计策略的Service Access Policy;为确保只 运行来源可信的代码,建了部署时检查机制Binary Authorization和验证BIOS/ BMC/Bootloader/内核签名的Host Integrity;为给工作负载强隔离,建了轻量级 虚拟化方案gVisor(与Intel的Kata Containers思路相似,本质都是为每个容器 配一个独立虚拟Linux内核来弥补容器共享内核带来的隔离缺陷)。这一长串 专用基础设施清单本身就是最有力的证据:零信任安全的目标很美好(”对程序 来说安全是日常、风险是例外”),但要真正做到,需要的工程投入远超大多数 团队的现实能力——只有到了云原生时代、虚拟化基础设施能把这些复杂度隐藏 起来,且容器和虚拟网络性能足够高、能弥补安全隔离带来的额外损耗时,零信任 才有落地的现实基础,而不只是”喊口号”。

参考来源

- 位置:《凤凰架构:构建可靠的大型分布式系统》第9章"可靠通信"9.1.2节 "Google的实践探索"(源文件:_epub-src对应OEBPS/Text/chapter107.xhtml) - 结论依据:原文逐一列举Google Front End、Application Layer Transport Security、Service Access Policy、Binary Authorization、Host Integrity、 gVisor等专用工具及其对应解决的安全原则,并指出普通团队难以负担这样的 运维能力,直接支撑本卡片结论。 - 原始内容:为了保护服务集群内的代码与基础设施,Google设计了一系列 内部工具,才最终得以实现前面所说的那些安全原则……哪怕不需要开发、 购买,免费将上面Google开发的安全组件赠送于你,大多数开发团队恐怕也 没有足够的运维能力。