GitHub的工程师们最近调查了用户报告中的那些异常“请求过多”的问题，发现这些错误其实是由于一些滥用防范规则在引发这些问题的事件发生后仍然处于激活状态所导致的。
根据GitHub的说法，受影响的用户并没有产生大量的网络流量；他们只是“进行了一些正常的请求”，但这些请求仍然触发了这些防范规则。调查发现，那些较旧的规则是基于当时与滥用行为密切相关的流量模式制定的，但后来它们也开始将一些合法的正常请求也识别为异常请求。GitHub将这些检测机制描述为“结合了行业标准的手势识别技术以及平台特定的业务逻辑”，并指出“这种综合判断方式有时也会产生误报。”
GitHub还具体分析了这些多层防御机制在实际运行中的效果。在那些被识别为可疑请求的案例中，只有其中的一小部分被真正阻止了。具体来说，那些同时触发了业务逻辑规则的请求才会被阻止，因此大约有0.5%到0.9%的被识别为可疑的请求实际上被阻断了；而误报的比例则非常低，占总流量的比例仅为十万分之一左右。尽管如此，GitHub仍然认为这种对用户造成的影响是不可接受的，并通过这一事件指出了一个更普遍的问题：在紧急情况下实施的防控措施在事件发生期间可能是正确的，但随着威胁形势的变化以及合法使用方式的改变，这些措施往往会变得不再适用。
从GitHub的说明中可以得出一个关键结论：当出现问题时，多层防御机制反而会使得问题的根源难以被准确判断。GitHub表示，他们通过追踪跨越多个基础设施层的请求信息，来确定哪些地方实施了阻断操作，并指出了实际操作中遇到的困难：每一层防护机制都有权对请求进行速率限制或直接阻止它们，而要确定到底是哪一层做出了这样的决定，就需要将来自不同系统的日志数据进行关联分析，而这些日志的数据结构往往各不相同。
来源：GitHub
为了解决这一紧急问题，GitHub重新审查了现有的防范措施，比较了当前这些规则实际阻止了哪些请求，以及它们最初被设计出来时应该阻止哪些请求，从而去除了那些已经不再具有作用的规则，同时保留了对现有威胁的有效防护。从长远来看，GitHub表示将会投入精力来完善对这些防御机制的生命周期管理：提高跨层监控的能力，以便能够准确追踪速率限制和阻断操作的来源；默认将这些临时性的防范措施视为暂时性的解决方案；并在事件发生后采取相应的措施，将这些紧急防控措施逐步发展成可持续、有针对性的长期解决方案。
来源：GitHub
虽然GitHub的文章主要讨论了规则生命周期以及各层之间的可观测性，但其他处理互联网流量的大型平台也采用了类似的“深度防御”请求处理机制。例如，Vercel详细描述了其请求处理流程：请求在经过网络层（L3）、传输层（L4）和应用层（L7）的防火墙保护后，还会根据项目级策略进入WAF防护阶段；同时，这些系统也实现了各层之间的反馈机制——如果某个WAF规则触发了某种持久性操作，上游环节就可以更早地拦截后续请求。
这种分层设计不仅体现在边缘流量管理中。Kubernetes的API服务器安全模型同样采用了分层架构：准入控制器会在身份验证和授权之后、数据持久化之前拦截请求，从而形成一条有序的处理链，在这条链上可以逐步添加更多的策略和安全检查机制。
综合这些例子可以看出，大型系统中普遍存在这样一个权衡：通过分层部署防御措施确实可以提高系统的弹性和灵活性，但同时也有可能导致某些防护机制在不再适用的环境中依然继续发挥作用。GitHub的经验表明，深度防御措施的长期有效性不仅取决于这些措施的具体部署位置，还取决于人们能否随着系统和技术环境的变化，清楚地理解这些措施的作用目的、影响范围以及使用寿命。
