CN115623013A

CN115623013A - Strategy information synchronization method, system and related product

Info

Publication number: CN115623013A
Application number: CN202110786571.2A
Authority: CN
Inventors: 吴岳廷
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-07-12
Filing date: 2021-07-12
Publication date: 2023-01-17

Abstract

The embodiment of the application discloses a strategy information synchronization method, a strategy information synchronization system and a related product. The first equipment requests the second equipment for pulling the relevant information of the target strategy according to the pulling request of the target strategy by the component to be synchronized; and receiving a response message of the second device for the pull request, encrypting the relevant information of the target strategy into a first ciphertext, and sending the first ciphertext to the component to be synchronized. The first key is dynamically calculated and generated according to the dynamic characteristic information and the static characteristic information of the first device, so that only when the component to be synchronized dynamically calculates and generates the first key according to the dynamic characteristic information and the static characteristic information, the component can successfully decrypt the first ciphertext to obtain the related information of the target policy to achieve policy synchronization. Because the first key is dynamically associated with the equipment and encrypts the strategy information requested by the component to be synchronized by the first key, the strategy information requested by the component is difficult to be attacked and cracked by a third party, the safety of synchronizing the strategy information to the component to be synchronized is ensured, and the privacy information in the strategy is difficult to leak.

Description

Policy information synchronization method, system and related product

Technical Field

The present application relates to the field of information security technologies, and in particular, to a policy information synchronization method, system and related product.

Background

In a zero trust network access architecture, a client often needs to synchronize policy information of a server. The policy information includes rules that drive the functional components of the client to perform the corresponding functions. The policy information may contain sensitive information such as tickets, age, validity times, etc. At present, in a scheme of synchronizing policy information of a zero trust network access architecture, a protection mechanism of the policy information is weak, so that potential safety hazards exist in sensitive information.

Specifically, in the existing scheme of synchronizing policy information, the policy information is written in the form of a file into the client device. The functional component of the client periodically checks or continuously monitors the change of the policy information in the file to determine whether the policy information needs to be updated synchronously. Although the policy information written in the local file is encrypted, the encryption mechanism has insufficient security, so that the security of sensitive information in the policy information is damaged. The realization of policy information synchronization in security has become a technical problem to be solved urgently in the current field.

Disclosure of Invention

The embodiment of the application provides a method, a system and a related product for synchronizing policy information, so as to improve the security of policy information synchronization.

In view of this, a first aspect of the present application provides a policy information synchronization method, where the policy information synchronization method is applied to a first device, and a client and a server of a target software version are installed in the first device and a second device, respectively, and the method includes:

according to the pulling request of the target strategy by the component to be synchronized, the related information of the target strategy is requested to be pulled from the second equipment;

receiving a response message of the second equipment for the pull request;

encrypting the relevant information of the target strategy determined according to the response message into a first ciphertext by using a first secret key; the first key is a key generated according to the dynamic characteristic information and the static characteristic information of the first equipment;

sending a first ciphertext to the component to be synchronized;

and decrypting the first ciphertext through the component to be synchronized by using the first key to obtain the relevant information of the target strategy for synchronizing the component to be synchronized.

A second aspect of the present application provides a policy information synchronization system, including:

a first device and a second device; the first device and the second device are respectively provided with a client and a server of a target software version;

the first device is used for requesting the second device to pull the relevant information of the target strategy according to the pull request of the component to be synchronized to the target strategy;

the second equipment is used for sending a response message to the first equipment according to the request of the first equipment;

the first device is also used for determining the relevant information of the target strategy according to the response message and encrypting the relevant information of the target strategy into a first ciphertext by using a first key; sending a first ciphertext to the component to be synchronized; decrypting the first ciphertext through the component to be synchronized by using the first key to obtain the relevant information of the target strategy for synchronizing the component to be synchronized; the first key is a key generated according to the dynamic characteristic information and the static characteristic information of the first device.

A third aspect of the application provides a computer comprising a processor and a memory:

the memory is used for storing the program codes and transmitting the program codes to the processor;

the processor is adapted to perform the steps of the policy information synchronization method according to the first aspect as described above, according to instructions in the program code.

A fourth aspect of the present application provides a computer-readable storage medium for storing program code for executing the policy information synchronization method of the first aspect.

According to the technical scheme, the embodiment of the application has the following advantages:

the embodiment of the application provides a strategy information synchronization method. According to the method, a first device of an installation client requests a second device of a server with the same software version for pulling the relevant information of a target strategy according to the pulling request of a component to be synchronized to the target strategy. And receiving a response message of the second device for the pull request, encrypting the relevant information of the target strategy determined according to the response message into a first ciphertext, and sending the first ciphertext to the component to be synchronized. The first key is dynamically calculated and generated according to the dynamic characteristic information and the static characteristic information of the first equipment, and the dynamic association of the first key and the equipment is guaranteed, so that only when the component to be synchronized dynamically calculates and generates the first key according to the dynamic characteristic information and the static characteristic information, the component to be synchronized can successfully decrypt the first ciphertext to obtain the relevant information of the target strategy, and strategy synchronization is achieved. In the scheme, the first key is dynamically associated with the equipment and is used for encrypting the strategy information requested by the component to be synchronized, so that the strategy information requested by the component to be synchronized is difficult to be attacked and cracked by a third party, and the safety of synchronizing the strategy information to the component to be synchronized is ensured.

Drawings

FIG. 1 is an architecture diagram of a policy information synchronization system in an embodiment of the present application;

fig. 2 is a schematic view of a scenario that a client component in a first device synchronizes a policy from a server in a second device through a policy management component according to an embodiment of the present application;

fig. 3 is a flowchart of a policy information synchronization method provided in an embodiment of the present application;

FIG. 4 is a diagram illustrating a mapping relationship between a client component and a policy provided in an embodiment of the present application;

fig. 5 is a signaling diagram of policy information synchronization provided in an embodiment of the present application;

fig. 6 is a signaling diagram of a process of verifying a component to be synchronized, a policy management component, and a server based on a random number according to an embodiment of the present application;

fig. 7 is a schematic diagram of generation of a first key provided in an embodiment of the present application;

fig. 8 is a schematic diagram of generation of a second key provided in an embodiment of the present application;

FIG. 9 is a schematic diagram of a zero trust network security service provider providing network security services;

FIG. 10 is a schematic diagram of the design of an iOA system;

FIG. 11 is a schematic flow diagram for compiling versions of integrated products in a CI system;

fig. 12 is a schematic structural diagram of a server according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of a terminal device according to an embodiment of the present application.

Detailed Description

In a zero trust network access architecture the client needs to synchronize policy information from the second device. Currently, the policy information of the client may be written into the first device file, and the components of the client may share the policy information in the file. But the encryption mechanism is not strict, and the key is easy to be cracked by a third party, so that sensitive information is leaked or falsely used.

In view of the above problems, embodiments of the present application provide a policy information synchronization method, system and related product. The method comprises the steps that a first device requests a second device for pulling relevant information of a target strategy based on a pulling request of a component to be synchronized to the target strategy; receiving a response message of the second device; encrypting the relevant information of the target strategy determined according to the response message by using the first key to form a ciphertext, and sending the ciphertext to the component to be synchronized; and decrypting the ciphertext by the component to be synchronized with the first key. The first key is dynamically calculated and generated according to the dynamic characteristic information and the static characteristic information of the first device, so that only when the component to be synchronized dynamically calculates and generates the first key according to the dynamic characteristic information and the static characteristic information of the device, the component can successfully decrypt the first ciphertext to obtain the relevant information of the target policy to achieve policy synchronization. In the embodiment of the application, the first key is obtained in a specific mode and is used for encrypting the relevant information of the target strategy, so that the relevant information of the strategy is transmitted in a safer mode and is not easy to be cracked by attacks.

In order to make the technical solutions of the present application better understood, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be understood that the present application is applied to a policy information synchronization system, please refer to fig. 1, where fig. 1 is an architecture diagram of a policy information synchronization system in an embodiment of the present application. As shown in fig. 1, the policy information synchronization system 100 in fig. 1 includes a first device 101 and a second device 102. The policy information synchronization system 100 has a client of a target software version installed on the first device 101. The number of the first devices 101 is not limited, that is, the system 100 may include one first device 101, or may include a plurality of first devices 101. The first device 101 may be a mobile phone, a desktop computer, a Personal Digital Assistant (PDA), a tablet computer, etc. installed with a client of the target software version. The specific type of the first device 101 is not limited herein. The second device 102 may be a server, or may be a terminal device such as a desktop computer or a tablet computer. The second device 102 is installed with a second device software package associated with the target software version server. The second device 102 can provide a service for synchronizing the policy information for the clients of the first devices 101 based on the pull request of the clients of the first devices 101 for the policy information by running the server program.

Fig. 2 is a schematic view of a scenario that a client component in a first device synchronizes a policy from a server in a second device through a policy management component according to an embodiment of the present application. As shown in fig. 2, the first device 101 includes at least one functional component of the target version client, and such a component has a requirement for synchronizing the policy from the server, and some functions of the client are performed through the synchronized policy. For example, client component 001 is used to implement network blocking functionality, client component 002 is used to implement firewall functionality, and client component 003 is used to monitor a Universal Serial Bus (USB). If each functional component of the client pulls a policy to the server, it is obvious that the transmission performance between the first device 101 and the second device 102 is reduced, and meanwhile, the security verification difficulty of the server is greatly increased. Therefore, in this embodiment of the present application, the first device 101 may be specially provided with a policy management component 000, where the policy management component 000 is a component that serves to pull a policy from other client components, and the policy management component 000 serves as a unified entry for pulling the policy from each of the functional components 001 to 003 in the client of the target software version to the server, so as to facilitate pulling the policy from the client in the first device 101 to the server in the second device 102, and reduce congestion in communication between the two devices. The strategy pulling strategy of each client functional component needs to be controlled and controlled by the same safety of the strategy management component 000, the way of pulling strategy information from the client to the server is simplified, and the safety is improved. In the following description, a component to be synchronized in each client component that needs to pull a policy to the server is referred to as a to-be-synchronized component.

Herein, the server may be an independent physical server, may also be a server cluster or a distributed system formed by a plurality of physical servers, and may also be a cloud server that provides basic cloud computing services such as cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a network service, cloud communication, middleware service, a domain name service, a security service, a CDN, and a big data and artificial intelligence platform. The terminal may be, but is not limited to, a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, and the like. The terminal and the server may be directly or indirectly connected through wired or wireless communication, and the application is not limited herein.

Cloud Security (Cloud Security) refers to a generic term for Security software, hardware, users, organizations, secure Cloud platforms based on Cloud computing business model applications. The cloud security integrates emerging technologies and concepts such as parallel processing, grid computing and unknown virus behavior judgment, the latest information of Trojan horses and malicious programs in the internet is obtained through abnormal monitoring of a large number of netted clients on software behaviors in the network, the latest information is sent to a server for automatic analysis and processing, and then the solutions of viruses and Trojan horses are distributed to each client.

The main research directions of cloud security include: 1. the cloud computing security mainly researches how to guarantee the security of the cloud and various applications on the cloud, including the security of a cloud computer system, the secure storage and isolation of user data, user access authentication, information transmission security, network attack protection, compliance audit and the like; 2. the cloud of the security infrastructure mainly researches how to adopt cloud computing to newly build and integrate security infrastructure resources and optimize a security protection mechanism, and comprises the steps of constructing a super-large-scale security event and an information acquisition and processing platform through a cloud computing technology, realizing the acquisition and correlation analysis of mass information, and improving the handling control capability and the risk control capability of the security event of the whole network; 3. the cloud security service mainly researches various security services, such as anti-virus services and the like, provided for users based on a cloud computing platform.

The following describes an implementation process of the policy information synchronization method. First, a description is given of an implementation process of the policy information synchronization method, with the first device as an implementation subject.

Fig. 3 is a flowchart of a policy information synchronization method according to an embodiment of the present application. The policy information synchronization method shown in fig. 3 includes:

s301: and the strategy management component of the first equipment requests the second equipment to pull the relevant information of the target strategy according to the pull request of the component to be synchronized to the target strategy.

Here, the component to be synchronized refers to any functional component that needs to pull a policy from the server side under the client side of the target software version of the first device. The component to be synchronized first initiates a pull request for the target policy to the policy management component. And then, based on the pulling request of the component to be synchronized, the policy management component initiates a pulling request for the relevant information of the target policy to the server of the second device, and informs the server of which component to be synchronized the component to be synchronized of the target policy is specifically requested to be pulled. For example, when the policy management component sends a pull request to the server, the identifier of the component to be synchronized is also sent to the second device. Different component identifications are different, so that the server side can uniquely determine the component to be synchronized for initiating the pull request aiming at the target strategy according to the identification.

In addition, the pull request may include known information of the target policy, such as an identifier of the target policy, a content hash of the target policy known to the component to be synchronized, and the like. The known content hash may be synchronized to the component to be synchronized at the time of the past synchronization policy. The content hash is used to verify whether the content of the target policy is updated. The policy management component may generate a to-be-verified list according to the pull request, where the to-be-verified list includes an identifier of the target policy and a hash of a content of the target policy, which may be known. The policy management component may specifically send the to-be-checked list to the server when requesting from the second device server. The server side can check the updating condition according to the existing content hash, and can determine whether the request can be correctly responded according to the identification of the target strategy if the request is not updated.

In practical application, the policy management component may interface multiple components to be synchronized, and therefore, in order to reduce the number of transmission times, the policy management component may collect pull requests of the multiple components to be synchronized, generate a total list one to be checked, and send the total list one to the server.

S302: the policy management component receives a response message of the second device to the pull request.

In an embodiment of the present application, the server side of the second device includes a mapping relationship between the client component and the policy associated with the target software version. The mapping relationship between the client component and the policy can be one-to-one, many-to-one, one-to-many. Fig. 4 is a schematic diagram of a mapping relationship between a client component and a policy according to an embodiment of the present application. As shown in fig. 4, the dashed line between the policy and the client component is the mapping relationship between the policy and the client component, and the client component only has the right to request to pull the policy with the mapping relationship, but cannot successfully pull the policy without the mapping relationship. Fig. 4 is only illustrated by taking four client components A1 to A4 and five policies P1 to P5 as examples, and the number of policies and the number of client components involved in the mapping relationship maintained at the service end are not limited herein. At the server, the mapping relationship between the client component and the policy may also be referred to as a subscription relationship and an execution relationship, and taking fig. 4 as an example, the client component A3 subscribes to the policies P1 to P4 at the same time, and executes the policies according to the subscribed policies; policy P1 is subscribed to by client components A1-A3, and is enforced by these client components.

In a specific implementation scenario of the present solution, the software is security office software installed and deployed on employee devices (first devices) and servers (second devices) of a certain enterprise. The software versions of the first device and the second device are consistent, namely, both the software versions are the target software version. The software also has a management end which is installed on the equipment used by the enterprise administrator, and the enterprise administrator can pre-configure various types of strategies on the management end and specify the mapping relation between the strategies and the functional components of the client side by operating the management end. The server side stores the content of each strategy and the mapping relation between each type of strategy and the client side component. The management end can change the content of the strategy and can also change the mapping relation between the client component and the strategy when necessary. For example, removing the client component A4 subscription to the policy P5 shown in fig. 4, so that the client component A4 subscribes only to the policy P4. The content of the policy and the mapping relationship of the policy to the client components are controlled by the enterprise administrator through the administrator. After the client receives the strategy, the strategy can be flexibly analyzed and executed by a client component subscribing the strategy. Since the mapping relationship between the client component and the policy can be adjusted at the management end, the mapping relationship between the client component and the policy, which is equivalent to the mapping relationship between the client component and the policy stored at the service end, can also be adjusted and changed. The adjustment mode comprises the following steps: deleting or adding a client component, deleting or adding a policy, deleting or adding a mapping of a policy to a client component, and the like.

Based on the above description, the second device operation server can determine whether the requested target policy has a correct mapping relationship with the component to be synchronized according to the stored mapping relationship and the identifier of the component to be synchronized. And the second device sends a response message aiming at the pull request to the first device based on the specific condition that the mapping relation is met or not met. The first device may then receive the response message through communication with the second device.

S303: and the strategy management component encrypts the relevant information of the target strategy determined according to the response message into a first ciphertext by using a first key, wherein the first key is a key generated according to the dynamic characteristic information and the static characteristic information of the first device.

In an example implementation manner, the latest content about the target policy requested by the component to be synchronized is included in the response message, and since the component to be synchronized does not directly interface with the server when requesting the policy, but requires the policy management component to be a "broker" for relay, the policy management component needs to determine the relevant information of the target policy from the response message after receiving the response message, and send the information to the component to be synchronized.

It should be noted that, there is a possibility that the component to be synchronized is forged, and in order to ensure secure transmission of the policy information, in the embodiment of the present application, the policy management component encrypts the relevant information of the target policy by using the first key, and sends the first ciphertext obtained by the encryption to the component to be synchronized. The first key is a key generated according to the dynamic characteristic information and the static characteristic information of the first device. If the component to be synchronized is not a forged component, the component to be synchronized should be able to acquire the device dynamic characteristic information and the static characteristic information that are consistent with those used by the policy management component to generate the first key, so that the first key can also be generated to decrypt the first ciphertext.

The dynamic characteristic information of the first device may include, but is not limited to, at least one of:

boot time or process start time.

The static feature information of the first device may include, but is not limited to, at least one of:

processor identification cpuid, bios unique identification Biosuuid, or hard disk serial number.

S304: and the policy management component sends the first ciphertext to the component to be synchronized.

S305: and the component to be synchronized of the first equipment decrypts the first ciphertext by using the first secret key to obtain the relevant information of the target strategy for synchronizing the component to be synchronized.

If the component to be synchronized successfully generates the first secret key, the first ciphertext can be decrypted to obtain the relevant information of the target strategy. Such as a hash value of the policy content of the target policy.

The above is the policy information synchronization method provided in the embodiment of the present application. In the method, a first device of an installation client requests a second device of a server with the same software version for pulling the relevant information of a target strategy according to the pulling request of a component to be synchronized to the target strategy. And receiving a response message of the second device for the pull request, encrypting the relevant information of the target strategy determined according to the response message into a first ciphertext, and sending the first ciphertext to the component to be synchronized. The first key is generated by dynamic calculation according to the dynamic characteristic information and the static characteristic information of the first device, so that the dynamic association between the first key and the first device is ensured, and therefore, only when the component to be synchronized dynamically calculates the first key according to the dynamic characteristic information and the static characteristic information, the component to be synchronized can successfully decrypt the first ciphertext to obtain the relevant information of the target policy, so as to realize policy synchronization. Because the first key is dynamically associated with the first device and encrypts the policy information requested by the component to be synchronized by the first key, the third party is difficult to acquire the accurate device dynamic characteristic information and static characteristic information for generating the first key, and therefore the third party is difficult to intercept the first ciphertext sent by the policy management component and decrypt the first ciphertext successfully through the component to be synchronized which is forged on other devices. Therefore, the safety that the strategy information is synchronized to the component to be synchronized is ensured, and sensitive information in the strategy information is prevented from being leaked and falsely used.

Furthermore, currently in the zero trust access network architecture, the mapping relationship between the client component and the policy is usually written into the logic code of the client, and the writing mode is hard code (hardcode). When the data changes, the modification of the data is not facilitated, and the quality of the program is reduced. Because the code has strictly stipulated the strategy type that the client component can subscribe, the mapping relation between the strategy and the component is not easy to expand, the flexibility is poor, and the maintenance is difficult. In the embodiment of the application, the mapping relationship established by the policy and the client is configured, adjusted and maintained by the management terminal, and the adjustment on the mapping relationship can be embodied in the mapping relationship stored by the server terminal, so that the client is not required to make hard coding on the mapping relationship. Thus, the flexibility of strategy synchronization is improved.

The method comprises the steps that a client repeatedly pulls a strategy from a server, so that the network transmission times are excessive, and the strategy synchronization efficiency is low. And further, the problems of heavy transmission burden and low synchronization efficiency caused by frequent transmission of the strategy information between the server and the client are avoided. Meanwhile, the probability that the strategy information is attacked in the transmission process between the first equipment and the second equipment is reduced. The following describes the procedure of pulling the initial full-scale policy and utilizing the initial full-scale policy with reference to fig. 5, and further describes the influence of the mapping relationship included in the server on the indication content of the response message.

Referring to fig. 5, the figure is a signaling diagram of policy information synchronization provided in an embodiment of the present application. As shown in fig. 5, the method involves a policy management component of a first device client, a component to be synchronized, and a server of a second device. The policy management component and the component to be synchronized have a public key uniquely corresponding to the target software version, and the server side has a private key uniquely corresponding to the target software version.

S501: the policy management component pulls the initial full-scale policy to the server.

And the strategy management component and the server establish https bidirectional connection and initiate a pull request for the initial full-scale strategy to the server. This step may be performed only once, for example, after the client and the server are installed separately and the mapping relationship between the client component and the policy is preliminarily configured, the policy management component performs this step. The initial full-scale policy includes the policies configured for all client components of the first device client.

And initiating a pull request for the initial full-scale strategy to a server.

S502: and the server loads the initial full-scale strategy configured by the management terminal for the components of the first equipment client from a database or other storage media, and encrypts the initial full-scale strategy by using the private key.

Upon receiving the request, the server loads the initial full-scale policy configured by the administrator from a database or other storage medium of the second device and encrypts the contents of the initial full-scale policy using the private key before responding to the policy management component.

S502': and the server side sends the ciphertext of the initial full-scale strategy to the strategy management component.

S502': the policy management component decrypts the initial quantum policy sent using the initial quantum policy encrypted with the private key using the public key.

After receiving the response of the server, the policy management component decrypts the initial full-scale policy by using the built-in public key.

S503: the policy management component encrypts the initial full-scale policy by using a second key; the second key is a key generated according to the dynamic characteristic information and the static characteristic information of the first device.

The policy management component may encrypt the decrypted initial full-size policy using a second key for storage in memory. Wherein the second key is a key generated according to the dynamic characteristic information and the static characteristic information of the first device.

S504: and the strategy management component caches the ciphertext of the initial full strategy in a memory of the first device, and takes the strategy cached in the memory as the stored strategy of the first device.

And establishing a ciphertext cache in the memory, storing the content of the initial full strategy and avoiding repeatedly pulling the strategy to the server. And only when the strategy is updated, the strategy content is pulled from the server. The network transmission times are reduced, and the efficiency and the reliability are improved. In addition, because the policy content is stored in the ciphertext of the policy management component, and the key is dynamically calculated and generated, for example, the key changes when the environment changes, the device is different, or the process is started for different time, the key changes, and the security of the initial full-scale policy stored in the memory of the first device is improved. When the strategy in the plaintext needs to be read, the strategy still needs to be decrypted by the second secret key, the decrypted strategy plaintext is deleted after being used, and any decrypted plaintext is not kept in the first equipment.

S505: and the component to be synchronized sends a pull request for the target policy to the policy management component.

The hash value of the component to be synchronized can be carried in the pull request of the target policy sent by the component to be synchronized to the policy management component, and in addition, the hash value of the component to be synchronized can also be independently sent to the policy management component independently of the pull request. The hash value is used for the strategy management component to verify whether the component to be synchronized has the authority of requesting the strategy from the server.

S506: and when the policy management component determines that the component to be synchronized is the client component associated with the target software version, allowing the pull request to be received.

The manner of determining whether the component to be synchronized is a client component associated with the target software version is as follows:

the policy management component pulls a component hash list from the second device, wherein the component hash list comprises hash values corresponding to client components associated with the target software version; when the hash value corresponding to the component to be synchronized is in the component hash list, determining that the component to be synchronized is a client component associated with the target software version; otherwise, the component to be synchronized is not a client component associated with the target software version, that is, the component to be synchronized does not have the right to pull the policy to the server through the policy management component.

It should be noted that, in the present application, after the policy management component pulls the component hash list, the policy management component may encrypt the component hash list by using the second key; and then, caching the ciphertext of the component hash list in the memory of the first device. The component hash list is cached in the memory of the first device through a ciphertext (encrypted by the second key), so that the leakage probability of the component hash list can be reduced, and the component to be synchronized is less prone to being forged. The method and the device realize more reliable safety check of the policy management component on the component to be synchronized.

When the component hash list in the ciphertext needs to be read, the component hash list still needs to be decrypted by the second secret key, the decrypted list is deleted after being used, and any decrypted plaintext is not kept in the first device.

S507: the policy management component judges whether the target policy is included in the stored policy according to the pull request and the stored policy of the first device, and if yes, the process goes to S508; if not, S509 is entered.

This step is performed in order to determine how to make subsequent requests to the server, for example, for a target policy contained in an existing policy, it is necessary for the server to verify whether it has made policy content updates at the server. For a target policy that is not included in the existing policies, the policy is a new policy for the client, and the policy management component is required to directly request the server for the information related to the target policy.

S508: the policy management component requests the server to check the update condition of the relevant information of the target policy at the server, requests the server to pull the relevant information after the update of the target policy, sends the identifier of the component to be synchronized to the server, and enters S510.

The target policy comprises that when the existing policy exists, the policy management component requests the server to check the updating condition, specifically, whether the content of the target policy is updated at the server compared with the content at the client is confirmed by the server. As mentioned above, the identifier of the component to be synchronized can be used for the server to determine whether the target policy requested by the server conforms to the mapping relationship between the client component and the policy.

S509: the policy management component requests the server to pull the relevant information of the target policy, sends the identifier of the component to be synchronized to the server, and enters S510.

When the target policy is not contained in the existing policies, the policy management component cannot provide the requested target policy for the component to be synchronized. And therefore can only request from the server.

S510: the server side judges whether the pull request of the target strategy by the component to be synchronized accords with the mapping relation between the client component and the strategy associated with the target software version; if yes, the process proceeds to S511, and if no, the process proceeds to S513.

If the mapping relation is met, the pulling request of the component to be synchronized to the target strategy is represented, and the server side can normally respond; on the contrary, it indicates that the server cannot respond normally to the pull request of the component to be synchronized to the target policy, so S513 needs to be entered to check the specific problem by the server.

S511: the server side indicates that the target strategy contained in the existing strategy is not updated at the server side through a response message issued to the strategy management component; alternatively, the target policy indicating the inclusion or non-inclusion of the existing policies is updated at the server, and the information related to the target policy is sent to the policy management component via a response message, and the process proceeds to S512.

It should be noted that the response message sent by the server to the policy management component, including the response message mentioned below, may be encrypted by the server through a private key. The response message may be decrypted if the policy management component holds a public key that matches the private key.

S512: the policy management component determines the relevant information of the target policy according to the indication of the response message, and proceeds to S518.

For the case of not being updated, the policy management component can determine that the relevant information of the target policy required by the component to be synchronized exists in the memory according to the indication of the response message.

For the update condition, the information matched with the target policy decrypted by the policy management component with the public key in the response message is the latest content of the target policy issued by the server. Here, for a target policy that is not included in the existing policies, it is also new in nature to the client, and therefore is also referred to as an update occurred.

Since the step determines the relevant information of the target policy, S518 may be entered, and the policy information required by the component to be synchronized is encrypted and transmitted to the component to be synchronized.

S513: the server determines whether the target policy exists in the server, and if yes, the process proceeds to S514, and if no, the process proceeds to S516.

Whether the target strategy exists in the server side or not is judged because the reason and the measures are different for the target strategy to exist in the server side or not.

For example, if the target policy is at the server, it is only stated that the mapping relationship between the component to be synchronized and the target policy no longer exists. The possible reason for this is that the mapping is changed after being adjusted. For example, a target policy subscribed by the component a to be synchronized is configured, and the target policy subscribed by the component B to be synchronized is adjusted. At this time, although the component to be synchronized does not need to wait for the pulling and execution of the target policy, other components may still need to use the target policy, and thus S514 is entered.

If the target policy is not on the server, the target policy may be deleted from the server. At this time, the mapping relationship between other client components and the target policy also does not exist, the client does not need to keep the relevant content of the target policy, and the component to be synchronized does not need to wait for pulling the policy. Thus, the process proceeds to S516.

S514: and instructing the policy management component to clear the target policy from the execution domain of the component to be synchronized through a response message issued to the policy management component, and entering S515.

S515: and the policy management component clears the target policy from the execution domain of the component to be synchronized according to the indication of the response message.

S516: and instructing the policy management component to clear the target policy from the execution category of the component to be synchronized through a response message issued to the policy management component, clearing the target policy from the memory of the first device, and entering S517.

S517: and the policy management component clears the target policy from the execution scope of the component to be synchronized according to the indication of the response message and clears the target policy in the memory of the first equipment.

S518: and the strategy management component encrypts the relevant information of the target strategy determined according to the response message into a first ciphertext by using a first key, wherein the first key is a key generated according to the dynamic characteristic information and the static characteristic information of the first device.

S519: and the policy management component sends the first ciphertext to the component to be synchronized.

S520: and the component to be synchronized decrypts the first ciphertext by using the first key to obtain the relevant information of the target strategy, and performs strategy synchronization.

In the embodiment of the application, after the component to be synchronized decrypts to obtain the relevant information of the target policy, a ciphertext cache of the latest content of the target policy is constructed, and the plaintext is deleted after being used. The security of the latest target policy at the component to be synchronized is guaranteed.

The implementation manners of S518 to S520 in the above embodiments are substantially the same as those of S303 to S305 in the foregoing embodiments, and are not described herein again. S501-S504 may be performed only once, i.e., a pull of the initial full-scale policy is performed once.

In the above embodiment, the S506 policy management component allows receiving the pull request only when determining that the component to be synchronized is the client component associated with the target software version. The method is essentially to perform hash check on the component to be synchronized, so that the qualification of the client component associated with the target software version approved by the server is guaranteed, and the possibility that other unqualified components forge the client component into the target software version to acquire sensitive information is prevented.

In order to further check the security of the component to be synchronized, the policy management component may check the confidential directory and the signature of the component to be synchronized, in addition to the hash check. The specific mode is as follows:

performing directory verification on the component to be synchronized by using the installation directory of the client, and determining that the directory verification of the component to be synchronized passes when the process path of the component to be synchronized is in the installation directory;

performing signature verification on the component to be synchronized by using a preset signature verification condition, and determining that the signature of the component to be synchronized passes the verification when the signature of the component to be synchronized meets the preset signature verification condition;

s506 may specifically include: and when the component to be synchronized is determined to be the client component associated with the target software version and the directory check and the signature check of the component to be synchronized pass, allowing the pull request to be received. Through Hash check, directory check and signature check, a heavy restriction constraint is set for receiving and responding to the pull request by the policy management component, so that the legality and the safety of the component to be synchronized are guaranteed through multiple checks.

The detailed procedure for triggering the check is described below.

When the client runs, a long chain, called heartbeat link or heartbeat for short, is maintained with the server through the main service. The client periodically initiates a request to the server and receives a response of the server. When a client initiates a heartbeat request, the client takes the identification of each client component, the hash of the strategy content received by the components and the strategy distribution state (whether the latest strategy of the server is received by the client component or not), and after the server receives the heartbeat request, the strategy is combined with the mapping relation of the specified components to be processed according to the following logic.

1) Traversing all the strategy types received by the components, comparing all the strategies of the server side by combining the mapping relation between the strategies and the specified components, and triggering the specified client component to initiate strategy pull to the strategy management component if some strategies are not successfully received;

2) And traversing all the strategy content hashes received by the components, comparing the strategy content hashes stored by the server, and if the strategy content hashes are not consistent, forcibly triggering the corresponding client components to initiate strategy pulling (strategy updating) to the strategy management component.

When the main service in which the heartbeat is located identifies that a certain client component does not receive the policy or the policy update of the management end, the client component is informed to initiate a policy pull request to the policy management component through the TCP connection, and the client component (namely, the component to be synchronized) checks the file hash, the directory and the digital signature according to the following steps before establishing the TCP connection with the policy management component. As can be seen from the above description, for the pulling of the target policy, the component to be synchronized is specifically connected with the heartbeat of the client through the server, and the server indicates the target policy that the component to be synchronized needs to be pulled to the server through the policy management component.

Firstly, the policy management component checks whether the component to be synchronized requesting to pull the target policy is a normal in-version binary file. And the strategy management component acquires PID (process ID) of the opposite-end process through the address and the port number of the opposite end, acquires the path of the opposite-end process according to the PID, further acquires the hash (hash value corresponding to the component to be synchronized) of the process file, compares the hash of the process file with a component hash list (decrypted by a dynamically calculated second key) stored in a memory cache, and if the hash value does not meet the requirement, directly disconnects the connection and rejects the current strategy request.

Meanwhile, the client component requesting the policy management component for the policy may also acquire a PID (process ID) of the peer process through the address and port number of the peer in the same manner, and acquire the path of the peer process according to the PID. And the policy management component and the component to be synchronized requesting the policy both detect whether the file path of the opposite-end process is in the installation directory of the client. Because the pe files of the processing strategy are all in the subdirectory of the installation directory and the client has directory protection, other services or processes which are not the target software version are prevented from operating the installation directory, and the legality of the access process can be preliminarily judged by detecting whether the access process is in the installation directory or not. The PE file is called Portable Executable, meaning Portable Executable, and the common EXE, DLL, OCX, SYS, and COM files are PE files, and the PE file is a program file (which may be executed indirectly, such as DLL) on the microsoft Windows operating system.

And if the file of the opposite-end process is judged to be positioned in the installation directory of the client, acquiring the signature information of the process file and verifying the signature information. If the enterprise regulatory strength is low, process policy access to non-digital signatures may be relaxed. If the enterprise implements strong management and control, the process with the digital signature can be limited to request the policy. According to different control strengths, detection of the signature can be performed under one of the following preset signature verification conditions.

The 1 st: detecting whether the process file has a signature, wherein the process file is considered to be effective if the process file has the digital signature;

the 2 nd: the client locally verifies the validity of the digital signature, and if the digital signature is verified to be normal, the signature is considered to be valid;

and (3) type: on the basis of local signature verification, the name of the signer of the process digital signature is collected, the judgment is carried out according to a black and white list of the signature, and if the name of the signer is not in the black list, the signature is considered to be effective.

And 4, the method comprises the following steps: the method comprises the steps of collecting certificate chain information, information such as serial numbers, names, expiration times and signature states of a digest algorithm, a root certificate, a middle certificate and a signature certificate, and judging whether a signature is valid or not by searching whether blacklist node information exists in a certificate chain or not.

The detection strength of the 4 preset signature verification conditions on the signature is enhanced along with the increment of the enterprise management and control strength, and meanwhile, the detection time is also prolonged. The preset signature verification condition can be selected according to actual requirements. The specific preset signature verification condition for signature verification is not limited herein. And after synchronously detecting the process file hash, the installation directory and the signature information, entering a subsequent link. I.e., responding according to the pull request.

Given that a third party may forge a pull request to intercept a policy through a replay attack, in one possible implementation, the policy management component may also verify the pull request against a replay attack. The policy management component generates a random number when the pull request is verified in a check against replay attacks. The random number is generated, and in order to realize the cooperative verification among the policy management component, the component to be synchronized and the server. The associated usage of random numbers will be described in more detail below. A verification approach to prevent replay attacks is first described herein.

In a possible verification mode for preventing replay attack, a pull request for a target policy, which is sent to a policy management component by a component to be synchronized, contains a timestamp. The policy management component determines whether the policy management component is a replay attack according to the timestamp and the timestamp of the pull request sent to the policy management component to be synchronized last time. For example, if the difference between the two timestamps exceeds a preset time difference, the pull request is considered to belong to a replay attack. Of course, the manner in which replay attacks are determined here with a preset time difference is limited to requests for the same target policy. If the request is not for the same target policy, the predetermined time difference cannot be used to figure out the occurrence of a replay attack. In the embodiment of the application, whether the pull request belongs to replay attack or not can be effectively determined through the timestamp in the pull request, so that the safety of the pull request is ensured only after the verification for preventing replay attack is passed, and random numbers are generated to serve as the response of the strategy management component to the synchronization component.

Next, a process of verifying the component to be synchronized, the policy management component, and the server based on the random number according to the embodiment of the present application is described with reference to fig. 6, and fig. 6 is a signaling diagram of the process. As shown in fig. 6, the process includes:

s601: the policy management component generates a random number.

S602: the strategy management component encrypts the random number by a second secret key to obtain a second ciphertext of the random number; the second key is a key generated according to the dynamic characteristic information and the static characteristic information of the first device.

S603: and the policy management component sends a random number second ciphertext to the component to be synchronized.

S604: and the component to be synchronized decrypts the second ciphertext of the random number by using the second key to obtain the random number.

S605: and the component to be synchronized encrypts the random number by using the public key to obtain a third ciphertext of the random number.

S606: and the component to be synchronized sends the third ciphertext to the policy management component.

S607: and when the policy management component requests the second device to pull the relevant information of the target policy, the policy management component sends a third ciphertext of the random number and the random number to the second device.

S608: and after the server decrypts the third ciphertext of the random number by using the private key, performing security check on the first device based on the consistency of the decryption results of the random number and the third ciphertext.

S609: and after the server passes the security check of the first equipment, encrypting the response message to be sent by using a private key.

S610: and sending the encrypted response message to the policy management component.

In the verification process of the above-mentioned component to be synchronized, the policy management component, and the server introduced in fig. 6, the component to be synchronized can solve the random number encrypted by the policy management component, and also obtain the random number, which proves that there is substantially no mutual trust problem between the two, because the encryption and decryption keys of the random number are matched. Because the encryption and decryption keys, i.e. the second key, are generated based on the static characteristic information and the dynamic characteristic information of the device, the encryption and decryption keys serve as security guarantee for mutual trust between the static characteristic information and the dynamic characteristic information. And then, the component to be synchronized encrypts the random number again by using the public key and sends the random number to the strategy management component, the strategy management component sends the random number and the random number ciphertext encrypted by the public key to the server, and the server decrypts the random number ciphertext. If the server side can not solve the problem, the public key of the opposite side is in a problem, namely the public key of the side providing the ciphertext is not matched, and therefore the response can be refused. If the server side resolves the inconsistency, the received plaintext and the received ciphertext are explained, and one party is forged. For example, (plain text is not right), it is a false policy management component to indicate that the random number message is sent to the server; or for example, (ciphertext not correct), indicating that it is a false component to be synchronized that sends the ciphertext to the policy management component at a later time.

The above is one of the functions of random numbers, namely, the verification process of the component to be synchronized, the policy management component and the server is completed in a matching way. In addition, the random number can also enhance the cracking difficulty of the first key by the user. For example, in one possible implementation, the policy management component and the component to be synchronized generate the first key according to the dynamic feature information and the static feature information of the first device and the random number, respectively. Therefore, the difficulty of successfully cracking the first key is increased, and the reliability and the safety of the transmission of the related information of the target strategy between the strategy management component and the component to be synchronized are effectively improved. The risk of reverse cracking success is reduced.

In practical applications, to further enhance the security of the keys (including the first key and the second key) involved herein. Taking the generation of the first key as an example, the white-box key may be specifically generated based on a white-box cryptographic technique; the white-box key is associated with the target software version; the first key is generated from the white-box key, the dynamic and static feature information of the first device, and the random number. In one possible implementation, a static white-box encryption technique is used to generate the white-box key, which requires that a static white-box encryption/decryption mapping table is built in each of the component to be synchronized and the policy management component. The static white-box encryption and decryption mapping table is generated before the target software version is compiled, and the static white-box encryption and decryption mapping table is built in both the components of the client and the components related to encryption and decryption during compiling. The static white-box encryption and decryption mapping table is related to the version of the target software, and when the version of the target software changes, the static white-box encryption and decryption mapping table also changes. By the static white-box encryption and decryption mapping table, the difficulty of reversely cracking the software of different versions to obtain the key can be greatly increased. Fig. 7 is a schematic diagram of generation of the first key. Fig. 8 is a schematic diagram of generation of the second key.

As shown in fig. 7, the generation of the first key requires the first device to have static feature information, dynamic feature information, a random number, and a static white-box encryption/decryption mapping table. As shown in fig. 8, the second key is mainly used to encrypt and decrypt the memory ciphertext, and the second key generates the static feature information, the dynamic feature information, and the static white-box encryption/decryption mapping table that require the first device.

In the embodiment of the application, the client holds the public key matched with the private key of the server, and the public and private key pair is uniquely corresponding to the target software version, so that the matched public key is difficult to obtain by cracking other software versions. Therefore, the security of the first device and the second device in transmission communication of the strategy requested to be pulled by the client component is enhanced, and the probability of successful cracking of the key, the strategy and the like on the basis of other versions is reduced.

In the above embodiment, a process of a mechanism for pulling and synchronizing policy information from a client to a server is described with reference to fig. 5, and an implementation manner for performing multi-party verification based on a random number and enhancing security of policy information transmission is described with reference to fig. 6. For the convenience of understanding, the following comprehensively describes the implementation background of the whole scheme, and briefly describes the whole flow of implementing policy information synchronization by using a multi-aspect security mechanism.

A Tencent self-developed zero-trust borderless office security solution, namely a Tencent zero-trust security management system (hereinafter referred to as iOA), ensures efficient and stable remote cooperative office experience, and promotes application of a zero-trust technology in the digital industry. The following operations can be performed at the management end of the iOA, and are not in sequence:

1. and configuring the zero trust gateway, including deleting or adding the zero trust gateway. The name, settings, priority IP segments (which may be empty) and creation time of the configured gateway, etc. are displayed on the configuration interface of the iOA. Meanwhile, the configured gateway related information can be queried based on the name of the gateway.

2. And carrying out policy management.

3. The service site (domain name or IP) is configured. For example, edit accessible business system as. The category is IP; the IP is specifically a designated IP; the ports are all ports.

4. Adding resources, including: resource name, resource category (domain name, IP or IP segment), port, resource grouping, whether it is intranet direct, and protocol type.

When the administrator configures the zero trust policy at the management end, different accessible gateways can be configured for each business system. For example, an intranet resource may be added first, and then a gateway that can access the intranet resource in the service system is configured, and finally the determination is performed. Traffic filtering can be achieved based on combined policy control of person (identity) -application-target business systems. The iOA supports domain-wide names, IP segments, multiple ports, and can enable inheritance and extension based on a user organizational architecture. In policy management, a trusted application needs to be configured, and the configuration of the trusted application is as follows: including process name, signature information, version, process MD5, and sha256. In the process details of the iOA, the process name, operating system, signature, version, MD5, and sha256 can be seen.

Under the condition of starting zero-trust office, the terminal user can realize the zero-trust office function by logging in the iOA. The method for realizing login comprises the following steps: code scanning login, account login and the like. After the user logs in, if the terminal equipment of the user is connected with the internal network of the company, the internal resources can be accessed. In one possible implementation, the real-time protection policy is in an active state after the user logs in. After logging in, the user can also see the details of the trusted software issued by the administrator through the iOA client interface. The trusted software may be configured based on the identity authority of the user, and the access authority to the resource is configured according to the identity authority of the user. According to the user-level strategy issued by the management terminal, the terminal user can designate a trusted application to access the service system configured by the administrator.

In the embodiment of the application, the IOA serves as a zero trust network security service provider, a uniform entrance is provided for an access subject to access resources of an object through a network request through the zero trust proxy and the intelligent gateway, the iOA provides authentication operation for the uniform entrance, only the network request passing the authentication can be forwarded to the intelligent gateway through the zero trust proxy, and the intelligent gateway proxies the access of an actual service system. Fig. 9 is a schematic diagram of a zero trust network security service provider providing network security services.

FIG. 10 is a schematic diagram of the design scheme of the iOA system. As shown in fig. 10, the core block in the iOA system includes: the system comprises an iOA client, an iOA server, an access agent and an intelligent gateway. The core modules are explained below.

iOA client: the security agent is arranged on the employee working equipment and is responsible for verifying the credible identity of a user on the equipment, verifying whether the equipment is credible and verifying whether the application is credible; and applying the unknown process to the server for process inspection.

2. The access agent: hijacking equipment flow through the TUN/TAP virtual network card, authenticating through the iOA client, and then forwarding the request to the intelligent gateway, and if the request does not pass the authentication, directly connecting or interrupting the connection.

3. The intelligent gateway: the system is deployed at the entrances of enterprise application programs and data resources and is responsible for verifying, authorizing and forwarding each session request for accessing the enterprise resources;

4, iOA server: by the policy control engine: and performing safe scheduling on the service flow, and authorizing according to the human-equipment-software-application granularity. The identity authentication module authenticates the identity of a user, the equipment trusted module authenticates the hardware information and the safety state of the equipment, and the application detection module detects whether the application process is safe, such as whether a bug exists or not, whether a virus Trojan horse exists or not, and the like. The server periodically sends file inspection to threat intelligence cloud inspection service security or tav periodically, and if a malicious process is identified, the client is informed to execute asynchronous blocking operation.

The overall flow for the iOA to process an access subject request is: an access subject initiates a network request (as shown in (1) in fig. 10) for an access object through an application, a client hijacks the network request through a proxy client, the proxy client initiates an authentication request to an iOA client (i.e. the proxy applies for a credential of a current network request to the iOA client, as shown in (2) in fig. 10), and request parameters include a source IP or a domain name, a source port, a destination IP or a domain name, a destination port, and a process PID corresponding to the application. The IOA client collects the MD5 of the process, the process path, the latest modification time of the process (as shown in (3) in figure 10), copyright information, signature information and the like through the process PID sent by the agent, and the agent clientThe source IP or domain name, source port, destination IP or domain name, destination port of the network request transmitted from the client applies for the ticket to the iOA server (e.g., (4) (5) in fig. 10), and if the application is successful, the ticket, the maximum use number of the ticket, and the valid time of the ticket are sent to the proxy client as a response (e.g., (6) in fig. 10). The proxy client initiates an http request to the intelligent gateway (as shown in fig. 10 (7)), where the Authorization header field carries the network request certificate (ticket) transmitted from the iOA client, the intelligent gateway parses the ticket in the header field after receiving the request from the proxy client, checks the ticket to the iOA server (as shown in fig. 10 (8)), and if the check is successful (as shown in fig. 10 (9)), the intelligent gateway establishes a connection with the proxy client, and then the proxy client sends the original network request to the intelligent gateway, and the gateway forwards the original network request to the corresponding service server (as shown in fig. 10), and proxies the actual application network access (as shown in fig. 10 (7)), and the intelligent gateway verifies the ticket, and forwards the original network request to the corresponding service server (as shown in fig. 10 (8))

) (ii) a If the intelligent gateway fails to check the ticket (as shown in (9) in fig. 10), the connection between the proxy client and the intelligent gateway is interrupted, and a network access request is directly sent to the target service server through the proxy client to realize direct connection aiming at the traffic of an application except the zero trust policy for accessing a specific site.

In the zero trust network access architecture described above, the policy may contain sensitive information such as device information (device unique identifier, etc.), login user account information, login credentials (large ticket), network access credentials (small ticket), etc., and needs to be protected in an important way. A malicious attacker can perform reverse cracking analysis on an installation package of a client, read sensitive information with low complexity by combining a strategy issued by a management end, and illegally access an internal system of an enterprise by using a zero-trust network access function based on the sensitive information and a counterfeit protocol. The existing scheme of invoking a synchronous update policy based on local encrypted file sharing or an interface is to select a local encrypted file (or encrypt and store contents in a system registry) and drop a policy issued by a server, and a module needing to read policy contents realizes real-time policy update by self-defining service logic, such as periodically reading the policy encrypted file contents, or by monitoring the change of the policy encrypted file. Another solution is to synchronize the policy to the relevant modules through active dispatch or passive pull by means of process communication or active interface call (e.g., invoking an export interface of a dynamic link library dll or an SDK provided by a relevant component), and the prior art solution has disadvantages in that: on one hand, the scheme of landing the strategy on the local is easy to be reversely cracked, so that an attacker can obtain sensitive information in the strategy, and each service module realizes the strategy synchronization scheme through sharing the strategy file, thereby causing service code redundancy, poor flexibility and difficult expansion; on the other hand, the scheme called through the process communication or the active interface needs to put the mapping relation hardcode between the strategy concerned component and the specified strategy type into the client logic code, so that the expansion is not easy, and when the strategy content is synchronized, the safety of the strategy receiving component is not strictly verified, the strategy receiving component is easy to reverse and falsely use, and an attacker breaks and receives sensitive strategy information. The prior art fails to address the problem of secure receipt and theft of policies, and the present invention proposes a policy security synchronization scheme to address this problem. The scheme comprises the following steps:

1. the compiling system generates a mapping table for key calculation and a pair of public and private keys when producing the product version.

Continuous Integration (CI) is a term in software development, and CI is an automated process of automatic environment detection, code pulling, code scanning, compilation build (including unit testing in some cases) after a change in the source code of a software product. The CI system refers to an automated system that provides processes for software products, including code security scanning, full-scale compilation build, package export, unit testing, automatic deployment, and the like.

FIG. 11 is a flowchart illustrating the compilation of versions of integrated software products in a CI system. As shown in the above figure, after the automatic compiling and packaging process of the CI system is triggered manually or automatically, a public and private key pair generation tool generates a pair of public and private keys at random for the compiling process of subsequent servers and clients (the terminal platforms a and B shown in the figure represent different client platform versions, such as a client package running on Windows, mac). Before compiling, a white-box key generation tool whitebox.exe is automatically called to generate a static white-box encryption and decryption mapping table, and modules or components related to encryption and decryption are internally provided with the static white-box encryption and decryption mapping table during compiling, so that the encryption and decryption mapping tables (white-box libraries) of the iOA components of different versions are different.

The static white-box encryption and decryption mapping table is automatically generated when the product is compiled and packaged in the CI system, and the CI system can ensure that different iOA product versions correspond to different mapping tables. After the static white-box key generation tool generates the mapping table, on one hand, the CI system can automatically archive the contents of the mapping table and specific public and private key pairs to an appointed fixed domain name site for storage, and store the mapping table corresponding to each iOA version and the corresponding relation between the product version and the public and private key pairs. On the other hand, the public and private key pair and the white box key mapping table are applied to the product compiling and constructing process of the server and each platform client, and the specific process is as follows.

The unified construction process of the server deployment installation package can be performed in parallel with the client installation package unified construction process of each terminal platform, depending on whether the CI system supports parallel processing. FIG. 11 identifies only the key steps actually performed by the CI system, and is not a complete process. The private key of the public-private key pair is packaged into a service-side deployment installation package (which may be a service component or as a database initial value), and the public key is packaged into a related component or plug-in module of the client. And the static white-box key mapping table is packaged into binary files of the relevant service components of the service end and each platform version of the client.

After the code is scanned through the graph, the server executes the whole server code compiling and constructing process by using a private key and a static white box key mapping table, and each platform version of the client executes the whole client code compiling and constructing process by using a public key and a white box key mapping table, and then, the automatic unit testing and the safety scanning are completed. Before filing, each platform version of the client automatically scans binary files subjected to automatic compiling and signing, collects hash information of the components, packages the binary files to generate default data, stores the default data in a server deployment package, and provides basis for verification of subsequent client components as initial default data. The archived server and client versions uniformly form an iOA one-key installation deployment package, and after test acceptance and gradual gray scale, the iOA one-key installation deployment package can be deployed to an enterprise for formal use.

2. And (4) calculating an encryption and decryption key of the memory strategy.

The white-box key mapping table generated in the first step is used for encrypting and decrypting a policy memory, and the server is mainly protected, so that related information encrypted by the server can be landed, the client is easy to crack and reverse attack, in order to avoid exposing sensitive policy contents, the policy ciphertext is stored in the memory, specifically, the policy including the sensitive information related to equipment, login users, control information and the like is not landed, the policy ciphertext is stored in the memory, and the encryption and decryption key is generated through dynamic calculation. The method comprises the steps that an encryption salt value is formed by equipment static characteristic information (CPU, biosuid, hard disk serial number and the like) and equipment dynamic elements such as equipment dynamic starting time, an encryption and decryption key forming memory strategy contents is dynamically calculated by combining a mapping table generated in the first step, the key and an encryption process are changed into table look-up operation by using white-box encryption, and the key is hidden. The second key can be obtained by dynamic calculation in this way. The specific process is not described in detail. When the strategy is needed to be used, a decryption key is dynamically generated, a strategy ciphertext in the memory is read and decrypted, and the strategy ciphertext is destroyed after the plaintext is used up; when a certain type of strategy needs to be filled or updated in the memory, the encryption key is also dynamically generated, and the strategy ciphertext is generated or updated in the memory.

After the client host service receives the policy, it first needs to generate a key corresponding to the device. The memory encryption key is generated based on a binary file embedded static white-box encryption and decryption mapping table, dynamic information (such as a starting timestamp) associated with equipment, and equipment static characteristic information including CPUid, bios UUID and a hard disk serial number (serial num), so that when an iOA service is started, a bottom-layer driving service is started to acquire equipment information first to avoid the situation that a malicious attacker forges the equipment information, and an application layer is prevented from acquiring the equipment information falsely used by the attacker or increasing the falsely used cost of the attacker. And dynamically generating a key of the memory encryption storage strategy based on the equipment information and the white-box mapping table. The key used by the memory of the same iOA product version in each different device is different, the cost for an attacker to analyze the stolen information of the memory is improved, and the attacker can easily realize unauthorized access of the sensitive information under the background that a symmetric encryption algorithm and a general encryption and decryption key are usually adopted when the sensitive information is stored in the ground in the prior art, so that the unauthorized access is used as a breakthrough, the aim of system attack and occupation is fulfilled by using the normal functions of the product, and the security risk is caused to an enterprise service system.

3. And the server generates and stores the mapping relation between the strategy and the specified component.

4. The heartbeat of the client is regularly maintained with the long chain of the server, and the processing state of each component strategy of the client is sent (if the strategy is not processed by the component, the heartbeat informs the component to pull to the strategy management plug-in).

5. The heartbeat notifies the client component to pull the subscribed policies to the policy management component.

And (I) starting a policy management component, pulling the hash of each component of the client from the server, and constructing memory ciphertext cache storage.

And (II) the strategy management component pulls the full strategy from the server side to construct memory ciphertext cache storage.

And (III) the components requesting the policy and the policy management component verify the hash, the directory and the signature.

And (IV) the client component and the policy management component initiate a policy pull request and an interface verification process.

And (V) updating the self cache of the policy management component and synchronizing the policies.

(six) the client component receives and uses the policy.

The above third step to the fifth step have been described with emphasis on the foregoing, and are not described herein again. Please refer to the foregoing embodiments specifically.

The invention provides a safe and efficient strategy pulling and synchronizing scheme, which aims to reduce the risk of pulling or masquerading a strategy by a malicious attacker in the strategy pulling and synchronizing process and improve the flexibility of strategy synchronization. Firstly, instead of the correspondence between the hardcode function module and the policy type in the client component, the server dynamically maintains the mapping relationship between the client component and the policy type (which indicates that some client component is interested in a certain policy type, the policy of the type can only be pulled and synchronized by the corresponding client component, and meanwhile, when the policy content of the type changes, the corresponding client component needs to be notified to pull the policy again). When compiling the packaging version, the server side component and the client side component are uniformly provided with a corresponding public and private key and a static white box encryption and decryption mapping table, so that the safety of component verification is enhanced. When the integrated product versions are compiled in the CI system, a mapping table for generating the secret key is generated by using the static white box before compiling and is uploaded to the server side for storage, and meanwhile, the server side generates a unique public and private key for each product version. The strategy management component firstly pulls the full strategy from the server through HTTPS two-way communication and encrypts and stores the strategy in the memory. The memory encryption and decryption key adopts an introduced multi-factor mechanism, an encryption salt value is formed by static characteristic information (cpu id, biosuid, hard disk serial number and the like) of equipment and dynamic factors such as equipment startup time, process startup time and the like, and the memory encryption and decryption key is dynamically generated through a mapping table generated by a white box. The method includes the steps that multiple factors are integrated into the encryption process of the strategy memory, and a temporary memory key is dynamically calculated and generated based on a mapping table and equipment information, so that the key cannot be restored, different equipment and different product versions of the key are realized, the key safety is guaranteed, and strategy information is prevented from being cracked. When the strategy of the type specified by the server side changes, the server side informs all client side components concerned about the strategy to initiate a strategy pulling request to a strategy management component through heartbeat, the strategy management component and the server side firstly complete preliminary interface verification through preliminarily checking a binary file hash, a directory where the binary file hash exists and a digital signature, and verify the component validity of the request strategy by combining a built-in public and private key and a dynamically generated random number. After verification is successful, the strategy management component dynamically calculates the strategy information of the symmetric key encryption response to the client component, after the strategy ciphertext received by the client component is decrypted, the encryption and decryption keys are dynamically calculated and generated by combining the dynamic factors such as equipment static characteristic information (CPU, biosuuid, hard disk serial number and the like), equipment boot time and the like and a built-in white-box mapping table, the strategy is encrypted and decrypted, and the strategy plaintext is eliminated after the strategy ciphertext is used.

The invention only allows the strategy management component to pull and synchronize the strategy from the service through the entry point of the convergence strategy pull, and improves the dispatching flexibility of the strategy between the client components of the same version through the corresponding relation between the server control component and the strategy. Meanwhile, a public and private key and a white box encryption and decryption mapping table are built in the foreground and background components during compiling and packaging, and a factor for memory cache or dynamic calculation of a communication content encryption and decryption key is formed by combining dynamic and static characteristic information of equipment, so that the safety of strategy synchronization is effectively improved, the cost of attacking the client component by a cracker (the attack may cause the strategy containing sensitive information to be leaked and illegally used) is improved, the efficient synchronization of the strategy from a server to the actual functional component of the client is realized, the server provides the capability of an enterprise administrator for automatically or manually adjusting the corresponding relation between the strategy and the component, and the availability and the safety of the zero-trust network control system are enhanced.

Based on the policy information synchronization method introduced in the foregoing embodiment, correspondingly, the present application further provides a policy information synchronization system. The structure of the system can be seen in fig. 1. The policy information synchronization system 100 shown in fig. 1 includes: a first device 101 and a second device 102. The first device 101 and the second device 102 are respectively provided with a client and a server of a target software version;

the first device 101 is configured to request the second device 102 for pulling relevant information of a target policy according to a pull request of a component to be synchronized for the target policy;

the second device 102 is configured to send a response message to the first device 101 according to the request of the first device 101;

the first device 101 is further configured to determine relevant information of the target policy according to the response message, and encrypt the relevant information of the target policy as a first ciphertext by using a first key; sending a first ciphertext to the component to be synchronized; decrypting the first ciphertext by the component to be synchronized through the first key to obtain relevant information of the target strategy for synchronizing the component to be synchronized; the first key is a key generated from the dynamic characteristic information and the static characteristic information of the first device 101.

The first key is dynamically calculated and generated according to the dynamic characteristic information and the static characteristic information of the first device, and dynamic association of the first key and the device is guaranteed, so that only when the components to be synchronized dynamically calculate and generate the first key according to the dynamic characteristic information and the static characteristic information, the components to be synchronized can successfully decrypt the first ciphertext to obtain the relevant information of the target policy, and policy synchronization is achieved. In the scheme, the first key is dynamically associated with the equipment and is used for encrypting the strategy information requested by the component to be synchronized, so that the strategy information requested by the component to be synchronized is difficult to crack by a third party, and the safety of synchronizing the strategy information to the component to be synchronized is ensured.

Optionally, the server of the second device 102 includes a mapping relationship between the client component associated with the target software version and the policy, and the mapping relationship is adjustable at the second device 102; the first device 101 is further configured to send an identifier of a component to be synchronized to the second device 102 when requesting to pull the relevant information of the target policy from the second device 102;

the second device 102 is further configured to determine whether the pull request conforms to the mapping relationship according to the identifier, and send a response message to the first device 101 according to a determination result that the pull request conforms to the mapping relationship or does not conform to the mapping relationship.

Currently, in the zero trust access network architecture, the mapping relationship between the client component and the policy is usually written into the logic code of the client, and the writing mode is hard coding (hardcode). When the data changes, the modification of the data is not facilitated, and the quality of the program is reduced. Because the code has strictly stipulated the policy type that the client component can subscribe to, the mapping relation between the policy and the component is not easy to expand, the flexibility is poor, and the maintenance is difficult. In the embodiment of the application, the mapping relationship established between the policy and the client is configured, adjusted and maintained by the management terminal, and the adjustment on the mapping relationship can be embodied in the mapping relationship stored by the server terminal, so that the client is not required to make hard coding on the mapping relationship. Thus, the flexibility of strategy synchronization is improved.

The operations performed by the first device 101 and the second device 102 in the policy information synchronization process have been described in detail in the method embodiment section, so that the functions of the first device 101 and the second device 102 in the policy information synchronization system 100 can refer to the description in the method embodiment, and are not described in detail in this section.

The embodiment of the present application further provides a computer device, and the computer device provided in the embodiment of the present application will be described below from the perspective of hardware materialization. This device may be understood as the aforementioned second device.

Fig. 12 is a schematic diagram of a server 900 according to an embodiment of the present application, where the server 900 may have a relatively large difference due to different configurations or performances, and may include one or more Central Processing Units (CPUs) 922 (e.g., one or more processors) and a memory 932, and one or more storage media 930 (e.g., one or more mass storages) for storing applications 942 or data 944. Memory 932 and storage media 930 can be, among other things, transient storage or persistent storage. The program stored on the storage medium 930 may include one or more modules (not shown), each of which may include a series of instruction operations on a server. Still further, a central processor 922 may be provided in communication with the storage medium 930 to execute a series of instruction operations in the storage medium 930 on the server 900.

The server 900 may also include one or more power supplies 926, one or more wired or wireless network interfaces 950, one or more input-output interfaces 958, and/or one or more operating systems 941, such as Windows ServerTM, mac OS XTM, unixTM, linuxTM, freeBSDTM, etc.

The steps performed by the server in the above embodiment may be based on the server structure shown in fig. 12.

The CPU 922 is configured to execute the following steps:

and providing a response message to the first equipment according to the pull request of the first equipment to the target policy, so that the first equipment determines the relevant information of the target policy according to the response message.

The embodiment of the present application further provides another policy information synchronization device (which is understood as the aforementioned first device), as shown in fig. 13, for convenience of description, only the portion related to the embodiment of the present application is shown, and details of the specific technology are not disclosed, please refer to the method portion of the embodiment of the present application. The terminal may be any terminal including a mobile phone, a tablet computer, a Personal Digital Assistant (PDA, abbreviated as "Personal Digital Assistant"), a Sales terminal (POS, abbreviated as "Point of Sales"), a vehicle-mounted computer, etc., taking the terminal as a mobile phone as an example:

fig. 13 is a block diagram illustrating a partial structure of a mobile phone related to a terminal provided in an embodiment of the present application. Referring to fig. 13, the handset includes: radio Frequency (RF) circuit 1010, memory 1020, input unit 1030, display unit 1040, sensor 1050, audio circuit 1060, wireless fidelity (WiFi) module 1070, processor 1080, and power source 1090. Those skilled in the art will appreciate that the handset configuration shown in fig. 13 is not intended to be limiting and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.

The following specifically describes each component of the mobile phone with reference to fig. 13:

RF circuit 1010 may be used for receiving and transmitting signals during information transmission and reception or during a call, and in particular, for processing downlink information of a base station after receiving the downlink information to processor 1080; in addition, data for designing uplink is transmitted to the base station. In general, RF circuit 1010 includes, but is not limited to, an antenna, at least one Amplifier, a transceiver, a coupler, a Low Noise Amplifier (Low Noise Amplifier, LNA), a duplexer, and the like. In addition, the RF circuitry 1010 may communicate with networks and others via wireless communications. The wireless communication may use any communication standard or protocol, including but not limited to Global System for Mobile communications (GSM), general Packet Radio Service (GPRS), code Division Multiple Access (CDMA), wideband Code Division Multiple Access (WCDMA), long Term Evolution (LTE), e-mail, short message Service (Short SMS), and so on.

The memory 1020 may be used to store software programs and modules, and the processor 1080 executes various functional applications and data processing of the mobile phone by operating the software programs and modules stored in the memory 1020. The memory 1020 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the cellular phone, and the like. Further, the memory 1020 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.

The input unit 1030 may be used to receive input numeric or character information and generate key signal inputs related to user settings and function control of the cellular phone. Specifically, the input unit 1030 may include a touch panel 1031 and other inputs 1032. The touch panel 1031, also called a touch screen, may collect a touch operation performed by a user on or near the touch panel 1031 (e.g., an operation performed by a user on or near the touch panel 1031 using any suitable object or accessory such as a finger, a stylus, etc.) and drive the corresponding connection device according to a predetermined program. Optionally, the touch panel 1031 may include two parts, namely a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, and sends the touch point coordinates to the processor 1080, and can receive and execute commands sent by the processor 1080. In addition, the touch panel 1031 may be implemented by various types such as a resistive type, a capacitive type, an infrared ray, and a surface acoustic wave. The input unit 1030 may include other inputs 1032 in addition to the touch panel 1031. In particular, other inputs 1032 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a track ball, a mouse, a joystick, etc.

The display unit 1040 may be used to display information input by a user or information provided to the user and various menus of the cellular phone. The Display unit 1040 may include a Display panel 1041, and optionally, the Display panel 1041 may be configured by a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like. Further, the touch panel 1031 can cover the display panel 1041, and when the touch panel 1031 detects a touch operation on or near the touch panel 1031, the touch operation is transmitted to the processor 1080 to determine the type of the touch event, and then the processor 1080 provides a corresponding visual output on the display panel 1041 according to the type of the touch event. Although in fig. 13, the touch panel 1031 and the display panel 1041 are two separate components to implement the input and output functions of the mobile phone, in some embodiments, the touch panel 1031 and the display panel 1041 may be integrated to implement the input and output functions of the mobile phone.

The cell phone may also include at least one sensor 1050, such as a light sensor, motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 1041 according to the brightness of ambient light, and the proximity sensor may turn off the display panel 1041 and/or the backlight when the mobile phone moves to the ear. As one of the motion sensors, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally three axes), detect the magnitude and direction of gravity when stationary, and can be used for applications of recognizing gestures of a mobile phone (such as horizontal and vertical screen switching, related games, magnetometer gesture calibration), vibration recognition related functions (such as pedometers and taps), and the like; as for other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, and an infrared sensor, which can be configured on the mobile phone, further description is omitted here.

Audio circuitry 1060, speaker 1061, microphone 1062 may provide an audio interface between the user and the handset. The audio circuit 1060 can transmit the electrical signal converted from the received audio data to the speaker 1061, and the electrical signal is converted into a sound signal by the speaker 1061 and output; on the other hand, the microphone 1062 converts the collected sound signal into an electrical signal, which is received by the audio circuit 1060 and converted into audio data, which is then processed by the audio data output processor 1080 and then sent to, for example, another cellular phone via the RF circuit 1010, or output to the memory 1020 for further processing.

WiFi belongs to short-distance wireless transmission technology, and the mobile phone can help the user to receive and send e-mail, browse web page and access streaming media etc. through WiFi module 1070, it provides wireless broadband internet access for the user. Although fig. 13 shows the WiFi module 1070, it is understood that it does not belong to the essential constitution of the handset, and may be omitted entirely as needed within the scope not changing the essence of the invention.

The processor 1080 is a control center of the mobile phone, connects various parts of the whole mobile phone by using various interfaces and lines, and performs various functions of the mobile phone and processes data by operating or executing software programs and/or modules stored in the memory 1020 and calling data stored in the memory 1020, thereby integrally monitoring the mobile phone. Optionally, processor 1080 may include one or more processing units; preferably, the processor 1080 may integrate an application processor, which handles primarily the operating system, user interfaces, applications, etc., and a modem processor, which handles primarily the wireless communications. It is to be appreciated that the modem processor described above may not be integrated into processor 1080.

The handset also includes a power source 1090 (e.g., a battery) for powering the various components, which may preferably be logically coupled to the processor 1080 via a power management system to manage charging, discharging, and power consumption via the power management system.

Although not shown, the mobile phone may further include a camera, a bluetooth module, etc., which will not be described herein.

In the embodiment of the present application, the processor 1080 included in the terminal further has the following functions:

requesting to pull related information of a target strategy from second equipment according to a pull request of a component to be synchronized on the target strategy;

receiving a response message of the second device to the pull request;

sending the first ciphertext to the component to be synchronized;

The embodiment of the present application further provides a computer-readable storage medium, configured to store a program code, where the program code is configured to execute any one implementation of the policy information synchronization method described in the foregoing embodiments.

The present application further provides a computer program product including instructions, which when run on a computer, causes the computer to execute any one of the implementation manners of the policy information synchronization method described in the foregoing embodiments.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one type of logical functional division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer (which may be a personal computer, a server, or a network) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: a U disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions in the embodiments of the present application.

Claims

1. A strategy information synchronization method is characterized in that the strategy information synchronization method is applied to first equipment, and the first equipment and second equipment are respectively provided with a client and a server of a target software version; the method comprises the following steps:

according to a pulling request of a component to be synchronized to a target strategy, requesting a second device to pull related information of the target strategy;

receiving a response message of the second device to the pull request;

sending the first ciphertext to the component to be synchronized;

2. The method of claim 1, wherein a target software version the first device holds a public key of the target software version, wherein the second device holds a private key of the target software version, and wherein the method further comprises:

generating a random number;

encrypting the random number by using a second secret key to obtain a second ciphertext of the random number; the second key is a key generated according to the dynamic characteristic information and the static characteristic information of the first equipment;

sending a second ciphertext of the random number to the component to be synchronized;

decrypting a second ciphertext of the random number by the component to be synchronized through the second key to obtain the random number;

receiving a third ciphertext of the random number formed by encrypting the random number by the component to be synchronized through the public key;

when the request for pulling the relevant information of the target policy is sent to the second device, the method further includes:

sending the third ciphertext of the random number and the random number to the second device together, so that the second device decrypts the third ciphertext of the random number by using the private key and then performs security check on the first device based on the consistency of the decryption results of the random number and the third ciphertext; the response message is specifically sent to the first device after the security check of the second device on the first device is passed.

3. The method of claim 2, further comprising:

and generating the first key according to the dynamic characteristic information and the static characteristic information of the first device and the random number.

4. The method according to claim 1, wherein the requesting, from a second device, related information of a target policy according to a pull request of a component to be synchronized to the target policy includes:

when the target policy is determined to be contained in the stored policy according to the pull request and the stored policy of the first device, requesting the second device to check the update condition of the relevant information of the target policy in the second device; when the relevant information of the target strategy is updated in the second equipment, requesting the updated relevant information of the target strategy from the second equipment;

and when the target strategy is determined not to be contained in the stored strategy according to the pulling request and the stored strategy of the first equipment, requesting the second equipment to pull the relevant information of the target strategy.

5. The method according to claim 4, wherein before the request for pulling the relevant information of the target policy from the second device according to the request for pulling the target policy by the component to be synchronized, the method further comprises:

pulling a component hash list from the second device, the component hash list comprising hash values corresponding to client components associated with the target software version;

obtaining a hash value corresponding to the component to be synchronized;

when the hash value corresponding to the component to be synchronized is in the component hash list, determining that the component to be synchronized is a client component associated with the target software version;

and when the component to be synchronized is determined to be the client component associated with the target software version, allowing the pull request to be received.

6. The method of claim 5, wherein the server of the second device comprises a mapping of a client component associated with the target software version to a policy; the mapping relationship is adjustable in the server of the second device; when the request for pulling the information related to the target policy is sent to the second device, the method further includes:

sending the identification of the component to be synchronized to the second device; the identifier of the component to be synchronized is used for the second device to judge whether the pull request conforms to the mapping relation;

when the pull request conforms to the mapping relationship, determining relevant information of the target policy according to the response message, including:

for the target policy contained in the stored policy, when the response message indicates that the related information of the target policy is not updated in the second device, using the information matched with the target policy in the stored policy as the related information of the target policy; when the response message indicates that the relevant information of the target policy is updated in the second device, using the information matched with the target policy in the response message as the relevant information of the target policy;

and for the target strategy which is not contained in the stored strategies, taking the information matched with the target strategy in the response message as the relevant information of the target strategy.

7. The method of claim 6, further comprising:

when the pull request does not accord with the mapping relation, if the target strategy exists in the second equipment, clearing the target strategy from the execution scope of the component to be synchronized according to the indication of the response message; if the target policy does not exist in the second device, clearing the target policy from the execution scope of the component to be synchronized according to the indication of the response message, and clearing the target policy in the memory of the first device.

8. The method of claim 4, further comprising:

pulling an initial full-scale policy to the second device;

encrypting the initial full-scale strategy by using a second key; the second key is a key generated according to the dynamic characteristic information and the static characteristic information of the first equipment;

and caching the ciphertext of the initial full-scale strategy in a memory of the first device, and taking the strategy cached in the memory as the stored strategy of the first device.

9. The method of claim 5, further comprising:

encrypting the component hash list using a second key; the second key is a key generated according to the dynamic characteristic information and the static characteristic information of the first equipment;

and caching the ciphertext of the component hash list in a memory of the first device.

10. The method of claim 5, further comprising:

performing directory verification on the component to be synchronized by using the installation directory of the client, and determining that the directory verification on the component to be synchronized passes when the process path of the component to be synchronized is in the installation directory;

carrying out signature verification on the component to be synchronized by using a preset signature verification condition, and determining that the signature verification of the component to be synchronized passes when the signature of the component to be synchronized meets the preset signature verification condition;

when the component to be synchronized is determined to be the client component associated with the target software version, allowing to receive the pull request includes:

and when the component to be synchronized is determined to be the client component associated with the target software version and the directory check and the signature check of the component to be synchronized pass, allowing the pull request to be received.

11. The method of claim 2, further comprising:

checking the pull request to prevent replay attack;

said step of generating a random number is performed when said pull request checks through said verification against replay attack.

12. The method of claim 3, wherein the generating the first key according to the dynamic feature information and the static feature information of the first device and the random number comprises:

generating a white-box key based on a white-box cryptographic technique; the white-box key is associated with the target software version;

and generating the first key according to the white-box key, the dynamic characteristic information and the static characteristic information of the first device and the random number.

13. A policy information synchronization system, comprising: a first device and a second device; the first device and the second device are respectively provided with a client and a server of a target software version;

the second device is configured to send a response message to the first device according to the request of the first device;

the first device is further configured to determine, according to the response message, related information of the target policy, and encrypt the related information of the target policy with a first key to obtain a first ciphertext; sending the first ciphertext to the component to be synchronized; decrypting the first ciphertext through the to-be-synchronized component by using the first key to obtain the relevant information of the target strategy for synchronizing the to-be-synchronized component; the first key is a key generated according to the dynamic characteristic information and the static characteristic information of the first device.

14. A computer, comprising a processor and a memory:

the memory is used for storing program codes and transmitting the program codes to the processor;

the processor is configured to execute the policy information synchronization method of any one of claims 1-12 according to instructions in the program code.

15. A computer-readable storage medium for storing program code for performing the policy information synchronization method of any one of claims 1-12.