SaaS 多用户系统怎么设计，普通用户和管理员的数据应该如何区分

发表时间： 2026-09-23 07:00:02 人气：82 次

一个SaaS系统从几十个用户发展到几万、几十万甚至百万用户之后，最容易出问题的地方之一并不是页面，而是数据边界。

用户A登录以后，为什么不能看到用户B的数据？同一个企业里的普通员工为什么不能看到财务部门的资料？企业管理员为什么能够管理本企业员工，却不能管理另外一家公司的员工？而平台自己的超级管理员，又应该拥有多大的权限？

这些问题表面上都是“权限设置”，实际上涉及SaaS系统最基础的数据模型。

设计多用户SaaS系统时，不能只考虑“用户是谁”，还必须同时判断“用户属于哪个组织”“正在访问哪个资源”“这个资源属于谁”“当前角色是否有权限执行这个动作”。

一、先搞清楚SaaS真正需要隔离的是什么

很多初学者设计多用户系统时，会想到给每一个用户建立一个数据库。

例如：

用户A → 数据库A

用户B → 数据库B

用户C → 数据库C

这种方式确实能够形成非常强的物理隔离，但通常不是普通SaaS系统的首选方案。

假设一个系统有100万用户，如果每个用户都有自己的数据库，数据库实例、连接、备份、升级、监控和故障处理都会迅速变得复杂。

更常见的设计是“共享数据库、逻辑隔离”。

例如订单表可以设计成：

orders

其中增加：

tenant_id

user_id

id

amount

created_at

这里的tenant_id就是整个多租户系统非常关键的字段。

它表示这条数据属于哪个租户，也就是哪家公司、哪所学校或者哪个组织。

用户查询数据时，系统不能只写：

SELECT * FROM orders

而应该根据当前登录身份自动加入租户条件，例如：

SELECT * FROM orders WHERE tenant_id = 当前租户ID

这样用户即使知道另外一条订单的ID，也不能仅仅通过修改URL中的ID就拿到其他租户的数据。

二、租户隔离比“用户隔离”更重要

真正成熟的SaaS系统，通常首先建立的是租户，也就是Tenant。

例如一个企业协作系统可能是：

平台

→ 公司A

→ 公司B

→ 公司C

公司A下面又有：

管理员

经理

员工

财务人员

普通成员

因此，权限关系并不是简单的：

管理员 > 普通用户。

而是至少包含三个维度：

用户是谁；

用户属于哪个租户；

用户对这个资源拥有什么操作权限。

例如，公司A的管理员可以管理公司A的员工，但并不意味着他能够管理公司B的员工。

这就是多租户系统和普通“用户登录系统”之间最大的区别之一。

三、不要把“管理员”设计成一个超级密码

很多小型PHP网站最开始的做法是：

普通用户进入前台；

管理员进入后台；

后台管理员拥有全部权限。

这种方式在系统规模较小时还能工作，但一旦进入真正的SaaS环境，就容易出现权限过大的问题。

更合理的方式是采用RBAC，也就是基于角色的访问控制。

例如：

系统超级管理员

租户管理员

部门管理员

财务管理员

普通员工

只读用户

不同角色拥有不同权限。

甚至可以进一步把“角色”和“权限”分开。

角色决定用户属于哪一种身份，而权限决定这个身份可以执行什么操作。

例如：

user.read

user.create

user.update

user.delete

invoice.read

invoice.approve

invoice.export

这样以后增加新的角色，不需要重新编写大量程序，只需要重新组合权限。

四、权限检查必须发生在服务器端

这是很多系统最危险的地方。

前端页面隐藏一个“删除”按钮，并不等于用户没有删除权限。

例如JavaScript把：

“删除用户”

这个按钮隐藏起来。

攻击者完全可以直接向服务器发送：

POST /api/user/delete

如果服务器只检查“用户是否登录”，而没有检查“用户是否拥有删除权限”，那么所谓的前端权限控制实际上没有任何安全价值。

因此真正的权限检查必须发生在后端。

服务器收到请求以后，至少应该确认：

当前用户是谁；

属于哪个租户；

当前角色是什么；

请求访问的资源属于哪个租户；

这个角色是否拥有对应操作权限。

只有全部满足条件，服务器才执行操作。

五、最危险的问题其实是ID越权

假设一个系统有：

/invoice/10001

用户A可以查看10001号发票。

如果用户把地址改成：

/invoice/10002

系统就直接返回另一家公司的发票，这就是典型的对象级授权漏洞，也经常被称为IDOR。

数据库本身可能完全正常。

登录系统也可能完全正常。

问题出在服务器没有检查：

“这张发票是不是属于当前用户或者当前租户？”

所以，任何涉及资源ID的API，都不能只根据ID查询。

应该同时加入所有权或租户条件。

例如：

SELECT * FROM invoices WHERE id = ? AND tenant_id = ?

这一个设计习惯，对于SaaS数据隔离非常重要。

六、管理员数据和普通用户数据不一定要放两个数据库

原稿提出“普通用户独立数据库、管理员独立管理数据库”，这在某些高安全场景确实可以采用，但并不是通用SaaS架构。

管理员本身也是系统中的一种身份。

例如：

users

保存用户身份；

roles

保存角色；

permissions

保存权限；

user_roles

保存用户与角色之间的关系。

业务数据则按照：

tenant_id

进行隔离。

管理员执行操作以后，通过审计系统记录：

谁做的；

什么时候做的；

对哪个租户；

操作了什么对象；

执行了什么动作；

修改前是什么；

修改后是什么。

这样比简单地把“管理员数据”搬到另一个数据库更加完整。

当然，如果平台涉及医疗、金融、政府或者其他具有严格合规要求的数据，可能需要进一步采用独立数据库、独立密钥、独立网络区域甚至独立部署。

隔离等级应该由业务风险决定，而不是为了“看起来安全”就无限增加系统复杂度。

七、平台管理员和企业管理员必须区分

这是SaaS系统经常忽略的一层。

例如一个在线企业管理平台：

平台管理员负责整个SaaS平台。

公司A管理员只负责公司A。

公司B管理员只负责公司B。

这两个角色不能混为一谈。

公司A管理员可能可以：

创建员工；

删除员工；

修改员工权限；

查看公司A的数据。

但他不能：

查看公司B客户名单；

修改公司B员工；

导出整个SaaS平台的数据。

而平台超级管理员可能拥有更高权限，但这种权限也应该受到审计和限制。

这样才能避免一个企业管理员因为程序漏洞获得整个系统的数据访问能力。

八、管理员访问数据并不是“绝对禁止”，而是需要被控制

有些SaaS平台会宣传“管理员绝对无法看到用户数据”。

从技术架构上看，这句话往往需要非常谨慎。

如果平台需要提供故障排查、客户支持、数据恢复或者安全调查，那么某些高权限人员在特定条件下可能需要访问客户数据。

真正成熟的设计不是简单说“管理员永远不能看”，而是建立严格的访问机制。

例如：

普通管理员没有客户数据读取权限；

需要访问时必须提交工单或审批；

敏感操作需要二次认证；

访问行为全部记录；

高风险操作可以要求双人审批；

访问结束后自动失效。

这样管理员权限就从一个长期存在的“万能钥匙”，变成一个受到控制的临时能力。

九、审计日志应该和业务数据分开考虑

管理员修改数据以后，系统不能只留下“updated_at”。

因为：

updated_at = 2026-08-24

只能说明数据什么时候被修改，却不能说明谁修改的、修改了什么。

审计日志可以记录：

actor_id

tenant_id

action

resource_type

resource_id

before

after

ip

user_agent

created_at

例如管理员把某个员工的权限从普通用户改成财务管理员，审计记录应该能够回答：

谁修改的？

为什么有权限修改？

修改的是哪个用户？

修改前是什么权限？

修改后是什么权限？

什么时候修改？

从哪里发起？

对于高价值数据，这种审计能力甚至比单纯的数据库备份更加重要。

十、MFA不是替代权限控制，而是保护高权限账户

多因素认证非常重要，但它解决的是“这个人是不是本人”的问题。

权限控制解决的是“这个人即使是本人，到底允许做什么”。

两者不能混为一谈。

例如一个企业管理员已经通过MFA登录，并不意味着他因此拥有导出所有企业数据的权限。

合理的系统应该是：

身份认证 → 判断用户是谁

租户识别 → 判断属于哪个组织

角色判断 → 判断是什么身份

权限检查 → 判断能执行什么操作

资源授权 → 判断能操作哪一条数据

审计记录 → 保存操作证据

这几层共同构成SaaS的安全边界。

十一、数据库层最好再增加一道防线

如果所有数据隔离都依赖PHP、Node.js或者Java应用代码，一旦程序员某个查询漏写了tenant_id，就可能产生严重的数据泄露。

因此，在安全要求较高的系统中，可以进一步利用数据库本身提供的能力。

例如部分数据库支持Row-Level Security，也就是行级安全策略。

这样即使应用程序执行了一个过于宽泛的查询，数据库层也可以根据当前用户身份限制能够看到的记录。

对于大型SaaS系统，还可以进一步采用独立Schema、独立数据库甚至独立实例。

这些方案的成本和隔离程度不同。

共享表：

成本最低，管理简单。

独立Schema：

隔离程度更高。

独立数据库：

隔离更强，但运维复杂度增加。

独立实例：

隔离等级最高之一，但成本也最高。

没有一种方案适合所有SaaS。

十二、性能设计不能用“缓存权限”解决所有问题

当用户达到百万级以后，权限检查确实可能成为性能问题。

但解决办法不是简单地把所有权限永久放进缓存。

可以把相对稳定的角色和权限关系进行缓存，同时设置合理的失效机制。

例如管理员修改员工权限以后，旧权限缓存必须及时失效。

否则数据库中的权限已经改变，缓存仍然认为这个用户拥有旧权限，就可能形成安全漏洞。

因此权限缓存需要同时考虑：

速度；

一致性；

失效；

权限变更传播。

安全系统里，“快”永远不能成为放弃正确授权的理由。

十三、SaaS最值得采用的基础架构是什么

对于绝大多数中小型SaaS项目，一个比较实用的基础模型可以是：

用户表负责身份。

租户表负责组织。

角色表负责角色。

权限表负责具体能力。

用户角色关系负责授权。

业务表通过tenant_id进行租户隔离。

重要API执行服务器端授权。

管理员操作写入审计日志。

高权限账户启用MFA。

数据库备份与审计日志独立管理。

随着业务规模和安全要求增加，再逐步升级到独立Schema、独立数据库或者独立实例。

这种设计比一开始就给每一个用户建立一个数据库更加容易维护。

十四、真正需要防范的是“跨租户访问”

SaaS安全设计最后可以归结成一个非常简单的问题：

“当前这个人，为什么能够看到这条数据？”

如果程序无法明确回答这个问题，权限体系就还不够成熟。

用户登录，只能证明身份。

管理员身份，也不能自动证明对所有资源拥有无限权限。

一个请求从进入服务器开始，就应该经过身份认证、租户识别、角色判断、资源授权和审计记录。

而数据库中的每一条重要业务数据，都应该能够明确回答“它属于哪个租户”。

SaaS系统最大的安全风险往往不是数据库服务器被黑客直接攻破，而是一个看似普通的API因为漏掉了一项授权检查，让公司A的用户能够读取公司B的数据。对于多租户系统来说，最重要的安全边界不是“管理员页面和普通用户页面长得不一样”，而是从数据库、API到权限模型，每一层都必须知道数据属于谁、谁可以访问，以及为什么可以访问。

当系统规模扩大以后，再根据业务风险决定是否采用独立数据库、独立部署、专用密钥等更高级的隔离方式。这样既能控制安全风险，也不会因为一开始的过度设计，把一个本来简单的SaaS系统变成难以维护的数据库工程。

分享 Facebook | X | Whatsapp | Linkedin

捐助（Paypal）: https://www.paypal.me/observeccp
订阅中国观察电报 Telegram : https://t.me/s/ObserveCCP

责任编辑：雨轩来源：中国观察转载请注明作者、出处並保持完整。

今日热点:

更多新闻...

近期焦点:

推荐文章

通胀降温改变市场预期：美联储9月还会加息吗？投资者押注正在转向

美国金融市场正在发生一个微妙但重要的变化。过去几个月，投资者一直担心一个问题：关税、能源价格以及服务业价格压力，会不会让美国通胀重新升温，从...

2026年8月13日　 22652

阅读全文 →

AI科技股再遭重挫高投入时代开始面对回报考验

全球人工智能概念股在短暂反弹后再度遭遇抛售，半导体、数据中心及大型科技公司股价承压。美国纳斯达克指数期货走低，亚洲科技股同步下跌，投资者重新审视人工智能产业...

2026年10月22日　 17416

阅读全文 →

五中全会前北京官场传闻升温夏林茂去向牵动蔡奇旧部与高层权力观察

发表：2026-10-20 22:30:54 | 更新：2026-10-20 22:30:54 人气: 79700

【中国观察北京时间2026年10月20日讯】中共二十届五中全会临近，北京官场一则涉及常务副市长夏林茂的消息引发关注。独立时评人蔡慎坤在社交平台X发文称，夏林茂已于10月19日被中纪委带走，并出现被抄家的迹象。相关说法迅速传播，也引发外界对北京官场人事变化以及中共高层政治关系的猜测。

截至目前，尚未找到足以独立证实夏林茂被带走调查或遭到抄家的官方通报及可靠的多方交叉证据。北京市政府公开资料仍将夏林茂列为市委常委、常务副市长。因此，这一消息目前仍应视为有待核实的传闻，而不是已经确认的官员落马事件。

夏林茂的仕途与北京权力结构

夏林茂出生于1970年，拥有工学博士学位，长期在北京地方党政系统任职。他曾担任北京市规划部门职务，之后出任石景山区区长、密云区委书记、东城区委书记。2021年，他升任北京市委常委，并曾负责教育领域工作；2023年1月转任北京市政府党组副书记、副市长，负责市政府常务工作。

这条仕途轨迹使夏林茂成为观察北京官场人事变化的一个重要人物。北京市委、市政府的领导职位不仅关系地方行政事务，也涉及财政、城市建设、规划、重大项目和干部管理等领域。处于这一层级的官员一旦被正式宣布接受调查，通常会引起外界对其主管领域、相关决策及干部关系的进一步关注。

不过，干部在某一任市委书记任内得到提拔，并不足以证明双方存在牢固的私人派系关系。夏林茂在蔡奇主政北京期间获得重要职务，这是可以依据公开履历讨论的事实；将其直接定性为蔡奇的“嫡系”，或据此推断某种高层政治交易，则需要更多证据。

蔡奇曾担任北京市委书记，后来进入中共中央政治局常委会并担任中央书记处书记。由于其长期参与中央党务和重要协调工作，外界一直关注他与北京干部队伍之间的关系。如果夏林茂确实遭到调查，相关影响当然值得观察，但在事件尚未证实之前，不能据此断言蔡奇的政治地位已经受到冲击。

传闻为何容易与高层政治博弈联系起来

中共官场具有高度集中的权力结构，重要人事安排通常由党内体系决定，外界难以完整了解干部考察、内部审查及决策过程。纪律审查消息在正式公布之前，往往缺乏透明、可供公众核验的完整信息。这种信息不对称，使网络传闻容易与派系斗争、权力更替和政治清洗等解释联系在一起。

中共近年来持续以反腐败为名开展纪律审查。官方公布的案件通常强调被查干部违反政治纪律、组织纪律或廉洁纪律等问题，但对于调查启动的具体过程、内部决策依据以及不同案件之间是否存在政治关联，公开资料往往有限。

反腐败调查可以涉及真实的贪腐问题，也可能与干部任用、权力监督及党内政治秩序发生联系。判断某一案件的性质，需要分别考察正式指控、已经披露的证据、调查时间线和相关人员的实际职务关系，不能仅凭传闻便把所有人事变化归结为派系斗争。

同样，网络上有关北京市政协主席魏小东被查的说法，也需要以可靠报道或正式公告核实。若无法确认其是否确实被调查，就不能将这一说法作为蔡奇承受政治压力的既定依据，更不能把多则未经证实的消息相互拼接，构造出已经发生的高层权力冲突。

五中全会前夕，外界应关注什么

如果夏林茂被调查的消息最终得到证实，外界可以进一步关注三个方面：第一，官方通报是否说明涉嫌违纪违法的具体性质；第二，北京市政府及市委是否出现正式的人事调整；第三，调查是否延伸至其曾经主管的部门、重大项目或相关干部。

这些信息比单纯猜测谁是某人的旧部更有助于理解事件。假如调查涉及重大工程、城市规划、财政资金或干部任用，就应进一步追问相关决策如何形成、监督机制为何未能及时发现问题，以及公共资源是否受到损害。如果最终只有干部职务调整，而没有调查公告或案件说明，也不应直接把人事变化解释为刑事调查。

对于中共高层而言，五中全会前后的人事安排自然具有政治意义，但会议临近本身并不能证明某名官员遭到调查就是派系斗争的结果。政治观察必须建立在可以核验的时间线和事实之上，才能避免把猜测误当成内幕。

更值得持续追问的是，中共反腐机制究竟能否形成稳定、透明且可监督的制度约束。倘若官员的政治前途高度依赖上级信任，而调查信息又主要由党内机构掌握，公众便很难独立判断案件究竟源于贪腐、失职，还是其他政治因素。缺乏公开程序和有效外部监督，不仅让官场传闻不断滋生，也削弱了社会对权力运行的信任。

截至10月20日，夏林茂被中纪委带走及遭到抄家的消息仍缺乏充分的独立证据。后续应以官方公告、可靠媒体的交叉核实及可验证的人事变化为依据。若相关消息得到证实，其具体案情、涉及领域及对北京官场的影响才有进一步分析的事实基础；若消息最终被证明不实，也应及时更正。对权力的监督需要保持警觉，更需要事实支撑。

本文由中国观察編輯部原创。为了促进信息自由传播，本平台原创内容全面开放转载，无须申请授权，只需注明来源、保留原文链接，即可全文转载、引用、翻译。我们不追究版权，只在乎公正的传播。

捐助（Paypal）: https://www.paypal.me/observeccp
订阅中国观察电报 Telegram : https://t.me/s/ObserveCCP

最近文章: