刚接手讯维全域智能管控平台的权限模块改造时团队里有同事觉得这就是个给账号分角色的小事。等真正展开需求梳理才发现这套平台要管的资源类型远比我预想的多——几十路监控点位、门禁控制器、报警主机、各类传感器、工单流程、系统配置项每一类资源都有查看、操作、配置、删除等不同层级的动作排列组合下来权限点数量轻松上千。权限管理做不好轻则内部人员误操作把设备配置改乱重则敏感监控画面泄露、越权下发控制指令这都不是开玩笑的事故。这篇文章围绕讯维全域智能管控平台的权限管理功能把三层问题讲透权限模型怎么设计、鉴权逻辑怎么落地、这套体系到底能兜住哪些安全管控需求。适合正在做类似平台权限模块的研发同学也适合负责平台运维和安全制度落地的管理人员参考。1. 权限管理在全域平台里的真实定位管的不是登录是资源边界1.1 全域管控平台到底有多少种资源需要保护很多人对权限管理的第一反应是谁能登录系统这是最常见的认知偏差。登录只是身份认证权限管理真正要解决的是登录之后谁能碰什么、能做什么、能改什么。讯维这类全域智能管控平台有个特点资源类型极多而且彼此联动。一个典型的园区项目里平台至少要纳管视频监控、门禁、报警、消防、梯控、能耗、停车场等七八个子系统每个子系统下面又是成百上千台物理设备。这意味着权限对象不能只停留在功能菜单层面。菜单权限是最粗的一层比如能不能进入视频管理页面但全域平台更需要的是资源级权限比如能看一期的摄像机画面但不能看二期的能回放某栋楼的录像但不能导出能控制球机转动但不能修改预置位。只有把资源边界划清楚权限管理才有实际管控意义。1.2 全域管控平台里权限管理要回答的三个核心问题我梳理需求时习惯把权限问题拆成三个递进层次这样不容易漏谁能访问哪些资源这是数据权限。用户能看哪几个区域、哪几台设备、哪几类工单本质上是对数据集合的过滤条件。能对这些资源做什么操作这是功能权限。同是一台摄像机查看实时画面、查看回放、操作云台、修改配置是四个完全不同的动作危险级别也不同。谁能修改权限规则本身这是管理权限。拥有管理权限的人可以给他人授权也可以收回授权这类账户一旦失控就是系统性风险。把这三个层次想清楚再去设计数据库表和接口条理会清晰很多。很多项目上线前才爆出权限问题就是因为前期只做了菜单显隐没想清楚数据权限和管理权限的边界。1.3 为什么很多项目的权限问题到上线前才爆发实际接触的项目里权限需求被严重低估是常态。开发阶段用两个角色管理员和普通用户就能跑通演示大家都觉得功能没几个权限有什么好设计的。等项目进入联调和试运行业务方开始真实使用问题就冒出来了运维班组长需要看所有设备的在线状态但不能改配置安保经理要看全园区视频但不能导出外包巡检人员只能看自己负责那栋楼的告警每个角色都有自己的边界条件。这时候再回头补权限体系往往面临改表结构、加中间表、重构接口鉴权的连锁改动成本翻倍。所以我一直建议权限模型设计要放在项目启动阶段和业务建模同步做而不是等页面都写完了再往上套。2. RBAC的落地实现用户、角色、权限点的建模思路2.1 权限点的设计从菜单权限到操作权限再到数据权限讯维全域智能管控平台的权限管理采用的就是RBAC基于角色的访问控制模型。RBAC的核心思想不复杂用户不直接关联权限而是通过角色间接获得权限这样授权和回收都方便。但RBAC能管到什么程度完全取决于权限点怎么定义。我把权限点设计成资源类型动作的二元组合。资源类型包括摄像机、门禁点、报警主机、巡检任务、工单、系统参数等动作包括查看、控制、配置、导出、删除等。组合出来的权限点要有明确的编码比如camera:view:live表示查看实时视频camera:control:ptz表示云台控制camera:config:update表示修改摄像机参数。有了统一编码前端按钮显隐、后端接口鉴权、日志记录用的都是同一套标识不会出现页面能看但接口调不通这种对不上的情况。数据权限则需要单独的维度来承载因为数据权限通常不是固定的权限点而是带有范围条件的授权。比如查看视频这个权限要同时关联一个区域范围一期、二期、某栋楼我在设计时用数据范围表来存储每条授权记录包含权限点编码、授权对象、资源范围三个字段鉴权时把数据范围作为过滤条件拼到查询语句里。2.2 角色的组织内置角色、自定义角色与角色继承角色设计上讯维平台预置了几个基础角色分别对应典型的岗位职责系统管理员负责平台运维和配置安全管理员负责设备布撤防和报警规则操作员负责日常查看和巡检审计员只读访问所有日志和操作记录。这几个内置角色解决的是开箱即用的问题真正复杂的是自定义角色。自定义角色会碰到一个很现实的难题部门经理的角色到底继承操作员的权限还是一切从零配起。我建议采用角色继承补充授权的模式。子角色默认继承父角色全部权限再根据实际需要增加或剔除部分权限点。这样既省去重复配置又保留了灵活性。需要注意的是角色继承层级不要超过三层否则权限集合的计算会变得难以追踪查起问题来非常痛苦。2.3 授权策略的存储与检索数据库表设计与缓存加速RBAC的存储模型业界已经很成熟核心五张表用户表、角色表、权限表、用户角色关联表、角色权限关联表。数据权限范围单独再挂一张表。这五张表的关联关系简单清晰常规的SQL查询就能满足绝大多数场景。但全域平台的用户量和角色数量上去之后每次请求都实时查数据库关联表会非常慢。我实测过一个中型项目里有几百个用户、几十个角色、上千个权限点不做缓存的情况下每次鉴权查询要连查三张表接口响应时间明显变差。解决办法是把用户的权限集合在登录后一次性加载按用户维度缓存到Redis里key设计成perm:{userId}value里存该用户所有权限点编码的集合以及数据范围。权限变更时主动删除对应缓存或者维护一个全局版本号版本号变了就强制刷新所有用户的权限缓存。注意权限缓存必须设计主动失效机制不能只依赖过期时间。靠TTL自然过期会遇到权限改了但用户半天没生效的投诉这在安全管控场景里是不可接受的。3. 鉴权链路与动态授权权限判断是怎么跑起来的3.1 登录态与令牌体系鉴权链路的第一步是身份认证。讯维全域平台采用令牌机制用户登录成功后签发一个带有效期的令牌后续所有请求都携带这个令牌。令牌里可以包含用户ID、会话标识、令牌类型等基本信息但注意不要把权限点列表全塞进令牌里。令牌一旦签发就不好撤销把权限数据塞进去遇到权限变更根本没法及时更新只能等令牌过期这在实际运营中非常被动。正确的做法是令牌只证明你是谁权限判断在每次请求时实时从缓存里取这样权限变更可以秒级生效。我在项目中还按需要区分了普通令牌和短期操作令牌涉及修改配置、下发控制指令这类高风险操作时要求用户再次输入密码或提供短信验证码生成一个几分钟内有效的临时操作令牌和普通令牌配合使用相当于给敏感操作加一道二次认证。3.2 前端控制、接口拦截与业务层校验的三层防线很多系统把权限判断写在前端菜单按角色显隐就完事这是典型的自欺欺人。前端控制只影响界面上能不能看到入口懂技术的人直接拼接口地址就能绕过。安全上必须遵守一条原则所有权限判断最终都要在服务端完成。我在讯维平台的项目里做了三层防线。第一层是前端控制根据用户权限集合控制菜单显隐和按钮是否可点这一层纯粹是为了用户体验避免用户点了之后被拒绝产生困惑。第二层是接口拦截在网关或者统一的拦截器里根据接口路径和当前用户权限集合做匹配没有权限直接返回403这一层拦截了绝大部分越权访问。第三层是业务层校验针对数据权限做精细过滤拦截器只能判断能不能操作摄像机这类粗粒度权限但要判断能不能操作这台摄像机必须在业务代码里把数据范围条件拼接进查询或操作逻辑。三层防线缺一不可尤其是第三层。只做接口拦截不做数据范围过滤就会出现用户有查看视频权限但只能看自己片区的设备无法落地的尴尬局面。3.3 临时授权、时效授权与分级审批机制固定的RBAC模型解决的是日常的、稳定的授权需求但实际运营中经常出现临时需求。比如外包检修人员今天下午要进某栋楼处理门禁故障他只需要这三个小时的设备操作权限再比如管理员休假期间需要临时把部分管理权限委托给另一位同事期限两周。这些场景用固定授权去配会非常繁琐也容易配完忘记回收留下长期风险。我在权限模块里实现了临时授权功能授权记录上带有生效时间、失效时间和授权理由。到期后权限自动失效不需要任何人记得去回收。临时授权还支持走审批流程发起申请后由具备审批权限的管理员审核审核通过才生效全程留痕事后可以追溯谁申请了什么权限、谁批的、用在了哪里。这套机制对于满足等保合规里的授权审批要求非常有用。4. 安全管控需求的逐项满足对照具体场景看效果4.1 最小权限原则从制度要求落地为技术强制安全管控领域提得最多的就是最小权限原则意思是每个用户只拥有完成本职工作所必需的最小权限集合。制度上很容易写技术落地却要靠权限模型支撑。讯维平台的权限管理体系从几个方面保障了最小权限的落地。一是默认拒绝策略新创建的用户默认不关联任何角色没有任何权限必须由管理员显式授权才能访问资源。二是权限点拆分足够细操作员可以拥有查看门禁记录的权限但不拥有编辑门禁配置的权限权限粒度细了最小权限才有实现的可能。三是数据范围限制运维人员可以看所有设备的告警状态但只能对自己责任片区的设备执行复位操作这种能看到但不能碰的边界只能靠数据权限来实现。4.2 敏感设备操作与配置变更的权限隔离全域管控平台里最危险的操作集中在两块设备控制和系统配置。设备控制是向物理设备下发指令比如远程开门、布防撤防、云台转向系统配置是修改平台自身的运行规则比如报警联动策略、录像存储策略。这两类操作如果权限不隔离一个低权限的操作员可能通过调整报警规则让某个防区形同虚设这是很严重的安全隐患。我在权限设计里把设备控制类权限和配置类权限设置为互相独立的权限点并且要求配置类操作走审批流。实际操作中当用户发起配置变更时系统会记录变更前后的值、变更人、审批人、变更时间形成一条完整的变更轨迹。这样即便出了事故也能快速定位是哪一次变更、由谁批准、在什么时间生效的。4.3 文件与资源的特殊权限保护不只靠数据库里的记录全域平台会产生大量需要长期保存的文件资源监控录像片段、告警图片、操作日志、配置文件备份。这些文件的权限管理比数据库权限更隐蔽也更容易被忽略。数据库里给用户配了权限不等于文件系统层面就安全了用户完全可以通过服务器路径直接读取文件绕过平台层的鉴权。这里就涉及文件系统特殊权限和属性管理的问题。我强烈建议对平台产生的关键文件做两层保护。第一层是文件系统访问控制通过操作系统的用户权限和目录权限把平台服务账号之外的账号挡在外面。第二层是文件属性保护对录像证据文件、审计日志这类不可篡改的文件设置追加写属性只允许写入不允许修改和删除对关键配置文件设置不可变属性任何进程都不能改动需要变更时先解除属性再修改改完恢复。这个思路对应到Linux系统就是chattr命令的a只允许追加和i不可变更属性对应到Windows就是文件的只读和审核属性。别小看这层保护它解决了权限体系里一个死角平台内部的高权限账号即便被攻破或者滥用也无法静默篡改证据文件和日志。4.4 操作审计与异常行为追溯权限管理管的是事前和事中审计追溯管的是事后。安全管控需求里能不能说清楚谁在什么时间通过哪个设备做了什么操作往往是合规检查的硬指标。审计模块记录的内容要覆盖几个要素操作用户、用户IP、操作时间、操作类型、操作对象、操作结果、变更前后的值。尤其对于设备控制指令和配置变更必须记录完整的上下正文信息。我在设计审计日志表时特意加了一个不可篡改的约束——审计日志不能通过平台的管理界面删除或修改数据库账号也做到最小化授权只允许插入和查询不允许更新和删除。再配合上一节说的文件追加写属性双管齐下基本可以保证操作留痕的真实性。有了完整的操作审计异常行为追溯就顺理成章了。比如凌晨三点有人批量导出录像或者在非授权时段有人远程操作门禁这些行为都能从审计日志里提取出来触发告警。权限管理系统和审计告警联动之后才真正闭环成一套安全管控体系。5. 权限体系上线后的常见问题与调优实践5.1 角色膨胀与权限回收机制权限体系上线运行一段时间后最常见的失控方式是角色膨胀。业务部门今天提一个需求加一个角色明天换一个部门负责人又加一个角色几个月下来角色数量翻了几倍很多角色只有一两个人在用权限点配置却互相重叠甚至存在冲突。角色膨胀的直接后果是权限集合难以梳理审计时说不清某个人到底拥有哪些权限。我建议从两方面做治理第一用定期权限复核机制每隔一个季度把角色列表和用户的权限汇总导出来发给各部门负责人确认对超过三个月没有任何登录记录的用户自动冻结账号第二设置角色关联用户数的最低阈值告警角色下挂用户长期为零就提示合并或删除。这套机制刚开始推的时候业务方会觉得麻烦但坚持两轮之后权限体系会清爽很多。5.2 缓存一致性权限变更为什么没有立刻生效权限改了不生效是权限模块上线后被投诉最多的问题之一根子基本都在缓存。一次典型现象是管理员把某个用户从角色A挪到角色B用户那边还是能访问角色A的资源过了几分钟才恢复正常。排查链路通常是这样的。先确认数据库里的账号角色关系是否已经变更如果数据库变了但行为没变基本可以判定是缓存未失效。再看缓存失效机制写得对不对。我遇到过一个项目缓存key只包含用户ID和角色ID的拼接角色权限变更走了另一套逻辑只更新了角色权限表没有触发用户缓存失效结果角色权限改了但用户拿到的还是旧权限集合。后来我统一改成一个原则所有权限相关表的变更都发一条消息到权限变更队列消费端统一做缓存清理。这样不管改动的是用户角色关系还是角色权限关系缓存都能保持一致权限变更的生效时间压缩到秒级。5.3 粗粒度授权导致的越权隐患有不少平台在设计权限时图省事一个角色名对应一整页的权限勾选权限点只做到页面级别。这种粗粒度授权在安全管控里隐患很大。举个例子安保人员需要查看某个区域的实时画面但如果权限点是视频管理页面那他就同时获得了查看所有区域、回放、导出的能力超出实际工作需要的权限就暴露在了那里。我在权限点拆分时吃过这个亏。最初为了快速上线把摄像机权限做成了一个视频权限点结果上线后业务方提出不同级别的人应该看到不同区域只能返工拆权限点、改接口、挪数据。之后我总结了一条经验权限点宁可拆细一点也不要先粗后细因为从粗到细的迁移成本远高于一开始就设计好。权限点拆细之后通过角色把常用权限组合打包使用起来并不繁琐安全边界却清晰得多。5.4 一次越权排查的完整过程权限问题到底怎么查最后分享一次实际排查经历给大家一个可以参考的思路。现场反馈某个操作员反映我能查看一期所有设备但单独看不了其中一台球机的画面界面提示无权限。我按这个顺序排查第一查用户角色关联确认操作员绑定的角色包含视频查看权限点数据库里看是有的第二查权限缓存发现缓存的权限集合里也确实包含该权限点说明粗粒度权限没问题第三查数据权限范围发现该用户的数据范围只授权到了一期的楼栋列表而那台球机的组织归属被后来重新划分到了另一个楼栋节点没有纳入授权范围。问题一下就定位了是数据权限范围没跟上设备归属调整导致设备不在授权范围内。这次排查给我的启发是权限问题查起来要有固定的检查清单先粗粒度权限、再数据范围、再缓存最后看接口的鉴权日志。讯维平台的权限模块里每次接口被拒都会记录拒绝原因是未认证、权限点不匹配、还是数据范围不匹配一眼就能看到。权限日志这个细节很值得做排查效率能提高一个数量级。另外透露一个自己一直沿用的验证方法权限体系改版之后我会用两个测试账号做对照验证。一个账号取超管角色一个账号走最小权限原则只配一个最基本的查看权限拿这两个账号把所有关键接口各跑一遍。超管账号保证能通最小权限账号用来确认没有越权通道。这个笨办法每次都能发现几个自以为没问题、实际漏掉了的接口。
