合规与治理

1 合规与治理要回答什么

订单 API 已经能部署到云上：应用运行在计算服务里，数据库保存订单，对象存储保存导出文件，身份系统决定谁能操作，日志平台帮助排查故障。现在客户提出要求：订单数据只能保存在约定地域，生产访问必须经过审批，关键操作必须能够追溯。服务能运行只是起点，团队还需要解释这些要求由谁落实、如何持续执行，以及凭什么相信它们正在执行。

合规关心组织是否满足适用的法律法规、合同和内部制度。治理关心组织如何持续作出决定、分配责任、约束行为并处理偏差。合规要求可能写着“生产数据访问应获得授权”，治理则要把它变成具体流程：谁申请、谁批准、权限何时生效、多久失效、如何检查。不能仅凭某项云功能已经开启，就断言整个业务已经满足某种法规；适用范围和解释仍需要组织内相应负责人确认。

本课把控制理解为降低某类风险的措施。例如，禁止数据库直接暴露到公网，降低未经授权访问的可能性；临时授权自动过期，减少长期遗留权限；持续记录管理员操作，为事后追溯留下依据。控制可以包含技术设置，也可以包含人员职责和操作流程。采购了工具却没有确定谁处理告警，或者写了制度却没人执行，都会使控制留下空缺。

治理首先需要边界。订单 API 的范围可以包含生产账号、部署流水线、网络入口、订单库、备份、导出文件以及运维身份。支付处理若交给外部服务，团队仍需明确接口传递哪些数据、如何管理凭据、如何取得相关责任说明。云平台负责其承诺范围内的基础设施，业务团队负责自己配置的身份、网络和数据使用方式。责任共担需要落实到具体控制，不能只写在架构图的角落。

开始治理时，可以先提出 4 个问题：保护什么，遵守什么，谁来负责，如何证明。回答不必从庞大的表格开始。先选订单导出这类可观察的活动，就能看见身份、数据、审批和日志之间的关系。保护对象明确后，才容易判断某项控制是否覆盖了真正的风险，而不是仅仅增加操作步骤。

还要区分预防、发现和纠正。网络限制尝试预防违规访问，异常访问告警尝试发现偏差，撤销权限与隔离导出文件用于纠正问题。任何单项措施都可能存在失效条件，治理需要让这些措施能够衔接。入门阶段先把链路讲清楚；复杂的自动证明、跨组织认证和法规条文解释，留给相应专业工作展开。

2 控制映射、证据与审计

控制映射是把要求与实际措施连接起来。假设要求编号为 REQ-01，内容是“生产订单数据访问需要经过授权并可追溯”。它可以对应 CTRL-01：通过具名身份申请临时只读权限，以及 CTRL-02：记录授权变更和数据库访问事件。要求通常不能与某个开关简单对应，同项控制也可能支持多项要求。映射的价值是便于检查覆盖范围和发现缺口。

映射表至少说明要求来源、适用资源、控制描述、责任人、检查方式和证据位置。控制描述要能判断是否执行，例如“所有生产导出通过审批任务运行，任务使用限定范围的身份，权限到期自动撤销”。“加强权限管理”没有说明可检查的行为。对于不适用的要求，也应记录判断依据和确认者，避免空白被误认为遗漏，或用“不适用”掩盖尚未落实的工作。

证据是支持判断的记录。审批单可以证明某次请求经过批准，身份事件可以证明何时授予和撤销权限，数据库审计记录可以证明哪个身份访问了什么对象。它们各自证明的事情不同。批准访问不等于实际访问符合批准范围，配置日志保留期也不等于过去整个期间的日志都完整可用。整理证据时，需要明确每份记录能够支持哪项结论。

审计通常会关注控制设计是否合理，以及控制在考察期间是否按设计运行。设计层面可以查看流程、策略和责任安排；运行层面则需要期间内的执行记录、抽样结果和异常处理记录。某天拍摄的控制台截图只反映当时可见状态，很难证明过去 90 天持续有效。抽样可以帮助判断，但样本如何选、总体是什么、有哪些缺失，也应如实说明。

证据还需要上下文。资源名称可能重复，显示时间可能来自不同的时区，人员名称可能随组织变化。记录账号或项目标识、资源标识、事件时间与时区、执行身份、关联请求编号，有助于把来自不同系统的事件接起来。审批系统的请求编号若能传入自动化任务，检索会更容易；无法直接传递时，也要定义可靠的对应方法，而不是凭相近时间猜测。

证据保存也受权限和数据保护要求约束。订单日志可能含有客户标识，导出记录可能暴露业务信息，不能为了审计方便而复制到任何人可读的共享目录。通常应保留原始记录来源、采集时间、访问限制和保留规则，提供满足检查目的的必要字段。若使用校验值帮助发现文件变化，还要理解它只能支持完整性检查，不能单独证明源系统记录了全部事件。

动画沿着 REQ-01 展示审批、授权、访问、撤权和复核。观察时要同时看事件和证据：权限已经撤销但没有留下撤销事件，属于可证明性不足；有撤销事件但权限仍然可用，属于控制执行异常。治理需要分别处理这 2 类问题，不能把材料齐全直接当成业务风险已经消失。

3 数据驻留与访问审批

数据驻留描述数据被存储在哪些地域，相关要求可能还限制处理位置、传输路径或人员访问位置。这些概念需要分别确认。把订单数据库创建在约定 Region，并不自动约束数据库备份、对象导出、故障恢复副本和日志。也不能仅凭访问者坐在某地，就推断数据是否跨境；需要结合实际访问方式、传输内容和适用规则判断。

先画出数据清单与流向。订单 API 的请求进入网络入口，由应用写入数据库；备份服务生成副本；运营任务将订单导出到对象存储；观测服务接收错误日志。每条路径都可能产生新的数据副本。标注数据类别、存储地域、处理服务、接收者、保留时间与删除方式，能够把“数据只能留在这里”转换成需要检查的资源与配置。

地域限制应覆盖资源创建和日常变更。组织可以限制生产资源允许使用的地域，在部署流程里检查目标位置，并定期盘点已存在的资源。限制创建只能约束它实际覆盖的入口和资源类型；历史资源、外部工具生成的文件或未纳入管理的账号仍可能遗漏。发现越界资源后，需要判断包含什么数据、如何停止扩散、由谁批准处置，不能为了消除告警就仓促删除业务资料。

访问审批围绕任务建立边界。运维人员需要调查某笔订单问题时，应填写目的、目标资源、所需操作和持续时间。审批者根据职责和数据敏感程度判断是否必要，执行端再授予最小范围的权限。可以查看脱敏状态字段的任务，不应默认开放客户完整地址；需要诊断应用的人员，也不必因此获得修改备份策略的权限。

批准与执行之间必须有连接。工单里写着“只读 30 分钟”，身份系统却授予永久管理员，说明实际权限没有落实批准条件。较清晰的方案是让申请包含结构化字段，由受控流程授予限定权限，并以执行结果回填工单。系统不支持完全自动化时，也应有操作复核与到期检查，明确人工步骤可能出现的延迟和漏项。

紧急访问需要预先设计。故障处理中可以设立紧急授权通道，要求具名身份、限定权限、短期有效、完整记录，并在事后规定时间内复核。紧急通道的使用次数和原因应进入治理评审。若日常任务总在使用紧急权限，说明普通审批流程可能太慢，或权限设计与实际工作不匹配，需要改进流程，而不是把例外变成默认路径。

最后检查离职、转岗和服务身份。人员不再承担职责时，原权限应被回收；自动化任务的身份也应有负责人、用途和轮换安排。业务访问与管理员访问都可能涉及数据风险，但两者的审批方式未必相同。先对高风险人工访问建立可执行流程，再逐步覆盖批量任务和系统间访问，比把所有行为塞进相同的人工审批队列更容易持续运行。

4 动手：整理一份控制证据链

本次动手只使用虚构记录，目标是整理可复核的证据链。设定任务为“运营分析人员在 14:00 至 14:30 查询生产订单汇总”，不读取客户明细，不运行真实生产操作。准备 1 份审批记录、1 份授权记录、1 份查询记录、1 份撤权记录和1 份复核记录。没有真实系统时，可在文本表格中模拟这些记录，重点观察字段之间能否互相解释。

先建立控制卡片。卡片写明编号 CTRL-01，适用范围为生产订单汇总视图，负责人为数据平台值班角色，控制目标为授权访问并在到期后撤权。通过标准为：申请身份与执行身份一致，授权范围不超过批准范围，授权时间不早于批准时间，撤权不晚于到期时间。若实际系统有执行延迟，必须事先明确可接受边界和异常处理方式，不能事后临时放宽标准。

然后填写请求 APR-204。申请人为 user-17，目的为核对当天订单数量，目标为 order-summary，操作为读取，批准时间为 13:55，有效窗口为 14:00 至 14:30。审批者记录为具有相应职责的角色及实际操作人。这里使用角色表达责任可以避免流程依赖固定姓名，但执行记录仍要能够追溯到当时的具名身份。

把执行记录按时间接上：14:00 授予临时角色，14:08 查询汇总视图，14:30 撤销角色，14:35 完成复核。各记录携带 APR-204 或明确的关联字段，并包含来源系统与资源标识。将显示时间统一到约定时区，同时保留原始时间信息。遇到系统时钟偏差，应记录偏差来源和影响，不要直接修改原始事件时间以使顺序看起来整齐。

接着故意移除 E-04。此时不能因为批准窗口已经结束就填“撤权成功”，应填“缺少撤权证据，当前无法确认”，再检查身份状态与事件采集情况。当前已无权限只能说明检查时的状态，无法单独确定历史撤权时间。如果发现权限实际持续到 15:10，则记录超时事实、影响范围和修复动作，并评估这段期间是否存在访问。

整理后的材料应包含控制卡片、证据索引、受控的原始记录位置和复核结论。证据索引帮助检查者找到材料，原始记录提供核对依据，复核结论解释通过、失败或无法判断的原因。不要把所有原始客户信息复制进练习包。练习完成的标准是另一个人能够沿着编号重建事实，并能指出哪些结论仍缺乏支持。

5 合规速度与业务速度取舍

审批和复核会消耗时间，但缺少控制也会产生代价：权限扩散、误删数据、调查困难，甚至无法兑现合同承诺。治理的目标是让风险与处理成本可见，并为不同活动选择合适路径。读取公开商品目录、调整生产网络入口、导出客户地址，风险和影响明显不同，不应只因为都发生在云平台里就采用相同的审批强度。

可以先把请求分成常规、敏感和紧急路径。常规任务在预先批准的范围内自动执行，例如部署已通过检查的配置；敏感任务需要额外审查，例如扩大数据导出范围；紧急任务通过受控通道快速处理，并接受事后复核。分类标准必须具体，例如涉及的数据类别、权限级别、是否对外传输及影响范围，避免全凭审批者当时的直觉判断。

自动化能降低重复劳动，但前提是规则明确。把固定地域检查放入部署流程，把临时权限到期撤销交给系统，把证据编号自动写入任务记录，可以同时提高执行一致性和交付速度。对业务目的是否合理、异常是否可接受等判断，仍可能需要人员负责。自动审批并不意味着无人承担责任，规则的制定者和维护者同样需要明确。

滑块展示同组假设请求在不同人工审查比例下的排队时间与审查工作量。模型只帮助理解容量关系，不预测真实风险概率。人工审查比例提高时，若审核能力不变，等待可能增加；增加审核能力或将低风险规则自动化，可能缓解等待。不能把较短等待直接理解为不安全，也不能把更长审批理解为控制更有效。

看取舍时，应同时观察交付和控制结果。可以记录常规请求的等待时间、权限超时比例、紧急访问次数、证据缺口数量和异常关闭时间。平均等待会掩盖少量长时间阻塞，因此还要看较慢请求的情况和具体原因。如果某项检查几乎总是机械通过，却持续阻碍交付，可以评估是否转换成自动检查；涉及实质判断时，则应改善信息质量或增加处理能力。

例外需要期限和责任。某个旧服务暂时无法自动撤权，可以采用人工复核作为临时补偿措施，但必须说明风险、负责人、到期日期和改造计划。补偿措施是否足够，应由有权承担风险的角色确认。例外到期后需要重新判断，不能通过反复延长期限让问题从治理视野消失。取舍只有被记录、可追踪，才可能随着业务变化持续调整。

6 常见坑：截图当持续控制

截图适合说明某时刻的配置或界面，也可以作为操作说明的辅助材料。问题出在把它当成整个期间的持续证据。某张截图显示日志已启用，仍无法回答上周是否被关闭、哪些资源未接入、采集是否中断、日志能否检索。持续控制需要检查状态如何变化，以及变化后是否产生了应有的记录和响应。

还常见“有日志就能审计”的误解。应用错误日志主要帮助定位程序异常，未必记录身份授权、管理员变更或数据读取。记录登录成功也不能证明登录后的每项操作均有记录。团队应按控制目标选择事件类别，检查关键字段、覆盖资源和采集路径。数据库读取记录可能需要额外配置与成本评估，不能默认所有云服务都会完整提供。

可用的证据链需要监测自己是否失效。例如检查日志接入资源数量是否符合清单，近期是否持续到达，是否出现采集错误，以及受控测试事件是否能在预期位置检索到。没有新日志可能是业务安静，也可能是采集失败，必须结合事件预期判断。观测到延迟时，还要区分事件发生时间和入库时间，避免把迟到误判为从未发生。

“材料很多”也不等于“覆盖充分”。大量日常部署截图可能无法证明高风险的数据导出经过授权。反过来，只有成功记录而没有失败记录和例外清单，也可能隐藏真实问题。证据应围绕控制目标组织，覆盖适用总体、检查期间和已知偏差。对缺失部分写清范围和限制，比使用重复材料制造完整印象更有助于改进治理。

保留设置同样容易被误解。日志配置保留 180 天，不代表已经积累 180 天历史，也不保证数据在需要时能顺利恢复。归档格式、访问权限、查询能力和删除流程都影响证据可用性。可以定期抽取允许访问的历史样本，验证能否定位和读取。保留时长要依据适用要求与业务需要确定，不能认为保存越久总是越好。

最后，不要让执行者只复核自己的工作。资源负责人负责落实控制，复核角色检查证据与偏差，风险责任人处理重大例外，这种职责安排有助于发现遗漏。规模较小的团队可以采用交叉复核等现实办法，但仍需说明谁检查了什么。治理流程如果只有“大家共同负责”，通常意味着出现问题时很难找到真正的处理入口。

7 案例：审计前夜补日志失败

订单团队接到检查通知，需要说明过去 90 天的生产数据导出是否经过授权。团队能找到当前权限配置和部分工单，认为只要补开数据库审计日志，再导出几张截图就够了。实际排查发现，管理员变更日志一直开启，但数据库读取事件此前没有接入，应用只记录导出任务成功与否，也没有保存统一的申请编号。

新开启的日志开始记录后续访问，却不能重建此前没有采集的读取事件。工单可以证明某些导出获得批准，应用记录可以证明某些任务运行过，但两者缺少稳定关联，无法确认全部导出均有对应审批。检查者还发现，离职人员的旧自动化凭据仍然有效，任务记录里的共享身份无法准确对应实际操作者。

团队最初尝试通过文件修改时间反推导出活动，这只能提供线索。文件可能被复制或重新生成，时间含义也不等同于原始读取时间。若把这种推断直接填写成完整访问清单，会把不确定性带入结论。正确做法是保留线索来源，说明其可支持的范围，并与工单、对象存储事件和任务记录交叉核对。

处理顺序先控制当前风险：确认现有访问身份，撤销无主凭据，收紧导出入口，并在变更前保留必要现场记录。随后界定历史缺口，包括受影响资源、缺少的事件类别和起止时间。能取得的记录继续核对，不能证明的部分如实报告。是否构成进一步事件、是否需要对外通知，应交由组织规定的责任角色依据事实和适用要求判断。

修复方案把导出统一到受控任务，每次运行必须关联批准请求，使用可追溯身份，并记录输出对象标识和执行结果。新增监测检查日志采集是否正常，定期验证到期撤权和历史证据检索。改造后积累的记录支持新的运行期间，历史缺口则保留在问题清单中。可以说明缺口已经停止扩大，但不能声称过去的证据已因新配置而恢复。

这个案例的教训是，证据应随控制运行自然产生，并持续检查其可用性。审计前整理材料可以改善呈现方式，却无法替代过去的执行。对订单 API 来说，提前让部署、授权、数据操作和日志使用共同的资源标识与关联编号，通常比临时拼接截图更容易建立可信的事实链。

8 把治理流程写进合规方案

合规方案需要把要求翻译成日常工作，而不是只罗列服务名称。先写适用范围：哪些生产账号、应用、数据库、备份、导出任务和人员活动纳入管理，哪些外部依赖需要责任说明。接着写控制目标与责任角色，例如数据负责人确认导出用途，平台团队维护身份流程，服务负责人处理资源偏差，复核人员检查证据与异常关闭情况。

控制条目可以采用固定结构：要求来源、目标风险、适用对象、执行方式、检查频率、证据位置、失败处理和例外期限。执行方式要能落到动作，例如部署前校验地域、临时访问自动撤权、每日检查日志采集健康。检查频率应结合风险和实际能力确定；涉及持续状态的控制，仅写“年度检查”可能无法及时发现长时间暴露，需要说明期间如何监测。

方案还要写清变更入口。新建数据库、增加备份地域、引入外部分析服务，都会改变既有数据流和证据范围。应在相应变更流程中检查数据类别、访问主体、地域、日志覆盖和负责人。对低风险变更可采用预定义规则快速检查，对新增敏感数据路径则升级审查。这样治理才能跟随架构变化，而不是只在项目上线时出现。

异常处理应有可以执行的闭环。发现生产日志中断后，谁接收告警，多久开始调查，如何判断缺口范围，何时恢复采集，谁确认恢复有效，都需要安排。恢复服务与补齐事实调查可能不是同时完成，应分别跟踪。无法补回的历史记录需要保留限制说明，并判断是否需要额外控制，不能仅以“告警已恢复”关闭所有问题。

治理会议也要围绕事实。可以定期查看未关闭例外、超时权限、无主资源、采集缺口和重复出现的审批阻塞，再决定资源投入与规则调整。会议的产出应是有负责人和期限的行动项。对于已经连续稳定执行的控制，可以减少重复人工整理；对于反复失败的环节，应分析流程、工具或职责是否存在根因，而不是只要求填写更多表格。

最后定义方案如何更新。法规或合同要求变化、服务边界扩大、数据分类调整和重大异常，都可能触发重新评估。记录方案版本、变更原因与批准角色，让证据能够对应当时适用的控制版本。入门方案不必追求覆盖所有可能性，但必须让范围、责任、执行与证明形成闭环，并允许新发现的问题进入改进流程。

9 从合规与治理走向云迁移（C60）

迁移会改变资源位置、身份边界和运维方式，因此也会改变控制落点。原来机房通过跳板机保存操作记录，迁到云后可能改用临时身份与集中日志；原来备份保存在本地，迁移工具可能默认生成新的临时副本。只复制应用和数据库，容易遗漏这些治理依赖。迁移计划应同时说明业务怎么搬，以及已有要求如何在目标环境继续满足。

在迁移准备阶段，把本课的控制映射用作检查清单。确认源端与目标端的数据类别、驻留地域、访问权限、日志来源和保留规则，识别哪些控制可以沿用，哪些需要改造。迁移服务使用的临时凭据、同步通道和中间存储也要纳入范围。它们存在时间可能较短，但可能拥有大量数据读取权限，不能因为“迁完就删”而省略负责人和回收步骤。

切换前应验证目标端能产生所需证据。例如在测试环境执行经过批准的访问，确认授权、访问和撤权记录能正确关联；验证备份位于允许地域，恢复后权限与日志配置仍符合设计。验收需要基于实际结果，而不仅是配置计划。测试数据和生产数据的风险不同，正式迁移时仍要检查实际资源与身份是否保持了批准条件。

切换期间需要安排源端与目标端的责任交接，避免出现双方都认为日志由对方保留的空档。迁移后确认临时权限已回收、中间副本按规则处理、源端历史证据仍可检索。回滚方案也应遵守相同的数据与访问约束。下一课 C60 将把这些约束放入迁移步骤，讨论如何安排依赖、验证和切换，让业务连续性与治理要求共同进入计划。

放进方案里

本方案覆盖订单 API 的生产应用、身份权限、网络入口、订单数据库、备份、导出对象及相关日志。上线前建立资源与数据流清单，记录数据类别、实际地域、访问主体、责任角色和保留规则，并将法律法规、合同及内部制度中的适用要求映射到具体控制。要求适用性由相应责任人确认，服务清单或平台认证材料作为责任判断的参考依据。

生产数据访问采用具名身份和限定任务范围的临时权限。申请记录用途、目标资源、操作类型与有效时间，批准后由受控流程执行，到期撤权并保留结果。紧急访问使用预先定义的通道，限定权限与时长，记录原因并进行事后复核。服务身份明确负责人和用途，人员转岗、离职及任务停用触发权限回收检查。

控制证据按要求编号与请求编号关联，覆盖审批、授权、实际操作、撤权和复核。日志接入后持续检查覆盖范围、采集状态及必要字段，按适用要求设置保留期限与访问限制，定期验证历史记录可定位、可读取。截图用于辅助说明时点状态，持续执行情况通过期间记录与复核结果支持，证据缺失如实标明范围和影响。

新增地域、数据出口及高权限操作进入变更审查；明确规则的常规任务通过自动检查减少等待。控制失败进入异常流程，记录处置人、影响范围、修复期限和确认结果。例外写明风险、补偿措施、批准角色与到期日期，定期复评。迁移前验证目标环境的控制与证据链，切换后回收临时权限、处理中间副本，并保留源端历史证据的访问安排。

10 小结：下一步云迁移（C60）

合规与治理把要求连接到范围、责任、控制和证据。数据驻留要覆盖副本与数据流，访问审批要落实到实际权限，持续控制要有期间记录与异常处理。证据链存在缺口时，应界定事实和限制，修复当前控制，并持续积累后续证据。

检查自己能否回答 3 个问题：只有当前配置截图，能否证明过去 90 天持续有效？临时权限获得批准后，还需要哪些执行记录？迁移时新增的中间副本应由谁管理？带着这些问题进入 C60，将更容易理解迁移为什么同时需要技术步骤、验收条件和责任交接。