Google Cloud Cloud Armor 是什么，Web 应用如何防护异常流量

对于部署在Google Cloud上的网站和API服务来说，异常流量并不只有一种。突然增加的访问量可能来自正常用户，也可能来自爬虫、接口滥用、漏洞扫描、撞库、DDoS攻击或者专门针对某个API端点的自动化攻击。如果所有请求都直接进入Web服务器，应用本身就必须承担大量流量过滤、攻击识别和资源保护工作。

Google Cloud提供的Cloud Armor，本质上是一套与Google Cloud负载均衡体系结合的应用和网络流量防护服务。它可以利用安全策略对进入受保护后端的流量进行匹配和处理，并提供WAF规则、IP和地理位置控制、速率限制、Adaptive Protection等能力。对于部署在Google Cloud外部的服务器，Cloud Armor也不是一个可以随意放在任何网络路径上的通用代理，它的实际使用方式取决于具体的Google Cloud负载均衡和后端架构。

理解Cloud Armor，首先要把它和传统意义上的“服务器防火墙”区分开。

传统防火墙主要关注IP、端口、协议等网络层面的访问控制，而Web应用防火墙更关注HTTP请求本身。例如请求访问哪个URL、使用什么HTTP方法、请求头包含什么内容、查询参数是否存在异常模式，以及请求是否表现出明显的攻击特征。

Cloud Armor能够根据这些请求属性执行安全策略。例如可以允许或者拒绝特定IP地址、限制某些地区的访问、针对指定路径设置规则，也可以使用预配置的WAF规则检测常见Web攻击。

Cloud Armor最重要的组成部分之一就是Security Policy，也就是安全策略。

安全策略可以包含多个规则，每条规则针对特定条件匹配请求，然后执行允许、拒绝、重定向或者其他相应动作。规则可以根据IP地址、IP范围、地理位置、HTTP请求属性以及更复杂的表达式进行匹配。

这意味着企业可以针对不同业务建立不同的防护逻辑。

例如公开网站可以允许全球用户访问，但后台管理接口只允许企业办公网络或者指定IP范围访问。登录接口可以设置更加严格的速率限制，公开图片或者静态资源则可以采用不同策略。

这种策略化设计比单纯在Web服务器上写大量if判断更加适合云环境，因为请求在到达应用后端之前就可以经过前端防护层处理。

Cloud Armor的另一个核心能力是WAF。

Web应用攻击经常隐藏在正常的HTTP请求里面。一个HTTP请求本身可能完全符合协议规范，但参数内容可能包含SQL注入、跨站脚本或者其他恶意输入。

Cloud Armor提供预配置的WAF规则，可以针对常见攻击模式进行检测。这些规则与OWASP常见Web攻击类别相关，但不应该简单理解成“Cloud Armor就是OWASP CRS”。Google Cloud提供的是自己的预配置规则体系和相应规则管理机制，实际使用时需要根据具体规则版本、规则ID和敏感程度进行配置。

WAF最重要的工程问题并不是“规则越多越安全”，而是误报。

假设一个合法API允许用户提交一段SQL语句作为教学内容、允许HTML片段作为编辑内容，或者某个JSON字段中包含特殊字符，通用WAF规则可能把这些正常内容误认为攻击。

因此生产环境通常需要观察日志和命中情况，然后根据业务特征调整规则。对于确认存在误报的规则，可以采用更精细的匹配范围，而不是直接关闭整个WAF。

Cloud Armor还提供rate limiting，但它与传统意义上的DDoS防护不能混为一谈。

Rate limiting解决的问题主要是控制请求速率。例如一个登录API正常情况下每个客户端不会在短时间内发送数百次请求，那么可以针对该接口设置合理的速率控制。

当请求超过策略设定的条件以后，系统可以进行限制。对于HTTP层面的速率限制，常见结果可以是拒绝请求或者返回429 Too Many Requests，具体行为取决于配置的规则和动作。

但是rate limiting并不是万能的DDoS防护。

如果攻击流量规模已经达到网络基础设施级别，仅仅依靠应用层的“每个IP每秒多少请求”并不能解决所有问题。Cloud Armor依托Google的全球网络和基础设施提供DDoS防护能力，其中网络层和应用层防护需要结合具体产品版本和部署架构理解。

因此，不能把“Cloud Armor限制每个IP的请求数量”和“Google Cloud抵御大规模DDoS流量”当成同一件事情。

另一个容易被误解的功能是Adaptive Protection。

Cloud Armor Enterprise中的Adaptive Protection可以利用机器学习等机制识别异常应用层流量模式，并针对潜在的L7 DDoS攻击提供检测和防护能力。

这里与原始稿中所谓“Cloud Armor通过分析所有历史流量自动建立一个正常用户基线，然后自动判断异常IP”的描述存在明显区别。

Adaptive Protection并不是简单地给每一个网站建立一个固定的“正常访问次数表”，然后发现超过阈值就自动封IP。生产环境中的攻击检测涉及流量特征、请求模式以及攻击行为识别，并且自动防护机制仍然需要结合业务情况进行配置和验证。

机器学习在这里是增强检测能力的一部分，而不是Cloud Armor所有规则的底层工作方式。

Cloud Armor还可以通过自定义规则进行更精确的访问控制。

例如一个企业的API入口是/api/，管理后台是/admin/，登录接口是/login。这三个路径的安全需求完全不同。

公开API可能需要较高的访问容量，但登录接口应该重点防止暴力尝试。管理后台则可以采用IP allowlist或者更严格的身份认证体系。

这种情况下，与其给整个网站设置一个统一的限制，不如根据请求路径、请求属性和业务特征建立不同的规则。

不过需要强调，Cloud Armor并不等于身份认证系统。

如果某个API要求用户登录，Cloud Armor不能替代应用自己的OAuth、Session、JWT、API Key或者其他身份认证机制。Cloud Armor主要负责判断流量是否符合安全策略，而应用本身仍然必须判断“这个用户是谁”“有没有权限访问这个资源”“这个租户是否拥有这条数据”。

这也是云安全架构中经常被忽略的一层。

例如攻击者使用一个完全合法的账号调用API，如果应用没有做好Authorization和tenant isolation，那么Cloud Armor即使判断这是一条正常HTTP请求，也没有理由把它拦截。

所以Cloud Armor主要解决的是“请求是否应该进入后端”以及“异常流量如何限制”，而不是“用户是否有权访问业务数据”。

Cloud Armor与Google Cloud Load Balancing的关系也非常重要。

在典型Google Cloud架构中，外部请求首先进入Google Cloud的负载均衡体系，然后按照配置进入Cloud Armor策略处理，再由负载均衡系统将允许的请求转发到后端服务。

这使得安全策略能够处于应用后端之前。

如果攻击流量已经大量消耗了Web服务器的CPU、连接数和线程池，再由服务器自己的WAF进行判断，防护效果自然会受到影响。将部分过滤工作放在云端入口，可以减少恶意请求直接消耗后端资源的机会。

但这里也不能把Cloud Armor理解成“全球每个节点都自动建立一个本地WAF”。

Google Cloud的全球负载均衡和边缘网络负责流量接入、调度以及相关基础设施能力，而Cloud Armor则提供安全策略和应用层防护。两者是协同关系，而不是一个概念。

对于SQL注入和XSS，Cloud Armor的WAF可以提供重要的第一道防线，但应用程序本身仍然必须进行安全编码。

SQL查询应该使用参数化查询，而不是把用户输入直接拼接进SQL语句。

输出到HTML页面的数据应该根据上下文进行正确编码。

API应该验证输入的数据类型、长度、格式和业务规则。

文件上传必须检查真实文件类型、扩展名、大小、内容以及存储位置。

这些安全措施不能因为Cloud Armor已经部署就被省略。WAF应该被看成纵深防御的一部分，而不是替代安全开发。

Cloud Armor同样不能阻止所有类型的机器人流量。

一个爬虫可能完全按照HTTP协议正常访问网页，并且每秒只有几次请求。从网络层面看，这可能完全正常，但如果它持续抓取大量页面，仍然可能给数据库、应用服务器和带宽造成压力。

对于这种情况，需要结合rate limiting、请求特征、应用层行为分析以及业务本身的机器人管理策略。

如果网站有登录、搜索、评论、内容生成或者高成本API，那么最需要保护的往往不是首页，而是这些能够消耗大量后端资源的端点。

例如一个搜索API每次请求都会执行复杂数据库查询。如果攻击者每秒只发送几十个请求，看起来并不算传统意义上的“大流量攻击”，但数据库连接池可能已经开始饱和。

因此rate limiting的单位不应该只按照整个网站的requests per second设置，还应该结合endpoint、用户、IP、API Key、租户以及请求成本进行设计。

对于高价值API，还可以在应用层增加自己的并发控制、队列、缓存和熔断机制。

Cloud Armor的日志同样非常重要。

防护系统如果只负责“拦截”，却没有可观察性，管理员很难知道规则是否误伤了用户，也很难判断攻击究竟针对哪个接口。

生产环境应该结合Cloud Logging、Cloud Monitoring以及相关安全监控能力分析Cloud Armor产生的请求和安全事件。

需要观察的不只是被拒绝的请求数量，还包括命中规则、来源IP、请求路径、HTTP状态码、请求速率以及不同时间段的变化。

如果某个规则突然大量命中，而业务团队却没有发现对应的真实攻击，就需要检查是否发生了误报。

如果攻击者不断更换IP，但始终集中攻击同一个API，则单纯增加IP黑名单可能并不是最有效的解决办法。此时应该考虑针对路径、身份、API Key、请求速率以及其他请求属性进行控制。

IP黑名单本身也存在局限。

现代攻击经常使用代理网络、云主机、被入侵的设备或者大量不同来源地址。封掉一个IP并不能解决攻击者继续更换地址的问题。

对于IPv6环境尤其需要注意地址和网络前缀的处理方式。安全规则设计不能简单复制IPv4时代的思路。

企业还应该避免把Cloud Armor当成唯一的安全控制层。

一个比较完整的Google Cloud Web架构，通常至少需要考虑边缘流量防护、负载均衡、WAF、rate limiting、应用认证授权、数据库权限、Secret管理、日志审计以及漏洞管理。

如果后端是GKE、Compute Engine或者其他计算服务，还需要进一步考虑网络隔离、服务账号权限、实例安全和东西向流量控制。

Cloud Armor负责其中非常重要的一部分，但它无法替代IAM、应用安全、数据库安全和主机安全。

对于实际部署，可以按照业务特点建立分层策略。

公开网站首先处理明显恶意流量和已知攻击模式；登录、注册、搜索和高成本API设置更加严格的rate limiting；后台管理接口采用更严格的来源和身份控制；对于WAF规则则先观察命中情况，再逐步调整策略；对于高风险规则可以先采用预览或者监控方式验证误报情况，再决定是否正式阻断。

这样做的好处是不会因为一次规则配置错误，把整个生产网站一起关掉。

Cloud Armor真正有价值的地方，并不是它可以替企业写一套万能的安全规则，而是把大量流量控制能力放到了Google Cloud网络和负载均衡体系中，使应用后端不必独自承担所有异常请求。

但这也意味着Cloud Armor的效果高度依赖配置。

一个没有合理规则、没有日志监控、没有rate limiting、没有应用层授权控制的网站，即使部署了Cloud Armor，也不能因此变成安全系统。

对于Web应用来说，最可靠的架构仍然是纵深防御。Cloud Armor负责边缘流量和部分应用层攻击防护，负载均衡负责流量入口和后端调度，应用负责身份认证、授权和业务规则，数据库负责数据层访问控制，监控系统负责持续发现异常。

理解这一点以后，就不会再把Cloud Armor简单看成一个“云端防火墙”。

它更接近Google Cloud网络入口上的安全控制层。它可以帮助企业过滤恶意请求、限制异常流量、缓解部分DDoS风险，并利用WAF和Adaptive Protection等能力识别更复杂的应用层攻击，但最终能否把一个Web应用保护好，仍然取决于安全策略、应用架构、身份权限、数据保护和运维监控是否形成完整体系。