具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

参阅图1，图1是本申请提供的权限数据的采集方法第一实施例的流程示意图，该方法主要应用于对权限管理系统中基础权限数据的采集，该方法包括：

步骤11：获取权限数据采集指令。

可以理解地，在本实施例中，可以开发一数据采集工具，用于执行本实施例中数据采集的方法。该采集工具可以包括一启动按钮，通过操作该启动按钮实现权限数据采集。

步骤12：基于权限数据采集指令，确定权限管理系统中权限数据的维度；其中，权限数据的维度至少包括用户信息、用户分类以及权限信息中的一种。

可选地，在一实施例中，用户信息可以包括用户姓名、ID(Identity document，身份标识号)、出生日期、籍贯等，还可以进一步包括学历、入职时间等；用户分类可以包括用户在企业中的组织、岗位、群组、业务角色、系统角色、系统权限、系统资源等；权限信息可以包括用户授权、组织授权、岗位授权、群组授权等。

举例而言，一般的权限可以根据用户入职后创建账号后进行自动授权，组织授权、岗位授权、群组授权可以根据用户的组织、岗位、群组进行自动授权，例如用户的岗位是“行政管理”，那么可以在确定该用户的岗位后，自动对该用户进行“行政管理”方面的授权。群组授权则是在用户加入某个群组后进行自动授权，例如企业为了某个项目建立了一个项目群组，邀请某几个用户加入该群组，在加入该群组后，这几个用户自动被进行群组授权。

在本实施例中，权限数据的维度可以包括上述的用户，组织、岗位、群组、业务角色、系统角色，系统权限，系统资源，用户授权，组织授权，岗位授权，群组授权等。

步骤13：开启与权限数据的维度对应的多个线程，并利用每一线程对相应维度的权限数据进行采集。

由于权限管理系统中的权限数据庞杂，特别是对于大型企业，如果仅采用一个通道进行数据采集，一般要花费数个小时，效率较低。本实施例通过开启多个线程，每一个线程对一个维度的权限数据进行采集，大大的提高了数据采集的效率。

可选地，在一实施例中，多线程采用线程池的方式进行构建，线程池中包含了核心线程和非核心线程。具体地，在步骤13中，可以确定线程池的核心线程数；基于核心线程数，开启与权限数据的维度对应的多个核心线程。

另外，在步骤13之后，还可以包括：

步骤14：检测并确认多个线程中第一线程对应的缓冲队列达到目标数据量，开启与第一线程关联的第二线程，并利用第一线程和线程对一个维度的权限数据进行采集。

例如，线程池有10个核心线程和10个非核心线程，权限数据的维度数为8个，则可以启动8个核心线程分别对8个维度的权限数据进行采集。可选地，每一个线程中有一个缓冲队列，如果某一个核心线程的缓冲队列满了之后，可以再启用一个非核心线程对该维度数据进行并行采集，即一个核心线程和一个非核心线程对同一维度线程数据进行并行采集。

再比如，线程池有10个核心线程和10个非核心线程，权限数据的维度数为12个，则可以启动10个核心线程分别对10个维度的权限数据进行采集，另外两个维度的权限数据可以暂停采集。可选地，每一个线程中有一个缓冲队列，如果某一个核心线程的缓冲队列满了之后，可以再启用一个非核心线程对该维度数据进行并行采集，即一个核心线程和一个非核心线程对同一维度线程数据进行并行采集。

可选地，在一实施例中，在采集到权限数据之后，还需要将采集的权限数据保存至权限数据库，权限数据库用于对从各个权限管理系统中采集的权限数据进行存储和管理，权限数据库也可以叫做权限中心或权限中台。企业互联网中台架构，简称中台。在现代，中台和前台、后台对应，指的是在一些系统中，被共用的中间件的集合。常见于网站架构、金融系统。具体参阅图2，图2是本申请提供的权限数据的采集方法第二实施例的流程示意图，该方法主包括：

步骤21：压缩采集的权限数据，得到压缩数据包。

步骤22：导入压缩数据包至权限数据库。

步骤23：在权限数据库解压压缩数据包。

可选地，在一实施例中，在导入压缩数据包之前，还对压缩数据包进行加密，在导入压缩数据包后，还对压缩数据包进行解密。

步骤24：保存解压后的权限数据至权限数据库。

具体地，在采集到的权限数据后，将以加密压缩包的方式直接导入到权限中心，权限中心解压分别读取到数据后导入大数据容器，每个对象单独构建一个索引库，以“企业ID+应用ID+对象ID”的方式进行构建索引库，每个批次的数据以批次ID进行区分后存于同一索引库中。

可理解地，可以直接在权限数据库中对存储的权限数据进行查询。在一种方式中，可以通过输入两个搜索范围信息来对权限数据进行查询，例如，输入“岗位+业务角色”来进行查询，在查询完成后，显示查询到的权限数据。

区别于现有技术，本实施例提供的权限数据的采集方法包括：获取权限数据采集指令；基于权限数据采集指令，确定权限管理系统中权限数据的维度；其中，权限数据的维度至少包括用户信息、用户分类以及权限信息中的一种；开启与权限数据的维度对应的多个线程，并利用每一线程对相应维度的权限数据进行采集。通过上述方式，采用多个线程对权限管理系统中的权限数据进行采集，在多个线程并行运行时，可以大大的节省数据采集的时间，进一步由于每一线程只采集一个维度数据，采集的同时能够对权限数据进行分类，一方面保证了数据的整洁性，另一方面提高了数据采集的效率。

参阅图3，图3是本申请提供的权限数据的分析方法第一实施例的流程示意图，该方法主要用于在上述实施例对权限管理系统中的权限数据进行采集之后，对权限中心的权限数据进行分析，该方法包括：

步骤31：获取第一权限管理系统的第一权限数据。

其中，该第一权限数据包括上述实施例中的多个维度数据，例如用户，组织、岗位、群组、业务角色、系统角色，系统权限，系统资源，用户授权，组织授权，岗位授权，群组授权等。

步骤32：对第一权限数据进行多维度分析，得到多个第一数据分析结果；其中，多维度分析至少包括授权对象分析、授权范围分析和授权内容分析中的一个。

值得说明的是，本实施例中的多维度分析，与上述实施例中的多维度数据中的“维度”并不是对应的，多维度分析不是指对每一维度数据进行单独分析，而是通过多个不同的分析角度对权限数据进行分析。

可选地，在一实施例中，步骤32可以具体包括：从第一权限数据中查询多维度特征数据；分别对多维度特征数据进行分析，得到多个第一数据分析结果。

具体地，如图4所示，图4是本申请提供的分析模型示意图，并行运行多个查询模型，分别从第一权限数据中查询对应维度的特征数据；运行多个分析模型，分别对每一查询模型得到的一个维度的特征数据进行分析，得到多个第一数据分析结果。

下面通过几种分析模型进行具体介绍：

a、禁用分析(禁用对象授予了有效权限)；

例如，用户A属于被禁止授权的对象，但是在数据分析过程中，确定用户A被进行了有效权限的授权。

b、僵尸分析(没有任何组织、岗位或权限授予的游离对象)；

例如，用户A没有任何的组织、岗位或群组，且没有被授予任何权限；或者用户A加入了某一个组织、岗位或群组，但是没有被授予任何的权限。

c、冗余分析(权限数据定义存在重复性编码和名称、规范不统一)；

例如，用户A的ID和用户B的ID重复，或者某一个独有权限，被授予了不同的两个用户；

例如，命名规范为“用户名+ID”，但是有的命名为“ID+用户名”，则可以确定命名不规范。

d、授权范围过大分析(角色关联组织范围覆盖较大)；

例如，用户A被授予了多个权限，其中有的权限是组织a中的用户所应该具有的权限，其中有的权限是组织b中的用户应该具有的权限，导致用户A的权限范围过大。具体地，可以设置一个阈值，例如，当用户A的授权范围超过3个组织时，可以认定为用户A的授权范围过大。

e、授权粒度过大分析(用户或组织授权角色过大)；

授权粒度是指某一权限的粗细程度。例如，用户A可以对某一部门的报表进行查看，而用户B可以对所有部门的报表进行查看，那么，对于报表查看这一权限来说，用户B的授权粒度大于用户A的授权粒度。在本实施例中，通过分析每一用户的授权粒度，来确定每一个用户的授权角色是否过大。

f、各类型人员常用权限分析(各类职能人员都具有的权限)；

企业中不论什么岗位都拥有的权限，例如查看个人信息、工资信息、绩效信息，比如请假申请、报销申请等权限。

g、各类型岗位常用权限分析(各类岗位人员都具有的权限)；

一般指岗位的特有权限，例如财务岗位可以查看财务报表，可以查看每个人提交的报销单等，行政岗位可以查看简历信息等。

上述的例子是对同一企业的同一权限管理系统中的权限数据进行分析，在其他方式中还可以包括以下几种方式：

h、同比分析(本系统不同体检批次的比较)；

同比分析主要是同一系统不同批次的多个数据分析结果之间，进行对比分析。具体可以包括：获取第二权限管理系统的第二权限数据；其中，第一权限管理系统和第二权限管理系统为同一权限管理系统，第一权限数据和第二权限数据为不同批次获取的数据；对第二权限数据进行多维度分析，得到多个第二数据分析结果；对第一数据分析结果和第二数据分析结果进行比较，得到第一比较分析结果。

例如，第一批次分析中确定企业权限数据存在冗余情况，而第二批次分析中确定企业权限数据不存在冗余情况。则可以分析这两次冗余分析不同结果的原因，是否在两个批次之间进行过冗余数据的清理。进一步，由于不同批次的对比，也可以体现出该公司在权限数据管理的改善和进步。

i、环比分析(与本公司其他系统比较)；

环比分析主要是同一企业的不同权限管理系统(例如ERP系统和OA系统)的分析结果之间，进行对比分析。具体可以包括：获取第三权限管理系统的第三权限数据；其中，第一权限管理系统和第三权限管理系统不同，且用于对同一对象群进行权限数据管理；对第三权限数据进行多维度分析，得到多个第三数据分析结果；对第一数据分析结果和第三数据分析结果进行比较，得到第二比较分析结果。

例如，ERP系统分析结果中显示企业存在权限数据冗余问题，而OA系统分析结果中显示企业不存在权限数据冗余问题，则可以分析为什么两个系统之间存在这样的差异，是数据采集阶段不同还是数据分析阶段不同等。进一步，也可以分析出哪个系统更加适合该公司。

j、行比分析(与其他公司同系统比较)。

行比分析主要是不同企业的同一权限管理系统的分析结果，之间的对比分析。具体可以包括：获取第四权限管理系统的第四权限数据；其中，第一权限管理系统和第四权限管理系统为同一权限管理系统，且用于对不同对象群分别进行权限数据管理；对第四权限数据进行多维度分析，得到多个第四数据分析结果；对第一数据分析结果和第四数据分析结果进行比较，得到第三比较分析结果。

例如，A公司和B公司都在使用ERP系统，综合对比两个公司的权限数据情况和分析结果，对两个公司的权限管理进行对比分析。

步骤33：根据多个第一数据分析结果生成权限数据分析报告。

可以理解地，数据分析结果可以包括数字数据、图形、表格等方式来进行体现，然后将数据、图形和表格进行组合生成最终的分析报告。

进一步，在生成分析报告时，可以进一步对每一分析结果进行边界值判断。例如，对每一个分析结果设置一边界值，如冗余数据的边界值为10％，当冗余分析的结果显示冗余数据超过10％时，则可以提出针对冗余数据过多的整改建议，例如，可以删除冗余数据。

区别于现有技术，本实施例提供的权限数据的分析方法包括：获取第一权限管理系统的第一权限数据；对第一权限数据进行多维度分析，得到多个第一数据分析结果；其中，多维度分析至少包括授权对象分析、授权范围分析和授权内容分析中的一个；根据多个第一数据分析结果生成权限数据分析报告。通过上述方式，能够从多个角度对权限数据进行全面分析，检测出权限数据的多角度问题，有利于企业及时发现权限管理的问题以及时整改。

参阅图5，图5是本申请提供的权限数据的同步方法第一实施例的流程示意图，该方法主要用于权限管理系统和权限数据库的权限数据同步。可以理解地，通过上述的实施例将权限管理系统中的权限数据采集到权限数据库中，在权限管理系统和权限数据库中的任一一方都有可能产生权限数据的变更，在一方变更时，需要同步至另一方，本实施例主要是从权限管理系统同步至权限数据库。该方法包括：

步骤51：监听权限管理系统的日志。

权限管理系统中通过日志的形式来纪录权限数据的更变。

其中，日志信息可以包括时间戳、权限变更ID、权限变更内容。进一步，还可以包括该权限变更的操作者。例如，用户A为部门主管，用户B为部门普通员工，用户A在系统上进行操作授予用户B一项权限，那么该日志信息可以包括授权人、被授权人、授权时间、授权内容、权限截止时间等。

监听日志主要是监听日志中的每一条新增的权限变更信息。可以理解地，日志中可能还包括与权限变更无关的操作，例如某用户岗位调动，但是权限没有任何变化，也会产生一条日志信息。在这种情况下，需要注意对非权限变更信息的过滤。

可选地，可以建立一个日志监听插件，用于监听权限管理系统中的日志信息。

步骤52：从日志中确定权限管理系统的权限数据更变信息。

权限的变更可以包括授权和授权，如下所示：

步骤53：根据权限数据更变信息，将权限管理系统中变更的权限数据同步至权限数据库。

可选地，根据权限数据更变信息，在业务数据表中获取对应的权限数据；将获取的权限数据保存至权限数据库中。具体地，获取权限数据变更信息中的业务数据表名以及对应的字段名称；根据业务数据表名查找对应的业务数据表；根据字段名称在所述业务数据表中查找对应的权限数据。

业务数据表的一种形式如下：

例如，某一条权限变更日志中包含信息“Department_table+Is_update”，则可以从大量的业务数据表中查找到上述“Department_table”业务数据表，然后根据字段名称“Is_update”，可以确定是用于编辑部门员工信息的权限数据。

区别于现有技术，本实施例提供的权限数据的同步方法包括：监听权限管理系统的日志；从日志中确定权限管理系统的权限数据更变信息；根据权限数据更变信息，将权限管理系统中变更的权限数据同步至权限数据库。通过上述方式，可以实现权限管理系统和权限数据库的双轨管理方式，在其中一方进行数据变更时，可以方便的同步至另一方，实现了权限数据的多样化管理，提高了管理的能力，并且也避免了权限数据的不一致。

参阅图6，图6是本申请提供的权限数据的同步方法第二实施例的流程示意图，该方法主要用于权限管理系统和权限数据库的权限数据同步。可以理解地，通过上述的实施例将权限管理系统中的权限数据采集到权限数据库中，在权限管理系统和权限数据库中的任一一方都有可能产生权限数据的变更，在一方变更时，需要同步至另一方，本实施例主要是从权限数据库同步至权限管理系统。该方法包括：

步骤61：权限数据库将权限数据变更消息发送给消息中间件。

消息中间件(MQ)是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。

可选地，消息中间件可以采用ActiveMQ、RabbitMQ或Kafka。

步骤62：监听消息中间件中的消息。

可选地，可以在消息中间件中建立多个队列，每一个队列对应一个权限管理系统，例如一个消息队列对应ERP系统，另一个消息队列对应OA系统。

具体地，可以创建一个代理模块，用于监听消息中间件中每个队列中的消息，以确定是否有权限数据要进行同步。可以理解地，代理模块可以是以插件形式存在，也可以通过服务或进程等多种实现方式。代理模块和消息中间件可以位于同一设备，也可以位于不同设备。

步骤63：检测并确认消息中间件中有消息，将权限数据库中变更的权限数据同步至对应的权限管理系统。

具体地，在检测到消息中间件中的一个消息队列中有消息，则消费该消息，确定相应的权限数据，然后将该权限数据插入权限管理系统。

通过上述的两种方式，实现了权限数据的双轨管理，即权限管理系统(EPR系统或OA系统)和权限数据库都可以对权限数据进行管理，无论哪一方做了权限变更，都可以同步至另一方。

进一步，在权限管理系统和权限数据库进行权限数据同步时，如果权限管理系统将某一权限数据同步至权限数据库，对于权限数据库来说，发生了权限数据变更。按照上述的实施例，权限数据库会再次发消息给MQ，再次同步给权限管理系统，这样就会导致权限数据库和权限管理系统往复进行数据同步，以下实施例正是为了解决这样的问题。

区别于现有技术，本实施例提供的限数据的同步方法包括：权限数据库将权限数据变更消息发送给消息中间件；监听消息中间件中的消息；检测并确认消息中间件中有消息，将权限数据库中变更的权限数据同步至对应的权限管理系统。通过上述方式，可以实现权限管理系统和权限数据库的双轨管理方式，在其中一方进行数据变更时，可以方便的同步至另一方，实现了权限数据的多样化管理，提高了管理的能力，并且也避免了权限数据的不一致。

参阅图7，图7是本申请提供的权限数据的同步方法第三实施例的流程示意图，本实施例应用于权限数据库将权限数据同步至权限管理系统，该方法包括：

步骤71：权限数据库将权限数据变更消息发送给消息中间件。

步骤72：监听消息中间件中的消息。

步骤73：检测并确认消息中间件中有消息，对权限数据库中变更的权限数据添加第一标识信息。

可选地，权限数据包括授权对象、授权时间、授权内容和授权标识(即第一标识信息)等，其中，授权标识的添加取决于是哪方执行的权限数据变更，如果是在权限数据库中进行的权限数据变更，则添加第一标识信息。

步骤74：将添加有第一标识信息的权限数据发送至对应的权限管理系统。

在这样方式中，权限管理系统在接收到带有第一标识信息的权限数据时，可以进行正常的同步操作。

参阅图8，图8是本申请提供的权限数据的同步方法第四实施例的流程示意图，本实施例应用于权限管理系统将权限数据同步至权限数据库，该方法包括：

步骤81：监听权限管理系统的日志。

步骤82：从日志中确定权限管理系统的权限数据更变信息。

步骤83：根据权限数据更变信息，对权限管理系统中变更的权限数据添加第二标识信息。

可选地，权限数据包括授权对象、授权时间、授权内容和授权标识(即第二标识信息)等，其中，授权标识的添加取决于是哪方执行的权限数据变更，如果是在权限管理系统中进行的权限数据变更，则添加第二标识信息。

步骤84：将添加有第二标识信息的权限数据，发送至权限数据库。

在这样方式中，权限数据库在接收到带有第二标识信息的权限数据时，可以进行正常的同步操作。

结合上述图7和图8的实施例中，权限数据库检测并确认待同步的权限数据中有第一标识信息，则不进行同步；权限管理系统检测并确认待同步的权限数据中有第二标识信息，则不进行同步。

例如，权限数据库在进行授权操作时，对权限数据添加标识A，权限管理系统在进行授权操作时，对权限数据添加标识B。那么，权限数据库在接收到权限管理系统发送的某一权限数据中包含标识A时，可以确定该权限数据是自身进行授权操作的，则无需再次进行同步操作。同样，权限管理系统在接收到权限数据库发送的某一权限数据中包含标识B时，可以确定该权限数据是自身进行授权操作的，则无需再次进行同步操作。

另外，在其他实施例中，由于EPR系统和OA系统都有现有的权限管理系统，因此，可以不对权限管理系统进行改进，即仅仅在权限数据库进行数据变更时添加标识信息，而权限管理系统进行权限变更时，不做任何的标识。那么，权限数据库则仅对不带任何标识的权限数据进行同步，权限管理系统则仅对带有标识信息的权限数据进行同步。

可选地，在一实施例中，可以按照设定的频率对权限管理系统和权限数据库中的所有权限数据进行一次同步，可以保证两者之间的数据一致性。

参阅图9，图9是本申请提供的权限数据的管理方法第一实施例的流程示意图，该方法包括：

步骤91：从权限管理系统获取数据集；其中，数据集包括基础权限数据、权限变更数据和权限消费数据中的至少一个。

可以理解地，在上述的实施例中，将权限管理系统中的权限数据采集到权限数据库中。本实施例中通过建立一个数据湖，再将权限数据库或者权限管理系统中的权限数据采集到数据湖中，便于进行管理。

数据集可以包括：

可选地，在一实施例中，步骤91可以包括：从权限管理系统获取日志数据；对日志数据中的非权限数据过滤；对过滤后的日志数据进行处理，得到基础权限数据和权限变更数据。

由于权限管理系统中的日志包含非权限变更信息，所以需要对非权限数据过滤。

在数据采集时，可以利用探针采集日志信息，通过采集探针(例如log)采集权限管理系统(例如ERP系统或OA系统)权限数据，以采集增量日志数据，并将权限日志之外的数据进行拦截，保留的日志数据保存在权限数据湖。由于日志中一般包含的是审计日志(授权、受权等)，因此还需要采集基础权限数据对审计数据进行补全。

另外，还可以通过ETL(Extract-Transform-Load)数据采集，ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。ETL通过启用不同的任务，每个任务用于采集不同业务对象(用户、组织、岗位、权限、角色等)的权限增量数据，然后统一控制各个任务的运行，实现数据的采集。

在数据的采集时，可以分为实时采集和非实时采集。实时采集，实时监听权限管理系统的日志数据；将过滤后的日志数据加入缓冲队列，并对缓冲队列中的日志数据进行实时处理；即实时监听到权限管理系统的日志后，立即通过数据流缓冲的方式开展数据的实时计算，实时数据采集。非实时采集，每隔预设时间段从权限管理系统获取一次日志数据；即通过离线计算的构建方式计算一段时间之内的数据，然后进行数据采集。

步骤92：将数据集导入数据湖。

数据湖(Data Lake)是一个以原始格式存储数据的存储库或系统。它按原样存储数据，而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据(如关系型数据库中的表)，半结构化数据(如CSV、日志、XML、JSON)，非结构化数据(如电子邮件、文档、PDF)和二进制数据(如图形、音频、视频)。

步骤93：对数据湖中的数据进行审计，得到审计报告。

数据审计，是用于对权限数据的申请、创建、使用(消费)、回收以及销毁的整个生命周期的审计。

申请过程、创建过程、回收过程、销毁过程的审计，主要是判断申请流程是否合法(满足预设的规则)，申请人、审批人是否满足资质，申请的权限是否符合要求等。

可选地，在审计时，根据需求从权限数据中获取对应的特征数据，通过对特征数据进行分析，获得相应的审计结果。

例如，基于权限消费数据，确定目标权限消费数据对应的当前次消费地点和前一次消费地点；检测并确认当前次消费地点和前一次消费地点不同，则确定目标权限消费数据非法。

可以理解地，以登录权限为例，如果上一个时刻在上海登陆，下一个时刻在深圳登陆，审计为异地登陆。

例如，基于基础权限数据和权限消费数据，确定被消费过的权限数据和总权限数据的比值；检测并确认比值小于设定比例阈值，则确定权限数据的消费率不合格。

可以理解地，某用户具有100个权限，但是日常使用的只有30个权限，那么可以作为数据治理的范畴。

在一可选的实施例中，将审计报告进行展示，展示内容至少包括权限数据的申请、创建、使用、回收以及销毁的生命周期。

例如，可以看板的形式呈现审计结果，企业高管可以看到总共接入了多个业务系统、权限管理效率的提升、多个维度的数据、权限数据库的价值。由于管理查看完整生命周期的“申请-创建-使用-回收-销毁”，最终实现各业务环节的“可管、可知、可溯”。

区别于现有技术，本实施例提供的权限数据的管理方法包括：从权限管理系统获取数据集；其中，数据集包括基础权限数据、权限变更数据和权限消费数据中的至少一个；将数据集导入数据湖；对数据湖中的数据进行审计，得到审计报告。通过上述方式，可以对权限数据库和权限管理系统中的权限数据进行统一管理，追踪每一个权限数据的整个生命周期，实现对每一个环节的管控。

参阅图10，图10本申请提供的权限数据管理装置一实施例的结构示意图，该数据管理装置100包括处理器101和存储器102，存储器102用于存储程序数据，该处理器101用于执行该程序数据以实现如下的方法：

获取权限数据采集指令；基于权限数据采集指令，确定权限管理系统中权限数据的维度；其中，权限数据的维度至少包括用户信息、用户分类以及权限信息中的一种；开启与权限数据的维度对应的多个线程，并利用每一线程对相应维度的权限数据进行采集。

获取第一权限管理系统的第一权限数据；对第一权限数据进行多维度分析，得到多个第一数据分析结果；其中，多维度分析至少包括授权对象分析、授权范围分析和授权内容分析中的一个；根据多个第一数据分析结果生成权限数据分析报告。

监听权限管理系统的日志；从日志中确定权限管理系统的权限数据更变信息；根据权限数据更变信息，将权限管理系统中变更的权限数据同步至权限数据库。

权限数据库将权限数据变更消息发送给消息中间件；监听消息中间件中的消息；检测并确认消息中间件中有消息，将权限数据库中变更的权限数据同步至对应的权限管理系统。

从权限管理系统获取数据集；其中，数据集包括基础权限数据、权限变更数据和权限消费数据中的至少一个；将数据集导入数据湖；对数据湖中的数据进行审计，得到审计报告。

参阅图11，图11是本申请提供的计算机可读存储介质一实施例的结构示意图，该计算机可读存储介质110中存储有程序数据111，该程序数据111在被处理器执行时，用以实现如下的方法：

获取权限数据采集指令；基于权限数据采集指令，确定权限管理系统中权限数据的维度；其中，权限数据的维度至少包括用户信息、用户分类以及权限信息中的一种；开启与权限数据的维度对应的多个线程，并利用每一线程对相应维度的权限数据进行采集。

获取第一权限管理系统的第一权限数据；对第一权限数据进行多维度分析，得到多个第一数据分析结果；其中，多维度分析至少包括授权对象分析、授权范围分析和授权内容分析中的一个；根据多个第一数据分析结果生成权限数据分析报告。

监听权限管理系统的日志；从日志中确定权限管理系统的权限数据更变信息；根据权限数据更变信息，将权限管理系统中变更的权限数据同步至权限数据库。

权限数据库将权限数据变更消息发送给消息中间件；监听消息中间件中的消息；检测并确认消息中间件中有消息，将权限数据库中变更的权限数据同步至对应的权限管理系统。

从权限管理系统获取数据集；其中，数据集包括基础权限数据、权限变更数据和权限消费数据中的至少一个；将数据集导入数据湖；对数据湖中的数据进行审计，得到审计报告。

在本申请所提供的几个实施方式中，应该理解到，所揭露的方法以及设备，可以通过其它的方式实现。例如，以上所描述的设备实施方式仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。

另外，在本申请各个实施方式中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是根据本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。