CN116226894B

CN116226894B - 一种基于元仓的数据安全治理系统及方法

Info

Publication number: CN116226894B
Application number: CN202310518016.0A
Authority: CN
Inventors: 柯挺立; 曾云; 王翔; 张金银
Original assignee: Hangzhou Bizhi Technology Co ltd
Current assignee: Hangzhou Bizhi Technology Co ltd
Priority date: 2023-05-10
Filing date: 2023-05-10
Publication date: 2023-08-04
Anticipated expiration: 2043-05-10
Also published as: CN116226894A

Abstract

本发明公开了一种基于元仓的数据安全治理系统及方法，包括数据采集模块、元仓模块以及基于元仓的安全治理应用模块；其中，所述数据采集模块用于从多个系统和数据库采集数据提供给元仓模块使用；所述元仓模块用于将来自数据采集模块采集的数据整合到一起，形成基础元数据和时间数据；所述安全治理应用模块包括安全分析单元、操作审计单元和风险识别单元；用于通过安全指标体系对元仓模块内的数据进行安全分析、操作审计和风险识别。本系统及方法以元数据为基础，通过建立元数据仓库来统一管理数据资源的元数据信息，实现对数据访问的安全审计和风险预警等功能。

Description

一种基于元仓的数据安全治理系统及方法

技术领域

本发明涉及计算机及数据处理技术领域，尤其是涉及一种基于元仓的数据安全治理系统及方法。

背景技术

数据安全治理是一种重要的数据管理方式，它旨在确保数据的安全性、完整性、可用性和保密性，从而有效保护企业的数据。在数据安全治理中，需要采用一系列的技术和策略来实现数据的安全管理和保障。这些技术和策略包括但不限于以下内容。

1、数据分类和标记：

数据分类和标记是数据安全治理中的一项重要措施。通过对不同的数据进行分类和标记，可以实现对数据的不同管理和保护。例如，企业可以将数据按照机密性、重要性和敏感性等级进行分类，并为每个数据标记相应的标签，以便于对数据的管理和监控。

2、数据备份和恢复：

数据备份和恢复是数据安全治理中的另一个重要措施。通过对数据进行定期备份和恢复，可以有效地减少数据的丢失和损失。此外，数据备份和恢复还可以帮助企业应对各种突发事件和灾难，如火灾、水灾、电力中断等。

3、数据加密和解密：

数据加密和解密是数据安全治理中的一项核心技术。通过对数据进行加密和解密，可以实现对数据的保密和安全性。企业可以采用多种加密算法和技术来对数据进行加密和解密，如AES、DES、RSA等。此外，还可以通过密钥管理和访问控制等技术来加强数据的安全性。

4、安全审计和监控：

安全审计和监控是数据安全治理中的另一个重要环节。通过对数据的访问、修改、删除等操作进行审计和监控，可以及时发现和处理数据的异常情况。企业可以采用多种技术和工具来实现安全审计和监控，如日志审计、入侵检测、安全信息与事件管理（SIEM）等。

5、风险评估和预防：

在数据安全治理中，风险评估是指通过对数据进行全面的评估和分析，识别和定位潜在的数据安全风险，以及评估数据安全风险对组织带来的潜在影响和损失。通过风险评估可以帮助组织了解其数据安全状况，确定数据安全治理的重点和方向。

当前，数据安全的治理越来越重要，数据隐私的泄露和非法使用问题亟待解决。然而，现有的数据安全治理方法仍然存在诸多问题。传统的审计方法需要大量的人力物力投入，效率低下且易出现疏漏，而且不能及时发现新的数据安全问题。此外，数据安全治理还面临着复杂多变的风险，单一的数据安全防护手段往往无法满足实际需求。因此，急需一种更加高效、准确的数据安全治理方法来监测数据安全和隐私。

现有技术的缺陷在于：需要更新维护，基于元仓的自训练算法异常检测模型需要不断地更新和维护，以保证其能够适应不断变化的安全威胁和需求。

由于元仓数据是在离线环境下批量处理的，因此在数据被写入元仓后，需要一定的时间才能被其他系统和应用程序所使用。这种延迟通常被称为“T+1”，即数据写入元仓后至少需要等待一天才能被其他系统和应用程序使用。

在某些情况下，这种延迟可能会导致数据不够及时或不准确，从而影响决策的准确性和时效性。尤其是在需要快速响应的场景下，如安全事件的追踪和响应等，延迟的影响可能更加显著。基于以上，本发明提出一种基于元仓的数据安全治理方法被提出。该方法以元数据为基础，通过建立元数据仓库来统一管理数据资源的元数据信息，实现对数据访问的安全审计和风险预警等功能。

发明内容

针对现有技术存在的问题，本发明的目的在于提供一种基于元仓的数据安全治理系统及方法，能够确保企业数据的安全性、合规性和准确性，以支持企业的业务运营和决策制定。通过建立模型，并对新的数据进行监测和分析，当发现异常情况时，系统会进行相应的预警和处理。相对于基于规则的方法，自学习的方法更具有灵活性和准确性，能够自适应地识别和预防未知的风险和异常情况。同时，审计报表能够全面、准确地记录数据的访问和操作情况，帮助企业和组织进行风险识别和防范。

为实现上述目的，本发明提供一种基于元仓的数据安全治理系统，所述系统包括数据采集模块、元仓模块以及基于元仓的安全治理应用模块；

其中，所述数据采集模块用于从多个系统和数据库采集数据提供给元仓模块使用；

所述元仓模块用于将来自数据采集模块采集的数据整合到一起，形成基础元数据和时间数据；

所述安全治理应用模块包括安全分析单元、操作审计单元和风险识别单元；用于通过安全指标体系对元仓模块内的数据进行安全分析、操作审计和风险识别。

进一步，所述元仓模块中设有数据集成单元，所述数据集成单元用于将来自不同系统和数据源的数据整合到一起；安全治理的数据包含企业敏感元数据、数据中台数仓基础元数据、安全后端的规则元数据以及数据中台用户行为事件数据；将数据分为以下两类：

基础元数据，包含企业敏感元数据、数据中台数仓基础元数据、安全后端的规则元数据；这类数据存储在安全后端或平台其他后端的关系型数据库中；

事件数据，包含数据中台用户行为事件数据；是在用户进行登录、下载以及访问和操作数据中台里数据进行抓取采集。

进一步，对于基础元数据，复用DataSimba数据集成单元能力，利用集成工具将数据同步到元仓模块；对于事件数据，对事件行为进行数据抽象，定义某用户在事件时间时刻在DataSimba数据中台工作空间是进行登录、下载或访问和操作数据在事件触发的时候通个埋点事件收集，构建埋点总线通道，将数据发送到通道上，传输到元仓模块。

进一步，对于埋点服务异常、或者更上游的异常、或者网络异常导致数据迟到的异常场景，利用定时任务，对小文件进行合并，同时根据事件时间重分区数据，且清理掉历史的数据进行处理。

进一步，在基于元仓的数据安全治理过程中使用安全指标体系进行数据安全治理，所述安全指标体系由不同维度的指标构成，通过建立相应的指标，对数据进行监控、识别潜在的安全威胁并及时做出响应。

进一步，所述不同维度的指标包括数据访问指标和数据操作指标。

进一步，所述安全指标体系包含敏感数据分布指标和审计指标；敏感数据分布指标旨在对安全资产进行全盘了解；审计指标通过对单个用户的操作审计和整体操作概率统计达到对审计行为的监控目的。

进一步，元仓模块加工指标的过程，包括如下步骤：

数据清洗：数据清洗包括数据去重、数据补齐、数据修正和数据格式统一；

数据预处理：预处理包括对数据进行格式转换、标准化和聚合操作，以便于后续指标的计算和分析；

数据建模：在数据预处理之后，需要对数据进行建模，将数据转换为元数据；

指标计算：在数据建模之后，需要对数据进行指标的计算和统计；指标的计算基于元数据或基于原始数据进行；计算的结果可以是数值型指标、布尔型指标或枚举型指标；

指标的可视化和展示：可视化和展示方式包括报表、图表和数据透视表。

进一步，所述系统基于规则配置的定时风险识别检测方案进行风险识别；具体包括：

定义规则：指定安全行为监控的监控场景，制定风险识别规则，所述规则包括类别、次数以及检测条件；

实施规则：构建规则引擎，并将制定的规则导入到规则引擎中进行定时识别检测；其中规则引擎由元仓模块提供；

监测风险行为：规则引擎监测系统中的操作，检测行为是否达到规则阈值，超过阈值则定位为发现风险；

发出警报：当发现违规行为时，规则引擎会生成警报记录，并进行相应提示。

一种基于元仓的数据安全治理方法，所述方法应用于根据本发明所述的基于元仓的数据安全治理系统。

本发明的有益效果在于：

合规性：对于许多组织和企业，遵守各种法规和标准是非常重要的，特别是在涉及敏感信息和个人隐私的情况下。数据安全治理通过建立安全策略、流程和控制措施来确保数据的合规性，从而降低了企业可能面临的法律责任和罚款的风险。

改善业务决策：数据安全治理也可以帮助企业更好地了解自己的数据，从而改善业务决策。通过将数据整合到一个中央数据仓库中，并建立适当的数据标准和数据质量控制措施，企业可以更好地了解其业务和客户，并做出更好的决策。

降低成本：数据安全治理可以帮助企业降低数据处理和存储的成本。通过减少重复数据、增强数据质量和利用数据来改善业务决策，企业可以节省成本并提高效率。此外，通过建立安全策略和控制措施，企业可以避免由数据泄露和丢失带来的成本和损失。

附图说明

图1示出了根据本发明实施例基于元仓的数据安全治理系统架构图；

图2示出了根据本发明实施例埋点事件数据采集方案示意图；

图3示出了根据本发明实施例风险识别自训练算法模型技术方案时序图；

图4示出了根据本发明实施例中维度模型的轴表示示意图。

具体实施方式

下面将结合附图，对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

以下结合图1-图4对本发明的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本发明，并不用于限制本发明。

根据本发明的基于元仓的数据安全治理系统的架构如图1所示，本发明的系统包括用户触点层、数据采集层、元仓层和审计应用层。下面将介绍各个层的作用。

其中，所述用户触点层用于规范化用户行为入口，如在Datasimba平台的数据集成频道、研发、运维、API工厂各频道入口的用户操作行为，都将纳入安全治理的范围，同时针对底层平台运维的系统运维操作也标准化纳入数据监测和治理范围。

所述数据采集层作为元仓统一数据入口，采集源分为安全后端和埋点总线通道。埋点总线的数据通过监控用户的操作行为，对操作行为数据进行埋点采集并通过埋点sdk上报埋点收集网关，并由埋点收集网关写入进埋点总线，标准化的采集通道为后续接入其他安全相关数据源提供了拓展性和便利性。

所述元仓层采用数据建模标准的维度建模方法，用于将来自数据采集模块采集的数据进行建模。通过抽象用户域，定义用户操作的资产数据表这个业务过程，构建历史埋点事实和增量埋点事实，用户域的埋点事实模块将提供平台所有用户的所有操作行为的查询和审计支撑。通过抽象安全域等其他数据域，对安全各业务过程构建对应的事实表和维度表，形成元仓的安全治理数据资产，为安全审计应用提供支撑。

所述审计应用层用于数据安全治理应用，提供的功能包含安全分析、操作审计和风险识别，对应地，安全治理应用模块包括安全分析单元、操作审计单元和风险识别单元。

数据集成层包括数据集成单元，所述数据集成单元用于将来自不同系统和数据源的数据整合到一起，以确保元仓中的数据全面、准确、及时，并保障数据的安全性和完整性。首先，安全治理的数据包含企业敏感元数据、数据中台数仓基础元数据、安全后端的规则元数据以及数据中台用户行为事件数据。本发明将数据分为两类：

基础元数据，包含企业敏感元数据、数据中台数仓基础元数据和安全后端的规则元数据；这类数据存储在安全后端或平台其他后端的关系型数据库中；

事件数据，包含数据中台用户行为事件数据；主要是在用户进行登录、下载以及访问和操作数据中台里进行数据抓取采集。

对于基础元数据，本发明利用DataSimba数据集成单元能力，利用集成工具将安全后端的关系型数据库的数据同步到元仓。对于事件数据这种非结构化的数据，本发明对事件行为基于5W理论（分别是What、Why、Where、When和Who）进行数据抽象，定义某用户在事件时间时刻在DataSimba数据中台工作空间是进行登录、下载或访问和操作数据在事件触发的时候通个埋点事件收集，构建埋点总线通道，将数据发送到通道上，给到元仓模块后续使用、分析。事件数据的数据结构定义和样例如下表1所示。

表1：事件数据的数据结构定义和样例表

图2描述了埋点数据的采集方案。埋点数据来源于埋点总线，埋点总线底层是基于kafka的topic进行数据缓冲和存储。

埋点数据的采集方案通过spark streaming开发的任务把kafka的数据同步到元仓的hive表。首先本发明定义kafka的消费组标识meta_base_group用以明确是元仓的消费组，并且定义hive的表结构，表结构需要与埋点数据格式一致，同时将表分成天和小时两个分区，如下所示：

CREATE TABLE IF NOT EXISTS ods_sensor_simba_all_sensor_hi (

`event_id` string COMMENT "事件ID ",

**

)

COMMENT "埋点数据小时增量表"

PARTITIONED BY (ds string,hh string)

STORED AS PARQUET;

其次，创建sparksession，在Spark应用程序中需要创建SparkSession，同时开启对Hive的支持，以便后续可以将数据写入到Hive表中；接下来需要创建StreamingContext，指定数据消费频次、Spark的批处理间隔batch_interval；然后使用Spark Streaming的Kafka Direct API从Kafka读取埋点数据，最后对从Kafka中读取到的埋点数据进行处理和转换，转换成DataFrame的形式。最后一步是将转换后的使用DataFrame API写入到Hive表中。

但是该采集方案需要兼容一些异常场景。如在每5分钟的批次数据会产生很多小文件，影响集群性能,因此本发明构建埋点中间层表ods_sensor_simba_all_sensor_di，通过对初始表每天的各个小文件数据做合并，并写入到对应的表中进行存储。写入的表对应的底层文件将成为规范化的128M的每个文件。虽然做了合并操作，但是历史的小文件还一直在大数据平台中，对于这个异常场景，本发明构建了清理任务，用于对过去n天的数据进行清理，其中n的具体数值和kafka的数据生命周期同步，在保障原始层数据查询范围的同时，对集群性能提供保障。

本发明采用了天和小时的分区进行存储数据。在异常场景里，在收集的时刻，整体的时延是滞后的，可能存在当前的小时数据写入到下一个小时分区里，特别是在跨天分区的场景。同时，也存在埋点服务异常、或者更上游的异常、或者网络异常等等导致数据迟到从而最终导致数据乱序。整体针对乱序的处理方案，本发明通过构建乱序处理任务，对过去n天的数据进行全量读取，并对n天的数据进行排序，其中n的具体数值本发明定义为根据kafka的数据生命周期的设置同步，本实施例中n为7天，并重分区写入到真实事件时间的业务天里。异常处理整体的代码框架如下：

开启动态分区：

set hive.exec.dynamic.partition=true;

set hive.exec.dynamic.partition.mode=nonstrict;

with before_yesterday as (

获取前天之前的近7天的数据：

select

event_id

, *

, ds

from ods_sensor_simba_all_sensor_di

where ds >= ${yyyyMMdd,-7d} and ds <= ${yyyyMMdd,-2d}

), ods_yesterday as (

获取昨天和天边界的数据：

select

event_id

, *

, event_ds as ds

from (

select

event_id

, *

, DATE_FORMAT(event_time, 'yyyyMMdd') as event_ds

from ods_sensor_simba_all_sensor_hi

where (ds = ${yyyyMMdd,-1d} or ds = ${yyyyMMdd})

天边界的数据：

and event_time is not null

) a where cast(event_ds as int) >= ${yyyyMMdd,-7d} and cast(event_ds as int) <= ${yyyyMMdd,-1d}

)

插入到目标表，在设置了hive.exec.dynamic.partition=true之后，插入操作会进行充分区的操作：

insert overwrite table ods_sensor_simba_all_sensor_di partition(ds)

select

event_id

, *

, ds

from (

获取近7天的经过去重之后的数据：

select

ROW_NUMBER() over (partition by event_id) as rank

, event_id

, *

, ds

from (

近7天没有去重的数据=昨天的数据+截止到前天的数据：

select * from before_yesterday

union all

select * from ods_yesterday

) union_set

) a where rank = 1

任务重跑根据事件id进行去重。

结合以上代码的框架，本发明解决异常场景的流程包括如下步骤：

T1.开启动态分区：在Hive中，动态分区是指可以在插入数据时动态地指定分区的值，而不是事先固定分区。这样可以在插入数据时根据数据的属性灵活地指定分区，从而更方便地对数据进行管理。本代码中通过设置Hive参数hive.exec.dynamic.partition和hive.exec.dynamic.partition.mode，开启动态分区，并设置为非严格模式，以便在插入数据时动态地创建分区。

T2.获取前天之前的近7天的数据：在本代码框架中，先通过before_yesterday子查询获取前天之前的近7天的数据。这样做是为了避免因为异常情况导致昨天和今天的数据未写入到对应的分区中而导致数据丢失。前天之前的近7天的数据是指最近7天内并去除了今天和昨天的数据。

T3.获取天边界的数据：此处天边界的数据是指昨天和今天的数据，用于确保昨天和今天的数据能够完整地写入到对应的分区中。

T4.获取昨天和天边界的数据：在本代码框架中，通过ods_yesterday子查询获取昨天和天边界的数据。通过这种方式，可以确保昨天和今天的数据都能够完整地写入到对应的分区中。

T5.获取近7天的没有去重的数据，其中近7天没有去重的数据=昨天的数据+截止到前天的数据：由于在异常情况下可能存在数据迟到从而最终导致数据乱序的情况，因此在本代码框架中，需要获取近7天的没有去重的数据。为了避免数据丢失，需要包含昨天和截止到前天的所有数据。

T6.任务重跑根据事件id进行去重：在处理数据乱序时，可能存在任务重跑的情况，因此需要进行去重操作。在本实施例中，根据事件id进行去重，以确保每个事件只被处理一次。

T7.获取近7天的经过去重之后的数据：在本代码框架中，通过对before_yesterday和ods_yesterday的合并，并通过去重得到了近7天的经过去重之后的数据。这样可以确保所有的事件数据都被正确地写入到对应的分区中，并避免因为异常情况导致数据丢失。

T8.插入到目标表：在本代码框架中，通过开启动态分区，插入到目标表。插入操作会进行充分区的操作，确保所有的数据被正确地写入到对应的分区中。

数据写入到对应的分区之后，本发明对数据进行安全分析。

在基于元仓的数据安全治理过程中，安全指标体系是数据安全治理中不可或缺的一环。本发明的指标体系由不同维度的指标构成，包括数据访问指标、数据操作指标等方面。通过建立相应的指标，有效地对操作行为进行监控并及时做出响应。

首先通过对平台的安全事件进行明确的分类划分如表2所示：

表2：平台的安全事件的分类划分表

基于此，本发明构建如下的指标体系对平台的安全元数据的概览和操作行为进行审计监控，如表3所示：

表3：安全元数据的概览和操作行为进行审计监控的统计表

对于敏感数据分布和单个用户操作审计方面的指标，本发明采用基于统计学的方法进行监控和预测。本发明基于描述性统计，对敏感数据分布进行分析。下面着重对部分指标结合统计学的意义对数据安全审计监控的意义进行说明。

各级别敏感数据总量和占比指标是一种数据分布分析方法，用于了解不同级别敏感数据在整个数据集中所占的比例。在数据安全审计监控中，通过对不同级别的敏感数据占比进行分析，可以更好地把握整个数据安全风险情况，进而采取相应的措施。

各类别敏感数据（字段）占比TOP5是指对敏感数据按照不同类别或标签进行分类，然后分别计算每个类别或标签中占比最高的5个敏感数据字段。这一指标可以帮助企业了解哪些类别或标签的敏感数据更容易被访问或操作，有助于企业加强对这些数据的保护措施。

包含最多敏感数据字段的表TOP10是指在所有的数据表中，包含敏感数据字段数量最多的10张表。利用这个指标，可以对可以对其数据安全风险进行评估和监测，这些表的数据更容易受到攻击者的目标，因此需要更严格的安全保护措施。同时通过分析包含敏感数据字段数量最多的表TOP10，可以了解到哪些表所包含的敏感数据最为集中，从而在数据规划和管理过程中，更有针对性地制定安全策略和措施。最后，对于包含敏感数据字段数量最多的表TOP10，这些表往往是数据流转的关键节点，分析这些表的数据流转情况，可以识别出整个数据流程中的关键节点，从而更好地进行数据治理和安全控制。

单个用户操作审计访问/操作使用敏感数据（字段）总次数是用来衡量一个用户在一定时间范围内对敏感数据的使用频率。这个指标可以用于监测用户是否超出了他们的授权范围或者是否存在其他未授权的行为。

单个用户操作审计异常访问次数是指用户访问敏感数据时触发的异常事件次数，这个指标可以用于识别用户访问行为的风险程度。如果某个用户的异常访问次数很高，那么就需要对其进行更严格的审计监控，以便及时发现并防范数据泄露、盗用等风险。通过统计不同用户的异常访问次数，可以发现哪些用户访问敏感数据的行为更加危险，从而采取相应的安全措施。

风险规则识别的动态异常指标是一种基于规则的风险控制方法，通过时间段、行为次数、操作符号等属性的设置，判定实际发生的行为是否异常。在实际操作中，可以通过监控日志、数据分析等手段获取相关数据，并建立相应的规则模型，从而识别出风险行为，并进行预警或处置。该方法的优点是可以快速识别出异常行为，对于常规的风险控制具有较高的准确性和效率。缺点是对于复杂的风险行为，可能需要针对性更强的模型或算法才能有效识别，同时也需要不断优化规则模型，以保证风险控制的效果。

针对智能风险识别，本发明需要定义所有用户当天每小时登录的次数总量、所有用户当天每小时访问敏感数据行为的次数作为算法模型的特征输入。算法模型是基于历史、无监督、快速、高度自动化的异常检测，能够实现对数据异常时序和频率的检测，如每小时访问行为算法预测异常结果、每小时操作敏感数据行为算法预测异常结果和每小时下载数据行为算法预测异常结果。具体的算法步骤如下：

P1.周期性触发，获取推理样本：用户当天每小时访问/操作/下载敏感数据行为的次数；

P2.获取训练生成的模型文件和中间变量，对推理样本执行希尔伯特黄-孤立森林算法的推理流程；

P3.获取推理样本作为当前轮次的训练样本（T训练样本）；

P4.从存储中获取上一轮次的训练样本（T-1训练样本），以时间为索引对T-1和T训练样本进行拼接、去重、存储，得到完整的训练样本；

P5.对训练样本进行交叉验证，计算评估指标二分轮廓系数；

P6.使用二分轮廓系数最大时的模型参数训练生成希尔伯特黄-孤立森林异常检测模型。

其中，希尔伯特黄-孤立森林算法具体如下：

P2.1对给定的时间序列进行希尔伯特黄变换，得到一组IMF。

P2.2对于每个IMF，使用孤立森林算法进行异常检测。孤立森林是一种快速、可扩展的异常检测算法，通过将数据随机划分成不同的子空间来构建决策树，然后使用树的高度来度量数据点的异常程度。

P2.3将每个IMF的异常检测结果进行合并，得到最终的异常检测结果。可以使用简单的逻辑运算（例如“或”操作）来合并结果。

其中，步骤P6中，二分轮廓系数是衡量异常检测模型结果质量的评估指标。二分轮廓系数考虑的有两个因素：预测为正常的标签和预测为异常的标签的内聚度和分离度，它们的值介于[-1,1]，越趋近于1则代表内聚度和分离度都相对较优。本发明本发明在模型预测的结果中，正常的标签与异常的标签对应的点之间的距离足够的远，同时正常的标签对应的点簇中及异常的标签对应的点簇中的点足够的近，而不考虑正常的点簇之间与异常的点簇之间的情况。

元仓模块加工指标的过程，通过如下步骤进行处理：

S1.数据清洗和预处理：对于数据源中存在的不准确、不完整、重复等问题，需要进行数据清洗。数据清洗包括数据去重、数据补齐、数据修正、数据格式统一等。

在本发明的场景里，访问和登录、下载行为的日志数据是治理场景中非常重要的一部分数据。本发明通过如下手段进行数据清洗和预处理：

去除无效日志：删除所有无效的日志，例如空行、重复行等。

解析日志：将日志内容进行解析，提取出与访问行为相关的关键信息，例如用户ID、时间戳、访问URL等。

格式化数据：对数据进行格式化，统一时间戳格式、URL格式等，方便后续数据处理和分析。

IP地址过滤：对于一些已知的IP地址或者IP地址段，可以进行过滤，避免这些IP地址的访问行为对数据分析产生干扰。

URL过滤：对于一些已知的URL或者URL模式，可以进行过滤，避免这些URL的访问行为对数据分析产生干扰。

频次过滤：对于访问频次异常的用户或者IP地址，可以进行过滤，避免这些用户或者IP地址对数据分析产生干扰。

重复数据检测：对于重复的数据，可以进行去重操作，避免重复数据对数据分析产生干扰。

缺失数据检测：对于缺失的数据，例如缺失的用户ID、时间戳等，可以进行数据填充或者删除操作，避免缺失数据对数据分析产生干扰。

S2.数据建模：在数据清洗、预处理之后，需要对数据进行建模，将数据转换为标准的数据模型。建模对数据实体进行元数据的定义、命名和描述等操作。本发明采用标准的维度建模方法，用于确定业务过程、确定维度、事实等实体以及实体的属性和实体之间的关系。如在敏感数据操作这个业务下，定义事实如下：

事实：敏感字段使用记录事实表，包括：数据库、表、字段、分区、敏感数据等级id、敏感数据等级、数据标签id、数据标签名、工作空间、项目、事件id、事件时间、使用类型（访问-1/操作-2）、敏感字段使用类型、引擎类型、操作代码、用户id、账号名、用户名、用户类型、操作结果等字段。字段包括事件粒度字段“事件id”，以明确事实表中每条记录为对每个表的操作事件，同时本发明还需明确事实的度量，度量一般为数值类型的字段，但在该业务过程下的敏感字段使用记录事实表无度量字段，因此本发明针对各粒度数据定义默认的度量为1；同时，该事实表属性还包括各维表关联字段：项目、使用类型、敏感字段使用类型等维度关联字段。其中维度实体及重要属性的定义如下：

维度一：时间维度（Time Dimension）：包括日期、小时、分钟等属性。用于统计在不同时间段内的敏感数据操作情况，帮助发现敏感数据操作的规律和趋势。

维度二：用户维度（User Dimension）：包括用户ID、用户名称等维度属性。用于分析不同用户的敏感数据操作情况，比如哪些用户的敏感数据操作频率较高，哪些用户的敏感数据操作行为比较可疑。

维度三：敏感数据维度（Data Dimension）：包括敏感数据的名称、ID等信息。用于分析不同敏感数据的操作情况，比如哪些敏感数据被频繁操作，哪些敏感数据操作行为比较可疑。

维度四：操作类型维度（Operation Type Dimension）：包括敏感数据的操作类型，如读取、修改、删除等。用于分析不同类型的敏感数据操作情况，比如哪些操作类型的敏感数据操作频率较高，哪些操作类型的敏感数据操作行为比较可疑。

维度五：操作结果维度（Operation Result Dimension）：包括敏感数据操作的结果，如成功、失败等。用于分析敏感数据操作结果的情况，比如哪些操作结果的敏感数据操作频率较高，哪些操作结果的敏感数据操作行为比较可疑。

经过以上，本发明形成了在敏感数据操作这个业务下的标准星型模型用于后续的指标计算，维度模型的轴表示如图4所示：

其中事件时间作为时间维度属性与实践维度进行关联，用户id作为用户维度和用户表进行关联，操作代码作为操作维度和操作类型维度关联，敏感数据的字段名称和敏感数据维度进行关联，操作结果和操作结果维度进行关联。

S3.指标计算加工：在数据建模之后，需要对数据进行指标的计算和统计。指标的计算可以基于元数据进行，也可以基于原始数据进行。计算的结果可以是数值型指标、布尔型指标、枚举型指标等。结合Datasimba的任务调度子系统，本发明定义了一些列的数据ETL任务，进行指标的加工。任务之间存在数据上的依赖关系，本发明通过定义任务的依赖，来保障被依赖的数据先产出。

在定义了如下的敏感数据使用汇总表：

CREATE TABLE IF NOT EXISTS

dws_sfty_prjct_sensitive_data_use_summary_td (

`project_id` bigint COMMENT "simba项目id",

`project_name` string COMMENT "simba项目名称",

`operate_num_incr` bigint COMMENT "操作次数当日增量",

`operate_num_total` bigint COMMENT "操作次数截止当日总量",

`visit_num_incr` bigint COMMENT "访问次数当日增量",

`visit_num_total` bigint COMMENT "访问次数截止当日总量",

`use_num_incr` bigint COMMENT "使用次数（操作+访问）当日增量",

`use_num_total` bigint COMMENT "使用次数（操作+访问）截止当日总量"

)

COMMENT"项目粒度敏感数据使用截止当日汇总"

PARTITIONED BY (ds string)

其中，project_id：项目ID，唯一标识一个项目。

并且，关于敏感数据指标计算流程如下：

S3.1从敏感数据操作日志中筛选出当日的操作记录，按照项目ID进行聚合计数，得到当日敏感数据操作次数增量。

S3.2从敏感数据操作日志中筛选出所有操作记录，按照项目ID进行聚合计数，得到截止到当日敏感数据操作总次数。

S3.3从敏感数据访问日志中筛选出当日的访问记录，按照项目ID进行聚合计数，得到当日敏感数据访问次数增量。

S3.4从敏感数据访问日志中筛选出所有访问记录，按照项目ID进行聚合计数，得到截止到当日敏感数据访问总次数。

S3.5将当日敏感数据操作次数增量和当日敏感数据访问次数增量相加得到当日敏感数据使用总次数增量。

S3.6将截止到当日敏感数据操作总次数和截止到当日敏感数据访问总次数相加得到截止到当日敏感数据使用总次数。

以上的具体逻辑将通过任务的sql进行加工计算。

S4.指标的可视化和展示：指标的可视化和展示是元仓加工指标的最后一步，其目的是为了方便用户对指标数据的理解和分析。可视化和展示方式包括报表、图表、数据透视表等。可视化渲染的技术有很多，如基于开源/自研BI工具进行配置化渲染，本发明采用Datasimba平台的元仓数据治理方案，因此可视化技术和Datasimba保持一致，采用Html技术并结合Echarts进行实现。同时，本发明将选择符合数据特征的图表展现形式，进行数据层现。如各级别敏感数据占比使用饼图（Pie Chart）进行可视化。饼图可以将数据按照比例分成多个扇形，每个扇形代表一部分数据的比例，通过颜色、标签等视觉元素来区分不同的扇形，直观地展示每个级别敏感数据在总敏感数据中所占的比例。访问/操作使用敏感数据（字段）总次数可以使用折线图（Line Chart）进行可视化；折线图可以清晰地展现时间序列数据的趋势和变化规律，便于数据分析人员及时发现和解决异常情况。同时，折线图还可以进行多维度的展示，如按照不同的敏感数据字段分别绘制不同的折线，帮助用户更好地理解和比较数据。敏感数据被操作使用的Top10可以使用柱状图（Bar Chart）进行可视化。柱状图可以将数据按照大小绘制成不同高度的柱形，通过不同的颜色、标签等视觉元素来区分不同的数据，直观地展示敏感数据被操作使用的次数排名前十的情况。

除了指标体系描述安全行为，本发明还提供对敏感数据以及全平台所有数据的访问和操作行为明细，提供事后事件追踪，确保平台可审计。

数据安全风险描述了数据的敏感性以及出于恶意目的对数据访问的可能性，风险既指损失的可能性，也指构成潜在损失的事务或条件。所以及时发现风险变得尤为重要，以下提供风险识别方案。

本发明提供两种风险识别的方案，基于规则配置的定时风险识别检测方案和无监督的机器学习算法异常检测方案。

本发明通过对各异常监控场景的行为次数进行规则抽象，具体的规则的风险识别方案步骤如下：

定义规则：指定安全行为监控的监控场景，如下载、访问、操作敏感数据以及登录行为，制定适当的规则。规则包括类别、次数以及检测条件。规则将被规则引擎扫描器以元数据的方式使用。

检测风险行为：构建规则引擎，并将制定的规则导入到规则引擎中进行定时识别检测；其中规则引擎由元仓提供。规则引擎的内容主要是将用户的操作行为事实数据和定义的规则进行匹配，当操作行为事实数据满足的规则的定义条件，如登录次数>5，则规则引擎会生成一条异常记录，用于后续异常警报的发出。本发明的检测粒度是基于规则的，在Datasimba平台里，在每个项目里，定义无限制的规则，每个规则的扫描粒度是全平台的，这就会带来计算效率以及性能的低效，甚至会消耗大量资源，为了解决这个问题，本发明采用spark的分布式技术，利用大数据分布式任务的能力，对这种大体量的场景进行支持，保障了计算效率。为了保证资源，避免每个规则都会对全量数据进行扫描，本发明采用临时表方案，临时表里会把每个规则的事实数据进行一次性预处理好，然后每个规则只需要对各种关心的数据进行扫描，扫描完成后，临时表的数据讲会被清理删除。

发出警报：当发现违规行为时，规则引擎会生成警报记录，提示管理员进行处理查阅。管理员可以进一步调查并采取必要的措施，如立即停止相关操作、通知相关人员。

由于规则是预先定义的，因此在面对新的技术、威胁和漏洞时，需要不断更新和维护规则库，才能保证识别的准确性和时效性，因此本发明另外一种方案通过无监督的机器学习算法，直接从数据中学习数据的特征和结构，应用于异常检测任务，具体的方案流程详见图3。在图3时序图里，本发明定义几个角色：安全可视化WEB客户端、DataSecurity安全后端、Mysql数据库、元仓、存储域文件系统，以下是角色建的交互流程包括以下步骤：

Q1.风险管理员基于web开启智能识别的开关；

Q2.安全后端将状态写入mysql数据库；

Q3.元仓通过数据集成的方式拉取智能规则的状态；

Q4.元仓规则引擎识别到开关开启，计算算法的依赖指标项，并调用无监督算法进行训练和推理，智能识别每个小时时间点的访问行为是否为异常行为，将数据写入存储文件系统；

Q5.元仓拿到算法的识别结果，并将数据推入到安全后端的mysql数据库中；

Q6.风险管理员将基于web客户端进行结果查询和感知风险的存在。

本发明的关键点在于：

元仓架构：该方案基于元仓架构，将数据集中存储并进行管理。元仓作为平台测的统一数仓，为治理分析和安全数据分析和决策提供一致的视图。元仓提供大数据引擎的能力，对海量日志进行高效的清洗、加工，以保障安全应用的效率。同时元仓也可提供历史所有的数据备份、回溯，充分保障平台可审计。

审计报表指标体系：建立规范的数据指标体系，以确保数据的合规性和安全性。该指标体系可以帮助用户更好地理解和管理其数据资产，并提供一些标准指标和报表，以协助数据安全审计和监管。

安全审计：该方案可以对数据进行审计和监控，及时发现和防止潜在的安全风险。同时，该方案还可以实现对数据的访问控制和权限管理，从而保护数据的机密性和完整性。

基于规则的数据安全识别：该方案可以通过事先定义的规则和策略，实现对数据的安全识别和监控。该功能可以识别和防范潜在的数据泄露、未授权的数据访问等风险。

无监督机器学习算法的异常检测：该方案还可以通过自学习的方式，实现对用户数据访问、下载和登录行为的异常检测和报警。该功能可以及时发现和防止恶意用户的数据访问和行为，以解决规则识别的静态局限性。

本发明流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为表示包括一个或多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，可以实现在任何计算机刻度介质中，以供指令执行系统、装置或设备，所述计算机可读介质可以是任何包含存储、通信、传播或传输程序以供执行系统、装置或设备使用。包括只读存储器、磁盘或光盘等。

在本说明书的描述中，参考术语“实施例”、“示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。此外，本领域的技术人员可以在不产生矛盾的情况下，将本说明书中描述的不同实施例或示例以及其中的特征进行结合或组合。

上述内容虽然已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型等更新操作。

Claims

1.一种基于元仓的数据安全治理系统，其特征在于，所述系统包括数据采集模块、元仓模块以及基于元仓的安全治理应用模块；

所述元仓模块用于将来自数据采集模块采集的数据整合到一起，形成基础元数据和事件数据；对于基础元数据，利用DataSimba数据集成单元能力，利用集成工具将数据同步到元仓模块；对于事件数据，对事件行为进行数据抽象，定义某用户在事件时刻在DataSimba数据中台工作空间在事件触发的时候通过埋点事件收集，构建埋点总线通道，将数据发送到通道上，传输到元仓模块；

所述安全治理应用模块包括安全分析单元、操作审计单元和风险识别单元；用于通过安全指标体系对元仓模块内的数据进行安全分析、操作审计和风险识别;

解决异常场景，包括如下步骤：

T1.开启动态分区：在Hive中，在插入数据时根据数据的属性指定分区，通过设置Hive参数hive.exec.dynamic.partition和hive.exec.dynamic.partition.mode，开启动态分区，并设置为非严格模式，以便在插入数据时动态地创建分区；

T2.获取前天之前的近7天的数据：先通过before_yesterday子查询获取前天之前的近7天的数据；

T3.获取天边界的数据：天边界的数据是指昨天和今天的数据，用于确保昨天和今天的数据能够完整地写入到对应的分区中；

T4.获取昨天和天边界的数据：通过ods_yesterday子查询获取昨天和天边界的数据；确保昨天和今天的数据都能够完整地写入到对应的分区中；

T5.获取近7天的没有去重的数据，其中近7天没有去重的数据=昨天的数据+截止到前天的数据：

T6.任务重跑根据事件id进行去重：

T7.获取近7天的经过去重之后的数据：通过对before_yesterday和ods_yesterday的合并，并通过去重得到了近7天的经过去重之后的数据；

T8.插入到目标表：通过开启动态分区，插入到目标表；

数据写入到对应的分区之后，对数据进行安全分析。

2.根据权利要求1所述的基于元仓的数据安全治理系统，其特征在于，所述元仓模块中设有数据集成单元，所述数据集成单元用于将来自不同系统和数据源的数据整合到一起；安全治理的数据包含企业敏感元数据、数据中台数仓基础元数据、安全后端的规则元数据以及数据中台用户行为事件数据；将数据分为以下两类：

3.根据权利要求2所述的基于元仓的数据安全治理系统，其特征在于，埋点数据来源于埋点总线，埋点总线底层是基于kafka的topic进行数据缓冲和存储；埋点数据的采集方案用于把kafka的数据同步到元仓的hive表ods_sensor_simba_all_sensor_hi，基于sparkstreaming框架，通过构建spark streaming的应用程序，通过定义消费频次5分钟，对kafkatopic的数据进行消费，并将对应批次写入到hive表对应的天和小时分区中。

4.根据权利要求3所述的基于元仓的数据安全治理系统，其特征在于，对于埋点服务异常、或者更上游的异常、或者网络异常导致数据迟到的异常场景，利用定时任务，对小文件进行合并，同时根据事件时间重分区数据，且清理掉历史的数据进行处理。

5.根据权利要求1所述的基于元仓的数据安全治理系统，其特征在于，在基于元仓的数据安全治理过程中使用安全指标体系进行数据安全治理，所述安全指标体系由不同维度的指标构成，通过建立相应的指标，对数据进行监控、识别潜在的安全威胁并及时做出响应。

6.根据权利要求5所述的基于元仓的数据安全治理系统，其特征在于，所述不同维度的指标包括数据访问指标和数据操作指标。

7.根据权利要求6所述的基于元仓的数据安全治理系统，其特征在于，所述安全指标体系包含敏感数据分布指标和审计指标；敏感数据分布指标旨在对安全资产进行全盘了解；审计指标通过对单个用户的操作审计和整体操作概率统计达到对审计行为的监控目的。

8.根据权利要求7所述的基于元仓的数据安全治理系统，其特征在于，元仓模块加工指标的过程，包括如下步骤：

S1.数据清洗：数据清洗包括数据去重、数据补齐、数据修正和数据格式统一；

S2.数据预处理：预处理包括对数据进行格式转换、标准化和聚合操作，以便于后续指标的计算和分析；

S3.数据建模：在数据预处理之后，需要对数据进行建模，将数据转换为元数据；

S4.指标计算：在数据建模之后，需要对数据进行指标的计算和统计；指标的计算基于元数据或基于原始数据进行；计算的结果可以是数值型指标、布尔型指标或枚举型指标；

S5.指标的可视化和展示：可视化和展示方式包括报表、图表和数据透视表。

9.根据权利要求8所述的基于元仓的数据安全治理系统，其特征在于，所述系统基于规则配置的定时风险识别检测方案进行风险识别；具体包括：

10.一种基于元仓的数据安全治理方法，其特征在于，所述方法应用于根据权利要求1-9任一项所述的基于元仓的数据安全治理系统。