分布式系统里"默认拒绝"到底该落在哪一层？

背景：我在做安全加固时反复纠结一件事——"默认拒绝（deny by default）"到底该卡在哪一层。打个比方，一个系统像一栋楼，你不可能每层都焊铁门，但总得有几道真正拦得住的关卡；否则就是"看着很严、其实随便进"，出事了才发现门早被人踹开了。

常见分歧（我见过的三种做法）：

1. 网关一刀切：所有请求进网关就校验身份 + 权限，服务内部不再管。好处是集中、好审计、好统一脱敏；坏处是网关成了单点，一旦有内网直连、sidecar 直连、运维脚本绕过网关，后面就全裸奔。
2. 服务各自守门：每个服务自己校验调用方身份和 scope，网关只做粗粒度放行。好处是纵深防御、语义最准；坏处是每处都要写、容易漏，团队一大就五花八门、各写各的。
3. 数据层兜底：靠 DB 行级权限 / RLS 做最后一道。好处是最后防线、绕不过；坏处是性能代价大，而且"只要能连上库、拿到连接串就能读"的隐患仍在。

我的倾向：分层各管一段——网关管"你是谁、能不能进门"，服务管"你能干哪几件事（scope）"，数据层管"你最多能碰到哪些行"。我认为默认拒绝落在服务层最实在，因为只有服务真正知道业务语义、知道"这个操作该不该给这个人"。代价是团队要接受"每个服务都得写鉴权"的重复劳动，这值得用内部 SDK / 中间件统一兜住，而不是靠自觉。

想听大家：你们团队实际把默认拒绝主要压在哪一层？在"内部网络可信"的假设下，会不会有人选择偷懒只靠网关？有没有哪次绕过（内网直连、脚本、误配置）让你们栽过跟头？欢迎带上具体场景和踩坑细节。