《数据安全法》、《个人信息保护法》等相关的法律法规落地也有近1年的时间了，各个行业的敏感程度不尽相同，像是互联网、运营商、金融等行业在数据安全建设方面走的还是比较快，像是政府这类有强合规需求的客户也在快速加强数据安全的建设，而一些企业则主要还是由实际的需求来驱动。但是无论哪类客户，在数据安全建设上总会提出：我的数据安全应该如何建设？
其实数据安全的建设可以分为：数据安全管理体系、数据安全技术体系和数据安全运营体系，这里先说说对于技术体系建设的一些思考。
目录
一、数据安全风险的来源
1.账号带来的数据安全风险
2.系统及应用带来的数据安全风险
二、数据安全建设的难点
1.数据资产不清晰：
2.数据流动情况不清晰：
3.异常风险难以识别：
4.风险事件难以追溯：
三、数据安全如何落地
1.确认建设范围：
2.确认数据分布情况：
3.确认数据流转情况：
4.数据安全风险分析：
5.确认已有防护措施：
6.形成风险需求清单：
7.形成数据安全方案：
一、数据安全风险的来源
1.账号带来的数据安全风险
账号带来的数据安全风险分为两大类：一类是特权账号；一类是业务账号。
特权账号：就是我们常说的管理员账号，拥有这类账号的人员往往是操作系统管理员、数据库管理员，由于其工作的需要使得其具备较高权限，像是微盟、链家和思科等事件，均是后台相关的人员删除数据或者相关资源给公司带来巨大的损失。
业务账号：就是各类系统的业务账号，一般的业务操作人员安全意识不足，可能存在账号共用、账号外借、违规滥用、违规操作等情况，尤其是对那些存在大量个人敏感信息、金融信息的重要系统，可能带来较大的影响。
2.系统及应用带来的数据安全风险
承载数据的环境以及与数据发生连接的应用同样会对数据的安全产生危险，如：操作系统、WEB应用、API服务接口、数据库自身等。
操作系统：操作系统是承载数据的基础环境，通过对操作系统的渗透与口令爆破等攻击，然后进行提权操作进而控制系统，其中存放的数据无非就是一个个的文件夹，在操作系统层面可以轻易的将数据文件删除或是拷贝泄漏。尤其是近期centos宣布停止更新之后，大量的企业、政府的系统基于centos开发，后期或将面临大量的漏洞被发现且难以修复的问题。
数据库：是数据存储和运行的重要环境，数据库本身也是一种应用，如果说数据库自身存在漏洞，或是数据库版本停止维护，而有些用户的系统短时间内很难迁移到新版本的数据库平台上，将会导致面临漏洞无法修复的情况；同时对于SQL注入攻击，进行提权之后可以建立账号、导出数据、篡改数据等操作。
应用：应用是前端用户访问后端数据的重要渠道，用户使用各类WEB或客户端应用访问后台数据库，各类应用开发的严谨性不同，在各类开发语言的框架下或多或少存在一定的漏洞，应用中往往存储着连接数据库的硬编码账号，通过应用漏洞拿到这些账号可以直接连接到数据库，因此带来较大的安全风险。
API服务接口：现在大家都在建设平台，把各个业务系统打通，通过平台统一调度对外提供服务等等，尤其像是数据中台类产品，大量的通信都依赖于API接口，这些API接口可能存在缺少认证鉴权、越权、注入攻击、内容篡改、爬虫爬取数据、非法留存接口数据等都会对数据泄漏产生直接或者间接威胁。
二、数据安全建设的难点
之所以很多客户问数据安全到底应用如何建设？如何见到建设成效？按照个人理解其实是由以及几个方面导致的：
1.数据资产不清晰：
对于一个机构来讲，可能存在成百上千的系统，老的业务系统可能跑了十几年二十年，以及没有人进行运维；加之有些系统使用频率低，运维人员换了一波又一波；部分业务部门自建系统，未交给信息中心统一管理等等各类因素，很可能导致对于自身存在多少系统以及数据资产不清晰，这种情况下想进行数据安全的建设难度可想而知。
2.数据流动情况不清晰：
各业务系统存在如接口调用、数据交换、库表交换、文件交换等情况，很难全面了解数据的流动情况；不同的业务系统由哪些业务人员访问、操作、这些操作系统由哪些人员进行日常运维；数据是在机构内部流动还是对外提供服务等等无法形成完成的链条，导致数据流动的不可知。
3.异常风险难以识别：
合法的账号有没有被合理使用？相关的服务接口有没有发送未授权数据？将离职人员是否批量下载数据？运维人员是否直连服务器进行了违规操作？这些风险需要通过身份、权限、时间等等综合因素去分析才能够发现。
4.风险事件难以追溯：
由于缺乏相关的监测手段，当数据安全风险事件发生时很难进行定位，包括采用何种方式？在什么时间？被谁泄漏，是外部攻击还是内部人员？泄漏的数据敏感程度如何？会造成多大的内部以及外部影响等等。无法提供完成的证据链条会导致很多情况的不清晰。
三、数据安全如何落地
1.确认建设范围：
数据安全技术建设过程中最怕建设范围不清晰，数据安全可以理解是业务安全的一部分，需要深度的融合到业务当中去，而不同的业务其逻辑又差异巨大，因此在初期需要尽可能早的确认建设范围。
2.确认数据分布情况：
建设范围确认之后，就要对范围内的业务系统进行调研，掌握这些系统后台数据存放的位置，尤其是一些复杂系统（如医院的HIS，往往会与EMR、LIS等系统都有数据调用的接口），这些数据是采用物理服务器还是虚拟化、云平台等等，这些信息会影响到后续的产品选择以及实施方案。
3.确认数据流转情况：
对于各业务系统来讲其数据的产生、使用、存储、共享等等这些情况都不尽相同，建议采用5W1H的方式：谁（who）在什么时间（when）什么地点（where）用什么方式（how）对数据做了什么事情（what），为什么要这么做（why）。这几点搞清楚之后，就可以确认访问主体——人与访问客体——数据之间的关系，便于进行风险分析。
4.数据安全风险分析：
数据安全的风险分析是建设过程中的重要环节，我见过很多同学从网络安全转到数据安全出现水土不服的情况，这就是因为数据安全与业务结合紧密，网络安全往往属于边界安全，与业务的紧密型关联弱一些。数据安全风险分析过程中一定要深入了解业务情况，采用上述方法仔细分析，形成全量数据安全风险清单。
5.确认已有防护措施：
对于一个客户来讲，信息安全建设已经搞了这么多年，往往具备一定的数据安全防护能力，或者说有一些产品在一定程度上能够对数据安全起到作用，这种情况下要对已有能力进行深入的调研，防止重复建设。建议采用风险与安全能力矩阵的方式，这样有助于形成具象的清单，也方便与客户进行确认。
6.形成风险需求清单：
在数据安全风险分析与已有防护措施确认之后，就形成了风险需求清单，对于一些企业类客户，这个时候就可以拿着这份清单去与业主方进行确认了，确认风险中哪些是可以容忍的风险而短期不需要建设的，剔除这些风险之后，就进入到了安全能力选择阶段也就是确认要使用的产品和形成方案阶段了。但是对于政府或者行业类客户来讲，风险需求清单往往还要考虑相关的合规与政策要求，即便某些风险在风险分析阶段需求性不高，但是根据相关要求必须建设的不能遗漏，以免上级部门在评审过程中发现其建设的全面性不足。
7.形成数据安全方案：
数据安全方案会因为业务的差异性导致方案差别巨大，不会像是等保合规方案那种套用一些模块很快就可以输出。而那种标准化方案客户看了之后也会觉得落地性不好，原因就是觉得你不了解实际业务。
在方案编写部分总结几点注意事项：
1.要把实际业务现状讲述清楚；
2.需求分析过程中要把实际需求与合规性需求，要结合业务场景；
3.方案设计尽量针对风险采用什么样的能力来解决，不要直接采用XX产品来解决，要通过具体的安全能力让业主看到如何把某个产品在未来用起来。
