2. 企业数据保护需求分析
在对称加密真正落地之前，企业必须先回答一个更基础的问题：哪些数据需要保护、保护到什么程度、在什么阶段保护、防的是谁、受哪些规则约束。如果跳过需求分析直接选算法和密钥长度，往往会出现两类偏差：一类是对低敏感数据过度加密，拖慢系统并增加密钥管理负担；另一类是对高敏感数据保护不足，例如只加密数据库字段却遗漏了备份文件与日志。本节围绕分类分级、生命周期、威胁模型、合规要求和适用边界五个维度，建立一套可操作的需求分析方法。
一、数据分类分级：先定“保护对象”和“保护强度”
分类回答“这是什么数据”，分级回答“泄露后有多严重”。两者结合才能确定加密强度、密钥隔离级别和访问控制策略。分类可按业务属性划分，例如客户身份信息、支付信息、员工人事信息、设备遥测数据、源代码与配置、公开营销素材。分级通常采用四级模型：
| 级别 | 典型数据 | 泄露影响 | 对称加密建议 |
|---|---|---|---|
| L1 公开 | 官网文案、公开价格 | 无实质影响 | 通常不加密，仅完整性校验 |
| L2 内部 | 内部通知、一般运营报表 | 轻微影响 | 传输加密，静态可选 |
| L3 敏感 | 客户手机号、地址、订单明细 | 客户投诉、监管问询 | 传输+静态加密，字段级或表空间级 |
| L4 核心 | 身份证号、银行卡号、生物特征、密钥材料 | 重大合规与财务损失 | 字段级加密+独立密钥+严格审计 |
分级不是一次性标签，而应随数据流转动态继承。例如一份 L3 客户报表被导出为 CSV 后，其分级不应降为 L2，而应保持 L3 并附加水印或访问期限。实操中建议为每个数据资产登记“分类、分级、责任人、存储位置、加密状态”五个字段，形成可查询的数据资产台账。
二、生命周期视角：加密点分布在哪些阶段
数据生命周期通常包括采集、传输、存储、使用、共享、归档和销毁。对称加密在不同阶段的介入方式差异明显：
- 采集：终端或前端采集敏感字段时，可用应用层对称加密后再上传，避免明文经过不可信网络。
- 传输：由 TLS 等协议完成，属于通道加密，不替代存储加密。
- 存储：数据库字段级加密、表空间加密、对象存储服务端加密、备份文件加密，需明确密钥归属。
- 使用：解密后进入内存，需控制进程权限、禁止明文落盘、限制调试日志输出。
- 共享：对外提供数据时，可采用信封加密，为每个接收方生成独立数据密钥。
- 归档与销毁：归档数据仍需加密；销毁时除删除数据外，还应销毁对应密钥，实现密码学删除。
生命周期分析的核心产出是一张“数据流—加密点”对照表，标出每个阶段的数据形态（明文/密文）、加密算法、密钥来源和责任人。缺少这张表，后续密钥管理就无从谈起。
三、威胁模型：明确防谁、防什么
威胁模型决定加密的边界。常见威胁包括：数据库文件被拖库、备份磁带丢失、运维人员越权查询、应用服务器被入侵后读取内存、日志中意外记录明文、第三方接口泄露。对称加密能有效对抗“静态数据被直接读取”和“备份介质丢失”，但对“应用被入侵后以合法身份解密”防护有限，这类威胁需要结合访问控制、密钥隔离和审计。
建议用简化的威胁建模方法：列出资产、入口、攻击者能力和预期影响。例如资产为 L4 身份证号，入口为 Web 应用和数据库，攻击者能力为外部 SQL 注入，预期影响为批量泄露。对应措施可包括：字段级 AES-256-GCM 加密、密钥存放于 KMS 且应用仅持有短期数据密钥、数据库账号无密钥读取权限、查询行为审计。
四、合规要求：把法律语言翻译成技术参数
合规要求通常不会直接规定“使用 AES-256”，而是提出原则性要求，例如“采取加密等安全措施”“确保数据在传输和存储过程中的保密性”“发生泄露时能够追溯”。工程团队需要将其翻译为可验证的技术参数：加密算法、密钥长度、密钥存储位置、轮换周期、审计日志字段、数据留存期限。以个人信息保护为例，若涉及身份证号、银行卡号等敏感个人信息，建议采用 AES-256-GCM 进行字段级加密，密钥由 KMS 托管，应用通过短期令牌获取数据密钥，并记录每次解密的操作者、时间、数据标识和用途。这样在审计时才能提供“谁在何时解密了哪些数据”的证据链。
五、对称加密的适用边界
对称加密擅长处理“数据本身”的保密性，尤其适合静态存储、备份文件、字段级加密和信封加密。但它不解决密钥分发问题，也不提供身份认证和不可否认性。因此，以下场景不应单独依赖对称加密：
- 需要向多个互不信任方分发密钥时，应结合非对称加密或密钥协商。
- 需要验证数据来源和完整性时，应使用消息认证码或数字签名。
- 需要防止应用被入侵后合法解密时，应结合密钥隔离、最小权限和运行时保护。
- 需要支持密文检索或范围查询时，普通对称加密会破坏可查询性，需评估保序加密、可搜索加密或可信执行环境等方案。