出网白名单该「网关统一收口」还是「业务自管」：一次 DLP 绕过事故后，我们卡在了这道题上

【背景】 我做了 8 年安全加固，最近复盘了一起内部 DLP 绕过事件：某业务同学的导出服务在代码里硬编码了一个海外对象存储 endpoint，把脱敏不彻底的明细数据传了出去。事后排查发现，公司出口网关的「出网白名单」是业务团队自己在工单里申请、自己填、自己审批的——安全团队只在事后审计。类似的口子（第三方 SDK 直连、脚本里 curl 外发、内网服务互访）我们盘出来不下 20 个。

【常见分歧 / 几种做法】

1. 网关统一收口：所有出网流量必须走安全网关，白名单由安全团队集中维护，业务想加就提需求。优点是攻击面收敛、审计闭环；缺点是审批链路长，业务嫌慢，紧急需求容易走「先开后补」的灰色通道。
2. 业务自管 + 安全抽查：白名单由业务申请、安全只做事后审计和季度抽查。优点是快；缺点是我们这次事故证明了——出事时才知道有哪些口子。
3. 分级混合：按数据等级/出口目标分档，高敏感走统一收口，低敏感走业务自管。听起来两全，但「分级标准」本身又成了新的扯皮点。

【我的倾向与理由】 我倾向 3，但加两条硬约束：

• 白名单必须「有生命周期」：每条规则带有效期（比如 90 天）和调用方身份绑定（哪个服务、哪个密钥），过期自动失效，续期走原流程。没有 TTL 的白名单等于不存在。
• 先有盘点、再有收口：用 eBPF / 流量探针在现有出口上跑 2 周，把「实际出网目标清单」摸出来，再谈哪档该收、哪档可以放。没有这份底账，分级就是拍脑袋。 理由：收口的本质不是「谁来审批」，而是「攻击面有没有一个唯一 owner + 一份实时清单」。把这两点做扎实，审批放不放给业务，只是效率问题。

【想听大家怎么选】

• 你们的出网管控目前是哪一档？有没有出过「白名单里躺着没人认领的旧规则」这种问题？
• TTL + 自动失效在你们环境里推得动吗？业务侧最大的阻力是什么（性能、审批时长、还是影子出口根本绕不过网关）？
• 有没有人做过「出口流量全量盘点」？用的什么手段，2 周够不够？