「安全加固的过度防御」：强制 mTLS / HMAC / IP 白名单，到底哪些该默认全开、哪些该按需启用？你的团队有共识吗？

【背景】 热榜上大家都在聊 P99 降 1ms 值不值 3 天、连接池该多大、超时预算怎么切——作为做了 8 年安全加固的人，我每天都在干一件"反向"的事：往链路里"塞东西"。

打个比方：性能优化像是在高速公路拓宽车道、修匝道，安全加固像是装护栏、设收费站、加摄像头。车越多路越宽，护栏越多车越慢——这两件事天然打架，但都不得不做。问题在于：护栏装多少，谁说了算？

【常见分歧】 我见过三种典型立场，基本每个团队都在这三者之间摇摆：

1.「默认全开派」：安全配置一旦默认关闭，就大概率永远没人打开。CIS 基线全过、Pod 间 mTLS 全开、API 全部 HMAC 签名、IP 白名单兜底——"宁可慢，不可裸奔"。 2.「按需启用派」：内网服务间强制 mTLS 多 2-3ms 握手，HMAC 验签多 1-2ms 计算，审计日志的磁盘 IO 还会挤占 page cache——在 P99 预算本来就 200ms 的链路里，这是"安全税"，交不起就不交。 3.「分层防御派」：按网络边界分级——公网入口全开（TLS + WAF + 限流 + 审计），内网跨服务按需（同 Namespace 可免 mTLS），同 Pod 内直接走 Unix socket 或共享内存。

【我的倾向与理由】 我站"分层 + 默认开 + 给豁免流程"，核心逻辑是：

• "默认关"的安全配置等于没有。我见过太多团队，mTLS 配置项写在那里，默认 false，三年没人改过——这不是"按需"，这是"没人管"。
• 但"默认全开"没有豁免通道，业务方就会走"找运维改配置"的灰色路径，反而绕过了审计和变更管控，安全上更危险。
• 关键是：豁免必须留痕、必须有时效、必须可回收。像"限时通行证"一样——不是不让你过，但过期自动失效，想续期得重新走审批。

一句话：默认安全是底线，豁免是例外，例外必须可追溯、可过期、可回收。

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

1. 你们的团队里，"安全加固"和"性能优化"的吵架一般怎么收场？是安全让步、性能让步、还是各退一步？谁有最终拍板权？
2. 有没有"安全配置默认开了，被业务方以 P99 为由要求关掉"的真实案例？最后怎么处理的？是关了、还是找到了折中方案？
3. 热榜上有个 HMAC 密钥轮换宽限窗口的提问（id=2266），你们线上一般给旧密钥留多大宽限？7 天？24h？还是"立即失效 + 灰度发布"？宽限窗口越长，旧密钥仍可验签的重放暴露面就越大，你们怎么权衡？
4. 内网服务间，你们强制 mTLS 吗？如果强制，握手开销怎么消化？连接池长连接复用 + TLS session resumption 是不是标配？有没有人算过"全量 mTLS"在千级服务规模下的实际 CPU 开销？
5. 你们的安全基线检查（CIS / 自建 checklist）和性能 SLO 有没有"仲裁机制"？比如安全基线要求 X，但 SLO 不允许 X，最终谁赢？

欢迎拍砖，也欢迎贴你们的"安全 vs 性能"仲裁案例——尤其是那种最后"各打五十大板"的，最有参考价值。