# 本地执行记录可以支持 SOC 2 CC7 证据 本地防篡改执行记录可以支持 SOC 2 CC7 证据，但它无法单独承担 CC7.1 或 CC7.2 的全部证明责任。它可以显示哪个本地智能体进程启动了会话、该进程尝试了哪些需要凭据的调用、调用如何结束，以及存储的历史是否被更改。它无法显示范围内的每个系统都接受了漏洞监控，也无法证明有人按计划调查了异常。 这个边界很重要。我见过一些团队把一份签名完备的日志导出文件交给审计员，并称它就是自己的监控控制。导出文件证明事件存在过，却没有证明覆盖范围、检测逻辑、审查、升级处理或修复。把本地记录当作控制体系中的一个证据来源，它就有用。把它当成控制本身，抽样时就会暴露缺口。 实际检验方法很简单：把每项声明连接到一个字段、一套程序、一名负责人和佐证材料。如果缺了其中一项，要在审计员指出前先写清限制。 ## CC7.1 和 CC7.2 问的是不同问题 CC7.1 关注组织是否使用检测和监控程序，发现会引入新漏洞的配置变更，以及系统对新发现漏洞的暴露情况。CC7.2 关注组织是否监控系统组件及其运行，发现与恶意行为、自然灾害或错误相关的异常，再分析这些异常是否属于安全事件。智能体 API 或 SSH 操作的记录可以支持两项标准，但作用不同。 对 CC7.1 来说，执行记录通常是变更证据。它可能显示智能体修改了防火墙规则、部署了软件包、更改了身份设置，或在主机上运行了命令。这类证据可以帮助审查人员把检测到的配置漂移或新暴露点与造成它的进程联系起来。但除非另有扫描器、公告源、资产清单服务或审查程序，将已部署组件与新漏洞信息进行比较，否则该记录本身无法发现刚公开的漏洞。 对 CC7.2 来说，同一份记录是运行遥测数据。被拒绝的调用、意外目的地、反复出现的身份验证失败、异常命令，或在已批准会话之外发生的操作，都可能成为异常输入。但存下一个事件不等于实施监控。组织仍要有明确方法来筛选事件、识别可疑模式、把事件交给审查人员，并记录判断结果。 这一区分可以避免一种常见映射错误：把日志记录等同于检测。日志源记录观察结果，检测控制则对这些观察结果应用逻辑或人工判断。审计员通常会同时测试设计和运行情况，因此只证明收集行为的证据只回答了一半问题。 AICPA 的《信托服务标准》给出关注点，而不是统一的工具清单。这让公司可以按照自身风险设计控制，但也意味着不存在一个万能的保存期限或强制产品类别。本地执行数据是否相关，取决于你的系统描述、风险评估、控制措辞和实际程序。 一条范围窄而站得住脚的控制声明可以写成："安全团队在每个工作日审查由智能体发起的生产操作，关注被拒绝调用、失败调用、新目的地和高权限 SSH 命令；审查人员记录处置结果，并按事件程序升级可疑事件。"这句话明确了总体范围、信号、频率、负责人和后续处理。"我们保存防篡改日志"只说明一种存储属性。 ## 会话身份应描述进程，不能暗示具体人员 有用的会话记录必须充分识别智能体进程，能够区分不同运行。至少应记录唯一会话标识符、进程起止时间、可执行文件路径、代码签名身份或二进制摘要、父进程、主机标识符、本地账户、授权决定、授权人和撤销状态。还要保存每个字段的取得方式，因为智能体自行报告的值不如执行网关或操作系统观察到的值可信。 不要悄悄把进程身份变成人员身份。代码签名机构能告诉你谁签署了二进制文件，本地账户能告诉你它在哪个操作系统上下文中启动。两者都无法证明是哪名员工编写了提示、批准了每项操作，或希望执行某条特定命令。如果控制需要人员归属，应把会话与身份提供商登录记录、设备管理数据、批准记录、工单负责人或受控工作站分配记录连接起来。 对父子进程关系也要同样谨慎。某个 shell 可能启动智能体，智能体再启动辅助程序，辅助程序请求 SSH 操作。记录观察到的链条，但必须定义哪个进程是控制对象。否则，一个团队按顶层智能体分组，另一个团队按辅助程序分组，审计进行到一半时抽样总体就变了。 简洁的会话对象可以明确证据契约： ```json {"session_id":"ses_01JX...","host_id":"mac-042","started_at":"2026-07-21T14:03:18Z","ended_at":"2026-07-21T14:48:02Z","executable":"/usr/local/bin/agent","signing_authority":"Developer ID Application: Example","parent_pid":8821,"local_account":"builder","authorization":{"decision":"approved","method":"local_user_action","at":"2026-07-21T14:03:22Z"},"revoked_at":null} ``` 上面的省略号表示示例经过缩写，不能作为合格的已存储标识符。生产证据需要完整值和有文字说明的唯一性规则，也需要时钟同步证据。如果端点、网关、身份系统和工单的时间戳发生偏移，即使每个来源内部一致，审计员也无法可靠重建顺序。 在 Sallyport 中，Sessions 日志记录智能体运行；首次调用批准卡会先显示进程的代码签名机构，批准持续到该进程退出。它能提供很好的本地会话证据，但当控制声明涉及指定员工、受管设备、已批准变更或公司登录时，团队仍需要外部记录。 ## 调用结果必须提供足够判断背景 单次调用记录应回答：进程尝试了什么、尝试目标在哪里、网关使用了哪个凭据引用或密钥类别、是否需要批准、做出了什么决定、执行是否开始，以及最终如何结束。记录时间戳和持续时间、通道、标准化目的地、操作类型、结果类别、错误类别和稳定的关联标识符。保留足够的命令或请求细节以便调查，但不要把秘密或敏感响应正文复制进审计轨迹。 结果词汇必须严谨。"denied"应表示控制在外部操作发生前阻止了执行。"failed"应表示执行已经开始，但返回错误、超时或丢失传输。"succeeded"应表示远程接口按有文字说明的规则报告成功。"unknown"应覆盖客户端发出操作后未能收到确认的棘手情况。把被拒绝和失败的调用合并为一个错误类别，会破坏控制是否实际运行的证据。 HTTP 状态码很少能说明全部情况。`200` 响应中可能包含应用错误，`202` 可能只表示任务已排队。SSH 退出码为零，说明远程 shell 命令报告成功，不代表预期系统状态已经改变。要按操作类型定义结果标准化规则，并在标准化结果旁保留原始状态或退出码。 实际调用记录可以采用如下形式： ```json {"call_id":"call_01JX...","session_id":"ses_01JX...","occurred_at":"2026-07-21T14:17:09Z","channel":"ssh","destination":"prod-web-03","action":"systemctl restart api","credential_ref":"ssh-prod-ops","approval":{"required":true,"decision":"approved","method":"touch_id"},"execution":{"started":true,"result":"failed","exit_code":1,"error_class":"remote_command_error","duration_ms":842},"ticket_ref":"CHG-1842"} ``` 不要仅仅为了让证据显得完整，就记录 bearer token、私钥、完整授权头或原始响应。会泄露秘密的审计日志会造成另一项控制失败。使用稳定的凭据引用并记录注入方法，同时让秘密材料远离智能体和导出的证据。 对于 CC7.1，审查人员可以把具备变更能力的调用与配置漂移、部署记录和漏洞发现结果关联起来。对于 CC7.2，他们可以筛选被拒绝、失败、未知、目的地异常或高风险的操作进行分析。只有当组织能够列举完整总体时，调用记录才能支持这些程序。五个有趣事件的截图只能证明五个事件存在，不能证明审查人员考虑了所有相关事件。 ## 完整性检查证明历史一致，不证明事件真实 只要验证器从可信格式和锚点开始，哈希链就能检测记录进入链条后的删除、插入、重排或修改。它不能证明来源捕获了每项操作，也不能证明字段写入时全部准确，更不能证明攻击者从未绕过日志记录器。防篡改日志中最需要分清的一点就是：记录完整性不等于收集完整性。 只写加密存储可以降低读取者或受入侵分析路径重写旧条目的可能性。加密保护机密性，链式结构保护可检测的连续性，硬件支持的密钥可以加强访问控制。这些机制回答的是不同审计问题，应分别记录，不要把整个设计统称为"不可变"。 完整性程序需要可重复的输入和保存下来的结果。使用 Sallyport，审查人员不需要密钥就能离线验证加密链： ```text $ sp audit verify /evidence/agent-audit-2026-07.splog verified: 18432 records first: 2026-07-01T00:01:44Z last: 2026-07-31T23:58:10Z chain: valid ``` 确切输出必须来自已安装版本。上面的形式定义了证据包应保留的内容：命令、工具版本、文件标识符或摘要、记录数量、时间边界、结果、执行时间和操作人员。如果真实命令使用不同标签，应保留原始输出，不要改写成示例形式。 在依赖该程序前先运行负面测试。复制一份非生产导出文件，用工程团队支持的测试夹具更改或删除一条记录，然后确认验证失败。保留测试方法、预期失败、实际输出、工具版本和审查人员签字。成功验证只能说明一个文件通过检查，受控负面测试则能说明检查器确实可以发现你声称可检测的修改。 还要核对边界。比较一次导出的最后记录数和链锚点，与下一次导出的预期起始状态。调查空档、重置、重新安装、时钟跳变和主机更换。如果本地管理员能够删除整份日志及其锚点，哈希链可能只会忠实验证替代后的历史。应按风险要求的频率，把锚点、摘要或签名导出回执发送到另一个受控位置。 NIST 特别出版物 800-92 建议保护归档日志的完整性，并验证传输后的日志，常见做法是比较消息摘要。这项建议仍然适用，但摘要或哈希链不能取代来源覆盖监控。用它暴露传输和保存故障，再测试范围内的所有来源是否确实报告。 ## 保存期限取决于控制期间和调查需要 SOC 2 没有为 CC7.1 或 CC7.2 证据规定统一天数。应根据审计期间、合同和法律义务、事件调查需要、检测延迟、存储内容的敏感程度，以及生成抽样材料所需时间来设定保存期限。政策应写明保存的事件类别、位置、负责人、访问限制、销毁方法和例外流程。 对于 Type 2 检查，审计员会测试一段期间内的运行情况。如果团队只保存最近一小段本地历史，就可能无法支持期间早期的抽样或证明连续性。证据保存时间应覆盖整个检查期间、准备阶段、现场工作，并为后续问题留出合理缓冲。更长的法律或合同义务应由法律顾问或合规负责人确定，不能直接照抄另一家公司的报告。 只在本地保存会出现一种很容易预见的故障。四月更换了一台笔记本电脑，原有日志随之消失，而十月的审计抽样选中了二月。团队只有替换设备上完整无误的哈希链，却没有选定日期的证据。按确定的计划把记录和验证锚点导出到组织控制的存储中，并保留计划导出实际运行的证明。 要测试检索，不要只测试设置。选一个期间早期的日期，找到会话总体，检索调用记录，验证完整性，再把一个事件连接到其审查处置。记录耗时和故障。保存配置截图能显示设计，从较早期间成功检索才能显示运行情况。 隐私和安全要求仍然适用。命令、目的地、本地账户名和错误正文可能含有个人数据或敏感基础设施细节。限制证据访问，按照有文字说明的规则处理导出副本，并且只在获得授权时保存未遮盖的来源。遮盖绝不能改变记录顺序，或在没有保存可独立验证原件的情况下破坏验证路径。 ## 审查频率应与信号相称并留下证明 当指定角色按明确频率检查确定的总体、应用书面判断标准并记录处置时，审查控制才算运行。"定期审查日志"无法可靠抽样，因为没人知道"定期"具体指什么，也不知道哪些日志属于范围。针对生产环境的智能体操作可能适合每个工作日审查，少数高权限密钥可能适合逐次批准，低风险开发目的地可能适合每周趋势审查。风险评估应说明选择依据。 要把预防性批准与检测性审查分开。批准决定某项操作能否继续，审查则判断已允许、被拒绝、失败和被绕过的操作是否表明异常或控制问题。即使有人批准了高风险调用，也不能证明后来有人核查结果、关联相关调用或识别受入侵会话。 选择工具前先用明确文字定义审查选择条件。一套可行程序可以选择 `result` 等于 `failed` 或 `unknown` 的所有调用、所有被拒绝批准、每个新目的地、所有指定生产凭据的使用、由未知签名机构启动的会话，以及任何完整性失败。审查人员把每项标记为预期行为、运行问题、政策偏差或疑似安全事件。疑似事件要获得事件标识符和升级时间戳。 保留零结果证据。在平静的一天，保存的查询、覆盖时间窗口、执行时间戳、审查人员身份和零计数，可以证明程序确实运行。一个月里只有正面发现的工单，会让人怀疑没有工单的那些天。审计员抽样的是控制运行情况，不只是引人注意的事件。 审查证据应包括： - 总体查询或导出标准及其版本。 - 覆盖的开始和结束时间、时区及记录数量。 - 审查人员身份、完成时间及任何延迟说明。 - 每个选中异常、处置和支持理由。 - 发生升级时关联的事件、变更或问题工单。 不要让事件生成者成为自身历史的唯一审查人员。小团队可能无法完全分工，但可以由另一名负责人进行补偿性审查，由管理层定期检查，并使用单独控制的导出。应描述实际安排。虚构的职责分离声明，比诚实说明限制并设置合理补偿控制更糟糕。 频率也适用于控制健康状况。按确定间隔确认预期主机生成了记录、导出完成、时钟保持同步、完整性检查通过、检测选择条件仍匹配数据结构，而且审查人员清空了队列。数据结构变更可能在表面正常的情况下悄悄破坏查询。加入已知测试事件或受监控的数量边界，让团队能在管道停止选择任何内容时发现问题。 CC7.2 要求通过分析确定异常是否属于安全事件。只把工单关闭为"误报"却不给理由，并不能证明完成了分析。记录应说明发生了什么、为何威胁或未威胁目标、哪些证据支持决定、谁做了决定，以及后续是否更改了检测器或程序。 ## 按照声明和抽样构建审计证据包 审计员通常先索取设计证据，再索取选定日期或事件的运行证据。组织本地执行记录时，应让每项材料回答一条明确的控制声明。不要先交出原始归档，再指望审计员自己从中找出你的控制。 把以下映射作为工作证据索引： | 审计员请求 | 有帮助的本地证据 | 通常需要的佐证 | | --- | --- | --- | | 显示由谁或什么发起操作 | 会话 ID、观察到的可执行文件、签名机构、主机和本地账户 | 身份提供商登录、设备清单、人员分配 | | 显示配置变更活动 | 目的地、命令或请求、凭据引用、时间戳、结果 | 变更工单、代码库历史、云端或主机配置状态 | | 显示对异常智能体行为的监控 | 完整调用总体、选择条件、被拒绝和失败结果 | 检测配置、警报路由、审查和事件工单 | | 显示记录未被更改 | 哈希链验证输出、版本、摘要、锚点和负面测试 | 导出控制设置、独立存储访问、来源覆盖测试 | | 显示证据已保存 | 可检索的最早和最新记录、导出运行历史 | 保存政策、存储配置、删除和例外记录 | | 显示异常已分析 | 审查工作表、处置、理由、升级引用 | 事件程序、响应人员证据、纠正措施跟踪 | 对每项控制维护一页证据定义，写明控制措辞、负责人、频率、系统总体、事件总体、程序、预期材料、存储位置和例外处理。为导出文件的每一列添加字段字典。审计员不应猜测 `actor` 是指员工、本地账户、进程还是签名机构。 准备两条抽样路径。第一条从随机选中的日期开始，证明完整审查按时运行。第二条从选中的高风险调用开始，向前追溯会话授权，向后追踪远程结果、审查处置以及任何变更或事件工单。两条路径测试不同声明。日期抽样测试重复运行，事件抽样测试可追溯性。 核对每次交接的总数。Sessions 日志数量应在有文字说明的筛选条件下与会话导出一致。调用数量在传输前后应相符。审查输入数量应能核对到选中、排除和未解决的项目。说明合理差异，例如测试环境、已批准排除项、重复重试或控制时间窗口外的记录。 Type 1 报告评估某一时点的控制设计。Type 2 报告还评估控制是否在规定期间内运行。当前截图、新鲜的完整性检查或最近写成的程序可以支持 Type 1 设计证据，却无法补回几个月缺失的 Type 2 运行情况。如果历史不存在，就披露缺口并重新安排准备时间，不要补做追溯签字。 现场工作前，询问审计员希望如何接收加密或敏感证据、抽样中需要哪些属性，以及他们会选择日期、会话、调用还是警报。这次沟通会改变证据打包方式，不会改变控制。控制必须在抽样到来前已经持续运行。 ## 覆盖和响应证据要从其他地方收集 本地执行记录只覆盖经过本地执行路径的操作。它不能证明所有生产变更都走了这条路径。管理员还可能使用云控制台、直接 SSH、CI/CD 凭据、提供商支持渠道、紧急账户、计划任务或另一台工作站。建立变更和访问路径清单，然后把它们纳入控制，或分别收集日志。 CC7.1 需要执行历史以外的证据： - 与审计范围关联的当前资产和软件清单。 - 配置标准和批准的基线版本。 - 漏洞扫描配置、覆盖范围、结果和扫描健康状况。 - 处理新披露漏洞并匹配受影响组件的流程。 - 修复工单、风险接受、期限、复测和例外。 安装软件包 X 版本的智能体调用是一项有用的变更证据。它无法告诉你三周后 X 版本被发现存在漏洞。漏洞管理系统、公告接收流程、软件清单和修复记录必须补全这个过程。 CC7.2 同样需要更广泛的来源。按照范围内风险收集端点、身份、网络、云控制平面、应用、数据库和可用性遥测。保留检测器定义、已启用来源清单、警报路由测试、值班或审查人员分配、警报历史、处置、事件记录和事件后措施。自然灾害和运行错误的覆盖可能需要可用性警报与连续性程序，而操作网关看不到这些内容。 通过核对证明完整性。把受管设备与导出本地记录的设备比较，把生产凭据与可通过网关使用的凭据比较，把云端变更与网关调用及批准的自动化比较。调查两个方向的不匹配记录：没有本地调用的云端变更可能表明绕过，有成功本地调用却没有预期远程变更，则可能表明结果标准化有误或发生回滚。 还要收集治理证据。风险评估应说明为何智能体操作与 CC7.1 和 CC7.2 有关。政策应分配日志、漏洞、监控、审查、事件和保存职责。培训或程序确认应覆盖批准和审查操作的人员。访问审查应显示谁可以读取、导出、管理或删除证据，以及谁可以更改检测逻辑。 NIST 特别出版物 800-92 把日志管理看成生成、传输、存储、分析和销毁的完整过程。这个生命周期能有效检验只考虑本地的做法。如果证据设计解决了生成和存储，却跳过传输、分析和销毁，那么即使加密技术可靠，设计仍未完成。 维护明确的证据缺口登记表，记录未覆盖系统、缺失期间、受影响控制、风险、临时程序、负责人和目标日期。审计员不会指望一份小型执行日志观察整家公司，但会要求管理层了解范围，并避免提出证据无法支持的声明。 ## 把本地记录当成狭窄而可测试的控制组件 当控制声明与记录观察到的内容相符时，本地防篡改记录值得使用。它可以提供精细的会话和调用证据，保留远程系统永远收不到的被拒绝尝试，并让后续修改可被检测。它特别适合追踪 AI 智能体活动，因为远程 API 往往只能看到共享服务身份，丢失本地进程背景。 当团队夸大身份、忽视绕过路径、只在可更换端点保存数据，或把有效哈希链误当成完整监控时，这类证据就会变弱。解决办法不是再加一个加密技术形容词，而是缩小声明、记录总体、重复审查、单独保存验证结果，并连接权威系统。 依赖这些记录前，用一个植入事件运行端到端控制测试。启动可识别的测试会话，尝试一个已批准操作和一个被拒绝操作，确认两种结果，导出该期间，验证哈希链，运行审查选择条件，记录处置，再核对远程系统中的对应事件。然后针对更早期间重复检索。这条链路中的每个断点都是真实证据缺口。 向审计员提供哈希链结果，同时也要提供来源清单、选择条件、审查证明、例外轨迹和外部佐证。这样的证据包可以支持站得住脚的 CC7.1 或 CC7.2 控制。只有哈希链时，你最多只能作出一项有限声明：所提供的本地历史仍保持验证器所预期的结构。