2.2 安全云架构设计原则

2.2 安全云架构设计原则

本节摘要：设计原则是架构评审的判据库。本节逐条讲六条核心原则——最小权限、职责分离、纵深防御、安全默认、失败安全、保持简单——各自的来历、适用边界与典型误用，再用一次评审推演示范怎么把原则变成能问出答案的问题清单。

六条原则各自的来历

原则之所以成为原则，是因为每条背后都站着一堆事故。逐条过，重点看它的适用边界与常见误用——考试爱考的恰是边界情况。

最小权限：每个身份只拿完成当前任务所必需的权限，且只在需要的时间段持有。来历是内部威胁与横向移动：攻击者拿到一个账号后能走多远，取决于这个账号有多大的权限。云上的典型误用是把管理类权限直接授给整个团队"图省事"，或给服务账号配了远超其功能的宽权限。边界情况：权限收得太紧会催生"影子权限"——工程师私下共享高权账号，反而更危险，所以最小权限必须配自助申请流程才有生命力。

职责分离：关键操作拆给不同角色，任何人无法独立完成危险动作。经典设计是"申请者不能自己审批"。云上的落地形态包括：生产变更需要第二人复核、密钥的管理与使用分开、审计员不能改自己审计的系统。误用形态是把职责分离做成官僚流程，审批链五级导致人人想绕过——好设计是让守规矩的路成为最短的路。

纵深防御：任何单层防御都被假定为会失效，层数才是可靠性来源。云原生场景里它有个新表达：边界破了之后，攻击者每往里走一步都要再过一道关。误用是"墙够厚就不用锁抽屉"——重金买边界设备却让所有主机用同一个弱口令。

安全默认：系统出厂状态就应当是安全的，不安全的选择必须显式开启。云上有句行话叫"默认即公开的资源是勒索信的摇篮"，指的就是那些为了便利把默认值设为开放的组件。评审时盯住所有"默认值"：默认加密开没开、默认公开关没关、默认日志记不记。

失败安全：系统失效时应当退回安全状态而不是开放状态。比如认证服务宕机时，正确行为是拒绝请求并报警，而不是放行。这条原则在考试里常以场景题出现：防火墙故障时流量放行还是拦截？答案永远是拦截（fail closed），除非有明示的业务例外。

保持简单：复杂度本身是敌人。每多一个组件、一条跨区信任、一套特殊配置，就多一处没人说得清的攻击面。评审中"为什么这里有这条规则"答不上来的，一律建议删除。简单原则还有个推论：能靠平台标准能力解决的，不自制特殊机制。

评审推演：六问过一张图

拿 2.1 的订单系统草图做一次完整评审，示范原则怎么变成问题。评审记录的标准格式是"原则—问题—发现—建议"四栏。

第一问（最小权限）：应用服务器访问数据库用什么身份？草图画的是"数据库账号密码写在配置文件里"。发现：凭据与应用同生共死，任何拿到代码仓库的人都有生产库权限。建议：改用平台托管的角色映射，应用运行时自动获得临时凭据。

第二问（职责分离）：谁能改生产环境的路由规则？草图答案是"运维都在一个组里"。发现：无审批环节，单人可变更生产流量。建议：路由与安全组变更纳入双人复核。

第三问（纵深防御）：应用服务器之间以及到数据库之间有访问控制吗？草图默认同网段互通。发现：一旦一台应用服务器失陷，攻击者可以直接横移到数据库。建议：按微分段拆分安全组，数据库只接受应用组特定端口的访问。

第四问（安全默认）：对象存储的默认权限是什么？答：为了转码方便设了公开读。发现：即开篇 1.2 事故的同款配置。建议：默认私有，转码服务用临时授权访问。

第五问（失败安全）：认证服务不可用时系统行为？草图没画。发现：未定义，按经验大概率是异常放行。建议：明确失败即拒绝，认证组件做多可用区冗余。

第六问（保持简单）：草图里有两条跨区专线与三套网络规则集，申请方解释不清第二条专线的用途。发现：历史遗留。建议：拆除，网络规则合并为单一策略集。

图 2-2：六条原则在评审中的检查位置

原则的冲突与取舍

六条原则偶尔打架，评审的功力体现在冲突裁决上。最常见的冲突是安全默认与业务便利（默认私有让转码服务多一步授权）、最小权限与应急响应（事件处置需要临时宽权限）、保持简单与纵深防御（层多了系统复杂）。裁决的通用次序：先保失败安全与最小权限这两条底线，再用流程与自动化化解便利性损失——比如给应急响应开一条"事后强制复盘"的临时提权通道，而不是常设宽权限。

考场景题时同样适用这个次序：两个选项都"有点道理"时，选更贴近底线原则的那个，再看哪个把便利性的损失处理得更周全。

原则速查表与反模式

评审跑多了会发现，违规形态高度重复。把六条原则的高频反模式汇总成一张速查表，评审时逐行扫一遍，大部分问题逃不出这几行。

表的价值在于"评审可以被机器辅助"：前三行能部分自动化（权限扫描、变更记录核查），后三行偏人工判断。这与 2.4 的思路一致——能机器判定的进检查规则，不能的进人工评审清单，评审资源永远向判断型问题倾斜。

一场失败的评审复盘

给本节配一个反面案例，看"评审形同虚设"的完整画像。某项目的安全评审开了四十分钟，记录只有一句"架构基本合理，建议加强安全管理"。三个月后系统上线即出事故：内部服务之间的明文接口被利用，攻击者横向读取了用户表。

复盘这场评审，问题不在评审人不懂，在评审没有产出物：没有按原则逐条过问题（六问一问没问），没有要求看配置证据（WAF 只在口头里存在），没有把发现写成可验证的建议（"加强安全管理"无法执行也无法复核）。对照本节的四栏格式与 2.1 的六问清单，这场评审每一步都反着来了一遍——它因此成了培训新评审官的最佳教材。

教训沉淀成一句话：**评审的严肃性不看时长看记录，每一条发现都该是"原则引用加问题事实加可验证建议"的三段式。**做不到三段式的发现，说明评审人自己也没想清楚。

本节要点回顾

• 六条原则各有来历：每一条都对应一类真实事故的教训，评审时引用原则而非引用口味，争论会少一半。
• 冲突裁决有次序：先保失败安全与最小权限两条底线，再用流程与自动化化解便利性损失。
• 反模式高度重复：速查表六行能覆盖大部分评审发现，前三行可机器辅助，后三行靠人工判断。
• 评审的严肃性看记录不看时长：每条发现都该是"原则引用、问题事实、可验证建议"三段式，做不到三段式说明评审人没想清楚。
• 原则是判据库不是 checklist：场景题里两个选项都有道理时，选更贴近底线原则的那个。

收尾前补一句六条原则的记忆法：把它们按"防谁"分组——最小权限与职责分离防的是"自己人出错"，纵深防御与失败安全防的是"控制失灵的那一刻"，安全默认与保持简单防的是"复杂度本身"。评审时按这个分组喊话，每一条原则都能对上一种具体的失效场景，原则引用就不会沦为口号。

下一节把镜头从图纸推近到资源本身：同一套原则落到计算、存储、网络、数据库四类组件上，各自长成什么样，我们逐类过核对项。