一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

用于确定第三方SDK的方法、装置、设备及存储介质与流程

2021-12-07 21:12:00 来源:中国专利 TAG:

用于确定第三方sdk的方法、装置、设备及存储介质
技术领域
1.本技术实施例涉及特征识别技术领域,尤其涉及个人隐私数据保护领域。


背景技术:

2.随着电子信息化技术的发展,用户个人数据的隐私问题越来越被社会重视,政府部门相继出台个人信息保护的法律法规。
3.按规定,应用程序(app,application)的运营主体对其app内集成的sdk(software development kit,软件开发工具包)所收集个人信息行为/所传输内容/所传输url(uniform resource locator,统一资源定位符)行为负有安全责任。app开发者对其使用的自有sdk(也称第一方sdk)的行为当然十分清楚,但对其使用的第三方sdk的行为却知之甚少,因此要求app应该在自身隐私政策中逐一列出第三方sdk收集的个人信息类别和目的等。为实现此要求,就需要准确的识别出app中集成了哪些第三方sdk,以便对第三方sdk的安全风险等级进行评定。
4.现有技术通常通过基于sdk包名的特征匹配方式来确定app中的第三方sdk。


技术实现要素:

5.本技术实施例提出了一种用于确定第三方sdk的方法、装置、电子设备及计算机可读存储介质。
6.第一方面,本技术实施例提出了一种用于确定第三方sdk的方法,包括:获取待测应用程序中包含的各实际sdk;利用预先构建好的知识图谱确定各所述实际sdk中的第三方sdk;其中,所述知识图谱中记录有每种应用程序与其第三方sdk之间的关联关系。
7.第二方面,本技术实施例提出了一种用于确定第三方sdk的装置,包括:实际sdk确定单元,被配置成获取待测应用程序中包含的各实际sdk;第三方sdk确定单元,被配置成利用预先构建好的知识图谱确定各所述实际sdk中的第三方sdk;其中,所述知识图谱中记录有每种应用程序与其第三方sdk之间的关联关系。
8.第三方面,本技术实施例提供了一种电子设备,该电子设备包括:至少一个处理器;以及与至少一个处理器通信连接的存储器;其中,存储器存储有可被至少一个处理器执行的指令,该指令被至少一个处理器执行,以使至少一个处理器执行时能够实现如第一方面中任一实现方式描述的用于确定第三方sdk的方法。
9.第四方面,本技术实施例提供了一种存储有计算机指令的非瞬时计算机可读存储介质,该计算机指令用于使计算机执行时能够实现如第一方面中任一实现方式描述的用于确定第三方sdk的方法。
10.由于sdk与应用程序之间存在复杂的关联关系,常规通过包名的识别方式效果不佳,为解决这一问题,本技术实施例提供了一种用于确定第三方sdk的方法、装置、电子设备及计算机可读存储介质:首先,获取待测应用程序中包含的各实际sdk;然后,利用预先构建好的知识图谱确定各实际sdk中的第三方sdk;其中,知识图谱中记录有每种应用程序与其
第三方sdk之间的关联关系。
11.本技术通过上述技术方案将本应用于其它领域的知识图谱技术引入了识别应用程序与sdk间关联的新技术领域,借助知识图谱对存在关联的应用程序与sdk间关联关系的整理、归纳能力,得以从更深层次找到两者之间更加全面的关联关系,进而得到更加准确的识别结果,以实现应用程序的安全风险管控。
12.应当理解,本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征,也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
13.通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本技术的其它特征、目的和优点将会变得更明显:
14.图1是本技术可以应用于其中的示例性系统架构;
15.图2是根据本技术的用于确定第三方sdk的方法的一个实施例的流程图;
16.图3是根据本技术的用于确定第三方sdk的方法的另一个实施例的流程图;
17.图4是本技术提供的用于确定第三方sdk的方法中一种构建得到知识图谱的示意图;
18.图5是本技术提供的用于确定第三方sdk的方法中一种app与sdk间的关联信息在知识图谱中的表现形式的示意图;
19.图6是根据本技术的用于确定第三方sdk的装置的一个实施例的结构示意图;
20.图7是适用于实现本技术实施例的用于确定第三方sdk的方法的电子设备的框图。
具体实施方式
21.下面结合附图和实施例对本技术作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释相关发明,而非对该发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与有关发明相关的部分。
22.需要说明的是,在不冲突的情况下,本技术中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本技术。
23.图1示出了可以应用本技术的用于确定第三方sdk的方法、装置、电子设备及计算机可读存储介质的实施例的示例性系统架构100。
24.如图1所示,系统架构100可以包括终端设备101、102、103,网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。
25.用户可以使用终端设备101、102、103通过网络104与服务器105交互,以接收或发送数据等。终端设备101、102、103和服务器105上可以安装有各种用于实现两者之间传输数据的应用,例如应用程序发布类应用、待发布应用程序安全审查类应用、即时通讯类应用等。
26.终端设备101、102、103和服务器105可以是硬件,也可以是软件。当终端设备101、102、103为硬件时,可以是具有显示屏的各种电子设备,包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等;当终端设备101、102、103为软件时,可以安装在上述
所列举的电子设备中,其可以实现成多个软件或软件模块,也可以实现成单个软件或软件模块,在此不做具体限定。当服务器105为硬件时,可以实现成多个服务器组成的分布式服务器集群,也可以实现成单个服务器;服务器为软件时,可以实现成多个软件或软件模块,也可以实现成单个软件或软件模块,在此不做具体限定。
27.服务器105通过内置的各种应用可以提供各种服务,以提供第三方sdk确定服务的待发布应用程序安全审查类应用为例,服务器105在运行该待发布应用程序安全审查类应用时可实现如下效果:首先,接收终端设备101、102或103通过网络104发来的待测应用程序,然后,获取待测应用程序中包含的各实际sdk;接着,利用预先构建好的录有每种应用程序与其第三方sdk之间的关联关系的知识图谱确定出各实际sdk中的第三方sdk。即服务器105通过上述处理步骤确定出待侧应用程序中的第三方sdk,并将其作为结果输出。进一步的,该待发布应用程序安全审查类应用还可以基于输出的第三方sdk提供针对性的安全风险测试,以最终确定该待测应用程序是否符合安全规定的通知返回终端设备101、102或103。
28.需要指出的是,待测应用程序除可以通过网络104从终端设备101、102、103中实时接收到之外,也可以通过各种方式预先存储在服务器105本地。因此,当服务器105检测到本地已经存储有这些数据时(例如待处理队列中还剩余由待测应用程序),可直接从本地获取该待测应用程序,在此种情况下,示例性系统架构100也可以不包括终端设备101、102、103和网络104。
29.为实现准确确定出第三方sdk的目的,本技术所使用的知识图谱无论是构建和使用都需要占用较多的运算资源和具有较强的运算能力,因此本技术后续各实施例所提供的用于确定第三方sdk的方法一般由具有较强运算能力、拥有较多运算资源的服务器105来执行,相应地,用于确定第三方sdk的装置一般也设置于服务器105中。但同时也需要指出的是,在终端设备101、102、103也具有满足要求的运算能力和运算资源时,终端设备101、102、103也可以通过其上安装的待发布应用程序安全审查类应用完成上述本交由服务器105做的各项运算,进而输出与服务器105同样的结果。尤其是在同时存在多种具有不同运算能力的终端设备的情况下,若待发布应用程序安全审查类应用判断出所在的终端设备具有较强的运算能力和剩余较多的运算资源时,也可以让所在的终端设备来执行上述运算,从而适当减轻服务器105的运算压力。相应的,用于确定第三方sdk的装置也可以设置于终端设备101、102、103中。在此种情况下,示例性系统架构100也可以不包括服务器105和网络104。
30.应该理解,图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端设备、网络和服务器。
31.继续参考图2,其示出了根据本技术的用于确定第三方sdk的方法的一个实施例的实现流程200,包括以下步骤:
32.步骤201:获取待测应用程序中包含的各实际sdk;
33.本步骤旨在由用于确定第三方sdk的方法的执行主体(例如图1所示的服务器105)获取到待测应用程序中包含的各实际sdk。
34.具体的,本步骤在执行过程中可根据第一手数据的具体类型划分为两类,其一,在上述执行主体获取到的第一手数据即为待测应用程序(后续将统一简称为待测app)时,确定其中包含的各实际sdk的操作可由上述执行主体来执行,也可以由上述执行主体将接收
到的待测app转发给其它执行主体来完成并接收其确定结果,其中,可用于确定其中包含的各实际sdk的特征包括且不限于sdk的包名、流量特征、代码特征等;其二,在上述执行主体可直接获取到待测app中包含的各实际sdk时,也就是说第一手数据即为包含各实际sdk的列表/集合时,上述执行主体就只需接收到现成的结果即可,无需进行其它操作。
35.应当理解的是,本步骤的目的为获取到待测app中实际包含有哪些sdk的实际sdk列表/集合,以便于后续确定实际sdk列表/集合中的哪些sdk属于该待测app中的第三方sdk。
36.需要说明的是,能够确定出一个待测app中包含有哪些实际sdk,但并不意味着就能够直接确定出哪些实际sdk属于该待测app中的第三方sdk,因为一个实际sdk是否为该待测app的第三方sdk,往往取决于非常多的影响因素,并非仅基于表层的诸如sdk包名、流量等特征就能够得到准确的判断结果。
37.需要指出的是,待测app或待测app中包含的各实际sdk可以由上述执行主体直接从本地的存储设备获取,也可以从非本地的存储设备(例如图1所示的终端设备101、102、103)中获取。本地的存储设备可以是设置在上述执行主体内的一个数据存储模块,例如服务器硬盘,在此种情况下,待测app或待测app中包含的各实际sdk可以在本地快速读取到;非本地的存储设备还可以为其它任何被设置用于存储数据的电子设备,例如一些用户终端等,在此情况下,上述执行主体可以通过向该电子设备发送获取命令来获取所需的待测app或待测app中包含的各实际sdk。
38.步骤202:利用预先构建好的知识图谱确定各实际sdk中的第三方sdk。
39.在步骤201的基础上,本步骤旨在由上述执行主体利用预先构建好的知识图谱确定各实际sdk中的第三方sdk。为实现本步骤的目的,本技术预先构建好了记录有每种app与其第三方sdk之间的关联关系的知识图谱。
40.应当理解的是,拥有能够准确识别第三方sdk的能力对app安全防护、隐私合规等领域来说都是必不可少的。但是app数量众多(几千万量级),第三方sdk总量也是成千上万。识别并获得app或sdk的信息(开发者、代码、特征等)相对较为容易,即基于识别出的sdk的信息来确定app中包含有哪些sdk相对较为容易,最困难的是如何确定sdk开发者和app开发者的关系(用于确定自有sdk还是第三方sdk的信息),这个信息无法从分析app本身代码来得到,也无法通过知识的简单积累中得到,即如何确定出各实际sdk中哪些是属于该待测app的第三方sdk是当前的难点。
41.为解决这一难点,本技术引入了知识图谱的概念,知识图谱(knowledge graph),最早出现在图书情报界,也被称为知识域可视化或知识领域映射地图,是显示知识发展进程与结构关系的一系列各种不同的图形,用可视化技术描述知识资源及其载体,挖掘、分析、构建、绘制和显示知识及它们之间的相互联系。当前知识图谱被主要应用在:搜索引擎、社交网络、人力资源与招聘、金融、保险、零售、广告、物流、通信、it、制造业、传媒、医疗、电子商务和物流等领域。针对风险控制领域,主要被应用于反欺诈、反洗钱、互联网授信、保险欺诈、银行欺诈、电商欺诈、项目审计作假、企业关系分析、罪犯追踪等场景中。
42.基于知识图谱的特性,本技术用节点和关系所组成的知识图谱来为两者之间存在复杂关联的app和sdk进行直观地建模,以期通过对不同知识之间关联性的分析和整理形成一个更加直观、清晰的网状知识结构。形成这个知识图谱的过程本质是在建立机器或自动
化设备对app与sdk之间关联的认知能力,并且可以通过知识的积累让这种认知能力越来越强大。
43.为构建得到一个能够实现本步骤目的的知识图谱,就需要尽可能的从尽可能多的渠道寻找到所有可能表征app和sdk之间关联关系的信息,包括且不限于:app和sdk的版本号、包名、应用名、类名列表、方法列表、证书签名、类签名、申请的权限列表、函数调用图、敏感api(application programming interface,应用程序编程接口)调用信息、ui(user interface,用户界面)布局信息、图标、资源文件、字符串资源、访问的网址和ip地址、程序中内置的uri(uniform resource identifier,统一资源标识符)、个人信息保护政策(隐私政策)、官方网址、官方服务器地址、历史版本、发行渠道、用户分布、开发者(厂商)的全名、别名、简称、公司性质、国别、公司注册名、联系方式、负责人、经营范围、成立时间、股权关系、子公司信息、母公司信息、关联公司信息中的至少一项。基于上述内容,结合知识图谱的构建顺序和实际应用场景下的实际需求,灵活的构建出不同的知识图谱,此处不做具体限定。同时,为了保障知识图谱的准确性,还可以按预设周期对知识图谱中的关联信息进行增量更新和调整,以尽可能的降低调整的工作量。
44.进一步的,为实现高准确的判断,除依赖于收集到更多的信息和知识之外,同样也依赖于对获取到的信息和知识的深加工处理,以“xx公司”为例,其可能代表着以“xx”为名的多个注册公司实体,那么其具体表征何种含义就需要综合利用自然语言处理、数据分析技术来进行分析、处理。
45.更进一步的,由于第三方sdk普遍以jar或者aar格式对外发布,app开发者无法阅读源代码,因此app者不了解第三方sdk的全部功能和安全风险。同时,app和第三方sdk在同一进程下运行,两者共享权限,第三方sdk可以在用户或者app开发者不知情的情况下收集个人信息,还可能嵌入恶意代码,现有的访问控制机制却又无法区分个人信息访问请求的来源。因此,在准确识别出第三方sdk的基础上,为了不使包含存在安全风险的第三方sdk的待测app被发布至用户的智能移动终端,还可以基于预设的安全风险管控标准对第三方sdk进行安全风险测试,以阻止不符合要求的应用程序被发布至用户端。
46.本实施例提供了一种用于确定第三方sdk的方法:首先,获取待测应用程序中包含的各实际sdk;然后,利用预先构建好的知识图谱确定各实际sdk中的第三方sdk;其中,知识图谱中记录有每种应用程序与其第三方sdk之间的关联关系。本实施例通过上述技术方案将本应用于其它领域的知识图谱技术引入了识别应用程序与sdk间关联的新技术领域,借助知识图谱对存在关联的应用程序与sdk间关联关系的整理、归纳能力,得以从更深层次找到两者之间更加全面的关联关系,进而得到更加准确的识别结果,以实现应用程序的安全风险管控。
47.在上述实施例的基础上,本技术还通过图3提供了另一种用于确定第三方sdk的方法的流程300,在上一实施例的基础上,不仅提供了一种具体的构建知识图谱的方案,还基于确定出的第三方sdk给出了一种判断其安全风险等级并如何进行后续处理的方案,包括如下步骤:
48.步骤301:从各已知应用程序信息库和已知sdk信息库中获取基础信息;
49.其中,基础信息包含且不限于:版本号、包名、应用名、类名列表、方法列表、证书签名、类签名、申请的权限列表、函数调用图、感api调用信息、ui布局信息、图标、资源文件、字
符串资源、访问的网址和ip地址、程序中内置的uri、个人信息保护政策(隐私政策)等。上述基础信息除可以通过直接通过信息库中获取到现成的之外,也可以自行对已知app和已知sdk进行动态和静态提取得到,以便用于补足和通过比对提升准确性。
50.步骤302:从预设的公开渠道获取各已知应用程序和已知sdk的其它信息;
51.其中,其它信息指从各种权威的公开渠道获取到的信息,例如app和sdk的官方网站、各大app市场、开源技术网站、移动开发者平台、财经网站、国家工商管理局网站等。具体的其它信息包括且不限于:各种格式的app和sdk文件(例如apk、ipa、jar、aar、zip等)、包名、应用名、官方网址、官方服务器地址、历史版本、发行渠道、用户分布、开发者(厂商)的全名、别名、简称、公司性质、国别、公司注册名、联系方式、负责人、经营范围、成立时间、股权关系、子公司信息、母公司信息、关联公司信息等。
52.步骤303:根据基础信息和其它信息,整理得到每个应用程序分别与其第一方sdk和第三方sdk之间的关联信息;
53.本步骤旨在由上述执行主体根据步骤301和步骤302获取到的基础信息和其它信息,整理得到每个应用程序分别与其第一方sdk(也称自有sdk)和第三方sdk之间的关联信息。
54.步骤304:根据关联信息按照知识图谱的特性构建得到知识图谱;
55.在步骤303的基础上,本步骤旨在根据关联信息按照知识图谱的特性构建得到知识图谱。为更加直观的了解知识图谱的构建构成,本技术还提供了与步骤301至步骤304方案对应的一种示意图,请参见图4。
56.同时,基于知识图谱使用节点和节点间关系进行表示的特性,此处还对知识图谱中的主要实体(节点)、重要属性和关系举例:
57.(1)实体:
58.app:又名移动应用,在android系统下是apk格式文件,ios系统下是ipa格式文件;
59.sdk:是一种软件开发工具包,为app提供某些功能,如:谷歌的gson库为app提供json解析功能,某某移动统计sdk为app提供免费的移动应用分析统计。sdk一般可以分为第一方sdk和第三方sdk,例如对某某app来说,通常被命名为某某移动统计sdk就是该app的第一方sdk,gson库即为第三方库(或称第三方sdk)。
60.(2)重要属性:
61.个人信息保护政策:又名隐私政策,个人信息保护政策负责说明app如何收集和保护个人信息,也应当说明app中包含的主要第三方sdk;
62.app名称:一般包含在app文件内部,如“某某地图”、“某某旅行”等;
63.app包名:app的唯一标识,一般包含在app文件内部形如com.baidu.xxx.yyy;
64.权限列表:访问移动设备和信息通常需要操作系统权限,常见的敏感系统权限如:访问相机权限、访问身体传感器权限、存储权限、短信读写权限、获取地理位置权限等
65.app和sdk的类别:按照功能划分的类别,常见的分类如:地图导航、网络约车、即时通讯、网络支付、新闻资讯、网上购物等
66.签名证书:app证书一般包括秘钥、有效年份,发布人员的姓名,单位,所在城市,省份,国家等信息;
67.类名:app和程序库中的类名列表;
68.方法名:app和程序库中的函数名列表;
69.网址:app和程序库可能会包含大量网址(或uri,uniform resource identifier,统一资源标识符),用于实现各种功能,向服务器上传数据等;
70.官方网站:app和程序库一般有官方网站可以提供开发包或者app文件下载,为开发者和用户提供技术支持等;
71.公司名:app和程序库的作者一般是各公司(也有个人或者机构开发者),为方便起见,统称公司名。公司名分为全名和简称,全名一般是公司注册的名称,公司可能有多个简称,如“某某在线网络技术(北京)有线公司”可以简称“某某公司”;
72.(3)重要关系:
73.app和程序库之间可以分为第一方和第三方的关系,例如:对某某app来说,某某移动统计sdk是第一方程序库,gson库就是第三方库;
74.公司关联关系:例如a公司是b公司的子公司,所以a公司发布的地图sdk是b公司发布的某个app的第一方库;
75.名称对等关系:全名=简称=别名,如“某某在线网络技术(北京)有限公司”和“某某公司”可以认为是同一个公司的不同名称。又如:某某移动统计sdk,可以有多种别名(某某统计、某某统计sdk、xxxx_static等)。
76.一种基于上述举例内容构建得到的网状知识图谱示意图可参见图5。
77.步骤305:获取待测应用程序中包含的各实际sdk;
78.步骤306:利用知识图谱确定各实际sdk中的第三方sdk;
79.以上步骤305-306与如图2所示的步骤201-202一致,相同部分内容请参见上一实施例的相应部分,此处不再进行赘述。
80.步骤307:确定第三方sdk的实际隐私风险等级;
81.本步骤旨在由上述执行主体确定步骤306确定出的第三方sdk的实际隐私风险等级,即主要针对该第三方sdk对用户个人隐私数据的威胁来评估其实际隐私风险等级,可预先设置好评估规则或评估标准,此处不做具体限定,可结合实际情况灵活制定。
82.步骤308:判断第三方sdk的实际隐私风险等级是否小于预设等级,若是,执行步骤309,否则执行步骤310;
83.在步骤307的基础上,本步骤旨在判断第三方sdk的实际隐私风险等级是否小于预设等级,该预设等级作为评判第三方sdk是否符合安全隐私要求的分界线存在,包含于预先设置好的评估规则和评估标准中,实际参数可基于国家标准或行业标准计算得到。
84.步骤309:返回待测应用程序符合安全隐私要求的通知;
85.本步骤建立在步骤308的判断结果为第三方sdk的实际隐私风险等级小于该预设等级的基础上,在该待测app仅包含该第三方sdk的情况下,该第三方sdk的实际隐私风险等级小于该预设等级,可以判定待测app符合安全隐私要求,因此将向发起检测请求(例如发来待测app的终端设备)的一端返回待测app符合安全隐私要求的通知。当然,若待测app中包含有多个第三方sdk,往往还需要在所有第三方sdk的实际隐私风险等级均小于预设等级的情况下,才能够判定待测app符合安全隐私要求。
86.步骤310:返回待测应用程序不符合安全隐私要求的通知。
87.本步骤建立在步骤308的判断结果为第三方sdk的实际隐私风险等级不小于该预
设等级的基础上,在该待测app仅包含该第三方sdk的情况下,该第三方sdk的实际隐私风险等级不小于该预设等级,将判定待测app不符合安全隐私要求,因此将向发起检测请求(例如发来待测app的终端设备)的一端返回待测app不符合安全隐私要求的通知。当然,若待测app中包含有多个第三方sdk,任意第三方sdk的实际隐私风险等级不小于预设等级,都可以被判定待测app不符合安全隐私要求。
88.进一步的,为了方便整改,还可以同时返回是哪些第三方sdk因为哪些原因导致判定其实际隐私风险等级不小于预设等级的信息。同时,为了便于识别和后续统一处理,还可以为实际隐私风险等级不小于预设等级的待测应用程序附加不合格标签,并记录所有附加有不合格标签的应用程序的其它安全检测信息,以便通过其它安全检测信息来从其它角度发现是否还存在其它问题。
89.在包含上一实施例全部有益效果的基础上,本实施例给出了一种更加具体、便于实行的知识图谱构建方案,同时也通过对第三方sdk的后续处理,完成了对待测app是否符合安全隐私要求的判断,使得应用本技术所提供的方案将能够直接得到待测app是否满足app隐私审核、合规领域的结果。
90.进一步的,考虑到从多种渠道收集来的信息不免可能会存在重叠和不一致的问题,可以通过对信息进行深加工处理的方式来尽可能的解决,一种包括但不限于的处理方式可以为:
91.通过自然语言理解技术将基础信息和其它信息中的各种名称、缩略词、不规范语句进行标准化处理,得到第一标准化信息;
92.将基础信息和其它信息中的各种描述信息、隐私政策、文件特征等进行知识提取,并对经知识提取后得到的信息进行标准化处理,得到第二标准化信息;
93.根据第一标准化信息和第二标准化信息,整理得到每个应用程序分别与其第一方sdk和第三方sdk之间的关联信息。
94.通过对不同类型的信息进行不同的标准化处理,辅以知识提取技术,可以尽可能的消除不同渠道信息内容不一致或冲突的问题。
95.为加深理解,本技术还结合一个具体应用场景,给出了一种具体的实现方案:
96.1)app发布者x将待发布app发送至安全隐私审核服务器进行发布审核;
97.2)安全隐私审核服务器通过包名、流量特征、代码特征等确定出待发布app共包含4个sdk,分别用编号01、02、03、04来指代;
98.3)安全隐私审核服务器依次将每个编号的sdk的信息输入预先构建好的知识图谱;
99.4)安全隐私审核服务器根据知识图谱输出的判断结果发现:
100.编号01的sdk与待发布app具有相同的开发者签名,因此判定编号01的sdk属于待发布app的自有sdk(第一方sdk);
101.编号02的sdk与待发布app在官方网址、公司简称上不同,且包名相似度上均存在明显差异,因此判定编号02的sdk属于待发布app的第三方sdk;
102.编号03的sdk的独有包名多次出现在待发布app的开发者的官方网址的产品列表,因此判定编号03的sdk属于待发布app的自有sdk(第一方sdk);
103.经测试,待发布app拥有编号04的sdk的全部解析权限,因此判定编号04的sdk属于
待发布app的自有sdk(第一方sdk)。
104.5)安全隐私审核服务器按照预设的测试用例对编码02的第三方sdk进行安全隐私风险测试,并发现其会在待发布app运行10分钟后被私自调用,并将获取到的用户个人账号密码外发至指定邮箱后停止,因此判定编号为02的第三方sdk违反了相关安全隐私规定;
105.6)安全隐私审核服务器将包含编号02的第三方sdk违反了相关安全隐私规定的审核未通过通知返回至app开发者x。
106.进一步参考图6,作为对上述各图所示方法的实现,本技术提供了一种用于确定第三方sdk的装置的一个实施例,该装置实施例与图2所示的方法实施例相对应,该装置具体可以应用于各种电子设备中。
107.如图6所示,本实施例的用于确定第三方sdk的装置600可以包括:实际sdk确定单元601、第三方sdk确定单元602。其中,实际sdk确定单元601,被配置成获取待测应用程序中包含的各实际sdk;第三方sdk确定单元602,被配置成利用预先构建好的知识图谱确定各实际sdk中的第三方sdk;其中,知识图谱中记录有每种应用程序与其第三方sdk之间的关联关系。
108.在本实施例中,用于确定第三方sdk的装置600中:实际sdk确定单元601、第三方sdk确定单元602的具体处理及其所带来的技术效果可分别参考图2对应实施例中的步骤201-202的相关说明,在此不再赘述。
109.在本实施例的一些可选的实现方式中,用于确定第三方sdk的装置600还可以包括:基础信息获取单元,被配置成从各已知应用程序信息库和已知sdk信息库中获取基础信息;其它信息获取单元,被配置成从预设的公开渠道获取各已知应用程序和已知sdk的其它信息;关联信息整理单元,被配置成根据基础信息和其它信息,整理得到每个应用程序分别与其第一方sdk和第三方sdk之间的关联信息;知识图谱构建单元,被配置成根据关联信息按照知识图谱的特性构建得到知识图谱。
110.在本实施例的一些可选的实现方式中,关联信息整理单元可以进一步被配置成:通过自然语言理解技术将基础信息和其它信息中的各种名称、缩略词、不规范语句进行标准化处理,得到第一标准化信息;将基础信息和其它信息中的各种描述信息、隐私政策、文件特征等进行知识提取,并对经知识提取后得到的信息进行标准化处理,得到第二标准化信息;根据第一标准化信息和第二标准化信息,整理得到每个应用程序分别与其第一方sdk和第三方sdk之间的关联信息。
111.在本实施例的一些可选的实现方式中,用于确定第三方sdk的装置600还可以包括:实际隐私风险等级确定单元,被配置成在确定第三方sdk之后,确定第三方sdk的实际隐私风险等级;符合安全隐私要求通知发出单元,被配置成当实际隐私风险等级小于预设等级时,返回待测应用程序符合安全隐私要求的通知;不符合安全隐私要求通知发出单元,被配置成当实际隐私风险等级不小于预设等级时,返回待测应用程序不符合安全隐私要求的通知。
112.在本实施例的一些可选的实现方式中,用于确定第三方sdk的装置600还可以包括:不合格标签附加单元,被配置成为实际隐私风险等级不小于预设等级的待测应用程序附加不合格标签;其它安全检测信息记录单元,被配置成记录所有附加有不合格标签的应用程序的其它安全检测信息。
113.在本实施例的一些可选的实现方式中,用于确定第三方sdk的装置600还可以包括:增量更新和调整单元,被配置成按预设周期对知识图谱中的关联信息进行增量更新和调整。
114.本实施例作为对应于上述方法实施例的装置实施例存在,本实施例提供的用于确定第三方sdk的装置通过上述技术方案将本应用于其它领域的知识图谱技术引入了识别应用程序与sdk间关联的新技术领域,借助知识图谱对存在关联的应用程序与sdk间关联关系的整理、归纳能力,得以从更深层次找到两者之间更加全面的关联关系,进而得到准确的识别结果,以实现应用程序的安全风险管控。
115.根据本技术的实施例,本技术还提供了一种电子设备和一种计算机可读存储介质。
116.图7示出了一种适于用来实现本技术实施例的用于确定第三方sdk的方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机,诸如,膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置,诸如,个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例,并且不意在限制本文中描述的和/或者要求的本技术的实现。
117.如图7所示,该电子设备包括:一个或多个处理器701、存储器702,以及用于连接各部件的接口,包括高速接口和低速接口。各个部件利用不同的总线互相连接,并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理,包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如,耦合至接口的显示设备)上显示gui的图形信息的指令。在其它实施方式中,若需要,可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样,可以连接多个电子设备,各个设备提供部分必要的操作(例如,作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图7中以一个处理器701为例。
118.存储器702即为本技术所提供的非瞬时计算机可读存储介质。其中,存储器存储有可由至少一个处理器执行的指令,以使至少一个处理器执行本技术所提供的用于确定第三方sdk的方法。本技术的非瞬时计算机可读存储介质存储计算机指令,该计算机指令用于使计算机执行本技术所提供的用于确定第三方sdk的方法。
119.存储器702作为一种非瞬时计算机可读存储介质,可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块,如本技术实施例中的用于确定第三方sdk的方法对应的程序指令/模块(例如,附图6所示的实际sdk确定单元601、第三方sdk确定单元602)。处理器701通过运行存储在存储器702中的非瞬时软件程序、指令以及模块,从而执行服务器的各种功能应用以及数据处理,即实现上述方法实施例中的用于确定第三方sdk的方法。
120.存储器702可以包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需要的应用程序;存储数据区可存储该电子设备在执行用于确定第三方sdk的方法所创建的各类数据等。此外,存储器702可以包括高速随机存取存储器,还可以包括非瞬时存储器,例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中,存储器702可选包括相对于处理器701远程设置的存储器,这些远程存储器可以通过网络连接至适用于执行用于确定第三方sdk的方法的电子设备。上述网络的实
例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
121.适用于执行用于确定第三方sdk的方法的电子设备还可以包括:输入装置703和输出装置704。处理器701、存储器702、输入装置703和输出装置704可以通过总线或者其他方式连接,图7中以通过总线连接为例。
122.输入装置703可接收输入的数字或字符信息,以及产生适用于执行用于确定第三方sdk的方法的电子设备的用户设置以及功能控制有关的键信号输入,例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置704可以包括显示设备、辅助照明装置(例如,led)和触觉反馈装置(例如,振动电机)等。该显示设备可以包括但不限于,液晶显示器(lcd)、发光二极管(led)显示器和等离子体显示器。在一些实施方式中,显示设备可以是触摸屏。
123.此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用asic(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括:实施在一个或者多个计算机程序中,该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释,该可编程处理器可以是专用或者通用可编程处理器,可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令,并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
124.这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令,并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的,术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如,磁盘、光盘、存储器、可编程逻辑装置(pld)),包括,接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。
125.为了提供与用户的交互,可以在计算机上实施此处描述的系统和技术,该计算机具有:用于向用户显示信息的显示装置(例如,crt(阴极射线管)或者lcd(液晶显示器)监视器);以及键盘和指向装置(例如,鼠标或者轨迹球),用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互;例如,提供给用户的反馈可以是任何形式的传感反馈(例如,视觉反馈、听觉反馈、或者触觉反馈);并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
126.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如,作为数据服务器)、或者包括中间件部件的计算系统(例如,应用服务器)、或者包括前端部件的计算系统(例如,具有图形用户界面或者网络浏览器的用户计算机,用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如,通信网络)来将系统的部件相互连接。通信网络的示例包括:局域网(lan)、广域网(wan)和互联网。
127.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计
算机程序来产生客户端和服务器的关系。
128.根据本技术实施例提供的上述技术方案,将本应用于其它领域的知识图谱技术引入了识别应用程序与sdk间关联的新技术领域,借助知识图谱对存在关联的应用程序与sdk间关联关系的整理、归纳能力,得以从更深层次找到两者之间更加全面的关联关系,进而得到准确的识别结果,以实现应用程序的安全风险管控。
129.应该理解,可以使用上面所示的各种形式的流程,重新排序、增加或删除步骤。例如,本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行,只要能够实现本技术公开的技术方案所期望的结果,本文在此不进行限制。
130.上述具体实施方式,并不构成对本技术保护范围的限制。本领域技术人员应该明白的是,根据设计要求和其他因素,可以进行各种修改、组合、子组合和替代。任何在本技术的精神和原则之内所作的修改、等同替换和改进等,均应包含在本技术保护范围之内。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献