亚马逊AWS官方博客
利用 Gateway Load Balancer 打造符合 MLPS2.0 的安全网络架构 – 网络部署篇
一、概述
随着我国网络空间日益开放,网络安全形势日趋严峻。为贯彻落实《网络安全法》,保障关键信息基础设施的安全可控,国家网信办等部门联合制定了《网络安全等级保护制度》。该制度要求网络运营者建立网络安全防护体系,采取相应的技术手段和管理措施,保证网络安全等级不低于该规定要求。
亚马逊云科技作为云计算领域的领先厂商,也在积极响应国家政策要求,并结合自身的技术为用户构建符合网络安全等级保护技术要求的云上架构,AWS Gateway Load Balancer(GWLB)的推出为此提供了重要支撑。本文拟通过详细介绍 GWLB 的工作原理,并给出基于 GWLB 实现网络安全等级保护的网络安全架构方案,以帮助读者更好地在云上部署安全可靠的业务系统,提高网络安全防护能力。
二、总体架构
概述
Gateway Load Balancers(GWLB)让您能够部署、扩展和管理虚拟设备,例如防火墙、入侵检测、防御系统以及深度数据包检测系统。它结合了一个透明的网络网关(即所有流量的单个入口和出口点),并分配流量,同时也可以根据需求扩展虚拟设备。
本方案的 VPC 架构如下:
- 1 个 Appliance VPC 负责运行 Appliance(模拟虚拟防火墙),VPC 具备 Internet Gateway(IGW)作为 Appliance 的更新和管理入口;
- 1 个 Spoke VPC 运行 WEB 应用,具备 IGW 作为流量出口;WEB 应用采用 Application Load Balaner(ALB)进行负载均衡,并通过 ALB 的 CNAME 对外提供 WEB 服务;
- Spoke VPC 为多层结构,分为 Gateway Load Balancer Endpoint(GWLBe)所处的 Public Subnet,ALB 所处的 Protected subnet,以及 Application EC2 所处的 Private subnet。
ALB 流量转发如下:
- 客户端从公网发起了一个在 ALB 上 Host 的 Web 服务请求数据包,此数据包经过 IGW 进入了 VPC 内部,将 ALB Public IP 转换成 Private IP,根据 ingress 路由表(igw-rtb),数据包转被发到了 Availability Zone 1(AZ1)的 GWLBe。
- AZ1 GWLBe 收到数据包后,通过 GWLB 将数据包转发到了 Appliance 上进行 ingress flow 的 Inspection。
- Inspection 完毕后数据包返回到了 AZ1 GWLBe 中。
- GWLBe 根据所处 subnet 的路由表的 Local 条目,将数据转发到了 ALB Private IP 上,ALB 进行了负载均衡转发到了后端的 application instance 中。
- Application instance 处理完数据包后根据所处子网路由表,将路由转发至 ALB,ALB 根据所处子网路由表的默认路由,将数据包转发给了 GWLBe。
- AZ1 GWLBe 收到数据包后,通过 GWLB 将数据包转发到了 Appliance 上进行 egress flow 的 inspection。
- Inspection 完毕后数据包再此返回到了 AZ1 GWLBe 中。
- GWLBe 根据所处 subnet 的路由表的默认路由条目,将数据返回了 IGW,后者将数据包返回公网,最终回到客户端。
NATGW 流量转发如下:
- AZ1 的 Application Instance 主动访问公网的流量,根据其子网路由表默认路由转发到 NATGW,NATGW 将数据包的源 IP 从 Application instance 转换为 NATGW 的 Private IP,最后根据其子网路由表的默认路由转发到 AZ1 的 GWLBe。
- AZ1 GWLBe 收到数据包后,通过 GWLB 将数据包转发到了 virtual appliance 上进行 egress flow 的 inspection。
- Inspection 完毕后数据包再此返回到了 AZ1 GWLBe 中。
- GWLBe 根据所处 subnet 的路由表的默认路由条目,将数据转发到了 IGW,IGW 将数据包源 IP 转成 NATGW 的 EIP,然后将数据包发向公网。
- 公网处理完数据之后,回包到 NATGW 的 EIP,此数据包经过 IGW 进入了 VPC 内部,将数据包的目标 IP 转换成 NATGW 的 Private IP,根据 ingress 路由表,数据包转被发到了 AZ1 的 GWLBe。
- AZ1 GWLBe 收到数据包后,通过 GWLB 将数据包转发到了 virtual appliance 上进行 ingress flow 的 inspection。
- Inspection 完毕后数据包返回到了 AZ1 GWLBe 中。
- GWLBe 根据所处 subnet 的路由表的 Local 路由条目,将数据转发到了 NATGW Private IP 上,NATGW 根据记录将目标 IP 转成 Application instance 的 private IP,最后根据 local 路由条目,转发到了后端的 application instance 中。
跨区域负载均衡 Cross Zone Load Balancing 配置
若要实现 GLWB 跨区域负载均衡,需要 GWLB 在不同 AZ 的 ENI 与在不同 AZ 的 Appliance 数据口之间建立 full mesh 的 geneve tunnel,以保障 GWLB 跨可用区进行负载均衡,本文模拟的 Genve tunnel 拓扑如下图:
在 EC2 配置 NAT 规则模拟 Geneve tunnel 与 GWLB 进行通讯
在本文中,在 appliance VPC 里,我们用 EC2 模拟了 virtual appliances,采用 NAT 的技术将所有 6081 的流量直接环回透传给了 gateway load balancer,以达到模拟 geneve tunnel 的目的,以处于 AZ1 的 appliance 1 为例,其 NAT iptables 规则如下图:
- 192.168.1.8(AZ1 GWLB ENI IP)
- 192.168.1.22(AZ2 GWLB ENI IP)
- 192.168.1.10(Appliance 1 IP)
- 入向:将源为 GWLB 192.168.1.8,192.168.1.22,而目的地为 192.168.1.10 的任意端口的这种流量的目的地址,DNAT 改为 192.168.1.8:6081,192.168.1.22:6081
- 出向:把源目的 IP 都为 192.168.1.8,192.168.1.22,并且目的端口为 6081 的流量,在往外发出时都将 SNAT 改为本 Appliance 1 的 eth0 地址 192.168.1.10
也许聪明的你已经注意到,我们的 Appliance 1 的 NAT 规则对 AZ1 和 AZ2 的 GWLB ENI IP 都进行了配置。没错,因为我们在后续的章节里需要模拟跨区域负载均衡,所以必须按照前面所讲到的拓扑进行配置,也就是建立 full mesh 的通讯,在现实场景将会需要建立 full mesh 的 geneve tunnel,本文的模拟场景则是用 full mesh 的 NAT 规则代替。
三、部署流程
我们将基于此链接中的 CloudFormation 模版进行我们得方案部署,CloudFormation 将会部署以下资源:
DistributedArchitectureApplianceVpc2AzCN.yaml:
- 1 个 VPC
- 1 个 IGW
- 2 个 位于不同可用区的 Public 子网
- 1 个 Public 路由表
- 与该路由表关联的 2 个 Public 子网
- 0.0.0/0 的下一跳设置为 IGW
- 1 个安全组
- 允许 22 端口访问
- 允许 80 端口访问
- 允许从 VPC CIDR 的所有 TCP、UDP 和 ICMP
- 每个 AZ 中 2 个 Amazon Linux 2 实例作为虚拟防火墙,并作为 GWLB 后的目标进行注册,在实例上配置 iptables 以进行 hairpin 设置
- 1 个 GWLB
- GWLB 的 1 个目标组
- GWLB 的 1 个监听器
- 1 个 VPC 端点服务
DistributedArchitectureSpokeVpc2AzCN.yaml:
- 1 个 VPC
- 1 个 IGW
- AZ1 中的 3 个子网:分别用于 application1、GWLBE1 和 protected(ALB1/NATGW1)
- AZ2 中的 3 个子网:分别用于 application2、GWLBE2 和 protected(ALB2/NATGW2)
- 6 个路由表:分别用于 application1、GWLBE1、application2、GWLBE2、protected(ALB1/NATGW1)、protected(ALB2/NATGW2)和 IGW
- 2 个 安全组:Application 和 Bastion
- 2 个 Amazon Linux 2 实例,在 application1 和 application2 中充当 WEB 应用程序
- 如果 Bastion 条件设置为 Yes,则有 1 个 Amazon Linux 2 实例充当堡垒主机
- 还为 AWS Systems Manager (SSM)创建 interface endpoint
打开 CloudFormation console,点击 create stack > with new resources,点击 Specify template,选择 upload a template file,载入 DistributedArchitectureApplianceVpc2AzCN.yaml,然后点击 Next。
参考下列例子填入必选参数,然后点击 Next:
- Stack name:appliance
- Availability Zone 1:cn-northwest-1a
- Availability Zone 2:cn-northwest-1b
- KeyPair required for accessing Appliance instance:your-key
- AWS Account to Whitelist for the Service:*
最后一步维持所有默认参数,点击创建。
等待部署完成后,选择 appliance stack,点击 output,记录下 ApplianceVpcEndpointServiceName 的值,例如:cn.com.amazonaws.vpce.cn-northwest-1.vpce-svc-xxxx,留在下一阶段使用。
部署 DistributedArchitectureSpokeVpc2AzCN.yaml
打开 CloudFormation console,点击 create stack > with new resources,点击 Specify template,选择 upload a template file,载入修改后的 DistributedArchitectureSpokeVpc2AzCN.yaml,其他参数保持默认,点击 Next。
参考下列例子填入必选参数,然后点击 Next:
- Stack name:spoke
- Availability Zone 1:cn-northwest-1a
- Availability Zone 2:cn-northwest-1b
- KeyPair required for accessing Appliance instance:your-key
- Gateway Load Balancer Endpoint Configuration:填入上一步里 ApplianceVpcEndpointServiceName 的值
部署完成。
四、测试
访问测试
接下来我们会进行测试。首先,我们会在 Appliance 上运行 tcpdump 抓取 WEB 服务的访问流量。
NOTE* 在亚马逊云科技中国区部署的 ALB 需要通过 ICP 备案才能够被公网访问。
在 EC2 console 里找到 Bastion,登陆并使用 curl 访问 ALB CNAME,访问成功。
同时,在已运行 sudo tcpdump -ni eth0 port 6081 | grep 68.79.11.202 的 appliance1(68.79.11.202 为 Bastion IP 地址),我们可看见 web 访问流量流量由 IP 192.168.1.8,即 cn-northwest-1b 的 gateway load balancer ENI IP 转发而来。
在 Appliance2 可看见 web 访问流量由 IP 192.168.1.22,即 cn-northwest-1b 的 gateway load balancer ENI IP 转发而来。
测试成功,两个 Appliance 都能够检测到 ALB 的 web 访问流量。当前因为没开启跨区域负载均衡,所以 appliance 都只能从自己所处的可用区 gateway load balancer ENI 收到流量。
跨区域负载均衡测试故障模拟
关键网络设备的高可用性,是网络安全等级保护中的重点技术要求。GWLB 可以实现跨区域的负载均衡,来实现高可用功能。接下来我们将打开 GWLB 跨区域负载均衡并进行跨区域负载均衡故障模拟测试。
进入 EC2 Console > Load Balancer > gwlb1,对 gwlb1 点击右键,选择 edit attributes,在 cross-zone load balancing 打勾
开启此功能后 GWLB 将会进行跨区域负载均衡,针对此功能的详细解释可参考此链接,接下来我们将进行故障模拟。
设备级别故障:
我们将 virtual appliace 2 从 GWLB 的 Target group 里进行剔除。下图为此情况下流量走向预测:当 dns 解析到 cn-northwest-1b 的 ALB 时,流量会转发到 appliance vpc 里 cn-northwest-1b GWLB ENI,因为 1b 的 Appliance 2 已不存在,ENI 只能将流量转发到 AZ1 的 appliance 1。
下面我们来登陆 Appliance 1 用 tcpdump 来验证我们的预测,由截图可见,web 访问流量 192.168.1.22,即不同于 appliance1 所处的 cn-northwest-1a的cn-northwest-1b GWLB ENI 跨区域转发而来。
核实 192.168.1.22,确定是 cn-north-1b 的 GWLB ENI 地址,符合预期。
五、总结
本文所提出的基于 Gateway Load Balancer 的网络安全防护架构,能够满足网络安全等级保护中的以下核心技术要求:
- 构建多级网络边界防护体系。GWLB 可以转发流量到多台虚拟防火墙进行层层检测,实时监控并预警发现入侵行为。
- 支持必要的网络流量过滤。虚拟防火墙可以进行黑白名单、协议、端口控制等流量过滤。
- 设备与网络采取区隔管理。通过虚拟网络隔离不同安全区域。
- 资源扩展能力弹性。GWLB 后端可以灵活扩展虚拟防火墙实例。
- 架构为关键网络设备提供高可用性, GWLB 可以实现跨区域的负载均衡,来实现高可用功能。
综上,本方案能帮助用户打造一个动态可控、安全可靠的网络防护体系,满足国家网络安全等级保护的合规要求。在接下来的一篇博客中,我们将介绍如何基于本架构加入审计日志收集分析功能,敬请期待。
六、参考文档
https://github.com/aws-samples/aws-gateway-load-balancer-code-samples