jibin006/aws-secure-landing-zone

# AWS Secure Landing Zone — 生产级多账户架构 ## 架构理念 此 Landing Zone 的设计围绕每个决策点的一个核心问题展开： 每项 SCP、每个账户边界、每个日志决策都可追溯到该问题。 ## 账户结构 ``` Root (Management Account) — NO workloads run here ├── Security OU │ ├── log-archive ← Immutable audit trail. Separate credentials. Harder to destroy than to commit the attack. │ └── security-tooling ← GuardDuty delegated admin, SecurityHub aggregator, Config aggregator ├── Infrastructure OU │ └── shared-services ← Transit Gateway, Route53 Resolver, shared AMI library ├── Workloads OU │ ├── Production OU │ │ └── prod-app ← Production workloads. Strictest SCPs. │ ├── Staging OU │ │ └── staging-app ← Pre-prod. Moderate SCPs. │ └── Sandbox OU │ └── sandbox-eng ← Engineer experimentation. Region-restricted. No prod data. └── Suspended OU ← Quarantine zone. Deny-all SCP. Used during incident response. ``` ## 爆炸半径分析 ### 场景 1：沙盒账户失陷 - **攻击者可达范围：** 仅限 `sandbox-eng` 内的资源。没有通往生产或预发布环境的 VPC Peering（TGW 路由表已隔离）。从沙盒到工作负载账户没有跨账户 IAM 角色信任。 - **无法触及：** 生产数据、预发布数据库、log-archive 账户中的 CloudTrail、任何 Security OU 资源。 - **检测延迟：** 异常 API 调用后约 5 分钟内产生 GuardDuty 发现。5–15 分钟内 CloudTrail 事件进入 log-archive（交付 SLA）。 - **残余风险：** 攻击者可以破坏沙盒账户、产生费用，或将其作为钓鱼的跳板（欺骗内部外观的域名）。爆炸半径受控；声誉风险不为零。 ### 场景 2：生产工作负载账户失陷 - **攻击者可达范围：** `prod-app` 内的资源。具有跨账户信任至 `shared-services` 的 IAM 角色，用于特定操作（只读）。 - **无法触及：** 无法修改 SCP（仅管理账户可修改）。无法禁用 CloudTrail（SCP 拒绝）。无法访问 log-archive（独立账户、独立凭证、日志桶上的拒绝策略）。 - **检测延迟：** GuardDuty + SecurityHub 在 5 分钟内完成关联。跨账户角色承担会记录在双方账户的 CloudTrail 中。 - **残余风险：** 检测前账户内的数据渗出。VPC Endpoint 策略将 S3 渗出限制为组织拥有的桶。并非所有渗出路径都已封堵（例如，通过 NAT Gateway 直接以 HTTPS 连接到攻击者基础设施）。检测工程管道覆盖了这一点。 ### 场景 3：管理账户失陷 —— 最坏情况 - **攻击者可达范围：** 一切。可以分离 SCP、修改组织结构、访问整合账单。 - **限制损害的因素：** 管理账户无工作负载、无长期使用的凭证，仅通过带 MFA 的 SSO 访问。Break-glass 访问是唯一的凭证途径（记录在 `docs/break-glass-runbook.md`）。来自管理账户的 CloudTrail 流向 log-archive —— 但如果攻击者拥有管理账户访问权限，他们最终也能触及 log-archive。 - **检测延迟：** 管理账户发出的任何超出正常 SSO 模式的 API 调用都会触发高优先级 GuardDuty 发现。2 分钟内 PagerDuty 升级。 - **残余风险：** 这是一个生存级事件。该架构通过访问限制（而不仅仅是检测）将可能性降至最低。管理账户失陷 = 全面启动事件响应。 ## 控制设计决策 ### 为什么 SCP 还不够（以及填补空白的是什么） | 层级 | 工具 | 覆盖内容 | 遗漏内容 | |---|---|---|---| | 预防性 | SCP | 阻止 IAM 控制的操作 | 允许操作内的行为 | | 侦探性 | AWS Config | 配置偏差 | 行为异常 | | 行为性 | GuardDuty | 威胁情报 + ML 异常 | 已知良好但恶意的模式 | | 关联性 | SecurityHub | 跨服务信号聚合 | 上下文感知调查 | 四个层均已部署。缺一不可。 ### 账户自动发放 —— 无需工单 新产品团队通过 `terraform/organization/account_vending.tf` 中的账户自动发放管道，在 2 小时内获得安全的 AWS 账户。该管道： 1. 接受 JSON 请求（团队名称、OU 目标、成本中心标签） 2. 通过 AWS Organizations 创建账户 3. 应用基线 Terraform 模块（CloudTrail、Config、GuardDuty、SecurityHub） 4. 通过 IAM Identity Center 分配权限集 5. 向团队发送 Slack 通知，包含账户 ID 和 SSO 登录 URL 安全团队无需人工审批。控制措施已融入基线 —— 默认即安全，而非审查后安全。 ## 如何部署 ### 前置条件 ``` # Terraform >= 1.6 terraform -version # 具有管理账户凭证的 AWS CLI aws sts get-caller-identity # 您必须在拥有 OrganizationsFullAccess 的管理账户中 ``` ### 步骤 1：引导 State Backend ``` cd terraform/state-backend terraform init terraform apply # 这将创建所有其他模块使用的 S3 + DynamoDB backend ``` ### 步骤 2：创建组织结构 ``` cd terraform/organization terraform init -backend-config=../state-backend/backend.hcl terraform apply ``` ### 步骤 3：应用 SCP ``` cd terraform/scp terraform init -backend-config=../state-backend/backend.hcl terraform apply ``` ### 步骤 4：向所有账户部署基线 ``` cd terraform/baseline terraform init -backend-config=../state-backend/backend.hcl terraform apply ``` ### 步骤 5：部署网络层 ``` cd terraform/network terraform init -backend-config=../state-backend/backend.hcl terraform apply ``` ## 本仓库安全说明 - **代码中无凭证。** Provider 认证使用 AWS SSO / OIDC。 - **State backend** 使用 S3（KMS 加密）+ DynamoDB 锁定。参见 `terraform/state-backend/`。 - **所有密钥** 通过 AWS Secrets Manager 数据源引用 —— 永远不存储在 state 值中。 - **模块版本锁定** —— 所有外部模块锁定到特定 git commit SHA，而非版本标签。 ## 作品集证据映射 | 概念 | 演示位置 | |---|---| | 爆炸半径设计 | 本 README + `docs/blast-radius-design.md` | | SCP 组合 | `terraform/scp/` — 每个控制项均有文档 | | 预防性与侦探性权衡 | `docs/control-design.md` | | State 文件安全 | `terraform/state-backend/` | | 账户自动发放自动化 | `terraform/organization/account_vending.tf` | | 事件事后分析 | `docs/postmortem-state-exposure.md` | | 威胁模型 | `docs/threat-model.md` |

标签：AWS, CloudTrail, DPI, GuardDuty, IAM, Landing Zone, SCP策略, SecurityHub, VPC, Web报告查看器, 多云架构, 多账户管理, 安全合规, 安全架构, 安全组, 漏洞探索, 爆炸半径分析, 生产环境, 网络代理, 网络隔离, 账号工厂