【零信任安全架构】BeyondCorp 六篇论文全景：Google 怎么把零信任从概念变成全公司现实

Google BeyondCorp 是零信任工程史上最重要的参考实现——不是因为它的技术方案完美无缺，而是因为 Google 公开记录了从 2011 年的决策到 2018 年的收官，整整 7 年的工程演化。六篇论文发表在 USENIX ;login: 杂志上，每一篇解决一个特定的工程问题。

本文把六篇论文当工程复盘来读——看 Google 在每一步面临什么约束、做了什么取舍、犯了什么错。这不是论文摘要的中文版，而是对设计决策的交叉对比分析。

前置阅读：本站 NIST SP 800-207 架构拆解。

一、背景：极光行动和 Google 的反思

2009 年底，Google 遭受了代号为”极光行动”（Operation Aurora）的 APT 攻击。攻击者利用 IE 浏览器的零日漏洞渗透了 Google 的网络。这次攻击的直接后果不是修复漏洞——而是 Google 安全团队对整个安全架构的根本性反思。

他们的核心洞察后来写在了 BeyondCorp Part I (Ward & Beyer, 2014) 的第一段：如果内网的边界可以因为一个浏览器零日漏洞而瞬间失守，那么把信任建立在内网位置上是一个数学上不可靠的假设。

John Kindervag 在 2010 年提出了”零信任模型”的概念（Forrester Research），但当时没有任何一家大型企业实践过。Google 决定做第一个。

二、六篇论文的工程问题和设计决策

2.1 Part I（2014）：为什么、是什么

论文：Ward, R. & Beyer, B. “BeyondCorp: A New Approach to Enterprise Security”. ;login:, Vol. 39, No. 6, December 2014.

解决的问题：定义 BeyondCorp 的架构愿景。

这篇论文的核心贡献是重新定义了企业网络的信任模型：

• 传统模型：“内网可信，外网不可信”——这是一个二元假设
• BeyondCorp 模型：“不信任网络位置，信任设备和用户身份的实时验证”

论文给出了 BeyondCorp 的核心组件蓝图：设备证书 + 设备清单数据库 + SSO + 访问代理 + 访问控制引擎。但这个蓝图没有实现细节——那留给后面的论文。

被否定的方案：论文暗示 Google 考虑过在 VPN 基础上加固（加 MFA、加设备检查、加更细的 ACL），但得出的结论是”加固后的 VPN 仍然是 VPN”——只要边界存在，边界内就是信任区，横向移动就不可控。

2.2 Part II（2016）：怎么搭

论文：Osborn, B., McWilliams, J., Beyer, B., & Saltonstall, M. “BeyondCorp: Design to Deployment at Google”. ;login:, Vol. 41, No. 1, Spring 2016.

解决的问题：从白板到生产部署的完整实施路径。

这篇是关键论文——它回答了 Part I 没有回答的所有工程问题：

（1）设备清单数据库（Device Inventory Service）

这是一个覆盖全公司所有设备的元数据库，记录每台设备的： - 硬件信息（型号、序列号、TPM 芯片） - 操作系统版本和补丁级别 - 磁盘加密状态 - 已安装的安全软件 - 设备所有权（企业配发 vs 个人设备） - 最后同步时间

关键设计决策：设备清单数据库的更新频率和延迟容忍度。Google 选择的方案是每分钟同步一次——这意味着设备姿态变化（如补丁打上）最长一分钟后才能反映到访问决策中。这是一个有意的权衡：更短的间隔会增加数据库的写负载，更长的间隔会延长”设备已不合规但仍能访问”的窗口。

（2）信任推断引擎（Trust Inference Engine）

Google 的信任引擎不是基于分数的（score-based），而是基于等级的（tier-based）——设备被分配到三个信任等级之一：

（3）访问控制引擎（Access Control Engine）

这是 PDP 的雏形——接收用户身份、设备信任等级、资源敏感级别，返回 allow/deny。Google 的实现是集中式的——所有访问决策在一个引擎中做出，然后下发到访问代理执行。

被否定的方案：论文提到 Google 最初尝试在 2012 年自行开发客户端证书系统，但失败了——原因是跨平台的证书管理复杂度远超预期。Google 后来引入了第三方 CA 来管理设备证书，这是一个非技术性的但非常关键的工程决策。

2.3 Part III（2016）：访问代理

论文：Escobedo, V., Beyer, B., Saltonstall, M., & Peck, J. “BeyondCorp: The Access Proxy”. ;login:, Vol. 42, No. 4, Winter 2016.

解决的问题：访问代理是 BeyondCorp 架构中最关键的组件——它是每个用户请求的入口点。本文拆解了访问代理的完整请求处理管线。

访问代理的请求管线：

sequenceDiagram
    participant User as 用户浏览器
    participant AP as 访问代理 (PEP)
    participant SSO as Google SSO
    participant DI as 设备清单服务
    participant ACE as 访问控制引擎 (PDP)
    participant App as 企业应用

    User->>AP: 1. GET /internal-app (携带设备证书)
    AP->>AP: 2. 验证设备证书 (X.509 client cert)
    AP->>SSO: 3. 重定向用户到 SSO (OAuth2 / OIDC)
    SSO->>User: 4. 登录 + MFA
    User->>AP: 5. 携带 SSO token 返回
    AP->>DI: 6. 查询设备信任等级
    DI->>AP: 7. 返回设备信任等级
    AP->>ACE: 8. 查询: user + device_tier + resource
    ACE->>AP: 9. allow / deny
    alt allow
        AP->>App: 10. 转发请求 (注入用户身份 Header)
        App->>AP: 11. 响应
        AP->>User: 12. 返回响应
    else deny
        AP->>User: 10. 403 Forbidden + 解释信息
    end

关键设计点：

• 设备证书是第一步：在用户身份验证之前，访问代理首先验证设备证书。如果设备证书无效或缺失，请求直接拒绝——不进入 SSO 流程。这个顺序是刻意的：减少对未知设备发送 SSO 挑战的浪费。
• 证书透明性：Google 运行了一个内部的证书透明性日志（Certificate Transparency），记录所有设备证书的签发和吊销。这是一个防御措施——如果设备证书被冒签，至少能被事后发现。
• Header Injection 的安全性：访问代理将用户身份信息（email、用户 ID）注入 HTTP Header（如 X-Goog-Authenticated-User-Email）传递给后端应用。论文明确指出：后端应用不能直接信任这些 Header——因为 Header 可以被伪造。Google 的做法是让访问代理和后端应用之间使用 mTLS，使得只有访问代理能连接到后端——但即便如此，后端仍然被建议验证访问代理签发的 JWT，而不是信任 Header。
• 非 HTTP 协议的支持：访问代理通过 WebSocket 隧道方式来支持 SSH、gRPC 等非 HTTP 协议。这是一个重要的架构扩展——零信任不只是”Web 应用的访问控制”。

性能数据：论文提到访问代理引入的额外延迟在 10-20ms 量级（设备证书验证 + SSO token 验证 + 访问控制查询），在 Google 的全球基础设施中通过就近部署（anycast）将延迟保持在可接受范围。

2.4 Part IV（2017）：迁移

论文：Spear, B., Beyer, B., Cittadini, L., & Saltonstall, M. “Migrating to BeyondCorp: Maintaining Productivity While Improving Security”. ;login:, 2017.

解决的问题：怎么让全公司从 VPN 模型迁移到 BeyondCorp 模型，而不中断业务。

迁移策略：

flowchart LR
    subgraph Phase1["Phase 1: 并行运行"]
        VPN1["VPN 路径"]
        BC1["BeyondCorp 路径"]
    end
    
    subgraph Phase2["Phase 2: 监控对比"]
        VPN2["VPN 路径 (监控)"]
        BC2["BeyondCorp 路径 (主力)"]
    end
    
    subgraph Phase3["Phase 3: 收紧"]
        BC3["BeyondCorp 路径<br/>(更多资源仅通过此路径可达)"]
        VPN3["VPN 路径<br/>(仅遗留系统)"]
    end
    
    subgraph Phase4["Phase 4: 退役"]
        BC4["BeyondCorp 唯一路径"]
    end
    
    Phase1 --> Phase2 --> Phase3 --> Phase4

论文的核心教训：

（1）遗留系统是最大阻力。不是所有应用都支持 OAuth2/OIDC 认证。Google 花了大量精力在”应用适配”上——对于无法直接改造的应用，Google 在访问代理层面做身份映射（将 Google SSO 身份映射为应用理解的 HTTP Header），应用本身不需要改动认证逻辑。

（2）用户习惯迁移。VPN 对用户来说是一种心智模型：“先连 VPN，然后一切照旧”。BeyondCorp 改变了这个模型——“不用连任何东西，每个应用自己验证你”。这个改变在初期造成了大量 helpdesk 工单，用户的直觉是”我没连 VPN，所以这个应用打不开”。

（3）监控驱动迁移。Google 在迁移过程的每个阶段都监控了两个关键指标：VPN 上的流量和 BeyondCorp 访问代理上的流量。迁移进入下一阶段的条件不是”时间到了”，而是”BeyondCorp 路径上的流量占比超过了某阈值”。这种数据驱动的切流确保了没有应用在迁移中被遗忘。

2.5 Part V（2017）：用户体验

论文：Zyzniewski, F. & Saltonstall, M. “BeyondCorp: The User Experience”. ;login:, Fall 2017.

解决的问题：零信任改变了用户的工作方式——怎么让这种改变不成为生产力障碍？

这篇论文最独特的地方在于：它的作者中有 UX 工程师（Zyzniewski），而不是纯安全工程师。论文讨论了：

• Chrome 扩展：Google 开发了一个 BeyondCorp Chrome 扩展，在浏览器层面处理设备证书的展示和 SSO 流程的重定向。这是把”安全基础设施”和”用户日常工作流”的接触面做得尽量小。
• 新员工入职流程：新员工拿到设备后，不再需要配置 VPN——设备证书在 MDM 注册时自动安装，SSO 账户在 HR 系统创建时自动同步。从新员工的角度，BeyondCorp 比 VPN 更简单——“打开电脑就能访问内部系统”。
• VPN 减少策略：不是直接关闭 VPN，而是逐步减少”只能通过 VPN 访问”的资源数量。当 VPN 上能做的事越来越少，用户自然地停止使用 VPN。
• 自助排障门户：当用户被拒绝访问时，访问代理返回一个包含解释信息的 403 页面（“你的设备信任等级是 Basic，但这个资源需要 Trusted 等级——你的设备因 macOS 补丁过期而处于 Basic 等级，请打开系统偏好设置 → 软件更新”）。这与传统 VPN 的”连不上就是连不上，自己猜原因”形成了鲜明对比。
• 解释引擎：一个内部系统，允许用户输入”我想访问 X 但被拒绝了”，系统告诉他准确的被拒绝原因以及如何修复。

这些看起来像是”小功能”，但它们是零信任从安全工程变成全公司范围的可用基础设施的关键。

2.6 Part VI（2018）：机群健康

论文：Google BeyondCorp Team. “BeyondCorp: Building a Healthy Fleet”. ;login:, 2018.

解决的问题：设备机群的持续健康管理。如果零信任的访问决策依赖设备姿态，那么设备姿态的准确性和全面性就成了整个架构的基础假设。

Google 面临的设备多样性：论文提到 Google 内部同时运行 6 种操作系统（macOS、Windows、ChromeOS、Linux 多个发行版、Android、iOS）。每种操作系统的安全属性测量方式不同：

“已识别”状态的引入：这是论文的一个重要设计——Google 在 Trusted 和 Untrusted 之间引入了一个过渡状态：Identified（已识别）。当一台新设备首次出现在网络中的时候，它既不能标记为 Trusted（没有历史数据验证合规），也不能标记为 Untrusted（这会导致使用者完全无法工作）。Identified 状态允许该设备访问最低级别的资源（如内部 Wiki 和 HR 系统），同时触发设备合规检查——当检查通过后，自动提升到 Basic 或 Trusted。

补救机制（Remediation）：当设备被降级后（如从 Trusted 降到 Basic），补救软件自动向用户弹出通知，告知降级原因和修复步骤。用户完成修复（如安装补丁）后，设备姿态在下一轮检查中更新，信任等级自动恢复。

这台设备是怎么来的？：论文讨论了一个”先有鸡还是先有蛋”的问题——新设备刚出厂，没有设备证书，无法通过访问代理获取公司软件库。Google 的解决方案是：新设备在 MDM 注册时通过 TPM 证明获得一个初始的 Identified 状态和临时证书，然后可以下载公司软件（包括设备管理 agent），完成合规检查后升级。

三、六篇论文的隐含叙事

读这六篇论文不能只看技术方案——六篇论文的发表顺序和内容侧重本身就传达了 Google 对零信任工程的深层理解：

1. 先架构，后实现（Part I → Part II）：Paper I 先定义了”什么是 BeyondCorp”，Paper II 才讲”怎么搭”。这个顺序听起来理所当然，但绝大多数失败的安全项目正好是倒过来的——先买了产品，再问”这个产品在我们的架构中扮演什么角色”。

2. 先核心组件，后边缘体验（Part II → Part III → Part IV → Part V）：设计到部署（Part II）首先到位，然后才是访问代理作为具体组件（Part III），接着是迁移路径（Part IV），最后才讨论用户体验（Part V）。用户体验不是 Afterthought——它被放在了”迁移路径”之后，因为只有迁移过程中才能真实暴露用户体验问题。

3. 安全基础设施最终要变成平台（Part V → Part VI）：Paper V（用户体验）和 Paper VI（机群健康）的隐含信息是：零信任的最终形态不是一个安全产品，而是一个基础设施平台——用户不需要理解它、IT 团队不需要手动管理它、安全团队通过策略而非工单来运营它。

4. 4 年的迁移时间线不是”慢”，而是”必须”：从 2011 年启动 BeyondCorp 项目到 2014 年发表第一篇论文，再到 2018 年全公司迁移完成——7 年。Google 即使在拥有完全控制的基础设施和统一的身份系统的情况下，也没有试图在 6 个月内”完成零信任迁移”。这个时间线本身就是对”零信任是一套产品可以快速部署”论点的反驳。

四、BeyondCorp 公开承认的限制

六篇论文并非只讲成功——它们也坦诚地记录了限制：

1. 不适合所有应用：实时协作应用（如 Google Docs 的实时编辑引擎）在访问代理后面运行会增加延迟。Google 没有为这些应用强制走访问代理，而是通过应用层自己的认证机制来补偿。
2. 遗留协议：依赖固定 IP 地址或网络层协议的遗留系统无法直接适配 BeyondCorp。Google 最终为这些系统保留了专用的网络出口，但在网络层严格限制它们的访问范围。
3. 不是所有人都能在 BeyondCorp 模型下工作：合同工、合作伙伴、被收购公司员工的设备不在 Google 的设备管理范围内——这些”非标”身份的管理在论文中被承认为一个未完全解决的问题。Google 的妥协方案是为这些用户生成临时凭证（有时间限制、功能受限），但承认这不是理想的解决方案。
4. 信任等级的粒度：三级信任模型（Untrusted / Basic / Trusted）比 VPN 的二元模型（能连/不能连）精细，但仍然是粗粒度的。同一等级内的设备没有任何差异化——一个”Trusted”等级的 macOS 设备和”Trusted”等级的 ChromeOS 设备在访问权限上没有区别。Google 承认这是有意简化的结果——更多的等级会增加策略管理复杂度和用户困惑。

五、与 NIST SP 800-207 的对照

最大的差异：NIST 的架构是”应该怎样”（规范），BeyondCorp 的论文是”实际怎样”（复盘）。两者不是竞争关系，而是互补关系——NIST 给出了评估框架，BeyondCorp 给出了在这个框架下运行 7 年的实际数据。

下一篇拆解 身份感知代理（IAP），看零信任入口的协议层细节。

参考资料

1. Ward, R. & Beyer, B. (2014). “BeyondCorp: A New Approach to Enterprise Security”. ;login:, Vol. 39, No. 6.
2. Osborn, B., McWilliams, J., Beyer, B., & Saltonstall, M. (2016). “BeyondCorp: Design to Deployment at Google”. ;login:, Vol. 41, No. 1.
3. Escobedo, V., Beyer, B., Saltonstall, M., & Peck, J. (2016). “BeyondCorp: The Access Proxy”. ;login:, Vol. 42, No. 4.
4. Spear, B., Beyer, B., Cittadini, L., & Saltonstall, M. (2017). “Migrating to BeyondCorp: Maintaining Productivity While Improving Security”. ;login:.
5. Zyzniewski, F. & Saltonstall, M. (2017). “BeyondCorp: The User Experience”. ;login:, Fall 2017.
6. Google BeyondCorp Team. (2018). “BeyondCorp: Building a Healthy Fleet”. ;login:.
7. Kindervag, J. (2010). No More Chewy Centers: Introducing The Zero Trust Model Of Information Security. Forrester Research.