Google Cloud DDoS 防护应该怎么做，企业网站需要关注哪些网络安全问题

企业网站部署到 Google Cloud 以后，很多人第一反应是给服务器安装防火墙、增加几条 IP 黑名单，然后认为 DDoS 防护基本完成。实际情况远比这复杂。现代网站面对的攻击并不只有传统意义上的大流量 DDoS，还包括 HTTP Flood、漏洞扫描、账号撞库、恶意爬虫、SQL 注入、跨站脚本、文件上传攻击、API 滥用以及利用应用程序高成本接口消耗 CPU、数据库连接和后端资源的低速攻击。

因此，Google Cloud 上的网站安全不能依靠一个产品解决，而应该按照流量入口、负载均衡、WAF、应用程序、身份认证、数据库和运维监控等层次建立防护体系。其中 Google Cloud 的 Cloud Armor 主要承担边缘流量防护和 Web 应用安全控制，而不是传统意义上的服务器主机防火墙。

先理解 Google Cloud 的 DDoS 防护边界

对于部署在 Google Cloud 负载均衡架构中的网站，DDoS 防护首先应该尽可能在靠近 Google 网络边缘的位置处理，而不是等攻击流量全部进入自己的 VM 后再进行过滤。

Google Cloud 的全球负载均衡可以把用户请求接入 Google 的全球网络，再根据负载均衡配置将流量发送到后端服务。Cloud Armor 则可以在这个架构中提供安全策略、WAF、访问控制和部分基于请求频率的限制。

这和“服务器收到攻击以后自己过滤”完全是两个概念。

如果企业网站把公网 IP 直接暴露给一台 VM，然后让攻击流量全部打到这台机器，再依靠操作系统防火墙处理，服务器的 CPU、网络接口、连接表以及上游带宽都可能在应用层防火墙开始发挥作用之前承受压力。

所以第一原则不是不断增加服务器防火墙规则，而是尽可能把公网入口放在 Google Cloud 的负载均衡和边缘安全架构后面。

Cloud Armor 也不应该被理解成一个万能的 DDoS 开关。Google Cloud 本身拥有基础设施级的 DDoS 防御能力，而 Cloud Armor 更适合承担可配置的应用层安全策略、WAF、访问控制和流量限制等任务。企业需要根据具体的负载均衡类型、后端架构和 Cloud Armor 配置确认哪些保护能力适用于自己的部署。

不要自己实现 SYN Flood 的“三次握手防护”

原稿中提到企业需要在负载均衡器部署状态检测防火墙，通过 TCP 三次握手验证来防御 SYN Flood，这种描述容易把云平台基础设施能力和企业应用配置混在一起。

对于使用 Google Cloud 托管网络和负载均衡服务的企业，通常不需要自己在 Web 应用代码中实现 TCP 三次握手检测。TCP 连接建立属于网络协议栈和基础设施层面的工作。

企业真正应该配置和管理的是允许哪些流量进入应用、哪些请求需要被拒绝、哪些来源需要限制，以及哪些业务接口需要设置请求频率和并发控制。

也就是说，企业网站安全的重点应该从“自己造一个 DDoS 清洗器”转向“正确利用云平台提供的边缘防护能力，并保护自己的应用资源”。

Cloud Armor 最有价值的地方在哪里

Cloud Armor 可以通过 Security Policy 对进入受保护服务的请求进行规则匹配。企业可以根据 IP、地理位置、HTTP 请求属性以及表达式等条件制定允许、拒绝或者其他处理策略。

WAF 则适合处理典型的 Web 攻击，例如 SQL Injection、跨站脚本以及其他常见的恶意请求模式。Google 提供预配置的 WAF 规则，可以减少企业从零开始编写大量检测规则的工作量。

但 WAF 并不是“开了以后什么攻击都能挡”。

例如，一个攻击者发送完全合法的 HTTPS 请求，每次请求都访问网站的搜索接口，而搜索接口内部需要查询大量数据库记录。对于 WAF 来说，这些请求可能完全符合 HTTP 协议，也没有明显的 SQL Injection 特征，但攻击者仍然可以通过大量请求消耗数据库和应用服务器资源。

这就是应用层 DDoS 与传统网络层攻击之间的重要区别。

Rate Limiting 不能等同于 DDoS 防护

Cloud Armor 的 Rate Limiting 对保护登录、搜索、API、评论、内容生成以及其他高成本接口非常有价值，但它不应该被描述成完整的 DDoS 清洗服务。

例如企业可以针对某类请求设置频率限制。当某个来源在一定时间内产生异常数量的请求时，可以对超出限制的请求进行处理。

不过简单按照 IP 限制并不总是可靠。

现代互联网用户大量使用 NAT、移动网络、企业代理和 VPN。一个公网 IP 可能对应大量正常用户；另一方面，攻击者也可以使用代理网络、云主机和大量不同地址发动攻击。

因此对于登录系统，企业可以同时考虑账号、来源地址、设备或请求风险信号以及接口本身的访问模式，而不是简单设置“一个 IP 每分钟最多 100 次”。

对于 API，还应该结合 API Key、用户身份、租户、接口类型和业务成本进行限制。

例如一个读取静态配置的 API 和一个执行复杂数据库搜索的 API，其资源消耗完全不同，就没有理由使用完全相同的限制策略。

WAF 规则越多并不意味着越安全

这是企业非常容易犯的错误。

安全团队有时会不断增加黑名单、User-Agent 规则、Referer 规则、IP 规则和各种正则表达式，最后形成一套非常庞大的规则集合。

问题是攻击者不会一直使用同一个 IP，也不会老老实实使用一个明显的恶意 User-Agent。

更麻烦的是，一些企业代理、移动网络、搜索引擎、API 客户端和自动化业务本身就可能具有与攻击流量相似的特征。

因此安全策略应该尽可能建立在明确的业务逻辑上，而不是看到一种异常请求就永久增加一条规则。

WAF 规则需要结合日志观察误报情况。对于核心业务，可以先以观察和记录为主，再逐步转换为阻断策略，避免新规则上线以后把正常客户一起挡掉。

CDN 可以减轻源站压力，但不能替代 WAF

Cloud CDN 对静态资源和适合缓存的内容非常有价值。

图片、CSS、JavaScript、字体以及其他可缓存资源如果能够在边缘节点直接返回，就不需要每次请求都访问源站。

这可以减少源站网络流量和计算压力，也可以改善全球用户的访问速度。

但 CDN 并不会自动解决所有动态请求问题。

登录、购物车、用户账户、后台管理、数据库查询以及高度个性化的页面通常无法像静态文件一样简单缓存。

攻击者如果直接针对这些动态接口发送请求，仍然可能让应用服务器和数据库承担大量工作。

所以企业应该分别考虑静态资源缓存和动态接口保护，而不是认为“开启 CDN 后网站就不怕 DDoS”。

最容易被忽略的是应用层资源消耗

现代网站面对的一种危险攻击，不一定具有惊人的带宽。

假设一个网站拥有一个搜索接口，每次搜索都会执行多个数据库查询，还需要排序、分页和全文匹配。

攻击者只需要持续请求这个接口，就可能让数据库连接池、CPU、磁盘 I/O 和缓存系统持续处于高负载。

如果接口每秒只能处理几十个复杂请求，那么攻击者甚至不需要制造几百 Gbps 的网络流量。

因此企业应该找出网站内部最昂贵的 HTTP 请求。

登录、搜索、注册、密码重置、文件上传、报表生成、全文检索、图片处理、AI 推理和后台管理接口，都应该重点检查。

对于这些接口，可以结合 Rate Limiting、应用层并发限制、任务队列、缓存、数据库索引以及超时机制降低攻击造成的资源消耗。

身份认证本身也是网络安全的一部分

很多网站把 DDoS 防护和账号安全完全分开，实际上两者经常会同时发生。

攻击者可能先进行大量密码尝试，然后使用撞库得到的账号访问网站。

因此企业网站至少应该考虑 MFA、多因素认证、登录失败限制、密码重置保护、会话管理、异常登录检测以及权限控制。

尤其是管理员后台。

如果一个网站的 WordPress、CMS、数据库管理工具、SSH、云控制台或者内部 API 直接暴露在公网，即使 DDoS 防护做得很好，攻击者仍然可能通过有效账号进入系统。

DDoS 防护解决的是“流量是否能够到达服务”的问题，而身份认证解决的是“这个人有没有权限执行操作”的问题，两者不能相互替代。

Zero Trust 不是一句安全口号

企业采用 Zero Trust 架构时，也不能简单理解成“所有流量都必须通过 Cloud Armor”。

Zero Trust 更强调身份、设备、应用和资源之间的访问控制。

例如管理员访问数据库，不应该因为“已经进入公司 VPN”就获得整个数据库的权限。更合理的方式是根据身份、设备状态、应用和具体资源授予最小权限。

同样，Web 服务器访问数据库时，也不应该使用拥有整个数据库管理权限的账号。

网站应用只应该拥有完成业务所需要的数据库权限。

如果应用只需要读写几个业务表，就没有必要给它授予创建用户、修改权限或者访问其他敏感数据库的能力。

SQL Injection 不能靠 Cloud Armor 解决

WAF 可以帮助检测和阻断一部分 SQL Injection，但企业绝不能因此放弃应用程序自身的防护。

数据库访问应该使用参数化查询或者成熟 ORM 提供的安全查询机制，同时进行输入验证和权限控制。

对于 PHP、Java、Node.js、Python 等 Web 应用都是如此。

如果开发人员把用户输入直接拼接进 SQL 字符串，那么网站依赖 WAF 来阻挡 SQL Injection，就相当于把最后一道防线当成第一道防线。

同样，XSS 防护也不能只依赖 WAF。

应用程序应该进行正确的输出编码、模板转义，并根据业务需要配置 Content-Security-Policy 等安全响应头。

文件上传是企业网站的高风险入口

文件上传功能经常被低估。

如果网站允许用户上传图片、PDF、Office 文件甚至压缩包，就需要考虑文件类型验证、大小限制、文件名处理、存储位置、病毒扫描以及下载方式。

最危险的情况之一，是上传文件最终能够被 Web Server 当成可执行脚本处理。

因此用户上传目录通常应该与应用代码目录隔离，并禁止不必要的脚本执行能力。

文件上传接口也非常适合设置专门的请求大小限制和频率限制。

VPC 和数据库不能只靠公网隐藏

企业网站的数据库通常没有必要直接暴露公网。

更合理的架构是让 Web 后端通过 VPC 网络访问数据库，并利用防火墙规则、身份认证和数据库权限控制访问范围。

如果数据库管理端口可以从整个互联网访问，即使数据库使用了强密码，也会增加扫描、漏洞利用和暴力攻击的风险。

远程管理接口也应该采用最小暴露原则。

SSH、RDP、数据库管理端口以及内部管理 API，都应该根据实际业务限制来源范围，而不是简单地开放给 0.0.0.0/0。

日志和监控决定企业能不能发现攻击

安全防护如果没有日志，就很难判断到底发生了什么。

企业至少应该观察负载均衡日志、Cloud Armor 日志、应用日志、身份认证日志、数据库日志以及必要的 VPC 网络流量信息。

需要关注的不是单纯的“访问量增加了没有”，还包括请求来源分布、HTTP 状态码、URI 分布、请求延迟、后端错误率、数据库连接数、CPU、内存、网络吞吐量以及特定接口的请求频率。

例如网站整体流量只增加两倍，看起来并不严重，但如果其中 80% 的请求集中在一个数据库搜索接口，那么后端可能已经处于危险状态。

因此监控应该从“网站总流量”进一步深入到“哪个接口正在消耗资源”。

Security Command Center 的作用也需要准确理解

Google Cloud Security Command Center 可以作为企业云安全管理和发现能力的一部分，用于查看和管理安全发现、资产风险以及相关安全信息。

但不能把 SCC 描述成“自动把所有攻击特征同步到 Cloud Armor，然后自动更新所有防火墙规则”。

Cloud Armor 和 SCC 在企业安全架构中的职责不同。

Cloud Armor更偏向网络边缘和 Web 请求防护，SCC 更偏向云环境安全态势、发现和安全运营。

企业应该把这些工具产生的日志和安全发现纳入自己的监控和事件响应流程，而不是期待一个产品自动完成整个安全闭环。

DNS 和灾备不要混为一谈

遭遇 DDoS 时，企业有时会想到把 DNS 切换到备用服务。

但 DNS 切换并不是万能的 DDoS 应急方案。

如果攻击目标本身就是网站的域名和公网服务，那么仅仅改变 DNS 解析并不会自动解决应用层攻击，而且 DNS 缓存、TTL、客户端缓存以及其他因素都会影响切换速度。

更合理的做法是提前设计灾备架构，明确哪些组件需要冗余、哪些数据需要备份、故障转移需要多长时间，以及发生攻击时谁负责修改安全策略、谁负责联系云平台、谁负责判断是否需要限制业务功能。

企业真正应该建立的是分层防护

一个比较合理的 Google Cloud 网站安全架构，可以从几个层次理解。

最外层是 Google Cloud 网络和基础设施提供的 DDoS 防护能力。

接下来是全球负载均衡，把用户流量接入合适的后端服务。

Cloud Armor 负责 Security Policy、WAF、访问控制和适合业务的 Rate Limiting。

Cloud CDN 可以负责适合缓存的静态资源和内容。

后端应用继续承担身份认证、授权、输入验证、输出编码、CSRF 防护、Session 管理、业务级限流以及租户隔离。

数据库则负责参数化查询、最小权限、网络隔离、备份和恢复。

最后是日志、监控、告警、安全审计以及事件响应。

这样的架构有一个很重要的特点：任何一层失效，都不会意味着整个系统立即失去保护。

DDoS 防护解决的是流量洪峰和恶意请求问题，WAF 解决的是部分 Web 攻击，Rate Limiting 解决的是资源滥用，身份认证解决的是非法账户访问，应用安全解决的是代码和业务逻辑漏洞，数据库权限解决的是数据层面的越权，而日志和监控负责让企业知道系统究竟发生了什么。

企业网站安全最危险的误区，就是把某一个云安全产品当成整个安全体系。

对于 Google Cloud 网站，最值得投入精力的通常不是继续堆积几十条看起来很专业的防火墙规则，而是把公网入口、负载均衡、Cloud Armor、CDN、应用认证、API 限流、数据库权限、秘密管理、日志监控和灾备真正连接起来。

当攻击发生时，企业需要知道攻击流量从哪里进入、在哪一层被识别、哪些请求被拦截、哪些请求已经进入应用、哪个接口消耗了最多资源、数据库是否受到影响，以及如何在不误伤正常用户的情况下恢复业务。

做到这一点，网站面对的就不再只是一次单纯的 DDoS 防御，而是一套能够持续运行、监控、调整和恢复的云安全体系。