第2章 云架构与设计推演

第 2 章 · 云架构与设计推演

章节摘要：安全的成本曲线在图纸上最平缓——图纸阶段改一条线，上线之后要动一整套系统。本章做第一场正式推演：面对一份云上架构设计，怎么用参考架构读懂它、用设计原则审出它、用组件清单核对它，最后把审查结论固化成可执行的 IaC 安全基线。读完本章，你应当能独立完成一次云上架构的安全评审，并交出一份带验证方式的基线清单。

学习目标

读完本章，你应当能够：

1. 用分层的参考架构描述任意一套云上系统，指出每层的职责与层间的信任关系。
2. 面对具体业务约束（合规要求、成本上限、团队能力），论证 IaaS、PaaS、SaaS 的选型理由。
3. 用最小权限、纵深防御、安全默认、失败安全等原则逐条审查一份架构图，指出违规点。
4. 对计算、存储、网络、数据库四类云组件分别列出安全核对项。
5. 读懂一份基础设施即代码模板，识别其中缺失的安全配置。
6. 设计一套配置漂移检测机制，让基线在上线后持续生效。

核心概念速览

本章的知识流是一条"从读到写"的链：参考架构给了描述系统的语法，设计原则给了评判好坏的标准，组件考量把标准落到每类资源，IaC 基线把结论变成可执行的清单。

金句先立此存照：架构评审的最高境界不是挑错，而是在错误被写进代码之前就让它改道——安全左移的本质是让图纸替你值夜班。

子章节导航

• 2.1 云参考架构与服务模型：从一份架构评审邀请函切入，讲参考架构的分层语法与三种服务模型的选型推演，给出"什么约束选什么模型"的决策路径。
• 2.2 安全云架构设计原则：逐条讲六条设计原则的来历与适用边界，并用一次真实感的评审推演示范怎么把原则变成问题清单。
• 2.3 云服务组件安全考量：把镜头推近，对计算、存储、网络、数据库四类组件逐一过安全核对项，附可复用的核对表。
• 2.4 IaC 安全基线演练：本章的落点，把前三节的审查结论写成基础设施即代码模板的安全基线，配漂移检测机制与完整演练。

子章节之间的逻辑关系

四节是"语法—标准—清单—落地"的递进：不懂参考架构，评审时连系统都读不完整；不懂设计原则，读得完也判不出好坏；不做组件核对，原则永远悬在半空；不落成 IaC 基线，清单随人员流动而流失。第四章的演练是前三节的总和，也是全册第一次"把结论写成代码"。

2.1 参考架构        2.2 设计原则        2.3 组件核对        2.4 IaC基线
 ┌───────────┐     ┌───────────┐     ┌───────────┐     ┌───────────┐
 │ 系统怎么读  │ --> │ 好坏怎么判  │ --> │ 逐项怎么查  │ --> │ 结论怎么存  │
 └───────────┘     └───────────┘     └───────────┘     └───────────┘
    读图纸             定标准             过清单             固化复用
​

前置知识与后续延伸

前置只需要第一章的公共语言：服务模型、共享责任、控制面与数据面。有运维或开发背景的读者在 2.4 会非常顺手，纯管理背景的读者可以重在理解基线的治理价值、跳过模板语法细节。

后续延伸有两条线：一条向下钻进第三章——基线里最要紧的数据类资源（加密、密钥、分类分级）在下一章展开；另一条横向铺开——2.4 的"配置漂移"概念将在第六章运营域长成完整的配置合规体系。读完本章，你手里应当留下两样东西：一份评审问题清单模板，和一个"安全结论必须可执行"的执念。

高频疑问与易错点

问：没有架构经验，能直接学评审方法吗？ 可以，评审的入门门槛是提问能力而非设计能力。四节的六问清单本身就是给非架构者准备的脚手架：你不需要会画架构，只需要会沿着数据流追问。做过两轮评审之后，问题会自然内化成直觉。

问：安全评审怎么说服业务方接受整改？ 用风险语言而不是安全语言（第七章的方法在这里预演）：把每条发现折算成"不修的话最坏场景是什么、概率多大"，再给整改成本。架构师尊重的是交换，不是禁令——给出"成本最低的合规路径"通常比"必须整改"更快被接受。

易错点：把参考架构当标准答案。 参考架构是描述语法不是设计模板，真实系统总是四层的变体组合。评审时若发现某层"缺失"（如没有独立访问层），先确认功能由哪层代偿，再判断代偿是否安全——直接报"缺层"是教科书式误报。