只要密码正确，共享云盘就能让你打开文件。但它无法证明谁才真正有权拥有这份文件。这个漏洞平时不会显现，潜伏在每一份委托、每一段合伙关系、每一张股权表的背后，直到有人离开、关系破裂，或者密码成了团队与急需的记录之间唯一的屏障。到那时候，再想改变文件的存放方式已经太晚了。这从来都只是出于方便的保管，而方便不能当作证据。
"方便式保管"究竟意味着什么
云存储把访问权交给任何持有登录信息的人。Dropbox、谷歌云端硬盘、公司共享文件夹，没有一个会去问打开文件的人是否真的有权这样做，它们只问密码对不对。多数时候这不是问题，因为多数时候没人提出异议。问题恰恰出现在财务或法律团队无法提前规划的时刻：一位创始合伙人在纠纷正酣时离开，却仍保留着登录信息。一名外部承包商的账号在合同结束很久之后依然有效。一份已解除的委托关系留下一个没有明确归属的共享云盘，两位前合伙人都认为文件应归自己所有。密码管理器出故障，员工离职时没有交接登录信息，或者账号因多次输错密码被锁定，事务所突然连自己保管多年的文件都打不开了。
这些都不是技术故障。云存储本来就是这样设计的：凭登录信息的持有权授予访问权限，它从来不是为了回答"这究竟归谁"这个问题而生的。把它当成能回答这个问题来用，恰恰就是那个漏洞，一旦发生纠纷，它就会立刻暴露出来。
当恢复权与身份挂钩、而非与登录状态挂钩时，会改变什么
Swiss Trust Layer 登记簿上的托管存储运作方式不同，因为它从一开始问的就是另一个问题。用户在能够使用或订阅托管存储之前，必须先完成一次完整的身份核验，以护照验证，与登记簿上其他环节使用的是同一套核验流程。之后，恢复权就与这个经过核验的人绑定，而不是与恰好登录着的设备或浏览器绑定。登录信息丢了，身份不会跟着丢。这才是真正的转变：从"谁拿着密码"变成"登记簿能核实谁是正确的人"，这也正是托管存储与共享云盘从设计之初就截然不同的地方。
文件本身保存在瑞士，独立于任何云服务提供商。它与登记簿已有的一切并存：带有合格时间戳的已封存文件、其背后经核验的身份、一个能识别作品却不暴露文件本身的 ISCC 代码，以及适用情况下的内容标签。我们在此前一篇文章中介绍过完整的登记簿，注册一次，证明随身携带，托管存储正是专为文件封存之后的情形而设计的那一部分：在封存者第一次登录多年之后，谁还能访问它，又是在什么条件下。
这项服务不做出的承诺
有必要说清楚身份核验托管存储目前的适用范围。费用是多少，哪种方案适用于哪种账户，这是另一个话题，本文不会替你做出判断。我们能明确说的是恢复承诺本身：身份可以在线或通过 KYC 核验人员当面重新核验，记录和托管存储中的文件的访问权限可以恢复。这就是托管存储所做的一切，措辞尽量精确到我们能够负责的程度，不多加一句，也不做出超出这个范围的承诺。
这对财务和法律工作到底意味着什么
想想财务或法律团队积累的那些文件，平时没人打算为它们争执，直到真的有人这么做。一段以糟糕方式结束的客户委托关系的记录。股权表中某一条目背后的支持文件，由某位在纠纷爆发两年前就已离开事务所的人起草。共同完成的成果的知识产权转让证据，在合资项目解散后变得存在争议。一份合伙关系的创立文件，存放在双方前合伙人在技术上都还能打开的云盘里，但谁都不信任对方没有改动过什么。在每一种情况下，最终被问到的问题都不是"这份文件是否曾被安全存放"，而是"你能否证明谁有权访问它，无论今天登录信息在谁手上"。共享云盘回答不了这个问题。与经核验身份绑定的托管存储记录正是为此而生。对于这类工作，我们的知识产权与法律团队专页说明了封存与托管存储如何融入事务所已有的举证实践，而不是取代它。
保管卫生习惯，而非一次性的解决方案
以上这些都无法取代最初确定文件归属的那些协议：委托函、知识产权转让条款、合伙协议仍然承担着这个角色。身份核验托管存储所增加的，是在共享云盘曾经赖以维系的人、密码和相互信任统统改变之后，继续能够访问文件本身的一种方式。这不是一次性做出的决定，而是一种值得纳入事务所日常保管习惯的做法，用来保存那些终将需要出示的记录，最好在纠纷成为寻找它们的理由之前就已养成。
