一、问题:权限做错,轻则越权,重则数据泄露

独立开发者做后台和 SaaS 时,最常见的临时方案是「先判断一下是不是管理员」。功能越加越多,判断散落在几十个接口里,新同事(哪怕是未来的自己)根本说不清谁能做什么。等到出现第一个越权访问,才发现没有统一的地方可以排查。

权限不是登录之后顺便加的一个字段,而是一套贯穿数据模型、接口设计和运营流程的约束。做得早,成本很低;补得晚,改一处漏三处。

二、先理清概念:认证与授权是两件事

· 认证回答「你是谁」,对应登录、令牌、会话;

· 授权回答「你能做什么」,对应角色、权限点、资源归属;

· 主体是用户、服务账号或外部应用;

· 资源是要保护的对象,比如订单、文档、配置;

· 动作是对资源的操作,比如读取、修改、删除、导出。

把这几件事分开建模,后面的规则才能表达清楚;混在一起写,权限逻辑很快就会变成一堆 if 判断。

三、从角色开始:RBAC 是最实用的起点

· 权限点先定义清楚,例如订单读取、订单退款、成员邀请;

· 角色是一组权限点的集合,而不是一个字符串;

· 用户通过角色获得权限,避免直接绑定大量权限点;

· 系统内置角色与自定义角色分开,内置角色不要随意修改;

· 角色的变更要可追溯,谁在什么时候加了什么权限。

RBAC 不能解决所有问题,但它能把「谁能做什么」从代码里抽出来,变成可配置、可审查的数据。

四、权限粒度:接口、数据与字段要分开考虑

· 接口级:能不能调用这个操作;

· 数据级:只能看到属于自己或自己组织的数据;

· 字段级:同一资源里,敏感字段是否可见;

· 操作级:可见但不可改、可改但不可删等细分;

· 导出与批量操作单独授权,风险远高于单条操作。

很多越权事故不是接口没鉴权,而是接口鉴权了、却没有校验数据归属,换个 ID 就能读到别人的数据。

五、多租户:把租户当成不可跨越的边界

· 每条业务数据都带租户标识,且由服务端写入而不是客户端传入;

· 查询默认附加租户条件,避免漏写导致跨租户读取;

· 跨租户的运营操作要有显式的特权标记与审计;

· 成员邀请、角色分配都限制在租户内部;

· 数据库层面可以考虑行级隔离作为最后一道保险。

多租户的漏洞往往来自「某一次查询忘了加条件」,因此需要机制兜底,而不是依赖每个人都记得。

六、检查位置:集中与分散要互相补充

· 统一的鉴权入口负责登录态与基础权限判断;

· 业务内部负责数据归属与业务规则校验;

· 敏感操作在服务端二次确认,不信任前端传来的任何身份字段;

· 前端隐藏按钮只是体验优化,不是安全措施;

· 公共接口与内部接口使用不同的鉴权策略。

把所有判断放在一个地方会过于粗放,散落在各处又难以维护,正确做法是分层,而不是二选一。

· 新角色默认没有权限,按需逐项授予;

· 服务账号只给完成任务所需的最小范围;

· 临时权限设置有效期,用完自动回收;

· 高危操作要求更强验证,比如二次确认或额外授权;

· 定期清理不再使用的角色与密钥。

默认允许的系统,漏洞是常态;默认拒绝的系统,最多是功能不方便,而后者可以修。

八、会话与令牌:权限变更要及时生效

· 访问令牌短有效期,刷新令牌可撤销;

· 角色或权限被收回时,相关会话应尽快失效;

· 修改密码或发现异常时,支持强制下线;

· 令牌不要携带过多权限信息,避免回收后仍然有效;

· 服务之间的调用使用独立凭据,不与用户令牌混用。

权限改了但旧令牌还能用,是很多系统真实存在的窗口期,设计时就要把失效路径想好。

· 记录谁在什么时间对哪个资源做了什么操作;

· 权限变更、角色分配、敏感导出必须留痕;

· 审计日志与业务日志分开存储,避免被一起清理;

· 日志要能按用户、资源、时间检索;

审计日志的价值不只是出事之后查原因,更在于让高危操作在设计阶段就被看见。

· 只在前端隐藏入口,后端接口没有校验;

· 用自增 ID 直接访问资源,没有校验归属;

· 超级管理员账号共用,出了问题无法定位;

· 权限判断写死角色名,新增角色时到处漏改;

· 测试环境权限宽松,上线后忘了收紧。

这些问题的共同点是「看起来能跑」,直到有人用错误的身份访问了正确的接口。

· 第一步:定义资源、动作与权限点,形成清单;

· 第二步:建立角色与用户-角色关系,统一鉴权入口;

· 第三步:所有查询补上数据归属与租户条件;

· 第四步:为高危操作加二次校验与审计;

· 第五步:定期审查角色权限,回收长期未使用的授权。

权限模型不需要一开始就做到最复杂,但需要一开始就有清晰的边界:谁能做什么、能看哪些数据、出了问题留下什么记录。对一人公司来说,这套约束越早建立,后面加功能时越省心。

安全不是加出来的功能,而是设计时就存在的边界。

一人公司的权限模型设计:独立开发者如何把角色、多租户与最小权限做对

权限做错,轻则越权,重则数据泄露。本文从认证与授权的区分、RBAC 角色建模、接口与数据粒度、多租户隔离、鉴权位置、最小权限、令牌失效、审计日志与常见坑,给出一人公司可维护的权限模型设计方法。

安全

架构设计

后端

权限系统设计是SaaS和后台开发核心，越权漏洞源于认证授权混淆。基于RBAC模型管理角色权限，分层控制接口、数据和字段级访问。多租户必须隔离数据归属，统一鉴权入口配合业务校验。实施最小权限原则，会话令牌及时失效，并全程记录审计日志。

数据泄露

数据库

SaaS

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

一人公司的权限模型设计:独立开发者如何把角色、多租户与最小权限做对

一人公司的权限模型设计:独立开发者如何把角色、多租户与最小权限做对

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐