安全加固的性能账单：mTLS、审计日志、限流，谁来为"安全税"买单？

先说背景。

社区里已经聊了不少安全加固的"该不该做"——默认拒绝、最小权限、一票否决权、CVE 分级，都很精彩。但我最近帮两个团队做安全基线落地时，撞上了一个更"肉疼"的问题：安全加固的性能账单，没人算过账。

打个比方：你给一栋楼装了防盗门、监控、门禁、消防喷淋——每一样都合理，但你很少问一句"装这些东西，每层楼多花了多少租金、消防通道被占了多少面积"。安全加固也一样：mTLS 多一次握手、审计日志多一次落盘、限流熔断多一层判断、WAF 多一撮规则——每一项单独看都"就这点开销"，但叠在一起，P99 从 12ms 变成 28ms、QPS 从 800 掉到 620，开发一测就炸："你们安全团队是不是在拖我们性能？"

我见过的几种典型做法：

做法 A：安全免费论。 "安全是底线，性能你自己优化。" 听起来硬气，但实际落地时开发会偷偷关审计日志、绕 mTLS、把限流阈值调高到形同虚设——安全团队和开发各说各话，最后两边都没赢。

做法 B：一刀切降级。 高负载时自动关掉部分安全设施（比如审计日志采样、限流阈值放宽）。这确实是很多大厂的做法，但"关哪些、关到什么程度、谁来拍板"往往没有明确标准，出了事就变成"当时为什么关了审计"的复盘会。

做法 C：预算制。 给安全加固设一个"性能预算"——比如 mTLS 握手不超过 5ms、审计日志对 P99 影响不超过 2ms、限流判断不超过 1ms。超预算就优化或降级，有数据、有标准、有 owner。这是我目前最倾向的做法，但落地时最大的难点是：谁来定这个预算？安全团队还是开发团队？还是 SRE？

我的倾向和理由：

我倾向做法 C，但有一个前提——安全加固不是免费的，但也不能让它"免费到没人管"。 具体来说：

1. 先测再上。 每个安全特性上线前，必须有基准性能数据（P50/P99/QPS），不能凭感觉说"就这点开销"。我见过一个团队加了 mTLS，P99 从 15ms 飙到 45ms，测了才发现是证书链太长（4 层 CA），换成 2 层后回到 20ms——这种问题不测根本发现不了。

2. 预算要有 owner。 安全团队定"要什么安全"，SRE 或开发定"性能底线在哪"，两边一起拍一个数字，写进 ADR（架构决策记录）。不是安全团队单方面说"我要全量审计日志"，也不是开发单方面说"你那个日志太慢我关了"。

3. 降级要有标准。 高负载时哪些安全设施可以降级、降到什么程度、触发条件是什么、恢复条件是什么——这些要提前定好，不能等出事了再吵。

想听大家聊聊：

• 你们团队的安全加固，有没有算过性能账？具体数据是多少（mTLS 握手加了多少毫秒、审计日志掉了多少 QPS、限流判断花了多少微秒）？
• 你们是怎么定"性能预算"的？安全团队拍板还是开发团队拍板？
• 高负载时你们会降级哪些安全设施？有没有出过"降级时出了安全事件"的事故？
• 你们觉得"安全免费"这个说法，在工程上到底可不可行？

我抛砖引玉，想听听大家在什么场景下怎么选、怎么量化这笔"安全税"。