一、项目背景

我们的 AI 网关早期对接调用方，图省事只用 API Key 做鉴权。一开始还行，等接入的业务方多了，问题就来了。一个业务方的 Key 因为代码写进前端被人扒出来，结果那把 Key 被人拿去刷我们的模型接口，一天烧掉我们大半个预算，还连累了正常业务被限流。安全团队拍桌子要求我们上双向认证，调用方必须拿证书才能握手。我们照做了，却踩了另一个坑，证书半年一过期，负责续期的同事离职了没人接，某天凌晨一批业务集体掉线，告警响成一片。

二、落地场景

现在网关侧强制 mTLS，调用方得先在证书中心签发一张客户端证书，握手时双方互验，证书不对直接拒。证书中心统一管理签发和吊销，每个调用方的证书绑定到具体应用和部门。网关侧配了到期预警，提前三十天开始催办。续期走自动化，脚本在到期前自动签发新证、推到调用方、网关热加载，全程不用人盯。吊销也接了实时列表，某把 Key 真泄露了，我们在证书中心一键吊销，网关下次握手就拦。

三、关键技术挑战与解决思路

首先要解决的是存量调用方迁移，几百个业务方不能一刀切全上 mTLS，我们做了兼容期，网关同时认 Key 和证书，新接入强制证书，老的给一个迁移窗口。接着要解决的是续期零中断，续期不能在业务跑着的时候让握手失败，我们让网关支持多证书并存，新证加载后旧证保留到自然过期，切换无感。还有一块难啃的是吊销及时同步，我们没用笨重的证书吊销列表全量下发，而是网关本地缓存加短周期刷新，吊销事件用消息推一把，秒级生效又不常打扰。

案例片段（已脱敏）： 网关 mTLS 与续期配置片段（字段示意）：mtls:  client_ca: ca-gateway-prod  verify: required  cert_ttl: 180d  auto_renew: true  renew_before: 30d  reload: hot          # 热加载，不重启  crl_refresh: 60s一次事故复盘：某调用方 Key 泄露，日耗暴涨约 8 倍；上 mTLS 后同类泄露需持证书，且证书中心一键吊销，网关 60s 内生效，未再出现预算被刷穿。

四、效果数据

mTLS 覆盖率从零提到接近全量接入，未授权调用拦截数上线首月就抓到十几起拿错证书或伪造证书的尝试。证书过期导致的集体掉线事故归零，自动续期跑起来后没人再手动盯到期日。续期自动化率到百分之百，我们运维基本不用碰证书。要承认，兼容期我们拖得有点长，老业务方一直没迁，结果是两套机制并行维护了大半年，下次我会把迁移窗口卡死。

五、可复用经验总结

网关鉴权这事，API Key 就像把家门钥匙挂在门外，谁捡到都能进，mTLS 才是把锁换成刷脸。但证书这东西，最大的坑不是签发，是续期，过期比泄露还阴，因为它专挑你没人盯的时候发作。自动续期加热加载，是我们踩了半夜掉线那次才补上的，现在看是刚需。迁移窗口我后来的建议是别心软，给太久大家都不动，最后还是你维护两套。这套做法后来我们推到其他几个对外的网关也顺。

结语

网关鉴权这事，API Key 像把钥匙挂门外，谁捡到都能进，mTLS 才是把锁换成刷脸。但我们踩的另一个坑更阴，证书过期比泄露还坑，专挑没人盯的凌晨发作，那次集体掉线让我记了很久。自动续期加热加载是必需品不是加分项，上了之后运维基本不碰证书。迁移窗口我后来建议别心软，给太久大家都不动，最后还是你维护两套机制，我们并行了大半年才清完。证书中心一键吊销接实时列表，让泄露的代价从预算被刷穿变成几十秒生效，这个能力在安全团队那边的评分很高。如果重来，我会把 mTLS 设为新接入的默认，老的给短窗口强迁，而不是长期兼容。另外我们后来把证书和调用方应用绑定，离职的人走了证书跟着回收，不再出现 Key 散落没人管的情况，安全审计也省事。多证书并存那段时间，网关支持新旧证同时有效，切换无感，这点对零中断很关键，值得在别的对外部署里照搬。续期脚本接了到期前三十天预警再自动签发热加载，全程无人值守，半夜再没被叫起过。身份跟着人走才是治理终点，想通之后合规压力小了一大半，这块我们交过学费才踏实。

我们顺手做了张证书资产表，谁有什么证、啥时候到期一目了然，审计来了直接导出不用翻日志。迁移给老调用方发双证过渡包，他们改一行配置就行，阻力小很多。离职的人证跟着回收，证书和调用方应用绑定，不再出现 Key 散落没人管的情况，安全审计也省事。mTLS 现在是对外部署的底线要求，新接入默认强制，没得商量。证书和调用方绑定后，我们顺手做了张资产表，谁有什么证、啥时候到期一目了然，审计来了直接导出。迁移那块我们给老调用方发了双证过渡包，他们改一行配置就行，阻力小了很多。mTLS 现在是我们对外部署的底线要求。