Muhammad-Imad/terraform-aws-landing-zone

# terraform-aws-landing-zone [](https://www.terraform.io/) [](https://registry.terraform.io/providers/hashicorp/aws/latest) [](./LICENSE) [](./.github/workflows/terraform-ci.yml) 本仓库演示了如何使用 AWS Organizations、Service Control Policies、委托安全管理、Transit Gateway 中心、集中式出口以及不可变的集中式审计日志，从零开始引导并治理多账号 AWS 资产——所有这些都以可组合的 Terraform 模块和按账号划分的根配置形式实现。 ## 🏛️ 架构 ``` graph TD Root["AWS Organizations Root
(Management Account)
Organizations · SCPs · Identity Center"] Root --> OU_Sec["OU: Security"] Root --> OU_Infra["OU: Infrastructure"] Root --> OU_Work["OU: Workloads"] Root --> OU_Sandbox["OU: Sandbox"] OU_Sec --> A_Audit["Audit Account
GuardDuty · Security Hub · Config
(delegated admin)"] OU_Sec --> A_Log["Log Archive Account
Org CloudTrail S3 + KMS"] OU_Infra --> A_Net["Network Account
Transit Gateway + Egress VPC"] OU_Infra --> A_Shared["Shared Services Account
Route 53 PHZ · ECR"] OU_Work --> A_Prod["Workload Accounts
(Prod / NonProd)"] Root -. "SCP guardrails" .-> OU_Work A_Net <-. "TGW attachments
(shared via RAM)" .-> A_Prod A_Net <-. "TGW attachments" .-> A_Shared ``` 请参阅 [`docs/ARCHITECTURE.md`](./docs/ARCHITECTURE.md) 以获取完整的账号模型、流量流向、日志拓扑和建议的应用顺序。 ## ✨ 功能特性 - **基础设施即代码的 AWS Organizations** — OUs（Security、Infrastructure、Workloads、Sandbox、Suspended）、成员账号和受信任的服务访问集成在一个可重用的模块中。 - **Service Control Policy 防护栏** — `deny-leave-org`、`deny-root-user`、`require-imdsv2` 以及 `region-restriction` 白名单，可按 OU 进行切换。 - **委托安全管理** — GuardDuty、Security Hub 和 AWS Config 在组织级别启用，并汇聚到一个专用的 **audit**（审计）账号中，而非管理账号。 - **集中式、不可变的审计日志** — 单一的组织 CloudTrail 将日志交付到 **log archive**（日志归档）账号中经过 KMS 加密、启用版本控制和访问日志记录的 S3 存储桶，并具备向 Glacier 的生命周期转换。 - **中心辐射型网络** — 通过 AWS RAM 在整个组织内共享的 Transit Gateway，具有分段的路由表和集中式、可检查的出口 VPC。 - **集中式身份管理** — IAM Identity Center 权限集（Administrator、PowerUser、ReadOnly、Billing）以及声明式账号分配。 - **共享平台服务** — Route 53 私有托管区域以及不可变、推送时扫描、KMS 加密的 ECR 仓库。 - **安全的账号基线** — 默认 EBS 加密、S3 账号级公开访问阻止以及强化的 IAM 密码策略，应用于每个账号。 - **CI 质量门禁** — GitHub Actions 在每个 Pull Request 上运行 `terraform fmt`、`validate`、`tflint` 和 `tfsec`。 ## 🗂️ 仓库结构 ``` terraform-aws-landing-zone/ ├── organization-hub/ # Management account: Organizations + OUs + SCPs ├── identity-hub/ # Management account: IAM Identity Center ├── network-hub/ # Network account: Transit Gateway + egress VPC ├── logarchive-hub/ # Log Archive account: org CloudTrail bucket + KMS ├── audit-hub/ # Audit account: GuardDuty/Security Hub/Config ├── sharedsvc-hub/ # Shared Services account: Route 53 PHZ + ECR ├── workloads-hub/ # Example workload account baseline + app VPC ├── modules/ │ ├── aws-organizations/ # OUs + member accounts │ ├── service-control-policies/ # deny-leave-org, deny-root, imdsv2, regions │ ├── org-cloudtrail/ # central CloudTrail S3 bucket + KMS │ ├── guardduty-org/ # org-wide GuardDuty │ ├── securityhub-org/ # org-wide Security Hub + aggregator │ ├── aws-config-org/ # org Config aggregator + recorder │ ├── transit-gateway/ # TGW + RAM share + route tables │ ├── iam-identity-center/ # permission sets + assignments │ └── account-baseline/ # EBS encryption, S3 BPA, password policy ├── docs/ │ └── ARCHITECTURE.md ├── .github/workflows/terraform-ci.yml ├── .gitignore ├── LICENSE └── README.md ``` 每个 `*-hub` 目录都是一个自包含的 Terraform 根配置，包含 `main.tf`、`variables.tf`、`outputs.tf`、`providers.tf`、`backend.tf` 以及一个 `config.example.tfvars`。 ## 🚀 快速开始 ### 前置条件 - Terraform `>= 1.5` - AWS provider `>= 5.0` - 一个启用了 AWS Organizations 的 AWS 管理账号（付款账号）。 - 一个已引导的 Terraform 远程状态后端：一个 S3 存储桶和一个 DynamoDB 锁定表（在带外进行配置）。更新每个 `backend.tf` 中的占位符。 - 在每个成员账号中可担任的 `OrganizationAccountAccessRole`（或专用的 Terraform 执行角色）。管理账号根配置直接使用管理账号的凭证运行。 ### 使用方法 根配置按照依赖顺序应用（参见 `docs/ARCHITECTURE.md`）。对于每个 hub： ``` cd organization-hub # 使用您的 backend 进行初始化（backend.tf 中有部分配置示例） terraform init \ -backend-config="bucket=acme-tf-state-111111111111" \ -backend-config="key=organization-hub/terraform.tfstate" \ -backend-config="region=us-east-1" \ -backend-config="dynamodb_table=acme-tf-locks" # 查看 inputs cp config.example.tfvars config.tfvars $EDITOR config.tfvars terraform plan -var-file=config.tfvars terraform apply -var-file=config.tfvars ``` ## 🔐 安全与治理 | 控制项 | 位置 | 作用 | |---------|-------|--------------| | **SCPs** | `organization-hub` → `service-control-policies` | 组织级防护栏：防止离开组织、拒绝 root 用户操作、要求使用 IMDSv2、限制区域。 | | **Org CloudTrail** | `logarchive-hub` → `org-cloudtrail` | 单一的多区域组织追踪，记录到经过 KMS 加密、启用版本控制和访问日志记录，并由生命周期管理的 S3 存储桶中。 | | **GuardDuty** | `audit-hub` → `guardduty-org` | 威胁检测在所有账号中自动启用，提供 S3、EKS 和恶意软件保护。 | | **Security Hub** | `audit-hub` → `securityhub-org` | 组织级的安全态势管理，具有跨区域调查结果聚合器和可配置的标准。 | | **AWS Config** | `audit-hub` → `aws-config-org` | 组织级的资源记录和中央配置聚合器。 | | **账号基线** | 每个 hub → `account-baseline` | 默认 EBS 加密、S3 账号公开访问阻止、强化的 IAM 密码策略。 | 关键强化措施： - **管理账号不运行任何工作负载** — 仅用于 Organizations、SCPs 和 Identity Center。 - 安全工具由**委托管理员账号 (audit)** 管理，因此日常操作不需要管理账号的凭证。 - 审计日志存储桶**由独立账号（log archive）拥有**，并使用由客户管理的 KMS 密钥进行加密，该密钥的策略将访问权限限制在 CloudTrail 服务和组织范围内。 - 所有跨账号的 Terraform 访问均通过**担任角色**进行，而非使用长期有效的凭证，并且本仓库中不存储任何密钥。 ## 🧭 工程案例研究 **问题。** 一个快速发展的工程组织已经积累了 50 多个由各个团队临时创建的 AWS 账号。没有一致的 OU 结构，没有集中式的审计追踪，GuardDuty 和 Config 覆盖不一致（或缺失），root 凭证仍在使用中，EC2 实例通过 IMDSv1 暴露于 SSRF 攻击，并且在意外区域中的支出不受控制。安全审查是手动的、缓慢的且逐个账号进行的；没有一个统一的地方可以回答“我们是否在任何地方都记录了所有操作？” **方法。** 我设计并代码化了一个具有明确职责分离的中心辐射型 landing zone：一个干净的管理账号用于组织和身份管理，一个专用的日志归档账号用于不可变的集中式 CloudTrail，以及一个委托管理员审计账号用于在整个组织中汇总 GuardDuty、Security Hub 和 Config。防护栏被表示为附加在 OU 级别的 Service Control Policies（deny-leave-org、deny-root、require-IMDSv2、区域白名单），因此它们会自动应用于每个现有和未来的账号。网络整合在通过 RAM 共享的 Transit Gateway 之后，具有单一的集中式出口路径。所有内容都以小型、可重用的 Terraform 模块形式交付，具有按账号划分的根配置、远程状态以及每次更改时的 CI 门禁（`fmt`/`validate`/`tflint`/`tfsec`）。 **影响。** - **100% 审计覆盖率** — 每个账号都交付到一个不可变的、KMS 加密的 CloudTrail 日志存储桶；Config 和 GuardDuty 在创建账号时自动启用，因此新账号从第一分钟起就受到治理。 - **标准化的防护栏** — root 使用、IMDSv1 和区域外 API 调用被组织级别的策略拒绝，而不是通过审查拒绝，从而消除了整类手动安全发现。 - **更快、更安全的引导** — 新账号会自动继承 OU 防护栏、安全工具、安全基线和网络连接，而不是通过多日的手动检查清单。 - **成本治理** — 区域白名单和集中式出口遏制了意外的跨区域和按账号的 NAT 支出，并且合并的标签实现了准确的成本回流。 *（本案例研究是对本仓库中模式的概括性描述，不涉及任何特定的雇主或客户。）* ## 📄 许可证 基于 MIT 许可证分发。详情请参阅 [`LICENSE`](./LICENSE)。 作者：**Muhammad Imad**

标签：AWS, DPI, ECS, Terraform, 多云管理, 漏洞利用检测, 网络安全架构