企业与 SaaS 网络的 DDoS 防护

确定哪种资源正在变得不可用

网络饱和与高成本请求不同

链路被打满时，流量可能尚未到达应用就无法访问。高成本的已认证请求，则可能在链路未满时耗尽后端资源。同一张带宽图不能诊断这两类问题。

源站可能位于多个交付层之后

CDN、应用代理、防火墙和源站可能观察到不同流量。更改防护前，应梳理公共域名、暴露地址及回程，包括主网站以外的端点。

地址可能属于其他服务商

托管或云服务商分配的地址，不会自动允许通过新的 BGP 服务转移。评估地址归属及提供商的路由或隧道限制；设计必须符合各运营方允许的范围。

让网络防护与应用控制相互补充

受保护的 Transit IP 或兼容的本地过滤部署可以处理网络层。HTTP 授权、请求预算和应用专属控制，仍应由适当的应用或安全组件负责；这里不意味着提供通用 WAF 服务。

1. 1

   梳理暴露的服务

   确定公网端点、托管责任、所需协议，以及必须保持可用的应用操作。

2. 2

   验证受保护网络路径

   评估交付选项、允许的路由、MTU，以及所选过滤模式所需的流量可见性。

3. 3

   保留应用保护措施

   保持源站访问策略、认证、请求限制和后端监测与应用一致。

以下为部署顺序示例。实际交付服务以报价和验收记录为准。

选择团队能够运营的责任边界

您能更改路由，还是只能更改应用端点？

答案决定是否可以考虑 Transit、兼容的隧道方案或其他交付层。选择架构前，先确认服务商限制。

这项服务的可用性如何定义？

以成功完成的业务操作为依据，而不只是端口开放。记录预期响应、超时和依赖行为，让网络与应用团队比较同一事件。

网络仍可达时由谁调查？

提供同一时间段的应用错误、资源使用和网络计数。路由正常并不证明认证、数据库或外部依赖正在工作。

验证完整用户操作

• 修改交付路径前，记录正常应用成功情况与依赖行为。
• 通过拟议网络层验证所需协议、双向流量及有代表性的较大数据交换。
• 在托管、网络与应用团队之间约定回退和事件责任，并保留现有应用控制。

此部署的常见问题