NIST 令牌安全指南将责任转移给云服务提供商和机构
在被盗凭证暴露出仅靠密码和多因素身份验证无法解决的弱点后，NIST 于 2026 年 9 月 15 日最终确定了新的令牌安全指南。NIST IR 8587 与 CISA 联合制定，针对的是支撑云访问、联合身份验证和单点登录的已签名令牌及身份断言。
这份报告以一种重要方式改变了安全讨论。有效签名已不足以成为授予访问权限的充分依据。机构和云服务提供商还必须验证令牌的来源、可访问的资源、过期时间，以及其行为是否存在可疑迹象。
这一要求直接回应了 Storm-0558 等事件。Microsoft 发现，该威胁行为者利用被盗签名密钥伪造令牌并进入电子邮件账户。NIST 表示，这次攻击活动导致某联邦机构超过 60,000 封电子邮件被窃取。
因此，核心矛盾在于共同责任与控制分散之间。云服务提供商签发令牌并运营核心身份基础设施。机构则配置访问策略、连接多个环境，并利用提供商开放的遥测数据调查活动。
NIST IR 8587 试图弥合这些责任之间的空白。其建议涵盖签名密钥隔离、令牌验证、撤销、工作负载身份、日志记录和持续监控。它们最直接适用于联邦系统，但 NIST 表示商业组织同样可以采用。
NIST 令牌安全指南不再止步于有效签名
NIST IR 8587 将正确签名的令牌视为一项安全信号，而非访问请求可信的最终证明。
这份最终报告聚焦于使用非对称签名令牌和断言的系统，其中包括 Security Assertion Markup Language、OpenID Connect 和基于 OAuth 的部署。
断言会将身份验证信息从身份提供商传递给另一套系统。访问令牌则代表使用特定资源或执行已定义操作的授权。这两者都能让用户和服务跨越安全边界，而无需反复提供密码。
这种效率使其成为单点登录、云 API、联合身份验证和机器间访问的关键组成部分，也使其成为颇具吸引力的攻击目标。攻击者若窃取可重复使用的令牌，便可继承其权限，无需攻破原始身份验证流程。
签名密钥遭到泄露会造成更严重的问题。它可能让攻击者创建在信任该密钥的系统看来合法的新令牌。除非应用进一步检查，否则这些系统可能会接受伪造的身份、权限和过期数据。
因此，NIST 令牌安全指南要求依赖方验证的内容不能仅限于加密签名。依赖方是负责作出访问决策的应用或服务。它必须确认令牌的完整性、来源、范围、有效性和预期使用环境。
令牌还应包含明确的受众限制。受众指明允许接受该令牌的应用、服务或安全域。访问控制必须拒绝缺少受众值或受众值错误的凭证。
这一要求限制了横向移动。为某一应用签发的令牌不应成为访问无关服务的通用凭证。同一原则也适用于不同租户、环境和云边界之间。
NIST 还要求签名密钥应具有合理情况下最窄的作用范围。提供商可以按租户、客户群组或运行环境将其隔离。开发和测试密钥不应继续在生产环境中有效。
在联邦授权环境之外使用的密钥，不应对这些环境内可接受的凭证进行签名。例外情况需要存在有意建立的联合身份关系以及适当的信任协议。
这些措施旨在应对联合系统的一项危险特性：一个受损组件可能影响所有信任其输出的服务。缩小作用范围可减少密钥或令牌被盗时受影响的系统数量。
报告还区分了无状态和有状态访问架构。有状态系统维护集中式会话信息，因此可以直接撤销会话。无状态系统则将所需信息封装在由应用本地验证的已签名令牌中。
无状态令牌适用于分布式服务和高流量 API。但由于独立于中央会话存储，它们可能更难立即撤销。较短的有效期、受限使用和持续评估有助于控制这一弱点。
NIST 并未要求组织放弃已签名令牌。它是在界定：当这些令牌成为分布式企业中可携带的权限时，周边必须具备哪些控制措施。
一把被盗密钥如何让云端信任成为攻击路径
Storm-0558 表明，若系统接受利用已泄露签名密钥伪造的凭证，强大的用户身份验证也无法保护该系统。
Microsoft 在调查客户电子邮件遭未经授权访问后，于 2023 年 7 月披露了这一事件。其Storm-0558 分析描述了一名行为者如何使用伪造的身份验证令牌访问 Outlook Web Access 和 Outlook.com。
攻击者获得了一把 Microsoft 账户消费者签名密钥，并利用它伪造令牌。随后，验证缺陷使消费者签名的令牌得以进入企业电子邮件系统。这一组合跨越了本应隔离消费者与企业身份的边界。
NIST 引用这一事件，是因为它揭示了多个相互关联的失效环节。该密钥价值极高、潜在作用范围广泛，而依赖系统接受了伪造凭证。调查人员还需要适当的日志，才能识别受影响的账户和操作。
这次入侵并非始于猜测数千个密码，而是攻击了决定应用应信任哪些身份的机制。一旦该机制接受了伪造令牌，常规身份验证控制所能提供的保护便十分有限。
这正是 NIST IR 8587 背后的反转。单点登录减少了重复登录带来的暴露，并集中化了访问管理。然而，同样的集中式信任也会放大签名系统遭泄露的后果。
NIST 的应对措施首先是加密密钥保护。中等影响级别系统必须为签名密钥使用基于硬件、硬件支持或其他隔离式存储。应用、虚拟机、服务器和容器不得持久存储这些密钥。
可接受的机制包括硬件安全模块、安全处理器、云密钥管理系统和隔离的密钥管理服务。这些系统将密钥材料与请求加密操作的工作负载分离。
高影响级别系统面临更严格的要求。它们必须在隔离的执行环境中同时保护存储的密钥和签名操作。受损主机或管理员账户不应自动暴露签名功能。
可能的实现方式包括硬件安全模块、安全协处理器、机密计算环境和远程签名服务。正确选择取决于系统影响级别、运营限制和提供商的架构。
隔离并不能解决所有问题。攻击者可能在不提取私钥的情况下滥用已获授权的签名接口。因此，提供商还必须限制谁能够请求签名、记录这些请求，并监控异常签名活动。
密钥轮换也需要运营规划。更换签名密钥会影响每一个验证其输出的系统。提供商需要进行受控分发、在必要时设置重叠期，并为受损密钥建立快速撤销程序。
这在可用性与遏制之间形成了张力。仓促轮换可能中断合法服务，而延迟轮换则会让伪造凭证更长时间保持可用。
NIST 在最终版本中避免规定统一的密钥有效期，而是采用与风险和组织能力挂钩的结果导向方法。发布摘要称，这一变化源于对 2025 年 12 月草案的公开反馈。
最终指南还扩展了有关密钥使用、存储和保护的建议。它为组织提供了更多灵活性，但这种灵活性也将判断责任重新交给安全和架构团队。
提供商不能仅因拥有 HSM 就声称合规。机构仍需获得证据，证明密钥的作用范围、签名接口、授权规则、轮换流程和审计记录符合受保护系统的风险水平。
共同责任如今需要共同证据
该报告敦促云服务提供商开放安全能力，并要求机构进行配置、监控和测试，而不是假定保护会自动生效。
云服务提供商通常控制物理基础设施、核心身份服务、令牌签发、签名系统、密钥库和基础设施级监控。机构通常控制 IAM 策略、用户访问、应用密钥、会话设置和应用日志。
若干职责仍属共同责任。NIST 将事件响应、持续监控、用户教育和令牌撤销列为需要协调的领域。实际边界因服务模式、合同和开放的技术能力而异。
这并非整齐的责任划分。软件即服务客户无法检查每一套内部签名系统。提供商也无法确定每个机构的任务敏感度，或决定哪些用户应访问某一特定记录。
NIST 通过四项提供商原则应对这种不匹配：安全设计、透明度、可配置性和互操作性。每项原则都让机构对自己无法直接运营的控制措施拥有更多影响力。
透明度要求提供足够的架构信息和系统数据，使消费者能够作出明智决策。它还要求为令牌相关事件、安全发现和事件响应建立沟通渠道。
可配置性让消费者能够根据自身风险调整控制措施。例如，加强监控、缩短会话、收紧访问策略或增加提供商服务。NIST 建议默认提供得到广泛认可的保护措施。
互操作性支持在混合云和多云环境中采用一致的控制措施。OpenID Connect、OAuth 和 SAML 等标准可减少对自定义集成的依赖，也让获批系统之间更容易交换身份数据。
标准并不保证部署安全。格式正确的 OAuth 令牌仍可能拥有过多权限或不恰当的有效期。若依赖方忽视唯一性检查，有效的 SAML 断言仍可能被重放。
因此，机构仍承担多项直接责任。它们必须进行风险评估、选择并定制控制措施、记录令牌管理策略，并按照自身的保障要求配置云环境。
所需文档涵盖令牌生命周期、验证流程、密钥管理、日志记录、撤销、会话管理和事件响应。机构和服务提供商还必须记录其支持的协议和令牌内容。
这些文档并非脱离运营的文书工作。它界定了令牌暴露时响应人员所需的信息。团队应当已经了解哪些系统信任该令牌、哪些日志包含相关活动，以及撤销操作如何传达至连接的服务。
NIST 将这些职责与其更广泛的控制目录相联系，尤其是身份提供商、授权服务器、加密密钥和令牌管理相关的控制措施。该报告将这些控制措施转化为实施考量。
最终发布文件支持第 14306 号行政命令。不过，除非政策、合同、拨款或其他具有约束力的协议将具体条款规定为强制要求，否则遵从仍属自愿。
这一限制至关重要。NIST 令牌安全指南能够影响采购和评估，但不会自动改变已部署的系统。机构需要将预期成果转化为合同条款、技术要求和验收测试。
云服务提供商面临相关挑战。支持某项控制措施，并不意味着客户已经启用它。提供商需要提供安全默认设置、易于使用的配置路径，以及客户无需定制开发即可集成的遥测数据。
采购团队应直接提问。客户能否按租户限制签名密钥？能否跨服务撤销活跃会话？令牌事件是否可实时获取？服务是否能够识别缺失的受众限制？
他们也应测试这些回答。文档可以描述某项功能，却无法证明它能在每一条身份路径中正常运行。联邦身份网关、遗留应用、移动客户端和自动化工作负载的行为都可能不同。
因此，该报告将共同责任转化为共同证据。双方都需要可验证的记录，说明由谁配置了控制措施、其运行方式，以及发生泄露时会如何处置。
令牌生命周期成为主要遏制机制
当组织无法阻止每一次窃取时，它们必须缩短失窃令牌的有效时间，并限制攻击者可重放令牌的范围。
令牌管理始于签发。身份提供商和授权服务器应为明确的主体、受众、范围和有效期签发凭证。依赖应用必须在每次访问决策中执行这些限制。
OAuth 范围描述用户或应用可以执行的操作。狭窄的范围有助于实现最小权限，因为它限制了单个令牌携带的权限。细粒度授权可进一步降低暴露风险。
有效期带来运营权衡。长生命周期令牌可减少身份验证流量和用户中断，但也让攻击者有更多时间重复使用失窃凭证。
短生命周期访问令牌可缩短这一窗口。不过，刷新令牌可以通过请求新的访问令牌来延长会话。因此，这些刷新令牌需要强大的存储、轮换和撤销控制。
NIST 建议在可行时使用发送方约束令牌。发送方约束会在加密层面将令牌绑定到特定客户端或密钥。仅持有令牌本身不足以让攻击者从其他系统重放它。
报告提到两种方法。双向 TLS 将令牌使用绑定到客户端证书。持有证明（Demonstrating Proof of Possession，DPoP）则使用客户端生成的密钥和已签名证明来处理 HTTP 请求。
相关的DPoP 标准描述了授权服务器如何将令牌绑定至公钥。资源服务器随后可验证请求者是否控制相应的私钥。
发送方约束会提高实施成本。客户端需要安全的密钥处理，服务需要兼容的验证能力，而分布式环境需要可靠的元数据。遗留应用可能不支持所需协议。
报告并未假装这些约束能立即适用于每个系统。它建议在可行时采用，尤其适用于工作负载身份和高风险访问。
工作负载身份包括软件服务、自动化流程及其他非个人实体。随着企业连接 API、部署流水线、云函数和 AI agents，其数量正在增长。
NIST 表示，工作负载必须通过获批准的身份平台使用权限范围严格、生命周期短的令牌。它不鼓励使用在被复制后仍然有效的长生命周期静态凭证。
报告还强调了基于 SPIFFE 的身份。SPIFFE 通过受信任的控制平面向工作负载提供可通过加密验证的身份证明文件。凭证可以自动轮换，并始终绑定到特定工作负载。
这种方式改变了机密管理。应用会在运行时获取临时凭证，而不是将其嵌入源代码、容器镜像或配置文件。
NIST 将同样的逻辑应用于构建流水线。令牌不得出现在日志、控制台输出、缓存或部署工件中。流水线应从获批准的系统获取机密，并仅在需要时注入。
一旦检测到暴露，就应触发事件响应。团队不应认为从原始日志中删除令牌即可消除威胁。副本可能已经存在于日志聚合器、备份、开发者工具或第三方集成中。
受众限制提供了另一层遏制措施。即使两个服务都信任同一身份提供商，为一个 API 签发的访问令牌也必须在另一个 API 上失效。
唯一令牌标识符也有助于检测重放。依赖系统可以识别重复提交的凭证，而这类凭证原本应只支持一次交易。当提供商保留适当的事件记录时，这一做法更有价值。
在无状态架构中，撤销仍然更困难。自包含令牌在过期前可以持续通过本地验证。系统需要借助撤销列表、内省、共享事件信号或短生命周期来缩短这一间隔。
最终报告增加了对当前和新兴撤销方法的更多引用。它没有选择一种通用协议，因为企业架构和可用性要求各不相同。
这种灵活性是合理的，但也带来了可衡量的要求。每个组织都需要确定其能够多快地在所有依赖服务中使令牌失效。耗时数小时的撤销流程会留下巨大的事件窗口。
团队还需要测试故障条件。他们应了解当身份提供商、撤销服务或密钥分发端点不可用时，应用会如何运行。安全控制不能悄然以失效开放模式运行。
检测必须跨越云边界追踪令牌
预防措施保护密钥和凭证，而检测能力决定了防御人员能否在失窃令牌过期前识别滥用行为。
NIST 表示，身份控制绝不应成为“一劳永逸”的配置。服务提供商和机构需要持续监控每一个签发、验证、使用或代表令牌的系统。
有用的信号包括地理位置、设备信息、请求速度、访问时间和资源选择。没有任何一项单独能够证明发生了泄露，但关联分析可以揭示与该身份正常模式相冲突的行为。
在不可能的时间间隔内从两个相距遥远的位置使用的令牌，值得仔细审查。来自未经批准网络的工作负载凭证，或请求超出其通常角色范围的资源，也同样如此。
NIST 建议身份提供商与依赖方之间共享安全信号。OpenID 持续访问评估可以传达影响连接服务中活跃会话的事件。
这类事件可包括账户停用、凭证变更、会话风险上升或其他安全状况。接收系统可在原始令牌达到正常过期时间之前重新评估访问权限。
报告还要求令牌数据采用安全信息与事件管理系统可使用的格式。相关信息可输入行为分析、云保护平台及其他检测工具。
该要求针对云事件中反复出现的问题。某机构可能控制受影响账户，却无法看见服务提供商的身份基础设施。提供商可能检测到异常活动，却不了解该机构的任务背景。
关联分析需要双方的数据。提供商日志可以显示令牌签发、密钥使用和基础设施事件。机构日志则可以显示应用活动、授权结果及对敏感记录的访问。
NIST 建议为令牌和断言事件保存防篡改记录。有用的元素包括时间戳、令牌标识符、签发者、主体、受众、客户端、验证结果和撤销活动。
记录每一个令牌值会制造新的安全问题。原始持有者令牌不得出现在日志中，因为任何获得它们的人都可能重放它们。系统应记录安全的标识符和相关属性。
保留期限同样重要。组织无法调查发生在其可用日志之前的入侵。合同和配置应使保留期与机构的检测和报告需求相一致。
可扩展性挑战十分显著。大型云环境可能产生海量身份验证和 API 事件。在缺乏优先级的情况下收集一切，可能淹没真正有意义的信号。
机构需要与实际滥用情形相关联的检测规则，包括意外的受众值、来自未经批准签发者的令牌、重复的令牌标识符、异常的刷新活动，以及正常模式之外的签名操作。
提供商应持续一致地提供这些字段。专有格式会增加跨云关联事件所需的工作量，也会在机构在分析平台之间迁移数据时使事件响应更加复杂。
NIST 令牌安全指南并未定义一种单一的检测架构。它描述了系统应支持的结果和事件关系。组织仍必须围绕这些能力建立运营流程。
这项工作包括指定告警责任归属。如果没有团队有权撤销令牌、隔离账户或联系服务提供商，再准确的技术告警也价值有限。
安全团队还需要有文档化的调查背景。在事件期间，可搜索的工程知识库可以保留架构决策、信任关系和响应程序，以便随时查阅。
更广泛的经验是，身份遥测必须随身份信任一同流动。如果令牌能够跨服务和云边界流转，调查它所需的证据也必须跨越这些边界。
最终指南仍面临三项考验
该报告确立了基线，但采购执行、撤销性能和机器身份的采用情况将决定其实际影响。
首先值得关注的信号是，联邦机构将如何把 NIST IR 8587 转化为合同和服务要求。除非其他授权机制使具体条款具有约束力，否则遵从仍属自愿。
采购语言可以增强报告的影响力。机构可要求隔离的签名操作、租户范围限定的密钥、可互操作的日志、经过测试的撤销机制以及事件通知，并可在授权审查期间要求提供证据。
缺乏合同层面的采纳将削弱这些指导意见。服务提供商可能支持部分能力，却未能始终如一地向客户开放。届时，机构仍可能依赖手动替代方案和提供商专属工具。
第二项信号是在联邦和多云环境中测得的撤销时间。组织应确定：响应人员启动遏制措施后，已泄露的令牌还会在多长时间内被接受。
更短且经过一致测试的撤销时间将支持 NIST 的方法。文档所述性能与实际观测表现之间若存在较大差异，则会暴露依赖应用、事件传递或身份提供商集成中的缺口。
这项测量还应涵盖刷新令牌和活跃会话。如果另一凭证能够立即铸造替代令牌，撤销访问令牌提供的保护将十分有限。
第三项信号是短生命周期、发送方约束型工作负载身份的采用程度。自动化服务如今使用令牌的规模，已超出人工密钥管理能够可靠治理的范围。
更广泛地使用双向 TLS、DPoP、SPIFFE 和托管工作负载身份，将减少对复制的静态凭证的依赖。采用缓慢则会使流水线、容器和与 AI 连接的服务面临重放攻击风险。
AI 代理让这个问题更为紧迫。NIST 增加了高层级指导，因为代理正日益以委托权限调用工具、数据服务和 API。报告明确表示，它并非一份全面的 AI 代理安全指南。
这一边界十分重要。代理即使使用了得到妥善保护的令牌，仍可能做出不安全的决策。令牌控制机制用于确定谁或什么能够获得访问权限，却无法验证每项自动化操作的质量。
后量子迁移则是另一个尚未解决的领域。NIST 增加了高层级考量，但组织仍需要制定替换加密算法和轮换依赖凭证的详细计划。
遗留系统会使两类迁移都更加复杂。旧版应用可能不支持受众限制、快速撤销、现代联邦协议或发送方约束型令牌。转换网关可以有所帮助，但也会引入额外的信任点。
因此，对 NIST IR 8587 的审慎解读很直接：以结果为导向的指导支持架构多样性，但身份专业能力有限的组织可能会以不均衡的方式实现这些结果。
硬件隔离可以保护密钥材料，却仍可能暴露权限过大的签名接口。短令牌生命周期也可以与长期有效的刷新凭证并存。即使日志记录十分广泛，如果团队无法关联服务提供商和机构的事件，依然可能失效。
这份报告不应沦为脱离攻击路径的合规清单。它的真正价值在于，促使人们围绕签发、验证、监控和响应提出相互关联的问题。
对于云客户而言，下一步是梳理每个签发方、签名密钥、受众、依赖服务和撤销路径，随后测试其中一个组件遭到入侵时会发生什么。
对于服务提供商而言，任务是让安全配置具备可观测性和互操作性。客户需要证据证明，这些保护措施能够跨租户、API、工作负载和联邦关系发挥作用。
当有效令牌不再终结安全讨论时，NIST 令牌安全指南的意义将最为突出。请问：当某份凭证虽然签名正确、但其来源、范围、行为或上下文存在问题时，你的系统能否拒绝它？
