混合云安全审计：验证本地环境与云端之间的信任边界

混合云并不只是连接到云账户的本地基础设施。它是一条跨越目录、令牌签发方、路由器、管理代理、日志系统和多个运维团队的信任链。如果审计只检查云租户，却把数据中心当作黑盒，最容易遗漏的恰恰是使架构成为“混合”的路径。反过来也一样：常规内网检查无法说明同步身份、云角色或远程代理究竟能对本地系统做什么。

因此，采购方真正要问的不是“Azure、AWS 或 Google Cloud 配得安全吗”，而是：“哪些身份、命令和数据可以穿过每条边界，哪项控制应当阻止它们，我们能否用证据证明控制确实生效？”本文把这个问题转化为范围、证据计划、安全验证方法和复测标准。它与多云安全评估指南互为补充，重点是本地到云端的信任关系，而不是比较多个云环境。

审计对象是一条边界链

应从业务流开始，而不是从云厂商检查表开始。工资数据可能源自本地数据库，经专线传输到对象存储，再触发云函数。管理员可能使用 Active Directory 身份登录，取得云令牌，然后从云控制平面调用特权扩展，操作仍位于数据中心的服务器。每条流程都跨越多道相互独立的边界。

这会改变“安全”的含义。私有路由不能证明传输已加密；目录对象完成同步，不能证明禁用源账户后所有会话立即结束；存在云管理日志，不能证明敏感数据读取被记录；角色名称里有“监控”，也不能证明代理没有特权执行能力。审计需要把每项安全主张对应到实际使用的产品模式、加密端点和日志类别。

最好把边界登记表作为范围的核心文档。每一行列出来源、目标、协议或代理、身份、数据类别、预期控制、证据负责人和失效影响。它比扁平资产清单更有价值，因为能显露责任交接：网络团队可能负责专线，IAM 团队负责联合身份，平台团队负责订阅，而在身份变化后仍有效的应用 Cookie 由应用负责人控制。

范围必须让混合系统可以被完整枚举

合格的范围要识别每次跨越的两端。云端包括租户、组织、账户、订阅、项目、区域和相关资源组；本地侧要对应列出林、域、身份提供方、联合服务器、同步主机、DNS 区域、地址空间、网关、运营商线路、代理服务器和远程管理代理。如果 SaaS 应用的会话或预配依赖混合身份路径，也应纳入模型。

不能在没有清单日期和核对方法的情况下接受“全部生产环境”这种表述。云组织导出结果应与计费账户、身份目录、网络路由清单和 CMDB 互相核对，并抽查最近创建和最近退役的资产。孤立订阅、陈旧连接器和断开连接的代理很重要，因为系统台账显示资产已删除后，它们仍可能保留凭据或信任。

范围排除项应写成可验证的假设。如果运营商管理的网段被排除，要写明两端及运营商提供的保证。如果生产应用不能测试，要指定代表性环境，并列出会影响身份、路由或日志的差异。没有补偿证据的排除项仍是未知项，不能算控制通过。

清单还应保留采集时间和负责人，避免把不同日期的导出误拼成同一时刻的架构。对于动态创建的短期资源，可从组织级配置记录、账单记录或日志中重建存在区间，再判断其是否落在测试窗口。这样既能发现“当前已经不存在、但曾经承载信任”的资源，也能解释为什么某条证据无法在现场再次获取。

身份同步、联合与访问撤销

应为每种重要身份绘制认证路径：员工、承包商、服务账户、紧急管理员和工作负载身份。图中要包括权威目录、同步或联合组件、令牌签发方、条件访问决策、组到角色的映射以及应用会话。如果启用了密码写回、用户预配、取消预配或设备状态，还要补充反向路径。

撤销访问是一串动作，不是单个开关。在 Microsoft Entra ID 中，阻止登录并撤销刷新令牌后，资源已接受的访问令牌或应用自身会话仍可能继续有效；持续访问评估也只在受支持场景生效。因此要分别测量新认证、令牌续期、资源接受和应用会话终止。

安全测试应使用专用账户和事先约定的最长观察窗口。先建立会话并记录令牌与 Cookie 时间，再按正常事件响应流程禁用账户，随后观察每个边界，不尝试规避控制。还应在自身会话具有实际风险的关键 SaaS 或内部应用上复测。结论不应只写“撤销耗时 N 分钟”，而要说明哪种凭据在什么依赖方、什么配置下仍然有效。

同步主机本身也属于关键基础设施。审计要检查谁能管理它，服务账户和证书如何保护，配置变更记录在哪里，以及本地管理员遭入侵后能否通过组成员关系影响云角色。反方向则检查云端写回或预配路径能否修改本地对象。目标是识别两个方向的权限传递。

私有连接与加密是两项不同控制

对每条 Direct Connect、ExpressRoute、合作伙伴互联、VPN 和应用隧道，要分别记录物理或逻辑连接端点与加密终止端点。AWS Direct Connect 默认不会加密传输流量。MACsec 保护特定设备之间的二层链路，不会跨多个连续网段自动形成端到端加密。配置模式也很关键：协商失败后允许明文回退，与协商失败即停止传输，提供的是不同保证。

ExpressRoute 流量也默认不加密。ExpressRoute Direct 可用 MACsec 保护客户到 Microsoft 的物理链路；IPsec 则覆盖配置好的本地网关到 Azure 网关路径。应将这些端点标在应用流图上，对剩余网段单独决定保护措施，例如 TLS。

审计要把架构图与实时状态核对：线路类型、对等连接、路由通告、故障转移路径、加密模式、密钥负责人、轮换流程和监控。故障切换应在维护窗口测试，或检查最近一次受控演练的证据。还要确认备用路径不会悄然绕过检查或加密。主动操作风险过高时，先用只读方式验证配置与状态，再约定由系统负责人执行的窄范围测试。

远程管理代理可能反转信任方向

混合代理可能建立从云角色到本地特权进程的路径。对 Azure Arc 服务器，Custom Script Extension 和 Run Command 默认以 Windows Local System 或 Linux root 身份执行脚本。主机侧限制可以缩小路径，但新增允许列表不会删除已安装扩展。

不能简单断言“任何云 Contributor 都等于 root”。要核实实际分配的 Azure 角色、允许的扩展操作和主机有效状态，并把两层一起测试：云端有权提出请求，与主机最终接受请求，是两个不同条件。发现项必须描述真实存在的组合路径。

验证可在非关键或专用测试主机上执行预先批准的无害操作，例如请求安装一个理应被拒绝的扩展，或运行约定命令，把随机标记写入临时测试位置。随后关联云活动事件、代理日志和主机事件。未经单独、明确授权，不应投放任意载荷、关闭终端防护或在域控制器上测试。

证据必须同时覆盖控制平面和数据平面

脱离范围、时间和身份的配置截图是弱证据。应优先使用机器可读导出，保留租户或账户标识、采集时间及所用命令或 API；流程允许时，还可保留哈希或不可变副本。每项关键控制需要三类证据：设计证据说明预期行为，运行证据说明相关期间实际记录了什么，验证证据说明授权测试时发生了什么。

云日志默认值特别容易被误解。在 AWS CloudTrail 中，管理事件描述控制平面操作，跟踪和事件数据存储默认记录此类事件；对象级访问等数据事件需要显式选择。Google Cloud 会写入 Admin Activity，而 Data Access 除特定服务例外外通常默认关闭。因此，“已启用 CloudTrail”或“存在 Audit Logs”并不能证明敏感对象读取、函数调用或数据库数据操作可见。

事件矩阵应从威胁模型生成。行表示重要动作：修改联合设置、附加管理员策略、改变路由、安装代理扩展、读取敏感对象、使用紧急账户、修改日志汇聚规则以及触发拒绝访问。列中写明预期来源、事件类别、身份字段、目的地、保留期、告警和证据负责人。对有代表性的行执行一次无害已知事件，并端到端追踪。字段脱敏、不支持的服务和抽样限制要明确记录。

证据索引要把每项结论链接到具体导出、查询条件、时间范围和测试标记，而不是只附一批截图。若云端事件只证明请求已提交，本地代理日志应补充请求是否执行；若主机只看到进程启动，云端身份字段应补充是谁通过哪项权限触发。多层证据相互校验，才能区分配置存在、控制运行和业务结果三件不同的事。

1. 资产清点枚举两端、信任对象、代理与负责人
2. 配置取证导出身份、网络、代理和日志的有效状态
3. 受控验证使用唯一标记执行获批的无害动作
4. 事件关联在云端、代理、主机和检测系统中查找同一标记
5. 整改复测修复后重复相同验收测试

安全验证需要明确的授权边界

交战规则要列出账户、主机、应用、测试窗口、源地址、允许动作、数据处理规则和停止条件。应指定能叫停测试的技术负责人，并明确谁监控生产健康。联合配置、密钥轮换、路由切换和管理代理尤其需要这样做，因为很小的技术动作也可能中断认证或连接。

选择能回答问题的最低侵入方法。先做只读导出和日志查询；审计方不需要写权限时，由系统负责人执行变更；使用专用测试身份和合成对象。如果被拒绝本身就能证明控制，应优先测试预期被拒绝的操作。若判断影响必须涉及利用，应约定安全证明边界：证明可达权限或执行原语即可，不访问业务数据，也不在主机上持久化。

这也是云红队评估与本文审计的差别。红队会追求约定的对手目标并串联弱点；混合云审计在取得可重复证据，证明边界主张不成立且足以整改后即可停止。如果主要需求是基线核验，而不是跨边界攻击路径分析，可参考安全配置审计。

发现项应指向失效的责任交接

有用的发现项要写清源端状态、跨越动作、目标端影响和缺失证据。“ExpressRoute 未加密”过于宽泛；可执行的表述应是：“运营商线路为私有，但端点 A 到工作负载 B 的应用流量在边缘链路终点之后没有可验证的加密。”同样，“撤销太慢”应改成：“云账户无法取得新令牌后，应用 C 仍接受自身会话，直至其配置的过期时间。”

整改要分配给真正能改变控制的团队，并列出依赖关系。IAM 可以缩短令牌暴露时间，但应用会话失效由应用负责人实现；网络团队可以启用 MACsec，但链路端点后的 TLS 仍由应用负责；云平台团队可以限制 Arc 角色，服务器团队还要配置本地允许列表并清理现有扩展；安全运营可以建立检测规则，服务负责人仍需启用相应数据事件源。

优先级应依据可信攻击路径和业务影响，而不是产品标签。从大量分配的云角色通往本地身份服务器特权执行的路径可能跨越管理层级，应优先处理。低价值对象缺少读取日志可能紧迫性较低，但若妨碍调查受监管数据访问，仍然重要。假设应明确写出，不应夸大确定性。

复测标准要写进原始发现项，包括要重新执行的导出或查询、要运行的无害动作、预期拒绝或事件，以及允许的最长传播时间。如果问题针对实际行为，仅看到配置项存在并不能关闭发现。

采购方应获得什么

最终交付应包含高风险信任路径的管理摘要、边界登记表、范围与排除项、架构视图、证据索引、可重复发现、整改负责人和复测用例。渗透测试报告示例可帮助采购方判断证据深度，范围规划工具则可在采购前整理账户、身份系统、线路、代理和应用。

评估工作量不应只按“几个云账户”估算。真正驱动投入的是信任路径数量、身份类型、线路与加密端点、代理覆盖的主机、需要验证的日志类别、允许的手工验证以及复测轮次。范围较窄但跨多个管理团队的关键身份路径，可能比资源很多却高度标准化的单一环境更费协调。供应商应解释这些变量怎样影响报价和时间，而不是给出缺乏边界定义的固定承诺。

还应询问评估方怎样管理临时访问、生产安全、多管理员团队协作，以及被排除的运营商或 SaaS 网段如何取得证据。确认其是否区分控制平面与数据平面可见性，复测究竟重复行为还是只复查设置。这些回答比很长的云厂商基准清单更能说明方法质量。

临时访问方案应说明测试身份由谁创建、权限何时到期、证据如何移交以及工作结束后怎样确认撤销。多团队环境还要有统一联系人和升级路径，避免网络、身份、平台与应用团队分别认为关键控制由对方负责。

当责任分散、迁移后多套控制重叠，或组织无法证明事件响应动作会跨边界传播时，独立评估尤其有用。Pentest.red 的云安全审计可在约定范围内结合 IAM 与联合审查、只读配置分析、选定的手工验证和攻击路径推理。如果团队已经理解信任路径，只需弥补一个窄证据缺口，内部证据演练也可能是合适的下一步。目标是用可辩护的证据回答：混合系统实际上如何运行、每项修复由谁负责，以及如何再次验证。