角色与权限：配合业务示例的明确规则

真正的问题：人们看到了不该看到的数据

职场上的“数据泄露”往往很无聊：客服打开客户资料就看到完整的付款记录；客户登录后发现内部备注，比如“如果抱怨就给 20% 折扣”或发票上的真实成本与利润。没有人偷密码，应用只是显示了错误的内容。

多数泄露是意外发生的。权限后来才添加、新页面仓促上线，或有人复制了一个“足够用于测试”的旧角色。然后一个小改动，比如向表里添加新字段，就悄悄对所有人可见了。

因此，角色和权限应该是应用的核心功能，而不是最后的核对项。大多数小型企业最终会采用相同的四类角色：业主、经理、员工和客户。

目标很简单：每个人只应看到完成工作所需的内容，而不要看到其他东西。这不仅包括界面上的内容，也包括幕后数据，而不只是你习惯的那些屏幕。

如果你在像 AppMaster 这样的无代码平台上快速构建，这一点更为重要。速度很好，但如果事先不设计好访问控制，更容易意外暴露私人备注、定价规则或其他客户的记录。

角色、权限与作用范围：简单定义

角色和权限是决定谁可以在应用内做什么的规则。

• 一个角色是像业主、经理、员工或客户这样的职位标签。
• 权限是该角色被允许执行的具体动作。

一个访问级别是这些规则的实际结果。两个人都可能是“员工”，但因为其中一人可以批准退款，所以他的访问级别更高。

防止错误的可靠方法是从最小权限开始，然后只添加该人完成日常工作所需的权限。如果某人从不编辑发票，就不要为了“以防万一”给他们编辑权限。添加权限比撤回权限要容易得多。

大多数权限可以归结为一小组动作：查看、创建、编辑、删除，以及一些高风险动作，如导出或批准。

作用范围回答另一个问题：“他们可以对哪些记录这么做？”有人可能被允许查看发票，但只能查看自己的，而不是所有人的。

典型的范围模式包括：

• 自己的记录（只限他们创建或被分配的项目）
• 团队或地点（他们的分支、部门或项目）
• 整个公司（企业范围内的所有记录）

销售代表可能可以创建并查看自己的报价，但不能导出完整客户名单。销售经理可以查看整个团队的报价并批准折扣。业主可以查看所有内容并导出会计报表。

业主、经理、员工与客户通常需要什么

大多数应用最终分为相同的四类人。细节会改变，但模式不会。如果一开始就明确角色和权限，你可以避免许多以后“为什么他们能看到那个？”的尴尬时刻。

业主通常需要对业务有全面可见性。通常包括计费、安保设置（如密码规则和多因素认证）以及审计历史，以便查看谁在何时更改了什么。

经理需要在不成为完全管理员的情况下管理团队。他们通常需要监督（查看他们部门的一切）、批准操作（折扣、退款、休假、内容变更）和读取报表。他们可能需要有限的管理员操作，比如邀请员工或重置密码，但不应能访问计费或全局安全控制。

员工应能快速完成日常工作，同时风险最低。一个安全的默认是“仅限分配给我的”。客服只看他们的工单，调度员只看今天的路线，销售只看自己的潜在客户。导出和批量下载应默认关闭，仅在确有需要时开启。

客户应只看到他们自己的数据，即便多人共享一个账户。允许他们做有限的操作（创建请求、支付发票、更新个人资料），但隐藏内部备注、员工评论和内部状态。

一个适用于许多业务的默认设置：

• **业主：**全部内容，包括计费、安全和审计日志
• **经理：**团队数据、审批、报表和有限的用户管理
• **员工：**仅限分配记录，无批量导出，无管理设置
• **客户：**仅限自己的记录，禁止查看内部备注，操作受限

按数据类型划分访问，而不仅仅按界面

许多团队按界面设置角色和权限：“员工可以打开订单页面，客户不能。”这有帮助，但遗漏了真正的风险。相同的数据会在搜索、评论、通知、导出和附件中出现。

从列出你的数据领域开始，而不是菜单。高影响的领域通常包括客户联系人、订单与配送状态、发票与付款状态、工资与人事记录，以及内部备注或分析数据。

然后决定每个角色对每种数据类型可以做什么：查看、创建、编辑、删除、审批与共享。这就是字段级规则重要的地方。同一个对象通常需要一个公开视图和一个内部视图。

示例：一个订单可能包括客户姓名、送货地址、价格、内部利润率和内部备注如“客户爱抱怨，给折扣”。客户应看到地址和状态，但绝不应看到利润率或内部备注。经理可能看到所有字段并能批准折扣。员工可能看到完成交付所需的字段，但看不到财务细节。

文件和附件需要额外注意。合同、身份证、收据和截图常常比表单字段包含更多敏感信息。把它们视为单独的权限：谁可以上传、谁可以下载、谁可以预览。还要决定附件是否继承父记录（如发票）的访问规则，或有自己的规则。

最后，不要把导出和批量操作当作“包含的”权限，仅仅因为某人能查看列表。明确列出：导出到 CSV/PDF、批量下载附件、批量状态更改（批准、取消、退款）、批量消息（邮件/SMS/Telegram），以及像重新分配记录这样的管理员操作。

业务示例 1：销售与开票应用

想象一个小型服务型业务：业主销售项目，经理督导工作，员工完成工作，客户批准报价并支付发票。避免尴尬错误的最快方式是在任何人登录前就就角色与权限达成一致。

从金钱细节开始。定价可以对比利润更广泛的人可见。一个常见规则是：员工可以看到需要收多少钱，但不知道你为何定这个价。技师可能需要行项目来解释发票，但不需要看到内部利润、供应商成本或为赢得订单而给出的特殊折扣。

客户数据是另一个高风险点。许多团队希望多人能查看联系信息（以便联系到正确的人），但仅少数人能编辑。否则会出现意外覆盖，例如把账单邮箱改成个人邮箱，发票就无法到达财务。

适合许多团队的简单设置：

• **业主：**查看所有内容，包括利润和折扣历史，并能更改支付状态
• **经理：**能创建报价与发票、批准折扣并编辑客户联系人
• **员工：**能查看分配给他们的客户详情和发票行项，但不能编辑定价规则或查看利润
• **客户：**只能查看自己的报价与发票，并能付款或请求修改

对高风险操作进行锁定。将发票标记为已付、发放退款或更改支付方式应限制为业主（或受信任的财务角色）。

业务示例 2：带内部备注的支持台

支持台看起来很简单：客户发消息，团队回复，工单关闭。问题出现在同一工单视图被所有人复用时。一次错误设置，客户就能看到内部备注、标签，甚至员工绩效数据。

想象一个小型电商的共享支持收件箱。一个工单包含客户消息、订单详情、运输状态，以及像“可疑欺诈，核验身份证”或“VIP，优先处理”这样的内部备注。这些内部上下文对团队有帮助，但绝不应对客户可见。

一个清晰的划分可以保持敏感数据安全：

• **客户：**仅看到自己的消息、公开状态更新和最终处理结果。无内部标签、无员工专用备注。
• **员工客服：**看到客户消息以及解决问题所需的客户数据，如订单历史。可以添加内部备注和标签。
• **经理：**看到员工能看到的一切，外加指派与 SLA 覆盖控制。
• **业主/管理员：**看到全公司的所有工单与高级报告。

客户个人身份信息（PII）是下一个陷阱。支持方通常需要电话号码或地址，但并非每个工单都必需。一个好的规则是：仅在工作流需要时显示敏感字段。例如，只有当代理选择“运输问题”时才显示地址，工单关闭后再隐藏。

将内部指标与客户体验分开。像“首回复时间”、“客服评分”或“升级至法务”这类属于员工与经理视图。

业务示例 3：运营与配送跟踪

想象一个仓库与外勤团队整天进行配送。一个人规划路线，另一个拣货，司机完成到站。如果你的应用把错误的信息展示给错误的人，不仅尴尬，还可能暴露客户地址、定价或内部备注。

首先划清每组每天需要的内容。

**员工（拣货员与司机）**通常需要一个紧凑、面向任务的视图。司机打开应用应只看到今天分配给他们的任务，包含停靠顺序、该停靠点的联系方式与配送说明。他们不应能浏览完整客户名单或查看分配给其他司机的任务。如果人员轮班覆盖，经理可以重新分配任务，而不是赋予广泛访问权限。

经理需要更广的运营视角。他们应看到所有团队的日程、库存数量和当前的问题（延迟配送、投递失败、物品损坏、缺失签收）。他们还需要处理异常的工具：重新分配停靠点、拆分路线或批准库存调整。

客户需要最小视图：仅他们自己的配送状态。他们可以跟踪 ETA，查看送达凭证，并收到“正在发货”或“延迟”等更新。他们不应看到其他客户、整天的路线地图或内部异常备注。

在这里实施角色与权限的一种简单方法是按分配和按客户账户来限定数据范围。例如，一个配送任务记录只对（1）被分配的员工、（2）经理，以及（3）与订单关联的客户可读。

逐步指导：如何设计角色和权限

先用白话命名用户组。“业主”、“经理”、“员工”和“客户”是不错的起点，但前提是它们要符合你公司的实际运作。为每个组写一句话描述成功是什么样子，例如“经理可以指派工作并查看团队绩效，但看不到工资单”。

接着，把动作映射到数据领域。不先想界面，而先想有哪些数据以及人们能对这些数据做什么。纸上画一个简单的表格就够了：

• 列出你的角色和数据领域（客户、订单、发票、工单、报表）。
• 为每个角色写出其需要的动作（查看、创建、编辑、审批、导出）。
• 为每个动作决定作用范围（自己、团队或全部）。
• 明确定义“团队”（分支、区域、项目或直接下属）。
• 标记任何“绝对不允许”的项（例如客户永远不能看到内部备注）。

然后用真实任务来测试你的草案，而不是凭空猜测。演练常见流程，如“创建订单”、“解决工单”和“下载报表”。如果某个任务迫使你赋予广泛访问，说明你可能缺少某个细化的权限（比如“查看合计而不允许导出”）。

在涉及金钱或敏感变更时添加审批。员工可以起草发票，但只有经理可以批准或发送它。员工可以编辑送货地址，但更改银行信息需要业主批准。

导致意外数据泄露的常见错误

小团队的大多数数据泄露不是被黑客攻破，而是应用悄悄给了某人超出其工作需要的权限。角色与权限出问题通常是设定一次后再也不去复查。

一个常见模式是为了“设置配置”而给某人完全管理员权限。匆忙过去了，但权限却保留着。数周后，那个人为了“帮忙做个报表”导出了完整的客户名单，私密数据就躺在电子表格中了。

常见错误包括：

• 将“管理员”设为默认角色以避免支持问题
• 允许广泛导出（客户、联系人、结算、发票），却不做限制或审计
• 共享同一登录账号用于轮班，使你无法追踪谁查看或更改了什么
• 保护了主界面却忘记了侧门，如移动端视图、PDF、邮件通知、附件和自动填充表单
• 未及时做离职处理：离职员工仍保有应用访问、邮箱访问或手机上的保存会话

侧门最难发现。你可能阻止员工看到合同页面，但仍通过邮件把 PDF 发送给他们。或者你的移动端布局可能展示了桌面上隐藏的额外字段。

一个实用修正是把导出和下载视为独立权限，而不是普通的“查看”权限。如果某个角色需要列表，给他们受限视图，而不是完整导出。

邀请真实用户前的快速检查

在邀请真实用户前，假设有人会误点、共享屏幕或下载不该有的文件。现在做几项检查可以避免之后痛苦的善后。

从默认开始。当创建新用户时，他们应默认归入最低角色，无法访问资金、导出或管理设置。如果有人需要更多权限，必须有意为之。

接着像陌生人一样测试客户体验。客户不应在任何情况下看到别人的记录，哪怕他们更改 URL、搜索或筛选。一个快速测试是以客户 A 登录并尝试通过姓名、发票号或工单 ID 查找客户 B。

五个能捕捉大多数泄露的快速检查：

• 默认隐藏敏感字段（工资、成本/利润、身份证、内部备注）
• 锁定导出与批量操作
• 在错误代价高的地方加审批（退款、支付、角色变更）
• 确认作用范围在所有地方都被强制执行（界面、搜索结果、API 响应）
• 确保可以审计更改：谁在何时修改了什么，包括角色更新和支付操作

做一次“事故测试”。让队友用员工账号完成一项真实任务，然后用客户账号重复同样的操作。如果客户能看到内部定价、下载完整客户名单或触发退款，说明权限过宽。

一个现实场景：员工与客户共用一套应用

一个常见请求是：客户想要一个“查看状态”的门户，但你员工已经用同一系统来执行工作。没有清晰的角色与权限，门户可能会暴露内部备注、其他客户的订单或员工专用定价。

想象一个定制印刷公司。一个订单从报价到生产到交付再到开票，全部在一个应用内完成。

以下是每个角色在该流程中应看到的内容：

• **业主：**全部内容，包括利润、员工绩效和所有客户账户
• **经理：**其团队的所有订单、内部备注，以及批准折扣和退款的权限
• **员工：**仅限分配给他们的订单、下一步待完成的任务以及完成工作所需的联系方式
• **客户：**仅限自己的订单、高层状态（已批准、生产中、已发货）、送达凭证和需支付的发票

两个边缘情况通常会破坏模型。

其一，经理临时顶替另一个团队。不要把他们切换为业主，而是添加时间受限的权限，例如对 B 团队订单的 7 天访问。覆盖结束后，该访问权限过期。

其二，VIP 客户请求“更多可见性”。在不增加数据暴露的情况下提供更多上下文。展示扩展的时间线或专门的消息线程，但保留内部备注（如“客户逾期未付款”或“因我方失误需重印”）为员工专用。

职责会改变，所以把访问视为需要定期复核的事项，而不是一次性设置。当有人变更角色时，避免简单累加权限。先移除他们不再需要的权限，再按新工作只添加最小集。

下一步：制定清晰的访问策略并落地

从小处着手。挑一个最重要的工作流，如“创建发票并收款”或“记录支持工单并回复”。先为该单一流程定义角色与权限，然后再扩展。

把规则放到一张简单的表里，并视为活文档：角色、他们能做的、不能做的，以及任何限制（如“仅限自己的记录”或“仅限本地点”）。当有人问“员工能看到客户电话号码吗？”时，这张表应能在几秒内给出答案。

一个实用的推广步骤：

• 为你的首个工作流起草表格（业主、经理、员工、客户）
• 将每条规则映射到具体数据（包括字段）和动作（查看、编辑、导出、删除）
• 为每个角色创建演示账户并端到端测试真实任务
• 先向小范围发布，确认无异常后再扩大范围
• 每季度复查权限，在组织调整后（新经理、新团队、新供应商）立即复核

如果你在 AppMaster (appmaster.io) 上构建，建议在规划数据模型和业务逻辑时同时设计角色，这样相同规则能在 Web 应用、移动应用和 API 端一致应用。

如果愿意的话，今天就写下你的第一张访问表并把它应用到一个工作流。这个单一步骤能防止大多数意外数据泄露。