3、五大信任服务原则详解（上）：安全性、可用性、处理完整性
好，咱们直接进入正题。SOC2 的核心，说白了就是这五个信任服务原则。很多朋友第一次接触时，会觉得它们很抽象，像五个大帽子。其实没那么复杂。我习惯把它们拆成「技术控制」和「管理控制」两个维度来看。
今天我们先聊前三个：安全性（Security）、可用性（Availability）、处理完整性（Processing Integrity）。这三个是 SOC2 的基石，也是审计师最关注的部分。
3.1 安全性（Security）—— 你的系统到底防不防得住？
安全性原则，是所有原则里最重头的。它要求你证明：系统有足够的能力防止未经授权的访问、信息泄露或数据损坏。
嗯，这里要注意，审计师看安全性，不是只看你装了几个防火墙。他们看的是你有没有一套完整的安全控制体系。我把它总结为三个层面：
- 逻辑访问控制：谁可以进系统？能做什么？
- 物理访问控制：服务器机房的门锁、监控、访客登记。
- 安全生命周期管理：漏洞扫描、补丁管理、事件响应。
核心要点：安全性原则的审计证据，通常包括：
- 访问控制策略文档（谁有权访问什么数据）
- 身份认证机制（MFA 是否启用？）
- 安全事件日志（有没有人半夜登录？）
- 渗透测试报告（最近一次测试是什么时候？）
我在项目中遇到过一家 SaaS 公司，他们自认为安全做得很好，防火墙、WAF 全都有。结果审计师一问：「你们的防火墙规则变更有没有审批流程？」他们愣住了。原来所有规则都是运维直接改，没有任何记录。这就是典型的「有工具，没管理」。审计师直接给了个观察项。
我的个人习惯：做安全性控制时，别只盯着技术工具。先把「谁可以做什么」这件事用文档写清楚。哪怕你只有 10 个人，也要有明确的角色权限矩阵。这是审计师最喜欢看到的证据之一。
3.2 可用性（Availability）—— 系统挂了，你多久能恢复？
可用性原则，很多人以为就是「系统不宕机」。其实没那么简单。它要求你证明：系统在约定的服务水平上，能够持续可用。
为什么会这样？因为 SOC2 报告是给客户看的。客户关心的是：「万一你们系统崩了，我的业务会不会停？」
可用性的核心控制点，我通常归纳为：
- 基础设施冗余：单点故障有没有消除？比如数据库主从、负载均衡。
- 监控与告警：系统出问题，你多久能发现？
- 灾难恢复计划（DRP）：真挂了，RTO（恢复时间目标）和 RPO（恢复点目标）是多少？
- 定期演练：计划写得好，不演练等于零。
| 指标 | 说明 | 常见目标值 |
|---|---|---|
| RTO | 从故障发生到系统恢复的时间 | 4 小时以内 |
| RPO | 允许丢失的最大数据量（时间维度） | 15 分钟以内 |
| 可用性 SLA | 系统正常运行时间百分比 | 99.9% 或 99.99% |
我曾经踩过的坑：有一年做审计，客户说他们有灾备方案，RTO 是 2 小时。结果审计师要求看演练记录。客户翻箱倒柜只找到一份一年前的演练报告，而且那次演练还失败了。审计师直接说：「没有定期演练的 DRP，等于没有。」从那以后，我要求所有客户至少每季度做一次桌面推演，每半年做一次全量演练。
你想想看，如果你的客户是一家金融机构，他们能接受系统宕机超过 30 分钟吗？所以可用性原则，本质上是在回答：「你拿什么保证你的承诺？」
3.3 处理完整性（Processing Integrity）—— 数据有没有被改错？
处理完整性，这个名字听起来有点绕。说白了就是：系统处理数据时，有没有出现错误、遗漏、或者未经授权的修改？
我习惯把它理解为「数据管道」的完整性。从数据输入、处理、到输出，每一步都不能出错。审计师会关注：
- 输入验证：用户提交的数据，系统有没有做格式校验？
- 处理逻辑：比如财务系统算利息，算法对不对？
- 输出核对：生成报表前，有没有对账机制？
- 变更管理：谁改了代码？有没有经过测试和审批？
一个典型的审计场景：审计师会要求你展示「一笔交易从创建到完成」的完整日志。如果日志里缺少某个环节，或者时间戳对不上，那就是处理完整性的问题。
我记得有一次，客户是做电商平台的。他们有个促销活动，满 100 减 20。结果审计师发现，系统在处理并发订单时，偶尔会出现「满 100 减了 40」的情况。原因是代码里有个竞态条件，没有做幂等处理。这就是典型的处理完整性缺陷。最后他们花了两个月重构了订单模块。
我的建议：处理完整性最容易出问题的地方，往往是「边界条件」和「并发场景」。写代码时多想想：如果用户同时提交两次请求会怎样？如果网络超时重试会怎样？把这些场景覆盖到测试用例里，审计师问起来你也有底气。
3.4 三个原则的关系
这三个原则不是孤立的。我经常跟团队说：安全性是基础，可用性是承诺，处理完整性是底线。
没有安全性，可用性再高也没用——系统一直在线，但数据全被偷了，有什么用？没有处理完整性，安全性做得再好，客户也不敢用——数据没丢，但算出来的账全是错的，你敢信？
所以做 SOC2 认证，别想着「先搞定一个原则再说」。它们是一体的。你设计控制措施时，要同时考虑这三个维度。比如一个简单的数据库备份策略：
- 安全性：备份数据要加密，访问要权限控制。
- 可用性：备份要异地存储，确保灾难时能恢复。
- 处理完整性：备份过程要有校验，确保数据没损坏。
你看，一个备份策略，三个原则全用上了。这才是 SOC2 的实战思维。
好，今天先聊到这里。下一章我们讲剩下的两个原则：保密性和隐私性。这两个容易混淆，到时候我会重点讲它们的区别。