以 AWS 为例,我们创建 EC2、ECS 等云服务器后，通常都需要配置一个非常重要的网络安全组件：
安全组可以理解为一种由云平台提供的虚拟网络访问控制机制。
例如，一台云服务器运行了：
greenyang361
SSH 22
HTTP 80
HTTPS 443
MySQL 3306
Redis 6379
并不意味着这些端口一定能够从互联网访问。
即使程序正在监听 3306：
ss -lntp
显示：
LISTEN 0 128 0.0.0.0:3306
如果云平台安全组没有允许外部 IP 访问 TCP 3306，那么外部客户端仍然无法建立连接。
因此，可以简单理解为：
程序监听端口
↓
操作系统防火墙允许
↓
云平台安全组允许
↓
网络路由/NAT等条件满足
↓
客户端才能成功访问
安全组与服务器内部的 iptables、nftables、firewalld、Windows Defender Firewall 并不是同一个东西。
所谓“添加白名单”，本质上就是：
在安全组中添加一条允许规则，规定哪些来源可以通过什么协议访问哪些端口。
例如：
协议：TCP
端口：22
来源：203.0.113.10/32
动作：允许
其含义可以理解为：
203.0.113.10
│
│ TCP 22
▼
┌───────────────┐
│ 云平台安全组 │
│ │
│ 规则匹配成功 │
│ Allow │
└───────┬───────┘
│
▼
EC2/ECS
│
▼
SSH 服务
其他来源访问 22 端口时，如果没有其他允许规则与之匹配，就无法通过安全组。
例如：
203.0.113.10 ──→ TCP 22 ──→ Allow
198.51.100.8 ──→ TCP 22 ──→ 无匹配规则
↓
丢弃
这就是安全组“白名单”的基本原理。
安全组经常使用 CIDR 表示允许访问的 IP 范围。
例如：
203.0.113.10/32
表示只允许：
203.0.113.10
这一台 IPv4 主机。
而：
203.0.113.0/24
表示一个更大的地址范围。
最需要谨慎的是：
0.0.0.0/0
它表示所有 IPv4 地址。
例如：
TCP 22
Source: 0.0.0.0/0
实际上意味着：
互联网任意 IPv4 地址
│
▼
TCP 22
│
▼
云服务器
所以对于 SSH、数据库、Redis、Elasticsearch 等管理或基础设施端口，通常不应该为了方便直接长期开放：
0.0.0.0/0
更合理的方式通常是限制为固定公网 IP、VPN 网段、堡垒机、安全组引用或其他可信网络来源。
从实现角度看，安全组属于软件定义的网络安全机制。
但它与通常所说的“服务器软件防火墙”不是一回事。
例如 Linux：
iptables
nftables
firewalld
Windows：
Windows Defender Firewall
这些防火墙运行在实例自己的操作系统网络栈中。
而 AWS Security Group 安全组由云平台的虚拟网络基础设施负责执行。
可以把它们分成三层理解：
┌──────────────────────────────┐
│ 云平台网络层 │
│ Security Group / 安全组 │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ 云服务器操作系统 │
│ nftables / iptables / firewalld│
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ 应用程序 │
│ Nginx / MySQL / Redis / Go │
└──────────────────────────────┘
因此，即使服务器内部完全没有配置 iptables，云安全组仍然可以阻止网络访问。
反过来也一样：
即使安全组允许 TCP 3306，如果 Linux 防火墙禁止 3306，客户端依然连接失败。
这里非常容易产生误解。
不能简单地认为：
Internet
↓
Security Group
↓
VPC
↓
EC2
然后认为 Security Group 就部署在整个 VPC 的入口。
更准确的理解是：
安全组通常与云资源的虚拟网络接口或实例关联，并针对这些资源的入站和出站流量实施访问控制。
逻辑上可以理解为：
Internet
│
▼
云平台网络基础设施
│
├── 路由
├── NAT / 公网映射
├── 网络访问控制
│
▼
┌───────────────────┐
│ Security Group │
│ 与实例/网络接口关联 │
└─────────┬─────────┘
│
▼
EC2 / ECS
│
▼
OS Firewall
│
▼
Application
因此：
安全组 ≠ VPC 边界防火墙
安全组 ≠ 虚拟路由器
安全组 ≠ 操作系统防火墙
它们属于不同层次的网络组件。
传统数据中心可能部署：
Internet
│
▼
Hardware Firewall
│
▼
Switch
│
▼
Server
硬件防火墙通常是独立的物理设备或者专用安全设备。
例如：
Linux
├── nftables
├── iptables
└── firewalld
它们运行在服务器内部。
数据包已经到达服务器后，由操作系统网络栈决定是否允许继续处理。
云安全组则由云平台控制：
Cloud Network
│
▼
Security Group
│
▼
Virtual NIC
│
▼
Virtual Machine
用户并不需要知道底层究竟是哪台交换机、哪张网卡或者哪台物理服务器负责执行规则。
用户只需要声明：
允许谁
访问什么协议
访问什么端口
云平台负责将策略转换成实际的数据平面规则。
假设 EC2 正在运行：
Ubuntu
服务器里面什么都不修改。
我们只在 AWS 控制台中增加：
TCP
Port: 8080
Source: 203.0.113.10/32
规则仍然可以生效。
原因就在于：
Security Group 并不是依靠 Ubuntu 内部的软件执行的。
配置过程可以抽象为：
用户
│
│ Web Console / API / CLI
▼
AWS 控制面
│
│ 保存安全策略
▼
网络控制系统
│
│ 将规则下发到相关网络数据平面
▼
云平台网络基础设施
│
│ 执行数据包过滤
▼
EC2 / ECS
因此：
控制台只是配置入口
API只是配置接口
真正过滤数据包的是云平台网络基础设施
理解云安全组最重要的概念之一，就是：
Control Plane
+
Data Plane
控制平面负责：
创建规则
修改规则
删除规则
保存策略
管理资源
将策略分发到数据平面
例如我们在 AWS 控制台添加：
TCP 443
Source: 0.0.0.0/0
本质上是在修改云平台中的网络策略。
控制平面负责把：
用户声明的规则
转换成底层网络系统能够执行的策略。
数据平面负责真正处理：
每一个数据包
例如：
Client
│
│ TCP SYN
▼
Cloud Network
│
│ 查询/执行安全策略
▼
Allow ?
│
┌┴──────────┐
│ │
YES NO
│ │
▼ ▼
EC2 DROP
因此：
控制平面 = 决定规则是什么
数据平面 = 根据规则处理真实流量
假设服务器：
10.0.1.10
运行 Nginx：
TCP 80
安全组规则：
TCP 80
Source: 203.0.113.10/32
当：
203.0.113.10
访问服务器时，可以抽象为：
客户端
203.0.113.10
│
│ TCP SYN :80
▼
云平台网络数据平面
│
│ Security Group
│
├── Source IP？
├── Protocol？
├── Port？
└── Connection State？
│
▼
规则匹配
│
▼
Allow
│
▼
EC2虚拟网络接口
│
▼
Linux Network Stack
│
▼
Nginx :80
如果来源变成：
198.51.100.20
并且没有其他规则允许它：
198.51.100.20
│
▼
Security Group
│
▼
没有允许规则
│
▼
DROP
数据包不会因为 Nginx 正在监听 80 就自动获得访问权限。
AWS Security Group 是 Stateful（有状态） 的。
例如入站规则允许：
203.0.113.10
↓
EC2 TCP 443
连接建立以后：
Client
│
│ Request
▼
EC2
│
│ Response
▼
Client
返回流量属于已经建立的连接。
安全组会跟踪连接状态，因此不需要简单地为每一个请求/响应方向机械地建立完全对称的规则。
可以理解为：
第一次：
检查规则 + 建立连接状态
后续：
识别为已建立连接的相关流量
这与无状态 ACL 的工作方式不同。
AWS 中还存在另一个容易与 Security Group 混淆的组件：
Network ACL
二者不是同一个东西。
可以用下面的方式建立初步认识：
| Security Group | Network ACL |
|---|---|
| 与资源/网络接口相关联 | 与 Subnet 相关联 |
| Stateful | Stateless |
| 主要使用 Allow 规则 | 支持 Allow / Deny |
| 更接近实例级访问控制 | 更接近子网级访问控制 |
例如：
VPC
│
├── Subnet
│ │
│ ├── Network ACL
│ │
│ ├── EC2 A
│ │ └── Security Group A
│ │
│ └── EC2 B
│ └── Security Group B
所以不能简单地把：
Security Group
理解成：
VPC入口防火墙
AWS Security Group 安全组在使用思想上非常相似：
用户定义网络访问策略
│
▼
云平台控制面
│
▼
网络虚拟化系统
│
▼
数据平面执行策略
│
▼
云服务器虚拟网络接口
│
▼
EC2 / ECS
用户看到的是：
IP
Protocol
Port
Source / Destination
Allow / Policy
底层看到的则是云平台需要执行的网络策略。
假设：
EC2
└── Ubuntu
即使 Ubuntu：
iptables -F
把本机防火墙规则全部清空，AWS Security Group 仍然存在。
甚至服务器操作系统根本不知道：
AWS Console 中到底配置了哪些 Security Group Rules
因为这些规则属于：
Cloud Infrastructure
而不是：
Guest Operating System
可以理解成：
┌─────────────────────────────────┐
│ Cloud Provider │
│ │
│ VPC / Routing / Security Group │
│ Virtual Networking │
│ │
│ ┌──────────────────┐ │
│ │ Virtual Machine │ │
│ │ │ │
│ │ Linux │ │
│ │ nftables │ │
│ │ Nginx │ │
│ └──────────────────┘ │
└─────────────────────────────────┘
Security Group 属于外层云基础设施提供的能力。
从用户视角：
AWS Console
│
▼
Security Group
非常简单。
但底层实际上涉及一个规模巨大的分布式网络系统。
可以抽象成：
Control Plane
│
┌───────┴───────┐
│ Network Policy │
│ Routing │
│ SG Rules │
└───────┬───────┘
│
规则分发/同步
│
▼
Data Plane
│
┌────────────┼────────────┐
│ │ │
Host A Host B Host C
│ │ │
VM / ENI VM / ENI VM / ENI
因此，安全组不是：
一台专门的 VPS
↓
运行一个 Firewall.exe
而更接近：
分布式网络策略
+
云网络数据平面
+
虚拟化/硬件加速
共同实现的安全功能。
传统物理服务器可能是：
Server A ──┐
Server B ──┼── Physical Switch
Server C ──┘
虚拟化以后，一台物理服务器可能运行很多 VM：
Physical Server
│
├── VM1
├── VM2
├── VM3
│
└── Virtual Networking
│
▼
Physical NIC
│
▼
Physical Network
虚拟网络系统负责把：
VM
虚拟网卡
VPC
Subnet
Route
Security Policy
映射到真实物理网络。
因此用户看到：
10.0.1.10
10.0.1.11
10.0.2.10
并不意味着物理网络真的按照用户看到的逻辑拓扑进行布线。
这就是：
Network Virtualization
的重要意义。
SDN 的核心思想之一，是将：
控制逻辑
和：
数据转发
进行逻辑上的分离。
传统网络：
Router
├── Control Plane
└── Data Plane
云网络：
Central / Distributed Control System
│
│ 下发策略
▼
Distributed Data Plane
于是云平台可以通过软件/API快速创建：
VPC
Subnet
Route
Security Group
Load Balancer
NAT
而不需要工程师每创建一台 EC2，就跑到机房里重新插网线、配置一台物理交换机。
“虚拟网络”并不代表不存在真实硬件。
最终的数据包仍然必须经过：
CPU
NIC
Switch
Router
Fiber
Cable
ASIC
只是云平台在这些物理资源之上建立了一层抽象。
因此：
Virtual Network
│
▼
Software Defined Networking
│
▼
Virtualization / Offload
│
▼
Physical Network
如果所有网络功能都完全依赖服务器 CPU 软件处理：
VM Traffic
│
▼
Host CPU
│
├── Routing
├── Firewall
├── NAT
├── Encryption
└── Virtual Switching
大量网络流量会消耗很多 CPU。
因此现代大型云平台会利用：
SmartNIC
DPU
ASIC
FPGA
专用加速硬件
承担部分网络、存储、安全或虚拟化任务。
抽象来看：
Physical Server
│
┌────────────┴────────────┐
│ │
Host CPU SmartNIC / DPU
│ │
VM计算 网络处理/卸载
│ │
└────────────┬────────────┘
│
Physical Network
这样能够减少主机 CPU 在基础设施任务上的开销。
AWS Nitro System 不应该简单理解成：
Nitro = 一张普通 SmartNIC
更准确的理解是：
Nitro 是 AWS EC2 使用的一套硬件与软件虚拟化基础设施体系，其中包含专用硬件组件，用于卸载和隔离部分网络、存储、管理和虚拟化功能。
因此：
AWS Nitro System
│
├── 专用硬件
├── 网络/存储卸载
├── 安全隔离
└── 虚拟化基础设施
它比单纯的“智能网卡”概念更广。
我们在浏览器里：
AWS Console
点击：
Edit inbound rules
添加：
TCP 22
203.0.113.10/32
并不是浏览器本身在过滤数据包。
Web 控制台只是：
管理界面
其背后的过程可以抽象成：
Browser
│
▼
AWS / Alibaba Cloud API
│
▼
Cloud Control Plane
│
▼
Network Policy
│
▼
Distributed Data Plane
│
▼
Traffic Filtering
所以：
Web Console ≠ Firewall
API ≠ Firewall
Security Group Policy + Cloud Data Plane
↓
才构成实际的访问控制
假设：
AWS EC2
Public IP:
203.0.113.100
Private IP:
10.0.1.10
Nginx:
TCP 443
安全组：
HTTPS
TCP 443
Source: 0.0.0.0/0
Linux：
nftables允许443
Nginx：
listen 443 ssl;
那么一次访问可以抽象为：
用户浏览器
│
│ HTTPS
▼
Internet
│
▼
AWS Physical Network
│
▼
AWS Virtual Network
│
├── Routing
├── Public/Private Address Mapping
├── Security Policy
│
▼
Security Group
│
│ TCP 443 Allow
▼
EC2 Virtual NIC
│
▼
Linux Network Stack
│
▼
nftables
│
▼
Nginx
│
▼
Application
这里任何一层出现问题，都可能表现为：
“服务器访问不了”
所以排查云服务器网络问题时，不能只检查 Security Group。
当发现：
服务器 8080 端口访问不了
可以按照下面的顺序检查。
首先确认程序是否监听：
ss -lntp | grep 8080
确认绑定地址：
127.0.0.1:8080
只能本机访问。
通常需要：
0.0.0.0:8080
或者指定正确的服务器网卡地址。
然后检查：
Security Group
是否允许：
TCP 8080
Source: 客户端IP
再检查 Linux：
sudo nft list ruleset
或者：
sudo iptables -L -n
还需要根据网络架构检查：
VPC Route
Subnet
Public IP
NAT
Network ACL
Load Balancer
因此，“端口不通”实际上可能发生在：
Application
↑
OS Firewall
↑
Security Group
↑
VPC / Route / ACL
↑
Cloud Network
↑
Internet
任何一个位置。
可以把整个概念浓缩成下面这张逻辑图：
用户
│
Web Console / API
│
▼
┌─────────────┐
│Control Plane│
│ │
│VPC │
│Route │
│SG Rules │
└──────┬──────┘
│
下发策略
│
▼
┌─────────────┐
│ Data Plane │
│ │
│网络转发 │
│安全策略执行 │
│虚拟网络 │
└──────┬──────┘
│
▼
Virtual NIC
│
▼
┌──────────────┐
│ EC2 / ECS │
│ │
│ OS Firewall │
│ ↓ │
│ Application │
└──────────────┘
所以，AWS Security Group 安全组最核心的理解是：
安全组不是安装在 EC2/ECS 操作系统里的防火墙软件，也不是简单部署在 VPC 入口的一台虚拟防火墙服务器，而是由云平台提供并在虚拟网络基础设施中执行的分布式网络访问控制机制。
用户通过控制台、CLI 或 API 声明：
谁可以访问
+
使用什么协议
+
访问什么端口
+
允许哪些方向的流量
云平台的控制平面负责管理和分发这些策略，数据平面负责在真实网络流量经过时执行这些策略。
所谓：
“给服务器端口添加 IP 白名单”
本质就是：
指定 Source / Destination
+
指定 Protocol
+
指定 Port
↓
建立允许访问的安全组规则
↓
云网络数据平面执行规则
↓
允许或丢弃数据包
这也是理解 AWS 以及其他公有云网络安全机制的基础。
iThome鐵人賽
看影片追技術