运营中心数据权限三级分类实践:从混乱到精准
|
告警响的那一刻,我正把泡面叉子插进最后一块蛋里——汤都凉了,面坨成团,咸得发苦。手机震起来,是开发老张,电话里吼:“你那个运营中心后台查不到订单明细!财务说今天结账卡在那儿了!”我没接话,直接切回终端窗口,顺手把屏幕上还开着的证书续签脚本窗口最小化——那玩意儿其实早该跑完了,但忘了看输出。 我原以为是缓存没刷,清了三遍 Redis key,重启了两轮 gateway,连 configmap 都 reload 了三次。结果老张五分钟后又打进来:“不是接口超时,是返回 403,连字段名都给你拦掉了。”我愣住,手指悬在键盘上,听见自己后槽牙有点响。机房空调冷得过分,我缩了缩脖子,抬眼看见监控屏右下角时间:凌晨三点半。窗外天快亮了,灰白一层浮在玻璃上,像没搅匀的石膏浆。 去年十二月那会儿,我们所谓“数据权限”,就三类人能碰:DBA、SRE、还有“业务方提了工单并签字”的人。但实际呢?前端一个埋点开关配置页,后端顺手把整个用户表结构全吐过去;报表平台导出按钮底下,藏着一串拼接 SQL 的 Python 函数——参数校验只有 if len(userid) > 3;运维同学自己写的备份检查脚本,居然调用了一个内部审计 API 做“权限兜底”,而那个 API 权限开关压根没人维护过,半年前就失效了。优胜劣汰?不,是淘汰掉最后一个敢问“这字段真要透给前端?”的人。 最绝的是迁移复盘会上,开发小李举手说:“你们要不要把运营中心权限从‘按角色’改成‘按字段掩码’?”全场静了三秒。DBA 老赵当场冷笑:“字段掩码?上周我查 slowlog,发现有个报表查询 select from order_detail where create_time > '2020-01-01'——三百多个字段,你掩哪个?掩完字段名还在 JSON 里明文挂着,前端控制台 console 一下照见。”他掏出手机晃了晃,屏幕还亮着刚才抓的 response 截图。我看了眼,确实,mask 字段是“”,但字段名是 “order_status_desc_zh”、“shipping_company_code”……全是中文拼音加英文缩写,根本没藏。我承认,当时没做备份。不是忘了,是觉得“不就改个权限表嘛”,结果改崩了一个权限上下文初始化逻辑,三台机器同时掉 session,登录态集体失守。那晚没宕机,但比宕机还瘆人——所有人还能点进去,就是点哪儿都弹 403,像进了鬼屋,门全开着,屋内空无一人。 值班表刚换到我头上那周,我妈打电话问我能不能春节回趟家。我说“尽量”。她说:“你爸修电动车胎,修了四次,每次都说这次肯定行——结果第四次还是漏气。”我笑出声,挂了电话才发现自己在终端里敲了七遍 chmod -R 755 /etc/permissions/ ——那目录早就被删了,权限文件现在全在 etcd 里跑,但手指记得旧路径。认了。真认了。
文章配图,仅供参考 后来搞三级分类,也不是谁拍脑门定的:L1 是“谁都不能看”的(比如身份证号、银行卡号),L2 是“只给审批通过的角色看特定字段”(比如客服只能看 last_contact_time,看不到 payment_token),L3 是“可开放给全部运营人员的脱敏字段”(比如订单状态、下单时间)。听起来挺板正?执行的时候全是破洞。测试环境里跑得好好的,上线第一天,财务同事导出Excel,发现金额列全是“[PERMISSION_DENIED]”,而不是数字。查了一小时,发现不是代码问题,是我们用的 BI 工具在导出时绕过了网关权限层,直连了数据服务,而那个服务没做 L2/L3 拆分,只认 L1 的全局黑名单。最后解决方案?在 export 接口前面硬塞了个中间件,用反射偷看 caller 的 stack trace——如果是报表模块的 class 名,就自动切 L3 上下文。荒谬吧?但真用了三个月,没出事。反常识结论来了:不是分级越细越安全,是分级之后,大家终于肯坐下来吵架了。以前没人管权限,因为查不出责任——出事就甩锅“DBA 开了太宽权限”或“前端没做校验”。现在一级字段一级字段抠,老张为了多看一个“买家备注”字段,连续三天在钉钉艾特我,发截图发文档发邮件,附带法律合规条文编号。吵赢了,他拿到 L2 权限;吵输了,他就把那个字段从页面上干掉了。这不是技术胜利,是耗尽耐心后的战术性退让。优胜劣汰,汰掉的是假装看不见问题的人,优胜的是那些愿意为一行 SQL 纠缠到凌晨四点的人。 昨天又看到一个新需求:给区域经理开个“下属门店流水总览”,但要求“不可下钻至单店明细”。产品写 PRD 时画了个三层嵌套框图,密密麻麻全是条件分支。我扫了一眼,直接回复:“先砍掉下钻功能,上线后再补。”旁边同事抬头看了我一眼,没说话,继续敲他的 Ansible playbook,屏幕上还开着三个 ssh 连接,其中一个在重跑 yesterday’s backup script,进度条卡在 89%。我其实不确定这个脚本到底有没有成功备份上个月的权限元数据——没查,也懒得查。这事本来能避免。去年十二月要是谁在部署时顺手 diff 一下权限表 schema 和新版 RBAC DSL,就不会有后来那三十几个 403 日志堆满 ELK 的凌晨。 算了,泡面早坨了。我关掉所有窗口,只剩一个 vim,光标停在 ~/.zshrc 最后一行,那里写着 alias perm-check='curl -s localhost:8080/api/v2/audit/permission/context | jq .'——这命令我写了七次,删了六次,第七次才留着。下周一补个真实权限上下文快照功能,不带 mock,不上 dev 分支,就放 prod。反正……也塌不了天。 (编辑:站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |


运营中心如何用PHP智能算法让每次点击都更懂你
API性能优化:运营中心响应提速300%,用户等待≤2秒
元数据驱动运营中心服务器响应提速40%
运营中心数据规划:点击提速0.3秒的科技实战
运营中心实时交互操作系统:毫秒级决策可溯、可干预、可优化
运营中心PHP实时交互卡顿?3步优化立竿见影