1. VPC和子网：安全边界的起点
VPC是用户自行定义的逻辑虚拟网络。如果与本地环境类比，它类似于在AWS中创建公司的内部网络。
然而，仅仅创建一个VPC并不能完成安全。重要的是如何划分VPC内部。
最基本的方法是分离公共子网和私有子网。
公共子网
公共子网是具有指向互联网网关路由的子网。
通常，以下资源位于其中：
- ALB
- 堡垒主机（Bastion Host）
- NAT网关（NAT Gateway）
- 一些需要直接外部访问的服务
私有子网
私有子网是配置为无法从互联网直接访问的子网。
通常，以下资源位于其中：
- 应用服务器
- 数据库
- 内部API服务器
- EKS节点
- ECS服务
- ElastiCache
- OpenSearch
从安全角度来看，重要的原则很简单。
只有需要直接暴露在外部的资源才应放置在公共子网中，其余的应尽可能放置在私有子网中。
特别是数据库，在大多数情况下不需要放置在公共子网中。
实践中最常见的错误是“只是为了测试，暂时开放为公共”。问题是，这种设置常常会一直保留到生产环境。
VPC安全始于正确设计资源放置位置，而不是复杂的安全设备。
2. 路由表：控制流量移动路径的功能
在VPC中，路由表决定了流量的去向。
即使子网看起来是私有的，如果其路由表中有指向互联网网关的默认路由，它就会变成一个可以进行外部通信的结构。
例如，如果存在以下路由，则该子网具有公共性质。
0.0.0.0/0 -> Internet Gateway相反，私有子网的典型路由如下：
0.0.0.0/0 -> NAT Gateway在这种情况下，私有子网中的实例可以访问互联网，但互联网无法直接连接到这些实例。
也就是说，可以进行补丁下载、软件包安装和外部API调用，但外部用户无法直接连接到服务器。
路由表可能不被视为安全功能，因为它不像安全组或网络ACL那样显示为“允许/拒绝规则”。但实际上，它是VPC安全中非常重要的功能。
错误的路由可能会将内部网络暴露给外部。
进行VPC安全检查时，必须确认以下项目：
- 数据库子网是否有互联网网关路由？
- 内部应用子网是否不必要地直接连接到互联网？
- 通过NAT网关的出站流量是否受到控制？
- 是否通过Transit Gateway、VPC Peering或VPN连接创建了意外的网络路径？
进行VPC安全检查时，不仅要查看安全组，还要同时查看路由表。
实际的攻击路径是在“允许的端口”和“开放的路由”结合时形成的。
3. 安全组：资源级别的虚拟防火墙
安全组是VPC安全中最常用的功能。
它连接到EC2、RDS、ALB、ENI、VPC Endpoint等多种资源，用于控制入站和出站流量。
安全组的核心特点是其有状态性。
例如，如果一个EC2实例向外部发送HTTPS请求，即使入站规则中没有单独明确指定，其响应流量也会被允许。
反之，从外部进入EC2的流量必须在入站规则中被允许。
危险的安全组示例
以下设置在生产环境中非常危险。
SSH 22번 포트 0.0.0.0/0 허용
RDP 3389번 포트 0.0.0.0/0 허용
MySQL 3306번 포트 0.0.0.0/0 허용
모든 아웃바운드 0.0.0.0/0 허용虽然在测试环境中常见，但在生产环境中却非常危险。
特别是将SSH和RDP开放给整个互联网，可能成为暴力破解攻击、弱账户攻击和暴露密钥滥用的目标。
推荐的安全组设计
好的做法是根据源IP或其他安全组进行限制。
例如，ALB安全组可以允许80和443端口对互联网开放。
但应用服务器安全组应只允许来自ALB安全组的流量，而不是互联网。
RDS安全组只需允许来自应用服务器安全组的3306或5432端口流量。
一般流程如下：
사용자 -> ALB -> 애플리케이션 서버 -> 데이터베이스此时，数据库既不需要直接知道用户的IP，也不需要暴露在互联网上。
它只需要接收来自应用服务器的流量。
安全组不仅仅是开放端口的功能。
安全组是在网络层面表达应用层之间信任关系的功能。
4. 网络ACL：子网级别的辅助防线
网络ACL（NACL）是子网级别的访问控制功能。
安全组是资源级别的，而网络ACL则在子网边界控制流量。
安全组和网络ACL有以下区别：
| 类别 | 安全组 | 网络ACL |
| 应用单位 | 资源或ENI | 子网 |
| 操作方式 | 有状态 | 无状态 |
| 规则类型 | 允许规则 | 允许和拒绝规则 |
| 主要目的 | 资源级别控制 | 子网级别辅助控制 |
无状态方式意味着请求和响应被视为独立的。
例如，即使允许入站80端口，如果出站响应流量未被允许，通信也可能失败。
网络ACL更适合于子网级别的广泛控制，而不是细粒度的应用控制。
例如，可以在整个子网中阻止特定的恶意IP范围，或者限制特定子网只能在指定端口进行通信。
然而，试图用网络ACL处理所有安全问题可能会使操作变得复杂。
在实践中，安全组通常用作主要的控制手段，而网络ACL则用作辅助防线或护栏。
5. 互联网网关和NAT网关：安全地分离互联网连接
VPC要与互联网通信，需要互联网网关（Internet Gateway）。
然而，仅仅存在互联网网关并不意味着所有资源都暴露在互联网上。
实际的互联网访问取决于以下因素：
- 是否存在公共IP
- 路由表
- 安全组
- 网络ACL
- 互联网网关连接状态
公共子网中的资源可以通过互联网网关直接与外部通信。
相反，私有子网中的资源通常通过NAT网关访问互联网。
NAT网关允许私有子网资源出站到互联网，但阻止外部互联网直接发起连接到私有实例。
这种结构非常重要。
例如，应用服务器可能需要互联网访问来进行操作系统更新或外部API调用。
但互联网用户不需要直接访问应用服务器。
此时，使用NAT网关可以创建以下结构：
프라이빗 서버 -> NAT Gateway -> Internet Gateway -> 인터넷也就是说，它是一个允许出站通信但阻止直接入站连接的结构。
然而，仅凭NAT网关并不能实现完全的安全。
NAT网关本质上不是一个能够细致检查出站流量或按域名阻止流量的安全设备。
因此，在重要环境中，建议与以下功能一起设计：
- AWS网络防火墙（AWS Network Firewall）
- 代理服务器
- Route 53 Resolver DNS防火墙
- 出站过滤（egress filtering）
- VPC流日志（VPC Flow Logs）
6. VPC Endpoint和PrivateLink：通过私有网络访问AWS服务
许多AWS服务通过公共端点访问。
例如，可以考虑EC2访问S3、ECS获取ECR镜像或应用程序调用Secrets Manager的情况。
在对安全性要求高的环境中，最好尽可能不通过互联网，而是通过AWS内部网络路径访问AWS服务。
此时使用的功能是VPC Endpoint。
VPC Endpoint主要分为两种类型：
网关端点（Gateway Endpoint）
网关端点主要用于以下服务：
- Amazon S3
- Amazon DynamoDB
使用网关端点，无需单独的互联网网关或NAT网关，即可从VPC内部访问S3和DynamoDB。
接口端点（Interface Endpoint）
接口端点基于AWS PrivateLink运行，允许通过私有IP访问AWS服务。
主要可用于以下服务：
- AWS Systems Manager
- AWS Secrets Manager
- Amazon ECR
- Amazon CloudWatch Logs
- AWS STS
- AWS KMS
- Amazon ECS
- Amazon EKS相关的一些服务
VPC Endpoint在安全方面具有显著优势：
- 可以减少互联网路径。
- 可以减少对NAT网关的依赖。
- 可以通过端点策略限制可访问的操作。
- S3存储桶策略可以只允许通过特定VPC Endpoint的请求。
- 即使凭证被外部窃取，也可以限制访问路径。
例如，可以创建以下安全策略：
此S3存储桶只能通过我们VPC中的特定VPC Endpoint访问。
这样，即使凭证被窃取，也难以从外部互联网直接访问S3。
VPC Endpoint不仅仅是出于成本节约的目的。它实际上是减少数据泄露路径的强大安全设计要素。
7. AWS网络防火墙：VPC级别的托管防火墙
虽然安全组和网络ACL对于基本的网络控制非常有用，但对于高级安全检查存在局限性。
例如，如果存在以下需求，可以考虑AWS网络防火墙：
- 基于域名的过滤
- 有状态流量检查
- 入侵检测和防御
- 集中式出站控制
- 阻止可疑的外部通信
- VPC间流量检查
AWS网络防火墙是一种可应用于VPC的托管网络防火墙服务。
它提供有状态防火墙功能和入侵检测与防御功能，可用于过滤来自互联网网关、NAT网关、VPN和Direct Connect路径的流量。
在实践中，它主要用于出站流量控制。
许多企业对入站安全敏感，但对出站安全相对宽松。
然而，在发生入侵事件后，恶意软件与外部C2服务器通信或内部数据泄露的方向通常是出站的。
因此，对于重要的VPC，应考虑以下策略：
- 将私有子网的所有互联网出站流量通过网络防火墙。
- 只允许与已批准的域名或IP范围进行外部通信。
- 阻止可疑协议或异常端口。
- 将防火墙日志收集到CloudWatch Logs、S3、Security Lake等。
网络防火墙不仅仅是“昂贵的防火墙”。
它可以被视为VPC出站控制和集中安全策略实施的核心功能。
8. VPC流日志：记录网络流量的基本可见性功能
安全中最危险的状态是“不知道发生了什么”。
如果在VPC中无法知道哪个IP与哪个IP通信，哪个端口被允许，或者哪个流量被拒绝，那么事故响应将变得非常困难。
VPC流日志是一种在VPC、子网和网络接口级别收集IP流量信息的功能。
收集到的日志可以发送到以下目标：
- Amazon CloudWatch Logs
- Amazon S3
- Amazon Data Firehose
利用流日志可以进行以下分析：
- 确认特定EC2是否与外部陌生IP通信
- 确认被安全组或网络ACL拒绝的流量
- 分析未使用的端口是否持续被调用
- 确认是否存在直接访问数据库的尝试
- 了解通过NAT网关的出站流量流向
- 在发生入侵事件时追踪攻击者的移动路径
但是，流日志不存储数据包的完整内容。
也就是说，它不显示HTTP正文或文件内容。
相反，它提供以下流量信息：
- 源IP
- 目的IP
- 源端口
- 目的端口
- 协议
- 允许或拒绝状态
- 字节数
- 数据包数
- 时间信息
因此，流日志更像是“网络出入记录簿”，而不是“网络CCTV”。
它记录了谁去了哪里，从哪个门出去。
在生产环境中，建议至少在重要的VPC或重要子网中启用流日志。
特别是从安全角度来看，不仅要查看ACCEPT日志，还要同时分析REJECT日志。
被拒绝的流量可能是攻击尝试、错误配置或应用程序故障的线索。
9. 流量镜像：当需要进行数据包级别分析时
VPC流日志提供网络流量信息，而流量镜像（Traffic Mirroring）则是一种将实际流量副本传输到安全分析设备的功能。
例如，可以复制特定EC2实例的ENI产生的流量，并发送到以下系统：
- IDS（入侵检测系统）
- NDR（网络检测与响应）
- 数据包分析系统
- 取证设备
- 安全监控设备
流量镜像对于安全事件分析、入侵检测、合规性以及网络故障排除非常有用。
但是，它并非所有环境都必需的功能。
在一般的Web服务运营中，流日志和应用日志通常就足够了。
但在以下环境中可能会很有用：
- 金融机构或安全监控至关重要的环境
- 需要数据包级别入侵检测的环境
- 执行零信任网络分析的环境
- 在发生入侵事件时需要详细分析特定服务器流量的环境
需要注意的是，由于流量镜像是一种流量复制功能，因此必须同时考虑成本、性能、隐私保护和存储策略。
建议选择性地镜像关键区域的流量，而不是盲目复制所有流量。
10. 可达性分析器：验证实际连接路径的功能
VPC安全设置涉及多个相互作用的元素。
由于以下元素的组合，人工目视检查可能会出现遗漏：
- 安全组
- 网络ACL
- 路由表
- NAT网关
- 互联网网关
- Transit Gateway
- 负载均衡器
- 网络防火墙
- VPC Endpoint
可达性分析器（Reachability Analyzer）是一种分析特定源到目标在网络上是否可达的工具。
例如，它可以回答以下问题：
- 此EC2是否可以访问RDS的3306端口？
- 互联网是否可以到达此ENI？
- 堡垒主机是否可以SSH到内部服务器？
- 是否只有应用服务器可以访问RDS？
- 特定子网是否存在通往外部互联网的路径？
如果可达，它会逐步显示路径；如果不可达，它会指出是哪个组件阻止了连接。
在实践中，可达性分析器不仅适用于故障分析，对于安全验证也极其有用。
在生产环境中进行重要更改前后使用可达性分析器，可以帮助评估网络更改对安全的影响。
11. 网络访问分析器：查找意外的网络访问
如果说可达性分析器是检查特定源和目标之间连接可能性的工具，那么网络访问分析器（Network Access Analyzer）则是从更广阔的视角查找意外网络访问路径的功能。
例如，它可以执行以下基于范围的分析：
- 是否存在可从互联网访问的网络接口？
- 是否存在从特定VPC外部访问内部资源的路径？
- 是否存在意外的VPC Peering路径？
- 是否存在从外部网络访问数据库层的路径？
由于人工逐一检查所有资源组合很困难，因此通过静态分析方式查找网络路径的功能对于安全审计非常有用。
特别是在运营多个账户、多个VPC和多个子网的组织中，例外设置会随着时间积累。
典型的例子包括：
- 最初为测试目的开放的端口
- 临时创建的VPC Peering连接
- 未删除的安全组规则
- 操作移交后遗留的公共访问路径
- 不必要地宽泛的CIDR允许
- 临时VPN连接
- 不必要地保留的Transit Gateway路由
这些设置通常只存在于实际环境中，而不会记录在文档中。
网络访问分析器有助于发现这些隐藏的访问路径。
VPC安全并非一次性配置完成的工作。
它需要定期验证“我们的网络目前是否只按预期开放？”
12. DNS安全和基于Route 53 Resolver的控制
在网络安全中，仅关注IP和端口是不够的。
实际的恶意软件或内部系统通常通过域名与外部通信。
因此，控制和记录DNS请求也很重要。
在AWS环境中，可以利用以下功能：
- Route 53 Resolver查询日志
- Route 53 Resolver DNS防火墙
- 网络防火墙
- 基于代理的域名控制
例如，如果内部EC2突然查询可疑域名，则可能怀疑是恶意软件感染或数据泄露尝试。
还可以阻止访问公司内部策略不允许的域名。
DNS安全尤其与出站安全密切相关。
仅仅在安全组中开放443端口，并不能知道正在访问哪些域名。
结合使用网络防火墙、代理、DNS防火墙和Resolver查询日志，可以更好地理解和控制外部通信。
13. VPC安全实践设计示例
让我们考虑一个安全配置良好的典型三层Web服务架构。
公共子网
公共子网中只放置需要直接与外部连接的资源。
- ALB
- NAT网关
- 堡垒主机或Session Manager替代配置
私有应用子网
私有应用子网中放置实际的应用工作负载。
- EC2
- ECS服务
- EKS工作节点
- 应用服务器
- 内部API服务器
私有数据子网
私有数据子网中放置不应直接暴露在外部的数据层。
- RDS
- ElastiCache
- OpenSearch
- 内部专用数据存储
在此架构中，安全流如下：
사용자
-> ALB
-> 애플리케이션 서버
-> 데이터베이스安全设计可以按以下方式应用：
- 用户只通过ALB的443端口访问。
- ALB只通过特定端口访问应用服务器。
- 应用服务器只通过特定端口访问数据库。
- 数据库不直接暴露在互联网上。
- 私有服务器的互联网出站流量通过NAT网关或网络防火墙控制。
- S3、DynamoDB、ECR、Secrets Manager、Systems Manager的访问尽可能使用VPC Endpoint。
- VPC流日志记录网络流量。
- 可达性分析器和网络访问分析器检查意外路径。
此架构的核心不是严格阻止所有资源，而是明确开放必要的流量。
安全并非“全部阻止”。它是指只允许服务正常运行所需的路径，其余的则不开放。
14. 常见的VPC安全错误
实践中常见的VPC安全错误如下：
1. 将SSH和RDP开放给0.0.0.0/0
这是最常见也是最危险的设置。
在生产环境中，最好使用AWS Systems Manager Session Manager，或者只允许受限的VPN或公司内部IP访问。
2. 将RDS设置为公共访问
RDS在大多数情况下不需要直接暴露在互联网上。
应配置为仅允许应用服务器访问。
3. 无条件允许所有出站流量
由于默认安全组设置，生产环境中所有出站流量通常都被允许。
但对于重要系统，也应控制流量可以流向何处。
4. 不启用VPC流日志
如果发生事故后没有日志，分析将变得非常困难。
即使考虑到成本，也强烈建议在关键区域启用日志。
5. 认为VPC Endpoint不必要
依赖互联网或NAT网关访问S3、DynamoDB、ECR、Secrets Manager等服务，可能会产生不必要的外部路径和成本。
6. 仅凭安全组名称判断安全性
即使名称带有private-sg、db-sg、secure-sg等字样，如果实际规则是开放的，仍然存在风险。
应查看实际的入站和出站规则，而不仅仅是名称。
15. VPC安全检查清单
在生产环境中检查VPC时，最好核对以下项目：
[ ] 퍼블릭 서브넷과 프라이빗 서브넷이 명확히 분리되어 있는가?
[ ] 데이터베이스가 퍼블릭 서브넷에 있지 않은가?
[ ] 라우트 테이블에 불필요한 0.0.0.0/0 경로가 없는가?
[ ] SSH, RDP가 전체 인터넷에 열려 있지 않은가?
[ ] 보안 그룹이 다른 보안 그룹을 참조하도록 설계되어 있는가?
[ ] Network ACL이 의도치 않게 너무 넓게 열려 있거나 너무 강하게 막혀 있지 않은가?
[ ] 프라이빗 리소스의 AWS 서비스 접근에 VPC Endpoint를 사용하고 있는가?
[ ] S3 버킷 정책에서 특정 VPC Endpoint 조건을 사용할 수 있는가?
[ ] VPC Flow Logs가 활성화되어 있는가?
[ ] Flow Logs가 S3 또는 CloudWatch Logs로 적절히 저장되고 있는가?
[ ] Network Firewall 또는 egress filtering이 필요한 환경인가?
[ ] Reachability Analyzer로 주요 경로를 검증했는가?
[ ] Network Access Analyzer로 의도하지 않은 인터넷 노출 경로를 점검했는가?
[ ] Transit Gateway, VPC Peering, VPN 연결로 인해 내부망이 과도하게 연결되어 있지 않은가?
[ ] 보안 그룹과 라우트 테이블 변경 이력이 관리되고 있는가?从这份清单可以看出，VPC安全并非由单一功能完成。
它必须通过组合多个功能进行分层配置。
16. VPC安全一览
VPC安全功能按角色总结如下：
| 领域 | 主要功能 | 安全目的 |
|---|---|---|
| 网络隔离 | VPC, 子网 | 公共/私有区域分离 |
| 路径控制 | 路由表 | 控制流量移动路径 |
| 资源防火墙 | 安全组 | 实例、数据库、ALB单位访问控制 |
| 子网防火墙 | 网络ACL | 子网单位允许/拒绝 |
| 互联网连接 | 互联网网关，NAT网关 | 外部连接结构分离 |
| 私有AWS服务连接 | VPC Endpoint, PrivateLink | 不通过互联网访问AWS服务 |
| 高级防火墙 | AWS Network Firewall | 出站控制，IDS/IPS，域名过滤 |
| 流日志 | VPC Flow Logs | 网络通信记录 |
| 数据包分析 | Traffic Mirroring | 数据包级别安全分析 |
| 路径验证 | Reachability Analyzer | 验证特定路径的可达性 |
| 暴露分析 | Network Access Analyzer | 检测意外访问路径 |
| DNS安全 | Route 53 Resolver Query Logs, DNS Firewall | 基于域名的通信记录和阻止 |
—
总结：VPC安全是“架构设计”
AWS VPC安全不仅仅是编写防火墙规则的工作。
它是设计网络架构的工作。
您必须划分公共和私有区域，控制路由，使用安全组限制资源间的通信，使用网络ACL创建子网级别的辅助防线，使用VPC Endpoint减少互联网路径，使用网络防火墙执行高级流量控制，通过流日志和流量镜像获得可见性，并使用可达性分析器和网络访问分析器验证意外路径。
良好的VPC安全设计可能看起来复杂，但原则很简单：
- 最小化暴露在外部的内容。
- 内部通信只允许必要的对象之间进行。
- 控制通往互联网的路径。
- 记录所有重要的流量流。
- 定期验证设置是否按预期工作。
在云中，只需点击几下即可开放网络。
因此，安全事件也可能从几次点击开始。
反过来说，如果正确理解和组合VPC安全功能，可以提前预防许多事故。
AWS安全的第一个防线不仅仅是IAM。
安全设计的VPC也是一个非常强大的第一道防线。
参考文献
- AWS VPC Security
- Security groups for your VPC
- Control traffic to subnets using Network ACLs
- VPC Flow Logs
- AWS PrivateLink and VPC endpoints
- AWS Network Firewall
- Reachability Analyzer
- Network Access Analyzer
发表回复