Transport for London 将网络事件转变为通勤者身份问责测试

摘要

• Transport for London（TfL）在 2024 年 9 月披露了一起网络安全事件，后来表示部分客户和员工数据遭访问，英国国家打击犯罪局随后宣布了与该入侵相关的定罪。
• 核心问责问题是：谁对身份记录、Oyster 卡和非接触式客户数据、员工凭据重置、交通服务连续性、公开更新以及执法证据拥有实际控制权？
• 本案的实际根源并非单一的违规、中断、漏洞或供应商故障标签。记录聚焦于客户账户暴露、有限群体的银行代码和账号风险、员工访问控制、运营连续性、公开沟通以及执法重建。
• 尽管交通网络继续运营，但通勤者、优惠卡持有者、退款客户、员工、警务团队、银行和伦敦公共服务面临身份、支付、访问和信心后果。
• 该记录支持对控制责任和证据缺口的高置信度问责结论。它不支持假设仍属非公开的事实，如每条日志记录、每个客户影响、每个内部决策或每次下游损失。

证据记录及其使用方式

本文将公开记录视为分层证据，而非单一的主叙事。公司通知用于说明 Transport for London 所述发现、变更或建议的内容。政府、监管机构、漏洞和安全研究资料用于构建围绕事件的控制责任。次级报道仅在其保留了公开声明、时间顺序或受影响方背景、且其他稳定一手文件中无法获取时才被使用。

事件本质在于控制

Transport for London 将网络事件转变为通勤者身份问责测试，是因为该事件将实际控制置于比标题更明亮的光照下。公开记录始于TfL 网络安全事件页面，并由TfL 关于网络安全事件的媒体公告和NCA 定罪公告予以强化。这些记录之所以重要，是因为它们标记了模糊的安全叙事与一套运营职责之间的区别：找出受影响的系统，确定哪些数据或信任材料可被触及，通知必须采取行动的人员，并证明旧的风险路径已被关闭。

重要的分析步骤是将触发因素与问责区分开来。触发因素是 Transport for London 网络事件、客户数据暴露、逮捕和定罪记录（2024-2026 年）。问责则更为广泛。它包括事件前的设计选择、本应检测到异常活动的监控、遏制事件的紧急权限、区分已确认入侵与潜在暴露的证据，以及让依赖方能够自行决策的沟通。供应商可以准确描述狭隘的技术触发因素，但仍然让客户缺乏足够的证据来管理其自身的风险。

因此，对于 Transport for London 而言，公共问题在于控制面：公共交通身份数据、客户通知、员工访问、运营连续性、银行细节暴露、公共沟通和执法证据。这些不是公关细节。它们是损害扩大或缩小的机制。一次短暂的入侵可能产生长期的身份风险。一个旧漏洞可能变成持续的连续性故障。一个供应商账户可能变成客户账户问题。一个平台支持工单可能携带比生产服务本身更敏感的材料。本文通篇使用这一视角。

时间线是证据的一部分

时间线之所以重要，是因为客户只有在了解足够信息后才能采取行动。在本案中，公开时间线始于上述触发因素，随后经历遏制、客户指导、后续报告和后期分析。早期时刻考验检测和升级能力。中期时刻考验临时控制是否转化为持久修复。后期时刻考验组织是否充分汲取教训，以防止相似路径，而非在关注消退后简单了结事件。

一份好的事件时间线应能回答几个问题。异常活动何时开始？防御者首次发现是何时？防御者何时意识到其重要性？组织何时遏制了路径？组织何时得知哪些客户、记录、服务、凭据或系统可能受到影响？组织外部人员何时收到足够信息以自我保护？公开通知很少能完全回答每一个问题，但这些问题仍是正确的问责框架。

内部事件与公开通知之间的时间差并不自动构成过错。事件响应人员需要时间核实事实。过早的通知可能传播不正确的建议。但该时间差必须可以解释。如果客户控制着密码、令牌、端点、支持文件、银行账户、管理员或下游用户，延迟也会将风险转移给他们。问责的标准并非瞬时完美，而是及时、分阶段的沟通，区分已确认事实、合理风险、建议行动和未解决的不确定性。

数据或信任对象并非偶然

本案中暴露或受威胁的对象并非业务中的偶然之物。记录聚焦于客户账户暴露、有限群体的银行代码和账号风险、员工访问控制、运营连续性、公开沟通以及执法重建。这意味着事件触及了该组织存在就是为了管理、或已邀请客户依赖的信任对象。当该对象是凭据、签名证书、支持附件、客户元数据集合、构建服务器、防火墙、虚拟化平台或是公共服务身份记录时，组织就不能将其视为普通的办公系统细节。

信任对象具有特殊的问责属性。它们使其他系统能够做出决策。代码签名证书告诉端点软件是否合法。支持凭据告诉平台某人是否可以查看客户记录。构建服务器告诉下游用户，某个工件来自预期流程。防火墙或远程访问网关告诉网络哪些会话可以进入。客户元数据记录告诉欺诈者目标是谁。损害往往在之后出现，当某人在不同场景中重用该信任对象时。

这就是为什么要进行功能范围分析，而不仅仅是表名或服务器名。如果被复制的字段能识别出管理员，仅问数据库表是否被复制就过于狭隘。如果企业记录揭示了日后如何攻击该数据面，仅问生产数据面是否被入侵就过于狭隘。如果凭据、证书或附件在事件后仍可使用，仅问服务是否保持在线就过于狭隘。

供应商责任取决于最高杠杆的控制措施

此故事中的供应商控制了公共事件开始的环境，但这一陈述并不足够。更精确的问题是，供应商一方有哪些高杠杆的控制措施。在许多事件中，这些控制包括架构、特权访问、服务分段、证书或密钥处理、日志覆盖范围、客户数据最小化、安全默认设置、紧急撤销、发布工程，以及发布可靠指南的权限。

判断供应商应根据其让风险路径变得容易还是困难。特权工具是否需要强身份验证和严格角色？敏感的支持附件或元数据是否被保留超必要时长？生产系统是否与企业系统分离？暴露的服务是否设计为故障关闭？日志是否完整到足以重建访问记录？组织能否快速撤销信任材料？客户能否验证自己已安装安全版本，或采取了正确的遏制步骤？

公开记录可能只展现该控制态势的一部分。它可以显示已发布通知、已发布补丁、需要重置密码、已禁用供应商账户、已替换证书或某个公共机构保持服务运行。它通常无法显示内部访问审查、董事会讨论、取证信心或每一条客户信息。对这种完全可见性的缺乏，不应以猜测来填补。应将其称为证据限制，并转化为对更清晰的未来保证的需求。

客户和运营者责任并未消失

客户和运营者也有责任。这并非推卸责任，而是承认许多技术事件跨越组织边界。客户可能控制端点更新、密码重复使用、特权账户、防火墙暴露、支持文件上传、管理员行为、备份隔离、警报审查和用户教育。公共机构可能控制身份核验和公民通知。托管服务提供商可能控制客户从未见过的控制台。

正确的分配取决于能力。如果只有供应商能识别哪些支持记录被访问，那么供应商就拥有该证据。如果只有客户能轮换下游密钥或审查自己的日志，客户在收到可信通知后就拥有该行动责任。如果托管提供商运行着受影响的工具，那么托管提供商对客户负有行动和证据的双重义务。问责遵循实际控制，而非品牌知名度。

这很重要，因为反应不足往往隐藏于另一方过失的背后。客户可能会说是供应商造成了问题，因此不审查自身的暴露情况。供应商可能会说是客户配置不当，因此不改进安全默认设置。托管提供商可能会说已打补丁，却避免解释是否审查了入侵。只有当每一方都说明其控制了何物以及采取了何种措施时，公共利益才能得到保障。

分段是事件与扩散的边界

分段决定了事件是否保持局限。在本案中，相关的分段可能在企业 IT 与产品基础设施之间、支持工具与生产数据之间、元数据与客户内容之间、管理面与流量面之间、构建服务与签名密钥之间，或是虚拟化主机与备份区域之间。确切的边界因主体而异，但问责原则是稳定的。

分段声明应可验证。仅仅说一个环境与另一个环境是分离的是不够的。记录应显示哪些身份可以跨越边界、存在哪些网络路径、哪些日志确认了失败的或不存在的移动、审查了哪些服务账户以及应用了哪些紧急控制。客户不需要每一个敏感细节，但需要足够的保证，以知晓供应商一方的事件是否改变了他们自身的风险。

最有力的公开声明避免两种极端。它们不会通过暗示每一个依赖系统都遭入侵来夸大损害。它们也不会躲藏在狭隘的技术边界后，同时忽略相关的风险。说明生产数据面未受影响是有用的。说明哪些元数据、凭据、证书、附件或管理记录受到了影响同样必要，因为这些材料日后可被用于攻击数据面。

通知必须告知收件人他们能做什么

通知不是一种仪式，而是一种可执行证据的传递。有用的通知会告知收件人发生了什么、可能涉及哪些数据或信任材料、组织已经做了什么、收件人现在应做什么、哪些仍属未知以及后续更新将出现在何处。如果通知只说明发生了一起事件，它可能满足了正式的沟通需求，却未能满足操作需求。

不同的收件人需要不同的内容。安全管理员需要指标、受影响账户、重置要求、日志审查窗口和配置指南。消费者需要通俗易通的身份风险建议、支付和密码指南以及支持联系方式。公共服务用户需要确保基本服务延续或有替代方案。开发者需要构建完整性指南和密钥轮换步骤。高管需要暴露、入侵、补救和残余风险的矩阵。

因此，本文将沟通视为一种控制，而非一种礼貌。即使最初入侵被迅速遏制，延迟或模糊的通知也可能扩大损害。分阶段的通知甚至能在每个事实确定之前就减少损害。当范围扩大时，更正通知可以是负责任的做法。关键在于诚实标明不确定性，而非假装首次公开版本即为最终版本。

滥用面超出已确认的入侵

已确认的入侵只是第一层风险面。攻击者、犯罪分子和机会主义者可以将事件信息用于钓鱼、欺诈、凭据窃取、勒索、虚假支持电话、软件更新诱饵、发票诈骗、招聘定位及社会压力。通勤者、优惠卡持有者、退款客户、员工、警务团队、银行和伦敦公共服务面临身份、支付、访问和信心后果，尽管交通网络继续运营。因此，组织不仅须衡量入侵者做了什么，还要衡量暴露信息使其他人在之后能做什么。

当暴露的材料能识别出管理员、支持联系人、支付关系、特定品牌的客户、提交过身份文件的用户或运行特定技术的组织时，尤其如此。这些记录降低了攻击者的搜索成本。它们使社会工程攻击更廉价、更可信。它们也让犯罪分子能够个性化时机：真实事件后的虚假重置通知看起来比普通的钓鱼消息更可信。

事件后的滥用预防应包括监控假冒行为、向客户警示可能的诱饵、收紧支持验证、撤销失效令牌、轮换暴露的密钥、监控新账户活动，并为一线支持人员提供不会泄露更多信息的应答脚本。组织还应审查其收集或保留的数据是否超出了支持或服务功能真正所需。

取证必须支持信任决策

取证审查有特定的目的：它支持信任决策。客户能否继续使用该软件？组织能否信任该防火墙？能否信任构建产物？能否信任支持记录？能否信任身份提供商、元数据存储、虚拟化平台、证书、备份或远程访问会话？修补、重置或禁用某物只是答案的一部分。

信任决策需要关于什么被访问、什么可能被访问、什么被更改、存在哪些凭据或密钥、哪些日志是完整的、日志是否可能被篡改，以及哪些独立信号确认了结论的证据。当证据不完整时，组织应说明并针对高价值资产做出保守决策。一个被入侵的边界系统或构建服务器，即使在原始漏洞修复后，也可能需要重建和密钥轮换。

薄弱的取证记录会造成二次问责问题。如果组织无法证明信任对象仍保持安全，它可能需要承担更广泛补救的成本。这代价高昂。但替代方案是将不确定性转移给缺乏供应商证据的客户、公民或下游用户。成熟的事件管理将私人日志转化为足够的外部保证，以便外人能够理性行动。

经济激励解释了投入不足

各类事件中反复出现的模式并不神秘。预防性控制在任何事件发生之前，往往强加可见的成本。分段减缓了便利性。最小权限让支持工作变得困难。证书轮换带来兼容性风险。构建服务器加固减缓交付速度。虚拟化平台修补需要维护窗口。客户数据最小化可能减少市场营销或支持细节。备份测试消耗时间。这些成本是即时的；而避免的损害在到来之前是不确定的。

这种激励差距就是问责不能等待法庭记录或确认损失数字的原因。如果每个组织都等到损害被证实，那么最廉价的路径总是推迟控制并希望另一方吸收损失。客户可能承受身份风险、停机时间、欺诈监控、紧急人员配置、合同中断或公共服务不便，而拥有最佳预防控制的一方却将成本视为外部性。

更好的激励模型将控制责任与能够在事件发生前以最低成本降低风险的一方联系起来。供应商应让安全默认设置和完整日志成为常态。客户应维护资产清单、修补窗口、恢复测试和凭据卫生。托管提供商应提供证据包。监管机构和保险公司应在事件发生前要求这些控制的证明，而不仅仅是事后的叙事。

治理记录应比新闻周期更长久

治理记录应在新闻热度消退后仍保持有用。该记录应描述触发因素、受影响资产、受影响人员、遏制行动、客户建议、证据质量、残余风险、业务影响、补救负责人及后续测试。它还应显示事件后哪些方面发生了变化：访问规则、保留期限、供应商监督、日志覆盖范围、补丁服务级别、密钥轮换、备份隔离或客户通知操作手册。

没有该记录，组织只会暂时学习。员工轮岗。紧急例外仍在。临时缓解措施变成永久方案。同一类事件在不同产品或供应商关系中再次发生。长尾问责记录使董事会、监管机构、客户或未来的运营者能够在六个月后询问承诺的修复是否仍然存在。

对 Transport for London 而言，持久的教训并非所有可能的损害都已发生，而是该公共事件暴露了一类将会重复出现的控制问题。下一个案例可能涉及不同的产品、地理区域、攻击者或数据集。考验将是相同的：组织能否表明谁控制了风险路径、他们做了什么，以及为何局外人应信任结果？

哪些因素会改变评估

评估会随着证据的强弱而改变。更强的证据包括独立的取证摘要、完整的客户影响类别、从首次检测到遏制的清晰时间线、相关信任材料已轮换或从未暴露的证明，以及表明相同路径已不再有效的后续测试。更弱的证据则包括未做解释的延迟扩大范围、数据类别不清、日志缺失、类似事件重复发生，或在客户行动必要时却将其视为可选的模式。

它还会随着受影响方的证据而改变。能够证明无暴露、快速更新、日志完整且无可触及信任材料的客户，应与那些使用旧版本、暴露管理面、日志不完整、重复使用凭据或存有敏感支持文件的客户受到不同评估。拥有安全默认设置和窄保留期限的供应商，应与那些赋予广泛内部工具对敏感记录持久访问权限的供应商受到不同评估。

这就是为什么一篇好的问责文章既要抵制恐慌，也要抵制免罪。公开记录可以支持控制结论，而不必证明每一项损失。它可以识别证据缺口，而不凭空捏造事实。它可以认识到供应商负责任地处理了事件的部分内容，同时仍质疑事件前的设计是否造成了本可避免的风险。精确并非软弱；它是问责可信的原因。

在记忆消退前，客户应保存的证据

最有用的客户证据通常在通知后的最初几小时内收集。管理员应保存身份验证日志、支持通信、暴露账户列表、防火墙或端点事件、配置导出、密码重置记录、证书或密钥清单，以及当时存在的供应商通知截图。这些材料日后能够解释组织为何选择窄幅重置、宽幅重置、重建、披露或监控响应。没有它们，后续审查就会变成对记忆的争论，而非控制记录。

保存也很重要，因为供应商的通知可能演变。第一份通知可能说调查正在进行中。后来的通知可能缩小或扩大受影响人群。安全公告可能增加“已被广泛利用”的状态。保存每个版本的客户可以将其决策与当时可用的事实对应起来。这既防止了不公平的事后评价，同时也暴露了在可信通知后行动迟缓的问题。

证据不应仅停留在安全团队内部。法律、采购、隐私、支持、业务连续性、工程和高管团队各需一份适合其角色的版本。隐私团队需要受影响的数据字段。工程团队需要技术指标和系统所有者。采购团队需要合同义务。支持团队需要面向客户的话术。高管需要残余风险和责任人姓名。如果证据正确却被困在错误的职能中，单次事件也可能失败。

客户行动窗口是一项可衡量的责任

供应商一方的事件常会启动客户一方的时钟。如果通知要求客户更新软件、轮换凭据、审查日志、禁用暴露接口或警告用户，那么客户的响应时间便成为问责记录的一部分。供应商控制着通知和受影响的服务。客户控制着本地的行动。任何一方都无法单独完成工作。

该行动窗口应以匹配风险的尺度来衡量。一个关键暴露的边缘缺陷可能需要数小时。一次广泛的元数据暴露可能需要即日发出钓鱼警告并进行管理员审查。证书替换可能需要更新部署、白名单清理以及证明旧的签名包不再受信任。支持工单暴露可能需要审查附件和通知用户。虚拟化平台的勒索软件潮可能需要紧急隔离和备份验证，然后才能应用常规维护窗口。

要义不在于惩罚每一次延迟。有些环境很复杂，公共服务不能随意停止，紧急变更可能中断关键运营。要义在于使延迟明确化。如果组织延迟了，它应记录补偿控制、业务原因、负责人、到期时间以及风险未无限期敞开之证据。未记录的延迟正是临时例外演变为下一次事件的原因。

修复声明需要持久证据

当修复声明明确指出改变了何种控制，并提供变更仍维持着的证据时，它便更为有力。对于身份事件，证据可能包括已禁用的服务账户、更短的会话、更强的管理员身份验证、访问审查以及抗钓鱼的重置工作流程。对于支持事件，证据可能包括更窄的供应商角色、附件保留限制、特权操作日志记录以及客户文件净化。对于边缘设备事件，证据可能包括经外部验证的管理隔离、固定版本、日志审查、密钥轮换和重建决策。

公众受众不需要每一个敏感细节，但确实需要修复的轮廓。说“安全性已增强”弱于说明移除了哪类访问、最小化了哪类记录、轮换了哪类凭据、重建了哪类设备，以及哪项测试验证了结果。具体的修复语言让客户能够将补救措施与故障路径进行比对。

持久性才是难点所在。许多修复在事件刚过后看似牢固，随后便衰退。临时防火墙规则卷土重来。旧有的支持权限重新累积。新增的日志无人审查。备份未经测试。培训只进行了一次便消逝。因此，问责记录应包含一个后续验证节点。一项无法经受日常运营的修复，只是风险的暂停，而非终结。

托管提供商处于责任链中

许多受影响组织并不直接管理公开通知中讨论的系统。托管提供商可能运营着远程支持工具、构建服务器、邮件平台、防火墙、数据库账户、虚拟化平台、帮助台工作流或客户通知。该提供商可以快速降低风险，或使客户不知情。因此，其证据责任并非仅仅是一种服务礼节。

托管提供商应准备好告知客户：受影响产品或服务是否存在、是否已暴露、何时更新或隔离、日志是否显示可疑活动、凭据是否轮换、备份是否测试，以及还存在何种残余风险。对于须向其自身用户、监管机构、保险公司或董事会负责的客户而言，一句“事情已处理”的简单声明是不够的。

合同应在紧急情况发生前就明确这一期望。它们应规定紧急通知触发条件、证据交付、紧急维护权限、凭据所有权、备份责任以及谁为超常恢复支付费用。如果合同将安全证据视为可选项，客户可能会在事件期间发现它购买的是正常运行时间，而非问责。

数据最小化改变爆炸半径

最容易保护的暴露记录是那些从未保留的记录。这就是为什么在看似事关技术入侵的事件中，数据最小化很重要。一个存储旧附件的支持工具、一个保留不必要元数据的账户门户、一个能查看广泛身份证据的客服提供商，或是一个汇总管理员联系信息的企业系统，都会在攻击者到来之前增加入侵的价值。

最小化并不意味着假装业务可以在没有记录的情况下运行。支持团队需要足够的信息来解决客户问题。安全团队需要日志。金融服务需要受监管的记录。公共交通系统需要账户、优惠、退款和支付操作。控制问题在于，组织能否在事件后为每个敏感字段、每条保留期限、每项供应商权限和每条导出路径提供正当理由。

更少的记录也会改变通知。如果供应商能说，仅保留并触及了狭窄的字段集合，客户就可以精准地行动。如果供应商保留了宽泛的附件或丰富的元数据，通知就变得更为困难，下游滥用面也随之扩大。因此，最小化不是一句隐私口号，而是一项韧性控制，因为它减少了被卷入事件的人员和决策数量。

董事会监督应要求控制证据，而不仅是状况

高管们通常将事件更新作为状态词接收：已遏制、已修复、无重大影响、调查正在进行中。这些词语太过宽泛，无法治理风险。董事会层面的监督应询问哪种控制失效或受到压力、由哪方拥有、何种证据证明了遏制、哪些客户或用户仍可能受到损害、哪些修复是持久的，以及哪些仍属未知。

董事会还应询问该事件是否揭示了一种模式。这是否是早期支持工具暴露、旧补丁缺口、分段设想、供应商监督弱项或反复未能轮换信任材料的重演？一次事件或许只是运气不佳。重复的控制模式则是治理证据。它显示组织是在学习，还是仅在应对。

这并不要求董事成为事件响应者，而是要求他们索要决策级别的证据。他们需要暴露计数、行动窗口、客户义务、法律触发点、业务连续性影响和后续负责人。当董事会只问故事是否结束时，管理层便因悄然了结而受到嘉奖。当董事会询问何种证据改变了控制环境时，修复便变得可见。

该事件应改变未来的采购问题

客户应将此类事件转化为更好的采购问题。他们应询问供应商：如何限制支持访问、如何净化客户附件、企业 IT 如何与生产服务分离、签名证书如何保护、构建系统如何存储密钥、边缘产品如何记录管理活动、旧版本如何退役，以及在安全事件期间客户如何接收紧急证据。

这些问题应在续约前提出，而非仅在危机之后。商业团队或许更青睐简单的功能对比，但事件表明，运营保证可能与产品性能同等重要。一个拥有广泛支持权限、薄弱日志、缓慢通知和不明确恢复责任的廉价平台，一旦出现问题，可能代价高昂。一个更有纪律的供应商，即使一切正常，也能减少隐藏的风险。

采购还必须避免仅停留在纸面的保证。问卷调查答案应关联可验证的证据：审计摘要、保留设置、角色模型、补丁服务水平、客户通知示例、恢复演练以及可用的独立评估。目标不是要求不可能的透明度，而是购买足够的证据权利，使得当供应商成为其风险面的一部分时，客户不至于束手无策。

问责教训可重复使用

可重复使用的教训是，现代基础设施事件很少止步于最初发生的系统。一个被入侵的支持提供商可能演变为身份问题。一个企业系统事件可能演变为客户元数据问题。一个脆弱的构建服务器可能演变为软件供应链问题。一个远程访问产品可能演变为证书信任问题。一台防火墙或虚拟化平台可能演变为连续性故障。这些类别相互重叠，因为客户依赖的是整合服务，而非孤立的盒子。

这种重叠正是为什么响应计划应围绕控制面来编写。谁拥有身份信任？谁拥有签名软件信任？谁拥有支持数据？谁拥有边缘管理？谁拥有备份？谁拥有客户沟通？谁拥有供应商证据？如果这些所有者在事件前就已知晓，组织的响应就能更少混乱。如果他们在事件期间才被发现，事件就会在人们协商权限时扩大。

一个成熟的组织应能阅读此类未来的任何通知，并立即将其映射到所有者、行动和证据。这就是事件意识与事件准备之间的区别。意识说“某事发生了”。准备说“谁必须在何时做什么，用何证据，以及依赖方将如何知晓”。

公共利益结论

公共利益结论是，Transport for London 网络事件、客户数据暴露、逮捕和定罪记录（2024-2026 年）应被铭记为一次控制测试。该事件测试了组织及其客户是否能区分技术遏制与信任恢复。它测试了通知是否具有可执行性。它测试了敏感记录或信任对象是否已被最小化。它测试了依赖方是否收到了足够证据以自我保护。

对此类事件最强有力的回应不是更响亮的保证。它是一条更窄的风险路径、一条更快的遏制路径、一条更完整的证据路径和一条更清晰的客户行动路径。这意味着更少的不必要数据、更少的宽泛支持权限、更严格的管理边界、业务与服务环境之间更强的分离、更好的日志记录、经过测试的恢复，以及在信任不确定时更快地撤销凭据或证书。

Transport for London 将网络事件转变为通勤者身份问责测试，是因为该组织处于一个许多其他方不得不依赖其证据的节点。当情况如此时，问责便紧随实际控制面。视线最清晰、降低损害能力最强的一方，不能仅仅说事件已经结束，还必须表明为何信任关系可以安全地继续。