★ FEATURED ARTICLE 1. 凭据混用的代价为什么HeySmart要把隔离当成第一优先级做智能服务类的项目尤其是HeySmart这种需要对接多个第三方供应商、多个内部微服务的平台最先要回答的问题往往不是功能怎么做而是密钥放哪里。很多人觉得这问题很基础基础到不值得专门写一篇文章。但我在实际项目里见过太多次因为凭据管理不当引发的连锁事故坦白说功能上线半年没出事很多时候只是运气好。1.1 一次典型事故的复盘一条AK打穿所有环节先说一个我参与过的真实案例不是HeySmart但非常具有参考价值。当时某个团队把所有第三方API密钥、数据库密码、对象存储的AccessKey全部写在一个配置中心里而且所有服务共用同一个密钥。某天一个前端项目在打包时把后端配置文件的路径暴露到了静态资源里里面恰好包含了一条带有完整权限的AccessKey。两天后账单上出现了一笔异常的对象存储下载费用检查后发现有人用这条AK遍历了整个Bucket目录把数据打包拖走。问题的根源不是加密不够而是凭据没有被隔离。一条密钥泄露等于整个系统裸奔。做HeySmart的安全设计时我直接把凭据隔离提到了架构层面的最高优先级。原因很简单凭据隔离做不好后续做再多的接口鉴权、数据加密、WAF防护都等于在大门上装金锁钥匙却挂在门口。1.2 凭据隔离要防住的三种攻击路径把凭据隔离这件事拆开看它防的其实是三类常见攻击路径第一种是横向移动。攻击者拿到某个服务的凭据后用它去访问另一个服务。如果所有服务共享凭据横向移动几乎不设防。比如拿到数据库密码顺手访问Redis再通过Redis写文件拿到服务器权限。隔离之后每把钥匙只能开一扇门横向移动的成本和噪音都会显著增加。第二种是供应链泄露。现在的项目大量依赖开源组件和第三方SDK某个依赖包被投毒或者某个工程文件被上传到公开仓库都可能把硬编码的密钥带出去。凭据如果集中托管而不散落在代码和配置里供应链单一环节泄露的影响面就会被限制住。第三种是内部人员越权。不是说团队成员不可信而是最小权限原则本身有助于减少误操作。一个只需要读权限的调度任务给了它写权限某次SQL写错就能把生产数据清掉。凭据隔离配合权限收敛可以让误操作的影响面也降到最低。1.3 设计威胁模型先搞清楚你的对手要什么做凭据隔离之前我习惯先拉一个简单的威胁模型明确这几件事谁可能拿到凭据外部攻击者、恶意第三方组件、内部低权限员工还是仅仅因为操作失误拿到凭据后最有价值的目标是什么是客户数据、第三方API的调用额度还是云主机的控制权凭据泄露后我们有多长的时间窗口来发现和处置这个模型不需要写成几十页的文档一页纸足够。但它能帮你决定隔离的力度。比如HeySmart核心数据是用户的行为日志和对话记录那么对象存储和数据库的凭据就是最需要保护的对象而一些公开的只读数据源隔离策略可以适当放松没必要把系统所有环节都勒到窒息。2. 第一道防线云端凭据集中托管与动态下发明确要隔离之后接下来是技术选型。很多团队的第一反应是把密钥放到环境变量里这确实比硬编码进代码强但远远不够。环境变量的问题是它只在应用启动时读取一次、在进程内存和容器环境里长期存在而且难以追踪谁在什么时候读到了它。2.1 环境变量的局限从12-Factor到现实中的五个坑12-Factor应用规范里建议把配置存入环境变量这本身没错但落地时会踩到几个具体的坑第一个坑环境变量在镜像构建时被固化。很多人不是用运行时的环境变量而是用ENV指令把密钥直接写进Dockerfile。镜像推送到私有仓库后任何能拉取镜像的人都能用docker inspect看到密钥这比硬编码好不到哪里去。第二个坑环境变量的可见性不可控。在Kubernetes里env字段的值通过API就能看到有get pods -o yaml权限的成员都可以读到明文。第三个坑轮换困难。环境变量通常是进程启动时读取一次改了配置不重启不生效。但重启就涉及可用性窗口于是很多团队因为怕麻烦硬是把一个快要过期的密钥拖到最后一天才换。第四个坑难以审计。谁在什么时间访问了环境变量背后的真实密钥环境变量方案回答不了这个问题。第五个坑多环境之间容易串。开发、测试、生产三套配置偶尔写错一个变量名调试半小时才发现用的是生产数据库地址。隔离本身也包含了环境之间的隔离。2.2 集中托管让每套环境都有独立的密钥体系我在HeySmart里采用的方案是云端集中托管服务也就是把密钥放到专门的凭据管理系统里。选型时对比过几款主流产品包括HashiCorp Vault、云厂商自带的密钥管理服务以及自建的开源替代方案最终结合团队规模选择了云厂商的托管服务。这里核心的思路是机器不再拥有永久密钥应用运行时才向托管服务申请临时凭据。集中托管后可以做几件环境变量做不了的事细粒度授权每个服务有自己独立的身份只能读取自己需要的那些密钥。自动轮换托管服务可以按周期旋转密钥应用拿到的临时凭据通常几十分钟到几小时就会失效。全量审计每一次凭据的获取、每一次密钥的读取都有记录。提示如果团队规模小或者不想绑定特定云厂商社区版的Vault也是一个不错的选择。但自建意味着你要自己扛高可用、备份和升级人力成本要算进去。我倾向于在业务早期直接用云托管等团队有时间了再评估是否自建。2.3 应用侧接入Sidecar注入与SDK拉取两种路径凭据管理系统的接入方式主要有两种我分别说下适用场景。第一种是Sidecar注入。在Kubernetes环境下给每个业务Pod附加一个轻量级代理容器代理负责与凭据管理系统通信把获取到的临时凭据通过内存文件系统挂载给业务容器。业务代码层面的改动很小只需要读取固定路径下的文件。适合Java、Go这类传统微服务也适合大量历史服务改造的场景。第二种是SDK直接拉取。业务代码直接调用SDK应用启动时向凭据管理系统请求凭据拿到后在内存里使用。这种方式灵活度最高可以把刷新、重试逻辑写进自己的框架里也方便在单元测试里做Mock。但需要统一的SDK版本管理和编码规范团队如果没有统一的开发框架容易各行其是。HeySmart最终选择的是SDK方式。原因是团队里Go和Python服务占了绝大多数统一维护一套SDK封装成本可控而且我们希望在凭据刷新时做更多细粒度的业务日志记录SDK更容易实现。2.4 动态凭据的场景化注意事项缓存、刷新与优雅降级引入动态凭据之后有一个最容易被忽视的问题应用拿到凭据后的生命周期管理。凭据管理系统签发的临时凭据有时效业务服务如果每次请求都去申请一次一是延迟高二是容易触发托管服务的限流。所以必须在SDK里做缓存。但缓存的过期时间设置很讲究设得太短频繁申请设得太长又失去了临时的意义。我用的策略是缓存时间设为凭据有效期的一半比如凭据有效期40分钟那么20分钟就去主动刷新一次。这样即使刷新失败内存里还有20分钟的旧凭据可以继续用不会立刻中断线上服务。另外还要处理优雅降级。假设凭据管理系统本身故障了业务服务怎么办我在代码里加了降级开关如果内置的旧凭据仍处于有效期内允许它继续工作同时发出告警如果旧凭据已过期则直接返回错误而不是无限重试。这段逻辑听起来简单但真上线后能避免好几次大事故。不夸张地说凭据本地缓存策略是整个隔离体系里最容易出细节问题的地方。3. 第二道防线最小权限与临时凭据的生命周期管理凭据隔离不等于把密钥分散放到不同地方就行。隔离的核心是权限边界。如果你给每个服务单独发了一把密钥但每把密钥都有整个云账号的管理权限那隔离就形同虚设。3.1 为每项服务签发独立身份在HeySmart的架构里每个微服务都有一个独立的云身份这个身份只拥有它真正需要的权限。举个例子用户服务只允许读写用户库中的用户表不能访问订单表不能访问对象存储。对话服务只允许调用对话模型的API和读取模型配置不能访问对象存储中的模型文件。调度任务只允许读取任务表和向消息队列发送消息不能修改任务状态更不能删除表。有人会问这样做是不是太麻烦权限列表维护成本很高。确实高但这种麻烦本质上是把运维压力前置了换来的是一旦某个服务被攻破攻击者的活动半径非常有限。一个只被授权读一张表的API密钥即使泄露了攻击者也很难靠它推进攻击。3.2 用短期令牌替代长期密钥长期密钥一旦泄露在轮换之前一直有效攻击者有充足的时间利用它。所以我在设计里优先使用短期令牌并且把到期时间尽量缩短。具体做法是各服务之间互相调用时不使用API Key而是通过身份管理服务签发JWT或类似的短时令牌。令牌默认有效期设为15分钟部分高安全场景甚至压缩到5分钟。服务拿到令牌后再调用目标服务目标服务只校验令牌签名和时效不关心调用方是什么IP、什么容器。这里有一个经验值令牌有效期不能一味追求短。太短会导致服务间调用频繁刷新增加身份服务的压力。我建议从15分钟起步观察一段时间的刷新成功率再调整。3.3 自动化轮换是唯一不会让人崩溃的轮换方式长期密钥的轮换是很多团队最头疼的事。人工轮换通常发生在密钥快过期了或者疑似泄露的时候这就意味着两次轮换之间有很长的暴露窗口。自动化轮换的要点在于先签发新密钥等业务稳定后再禁用旧密钥。也就是有一个重叠期。我常用的节奏是凭据管理系统通过策略自动生成新版本密钥。应用在下次刷新时拿到新密钥同时旧密钥在内存里保留一段时间。观察一段时间确认应用已经全部切换到新密钥再标记旧密钥为禁用并从系统中删除。这个流程对用户是透明的服务不会因为轮换而重启。需要注意的点是必须把禁用旧密钥也纳入自动化流程只生成不回收久而久之密钥数量膨胀管理成本反而升高。3.4 数据库、对象存储、消息队列的权限逐项收紧不同资源的权限模型差别很大我逐个说一下在HeySmart里的落地方式。数据库层面我尽量让每个服务使用独立的数据库账号而不是共用同一个高权限账号。独立的账号配合库表级别的授权可以在数据库层面再兜一层底。同时禁止所有服务使用云账号的根用户直连数据库。对象存储层面使用按前缀划分的Bucket策略或IAM策略。比如对话服务只允许访问bucket/private/hey/chat/前缀模型服务只允许访问bucket/private/hey/models/前缀。策略里显式禁止ListAllBuckets这类高危操作。消息队列层面生产者和消费者使用不同权限的账号。生产者只能发消息消费者只能读自己队列里的消息。这样即使一个消费者的凭据泄露攻击者也只能消费消息而不能伪造消息。注意权限收紧的粒度要和团队运维能力匹配。如果你只用了三五个服务就没必要把一个数据库账号拆成二十个否则光是创建账号、管理授权就会占用大量时间。我建议是服务数量在10个以内时账号粒度保持1个服务1个账号规模上来之后再考虑按业务域合并或拆分。4. 第三道防线运行时隔离把泄露面降到最小凭据管理的再往后一层是运行时隔离。即使凭据本身管理到位了如果攻击者可以直接在你的服务器上执行命令他依然有办法从进程内存里把密钥抠出来。所以运行时环境的设计也要配合凭据隔离一起做。4.1 进程级与容器级隔离让密钥只属于特定进程在容器化部署里我坚持一个原则每个服务一个容器每个容器只有一个职责。这不是为了部署方便而是为了保证密钥的可见范围。设想一下如果你把一个负责处理用户上传文件的进程和一个负责调用支付API的进程放在同一个容器里容器内共享环境变量和文件系统那么任何一个进程的漏洞被利用另一个凭据也会暴露。容器隔离之后即使某个服务被攻破攻击者还需要再进行一次容器逃逸才能碰到其他服务的凭据这个门槛是实实在在的。Kubernetes环境中还可以用安全上下文来进一步收紧权限。例如容器内以非root用户运行即使被getshell也不会直接获得root权限。文件系统设置为只读只有挂载的临时目录可写减少攻击者写入恶意文件的可能性。禁用特权容器关闭不需要的Linux capabilities。这些配置属于基础安全加固但我说句实话很多团队在快速迭代时都没来得及做。HeySmart从第一天就规范好了后面省了大量补课的时间。4.2 网络边界凭据不应该全网可见凭据隔离还包含一个容易被忽略的维度网络访问控制。凭据管理系统本身就是一个高价值目标所以绝不能放在公网可达的区域。我把它放进私有网络只有应用所在的子网能访问。与此同时业务服务之间的调用也尽量通过服务网格或者安全组规则来限定来源。这样即使有人拿到了某个服务的凭据他从外部网络也无法直接访问凭据管理系统去申请更多密钥。另外SSH密钥的管理也要纳入隔离范畴。不要用同一把SSH密钥管理所有服务器建议按环境分开发、测试、预发、生产各用各的并且开启双因素认证。4.3 日志与审计所有的凭据使用都要能追踪隔离做得再严密也需要能回答一个问题发生了什么什么时候发生的所以审计日志是凭据隔离体系里不可省略的一部分。我在HeySmart里建立了三层审计第一层是凭据管理系统的访问审计记录所有对密钥的读取操作字段至少包含时间、调用者身份、目标密钥名、来源IP和调用结果。第二层是业务系统的敏感操作审计比如调用模型API、读取用户文件等操作全部记录操作者和目标对象。第三层是日志脱敏。业务日志中严禁打印完整密钥、令牌或者包含Authorization头的请求内容。日志组件的管道里加一个脱敏过滤器凡是匹配到密钥格式或者令牌格式的字段统一替换成掩码。这个一定要在研发规范里定死否则某个开发同学为了排查问题随手加一行日志就可能把临时凭据打出来。经验日志脱敏过滤器的正则要覆盖常见的密钥格式包括但不限于AKIA开头的访问密钥、sk-开头的API密钥、JWT三段式令牌、以及各种形如password或token:的参数。上线前用一组包含真实格式的测试数据专门验证脱敏效果。4.4 应急响应凭据泄露后的第一小时做完隔离不代表永远不出事更重要的是出事之后能快速止血。我整理了一个简单的应急预案分享出来供参考。当疑似凭据泄露时按这个顺序处理立即在凭据管理系统中吊销泄露的凭据或者禁用对应的身份。这个过程应该能在两分钟内完成所以要提前演练。通知应用侧重新刷新凭据不要手动重启服务等缓慢流程而是触发SDK的强制刷新接口。拉取泄露凭据近24小时的使用日志重点看有没有异常IP和异常调用频率。如果泄露发生在云平台进入云控制台检查相关账号的近期操作记录。根据审计结果判断影响范围决定是否需要将数据回滚或者通知相关方。我见过太多团队在泄露发生后的第一反应是查日志找原因这是错的。第一时间应该是止损也就是吊销凭据而不是先侦查。侦查可以晚一点但凭据多存在一秒风险就多一分。5. 落地路线图从零到一的四个阶段与常见反模式前面讲的是技术层面怎么做这一节我想说说推进的过程。一个完整的安全改造如果一上来就铺开做一定会遇到巨大的阻力。我的建议是分阶段推进。5.1 四个阶段与验收指标阶段一是摸底。梳理所有服务的凭据类型、存储位置、调用方式输出一张表至少包含凭据名称、用途、当前存储方式、是否有硬编码、权限范围。这一步不改变任何东西只做盘点。阶段二是优先迁移高风险项。先处理那些硬编码在代码里的密钥、有管理员权限的密钥、以及已经泄露过或疑似泄露过的密钥。把它们接入凭据管理系统设置独立的身份和最小权限。验收指标很具体主干仓库中不再出现任何明文密钥扫描工具通过。阶段三是全量接入。所有服务统一走凭据管理系统获取凭据本地不再保存长期密钥。验收指标是重启任意服务不需要人工输入密钥凭据轮换时系统零操作。阶段四是常态化运营。审计日志持续上报自动化轮换覆盖所有长期密钥定期比如每季度重放威胁模型确认隔离策略仍然覆盖新增服务。验收指标是新增服务在CI阶段就必须完成凭据隔离配置否则无法上线。5.2 我踩过或见过的五种反模式顺手总结几个反模式写出来给大家避坑。第一种是**开发环境无所谓**。开发环境的凭据管理得乱七八糟然后某次联调时开发环境数据库使用了生产环境的备份结果开发环境泄露的生产数据。我现在的原则是环境可以变凭据的管理标准不能变。开发环境也要托管只是权限范围可以小。第二种是**给所有服务开同一个只读账号**。有些账号确实只有只读权限但所有服务共用后任何日志里出现这个账号都无法定位是哪个服务泄露的。隔离的意义之一就是可归因性账号必须独立。第三种是**轮换只换密钥不换配置**。有些自动化工具更新了密钥本身但应用侧还拿着旧配置在内存里缓存。轮换流程必须包含应用侧刷新环节不然换了个寂寞。第四种是**凭据管理系统本身不做高可用**。它一挂所有服务都拿不到密钥整套系统瘫掉。我给它的冗余级别是和生产核心数据库一致的。第五种是**做完隔离就不做漏洞扫描**。凭据隔离是纵深防御的一部分不是终点。代码仓库、容器镜像、历史文档仍可能存在泄露的密钥定时扫描是必需的。5.3 顺手值得做的事一个清单最后列一份我在改造完成后顺手做的事情算是安全设计整体体系中与凭据隔离配套的清单仓库配置Secret扫描在CI阶段拦截包含疑似密钥代码的合并请求。为每个内部服务启用独立的可观测性仪表盘重点关注凭据刷新失败率和授权失败次数。给凭据管理系统的访问添加告警规则比如非工作时间的大批量密钥读取、单IP高频访问等。定一个密钥安全日每月检查一次所有密钥的权限范围是否需要收缩。新服务上线模板里强制包含凭据托管、日志脱敏、独立身份、网络隔离四项配置。凭据隔离这件事最让我意外的收获是它其实也在反向优化架构。当一个服务只能拥有自己需要的最少权限时服务之间的调用边界会变得清晰依赖关系也会显式化。它不只是一道安全防线也是一次架构治理的机会。如果你正打算做类似的改造别急着全面铺开先摸底、再迁移、再固化一步步来稳比快重要。
阅读完成 · 觉得有帮助？
