SAAS客户管理系统怎么管权限？租户隔离与部门隔离差在哪，字段级脱敏要落到手机号与身份证，谁能看到客户手机号必须能查到记录

自有系统生产库里，权限点在表里有 1569 行，但去掉重复之后只有 81 个不同的按钮编码；角色 61 个、角色与权限的关联 3682 条、角色与菜单的关联 3407 条、数据范围配置 61 条；操作日志 7264 条，分十种动作，一条「查看」都没有。

这五个数字放在一起，能回答一个很实际的问题：SAAS客户管理系统的权限，到底能管到多细，以及管不到的那一块长什么样。很多机构上线后才发现，按钮权限配得很细，但「谁看了客户手机号」这件事永远查不出来——不是管理员偷懒，是这张表里压根没有这种记录。

这篇只讲三级隔离（租户、部门、字段）在系统里分别落到哪张表、哪个字段，以及每一级配完怎么当场验证。角色怎么切、职级怎么分，站内《助贷CRM权限怎么分级》已经写过，本篇不重复，只补它没讲的「SAAS 形态下这三级的实测缺口」。文中数字全部来自自有系统生产库实测（2026-10-27），只描述结构与配置，不涉及任何真实客户信息。

一、SAAS客户管理系统管权限：三级隔离问的是三个不同的问题

权限配不明白，通常是把三个问题混成一个。拆开看，它们各自回答一句话：

第一级，租户隔离——「你会不会看到别人公司的数据」。这一级不是靠角色做的，是靠每条数据上挂的那个租户标识做的。角色配错了顶多让人少看几条，租户这一级配错了，看到的是别家机构的客户名单。

第二级，部门隔离——「同一家公司里，你能看到谁的数据」。这一级回答的是范围：只看自己名下、看本部门及下级、还是看全公司。它不控制字段，只控制行。

第三级，字段隔离——「一条数据摆在你面前时，哪几列是打码的」。手机号、证件号这类列的可见性，跟前两级不是一个维度：范围给了你这条客户，不代表你能看到完整号码。

三级的关系是乘法，不是加法。范围给对了、字段没脱敏，等于把整份名单交出去；字段脱敏了、范围给错了，人能看到不属于他的客户，只是号码打了码——客户名称、公司、跟进记录照样能拿去用。所以配置顺序也应该是这个顺序：先确认租户标识覆盖到哪些表，再定数据范围档位，最后才做字段打码。反过来做，前两级一改，字段配置要跟着重来。

三级还有个容易混淆的地方：它们在数据库里不在同一张表。租户靠数据行上的租户标识，数据范围靠一张按角色存档位的表，字段脱敏则根本不落库、只在接口返回时算一遍。所以排查问题时不能只翻一个界面——「看不到客户」和「看不到号码」是两个完全不同的问题，前者查范围表和归属链，后者查展示逻辑。助贷CRM权限怎么分级里讲过角色怎么按职能切，那部分本篇不复述，只把「怎么验」这一层补上。

二、租户隔离怎么证明：权限表的行数和去重后的编码数对不上

先看一组能直接跑出来的数：按钮权限表 1569 行、去重后 81 个编码、覆盖 20 个租户，每租户 78 到 80 行。三个数一除就能看出来——这 81 个按钮是按租户各存了一份副本，不是一张全局字典。

这意味着两件事。第一，新增一个按钮权限点，要往 20 个租户各写一行，漏一个租户，那个租户的界面上就少一个按钮，而且不会报错。第二，改按钮名称也是改 20 份，改完如果发现两个租户的文案不一样，那是正常现象，不是数据被改坏了。

再看数据范围表：61 行，正好等于 61 个角色，也就是一个角色一行。这张表的关键在它的关联方式——存的是角色编码（文字），不是角色 ID。这个设计有个直接后果：同一家公司里角色编码不会重，但跨租户会重，20 个租户里每个都有一个叫 tenant_admin 的管理员角色。

我本地就踩过一次：按角色编码关联角色表和权限关联表，算出「管理员角色有 31380 条权限」，数字大得离谱。原因就是编码跨租户重复，20 个租户的管理员被当成一个角色累加了。正确的口径是 角色编码 + 租户 ID 双键关联，按双键算出来的总量是 3682 条，跟表里的行数对得上。

这一级的当场验收动作：跑一句「按钮权限总行数」和「去重编码数」，两者差得越多，说明按租户复制的份数越多；再拿两个不同租户的账号，看同一个页面上按钮数量是否一致，不一致说明有租户漏了权限点。这两步五分钟能做完，比翻配置界面快。

还有一层要顺手确认：租户标识到底覆盖了多少张表。库里 74 张表，带租户标识的 62 张，剩下 12 张不带——文章表、分类表、节假日表、平台管理员表这些不带是合理的，但如果哪天新建了一张业务表忘了加这一列，它就成了跨租户可见的表。每次上新的业务表，第一件事是问「这张表有没有租户列」，第二件事是问「查询接口有没有按它过滤」。两句话都答得上，这张表才算进了隔离范围。

三、部门隔离：三个档位存在哪张表，以及为什么开了它可能谁都看不到

数据范围在这个系统里是单独一张表，一个角色一行，取值只有三个：self 21 行、all 20 行、dept_and_sub 20 行。三个档位的含义分别是只看本人、看全公司、看本部门及下级部门。

这三个值是文本字段，不是枚举表。好处是加档位不用改表结构，坏处是写错一个字就没有任何约束能拦住——写 self 和写 SELF，在系统里是两回事。所以配置时的第一条规矩：档位值要么从界面上选，要么照抄已有值，别手打。

真正的问题不在档位，在部门隔离依赖一条链：客户 → 归属人 → 归属人所在部门。这条链上任何一环是空的，部门隔离就失效。而这条链在实测数据里断得很厉害：

客户表 606 行，归属人有值的只有 19 行（3.1%），587 行是空的；员工表 33 名在职，22 人没有挂部门，只有 11 人有部门，部门负责人 3 个。也就是说，如果今天把某个角色的范围改成「本部门及下级」，这个角色登录后大概率看不到任何客户——不是权限配错了，是这条链上没有数据可算。

这个现象容易被误判成 bug。正确的处理顺序是反过来的：先把客户归属补齐，再开部门隔离。补齐的标准很简单——每个在职员工名下至少要有客户，且这些员工都挂了部门。补不齐之前，部门隔离这一档先别开，让主管用「指定共享」或者「按名单池分配」来过渡。

还有一种半开状态要避免：一部分角色开 all、一部分开 dept_and_sub。这时候同一个部门的两个人看到的数据量可能差几倍，主管会以为系统统计错了。同一家公司内，档位要么按职能成套配，要么先统一成 self，别混着来。

开部门隔离失败的三个典型症状，可以先对着看：症状一，主管登录后客户列表是空的，但管理员能看到同一批客户；症状二，同一条客户两个销售都说自己看不到，管理员点进去发现归属人是空；症状三，某个部门的人只看到一两条，因为那个部门只有一个人名下有客户。

三个症状指向同一件事：范围是算出来的，不是配出来的。系统按「归属人 → 部门」现算，归属为空的行归不到任何部门，就谁都看不到。所以补数据这一步没法跳过——先把客户按名单池分下去、把离职员工的客户转交出去，再开档位。

补归属的时候顺手做两件事：一是把「无归属客户」单独拉一个清单，这批客户要么进公海池重新分配，要么指定一个人接；二是把员工与部门的一次性对齐，22 个没挂部门的人里，如果还在正常办公，就必须选一个部门，否则他在部门隔离下等同于不存在。这两件事做完，部门隔离才算能开。团队结构那张表怎么记，助贷团队管理制度里有现成的五张表，归属表是其中第一张。

四、字段级脱敏：客户手机号这一列现在是什么状态

客户表 40 列，跟个人信息直接相关的只有三列：客户名称、手机号、销售名称。有两个事实要先说清楚：

第一，这张表里没有证件号字段。不是脱敏了，是没有这一列。所以「身份证要脱敏」这种说法，在落地时第一步不是配脱敏规则，而是先决定要不要加这个字段、加了存在哪、谁能填。很多机构的实际情况是：证件号在进件材料里，不在客户档案里，那就应该按材料权限管，而不是按客户字段管。

第二，全库除三个密码哈希列之外，没有任何加密或掩码字段。手机号是明文存储。这意味着脱敏只能在展示层做：接口返回时按角色打码，前端拿到的就是 138****1234。存储层没有第二道防线——一旦有人拿到数据库备份或者导出了一份 Excel，打码规则一条都用不上。

所以字段级脱敏要落成三件事，缺一件就不算配上：

一是列级清单。不要笼统说「敏感字段脱敏」，要写出列名：手机号、证件号（如果新增）、对接人手机、备注里可能出现的号码。清单要能对应到表里的字段名，写不出字段名的清单，开发没法落地。

二是谁能解锁。打码之后必须有一条解锁路径，否则坐席没法打电话。合理的做法是按角色给：坐席默认打码、点「查看完整」输理由后解锁；主管直接看完整；财务、运营这类岗位永久打码。

三是解锁动作能不能查。这一条决定了脱敏是不是真的有约束力——下一节专门说，因为现在的日志答不上来。

当场验的动作：拿一个普通销售账号打开客户详情，手机号应该显示成前三后四；点「查看完整」，要么要求输理由，要么直接被拒。如果点开就是完整号码，说明脱敏这一级根本没生效，前面两级配得再细也没用。

打码有三个实现位置，防护力完全不同。前端打码最省事，接口把完整号码发下来，页面上用星号盖住——防的是截图，防不住开发者工具；接口层打码好一档，返回前就换成星号，前端拿不到原文，但列表页和详情页要各自实现一遍，容易一处漏；导出文件打码最容易被忘，页面上打了星号，导出的 Excel 里却是完整号码，这一条在很多机构里是实际发生过的事故点。

三个位置都要做，顺序是接口层 → 导出文件 → 前端。接口层做完，前端自然就没有原文可用；导出文件那条要单独测一次，因为很多导出是另一套代码路径。导出这一块的完整防线，助贷客户资料怎么防止被导出讲得比这里细，本篇只留一句：页面上打了码不算脱敏，导出文件里打了码才算。

五、谁能看到客户手机号：为什么现在的日志答不上来

这是本篇最该被记住的一组数。操作日志 7264 条，按动作拆开是这样的：

新建 5817 条、修改 1215 条、删除 69 条、审批 62 条、提交 47 条、导出 37 条、领取 9 条、退回 5 条、拉黑 2 条、驳回 1 条。十种动作，全是「写」。而「查看」「查询」「搜索」「下载」「打印」这几类动作，加起来 0 条。

按模块看，通话记录 4072 条、客户 1406 条、消息 1079 条、登录 130 条、进件 102 条。客户模块这 1406 条里，修改占 1093 条、新建 254 条、导出 37 条。也就是说，客户档案这块记录得不算少，但记的都是「改了」。

更麻烦的是明细。客户模块的修改日志里，明细字段是空的，对象字段只留了 8 位短码。这意味着即便你知道「某人在 3 点 12 分改过一条客户」，也说不出他改的是手机号还是备注——字段级的前后值没有落库。

结论很直接：「谁在什么时候看了哪条客户手机号」，用现在这张表答不出来。这不是配置问题，是表结构少了两样东西。要让这句话变成可查的记录，至少要补三列和一个动作类型：

动作类型补一个 view，跟新建、修改并列，专门记查看；目标对象补到字段级，加一列记字段名（phone 还是 id_card），再加一列记查看理由；明细列真正写内容，修改动作要能存「旧值 → 新值」，否则改了什么都说不清。

补的时候有两条规则要想清楚。第一条，只记敏感列的查看，不要给每次翻页都写一条日志——现在这 7264 条只覆盖 2026-08-24 到 2026-10-26 这两个月，全量记查看会让它膨胀几十倍，查询反而更慢。第二条，保留期单独定，查看日志的价值在事后追溯，通常比业务日志留得久，别跟业务表用同一个清理周期。

表结构落成什么样，可以直接照这个写：日志主表加三个字段——动作类型（枚举，补 view）、字段名（文本，记 phone 或 id_card 这类列名）、理由（文本，解锁时必填）。明细列从空文本改成结构化存储，存「旧值 → 新值」，这样改手机号这件事才能回放到具体某一位数字。

另外两类动作值得单独看一眼：拉黑 2 条、退回 5 条。这两个数字小，但它们代表客户从谁手上离开，是防飞单和防撞单最直接的两个证据。数量这么少，说明这两个动作在业务上用得很少，而不是系统记漏了——如果机构实际有大量客户被退回公海，日志里应该能看到对应规模的记录，对不上就是动作没接日志。

顺带说一句审计与合规的关系：客户授权、通话录音、进件材料这六类记录怎么在十分钟内调出来，助贷机构怎么做合规留痕里逐类拆过。本篇补的是它没覆盖的一类——「谁看了」这类内部访问记录。它不在那六类里，但出事时往往第一个被问。

还有一层是租户与数据落点的关系：日志表同样带租户列，跨租户查日志的口子要堵住，否则一个租户的管理员能通过日志看到别家的客户名称。SaaS系统的数据到底放在哪里把 74 张表按「带不带租户列」分过一遍，日志表在这份清单里属于必须带的那一类。

六、导出这一道门要单独管

导出是那个「一次动作带走一批数据」的功能，所以它不能跟查看共用一套权限。日志里导出动作 37 条，全在客户模块，说明这个动作在系统里是被记录了的——但明细同样是空的，记了「谁导了」，没记「导了几条、哪些列」。

这一层怎么和机构本身的业务边界对齐，金融居间CRM与普通CRM的差异里从「服务可举证」的角度讲过一遍，导出记录恰好是其中最容易被引用的一份。导出要配三道：谁能导（角色维度，销售默认不给，主管给审批后的临时权限）、单次能导多少（条数上限，超过走审批）、导出了什么（字段清单 + 条数 + 文件名，写进日志）。三道的落地顺序是后者先做——没有日志，前两道出问题时你都不知道发生过什么。

另外一条容易被忽略：导入也是同一类动作。批量导入的模板里如果带手机号，导入日志要能记到「这个文件多少行、成功多少、失败原因」，否则一批脏数据进来，事后连哪个文件都追不回来。

这两道门（导出、导入）在 SaaS 形态下还多一层考虑：数据一旦落成文件，就脱离了系统里那套打码规则。所以导出文件本身要带痕迹——文件里写清导出人、导出时间、条数，必要时加一列水印。SaaS客户管理系统有哪些里讲形态时提过一句「配置面能改的只有参数」，导出水印属于参数还是属于定制，签合同前就该问清楚，别等出事才发现要改代码。

七、配完当场怎么验：五个动作，二十分钟跑完

权限这类配置最怕「看起来生效了」。下面四个动作，建议每改一次权限就跑一遍，二十分钟能跑完：

动作一，三个账号看同一条客户。建管理员、主管、销售三个测试账号，都打开同一个客户的详情页。管理员看全字段、主管看全字段、销售看打码——三个结果对不上任何一条，说明三级里有一级没生效。

动作二，查一次范围档位。把数据范围表按角色列出来，看每个角色的档位值是不是预期的那三个之一。文本字段没有约束，这一步是为了抓错别字。

动作三，制造一次查看并回查日志。用销售账号点「查看完整手机号」，然后按时间倒序查最近的日志。如果日志里没有新增记录，说明查看动作没接上审计——这一条不过，脱敏就只是「看起来打了码」。

动作四，试一次超量导出。用销售账号导 100 条客户，看是被直接拒绝、还是进了审批、还是导成功了。三种结果对应三种配置状态，第三种是必须马上处理的。

验完把这四步的结果记在一张表上，跟着权限变更一起存档。下次换人、换部门、换角色，照这张表再跑一遍，比让新人从界面上反推配置快得多。

再加第五个动作，专门验租户这一级：拿 A 租户的账号，去请求 B 租户某条客户的详情 ID。预期结果是 404 或者「无权访问」，如果返回了数据，说明这个接口只按 ID 查、没按租户列过滤。这个动作比界面上的互相搜索更准，因为搜索通常带租户条件，而详情接口容易漏。

验收清单可以简化成一句话：三个账号看到的东西不一样、日志里能查到最后一次查看、超量导出被拦住、跨租户请求拿不到数据。四件事都成立，三级隔离就算配完了；缺哪一条，就把那一条对应的表拿出来单独看。功能清单这一层怎么和权限对齐，CRM客户管理系统有哪些功能按模块列过，配权限时建议照着模块顺序走一遍，别漏掉报表和字典这两块——它们经常被当成「只读」而放过，实际上报表能导出、字典能改枚举值，都是会动数据的地方。

八、SAAS客户管理系统管权限的常见问题

问：部门隔离和数据范围是一回事吗？

是一件事的两种叫法：数据范围就是部门隔离的那个「档位」。区别在于口径——讲「数据范围」时说的是三档取值（本人、本部门及下级、全公司），讲「部门隔离」时说的是它依赖的那条链（客户归属人到部门）。配置时盯档位，出问题时查那条链。

问：只做脱敏不做审计，行不行？

不行，但也不是完全没用。脱敏能挡住「顺手拍照」「截屏发出去」这类动作，挡不住「有权限的人慢慢抄」。审计的作用是让抄这个动作有代价——知道有人会回查，行为会变。所以脱敏和审计要一起上，先上哪个都行，但不能只上一个。

问：租户之间会不会串数据，怎么验？

验的方法很土但有效：拿两个租户的账号，各自建一个名称相同的客户，然后互相搜这个名称。搜得到就是串了。再进一步，用其中一个租户的账号去请求另一个租户的客户 ID，接口应该返回 404 而不是数据——返回数据说明接口只按 ID 查、没按租户过滤。

问：权限配完多久复查一次？

三个时点必须查：新员工入职、员工离职或转岗、角色权限改动。这三个时点之外，建议每季度看一次「谁的档位是 all」——这个名单会自己长大，涨到十几个人时，等于没有隔离。离职这一项尤其要当天做，账号停用和客户移交是一套动作，不能只做一半。