CN118013528A - 安全策略生成方法、装置及系统 - Google Patents

Abstract

本申请提供一种安全策略生成方法、装置及系统，涉及计算机技术领域，能减少安全策略生成过程导致的运行环境中资源紧张的问题。上述方法可以应用于部署运行环境的第一平台，第一平台针对第一平台上的进程调用的第一接口，利用第一接口对应的用例，确定第一接口对应的第一安全策略，这样，在运行环境中使用一部分用例(即第一接口对应的用例)就可以获取到安全策略，用例较少，占用的运行环境的资源也减少，从而减轻安全策略生成的过程对于运行环境资源的消耗，也降低该过程中投入的时间成本。

Description

安全策略生成方法、装置及系统

技术领域

本申请涉及计算机技术领域，尤其涉及一种安全策略生成方法、装置及系统。

背景技术

Linux系统中的访问控制模型可以采用强制访问控制(mandatory accesscontrol，MAC)模型。该模型要求进程对资源的所有操作都基于预置的安全策略进行决策，MAC模型根据安全策略确认是否将进程的资源访问行为放行。安全增强型Linux(security-enhanced linux，SELinux)模型是MAC模型的一种实现方式，SELinux通过预置的SELinux安全策略来控制特定进程对系统中指定资源的访问。例如，主体(如进程)发起对客体(如系统资源)访问请求后，SELinux基于安全策略对访问请求进行判断，只有主体的上下文与客体的上下文匹配时，才能允许主体访问客体。

目前，生成上述SELinux安全策略的方式多为人工配置原始版本策略的方式与自动化配置遗漏策略的方式相结合。其中，在自动化配置遗漏策略的过程中，需要在运行环境中部署人工配置的原始版本策略，并开启SELinux调测模式，基于原始版本策略进行完整的功能覆盖操作，即在运行环境中运行功能覆盖用例。在运行用例的过程中，运行环境中可能会产生审计日志告警信息。之后，可以通过进一步分析审计日志告警，来自动化完成遗漏策略的配置。

然而，上述方法过于依赖运行环境，例如，必须基于运行环境中产生的审计日志告警信息才能完成遗漏策略的配置，而由于需要使用的用例是海量的，在运行用例产生审计日志告警信息的过程中，海量的用例会过度地占用运行环境中的资源，导致运行环境中的资源紧张，影响运行环境中其他功能的正常运行。

发明内容

本申请提供一种安全策略生成方法、装置及系统，可以减少安全策略生成过程中导致的运行环境中资源紧张的问题。

为达到上述目的，本申请采用如下技术方案：

第一方面，提供一种安全策略生成方法，该方法应用于部署运行环境的第一平台。第一平台获取第一平台上的进程对应的第一接口信息，并获取第一接口信息中的第一接口对应的用例，以及基于用例，确定第一接口对应的第一安全策略。

上述第一接口信息包括进程、进程与调用的第一接口的对应关系。其中，第一接口访问的资源是变化的。

上述方法，可以在运行环境中，利用第一接口对应的用例，生成第一接口对应的安全策略。并且，由于第一接口是由第一平台上的进程调用的，所以第一接口对应的安全策略也可以看作是第一平台上进程的安全策略。这样一来，无需在运行环境中基于全量的功能覆盖用例，来确定进程的安全策略，从而减少运行环境中的资源被用例大量占用的情况，减轻安全策略生成过程中对于运行环境资源的消耗，缓解运行环境资源紧张的问题。

其次，在运行环境中减少用例的使用，也能减少运行环境中安全策略生成的时间，提高安全策略生成的效率。

再有，在运行环境中，因为只需要运行第一接口对应的用例即可，所以，无需要求用例的覆盖率较高，也可以降低由此而产生的人工成本和代价。

另外，一旦进程对应的应用程序(或者软件)等发生更新迭代、需求变更等情况，针对发生变化的功能对应接口，重新确定新的用例并再次基于新的用例确定新的安全策略即可，这样，也无需运行全量的功能覆盖用例，从而减少时间成本。

在第一方面的一种可实现方式中，第一接口包括动态系统调用接口和/或动态对外接口，动态系统调用接口用于通过发生变化的参数访问资源，动态对外接口不存在于预设接口清单中，发生变化的参数包括外部输入的参数、配置信息、环境变量中的一项或多项，预设接口清单包括第一平台的对外接口。

例如，预设接口清单可以是第一平台对应的产品说明书、对外接口清单、对外接口文档等，以及，预设接口清单中的对外接口可以是至少一个。

在第一方面的一种可实现方式中，第一平台确定第一接口对应的功能，以及根据第一接口对应的功能，获取第一接口对应的一个或多个用例。

这种实现方式中，进程调用的接口都有其对应的功能，不同的接口对应的功能可能相同，也可能不同。第一平台上的用例是针对进程对应的不同功能而配置的，也就是说，用例也可以对应于接口的功能。因此，在确定第一安全策略的过程中，第一平台可以根据第一接口对应的功能，确定出第一接口对应的一个或多个用例。从而实现有针对性地使用用例，而不是运行全量的功能覆盖用例。

在第一方面的一种可实现方式中，第一平台运行用例，并获取第一平台生成的第一告警信息，之后，根据第一告警信息，确定第一接口对应的第一安全策略。

其中，第一告警信息可以是第一平台上产生的审计日期告警信息，从而第一平台可基于审计日期告警信息，自动生成第一安全策略。

这种实现方式中，第一平台上运行动态接口对应的用例即可，从而减少第一平台的资源被用例大量占用的情况，也无需要求用例的覆盖率较高，不仅可以缓解第一平台资源紧张的问题，还可以降低由此而产生的人工成本和代价。

以及，在第一平台减少用例的使用，也能减少第一平台安全策略生成的时间，提高安全策略生成的效率。一旦进程对应的应用程序发生更新迭代、需求变更等情况，针对发生变化的功能对应接口，重新确定新的用例并再次基于新的用例确定新的安全策略即可，这样，也无需运行全量的功能覆盖用例，从而减少时间成本。

在第一方面的一种可实现方式中，第一平台还获取进程的第二安全策略，其中，第一平台从部署开发环境的第二平台获取第二安全策略，或，根据第二接口信息生成第二安全策略。

这种实现方式中，可以无第二平台参与，即，第一平台自行获取第一接口信息和第二接口信息后，自行生成第一接口对应的第一安全策略，和第二接口对应的第二安全策略。或者，也可以有第二平台参与，即，由第二平台获取到第一接口信息和第二接口信息后，向第一平台发送第一接口信息，并自行生成第二接口对应的第二安全策略。

无论哪种方式，都能实现分别针对不同类型的接口，分别确定安全策略的目的，以及，生成第二安全策略时，可以根据第二接口信息直接生成，而获取第一安全策略时，则利用第一接口对应的用例来获取。这样，可以减少第一平台上运行的用例的数量，减轻安全策略生成过程中对于运行环境资源的消耗、提高安全策略生成的效率、降低由此而产生的人工成本和代价、减少时间成本。

在第一方面的一种可实现方式中，在确定第一接口对应的第一安全策略之后，第一平台基于第一安全策略和进程的第二安全策略，再次运行用例，并获取第一平台生成的第二告警信息。之后，第一平台根据第二告警信息，对第一安全策略进行第一操作，获得进程的第三安全策略。

其中，第一操作包括对第一安全策略修改和/或补充。

这种实现方式中，上述对于安全策略修改和/或补充的操作，其实是一个循环执行的过程，直至第一平台上无告警信息产生，则可以结束该过程。此时，也就是完成了所有安全策略在第一平台上的整体适配。

在第一方面的一种可实现方式中，第一平台从部署开发环境的第二平台获取第一接口信息。或者，在另一种可实现方式中，第一平台可以自行获取进程对应的第一接口信息。

上述实现方式中，可以无第二平台参与，即，第一平台可以自行获取第一接口信息，以及第一平台自行确定第一接口对应的第一安全策略。或者，也可以有第二平台参与，即，由第二平台获取到第一接口信息后，向第一平台发送。无论哪种方式，都能实现针对性地获取到第一接口对应的一个或者多个用例并运行，从而减少第一平台上运行的用例的数量，减轻安全策略生成过程中对于运行环境资源的消耗、提高安全策略生成的效率、降低由此而产生的人工成本和代价、减少时间成本。

另外，在一种可实现方式中，无论是第一平台还是第二平台，在获取第一接口信息之前，都需要在线获取进程的打包信息，以便后续根据打包信息获取接口信息，其中，在线获取的打包信息可以包括从远程的代码仓获取的代码，或者是在线的文档等。

在第一方面的一种可实现方式中，第一平台获取进程对应的第一接口信息过程中，先获取第一平台上进程对应的打包信息，以及解析打包信息，获得二进制文件和/或配置文件在第一平台上部署的实际路径信息。之后，第一平台根据实际路径信息，确定进程对应的主体安全上下文信息和客体安全上下文信息，并基于主体安全上下文信息和客体安全上下文信息，扫描进程对应的接口，确定第一接口信息和进程对应的第二接口信息。

上述打包信息包括进程对应的二进制文件和/或配置文件对应的打包文件的信息。

在另一种可实现方式中，若是由第二平台获取第一接口信息，那么第二平台也可以参照上述方式扫描进程对应的接口，从而确定第一接口信息和第二接口信息。

无论哪种实现方式，都是针对进程进行接口扫描，从而确定出接口的类型，如第一接口、第二接口，再分别获取第一接口信息和第二接口信息。这样能更为准确地将接口分类，在后续过程中才能分别针对不同的接口准确地确定出接口信息。在第一方面的一种可实现方式中，上述第二接口信息包括进程、进程与调用的第二接口的对应关系，其中，第二接口访问的资源是固定的。

在另一种可实现方式中，上述第二接口包括静态系统调用接口和/或静态对外接口，静态系统调用接口用于通过不发生变化的参数访问资源，静态对外接口存在于上述预设接口清单中。

第二方面，提供一种安全策略生成装置，该装置部署有运行环境，该装置包括：

获取模块，用于获取装置上的进程对应的第一接口信息；第一接口信息包括进程、所述进程与调用的第一接口的对应关系；所述第一接口访问的资源是变化的；

第一策略生成模块，用于获取所述第一接口信息中的所述第一接口对应的用例，并基于所述用例，确定所述第一接口对应的第一安全策略。

在第二方面的一种可实现方式中，第一策略生成模块，还用于：确定第一接口对应的功能；根据第一接口对应的功能，获取第一接口对应的一个或多个用例。

在第二方面的一种可实现方式中，第一策略生成模块，还用于：运行用例，并获取装置生成的第一告警信息；根据第一告警信息，确定第一接口对应的第一安全策略。

在第二方面的一种可实现方式中，第一策略生成模块，还用于：基于第一安全策略和进程的第二安全策略，再次运行用例，并获取装置生成的第二告警信息；根据第二告警信息，对第一安全策略进行第一操作，获得进程的第三安全策略；第一操作包括对第一安全策略修改和/或补充。

在第二方面的一种可实现方式中，获取模块，还用于：从部署开发环境的第二平台获取第一接口信息。

在第二方面的一种可实现方式中，获取模块，还用于：获取装置上进程对应的打包信息，打包信息包括进程对应的二进制文件和/或配置文件对应的打包文件的信息；解析打包信息，获得二进制文件和/或配置文件在装置上部署的实际路径信息；根据实际路径信息，确定进程对应的主体安全上下文信息和客体安全上下文信息；基于主体安全上下文信息和客体安全上下文信息，扫描进程对应的接口，确定第一接口信息和进程对应的第二接口信息。

在第二方面的一种可实现方式中，获取模块，还用于：从部署开发环境的第二平台获取该进程的第二安全策略；或，根据第二接口信息生成该进程的第二安全策略。

第三方面，提供一种安全策略生成系统，包括第一平台和第二平台，第一平台部署运行环境，第二平台部署开发环境。

第二平台，用于获取第一平台上的进程对应的第一接口信息和第二接口信息；第一接口信息包括进程、进程与调用的第一接口的对应关系，第二接口信息包括进程、进程与调用的第二接口的对应关系，第一接口访问的资源是变化的，第二接口访问的资源是固定的；

第二平台，还用于根据第二接口信息，获取进程的第二安全策略，并向第一平台发送第一接口信息；

第一平台，用于获取第一接口信息中的第一接口对应的用例，并基于用例，确定第一接口对应的第一安全策略。

进一步地，第二平台还用于向第一平台发送该第二安全策略。第一平台用于根据第一安全策略和该第二安全策略，获得该进程的第三安全策略。

第四方面，提供一种计算机可读存储介质，包括计算机指令，当所述计算机指令在第一平台上运行时，使得所述第一平台执行如第一方面及其任一种实现方式中的安全策略生成方法。

第五方面，提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得计算机执行如第一方面及其任一种实现方式中的安全策略生成方法。

上述第二方面提供的安全策略生成装置、第三方面提供的安全策略生成系统、第四方面提供的计算机存储介质和第五方面提供的计算机程序产品，所能达到的有益效果可参考第一方面及其任一种实现方式所能实现的有益效果，此处不再赘述。

附图说明

图1为本申请实施例示出的SELinux控制进程访问资源的示意图；

图2为本申请实施例示出的SELinux安全策略的生成方式的示意图一；

图3为本申请实施例示出的SELinux安全策略的生成方式的示意图二；

图4为本申请实施例示出的安全策略生成系统的示意图；

图5为本申请实施例示出的安全策略生成方法的示意图一；

图6为本申请实施例示出的第二平台的结构示意图；

图7为本申请实施例示出的开发场景的示意图；

图8为本申请实施例示出的安全策略生成方法的示意图二；

图9为本申请实施例示出的安全策略生成方法的示意图三；

图10为本申请实施例示出的安全策略生成方法的示意图四；

图11为本申请实施例示出的第一平台的示意图；

图12为本申请实施例示出的安全策略生成装置的示意图一；

图13为本申请实施例示出的安全策略生成装置的示意图二；

图14为本申请实施例示出的电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请的描述中，除非另有说明，“/”表示前后关联的对象是一种“或”的关系，例如，A/B可以表示A或B；本申请中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，其中A,B可以是单数或者复数。并且，在本申请的描述中，除非另有说明，“多个”是指两个或多于两个。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。同时，在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念，便于理解。

此外，本申请实施例描述的业务场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

Linux系统默认的访问控制模型为自主访问控制(discretionary accesscontrol，DAC)模型。DAC模型依据进程的身份和该身份对文件及目录的读、写、执行等权限来判断进程是否可以进行资源访问操作。

但是，DAC模型存在显著缺点，即，权限控制分散、安全性较低、容易发生安全漏洞、无法满足高安全系统实现对进程的细粒度访问控制要求等。

为了弥补DAC模型的缺点，诞生了强制访问控制(mandatory access control，MAC)模型。该模型要求进程对资源的所有操作都基于预置的授权安全策略进行决策。该模型要求进程对资源的所有操作都基于预置的安全策略进行决策，MAC模型根据安全策略确认是否将进程的资源访问行为放行。MAC模型作为DAC模型的补充，支持对进程进行细粒度的访问控制，通过将各个进程的资源访问行为隔离以及权限范围限制到最小，以减小或清除单个应用程序在失效或者出错的情况下对整个系统造成危害。

SELinux模型是上述MAC模型的一种实现方式，SELinux通过预置的SELinux安全策略来控制特定进程对系统中指定资源的访问。例如，参见图1所示，主体(subject)发起对客体(object)访问请求后，SELinux基于安全策略针对该访问请求从策略数据库中获取到对应安全策略，并基于安全策略进行安全上下文的判断，只有主体的上下文与客体的上下文匹配时，才能允许主体访问客体，否则，SELinux拒绝主体访问客体。

上述主体为试图访问系统资源的实体，例如用户、进程或服务等。客体为系统中需要保护的资源或者被访问的系统资源，例如文件、目录、数据库、网络服务等。策略(policy)或者安全策略为规定主、客体域之间权限访问约束的集合，以及，策略是一套指导SELinux进行安全决策的规则，它定义了客体的类型、进程的域、使用限制进入域的角色及访问许可的规则表达式等。安全上下文(security context)为主体或客体的身份标识，描述主体或客体的访问控制属性，每个主体或客体都有一个与之关联的安全上下文。

SELinux提供了3种工作模式，包括：关闭模式(disabled)、宽容模式(permissive)和强制模式(enforcing)。在disabled模式中，SELinux被关闭，默认的DAC模型工作；在permissive模式中，SELinux被启用，但不会对主体强制执行安全策略规则，当利用安全策略规则鉴权失败时，主体的访问仍然被允许，这种情况下会同步产生一条审计日志告警信息，其中，审计日志告警信息可以包括对应的主体、客体、资源类型、缺失权限等信息。在enforcing模式中，SELinux被启动，具有强制访问功能，可以强制执行所有的安全策略规则，以及当利用安全策略规则鉴权失败时，主体的访问不会被允许。

可见，在SELinux被启用后，SELinux安全策略影响着SELinux对发起访问的主体的正确决策，所以安全策略正确、全面地生成(或者配置)是至关重要的。

生成上述SELinux安全策略的方式多为人工配置原始版本策略的方式与自动化配置遗漏策略的方式相结合，例如图2所示。其中，在自动化配置遗漏策略的过程中，需要在运行环境中部署人工配置的原始版本策略，并开启SELinux调测模式，基于原始版本策略进行完整的功能覆盖操作，即在运行环境中运行功能覆盖用例。在运行用例的过程中，运行环境中可能会产生审计日志告警信息，之后，可以通过进一步分析审计日志告警信息，来自动化完成遗漏策略的配置。可以理解的是，所有安全策略以二进制形式保存。

示例性的，参见图3中的(a)所示，在生成SELinux安全策略时，上述人工配置原始版本策略的过程可以在开发环境中进行，例如确定进程的资源依赖信息，基于资源依赖信息配置进程的主客体安全上下文，以及，基于主客体安全上下文确定配置原始版本策略。之后，将原始版本策略打包发送至运行环境，在运行环境加载原始版本策略，基于原始版本策略运行全量的功能覆盖用例。之后，再将运行用例过程中产生的审计日志发送至开发环境，开发环境针对审计日志的信息进行预处理，例如，过滤不符合要求的数据，得到审计日志中的审计日志告警信息等。此后，开发环境中的安全策略生成模块可以基于审计日志告警信息在开发环境中实现遗漏策略的自动化配置。

再示例性的，参见图3中的(b)所示，在生成SELinux安全策略时，上述人工配置原始版本策略的过程可以在开发环境中进行。在运行环境加载原始版本策略，基于原始版本策略运行全量的功能覆盖用例。之后，继续在运行环境中利用获得的审计日志告警信息，自动化配置遗漏的安全策略。

上述方式能减少遗漏的SELinux安全策略，保证生成的SELinux安全策略较为全面。但是，也都或多或少地存在一些问题：

其一，必须基于运行环境中产生的审计日志告警信息才能完成遗漏策略的配置，这样的话，SELinux安全策略的生成过程过于依赖运行环境。由于在运行环境中需要使用的用例是海量的(如上万或者数10万条)，在运行用例产生审计日志告警信息的过程中，海量的用例会过度地占用运行环境中的资源，并且进行一轮功能覆盖也需要较长的时间，这样会导致运行环境中的资源紧张，影响运行环境中其他功能的正常运行。

其二，在使用全量的功能覆盖用例自动化配置遗漏策略的过程中，对用例的覆盖率要求较高，通常要求用例的代码覆盖率达到100％，其中，有一些高安全且复杂的系统功能覆盖用例甚至可能多达上万或者数10万条。这样一来，为了保证用例的覆盖率，而投入的人工成本和代价也会比较高。

其三，目前的应用程序(或者软件)等更新迭代、需求变更也比较快，一旦发生迭代或者变更，都需要针对应用程序(或者软件)的进程配置新的SELinux安全策略，这个过程中，需要重新在运行环境中运行全量的功能覆盖用例，由此付出的时间成本也比较高。

其四，在上述人工配置原始版本策略的过程中，也容易造成SELinux安全策略漏配或者多配的情况，如果SELinux安全策略漏配，可能会造成某些进程的功能异常，而如果SELinux安全策略多配，则可能会造成进程访问系统资源的权限被放大，从而产生系统漏洞，提高系统被攻击的风险。

基于上述内容，本申请实施例提供了一种安全策略生成方法，在该方法中，部署了运行环境的第一平台可以获取第一平台上的进程对应的第一接口信息，以及，获取第一接口信息中的第一接口对应的用例，并基于该用例，确定第一接口对应的第一安全策略。

其中，第一接口信息包括进程、进程与调用的第一接口的对应关系，以及，第一接口访问的资源是变化的。

上述安全策略生成方法可以在运行环境中，针对访问变化的资源的接口(即第一接口)，利用这类接口对应的用例，生成这类接口对应的安全策略。并且，由于这类接口是由第一平台上的进程调用的，所以这类接口对应的安全策略也可以看作是第一平台上进程的安全策略。这样一来，无需在运行环境中基于全量的功能覆盖用例，来确定进程的安全策略，从而减少运行环境中的资源被用例大量占用的情况，减轻安全策略生成过程中对于运行环境资源的消耗，缓解运行环境资源紧张的问题。

其次，在运行环境中减少用例的使用，也能减少运行环境中安全策略生成的时间，提高安全策略生成的效率。

再有，在运行环境中，因为只需要运行第一接口对应的用例即可，所以，无需要求用例的覆盖率较高，也可以降低由此而产生的人工成本和代价。

另外，一旦进程对应的应用程序(或者软件)等发生更新迭代、需求变更等情况，针对发生变化的功能对应接口，重新确定新的用例并再次基于新的用例确定新的安全策略即可，这样，也无需运行全量的功能覆盖用例，从而减少时间成本。

本申请实施例提供的上述安全策略生成方法，可以应用于安全策略生成系统。例如，参见图4所示，该安全策略生成系统可以包括部署运行环境的第一平台401和部署开发环境的第二平台402。

其中，第一平台401可以安装至少一个应用程序，作为应用程序的运行平台，为应用程序提供运行环境。第二平台402也可以安装第一平台401上的应用程序，作为应用程序的开发平台，为应用程序提供开发环境。

应用程序包括进程，进而第一平台401在安装应用程序的情况下，也包括进程。其中，进程运行时可以不访问第一平台的资源，或者，进程运行时可以调用对应的接口访问第一平台401的资源。其中，资源是指第一平台401的系统资源，系统资源可以包括配置文件、目录、数据库、网络服务等。

在针对进程配置对应的安全策略时，第二平台402需预先获取应用程序的配置信息，例如配置文件、二进制文件、编译文件等。之后，基于配置信息获取进程对应的第一接口信息和第二接口信息。其中，第一接口信息包括进程、进程与调用的第一接口的对应关系，第二接口信息包括进程、进程与调用的第二接口的对应关系。

上述第一接口是指动态接口，即第一接口访问的资源是变化的。例如，第一接口可以包括动态系统调用接口和/或动态对外接口，其中，动态系统调用接口用于通过发生变化的参数访问资源，动态对外接口不存在于预设接口清单中，以及，发生变化的参数包括外部输入的参数、配置信息、环境变量中的一项或多项。

上述预设接口清单包括第一平台401的对外接口，例如，预设接口清单可以是第一平台对应的产品说明书、对外接口清单、对外接口文档等，以及，预设接口清单中的对外接口可以是至少一个。

上述第二接口是指静态接口，即第二接口访问的资源是固定的。例如，第二接口可以包括静态系统调用接口和/或静态对外接口，其中，静态系统调用接口用于通过不发生变化的参数访问资源，静态对外接口存在于上述预设接口清单中。

第二平台402在获取到第一接口信息和第二接口信息后，可以根据第二接口信息，获取进程的第二安全策略，并向第一平台401发送第一接口信息。从而，第一平台401在接收到第一接口信息后，获取第一接口信息中的第一接口对应的用例，并基于用例，确定第一接口对应的第一安全策略，即，进程的第一安全策略。

可以理解的是，进程调用接口能实现相应的功能，进而进程调用的接口都有其对应的功能，不同的接口对应的功能可能相同，也可能不同。第一平台401上的用例是针对进程对应的不同功能而配置的，也就是说，用例也可以对应于接口的功能。因此，在确定第一安全策略的过程中，第一平台401可以根据第一接口对应的功能，确定出第一接口对应的一个或多个用例。之后，第一平台401运行用例，并获取生成的第一告警信息，以及根据第一告警信息，确定第一接口对应的第一安全策略。

其中，第一告警信息可以是第一平台401上产生的审计日志告警信息，从而第一平台401可基于审计日期告警信息，自动生成第一安全策略。

上述根据第一接口的功能确定出需运行的用例，从而实现有针对性地使用用例，而不是运行全量的功能覆盖用例。

上述的第二平台402可以针对进程的静态接口确定进程的第二安全策略，而第一平台401可以针对进程的动态接口确定进程的第一安全策略。这样在第一平台401上运行动态接口对应的用例即可，无需在第一平台401(或者运行环境中)基于全量的功能覆盖用例，来确定进程的安全策略，从而减少第一平台401的资源被用例大量占用的情况，也无需要求用例的覆盖率较高，不仅可以缓解第一平台401资源紧张的问题，还可以降低由此而产生的人工成本和代价。

以及，在第一平台401减少用例的使用，也能减少第一平台401安全策略生成的时间，提高安全策略生成的效率。一旦进程对应的应用程序发生更新迭代、需求变更等情况，针对发生变化的功能对应接口，重新确定新的用例并再次基于新的用例确定新的安全策略即可，这样，也无需运行全量的功能覆盖用例，从而减少时间成本。

上述静态接口访问的资源是固定的，也就是说，静态接口对应的功能、实现的目的等是固定的、不会发生变化的，因此，在第二平台402上可以采用固定的方式获取静态接口对应的安全策略，而无需利用接口对应的用例来确定对应的安全策略。例如，固定的方式可以包括，针对固定功能的接口或者静态接口等，预先配置策略生成模型或者代码，从而自动化地针对固定功能的接口或者静态接口等确定对应的安全策略。这种情况下，当第二平台402部署了策略生成模型或者代码时，第二平台402可以看作是一种自动化的开发平台。

可以理解的是，上述提供开发环境的第二平台402可以实现安全策略的自动生成，而无需人工进行配置，可以减少由于人工配置而导致的安全策略漏配或者多配的问题，从而改善进程功能异常的情况，以及，减少进程访问资源的权限被放大的情况，减少系统漏洞的产生，降低系统被攻击的风险。

第二平台402在获取第一接口信息和第二接口信息时，可以基于第二平台402上进程对应的打包信息进行操作。示例性的，参见图5所示的安全策略生成方法，第二平台402可以获取进程对应的打包信息，例如二进制文件、配置文件等。之后，第二平台402对打包信息进行解析，获取二进制文件、配置文件等在运行环境上部署的实际路径，并根据实际路径，生成主体安全上下文信息和客体安全上下文信息。第二平台402基于主体安全上下文信息和客体安全上下文信息对进程进行接口扫描，获取主体访问客体时调用的接口，例如系统调用接口、对外接口等。之后，第二平台402再针对系统调用接口和对外接口分别进行判断，其中，针对系统调用接口的判断可以包括，确定系统调用接口是否使用不发生变化的(或者静态的)参数对资源进行访问，若是，则确定该系统调用接口为静态系统调用接口，而若不是(或者使用发生变化的(或者动态的)参数对资源进行访问)则为动态系统调用接口。针对对外接口的判断可以包括，确定对外接口是否存在于预设接口清单中，若是，则为静态对外接口，若不是则为动态对外接口。

上述动态系统调用接口和动态对外接口可以作为第一接口，而静态系统调用接口和静态对外接口可以作为第二接口。

最后，第二平台402可以获取到第一接口对应的第一接口信息和第二接口对应的第二接口信息，并将第一接口信息发送至第一平台401。

本申请实施例中，上述第二平台402是应用程序的开发平台，例如，可以是Linux软件开发平台。在开发平台上，技术人员可以对应用程序进行开发，以及，开发平台上也可以部署安全策略，进而对开发平台上运行的进程进行安全检测或者限制。

示例性的，参见图6所示，第二平台402可以分为存储层、内核(kernel)层、平台服务层、应用层。

其中，存储层主要对第二平台402的资源(或者称为系统资源)进行管理。在第二平台402上，一切资源皆以文件的形式保存，例如保存在存储层的文件存储器(file storage)中。

Kernel层是内核第二平台402的核心，它负责管理平台上的进程、内存、设备驱动程序、文件和网络系统等。

以开发平台部署SELinux模块为例，SELinux模块可以部署在Kernel层中，并通过消息处理(hook)机制拦截上层(即平台服务层)的进程对存储层资源的调用。以及，SELinux模块基于预置的安全策略，决定是否允许上层进程对底层资源的访问。

平台服务层负责管理第二平台402的正常运行，平台服务层提供的关键服务包括：状态管理、资源管理、故障管理、网络管理等，同时也可以对外提供相关服务。

应用层可以包括应用程序或者功能平台等。以第二平台402针对于第三方(或者称为OEM/3rd)提供的应用程序或者功能平台进行二次开发为例，应用层包括的应用程序可以是第三方应用程序，如通讯软件、视频软件、音乐软件等，应用层包括的功能平台可以是第三方功能平台，如自动驾驶平台、大数据服务器等。其中，由于应用程序可以来自于手机等智能终端平台，因此，从另一个角度来看，软件开发工程师或者技术人员等可以基于上述第二平台402对自动驾驶、手机、大数据服务器等平台进行开发或者二次开发，例如图7所示。

另外，在Kernel层中还可以部署策略数据库，主要用于保存平台服务对应的安全策略和第三方应用程序或者第三方功能平台对应的安全策略。当第三方应用程序对应的进程发起资源访问请求时，SELinux模块可以从策略数据库中获取到对应的安全策略，并基于安全策略对该资源访问请求进行决策，判断是否可以对进程放行。当平台服务对应的进程发起资源访问请求时，SELinux模块也可以从策略数据库中获取到对应的安全策略，并基于安全策略对该资源访问请求进行决策，判断是否可以对进程放行。其中，策略数据库中的安全策略均以二进制文件(policy)的形式保存。

在一些可能的应用场景中，上述第一平台可以部署在电子设备上，从而使电子设备为应用程序提供运行环境；或者，第一平台也可以是电子设备，该电子设备部署有运行环境。其中，电子设备可以是例如安全策略生成装置、笔记本电脑、个人计算机等具有数据处理和计算功能的设备。

在另一些可能的应用场景中，上述第二平台也可以部署在电子设备上，从而使电子设备为应用程序提供开发环境；或者，第二平台也可以是电子设备，该电子设备部署有开发环境。其中，电子设备也可以是例如安全策略生成装置、笔记本电脑、个人计算机等具有数据处理和计算功能的设备。

可以理解的是，第一平台和第二平台可以分别部署在不同的电子设备上，或者，也可以部署在相同的电子设备上，本申请对此不做具体限制。

另外，本申请上述实施例中所述的第一接口信息也可以称为进程的动态资源依赖信息，第一接口也可以称为动态资源依赖或者动态接口。以及，上述实施例中所述的第二接口信息也可以称为进程的静态资源依赖信息，第二接口也可以称为静态资源依赖或者静态接口。

例如图8所示，第一平台和第二平台上可以分别设置有策略生成模块，从而两个平台分别通过策略生成模块根据不同接口信息生成不同的安全策略，例如第二平台上的策略生成模块针对静态资源依赖，对应生成安全策略1、安全策略2等，第一平台上的策略生成模块针对动态资源依赖，对应生成安全策略3、安全策略4等。

上述实施例中，是由第一平台401和第二平台402分别完成第一安全策略和第二安全策略的生成，之后，可以将两种安全策略整合在一起部署在第一平台401，在此过程中，第一平台401可以从第二平台402上获取到第二安全策略。

之后，第一平台401还可以基于第一安全策略和第二安全策略，再次运行上述用例。在此过程中，第一平台401上可能会产生另一告警信息(第二告警信息)，如新的审计日志告警信息等。这种情况下，参见图9所示，第一平台401可以继续基于该另一告警信息，对第一安全策略进行第一操作，例如修改和/或补充，从而获得第三安全策略(即更新后的第一安全策略)。其中，第三安全策略可以看作是对当第一安全策略完善后的策略。

经过上述过程后，可以再基于第三安全策略以及第二安全策略，再次运行上述用例，若又产生告警信息，则第一平台401可以再次重复上述的过程，对第三安全策略再次进行修改和/或补充。

上述对于安全策略修改和/或补充的操作，其实是一个循环执行的过程，直至第一平台401上无告警信息产生，则可以结束该过程。此时，也就是完成了所有安全策略在第一平台401上的整体适配。

在另一些实施例中，也可以由第一平台401完成第一安全策略和第二安全策略的生成，这样一来，无需第二平台402参与，可以节省信息或者策略发送所消耗的时间，加快安全策略的生成效率。可以理解的是，该实施例中，第一平台401生成第二安全策略的过程可以参考前述实施例中第二平台402生成第二安全策略的过程，此处不再赘述。

以上述安全策略生成方法应用于第一平台为例，参见图10所示，上述安全策略生成方法可以包括如下步骤S1001-S1002。

S1001、第一平台获取第一平台上的进程对应的第一接口信息。

其中，第一平台可以自行获取进程的第一接口信息。具体方式可以参考上述第二平台获取第一接口信息和第二接口信息的过程。

例如，第一平台可以先获取到进程对应的打包信息，并解析打包信息，获得二进制文件和/或配置文件在第一平台上部署的实际路径信息。之后，第一平台根据实际路径信息，确定进程对应的主体安全上下文信息和客体安全上下文信息，再基于主体安全上下文信息和客体安全上下文信息，扫描进程对应的接口，确定该进程对应的第一接口信息和第二接口信息。

或者，第一平台还可以从第二平台获取该第一接口信息。这种情况下，第二平台先确定第一接口信息和第二接口信息，再向第一平台发送第一接口信息。

无论是由第一平台确定第一接口信息，还是由第二平台确定第一接口信息，都是对进程进行接口扫描，从而确定出接口是第一接口还是第二接口，再分别获取第一接口信息和第二接口信息。这样能更为准确地将接口分类，在后续过程中才能分别针对不同的接口准确地确定出接口信息。

另外，在一些可能的应用场景中，无论是第一平台还是第二平台，在获取第一接口信息之前，都需要在线获取进程的打包信息，以便后续根据打包信息获取接口信息，其中，在线获取的打包信息可以包括从远程的代码仓获取的代码，或者是在线的文档等。

S1002、第一平台获取第一接口信息中的第一接口对应的用例，并基于用例，确定第一接口对应的第一安全策略。

示例性的，参见图11所示，第一平台确定第一接口对应的功能，并根据第一接口对应的功能，获取第一接口对应的一个或多个用例。之后，第一平台运行用例，并获取第一平台产生的告警信息(如第一告警信息)，再根据该告警信息，确定第一接口对应的第一安全策略。

这样，第一平台无需运行覆盖进程所有功能的全量的用例，运行第一接口对应的用例即可。第一接口对应的用例往往少于全量的用例，进而，第一接口对应的用例在第一平台上运行的耗时会减少，运行时所占用的第一平台的资源也会减少。

若是第一平台确定了上述第一接口信息和第二接口信息，那么第一平台除了可以确定上述第一安全策略，还可以生成第二安全策略，仍可以参见上述图11。以及，示例性的，第一平台还可以参考上述第二平台生成第二安全策略的内容，采用自动化的方式生成第二安全策略，从而减少由人工配置策略引起的一系列的问题。

在一些可能的应用场景中，第一平台在确定上述第一安全策略和第二安全策略之后，可以基于第一安全策略和第二安全策略，再次运行上述用例，并获取第一平台产生的新的告警信息(如第二告警信息)，以及，根据该告警信息，对第一安全策略进行第一操作，获得进程的新的第一安全策略(如第三安全策略)，该过程可以参考例如上述图9所示。

可以理解的是，本实施例中第一平台除了能自行获取第一接口信息和第二接口信息、生成第二安全策略以外，其他所能实现的功能，均可以参考前述实施例中第一平台的功能。

若是第二平台确定了上述第一接口信息和第二接口信息，那么第二平台可以先根据第二接口信息，获取到第二安全策略。而后，第一平台再从第二平台获取第二安全策略。

上述实施例中，若是由第一平台完成第一安全策略和第二安全策略的生成，同样也可以实现针对不同类型的接口确定不同的安全策略，并且在确定动态接口(即动态系统调用接口和动态对外接口)对应的安全策略的过程中，也无需使用全量的功能覆盖用例，从而减少第一平台的资源被用例大量占用的情况，缓解第一平台资源紧张的问题。并且，也无需要求第一平台上用例的覆盖率较高，从而降低由此而产生的人工成本和代价。以及，一旦进程对应的应用程序(或者软件)等发生更新迭代、需求变更等情况，针对发生变化的功能对应接口，重新确定新的用例并再次基于新的用例确定新的安全策略即可，这样，也无需运行全量的功能覆盖用例，从而减少时间成本。

可以理解的是，本申请实施例提供的上述安全策略生成方法可以适用于SELinux模型，也可以使用其他具有类似于强制访问功能的模型或者系统，本申请实施例中对此不做具体限制。

当适用于SElinux模型时，上述第一平台上可以配置有SElinux模型，并且在第一平台开始工作时，应首先开启SElinux模型的调测模式。

在一些方案中，可以对本申请的多个实施例进行组合，并实施组合后的方案。可选的，各方法实施例的流程中的一些操作任选地被组合，并且/或者一些操作的顺序任选地被改变。并且，各流程的步骤之间的执行顺序仅是示例性的，并不构成对步骤之间执行顺序的限制，各步骤之间还可以是其他执行顺序。并非旨在表明所述执行次序是可以执行这些操作的唯一次序。本领域的普通技术人员会想到多种方式来对本申请实施例所描述的操作进行重新排序。另外，应当指出的是，本申请某个实施例涉及的过程细节同样以类似的方式适用于其他实施例，或者，不同实施例之间可以组合使用。

此外，方法实施例中的某些步骤可等效替换成其他可能的步骤。或者，方法实施例中的某些步骤可以是可选的，在某些使用场景中可以删除。或者，可以在方法实施例中增加其他可能的步骤。

并且，各方法实施例之间可以单独实施，或结合起来实施。

可以理解的是，为了实现上述功能，前述第一平台、第二平台包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本实施例可以根据上述方法示例对第一平台、第二平台进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块可以采用硬件的形式实现。需要说明的是，本实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

本申请实施例还提供了一种安全策略生成装置，如图12所示，该装置可以包括获取模块1201、第一策略生成模块1202和第二策略生成模块1203。

其中，获取模块1201可以实现上述S1001所能实现的相关功能。第一策略生成模块1202可以实现上述S1002所能实现的相关功能。第二策略生成模块1203可以实现上述第一平台生成第二安全策略时的相关功能。

本申请实施例还提供了另一种安全策略生成装置，如图13所示，该装置以包括获取模块1301、和第一策略生成模块1302。

其中，获取模块1301可以实现上述S1001所能实现的相关功能。第一策略生成模块1302可以实现上述S1002所能实现的相关功能。

在一些实施例中，该安全策略生成装置还可以与第二平台通信，从而从第二平台获取第一接口信息和第二安全策略。其中，第二平台可以包括第二策略生成模块，该模块可以实现上述第二平台生成第二安全策略时的相关功能。

本申请实施例还提供一种电子设备，如图14所示，该电子设备可以包括一个或者多个处理器1401、存储器1402和通信接口1403。可以理解的是，该电子设备可以是上述第一平台，或者，可以是上述第二平台。

其中，存储器1402、通信接口1403与处理器1401耦合。例如，存储器1402、通信接口1403与处理器1401可以通过总线1404耦合在一起。

其中，通信接口1403用于与其他设备进行数据传输。存储器1402中存储有计算机程序代码。计算机程序代码包括计算机指令，当计算机指令被处理器1401执行时，使得电子设备执行本申请实施例中的安全策略生成方法。

其中，处理器1401可以是处理器或控制器，例如可以是中央处理器(centralprocessing unit，CPU)，通用处理器，数字信号处理器(digital signal processor，DSP)，专用集成电路(application-specific integrated circuit，ASIC)，现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。

其中，总线1404可以是外设部件互连标准(peripheral componentinterconnect，PCI)总线或扩展工业标准结构(extended industry standardarchitecture，EISA)总线等。上述总线1404可以分为地址总线、数据总线、控制总线等。为便于表示，图14中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令，当计算机指令在电子设备或者安全策略生成装置上运行时，电子设备或者安全策略生成装置执行上述方法实施例中的相关方法步骤。

本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述方法实施例中的相关方法步骤。该计算机程序产品可以存储到可读存储介质。

前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

其中，本申请提供的电子设备、安全策略生成装置、计算机存储介质或者计算机程序产品均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (22)

1.一种安全策略生成方法，其特征在于，应用于部署运行环境的第一平台，包括：

获取所述第一平台上的进程对应的第一接口信息；所述第一接口信息包括所述进程、所述进程与调用的第一接口的对应关系；所述第一接口访问的资源是变化的；

获取所述第一接口信息中的所述第一接口对应的用例，并基于所述用例，确定所述第一接口对应的第一安全策略。

2.根据权利要求1所述的方法，其特征在于，所述第一接口包括动态系统调用接口和/或动态对外接口，所述动态系统调用接口用于通过发生变化的参数访问资源，所述动态对外接口不存在于预设接口清单中，所述发生变化的参数包括外部输入的参数、配置信息、环境变量中的一项或多项，所述预设接口清单包括所述第一平台的对外接口。

3.根据权利要求1或2所述的方法，其特征在于，获取所述第一接口对应的用例，包括：

确定所述第一接口对应的功能；

根据所述第一接口对应的功能，获取所述第一接口对应的一个或多个用例。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述基于所述用例，确定所述第一接口对应的第一安全策略，包括：

运行所述用例，并获取所述第一平台生成的第一告警信息；

根据所述第一告警信息，确定所述第一接口对应的第一安全策略。

5.根据权利要求4所述的方法，其特征在于，在确定所述第一接口对应的第一安全策略之后，所述方法还包括：

基于所述第一安全策略和所述进程的第二安全策略，再次运行所述用例，并获取所述第一平台生成的第二告警信息；

根据所述第二告警信息，对所述第一安全策略进行第一操作，获得所述进程的第三安全策略；所述第一操作包括对所述第一安全策略修改和/或补充。

6.根据权利要求5所述的方法，其特征在于，获取所述第一接口信息，包括：

从部署开发环境的第二平台获取所述第一接口信息。

7.根据权利要求1-5任一项所述的方法，其特征在于，获取所述第一接口信息，包括：

获取所述第一平台上所述进程对应的打包信息，所述打包信息包括所述进程对应的二进制文件和/或配置文件对应的打包文件的信息；

解析所述打包信息，获得所述二进制文件和/或配置文件在所述第一平台上部署的实际路径信息；

根据所述实际路径信息，确定所述进程对应的主体安全上下文信息和客体安全上下文信息；

基于所述主体安全上下文信息和所述客体安全上下文信息，扫描所述进程对应的接口，确定所述第一接口信息和所述进程对应的第二接口信息。

8.根据权利要求7所述的方法，其特征在于，所述第二接口信息包括所述进程、所述进程与调用的第二接口的对应关系，所述第二接口访问的资源是固定的。

9.根据权利要求8所述的方法，其特征在于，所述第二接口包括静态系统调用接口和/或静态对外接口，所述静态系统调用接口用于通过不发生变化的参数访问资源，所述静态对外接口存在于预设接口清单中，所述预设接口清单包括所述第一平台的对外接口。

10.根据权利要求5所述的方法，其特征在于，所述方法还包括：从部署开发环境的第二平台获取所述进程的第二安全策略；或

根据第二接口信息获取所述进程的第二安全策略，所述第二接口信息包括所述进程、所述进程与调用的第二接口的对应关系，所述第二接口访问的资源是固定的。

11.一种安全策略生成装置，其特征在于，所述装置部署有运行环境，所述装置包括：

获取模块，用于获取所述装置上的进程对应的第一接口信息；所述第一接口信息包括所述进程、所述进程与调用的第一接口的对应关系；所述第一接口访问的资源是变化的；

第一策略生成模块，用于获取所述第一接口信息中的所述第一接口对应的用例，并基于所述用例，确定所述第一接口对应的第一安全策略。

12.根据权利要求11所述的装置，其特征在于，所述第一接口包括动态系统调用接口和/或动态对外接口，所述动态系统调用接口用于通过发生变化的参数访问资源，所述动态对外接口不存在于预设接口清单中，所述发生变化的参数包括外部输入的参数、配置信息、环境变量中的一项或多项，所述预设接口清单包括所述装置的对外接口。

13.根据权利要求11或12所述的装置，其特征在于，所述第一策略生成模块，还用于：

确定所述第一接口对应的功能；

根据所述第一接口对应的功能，获取所述第一接口对应的一个或多个用例。

14.根据权利要求11-13任一项所述的装置，其特征在于，所述第一策略生成模块，还用于：

运行所述用例，并获取所述装置生成的第一告警信息；

根据所述第一告警信息，确定所述第一接口对应的第一安全策略。

15.根据权利要求14所述的装置，其特征在于，所述第一策略生成模块，还用于：

基于所述第一安全策略和所述进程的第二安全策略，再次运行所述用例，并获取所述装置生成的第二告警信息；

根据所述第二告警信息，对所述第一安全策略进行第一操作，获得所述进程的第三安全策略；所述第一操作包括对所述第一安全策略修改和/或补充。

16.根据权利要求15所述的装置，其特征在于，所述获取模块，还用于：从部署开发环境的第二平台获取所述第一接口信息。

17.根据权利要求11-15任一项所述的装置，其特征在于，所述获取模块，还用于：

获取所述装置上所述进程对应的打包信息，所述打包信息包括所述进程对应的二进制文件和/或配置文件对应的打包文件的信息；

解析所述打包信息，获得所述二进制文件和/或配置文件在所述装置上部署的实际路径信息；

根据所述实际路径信息，确定所述进程对应的主体安全上下文信息和客体安全上下文信息；

基于所述主体安全上下文信息和所述客体安全上下文信息，扫描所述进程对应的接口，确定所述第一接口信息和所述进程对应的第二接口信息。

18.根据权利要求17所述的装置，其特征在于，所述第二接口信息包括所述进程、所述进程与调用的第二接口的对应关系，所述第二接口访问的资源是固定的。

19.根据权利要求18所述的装置，其特征在于，所述第二接口包括静态系统调用接口和/或静态对外接口，所述静态系统调用接口用于通过不发生变化的参数访问资源，所述静态对外接口存在于预设接口清单中，所述预设接口清单包括所述装置的对外接口。

20.根据权利要求15所述的装置，其特征在于，所述获取模块，还用于：

从部署开发环境的第二平台获取所述进程的第二安全策略；或，

根据第二接口信息获取所述进程的第二安全策略，所述第二接口信息包括所述进程、所述进程与调用的第二接口的对应关系，所述第二接口访问的资源是固定的。

21.一种安全策略生成系统，其特征在于，包括第一平台和第二平台，所述第一平台部署运行环境，所述第二平台部署开发环境；

所述第二平台，用于获取所述第一平台上的进程对应的第一接口信息和第二接口信息；所述第一接口信息包括所述进程、所述进程与调用的第一接口的对应关系，所述第二接口信息包括所述进程、所述进程与调用的第二接口的对应关系，所述第一接口访问的资源是变化的，所述第二接口访问的资源是固定的；

所述第二平台，还用于根据所述第二接口信息，获取所述进程的第二安全策略，并向所述第一平台发送所述第一接口信息；

所述第一平台，用于获取所述第一接口信息中的所述第一接口对应的用例，并基于所述用例，确定所述第一接口对应的第一安全策略。

22.一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在第一平台上运行时，使得所述第一平台执行如权利要求1-10任一项所述的安全策略生成方法。