2、信任服务准则（TSC）详解：安全性、可用性、处理完整性、保密性、隐私性五大准则

好，咱们进入正题。SOC2 审计的核心，说白了就是围绕这五个信任服务准则（TSC）展开的。很多刚接触 SOC2 的朋友，一上来就被这五个词搞晕了。我刚开始也一样，觉得它们长得差不多。但实际做项目时你会发现，每个准则的审计重点、证据要求、甚至整改难度，差别都挺大的。

这五个准则分别是：安全性、可用性、处理完整性、保密性、隐私性。嗯，咱们一个一个来拆解。

2.1 安全性（Security）

安全性是 SOC2 的基石。说白了，就是防止未经授权的访问。不管是系统被黑、数据泄露，还是内部人员乱搞，都属于安全性的范畴。

我个人习惯把安全性理解为「门锁和围墙」。你得确保只有该进来的人能进来，不该进来的人进不来。

我在项目中遇到过一家 SaaS 公司，他们自认为安全性做得很好，防火墙、WAF 都上了。结果一审计，发现所有员工的 SSH 密钥都放在一个共享文件夹里，权限还是 777。嗯，这种「灯下黑」的情况其实很常见。

2.2 可用性（Availability）

可用性，就是系统该干活的时候得能干活。你想想看，一个系统再安全，如果三天两头宕机，客户能接受吗？

这里要注意，SOC2 的可用性不是要求你 100% 可用——那不可能。它要求的是：你承诺的可用性，你得做到。比如你合同里写了 99.9%，那审计师就会看你有没有相应的监控、备份、容灾措施来支撑这个承诺。

可用性级别	年停机时间	常见场景
99.9%（三个9）	约 8.76 小时	一般企业级 SaaS
99.99%（四个9）	约 52.56 分钟	金融、医疗核心系统
99.999%（五个9）	约 5.26 分钟	电信、关键基础设施

2.3 处理完整性（Processing Integrity）

这个准则很多人会忽略。处理完整性，就是系统处理数据时，不能出错。数据不能丢、不能改、不能重复处理。

举个例子：你做一个支付系统，用户付了 100 块，系统不能记成 1000 块，也不能记成 10 块。更不能用户付了钱，系统说「没收到」。这就是处理完整性要解决的问题。

我个人的经验是，处理完整性审计最容易被忽视的是「边界条件」。比如并发处理、数据同步延迟、批处理任务中断恢复等场景。这些地方最容易出幺蛾子。

2.4 保密性（Confidentiality）

保密性，就是敏感数据不能泄露。这里说的「敏感数据」，通常是指客户明确要求保密的那些信息，比如商业机密、源代码、客户名单等。

注意，保密性和后面的隐私性有重叠，但侧重点不同。保密性更关注「数据本身」的保护，而隐私性更关注「个人信息」的处理方式。

我记得有一次审计，客户说他们的数据都加密了。结果我一看，加密密钥和加密数据存在同一个数据库里。这叫什么？这叫「锁门但把钥匙挂在门上」。保密性要求的是端到端的保护，从传输、存储到销毁，每个环节都不能掉链子。

2.5 隐私性（Privacy）

隐私性，是五个准则里最「麻烦」的一个。因为它涉及的法律法规最多——GDPR、CCPA、PIPL（个人信息保护法）等等。

隐私性关注的是：个人信息的收集、使用、存储、共享、销毁，是否合规。说白了，你不能乱用用户的数据。

举个例子：用户注册时给了你手机号，你只能用来发验证码。如果你拿这个手机号去做营销，那就违反了隐私性原则——除非你事先获得了用户的明确同意。

隐私性原则	说明	常见违规场景
告知与同意	收集数据前必须告知用途并获取同意	默认勾选同意、隐私政策藏得太深
目的限制	数据只能用于告知时的目的	把注册信息拿去给第三方做分析
数据最小化	只收集必要的数据	注册时要求用户填身份证号
数据保留与销毁	数据不用了要及时删	用户注销账号后数据还留着

2.6 五个准则的关系

最后，我简单说说这五个准则之间的关系。你可能会问：我能不能只做安全性，不做其他的？

答案是：看你的 SOC2 报告类型。SOC2 允许你选择性地覆盖某些准则。比如你只做安全性和可用性，那报告上就只写这两个。

但实际项目中，我建议你尽量覆盖全部五个。为什么？因为客户越来越懂行了。你只做安全性，客户会问：「那我的数据完整性怎么保证？我的隐私合规怎么办？」

嗯，说白了，五个准则是一个整体。安全性是基础，可用性是承诺，处理完整性是质量，保密性和隐私性是信任。缺了任何一个，你的 SOC2 报告含金量都会打折扣。