云安全架构：安全验收 landing zone 中的云账户

当平台团队必须决定是否把新的 AWS 账户、Azure 订阅或 Google Cloud 项目交给产品团队时，云安全架构需要为这项运行决策提供依据。架构图可以画出正确的文件夹、组织单元、策略与集中日志，但仍可能没有回答关键问题：子资源实际生效了哪些控制，哪些身份不受这些控制约束，旧资源会如何处理，谁能批准例外，以及有害的控制平面变更如何回滚。

虚构场景 — Northstar Retail。 公司准备把支付工作负载接入多云 landing zone。平台团队表示，所有子资源都会继承企业基线。支付负责人却发现一个 Azure 豁免、一项依赖服务相关角色的 AWS 工作负载，以及一个从旧文件夹迁移来的 Google 项目。生产数据进入前，采购方必须接受或拒绝该环境。“已经分配策略”不能作为验收标准；Northstar 需要最终状态的证据，也需要为每个缺口指定负责人。

先定义验收决策

Landing zone 是云账户、订阅和项目的按照统一规则管理的基础环境。它规定资源层级、身份入口、网络模式、日志目的地、策略部署、所有权和生命周期。因此，安全架构应表达可验证的决策与不变量，而不是云厂商功能清单。

为每类工作负载写一条简短验收声明。例如：生产环境只有在以下条件全部满足时才能放行——子资源位于预期父级之下；有效限制与批准基线一致；必需遥测到达中央目的地；各环境的管理员无法移除受保护控制；每个例外都有负责人和到期日；无害的控制测试（canary）同时证明预期允许路径与拒绝路径。还要写明声明之外的内容，例如某个不受所选组织策略约束的云厂商托管身份。

这种做法可避免两类采购错误。冗长的控制清单可能掩盖缺失的管理边界；绿色合规面板可能把预防、检测与尚未修复的资源混为一谈。验收决策会迫使平台团队说明：什么已被阻止，什么只是被发现，什么仍是待完成的运营工作。

建立有效策略验收矩阵

分析单位应是工作负载、完整祖先链，以及相关身份层。只收集直接分配给子资源的策略，会漏掉继承；只查看组织基线，则会漏掉子级覆盖、排除和云厂商特有的例外。对一个代表性生产子资源，以及每种实质不同的接入模式，都应完成下表。

组织级防护规则设定权限上限或配置限制，但不会自动向工作负载授予所需权限。运行时 IAM、资源策略、网络访问、加密、服务配置和应用授权仍是不同层。矩阵必须指出每项主张由哪个层证明。

AWS：追踪完整 SCP 路径并保留边界

在 AWS Organizations 中，服务控制策略（SCP）限制成员账户内 IAM 用户和角色可获得的最大权限。SCP 本身不授予权限。在允许列表设计中，相关操作必须在组织根、路径上的每个组织单元（OU）和账户层都保持允许；路径上任一明确 deny 都会优先。账户仍需要 IAM 或资源策略实际授予操作。

验收证据应包含账户的组织路径、所有适用 SCP 的标识、受控内容修订或内容哈希、策略关联状态，以及一组小型测试。一个控制测试应在刻意收窄的 IAM 授权下成功执行预期允许的操作；另一个应尝试被目标组织级防护规则拒绝的无害操作。保存主体、账户、API、结果、错误原因和控制平面事件。拒绝本身不能证明 SCP 生效，因为缺少 IAM 权限或错误请求也会失败；必须有正向对照和指向预期 SCP 的策略拒绝依据。

安全结论必须保留 AWS 的适用边界。SCP 不约束管理账户中的用户和角色，也不约束服务相关角色；当组织外主体通过成员账户资源的资源策略访问时，SCP 也不会仅因资源位于该成员账户就直接约束外部主体。架构应把工作负载移出管理账户，尽量减少其访问权限，并分别评估服务相关角色与外部资源访问。

AWS 建议在广泛附加 SCP 之前先测试影响，例如使用测试 OU，并以受控批次移动账户。回滚计划还要保护允许链：错误移除或替换允许策略，可能阻断其下方账户。变更记录应保存原策略关联状态与内容、控制测试账户、恢复操作人，以及该操作人不会被新策略锁定的证据。

Azure：区分评估、执行和修复

Azure Policy 的不同执行效果 具有不同运营含义。Deny 可以阻止匹配的创建或更新请求，而已有匹配资源只会被标记为不合规。Audit 记录合规结果，但不阻止请求。Modify 可以在创建或更新时更改支持的字段，但评估周期不会自动改写旧资源。DeployIfNotExists 和 modify 可通过明确的修复任务使旧资源接近合规。

因此，一个订阅即使继承了管理组上的采用 deny 效果的策略集合，也可能同时包含旧的禁止配置。验收时应取得分配适用范围、参数、排除项、执行模式、合规快照，以及与快照核对过的资源清单。对 modify 与 DeployIfNotExists，还要取得修复任务状态和失败资源明细。“Non-compliant”证明发现了问题，并不证明问题已修复。

修复过程还有独立的权限边界。策略分配的托管身份执行部署或修改，需要定义中列出的角色。应把这些权限视为控制平面权限：缩小适用范围，明确谁可变更策略定义或策略分配，并确认回滚不会留下不必要访问。授予修复身份的权限过宽，可能破坏原本受限的工作负载管理模型。

Azure 提供独立的策略豁免对象。可审查的豁免应记录策略分配、涉及的策略定义、类别、适用范围、申请人、批准人、工单、到期日和补偿措施。资源选择器可以支持逐步覆盖。安全部署方法还可使用分阶段策略分配、初始不强制模式、自动合规检查、健康门禁和按层扩展。采购方需要这条变更路径，而不只是最终 JSON。

Google Cloud：按约束类型计算继承

Google Cloud Organization Policy 限制资源如何配置，IAM 决定谁可以采取操作。组织策略不会给项目负责人授予访问，IAM 授权也不能证明某项配置被允许。接入验收必须分别验证两层。

不要假设父级的限制一定会向下累积。有效行为取决于约束类型和子级策略。旧式列表规则在启用继承时可以与父级合并，合并时 deny 值优先。布尔规则不合并：子级值就是该子级的有效值。继承父级的托管约束按父级设置整体执行，或者由子级策略覆盖；它不会像旧式列表规则那样合并。因此，项目级覆盖设置可以显著改变结果。

对每项关键约束，记录其类型、父级策略、子级策略、继承或覆盖设置、条件和标签、有效结果，以及控制测试操作。试运行有助于执行前观察，但验收必须区分试运行结果与强制执行中的策略。策略传播需要时间，因此证据时间戳，以及传播后首次成功或被拒的操作都很重要。

Organization Policy 的变更通常不会追溯修改旧资源。旧资源可能持续处于违反状态，直至团队处理；只有约束明确说明追溯执行时才是例外。接入证据包应把有效策略与现有资源清单查询放在一起。对自定义约束，还要确认目标服务、资源类型、方法和字段受支持；存在一个定义，并不表示它覆盖了架构假定的所有操作。

把接入设计成证据驱动的状态转换

账户工厂或订阅发放流程只有在能把请求变成可预测状态时才有价值。门禁应足够明确，使审计人员能够重放，使平台工程师能够诊断失败。

1. 请求绑定工作负载类别、数据敏感度、区域、负责人和例外需求
2. 放置在批准父级下创建或移动子资源，并验证完整层级
3. 有效状态导出实际组织级防护规则、IAM 边界、日志状态和未解决旧资源
4. 验证执行无害的允许与拒绝操作，并关联控制平面记录
5. 接受签署证据包、记录例外到期时间，并登记配置漂移与回滚负责人

接入失败后，子资源应留在专门设计的受限状态，不获得生产身份和数据。这里的“受限状态”不是云厂商自带的神奇标签，而是具体的父级、策略、网络和允许操作组合。流程不能把子资源暂时放在宽松父级下，再依赖未来迁移。如果必需服务需要例外，应在放行前建立例外记录、测试补偿控制，并确定移除或续期日期。

证据要绑定不可变 ID 和受控修订。“生产订阅合规”如果没有订阅 ID、策略分配修订、评估时间和未解决数量，无法支持验收。当云厂商没有为某项主张提供单一有效策略导出时，应保存输入和计算程序，让另一位审核者能重建结果。

分别管理旧资源与例外

预防性策略、现有资源修复和例外具有不同完成条件。预防登记表确认新建或变更资源是否按设计被阻止或转换；修复登记表跟踪旧资源、负责人、动作、失败原因和复测；例外登记表记录主动偏离、风险决定、补偿控制、适用范围和到期日。

不要因为基线出现正确规则就关闭现有资源问题。只有当资源被删除、更改、隔离或明确接受，并且证据与处置一致时，才能关闭。也不要把每个不合规资源都称为例外：它可能是部署错误、等待批准窗口，或策略查询并不适用。混合这些状态会破坏问责。

例外到期必须有可执行后果，例如阻止新部署、移除访问、创建工单、把子资源转入受限状态，或升级续期决策。到期本身不会修复旧资源。生产接入前应测试后果机制。紧急访问应有独立负责人和证据链，不能藏在永久排除项中。

明确控制平面所有权并测试回滚

工作负载负责人通常不是组织策略负责人。可运行的模型至少应明确四类权力：基线作者、部署操作人、例外批准人和工作负载应急响应负责人。规模与风险适合时，应分离策略提议、批准、部署和子资源豁免能力。

每次重大组织级防护规则变更都应包含受控变更差异、受影响层级、预期新增违规、控制测试批次、传播时间、健康与合规门禁、停止条件和回滚方法。回滚测试应与发布测试同等严肃。确认恢复旧状态所需的凭据、紧急恢复访问路径、策略仓库和部署系统，在新策略生效后仍可使用。

监控应检测两个方向的配置漂移：限制消失，以及未经测试的限制出现。重要事件包括策略或层级变更、子资源移动、豁免创建或延期、修复身份的角色权限授予、日志目的地变更和控制测试失败。把事件关联到变更记录，响应团队才能区分批准发布与未经授权的控制平面活动。

明确供应商应交付的证据

有用的交付物应包括：层级与所有权地图；按云厂商拆分的有效策略矩阵；账户、订阅和项目样本证据；旧资源核对；豁免与修复登记表；控制平面权限路径；发布和回滚测试结果；带假设的验收决定。每项发现都应写出失败的安全主张、受影响子资源、可复现查询或无害操作、责任人和复测标准。

询问供应商如何对大型环境采样、重建有效策略、处理厂商例外、区分预防与修复，以及在不扰动生产的情况下验证回滚。仅按云账户数量估算范围并不可靠。工作量由不同层级模式、策略变体、例外类别、旧资源清单、控制平面身份、控制测试和复测数量决定。

多云安全评估指南适合建立跨云安全保障框架；混合云安全审计则覆盖本地与云之间的身份、网络、代理和证据。本文的 landing-zone 决策应聚焦组织级防护规则与子资源验收。

在重大迁移之前、层级重构之后，或者多个团队无法给出一份可辩护的验收包时，独立检查会有帮助。在书面授权和明确适用范围下，Pentest.red 云安全审计可以审阅有效控制与约定的只读导出；如另行批准所需权限，也可执行选定的无害控制测试，并交付可复现缺口、负责人和复测标准。它不能保证未来每次云变更都安全；成熟平台团队也可能自行完成验收。范围规划工具可明确子资源、身份、例外、测试动作和停止条件，示例报告展示如何区分证据、影响与修复。