SRM 供应商管理系统权限与审计怎么做？角色、数据范围和操作日志实践

权限设计不是堆砌角色

很多企业在规划 SRM 供应商管理系统时，第一反应是列出几个角色：管理员、采购员、供应商、财务。然后给每个角色勾选一堆功能菜单。这种做法在内部协作简单的团队里勉强能用，但一旦涉及多部门、多层级、多供应商，问题立刻暴露。

我见过一个中型制造企业，采购部能看到所有供应商的报价明细，财务部能看到所有采购订单的付款条款，供应商之间甚至能看到彼此的历史交易记录。这些问题的根源只有一个：权限设计只做了功能菜单控制，没有做数据范围控制。

权限与审计在 SRM 系统中是一体两面。权限决定了谁能做什么、能看到什么，审计则记录谁做了什么、看到了什么。两者配合，才能满足合规要求和风险控制。

角色权限的三层结构

SRM 系统的角色权限不应该只有一层“功能菜单”，建议分为三层：功能权限、数据权限、字段权限。

功能权限

功能权限控制的是“能不能用某个功能”。比如创建采购订单、审批供应商注册、导出供应商列表。这是最基础的权限层，通常用 RBAC（基于角色的访问控制）模型实现。

实施时注意两个问题：

• 角色继承：不要为每个用户单独分配权限，而是定义角色，再把用户挂到角色下。如果某个用户需要多个角色的权限，用“角色组”或“多角色”来处理，不要搞出几十个角色。
• 功能粒度：功能菜单的粒度要适中。把“供应商管理”拆成“查看供应商”“编辑供应商”“删除供应商”是合理的，但拆成“查看供应商名称”“查看供应商地址”就过度了，那应该属于字段权限。

数据权限

数据权限控制的是“能看到哪些数据”。这是 SRM 系统中最容易被忽视的层面。典型场景：

• 采购员 A 只能看到自己负责的供应商，不能看到采购员 B 的供应商。
• 财务部只能看到已审批通过的采购订单，不能看到草稿状态的订单。
• 不同事业部的采购员只能看到本事业部的供应商。

数据权限的实现方式主要有两种：

• 基于组织架构：用户所属部门决定了数据可见范围。比如“采购一部”只能看到“采购一部”的供应商。
• 基于数据归属：每条数据记录一个“负责人”或“创建部门”，用户只能看到自己或本部门的数据。

实际项目中，两种方式经常混合使用。比如默认按部门隔离，但管理员可以跨部门查看。

字段权限

字段权限控制的是“能看到哪些字段”。这在 SRM 系统中非常重要，因为供应商数据包含大量敏感信息。

• 银行账号、联系人手机号、营业执照照片，这些字段只有财务和合规人员能看到。
• 供应商的报价成本明细，只有采购经理和成本核算人员能看到。
• 供应商的评分和评级，只有采购主管和质量管理能看到。

字段权限的实现通常是在后端接口中做字段级别的过滤，前端根据权限动态显示或隐藏字段。注意：只在前端隐藏是不够的，必须在后端做拦截，否则直接调用 API 就能拿到数据。

部门数据范围的设计

部门数据范围是数据权限的一种具体实现，之所以单独拿出来说，是因为它在 SRM 系统中特别容易出问题。

典型的部门数据范围模型

假设一个企业有三个事业部：消费电子事业部、汽车零部件事业部、医疗设备事业部。每个事业部都有自己的供应商资源。事业部之间应该隔离，但集团总部需要跨部门查看。

这种情况下，数据范围设计需要考虑：

• 供应商的归属：每个供应商可以属于一个或多个部门。如果供应商同时为两个事业部供货，应该允许跨部门共享。
• 用户的部门归属：用户只能看到自己部门（及下属部门）的供应商。
• 跨部门授权：通过“数据共享规则”实现。比如事业部 A 可以将某个供应商共享给事业部 B，但 B 只能查看，不能修改。

实现时的常见陷阱

第一个陷阱是“部门树”的层级深度。有些企业部门层级很深，比如“集团-事业群-事业部-产品线-团队”。权限设计时不要试图在所有层级上都做数据隔离，通常控制在三级以内就够了。超过三级，建议用“数据域”的概念来扁平化。

第二个陷阱是“临时跨部门协作”。采购员可能因为一个项目需要临时查看其他部门的数据。这时不要改他的部门归属，而是用“临时授权”机制，设定时间范围和数据范围，到期自动收回。

第三个陷阱是“供应商自注册时的归属”。供应商在系统上注册时，应该选择自己属于哪个部门。如果选错了，后台需要能调整。这要求系统在注册流程中提供部门选择控件，并且采购部门能审核归属是否正确。

敏感字段的控制策略

SRM 系统中的敏感字段主要集中在供应商基础信息和交易信息中。

敏感字段的分类

• 财务敏感：银行账号、开户行、纳税人识别号、付款条款、应收应付余额。
• 联系敏感：联系人姓名、手机号、邮箱、地址。
• 商业敏感：报价明细、成本结构、历史成交价格、合同条款。
• 资质敏感：营业执照、许可证、认证证书、检测报告。

控制策略

**字段级加密存储**：对于银行账号、身份证号这类高敏感字段，建议在数据库层面加密存储。这样即使数据库被拖走，数据也是不可读的。加密密钥与权限系统分离，由专门的密钥管理服务管理。

**动态脱敏**：对于需要在界面上显示但不需要完整信息的场景，使用动态脱敏。比如联系人手机号显示为 138****1234，银行账号显示为尾号四位。脱敏规则可以按角色配置，财务人员可以看到完整手机号，采购员只能看到脱敏后的。

**操作审计**：对于敏感字段的查看和修改，必须记录详细的操作日志。谁、什么时间、查看了哪个字段、修改了哪个字段，都要记录下来。这部分后面审计追踪会详细说。

**导出控制**：导出的 Excel 或 PDF 中，敏感字段的处理方式必须与界面上一致。很多系统只在界面上做了脱敏，导出时却把完整数据放出去了，这是严重的合规漏洞。

审批流程中的权限控制

SRM 系统中的审批流程很多：供应商注册审批、供应商变更审批、采购订单审批、付款审批、合同审批。每个审批环节都涉及权限控制。

审批节点的权限

审批流程中的每个节点，都需要明确“谁能审批”。常见的做法是：

• 按角色指定：比如“采购经理”这个角色可以审批供应商注册。
• 按部门指定：比如“采购部负责人”审批本部门的供应商注册。
• 按金额范围：比如金额小于 10 万的订单由采购经理审批，10 万到 100 万由总监审批，100 万以上由副总裁审批。

注意：审批权限和功能权限是两回事。一个人可能没有创建采购订单的权限，但可以有审批采购订单的权限。这取决于业务流程设计。

审批中的数据可见性

审批人在审批时，能看到哪些数据？这是个容易被忽略的问题。

假设一个供应商变更申请，采购员提交了变更后的银行账号。审批人（财务经理）在审批时，应该能看到变更前后的对比，以及变更原因。但审批人不应该看到该供应商的其他历史交易数据，除非他本身有查看这些数据的权限。

也就是说，审批界面的数据可见范围，应该受审批人的数据权限约束，而不是因为他在审批流程中就能看到所有数据。

审批委托与代理

审批人出差或休假时，需要将审批权限临时委托给其他人。委托机制必须记录在审计日志中。谁委托给了谁、什么时间委托、什么时间收回、委托期间谁审批了哪些单据，都要可追溯。

代理审批和委托审批不同。代理是审批人主动设置一个代理人，代理人有独立的审批权限。委托是审批人将自己的权限完全交给另一个人。建议使用代理模式，因为代理人的操作记录仍然保留在代理人的名下，审计更清晰。

审计追踪的落地实践

审计追踪是 SRM 系统合规性的最后一道防线。审计日志记录什么、怎么记录、怎么存储、怎么查询，需要提前设计好。

审计日志记录的内容

至少记录以下信息：

• 操作人：用户 ID、用户名、部门。
• 操作时间：精确到毫秒的时间戳。
• 操作类型：查看、创建、修改、删除、导出、审批、驳回。
• 操作对象：操作的是哪个供应商、哪个采购订单、哪个合同。记录对象 ID 和对象类型。
• 操作详情：修改了哪些字段，修改前和修改后的值。如果是查看操作，记录查看了哪些字段。
• 操作来源：IP 地址、设备类型、浏览器 User-Agent。
• 操作结果：成功或失败，如果失败记录失败原因。

审计日志的存储

审计日志的数据量会非常大。一个中型企业每天可能产生几十万条日志。存储方案需要考虑：

• 热存储：近三个月的日志放在高性能数据库（如 PostgreSQL 或 Elasticsearch）中，支持快速查询。
• 冷存储：三个月以上的日志归档到对象存储（如 S3 或 MinIO）中，按天或按月打包。查询时需要先解压再搜索。

不要把所有日志都放在业务数据库里，否则业务表的查询性能会受影响。建议单独建一个审计日志库，甚至用独立的审计服务。

审计日志的查询

审计日志的查询功能是为审计人员和合规部门设计的。查询条件应该包括：

• 时间范围
• 操作人
• 操作类型
• 操作对象
• 关键字搜索（比如搜索某个供应商名称）

查询结果应该支持导出为 Excel 或 CSV，供审计人员进一步分析。

不可篡改的审计日志

有些行业（如医疗、金融）要求审计日志不可篡改。实现方式有两种：

• 写前日志：在写入业务数据之前，先写入审计日志。如果业务数据写入失败，审计日志也要回滚。
• 日志签名：每条审计日志写入时，用当前日志的 Hash 值加上上一条日志的 Hash 值生成签名。这样如果有人修改了中间某条日志，后面的签名都会对不上。

第二种方式更常用，实现成本也相对较低。可以在应用层做，不需要引入区块链这类复杂技术。

实施中的常见风险

权限配置过于复杂

风险：角色定义太多，数据范围规则太细，导致系统上线后管理员无法维护，用户频繁遇到权限不足的问题。

应对：权限设计遵循“够用就好”原则。初期只定义 5 到 8 个核心角色，数据范围只做部门级隔离。上线运行三个月后，根据实际需求逐步细化。不要试图在上线前就把所有场景都覆盖到。

审计日志影响性能

风险：每条操作都写审计日志，导致业务操作响应变慢。

应对：异步写入审计日志。业务操作成功后，将审计日志放入消息队列（如 Kafka 或 RabbitMQ），由单独的消费者写入日志库。这样业务操作的响应时间不受日志写入的影响。

敏感字段泄露

风险：接口返回数据时，敏感字段没有做过滤，前端虽然隐藏了但后端返回了完整数据。

应对：后端接口必须做字段级别的权限校验。建议在 API 网关层或服务层统一处理字段过滤，而不是在每个接口里单独写。这样即使新增接口，也不会忘记做字段权限控制。

审批流程绕过

风险：用户通过直接调用接口跳过审批流程，或者审批人能看到不应该看到的数据。

应对：审批状态必须在后端校验。前端隐藏审批按钮不够，后端接口必须判断当前单据的状态和当前用户的审批权限。任何跳过审批的状态变更都不应该被允许。

最佳实践总结

基于我在多个 SRM 项目中的经验，总结几点实践建议：

**权限设计从业务场景出发，不是从技术模型出发。** 先画出业务流程图，标注每个节点需要哪些角色、哪些数据、哪些字段，再转化为权限模型。不要直接套用 RBAC 的标准模板。

**审计日志是刚需，不是可选项。** 即使当前没有合规要求，也建议把审计日志功能做上。因为一旦出了问题需要追溯，没有日志就意味着没有证据。审计日志的存储成本不高，但事后补救的成本很高。

**权限和审计分开设计，但统一管理。** 权限系统和审计系统在技术实现上可以独立，但在管理界面上应该统一。管理员可以在同一个界面上配置权限和查看日志，减少运维复杂度。

**定期做权限审计。** 每季度检查一次角色权限配置，清理不再使用的角色和用户。很多企业的权限系统在运行一两年后，会积累大量僵尸角色和无效权限，这是安全风险。

**测试阶段要覆盖权限场景。** 功能测试通过不代表权限测试通过。建议在测试用例中专门设计权限相关的场景：越权访问、跨部门查看、审批绕过、敏感字段泄露等。SystemDo 在过往的 SRM 项目中，会把权限测试作为独立测试阶段，与功能测试并行执行，确保上线前权限逻辑完整。

结语

SRM 供应商管理系统的权限与审计设计，本质上是回答三个问题：谁能做什么、谁能看到什么、谁做了什么。角色权限解决第一个问题，数据范围和字段权限解决第二个问题，审计日志解决第三个问题。三个层面缺一不可。

企业在上线 SRM 系统时，不要只关注功能能不能用，更要关注权限和审计是否到位。因为供应商数据涉及采购成本、商业机密和合规要求，一旦出问题，损失往往不是功能缺失能比的。提前规划好权限与审计，比事后补救要省心得多。