企业数据加解密方案
概述
数据保护是近年来关注度极高的议题，一则国家立法，属合规性要求，二则泄漏事件频发，保护核心数据是安全部门最紧迫的里子工程(面子工程要吹得出去，里子工程要落得了地)，然而数据保护从数据的生产、分类分级(打标)、传输、存储、使用、分析、外发到销毁，要全流程介入，任一环节出现缺漏都可能会功亏一篑，这就导致数据防护战线拉得过长，这与安全部门最擅长的重点突破，严卡枢纽的作战方式不同，要回到熟悉的战场就需要找到能牵一发而动全身的发力点，让整个数据链条向其收拢，依靠这种强依赖关系，人力紧缺的安全部门在数据保护的项目运作中也可有的放矢，而这个发力点就是——数据加解密平台。
数据保护方案的前置条件是一定要遵从公司的发展愿景，不能因过度保护而阻碍数据赋能，这也是加解密方案实施过程中最大的阻力，大多数时候评估是否会阻碍数据赋能的话语权在业务方，这就需要方案制订者明确安全红线所在，设置合理的数据分类分级标准，且能提供对业务改动最小的整改方案。
数据分类分级
数据保护建立在合理的数据分类分级标准之上，分级标准相对固定，可直接参考以下表格(源自《CISSP认证考试指南第七版CISSP All in One第7版》)：
而数据分类标准则与公司业务特效强相关，也直接影响整个加解密系统的构架，本文重点阐述关系型数据库格式的敏感数据保护，文档、文件等非结构化数据和数据链路尾端的办公网数据防泄漏不在本议题以内。
站在数据加解密系统的视角，数据可分类为以下两种：
- 封闭数据。即沉寂数据，在业务流程内流转，数据链路在本业务闭环。例如：常见的用户基本信息字段(身份证、邮箱、银行卡、支付密码等)
- 赋能数据。即数据有附加价值，需聚合、分析，数据链路的中后段从业务流向数据仓库，基本已经脱离了原有的数据使用逻辑，加之部分大数据组件在设计之初就忽视安全因素，相当于危楼上建高层，这类数据一定要花大量时间摸清数据流向和脉络。例如：订单数据、用户浏览数据等。
数据加解密方案
加解密算法
算法内容非我所擅长，架构中隐去此类实践，具体内容自行Google。
设计原则
在基于角色的权限访问控制(RBAC)模型中提出了以下三个安全原则，可覆盖本方案：
- 职责分离:加解密密钥分片，业务半片，平台半片，调用时拼接’虎符’，开发、安全、运维多权分立，即便两方共谋都无法复原加密数据；
- 最小权限:本条原则并不在加解密系统体现，他更好的阐述了数据保护的中台系统，即数据DAO层，对业务的授权收敛到SQL语句级别，既可规范业务，也可有效规避SQL注入等攻击；
- 数据抽象:在异常审计环节，加密与解密要分层制定方案；量级异常加密场景极其有限，而解密函数直接关系数据机密性，在函数设计时需尽可能多的收集和透传数据，方便后期审计分析；
数据链路架构
大致的数据流链路如下图：
其中数据逻辑层属数据中台，负责将SQL语句映射为函数调用或SQL语句模型化，审计/配置平台负责对数据逻辑层的异常和加解密系统的调用做联动分析，审计数据调用隐患。
封闭数据的加解密架构
概述
封闭数据场景由于业务特性决定，其数据的机密性大于适用性，加密强度优先级高。
优势与缺陷
- 沉寂数据，适用场景较少；
- 可能存在单点故障；
- 加密强度高，可做到单用户单密钥，单设备单密钥，或者安全等级要求较高的端对端加密。
架构流程
- 提供统一的接口或者服务做加解密；
- 不同字段设定不同加解密算法；
- 设置唯一表示，关联密钥与密文；
- 属较为传统的KMS架构，可根据需有做变动，比如下放密钥，提升安全等级。
赋能数据的加解密架构
设计原则
兼具通用性与可用性，能适配复杂场景。
优势与缺陷
- 架构复杂性，需要分拆密钥系统，心跳接口等模块，架构复杂；
- 逆向风险，密钥下放到业务系统SDK，存在逆向获取到密钥的风险；
- 可用性高，性能和可用性也随之下放到业务方，单点故障隐患较低；
- 灵活且通用，适配场景多，能在数据赋能的场景下通用。
架构流程
- SDK下发到业务机器，设置token和授信IP拉取密钥；
- 设置心跳机制，验证存活和上报日志；
- 分业务和BI两套机制：单业务单密钥，BI维护聚合表信息和权限；
- 密文追加分割字符，用以匹配业务密钥，适配复杂场景。
外发数据
除了以上两类数据以外，电商业务的数据安全拥有更长的链路，POP商家、仓储、物流这些阶段都已经流出企业数据防护架构，而下游的服务商良莠不齐，是快递订单信息泄漏的重灾区，将加解密的架构延伸出去，通过合同约束条款制定规范是现阶段的解决方案，要想彻底解决外发数据的安全隐患，还需要整个行业输出安全标准，做各服务商的准入门槛，这才是最优解。
针对该类数据的保护，投入成本巨大，且需要极大的行业影响力才有能力完成闭环，可参考阿里的打法，其借助阿里云及诸多平台提供了较好的范本。
- 所有产品控制在阿里云场景，虽然业务逻辑上属三方系统，但一直没跑出阿里的五指山；
- 三方系统做埋点监控；
- 御城河系统做统一的监控、调度。
审计
审计平台是加解密架构中最重要的一环，也是后续数据保护体系的关键枢纽，后续的运营工作都围绕此平台展开。
数据模型
在数据中台的位置，需要监控异常的SQL语句调用，和异常量级的数据查询，属基础监控和审计，针对的场景是外部入侵、业务异常请求和违规的数据拉取。
风控策略
风控策略是审计的核心，是基于业务特性的策略定制，在加解密系统的调用接口处尽可能多的获取透传数据，可极大的拓展风控策略范围，针对的场景是各类高风险数据调用和数据链路溯源。
可参考阿里御城河系统部门策略：
以上属参考各类资料后，梳理出的数据加解密平台的架构支干，而数据治理的最大阻力其实在实施阶段，后续如有收获，当再作文详述。