vchoudhary480/aws-security-hardening

# AWS 云安全加固 一个实用的 AWS 安全项目，旨在对新账户进行加固以防范常见的错误配置，并使用自定义的 Python 审计脚本验证配置。本项目是作者在准备 SOC 分析师和云安全职位期间构建的作品集。 ## 概述 本项目演示了在 AWS 上的端到端云安全实施： - **IAM** — Root 账户启用 MFA，遵循最小权限原则的 admin 用户，将 root 账户与日常使用账户分离 - **S3** — AES-256 默认加密，启用版本控制，账户级别开启 Block Public Access - **日志记录** — 开启多区域 CloudTrail 并启用日志文件验证 - **合规性** — 使用 AWS Config 记录所有受支持资源的配置变更 - **自动化** — 使用 Python 和 Boto3 编写审计脚本，以检测所有区域中的错误配置 - **验证** — 执行受控的检测自测，以验证脚本的准确性 ## 架构 ``` flowchart TB subgraph AWS["AWS Account"] IAM[IAM Users
MFA + Least Privilege] S3[S3 Buckets
Encrypted + Versioned] SG[EC2 Security Groups
Multi-Region] CT[CloudTrail
Multi-region audit log] CONFIG[AWS Config
Configuration history] LOGS[(S3 Logs Bucket
Encrypted)] IAM --> CT S3 --> CT SG --> CT IAM --> CONFIG S3 --> CONFIG SG --> CONFIG CT --> LOGS CONFIG --> LOGS end BOTO[Boto3 Audit Scripts
Python + AWS SDK] REPORT[JSON Audit Report] BOTO -.queries.-> IAM BOTO -.queries.-> S3 BOTO -.queries.-> SG BOTO --> REPORT style IAM fill:#ff9900,stroke:#333,color:#000 style S3 fill:#569A31,stroke:#333,color:#fff style SG fill:#ff9900,stroke:#333,color:#000 style CT fill:#1f7be7,stroke:#333,color:#fff style CONFIG fill:#1f7be7,stroke:#333,color:#fff style LOGS fill:#232f3e,stroke:#333,color:#fff style BOTO fill:#3776ab,stroke:#333,color:#fff style REPORT fill:#666,stroke:#333,color:#fff ``` ## 审计脚本 | 脚本 | 目的 | |---|---| | `scripts/iam_audit.py` | 缺失 MFA，访问密钥超过 90 天，非活动的控制台 | | `scripts/s3_audit.py` | 公有访问，加密，版本控制，访问日志，通配符策略 | | `scripts/security_groups_audit.py` | SSH/RDP 对互联网开放，数据库暴露，大范围端口开放 — 扫描所有区域 | | `scripts/full_audit.py` | 编排器 — 运行所有审计，生成 JSON 报告 | ## 用法 ### 前置条件 - 拥有 admin IAM 用户的 AWS 账户（日常工作中不使用 root 账户） - 已配置 AWS CLI (`aws configure`) - Python 3.10+ ``` pip install -r requirements.txt ``` ### 运行审计 ``` cd scripts python full_audit.py ``` 输出： - 控制台 — 包含严重程度计数的执行摘要 - 文件 — `docs/audit_report_YYYYMMDD_HHMMSS.json` - 退出代码 — 0 (干净) 或 1 (检测到发现项)，可用于 CI/CD 集成 ## 验证：检测自测 为了验证审计脚本能捕捉到它们声称能捕捉到的问题，我故意创建了一个配置不当的安全组，其中包含三个典型的真实世界错误： 1. SSH (端口 22) 对 `0.0.0.0/0` 开放 — 管理员访问权限暴露在互联网上 2. MySQL (端口 3306) 对 `0.0.0.0/0` 开放 — 数据库直接暴露在互联网上 3. 端口范围 8000-9000 对 `0.0.0.0/0` 开放 — 权限过大的批量规则 我还测试了较简单的检查容易遗漏的对抗性边缘情况： - 一个 `/8` 的 CIDR 块（实际上是公有的，但字面上不是 `0.0.0.0/0`） - 一个通过 `Condition` 块授予通配符访问权限的 S3 存储桶策略 - 一个拥有 `iam:PassRole` 权限（可传递给高权限角色）的 IAM 用户 审计脚本正确识别了所有发现项并给出了适当的严重性评级，随后在补救措施实施后验证了干净的状态。有关逐项控制的详细分解，请参见 `CIS_MAPPING.md`。  ## 示例输出 针对已加固账户运行的完整审计：  JSON 审计报告（机器可读，适合 SIEM 摄取）：  ## 与现有工具的关系 像 [Prowler](https://github.com/prowler-cloud/prowler)、ScoutSuite 和 CloudSploit 这样的工具已经在生产规模上解决了这个问题。本项目的目标并不是要与它们竞争，而是通过从头开始重建 Prowler 功能的一个狭窄切片，来学习 Boto3、AWS 身份验证流程以及底层的 API 形状。在实际环境中，我会运行 Prowler（或等效的 AWS Config 托管规则），并辅以针对组织特定控制的自定义检测。 ## 安全决策与权衡 - **管理员组拥有 AdministratorAccess 权限** — 为了实验室的简便性而使用。生产部署应遵循最小权限原则使用限定范围的 IAM 策略。 - **未启用 GuardDuty 和 Security Hub** — 这两项服务都提供免费试用（GuardDuty：30 天，Security Hub：提供免费套餐），但我将本项目的范围限定在 CloudTrail + AWS Config + 自定义 Python 检测，以保持在永久免费套餐内，并将重点保持在检测工程层面上。 - **并未在所有存储桶上启用 S3 访问日志** — 作为一个已知发现项保留，以演示审计脚本如何对真实的配置缺口进行分类。 ## CIS AWS 基础安全基准 参见 [`CIS_MAPPING.md`](CIS_MAPPING.md)，了解本项目检查项与 CIS AWS Foundations Benchmark v1.4 之间的逐项控制映射。 ## 展示的技能 - 通过 CLI 配置 AWS 服务 (IAM, S3, CloudTrail, Config, EC2) - 使用 Boto3 SDK 进行 Python 自动化 - JSON 策略编写（IAM 信任策略，S3 存储桶策略） - 合规框架（CIS AWS Foundations Benchmark v1.4） - 检测工程 — 受控的负面测试和对抗性边缘情况 - 防御性脚本编写（无硬编码凭证，分页，错误处理，多区域） ## 作者 **Vishwa Prakash Choudhary** - 计算机科学，UC Davis（将于 2026 年 8 月毕业） - vpc8848@gmail.com - [GitHub](https://github.com/vchoudhary480)

标签：Anthropic, AWS, AWS Config, Boto3, CIS基准, CloudTrail, DPI, GitHub Advanced Security, IAM, Python, S3加密, SOC分析师, 云合规, 云安全工程师, 多区域日志, 安全加固, 对称加密, 无后门, 最小权限, 检测自测, 端口安全, 网络安全, 自动化审计, 逆向工具, 配置验证, 隐私保护