大数据数据安全之数据脱敏
在数据仓库建设过程中，数据安全扮演着重要角色，因为隐私或敏感数据的泄露，会对数据主体（客户，员工和公司）的财产、名誉、人身安全、以及合法利益造成严重损害。因此我们需要严格控制对仓库中的数据访问，即什么样的人员或者需求才可以访问到相关的数据。这就要求对数据本身的敏感程度进行安全级别划分。数据有了安全等级的划分，才能更好管理对数据访问控制，以此来保护好数据安全。
一、数据安全等级划分
在数据脱敏进行之前，我们首先要确定哪些数据要作为脱敏的目标。我们根据公司的业务场景和数据安全级别划分（绝密、高保密、保密、可公开）四个级别， 主要从“高保密”等级的敏感数据，开始进行梳理。
二、数据脱敏
2.1 敏感数据梳理
敏感数据分成四个维度进行梳理，用户、商家、终端、公司：
- 从用户维度进行梳理可能有这些敏感字段如下：手机号码、邮件地址、账号、地址、固定电话号码等信息（此外个人隐私数据相关还有如：种族、政治观点、宗教信仰、基因等）
- 从商家维度进行梳理：合同签订人，合同签订人电话等（不排除全局敏感数据：如商家团购品类等）
- 从用户终端维度进行梳理：能够可能标识终端的唯一性字段，如设备id。
- 从公司角度进行梳理：交易金额、代金卷密码、充值码等
2.2 数据脱敏的方法
数据脱敏可以根据特定的应用场景对敏感字段实施具体的脱敏处理方法，例如：
- 替换：如统一将女性用户名替换为F，这种方法更像“障眼法”，对内部人员可以完全保持信息完整性，但易破解。
- 重排：序号12345重排为54321，按照一定的顺序进行打乱，很像“替换”， 可以在需要时方便还原信息，但同样易破解。
- 加密：编号12345加密为23456，安全程度取决于采用哪种加密算法，一般根据实际情况而定。
- 截断：13811001111截断为138，舍弃必要信息来保证数据的模糊性，是比较常用的脱敏方法，但往往对生产不够友好。
- 掩码: 123456 -> 1xxxx6，保留了部分信息，并且保证了信息的长度不变性，对信息持有者更易辨别， 如火车票上得身份信息。
- 日期偏移取整：20130520 12:30:45 -> 20130520 12:00:00，舍弃精度来保证原始数据的安全性，一般此种方法可以保护数据的时间分布密度。
数据脱敏的原则：
- remain meaningful for application logic(尽可能的为脱敏后的应用,保留脱敏前的有意义信息)
- sufficiently treated to avoid reverse engineer(最大程度上防止黑客进行破解)
数据脱敏示例：
| 字段名称 | 方案 | 举例 | 原则 |
|---|---|---|---|
| 电话号码（moblie） | 掩码 | 13812345678-> 13812340000 | 防止号码泄露，但保留运营商和地区信息 (唯一性，由前端绑定或者注册时约束) |
| 邮件（email） | 截断+ 加密 | hxs@163.com -> 6225888e3a1d4a139f5f5db98d846102b2cd0d@163.com | 保留邮件域信息 |
| 团购密码（code） | 加密 | 4023926843399219 -> 1298078978 | 加密后在一定精度上保持唯一性，并与数据类型一致 |
| 设备号（deviceid） | 加密 | ffbacff42826302d9e832b7e907a212a -> b9c2a61972a19bf21b06b0ddb8ba642d | 加密后保持唯一性 |
2.3 数据脱敏范围与步骤
在数据仓库分层理论中，数据脱敏往往发生在上层，最直接的是在对外开放这一层面上。在实际应用中，我们既要参考分层理论，又要从现有数据仓库生产环境的体系出发，主要在数据维度层（dim），以及基础服务数据层（fact）上实施脱敏。这样，我们可以在下游相关数据报表以及衍生数据层的开发过程中使用脱敏后的数据，从而避免出现数据安全问题。
确认处理的表和字段后，我们还要确保相关上下游流程的正常运行, 以及未脱敏的敏感信息的正常产出与存储（通过更严格的安全审核来进行访问）。
以用户信息表user为例，脱敏步骤如下：
- 首先生产一份ndm_user未脱敏数据，用于未脱敏数据的正常产出。
- 对下游涉及的所有依赖user生产流程进行修改，来确保脱敏后的正常运行，这里主要是确认数据格式，以及数据源的工作。
- 根据对应的脱敏方法对user表中对应的字段进行脱敏处理。
三、数据安全和数据访问隔离控制
待更新…
