💡
原文英文，约600词，阅读约需2分钟。
📝
内容提要
GitHub工程师发现用户报告的“请求过多”错误是由于过时的滥用防范规则导致的，这些规则在事件后仍然生效，导致正常请求被误判。GitHub计划改进防御控制的生命周期管理，以提高可见性和适应性，确保防护措施与实际威胁相符。
🎯
关键要点
- GitHub工程师发现用户报告的“请求过多”错误是由于过时的滥用防范规则导致的。
- 这些规则在事件后仍然生效，导致正常请求被误判。
- 受影响的用户并未产生高流量，而是进行了少量正常请求。
- 调查发现，旧的事件规则基于与滥用相关的流量模式，但后来开始匹配一些合法请求。
- GitHub指出，复合信号有时会产生误报。
- 在匹配可疑指纹的请求中，只有一小部分被阻止，误报占总流量的极小部分。
- 用户影响被认为不可接受，强调了应急控制在事件后可能失效的问题。
- 分层防御使得在出现问题时追踪责任变得更加困难。
- GitHub计划通过比较当前规则与创建时的目的来解决问题，移除不再有效的规则。
- 长期来看，GitHub将投资于防御控制的生命周期管理，以提高跨层可见性。
- 其他大型平台也采用类似的“深度防御”请求管道，显示出防御控制的分层。
- 分层防御提高了系统的弹性和灵活性，但也增加了保护措施过时的风险。
- GitHub的经验表明，深度防御的长期有效性取决于控制措施的意图、影响和生命周期的理解。
❓
延伸问答
GitHub为何会出现“请求过多”的错误？
这是由于过时的滥用防范规则仍然生效，导致正常请求被误判。
GitHub如何计划改进其防御控制？
GitHub计划通过比较当前规则与创建时的目的，移除不再有效的规则，并投资于防御控制的生命周期管理。
分层防御的优势和风险是什么？
分层防御提高了系统的弹性和灵活性，但也增加了保护措施过时的风险。
GitHub的误报率是多少？
误报占总流量的极小部分，大约是每10万次请求中只有几次。
GitHub在处理滥用防范时遇到了什么挑战？
挑战在于每层防御都可以合法地限制或阻止请求，追踪责任变得更加困难。
GitHub如何确保防御措施与实际威胁相符？
通过定期审查和更新防御规则，确保它们与当前的威胁模式相匹配。
➡️
