03 授权引擎与数据保险箱：访问控制与敏感数据保护

03 授权引擎与数据保险箱：访问控制与敏感数据保护

访问控制实现的要领是“每次访问资源都在服务端校验是否归属当前身份”，辅以 RBAC/ABAC 统一授权模型，杜绝只靠前端隐藏；敏感数据保护则是把密码加盐哈希、敏感字段加密脱敏、传输强制 HTTPS 三件事做到底，让即使被攻破也拿不到可读数据。授权管“你能不能看”，加密管“看了也没用”。

第五幕第三个装具盒把第三幕的“越权”与“敏感数据泄露”反转为建闸与上锁。前一个管权限授权，后一个管数据价值，两者一起把“数据被拿走”的伤害降到最低。

一、访问控制：服务端归属校验 + 统一授权模型

矫正越权的前提是把“有没有权限”从“前端藏不藏按钮”捞回到服务端判断。核心两条：

一是每次访问都校验归属。查某资源前，先确认“当前身份是否有权访问这个指定资源”，而不是“能不能调这个接口”。接口可调≠你有权看里面的数据。

二是统一授权模型。别在几百个接口里各自手写 if 造漏网，用 RBAC（基于角色：谁扮演了什么角色）或 ABAC（基于属性：主体/资源/环境属性组合判决策）在入口集中定义“角色/属性能访问哪些资源”。改权限只改一处，审计也有据可查。

二、敏感数据保护：让“拿走了也没用”

数据价值这条线上，加密与脱敏是把泄露的“战利品”变成“废料”的收尾动作。四大动作：

• 密码：加盐强哈希（前文已述），绝不存明文或可逆加密。
• 敏感列：信用卡、手机号等做字段级加密，展示时脱敏（只露末尾几位）。
• 传输：强制 HTTPS，配 HSTS 避免降级。
• 密钥：集中管理、按环境隔离、定期轮换、不入代码仓库。

三者叠加后，即使某天有接口被越权或数据库被搬走，攻击者拿到的也是密文/打码值而不是可直接用的明文，泄露的杀伤大大降低。

三、工程实践要点与取舍

• RBAC 适合组织层级清晰、角色固定的场景；ABAC 更适合属性驱动、规则复杂的场景，代价是规则与属性的维护成本。
• 归属校验要做成样板代码/中间件，避免每个接口手写遗漏。
• 加密有性能与密钥管理成本：给真正敏感的列加密，别给所有字段无差别加密拖垮查询。
• 加密 vs 脱敏区分：加密是对“存储与传输”的保护，脱敏是对“展示与审计”的保护，两回事别混用。

💡 关键直觉：访问控制与数据保护其实互为兜底。授权没拦住，加密还能让数据不可读；加密做得再好，授权乱也会把密文密钥一起暴露。两条线都做，才是“即便防线失守也收住损失”。

四、一次完整的演练

背景：一个订单站，订单按 ID 查询且手机号明文存储展示。操作：改 ID 看他人订单（越权）；观察手机号在数据库与页面展示的形态。结果：可越权读他人订单，手机号明文。解读：授权缺归属校验，数据缺脱敏。变式：给查询入口加服务端归属校验 + 抽统一授权中间件；手机号字段加密 + 展示脱敏。重复操作后越权被拒、泄露的是密文/打码值。

五、授权模型怎么选，别一上来就 ABAC

许多团队一谈“统一授权”就直接上了 ABAC，结果规则又多又乱、维护成本爆表。给一个务实的选型顺序：组织层级清晰、权限随职位走的，先用 RBAC——建角色、角色挂权限、用户挂角色，简单可审计。只有当出现“一个用户的权限要随资源属性或环境动态决定”（比如“该区域经理只能看自己管辖门店的销售”“同一文档不同人看到的字段不同”）这种 RBAC 说不清的复杂规则，再加 ABAC。ABAC 强大但需要有人持续维护属性字典与规则库，权限模型最忌讳“一开始就上最复杂那套”——它通常让本来就漏的授权变得更难维护，而不是更安全。

六、数据保护里的“密钥本身”是另一道保险箱

谈加密时，大家往往盯着密文本身，却忽略密钥的处境。若密钥硬编码在前端代码、写进仓库、或所有环境共用一个，加密就形同虚设——攻击者搬走数据库时连钥匙一起捡走。到底怎么处理：密钥集中存储在专用的托管服务里，按环境（开发/预发/生产）隔离，责任人按最小权限申请、定期轮换；前端代码和开源仓库绝对不落任何真密钥。把密钥当作“和密文一样重要甚至更重要”的对象来管，加密才真正成立了；否则你只是给数据换了个壳，钥匙还挂在门上。

七、授权与加密的“串一条链”检查

把这两个主题放到一条时间线上检查最直观：请求进来先过授权（你允不允许看这份资源），过了再谈数据形态（看的是明文还是脱敏后）。给三个能一键对表的问题：第一，这本资源我能不能“拿到它已被授权”的证据，还是资源 ID 一露就能直接读（归属校验是否存在）；第二，就算拿到了，读出来的是不是密文或脱敏值，还是裸的明文手机号/卡号（字段级加密与展示脱敏是否就位）；第三，如果能解密，那把钥匙是不是集中托管、按环境隔离，而不是和服务一起被搬走（密钥管理是否成立）。三个问题会得出“授权闸住了没、最贴身那层保险箱锁了没、钥匙还在不在身边”三个答案。任一答案是反面，就说明数据被拿走时损伤没有压到最低。把这条链写进数据接口的评审，访问控制与数据保护就不会各自为政。

八、授权与数据保护的“常态巡检”频率

两条线都做好还不够，更关键的是一贯性——权限会在版本迭代里被手改回放开，密钥会在运维里被挪地方。给一个巡检节奏：对外数据接口，每次发版都过一遍“归属校验 + 脱敏是否仍在”；密钥与访问控制台账，按月核对一遍“责任人是否还准确、是否有无人认领的超权账户”；高危数据资产（支付、核心库、身份证件）加一条基线比对，一旦配置偏离即告警。把这条频率写进例行运维，访问控制与数据保护才不会“上线那天很安全、三个月后悄悄退化”。它和第六幕配置审计是同一件事在不同层的体现：安全是持续的动作，不是一次性的完工。

本节要点回顾

• 授权选型务实：组织清晰先用 RBAC，出现动态属性规则再上 ABAC，别一上来就最复杂那套。
• 密钥是另一半保险箱：密钥落库、硬编码、共用即加密形同虚设，集中存储、分环境隔离、定期轮换。
• 访问控制核心是服务端每次访问校验归属，杜绝只靠前端隐藏。
• RBAC/ABAC在入口统一裁决，比逐接口手写 if 更可靠、可审计。
• 数据保护四动作：密码加盐哈希、敏感列加密脱敏、强制 HTTPS、密钥集中管理。
• 授权与加密互为兜底，都做才能把泄露伤害压低。
• 身份是数据保护与授权的前提，三者要放在一起看。