CDN安全能力能不能量化？先看懂这8个检查项

一家CDN宣称能够防御DDoS攻击，另一家强调拥有WAF、Bot管理和全球安全节点。把两份产品资料放在一起，很容易陷入一个困境：功能名称看起来差不多，却很难判断谁的安全能力更强。

CDN安全能力可以量化，但不能压缩成一个脱离业务场景的绝对分数。

TLS版本、安全响应头和证书链等配置，可以通过公开网络直接检测；DDoS清洗容量、WAF实际拦截效果、规则误报率和应急响应速度，则需要厂商规格、合同条款、日志记录以及授权POC共同验证。把“厂商声明”直接当成“实测结果”，最终得到的安全评分通常没有决策价值。

真正有用的量化方法，是把CDN安全拆成八个检查项，分别记录可验证指标、证据来源和不能接受的底线。

先分清三类数据：可实测、可验证和仅声明

评估CDN安全时，所有数据不应该放在同一张表里直接相加。更稳妥的做法是先给证据分类。

CDNChart目前在安全评分中，将TLS 1.3、弱加密套件、证书链完整性、HSTS、CSP、X-Content-Type-Options、HTTP/3和OCSP Stapling等作为可实测项；WAF和DDoS防护等级等厂商公开能力则单独展示，不直接混入实测分数。CDN测试方法与评分标准中说明了这一区分。

这样的边界很重要：检测到网站支持TLS 1.3，不等于已经证明它可以抵御大规模DDoS；厂商宣称支持WAF，也不等于你的业务已经启用正确规则。

检查项一：DDoS防护到底覆盖哪一层

“支持DDoS防护”本身无法量化，因为DDoS包含完全不同的攻击方式。

网络层和传输层攻击可能消耗带宽、连接表或网络设备资源，例如UDP Flood和SYN Flood；HTTP Flood、CC攻击则表现为大量看似正常的网页或接口请求，重点消耗应用服务器、数据库和业务资源。

评估时至少要记录：

• 是否覆盖L3、L4和L7攻击；

• 支持保护HTTP、HTTPS、TCP、UDP中的哪些协议；

• 防护是始终启用，还是攻击后切换到清洗中心；

• IPv4和IPv6是否都在保护范围内；

• WebSocket、QUIC及非标准端口是否支持；

• 攻击超过规格后是限速、黑洞、弹性扩容还是尽力防护；

• 防护失败或长时间不可用是否进入SLA。

NIST的DDoS与互联网路由安全指南指出，DDoS缓解并不是单一技术，还可能涉及源地址验证、访问控制、流量过滤、FlowSpec和响应速率限制等机制。只用一个“防护峰值”无法描述完整防护体系。

量化这一项时，不妨将“明确写入合同的覆盖范围”与“产品页面提到的能力”分开计分。前者可以进入采购评分，后者只能作为待验证项。

检查项二：防护容量、业务容量和超限策略

看到“1Tbps防护”时，真正需要追问的是：这个数字属于全网资源池、单个清洗中心，还是单个客户可以获得的承诺能力？

至少要拆开以下指标：

这几项不能相互替代。一家CDN可能拥有很大的清洗资源池，但客户购买的正常业务带宽很小，攻击流量被清洗后，真实用户仍然可能因为限速而访问失败。

需要高防能力的网站，可以把这些容量边界与高防CDN的节点和测试范围放在同一张选型表中，避免只比较厂商首页上的峰值数字。

检查项三：WAF能拦什么，误报能不能控制

WAF不是一个“开启即安全”的开关。

真正能够量化的不是产品有没有WAF，而是规则覆盖、配置粒度、误报控制和更新能力。例如：

• 是否有托管规则，并说明规则的更新机制；

• 是否支持SQL注入、XSS、路径遍历、恶意文件上传等常见攻击类别；

• 能否按照域名、URL、请求方法、Header、Cookie和请求体配置规则；

• 是否支持观察、记录、拦截、挑战和限速等不同动作；

• 能否为登录、支付回调、搜索和API设置独立策略；

• 规则命中后能否看到匹配字段、规则编号和处置结果；

• 从发现误报到调整规则需要多长时间；

• 自定义规则数量和表达式复杂度是否有限制。

OWASP Core Rule Set是一套用于ModSecurity及兼容WAF的通用攻击检测规则，覆盖多类常见Web攻击。但通用规则集只是起点，真实业务仍然需要根据接口、参数和风险调整策略。

NIST的API保护指南也指出，WAF可以检查HTTP请求的元数据和内容，却不能替代API自身的身份认证、授权和业务字段验证。换句话说，WAF是重要的第一道防线，但不是完整的应用安全方案。

量化WAF时，可以记录测试请求数量、正确拦截数量和误拦截数量，但不要在未获授权的生产网站上发送漏洞利用载荷。正式验证应在测试环境或厂商同意的POC范围内进行。

检查项四：CC、Bot与API滥用能否按业务识别

CDN能够阻断明显异常的请求频率，不等于能够识别复杂的自动化滥用。

恶意Bot可能保持较低请求速率，模拟正常浏览器，轮换IP和账号，攻击目标也不一定是网站可用性，还可能是撞库、刷券、抢购、内容采集或批量注册。

需要量化的内容包括：

• 能否按IP、会话、账号、设备和API令牌限速；

• 限速周期能否按秒、分钟或滑动窗口配置；

• 是否区分搜索引擎、合作伙伴接口和普通自动化工具；

• 支持阻断、JavaScript挑战、验证码、记录和放行中的哪些动作；

• 是否能为不同API路径设置独立阈值；

• 是否支持请求体大小、并发数和单次处理时间限制；

• 规则命中日志是否包含请求路径、客户端特征和处置动作；

• 正常用户通过率和误挑战率能否统计。

Bot防护不能只看“识别率”宣传值。如果厂商没有公开测试数据、测试集和计算口径，这个比例很难直接横向比较。对采购方更实用的指标，是自己核心业务路径上的误拦截率、挑战通过率以及规则调整时间。

检查项五：源站能不能被绕过

CDN在边缘挡住了攻击，但源站IP仍然可以直接访问，攻击者就可能绕过全部边缘防护。

源站保护可以转化为一组明确的检查结果：

• 当前DNS记录是否直接暴露源站IP；

• 历史子域名、测试域名和旧解析是否仍指向源站；

• 源站是否只允许CDN回源地址访问；

• 回源IP列表是否有可靠的更新机制；

• 是否支持回源鉴权Header、双向TLS或其他来源认证；

• 源站直接使用IP访问时是否还能返回真实业务；

• 管理端口、数据库和监控服务是否暴露在公网；

• 源站日志中的请求来源是否符合预期。

可以先利用公开DNS、CNAME、响应IP和HTTP特征识别当前访问链路，但外部检测无法证明源站已经完全隐藏。CDN检测未识别的原因也说明，CNAME扁平化、白标CDN、隐藏响应头和多CDN调度都会影响外部判断。

因此，这一项必须结合云安全组、主机防火墙、历史DNS资产和源站日志检查。CDN识别结果只能帮助寻找线索，不能替代站点所有者的内部验证。

检查项六：TLS和HTTP安全基线是否达标

这部分是CDN安全能力中最容易进行公开量化的一类。

建议检查：

• 是否支持TLS 1.3；

• 是否仍允许过时协议或弱加密套件；

• 证书链是否完整；

• 证书域名、签发机构和有效期是否正常；

• 是否启用HSTS；

• 是否配置Content-Security-Policy；

• 是否设置X-Content-Type-Options；

• OCSP Stapling是否可用；

• HTTP跳转到HTTPS是否存在异常；

• IPv4与IPv6是否使用一致的安全配置。

不过，检测结果反映的是“这个域名当前对外提供的配置”，不一定代表厂商默认配置，更不代表该厂商所有客户都采用相同策略。

例如，没有启用HSTS，可能是CDN不支持，也可能只是网站管理员没有打开；出现证书链错误，则可能来自客户上传证书不完整，而不是CDN平台本身存在缺陷。做厂商对比时应区分“产品能否支持”和“被测网站是否正确配置”。

检查项七：日志、告警和安全事件能否解释

无法解释的防护，很难持续改进。

安全事件发生后，控制台至少应该能够回答：

• 攻击何时开始、何时结束；

• 攻击类型和目标是什么；

• 峰值带宽、请求速率和持续时间是多少；

• 哪些节点、域名和URL受到影响；

• 哪条规则触发了什么动作；

• 正常请求是否被误拦；

• 源站带宽、连接数和错误率有没有异常；

• 是否支持原始日志、报表或API导出。

可以进一步量化：

“攻击已被防护”只是一条状态。如果看不到攻击类型、规则动作和业务影响，企业很难验证服务是否符合合同，也无法为下一次事件调整策略。

检查项八：控制台权限和整体运维韧性

不少CDN安全事故并不是防护容量不够，而是配置被误改、账号被盗、规则上线失败或者故障切换没有生效。

因此还要检查：

• 控制台是否支持多因素认证；

• 是否提供角色权限和最小权限控制；

• 是否记录登录、配置修改和API调用审计日志；

• API密钥能否限制权限、来源和有效期；

• 安全规则能否灰度发布、快速回滚；

• 配置变更需要多长时间同步到全部节点；

• 单个区域故障时是否支持自动切换；

• 故障切换后TLS、WAF、缓存和源站鉴权是否继续有效；

• 是否有7×24小时紧急联系渠道；

• 厂商自身发生安全事件时如何通知客户。

这一项很难通过公开扫描完成，却可能直接影响实际风险。采购前可以要求厂商演示账号权限、配置审核、回滚流程和日志导出，再把关键响应时间写入POC记录或合同附件。

怎样把8个检查项变成可用的评分表？

安全评分最好分两步进行。

第一步是设置硬性淘汰项。例如：

• 不支持业务必需的协议；

• 源站无法限制回源来源；

• 不支持多因素认证或操作审计；

• 超过防护规格后的处置方式不明确；

• WAF不能为关键API设置独立规则；

• 安全日志无法导出；

• 厂商拒绝书面确认SLA和计费边界。

硬性条件不满足时，不应该用其他项目的高分抵消。

第二步才是加权评分。每一项可以使用0—5分：

不同业务应设置不同权重。内容网站可以提高DDoS、源站保护和可用性的权重；电商与金融业务通常更重视WAF、Bot、API保护、误报控制和审计日志；下载与视频业务还需要提高正常业务带宽和攻击期间吞吐能力的权重。

CDNChart的CDN厂商对比可以用于观察公开性能、覆盖和可实测安全信息，帮助缩小候选范围。但公开比较不能替代企业真实业务POC，更不能代替合同审查、授权安全测试和价格谈判。

常见问题

CDN安全能力真的可以用一个分数表示吗？

可以建立综合评分，但这个分数只对明确的业务需求和权重有效。脱离用户地区、业务类型、风险和预算的“安全总分”，不适合直接决定采购结果。

CDN支持WAF，是不是就能防住所有Web攻击？

不是。WAF主要根据HTTP请求特征和规则识别风险，无法替代应用自身的身份认证、权限校验、安全编码和漏洞修复。规则过松可能漏报，规则过严也会误伤正常用户。

DDoS防护峰值越大越好吗？

峰值只是一个指标。还要确认它是全网容量、单节点容量还是单客户承诺，并检查业务带宽、QPS、超限处置、弹性费用和攻击期间的用户可用性。

不进行攻击测试，能评估CDN防护能力吗？

可以完成初筛和大部分边界核验，包括检查规格、合同、SLA、节点路径、源站保护、WAF配置、日志和厂商历史事件。最终验证应在供应商授权和明确测试范围下进行，不能擅自对生产系统发起压力攻击。

CDN检测工具能直接判断一家厂商安不安全吗？

不能。CDN检测主要用于识别CNAME、响应IP、HTTP特征和可能的服务商。它能帮助确认流量路径和发现公开配置问题，但无法直接验证清洗容量、WAF效果、Bot模型或应急响应能力。

TLS 1.3、HSTS和CSP都正常，能说明CDN安全能力很强吗？

只能说明被测域名的部分传输与HTTP安全配置较完整。它不能证明DDoS、WAF、Bot防护和源站保护同样可靠。

WAF误报率应该怎样计算？

可以在测试环境或规则观察模式下，用真实业务请求集统计被错误识别为攻击的正常请求比例。还要按登录、支付、API、上传和搜索引擎等关键路径分别观察，不能只计算全站平均值。

CDN安全评分需要多久更新一次？

公开配置项可以持续或定期检测；WAF规则、权限、日志和SLA至少应在重大变更、续约和业务上线前重新检查。发生攻击、安全事件或厂商架构调整后，也应重新验证原有结论。