Aboubakr2000Cloud/ecs-weather-platform-secured

# 🔐 ECS 天气平台 – 安全加固             # 📖 项目概述 本项目是**带有监控的 ECS 天气平台**（ECS Weather Platform with Monitoring）的安全主题延续。其目标不是构建一个新的应用程序，而是利用云安全最佳实践来**加固现有的生产级 AWS 基础设施**，同时确保应用程序保持完全正常运行。 该基础设施完全使用 **Terraform** 进行配置，项目重点在于保护基础设施、凭证、secrets 和应用程序配置，而不改变应用程序的功能。 在整个项目中，引入了几种生产级的 AWS 安全服务和实践，包括： - 客户管理的 KMS 密钥 - IAM 最小权限策略 - AWS Secrets Manager 加密 - AWS Systems Manager Parameter Store - CloudTrail 审计 - 基础设施安全加固 - 使用 TruffleHog 进行 secret 扫描 - 自动化安全审计 - 在每次安全改进后进行持续验证 一个主要目标是证明实施安全改进**可以在不影响应用程序可用性的情况下**进行。在完成所有加固更改后，ECS 应用程序继续成功处理流量并保持了数据库连接。 # 🎯 项目目标 本项目的主要目标是： - 审计 IAM 用户和凭证 - 应用最小权限原则 - 使用客户管理的 KMS 密钥加密 Secrets Manager secrets - 将非敏感配置移至 Systems Manager Parameter Store - 减少 ECS Task Definition 中的硬编码配置 - 启用 CloudTrail 进行账户审计 - 加固基础设施以防范常见的安全风险 - 将 TruffleHog 集成到 CI pipeline 中 - 构建自动化的 AWS 安全审计脚本 - 验证在每次安全增强后应用程序是否继续运行 # ✨ 主要特性 ## 🔑 身份与访问管理 - IAM 凭证审计 - 访问密钥规范验证 - 最小权限 IAM 策略 - 专用的 ECS Execution Role - 专用的 ECS Task Role - 细粒度的 Secrets Manager 权限 - 细粒度的 Parameter Store 权限 ## 🔒 数据保护 - 客户管理的 AWS KMS 密钥 - 使用 CMK 加密的 secrets - 加密的 Amazon RDS 数据库 - 加密的 S3 存储桶 - 安全的 Terraform 远程状态存储桶 - 仅限 HTTPS 的存储桶策略 ## 🔐 Secrets 管理 敏感值存储在 **AWS Secrets Manager** 中 - 数据库密码 - 天气 API 密钥 非敏感配置存储在 **AWS Systems Manager Parameter Store** 中 - 数据库主机 - 数据库名称 - 数据库端口 - 数据库用户名 ECS Task Definition 中不再保留任何硬编码的应用程序配置。 ## 📋 安全监控 - 启用 CloudTrail - 启用日志文件验证 - 将 CloudTrail 日志存储在 S3 中 - 保留 CloudWatch 监控 - 加固后验证现有的警报 ## 🚀 DevSecOps GitHub Actions pipeline 增加了以下功能： - Python 测试 - Terraform 验证 - Linting - 安全扫描 - Docker 构建验证 - TruffleHog secret 扫描 # 🏗️ 高层架构 ``` flowchart TD Developer --> GitHub GitHub --> Actions[GitHub Actions CI] Actions --> TruffleHog Actions --> Terraform Terraform --> IAM[IAM Roles & Policies] Terraform --> KMS[AWS KMS] Terraform --> Secrets[Secrets Manager] Terraform --> SSM[Parameter Store] Terraform --> CloudTrail Terraform --> ECS[ECS Fargate] Terraform --> ALB[Application Load Balancer] Terraform --> RDS[Amazon RDS] Internet --> ALB ALB --> ECS ECS --> SSM ECS --> Secrets Secrets --> KMS ECS --> RDS CloudTrail --> TrailBucket[S3 CloudTrail Bucket] ECS --> CloudWatch ALB --> CloudWatch RDS --> CloudWatch CloudWatch --> Dashboard CloudWatch --> Alarms Actions --> GitHubRepo[(Repository)] ``` # 📂 仓库结构 ``` ecs-weather-platform-secured/ ├── .github/ │ └── workflows/ │ └── ci.yml │ ├── app/ │ ├── terraform/ │ ├── modules/ │ │ ├── alb/ │ │ ├── ecr/ │ │ ├── ecs/ │ │ ├── iam/ │ │ ├── monitoring/ │ │ ├── rds/ │ │ ├── security/ │ │ ├── security_groups/ │ │ └── vpc/ │ │ │ ├── backend.hcl │ ├── main.tf │ ├── variables.tf │ ├── outputs.tf │ └── iam.tf │ ├── scripts/ │ └── security-audit.sh │ ├── docker-compose.yml ├── Dockerfile ├── requirements.txt └── README.md ``` # 🛡️ 安全架构 基础设施不再将凭证或配置直接存储在应用程序内部，而是现在遵循分层安全模型。 ``` AWS KMS (Customer Managed Key) │ ▼ AWS Secrets Manager ┌───────────────────┐ │ DB_PASSWORD │ │ WEATHER_API_KEY │ └───────────────────┘ ▲ │ ECS Execution Role (Least Privilege) │ ▼ ECS Task Definition (No Hardcoded Configuration) ▲ │ AWS Systems Manager Parameter Store ┌─────────────────────────────────┐ │ DB_HOST │ │ DB_NAME │ │ DB_PORT │ │ DB_USER │ └─────────────────────────────────┘ ``` # 🔐 安全改进 与之前版本的天气平台不同，此版本侧重于在保持应用程序完全正常运行的同时保护基础设施。 每一项更改都遵循 AWS 安全最佳实践和生产建议。 # 🔑 身份与访问管理 (IAM) 项目的第一阶段是审查应用程序如何与 AWS 服务进行交互。 该基础设施遵循**最小权限原则**，这意味着每个 IAM 角色仅获得其特定职责所需的权限。 这里使用了两个专用的 ECS 角色。 ## ECS Execution Role Execution Role 由 ECS 代理承担。 职责： - 从 Amazon ECR 拉取 Docker 镜像 - 从 AWS Secrets Manager 读取 secrets - 从 AWS Systems Manager Parameter Store 读取配置 - 将应用程序日志发送到 CloudWatch Logs 权限包括： - AmazonECSTaskExecutionRolePolicy - Secrets Manager 访问权限 - Parameter Store 访问权限 ## ECS Task Role Task Role 由在容器内运行的应用程序承担。 职责： - 发布自定义 CloudWatch 指标 - 通过 AWS Systems Manager 执行 ECS Exec 会话 - 仅访问应用程序所需的 AWS 服务 这种分离防止了应用程序获得不必要的基础设施权限。 # 🔐 AWS KMS 引入了客户管理密钥 (CMK)，以替换应用程序 secret 默认的 AWS 管理加密。 该 KMS 密钥用于加密： - 数据库密码 - 天气 API 密钥 优势： - 客户控制的加密 - 密钥轮换支持 - 细粒度的 IAM 控制 - 密钥使用的 CloudTrail 审计日志 Terraform 会自动将客户管理密钥与每个 Secrets Manager secret 关联。  # 🔒 AWS Secrets Manager 敏感的应用程序值存储在 AWS Secrets Manager 中，而不是 Terraform 变量或 ECS 环境变量中。 存储的 secrets： - 数据库密码 - OpenWeather API 密钥 ECS Execution Role 在任务启动期间安全地检索这些值。 没有任何 secret 值会暴露在以下位置： - Terraform 状态变量 - Task Definition 环境变量 - 应用程序源代码  # ⚙️ AWS Systems Manager Parameter Store **非敏感的**配置值被移至 Systems Manager Parameter Store 中。 存储的参数包括： - 数据库主机 - 数据库名称 - 数据库端口 - 数据库用户名 现在，ECS Task Definition 会在 runtime 动态检索这些参数。 这完全消除了容器定义中硬编码的基础设施配置。  # 📋 ECS Task Definition 加固 在本项目之前，一些配置值被定义为环境变量。 经过安全改进后： - 敏感值来自 Secrets Manager。 - 非敏感值来自 Parameter Store。 结果： - Task Definition 中不再存储任何凭证。 - 基础设施更改需要更少的代码修改。 - 可以在不重新构建应用程序镜像的情况下更新配置。  # 🛡️ 基础设施加固 对 AWS 资源应用了额外的加固。 ## Amazon S3 已实施： - 服务器端加密 (AES-256) - 阻止公共访问 - 仅限 HTTPS 的存储桶策略 - 受保护的 Terraform 远程状态存储桶 ## Amazon RDS 数据库现在包括： - 启用存储加密 - 私有子网部署 - 无公共可访问性 加密后数据库功能保持不变。 ## AWS CloudTrail 启用 CloudTrail 以记录整个 AWS 账户的管理事件。 配置包括： - 多可用区日志传输 - 日志文件验证 - 专用的加密 S3 存储桶 CloudTrail 为基础设施更改和安全调查提供了审计跟踪。  # 🚀 CI/CD 安全 GitHub Actions pipeline 增加了额外的安全验证。 Pipeline 阶段包括： - Terraform 验证 - Python 测试 - Docker 构建验证 - 静态分析 - Secret 扫描 ## TruffleHog TruffleHog 被集成到 CI pipeline 中，以检测意外提交的 secrets。 扫描器会在每次推送时自动运行，并在 Docker 镜像验证之前执行。 使用： ``` --only-verified ``` 通过仅报告可以验证的 secrets 来减少误报。 这确保了在部署之前检测到泄露的凭证。  # 📊 自动化安全审计 创建了一个可重用的 Bash 审计脚本，用于验证基础设施的安全态势。 该脚本会自动检查： - IAM 凭证报告 - 暴露 0.0.0.0/0 的安全组 - S3 公共访问配置 - 存储桶加密 - RDS 加密 - CloudTrail 状态 在加固过程前后均执行了审计，以展示可衡量的安全改进。 ## 审计结果 初始审计突出了需要改进的地方，包括缺少加密、存储桶保护不完整以及缺乏集中的审计日志记录。 完成项目后，审计确认了： - ✓ RDS 存储加密已启用 - ✓ CloudTrail 日志记录已启用 - ✓ S3 存储桶加密已配置 - ✓ 受保护存储桶已启用公共访问阻止 - ✓ 客户管理的 KMS 密钥保护 Secrets Manager - ✓ ECS Task Definition 使用 Secrets Manager 和 Parameter Store  # ✅ 安全验证 部署后，通过 AWS CLI 验证了每个主要的安全控制。 验证包括： - 保护 Secrets Manager 的客户管理的 KMS 密钥 - Parameter Store 配置检索 - RDS 存储加密 - 启用 CloudTrail 日志记录 - S3 存储桶加密 - 公共访问阻止配置 - ECS Task Definition 使用 Secrets Manager 和 Parameter Store - 应用程序健康 endpoint 保持运行 基础设施在采用显著更强的安全控制的同时，保持了完全正常运行。 # ⚙️ 工程历程 本项目不仅仅是启用 AWS 安全功能。它需要将安全控制集成到已经可以正常运行的云应用程序中，且不能破坏部署、应用程序可用性或 CI/CD pipeline。 在整个实施过程中，遇到了几个生产环境中的实际挑战，需要进行调查、故障排除和迭代改进。 # 🧩 挑战与解决方案 ## 挑战 1 — 应用最小权限 ### 问题 最初的 ECS 基础设施已经包含了以前项目中的 IAM 角色。确定哪些权限属于 Execution Role，哪些属于 Task Role，需要审查现有策略并了解 ECS 如何与 AWS 服务交互。 ### 解决方案 将职责划分为专用的 IAM 角色。 Execution Role： - 从 ECR 拉取镜像 - 读取 Secrets Manager - 读取 Parameter Store - 写入 CloudWatch Logs Task Role： - ECS Exec - 自定义 CloudWatch 指标 这产生了一个更加清晰的安全模型，同时遵循了 AWS 最小权限建议。 ## 挑战 2 — Secrets 与 Parameter Store 的对比 ### 问题 最初，几个数据库配置值作为环境变量硬编码在 ECS Task Definition 中。 虽然可行，但这种方法对于生产环境来说并不理想。 ### 解决方案 将配置分为两类。 敏感值： - 数据库密码 - 天气 API 密钥 存储在 AWS Secrets Manager 中。 非敏感值： - 数据库主机 - 数据库名称 - 数据库端口 - 数据库用户名 存储在 Systems Manager Parameter Store 中。 现在，ECS Task Definition 会动态检索每一个值。 ## 挑战 3 — Terraform 模块依赖 ### 问题 一些安全资源需要其他模块生成的信息。 Terraform 模块不能直接相互引用。 ### 解决方案 通过根模块将输出从一个模块中暴露出来，并传递到另一个模块中。 这保持了模块的独立性，同时使基础设施保持模块化和可重用。 ## 挑战 4 — GitHub Actions 扫描 ### 问题 在将 TruffleHog 添加到 CI pipeline 后，第一次工作流失败了，因为基础提交和目标提交是完全相同的。 ### 解决方案 为仓库工作流正确配置了 TruffleHog，并将扫描定位在 Docker 镜像验证之前，从而使 secret 扫描成为部署关卡的一部分。 ## 挑战 5 — GitHub Actions 服务中断 ### 问题 尽管工作流配置有效，但每个 CI 作业都无限期地保持在排队状态。 ### 解决方案 在验证了仓库设置、工作流语法和 runner 配置后，该问题被追踪到正在发生的 GitHub Actions 服务中断。 一旦 GitHub 恢复了托管的 runner，pipeline 就会正常恢复。 ## 挑战 6 — GuardDuty 可用性 ### 问题 Terraform 在创建 GuardDuty detector 时失败，出现 SubscriptionRequiredException 错误。 ### 解决方案 调查显示，AWS 免费方案目前限制了 GuardDuty 的激活。 该模块已更新为支持条件部署，允许基础设施成功部署，同时为将来的激活保持 GuardDuty 就绪。 ## 挑战 7 — 免费方案 RDS 限制 ### 问题 Terraform 在创建 RDS 实例时失败，因为配置的备份保留期超出了免费方案的限制。 ### 解决方案 调整了备份保留配置，使其与账户限制保持兼容，同时保留了存储加密和数据库安全性。 ## 挑战 8 — 安全验证 ### 问题 安全控制只有在部署后能够得到验证时才具有价值。 ### 解决方案 使用 AWS CLI 验证了每一个实施的控制，包括： - KMS 加密 - Secrets Manager - Parameter Store - CloudTrail - S3 加密 - RDS 加密 - ECS Task Definition - 应用程序健康 endpoint 这证实了基础设施在加固后依然保持完全正常运行。 # 📚 经验总结 本项目强化了几个重要的云安全原则。 - 应当从一开始就将安全性集成到基础设施中，而不是稍后再添加。 - 最小权限极大地减少了不必要的权限。 - 客户管理的 KMS 密钥提供了比 AWS 管理的加密大得多的控制权。 - Secrets Manager 和 Parameter Store 解决不同的问题，应该结合使用。 - CloudTrail 对于审计基础设施更改至关重要。 - CI/CD pipeline 应包含自动化的 secret 扫描。 - 安全改进必须在部署后始终进行验证。 - 模块化的 Terraform 设计使安全增强更易于维护。 # 🚀 未来改进 潜在的增强功能包括： - 一旦解除账户限制，立即启用 GuardDuty。 - 添加 AWS Config 合规规则。 - 启用 Amazon Inspector 进行容器漏洞扫描。 - 添加 IAM Access Analyzer。 - 启用 Security Hub。 - 使用客户管理的 KMS 密钥加密 EBS 卷。 - 实施 AWS Organizations 服务控制策略 (SCP)。 - 引入自动化合规性报告。 # 🧹 清理 不再需要时，销毁所有由 Terraform 管理的资源。 ``` cd terraform terraform destroy ``` 验证 AWS 账户内是否还有任何剩余的计费资源在运行。 # ✅ 项目成果 到本项目结束时，天气平台成功地从一个功能正常的云应用程序过渡到了一个安全性显著增强的、具有生产启发性的部署。 主要改进包括： - 客户管理的 KMS 加密 - 使用 AWS Secrets Manager 进行安全的 secret 管理 - 存储在 Parameter Store 中的非敏感配置 - 最小权限 IAM 策略 - CloudTrail 审计 - 加固的 S3 存储桶 - 加密的 RDS 数据库 - CI/CD 中的自动化 secret 扫描 - 自动化的基础设施安全审计 最重要的是，所有安全增强功能的实施都没有影响应用程序的可用性或部署自动化。 # 📄 许可证 本项目采用 MIT 许可证授权。 # 🙏 致谢 本项目是我云工程学习历程的一部分，重点在于使用 Terraform、ECS Fargate、GitHub Actions 和现代 DevSecOps 原则，应用具有生产启发性的 AWS 安全实践。 目标不仅是保护基础设施，还要了解每项安全控制背后的原因，并通过真实的 AWS 部署验证其有效性。 # 👨‍💻 作者 **Aboubakr** Cloud 工程师 GitHub: https://github.com/Aboubakr2000Cloud

标签：AWS, DevSecOps, DPI, ECS, GitHub Advanced Security, Terraform, 上游代理, 安全加固, 应用安全, 请求拦截, 逆向工具