数据安全风险评估总结（二）——基于场景进行安全风险评估

一、概述

        数据安全风险评估总结（一）描述了数据安全风险评估的相关理论，数据安全应该关注业务流程，以基础安全为基础，以数据生命周期及数据应用场景两个维度为入口进行数据安全风险评估。最后以《信息安全技术 信息安全风险评估规范》为参考，并且以信贷业务中的授信申请为例说明了如何从数据生命周期的维度进行数据安全风险评估，本文将总结常见的数据应用场景，并且对这些场景中可能涉及到的威胁、脆弱性进行说明，同时补充说明相关的控制手段。

二、数据安全常见场景

（一）、开发测试

1、场景描述

       在开发测试场景中，为了确保软件测试的有效性，往往需要用到与生产环境保持一致的数据（如数据正确性、完整性、表间关联性、字段关联性、数据保持原有的意义不变等），最理想的情况下当然是直接使用生产数据，但是这样必然大大增加了数据安全相关的风险，其中最核心的问题是数据泄露。所以通常需要从生产的备库中提取数据出来，经过去标识化等脱敏处理后，再将脱敏数据导入开发测试环境中。

2、风险评估说明

       在这个过程中需要关注的有流程合规风险（数据提取申请）、数据泄露风险（数据提取过程的操作风险、脱敏数据传输安全、脱敏数据进入到测试环节后的泄露风险等）。

威胁类型（T）	场景（S）	脆弱性分析（V）	可用的控制措施（M）
T1、流程合规	S1、数据提取申请	V1、无数据提取流程； V2、未严格遵守提取流程； V3、流程中申请人员、提取操作人员、脱敏操作人员、核实人员职责不明确，签批级别不明确，提取范围不明确等，时间节点不明确等。	M1、制定数据提取流程，明确数据提取量级与审批的级别； M2、明确流程关键节点及流程审计策略。
T2、数据泄露	S1、数据提取操作过程	V1、操作人员提取后恶意本地保存数据； V2、手工脱敏，操作人员接触原始数据； V3、数据未进行脱敏、或者数据不彻底； V4、操作过程无监控审计； V5、无数据防泄露措施。	M1、手工脱敏时，全程通过堡垒机进行监控记录； M2、采用自动化脱敏工具，如数据库静态脱敏； M3、设置数据交换平台、文件共享平台、或者SFTP共享服务器； M4、数据加密传输； M5、测评环境同样需要安全管控； M6、部署数据防泄露工具； M7、通过桌面云拒绝数据落在本地。
	S2、脱敏数据传输安全	V1、数据未加密传输； V2、数据传输、接收未留下日志记录； V3、无数据防泄露措施。
	S3、进入测试环境后	V1、测评环境业务存在漏洞，暴露在互联网； V2、测试环境安全区域控制不到位； V3、超过了申请日期未及时删除； V4、无数据防泄露措施。

       注意：脱敏后的数据也需要注意其传播的范围，防止数据泄露。大量脱敏后的数据累积后，仍然存在安全风险，即使数据已经全部脱敏，失去了意义，被泄露后由于真假难辨，势必会给企业带来负面的影响。

（二）、数据运维

1、场景描述

       在企业的运维团队中，通常设置了专门的数据库管理人员，数据库管理员会设置多个不同级别的普通管理员，并且授权给不同的业务组，这里的数据运维场景即适用于企业中对数据库、数据进行运维管理的场景。

2、风险评估说明

       在该场景中主要关注的是内部的运维人员及其操作带来的威胁，比如数据不可用、数据篡改、数据泄露等。

威胁类型（T）	场景（S）	脆弱性分析（V）	可用的控制措施（M）
T1、数据不可用	S1、数据库被恶意删除	V1、数据库管理员拥有系统管理员超级权限，可以操作数据库文件； V2、数据库管理员可以执行高危命令。	M1、实现职责分离，数据库管理员与系统管理员权限分离； M2、通过堡垒机、数据库防火墙等措施对高危命令进行阻断； M3、通过数据库审计系统对SQL语句进行审计。
	S2、数据库被勒索病毒加密	V1、系统存在高危端口，生产区域向运维区域暴露了过多的端口资产； V2、运维区域可以直接连接到生产区域的数据库服务器。	M1、从运维区域到生产区域进行严格的隔离，如果运维的终端从办公区发起访问，还需要严格控制运维区域到办公区域的访问； M2、严禁直接从办公终端、运维终端连接到服务器； M3、禁止上传无关的文件到数据库服务器。
	S3、未进行数据库备份或者有备份但恢复验证失败	V1、未进行数据库备份及离线备份； V2、有备份，但是未周期性的进行恢复验证测试； V3、备份介质损坏或者被盗。	M1、通过流程制度进行数据备份机制的约束，实时在线备份与远程备份； M2、对备份数据进行周期性的恢复验证测试，并且记录结果； M3、建立备份介质管理流程，明确保留的份数及保护措施。
T2、数据篡改	S1、运维人员恶意修改数据	V1、数据库管理员可以执行高危命令。	M1、通过堡垒机、数据库防火墙等措施对高危命令进行阻断； M2、通过数据库审计系统对SQL语句进行审计。
T3、数据泄露	S1、运维人员可以批量查询、导出、下载数据。	V1、未限制批量查询数据的数量； V2、未限制运维人员从服务器下载数据； V3、无数据防泄露措施。	M1、根据业务情况限制批量数据查询； M2、严格限制数据下载，必须有相应的申请流程及审批层级授权； M3、部署数据防泄露措施及屏幕水印等。
	S2、运维人员查询敏感的统计信息，如月度营业额、通过使用聚合函数查询公司总的收入等。	V1、未严格限制给予运维人员的查询权限。	M1、严格限制聚合函数的使用； M2、对数据库进行分区，防止聚合、推理等导致的敏感信息泄露。

 

（三）、应用访问

1、场景描述

       应用访问在宏观的角度是用户对应用程序的访问，从数据流转来讲，是用户从各种应用作为入口对数据进行访问的行为，即用户通过应用程序对数据进行增、删、改、查等相关的操作过程。本质上讲，用户对应用的访问实际上就是数据流的流转过程。

2、风险评估说明

       应用访问主要的威胁通常来自用户的访问输入，包括正常用户的错误请求及恶意用户的请求。因此，这一类的场景主要从传统的网络安全进行分析，主要的威胁类型有数据泄露、数据未授权访问、数据篡改、数据不可用等，具体分析如下：

威胁类型（T）	场景（S）	脆弱性分析（V）	可用的控制措施（M）
T1、数据泄露	S1、应用程序存在注入 类的漏洞；	V1、程序存在如SQL注入漏洞；	M1、引入安全开发流程，控制程序在后端进行校验； M2、部署WAF、IPS、网页防篡改等工具； M3、制定系统及程序安全配置基线； M4、对服务器进行安全加固。 M5、定期进行安全测试、风险评估、WEBSHELL检查等。
	S2、应用程序存在配置错误	V1、系统配置随意，无规范基线
T2、数据未授权访问	S1、程序存在越权漏洞；	V1、权限设计不合理，角色之间出现权限的覆盖，角色权限范围过大，未遵守“最小授权”； V2、权限控制存在漏洞，如越权漏洞；
	S2、程序系统存在未授权访问漏洞	V1、系统存在未授权访问漏洞，如redis未授权访问。
T3、数据篡改	S1、网页、用户信息等被恶意篡改；	V1、系统存在应用漏洞，如注入漏洞； V2、系统被安装WEBSHELL
T4、数据不可用	S1、系统中了勒索病毒	V1、程序被种马，下载了勒索软件；	M1、加强恶意软件防范，部署防病毒、主机安全等软件； M2、对系统程序等进行安全检查、安全测试； M3、使用IPS工具； M4、对数据进行备份。

（四）、特权访问

1、场景描述

       特权访问严格上来讲不能算作是一个场景，因为权限一定是和某个系统相关联，但是我们可以抽象地说明一下当系统存在特权账号，当管理员使用这种账号时，可能会存在的数据安全问题。

2、风险评估说明

       系统存在特权账号，通常该账号的权限即为系统的最高权限，但是并不是代表着这使用这个账号做任何事情，比如查询任何数据都是合规的，因为可能会违背“知其所需”的原则。在特权账号下，主要的数据安全风险是数据泄露、数据篡改及数据未授权访问相关的问题。

威胁类型（T）	场景（S）	脆弱性分析（V）	可用的控制措施（M）
T1、数据泄露	S1、特权账号可以对数据进行批量查询、导出	V1、系统未对查询的时间跨度、数据的条数进行限制； V2、系统未对可导出数据的条数进行限制； V3、特权账号本身存在脆弱性，如密码复杂度不够、未定期修改密码、登录方式单一、未对特权账号的操作行为进行记录审计等。	M1、加强特权账号的管理，如减少使用、双人管理、多因素认证等； M2、加强对特权账号使用、操作行为的记录及审计； M3、限制特权账号的批量查询、条数查询等； M4、严格限制特权账号的高危操作指令，比如删除时，可以进行二次认证确认； M5、对账号的密码策略、密码强度进行限制要求。
T2、数据篡改	S1、特权账号可以对敏感数据进行修改	V1、系统未对修改、删除权限进行限制； V2、特权账号本身存在脆弱性，如密码复杂度不够、未定期修改密码、登录方式单一、未对特权账号的操作行为进行记录审计等。
T3、数据未授权访问	S1、特权账号可以对指定的数据进行查询、可以遍历数据等。	V1、系统未对查询的时间跨度、数据的条数进行限制，查询无限制条件等； V2、特权账号本身存在脆弱性，如密码复杂度不够、未定期修改密码、登录方式单一、未对特权账号的操作行为进行记录审计等。

（五）、数据修复

1、场景描述

       数据修复主要是当生产中的部分数据发生了异常时进行修复，这里说的并不是使用备份数据进行数据恢复。可能需要从生产库中取出数据，然后在测试环境中执行语句进行修复测试，最后再将新的数据导入生产库中，或者将测试好的SQL语句在生产库中执行。

2、风险评估说明

       从上面的描述可以看出数据修复可以认为是一个高风险操作，不管是上述的哪一种方式，都可能产生数据安全相关的问题，如数据合规、数据泄露、数据篡改等等。

威胁类型（T）	场景（S）	脆弱性分析（V）	可用的控制措施（M）
T1、数据合规	S1、流程不合规，操作未遵循相关的流程。	V1、未制定数据修复的审批流程； V2、流程中未明确申请、审批、核实等环节的责任人等。	M1、制定明确的数据修复流程，明确各环节责任人
T2、数据泄露	S1、数据提取环节数据泄露	V1、操作人员提取后恶意本地保存数据； V2、操作过程无监控审计； V3、无数据防泄露措施。	M1、操作过程全程进行记录； M2、设置数据交换平台、文件共享平台、或者SFTP共享服务器； M3、数据加密传输； M4、测试环境同样需要安全管控； M5、部署数据防泄露工具； M6、通过桌面云拒绝数据落在本地。
	S1、数据传输环节数据泄露	V1、数据未加密传输； V2、数据传输、接收未留下日志记录； V3、无数据防泄露措施。
T3、数据篡改	S1、操作人员修复数据时，“顺便”篡改数据	V1、未对执行的SQL语句进行审核	M1、对修数的SQL语句进行审核； M2、对修数的行为进行记录审计。

 

（六）、年结审计

1、场景描述

       年结审计其实是两个不同的事情，包括年终结算以及外部审计，虽然是两个不同的事情，但是有一个共同的特点，都需要向外部第三方提供数据，而且通常包括比较多的敏感信息，因此在这里作为一个场景进行描述。通常是外部与公司企业某个部门进行对接，该部门因为需要使用数据而发起相关的申请，相关的部门提取数据后再转交给该接口人，该接口人再将数据提供给第三方。

2、风险评估说明

       通常上面的场景描述，可以看到这里有一个数据的流转过程，而伴随数据流转过程一定有一个流程制度在运转，即该过程需要关心合规性，也需要我们关心数据在流转过程中的安全风险，如数据泄露风险、数据篡改风险。

威胁类型（T）	场景（S）	脆弱性分析（V）	可用的控制措施（M）
T1、数据合规	S1、数据获取及发送流程不合规	V1、无数据提取流程； V2、未严格遵守提取流程； V3、流程中申请人员、提取操作人员、脱敏操作人员、核实人员职责不明确，签批级别不明确，提取范围不明确等，时间节点不明确等。	M1、制定数据提取流程，明确数据提取量级与审批的级别； M2、明确流程关键节点及流程审计策略。
	S2、与第三方保密责任界定	V1、与第三方未签署明确的保密协议，未对双方的职责进行明确界定； V2、数据的交接未履行交接协议，明确签收过程。	M1、制定并签署保密协议； M2、明确交接手续，签字确认。
T2、数据泄露	S1、数据提取操作过程	V1、操作人员提取后恶意本地保存数据； V2、手工脱敏，操作人员接触原始数据； V3、数据未进行脱敏、或者数据不彻底； V4、操作过程无监控审计； V5、无数据防泄露措施。	M1、手工脱敏时，全程通过堡垒机进行监控记录； M2、采用自动化脱敏工具，如数据库静态脱敏； M3、设置数据交换平台、文件共享平台、或者SFTP共享服务器； M4、数据加密传输； M5、测评环境同样需要安全管控； M6、部署数据防泄露工具； M7、通过桌面云拒绝数据落在本地。
	S2、脱敏数据传输安全	V1、数据未加密传输； V2、数据传输、接收未留下日志记录； V3、无数据防泄露措施。

 

（七）、数据治理

1、场景描述

       数据治理是一个非常复杂的过程，包括了对数据的整个生命周期的管理，覆盖了业务经营、风险管理和内部控制流程中的全部数据，覆盖内部数据和外部数据，监管数据等等。在GBT 37973-2019《信息安全技术 大数据安全管理指南》中对大数据安全管理基本原则进行了说明，规定了大数据安全需求、数据分类分级、大数据活动的安全要求、评估大数据安全风险等环节，但是总体上讲这个标准比较粗略。本部分关于数据治理的安全风险评估也会从数据安全威胁的角度进行抽象说明，不同的企业会面临着不同的场景，因此会有不同的问题。数据治理的结果可用于经营分析改进产品、可用于形成统一的分析报表，包括监管报表等，在本场景后面还有两个场景分别是数据分析及报表报送的相关说明。

2、风险评估说明

       大数据安全评估涉及多个方面的评估，比如数据安全合规、大数据跨境、大数据隐私保护、大数据平台安全、大数据业务应用、大数据安全运营等内容。不管数据治理有多复杂，我们在安全的角度考虑的是数据的安全性，包括数据的机密性、完整性、可用性、可审计等。在本场景下，需要综合考虑数据的生命周期的安全。

威胁类型（T）	场景（S）	脆弱性分析（V）	可用的控制措施（M）
T1、数据合规	S1、数据生命周期管理不合规	V1、数据采集、传输等各阶段不符合法律法规，未对数据来源进行合规检查； V2、企业没有制定相应的流程制度，数据处理的各环节无流程依据，无审计流程。	M1、参考国家法律法规，并以此为合规基线制定企业自己的规程； M2、制定审计办法及审计频率，留存审计日志。
T2、数据泄露	S1、数据被泄露	V1、数据未加密传输； V2、数据未分级保护，高敏感信息未加密存储； V3、数据未分级保护，高敏感信息未脱敏存储； V4、数据治理环境与一般的生产或者办公区域保护级别相同； V5、数据治理人员可以随意从大数据平台中提取查看数据； V6、存储数据的介质不可控或者故障介质处理不当； V7、数据交换或者提供时无安全控制，无溯源审计措施； V8、数据采集源、采集软件、系统等存在安全漏洞，无配置基线； V9、用户可下载数据到本地、未部署数据防泄露工具。	M1、采用加密传输确保传输安全； M2、根据分类分级办法进行分级管理，敏感数据进行脱敏存储、去标识化存储、或者根据账号权限显示信息； M3、遵守“纵深防御”策略，大数据治理独立安全区域，严格管理数据的流动方向及区域的访问控制； M4、实施统一身份认证与授权，全员遵守； M5、设置数据交换平台、文件共享平台、或者SFTP共享服务器； M6、对基础软硬件设施及系统定期进行漏洞测试与漏洞扫描； M7、严格的介质管理措施，高安全级的存储介质遵守高级别的介质安全策略，如存储“机密”数据的故障介质做销毁处理，不退回“更换”； M8、采用堡垒机、云桌面等措施，严控上传与下载功能，部署数据防泄露工具。
T3、数据未授权访问	S1、权限控制不合理或者失效	V1、权限设计不合理，角色之间出现权限的覆盖，角色权限范围过大，未遵守“最小授权”； V2、权限控制存在漏洞，如越权漏洞； V3、无明确的权限管理及审计办法，在岗用户、转岗用户、离职用户未定期清理； V4、数据治理环境与一般的生产或者办公区域保护级别相同。	M1、实施统一身份认证与授权，全员遵守； M2、定期对系统中的权限进行梳理，存档记录； M3、遵守“纵深防御”策略，大数据治理独立安全区域，严格管理数据的流动方向及区域的访问控制； M4、对基础软硬件设施及系统定期进行漏洞测试与漏洞扫描。

（八）、数据分析

1、场景描述

       该场景是场景七的一个补充，通常业务部门会需要各种数据来支撑该部门的一些决策经营，业务部门会向数据分析中心（数据治理的一个团队）提出数据需求及申请，数据中心会将治理后的数据以业务部门需要的形式进行呈现，用以支撑业务部门的数据分析。

2、风险评估说明

       本场景需要关注业务部门获取数据的流程是否合规、传输过程是否安全可控、数据分析的环境是否安全可控、数据的保留及终端安全等方面，具体如下：

威胁类型（T）	场景（S）	脆弱性分析（V）	可用的控制措施（M）
T1、数据合规	S1、数据申请流程不合规	V1、无数据需求申请流程； V2、数据申请流程签批不规范，申请人、提供人、审批人等责任人员职责不清晰，时间节点不清晰、申请的数据范围及保留时长不清楚等。	M1、制定数据申请的流程规范，明确其中的关键环节及责任人； M2、定期对申请进行审计回顾。
T2、数据泄露	S1、数据传输过程不安全	V1、数据提供过程未加密、接收者不可控，接收者无确认机制等； V2、数据传输或者提供的方法不安全，如通过各种即时通讯软件发送、通过私有邮箱发送、通过“各种互联网平台的企业邮箱”发送等等，事后双方均可通过保存的副本再下载到本地； V3、严格禁止提供未去标识化的数据； V4、数据提供过程日志不完整，无法审计。	M1、数据接收者签字确认； M2、数据传输采用加密的方式进行，并且密码要通过独立的通道向接收者单点提供； M3、建立企业数据交换共享平台； M4、严格管理数据治理、数据分析的环境，采用堡垒机、云桌面等环节严控数据落在本地终端； M5、进行数据资产的梳理； M6、严格限制原始数据的对外提供，部署数据脱敏工具； M7、部署数据防泄露工具； M8、部署终端安全管理工具及杀毒软件。
	S2、数据分析的环境不够安全可控	V1、业务人员可以将数据报表下载到本地电脑； V2、终端未安装杀毒软件或者未保持病毒库更新； V3、数据报表在终端上长期保留，大量终端上存在分散的数据资产； V4、未部署数据防泄露工具。

（九）、报表报送

1、场景描述

       该场景是场景七的一个补充，在这个场景与数据分析场景有一些类似，少了数据分析的部分，通常是企业中的某个部门与上级单位或者主管部门对接，该部门根据其要求向数据中心部门申请数据报表，并且向上级单位或者主管部门提供。

2、风险评估说明

       本场景关注数据申请的流程是否合规，数据的流程是否安全可控等环节，具体如下：

威胁类型（T）	场景（S）	脆弱性分析（V）	可用的控制措施（M）
T1、数据合规	S1、数据申请流程不合规	V1、无数据需求申请流程； V2、数据申请流程签批不规范，申请人、提供人、审批人等责任人员职责不清晰，时间节点不清晰、申请的数据范围及保留时长不清楚等。	M1、制定数据申请的流程规范，明确其中的关键环节及责任人； M2、定期对申请进行审计回顾； M3、数据对外提供时同样要考虑合规及审计的问题。
T2、数据泄露	S1、数据获取过程发生数据泄露	V1、数据提供过程未加密、接收者不可控，接收者无确认机制等； V2、数据传输或者提供的方法不安全，如通过各种即时通讯软件发送、通过私有邮箱发送、通过“各种互联网平台的企业邮箱”发送等等，事后双方均可通过保存的副本再下载到本地； V3、严格禁止提供未去标识化的数据； V4、数据提供过程日志不完整，无法审计； V5、终端未安装杀毒软件或者未保持病毒库更新； V6、数据报表在终端上长期保留，大量终端上存在分散的数据资产； V7、未部署数据防泄露工具。	M1、数据接收者签字确认； M2、数据传输采用加密的方式进行，并且密码要通过独立的通道向接收者单点提供； M3、建立企业数据交换共享平台； M4、进行数据资产的梳理； M5、严格限制原始数据的对外提供，部署数据脱敏工具； M6、部署数据防泄露工具； M7、部署终端安全管理工具及杀毒软件。
	S2、数据对外提供过程发生数据泄露

三、总结

        本文从各种不同的场景出发，对数据安全的风险评估进行了简要的说明，当然实际情况要远比这里提到的复杂，场景也是千变万化，由于个人认识浅陋，权当作自己的一些心得。如前文所述，数据安全一定是以业务流程为中心的，所以在实际的工作中还需要针对这些场景做进一步的分析细化，个人认为要想把数据安全风险评估分析清楚就一定要去分析业务流程。本文没有再像数据安全风险评估总结（一）中对数据安全风险评估的流程进行分析，而是从场景入手，对场景所面临的威胁与对应措施进行分析，评估过程与上文一致。