index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html
![]()
本文深入解读了美国管理和预算办公室发布的《联邦政府零信任战略》正式版，对比了草案与正式版的目录结构差异，并重点分析了关键内容的变化。文章详细介绍了任务矩阵，该矩阵为各政府机构实施零信任提供了具体的行动计划和时间表，体现了该战略的实际推动力。此外，文章还探讨了身份验证、网络安全、应用和数据安全等方面的具体要求，为读者提供了全面的视角。
🔑 正式版与草案相比，目录结构差异不大，但内容层面有显著变化，例如单点登录（SSO）被集中式身份管理系统取代，并增加了用户授权要求。
🛡️ 网络安全方面，正式版强调了网络可见性和攻击面的重要性，并建议限制对加密流量的解密和检查，深度检查更适用于敏感数据环境。
💻 应用和工作负载方面，正式版引入了不可变工作负载的概念，强调其在支持零信任目标方面的优势，鼓励机构采用。
🗓️ 任务矩阵是正式版的核心，它明确了美国联邦政府对零信任的五大支柱的具体要求和时间表，其中60天内提交实施计划和预算估算的要求具有重要意义。
🔑 口令策略方面，正式版取消了对特殊字符和定期轮换口令的要求，反映了对用户体验和实际安全性的综合考量。
2022年1月26日，美国
管理和预算办公室（OMB）发布《联邦政府零信任战略》（Federal Zero Trust Strategy）正式版。这是继2021年9月7日
发布《联邦政府零信任战略》
草案之后的重要进展。
联邦政府零信任战略以备忘录的方式发布，备忘录的全称是：OMB
M-22-09 《推动美国政府走向零信任网络安全原则》（Moving the U.S. Government Toward Zero Trust Cybersecurity Principles）。
在之前的微信文章
《美国联邦政府零信任战略》中，笔者已经概述了《联邦政府零信任战略》草案的内容要点。本文中，则主要对两个版本的目录结构进行了对比，解释了几个重要的变化，并展示了最大的变化——
任务矩阵（Task Matrix）。该任务矩阵对各个政府机构实施零信任的具体行动做出了
计划安排，体现了真正的
推动力。本文件的PDF文档有
29页，译文大概2万字。原文链接：
https://zerotrust.cyber.gov/federal-zero-trust-strategy/
1.目录对比
2.内容差异
3.任务矩阵
图1-《联邦政府零信任战略》（Federal Zero Trust Strategy）正式版发布的网站截图
01目录对比
以下是两个版本的目录。笔者分别使用蓝色和绿色，标记了草案目录和正式版目录的主要区别：
草案目录：
1. 概述
2. 目的
3. 目标
3.1 身份
3.1.1 愿景 3.1.2 行动 1. 企业范围的身份 2. 多因素认证，抵御网络钓鱼 3. 面向公众的身份验证 4. 使用强口令策略 3.2 设备
3.2.1 愿景
3.2.2 行动
1. 盘点资产
2. 政府范围的EDR（端点检测和响应）
3.3 网络
3.3.1 愿景
3.3.2 行动
1. 加密 DNS 流量
2. 加密 HTTP 流量
3. 加密电子邮件流量
4. 围绕应用程序，分段网络
3.4 应用
3.4.1 愿景
3.4.2 行动
1. 应用安全测试
2. 容易获得的第三方测试
3. 欢迎应用漏洞报告
4. 安全地使应用程序可访问互联网
5. 发现可上网的应用程序
3.5 数据
3.5.1 愿景
3.5.2 行动
1. 联邦数据安全策略
2. 自动化安全响应
3. 审计对云中敏感数据的访问
4. 及时获取日志
附录. 参考资料
正式版目录：1. 概述2. 执行摘要3. 行动 3.1 身份 3.1.1 愿景 3.1.2 行动 1. 企业范围的身份系统 2. 多因素认证 3. 用户授权 3.2 设备 3.2.1 愿景 3.2.1 行动 1. 盘点资产 2. 政府范围的EDR（端点检测和响应） 3.3 网络 3.3.1 愿景 3.3.1 行动 1. 网络可见性和攻击面 2. 加密 DNS 流量 3. 加密 HTTP 流量 4. 加密电子邮件流量 5. 企业范围的架构和隔离策略 3.4 应用和工作负载 3.4.1 愿景 3.4.1 行动 1. 应用安全测试 2. 容易获得的第三方测试 3. 欢迎应用漏洞报告 4. 安全地使应用程序可访问互联网 5. 发现可访问 Internet 的应用程序 6. 不可变的工作负载 3.5 数据 3.5.1 愿景 3.5.1 行动 1. 联邦数据安全策略 2. 自动化安全响应 3. 审核对云中敏感数据的访问 4. 及时获取日志 3.6 OMB 政策对齐 1. OMB M-21-07：IPv6 和零信任 2. OMB M-19-17：PIV 和非 PIV 身份验证器 3. OMB M-19-26 和 OMB M-21-31：网络检查的替代方案 4. OMB M-15-13：用于内部连接的HTTPS附录A. 参考资料附录B. 任务矩阵（Task Matrix）
02内容差异
经过对比，主要的发现是：目录级别的差异并不大：差异反映在蓝色和绿色标记的地方；文字级别有大量的变化：尽管如此，但很多的文字变化，要么是改变了描述方式，要么是移动了位置，并无实质性的变化。
总体上看，两个版本的差别并不大。比较显著的变化包括：
1）在身份支柱方面，草案中一再强调的单点登录（SSO），在正式版中被完全抹除。比如草案中的要求"机构必须为机构用户建立单点登录 (SSO) 服务"，在正式版中被替换成"机构必须为机构用户采用集中式身份管理系统"。2）在身份支柱方面，正式版中增加了用户授权要求。指出目前联邦政府中的许多授权模型都侧重于RBAC（基于角色的访问控制），应该采取RBAC与ABAC（基于属性的访问控制）相结合的方式。3）在网络支柱方面，正式版中增加了关于网络可见性和攻击面的讨论。强调了权衡网络流量监控深度的观点：即随着零信任的普遍实施，大量流量将被加密。那么，对加密流量执行解密和检查，应该被限制在最低限度。而深度流量检查更适合保护敏感数据并具有少量预期网络客户端的应用程序环境。4）在应用和工作负载支柱方面，正式版中增加了不可变工作负载的内容。强调基于云的自动化、不可变部署方式，由于具有天然的最小权限特性，可以很好地支持零信任目标。所以，机构在部署服务时，应努力采用不可变的工作负载。5）正式版中增加了任务矩阵（Task Matrix）。在下面进一步描述。
02任务矩阵
正式版附录B中的任务矩阵如下：部分任务机构行动时间表（最后期限自本备忘录发布日期起）全体各机构必须向OMB和CISA提交一份22-24财年的实施计划，供OMB批准，并提交一份23-24财年的预算估算。60天内。身份机构必须为机构用户使用集中的身份管理系统，这些系统可以集成到应用程序和通用平台中。纳入机构实施计划。身份机构必须要求其用户使用防网络钓鱼方法，来访问机构托管的帐户。纳入机构实施计划。身份支持MFA的面向公众的机构系统，必须允许用户选择使用防钓鱼认证。一年之内。身份机构必须从所有系统中删除要求特殊字符和定期口令轮换的口令策略。一年之内。身份机构授权系统应将至少一个设备级信号与认证用户的身份信息结合起来。纳入机构实施计划。设备各机构必须建立持续、可靠和完整的资产清单，包括利用CDM项目。纳入机构实施计划。设备各机构必须确保其EDR工具符合CISA的技术要求，并在其机构内部署和运行。见M-22-01。设备各机构必须与CISA合作，以识别差距，协调部署，并与CISA建立信息共享能力，如M-22-01中所述。见M-22-01。网络在技术支持的任何地方，机构都必须使用加密的DNS，解析DNS查询。纳入机构实施计划。网络机构必须对所有生产HTTP流量，强制执行经过身份验证的HTTPS，包括不穿越公共互联网的流量。纳入机构实施计划。网络各机构必须与CISA的DotGov项目合作，在web浏览器中以仅HTTPS的形式“预加载”机构所有的.gov域名。纳入机构实施计划。网络各机构必须与CISA协商，制定零信任架构计划，描述机构计划如何隔离其应用程序和环境，并将其纳入本备忘录要求的全面实施和投资计划。纳入机构实施计划。应用程序和工作负载机构系统授权过程必须采用自动分析工具和手动专家分析。纳入机构实施计划。应用程序和工作负载机构必须欢迎其互联网接入系统的外部漏洞报告。2022年9月，与OMB M-20-32和BOD 20-01保持一致。应用程序和工作负载机构必须选择至少一个需要认证且目前无法通过互联网访问的FISMA中级系统，并安全地允许其在互联网上进行全功能运行。一年之内。应用程序和工作负载各机构必须开始向CISA和GSA提供其互联网可访问信息系统使用的任何.gov主机名。60天内。应用程序和工作负载机构在部署服务时，尤其是在基于云的基础设施中，应该努力使用不可变工作负载。纳入机构实施计划。数据机构首席数据官必须与关键机构利益干系人合作，为其企业内的敏感电子文档制定一套初始分级分类，目的是自动监控并可以限制这些文档的共享方式。120天内。
该矩阵的重要性在于，它高度浓缩了美国联邦政府对零信任的5个支柱（身份、设备、网络、应用和负载、数据）的具体要求，同时做出了明确的时间进度安排，具有实实在在的推动力。其中，最重要的一条是：各机构必须在60天内，提交一份22-24财年的零信任实施计划和一份23-24财年的零信任预算估算。
另外，在身份方面，比较有趣的一点是：口令策略不得要求使用特殊字符或定期轮换。之所以会提出这个要求，是因为美国研究人员在关于密码过期策略影响的定量研究论文中，发现定期轮换口令极度影响用户体验，但又不能切实提高口令安全性。作为每隔几个月就被逼迫修改系统登录口令的切实感受者，笔者深深地赞同这一点。
（本篇完）
