分类目录归档:架构和远方

海量「免费」的 OPENAI KEY,你敢用吗?

技术群在传一张 X 上发的一个截图,是这样的:

过去:如果你没有 windows 激活码,怎么办?去网上搜一个

现在:如果你没有 OPENAIAPIKEY,怎么办,答案仍然是去 Github 上搜一搜

(警告,不推荐这种行为,发帖的目的是告诉大家不要把环境变量扔到repo里,否则等着被用炸吧….)

我自己去搜了一下,多加了点匹配,如图:

在 GitHub 上搜索 “OPENAI KEY=sk-”,你能找到超过 2.5K 的代码记录。是的,是 2500+ 条。

如果有人拿到这些 KEY 去使用了,刚好有 KEY 可以使用,那对于 KEY 的主人来说,无疑是一个巨坑,一天可能超多的钱就没有了,有个好消息是 OpenAI 有消费上限保护。

这些 KEY 里,有多少是真正可用的?又有多少是已经被销毁的?更重要的是,你真的敢用吗?

为什么会发生这种事?

说到底,这是一个老生常谈却又屡禁不止的问题。

我们喜欢一切能让工作变得简单的方法。把 API KEY 直接写在代码里,确实很方便:

  • 不用每次都去环境变量里配置
  • 团队成员 clone 下来就能跑
  • 部署的时候也省事儿

但是,代价往往是昂贵的。

更深一些的原因是,很多开发者对安全的认知还停留在「我的仓库是私有的」或者「谁会那么无聊来翻我的代码」这种侥幸心理上。殊不知,GitHub 上有大量的自动化机器人,24 小时不间断地扫描新提交的代码,专门寻找各种敏感信息。

另外一个是认知偏差:

  • **临时变永久:「**先这样写,回头再改」——程序员最大的谎言之一。临时方案有一种神奇的特性,就是会变成永久方案。今天的 quick fix,明天就是 production code。
  • **版本控制的特性理解不足:**很多新手不知道,Git 会永久记录所有历史。即使你删除了包含密钥的文件,它依然存在于 Git 历史中。除非你重写整个历史(force push),否则密钥会一直在那里。
  • **公开的定义理解有误:**有人以为”不宣传就等于不公开”。但在互联网上,只要能被访问到,就等于向全世界公开。你不说,不代表爬虫不知道。

不只是 API KEY

在这个图的下面,有大佬回复了,曾经翻墙的代理也在这里找到过。扩展开来,用同样的方法,你能在 GitHub 上找到:

  • 数据库的账号密码
  • 服务器的 SSH 密钥
  • 各种云服务的 Access Key
  • 邮箱的 SMTP 配置
  • 支付接口的密钥
  • 甚至是公司内网的 VPN 账号

这就像是把家里的钥匙随手扔在大街上,还在上面贴了张纸条写着你家地址。

那些血淋淋的教训

说几个真实的案例,都是业内的血泪史。

案例一:Uber 的 5700 万用户数据泄露

2016 年,Uber 因为工程师将 AWS 密钥上传到 GitHub,导致黑客获取了 5700 万用户的个人信息。最后 Uber 不得不支付 10 万美元的”封口费”,试图掩盖这次事故。结果呢?不仅钱白花了,后来还是被曝光,额外付出了巨额罚款。

案例二:2025年 xAI(马斯克旗下AI公司)API 密钥泄露

xAI 开发者在公开 GitHub 仓库提交了包含 私有 API 密钥 的配置文件(.env),该密钥可访问 SpaceX、特斯拉及 Twitter/X 的定制化大语言模型(LLM)

。泄露内容包括:

  • 未发布的 Grok-2.5V 等核心模型开发版本;
  • 至少 60 个私有数据集,涉及内部运营数据。

影响

  • 密钥持续暴露 近两个月(2025年3月2日–4月30日),期间未被及时停用;
  • 攻击者可能窃取未发布模型、滥用内部基础设施或发起供应链攻击;
  • xAI 被迫删除涉事仓库,但未公开回应事件细节。

案例三:加密货币被盗空

这个更刺激。Web3 流媒体应用 Unlonely 的联合创始人 Brian Guan 错误的在 GitHub 上公开了一个包含其钱包私钥的存储库,导致该钱包在 2 分钟内即被盗空,损失了 4 万美元

那么,如何规避呢?

好了,聊完曾经的坑,咱们来说点实际的——怎么避免这种悲剧发生在自己身上。

1. 意识层面

首先得明白一个道理:任何敏感信息都不应该出现在代码里

这就像你不会把银行卡密码写在卡背面一样。哪怕是测试环境的密钥,也不应该直接写在代码里。因为你永远不知道什么时候会手滑把代码推到公开仓库。

2. 上点技术手段

使用环境变量

这是最基本的做法。把所有的敏感配置都放到环境变量里:

python

体验AI代码助手
代码解读
复制代码
import os
openai_key = os.getenv('OPENAI_API_KEY')

使用配置文件 + .gitignore

创建一个 config.example.json,里面是配置模板:

json

体验AI代码助手
代码解读
复制代码
{
  "openai_key": "your-key-here",
  "database_url": "your-database-url"
}

实际使用的 config.json 加入 .gitignore,这样就不会被提交到仓库。

使用密钥管理服务

对于正式的项目,建议使用专门的密钥管理服务:

  • AWS Secrets Manager
  • Azure Key Vault
  • HashiCorp Vault
  • 或者自建的密钥管理系统
  • 或者使用配置管理系统

3. 流程和工具保障

Git Hooks

.git/hooks/pre-commit 里添加检查脚本,自动扫描即将提交的代码中是否包含敏感信息。市面上有很多现成的工具,比如 git-secrets。

代码审查

建立 Code Review 机制,特别关注配置相关的改动。人工审查虽然可能遗漏,但多一道关卡总是好的。

定期扫描

使用工具定期扫描你的代码仓库:

  • TruffleHog:可以扫描整个 git 历史
  • GitGuardian:提供实时监控
  • GitHub 自带的 Secret Scanning

4. 应急响应机制

即使做了万全准备,意外还是可能发生。所以你需要:

快速撤销机制

  • 知道如何快速撤销泄露的密钥
  • 准备好备用密钥,可以快速切换

监控告警

  • 设置异常使用告警
  • 关注账单变化

定期轮换

  • 即使没有泄露,也要定期更换密钥
  • 就像定期换密码一样

本质是什么问题?

说了这么多,我们来思考一个更深层的问题:为什么这种低级错误会一再发生?

我觉得本质上是便利性与安全性的永恒矛盾

作为开发者,我们总是在寻找更高效的工作方式。把密钥写在代码里确实方便,但这种方便是以安全为代价的。这就像是为了省事不锁门,虽然进出方便了,但家里的东西也不安全了。

另一个层面是安全意识的缺失。很多开发者,特别是刚入行的新人,对安全问题的严重性认识不足。他们可能觉得「我就是个小透明,谁会盯上我」,但实际上,自动化的扫描工具可不管你是谁。

还有就是团队管理的问题。很多团队没有建立起完善的安全规范和流程,全凭开发者的自觉。这就像是期望每个人都自觉遵守交通规则,没有红绿灯和交警,结果可想而知。

写在最后

回到开头的问题——「海量免费的 OpenAI KEY,你敢用吗?」

我的答案是:还是不用的好。

这些所谓的「免费」密钥,背后可能是某个开发者的血汗钱,是某个创业公司的生死存亡。使用这些泄露的密钥,不仅是不道德的,更可能让我们卷入法律纠纷。

更重要的是,如果我们真的在做正经项目,这些来路不明的密钥随时可能失效,会让我们的服务变得极不稳定。与其贪这点小便宜,不如老老实实申请自己的密钥,至少睡得安稳。

最后想说的是,安全无小事。今天你可能觉得泄露个 API KEY 没什么大不了,明天可能就是整个数据库被端了。在这个数据就是金钱的时代,保护好自己的数字资产,就是保护好自己的钱包。

别让你的代码仓库成为黑客的 ATM 机。

记住:GitHub 不是你的密码本,代码仓库不是保险箱

如果这篇文章让你想起了什么,赶紧去检查一下你的代码仓库吧。说不定,你的密钥正在某个角落里呆着呢。

以上。

作者:潘锦
链接:https://juejin.cn/post/7523134315641045043
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

为什么90%的空降技术管理者都在做同一件事?

最近和几个做技术管理的朋友小聚,聊到曾经各自入职后的第一个月在干什么,答案出奇的一致。

「盘家底。」

「梳理资产。」

「摸排现状。」

说法不同,但干的都是同一件事——技术资产盘点。

这些朋友有从大厂跳到创业公司的,有从创业公司到大厂的,有接手十几人团队的,也有管上百号人的。按理说,不同规模、不同阶段的公司,管理重点应该不一样吧?

但为什么大家不约而同都在做技术资产盘点?

这事儿其实跟公司大小没关系,跟一个更本质的东西有关——手感。

什么是手感

做技术管理,手感是个很玄妙的东西。

举个例子: 团队和你汇报一个系统改造方案,说要花 3 个月,投入 10 个人。你如果此时心里犯嘀咕:这个时间是长还是短?人力是多还是少?如果你没有手感,你大概率会说:”方案不错,但能不能再优化一下时间?”

如果团队回复:”已经是最优方案了。”

然后呢?然后就只能批准了。或者再想其它办法来核实,但心里始终不踏实或者耗费时间。

这就是没有手感的典型表现。

手感是什么?是一种基于深度理解的直觉判断力。

有手感的状态大概这样的:

  • 听到「数据库 CPU 占用 80%」,马上能判断是 SQL 问题还是数据量问题
  • 看到「服务器 500 台」,立刻知道是不是合理规模
  • 团队说「这个需求要一个月」,心里有数是真需要还是在放水
  • 出现故障时,能快速圈定问题范围,而不是干着急

而没有手感的管理者呢?就像在迷雾中开车,处处都是未知,步步都要小心。

有手感的管理者,心里有地图,走到哪里都知道车怎么开。

当一个技术团队的管理者没有手感,你的每一个决策都依赖下属的汇报,而你提不出实质性的意见,这样,你的管理权威就会一点点流失,团队也就不好带了。

这也就是为什么空降管理者都急着做技术资产盘点——不是为了显得自己在做事,而是真的需要通过这个过程快速建立手感

没有手感,你就不是在管理,而是在被管理

手感从哪里来

手感不是天上掉下来的,也不是靠看几本书、听几次汇报就能有的。

我曾经见过太多空降管理者犯同一个错误:急于证明自己。

刚到一个新环境,看到这也不合理,那也不规范,马上就想大刀阔斧地改革。结果呢?不是改革受阻,就是改出更大的问题。

为什么会这样?因为我们所看到的「不合理」可能是合理的。

听说过一个案例。一个朋友刚接手一个团队时,发现新团队的部署流程特别繁琐,一个简单的上线要过五六道关卡。他当时就想,这也太低效了,必须优化。

还好当时忍住了,先做了技术资产盘点。这一盘点才发现,这个「繁琐」的流程背后是血的教训——两年前因为上线流程太简单,出过一次重大故障,损失上千万。从那之后,团队宁可效率低一点,也要确保稳定性。

如果当时贸然「优化」,很可能会重蹈覆梯,当然,也可能不会,至少不要那么急着做事,先缓一缓,看清局势。

手感这个东西,来自于对系统的深度理解。而这种理解,对于一个新接手的管理者来说,可以通过技术资产盘点一点点建立起来。

技术资产盘点就像考古,我们得一层层挖掘:

  • 这个服务为什么会存在?解决什么问题?
  • 这个架构为什么这么设计?有什么历史原因?
  • 这个配置为什么是这个值?踩过什么坑?
  • 这些技术债是怎么欠下的?为什么一直没还?

每个不合理的背后,都可能有一个合理的故事。每个奇怪的设计,都可能是特定时期的最优解。

只有当我们了解了这些前因后果,才能真正理解这个系统,才能培养出那种「一眼就能看出问题」的手感。

这就是为什么技术资产盘点如此重要——它不仅仅是在清点家底,更是在建立我们对整个技术体系的认知地图。有了这张地图,我们才知道哪里能动,哪里不能动;哪里需要改进,哪里需要保持。

手感,就是这样一点一点积累起来的。

掌控感是管理的基础

做管理,最重要的是什么?是掌控感。

什么是掌控?不是说我们要事事插手,而是当出现问题时,能快速定位;当需要决策时,有充分的信息;当团队需要支持时,知道资源在哪里。

没有掌控感的管理者是什么样的?

  • 技术评审时,只能听团队汇报,提不出实质性意见
  • 出现故障时,只能在旁边干着急,帮不上忙
  • 做预算时,不知道哪些该花哪些不该花
  • 定目标时,不知道什么是合理的预期

这样的管理者,很难获得团队的信任和尊重。

而手感,正是掌控感的基础。

有了手感,才能在关键时刻做出正确判断。有了手感,管理才不是空中楼阁,而是脚踏实地。

这就回到了我们的核心问题:为什么空降管理者都要做技术资产盘点?

因为这是建立手感的最快途径,是获得掌控感的必经之路。我们可以慢慢熟悉团队,慢慢了解业务,但技术资产是实实在在摆在那里的,是可以快速盘点和掌握的。

当我们知道每一分钱花在哪里,每一个系统如何运转,每一个瓶颈在什么地方,我们就有了管理的抓手,有了改进的方向,有了说话的底气。

这,才是技术资产盘点的真正价值。

技术资产到底包括什么

很多人以为技术资产就是服务器、数据库这些硬件资源。其实远不止于此。

我把技术资产分为几个层次:

入口层:掌控用户的入口

域名是最容易被忽视的资产。

以今年 6 月初的阿里核心域名 aliyuncs.com 故障为例:6 月 6 日凌晨,阿里云核心域名 aliyuncs.com 遭遇罕见的域名劫持事件,导致其对象存储服务(OSS)、内容分发网络(CDN)以及云解析 DNS 等多项核心云服务出现大范围故障,波及众多依赖阿里云服务的网站和应用。

除此之外,各企业网站、学校网站等等都出现过域名导致的线上故障。

还有 SSL 证书,很多公司的证书管理一团糟,快过期了才想起来续,结果用户访问时浏览器报警,体验极差。

为什么要盘点入口?因为这是用户接触我们的第一步。域名解析慢了,用户可能就走了;证书有问题,用户可能就不信任了。这些看似小事,实则关乎生死。

接入层:了解流量的来龙去脉

负载均衡怎么配的?有没有做 DDoS 防护?WAF 有没有?规则合不合理?

我在上一家公司,一个月 CDN 账单接近百万,我在做技术成本优化的时候发现,是其接入策略有问题,使用的是 OSS 的流量计费,并且当月受到一些图床攻击。这种浪费,比比皆是。不盘不知道,一盘吓一跳。

还有一些业务上线了,基本的安全策略都没有,直接服务器裸奔在线上,最终被黑客侵入,变成「肉鸡」或矿机。

计算层:服务器不只是数量

“我们有 500 台服务器”——这个信息对管理者来说几乎没有价值。

真正有价值的是:

  • 这些服务器的利用率如何?
  • 是否存在资源闲置?
  • 扩缩容策略是否合理?
  • 有没有僵尸服务器在白白烧钱?

我曾经做技术资产盘点发现 30% 的服务器 CPU 利用率不到 10%。为什么?因为之前为了应对突发流量,扩容后就没缩回去。这一项优化,一年就省了上百万。多说一句,大家还真都是草台班子。

中间件层:那些看不见的成本大户

消息队列、搜索引擎、大数据组件……这些中间件往往是成本大户。

比如消息队列,很多团队的使用方式是「能用队列的地方都用队列」,结果消息堆积严重,不仅成本高,还影响性能。盘点时你会发现,有些场景用简单的异步调用就够了,根本不需要引入消息队列。

甚至,连异步调用都不需要,同步调用就能解决问题,当时只是为了考虑扩展性,才做的甚至队列的最终一致性。然而业务一直用不上。

再比如搜索,Elasticsearch 集群动不动就是几十个节点,但真的需要这么多吗?数据的冷热分离做了吗?索引优化了吗?

存储层:数据是核心资产

数据库的盘点要细到什么程度?要细到表、甚至字段级别。

为什么?因为:

  • 得知道核心数据在哪里
  • 得了解数据的流转路径
  • 得评估存储成本是否合理
  • 得发现那些该清理的垃圾数据

曾做过一次数据库盘点,发现数据库中有超过 20 个 copy 表,还有几个超大的日志表,占数据库 80% 的空间,而这些表根本没有人在用,只是当时备份一下。

盘点存储,本质上是在梳理数据链路。

当我们能在脑海中清晰地描绘出「用户在界面上的一个操作,数据是如何流转并最终存储的」,我们才算真正理解了这个系统。

代码资产:不只是代码仓库

代码资产包括:

  • 有多少代码仓库?活跃度如何?
  • 技术栈是否统一?有没有历史包袱?
  • 代码质量如何?技术债务有多少?
  • 文档完善吗?新人能快速上手吗?

很多团队的代码仓库就像仓库一样,堆满了各种「以后可能用得上」的东西。结果就是,真正在维护的可能只有一半,另一半都是历史遗留。

流程资产:效率的关键

CI/CD 流程顺畅吗?从代码提交到上线要多久?

我接手过一个团队,上线一个小改动要两天。为什么?因为 CI/CD 流程设计得太「完美」了,各种检查、各种审批,结果效率极低。

盘点流程,我们会发现很多「以前合理现在不合理」的设计。比如,创业初期为了快速迭代,可能没有代码审查;规模大了之后,可能审查流程又过于繁琐。

在制品管理:别让半成品成为负担

什么是在制品?就是那些做了一半的项目、POC 了但没上线的系统、试验性的功能……

这些在制品是隐形的成本黑洞:

  • 占用服务器资源
  • 消耗维护精力
  • 增加系统复杂度
  • 埋下安全隐患

盘点时会惊讶地发现,可能有 30% 的资源被这些”半成品”占用着。

制品管理:那些容易被遗忘的二进制资产

什么是制品?简单说,就是我们的代码编译打包后生成的那些可执行文件——jar 包、docker 镜像、npm 包等等。这些东西看起来不起眼,但管理不当会成为大麻烦。

我见过最混乱的场景是什么样的?一个团队,所有的jar包都扔在一个共享文件夹里,文件名是这样的:

  • app-1.0.jar
  • app-1.0-final.jar
  • app-1.0-final-final.jar
  • app-1.0-final-真的final.jar

你猜哪个是生产环境在用的?没人知道。

为什么要盘点制品?因为制品管理的混乱会带来一连串问题:

版本追踪的噩梦:出了问题要回滚,找不到上个版本的包在哪。或者找到了,不确定是不是真的上个版本。

存储成本失控:没有清理机制,历史版本堆积如山。我见过一个团队,三年积累了2TB的jar包,其中90%是没用的历史版本。

安全隐患重重:制品里可能包含敏感配置、硬编码的密码。如果管理不当,这些信息很容易泄露。

部署效率低下:每次部署都要到处找包,或者重新编译。本来 10 分钟能完成的部署,硬是搞成了 1 小时。

盘点制品资产时,我们需要搞清楚:

  • 制品存在哪里?是 FTP、还是专业的制品仓库?
  • 版本管理策略是什么?保留多少个历史版本?
  • 制品的构建和发布流程是否标准化?
  • 有没有制品安全扫描?
  • 制品的访问权限管理是否合理?

建立规范的制品管理体系,看似是个小事,但对提升研发效率、保障系统安全都有重要作用。这也是为什么现代化的研发团队都会使用专业的制品仓库,而不是简单粗暴地用文件夹管理。

盘点的过程就是发现问题的过程

技术资产盘点最大的价值,不是得到一份资产清单,而是在这个过程中发现的问题。这些问题,往往就是我们这些空降的技术管理者的破局点。

比如:

  • 为什么同样的功能,A 团队用 10 台服务器,B 团队要用 50 台?
  • 为什么数据库连接数经常爆满,但 QPS 并不高?
  • 为什么 CDN 流量忽高忽低,找不到规律?
  • 为什么某个服务的日志特别多,一天就是几个 T?

这些问题的答案,可能是架构不合理,可能是代码有 bug,可能是产品设计有问题,也可能只是配置错误。但不管是什么原因,都是改进的机会。

如何做好技术资产盘点

说了这么多为什么,该说说怎么做了。

1. 不要贪大求全

很多人一上来就想把所有东西都盘点清楚,结果战线拉得太长,什么都没做好。

正确的做法是:先盘点最重要的,最花钱的,最容易出问题的。比如先看数据库和服务器,这通常占技术成本的大头。如果是内容业务,还有存储,如果是 AI 业务。还有算力或者外部大模型 API 等等。

2. 不要只看数字

“我们有 100 个 API”——这是数字 “我们有 100 个API,其中 30 个是僵尸接口,20 个性能有问题,10 个存在安全隐患”——这是洞察

盘点不是为了得到一个数字,而是为了理解现状,发现问题。

3. 要深入但不要钻牛角尖

盘点数据库要不要细到每个字段?大部分情况下不需要。但核心业务的核心表,我们必须了如指掌。

把握好粒度,既要有全局视角,又要有局部洞察。

4. 借助工具但不依赖工具

市面上有很多资产管理工具,可以自动发现服务器、统计资源使用率等。这些工具很有用,但不要完全依赖它们。

真正的理解来自于和团队的深入交流,来自于对业务的理解,来自于对历史的了解。工具只能告诉我们「是什么」,但只有人才能告诉你「为什么」。

5. 让团队参与进来

技术资产盘点不是管理者一个人的事。让团队参与进来,既能获得更准确的信息,又能让大家都有「当家」的感觉。

可以让每个小组负责盘点自己的模块,然后一起 review。这个过程中,我们会发现很多有意思的事情,比如 A 组和 B 组对同一个服务的理解完全不同。

盘点之后呢

完成技术资产盘点只是开始。真正的价值在于基于盘点结果的行动。

建立资产台账

别让盘点结果躺在Excel里吃灰。建立一个活的资产台账,定期更新,让它成为团队的知识库。

新人入职,先看资产台账;技术决策,先查资产台账;故障排查,资产台账能帮大忙。

制定优化计划

基于盘点发现的问题,制定优化计划。哪些是quick win,可以马上做?哪些需要长期规划?哪些需要跨团队协作?

记住,罗马不是一天建成的,技术债也不是一天能还清的。有节奏地推进,比急于求成更重要。

建立监控体系

光盘点不够,还要建立监控体系。资源使用率、成本趋势、性能指标……这些都要持续监控。

很多问题都是慢慢积累的。如果没有监控,等我们发现时可能已经很严重了。

形成资产管理文化

最高境界是形成资产管理的文化。让每个人都有成本意识,都知道自己用的资源值多少钱,都会主动优化。

这需要时间,需要机制,更需要管理者的坚持。

最后

技术管理空降,最难的不是推新技术、搞创新,而是先把现有的东西搞清楚。这就像医生看病,不把脉、不验血,上来就开药,那是江湖郎中。

技术资产盘点,就是给技术体系做一次全面体检。只有知道了哪里健康、哪里有病,才能对症下药。

这个过程可能很枯燥,可能会发现很多历史遗留问题让人头疼,但这是建立手感、获得掌控、赢得信任的必经之路。

记住,管理的本质是通过他人完成工作。而要想通过他人完成工作,我们首先得知道工作是什么、资源在哪里、问题在哪里。

技术资产盘点,就是回答这些问题的第一步。

不要急着证明自己,先把家底摸清楚。当我们真正理解了这个技术体系,知道了每一分钱花在哪里、每一个系统为什么存在、每一个问题因何而生,我们的管理才能真正落地。

毕竟,空降兵最重要的不是会打仗,而是先活下来。而活下来的第一步,就是搞清楚自己降落在哪里。

做了 10 年SaaS 产品后,我总结的权限设计避坑指南

做 SaaS 产品这么多年,我发现权限控制是个特别有意思的话题。说它简单吧,很多团队都做得奇奇怪怪;说它复杂吧,掌握了核心原理后其实也就那么回事。

如果你是产品经理、技术负责人,或者正在做 B 端产品的创业者,这篇文章可能会对你有一些帮助。今天咱们就聊聊 SaaS 产品里的权限控制,怎么设计、怎么实施、怎么避坑。

1 为什么权限控制这么重要

说个数据:2022 年 SaaS 安全报告显示,43% 的企业因为权限配置错误导致过数据泄露。而业内人士都知道,实际比例可能高达63%——很多公司出了事都选择悄悄处理,不对外声张(也能理解的)。

再看一下 2020 年,微盟删库事件,一个运维人员因为跟公司有矛盾,趁着自己还有生产环境的管理员权限,直接把核心数据库给删了。

300 万商家的店铺全部瘫痪,整整 7 天无法营业。正值疫情期间,很多商家本来就靠线上维持生计,这一下彻底断了收入来源。最后微盟赔偿了1.5亿,股价暴跌,品牌信誉更是一落千丈。

事后复盘发现问题出在哪?

  • 一个人就能删除生产数据库,没有任何审批流程
  • 删除操作没有双人复核机制
  • 权限过度集中,运维人员的权限大到离谱

以此作为警示:对 SaaS 行业来说,权限管理不是技术问题,是生死问题。

为什么说权限问题往往比较致命?

做了这么多年 ToB 产品,我发现权限问题有几个特点:

1. 爆发性强:不像性能问题是逐渐恶化,权限问题是突然爆发。今天还好好的,明天就可能因为一个配置错误,导致全部客户数据泄露。

2. 影响面广:一个权限漏洞,可能影响所有客户。特别是多租户架构,一个 bug 就能让所有租户的数据混在一起(如果在多租户逻辑中使用的是字段隔离,而且大部分 SaaS 产品是这样做的)。

3. 修复成本高:早期设计不好,后期改造就是噩梦。

4. 信任难恢复:客户把核心数据放在你的系统里,是基于信任。一旦出现权限问题,这种信任很难恢复。哪怕你后来改得再好,客户心里也会有阴影。

权限控制是基础,这就像盖房子,地基不牢,楼盖得越高越危险。

2 权限控制的核心概念

在深入讨论之前,咱们先把几个基本概念理清楚。

2.1 权限的本质是什么

说白了,权限就是回答一个问题:谁能对什么做什么操作?

  • 谁:用户、角色、部门
  • 什么:功能模块、数据对象、页面按钮
  • 操作:查看、创建、编辑、删除、审批

这三个要素组合起来,就构成了权限控制的基础。比如「财务主管可以查看所有部门的报销单」,这就是一条权限规则。

2.2 功能权限和数据权限

很多人容易把这俩混在一起,其实它们解决的是不同维度的问题。

功能权限控制的是「能不能用这个功能」。比如普通员工看不到薪资管理模块,这就是功能权限。实现起来相对简单,一般在前端控制菜单显示,后端做接口校验就行。

数据权限控制的是「能看到哪些数据」。同样是查看订单列表,销售 A 只能看自己的订单,销售主管能看整个团队的订单,老板能看全公司的订单。这就是数据权限,实现起来要复杂得多。

有一个典型案例:某 CRM 系统,销售经理发现自己看不到下属的客户数据,一查才发现只做了功能权限,忘了做数据权限。结果所有销售经理都只能看到自己作为销售时录入的客户,管理功能形同虚设。

2.3 权限的安全边界

做权限控制,安全永远是第一位的。我总结了几个容易踩坑的地方:

前端权限不可信:永远不要只在前端做权限判断,哪怕把按钮隐藏了,懂技术的人照样能通过开发者工具发请求。所有权限判断必须在后端再做一遍。

默认拒绝原则:权限设计应该是「没有明确允许的都是禁止的」,而不是「没有明确禁止的都是允许的」。这个原则能避免很多安全漏洞。

最小权限原则:给用户的权限应该刚好够用就行,不要为了方便给过多权限。特别是生产环境的管理员权限,能不给就不给,给了也要有审计日志。

3 三种主流权限模型

聊完基础概念,咱们来看看业界常用的几种权限模型。每种模型都有自己的适用场景,没有绝对的好坏。

3.1 ACL

ACL,访问控制列表,是最直观的权限模型,直接定义「用户-资源-权限」的对应关系。比如:

  • 张三可以编辑文档 A
  • 李四可以查看文件夹 B
  • 王五可以删除报表 C

优点是简单直接,实现容易。早期的文件系统、简单的内容管理系统多用这种模型。

缺点也很明显:用户一多就没法管理了。假设你有 1000 个用户,100 个资源,每个资源有 5 种操作权限,理论上你需要维护 50 万条权限记录。更要命的是,新员工入职你得一个个配置权限,员工离职你得一个个回收权限,运维成本极高。

所以 ACL 一般只适合用户量少、权限关系简单的场景。如果你的 SaaS 产品用户量大,还是趁早换其他模型。

3.2 RBAC

RBAC,基于角色的访问控制,是目前最主流的权限模型,核心思想是引入「角色」这个中间层。用户不直接拥有权限,而是通过角色来获得权限。

比如定义几个角色:

  • 销售员:可以查看和编辑自己的客户、订单
  • 销售主管:可以查看和编辑本部门所有客户、订单,可以查看销售报表
  • 财务人员:可以查看所有订单,可以开具发票,可以查看财务报表

新员工入职,只需要给他分配对应角色就行了。角色的权限变了,所有该角色的用户权限自动更新。

RBAC 还可以细分为四种类型,实际应用中按需选择:

RBAC0(基本模型):最简单的实现,用户-角色-权限三层结构。大部分中小型 SaaS 产品用这个就够了。

RBAC1(角色分层模型):角色可以继承。比如「销售主管」自动继承「销售员」的所有权限,再加上管理权限。这样可以减少重复配置。

RBAC2(角色限制模型):增加了约束条件。比如「角色互斥」(一个用户不能既是采购员又是审批员),「角色数量限制」(一个用户最多只能有 3 个角色)等。

RBAC3(统一模型):集成了 RBAC1 和 RBAC2 的所有特性,最完整但也最复杂。

我的建议是从 RBAC0 开始,随着业务发展再考虑升级。过度设计只会增加系统复杂度。

3.3 ABAC

ABAC,基于属性的访问控制,是相对较新的模型,通过属性组合来判断权限。这些属性可以来自:

  • 用户属性:部门、职级、工龄、地域
  • 资源属性:类型、创建者、敏感度、标签
  • 环境属性:时间、地点、设备类型

举个例子:”华东区的销售经理在工作时间可以查看本区域高价值客户的信息”。这条规则涉及了用户的地域属性、角色属性,资源的地域属性、价值属性,以及时间这个环境属性。

ABAC 的优势是灵活性极高,可以实现非常精细的权限控制。缺点是实现复杂,性能开销大,权限规则难以理解和调试。

一般来说,如果你的业务场景确实需要这么复杂的权限控制(比如医疗、金融等强监管行业),可以考虑 ABAC。否则 RBAC 就足够了。

4 SaaS 产品的特殊挑战

相比传统的企业内部系统,SaaS 产品在权限控制上面临一些独特的挑战。

4.1 多租户隔离

这是 SaaS 最核心的需求。同一套系统里住着几百上千家企业,必须保证数据完全隔离。A 公司的员工绝对不能看到 B 公司的任何数据。

常见的隔离方案有三种:

独立数据库:每个租户一个数据库。隔离性最好,但成本高,难以维护。适合大客户少量部署的场景。

共享数据库、独立 Schema:每个租户一个 Schema。隔离性不错,成本适中。适合中等规模的 SaaS 产品。

共享数据库、共享表:所有租户的数据都在同一张表里,通过 tenant_id 字段区分。成本最低,但要特别小心 SQL 注入和权限泄露。这是大部分 SaaS 产品的选择。

如果采用第三种方案,一定要在所有 SQL 查询中强制加上 tenant_id 条件。我见过的好做法是在 ORM 层面做全局过滤器,或者在数据库层面用行级安全策略(Row Level Security)。

4.2 组织架构的映射

企业客户通常都有复杂的组织架构,我们的权限系统必须能够映射这种结构。常见的需求包括:

  • 树形部门结构,支持多层级
  • 一个人可能属于多个部门(兼职、虚拟团队)
  • 临时授权(代理、请假)
  • 按项目组、按地域等多维度的权限控制
  • 集团,公公司等逻辑

我的经验是,组织架构不要做得太复杂,够用就行。很多企业其实就是简单的部门层级 + 角色,硬要上矩阵式组织、事业部制这些复杂结构,反而增加了使用成本。

4.3 权限的动态性

SaaS 产品的权限需求经常变化:

  • 新功能上线,需要新的权限点
  • 客户要求定制化的权限规则
  • 不同行业、不同规模的客户,权限需求差异很大

所以权限系统必须设计得足够灵活。我推荐的做法是:

权限点动态化:不要把权限点写死在代码里,而是存在数据库里,通过配置来管理。

规则引擎:对于复杂的权限判断逻辑,可以引入规则引擎,让权限规则可以通过配置来调整。

权限模板:为不同类型的客户准备权限模板,新客户注册时可以快速初始化。

4.4 性能优化

权限判断是高频操作,一个页面可能要判断几十上百个权限点。如果每次都查数据库,性能肯定扛不住。

常用的优化手段:

缓存:用户登录时把权限信息缓存到 Redis,设置合理的过期时间。权限变更时主动刷新缓存。

权限位图:把权限用位图来表示,一个 long 型变量可以表示 64 个权限点,判断权限只需要位运算。

懒加载:不要一次性加载所有权限,而是按需加载。比如用户进入某个模块才加载该模块的权限。

预计算:对于数据权限,可以预先计算好用户能访问的数据 ID 列表,查询时直接用 IN 条件。

5 设计一个权限系统

说了这么多理论,咱们来点实际的。假设你要为一个 SaaS CRM 系统设计权限控制,应该怎么做?

5.1 需求分析

首先要搞清楚业务需求:

  • 系统有哪些功能模块?客户管理、订单管理、报表分析等
  • 有哪些角色?销售员、销售主管、客服、财务、管理员等
  • 数据权限如何划分?按部门、按区域、按客户等级等
  • 有哪些特殊需求?审批流程、临时授权、数据导出限制等

5.2 模型选择

对于 CRM 这种相对标准的业务系统,RBAC 是首选。具体用 RBAC0 还是 RBAC1,看企业规模:

  • 中小企业:RBAC0 足够,角色数量有限,权限关系简单
  • 大型企业:考虑 RBAC1,利用角色继承减少配置工作

5.3 数据库设计

核心表结构:

-- 用户表
CREATETABLEusers (
    idBIGINT PRIMARY KEY,
    tenant_id BIGINTNOTNULL,
    username VARCHAR(50NOTNULL,
    -- 其他字段...
    INDEX idx_tenant (tenant_id)
);

-- 角色表
CREATETABLEroles (
    idBIGINT PRIMARY KEY,
    tenant_id BIGINTNOTNULL,
    role_name VARCHAR(50NOTNULL,
    parent_id BIGINT-- 用于角色继承
    -- 其他字段...
    INDEX idx_tenant (tenant_id)
);

-- 权限表
CREATETABLE permissions (
    idBIGINT PRIMARY KEY,
    permission_code VARCHAR(100NOTNULL-- 如 'customer.view'
    permission_name VARCHAR(100NOTNULL,
    moduleVARCHAR(50), -- 所属模块
    -- 其他字段...
    UNIQUEKEY uk_code (permission_code)
);

-- 用户-角色关联表
CREATETABLE user_roles (
    user_id BIGINTNOTNULL,
    role_id BIGINTNOTNULL,
    PRIMARY KEY (user_id, role_id)
);

-- 角色-权限关联表
CREATETABLE role_permissions (
    role_id BIGINTNOTNULL,
    permission_id BIGINTNOTNULL,
    PRIMARY KEY (role_id, permission_id)
);

-- 数据权限规则表
CREATETABLE data_permissions (
    idBIGINT PRIMARY KEY,
    role_id BIGINTNOTNULL,
    resource_type VARCHAR(50), -- 如 'customer', 'order'
    rule_type VARCHAR(50), -- 如 'self', 'department', 'all'
    rule_value TEXT-- 具体规则,可以是 JSON
    INDEX idx_role (role_id)
);

6 避坑指南

做了这么多项目,我总结了一些常见的坑,希望你能避开:

6.1 过度设计

最常见的错误就是一上来就想做一个「完美」的权限系统。支持 ABAC、支持动态规则、支持工作流集成… 结果做了半年还没上线,业务等不及了。

记住,权限系统是为业务服务的,不是为了秀技术。先满足基本需求,再逐步迭代。

6.2 忽视性能

另一个常见问题是只关注功能,不关注性能。权限判断是高频操作,如果每次都要查十几张表,系统很快就会崩溃。

一定要做好缓存,关键接口要做压测。我的经验是,权限判断的响应时间应该控制在 10ms 以内。

6.3 权限配置过于复杂

有些系统的权限配置界面,复杂得连开发人员都搞不清楚。这样的系统,客户是不会用的。

权限配置要尽量简化,提供合理的默认值和模板。最好能提供权限检查工具,让管理员可以模拟某个用户的权限,看看到底能访问哪些功能和数据。

6.4 缺少审计日志

权限系统必须有完善的审计日志,记录谁在什么时候做了什么操作。特别是权限的授予和回收,必须有据可查。

这不仅是安全需要,很多行业还有合规要求。审计日志最好是独立存储,防止被篡改。

6.5 数据权限的 N+1 问题

实现数据权限时,很容易出现 N+1 查询问题。比如查询订单列表,每个订单都要判断一次是否有权限查看,结果一个列表页产生了上百次数据库查询。

解决方案是在列表查询时就加入权限过滤条件,而不是查出来再过滤。这需要在 SQL 层面就考虑权限问题。

7 其它一些变化

权限控制这个领域,这几年也有一些新的发展趋势:

7.1 Zero Trust 模型

Zero Trust 模型就是我们常说的零信任模型。

传统的权限模型是「城堡式」的:进了城门(登录系统)就基本畅通无阻。Zero Trust 模型要求每次访问都要验证权限,不管你是内部用户还是外部用户。

这对 SaaS 产品来说特别重要,因为用户可能从任何地方、任何设备访问系统。

7.2 AI 辅助的权限管理

利用机器学习来优化权限配置,比如:

  • 根据用户行为自动推荐合适的角色
  • 检测异常的权限使用,可能是账号被盗用
  • 自动发现权限配置中的冲突和冗余

7.3 细粒度的数据权限

不仅控制能不能看某条数据,还要控制能看到数据的哪些字段。比如普通销售能看到客户的基本信息,但看不到信用额度;财务能看到信用额度,但看不到跟进记录。

这需要在字段级别做权限控制,实现起来更复杂,但确实是一些行业的刚需。

8 写在最后

权限控制是 SaaS 产品的基础设施,做好了用户感知不到,做不好用户骂声一片。它不是一个能带来直接收益的功能,但却是产品能否长期发展的关键。

我的建议是:

  1. 不要等到出问题才重视权限,一开始就要规划好
  2. 选择适合自己业务的权限模型,不要过度设计
  3. 功能权限和数据权限要分开考虑,都很重要
  4. 做好性能优化和安全防护,这是基本要求
  5. 保持系统的灵活性,因为需求一定会变

技术是为业务服务的。不要为了炫技而把简单问题复杂化,也不要为了省事而在安全问题上偷懒。在这两者之间找到平衡,才是一个成熟的技术方案。

以上。