CN117155716B

CN117155716B - Access verification method and device, storage medium and electronic equipment

Info

Publication number: CN117155716B
Application number: CN202311427543.7A
Authority: CN
Inventors: 吴岳廷
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2023-10-31
Filing date: 2023-10-31
Publication date: 2024-02-09
Anticipated expiration: 2043-10-31
Also published as: CN117155716A

Abstract

The application discloses an access verification method and device, a storage medium and electronic equipment. The method comprises the following steps: acquiring an access request for requesting access to a target application site; determining a first access policy cached by a collaborative system client logged in using a target user account; when the first access policy indicates that the target user account is allowed to access the target application site and the first access policy meets the periodic verification condition, generating an access ticket application request matched with the access request by utilizing the policy characteristics of the first access policy, and sending the access ticket application request to the collaborative system server; receiving an access bill verification result returned by the collaborative system server; and accessing the target application site according to the access ticket verification result. The method and the device solve the technical problem that the difficulty of verification operation is increased due to the fact that the access strategy is influenced by each factor associated with the terminal equipment where the client is located, so that the accuracy of access verification is reduced.

Description

Access verification method and device, storage medium and electronic equipment

Technical Field

The present invention relates to the field of computers, and in particular, to an access verification method and apparatus, a storage medium, and an electronic device.

Background

Collaborative office systems are now widely popular in the office environment of various enterprises, but collaborative office systems are often subject to various malicious attacks by attackers. For example, an attacker may try to tamper with the access policy written locally in the terminal device where the system is located, and then cooperate with the reverse analysis of the components in the terminal to find the available access security weakness in the system. Furthermore, an attacker can forge an access ticket for accessing the system by using the tampered access strategy and the obtained key data so as to bypass access security verification configured in the system, thereby realizing unauthorized illegal access to enterprise resources.

To overcome the above problem, the server often changes the access policy issued to the client periodically. However, because the access policy is also affected by each factor associated with the terminal device where the client is located, when the server performs security verification on whether the access policy is tampered maliciously, the operation difficulty is greatly increased, so that misjudgment occurs on the verification result, and the problem of reduced accuracy of access verification is caused.

In view of the above problems, no effective solution has been proposed at present.

Disclosure of Invention

The embodiment of the application provides an access verification method and device, a storage medium and electronic equipment, which are used for at least solving the technical problem that the difficulty of verification operation is increased and the accuracy of access verification is reduced because an access strategy is influenced by each factor associated with terminal equipment where a client is located.

According to an aspect of the embodiments of the present application, there is provided an access verification method, including: acquiring an access request for requesting access to a target application site; responding to the access request, determining a first access strategy cached by a collaborative system client logged in by using a target user account, wherein the first access strategy is received from a collaborative system server corresponding to the collaborative system client, encrypted and stored in a memory; when the first access policy indicates that the target user account is allowed to access the target application site and the first access policy meets a periodic verification condition, generating an access ticket application request matched with the access request by using policy characteristics of the first access policy, and sending the access ticket application request to the collaborative system server; receiving an access ticket checking result returned by the collaborative system server, wherein the access ticket checking result is obtained by the collaborative system server after checking the first access policy indicated by the access ticket application request by using a locally stored second access policy; and accessing the target application site according to the access ticket verification result.

According to another aspect of the embodiments of the present application, there is also provided an access verification apparatus, including: a first acquisition unit configured to acquire an access request for requesting access to a target application site; the first determining unit is used for determining a first access policy cached by a collaborative system client logged in by using a target user account in response to the access request, wherein the first access policy is an access policy received from a collaborative system server corresponding to the collaborative system client, is encrypted and then is stored in a memory; a verification unit, configured to generate an access ticket application request matched with the access request by using a policy feature of the first access policy, and send the access ticket application request to the collaboration system server, where the first access policy indicates that the target user account is allowed to access the target application site, and the first access policy meets a periodic verification condition; the receiving unit is used for receiving an access ticket checking result returned by the collaborative system server, wherein the access ticket checking result is obtained by the collaborative system server after checking the first access policy indicated by the access ticket application request by using a locally stored second access policy; and the access unit is used for accessing the target application site according to the access ticket verification result.

According to yet another aspect of the embodiments of the present application, there is also provided a computer readable storage medium having a computer program stored therein, wherein the computer program is configured to perform the above-described access verification method when run.

According to yet another aspect of embodiments of the present application, there is provided a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the access verification method as above.

According to still another aspect of the embodiments of the present application, there is also provided an electronic device including a memory, in which a computer program is stored, and a processor configured to execute the above-described access verification method by the above-described computer program.

In the embodiment of the application, an access request for requesting access to a target application site is acquired. And then, in response to the access request, determining a first access policy cached by the collaborative system client logged in by using the target user account, wherein the first access policy is an access policy received from a collaborative system server corresponding to the collaborative system client, and is stored in a memory after being encrypted. And further, under the condition that the first access policy indicates that the target user account is allowed to access the target application site and the first access policy meets the periodic verification condition, generating an access ticket application request matched with the access request by utilizing the policy characteristics of the first access policy, and sending the access ticket application request to the collaborative system server. And then, receiving an access ticket checking result returned by the collaborative system server, wherein the access ticket checking result is obtained after the collaborative system server checks the first access policy indicated by the access ticket application request by utilizing the locally stored second access policy. Thus, the target application site is accessed according to the access ticket verification result. In other words, by adopting the embodiment of the application and adopting the collaborative system client and the collaborative system server, the method of performing secondary authentication on the first access policy cached by the collaborative system client logged in by the target user account solves the technical problem that the difficulty of verification operation is increased and the accuracy of access verification is reduced because the access policy is influenced by each factor associated with the terminal equipment where the client is located. The technical effects of reducing the difficulty of access verification and improving the accuracy of the access verification are achieved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute an undue limitation to the application. In the drawings:

FIG. 1 is a network architecture diagram of an alternative access verification method according to an embodiment of the present application;

FIG. 2 is a schematic diagram of an alternative access verification method according to an embodiment of the present application;

FIG. 3 is a flow chart of an alternative access verification method according to an embodiment of the present application;

FIG. 4 is a schematic diagram of an alternative access verification method according to an embodiment of the present application;

FIG. 5 is a schematic diagram of an alternative access verification method according to an embodiment of the present application;

FIG. 6 is a schematic diagram of an alternative access verification method according to an embodiment of the present application;

FIG. 7 is a schematic diagram of an alternative access verification method according to an embodiment of the present application;

FIG. 8 is a flow chart of an alternative access verification method according to an embodiment of the present application;

FIG. 9 is a flow chart of an alternative access verification method according to an embodiment of the present application;

FIG. 10 is a schematic diagram of an alternative access verification device according to an embodiment of the present application;

Fig. 11 is a schematic structural view of an alternative electronic device according to an embodiment of the present application.

Detailed Description

In order to make the present application solution better understood by those skilled in the art, the following description will be made in detail and with reference to the accompanying drawings in the embodiments of the present application, it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, shall fall within the scope of the present application.

It should be noted that the terms "first," "second," and the like in the description and claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that embodiments of the present application described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

It should be further noted that, in the description and claims of the present application and the related data collection processing in the foregoing drawings, the informed consent or the individual consent of the personal information body should be obtained strictly according to the requirements of the relevant national laws and regulations when the examples are applied, and the subsequent data use and processing actions are performed within the authorized scope of the laws and regulations and the personal information body.

According to an aspect of the embodiments of the present application, there is provided an access verification method, optionally, as an optional implementation manner, the access verification method may be applied, but not limited to, in a network architecture as shown in fig. 1. As shown in fig. 1, the above access verification method may include the following steps: s102, sending a request; s104, requesting authentication; s106, sending the process characteristics, namely sending the process characteristics to the access subject by the cooperative system client; s108, sending an access ticket application request; s110, process inspection (namely, the cooperative system client sends a process check request to the cooperative system server); s112, authentication response (namely, the cooperative system client sends an authentication result to the access agent); s114, forwarding the bill request; s116, bill verification request; s118, sending a verification result; s120, forwarding an access request; s122, sending the service resource (namely, the service server sends the service resource to the intelligent gateway); s124, sending the business resource (namely, the intelligent gateway sends the business resource to the access agency); s126, the service resource is sent (i.e., the access agent sends the service resource to the access agent).

Further, as shown in fig. 2, the detailed execution steps corresponding to the access verification method may include:

to facilitate understanding of the present embodiment, a description is first given of a main body included in a network architecture: 1) The collaboration system client 202 may be, but is not limited to, installed in a terminal device used on the user side, and is used to verify the credibility of the user side, that is, send a process requested by the user side to the server side to apply for process verification. 2) An access agent 204 for hijacking device traffic through the TUN/TAP virtual network card. 3) The collaboration system server 206 is configured to perform security scheduling on the traffic by using the access policy control engine, and perform granularity authorization according to the user side-device side-software side-application. Wherein, still include in the collaborative system server: an identity verification module, a device trusted module and an application detection module. Specifically, the identity verification module is used for verifying the identity of the user side; the equipment trusted module is used for verifying equipment hardware information and equipment security state; the application detection module is used for detecting whether the application process is safe, such as whether a loophole, a virus Trojan horse and the like exist. The collaborative system server periodically initiates file censoring to the threat information cloud checking service, and if a malicious process is identified, the collaborative system client is informed to execute asynchronous blocking operation. 4) Intelligent gateway 208 may be, but is not limited to, deployed at the portal of enterprise applications and data resources for verifying, authorizing, and forwarding each session request to access the enterprise resources. 5) Business server 210 is used to store enterprise applications and data resources. 6) An access principal 212 for indicating a party in the network that initiated the access, e.g., a requestor that accessed a resource within the enterprise. Is a digital entity formed by any element of a user side, a device side and an application side, or by the combination of the user side, the device side and the application side.

In step S202, (corresponding to "S102, send request") the access agent 212 sends an access request sent by the target user account to the access proxy 204 for requesting access to the target application site.

In step S204, (corresponding to "S104 in fig. 1, request authentication") the access agent 204, upon receiving the access request, sends an authentication request corresponding to the access request to the collaborative system client 202.

Specifically, the access proxy 204 applies the access credentials of the current network request to the collaborative system client 202. The request parameters include source access IP (or domain name), source port, destination IP (or domain name), destination port, and process PID corresponding to the session original application process.

In step S206, the collaborative system client 202 determines, when receiving the authentication request, a first access policy cached by the collaborative system client logged in using the target user account, where the first access policy is an access policy received from a collaborative system server corresponding to the collaborative system client, and is stored in the memory after being encrypted.

In step S208, (corresponding to "S108 in fig. 1, send access ticket application request") the collaborative system client 202 generates an access ticket application request matched with the access request by using the policy feature of the first access policy when the first access policy indicates that the target user account is allowed to access the target application site and the first access policy satisfies the periodic verification condition, and sends the access ticket application request to the collaborative system server 206 based on the request parameters (i.e., the original application process PID, the hash of the application process, the process path, the latest modification time of the application process executable file, the copyright information, the digital signature information, and other application feature information of the application process, along with the source IP or domain name, the source port, the destination IP or domain name, the destination port, and other parameters of the network request in the request parameters.

In step S210, the collaboration system server 206 compares the policy features of the first access policy with the policy features of the second access policy to obtain a comparison result.

In step S212, the collaboration system server 206 obtains an authorized access ticket corresponding to the access request when the comparison result indicates that the first access policy matches the second access policy.

In step S214, the collaboration system server 206 generates an access ticket verification result for indicating that the access request passes the access verification by using the authorized access ticket, where the access ticket verification result includes: access ticket, and maximum number of uses and validity time of access ticket.

In step S216, the collaboration system server 206 transmits the access ticket verification result to the access agent 204.

In step S218, (corresponding to "S114 in FIG. 1, ticket request forwarding") the access proxy 204 will send an HTTPS network request to the intelligent gateway 208, with the access ticket check result carried in the authorization header field of the network request.

In step S220, the intelligent gateway 208 analyzes the network request to obtain the access ticket checking result when receiving the network request.

In step S222, (corresponding to "S116, ticket verification request" in FIG. 1) intelligent gateway 208 sends a verification request carrying access ticket verification results to collaboration system server 206.

In step S224, (corresponding to "S118 in FIG. 1, send check result") in the case where the collaboration system server 206 has successfully checked the access ticket check result, a check result indicating that the check was successful is sent to the intelligent gateway 208.

In step S226, the intelligent gateway 208 establishes a network connection with the access agent 204 upon receiving a check result indicating that the check is successful.

In step S228, the intelligent gateway 208 transmits a notification message indicating that the network connection establishment is successful to the access agent 204.

In step S230, (corresponding to "S120 in fig. 1, forwarding the access request") the access request is sent to the service server 210 through the intelligent gateway 208 in case the access proxy 204 receives a notification message indicating that the network connection establishment was successful.

In step S232, (corresponding to "S122, send service resource", "S124, send service resource", "S126, send service resource") in fig. 1), when the service server 210 receives the access request, the target application site is determined according to the access request, and the service resource in the target application site requested by the target user account is determined, so that the service resource is sent to the access agent 212 through the intelligent gateway 208 and the access proxy 204.

Alternatively, in the present embodiment, the terminal device involved may be a terminal device configured with a target client, and may include, but is not limited to, at least one of the following: a mobile phone (e.g., an Android mobile phone, iOS mobile phone, etc.), a notebook computer, a tablet computer, a palm computer, a MID (Mobile Internet Devices, mobile internet device), a PAD, a desktop computer, a smart television, etc. The target client may be a video client, an instant messaging client, a browser client, an educational client, and the like. The network may include, but is not limited to: a wired network, a wireless network, wherein the wired network comprises: local area networks, metropolitan area networks, and wide area networks, the wireless network comprising: bluetooth, WIFI, and other networks that enable wireless communications. The related server can be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, and can also be a cloud server for providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, basic cloud computing services such as big data and artificial intelligent platforms and the like. The terminal may be, but is not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, etc. The terminal and the server may be directly or indirectly connected through wired or wireless communication, which is not limited herein.

Optionally, as an alternative, as shown in fig. 3, the above access verification method includes:

s302, an access request for requesting access to a target application site is acquired.

It should be noted that the above access verification method may be applied, but not limited to, in an access verification scenario in which after a user account logs in a collaboration system client, resources inside any unit such as an enterprise and an organization that the collaboration system client is docked with are accessed. For example, after the user account logs in the collaborative system client, the collaborative system client requests to access the access verification scene of the resource corresponding to the application site in the enterprise.

It should be noted that, before the above-mentioned access request for requesting to access the target application site is obtained, the above-mentioned method may, but is not limited to, further include: responding to a login request for indicating a target user account to login to a collaborative system client, and checking the target user account carried in the login request and an account password corresponding to the target user account; allowing the target user account to log in the collaborative system client under the condition that the verification is passed; and after the target user account logs in the collaborative system client, acquiring a target access policy matched with the target user account from the collaborative system server. Wherein, after the target user account logs in to the collaborative system client, as shown in fig. 4, prompt information for prompting that the internal resource can be accessed through the collaborative system client is displayed in the collaborative system client (i.e., "welcome login collaborative system client | you can access the internal resource through the collaborative system client |").

Optionally, in this embodiment, before the above-mentioned obtaining the access request for requesting to access the target application site, the above-mentioned method may, but is not limited to, further include: establishing secure socket layer protocol (Secure Socket Layer, abbreviated as SSL) or transport layer security protocol (Transport Layer Security, abbreviated as TLS) bidirectional authentication between a collaborative system client and a collaborative system server; under the condition that the cooperative system client and the cooperative system server pass SSL or TLS mutual authentication respectively, the communication channel between the cooperative system client and the cooperative system server is determined to be opened.

Further, it is assumed that the above access verification method is applied to an access verification scenario in which after a user account logs in a collaborative system client, resources inside any unit such as an enterprise and an organization that the collaborative system client is docked with are accessed. The target application site may be, but is not limited to, a network site for indicating an internal resource of any entity of an enterprise, an organization, etc. that is interfaced with the collaboration system client, where the network site includes any entity of the enterprise, the organization, etc.

S304, responding to the access request, determining a first access strategy cached by the collaborative system client logged in by using the target user account, wherein the first access strategy is the access strategy received from the collaborative system server corresponding to the collaborative system client, and the access strategy is stored in the memory after being encrypted.

In this embodiment, the first access policy may include, but is not limited to, any key information such as an application site within a unit to which the target user account has access, an internal resource within the unit to which the target user account has access, an age of the application site and the internal resource within the unit to which the target user account has access, and the number of times the application site and the internal resource within the unit may be accessed. In this embodiment, the structure of the first access policy is not limited in any way, and the specific structure may be flexibly configured by the management side.

Alternatively, the access policy may be configured in the specified policy configuration platform in this embodiment, but is not limited to. The policy terms may include, but are not limited to, a trusted application, a specified user account group (which may be a single user account or a single group formed by multiple user accounts, or a large group formed by multiple single groups), a correspondence between an accessible resource group (which may be a single enterprise resource or a set of multiple enterprise resources), and a constraint condition for rule validation (i.e., an execution condition of a specified policy, including dynamic factors such as a network area limitation, a terminal environment state, a security level, access time and frequency of the user account, and the like). The access policy may be newly added to the policy homepage as shown in fig. 5 (a) in the policy configuration platform. Specifically, in the case where the add access policy control as shown in (a) of fig. 5 is touched, a newly added access policy configuration interface as shown in (b) of fig. 5 is displayed, and thus policy formulation is achieved by combining three elements of user account, application and resource. In addition, in the configuration process of the policy, a designated dynamic factor, such as a designated network location or network location switch, is also configured. And the method can also set the access permission of the appointed service system to the appointed user account group, and forbid or verify the access permission.

Further, the first access policy may be, but not limited to, stored in the memory of the collaborative system client after being encrypted by using key information matched with the terminal device where the collaborative system client is located. The key information may include, but is not limited to: the method comprises the steps of enabling a collaborative system client to be in a collaborative system, and enabling a target user account to be in a collaborative system client. In this embodiment, the encrypted first access policy is stored in the memory. The problem that the access strategy is tampered due to the fact that the access strategy is stored in the local storage space is avoided, and therefore accuracy of access verification is improved.

S306, when the first access policy indicates that the target user account is allowed to access the target application site and the first access policy meets the periodic verification condition, generating an access ticket application request matched with the access request by utilizing the policy characteristics of the first access policy, and sending the access ticket application request to the collaborative system server.

It should be noted that, in this embodiment, the policy feature of the first access policy may, but is not limited to, uniquely identify the first access policy. Specifically, the policy features described above may include, but are not limited to: the information such as the policy ID of the first access policy, the policy version of the first access policy, the update time of the first access policy, the content hash value of the first access policy, and the like.

Alternatively, in this embodiment, the above-mentioned periodic verification condition may be, but is not limited to, used to indicate that the historical access request initiated by the target user account is not received at a predetermined time interval. Specifically, the collaboration system server issues a periodic verification condition to the collaboration system client in advance, and after receiving a current access request initiated by a current user account, the collaboration system client is instructed to acquire time t1 when the current user account initiates the current access request and time t0 when the current user account initiates the access request last time. Further, a time interval between t0 and t1 is determined, and in the case that the time interval is greater than a predetermined time interval, it is determined that the first access policy satisfies the periodic check condition. In the event that the time interval is less than the predetermined time interval, it is determined that the first access policy does not satisfy the periodic verification condition.

It should be noted that, after determining, in response to the access request, the first access policy cached by the collaboration system client logged in using the target user account, and when the first access policy indicates that the target user account is allowed to access the target application site and the first access policy does not meet the periodic verification condition, an access ticket application request matched with the access request is generated, and the access ticket application request is sent to the collaboration system server, where the access ticket application request does not include a policy feature of the first access policy. Then, after cooperating with the system server, the present access request is allowed by default.

Further, the above-mentioned periodic verification condition may also be used to indicate that the first access policy is greater than the target threshold value from a time interval during which the policy update was last passively performed. Specifically, after determining a first access policy cached by a collaborative system client logged in by using a target user account, acquiring a time interval from a last passive execution policy update of the first access policy cached currently; and under the condition that the time interval is larger than the target threshold value, determining that the first access strategy meets the periodic verification condition.

Optionally, after the sending the access ticket application request to the collaboration system server, the method further includes: the collaboration system server compares the policy features of the first access policy with the policy features of the second access policy to obtain a comparison result; under the condition that the comparison result indicates that the first access strategy is matched with the second access strategy, the collaborative system server acquires an authorized access ticket corresponding to the access request; the collaboration system server will generate an access ticket check result using the authorized access ticket to indicate that the access request passes the access check.

S308, receiving an access ticket checking result returned by the collaborative system server, wherein the access ticket checking result is obtained after the collaborative system server checks the first access policy indicated by the access ticket application request by using the locally stored second access policy.

It should be noted that the above-mentioned authorized access ticket may be used for indicating an access ticket, but is not limited to the above. Specifically, in the case where the current number of times of use of the authorized access ticket does not reach the maximum number of times of use, and the authorized access ticket is still within the valid use time, the target user account number may legally access the target application site based on the authorized access ticket. Further, the above access ticket verification result may include, but is not limited to: the contents such as the authorized access ticket, the maximum number of times the authorized access ticket is used, the effective time of the authorized access ticket, and the like.

Optionally, in this embodiment, the second access policy may be, but is not limited to, an access policy corresponding to a target user account that is used to instruct the collaboration system server to store locally. In other words, since the first access policy is distributed to the collaborative system client by the collaborative system server, the first access policy should be completely consistent with the second access policy in case the first access policy is not tampered with.

And S310, accessing the target application site according to the access ticket verification result.

Alternatively, as an optional implementation manner, it is assumed that the above-mentioned access verification method may be applied, but not limited to, in an access verification scenario where a user account accesses a resource inside an enterprise a after logging into a collaboration system client, where the following steps as shown in fig. 6 are used to illustrate the above-mentioned method:

Steps S602-S606 are performed, and the collaborative system client 602 obtains an access request for requesting access to the web site 606 inside the enterprise a. The collaborative system client 602 determines, in response to the access request, a first access policy cached by the collaborative system client logged in using the target user account, where the first access policy is an access policy received from a collaborative system server corresponding to the collaborative system client, and is stored in the memory after being encrypted. The collaboration system client 602 generates an access ticket application request carrying information such as a policy ID of the first access policy, a policy version of the first access policy, an update time of the first access policy, a content hash value of the first access policy, and the like, in a case where the first access policy indicates that the target user account is allowed to access the network site 606 and the first access policy satisfies the periodic verification condition.

Next, step S608 is executed, and the cooperative system client 602 transmits an access ticket application request to the cooperative system server 604.

Further, steps S610 to S612 are executed, and when the collaboration system server 604 receives the request for application of the access ticket, the policy features of the first access policy and the policy features of the second access policy are compared, so as to obtain a comparison result. And then under the condition that the comparison result indicates that the first access strategy is matched with the second access strategy, the collaborative system server acquires an authorized access ticket corresponding to the access request. Thereby generating an access ticket verification result indicating that the access request passes the access verification using the authorized access ticket. The collaboration system server 604 sends the access ticket verification results to the collaboration system client 602.

Steps S614-S616 are then performed, and the collaboration system client 602 sends an access request carrying the access ticket verification result to the network site 606. Upon receiving the access request with the access ticket verification result, the network site 606 sends the internal resources related to enterprise a included in the network site to the collaboration system client 602 after parsing out the access ticket verification result in the access request.

Optionally, as an alternative, determining, in response to the access request, the first access policy cached by the collaboration system client logged in using the target user account includes:

s1, responding to an access request, and searching a first access strategy matched with a target user account in a storage space corresponding to a collaborative system client in a memory;

optionally, the searching the storage space corresponding to the collaborative system client in the memory for the first access policy matching the target user account may include, but is not limited to: searching an access policy carrying the account identifier of the target user account in a storage space corresponding to the collaborative system client in a memory through the account identifier (such as the account ID) of the target user account, and determining the access policy as a first access policy.

S2, under the condition that the first access strategy is found, decrypting the first access strategy by utilizing key information matched with terminal equipment where the client of the collaborative system is located, so as to obtain strategy content and strategy characteristics of the first access strategy;

note that, the key information may include, but is not limited to: software information and hardware information of terminal equipment where the collaborative system client is located, starting time of a process corresponding to a target user account in the collaborative system client, and the like.

Optionally, the first access policy may include, but is not limited to, any key information such as an application site inside a unit to which the target user account has authority to access, an internal resource inside the unit to which the target user account has authority to access, an application site inside the unit and a time period for which the internal resource inside the unit may be accessed, and a number of times for which the internal resource inside the unit and the application site inside the unit may be accessed. In this embodiment, the structure of the first access policy is not limited in any way, and the specific structure may be flexibly configured by the management side.

Further, the policy feature of the first access policy may, but is not limited to, uniquely identify the first access policy. Specifically, the policy features described above may include, but are not limited to: the information such as the policy ID of the first access policy, the policy version of the first access policy, the update time of the first access policy, the content hash value of the first access policy, and the like.

S3, prompting to reject the access request under the condition that the first access strategy is not found.

Alternatively, the prompting refusal of access request may include, but is not limited to, displaying, in the collaboration system client, prompting information for prompting the target application site to refuse access by the target user account, e.g., sorry, you have no authority to access the target application site.

Alternatively, as an alternative embodiment, the above method is illustrated by the following steps:

as shown in fig. 7 (a), in the case where a control corresponding to a target application site in an application site list in a collaborative system client is touched, an access request corresponding to a target user account for requesting access to the target application site is obtained. And further, responding to the access request, and searching an access strategy carrying an account identifier of the target user account in a storage space corresponding to the collaborative system client in the memory.

And under the condition that the access strategy carrying the account identification of the target user account is found, determining the access strategy as a first access strategy. And decrypting the first access policy by using key information matched with the terminal equipment where the client of the collaborative system is located, so as to obtain policy content and policy characteristics of the first access policy.

In the case that the access policy with the account identifier of the target user account is not found, it is confirmed that the first access policy is not found, and then, as shown in fig. 7 (b), prompt information for prompting the target application site to refuse to be accessed by the target user account is displayed in the collaborative system client (i.e., sorry, you have no authority to access the target application site).

In the embodiment of the application, in response to an access request, a first access policy matched with a target user account is searched in a storage space corresponding to a collaborative system client in a memory. And then, under the condition of finding out the first access strategy, decrypting the first access strategy by utilizing key information matched with terminal equipment where the client of the collaborative system is located, so as to obtain strategy content and strategy characteristics of the first access strategy. Further, if the first access policy is not found, the access request is prompted to be denied. In other words, in the embodiment of the present application, the first access policy is encrypted and then stored in the memory. The problem that the access strategy is tampered due to the fact that the access strategy is stored in the local storage space is avoided, and therefore accuracy of access verification is improved.

Optionally, as an alternative, after decrypting the first access policy by using the key information corresponding to the terminal device where the client of the collaboration system is located, the method further includes:

s1, acquiring a time interval from a last passive execution strategy update of a first access strategy of a current cache;

S2, under the condition that the time interval is larger than the target threshold value, determining that the first access strategy meets the periodic verification condition.

It should be noted that, the foregoing passive execution policy update may be, but is not limited to, used to instruct, after the collaboration system client receives the updated first access policy sent by the collaboration system server, to update the first access policy stored in the memory to the updated first access policy.

As an alternative embodiment, assuming that the current time is t1, the time for which the first access policy passively performs the policy update in turn recently is t0, the method is illustrated by the following steps: and acquiring the time t0 of the last passive execution of the policy update of the first access policy of the current cache and the current t1. And further determines the time interval between t0 and t1 to be t2. Further, it is determined whether t2 is greater than a target threshold, and if t2 is greater than the target threshold, it is determined that the first access policy satisfies a periodic verification condition.

In the embodiment of the application, the first access policy is decrypted by using key information corresponding to the terminal equipment where the client of the collaborative system is located, and after policy content and policy characteristics of the first access policy are obtained, a time interval from the last passive execution of policy update of the first access policy which is currently cached is obtained. Further, in the event that the time interval is greater than the target threshold, it is determined that the first access policy satisfies the periodic verification condition. And generating an access ticket application request matched with the access request by utilizing the policy characteristics of the first access policy, and sending the access ticket application request to the collaborative system server. In other words, with the embodiment of the present application, in the case that the first access policy is not updated for a long time, the policy feature of the first access policy is sent to the collaborative system server, so that the collaborative system server determines, through the policy feature of the first access policy, whether the first access policy is tampered. Under the condition that the first access strategy is updated recently, the probability of tampering the first access strategy is smaller, and then the strategy characteristics of the first access strategy are not required to be sent to the collaborative system server, and the collaborative system server is also not required to check whether the first access strategy is tampered. Therefore, on the basis of ensuring the accuracy of the access verification, the efficiency of the access verification is greatly improved.

Optionally, as an alternative, generating the access ticket application request matched with the access request by using the policy feature of the first access policy includes:

s1, acquiring request parameters of an access request;

s2, generating an access ticket application request based on the request parameters and the policy characteristics of the first access policy.

Optionally, in this embodiment, the request parameter includes a network parameter related to the access request. Specifically, the request parameters may include, but are not limited to: the parameters of the source IP of the access request, the source domain name of the access request, the source port of the access request, the destination IP of the access request, the domain name, the destination port of the access request and the like.

In the embodiment of the application, a request parameter of an access request is obtained, and an access ticket application request is generated based on the request parameter and the policy characteristics of a first access policy. Such that the cooperating system server determines, via the policy characteristics of the first access policy, whether the first access policy has been tampered with. Thereby realizing the technical effect of improving the accuracy of access verification.

Optionally, before obtaining the access request for requesting access to the target application site, the method further includes:

S1, acquiring a target access strategy matched with a target user account from a collaborative system server;

s2, encrypting the target access strategy by utilizing key information matched with terminal equipment where the client of the collaborative system is located, so as to obtain a first access strategy;

s3, storing the first access strategy into a memory, and performing compression protection processing on the first access strategy.

Optionally, the above-mentioned obtaining, from the collaboration system server, the target access policy matching the target user account may include, but is not limited to: when a target user account logs in a collaborative system client, acquiring a target access policy matched with the target user account from a collaborative system server; or after receiving the target access policy update notification prompt information sent by the collaborative system server, acquiring a target access policy matched with the target user account from the collaborative system server. The notification prompt information is used for prompting the collaborative system server to update the target access policy, and the collaborative system client needs to acquire the latest target access policy.

Further, the encrypting the target access policy by using the key information matched with the terminal device where the client of the collaborative system is located, to obtain the first access policy may include, but is not limited to: and encrypting the target access strategy by utilizing the software information and the hardware information of the terminal equipment where the collaborative system client is currently located, the starting time of the corresponding process of the target user account in the collaborative system client and the like, so as to obtain a first access strategy.

It should be noted that, the storing the first access policy in the memory and performing the compression protection processing on the first access policy may include, but is not limited to: and storing the first access strategy into a memory, and performing a shell protection treatment on the first access strategy, wherein the shell treatment is used for indicating a program protection measure for protecting the executable program by adding an additional protection layer on the original executable program. The protection layer can encrypt, compress or confuse the codes and data of the original program so as to increase the difficulty of an attacker in analyzing program logic and mining software vulnerabilities.

In the embodiment of the application, a target access policy matched with a target user account is obtained from a collaborative system server. And then, encrypting the target access strategy by utilizing key information matched with the terminal equipment where the client of the collaborative system is located, so as to obtain a first access strategy. And storing the first access strategy into a memory, and performing compression protection processing on the first access strategy. In other words, in the embodiment of the application, by adopting the mode of storing the first access policy in the memory after being encrypted, the problem that the access policy is tampered due to the fact that the access policy is stored in the local storage space is avoided, and therefore accuracy of access verification is improved.

Optionally, after obtaining the target access policy matched with the target user account from the collaboration system server, the method further includes:

s1, determining the size of a storage space matched with a target access strategy;

s2, generating a pseudo policy file corresponding to the target access policy locally at the client of the collaborative system according to the size of the storage space, wherein the pseudo policy file is used for interfering policy modification operation of the unauthorized user account on the target access policy.

It should be noted that the pseudo policy file may include, but is not limited to: spurious information related to the target access policy (e.g., a list of spurious enterprise internal resources that the target user account may access, etc.), and non-critical enterprise resources (e.g., published enterprise resources, etc.) are issued by the collaboration system server.

As an alternative embodiment, the above method is illustrated by the following steps: and determining the occupied storage size of the file corresponding to the target access strategy. And generating fake information related to the target access policy and issuing non-critical enterprise resources by the collaborative system server according to the storage space size locally at the collaborative system client. And further, the fake information related to the target access policy and the non-key enterprise resources issued by the collaborative system server are encrypted to obtain a fake policy file corresponding to the target access policy. Then, the pseudo policy file corresponding to the target access policy is stored in a storage space local to the collaborative system client.

In the embodiment of the application, the storage space size matched with the target access strategy is determined. And locally generating a pseudo policy file corresponding to the target access policy at the client of the collaborative system according to the size of the storage space, wherein the pseudo policy file is used for interfering policy modification operation of the unauthorized user account on the target access policy. In other words, in the embodiment of the application, by adopting a mode of locally storing the pseudo policy file corresponding to the size of the target access policy in the client of the collaborative system, the policy modification operation of interfering the execution of the target access policy by the account of the unauthorized user is achieved. Thereby realizing the technical effect of improving the accuracy of access verification.

Optionally, as an alternative, locally generating, at the collaboration system client, a pseudo policy file corresponding to the target access policy according to the storage space size includes:

s1, generating a pseudo strategy file of default content according to the size of a storage space;

s2, identifying first strategy information from a target access strategy, wherein the first strategy information is used for indicating a resource information list allowing direct access;

s3, writing the first strategy information into the pseudo strategy file according to a first content writing mode, wherein the first content writing mode comprises the following steps: the first strategy information is written in the plaintext content or is written after being encrypted according to the encryption mode of the first encryption level.

Alternatively, the pseudo policy file for generating default content according to the storage space size may include, but is not limited to: and randomly generating a default pseudo-strategy file according to the size of the storage space. It should be noted that the above-described resource information list allowing direct access may be, but not limited to, a resource list indicating disclosure included in the target access policy. The encryption manner according to the first encryption level may include, but is not limited to: the encryption method of the electronic codebook (Electric Codebook, abbreviated as ECB) or other simple symmetric encryption method is not limited in this embodiment.

Further, the writing the first policy information into the pseudo policy file according to the first content writing manner may include, but is not limited to: directly determining the first strategy information as a first type file, and further writing the first type file into a pseudo strategy file; or, the first strategy information is encrypted according to the encryption mode of the first encryption level to obtain a first type file, and then the first type file is written into the pseudo strategy file.

In the embodiment of the application, the pseudo-policy file of the default content is generated according to the size of the storage space. Then, first policy information indicating a list of resource information that allows direct access is identified from the target access policy. Further, the first policy information is written into the pseudo policy file according to a first content writing method, wherein the first content writing method includes: the first strategy information is written in the plaintext content or is written after being encrypted according to the encryption mode of the first encryption level. In other words, in the embodiment of the application, by adopting a mode of locally storing the pseudo policy file corresponding to the size of the target access policy in the client of the collaborative system, the policy modification operation of interfering the execution of the target access policy by the account of the unauthorized user is achieved. Thereby realizing the technical effect of improving the accuracy of access verification.

Optionally, after generating the pseudo policy file of the default content according to the storage space size, the method further includes:

acquiring second policy information under the condition that the access is performed according to the first policy information in the target access policy but the access fails, wherein the second policy information is used for indicating a resource information list which allows the access to be attempted but does not authorize the access;

and writing the pseudo-strategy file into the second strategy information according to a second content writing mode, wherein the second content writing mode comprises the following steps: adding interference characters into the second strategy information and then writing the second strategy information, or encrypting the second strategy information according to a second encryption level encryption mode and then writing the second strategy information; wherein the first encryption level is lower than the second encryption level.

For example, when the unauthorized user account analyzes the first type file included in the pseudo policy file to obtain the first policy information, and accesses the resource list included in the first policy information but fails to access, the resource list is determined as the second policy information. And then adding interference characters into the second strategy information and writing the second strategy information, or encrypting the second strategy information according to the encryption mode of the second encryption level and then writing the second strategy information into the pseudo strategy file.

In the embodiment of the application, under the condition that access is performed according to the second policy information in the target access policy but the access fails, the second policy information is acquired, wherein the second policy information is used for indicating a resource information list which allows the access attempt but does not authorize the access. Then, writing the pseudo policy file into the second policy information according to a second content writing mode, wherein the second content writing mode comprises the following steps: adding interference characters into the second strategy information and then writing the second strategy information, or encrypting the second strategy information according to a second encryption level encryption mode and then writing the second strategy information; wherein the first encryption level is lower than the second encryption level. In other words, in the embodiment of the application, by adopting a mode of locally storing the pseudo policy file corresponding to the size of the target access policy in the client of the collaborative system, the policy modification operation of interfering the execution of the target access policy by the account of the unauthorized user is achieved. Thereby realizing the technical effect of improving the accuracy of access verification.

Optionally, after generating the pseudo policy file corresponding to the target access policy locally at the client of the collaborative system according to the storage space size, the method further includes:

Acquiring a file operation request;

determining a process identifier of a target processing process triggering the file operation request under the condition that the file operation request indicates to execute read-write operation on the pseudo-strategy file;

in case the process identity is located on an access white list comprised in the first access policy, a read-write operation is allowed on the pseudo policy file.

It should be noted that, the access whitelist included in the first access policy may include, but is not limited to: an account identification of an authorized user account (e.g., an account ID of a user account, etc.), a client identification of a collaborative system client (e.g., a client ID of a collaborative system client, etc.).

Further, in the case that the process identifier is located on the access white list included in the first access policy, the allowing to perform the read-write operation on the pseudo policy file may include, but is not limited to: and under the condition that the initiator of the file operation request is a user account, determining the account identification of the user account initiating the process through the process identification. Furthermore, under the condition that the account identification is determined to be positioned in the access white list, the read-write operation on the pseudo policy file is allowed; or determining the client identification corresponding to the client initiating the process through the process identification under the condition that the initiator of the file operation request is the client. Further, in the case that the client identifier is determined to be located in the access white list, the read-write operation is allowed to be performed on the pseudo policy file.

In the embodiment of the application, a file operation request is acquired. Then, in the case that the file operation request indicates that the read-write operation is performed on the pseudo-policy file, a process identification of a target processing process that triggers the file operation request is determined. In case the process identity is located on an access white list comprised in the first access policy, a read-write operation is allowed on the pseudo policy file. In other words, in the embodiment of the application, by providing a way of accessing the white list, the authorized user account or the collaboration system client can perform the read-write operation on the pseudo policy file. Therefore, the purpose of further disturbing the unauthorized user account number and enabling the unauthorized user account number to determine the pseudo-policy file as the file of the first access policy is achieved. And further, the problem that the first access strategy is tampered by an account number of an unauthorized user is avoided, and the technical effect of improving the accuracy of access verification is achieved.

Optionally, after determining the process identifier of the processing process triggering the file operation request, the method further includes:

and executing the intervention operation on the target processing process according to the intervention operation priority matched with the target processing process under the condition that the process identification is not located on the access white list, wherein the intervention operation is used for stopping the read-write operation of the target processing process on the pseudo-strategy file.

It should be noted that the above intervention operation priority may be, but is not limited to, related to a request type of a file operation request corresponding to a target process, specifically, an intervention operation priority of a target process that requests to perform a read operation on a pseudo policy file is lower than an intervention operation priority of a target process that performs a write operation on the pseudo policy file. The manner in which the read-write operations performed by the target processing process on the pseudo-policy file are aborted is also different for the corresponding intervention operations under different intervention operation priorities.

For example, assume that the intervention operation priority of the target process a requesting to perform a read operation on the pseudo policy file is one level; the intervention operation priority of the target processing process B performing the write operation on the pseudo policy file is two-level. Then the intervention operation to the target process a may be an alarm and the intervention operation to the target process B may be a disconnection.

In the embodiment of the application, under the condition that the process identifier is not located on the access white list, executing the intervention operation on the target processing process according to the intervention operation priority matched with the target processing process, wherein the intervention operation is used for stopping the read-write operation of the target processing process on the pseudo-strategy file. In other words, in the embodiment of the application, by performing the daring operation on the process under the condition that the unauthorized process is detected to access the pseudo-policy file, the method achieves that the unauthorized user account is timely determined under the condition that the unauthorized user account does not threaten the access policy yet. Therefore, the problem that the access strategy is tampered by the account number of the unauthorized user is avoided from the source, and the technical effect of improving the accuracy of access verification is achieved.

Optionally, as an alternative, accessing the target application site according to the access ticket verification result includes:

under the condition that the access ticket checking result carries an authorized access ticket corresponding to the access request, determining that the access request passes the access check, and accessing the target application site by using the authorized access ticket;

and under the condition that the access ticket checking result does not carry the authorized access ticket corresponding to the access request, determining that the access request does not pass the access checking, and prompting to reject the access request.

It should be noted that, in the embodiment of the present application, the above-mentioned authorized access ticket may be, but is not limited to, an access ticket provided by the collaboration system server. Specifically, in the case where the current number of times of use of the authorized access ticket does not reach the maximum number of times of use, and the authorized access ticket is still within the valid use time, the target user account number may legally access the target application site based on the authorized access ticket. Further, the above access ticket verification result may include, but is not limited to: the contents such as the authorized access ticket, the maximum number of times the authorized access ticket is used, the effective time of the authorized access ticket, and the like.

In the embodiment of the application, under the condition that the access ticket verification result carries an authorized access ticket corresponding to the access request, the access request is determined to pass the access verification, and the authorized access ticket is used for accessing the target application site. Then, under the condition that the access ticket checking result does not carry the authorized access ticket corresponding to the access request, determining that the access request does not pass the access checking, and prompting to reject the access request. In other words, by adopting the embodiment of the application, the second authentication is performed on the first access policy cached by the collaborative system client logged in by the target user account through the collaborative system client and the collaborative system server. And rejecting the access of the target user account under the condition that the first access policy is not verified by the collaborative system server and the authorized access ticket is not provided to the collaborative system client. And allowing the target user account to access the target application site under the condition that the first access policy is verified by the collaborative system server and the authorized access ticket is provided to the collaborative system client. The technical problem that the access verification accuracy is reduced due to the fact that the difficulty of verification operation is increased due to the fact that the access strategy is influenced by factors associated with the terminal equipment where the client is located is solved. The technical effects of reducing the difficulty of access verification and improving the accuracy of the access verification are achieved.

Optionally, after sending the access ticket application request to the collaboration system server, the method further includes:

the collaboration system server compares the policy features of the first access policy with the policy features of the second access policy to obtain a comparison result;

under the condition that the comparison result indicates that the first access strategy is matched with the second access strategy, the collaborative system server acquires an authorized access ticket corresponding to the access request;

the collaboration system server will generate an access ticket check result using the authorized access ticket to indicate that the access request passes the access check.

Accordingly, the policy features of the second access policy described above may, but are not limited to, uniquely identify the second access policy. Specifically, the policy features described above may include, but are not limited to: the policy ID of the second access policy, the policy version of the second access policy, the update time of the second access policy, the content hash value of the second access policy, and the like.

It should be noted that, the above collaborative system server may generate, using the authorized access ticket, an access ticket verification result for indicating that the access request passes the access verification, which includes, but is not limited to: the collaboration system server will generate an access ticket check result indicating that the access request passes the access check using the authorized access ticket, the maximum number of times the authorized access ticket is used, and the validity time of the authorized access ticket.

Optionally, in this embodiment of the present application, after comparing the policy feature of the first access policy and the policy feature of the second access policy by the collaboration system server, the method further includes: and under the condition that the time interval between the first access strategy currently cached by the collaborative system client and the last passively executed strategy update is smaller than a first threshold value, determining a comparison result for indicating that the version ID of the first access strategy is lower than the version ID of the second access strategy (namely, the first access strategy is an old version of the second access strategy) as that the first access strategy and the second access strategy are matched with each other. In other words, in this embodiment, by setting the fault tolerance mechanism in the collaborative system server, the technical problem that an error exists in the comparison of policy features due to the fact that the collaborative system client side has not timely written the updated first access policy into the memory is avoided.

As an alternative embodiment, the above method is illustrated by the following steps as shown in fig. 8:

executing step S802, the collaborative system server locally searches an access policy corresponding to the target user account, and determines the access policy as a second access policy, thereby obtaining a policy feature of the second access policy, where the method includes: the policy ID of the second access policy, the policy version of the second access policy, the update time of the second access policy, the content hash value of the second access policy.

Then, step S804 is executed to obtain the policy features of the first query policy by analyzing the access ticket application request sent by the collaboration system client, where the steps include: the method comprises the steps of a policy ID of a first access policy, a policy version of the first access policy, an update time of the first access policy and a content hash value of the first access policy.

Step S806 is then executed to compare the policy characteristics of the first access policy with the policy characteristics of the second access policy, and determine whether the policy characteristics of the first access policy are consistent with the policy characteristics of the second access policy. Specifically, the policy ID of the first access policy is compared with the policy ID of the second access policy, the policy version of the first access policy is compared with the policy version of the second access policy, the update time of the first access policy is compared with the update time of the second access policy, and the content hash value of the first access policy is compared with the content hash value of the second access policy.

In the case that the policy characteristics of the first access policy are consistent with those of the second access policy, step S808-1 is executed to acquire an authorized access ticket corresponding to the access request, and generate an access ticket check result indicating that the access request passes the access check using the authorized access ticket, the maximum number of times the authorized access ticket is used, and the validity time of the authorized access ticket.

In case the policy characteristics of the first access policy are inconsistent with the policy characteristics of the second access policy, step S808-2 is performed to generate an access ticket check result indicating that the access request fails the access check.

In the embodiment of the application, the collaborative system server compares the policy characteristics of the first access policy with the policy characteristics of the second access policy to obtain a comparison result. Then, under the condition that the comparison result indicates that the first access strategy is matched with the second access strategy, the collaborative system server acquires an authorized access ticket corresponding to the access request. The collaboration system server will then generate an access ticket verification result using the authorized access ticket to indicate that the access request passes the access verification. In other words, in the embodiment of the application, the secondary verification of the first access policy is performed by the collaboration system server, so that the technical problem of inaccurate access verification caused by tampering of the first access policy is avoided. Thereby realizing the technical effect of improving the accuracy of access verification.

As an optional implementation manner, it is assumed that the above-mentioned access verification method is applied to an access verification scenario in which, after a user account logs in a collaborative system client, an enterprise internal resource that is docked with the collaborative system client is accessed, and the following steps as shown in fig. 9 are used to integrally illustrate the above-mentioned method:

it should be noted that the embodiment of the present embodiment may be based on, but not limited to, the following two preconditions:

precondition one: after the collaborative system client filters access sessions based on the zero trust access policy (from the collaborative system server), access sessions for enterprise resources are screened out. Then, an access ticket application is initiated to the backend server. The backend server, prior to responding to the access ticket, ensures that strict security policy verification and identity authorization checks are performed on relevant parameters (including five tuples, device information, user information, etc.) of the access session for which the access ticket was applied based on the latest zero-trust access policy.

Specifically, the zero-trust access policy is generated by an administrator at the management end and then synchronized to the collaborative system client via the collaborative system server. When the specific strategy is executed, the cooperative system client side is matched with the back end to filter and check the zero trust access strategy instead of judging the access flow. When the access agent hijacking the traffic initiated by the access main body, the cooperative system client compares the characteristics of the traffic (mainly five-tuple, namely the source IP address, the source port, the destination IP address, the destination port and the transport layer protocol related to the network session) according to the latest access strategy issued by the server, and initiates a bill application to the cooperative system server after determining that the current user and the application initiating the traffic have the access authority of the appointed enterprise resource. When receiving the ticket application request, the collaboration system server performs strict complete policy verification and identity authorization check based on the access policy configured by the administrator to verify the authority of the access subject, and responds to the access ticket after confirming without errors. In this way, even if the cooperative system client determines an error, the cooperative system server can make a right determination based on the latest access policy. That is, in this process, both the collaborative system client and the collaborative system server verify the access policy.

And on the premise of two: establishing secure socket layer protocol (Secure Socket Layer, abbreviated as SSL) or transport layer security protocol (Transport Layer Security, abbreviated as TLS) bidirectional authentication between a collaborative system client and a collaborative system server; under the condition that the cooperative system client and the cooperative system server pass SSL or TLS mutual authentication respectively, the communication channel between the cooperative system client and the cooperative system server is determined to be opened.

In step S902, the collaboration system client pulls the current latest zero-trust access policy (i.e., the target access policy) from the collaboration system server through a secure communication link, and then does not store the actual access policy locally, but stores the first access policy obtained by encrypting and casing the zero-trust access policy in the memory of the collaboration system client.

It should be noted that, while the first access policy is stored in the memory of the collaboration system client, the collaboration system client also encrypts and shells policy features (such as a policy ID, version, update time, and content hash) of the first access policy, and stores the encrypted and shelled policy features in the memory. The critical processing logic shell processing for the zero trust access strategy (target access strategy) is recommended to have the functions of reverse debugging and reverse engineering, so that the use of tools such as a debugger, reverse engineering and the like can be detected and prevented during running, the safety of an application program is improved, and the difficulty of analyzing program logic and excavating software vulnerabilities is increased.

Further, the key information used for encrypting the target access policy and the policy feature includes software and hardware information of the current device and the start time of the process. Accordingly, the key information used in decrypting the first access policy and policy feature also includes the software and hardware information of the current device, as well as the start time of the process. After the first access policy is used, the first access policy and policy features should be deleted from the memory.

In step S904, under the condition that the collaboration system client receives an access request initiated by the target user account for requesting to access the target application site, a first access policy cached by the collaboration system client logged in using the target user account is determined.

Step S906, when the first access policy indicates that the target user account is allowed to access the target application site and the first access policy satisfies the periodic verification condition, generating an access ticket application request matched with the access request by using the policy feature of the first access policy.

It should be noted that, the access ticket application request includes, in addition to the policy feature of the first access policy, a request parameter corresponding to the access request. Wherein the request parameters include: the five-tuple corresponding to the access request (such as the source IP or domain name, the source port, the destination IP or domain name, the destination port, and the characteristic information of the process corresponding to the session application process), the destination port, and the characteristic information of the process corresponding to the session application process (such as hash of the application process, process path, latest modification time of the executable file of the application process, copyright information, digital signature information, etc.).

In step S908, the collaboration system client sends an access ticket application request to the collaboration system server.

Step S910, accessing the target application site according to the access ticket checking result.

It should be noted that, in this embodiment, the collaboration system server may issue a rule to the collaboration system client in advance, and specifically, the rule requires the collaboration system client to carry the policy feature in the case where the time interval between the current time and the time when the request for requesting the access ticket carrying the policy feature was last sent to the collaboration system server is greater than a threshold. If the request sent by the cooperative system client does not carry the policy feature information, the authentication request of the cooperative system server is illegal and does not respond to the access ticket.

Further, after the collaborative system server receives the request carrying the policy feature, the policy feature is compared with the policy feature corresponding to the locally stored target user account. If inconsistent is found, the collaborative system server refuses to access the ticket. It should be noted that, in this embodiment, there is a fault tolerance mechanism, specifically, it is assumed that after the cooperative system server updates the target access policy at the time point T1, the latest target access policy is synchronized to the assumed cooperative system client, and the synchronization process will take a certain time. The collaboration system client may be able to synchronously pull the latest policy at time T2 (T2 > T1), and the collaboration system server may enable the fault tolerance mechanism during the interval [ T1, T2 ]. Specifically, in [ T1, T2), the collaboration system server may determine that the policy feature information reported by the collaboration system client is old policy ID, version, etc. is legal, and if the policy reported by the collaboration system client is inconsistent with the policy issued by the collaboration system server after a certain time is exceeded, the policy is determined to be abnormal.

It should be noted that, when the process of the collaboration system client side responsible for the zero trust access policy is started, or when the zero trust policy is changed, the collaboration system client side pulls the latest zero trust policy to the server side through a trusted network link. And if the zero trust policy pulling is successful, an available policy exists in the memory, the zero trust network access can normally operate, otherwise, after the zero trust policy pulling is failed, the correct zero trust network access is not executed. And after the zero trust policy is successfully pulled, the collaborative system server can judge whether the policy version executed by the client is consistent with the policy version actually issued to the current login user (ID and version, and content hash are consistent) according to the policy feature information reported by the collaborative system client, and if not, the server refuses to respond to legal access notes even if an available zero trust policy exists in a process memory of the collaborative system client responsible for executing the zero trust access policy.

Further, in this embodiment, an intervention mechanism for actively defending against policy tampering is provided, and the specific content of the mechanism is as follows:

When a new zero trust access policy is issued to the collaboration system client, the real policy content and policy feature information are stored in the memory in an encrypted manner, and the local file is not subjected to the landing (even if the encrypted file is brushed in, an attacker can detect the writing operation of the file by monitoring the reading and writing of the collaboration system client process, so that various forms of attacks are performed on the policy file). Therefore, after receiving the access policy of the collaboration system server, the collaboration system client can adapt the content size of the real policy to generate a plurality of plain text storages based on the specific low-sensitivity enterprise resources (or directly the resource list of the forged enterprise) issued by the collaboration system server, or encrypt the enterprise resources by adopting a simple secret key and combining a low-confidentiality-level encryption algorithm or a simple symmetric encryption mode (such as an ECB mode) and store the encrypted enterprise resources.

In particular, the access authority rule of some low sensitive resources or fake data is stored in the files, so that different files can be distinguished to respectively store enterprise resource information with access right and enterprise resource information with access attempt but without access right. For example, data such as files with access rights (referred to as class a files) represents a certain list of enterprise resources that are allowed to be accessed, while files without access rights (referred to as class B files) represent a list that the current user account attempts to access but fails to access. In addition, such files include a portion of scrambled binary content that cannot be decrypted or analyzed for purposes of confusing an attacker in order to allow the attacker to access a portion of the information therein, while other (and indeed useless) information is purposely hidden, enhancing the confusing, while also avoiding exposing the true purpose of such files because the content is too simple and obvious.

The kernel driven service of the collaboration system client will then continuously monitor the read and write operations of all processes within the device to these local files, where the collaboration system client's own processes default to being legitimate. In addition to the processes of the collaboration system client itself, the collaboration system server may also specify a process whitelist for reading and writing such files by issuing security policies. In addition to cooperating with the processes of the system client itself, the process list in the process whitelist defaults to legal read and write operations for such files. The process white list designates process characteristic information which is read and written in the files and is considered legal, wherein the process characteristic information comprises digital signatures, directory characteristics of processes, copyright information and the like.

Further, when the policy is changed, the access body initiates network access or starts a process related to the collaboration system client, and the operation of reading the local file is performed. In particular, when the collaboration system client identifies an enterprise resource that the accessing agent attempts to issue without access, the class B file is read (similarly, when the collaboration system client identifies that the accessing agent has access to the enterprise resource, the collaboration system client chooses to randomly read the class a file), and then writes relevant information, which may be a scrambled binary content in the updated file that cannot be decrypted or analyzed. Allowing an attacker to directly influence the results of network access with such files. When the kernel driving service of the client of the collaborative system detects that the file is read or written by a process except the process white list, alarm reporting is executed based on the security rule issued by the server of the collaborative system, or the method comprises the steps of log-back, requiring intervention measures such as secondary login of an account number of a terminal user, network disconnection of equipment and the like.

In this embodiment, the first access policy is stored in the memory after being encrypted. The problem that the access policy is tampered due to the fact that the access policy is stored in the local storage space is avoided. By adopting the cooperative system client and the cooperative system server to perform secondary authentication on the first access policy cached by the cooperative system client logged in by the target user account, the technical problem that the difficulty of verification operation is increased and the accuracy of access verification is reduced due to the fact that the access policy is influenced by each factor associated with the terminal equipment where the client is located is solved.

It should be noted that, for simplicity of description, the foregoing method embodiments are all expressed as a series of action combinations, but it should be understood by those skilled in the art that the present application is not limited by the order of actions described, as some steps may be performed in other order or simultaneously in accordance with the present application. Further, those skilled in the art will also appreciate that the embodiments described in the specification are all preferred embodiments, and that the acts and modules referred to are not necessarily required in the present application.

According to another aspect of the embodiments of the present application, there is also provided an access verification apparatus for implementing the above access verification method. As shown in fig. 10, the apparatus includes:

a first obtaining unit 1002, configured to obtain an access request for requesting access to a target application site;

a first determining unit 1004, configured to determine, in response to an access request, a first access policy cached by a collaboration system client logged in using a target user account, where the first access policy is an access policy received from a collaboration system server corresponding to the collaboration system client, and after being encrypted, stored in a memory;

a verification unit 1006, configured to generate an access ticket application request matched with the access request by using a policy feature of the first access policy, and send the access ticket application request to the collaborative system server, where the first access policy indicates that the target user account is allowed to access the target application site, and the first access policy meets a periodic verification condition;

the receiving unit 1008 is configured to receive an access ticket verification result returned by the collaboration system server, where the access ticket verification result is obtained by the collaboration system server verifying the first access policy indicated by the access ticket application request by using the locally stored second access policy;

And an access unit 1010, configured to access the target application site according to the access ticket verification result.

Optionally, in this embodiment, the first determining unit includes: the first searching module is used for responding to the access request and searching a first access strategy matched with the target user account in a storage space corresponding to the collaborative system client in the memory; the first decryption module is used for decrypting the first access strategy by utilizing key information matched with the terminal equipment where the client of the collaborative system is located under the condition that the first access strategy is found out, so as to obtain strategy content and strategy characteristics of the first access strategy; the first prompting module is used for prompting to reject the access request under the condition that the first access strategy is not found out.

Optionally, in this embodiment, the apparatus further includes: the second acquisition unit is used for acquiring the time interval from the last passive execution strategy update of the first access strategy of the current cache; and the second determining unit is used for determining that the first access strategy meets the periodic check condition under the condition that the time interval is larger than the target threshold value.

Optionally, in this embodiment, the verification unit includes: the first acquisition module is used for acquiring request parameters of the access request; the first generation unit is used for generating an access ticket application request based on the request parameters and the policy characteristics of the first access policy.

Optionally, in this embodiment, the upper device further includes: the third acquisition unit is used for acquiring a target access strategy matched with the target user account from the collaborative system server; the first encryption unit is used for encrypting the target access strategy by utilizing key information matched with the terminal equipment where the collaborative system client is located to obtain a first access strategy; the first storage unit is used for storing the first access strategy into the memory and carrying out compression protection processing on the first access strategy.

Optionally, in this embodiment, the apparatus further includes: a third determining unit, configured to determine a storage space size adapted to the target access policy; and the second generation unit locally generates a pseudo policy file corresponding to the target access policy at the client of the collaborative system according to the size of the storage space, wherein the pseudo policy file is used for interfering policy modification operation of the unauthorized user account on the target access policy.

Optionally, in this embodiment, the second generating unit is further configured to generate a pseudo policy file of the default content according to a size of the storage space; identifying first policy information from a target access policy, wherein the first policy information is used for indicating a resource information list allowing direct access; writing the first strategy information into the pseudo strategy file according to a first content writing mode, wherein the first content writing mode comprises the following steps: the first strategy information is written in the plaintext content or is written after being encrypted according to the encryption mode of the first encryption level.

Optionally, in this embodiment, the apparatus further includes: a fourth acquisition unit configured to acquire second policy information indicating a resource information list that allows access but does not grant access, in a case where access is performed according to the first policy information in the target access policy but access fails; the first writing unit is configured to write the pseudo policy file into the second policy information according to a second content writing manner, where the second content writing manner includes: adding interference characters into the second strategy information and then writing the second strategy information, or encrypting the second strategy information according to a second encryption level encryption mode and then writing the second strategy information; wherein the first encryption level is lower than the second encryption level.

Optionally, in this embodiment, the apparatus further includes: a fifth obtaining unit for obtaining a file operation request; a fourth determining unit, configured to determine a process identifier of a target processing process that triggers the file operation request, where the file operation request indicates that a read-write operation is performed on the pseudo-policy file; in case the process identity is located on an access white list comprised in the first access policy, a read-write operation is allowed on the pseudo policy file.

Optionally, in this embodiment, the apparatus further includes: the first operation unit is used for executing the intervention operation on the target processing process according to the intervention operation priority matched with the target processing process under the condition that the process identification is not located on the access white list, wherein the intervention operation is used for stopping the read-write operation of the target processing process on the pseudo-strategy file.

Optionally, in this embodiment, the access unit includes: a fifth determining unit, configured to determine that the access request passes the access verification and access the target application site by using the authorized access ticket when the access ticket verification result carries the authorized access ticket corresponding to the access request; and a sixth determining unit, configured to determine that the access request does not pass the access verification and prompt rejection of the access request when the access ticket verification result does not carry an authorized access ticket corresponding to the access request.

Optionally, in this embodiment, the apparatus further includes: the first comparison unit is used for comparing the strategy characteristics of the first access strategy with the strategy characteristics of the second access strategy to obtain a comparison result; a sixth obtaining unit, configured to obtain an authorized access ticket corresponding to the access request when the comparison result indicates that the first access policy is matched with the second access policy; and the third generation unit is used for generating an access ticket checking result for indicating that the access request passes the access check by using the authorized access ticket.

It should be noted that, for a specific example in this embodiment, please refer to the example shown in the above access verification method, and a detailed description is omitted here.

According to still another aspect of the embodiments of the present application, there is further provided an electronic device for implementing the above access verification method, where the embodiment uses the electronic device as an example of a terminal. As shown in fig. 11, the electronic device comprises a memory 1102 and a processor 1104, the memory 1102 having stored therein a computer program, the processor 1104 being arranged to perform the steps of any of the method embodiments described above by means of the computer program.

Alternatively, in this embodiment, the electronic device may be located in at least one network device of a plurality of network devices of the computer network.

Alternatively, in the present embodiment, the above-described processor may be configured to execute the following steps by a computer program:

s1, acquiring an access request for requesting to access a target application site;

s2, responding to the access request, determining a first access strategy cached by the collaborative system client logged in by using the target user account, wherein the first access strategy is an access strategy received from a collaborative system server corresponding to the collaborative system client, and storing the access strategy in a memory after being encrypted;

S3, under the condition that the first access policy indicates that the target user account is allowed to access the target application site and the first access policy meets the periodic verification condition, generating an access ticket application request matched with the access request by utilizing the policy characteristics of the first access policy, and sending the access ticket application request to the collaborative system server;

s4, receiving an access ticket checking result returned by the collaborative system server, wherein the access ticket checking result is obtained by the collaborative system server after checking a first access policy indicated by an access ticket application request by using a locally stored second access policy;

s5, accessing the target application site according to the access ticket checking result.

Alternatively, it will be understood by those skilled in the art that the structure shown in fig. 11 is only schematic, and the electronic device may also be a terminal device such as a smart phone (e.g. an Android phone, an iOS phone, etc.), a tablet computer, a palm computer, and a mobile internet device (Mobile Internet Devices, MID), a PAD, etc. Fig. 11 is not limited to the structure of the electronic device described above. For example, the electronic device may also include more or fewer components (e.g., network interfaces, etc.) than shown in FIG. 11, or have a different configuration than shown in FIG. 11.

The memory 1102 may be used to store software programs and modules, such as program instructions/modules corresponding to the access verification method and apparatus in the embodiments of the present application, and the processor 1104 executes the software programs and modules stored in the memory 1102, thereby performing various functional applications and data processing, that is, implementing the access verification method described above. Memory 1102 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 1102 may further include memory located remotely from processor 1104, which may be connected to the terminal via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof. Wherein the memory 1102 is particularly, but not exclusively, operable to store access requests. As an example, as shown in fig. 11, the memory 1102 may include, but is not limited to, the first obtaining unit 1002, the first determining unit 1004, the checking unit 1006, the receiving unit 1008, and the accessing unit 1010 in the access checking device. In addition, other module units in the above access verification apparatus may be included, but are not limited to, and are not described in detail in this example.

Optionally, the transmission device 1106 is used to receive or transmit data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 1106 includes a network adapter (Network Interface Controller, NIC) that may be connected to other network devices and routers via a network cable to communicate with the internet or a local area network. In one example, the transmission device 1106 is a Radio Frequency (RF) module for communicating wirelessly with the internet.

In addition, the electronic device further includes: a connection bus 1108 for connecting the various module components in the electronic device.

In other embodiments, the terminal device or the server may be a node in a distributed system, where the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting the plurality of nodes through a network communication. The nodes may form a point-to-point network, and any type of computing device, such as a server, a terminal, etc., may become a node in the blockchain system by joining the point-to-point network.

According to still another aspect of the embodiments of the present application, there is also provided an electronic device including a memory, in which a computer program is stored, and a processor configured to execute the above-described access verification method by the computer program.

Alternatively, in the present embodiment, the above-described computer-readable storage medium may be configured to store a computer program for performing the steps of:

Alternatively, in this embodiment, it will be understood by those skilled in the art that all or part of the steps in the methods of the above embodiments may be performed by a program for instructing a terminal device to execute the steps, where the program may be stored in a computer readable storage medium, and the storage medium may include: flash disk, read-Only Memory (ROM), random-access Memory (Random Access Memory, RAM), magnetic or optical disk, and the like.

The integrated units in the above embodiments may be stored in the above-described computer-readable storage medium if implemented in the form of software functional units and sold or used as separate products. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, including several instructions to cause one or more computer devices (which may be personal computers, servers or network devices, etc.) to perform all or part of the steps of the methods described in the various embodiments of the present application.

In the foregoing embodiments of the present application, the descriptions of the embodiments are emphasized, and for a portion of this disclosure that is not described in detail in this embodiment, reference is made to the related descriptions of other embodiments.

In several embodiments provided in the present application, it should be understood that the disclosed client may be implemented in other manners. The above-described embodiments of the apparatus are merely exemplary, and the division of the units, such as the division of the units, is merely a logical function division, and may be implemented in another manner, for example, multiple units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interfaces, units or modules, or may be in electrical or other forms.

The units described as separate units may or may not be physically separate, and units shown 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 may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The foregoing is merely a preferred embodiment of the present application and it should be noted that modifications and adaptations to those skilled in the art may be made without departing from the principles of the present application and are intended to be comprehended within the scope of the present application.

Claims

1. An access verification method, comprising:

generating a pseudo policy file corresponding to a target access policy locally at a collaborative system client according to a storage space size adapted to the target access policy, including: generating a pseudo strategy file of default content at the client of the collaborative system according to the size of the storage space; identifying first policy information from the target access policy, wherein the first policy information is used for indicating a resource information list allowing direct access; writing the first strategy information into a pseudo strategy file according to a first content writing mode, wherein the first content writing mode comprises the following steps: writing the first strategy information in a plaintext content, or writing the first strategy information after encryption processing according to an encryption mode of a first encryption level; the pseudo policy file is used for interfering with policy modification operation executed by an unauthorized user account on the target access policy, wherein the target access policy is an access policy matched with the target user account and obtained from a collaborative system server by using the collaborative system client logged in by the target user account;

Acquiring an access request for requesting access to a target application site;

determining a first access policy cached by the collaborative system client in response to the access request, wherein the first access policy is an access policy stored in a memory after the target access policy is encrypted;

generating an access ticket application request matched with the access request by utilizing the policy characteristics of the first access policy under the condition that the first access policy indicates that the target user account is allowed to access the target application site and the first access policy meets the periodic verification condition, and sending the access ticket application request to the collaborative system server;

receiving an access ticket checking result returned by the collaborative system server, wherein the access ticket checking result is obtained after the collaborative system server checks the first access policy indicated by the access ticket application request by using a locally stored second access policy;

and accessing the target application site according to the access ticket verification result.

2. The method of claim 1, wherein the determining, in response to the access request, the first access policy cached by the collaboration system client comprises:

Responding to the access request, and searching the first access strategy matched with the target user account in a storage space corresponding to the collaborative system client in the memory;

under the condition of searching the first access strategy, decrypting the first access strategy by utilizing key information matched with terminal equipment where the collaborative system client is located, so as to obtain strategy content and strategy characteristics of the first access strategy;

and prompting to reject the access request under the condition that the first access strategy is not found.

3. The method according to claim 2, wherein after decrypting the first access policy using the key information corresponding to the terminal device where the collaboration system client is located, obtaining the policy content and the policy feature of the first access policy, the method further comprises:

acquiring a time interval from the last passive execution policy update of the first access policy of the current cache;

and determining that the first access policy meets the periodic verification condition when the time interval is greater than a target threshold.

4. The method of claim 1, wherein generating an access ticket application request that matches the access request using the policy characteristics of the first access policy comprises:

Acquiring request parameters of the access request;

and generating the access ticket application request based on the request parameters and the policy characteristics of the first access policy.

5. The method of claim 1, further comprising, prior to locally generating, at the collaboration system client, a pseudo-policy file corresponding to the target access policy in accordance with the storage space size that is adapted to the target access policy:

acquiring the target access policy matched with the target user account from the collaborative system server;

encrypting the target access policy by using key information matched with terminal equipment where the collaborative system client is located to obtain the first access policy;

storing the first access strategy into the memory, and performing compression protection processing on the first access strategy.

6. The method of claim 1, further comprising, after the locally generating, at the collaboration system client, a pseudo-policy file corresponding to the target access policy in accordance with the storage space size adapted to the target access policy:

acquiring second policy information under the condition that access is performed according to first policy information in the target access policy but access fails, wherein the second policy information is used for indicating a resource information list which allows access to be attempted but does not authorize access;

Writing the second strategy information into the pseudo strategy file according to a second content writing mode, wherein the second content writing mode comprises the following steps: adding interference characters into the second strategy information and then writing the second strategy information, or encrypting the second strategy information according to a second encryption level encryption mode and then writing the second strategy information;

wherein the first encryption level is lower than the second encryption level.

7. The method of claim 1, further comprising, after the locally generating, at the collaboration system client, a pseudo-policy file corresponding to the target access policy in accordance with the storage space size adapted to the target access policy:

acquiring a file operation request;

and allowing the pseudo policy file to execute read-write operation under the condition that the process identifier is positioned on an access white list contained in the first access policy.

8. The method of claim 7, further comprising, after said determining a process identification of a process that triggered the file operation request,:

And executing intervention operation on the target processing process according to the intervention operation priority matched with the target processing process under the condition that the process identifier is not located on the access white list, wherein the intervention operation is used for stopping the read-write operation of the target processing process on the pseudo-strategy file.

9. The method of any one of claims 1 to 8, wherein accessing the target application site according to the access ticket validation result comprises:

10. The method of claim 9, further comprising, after said sending said access ticket application request to said collaboration system server:

The collaborative system server compares the strategy characteristics of the first access strategy with the strategy characteristics of the second access strategy to obtain a comparison result;

the collaboration system server will generate the access ticket verification result using the authorized access ticket to indicate that the access request passes access verification.

11. An access verification apparatus, comprising:

a first acquisition unit configured to acquire an access request for requesting access to a target application site;

the first determining unit is used for determining a first access strategy cached by the client of the collaborative system in response to the access request, wherein the first access strategy is an access strategy stored in a memory after the target access strategy is encrypted;

the verification unit is used for generating an access ticket application request matched with the access request by utilizing the policy characteristics of the first access policy and sending the access ticket application request to a collaborative system server when the first access policy indicates that the target user account is allowed to access the target application site and the first access policy meets the periodic verification condition;

The receiving unit is used for receiving an access ticket checking result returned by the collaborative system server, wherein the access ticket checking result is obtained after the collaborative system server checks the first access policy indicated by the access ticket application request by utilizing a locally stored second access policy;

the access unit is used for accessing the target application site according to the access ticket verification result;

the device is further configured to locally generate, at a client of the collaborative system, a pseudo policy file corresponding to a target access policy according to a storage space size adapted to the target access policy, where the pseudo policy file includes: generating a pseudo strategy file of default content at the client of the collaborative system according to the size of the storage space; identifying first policy information from the target access policy, wherein the first policy information is used for indicating a resource information list allowing direct access; writing the first strategy information into a pseudo strategy file according to a first content writing mode, wherein the first content writing mode comprises the following steps: writing the first strategy information in a plaintext content, or writing the first strategy information after encryption processing according to an encryption mode of a first encryption level; the pseudo policy file is used for interfering policy modification operation of the unauthorized user account on the target access policy, wherein the target access policy is an access policy which is acquired from a collaborative system server and matched with the target user account, and the collaborative system client logs in by using the target user account.

12. A computer readable storage medium, characterized in that the computer readable storage medium comprises a stored program, wherein the program when run by a processor performs the method of any one of claims 1 to 10.

13. An electronic device comprising a memory and a processor, characterized in that the memory has stored therein a computer program, the processor being arranged to execute the method according to any of the claims 1 to 10 by means of the computer program.