# aws-secure-cloud-infrastructure
AWS 云基础设施实验室，专注于安全工程、基础设施审计、身份访问管理（IAM）风险缓解以及自动化漏洞检测。
# 识别、审计和修复 AWS 基础设施中的安全风险
## 📌 项目概述
本项目模拟了企业级云工程生命周期：将安全的开发环境转变为易受攻击的状态以模拟现实世界中的风险；充当独立的安全审计员来检测并记录这些缺陷；以及执行符合行业标准的修复计划。它还演示了与 AWS Well-Architected Framework 保持一致的主动运营监控和成本优化实践。
### 🛠️ 使用的服务
* **计算：** Amazon EC2, Amazon EBS
* **存储：** Amazon S3
* **身份与治理：** AWS IAM, IAM Access Analyzer
* **监控与可观测性：** Amazon CloudWatch, CloudWatch Logs Agent
## 🗺️ 架构蓝图
下图展示了在本项目中建模的双状态基础设施配置，展示了从故意设置的漏洞到经过审计的安全基线的演进过程。
Figure 0: Comprehensive Project Architecture Blueprint showing Vulnerable vs. Remediated States.
---
## 🚀 阶段 1：环境基线与监控设置
为了建立运营基线，我们配置了一台安全的虚拟服务器（`dev-web-app-node`），并附加了 EBS 块存储卷。管理 SSH 访问权限被严格锁定，仅允许工程师的部署 IP 地址访问。
为了捕获主机级的运营数据，在实例内部配置了 Amazon CloudWatch logs agent，以将实时应用程序日志直接流式传输到集中的 CloudWatch 存储库中。
Figure 1: Initial secure infrastructure state restricting port 22 access.
Figure 2: CloudWatch console confirming active log stream from the agent.
### 🚨 运营故障模拟
实施了 CloudWatch 指标警报以跟踪后端应用程序的稳定性。为了测试监控的可靠性和事件响应机制，通过在后端 Web 服务器进程上执行 `pkill gunicorn` 命令故意触发了一次运营故障，由于突发的性能和延迟峰值导致了故意的警报触发。
Figure 3: Configuration of the CloudWatch metric alarm threshold.
Figure 4: CloudWatch console displaying an active 'ALARM' state post-incident.
Figure 4b: CloudWatch Metric Graph illustrating the application latency spike during simulated server failure.
---
## 💥 阶段 2：模拟生产安全风险
为了模拟企业云部署中常见的配置漂移和开发人员错误，环境中故意设计了五种不同的安全缺陷：
1. **S3 数据暴露：** `dev-application-assets` 的存储桶策略被更改为授予匿名全局访问权限（`"Principal": "*"`）。
2. **网络暴露：** EC2 Security Group 规则从单一可信 IP 扩展为允许来自互联网上任何位置（`0.0.0.0/0`）的入站 SSH 流量。
3. **身份风险（凭证蔓延）：** 为单个身份生成了多个活跃的、不受监控的 AWS 编程访问 Access Keys，成倍增加了凭证泄露的攻击面。
4. **身份风险（通配符策略）：** 应用了自定义的 IAM 策略（`OverlyBroadDevPolicy`），其中包含完全的管理员权限（`"Action": "*", "Resource": "*"`）。
Figure 5: Bucket policy open to global anonymous traffic.
Figure 6: Firewall rules modified to expose Port 22 to the public internet.
## 🔍 阶段 3：安全审查与配置审计
切换到独立的安全审计员角色，部署自动化治理工具和手动检查方法，以发现和分类在阶段 2 中创建的漏洞。
### 🤖 自动化分析（AWS IAM Access Analyzer）
激活了 AWS IAM Access Analyzer，以对整个区域内的资源权限进行数学评估。分析器成功扫描了环境，提出了有关公开暴露的存储基础设施的直接的高严重性发现。
Figure 7: Automated Access Analyzer findings highlighting public resource exposures.
### 🕵️♂️ 手动取证收集
为正式的安全评估报告汇编取证证据，需要直接从控制平面验证实时的生产风险状态：
Figure 8: Forensic audit confirming unmitigated SSH access from 0.0.0.0/0 on the active instance.
Figure 9: Verification of multiple active, unused AWS Access Keys linked to a single developer identity.
Figure 10: JSON view of the dangerous wildcard policy highlighting AWS native policy warning indicators.
## ⚠️ 瓶颈、边缘情况与运营陷阱
### 1. CloudWatch Log Agent 日志缓冲延迟
CloudWatch log agent 在由 `buffer_duration` 等参数调节的批处理和轮询周期上运行。在高吞吐量的生产工作负载中，日志生成的突然激增可能会导致处理延迟，或导致 EC2 主机上的本地 CPU 消耗激增。生产部署需要配置显式的文件轮转设置（`logrotate`），以保护磁盘容量在流式传输瓶颈期间不被填满。
### 2. IAM Access Analyzer 一致性窗口
Access Analyzer 会持续扫描基于资源的参数；然而，在用户保存不安全的策略与发现结果显示在集中式仪表板上之间存在轻微的传播延迟。安全运营不应仅依赖于异步扫描；它们必须集成内联的预提交验证或 CI/CD linting 规则，以在部署前阻止配置错误。
### 3. 账户级 S3 Block Public Access 约束
如果 AWS 账户在账户级别启用了全局 *S3 Block Public Access* 功能，则默认情况下，包含匿名公共 `"Principal": "*"` 字符串的单个存储桶策略将被覆盖并失效。要真实地模拟此风险，需要先明确禁用账户级安全防护栏——这突显了集中式云治理控制对于分布式工程运营的关键性。
## 💰 阶段 4：成本优化与资源生命周期
为了符合 AWS Well-Architected Framework 的成本优化支柱，执行了严格的资源回收工作流，以清理遗留资产、防止“僵尸资源”收费并控制云预算蔓延：
* **计算停用：** 干净地终止了空闲的 EC2 虚拟服务器，立即停止了计算运行时的每小时计费。
* **存储回收：** 分离并删除了关联的 EBS 块存储卷，以消除持续的每月每 GB 存储费用。目标 S3 存储桶已被彻底清除并删除，确保零滞留数据成本。
* **身份清理：** 完全废弃了不受监控的重复 Access Keys 和宽泛的 IAM 策略绑定，以减少管理开销和跟踪蔓延。