Azure上的安全内联防护故障开放架构
每个内联部署都面临着一个权衡：增强的检查能力与增加的停机风险。内联保护对于API来说至关重要，特别是考虑到API现在是最受攻击的目标表面，但持续的运行时间和性能同样重要。这就是故障开放架构的用武之地。
这篇Wallarm操作指南博客概述了如何在Azure上使用故障开放设计部署Wallarm的安全边缘平台，确保高可用性和零中断，即使过滤基础设施变得无响应。
挑战：无停机的内联安全
API驱动着业务关键操作。因此，它们的可用性是不可妥协的。任何内联解决方案，无论多么有效，都可能成为单点故障。如果流量过滤节点离线或变得无响应，用户可能面临延迟、集成中断或完整的应用程序中断。
这是对内联部署最常见的反对意见之一。虽然传统的WAF可能需要在保护和可用性之间做出权衡，但现代云架构允许两者兼得。通过将Azure Front Door与Wallarm的分布式安全边缘节点结合使用，组织可以构建一个高可用、自动故障转移的系统，在保持保护的同时不损害性能。
什么是Wallarm安全边缘？
Wallarm安全边缘是一个云原生的托管服务，在多个地理区域部署过滤节点。这些节点实时内联检查流量，在恶意API调用到达您的源服务器之前识别并阻止它们。
与传统安全设备不同，安全边缘不需要您安装或管理任何本地硬件。您只需将API和Web流量路由通过Wallarm过滤节点，即可受益于实时检测OWASP Top 10威胁、API漏洞利用以及新兴攻击（如LLM提示注入）。
但如果过滤集群变得不可达怎么办？
使用Azure Front Door引入故障开放逻辑
通过集成Azure Front Door的主动/被动路由能力，组织可以实现一个弹性的故障开放架构，在罕见的故障事件中绕过过滤节点，从而确保持续的API可用性。
设置带有源组的Azure Front Door
Azure Front Door充当传入流量的全局入口点。当您创建Front Door实例时，它会提供一个完全限定域名（FQDN）——例如，azureFrontDoor-a7ajbwefb6bza6ez.z01.azurefd.net。
通常，您会配置一个CNAME记录，将您的公共子域（例如api.example.com）映射到此FQDN，允许所有请求通过Front Door路由。
要启用自动故障转移，您需要将两个源端点配置到一个源组中：
- 主要源：指向Wallarm过滤节点集群。
- 次要源：直接指向您的应用程序后端，绕过Wallarm。
配置基于优先级的路由
Azure Front Door允许您为每个源分配优先级级别。数字越低，优先级越高：
- 优先级1：Wallarm过滤节点集群。
- 优先级2：直接到源的备份路径。
流量总是路由到最高优先级的健康源。如果Wallarm节点集群变得不可用，Azure Front Door会自动切换到次要源，确保持续服务。
这就是故障开放架构的精髓：如果安全基础设施失败，可用性通过设计获胜。
自定义健康探测以实现精细控制
为了检测故障条件，Azure Front Door依赖健康探测。这些定期检查验证过滤节点集群是否响应。如果探测在连续尝试一定次数后失败，流量将被重定向到健康的备用源。
您可以使用以下方式自定义这些探测：
- 特定的HTTP路径或头
- 超时和响应阈值
- 健康检查频率
这种灵活性使您的安全和基础设施团队能够精确控制故障转移行为。
流量如何流动
一旦部署，典型的请求流如下所示：
- 用户向api.example.com发出请求
- DNS CNAME记录将请求指向Azure Front Door FQDN
- Azure Front Door检查主要源（Wallarm过滤集群）的健康状况
- 如果健康，流量通过Wallarm进行内联检查
- Wallarm将清洁的请求转发到配置中定义的实际后端服务器
- 如果Wallarm集群不可用，Azure Front Door自动将流量重新路由到直接源路径，无需手动干预
无需牺牲的安全性
这种架构提供了两全其美的优势：
- 实时内联保护：当Wallarm集群健康时，所有流量都会进行威胁检查
- 默认高可用性：如果过滤失败，用户仍然可以无中断地访问您的API和应用程序
- 完全托管的部署：无需设备，无需手动修补，无需维护烦恼
Wallarm的安全边缘节点和Azure Front Door共同提供了一个弹性的、云原生的安全模型，专为现代API环境量身定制。要了解更多关于在Azure上内联部署Wallarm安全边缘并构建您自己的故障开放架构的信息，请查看官方Wallarm文档。