Zero-trust security protection method, system and equipment based on endogenous security and medium

Abstract

The invention relates to the technical field of network security, and discloses a zero-trust security protection method, system, device and medium based on endogenous security, and the method comprises the steps: obtaining a user access request sent by a terminal device, executing local security policy verification on the user access request, obtaining a first access request passing the verification, and sending the first access request to the terminal device; the first access request is sent to a plurality of heterogeneous zero-trust policy executors; for any heterogeneous zero-trust policy executor, performing rule verification on the first access request to generate a decision execution result; and performing multi-mode decision on each decision execution result to obtain a decision result, and performing access control on the first access request based on the decision result. The method has the beneficial effects of effectively defending unknown vulnerabilities and eliminating single-point fault risks.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, in particular to a zero-trust security protection method and system based on endogenous security, a device and a medium. BACKGROUND

[0002] With the deepening of digital transformation, the network scale and software as a service application are increasingly complex, and the hybrid office mode has become a new trend. This trend has promoted business development while leading to an explosive growth in the network attack surface. The zero-trust network security architecture has emerged as the times require, and its core principles include "never trust, always verify", minimum privilege access, and continuous security checks. This architecture effectively addresses the security challenges brought about by the blurring of boundaries by conducting strict authentication and authorization at each access request, thereby improving the security of enterprise networks to some extent. However, the related zero-trust security architecture is still essentially a single-point defense system. Once an attacker exploits unknown vulnerabilities or hidden backdoors in the strategy execution point itself, they can bypass multiple verification mechanisms and achieve malicious access and control of application systems or data. In the context of cloud network convergence and complex technology stacks, software and hardware vulnerabilities are inevitable, which makes the zero-trust architecture based on a single component inherently insufficient in its defense capabilities when facing advanced persistent threats (APTs) and unknown exploits, and it cannot fundamentally avoid the dangers posed by unknown threats. SUMMARY

[0003] The present application provides a zero-trust security protection method and system based on endogenous security, which solves the technical problem of how to improve the defense capabilities of the zero-trust architecture and achieves the technical effect of effectively defending against unknown vulnerabilities and eliminating single-point failure risks.

[0004] To achieve the above purpose, the main technical solution adopted by the present application includes:

[0005] In a first aspect, the present application provides a zero-trust security protection method based on endogenous security, which includes: obtaining a user access request sent by a terminal device, performing local security policy verification on the user access request to obtain a first access request that passes the verification, and sending the first access request to a plurality of heterogeneous zero-trust policy execution bodies; for any heterogeneous zero-trust policy execution body, performing rule checking on the first access request to generate a decision execution result; performing multi-mode arbitration on each decision execution result to obtain an arbitration result, and performing access control on the first access request based on the arbitration result.

[0006] The zero-trust security protection method based on endogenous security provided by the embodiments of the application filters invalid access requests in advance by performing local security policy verification on user access requests, which is conducive to reducing cloud processing load and improving system processing efficiency. The first access request that passes the verification is sent to a plurality of heterogeneous policy executors for parallel rule checking, and the heterogeneous diversity design makes it difficult for attackers to exploit the same vulnerability to break all executors, which is conducive to increasing the attack cost and difficulty. The decision execution results output by the heterogeneous policy executors are cooperatively decided by using multi-mode arbitration, so that even if part of the executors are broken, the system can still make correct judgments, realize intrusion tolerance, effectively defend unknown vulnerabilities, eliminate single-point failure risks, and improve the reliability and resilience of the system.

[0007] Optionally, each heterogeneous zero-trust policy executor is deployed in a different executor environment; the plurality of heterogeneous zero-trust policy executors are heterogeneous in at least one of an operating system, a zero-trust policy dimension, and a zero-trust policy rule programming language; and for any heterogeneous zero-trust policy executor, the executor environment of the heterogeneous zero-trust policy executor is periodically replaced.

[0008] Each heterogeneous zero-trust policy executor is deployed in a different executor environment, ensuring that it is almost impossible for an attacker to find a universal vulnerability to attack all executors at the same time. Each heterogeneous zero-trust policy executor can be operating system heterogeneous, zero-trust policy dimension heterogeneous, or zero-trust policy rule programming language heterogeneous. By periodically replacing the executor environment of each heterogeneous zero-trust policy executor, an attacker cannot establish a stable attack path. By constructing a highly heterogeneous and dynamically changing policy executor pool, the system has stronger defense capabilities against unknown vulnerabilities and backdoors.

[0009] Optionally, the rule checking on the first access request generates a decision execution result, including: performing rule checking on at least one security dimension of user identity, device state, network environment, behavior pattern, and data identifier in the first access request to generate a checking conclusion; and generating a corresponding decision execution result based on the checking conclusion, the decision execution result including allowing access, limiting access, or denying access.

[0010] The access request is placed in a complete context composed of user identity, device state, network environment, behavior pattern, and data identifier for comprehensive evaluation. Each heterogeneous zero-trust policy executor independently generates its own checking conclusion. Different executors may draw different conclusions for the same access request, thereby realizing intelligent and dynamic comprehensive security evaluation and providing accurate and reliable input for generating a ruling result.

[0011] Optionally, the multiple decision execution results are subjected to multi-mode arbitration to obtain an arbitration result, including: if any decision execution result is to reject access, the arbitration result is to reject access; if all decision execution results are to allow access, the arbitration result is to allow access; if all decision execution results are not to reject and there is at least one to limit access, the arbitration result is to limit access.

[0012] By replacing a single policy execution point with a dynamic, heterogeneous, and redundant execution cluster, and arbitrating their outputs, the security defense is changed from relying on the "absolute correctness of a single execution body" to relying on the "coordinated consensus of multiple heterogeneous execution bodies", greatly improving the system's invasion capacity and reliability. Even if some heterogeneous execution bodies have been broken, failed or produced false positives, the system can still make correct security decisions, completely eliminating single-point failures.

[0013] Optionally, based on the verification conclusion, a corresponding decision execution result is generated, including: if all security dimensions are verified, the decision execution result is generated to allow access; if any core security dimension fails to pass the verification, the decision execution result is generated to reject access; if all core security dimensions pass the verification and there is a non-core security dimension that fails to pass the verification, the decision execution result is generated to limit access.

[0014] By distinguishing core security dimensions and non-core security dimensions, complex security verification is converted into refined decision execution results, not only strictly guarding the security bottom line, but also achieving intelligent response to access request context risks, minimizing the interference of security rules on legitimate business under the premise of ensuring security, and achieving dynamic adaptive security protection.

[0015] Optionally, based on the arbitration result, the first access request is subjected to access control, including: if the arbitration result is to allow access, the data packet of the first access request is forwarded to the corresponding server; if the arbitration result is to limit access, the first access request is divided into a query type request and an operation type request, the data packet of the query type request is forwarded to the corresponding server, and the data packet of the operation type request is discarded; if the arbitration result is to reject access, the data packet of the first access request is discarded.

[0016] By accurately converting the arbitration result into a control action on the data packet of the first access request, threats are blocked, and closed-loop execution of security policies is achieved. By pre-filtering, the backend server is effectively protected, and the attack surface is reduced.

[0017] Optionally, the local security policy verification is performed on the user access request, including: performing compliance verification on at least one dimension of an initiating process, a device security state and a user token of the user access request based on a pre-configured security policy rule set locally; and if the verification is passed, a first access request of verification passed is generated.

[0018] By locally intercepting a large number of obviously invalid or malicious requests at the terminal, it is avoided that they occupy network bandwidth and computing resources of a cloud heterogeneous executor, and the accuracy and efficiency of overall security analysis are improved. The starting point of security control is pushed from the cloud to each terminal device, and real "edge security" is realized.

[0019] In a second aspect, an embodiment of the present application provides an endogenous security-based zero-trust security protection system, which comprises: a local verification module, configured to acquire a user access request sent by a terminal device; perform local security policy verification on the user access request to obtain a first access request of verification passed, and send the first access request to a plurality of heterogeneous zero-trust policy executors respectively; a rule checking module, configured to perform rule checking on the first access request for any heterogeneous zero-trust policy executor to generate a decision execution result; and a decision module, configured to perform multi-mode decision on each decision execution result to obtain a decision result, and perform access control on the first access request based on the decision result.

[0020] In a third aspect, an embodiment of the present application provides a computer device, comprising: a memory and a processor, which are in communication connection with each other, and the memory stores computer instructions; the processor executes the computer instructions to perform the endogenous security-based zero-trust security protection method described above.

[0021] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, which stores computer instructions, and the computer instructions are used to make a computer execute the endogenous security-based zero-trust security protection method described above.

[0022] In a fifth aspect, an embodiment of the present application provides a computer program product, which comprises computer instructions, and the computer instructions are used to make a computer execute the endogenous security-based zero-trust security protection method described above. BRIEF DESCRIPTION OF DRAWINGS

[0023] In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the drawings needed in the specific embodiments or the prior art description will be briefly introduced as follows. Obviously, the drawings in the following description are some embodiments of the present application, and those skilled in the art can also obtain other drawings according to these drawings without creative labor.

[0024] Figure 1 A flowchart of the zero-trust security protection method based on endogenous security provided for the embodiments of the present application is shown in FIG. 1;

[0025] Figure 2 A schematic diagram of the zero-trust security protection system based on endogenous security provided for the embodiments of the present application is shown in FIG. 2;

[0026] Figure 3 A structural schematic diagram of the zero-trust security protection system provided for the embodiments of the present application is shown in FIG. 3;

[0027] Figure 4 A flowchart of the zero-trust security protection process provided for the embodiments of the present application is shown in FIG. 4;

[0028] Figure 5 A structural schematic diagram of a computer device provided for the embodiments of the present application is shown in FIG. 5. DETAILED DESCRIPTION

[0029] In order to make the purposes, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0030] With the deepening of digital transformation, the network scale and software as a service (Saas, Software as a Service) applications are becoming increasingly complex, and the hybrid office mode has become a new trend. This trend has promoted business development while leading to an explosive growth in the network attack surface. In particular, unknown vulnerabilities and backdoors widely existing in cloud network environments have become a major threat to current network information security, as they are difficult to defend through traditional feature identification methods. Zero trust network security architecture has emerged as the times require, with its core principles including "never trust, always verify", minimum privilege access, and continuous security checks. This architecture effectively addresses the security challenges brought about by blurred boundaries by conducting strict authentication and authorization at each access request, thereby improving the security of enterprise networks to some extent. However, the relevant zero trust security architecture is still essentially a single-point defense system. Its core components, such as policy enforcement points (PEP, Policy Enforcement Point), still have the risk of single point of failure (Single Point of Failure) on the entire access link, and their decision logic and execution logic are isomorphic, essentially a "single point". Once attackers exploit unknown vulnerabilities or hidden backdoors in the policy enforcement point itself, they can bypass multiple verification mechanisms and achieve malicious access and control of application systems or data. In the context of cloud network integration and complex technology stacks, software and hardware vulnerabilities are inevitable, which makes the zero trust architecture based on a single-point defense architecture inherently insufficient in protecting against advanced persistent threats (APT) and unknown vulnerability exploitation, and unable to fundamentally avoid the harm caused by unknown threats.

[0031] Endogenous Security defense theory provides a new approach to solving the above fundamental problems. Instead of striving to completely eliminate vulnerabilities, this theory confronts the objective fact of widespread vulnerabilities in systems by building multiple functionally equivalent, heterogeneous redundant executors and introducing dynamics, diversity, and randomness, making the system's defense environment and behavior difficult to predict, thereby significantly reducing the exploitability of vulnerabilities and backdoors. Its core is the multi-modal decision mechanism of multiple executors, which can still produce correct output results even if some components are compromised, achieving intrusion tolerance. How to deeply integrate endogenous security with zero trust architecture to overcome the vulnerability of zero trust architecture in protecting against unknown vulnerabilities and build a more resilient and reliable security protection system has become a key technical problem that needs to be solved in this field.

[0032] The embodiment of the application provides a zero-trust security protection method based on endogenous security, which is suitable for government-enterprise networks, financial networks, cloud computing, Internet of Things and industrial Internet, and aims to strengthen the defense capability of the zero-trust architecture and provide effective protection against unknown vulnerabilities and backdoors and other security threats that are difficult to deal with.

[0033] It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in an order different from that shown.

[0034] Reference Figure 1 , Figure 1 The flowchart of the zero-trust security protection method based on endogenous security provided by the embodiment of the application is shown in Figure 1 , and the flowchart includes the following steps:

[0035] Step S1, obtaining a user access request sent by a terminal device, performing local security policy verification on the user access request, obtaining a first access request that passes the verification, and sending the first access request to a plurality of heterogeneous zero-trust policy executors.

[0036] The terminal device is a tool for users to access a network and access resources, including but not limited to an employee's office computer, notebook computer, smart phone, tablet computer, and sensors in the Internet of Things scenario and industrial control devices in the industrial Internet. The location of the terminal device can be a branch office, an employee's home, or even anywhere at any time. The user access request includes user identity information, device information, a target server to be accessed, a request operation type (reading, writing, deleting, etc.), and the like. Generally, the user access request is verified by a proxy software (i.e., a terminal data proxy) on the terminal device for local security policy, which is used to preliminarily intercept very obvious, low-level malicious or non-compliant requests, which is beneficial to reduce the processing pressure of the heterogeneous zero-trust policy executors in the cloud and improve the processing efficiency of the entire system.

[0037] The heterogeneous zero-trust policy executor refers to a plurality of security policy decision engines deployed in the cloud, which are functionally identical but have different implementation manners. These heterogeneous zero-trust policy executors differ in operating systems (for example, Linux or Windows Server), policy programming languages (for example, GoLang or C++), policy rule dimensions (for example, focusing on behavior analysis, focusing on identity authentication), and the like. Since the executors are heterogeneous, it is almost impossible for an attacker to find an exploit method that can attack all executors at the same time, avoiding the risk of overall loss due to the attack on a single point in the traditional architecture. As long as one healthy executor detects an anomaly, the attack will fail. For example, even if the attacker finds a vulnerability in executor A, he cannot use the vulnerability to attack executors B or C.

[0038] Step S3, for any heterogeneous zero-trust policy executor, rule checking is performed on the first access request to generate a decision execution result.

[0039] Each heterogeneous zero-trust policy executor independently performs rule checking on the first access request. Each heterogeneous zero-trust policy executor independently generates a decision execution result, such as allowing, rejecting, or limiting access. By performing rule checking on the same first access request in parallel, independently, and heterogeneously by multiple executors, the blind spots and vulnerabilities that may exist in a single component are eliminated, and the security of the overall system is improved. Here, the single component refers to the logically centralized and homogeneous policy execution point in the traditional zero-trust architecture.

[0040] Step S5, multi-modal arbitration is performed on each decision execution result to obtain an arbitration result, and access control is performed on the first access request based on the arbitration result.

[0041] Multi-modal arbitration can be performed by an arbitrator to comprehensively analyze each decision execution result and make an arbitration result according to predetermined security rules. This mechanism realizes intrusion tolerance. Since the executors are heterogeneous, even if a certain executor is attacked due to an unknown vulnerability and makes a false "allow" decision, as long as one healthy executor makes a correct "reject" decision, the attack can be ultimately blocked, thereby improving the resilience of the system when facing unknown threats. Based on the arbitration result, precise control actions are performed on the first access request. For example, if the arbitration result is to allow, the data packet of the first access request is normally forwarded to the application server. If the arbitration result is to reject, the access request is blocked and a rejection response is returned. If the final arbitration is to limit access, the data packet of the first access request is selectively forwarded.

[0042] The zero-trust security protection method based on endogenous security provided by the embodiments of the present application can pre-filter invalid requests by performing local security policy verification on user access requests, thereby reducing the cloud processing load and improving the system processing efficiency. The first access request that passes the verification is sent to a plurality of heterogeneous policy executors for parallel rule checking, and the diversity design makes it difficult for attackers to exploit the same vulnerability to break all executors, thereby increasing the attack cost and difficulty. The decision execution results output by the heterogeneous policy executors are cooperatively decided by a multi-mode decision, so that even if part of the executors are broken, the system can still make correct judgments, realize intrusion tolerance, effectively defend unknown vulnerabilities, eliminate single-point failure risks, and improve the reliability and resilience of the system.

[0043] In some embodiments, each heterogeneous zero-trust policy executor is deployed in a different executor environment; the plurality of heterogeneous zero-trust policy executors are heterogeneous in at least one of an operating system, a zero-trust policy dimension, and a zero-trust policy rule programming language; and for any heterogeneous zero-trust policy executor, the executor environment of the heterogeneous zero-trust policy executor is periodically replaced.

[0044] The executor environment refers to the sum of all software and hardware basic supports on which the heterogeneous zero-trust policy executor runs, such as servers, operating environments, etc. If all executors are deployed in the same executor environment, i.e., share the same underlying environment, it means that once the attacker finds a vulnerability in this underlying environment, he can use the same attack method to break all other executors. Deploying each heterogeneous zero-trust policy executor in a different executor environment ensures that the attacker is almost impossible to find a common vulnerability to attack all executors at the same time. Each heterogeneous zero-trust policy executor can be heterogeneous in operating system, zero-trust policy dimension, or zero-trust policy rule programming language. By periodically replacing the executor environment of each heterogeneous zero-trust policy executor, such as switching to cloud hosts in different regions, updating the operating system version, etc., the attacker cannot establish a stable attack path. By constructing a highly heterogeneous and dynamically changing policy executor pool, the system has stronger defense capabilities against unknown vulnerabilities and backdoors.

[0045] In some embodiments, the rule checking on the first access request generates a decision execution result, including: based on the principle of least privilege, performing rule checking on at least one security dimension in the user identity, device state, network environment, behavior pattern, and data identifier in the first access request, and generating a checking conclusion; based on the checking conclusion, generating a corresponding decision execution result, the decision execution result including allowing access, limiting access, or denying access.

[0046] Rule verification refers to the process of comparing and analyzing the received access request with the preset security policy rules by the policy executor. The principle of least privilege refers to granting only the most stringent permission necessary to perform the current task, and everything else is denied. For example, a user initiates an access request, and the user only needs "read-only" permission to complete the task. After rule verification, only "read-only" permission is granted, and no permission to modify, delete, or access other files is granted. Rule verification of user identity can be whether the identity credential is valid, whether the token is expired, etc.; rule verification of device state can be whether the device is registered, whether the key security software (such as antivirus software) is running, whether the operating system has a serious vulnerability, etc.; rule verification of network environment can be whether the access is from the company intranet or the public coffee shop Wi-Fi; rule verification of behavior pattern can be whether the access time is within normal working hours, whether the access frequency is abnormal; rule verification of data identification can be whether the accessed data is public information or core business secrets, etc.

[0047] In a specific verification process, the complete context corresponding to the user access request can be comprehensively evaluated. The complete context can represent feature information of various aspects such as user identity, device state, network environment, behavior pattern, and data identification. In actual application, for each feature information, different information states can be corresponded. For example, for user identity, the corresponding information state can represent the matching relationship between the username and the password; for example, for device state, the corresponding information state can represent whether the device is in a secure environment. In the specific evaluation process, each of the above feature information can be traversed, and the current information state of each feature information can be verified. Finally, by summarizing the verified information state, it can be determined whether the current user access request is verified.

[0048] In a specific application example, a correct username and password (user identity) from a device that does not install antivirus software (device state) and accesses the company's core financial data (data identification) from overseas at 3 a.m. (network environment, behavior pattern) has a high risk coefficient, and the system can capture this anomaly. The verification conclusion includes verification pass, verification exception, and verification failure, and the verification conclusion is the direct basis for generating the decision execution result.

[0049] Each heterogeneous zero-trust policy executor independently generates its own verification conclusion. Since the strategies of each executor may be different, different verification conclusions may be obtained for the same access request, thereby realizing intelligent and dynamic comprehensive security evaluation and providing accurate and reliable input for generating the ruling result.

[0050] In some embodiments, the multiple-mode decision is made based on the decision execution results of the respective decisions, and a decision result is generated, including: if any of the decision execution results is to deny access, the decision result is to deny access; if all of the decision execution results are to allow access, the decision result is to allow access; and if all of the decision execution results are neither to deny nor to limit access, the decision result is to limit access.

[0051] The multiple-mode decision is made based on the decision execution results of the respective decisions according to the principle of minimum-privilege decision. The principle of minimum-privilege decision means that if there is a decision execution result of deny from any of the execution bodies, the final decision is to deny; if there is no deny but a limit access in the decision execution results output by the respective execution bodies, the final decision is to limit access; and only when all of the decision execution results are to allow, the decision result is to allow.

[0052] By replacing a single policy execution point with a dynamic, heterogeneous, and redundant cluster of execution bodies, and making consistent decisions on their outputs, the security defense is changed from relying on the absolute correctness of a single policy execution point to relying on the coordinated consensus of multiple heterogeneous execution bodies, greatly improving the system's invasiveness and reliability. Even if some heterogeneous execution bodies have been broken, failed or produced false positives, the system can still make correct security decisions, completely eliminating single-point failures.

[0053] In some embodiments, based on the verification conclusion, a corresponding decision execution result is generated, including: if all of the security dimensions are verified, the decision execution result is to allow access; if any of the core security dimensions fails the verification, the decision execution result is to deny access; and if all of the core security dimensions pass the verification but there is a non-core security dimension that fails the verification, the decision execution result is to limit access.

[0054] The core security dimension is the bottom line of security, usually related to user identity and device status. If the core security dimension fails the verification, it means that the access request has a fundamental and unacceptable security risk. The non-core security dimension is used to assess the risk of the access context, which determines the risk level of the access. The non-core security dimension includes network environment, behavior pattern, and data identification. The verification results of the respective security dimensions are usually binary, either pass or fail.

[0055] If all of the security dimensions pass the verification, the access is allowed. If the core security dimension fails the verification, it means that the access is high-risk and must be blocked immediately. If the core security dimension passes the verification but the non-core security dimension fails the verification, it means that the identity and device are trustworthy, but the context of the access is risky, for example, a trusted employee accesses sensitive files from a foreign network at night. The system should not completely deny the access, but should grant the minimum privilege to ensure business continuity while controlling the risk.

[0056] By distinguishing the core security dimension and the non-core security dimension, the complex security check is converted into a refined decision execution result, not only strictly guarding the security bottom line, but also realizing intelligent response to the context risk of access requests, minimizing the interference of security rules on legal business under the premise of ensuring security, and realizing dynamic adaptive security protection.

[0057] In some embodiments, the access control on the first access request based on the adjudication result comprises: if the adjudication result is to allow access, forwarding the data packet of the first access request to the corresponding server; if the adjudication result is to limit access, dividing the first access request into a query type request and an operation type request, forwarding the data packet of the query type request to the corresponding server, and discarding the data packet of the operation type request; if the adjudication result is to reject access, discarding the data packet of the first access request.

[0058] For limited access, the query type request is usually a read-only, low-risk operation, and only the data packet of the query type request is forwarded to the target server, which can meet the basic business information acquisition demand; the operation type request involves addition, deletion and modification, and the risk is extremely high, so the corresponding data packet should be discarded. For rejected access, the data packet is discarded directly at the front end, and these flows will not reach the target server. By selectively forwarding and discarding data packets, the computing resources of the back-end server are protected, and the external attack surface of the server is reduced.

[0059] The adjudication result is accurately converted into a control action on the data packet of the first access request, which blocks the threat and realizes the closed-loop execution of the security policy. By pre-filtering, the back-end server is effectively protected, and the attack surface is reduced.

[0060] In some embodiments, the local security policy verification is performed on the user access request, comprising: based on a pre-configured security policy rule set locally, at least one dimension of the user access request, including the initiation process, the device security state and the user token, is verified for compliance; if the verification is passed, a first access request with verification passed is generated.

[0061] Compliance verification refers to the process of quickly comparing the user access request with a set of pre-configured security policy rules locally, including: whether the user token is valid; whether the initiation process is in the allowed whitelist; whether the device security state meets the baseline, such as whether the antivirus software is turned on. Compliance verification is used to intercept those obviously non-compliant, extremely suspicious or unnecessary to waste cloud resources for in-depth analysis. At the same time, verification passed does not mean allowing access. Verification passed only generates a first access request, which will continue to be sent to each heterogeneous zero trust policy execution body for further in-depth check.

[0062] By intercepting a large number of obviously invalid or malicious requests locally at the terminal, it avoids occupying network bandwidth and cloud heterogeneous executors computing resources, and improves the accuracy and efficiency of the overall security analysis. The starting point of security control is pushed from the cloud to each terminal device, realizing real "edge security".

[0063] Please refer to Figure 2 , Figure 2 The endogenous security-based zero-trust security protection system provided in the embodiments of the present application is shown in FIG. 1. The system includes a local verification module, a rule verification module, and a decision module. Figure 2 The local verification module is configured to obtain a user access request sent by a terminal device, perform local security policy verification on the user access request, obtain a first access request that passes the verification, and send the first access request to a plurality of heterogeneous zero-trust policy executors.

[0064] Please refer to Figure 3 , Figure 3 The structure of the zero-trust security protection system is shown in FIG. 2. The local verification module can be a terminal data agent, which is a lightweight software agent deployed on a terminal device. As a client component in the zero-trust network security architecture, the terminal data agent moves the security control point to the terminal device, realizing true zero-trust access. Figure 3

[0065] Please refer to Figure 4 , Figure 4 The zero-trust security protection process is shown in FIG. 3. In the initialization phase, the terminal data agent establishes a secure connection with the zero-trust security cloud, dynamically obtains the IP address and other access path information of the current zero-trust policy executor pool (including a plurality of heterogeneous zero-trust policy executors), and establishes an encrypted channel. The user initiates a data access request to the enterprise data center, public cloud or Web service through the agent. The agent first collects terminal device attributes, context environment and other information, coordinates the security service chain to perform access control, and performs preliminary verification according to the local security policy. The terminal data agent distributes the access request verified by the local policy in parallel to the known plurality of dynamic heterogeneous zero-trust policy executors, and synchronously waits for the response results. Figure 4

[0066] ​​The rule verification module is deployed in each heterogeneous zero-trust policy executor of the zero-trust policy executor pool. The zero-trust policy executor pool is deployed on a public cloud infrastructure, and each executor is distributed in different regions and sites of different cloud service providers, and is fully heterogeneous in three levels of operating system, policy dimension and programming language. For example, at the operating system level, the policy programs of each heterogeneous zero-trust policy executor run on different public cloud platforms, each cloud service provider provides at least three completely independent regional units, and the operating system covers multiple versions such as Windows and Linux, realizing double diversity of system type and version. At the policy dimension level, the heterogeneous zero-trust policy executors deployed on each cloud platform are independent of each other and cover one or more control principles such as minimum permission access, continuous identity verification and micro-isolation. At the programming language level, different languages such as Java, Python, Go and C++ are used to implement policy logic, further enhancing the implementation diversity.

[0067] After each executor receives the access request of the terminal data agent, it performs rule verification on the operation between the access subject and the access target from multiple dimensions such as user identity, device state, network environment, behavior pattern and data identifier according to the principle of "never trust, always verify", and strictly implements the principle of minimum permission to grant only the necessary permissions after verification. After the verification is completed, each executor generates one of the three types of decision execution results: allow, limit access or reject, and sends the decision execution result to the zero-trust verification result adjudicator for unified adjudication.

[0068] The adjudication module can be a zero-trust verification result adjudicator, and its core function is to compare the decision execution results reported by each executor and make a final decision according to the principle of minimum permission, i.e. selecting the result with the lowest permission among all decision execution results as the output. The permissions of the three types of decision execution results are ranked from high to low as follows: allow > limit access > reject. If any executor feedback is "reject", the adjudication result is "reject". If the adjudication result is abnormal (i.e. reject access), the access is blocked and a reject response is returned. If the adjudication result is normal, the access request data is forwarded to the target server. If there is an executor feedback of "limit access" and no "reject" result, the final decision is "limit access", only query type requests are allowed, and other operations are rejected. Only when all executors consistently feedback "allow", the adjudication result is "allow", at this time, the access request of the terminal data agent is allowed to pass through, and the request is forwarded to the target server.

[0069] The zero-trust security protection system based on endogenous security proposed in the present application effectively makes up for the defense deficiency of the traditional zero-trust architecture in dealing with unknown vulnerabilities and backdoors, and provides comprehensive and three-dimensional security protection capability for complex scenarios such as cloud network integration through a multi-level and dynamic defense system.

[0070] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0071] In this embodiment, the zero-trust security protection system based on intrinsic security is presented in the form of functional units. Here, a unit refers to an ASIC (Application Specific Integrated Circuit), a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0072] Please see Figure 5 , Figure 5 This application provides a schematic diagram of the structure of a computer device, as shown in the embodiment of the present application. Figure 5 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 5 Take a processor 10 as an example.

[0073] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0074] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0075] The memory 20 can include a program storage area and a data storage area. The program storage area can store an operating system, application programs required by at least one function, etc. The data storage area can store data created according to the use of the computer device, etc. In addition, the memory 20 can include a high-speed random access memory, and can also include a non-transitory memory such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. In some alternative embodiments, the memory 20 can optionally include a memory disposed remotely from the processor 10, which can be connected to the computer device through a network. Examples of the network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0076] The memory 20 can include a volatile memory such as a random access memory, and can also include a non-volatile memory such as a flash memory, a hard disk, or a solid state disk. The memory 20 can also include a combination of the above-mentioned kinds of memories.

[0077] The computer device also includes a communication interface 30 for communication of the computer device with other devices or communication networks.

[0078] The embodiments of the present application also provide a computer readable storage medium. The above-mentioned method according to the embodiments of the present application can be implemented in hardware, firmware, or recorded in a storage medium, or implemented as computer code originally stored in a remote storage medium or non-transitory machine readable storage medium and downloaded to a local storage medium, so that the method described herein can be processed by such software on a storage medium using a general-purpose computer, a special-purpose processor, or programmable or special-purpose hardware. The storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid state disk, etc. Further, the storage medium can also include a combination of the above-mentioned kinds of memories. It can be understood that the computer, the processor, the microprocessor controller, or the programmable hardware includes a storage component that can store or receive software or computer code, which, when accessed and executed by the computer, the processor, or the hardware, implements the method shown in the above-mentioned embodiments.

[0079] The embodiments of the present application provide a computer program product, which includes 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 to make the computer device execute the method of any of the embodiments of the present application.

[0080] The systems and modules described above can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0081] For the sake of description, the above apparatus is described in various units according to functions for description. Of course, the functions of the units can be implemented in one or more software and / or hardware in implementing the present application.

[0082] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) containing computer-usable program code.

[0083] The present application is described with reference to the flowcharts and / or block diagrams of the methods, systems and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and a combination of flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus generate a means for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in a flow or multiple flows and / or blocks Figure 1 The functions specified in a flow or multiple flows and / or blocks

[0084] These computer program instructions can also be stored in a computer-readable memory that can direct the computer or other programmable data processing apparatus to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including instruction means, which implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in a flow or multiple flows and / or blocks Figure 1 The functions specified in a flow or multiple flows and / or blocks

[0085] These computer program instructions can also be loaded into a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 Figure 1

[0086] It should also be noted that the term "comprising" or "comprises" when used in this specification is taken to mean the inclusion of one or more steps or elements from any one of the embodiments of the process, method, article or apparatus that follow the term, but not excluding others. It will be understood by those within the art that any alteration and further modifications of the method and system illustrated are possible and within the scope of the disclosure. Such alternations of the above illustrated methods and apparatus become apparent to those skilled in the art upon reading this disclosure.

[0087] Various embodiments of the present application are described herein with reference to the following drawings on which:

[0088] The above description is embodied in the form of embodiments and is not intended to limit the present application. Various modifications and changes can be made by those skilled in the art without departing from the spirit and scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

[0089] Although the embodiments of the present application are described with reference to the drawings, various modifications and changes can be made by those skilled in the art without departing from the spirit and scope of the present application, and such modifications and changes should be included in the scope of the claims of the present application.​​

Claims

1. A zero-trust security protection method based on intrinsic security, characterized in that, The method includes: The system obtains user access requests sent by terminal devices, performs local security policy verification on the user access requests, obtains a first access request that passes verification, and sends the first access request to multiple heterogeneous zero-trust policy executors respectively. For any heterogeneous zero-trust policy executor, the first access request is validated according to rules, and a decision execution result is generated. The results of each decision execution are subject to multi-mode adjudication to obtain an adjudication result, and access control is applied to the first access request based on the adjudication result.

2. The method according to claim 1, characterized in that, The method further includes: deploying each heterogeneous zero-trust policy executor in different execution environments; the multiple heterogeneous zero-trust policy executors are heterogeneous in at least one dimension, namely, operating system, zero-trust policy dimension, and zero-trust policy rule programming language; and periodically changing the execution environment of any heterogeneous zero-trust policy executor.

3. The method according to claim 1, characterized in that, The first access request is subjected to rule validation, and a decision execution result is generated, including: Perform rule verification on at least one security dimension among user identity, device status, network environment, behavior pattern, and data identifier in the first access request, and generate a verification conclusion; Based on the verification results, corresponding decision execution results are generated, including allowing access, restricting access, or denying access.

4. The method according to claim 3, characterized in that, The results of each decision implementation are evaluated using a multi-mode adjudication process to obtain the following adjudication results: If any decision results in access denial, then the ruling is access denial. If the outcome of each decision is to allow access, then the ruling is to allow access. If none of the decisions result in a rejection and at least one decision restricts access, then the decision is to restrict access.

5. The method according to claim 3, characterized in that, Based on the verification results, corresponding decision execution results are generated, including: If all security dimensions pass the verification, the generated decision execution result is to allow access; If any core security dimension fails the verification, the resulting decision is to deny access. If all core security dimensions pass the verification but some non-core security dimensions fail the verification, the resulting decision is to restrict access.

6. The method according to claim 1, characterized in that, Based on the ruling result, access control is applied to the first access request, including: If the ruling is to allow access, the data packet of the first access request will be forwarded to the corresponding server; If the ruling is to restrict access, the first access request is divided into query requests and operation requests. The data packets of the query requests are forwarded to the corresponding servers, and the data packets of the operation requests are discarded. If the decision is to deny access, the data packet of the first access request is discarded.

7. The method according to claim 1, characterized in that, Performing local security policy verification on the user access request includes: Based on a pre-configured set of security policy rules, compliance verification is performed on at least one dimension of the user access request initiating process, device security status, and user token. If the verification passes, a first access request that has passed verification is generated.

8. A zero-trust security protection system based on intrinsic security, characterized in that, The system includes: The local verification module is used to obtain user access requests sent by terminal devices; perform local security policy verification on the user access requests to obtain a first access request that has passed verification; and send the first access request to multiple heterogeneous zero-trust policy executors respectively. The rule verification module is used to perform rule verification on the first access request for any heterogeneous zero-trust policy executor and generate a decision execution result. The adjudication module is used to perform multi-mode adjudication on the execution results of various decisions, obtain the adjudication result, and perform access control on the first access request based on the adjudication result.

9. A computer device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the zero-trust security protection method based on intrinsic security as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the zero-trust security protection method based on intrinsic security as described in any one of claims 1 to 7.

Images