2、信任服务准则（TSC）：安全性、可用性、处理完整性、保密性、隐私性五大准则详解
好，咱们直接进入正题。SOC2 审计的核心，说白了就是围绕五个信任服务准则（TSC）来展开的。很多刚接触的朋友会觉得这五个词看着都懂，但一到实际落地就懵了。我当年第一次做 SOC2 项目时，也花了很长时间才理清它们之间的边界和联系。
这五个准则分别是：安全性、可用性、处理完整性、保密性、隐私性。它们不是孤立的，而是相互支撑的。你想想看，一个系统如果连安全都做不到，谈何保密？如果系统老宕机，可用性为零，处理完整性再高也没用。
下面我一个一个拆开来讲，结合我踩过的坑，帮你真正吃透它们。
2.1 安全性（Security）—— 系统的“门锁”
安全性是所有准则的基础。它关注的是：系统是否受到保护，防止未经授权的访问、使用或破坏。
我个人习惯把安全性理解为“门锁”。你家的门锁够不够结实？钥匙有没有乱丢？窗户有没有关好？对应到 IT 系统，就是防火墙、访问控制、入侵检测这些。
核心控制点：
- 逻辑访问控制：谁可以登录？能操作什么？
- 物理安全：机房有没有门禁？摄像头有没有死角？
- 网络安全：防火墙规则是否合理？有没有做网络隔离？
- 变更管理：改代码、改配置有没有审批流程？
我的经验： 我在项目中遇到过一家公司，防火墙规则写得密密麻麻，但有一台测试服务器直接暴露在公网上，连密码都是默认的。审计师一扫描就发现了。所以，安全性不是看你有多少控制措施，而是看有没有“漏网之鱼”。
2.2 可用性（Availability）—— 别让业务“断粮”
可用性关注的是：系统是否按照约定的服务水平正常运行？说白了，就是你的系统能不能稳定提供服务。
我记得有一次审计，客户说他们的系统可用性达到 99.9%，但审计师一问：“那你有监控吗？有告警吗？有灾备吗？”客户当场愣住了。原来他们只是凭感觉说“好像没怎么宕机”。
可用性不是靠感觉的，得有数据支撑。
| 关键要素 | 说明 |
|---|---|
| 监控与告警 | 系统宕机了，你多久能知道？ |
| 容量规划 | 流量高峰期，系统扛得住吗？ |
| 备份与恢复 | 数据丢了，能恢复回来吗？多久能恢复？ |
| 灾备演练 | 真出事了，你的灾备方案能跑通吗？ |
避坑指南： 我曾经见过一家公司，备份做了三年，但从没恢复验证过。结果真出故障时，发现备份文件早就损坏了。嗯，这里要注意：备份不验证，等于没备份。
2.3 处理完整性（Processing Integrity）—— 数据“不走样”
处理完整性听起来有点抽象，其实很简单：系统处理数据时，是不是准确、完整、及时？有没有丢数据？有没有算错账？
举个例子，你网购下单，系统扣了钱但没生成订单，这就是处理完整性出了问题。或者银行转账，转出去 100 块，对方只收到 99 块，这也是问题。
为什么会这样？很多时候是因为系统设计有缺陷，或者数据处理流程中缺少校验。
常见控制措施：
- 输入验证：数据进来时，检查格式、范围是否合法。
- 处理校验：比如金额计算后，做一次反向验证。
- 输出核对：生成报表后，与源数据做比对。
- 错误处理：出错了，系统能自动回滚吗？有日志记录吗？
我的经验： 我审计过一个支付系统，发现他们处理交易时，如果数据库写入失败，系统不会回滚，而是直接返回“成功”。结果用户以为支付成功了，实际上钱没扣。这就是典型的处理完整性缺失。
2.4 保密性（Confidentiality）—— 敏感数据“不外泄”
保密性关注的是：敏感数据（比如客户名单、商业机密、源代码）有没有被妥善保护？
注意，保密性和安全性有重叠，但侧重点不同。安全性是“谁都不能进”，保密性是“不该看的人不能看”。比如，公司内部员工可以登录系统，但只有特定角色才能查看客户合同，这就是保密性控制。
我个人习惯把保密性控制分为两类：
- 数据分类：你得先知道哪些数据是敏感的，才能谈保护。
- 加密与访问控制：传输加密（HTTPS）、存储加密（AES-256）、最小权限原则。
避坑指南： 我曾经遇到一家公司，把所有数据都加密了，但加密密钥就明文写在配置文件里，还放在 GitHub 上。这就像把保险柜钥匙挂在保险柜门上。所以，密钥管理是保密性的重中之重。
2.5 隐私性（Privacy）—— 个人信息“合规用”
隐私性是五个准则里最“麻烦”的一个，因为它涉及法律法规（比如 GDPR、CCPA、中国的《个人信息保护法》）。它关注的是：个人信息的收集、使用、存储、共享、删除，是否合规？
你想想看，用户注册时你收集了他的手机号，你有没有告诉他用来干嘛？你有没有给他删除数据的权利？你有没有把数据卖给第三方？这些都是隐私性要管的事。
隐私性其实可以看作是保密性的“升级版”。保密性只管“别泄露”，隐私性还要管“怎么用、用多久、用完怎么删”。
| 隐私性原则 | 说明 |
|---|---|
| 告知与同意 | 收集数据前，要明确告知用途并获得同意。 |
| 目的限制 | 收集的数据只能用于告知过的目的。 |
| 数据最小化 | 只收集业务必需的数据，别什么都想要。 |
| 访问与更正 | 用户有权查看、修改自己的数据。 |
| 删除权 | 用户要求删除时，你得能彻底删掉。 |
核心要点： 隐私性不是技术问题，而是管理问题。很多公司技术上做得很好，但隐私政策写得含糊不清，或者没有给用户提供删除数据的渠道，照样过不了审计。
2.6 五大准则的关系与优先级
最后，我简单总结一下这五个准则的关系。你不需要把它们割裂开来看，它们是一个整体：
- 安全性是地基，没有它，其他都是空谈。
- 可用性是保障，系统都跑不起来，其他准则没意义。
- 处理完整性是核心，数据不准，系统再安全也没用。
- 保密性是底线，敏感数据泄露，后果很严重。
- 隐私性是合规要求，法律风险不可忽视。
在实际审计中，并不是所有公司都需要覆盖全部五个准则。比如，你只做内部系统，不涉及个人信息，那隐私性可能就不在审计范围内。但安全性、可用性、处理完整性，几乎是所有 SOC2 审计的标配。
我的建议： 刚开始准备 SOC2 时，别想着一步到位。先把安全性做好，再逐步扩展到其他准则。我见过太多公司一上来就想搞隐私性，结果连基本的访问控制都没做好，最后审计师给了一堆发现项。
好了，这一章的内容就到这里。下一章我会讲如何根据这五个准则，设计具体的控制措施。到时候咱们再细聊。