MacUchegit/AWS-Network-Threat-Monitoring-and-Incident-Response-Lab
GitHub: MacUchegit/AWS-Network-Threat-Monitoring-and-Incident-Response-Lab
该项目构建了一个双 VPC 的 AWS 网络威胁监控与事件响应实验室，通过 VPC Flow Logs、CloudWatch 和 CloudTrail 实现生产环境的网络流量监控、威胁检测、告警通知和安全审计。
Stars: 0 | Forks: 0
# AWS-Network-Threat-Monitoring-and-Incident-Response-Lab
**由 Onyekwere McDonald 编写的云安全实操项目**
本项目记录了我如何为一家虚构的支付公司 **Northstar Payments** 设计、构建、测试和调查网络威胁监控环境。该实验室将公共的安全运维主机与私有生产工作负载分离开来，记录到达生产服务器的流量，检测可疑的网络行为，并支持实际的 incident-response 流程。
该项目建于 `eu-west-2`，使用的是模拟数据和我自己拥有的基础设施。未使用任何真实的客户信息、恶意软件或第三方系统。
## 项目概览
| 项目 | 详情 |
|---|---|
| 业务问题 | 生产工作负载具有预防性控制措施，但安全团队缺乏关于接受流量、拒绝流量、探测、异常传输和安全组变更的集中证据。 |
| 我的角色 | 初级云安全工程师，负责设计、实施、测试、调查、遏制、恢复和编写文档。 |
| 生产资产 | 运行模拟内部支付服务的私有 Amazon EC2 实例，端口为 TCP 8080。 |
| 管理路径 | 通过 EC2 Instance Connect 连接到公共分析主机，然后使用临时密钥通过跨 VPC peering 的 SSH 连接到生产私有 IP。 |
| 主要遥测数据 | 在生产网络接口上启用 VPC Flow Logs 并传送到 Amazon CloudWatch Logs。 |
| 检测路径 | CloudWatch Logs Insights、拒绝数据包指标过滤器、CloudWatch 告警、仪表板和 Amazon SNS 电子邮件通知。 |
| 变更证据 | 用于安全组 API 活动的 AWS CloudTrail Event History。 |
| 测试场景 | 拒绝连接激增、受控端口扫描、异常大的内部传输、不安全的安全组规则以及路由故障。 |
## 招聘人员摘要
我构建了一个双 VPC 的 AWS 安全监控实验室，它将生产服务器保持在私有状态，同时为分析师提供受控的管理路径。我应用了最小权限安全组规则，使用了 IAM role 和临时的 EC2 Instance Connect 密钥（而不是存储的访问密钥），将生产 ENI Flow Logs 集中在 CloudWatch 中，为拒绝的流量创建了查询和告警，构建了监控仪表板，并调查了五个受控的安全场景。我还诊断了一个真实的 IAM 授权失败，使用资源范围的策略对其进行了修复，并记录了完整的恢复过程。
## 我的实施内容
- 专用的 **Security Operations VPC**，包含公共分析师子网、Internet Gateway 和路由表。
- 独立的 **Production VPC**，包含私有应用子网，无 Internet Gateway，且工作负载上没有公共 IPv4 地址。
- 具有显式双向路由的 **VPC peering**，用于私有通信。
- **在处于同一 Region 的活动 peering 连接中引用安全组**，将生产访问权限限制为分析师安全组。
- 两台 Amazon Linux 2023 EC2 实例：`ec2-secops-analyst` 和 `ec2-prod-payment-app`。
- 用于分析主机的基于浏览器的 EC2 Instance Connect，以及用于短暂访问生产主机的 `SendSSHPublicKey`。
- 一个 EC2 IAM role，允许分析主机仅将临时 SSH 密钥推送到生产实例上的 `ec2-user` 账户。
- 一个生产 ENI Flow Log，将 `ACCEPT` 和 `REJECT` 元数据发送到 CloudWatch Logs。
- 用于基准流量、拒绝源、目标端口、探测和大容量传输的 CloudWatch Logs Insights 查询。
- 一个指标过滤器，将拒绝的数据包值转换为自定义的 `RejectedPackets` 指标。
- 一个 CloudWatch 告警，当被拒绝的数据包超过测试阈值时，通知 SNS 电子邮件订阅者。
- 一个 CloudWatch 仪表板，用于监控流量、端口、源、传输量、告警状态和实例健康状态。
- 针对 `AuthorizeSecurityGroupIngress` 活动的 CloudTrail Event History 分析。
- 受控的模拟演练，随后进行分类、遏制、恢复和经验总结。
## 架构演练
1. 分析师打开一个指向 `ec2-secops-analyst` 的 EC2 Instance Connect 浏览器会话。入站 SSH 仅限于 `eu-west-2` 的 AWS 托管 EC2 Instance Connect 前缀列表。
2. `NorthstarSecOpsAnalystRole` 向分析师实例提供临时的 AWS 凭证。服务器上不存储任何 IAM 用户访问密钥。
3. 分析师生成一个临时 SSH 密钥，并为 `ec2-prod-payment-app` 调用 `ec2-instance-connect:SendSSHPublicKey`。该密钥在短暂的连接窗口内可用，随后 SSH 通过 VPC peering 传输到 `10.10.1.123`。
4. 生产安全组仅接受来自 `secops-analyst-sg` 的 SSH 22、应用流量 8080 和 ICMP。
5. 生产实例的主 ENI 将 VPC Flow Log 元数据发送到 CloudWatch Logs 中的 `/aws/vpc/prod-payments/flowlogs`。
6. Logs Insights 支持各项调查。指标过滤器提取被拒绝的数据包计数，告警评估该指标，SNS 发送电子邮件警报，而仪表板提供共享的监控视图。
7. CloudTrail Event History 可识别生产安全组变更的操作者、源 IP、时间、API 操作和规则详细信息。
## 使用的 AWS 资源
| 层级 | 已实施的资源 |
|---|---|
| 网络 | 2 个 VPC、2 个子网、2 个自定义路由表、1 个 Internet Gateway 和 1 个 VPC peering 连接 |
| 网络控制 | `secops-analyst-sg` 和 `prod-payment-app-sg` |
| 计算 | 2 台使用 Amazon Linux 2023 和 8 GiB gp3 根卷的 Amazon EC2 实例 |
| 安全访问 | EC2 Instance Connect 和通过 VPC peering 的私有 SSH |
| 身份 | `NorthstarSecOpsAnalystRole`、`NorthstarSecOpsEICPolicy`、`NorthstarVPCFlowLogsRole` 和 `NorthstarVPCFlowLogsPolicy` |
| 网络遥测 | 生产 ENI 上的 VPC Flow Logs |
| 监控 | CloudWatch Logs、Logs Insights、指标过滤器、自定义指标、告警和仪表板 |
| 通知 | SNS 标准主题和已确认的电子邮件订阅 |
| 审计证据 | CloudTrail Event History |
## 寻址与信任边界
| 组件 | 名称 | 地址或 CIDR | 安全目的 |
|---|---|---|---|
| SecOps VPC | `vpc-secops` | `10.20.0.0/16` | 受控管理和测试源 |
| 公共子网 | `subnet-secops-public-a` | `10.20.1.0/24` | 托管分析师实例并路由到 Internet Gateway |
| 分析师 EC2 | `ec2-secops-analyst` | `10.20.1.195` 私有 IP 以及公共 IPv4 | 批准的管理主机和受控流量生成器 |
| 生产 VPC | `vpc-prod-payments` | `10.10.0.0/16` | 隔离的工作负载边界 |
| 私有子网 | `subnet-prod-app-private-a` | `10.10.1.0/24` | 托管私有支付应用程序 |
| 生产 EC2 | `ec2-prod-payment-app` | 仅限 `10.10.1.123` 私有 IP | TCP 8080 上的模拟内部服务 |
## 安全设计决策
### 私有生产工作负载
生产 VPC 没有 Internet Gateway，并且生产实例没有公共 IPv4 地址。这消除了直接的互联网管理，并使 SecOps 路径显性化。
### 最小权限网络规则
生产安全组在处于同一 Region 的活动 peering 连接中引用 `secops-analyst-sg`。它不接受永久的 `0.0.0.0/0` SSH 规则。
| 方向 | 协议或服务 | 端口 | 源或目标 | 原因 |
|---|---|---:|---|---|
| 分析师入站 | SSH | 22 | 区域 EC2 Instance Connect 前缀列表 | 基于浏览器的 IAM 授权访问 |
| 生产入站 | SSH | 22 | `secops-analyst-sg` | 来自批准主机的管理 |
| 生产入站 | 自定义 TCP | 8080 | `secops-analyst-sg` | 内部测试应用程序 |
| 生产入站 | ICMP IPv4 | 全部 | `secops-analyst-sg` | 受控的可达性测试 |
### 临时凭证取代存储的机密
分析师 EC2 角色通过实例元数据服务提供临时凭证。该角色只能将 SSH 公钥发送到生产实例，并且策略将操作系统用户限制为 `ec2-user`。
### 聚焦的遥测
流日志记录范围仅限于生产 ENI，而不是整个 VPC。这在限制日志数量的同时，捕获了调查所需的证据。日志组设置了三天的保留期，Logs Insights 查询使用的是较窄的时间窗口。
## 威胁模型与验证计划
| 威胁或故障 | 预期证据 | 已测试的响应 |
|---|---|---|
| 重复的阻断连接尝试 | `REJECT` Flow Log 记录和拒绝数据包告警 | 确定源、目标、目标端口和数据包量 |
| 端口探测 | 单一源联系多个目标端口 | 确认实验室授权并在收集证据后停止测试 |
| 异常大的内部传输 | 字节数远高于基准的已接受流 | 比较方向和数量；不主张具备 payload 可见性 |
| 不安全的生产安全组规则 | CloudTrail `AuthorizeSecurityGroupIngress` 事件 | 归因变更并立即移除规则 |
| 缺失 VPC peering 路由 | 连接失败且可能在生产 ENI 处无记录 | 检查路由，恢复路由并验证恢复情况 |
## 实施与证据
下面所有的截图块都是刻意的占位符。在发布之前，请用匹配的（经过脱敏处理的）图像替换每个块。建议的图像宽度至少为 1600 像素。
### 阶段 1：构建网络基础
我创建了两个 VPC，将子网放置在同一个可用区中，仅将 Internet Gateway 附加到 SecOps VPC，并配置了独立的路由表。
### 阶段 2：配置 VPC peering 和私有路由
我创建了 `pcx-secops-to-prod`，接受了请求，并在每个路由表中添加了指向对等 CIDR 的路由。VPC peering 是不可传递的，因此仅覆盖两个直接连接的 VPC。
### 阶段 3：强制执行最小权限安全组
分析主机仅接受来自区域 EC2 Instance Connect 前缀列表的 SSH。生产主机仅接受来自分析师安全组的 SSH、TCP 8080 和 ICMP。
### 阶段 4：启动 EC2 并实施临时访问
两个实例均使用 Amazon Linux 2023 和 8 GiB gp3 根卷。分析师实例是公共的；生产实例是私有的。生产 user data 创建了一个小型 HTTP 服务，而无需下载额外的软件包。
```
#!/bin/bash
set -e
mkdir -p /opt/northstar-app
cat > /opt/northstar-app/index.html <<'EOF'
Northstar Payments
::instance/",
"Condition": {
"StringEquals": {
"ec2:osuser": "ec2-user"
}
}
},
{
"Sid": "DescribeConnectionContext",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeAvailabilityZones"
],
"Resource": "*"
}
]
}
```
在分析主机上的 EC2 Instance Connect 浏览器会话中：
```
export AWS_REGION=eu-west-2
export PROD_INSTANCE_ID=
export PROD_AZ=eu-west-2a
export PROD_IP=10.10.1.123
mkdir -p "$HOME/.ssh"
chmod 700 "$HOME/.ssh"
KEY="$HOME/.ssh/northstar-prod-eic"
ssh-keygen -t ed25519 -f "$KEY" -N ""
aws ec2-instance-connect send-ssh-public-key \
--region "$AWS_REGION" \
--instance-id "$PROD_INSTANCE_ID" \
--instance-os-user ec2-user \
--availability-zone "$PROD_AZ" \
--ssh-public-key "file://${KEY}.pub"
ssh -o StrictHostKeyChecking=accept-new -i "$KEY" ec2-user@"$PROD_IP"
```
### 阶段 5：集中生产 VPC Flow Logs
我创建了 `/aws/vpc/prod-payments/flowlogs`，设置了三天的保留期，并创建了一个由 `vpc-flow-logs.amazonaws.com` 信任的服务角色。流日志捕获生产 ENI 的所有流量，最大聚合间隔为一分钟，并采用 AWS 默认记录格式。
```
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
```
Flow Logs 交付策略使用了一个范围限定为日志组的 ARN：
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "WriteToNorthstarFlowLogGroup",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:::log-group:/aws/vpc/prod-payments/flowlogs:*"
},
{
"Sid": "DescribeCloudWatchLogs",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": "*"
}
]
}
```
### 阶段 6：建立正常流量基准
我生成了已批准的 SSH、HTTP 和 ICMP 流量，然后记录了正常的源、目的地、端口、数据包计数和字节范围。
```
fields @timestamp, srcAddr, dstAddr, srcPort, dstPort,
protocol, packets, bytes, action
| filter srcAddr = "10.20.1.195" or dstAddr = "10.20.1.195"
| sort @timestamp desc
| limit 100
```
### 阶段 7：对被拒绝的流量发出告警
我创建了 SNS 主题 `secops-network-alerts`，确认了电子邮件订阅，并配置了以下指标过滤器。
```
[version, account, interfaceId, srcAddr, dstAddr, srcPort, dstPort,
protocol, packets, bytes, startTime, endTime, action="REJECT", logStatus]
```
| 告警设置 | 值 |
|---|---|
| 指标 | `Northstar/Security / RejectedPackets` |
| 指标值 | `$packets` |
| 统计数据 | Sum |
| 周期 | 5 分钟 |
| 阈值 | 大于或等于 20 |
| 数据点 | 1 / 1 |
| 缺失数据 | 视为未违规 |
| 操作 | 通知 `secops-network-alerts` |
### 阶段 8：构建监控仪表板
`Northstar-Production-Network-Security` 仪表板回答了四个运营问题：拒绝流量是否在增加？哪个源应负责？哪些被作为目标？是否在同一时间附近发生了异常传输或配置更改？
```
# 随时间变化的拒绝数据包
filter action = "REJECT"
| stats sum(packets) as rejectedPackets by bin(5m)
# 主要拒绝来源
filter action = "REJECT"
| stats sum(packets) as rejectedPackets by srcAddr
| sort rejectedPackets desc
| limit 10
# 受目标的目的端口
filter action = "REJECT"
| stats sum(packets) as rejectedPackets by dstPort
| sort rejectedPackets desc
| limit 10
# 最大的接受传输
filter action = "ACCEPT"
| stats sum(bytes) as bytesTransferred,
sum(packets) as packetsTransferred
by srcAddr, dstAddr, dstPort
| sort bytesTransferred desc
| limit 20
```
### 阶段 9：模拟并调查安全事件
#### 场景 1：拒绝连接激增
```
export PROD_IP=10.10.1.123
for i in $(seq 1 50); do
timeout 1 bash -c "echo >/dev/tcp/$PROD_IP/3389" 2>/dev/null || true
done
```
```
fields @timestamp, srcAddr, dstAddr, srcPort, dstPort,
protocol, packets, bytes, action
| filter action = "REJECT"
| sort @timestamp desc
| limit 100
```
#### 场景 2：受控端口扫描
```
export PROD_IP=10.10.1.123
for port in 21 22 23 25 80 443 3306 3389 5432 8080; do
timeout 1 bash -c "echo >/dev/tcp/$PROD_IP/$port" 2>/dev/null || true
done
```
```
filter action = "REJECT"
| stats count_distinct(dstPort) as uniquePorts,
sum(packets) as rejectedPackets,
count(*) as flowRecords
by srcAddr, dstAddr
| filter uniquePorts >= 8
| sort uniquePorts desc
```
#### 场景 3：异常大的内部传输
我将一个无害的 1 MiB 对象与由私有应用程序提供的 20 MiB 对象进行了比较。较大的流量应该会从正常基准中突显出来。
```
sudo dd if=/dev/zero of=/opt/northstar-app/baseline-1mb.bin \
bs=1M count=1 status=none
sudo dd if=/dev/zero of=/opt/northstar-app/unusual-20mb.bin \
bs=1M count=20 status=none
```
```
curl -s -o /dev/null -w "baseline: %{size_download} bytes\n" \
"http://10.10.1.123:8080/baseline-1mb.bin"
curl -s -o /dev/null -w "unusual: %{size_download} bytes\n" \
"http://10.10.1.123:8080/unusual-20mb.bin"
```
#### 场景 4：不安全的安全组更改
我暂时在生产安全组中添加了一条来自 `0.0.0.0/0` 的入站 SSH 规则，在 CloudTrail Event History 中捕获了该事件，并立即移除了该规则。生产 VPC 仍然没有 Internet Gateway，因此该测试生成了控制平面证据，而没有创建通往私有实例的互联网路径。
#### 场景 5：路由配置错误与恢复
我暂时从 `rtb-secops-public` 中移除了 `10.10.0.0/16` peering 路由，重复了批准的 ping 和 HTTP 测试，恢复了路由并验证了恢复情况。由于数据包无法正确离开源子网，它可能永远无法到达生产 ENI。因此，缺失生产 Flow Log 记录这一事实支持了路由假设。
## 故障排除案例：EC2 Instance Connect 授权失败
第一次尝试推送临时 SSH 密钥失败，返回 `AccessDeniedException`。随后 SSH 返回 `Permission denied (publickey)`，因为密钥从未被交付。
我的故障排除将网络路径与身份问题分离开来：
1. SSH 客户端到达了生产主机并记录了其主机密钥，这表明 peering、路由、生产安全组和 TCP 22 正常工作。
2. AWS API 响应明确指出，没有基于身份的策略允许 `ec2-instance-connect:SendSSHPublicKey`。
3. 我向 `NorthstarSecOpsAnalystRole` 添加了最小权限许可，将其范围限定在生产实例 ARN，并将 `ec2:osuser` 限制为 `ec2-user`。
4. 我重试了 API 调用，并在临时密钥窗口内立即打开了 SSH。
5. 我通过角色身份、SSH、ping 和 HTTP 证据验证了最终路径。
这是项目中最有用的失败，因为它需要基于证据的诊断，而不是随意的配置更改。
## Incident-response 工作流
| 阶段 | 执行的工作 |
|---|---|
| 检测 | 查阅告警、SNS 通知和仪表板，以了解被拒绝流量的激增情况。 |
| 分流 | 在 Logs Insights 中确定源、目标、操作、端口、数据包、字节和测试时间窗口。 |
| 关联 | 当涉及安全组更改时，将网络活动与 CloudTrail Event History 进行比较。 |
| 遏制 | 停止受控流量，移除不安全的 SSH 规则，并恢复批准的路由。 |
| 恢复 | 重新运行角色身份、临时密钥 SSH、ICMP 和 HTTP 检查。 |
| 记录 | 记录发现、限制、根本原因、补救措施和预防建议。 |
## 结果
- 生产 EC2 实例保持私有，没有公共 IPv4 地址。
- 批准的管理和应用流量使用私有 IP 地址跨越了 peering 连接。
- 未获批准的流量生成了 `REJECT` Flow Log 记录。
- 被拒绝的数据包指标和告警将日志证据转化为可操作的通知路径。
- Logs Insights 识别出了目标端口、重复的被拒绝源以及异常大的已接受传输。
- CloudTrail Event History 将不安全的安全组更改归因于具体的身份和 API 操作。
- IAM 故障和路由故障得到了诊断、修复和重新测试。
- 所有测试数据均为模拟，并且每个不安全的更改都是暂时的并被还原。
## 重要限制
- VPC Flow Logs 记录的是元数据，而不是数据包 payload。高字节数可以指示异常的移动，但这不能证明数据泄露或揭示文件内容。
- Flow Log 交付是尽力而为的，并非即时。本实验室不是一个实时的数据包检查系统。
- CloudTrail Event History 涵盖了所选 Region 中最近的管理事件。长期的集中保留需要在此处未实施的额外设计。
- 实验室使用一个账户、一个 Region 和一个可用区。它旨在展示安全推理，而不是生产环境的高可用性。
- 选择 5 分钟内拒绝 20 个数据包的阈值是为了进行受控验证。生产阈值需要更长的基准和对工作负载的调整。
## 成本控制
- 使用了 micro EC2 实例类型和 8 GiB gp3 根卷。
- 将 Flow Logs 的范围限定在一个生产 ENI。
- 将 CloudWatch Logs 的保留期设置为三天。
- 使用了较窄的 Logs Insights 时间窗口和至少五分钟的仪表板刷新间隔。
- 避免了 NAT Gateway、AWS Network Firewall 以及其他对本实验室不必要的云服务。
- 收集证据后删除了环境。
AWS 账户优惠和定价会随时间变化。在自行复现该实验室之前，请查看您自己 Region 中每个资源的当前价格。
## 清理顺序
1. 删除 CloudWatch 告警、仪表板和指标过滤器。
2. 删除 SNS 订阅和主题。
3. 删除生产 ENI Flow Log，然后在导出任何批准的证据后删除 CloudWatch 日志组。
4. 终止两台 EC2 实例，并确认它们的根卷已被删除。
5. 分离并删除项目 IAM 角色和客户管理的策略。
6. 在实例消失后删除这两个安全组。
7. 移除 peering 路由，然后删除 VPC peering 连接。
8. 分离并删除 `igw-secops`。
9. 删除自定义路由表、子网和 VPC。
10. 检查账单和资源清单，查看是否有任何遗留内容。
## 推荐的代码库结构
```
aws-network-threat-monitoring/
├── README.md
├── architecture/
│ ├── aws-network-threat-monitoring-architecture.png
│ └── aws-network-threat-monitoring-architecture.svg
├── docs/
│ └── AWS-Network-Threat-Monitoring-Portfolio.docx
├── evidence/
│ └── screenshots/
│ ├── 01-secops-vpc.png
│ ├── ...
│ └── 40-connectivity-recovered.png
├── policies/
│ ├── analyst-eic-policy.json
│ ├── analyst-role-trust-policy.json
│ ├── flow-logs-policy.json
│ └── flow-logs-role-trust-policy.json
├── queries/
│ └── cloudwatch-logs-insights.md
└── LICENSE
```
## 展现的技能
- AWS 网络架构和分段
- VPC、子网、路由表、Internet Gateway 和 VPC peering 配置
- 安全组设计和同 Region 对等安全组引用
- Amazon EC2 和 Amazon Linux 2023 管理
- EC2 Instance Connect 和临时 SSH 访问
- IAM role、信任策略、资源范围界定和条件密钥
- VPC Flow Logs 和 CloudWatch Logs
- CloudWatch Logs Insights 查询开发
- 指标、告警、仪表板和 SNS 通知
- CloudTrail 管理事件分析
- 威胁模拟、事件分流、遏制和恢复
- 根本原因分析、技术文档、证据处理和脱敏
- 成本意识和环境清理
## 简历项目条目
**AWS Network Threat Monitoring and Incident Response Lab**
- 设计了一个双 VPC 的 AWS 安全监控环境，配备一个公共的 SecOps 分析师主机和一个通过 VPC peering 连接的私有生产工作负载。
- 使用安全组引用、EC2 Instance Connect、临时 SSH 密钥和资源范围的 IAM 权限来强制执行最小权限管理。
- 在 CloudWatch 中集中了生产 ENI Flow Logs，构建了检测查询，创建了拒绝数据包告警和 SNS 通知路径，并调查了五个受控的安全场景。
- 诊断了 IAM 授权失败和路由失败，实施了纠正措施，并通过网络、身份和应用程序证据验证了恢复情况。
## 发布前的证据处理
对 AWS 账户 ID、IAM 主体 ID、不必要的 ARN、公共 IP 地址、电子邮件地址、账单信息和控制台会话详情进行脱敏。如果有助于解释架构，私有的 RFC 1918 实验室地址可以保留，但在提交之前必须确认每个截图都是安全的。
## 技术参考
- [使用 EC2 Instance Connect 连接到 Linux 实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-methods.html)
- [EC2 Instance Connect `send-ssh-public-key` 命令](https://docs.aws.amazon.com/cli/latest/reference/ec2-instance-connect/send-ssh-public-key.html)
- [VPC peering 连接的工作原理](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html)
- [跨 peering 连接引用安全组](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html)
- [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
- [将 VPC Flow Logs 发布到 CloudWatch Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-cwl.html)
- [用于将 Flow Logs 发布到 CloudWatch Logs 的 IAM 角色](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-iam-role.html)
- [CloudTrail Event History](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)
- [AWS 架构图标](https://aws.amazon.com/architecture/icons/)
## 项目概览
| 项目 | 详情 |
|---|---|
| 业务问题 | 生产工作负载具有预防性控制措施，但安全团队缺乏关于接受流量、拒绝流量、探测、异常传输和安全组变更的集中证据。 |
| 我的角色 | 初级云安全工程师，负责设计、实施、测试、调查、遏制、恢复和编写文档。 |
| 生产资产 | 运行模拟内部支付服务的私有 Amazon EC2 实例，端口为 TCP 8080。 |
| 管理路径 | 通过 EC2 Instance Connect 连接到公共分析主机，然后使用临时密钥通过跨 VPC peering 的 SSH 连接到生产私有 IP。 |
| 主要遥测数据 | 在生产网络接口上启用 VPC Flow Logs 并传送到 Amazon CloudWatch Logs。 |
| 检测路径 | CloudWatch Logs Insights、拒绝数据包指标过滤器、CloudWatch 告警、仪表板和 Amazon SNS 电子邮件通知。 |
| 变更证据 | 用于安全组 API 活动的 AWS CloudTrail Event History。 |
| 测试场景 | 拒绝连接激增、受控端口扫描、异常大的内部传输、不安全的安全组规则以及路由故障。 |
## 招聘人员摘要
我构建了一个双 VPC 的 AWS 安全监控实验室，它将生产服务器保持在私有状态，同时为分析师提供受控的管理路径。我应用了最小权限安全组规则，使用了 IAM role 和临时的 EC2 Instance Connect 密钥（而不是存储的访问密钥），将生产 ENI Flow Logs 集中在 CloudWatch 中，为拒绝的流量创建了查询和告警，构建了监控仪表板，并调查了五个受控的安全场景。我还诊断了一个真实的 IAM 授权失败，使用资源范围的策略对其进行了修复，并记录了完整的恢复过程。
## 我的实施内容
- 专用的 **Security Operations VPC**，包含公共分析师子网、Internet Gateway 和路由表。
- 独立的 **Production VPC**，包含私有应用子网，无 Internet Gateway，且工作负载上没有公共 IPv4 地址。
- 具有显式双向路由的 **VPC peering**，用于私有通信。
- **在处于同一 Region 的活动 peering 连接中引用安全组**，将生产访问权限限制为分析师安全组。
- 两台 Amazon Linux 2023 EC2 实例：`ec2-secops-analyst` 和 `ec2-prod-payment-app`。
- 用于分析主机的基于浏览器的 EC2 Instance Connect，以及用于短暂访问生产主机的 `SendSSHPublicKey`。
- 一个 EC2 IAM role，允许分析主机仅将临时 SSH 密钥推送到生产实例上的 `ec2-user` 账户。
- 一个生产 ENI Flow Log，将 `ACCEPT` 和 `REJECT` 元数据发送到 CloudWatch Logs。
- 用于基准流量、拒绝源、目标端口、探测和大容量传输的 CloudWatch Logs Insights 查询。
- 一个指标过滤器，将拒绝的数据包值转换为自定义的 `RejectedPackets` 指标。
- 一个 CloudWatch 告警，当被拒绝的数据包超过测试阈值时，通知 SNS 电子邮件订阅者。
- 一个 CloudWatch 仪表板，用于监控流量、端口、源、传输量、告警状态和实例健康状态。
- 针对 `AuthorizeSecurityGroupIngress` 活动的 CloudTrail Event History 分析。
- 受控的模拟演练，随后进行分类、遏制、恢复和经验总结。
## 架构演练
1. 分析师打开一个指向 `ec2-secops-analyst` 的 EC2 Instance Connect 浏览器会话。入站 SSH 仅限于 `eu-west-2` 的 AWS 托管 EC2 Instance Connect 前缀列表。
2. `NorthstarSecOpsAnalystRole` 向分析师实例提供临时的 AWS 凭证。服务器上不存储任何 IAM 用户访问密钥。
3. 分析师生成一个临时 SSH 密钥，并为 `ec2-prod-payment-app` 调用 `ec2-instance-connect:SendSSHPublicKey`。该密钥在短暂的连接窗口内可用，随后 SSH 通过 VPC peering 传输到 `10.10.1.123`。
4. 生产安全组仅接受来自 `secops-analyst-sg` 的 SSH 22、应用流量 8080 和 ICMP。
5. 生产实例的主 ENI 将 VPC Flow Log 元数据发送到 CloudWatch Logs 中的 `/aws/vpc/prod-payments/flowlogs`。
6. Logs Insights 支持各项调查。指标过滤器提取被拒绝的数据包计数，告警评估该指标，SNS 发送电子邮件警报，而仪表板提供共享的监控视图。
7. CloudTrail Event History 可识别生产安全组变更的操作者、源 IP、时间、API 操作和规则详细信息。
## 使用的 AWS 资源
| 层级 | 已实施的资源 |
|---|---|
| 网络 | 2 个 VPC、2 个子网、2 个自定义路由表、1 个 Internet Gateway 和 1 个 VPC peering 连接 |
| 网络控制 | `secops-analyst-sg` 和 `prod-payment-app-sg` |
| 计算 | 2 台使用 Amazon Linux 2023 和 8 GiB gp3 根卷的 Amazon EC2 实例 |
| 安全访问 | EC2 Instance Connect 和通过 VPC peering 的私有 SSH |
| 身份 | `NorthstarSecOpsAnalystRole`、`NorthstarSecOpsEICPolicy`、`NorthstarVPCFlowLogsRole` 和 `NorthstarVPCFlowLogsPolicy` |
| 网络遥测 | 生产 ENI 上的 VPC Flow Logs |
| 监控 | CloudWatch Logs、Logs Insights、指标过滤器、自定义指标、告警和仪表板 |
| 通知 | SNS 标准主题和已确认的电子邮件订阅 |
| 审计证据 | CloudTrail Event History |
## 寻址与信任边界
| 组件 | 名称 | 地址或 CIDR | 安全目的 |
|---|---|---|---|
| SecOps VPC | `vpc-secops` | `10.20.0.0/16` | 受控管理和测试源 |
| 公共子网 | `subnet-secops-public-a` | `10.20.1.0/24` | 托管分析师实例并路由到 Internet Gateway |
| 分析师 EC2 | `ec2-secops-analyst` | `10.20.1.195` 私有 IP 以及公共 IPv4 | 批准的管理主机和受控流量生成器 |
| 生产 VPC | `vpc-prod-payments` | `10.10.0.0/16` | 隔离的工作负载边界 |
| 私有子网 | `subnet-prod-app-private-a` | `10.10.1.0/24` | 托管私有支付应用程序 |
| 生产 EC2 | `ec2-prod-payment-app` | 仅限 `10.10.1.123` 私有 IP | TCP 8080 上的模拟内部服务 |
## 安全设计决策
### 私有生产工作负载
生产 VPC 没有 Internet Gateway，并且生产实例没有公共 IPv4 地址。这消除了直接的互联网管理，并使 SecOps 路径显性化。
### 最小权限网络规则
生产安全组在处于同一 Region 的活动 peering 连接中引用 `secops-analyst-sg`。它不接受永久的 `0.0.0.0/0` SSH 规则。
| 方向 | 协议或服务 | 端口 | 源或目标 | 原因 |
|---|---|---:|---|---|
| 分析师入站 | SSH | 22 | 区域 EC2 Instance Connect 前缀列表 | 基于浏览器的 IAM 授权访问 |
| 生产入站 | SSH | 22 | `secops-analyst-sg` | 来自批准主机的管理 |
| 生产入站 | 自定义 TCP | 8080 | `secops-analyst-sg` | 内部测试应用程序 |
| 生产入站 | ICMP IPv4 | 全部 | `secops-analyst-sg` | 受控的可达性测试 |
### 临时凭证取代存储的机密
分析师 EC2 角色通过实例元数据服务提供临时凭证。该角色只能将 SSH 公钥发送到生产实例，并且策略将操作系统用户限制为 `ec2-user`。
### 聚焦的遥测
流日志记录范围仅限于生产 ENI，而不是整个 VPC。这在限制日志数量的同时，捕获了调查所需的证据。日志组设置了三天的保留期，Logs Insights 查询使用的是较窄的时间窗口。
## 威胁模型与验证计划
| 威胁或故障 | 预期证据 | 已测试的响应 |
|---|---|---|
| 重复的阻断连接尝试 | `REJECT` Flow Log 记录和拒绝数据包告警 | 确定源、目标、目标端口和数据包量 |
| 端口探测 | 单一源联系多个目标端口 | 确认实验室授权并在收集证据后停止测试 |
| 异常大的内部传输 | 字节数远高于基准的已接受流 | 比较方向和数量；不主张具备 payload 可见性 |
| 不安全的生产安全组规则 | CloudTrail `AuthorizeSecurityGroupIngress` 事件 | 归因变更并立即移除规则 |
| 缺失 VPC peering 路由 | 连接失败且可能在生产 ENI 处无记录 | 检查路由，恢复路由并验证恢复情况 |
## 实施与证据
下面所有的截图块都是刻意的占位符。在发布之前，请用匹配的（经过脱敏处理的）图像替换每个块。建议的图像宽度至少为 1600 像素。
### 阶段 1：构建网络基础
我创建了两个 VPC，将子网放置在同一个可用区中，仅将 Internet Gateway 附加到 SecOps VPC，并配置了独立的路由表。
### 阶段 2：配置 VPC peering 和私有路由
我创建了 `pcx-secops-to-prod`，接受了请求，并在每个路由表中添加了指向对等 CIDR 的路由。VPC peering 是不可传递的，因此仅覆盖两个直接连接的 VPC。
### 阶段 3：强制执行最小权限安全组
分析主机仅接受来自区域 EC2 Instance Connect 前缀列表的 SSH。生产主机仅接受来自分析师安全组的 SSH、TCP 8080 和 ICMP。
### 阶段 4：启动 EC2 并实施临时访问
两个实例均使用 Amazon Linux 2023 和 8 GiB gp3 根卷。分析师实例是公共的；生产实例是私有的。生产 user data 创建了一个小型 HTTP 服务，而无需下载额外的软件包。
```
#!/bin/bash
set -e
mkdir -p /opt/northstar-app
cat > /opt/northstar-app/index.html <<'EOF'
Northstar Payments Internal Service
Status: healthy
This server contains simulated portfolio data only.
EOF cat > /etc/systemd/system/northstar-app.service <<'EOF' [Unit] Description=Northstar Payments Python HTTP Service After=network.target [Service] Type=simple WorkingDirectory=/opt/northstar-app ExecStart=/usr/bin/python3 -m http.server 8080 --bind 0.0.0.0 Restart=on-failure [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl enable --now northstar-app.service ``` 分析师角色使用以下资源范围的权限。部署前请替换所有尖括号中的值。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "SendTemporaryKeyToProductionInstance", "Effect": "Allow", "Action": "ec2-instance-connect:SendSSHPublicKey", "Resource": "arn:aws:ec2:标签：AWS云服务, CloudWatch监控, VPC流日志, 插件系统