一、概述

要成功实现现代化安全方案，联邦政府需共同努力，互相配合。2021年5月，总统发布了第14028号行政命令(14028)，即“改善国家网络安全”，要求整个政府通力合作，确保采取安全基线实践，推动联邦政府向零信任架构迁移，在降低风险的同时充分发挥云基础设施的安全优势。

二、目的

联邦零信任架构的战略构想如下：

• 在联邦各机构推广强大的身份验证实践；

• 依靠加密和应用测试，而非边界安全；

• 识别政府拥有的设备和资源；

• 支持安全操作的智能自动化；

• 确保安全可靠地使用云服务。

零信任战略并非旨在介绍或规定何为完全成熟的零信任实践，也不阻止机构采取上述之外的措施。该战略旨在为联邦机构制定统一路线图，采取必要的初步措施实现高度成熟的零信任架构。该战略指出，目前每个机构的成熟度不同，需确保在规定时间内采取行动的灵活性和敏捷性。该战略还希望通过在适当情况下呼吁整个政府部门共享服务，从而高效处理共同需求。

对于与联邦政府一样拥有各种复杂技术的机构而言，过渡到零信任架构并非易事，不可一蹴而就。不过，正如拜登总统在第14028号行政命令中提及的：“渐进式改进无法为满足我们的安全性需求。联邦政府需做出大胆的改变并投入大量资金为保障美国生活方式的重要机构提供保护。”

三、目标

虽然零信任架构的概念并非新鲜事物，但大多数机构，包括联邦机构，可能并不了解从“可信网络”迁移的影响。对联邦政府而言，这将是一个实现转变的过程，随着机构和政策逐步适应新的实践和技术，联邦政府也将进行学习和调整。

在零信任方面已有进展的机构需要与刚起步的部门合作，双方可开展信息、方案、人员方面的交流。机构的首席财务官、首席采购官和高管人员需与IT和安全管理人员合作，共同构建运营模式部署和维持零信任安全能力。

该战略鼓励各机构利用云基础设施提供的丰富的安全功能，同时确保机构的系统设计得当，为云系统的安全使用提供支持。各机构普遍预计，各机构将持续引入更多云基础设施和相关安全服务，所以该战略重点介绍了云服务。但该战略描述的行动还涉及本地部署和混合系统。

本备忘录将就在零信任架构迁移过程如何找到最合适的切入点为各机构提供指导。本文介绍了政府部门在长期的零信任架构迁移过程中涉及的几项重要的共享服务。

该战略只是一篇入门指导，而非完全成熟的零信任架构综合指南。

四、需采取的行动

（2）设备：联邦政府拥有其运营和授权供政府使用的所有设备的完整清单，并且能够检测和响应这些设备上的事件。

（3）网络：各机构对其环境中的所有DNS请求和HTTP通信进行加密，并开始围绕 其应用程序对网络进行分段。联邦政府确定了一个可行途径来加密传输中的电子邮件。

（4）应用程序：机构将所有应用程序视为互联网连接，定期对其应用程序进行严格测试，并采纳外部漏洞报告。

（5）数据：各机构正在采取一种清晰通用的方法部署保护措施，对数据进行完善的分级防护。各机构正在利用云安全服务监控敏感数据的访问，进行机构范围内的日志记录和信息共享。

第14028号行政命令要求各机构制定专属计划实现零信任架构。

各部门和机构须在本文件发布后60天内将本文件中的要求纳入其专属计划，向管理和预算办公室（OMB）提交2022-2024财年的实施计划和2023-2024财年的预算。各机构应在2022财年重新确定拨款优先次序，优先实现主要目标，或寻求其他资金来源，如：机构营运资本基金或技术现代化基金等。

各部门和机构须在本文件发布后30天内任命并确定零信任架构实施负责人。OMB将通过负责人进行各政府部门的协调工作，参与每个组织的规划和实施工作。

• 愿景

• 行动

• 需对机构工作人员、承包商和合作伙伴使用MFA。

• 须对公共用户使用反钓鱼攻击的MFA。

（3）各机构必须采用密码安全策略，根据已知泄露的数据检查密码。

• CISA将向机构提供一项或多项服务，可私下检查密码而不会泄露这些密码。

管理完善的身份验证系统是零信任架构的基础。若访问控制措施较弱，攻击者可通过账户接管在组织中获得立足点。同时，身份验证系统若过多会导致安全控制不一致，增加以可靠方式撤销整个机构的访问权限的难度。为确保持续提供强大的用户访问控制措施，各机构应整合身份验证系统，并根据需要整合本机构以及其他机构的访问权限。

随着联邦机构普遍使用MFA，他们的主要目标不仅局限于帮助用户防止凭据盗窃，还在于抵御自动执行的网络钓鱼攻击。本节介绍了面向政府的新的MFA实现基线，重点在于网络钓鱼防御。

该基线包含面向公众系统的最新MFA要求，即为公众提供更多选择。面向公众的系统和内部系统的安全性相互关联，如果反网络钓鱼的MFA普遍采用，则对每个用户而言都更加有效和可靠。不过，公共服务的普及至关重要，各机构需保持灵活性，确保目标用户可公平获得数字服务。

联邦机构要应对挑战，最简单的方法是使用精心设计的身份认证系统，并尽可能将该系统集成到该机构的更多应用程序中。许多大型机构的各种系统均需用户认证，为实现本文要求的一些更先进的防护措施，必须对身份认证系统进行整合。此外，本文涉及的其他零信任措施从功能上要求机构的SSO服务可在应用程序级别上集成。

机构须雇佣身份识别提供商，用户提供机构范围内的SSO服务，服务需可集成至应用程序和公共平台，并逐步淘汰其他身份验证系统。一般来说，用户只需登录一次就可访问机构的其他应用程序和平台。根据零信任和风险管理原则，机构还可添加额外身份验证要求或监控对更敏感应用程序的访问进行控制。SAML、OpenID Connect等此类SSO服务应利用开放性标准，还应可集成至外部运营的云服务和机构托管的应用程序。机构应审查其使用的全部应用程序，逐渐抛弃利用非SSO凭据的应用程序，转而采用机构主要的SSO服务。

各机构的最终目标应是利用单个身份认证系统为所有内部用户提供服务。机构可能存在多个部门或分支，他们可能需要使用自己的身份认证系统满足特殊的任务需要。当机构的某个部门需使用与其所属机构不同的身份认证系统时，该部门必须围绕单个身份认证系统进行整合。该身份认证系统必须能为访问其机构内其他身份认证系统的该部门用户的整合提供支持，而且必须接受整个机构的身份认证系统的联合身份。

MFA应在应用层集成，例如通过上述的机构SSO服务，而非通过VPN等网络认证。我们不应抱有这样的想法，从特定网络接入应用程序要比从公共网络连接的风险小。机构必须逐步降低对用户进行网络认证的重视程度，并最终取消网络认证。在成熟的零信任部署中，用户登录的是应用程序，而非网络。

MFA通常可阻止未授权帐户访问的通用手段，如猜测弱密码或复用从数据泄露中获得的密码。然而，大多数多重身份验证方法无法防护复杂的网络钓鱼攻击，这种攻击对官方应用程序进行欺骗，并与用户进行动态交互，显得非常令人信服。用户可能信以为真，提供一次性代码或对授予攻击者帐户访问权限的安全提示作出响应。攻击可以较低成本大规模自动化执行。

不过，令人欣慰的是，有些反钓鱼的MFA方法可抵御这些攻击。联邦政府的个人身份验证（PIV）标准就是其中一种方法，可帮助许多机构系统达到网络钓鱼防护基线。万维网联盟的开放式“Web认证”标准也是一种有效方法，现在，几乎所有主要的消费类设备和越来越多的主流云服务都支持该标准。任何其他验证协议若符合美国国家标准与技术研究院（NIST）SP 800-63B的“防冒充验证程序”的定义要求，也可抵御上述类型的网络钓鱼。

机构系统须要求内部用户利用反网络钓鱼的方式访问其帐户。对于机构工作人员、承包商和合作伙伴的日常自助访问，机构系统必须停止支持无法防御网络钓鱼的认证方式，例如，为SMS短信服务或语音通话注册电话号码、提供一次性代码或接收推送通知的协议等。

机构用户是网络钓鱼活动最主要的目标之一，所以非常有必要利用网络钓鱼协议，但是可为这些用户提供反钓鱼令牌，如PIV卡，并提供使用培训。对于许多机构系统来说，PIV或PIV衍生品是解决该需求的最简单方式。不过，机构的首要事项应是尽快提供反网络钓鱼的验证程序，例如PIV或WebAuthn等其他方法。

有时，紧急情况和人工辅助进行的账号恢复过程可能需要较弱的身份验证。但为防护非网络钓鱼攻击而进行的认证是例外情况，需得到首席信息官批准，进行充分监控，定期重新审核确定是否继续使用。

许多为公众提供服务的系统在向用户提供线上服务访问时无法利用防钓鱼认证的方法。政府在线服务的部分用户可能只能使用固话网络，而无法使用智能或非智能手机。

与此同时，在线公共服务是网络钓鱼攻击和账户接管的主要目标，许多用户希望政府服务提供防御工具。为了实现安全性和可用性之间的合理平衡，面向公众的政府系统需为用户提供更多身份验证方式。

为此，支持MFA的公共系统必须为用户提供反钓鱼身份验证方式。由于大多数人都没有PIV或CAC卡，各机构必须支持安全密钥等Web身份验证方式，满足网络钓鱼防护需求。

CISA将明确或向机构提供一项或多项服务，用于自行将用户密码与已知弱密码和泄露的数据进行比较，以免机构重复使用被盗凭据。应采用共享服务，确保其无法分辨哪些密码正处于检查中。对于希望对该功能采用新服务的机构，CISA应采取响应行动，跟上安全格局的演进步伐。CISA还应考虑使用政府官方电子邮件账户相关的账户外泄信息，确认相关政府系统当前是否在使用破解的密码。

机构的系统必须使用CISA已明确或提供的一项服务进行密码检查，确定用户是否使用了已知弱密码和破解的密码。由于机构不应明文存储密码，因此通常只能在用户创建帐户或登录等需要输入密码时进行比较。对于特别敏感的系统，机构应主动重置特权帐户的密码，确保进行密码检查。

• 愿景

• 行动

（2）机构必须确保每个手动操作的内部设备都安装有机构指定的端点检测和响应（EDR）工具。

• CISA将与各机构合作，填补EDR覆盖缺口。

• 各机构必须向CISA提供EDR数据的持续访问权限。

为实现零信任架构，各机构必须监控和评估其所有授权设备的安全态势。随着机构更多地使用云服务，他们的资产自然增多，在互联网络上的分布更广泛。

机构必须清楚自身在本地和云端的资产以及哪些地方存在漏洞，从而对其端点、服务器和其他重要技术资产的安全性进行监控和提升。

若云环境利用了提供丰富的细粒度功能的动态权限系统，上述情况尤其适合。CISA必须制定CDM计划，在本地支持物联网设备和联邦的云服务架构。

各机构应提前部署程序和技术设施，从而向CISA提供EDR工具报告的信息。该方法旨在确保整个政府采取各种各样的EDR工具，为不同技术环境的机构提供支持，同时确保提供联邦民用政府活动的全景概述。

• 愿景

• 行动

（2）机构必须对其环境中的全部Web和应用程序接口（API）流量采取HTTPS协议。

• CISA将与各机构合作，在Web浏览器中“预加载”.gov域，确保其仅可通过HTTPS访问。

（3）CISA将与联邦风险和授权管理计划（FedRAMP）共同评估MTA-STS是否可作为整个政府的电子邮件加密解决方案，并向OMB提出相应建议。

（4）各机构必须与CISA协商制定网络划分计划，并提交给OMB。

零信任架构的一个关键原则是对任何网络都不信任，任何流量均需加密和认证。正如第14028号行政命令指出，任何流量，包括内部流量，均需加密和认证，所有数据传输时也须加密。

近期，该战略重点关注DNS和HTTP流量。CISA和FedRAMP将评估MTA-STS是否能可靠地（且可能自动地）加密传输中的电子邮件。

随着各机构普遍对流量加密，他们一方面要确保网络监控深度，一方面又要不导致过大攻击面，需在二者之间寻求平衡。零信任的另一个关键原则是假设监控服务等任何组件都可能受到入侵。机构应尽量减少攻击者获得权限查看或修改流量的机会。

例如，机构应避免依赖具有过于广泛能力的静态密钥解密机构的流量，因为窃取该静态密钥会破坏整个机构的加密。各机构应在内部普遍利用最新版本的标准加密协议（如TLS 1.3），阻止批量解密。

这说明在实践中，正如NIST在SP 800-207中所述，有些位置的流量可能无法深入检测，但仍可使用可见元数据、机器学习技术和其他启发式技术检测异常活动，分析网络流量。有些地方需要深入的流量检测，很容易成为攻击面，攻击可对此采取主动代理，对其实现仅限工作所需的可见度和权限。

近年来，DNS请求加密标准已更新且广泛采用。机构现在可调整其DNS架构和相关监控，使其不断靠近零信任架构。

在技术支持的情况下，机构必须通过加密DNS处理DNS查询。这意味着机构的DNS解析器必须支持标准的DNS加密协议（基于HTTPS或TLS的DNS），且必须使用该工具与上游的DNS解析器通信。机构端点必须在配套的应用程序（如Web浏览器）和功能可用的操作系统中启用加密DNS。机构如果使用自定义开发的软件发起DNS请求，则必须支持加密的DNS。机构可通过访问特定的DNS解析器中的信息，持续识别和记录加密的DNS请求的内容。

各机构必须通过CISA运营的基础设施发送DNS请求。为支持机构安全的DNS流量，CISA的DNS防护产品将支持DNS加密通信，并进行扩展兼容机构的云基础设施和移动终端。

各机构必须对所有HTTP生产流量采取HTTPS，包括通过公共互联网传输的流量。OMB的M-15-13备忘录和第18-01行政命令要求各机构对联网系统强制实施HTTPS。现在机构必须对环境中所有的HTTP流量进行加密。

为确保以上加密，并加强.gov作为顶级域，各机构必须在Web浏览器中“预加载”所拥有的仅以HTTPS形式存在的.gov域。互联网域名在Web浏览器中“预加载”，使浏览器只能通过HTTPS使用这些域名获取服务。在客户端和域名侧采取HTTPS克带来显著的安全优势。自2020年以来，DotGov程序与Web浏览器协调配合，自动预加载所有新注册的.gov域。

不过，许多已有的.gov域名尚未预加载，最主要的障碍是有些内网网站使用了公共注册的.gov域名，而不支持HTTPS。随着各机构采用零信任架构时对内部流量进行加密，该障碍即将消除，各机构将能够安全地预加载域名，而无损害风险。

更普遍地说，.gov顶级域预示着最终预加载整个.gov域空间作为仅支持HTTPS的区域。这将促使美国各地利用.gov提供服务的政府机构提高安全性和零信任态势。然而，联邦机构会尽己之责加密内部的HTTP流量，尽可能减少损坏，从而过渡到零信任架构。

MTA-STS是一种非常有前景的开放性互联网标准，用于保护电子邮件传输安全，MTA-STS允许各机构在线发布政策，指示全球邮件服务器严格加密电子邮件。一些大型云电子邮件提供商采取了MTA-STS，但邮件中继之间的通信未广泛采用该标准，而且组织部署相关的安全策略时可能存在技术上的挑战。

CISA将对MTA-STS进行评估，明确该标准是否可用作政府范围的电子邮件加密解决方案，并向OMB提出建议，为政府的未来行动提供指导。评估过程中，CISA应与FedRAMP通力配合，召集云服务提供商和电子邮件生态系统中涉及的其他方共同商讨。此外，CISA还应明确是否可为.gov域注册人自动部署MTA-STS。

•  愿景

• 行动

• CISA将与美国联邦总务署（GSA）合作，促使公司快速采购。

（3）各机构必须制定有效且适宜的公共漏洞披露计划。

• CISA将提供漏洞披露平台，方便机构系统负责人直接接收报告并与安全研究人员沟通。

（4）各机构必须确定至少一种内部的FISMA中级应用程序，并使用机构SSO，通过公共互联网访问该应用程序。

（5）CISA将与GSA配合，向各机构提供在线应用程序和其他资产的数据。

• 各机构必须向CISA和GSA提供所使用的任何非.gov的主机名称。

零信任架构强调将保护措施部署时尽可能接近受保护的数据和操作。应用程序是联邦系统的前端攻击面，作为系统组件，通常被授权广泛的数据访问权限。

同时，机构不能依靠网络边界防护措施保护应用程序防止未经授权的访问。长远来看，根据CISA的零信任成熟度模型，机构预计将不再要求从特定网络访问应用程序。如上文“身份”一节所述，在应用层完成身份验证，而且应用程序通常通过公共互联网访问。短期内，每个应用程序都应视为可通过互联网访问。

一般来说，机构为保护应用程序不受攻击，需从攻击者的角度分析其应用程序。为此，需与外部合作伙伴配合，从独立视角评估机构的应用程序的实际安全性，并参阅公众共同对漏洞的披露。

为做好该项工作，政府必须充分了解机构目前有哪些在线应用程序。这需要利用互联网和外界进行现实检查，发现系统和遗漏的漏洞。

例如，在Web表单页面运行扫描器检测常见配置错误，可能起到一定作用，但该表单的安全性不足以令人信服。要进行更深入的测试，可尝试提交精心构造的无效数据，还可以检查客户端与服务器的验证逻辑是否一致。

机构系统的授权过程必须利用自动化分析工具和专家分析。为了解机构在授权前对应用程序的安全分析深度，OMB可随时要求机构提供应用程序的最新安全评估。各机构预计将逐步实现持续监测和授权，同时随着应用程序的发展，需要定期进行人工安全评估。各机构必须利用这些方法对SAR漏洞进行优先级排序并解决这些漏洞。

根据第14028条行政命令的指示，NIST制定了软件开发人员验证指南，各机构在制定应用程序测试计划时应参考该指南。NIST的指南描述了各类应用程序的通用基线，但并未涉及专业测试。除了评估应用程序的常见问题，各机构还需专家对其应用程序进行专业分析。

对于运营的每个在线系统，机构必须采用外部漏洞报告，构建上报渠道，方便系统负责人能够直接实时访问新的漏洞报告。

CISA发布了漏洞披露平台，方便联邦机构通过该平台接收漏洞信息，进行分类，以及直接与安全研究人员沟通。

为了避免出现任何问题阻止云的安全部署，FedRAMP将与云平台提供商通力配合，确认是否授权联邦机构的用户对提供商平台上客户运营的应用程序和基础设施进行漏洞测试。

为了推动这项工作并在零信任部署早期发现任何障碍，机构必须选择至少一个需要认证且当前无法接入互联网的FISMA中级系统，使其接入互联网。这将要求各机构构建最小可行化监测基础设施，并执行政策，提供安全的互联网接入。这一过程还应涉及与整个机构的单点登录系统集成，如上文“身份”一节所述。各机构可能会发现为了建立对其控制和流程的信心，可先在FISMA低级系统上实现这一转变，然后再在FISMA中级系统上部署零信任。

为协助机构，CISA将向机构提供CISA和GSA通过公共和私人来源发现的可接入互联网的资产的数据。CISA和GSA将通过互联网扫描查阅公共和商业数据，并在必要时自行进行扫描。CISA和GSA还将查阅其他权威的数据源，如.gov域名注册和DNS请求日志。

通过运营.gov域名，CISA可访问每个机构注册的.gov域名的权威完整列表，但无法了解该机构对非.gov域名的使用情况。GSA运营一款网站扫描服务，对各种有用的属性进行评估，并依赖CISA和GSA共同维护的开源软件。GSA也一直在跟踪联邦的非政府网站的Web URL的使用情况，但机构自行决定参与一些GSA工作，数据仅限于网站。

为了协助CISA和GSA，各机构必须向CISA和GSA持续提供可接入互联网的信息系统使用的任何非.gov主机名。CISA和GSA将与各机构合作，双方就制定高效的可持续性流程达成一致，尽量减少所有参与者的手动操作，确保长期数据质量，从而满足需求。

• 愿景

• 行动

（3）机构必须对商业云基础设施中的静态加密数据的访问进行审计。

（4）如OMB备忘录M-21-31所述，各机构必须与CISA协作，实现全面的日志记录和信息共享能力。

为确保参与应对这一挑战并取得进展，联邦首席数据官（CDO）委员会和联邦首席信息安全官（CISO）委员会将为联邦机构成立一个零信任数据安全联合委员会，由OMB担任主席。该委员会将为联邦机构制定一份数据分类和保护指南，监督实践社区，协助机构解决特定领域的问题。

同时，为了能够基于数据自动上报安全事件，用于编排和权限管理的系统将需要关于受保护数据类型的各类丰富信息。

各机构应努力采用基于机器学习的启发式方法来检测异常行为或对在整个机构中使用的数据进行分类。然而，机器学习模型可能不透明且调试复杂。要对利用机器学习的软件进行监督和配置需要专门技能，需投入一定的时间开发。

短期内，各机构将需要明确数据敏感性分类和安全自动化的前期备选方案，这些方案不需要机器学习即可发挥作用，可使用较为简单的技术方法（如脚本或正则表达式）实现。

任何自动化行动应首先以“仅报告”模式实现。也就是说，在启用任何可能影响员工工作流程的安全行动之前，机构安全团队应对启发式方法的性能和分类准确性进行监控。

首先，各机构必须通过其首席数据官为其敏感文档制定一套初始分类，并自动监控并可能限制这些文档的共享方式。这些分类预计通过手动制定，不要求很完整，但既要足够广泛确保有用性，同时又要非常具体，确保可靠准确。例如，若对采购敏感的文档使用标准模板，机构可尝试检测该模板何时使用。当通过协作工具共享文档或通过电子邮件发送文档时，机构可监测该文档是否可能存在过度共享。根据文档的特征和机构协作套件中的功能，机构可能会自动限制该文档的查看权限。

当加密云中存储的数据时，机构必须使用独立运营的密钥管理工具生成该数据访问相关的可信审计日志。为此，可利用云提供商运营的关键管理工具或者机构控制的云环境的内外部关键管理工具。无论哪种情况，对关键管理工具及其审计日志的访问必须与正在记录其活动的应用程序隔离。这一要求不适用于本地环境中的加密数据，因为这些环境中缺乏一直可用的第三方组件，这些组件若具备高可信性可防御机构遭遇的入侵。

在后期成熟阶段，机构可将这些审计日志与其他事件数据来源相结合，采用更复杂的方法进行安全监控。例如，机构可将数据访问时间与用户发起事件的时间进行比较，确定哪些数据库访问不是由正常应用程序的活动引起的。

为了帮助机构确定其工作的优先级，备忘录M-21-31构建了一个分层成熟度模型，指导机构解决需求。该成熟度模型旨在帮助机构在满足各种实现需求、日志分类、SOC运营改进和集中访问之间达成平衡。

机构必须达到备忘录M-21-31中所述的第一个事件记录成熟度（IL1）。这些机构的其中一项首要任务是采取日志完整性措施，限制访问和实现密码验证，并记录整个环境中的DNS请求。