信任服务准则（TSC）五大准则详解与合规要求

SOC2 审计的核心，说白了就是五个信任服务准则。我刚开始接触 SOC2 时，总觉得这五个词差不多——安全、保密、隐私好像是一回事。后来做了几个项目才明白，每个准则都有自己的脾气，审计师盯的点也完全不一样。

今天咱们逐个拆解。我会结合自己踩过的坑，告诉你每个准则到底在查什么，审计日志怎么配合，合规要求有哪些硬指标。

1. 安全性（Security）

安全性是五准则中最基础、也是最重的一个。它的目标是防止系统被未授权访问、篡改或破坏。说白了，就是“不让坏人进来，不让好人的数据乱跑”。

合规要求方面，审计师会重点看这几块：

• 访问控制——有没有 IAM、MFA、最小权限原则？我记得有一次客户把管理员账号密码贴在服务器显示器上，审计直接给了个严重缺陷。
• 网络安全——防火墙、WAF、分段策略、IDPS。我曾经遇到过一个 SaaS 平台，内网段直接暴露在公网，审计日志里全是扫描记录……嗯，那场面挺尴尬。
• 监控与响应——SIEM、SOAR、事件响应流程。审计师会翻日志，看你是不是真正在监控，还是只是开了个工具没人看。
• 变更管理——代码上线、配置变更有没有审批？有没有回退计划？我建议你拿一个生产环境的变更记录给审计师，他能从时间戳里读出很多东西。

安全性准则的审计日志要求非常明确：所有与认证、授权、数据访问、权限变更相关的操作，必须记录并保留至少 12 个月。日志字段至少包含时间、用户、源 IP、操作、结果、对象。

2. 可用性（Availability）

可用性不是“系统不宕机”，而是“服务必须达到承诺的可用性目标”。审计师会对照你的 SLA 来查，比如 99.9% 还是 99.99%。

合规要求主要包括：

• 基础设施冗余——负载均衡、跨 AZ 部署、灾备（DR）。我见过一家公司声称“99.999% 可用”，结果只有一个单节点数据库……审计师当场就笑了。
• 监控与告警——你用什么工具监控？告警阈值合理吗？响应时间多长？日志里要有宕机记录、恢复时间、根因分析。
• 容量管理——有没有压力测试？有没有扩展计划？
• 业务连续性——BCP/DRP 文档要齐全，并且要演练过。审计师可能会要求看演练报告和日志。

我个人习惯在可用性准则里特别关注 宕机日志。很多公司只保留了服务正常运行的日志，出故障时反而没记录——这叫“选择性失忆”。审计师一看就知道你在隐瞒。

3. 处理完整性（Processing Integrity）

这个准则容易被忽视。它关心的不是“系统有没有坏”，而是“数据处理得对不对”。说白了，就是数据从输入到输出，有没有被篡改、丢失、重复或延迟。

合规要求：

• 数据输入验证——有没有格式校验、范围检查、重复检测？
• 处理逻辑审计——重要交易有没有记录过程日志？比如支付流程，每一步的输入输出都要可追溯。
• 数据一致性检查——有没有对账机制？我曾经帮一个金融客户做整改，发现他们的交易日志和数据库记录差了 0.3%——就因为少了一个幂等检查。
• 错误处理与重试——失败任务有没有告警？有没有补偿事务？日志里要能看到重试次数、失败原因。

处理完整性准则对审计日志的要求最细。每个业务事务最好都有「唯一事务 ID」，串联起所有相关日志。否则你很难向审计师证明“数据没丢”。

4. 保密性（Confidentiality）

保密性 vs 安全性——我经常被问到这个问题。安全性是“防入侵”，保密性是“防泄漏”。即使用户是合法登录的，也不能看到不该看的数据。

合规要求集中在：

• 数据分类——你有没有对敏感数据打标签？（比如 PII、财务数据、商业机密）
• 加密——传输加密（TLS 1.2+）、存储加密（AES-256）、密钥管理（KMS）。审计师会查你密钥的轮换周期。
• 访问隔离——比如租户隔离、数据脱敏、最小权限。我遇到过一家公司把密钥文件放在源码仓库里，审计师直接给了一个 Critical 缺陷。
• 数据销毁——离职员工或过期数据，有没有彻底清除？日志里要保留销毁凭证。

保密性准则的审计日志要记录所有“对敏感数据的访问、修改、导出”行为。特别注意：谁、什么时间、从哪个 IP、访问了哪个敏感字段。建议加一个字段表示“敏感级别”，方便审计师快速筛选。

5. 隐私性（Privacy）

隐私性和保密性容易混淆。保密性管的是“公司内部的秘密”，隐私性管的是“用户个人的信息”。它更偏向法律合规，涉及 GDPR、CCPA 等法规。

合规要求：

• 告知与同意——你有没有清晰的隐私政策？用户有没有明确授权？
• 数据主体权利——用户能查询、修改、删除自己的数据吗？响应时间要在法规范围内。
• 数据最小化——只收集必要的字段？别把家庭住址当必填项。
• 跨境传输——数据存到哪里去了？有没有标准合同条款（SCC）？

我建议你在隐私性准则的日志中专门加一个“同意记录”。每次用户授权、撤销授权，都要留下不可篡改的日志。否则审计师问“这个用户的个人数据你凭什么处理”时，你会很被动。

各准则审计日志关键字段一览

准则	关键日志事件	必含字段	保留期限（建议）
安全性	登录、权限变更、防火墙规则修改、威胁告警	源IP、目标资源、操作类型、结果	12个月
可用性	宕机、恢复、扩容、灾备切换	开始/结束时间、影响范围、根因	24个月
处理完整性	事务开始/提交/失败、对账差异、重试	事务ID、输入哈希、输出值、错误码	7年（金融场景）
保密性	敏感数据访问、导出、加密密钥操作	用户身份、数据分类、敏感级别	12个月
隐私性	用户授权/撤销、数据删除请求、跨境传输	用户ID、同意版本、法律依据	用户关系存续期+6个月

说实话，很多团队一开始只重视安全性日志，觉得其他准则“用安全的日志对付一下就行”。结果审计师一查隐私性，发现连用户什么时候点同意都没记——那就麻烦了。我个人习惯做一次日志覆盖矩阵，把每个准则拆成具体事件，再对照现有的日志字段。缺什么补什么，不要等审计通知再动手。

嗯，核心就这些。五准则不是独立孤岛，它们共享一套基础设施和日志管道。理解每个准则的“真实关切点”，你的审计日志才能既全面又精准。