数据安全风险评估总结

数据安全风险评估总结

一、基于场景进行安全风险评估

一、概述

数据安全风险评估总结（一）描述了数据安全风险评估的相关理论，数据安全应该关

注业务流程，以基础安全为基础，以数据生命周期及数据应用场景两个维度为入口进行数据

安全风险评估。最后以《信息安全技术信息安全风险评估规范》为参考，并且以信贷业务

中的授信申请为例说明了如何从数据生命周期的维度进行数据安全风险评估，本文将总结常

见的数据应用场景，并且对这些场景中可能涉及到的威胁、脆弱性进行说明，同时补充说明

相关的控制手段。

二、数据安全常见场景

（一）、开发测试

1、场景描述

在开发测试场景中，为了确保软件测试的有效性，往往需要用到与生产环境保持一致

的数据（如数据正确性、完整性、表间关联性、字段关联性、数据保持原有的意义不变等），

最理想的情况下当然是直接使用生产数据，但是这样必然大大增加了数据安全相关的风险,

其中最核心的问题是数据泄露。所以通常需要从生产的备库中提取数据出来，经过去标识化

等脱敏处理后，再将脱敏数据导入开发测试环境中。

2、风险评估说明

在这个过程中需要关注的有流程合规风险（数据提取申请）、数据泄露风险（数据提取

过程的操作风险、脱敏数据传输安全、脱敏数据进入到测试环节后的泄露风险等）。

威胁类型（T）场景（S）脆弱性分析（V）可用的控制措施（M）

VI、无数据提取流程；

Ml、制定数据提取流程，

V2、未严格遵守提取流程；

明确数据提取量级与审

S1、数据提取V3、流程中申请人员、提取操作人员、

T1、流程合规批的级别；

申请脱敏操作人员、核实人员职责不明确，

M2、明确流程关键节点

签批级别不明确，提取范围不明确等，

及流程审计策略。

时间节点不明确等。

VI、操作人员提取后恶意本地保存数Ml、手工脱敏时，全程通

据；过堡垒机进行监控记录；

S1、数据提取

T2、数据泄露V2、手工脱敏，操作人员接触原始数M2、采用自动化脱敏工

操作过程

据；具，如数据库静态脱敏；

V3、数据未进行脱敏、或者数据不彻M3、设置数据交换平台、

底；文件共享平台、或者

V4、操作过程无监控审计；SFTP共享服务器；

V5、无数据防泄露措施。M4、数据加密传输；

M5、测评环境同样需要

VI.数据未加密传输；

S2、脱敏数据安全管控；

V2、数据传输、接收未留下日志记录；

传输安全M6、部署数据防泄露工

V3、无数据防泄露措施。

具；

VI、测评环境业务存在漏洞，暴露在M7、通过桌面云拒绝数

互联网；据落在本地。

S3、进入测试

V2、测试环境安全区域控制不到位；

环境后

V3、超过了申请日期未及时删除；

V4、无数据防泄露措施。

注意：脱敏后的数据也需要注意其传播的范围，防止数据泄露。大量脱敏后的数据累

积后，仍然存在安全风险，即使数据已经全部脱敏，失去了意义，被泄露后由于真假难辨,

势必会给企业带来负面的影响。

（二）、数据运维

1-场景描述

在企业的运维团队中，通常设置了专门的数据库管理人员，数据库管理员会设置多个

不同级别的普通管理员，并且授权给不同的业务组，这里的数据运维场景即适用于企业中对

数据库、数据进行运维管理的场景。

2、风险评估说明

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

据篡改、数据泄露等。

威胁类型（T）场景（S）脆弱性分析（V）可用的控制措施（M）

Ml、实现职责分离，数据

库管理员与系统管理员

权限分离；

VI、数据库管理员拥有系统管理员超

S1、数据库被M2、通过堡垒机、数据库

级权限，可以操作数据库文件；

恶意删除防火墙等措施对高危命

V2、数据库管理员可以执行高危命令。

令进行阻断；

M3、通过数据库审计系

统对SQL语句进行审计。

T1、数据不可用Ml、从运维区域到生产

区域进行严格的隔离，如

果运维的终端从办公区

VI、系统存在高危端口，生产区域向发起访问，还需要严格控

S2、数据库被

运维区域暴露了过多的端口资产；制运维区域到办公区域

勒索病毒加

V2、运维区域可以直接连接到生产区的访问；

密

域的数据库服务器。M2、严禁直接从办公终

端、运维终端连接到服务

器；

M3、禁止上传无关的文

件到数据库服务器。

MK通过流程制度进行

数据备份机制的约束，实

S3、未进行数时在线备份与远程备份；

VI、未进行数据库备份及离线备份；

据库备份或M2、对备份数据进行周

V2、有备份，但是未周期性的进行恢

者有备份但期性的恢复验证测试，并

复验证测试；

恢复验证失且记录结果；

V3、备份介质损坏或者被盗。

败M3、建立备份介质管理

流程，明确保留的份数及

保护措施。

Ml、通过堡垒机、数据库

S1、运维人员防火墙等措施对高危命

T2、数据篡改恶意修改数VI、数据库管理员可以执行高危命令。令进行阻断；

据M2、通过数据库审计系

统对SQL语句进行审计。

Ml、根据业务情况限制

批量数据查询；

S1、运维人员VI、未限制批量查询数据的数量；

M2、严格限制数据下载，

可以批量查V2、未限制运维人员从服务器下载数

必须有相应的申请流程

询、导出、下据；

及审批层级授权；

载数据。V3、无数据防泄露措施。

M3、部署数据防泄露措

施及屏幕水印等。

T3、数据泄露S2、运维人员

查询敏感的

MK严格限制聚合函数

统计信息，如

的使用；

月度营业额、VI、未严格限制给予运维人员的查询

M2、对数据库进行分区，

通过使用聚权限。

防止聚合、推理等导致的

合函数查询

敏感信息泄露。

公司总的收

入等。

（三）、应用访问

1、场景描述

应用访问在宏观的角度是用户对应用程序的访问，从数据流转来讲，是用户从各种应

用作为入口对数据进行访问的行为，即用户通过应用程序对数据进行增、删、改、查等相关

的操作过程。本质上讲，用户对应用的访问实际上就是数据流的流转过程。

2、风险评估说明

应用访问主要的威胁通常来自用户的访问输入，包括正常用户的错误请求及恶意用户

的请求。因此，这一类的场景主要从传统的网络安全进行分析，主要的威胁类型有数据泄露、

数据未授权访问、数据篡改、数据不可用等，具体分析如下：

威胁类型（T）场景（S）脆弱性分析（V）可用的控制措施（M）

S1、应用程序

存在注入类VI、程序存在如SQL注入漏洞；

的漏洞；

T1、数据泄露Ml.引入安全开发流程，

S2、应用程序

控制程序在后端进行校

存在配置错VI、系统配置随意，无规范基线

、口验；

M2、部署WAF、IPS、网

VI、权限设计不合理，角色之间出现页防篡改等工具；

S1、程序存在权限的覆盖，角色权限范围过大，未遵M3、制定系统及程序安

越权漏洞；守“最小授权”；全配置基线；

T2、数据未授权访V2、权限控制存在漏洞，如越权漏洞；M4、对服务器进行安全

问加固。

S2、程序系统

VI、系统存在未授权访问漏洞，如M5、定期进行安全测试、

存在未授权

redis未授权访问。风险评估、WEBSHELL检

访问漏洞

查等。

Six网页、用

VI、系统存在应用漏洞，如注入漏洞；

T3、数据篡改户信息等被

V2、系统被安装WEBSHELL

恶意篡改；

Ml、加强恶意软件防范，

部署防病毒、主机安全等

软件；

S1、系统中了

T4、数据不可用VI、程序被种马，下载了勒索软件；M2、对系统程序等进行

勒索病毒

安全检查、安全测试；

M3、使用IPS工具；

M4、对数据进行备份。

（四）、特权访问

1、场景描述

特权访问严格上来讲不能算作是一个场景，因为权限一定是和某个系统相关联，但是

我们可以抽象地说明一下当系统存在特权账号，当管理员使用这种账号时，可能会存在的数

据安全问题。

2、风险评估说明

系统存在特权账号，通常该账号的权限即为系统的最高权限，但是并不是代表着这使

用这个账号做任何事情，比如查询任何数据都是合规的，因为可能会违背“知其所需”的原

则。在特权账号下，主要的数据安全风险是数据泄露、数据篡改及数据未授权访问相关的问

题。

威胁类型（T）场景（S）脆弱性分析（V）可用的控制措施（M）

VI、系统未对查询的时间跨度、数据Ml、加强特权账号的管

S1、特权账号的条数进行限制；理，如减少使用、双人管

可以对数据V2、系统未对可导出数据的条数进行理、多因素认证等；

T1、数据泄露

进行批量查限制；M2、加强对特权账号使

询、导出V3、特权账号本身存在脆弱性，如密用、操作行为的记录及审

码复杂度不够、未定期修改密码、登录计；

方式单一、未对特权账号的操作行为M3、限制特权账号的批

进行记录审计等。量查询、条数查询等；

M4、严格限制特权账号

VI、系统未对修改、删除权限进行限

的高危操作指令，比如删

S1、特权账号制；

除时，可以进行二次认证

可以对敏感V2、特权账号本身存在脆弱性，如密

T2、数据篡改确认；

数据进行修码复杂度不够、未定期修改密码、登录

M5、对账号的密码策略、

改方式单一、未对特权账号的操作行为

密码强度进行限制要求。

进行记录审计等。

VI、系统未对查询的时间跨度、数据

S1、特权账号

的条数进行限制，查询无限制条件等；

可以对指定

T3、数据未授权访V2、特权账号本身存在脆弱性，如密

的数据进行

问码复杂度不够、未定期修改密码、登录

查询、可以遍

方式单一、未对特权账号的操作行为

历数据等。

进行记录审计等。

（五）、数据修复

1、场景描述

数据修复主要是当生产中的部分数据发生了异常时进行修复，这里说的并不是使用备

份数据进行数据恢复。可能需要从生产库中取出数据，然后在测试环境中执行语句进行修复

测试，最后再将新的数据导入生产库中，或者将测试好的SQL语句在生产库中执行。

2、风险评估说明

从上面的描述可以看出数据修复可以认为是一个高风险操作，不管是上述的哪一种方

式，都可能产生数据安全相关的问题，如数据合规、数据泄露、数据篡改等等。

威胁类型（T）场景（S）脆弱性分析（V）可用的控制措施（M）

S1、流程不合

VI、未制定数据修复的审批流程；Ml、制定明确的数据修

规，操作未遵

T1、数据合规V2、流程中未明确申请、审批、核实等复流程，明确各环节责任

循相关的流

环节的责任人等。人

程。

VI、操作人员提取后恶意本地保存数MK操作过程全程进行

S1、数据提取

据；记录；

环节数据泄

V2、操作过程无监控审计；M2、设置数据交换平台、

露

V3、无数据防泄露措施。文件共享平台、或者

SFTP共享服务器；

M3、数据加密传输；

T2、数据泄露

M4、测试环境同样需要

S1、数据传输VI、数据未加密传输；安全管控；

环节数据泄V2、数据传输、接收未留下日志记录；M5、部署数据防泄露工

露V3、无数据防泄露措施。具；

M6、通过桌面云拒绝数

据落在本地。

T3、数据篡改S1、操作人员VI、未对执行的SQL语句进行审核Ml、对修数的SQL语句

修复数据时，进行审核；

“顺便”篡M2、对修数的行为进行

改数据记录审计。

（六）、年结审计

1、场景描述

年结审计其实是两个不同的事情，包括年终结算以及外部审计，虽然是两个不同的事

情，但是有一个共同的特点，都需要向外部第三方提供数据，而且通常包括比较多的敏感信

息，因此在这里作为一个场景进行描述。通常是外部与公司企业某个部门进行对接，该部门

因为需要使用数据而发起相关的申请，相关的部门提取数据后再转交给该接口人，该接口人

再将数据提供给第三方。

2、风险评估说明

通常上面的场景描述，可以看到这里有一个数据的流转过程，而伴随数据流转过程一

定有一个流程制度在运转，即该过程需要关心合规性，也需要我们关心数据在流转过程中的

安全风险，如数据泄露风险、数据篡改风险。

威胁类型（T）场景（S）脆弱性分析（V）可用的控制措施（M）

VI、无数据提取流程；

Ml、制定数据提取流程，

V2、未严格遵守提取流程；

S1、数据获取明确数据提取量级与审

V3、流程中申请人员、提取操作人员、

及发送流程批的级别；

脱敏操作人员、核实人员职责不明确，

不合规M2、明确流程关键节点

签批级别不明确，提取范围不明确等，

及流程审计策略。

T1、数据合规时间节点不明确等。

VI、与第三方未签署明确的保密协议，Ml,制定并签署保密协

S2、与第三方

未对双方的职责进行明确界定；议；

保密责任界

V2、数据的交接未履行交接协议，明M2、明确交接手续，签字

定

确签收过程。确认。

VI、操作人员提取后恶意本地保存数Ml、手工脱敏时，全程通

据；过堡垒机进行监控记录；

V2、手工脱敏，操作人员接触原始数M2、采用自动化脱敏工

S1、数据提取据；具，如数据库静态脱敏；

操作过程V3、数据未进行脱敏、或者数据不彻M3、设置数据交换平台、

底；文件共享平台、或者

V4、操作过程无监控审计；SFTP共享服务器；

T2、数据泄露

V5、无数据防泄露措施。M4、数据加密传输；

M5、测评环境同样需要

安全管控；

VI、数据未加密传输；

S2、脱敏数据M6、部署数据防泄露工

V2、数据传输、接收未留下日志记录；

传输安全具；

V3、无数据防泄露措施。M7、通过桌面云拒绝数

据落在本地。

（七）、数据治理

1、场景描述

数据治理是一个非常复杂的过程，包括了对数据的整个生命周期的管理，覆盖了业务

经营、风险管理和内部控制流程中的全部数据，覆盖内部数据和外部数据，监管数据等等。

在GBT37973-2019《信息安全技术大数据安全管理指南》中对大数据安全管理基本原则进

行了说明，规定了大数据安全需求、数据分类分级、大数据活动的安全要求、评估大数据安

全风险等环节，但是总体上讲这个标准比较粗略。本部分关于数据治理的安全风险评估也会

从数据安全威胁的角度进行抽象说明，不同的企业会面临着不同的场景，因此会有不同的问

题。数据治理的结果可用于经营分析改进产品、可用于形成统一的分析报表，包括监管报表

等，在本场景后面还有两个场景分别是数据分析及报表报送的相关说明。

2、风险评估说明

大数据安全评估涉及多个方面的评估，比如数据安全合规、大数据跨境、大数据隐私

保护、大数据平台安全、大数据业务应用、大数据安全运营等内容。不管数据治理有多复杂，

我们在安全的角度考虑的是数据的安全性，包括数据的机密性、完整性、可用性、可审计等。

在本场景下，需要综合考虑数据的生命周期的安全。

威胁类型（T）场景（S）脆弱性分析（V）可用的控制措施（M）

VI、数据采集、传输等各阶段不符

M1、参考国家法律法规，

合法律法规，未对数据来源进行合

并以此为合规基线制定

S1、数据生命周规检查；

T1、数据合规企业自己的规程；

期管理不合规V2、企业没有制定相应的流程制

M2、制定审计办法及审

度，数据处理的各环节无流程依

计频率，留存审计日志。

据，无审计流程。

Ml、采用加密传输确保

传输安全；

VI、数据未加密传输；

M2、根据分类分级办法

V2、数据未分级保护，高敏感信息

进行分级管理,敏感数据

未加密存储；

进行脱敏存储、去标识化

V3、数据未分级保护，高敏感信息

存储、或者根据账号权限

未脱敏存储；

显息，

V4、数据治理环境与一般的生产或

M3、遵守“纵深防御”

者办公区域保护级别相同；

策略，大数据治理独立安

V5、数据治理人员可以随意从大数

全区域,严格管理数据的

T2、数据泄露S1、数据被泄露据平台中提取查看数据；

流动方向及区域的访问

V6、存储数据的介质不可控或者故

控制;

障介质处理不当；

M4、实施统一身份认证

V7、数据交换或者提供时无安全控

与授权，全员遵守；

制，无溯源审计措施；

M5、设置数据交换平台、

V8、数据采集源、采集软件、系统

文件共享平台、或者

等存在安全漏洞，无配置基线；

SFTP共享服务器；

V9、用户可下载数据到本地、未部

M6、对基础软硬件设施

署数据防泄露工具。

及系统定期进行漏洞测

试与漏洞扫描；

M7、严格的介质管理措

施,高安全级的存储介质

遵守高级别的介质安全

策略，如存储"机密”数

据的故障介质做销毁处

理，不退回"更换”；

M8、采用堡垒机、云桌面

等措施，严控上传与下载

功能，部署数据防泄露工

具。

Ml、实施统一身份认证

VI、权限设计不合理，角色之间出与授权，全员遵守；

现权限的覆盖，角色权限范围过M2、定期对系统中的权

大，未遵守“最小授权”；限进行梳理，存档记录；

V2、权限控制存在漏洞，如越权漏M3、遵守“纵深防御”

T3、数据未授权访S1、权限控制不洞；策略，大数据治理独立安

问合理或者失效V3、无明确的权限管理及审计办全区域,严格管理数据的

法，在岗用户、转岗用户、离职用流动方向及区域的访问

户未定期清理；控制；

V4、数据治理环境与一般的生产或M4、对基础软硬件设施

者办公区域保护级别相同。及系统定期进行漏洞测

试与漏洞扫描。

（八）、数据分析

1、场景描述

该场景是场景七的一个补充，通常业务部门会需要各种数据来支撑该部门的一些决策

经营，业务部门会向数据分析中心（数据治理的一个团队）提出数据需求及申请，数据中心

会将治理后的数据以业务部门需要的形式进行呈现，用以支撑业务部门的数据分析。

2、风险评估说明

本场景需要关注业务部门获取数据的流程是否合规、传输过程是否安全可控、数据分

析的环境是否安全可控、数据的保留及终端安全等方面，具体如下：

威胁类型（T）场景（S）脆弱性分析（V）可用的控制措施（M）

VI、无数据需求申请流程；

Ml、制定数据申请的流

V2、数据申请流程签批不规范，申

程规范，明确其中的关键

S1,数据申请流请人、提供人、审批人等责任人员

T1、数据合规环节及责任人；

程不合规职责不清晰，时间节点不清晰、申

M2、定期对申请进行审

请的数据范围及保留时长不清楚

计回顾。

等。

VI、数据提供过程未加密、接收者Ml,数据接收者签字确

S1、数据传输过不可控，接收者无确认机制等；认；

T2、数据泄露

程不安全V2、数据传输或者提供的方法不安M2、数据传输采用加密

全，如通过各种即时通讯软件发的方式进行,并且密码要

送、通过私有邮箱发送、通过“各通过独立的通道向接收

种互联网平台的企业邮箱”发送者单点提供；

等等，事后双方均可通过保存的副M3、建立企业数据交换

本再下载到本地；共享平台；

V3、严格禁止提供未去标识化的数M4、严格管理数据治理、

据；数据分析的环境，采用堡

V4、数据提供过程日志不完整，无垒机、云桌面等环节严控

法审计。数据落在本地终端；

M5、进行数据资产的梳

理；

VI、业务人员可以将数据报表下载

到本地电脑；M6、严格限制原始数据

的对外提供,部署数据脱

S2、数据分析的V2、终端未安装杀毒软件或者未保

环境不够安全可持病毒库更新；敏工具；

控V3、数据报表在终端上长期保留，M7、部署数据防泄露工

大量终端上存在分散的数据资产；具；

V4、未部署数据防泄露工具。M8、部署终端安全管理

工具及杀毒软件。

（九）、报表报送

1、场景描述

该场景是场景七的一个补充，在这个场景与数据分析场景有一些类似，少了数据分析

的部分，通常是企业中的某个部门与上级单位或者主管部门对接，该部门根据其要求向数据

中心部门申请数据报表，并且向上级单位或者主管部门提供。

2、风险评估说明

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

威胁类型（T）场景（S）脆弱性分析（V）可用的控制措施（M）

Ml,制定数据申请的流

VI、无数据需求申请流程；程规范，明确其中的关键