4、数据静态加密：全盘加密与文件级加密、数据库加密（TDE与列级加密）、云存储加密（S3/Blob）
好，咱们进入静态加密这个环节。说实话，在SOC2审计里，静态加密是审查员盯得最紧的一块。为什么？因为数据一旦「躺」在磁盘上，你没法像网络传输那样实时监控它。我见过太多公司，网络加密做得滴水不漏，结果硬盘被人拔走，数据直接裸奔。
静态加密，说白了就是给「睡着的」数据穿上盔甲。SOC2的CC6.1和CC6.7条款明确要求：必须保护静止状态下的机密信息。嗯，这里要注意，不是「建议」，是「必须」。
4.1 全盘加密 vs 文件级加密：选哪个？
先说说全盘加密。这东西就像给你的房子装了个防盗门——整块硬盘全部锁死。Windows上的BitLocker、Linux上的LUKS，都是典型代表。我个人习惯在服务器部署时，第一件事就是打开LUKS。为什么？因为省心。你不需要操心哪个文件该加密，哪个不该加密，操作系统帮你全包了。
但全盘加密有个坑——它只在「关机」状态下保护数据。机器一旦开机，密钥加载到内存里，整个磁盘对操作系统就是透明的。我曾经遇到过一家客户，服务器跑着跑着被人物理入侵，对方直接插了个USB启动盘，从内存里把LUKS密钥dump了出来。嗯，所以全盘加密不是万能的。
文件级加密就精细多了。它只加密你指定的文件或文件夹。比如你用GnuPG加密一个CSV文件，或者用eCryptfs加密某个目录。好处是粒度细，你可以对不同的文件用不同的密钥。坏处是——你想想看——你得自己管理哪些文件加密了、哪些没加密。我见过一个团队，文件级加密搞了半年，结果审计时发现有一半的敏感文件根本没加密，因为开发人员忘了执行加密脚本。
我的建议：能上全盘加密就上全盘加密，作为基础防线。然后在全盘加密之上，对特别敏感的文件（比如包含PII的导出文件）再加一层文件级加密。这叫「纵深防御」，SOC2审查员最喜欢看到这个。
4.2 数据库加密：TDE vs 列级加密
数据库加密这块，争议挺大。TDE（透明数据加密）和列级加密，到底选哪个？我直接说结论：看你的威胁模型。
TDE，像SQL Server的TDE、MySQL的InnoDB表空间加密，它们加密的是整个数据库文件（.mdf、.ibd文件）。好处是——对应用完全透明。你不需要改一行SQL代码，数据库自己把数据写磁盘前加密，读磁盘后解密。我在项目中遇到过一家金融公司，他们用TDE通过了SOC2审计，审查员只问了三个问题：密钥存哪了？谁有权限？轮换周期多长？答上来就过了。
但TDE有个致命弱点：它不保护内存中的数据。如果有人能直接查询数据库（比如通过SQL注入），TDE形同虚设。因为数据库引擎在返回结果前已经解密了。
列级加密就不一样了。它只加密特定的列，比如身份证号、信用卡号。应用层需要调用专门的加解密函数才能读写。举个例子：
-- 写入时加密
INSERT INTO users (name, ssn)
VALUES ('张三', ENCRYPTBYKEY(KEY_ID('SSN_Key'), '123-45-6789'));
-- 读取时解密
SELECT name, DECRYPTBYKEY(ssn) AS ssn_decrypted
FROM users;
这样做的好处是：即使DBA直接查数据库，看到的也是乱码。我曾经帮一家医疗SaaS公司做过架构，他们要求「医生能看到患者姓名，但不能看到社保号」。列级加密完美解决了这个问题——不同的列用不同的密钥，权限控制到列级别。
避坑指南：我曾经见过一个团队，对20列数据做了列级加密，结果查询性能下降了80%。为什么？因为每次查询都要解密，而且索引对加密列无效。所以我的建议是：只对真正敏感的列（PII、财务数据）做列级加密，其他列交给TDE。别贪多。
4.3 云存储加密：S3/Blob 怎么搞？
云存储加密，说白了就是对象存储的加密。AWS S3、Azure Blob Storage、阿里云OSS，大同小异。SOC2审计时，审查员会问：「你的对象存储加密是怎么配置的？」
云存储加密通常分三层：
- 服务器端加密（SSE）：云平台帮你加密，你只管存。S3的SSE-S3、SSE-KMS都属于这类。
- 客户端加密：你在上传前自己加密，云平台只存密文。
- 传输中加密：HTTPS/SSL，这个默认都有。
我个人习惯用SSE-KMS。为什么？因为你可以用KMS的密钥策略做细粒度权限控制。比如，只允许某个IAM角色解密特定桶里的文件。我在项目中遇到过一家电商公司，他们把所有用户订单数据存在S3里，用SSE-S3加密。审计时审查员问：「密钥谁管？」答：「AWS管。」审查员又问：「那你们怎么证明AWS没偷看数据？」……嗯，这个问题问得好。后来他们改成了SSE-KMS，自己管理CMK（客户主密钥），审计就过了。
Azure Blob Storage类似。它提供Azure Storage Service Encryption（SSE），默认启用。但如果你需要BYOK（Bring Your Own Key），可以用Azure Key Vault。我建议：
- 默认场景：用平台管理的密钥（SSE-S3或Azure SSE），省心。
- 合规要求高：用自己管理的密钥（SSE-KMS或Azure BYOK），满足审计要求。
- 极端敏感：客户端加密，密钥永远不离开你的应用。
小技巧：在S3上，记得开启「默认加密」和「桶策略强制加密」。这样即使有人忘了在PutObject时指定加密参数，数据也会自动加密。我见过太多因为「忘记加加密参数」导致数据明文存储的案例了。
4.4 密钥管理：静态加密的灵魂
说了这么多加密方式，其实核心就一个——密钥管理。没有好的密钥管理，加密就是自欺欺人。SOC2的CC6.1条款明确要求：密钥必须安全存储、定期轮换、有访问审计。
我总结了几条铁律：
- 密钥不要硬编码在代码里。用密钥管理服务（AWS KMS、Azure Key Vault、HashiCorp Vault）。
- 定期轮换。我建议至少每90天轮换一次。自动化脚本搞定，别手动。
- 审计日志。谁在什么时候用了哪个密钥，必须能追溯。SOC2审查员会查这个。
- 备份密钥。密钥丢了，数据就没了。我见过一家公司，TDE密钥没备份，数据库崩溃后所有数据无法恢复……嗯，那是灾难级的。
最后说一句：静态加密不是「配完就完事」的。你得定期验证——真的加密了吗？密钥还能用吗？权限对吗？我每季度会做一次加密验证演练，手动检查几个样本文件，确认它们确实是密文。这招在SOC2审计时特别加分。