服务间 mTLS 是「全量强制」还是「分级灰度」：安全收益和运维成本的账，你们线上是怎么算的？

【背景】 我做了 15 年安全工程，最近一年在推内部东西向流量全量 mTLS（服务身份 + 双向证书）。推的过程中发现团队里对同一件事的结论完全相反：安全侧坚持「默认拒绝、全部强制」，运维侧坚持「先灰度、按敏感度分级」，两边都没错，但一直没吵出共识。想借这个帖子把大家的真实做法摆出来对一对。

【常见的几种做法 / 分歧点】

1. 全量强制派：所有服务间调用默认 mTLS，例外走白名单审批。理由是零信任模型下「默认不信任」才是安全基线，白名单越少攻击面越小；分级灰度会留下大量"永远不升级"的尾巴。
2. 分级灰度派：按数据敏感度 / 爆炸半径分级，核心链路（支付、凭据、内部 OpenAPI）先上，边缘工具类服务后上。理由是 80+ 服务一次性切换，证书签发、轮换、调试成本会压垮值班，事故时"是不是 mTLS 引起的"会拖慢排障。
3. 托管派：直接把 mesh（Istio/Linkerd 这类）交给平台团队，业务无感。分歧在于：sidecar 注入后的 P99 开销、排障复杂度（证书错误和超时混在一起很难一眼分辨），以及"平台不熟 mTLS 时谁来兜底"。
4. 自研派：不用 mesh，SDK 层做双向 TLS。分歧在于：证书生命周期管理（签发、轮换、吊销）在几百个服务上怎么做自动化，以及 SDK 升级会不会变成一场运动。

【我的倾向与理由】 我倾向「分级灰度 + 明确的升级时间表」，但有两个硬性底线：

• 所有跨边界（跨机房 / 跨团队 / 出内网）流量，从第 1 周起强制 mTLS，不留灰度窗口；
• 内部同边界流量给 1~2 个迭代灰度，但每个例外必须登记 owner 和到期日，到期不升就自动降级为"只记录不拦截"的旁路模式，而不是无限期白名单。 理由：安全收益集中在高价值资产上，边际成本却随服务数线性增长；一次性全量强制的失败模式不是"没上完"，而是"上到一半没人敢动、也没人敢撤"。灰度 + 到期机制把"安全债务"变成了有主、有期限的工单。

【想听大家在什么场景下怎么选】

• 你们线上是几百还是几千个服务？mTLS 覆盖率现在多少？卡在哪类服务上（老 Java 单体 / C 语言工具 / 第三方 SDK）？
• 证书生命周期你们怎么做的自动化？轮换周期多长？有没有因为证书问题背过锅？
• 分级灰度时，"敏感度分级"的判定标准是什么？谁拍板？有没有出现过分级标准本身吵了三个月的情况？
• 有没有人经历过"全量强制"的翻车现场——想听听事故复盘里 mTLS 到底贡献了多少排障时间。