第四篇确定了迁移顺序：先迁移主数据，再迁移交易；并行运行要有明确宣布的结束日期，而不是无限期；成功的标志只有一个：有人在没人提醒的情况下不再打开旧文件。现在，数据已经住进了新家。

随之而来的是一个在文件世界里并不存在的问题，不是因为有人忽视了它，而是因为文件根本无法提出这个问题：谁能看到什么？这不是 IT 部门的安全问题，而是你的运营问题，因为它的答案决定了每位员工能够了解到关于公司、关于同事以及关于你的客户的哪些信息。

文件只知道一个答案：打开或关闭

电子表格在很多事情上都是出色的工具，但权限不在其中。它只有一个级别：谁拿到它，谁就能看到全部。没有一列能对一个人显示而对另一个人隐藏，也没有一行能让会计看而销售代表不能看。即使有时给文件加上密码，也改变不了这个等式，因为密码守的是门，而不是里面的内容：一旦跨过这道门，门后的一切都一览无余。

更重要的是，副本会不断增多。你把文件发给一位同事，请他核对一个条目，于是一份完整的副本就永久留在了他的电脑上。他再转发给帮忙的人，文件通过电子邮件、聊天工具和 U 盘四处流转，最后落到一位一年前就已离职的员工的笔记本电脑上。你从未给任何人永久访问权，但副本替你给了，而且一旦流出，就无法收回。

每天都在暴露却无人察觉的三类信息

问一位企业主他的文件暴露了什么，他通常会想到销售数字。另外三类信息流转得更悄无声息，也更加重要：

  • 工资。工资文件通常一开始是会计手里的一张表，接着人力资源部门需要它，然后负责执行银行转账的人要核对它。三份副本，每一份都载有公司里所有人的工资。泄露并不需要恶意：只要有人在一块路过的同事能看到的屏幕上打开这个文件就够了。它对团队的影响比任何经济损失都更沉重，因为工资比较对工作关系造成的伤害，是无法恢复原状的。
  • 利润率和特殊定价。销售表本身通常就包含成本价、允许的折扣区间，或者给某个大客户的特殊价格。销售代表需要价格来销售，却不需要成本。当他同时看到两者时，他的谈判方式就会改变，而你的特殊定价也会随着第一位跳槽到竞争对手的员工流入市场。
  • 客户数据。姓名、手机号码、地址，有时还有身份证件和注册文件的图片。这不只是公司的信息，更是信任你、把数据交给你的那些人的个人数据。它也是承担法定义务而不只是内部惯例的那一项，我们稍后再回到这一点。

请注意，这三类信息没有一类是经过决定才暴露的。没有人决定销售代表应该看到成本，那一列只是恰好在他因为别的原因需要的文件里。这正是问题所在：在文件的世界里，暴露是默认状态，而例外需要刻意的努力，在日常压力下没有人会这样做。

系统首先带给你的不是更漂亮的界面

当你转向系统时，第一个真正的区别既不是外观，也不是速度，而是这个问题终于可以被提出、也可以被回答了：谁能看到什么？实际的区别有四点：

  • 权限绑定到角色，而不是个人。你只需定义一次销售角色能看到什么，担任这个角色的每个人都会继承它。新员工入职时不需要从头再想一遍；员工在部门之间调动时，他能看到的内容会随角色一起变化，而不是等到某个人碰巧想起来。
  • 权限细化到字段。销售代表可以看到完整的客户记录和订单历史，却看不到同一行上的利润率。这在文件里不可能做到，在设计良好的系统里却是平常事。
  • 有记录可查：谁查看过，谁修改过。这份日志与其说是监控员工的工具，不如说是结束争论的工具。当一个数字发生变化，所有人都在问是谁改的、什么时候改的，系统一秒钟就能给出答案，而不是让这个问题演变成没有依据可以裁决的相互指责。这正是本系列第一篇中第四个信号所描述的情形。
  • 访问权可以立即收回。员工离职时，停用其账户就能立即、彻底地终止其访问。而他在多年工作中从你的文件里拿走的副本仍然留在他手里，没有办法收回，甚至无法知道有多少份。

法律层面：客户数据不是整洁与否的问题

客户数据与另外两类不同，因为处理不当的代价不是内部的尴尬，而是法定责任。由沙特数据和人工智能管理局（SDAIA）监管的《个人数据保护法》适用于任何处理王国境内个人之个人数据的组织，不因规模而有任何豁免。它要求组织负责保护这些数据、收集的数据不超过目的所需，并报告威胁这些数据的泄露事件。

把这项义务放在日常做法旁边看一看：一个包含数百条客户记录的文件通过聊天应用发给三名员工，并自动保存到他们的个人手机上。在这种情况下，你不知道数据的副本存在于哪里、谁能接触到它们，也不知道在客户提出要求时该如何删除。这与把数据集中保存在一个地方、并按明确权限加以管理的系统之间的差别，不是是否优雅的问题，而是能否合规的差别。

我们在《个人数据保护法》实用指南中更详细地阐述了这些义务，并在你的客户对话与法律一文中讨论了最常见的情形，即客户数据在对话中流转。关于小型公司更全面的防护全景，请参阅我们的中小企业网络安全指南。

Origami 的观点

当我们为一家一直靠电子表格运转的公司构建定制系统时，权限矩阵属于设计阶段，而不是交付阶段。原因很实际：权限不是最后才加上的一个设置，而是一项决定，它决定界面如何划分、报表如何构建，以及敏感字段在哪里与普通字段分开。把它推迟，得到的就是一个日后不重建部分模块就无法加以限制的系统。

我们还会从公司今天实际依赖的角色出发来制定这个矩阵，而不是从一份理论清单出发，因为脱离运营现实设计的权限会阻碍工作，团队就会用手边最快的办法绕过它，通常是把数据导出到文件里。到那时，你就完全回到了起点，还为一个没人使用的系统付了钱。这一逻辑贯穿于我们在各项服务中构建的一切：不尊重工作实际开展方式的管控是站不住的。

在不让工作停滞的前提下设置权限

首次上线时常见的错误是过度严格：一切都关闭，按申请逐项开放，于是团队整周都在等待审批，还没学会使用系统就先学会了厌恶它。按以下顺序可以避免这种情况：

  • 从角色入手，而不是从姓名入手。写下你公司实际存在的角色清单：会计、销售代表、仓库管理员、分店经理。通常不到十个角色就能覆盖所有员工，而管理一份角色清单远比管理一份每月都在变化的人员清单容易。
  • 先列出敏感字段。工资、成本、利润率、允许的折扣、客户身份证件。在任何公司里这都是一份很短的清单，对每一项做出明确决定，就能解决大部分问题。
  • 把查看与编辑分开。需要看到某个数字的人，并不都需要修改它。只读不改是最安全、对工作干扰最小的权限，在大多数情况下也已足够。
  • 把导出设为一项单独的权限。这一点总是被遗忘：任何能把数据导出到文件的人，只需点击一下就能绕过上面的一切。决定由谁持有这项权限，并让每一次导出都像其他任何操作一样出现在日志中。
  • 每当团队发生变化时都复核这份清单。新人入职、部门间调动，或者一段雇佣关系的结束。每隔几个月做一次定期复核，通常能发现已离职人员的账户，以及某项早已结束的临时任务遗留下来的权限。

总的原则很简单：每个人都能看到完成工作所需的内容，并且能看到完成工作所需的全部内容。前半句保护的是你；后半句保护的是系统，使它不至于变成团队绕道而行的障碍。

下一篇

我们已经解决了谁能看到什么的问题，剩下的问题是有什么可看。下一篇将讨论你过去每到月底都要手工制作的报表，以及为什么系统内的报表会成为对当下时刻的呈现，而不再是一项等到它所描述的那个月早已过去才完成的收集工作。随后，我们将以迁移后的头三十天以及这段时间里通常会出问题的地方来结束本系列。

参考来源