把数据放在客户的云盘里：最小化数据保留的设计思想

在服务提供方的服务器上囤积的客户数据越多，遭到攻击时的损失就越大。反过来，减少留在服务器上的数据，就能从结构上缩小万一发生时的影响范围。

需要保护的对象越少，防护方式就越简单，检查也越不容易遗漏。设计之初先问一句“真的有必要留在服务器上吗”，是出发点。

如果把日报的最终保存位置设为使用本服务的企业（也就是读者您所在的公司）自己的Google云端硬盘中的电子表格，数据的管理主体就回到了客户一侧。

提供方只负责中转，不做长期保管。客户可以通过自己的访问权限设置，自行决定谁能查看，即便终止合同，数据实体也仍在自己手中。

不把数据当作人质的设计，也会在导入时带来安心。

服务器只暂存从提交到批准之间的临时数据，批准时立即删除，即使未批准，超过24小时的数据也将无法再被查看，最迟在次日的定期删除中自动清除。

若能明示“最多可查看24小时，最迟次日清除”，对方的导入审查也更容易通过。这里重要的是：删除不依赖人工操作而自动执行，并且保留的上限能用语言说明白。

含糊的“尽快删除”，审查方无法判断。

最小化保留很有力，但仅凭它并不等于安全。通信加密、写入权限的分离、操作记录等基础措施配合起来，才能达到可以放心使用的状态。

例如，把“暂存期间不被第三方读取”“把写入目的地限定在必要范围”“事后能追溯发生了什么”这三点作为一组来考虑，遗漏就会减少。

考虑导入的一方，可以向提供方抛出下面这些提问作为参考。

“数据的实体在哪里？”“留在服务器上的期限上限是多久？”“删除是自动的还是手动的？”“想撤销权限时，步骤是什么？”回答越具体、越能作为机制来说明，越容易判断其设计是经过梳理的。

反之，如果回答依赖运维人员的细心，那里就容易成为薄弱之处。最后，也建议确认设计说明是否有书面留存，这在公司内部审批或复查时会派上用场。