4.4 多云混部对比与选型

4.4 多云混部对比与选型

本节摘要：多云与混合云不是时髦词，是责任与治理的乘法题。本节拆解多云、混合云、单云多区三种架构形态的安全差异，给一张多维对比矩阵与一套四步选型推演，核心结论只有一句：每多一个平台，身份、网络、数据、合规四套治理都要复制一份并互相打通——这笔账要在动工前算清。

多云不是免费午餐

行业语境里的多云通常指同时使用两家以上公有云，混合云指公有云与自建机房并存。它们的动机都很正当：议价与避免锁定、合规要求数据留在自建机房、不同平台各有所长、业务连续性的冗余诉求。但安全视角必须补上另一半：云平台的本质是一套治理体系的载体——身份模型、网络分段、加密密钥、审计日志、合规证据，每换一家平台就是换一套体系。单云时这套体系有一份维护成本，多云时它变成 N 份，还要追加第 N+1 份"互操作治理"：跨云身份怎么联邦、跨云网络怎么互通、跨云日志怎么汇聚、跨云事件谁牵头响应。

常见的决策失误是只比单价与功能清单，把治理成本当成零。等真上了第二家云，最常发生的事故形态是"两家的安全水位不一致"——攻击者永远从水位低的那家进来。所以本节的选型推演，重心不是"选哪家"，而是"上多家之前，治理账单有没有人签字"。

三种形态的安全对比

表里的规律值得点破：从上到下是"冗余收益递增、治理成本递增"的单一维度 trade-off，不存在全面占优的形态。选型的本质是判断业务真正需要哪一档冗余，并愿意支付对应的治理成本。

图 4-3：三种形态的收益与代价光谱

四步选型推演

第一步，列驱动因素：把"为什么想上多家"逐条写下来，区分合规强制、商业策略、技术互补、心理安慰四类——心理安慰不算正当驱动。第二步，算治理账单：身份联邦、日志汇聚、密钥体系、事件响应、合规证据五项，每项写清"复制到第 N 家的成本与负责人"，写不出的项就是红旗。第三步，定互操作底线：跨云互通的最小面（能不互通就不互通，互通越多攻击面越大）、统一日志格式、统一告警入口。第四步，签验收口径：水位对齐标准（两家的基线检查用同一张清单）、联合演练排期、退出预案（任何一家出事时业务怎么走）。

一套供练习的场景：支付公司要满足"核心交易数据不出自建机房、弹性风控计算上公有云"的监管要求。按四步走——驱动是合规强制；治理账单里身份要打通（员工一套账号）而数据面保持隔离；互操作底线是只通一条受审计的专线，日志双向汇聚到自建侧；验收口径是两套环境用同一份基线清单年检两次。结论：混合云形态，边界清晰的数据分区，而不是把交易系统拆两家公有云各跑一半——后者带来的跨云一致性难题远超收益。

混部时代的统一防线

无论选哪种形态，有三层"平台无关"的统一防线值得优先投入，它们能摊薄 N 套体系的治理成本：统一身份源（联邦身份为纲，各平台只做映射，入离职一条流程全平台生效）、统一日志与告警（各平台的审计日志汇入同一套分析体系，事件响应只有一张作战桌）、统一基线扫描（同一份配置基线清单跑在所有平台上，水位差异一眼可见）。这三层的建设顺序建议就是书写顺序：身份先行，日志随后，基线收口。

考试风格的场景判断

多云主题在考试里常以"架构建议"类选项出现，两条判断原则提前备好。原则一：考题里的多云动机要打折审读——题干说"为了容灾所以两个云各跑一套"，要看它是否付出了治理对价的准备（统一身份、统一日志）；没提治理的多云选项通常是干扰项。原则二：混合云的数据流向是答题钥匙——问敏感数据往哪去、谁有权访问、跨境了吗，流向理清了，合规与安全要求的答案就顺出来了。

再补一个常见变式：题干问"某组织要求关键业务在任何一家云厂商重大故障时仍可用，最合适的架构是什么"。候选里"同一云双区域"的冗余止步于区域级、不抗厂商级故障；"多云双活"满足要求但题干若同时给出"团队无多云运维经验"的约束，答案会转向"多云温备（热数据同步、冷备接管）"这类折中——注意题目给的每一个约束都在排除一个候选，约束清单就是答案的过滤器，这与 2.1 选型三步法同源。

混部预算：安全投入的分配基准

选型定案后紧跟着是预算分配问题。多云形态的安全预算按"一主多辅"分配通常最健康：主力平台承担七成投入（多数负载与数据所在），辅平台按最小可用配置投入（满足其承载业务的水位即可），互操作层（身份联邦、日志汇聚、告警统一）单独立项——它是唯一不能省的公共投入，省了它，两家平台就成了两座信息孤岛，事件响应时会同时失明两次。这个分配比例没有定规，但"互操作层单独立项"的原则屡试不爽：混进业务预算里的公共投入，永远是第一个被砍的。

统一身份落地：三个高频翻车点

统一身份源说起来一句话，落地时三个翻车点值得提前排。翻车一：映射粒度错位——把企业目录的部门结构直接映射成云平台的权限结构，组织架构一调整权限就错乱。正解是目录只管"人是谁"，云侧权限靠角色与策略表达"人能干什么"，两套结构解耦。翻车二：应急通道真空——联邦认证源故障时连平台管理员都进不了门。必须预设 break-glass 账号：离线保管凭据、使用即告警、用后强制轮换，并进演练剧本。翻车三：服务身份被遗漏——联邦化只做了员工身份，各平台的程序密钥依然散落，身份治理最难的存量恰恰在这；对策是给服务身份迁移立专项，按 4.3 的角色映射法逐个收编。

本节要点回顾

• 多云动机先打折审读：合规强制与商业策略是正当驱动，心理安慰不算；没有治理对价准备的多云方案通常是干扰项。
• 治理账单写不出负责人的项是红旗：身份、日志、密钥、响应、合规证据五项逐项落到人。
• 互操作层是唯一不能省的公共投入：统一身份、统一日志、统一基线，顺序是身份先行、日志随后、基线收口。
• 约束清单就是答案的过滤器：场景题的每个约束都在排除一个候选，与 2.1 选型三步法同源。
• 混合云的关键是数据分区清晰：边界清晰的分区优于把一套系统拆两家各跑一半。

一问一答：多云治理的两个现实问题

问：两家云的告警与日志格式不同，统一日志是不是要先做格式标准化的大工程？ 不必等大工程。可行的路径是"统一到事件层而不是日志层"：各平台日志原样留存，统一层只做事件归一——把两边的告警映射到同一套事件分级与处置字段，作战桌上一张事件单，证据回查时各回各家日志库。格式标准化是长期理想，事件归一是当周就能落地的现实，先用起来再逐步逼近。

问：小团队没有多云需求，这一节还剩什么用？ 剩"复制防线"的思维方式。哪怕单云单环境，开发测试生产三套环境本质上就是"混部"——本节的治理账单、互操作底线、统一身份源三个概念，把"环境"换成"账号"照样成立。考试场景题也常拿"开发测试环境要不要跟生产同水位"设问，答题框架就是本节的四步推演。

平台域四章到此完成：底座、通道、身份、形态。下一章上移一层，看应用这条线怎么在开发流程里把安全做进去——那里有一个词，叫安全左移的最后一公里。