jeremiahredden/cloud-security-reference-architecture

# 云安全参考架构     ### 面向云安全工程与架构的从业者工具包 —— 涵盖 AWS、Azure 和 GCP 上的 landing zone、identity、网络、数据、Kubernetes、IaC、检测和 zero trust **Jeremiah Redden** | 高级 AI/AppSec 安全架构师 | CISSP | [github.com/jeremiahredden](https://github.com/jeremiahredden) 本仓库是三部分参考集中的云安全部分。其同级仓库 [**appsec-reference-architecture**](https://github.com/jeremiahredden/appsec-reference-architecture) 和 [**ai-security-reference-architecture**](https://github.com/jeremiahredden/ai-security-reference-architecture) 分别涵盖应用安全和 AI 安全。本仓库涵盖位于应用*之下*的控制措施 —— 即云账户、identity、网络、data plane、容器平台以及一切其他内容运行所依赖的检测基础设施。 这种划分是刻意为之的。云安全本身就是一门工程学科，而不是 AppSec 的后勤支持功能。这些控制措施必须在 workload 落地之前进行设计，在平台层而非应用层强制执行，并由一个团队来运营，该团队的主要抓手是平台工程，而不是代码审查。将云架构内容混入 AppSec 仓库会导致该文件夹内容太浅而缺乏实用性，又太广而缺乏聚焦性。因此，本仓库独立存在。 第二个动机是：2026 年的云安全是一个涉及多账户、多云、多 runtime 的问题。如果参考架构仅仅说“使用 AWS Organizations 就万事大吉”，那么它无法帮助那些在两个 AWS 账户间运行 EKS 集群、在 Azure App Service 上运行 SaaS workload 以及在 BigQuery 中运行分析 pipeline 的团队。这里的模式假定多账户是基线，多云是常态，并且即使 Kubernetes 尚未引入，它也已在规划路径上。 同级的 AppSec 仓库包含一个 [`cloud-security/`](https://github.com/jeremiahredden/appsec-reference-architecture/tree/main/cloud-security) 文件夹，其中提供了大多数应用安全架构师所需的轻量级 AWS + Azure + 多云概述。该文件夹将保持原样。本仓库则面向主要职责是云平台本身的工程师和架构师，在更多维度上进行更深入的探讨。 ## 目录 - **[landing-zones/](./landing-zones/)** — 已完成 (7/7)。多账户 AWS Organizations、Azure Management Group 层级结构以及 GCP Organization 设计（三大云平台深度对齐）。账户发放、基线 SCP / Azure Policy / GCP Organization Policy，Control Tower 与 Azure Landing Zones 以及 Cloud Foundation Toolkit 的对比，包含改造模式在内的六周落地路径，以及五个反复出现的 landing-zone 失败模式及其纠正措施。 - **[identity-and-access/](./identity-and-access/)** — 已完成 (7/7)。Workforce identity（Entra ID, Okta, AWS Identity Center）和 workload identity（IAM Roles for Service Accounts, GCP Workload Identity Federation，来自 GitHub / GitLab / CI 提供商的 OIDC federation）。Federation 模式（跨云 federation 的 SAML / OIDC / SCIM）。跨所有云的 JIT / PIM 模式。Service-account 生命周期和资产盘点规范。带有分级修复顺序的 IAM 反模式目录。与 CloudTrail 和 IAM Access Analyzer 绑定的最小权限工作流。 - **[network-security/](./network-security/)** — 已完成 (7/7)。VPC / VNet 设计，hub-and-spoke + Transit Gateway / Cloud WAN，分段模式，egress 过滤（Network Firewall, Azure Firewall, GCP Cloud NGFW），PrivateLink / Private Endpoints / Private Service Connect，DNS 防火墙，以及检查架构决策树。 - **[data-security/](./data-security/)** — 已完成 (7/7)。KMS 策略和密钥层级，静态和传输中的加密，BYOK / HYOK / CMK 的权衡，S3 / Azure Storage / Cloud Storage 加固，RDS / Azure SQL / Cloud SQL 安全，tokenization，以及与检测集成而非独立存在的 DLP 模式。 - **[kubernetes-and-container-security/](./kubernetes-and-container-security/)** — 已完成 (9/9)。EKS / AKS / GKE 安全基线，Pod 安全标准，网络策略，OPA / Gatekeeper / Kyverno，runtime 安全（Falco, Tetragon），service mesh（Istio, Linkerd），镜像签名和验证（Cosign, Sigstore, SLSA），以及从镜像仓库到准入控制的安全供应链控制措施。 - **[iac-security/](./iac-security/)** — 已完成。Terraform / OpenTofu / Bicep / CloudFormation / Pulumi 模式；带有安全默认值的模块设计；policy-as-code（OPA / Conftest, Checkov, Trivy config, Sentinel, CFN Guard, Crossguard）；带有渐进式拦截 + 严重级别映射操作的 IaC pipeline 拦截机制；跨工具的 drift 检测；用于扫描器验证的故意配置错误的参考包。 - **[secrets-and-keys/](./secrets-and-keys/)** — 已完成 (7/7)。Secrets Manager, Key Vault, GCP Secret Manager，带有 Vault 的动态凭证，轮换模式，KMS 密钥策略，信封加密，secret 检测，以及用 OIDC federation 取代长期密钥的实操手册。 - **[cloud-detection-response/](./cloud-detection-response/)** — 已完成 (10/10)。CloudTrail / Activity Logs / Audit Logs 架构；GuardDuty / Defender for Cloud / Security Command Center 各计划的选择和调优；SIEM 集成模式（Splunk, Sentinel, Chronicle, Elastic, Datadog）及 log-router 模式；跨越 8 个类别的 25 条规则自定义检测目录；假设驱动的威胁狩猎；五个核心 IR runbook（泄露的 IAM key、暴露的存储、EKS pod 入侵、账户接管、挖矿攻击）。 - **[zero-trust-cloud/](./zero-trust-cloud/)** — 已完成 (7/7)。Identity-aware 代理（Cloudflare Access, AWS Verified Access, GCP IAP），微分段，使用 SPIFFE / SPIRE 的服务间身份验证，mTLS service mesh，持续授权，以及无需推翻现有网络架构的基于现有基础设施落地 BeyondCorp 的路径。 - **[serverless-and-paas-security/](./serverless-and-paas-security/)** — 已完成 (7/7)。Lambda / Azure Functions / Cloud Functions 和 Cloud Run 安全，API Gateway / API Management / Apigee，App Service + Beanstalk + App Engine + Cloud Run，边缘函数（CloudFront Functions, Cloudflare Workers），serverless 检测和 IAM 模式。 - **[threat-modeling-cloud/](./threat-modeling-cloud/)** — 已完成 (6/6)。针对云的特定 STRIDE 模板，MITRE ATT&CK for Cloud Matrix 覆盖率，攻击路径分析，云威胁建模会议的引导指南，以及针对多账户 SaaS 和多云数据平台的两个实操威胁建模案例。 - **[compliance-and-control-mapping/](./compliance-and-control-mapping/)** — 已完成 (8/8)。将 HIPAA Security Rule、SOC 2 Trust Services Criteria、PCI-DSS v4、FedRAMP Moderate / High 以及 NIST 800-53 Rev 5 逐行映射到具体的云控制措施。持续控制监控架构；云提供商责任共担 / 客户责任矩阵；具有严格保管链规范的证据收集 runbook。 - **incident-response-cloud/** — 已整合至 [cloud-detection-response/](./cloud-detection-response/) 中而不是单独拆分，因为相同的日志架构必须同时服务于检测和 IR。 ## 如何使用本仓库 **如果你是一名云安全架构师**，正在为新的 workload 或新业务部门设计控制措施，请从 [landing-zones/](./landing-zones/) 和 [identity-and-access/](./identity-and-access/) 开始。账户边界和 identity 模型是日后最难以撤销的两项决策；其他所有决策都是可以重新协商的。一旦这些落地，[network-security/](./network-security/) 和 [data-security/](./data-security/) 就是接下来的高杠杆决策，并按此顺序进行。 **如果你是一名平台工程师**，正在搭建一个供其他团队构建应用的 Kubernetes 平台，[kubernetes-and-container-security/](./kubernetes-and-container-security/) 就是你的目的地。那里的模式假定平台层负责上层应用团队无法改版的控制措施 —— pod 安全策略、网络策略、准入控制、runtime 检测和镜像供应链。将其与 [zero-trust-cloud/](./zero-trust-cloud/) 结合查看，以了解服务间的 identity 体系。 **如果你是一名安全工程师**，在云环境中负责检测和响应，[cloud-detection-response/](./cloud-detection-response/) 包含了 runbook 和 log-pipeline 模式。请结合 [threat-modeling-cloud/](./threat-modeling-cloud/) 一起阅读，这样你的检测覆盖率就能基于云环境中实际出现的攻击路径进行逆向构建，而不是基于你的工具自带的特征正向叠加。 **如果你是一名 SRE 或 DevOps 工程师**，负责 IaC pipeline，[iac-security/](./iac-security/) 是你应该首先阅读的章节。在 CI 中快速失败的 policy-as-code 拦截机制，是防止配置错误的云资源落地的最大抓手。 **如果你是一名审计员或合规负责人**，[compliance-and-control-mapping/](./compliance-and-control-mapping/) 是你需要的一整套交付物。它旨在生成大多数云审计实际需要的逐行证据包，而不是通常收到的那一大堆政策文档。 **如果你是一名招聘经理**，正在评估我的工作，那么 [threat-modeling-cloud/](./threat-modeling-cloud/) 中详尽的威胁模型、[landing-zones/](./landing-zones/) 中深度的 AWS landing zone，以及 [iac-security/](./iac-security/) 中的 policy-as-code 参考，比任何简历都更能代表我的实际交付能力。请先阅读这些内容。 ## 理念 有四项原则指导着本仓库中的每一部分内容。它们与同级的 AppSec 和 AI 安全仓库所遵循的四项原则相同，只是针对云环境进行了重述。 **1. 云安全应该让平台和产品团队变得更快，而不是更慢。** 一个用 40 分钟策略审查来阻塞每一次 Terraform apply 的 guardrail 不是安全控制 —— 这是一种生产力税，团队通常会通过获取影子账户来绕过它。正确的云安全自动化应该在部署的同一个 pipeline 中运行，在 CI 中遇到策略违规时快速失败，并在同一个 PR 中给工程师提供具体的修复方案。我致力于优化能够缩短总周期时间的控制措施，即使这意味着要接受最大化防御姿态所不能接受的残余风险。下周就能上线的预防性 guardrail 比下季度才能上线的完美方案更有价值；在一个 sprint 内关闭的 CSPM 发现比在队列中不断累积的发现更有价值。 **2. 正确的云控制是能在这个 sprint 上线的控制。** 云安全中最大的单一失败模式是供应商托管的参考架构，它展示了 47 个相互连接的服务，每年的许可费用高达六位数，需要两名专职的 FTE 来运营，而且没有逐步采用的路径。一个接手了 workload 并面临紧迫的 SOC 2 截止日期的团队根本无法使用它。他们需要一系列具体的操作，每一步都能在一个 sprint 内上线，并且每一步都能显著改善安全姿态。这里的每一条建议都是基于这种现实情况制定的：当我记录一个模式时，我会指明快速上线的 80% 降级模式版本，以及最终会上线的黄金标准版本。 **3. 每一个云安全发现都需要一个工程师能够在当前 sprint 完成的修复。** 一份以“收紧 IAM 姿态”结尾的 CSPM 报告是失败的。一份以“从 `DataPlatformOps` 角色的 KMS statement 中移除 `*` 操作，替换为由 IAM Access Analyzer 确定的四个特定 `kms:Decrypt` 资源 ARN，分配给 platform-eng 团队，追踪号为 CLOUD-204，在 sprint 47 完成时截止”结尾的 CSPM 报告才是成功的。没有负责人、截止日期和具体技术指导的安全发现最终只会沦为 Jira backlog 中的垃圾。本仓库中的每个模板和实操示例都是按照这一标准编写的。 **4. 只存在于策略文档中的云控制等于不存在。展示你的工作。** 架构演示文稿、控制矩阵和 CSPM 仪表板是意图的证据，而不是保护的证据。在可以将这里的模式转化为强制执行代码的地方 —— 如在 OU 上应用 SCP，在 Management Group 上分配 Azure Policy，一条导致 Terraform plan 失败的 Conftest 规则，一条拒绝准入请求的 Kyverno 策略 —— 它们都已经实现了。一个没有强制执行点的“Zero Trust 云架构”，一个没有 deny statement 的“最小权限 IAM 模型”，一个没有检测控制来未加密 bucket 的“默认加密”data plane —— 这些都是空谈。我写作的标准是：每一项架构声明都应该有审查者可以实际执行的交付物作为支撑。 ## 本仓库不包含什么 - **供应商产品指南。** 在提及特定工具（Wiz, Lacework, Prisma Cloud, Teleport, Vault, Okta, Entra ID, Cloudflare Access）的地方，是因为这样更容易具体地解释模式。你可以替换为你选择的供应商；模式本身才是最重要的。 - **CIS 基准解读。** CIS 基准很有价值，而且它们足够全面，完全可以自成一体。使用 CSPM 工具来衡量对它们的合规性。这里的模式是关于哪些控制最重要，以及如何实施它们而不被淹没。 - **完整的云平台工程参考。** 成本优化、超出安全遥测范围的 observability 以及纯粹的 SRE 问题（容量规划、autoscaling 设计、灾难恢复 RTO/RPO 工程）不在讨论范围之内。当这些主题与安全产生交集时 —— 例如作为安全事件的成本滥用、兼作检测手段的 observability、影响数据驻留的 DR 模式 —— 它们会出现，但这里的主要视角是安全。 - **AppSec 或 AI 安全。** 应用层控制（输入验证、安全的 API 设计、OWASP 修复）位于 [appsec-reference-architecture](https://github.com/jeremiahredden/appsec-reference-architecture) 中。AI 特定控制（prompt 注入防御、agent 权限模型、MCP server 加固、ML 供应链）位于 [ai-security-reference-architecture](https://github.com/jeremiahredden/ai-security-reference-architecture) 中。请将三者结合使用；这些边界是刻意划分的。 ## 许可与署名 除非另有说明，本仓库中的所有内容均在 MIT 许可下发布。模板、playbook 和参考实现可以被自由使用、修改和改编 —— 包括用于商业活动和客户交付物。表示感谢但不作强制要求。 如果你在这里发现了有用的内容，我希望能听到你的反馈。请提一个 issue，在 LinkedIn 上与我联系，或者提交一个包含你改进建议的 pull request。

标签：AWS, Azure, Chrome Headless, DPI, GCP, JSONLines, Kubernetes安全, 参考架构, 子域名突变, 构建工具, 漏洞利用检测, 零信任