2026-06-27
把数据放在客户的云盘里：最小化数据保留的设计思想
如何降低业务SaaS的信息泄露风险。讲解把数据实体放在客户一侧、最小化服务器保留的设计思路。
囤积越多，风险越大
在服务提供方的服务器上囤积的客户数据越多，遭到攻击时的损失就越大。反过来，减少留在服务器上的数据，就能从结构上缩小万一发生时的影响范围。需要保护的对象越少，防护方式就越简单，检查也越不容易遗漏。设计之初先问一句“真的有必要留在服务器上吗”，是出发点。
实体放在客户的云盘
如果把日报的最终保存位置设为客户自己Google云端硬盘中的电子表格，数据的管理主体就回到了客户一侧。提供方只负责中转，不做长期保管。客户可以通过自己的访问权限设置，自行决定谁能查看，即便终止合同，数据实体也仍在自己手中。不把数据当作人质的设计，也会在导入时带来安心。
服务器保留要设定时限
服务器只暂存从提交到批准之间的临时数据，批准时删除，即使未批准，最长24小时也会自动删除。若能明示“最长只保留24小时”，对方的导入审查也更容易通过。这里重要的是：删除不依赖人工操作而自动执行，并且保留的上限能用语言说明白。含糊的“尽快删除”，审查方无法判断。
仅靠删除还不够
最小化保留很有力，但仅凭它并不等于安全。通信加密、写入权限的分离、操作记录等基础措施配合起来，才能达到可以放心使用的状态。例如，把“暂存期间不被第三方读取”“把写入目的地限定在必要范围”“事后能追溯发生了什么”这三点作为一组来考虑，遗漏就会减少。
导入前值得确认的提问示例
考虑导入的一方，可以向提供方抛出下面这些提问作为参考。“数据的实体在哪里？”“留在服务器上的期限上限是多久？”“删除是自动的还是手动的？”“想撤销权限时，步骤是什么？”回答越具体、越能作为机制来说明，越容易判断其设计是经过梳理的。反之，如果回答依赖运维人员的细心，那里就容易成为薄弱之处。最后，也建议确认设计说明是否有书面留存，这在公司内部审批或复查时会派上用场。