数据脱敏项目实施方案.docx

数据脱敏项目实施方案.docx

《数据脱敏项目实施方案.docx》由会员分享，可在线阅读，更多相关《数据脱敏项目实施方案.docx（10页珍藏版）》请在冰豆网上搜索。

数据脱敏项目实施方案

数据脱敏项目实施方案

目录

项目背景3

项目概况4

项目目标4

项目需求4

项目范围4

系统范围4

隐私数据类型5

系统架构图6

系统流程说明6

脱敏平台系统配置7

项目人员8

阶段人员配置8

人员名单8

脱敏算法9

基本要求实现9

脱敏规则实现9

客户名称9

客户证件号码9

地址信息9

电话信息9

EMAIL地址信息10

密码信息10

有效期（日期）信息10

客户编码中身份证号10

账户号10

项目背景

随着银行业务的快速发展，业务生产系统积累了大量包含客户账户等敏感信息的数据。

而这些数据，在银行的很多工作场景中都会得到使用，例如，业务分析、开发测试、审计监管，甚至是一些外包业务等方面，使用的都是真实的业务数据和信息。

如果这些数据发生泄露、损坏，不仅会给银行带来经济上的损失，更重要的是会大大影响用户对于银行的信任度。

如何保证信息安全已经成为银行必须面对的一个重要的问题。

面临挑战：

确保敏感信息安全防止敏感数据泄露

银监会发布的《中国银行业十二五信息科技发展规则监管指导意见》文件中明确提出“完善敏感信息存储和传输等高风险环节的控制措施，对数据、文档的访问应建立严格的审批机制。

对用于测试的生产数据要进行脱敏处理，严格防止敏感数据泄露”。

《银监会信息科技风险现场检查指南》中也强调“测试中如需使用生产数据，应对相应数据进行脱敏、变形处理，当使用生产数据测试时是否得到高级管理层的审批并采取相关限制及进行脱敏处理”。

2014发布的《第317号》文件中也指出对要保护外包环境的数据安全，严格防止敏感数据泄露。

但随着业务发展，更多新应用已经完全不适合利用这些老旧数据进行测试，同步生产环境中的核心数据迫在眉睫。

银行希望在将最新的生产数据导入开发测试环境前，能够对敏感信息进行符合安全原则的变形及脱敏。

他们拟引入适合银行现状及未来发展的数据脱敏产品，在保存数据原始特征的同时改变它的数值，使数据依旧可以被用并与业务相关联，在开发、测试和其它非生产环境以及外包环境中安全地使用脱敏后的真实数据集，从而避免数据泄露的风险。

解决之道：

采用成熟数据脱敏工具配以完善安全管理流程

项目概况

银行过去一直使用真实数据进行开发、测试用途。

这样处理的好处是迅速、有效。

但考虑到客户信息的重要性，为了提高对银行客户的服务水平和信息安全保障，银行决定对开发、测试等非生产环境的数据使用环节进行整改，引入数据脱敏技术对客户信息进行保护。

项目目标

银行考虑开展数据脱敏项目，在保障客户信息安全的基础上，无论是从项目范围，还是功能、效果上，都将成为一个先进和完善的系统。

脱敏系统必须要求满足在数据上安全合规、技术上的可靠、有效、稳定和先进。

在各环节上都要求能够更多的自动化功能，减少不必要的人机交互过程，大幅降低人力成本投入。

实现整个流程的批量化、自动化、智能化处理。

项目需求

本次项目对脱敏系统产品的基本要求有：

1.在不了解数据库结构设计的情况下，能够自动发现和定位任意系统的客户信息所在的表、字段和相应的类型，以便于该系统在多系统范围内推广；

2.脱敏数据要求能满足跨数据库种类、跨业务系统的数据关联性要求；

3.脱敏效率更为高效；

4.使用更为便捷，利于大范围推广；

5.脱敏数据必须为高仿，能够满足数据原有的编码规则和特征，并能仿造原有数据的数据质量问题，达到高仿测试的要求。

项目范围

系统范围

本次计划实施脱敏的业务系统包括：

●核心系统

●前置系统

●信贷系统

●网银

●手机银行系统

隐私数据类型

考虑到为客户提供最基本的信息安全保障，以及开发、测试中的各种实际应用需求，例如制卡等问题，现将此次项目实施中进行脱敏的隐私数据类型规定如下：

1.客户名称：

a）对私：

姓名

b）对公：

企业单位名称

2.证件号码：

a）对私：

居民身份证号、护照号、港澳通行证、户口簿号、军官证等

b）对公：

组织机构代码、工商注册号、纳税人识别号；

3.电话号码：

a）固定电话

b）移动电话

c）传真

4.EMAIL

5.地址信息

6.密码（仅在需要大量账号进行压力测试时）

7.客户编号（仅在客户编号中包含证件号码时）

系统架构图

系统流程说明

根据架构图所示的流程如下：

1.首先从生产的备份恢复到一台中间数据库服务器上，获得一份完整且真实的数据库镜像，考虑到操作系统的差异和资源的重复利用，这里需要准备两台中间服务器，一台为AIX系统一台为Linux系统，根据生产数据库的实际情况进行分别使用；

2.脱敏系统对此数据库进行隐私数据发现，进行隐私数据模型梳理工作；

3.从中间数据库服务器上进行数据抽取，这里只需要抽取含有客户信息的表即可；

4.数据在脱敏平台平台上进行数据漂白脱敏；

5.经过脱敏后的数据回写到中间服务器上，这样中间服务器上的数据库即为一套完整的经过脱敏的数据库；

6.将中间服务器上的数据库通过备份或者拷贝等手段送到开发网段；

7.在开发网段将数据库进行恢复即可使用。

方案优势：

将由于本方案采用回写方式，脱敏系统无须抽取完整的数据库数据，只需要抽取含有客户信息的表进行脱敏处理并且回写即可。

此方案只处理含有敏感信息的表，处理量小，速度快。

脱敏平台系统配置

1.隐私数据模型建立；

a）使用脱敏平台的发现作业对备份恢复出来的业务数据库进行自动化、智能化的扫描，并生成报告；

b）人工对每个系统的自动发现报告进行隐私数据梳理工作，建立正式的隐私数据模型；

c）每个业务系统数据库单独建立一个发现作业，共计5个发现作业；

2.对上述建立的环境进行数据抽取

a）仅抽取包含隐私数据的表，在此可以根据需要设置子集抽取；

b）每个业务系统数据库单独建立一个抽取作业，共计5个抽取作业；

3.数据漂白脱敏：

a）对上述抽取的所有表进行脱敏

b）自动配置脱敏规则

c）脱敏作业：

i.每个业务系统数据库单独建立一个脱敏作业，共计5个漂白作业。

所有作业共享同一个漂白种子值以保证跨数据库系统的数据关联性，且种子值每季度更换一次，由管理员保管；

ii.在有条件的情况下，将多个数据库共用一个脱敏作业，种子值由系统自动管理每次更换，一来能够保证所有系统的数据关联性，二来提高算法安全性。

4.数据装载

a）将所有隐私数据表全量装载

b）装载作业回写至上述建立的临时环境或者测试环境数据库，以此用脱敏数据替换原来的真实数据，形成完整的脱敏数据库。

项目人员

阶段人员配置

阶段

参与人员

职责

需求调研

乙方项目经理

就项目的需求和范围与用户进行商讨

甲方安全负责人

从安全角度提出项目脱敏范围

甲方测试开发人员

从数据使用方角度提出脱敏的可行性范围

系统设计

乙方项目经理

根据用户的实际环境，与行方人员进行商讨脱敏系统架构与逻辑流程

甲方安全负责人

参与商讨合理可行的系统架构

甲方数据库管理员

参与商讨合理可行的系统架构

甲方系统管理员

参与商讨合理可行的系统架构

甲方网络管理员

参与商讨合理可行的系统架构

实施准备

甲方安全负责人

负责协调各方资源

甲方数据库管理员

进行中间数据服务器上的数据库恢复工作

甲方系统管理员

提供足够的虚拟化资源

甲方网络管理员

负责网络配置

系统安装

甲方脱敏负责人

负责协调各方资源与项目跟踪

乙方实施工程师

负责产品安装、调试

系统实施

甲方脱敏负责人

负责协调各方资源与项目跟踪

乙方项目经理

项目跟踪与监控

乙方实施工程师

根据项目实施要求进行各系统的脱敏实施

产品培训

乙方项目经理

项目跟踪与监控

乙方培训讲师

产品培训

甲方学员

产品使用技术学习

项目验收

项目经理

项目实施成果检验

甲方安全负责人

项目实施成果检验

甲方开发测试人员

项目实施成果检验

人员名单

序号

姓名

岗位

联系电话

身份证号码

职责

1

黄晓涛

项目经理

186********

441302************

负责项目人员协调、需求分析、架构设计，产品的安装、实施、调试。

以及项目跟踪。

2

宋永波

实施工程师

180********

610221************

负责项目实施工作。

3

田斌

项目经理

185********

342225************

负责项目实施及售后协调工作。

4

脱敏算法

基本要求实现

多表关联脱敏，包括同一数据库和不同数据库之间，同样字段的关联变化，脱敏平台产品提供两种技术实现关联脱敏：

1.将所有需要保持关联关系的表，包括不同数据库之间的表，同时加入一个“漂白作业”选择列表中，即可实现关联脱敏；

2.若因故无法将所有需要关联的不同数据库或者表一次性在一个“漂白作业”中进行处理，可以在不同的“漂白作业”中<漂白规则>页面，将“漂白种子值（SEED）”设定为同一个固定值，即可实现多表、多数据库的关联脱敏；

脱敏规则实现

所有隐私数据信息都可以使用固定字符串方式替换或者部分替换进行脱敏，但是为了保证脱敏数据的仿真度和测试开发项目组的使用效果，建议使用专用的脱敏算法。

客户名称

对公客户名：

将企业单位名划分为4部分：

行政区划、商号、行业特征、组织方式，脱敏规则允许独立配置4部分是否需要变化，缺省变换商号，其余3部分不变；

对私客户：

将姓名划分为姓氏和名字两部分，脱敏规则允许独立配置两部分是否需要变化，缺省两部分同时变换。

提供百家姓字库和中国名字字库进行脱敏处理。

客户证件号码

证件号码支持中国居民身份证号、护照号、港澳通行证、户口簿号码、军官证等中国地区所有的证件号码，且能保证脱敏后的证件号码能保持该种证据号码的编码规则和校验规则。

地址信息

地址脱敏使用中国任意地址进行替换，使用内置中国地址库进行处理。

电话信息

对移动电话和固定电话号码均采用同一算法，变换号码右边5位，变换位数可根据实际需求设定修改。

EMAIL地址信息

将EMAIL地址分为地址主体和域名两部分，两部分均可单独配置是否需要脱敏。

地址主体在保证唯一性前提下进行随机变换，域名变换成常用公共域名，缺省情况下域名不变换。

密码信息

密码信息根据实际需求分两种脱敏：

1.在开发或压力测试时需要用到客户的登录密码：

此时可以将密码统一修改成同一个值，例如“888888”，然后将888888的加密值直接替换所有账号的密码；

2.在不需要使用登录密码的其它测试开发场景，为了保密，建议使用随机算法进行脱敏；

有效期（日期）信息

日期脱敏分为日期老化、日期更新和随机变换，都能够通过调整变换范围来实现。

同时日期变换中，年、月、日均可单独控制是否变换。

由于脱敏平台的日期变换算法跟身份证中的日期部分算法一直，缺省就能够实现关联脱敏，无需额外配置。

客户编码中身份证号

客户编码中的身份证号，这里稍微扩展一下，变成客户编码中的证件号码，脱敏规则为保留客户编码中的前缀和后缀不变，单纯变换当中的证件号码，且算法与证件号码保持一致，保证脱敏后数据关联性。

账户号

账户号脱敏，首先程序自动判断原账户号的末位是否满足LUHN校验算法，如果不满足，直接变化账号右边6位（位数可调整），如果末尾满足LUHN校验算法，则末尾采用LUHN算法生成。