Data security authority management method and system based on service side

Abstract

The invention discloses a data security authority management method and system based on a service side, and relates to the field of data security, and the method comprises the steps that a public network server verifies an access request signature, and for an access request passing verification, the public network server judges whether an executable environment SGX is adopted or not according to the security level and the timeliness requirement of the access request; when it is judged that the executable environment SGX is adopted, the corresponding access request is sent to a first micro sandbox pool; otherwise, the corresponding access request is sent to the second micro sandbox pool; the first micro sandbox pool checks the access request by using a preset information library and an executable environment SGX, encrypts the access request passing the check by using an encryption algorithm, and sends the encrypted access request to a mirror image server; the second micro sandbox pool checks the access request by using a preset information library; the efficiency is improved for the problem that the sandbox technology in the prior art is low in efficiency when processing high-concurrency access requests.

Description

Technical Field

[0001] The present application relates to the field of data security, and in particular to a data security authority management method and system based on the service side. Background Art

[0002] With the rapid development and popularization of Internet technology, data security issues have become increasingly prominent. In various information systems, service-side data access control has become a key link in ensuring data security. Traditional data security permission management usually uses independently deployed security components, such as firewalls and intrusion detection systems, to perform coarse-grained inspections and filtering of access requests. However, this approach is difficult to cope with increasingly complex security threats, and when faced with massive concurrent requests, there are often performance bottlenecks and single point failure risks.

[0003] In order to improve the refinement and flexibility of data access control, the industry has introduced sandbox technology. Sandbox provides an independent execution environment for access requests, and prevents malicious code damage and data leakage through resource isolation and access restrictions. However, traditional sandbox technology still has the problem of low efficiency when processing high-concurrency access requests. The security isolation mechanism of the sandbox will introduce additional performance overhead, especially in high-concurrency scenarios, where frequent context switching and memory copy operations greatly affect the system's response speed and throughput.

[0004] For example, the relevant document CN114268459A discloses a data security access method based on the service side; this solution converts the first-level access request sent by the client into a second-level access request through a public network server, and sends the second-level access request to the message queue module, the message queue module sends the second-level access request to the sandbox module for compliance verification, if the compliance verification passes, the sandbox module sends the second-level access request to the mirror server, the mirror server generates a feedback response according to the received second-level access request, and sends the feedback response to the message queue module, the message queue module sends the received feedback response to the public network server, and the public network server sends the received feedback response back to the client; however, this solution uses a single sandbox module to verify and execute all access requests, without considering the differences in security levels and timeliness requirements of the requests, resulting in low utilization of sandbox resources and difficulty in meeting performance requirements in high concurrency scenarios. Summary of the invention

[0005] In response to the problem that the sandbox technology in the prior art is inefficient when processing high-concurrency access requests, the present application provides a data security permission management method and system based on the service side, which adopts micro-sandbox isolation technology to dynamically allocate access requests with different security levels and time requirements to the corresponding micro-sandbox pool for processing, thereby improving efficiency.

[0006] The purpose of this application is achieved through the following technical solutions.

[0007] One aspect of the present application provides a data security permission management method based on the service side, including: S1, a client sends a digitally signed access request to a public network server; S2, the public network server verifies the access request signature, and for the access request that passes the verification, the public network server determines whether to adopt the executable environment SGX according to the security level and timeliness requirements of the access request; when it is determined that the executable environment SGX is adopted, the corresponding access request is sent to a first message queue; otherwise, the corresponding access request is sent to a second message queue; the first message queue sends the access request to a first micro-sandbox pool; the second message queue sends the access request to a second micro-sandbox pool; the security level of the first message queue is greater than that of the second micro-sandbox pool. Two message queues, the first micro-sandbox pool integrates SGX hardware support, and the second micro-sandbox pool does not integrate SGX hardware support; S3, the first micro-sandbox pool uses the preset intelligence library and the executable environment SGX to check the access request, and for the access request that passes the check, it uses the encryption algorithm to encrypt it and sends it to the mirror server, otherwise the corresponding access request is rejected; S4, the second micro-sandbox pool uses the preset intelligence library to check the access request, and for the access request that passes the check, it uses the encryption algorithm to encrypt it and sends it to the mirror server, otherwise the corresponding access request is rejected; S5, the mirror server obtains the corresponding response data according to the access request, and sends the response data to the first micro-sandbox pool or the second micro-sandbox pool;

[0008] Among them, the Micro-Sandbox Pool is a secure and isolated execution environment for inspecting and processing access requests. It prevents the execution of malicious code and illegal access to data through fine-grained control and monitoring of requests, and provides a lightweight security container mechanism. In this application, there are two types of micro-sandbox pools: a first micro-sandbox pool and a second micro-sandbox pool. The first micro-sandbox pool integrates SGX hardware support and has a higher security level, which is used to process access requests with higher sensitivity and strong timeliness requirements; the second micro-sandbox pool does not integrate SGX hardware support and has a relatively low security level, which is used to process general access requests. By distributing requests to micro-sandbox pools of different security levels, hierarchical processing and isolation of access requests can be achieved, thereby improving the security and efficiency of the system.

[0009] SGX hardware support (Intel SGX Hardware Support) is a hardware-based trusted execution environment technology provided by Intel. It ensures the confidentiality and integrity of sensitive code and data from being affected by malware and the operating system by encapsulating them in a protected memory area called an "enclave". SGX hardware support includes a series of security instructions and hardware mechanisms, such as enclave creation, destruction, entry and exit, as well as memory encryption, integrity protection, etc. These hardware-level security features provide the basis for building a trusted computing environment, so that even in an untrusted system environment, the security of critical code and data can be guaranteed. In this application, the first micro-sandbox pool integrates SGX hardware support, which provides a higher level of security protection by encapsulating sensitive requests and data in an enclave for processing, preventing the threat of privileged software and physical attacks. This hardware-assisted trusted execution mechanism greatly improves the system's ability to resist attacks and protect data.

[0010] The mirror server is an intermediate server for processing access requests and obtaining response data. It receives encrypted requests from the micro-sandbox pool, obtains the corresponding response data from the back-end service or data storage according to the content of the request, and then returns the encrypted response data to the micro-sandbox pool. The main function of the mirror server is to isolate the micro-sandbox pool from the back-end service, prevent the micro-sandbox pool from directly contacting sensitive back-end resources, and reduce the potential attack surface. At the same time, the mirror server also plays the role of load balancing and caching. By distributing requests to multiple back-end nodes and caching commonly used response data, the performance and scalability of the system are improved. In this application, the mirror server acts as a bridge between the micro-sandbox pool and the back-end service, realizes the forwarding of requests and the acquisition of data, and at the same time, through encrypted communication and data isolation, ensures the security of data during transmission and processing. This middle-layer design pattern improves the flexibility and maintainability of the system and facilitates the upgrading and improvement of the security mechanism.

[0011] Furthermore, S2, the public network server verifies the signature of the access request. For the access request that passes the verification, the public network server determines whether to adopt the executable environment SGX according to the security level and timeliness requirements of the access request, including: S21, the public network server extracts characteristic parameters from the access request, and the characteristic parameters include the security level; S22, according to the extracted characteristic parameters, constructs a classification model based on the ordered classification tree OC1; S23, uses the integrated learning strategy Bagging to strengthen the classification model to obtain the Bagging decision tree strong classifier; S24, uses the Bagging decision tree strong classifier to determine whether the access request adopts the executable environment SGX.

[0012] Among them, the ordered classification tree OC1 is a decision tree algorithm for building a classification model. It divides the sample space into different sub-areas by recursively selecting the optimal partitioning attribute to generate a top-down decision tree. The characteristic of the OC1 algorithm is that at each internal node, according to the ordered nature of the attribute, the optimal binary partitioning point is selected to divide the sample into two left and right subsets. This partitioning method based on ordered attributes can effectively handle continuous and ordered discrete attributes and generate more compact and interpretable decision trees. In this application, step S22 uses the characteristic parameters of the access request to construct a classification model through the OC1 algorithm. The model uses features such as security level as partitioning attributes to generate a decision tree for determining whether to adopt the SGX environment. The ordered nature of the OC1 algorithm enables the constructed classification model to better adapt to continuous security level attributes and improve the accuracy and efficiency of classification.

[0013] The executable environment SGX (Intel Software Guard Extensions) provides a trusted execution space independent of the operating system, so that even in an untrusted system environment, the confidentiality and integrity of key code and data can be protected. This hardware-level security isolation mechanism greatly improves the system's ability to resist attacks and protect data. In this application, step S24 uses the trained Bagging decision tree strong classifier to determine whether the access request needs to use the SGX executable environment. For requests with higher security levels and stronger timeliness requirements, the classifier tends to assign them to the SGX environment for execution to provide a higher level of security protection; for general requests, they can be processed in a normal environment to balance security and performance. Through the selective use of the SGX executable environment, the scheme realizes hierarchical processing and dynamic scheduling of access requests, improving the security and flexibility of the system.

[0014] Further, S22, according to the extracted feature parameters, constructs a classification model based on the ordered classification tree OC1, including: collecting historical access request data as training samples; marking whether each access request sample adopts the executable environment SGX; extracting the security level features of each access request sample, and combining the extracted security level features and the label of whether the executable environment SGX is adopted to form a training sample set; using the security level features in the training sample set as the input of the ordered classification tree OC1, and whether the executable environment SGX is adopted as the classification target; according to the security level features of the current sample node, by calculating the Gini index of the node, the optimal splitting point is obtained; according to the optimal splitting point, the current sample node is divided into two child nodes, and the child nodes are recursively split until the preset stopping condition is met, and the ordered classification tree OC1 is obtained as the classification model.

[0015] Further, S3, the first micro-sandbox pool uses a preset intelligence library and an executable environment SGX to verify the access request, and for the access request that passes the verification, it is encrypted by an encryption algorithm and sent to the mirror server, otherwise the corresponding access request is rejected, including: S31, the first micro-sandbox pool uses a preset intelligence library to perform a first verification on the access request, if the verification passes, execute step S32, otherwise the corresponding access request is rejected; S32, the first micro-sandbox pool sends the access request that passes the first verification to the executable environment SGX, and in the executable environment SGX, the access request is verified for a second time by a formal verification method, if it passes, execute step S33, otherwise the corresponding access request is rejected; S33, the first micro-sandbox pool encrypts the request parameters, request header and request body of the access request to generate an encrypted access request; S34, the first micro-sandbox pool sends the encrypted access request to the mirror server; the first micro-sandbox pool and the mirror server pre-negotiate to generate an AES session key as a shared key.

[0016] Furthermore, the access request is verified for the second time through a formal verification method, including: defining symbolic variables of the access request, and constructing a request expression Req_Sym according to the symbolic variables; the symbolic variables include a request parameter variable Par_i, a request header variable Hdr_j and a symbolic variable library Sym_Lib, i is the index number of the request parameter, and j is the index number of the request header field; defining a path condition variable Path_Con, with an initial value of an empty set; starting from the entry point of the request expression Req_Sym, using an SMT-based symbolic execution tool to symbolically execute Req_Sym to explore all executable paths; during the symbolic execution process, collecting the conditional expressions Bran_Con_k of each path branch, where k is the index number of the path branch; adding Bran_Con_k to Path_Con , generate path constraints; define a security policy rule base Rule_Lib, Rule_Lib contains formally defined security constraints; match and replace the symbolic variables in the path constraint Path_Con with the constraint variables in Rule_Lib; merge the constraints in Path_Con and Rule_Lib and convert them into the constraint equation Smt_Equ; input the constraint equation Smt_Equ into the SMT solver, the SMT solver makes a satisfiability judgment on Smt_Equ, and obtains the solution result Smt_Res; if Smt_Res is satisfiable, it means that there is a set of symbolic variables whose values ​​satisfy Smt_Equ, and the access request is rejected; if Smt_Res is unsatisfiable, it means that there is no symbolic variable whose value satisfies Smt_Equ, and step S33 is executed.

[0017] Among them, the symbolic variable library Sym_Lib is a predefined symbolic variable collection used to represent various data types and value ranges in access requests. It contains common data types, such as integers, floating-point numbers, strings, etc., as well as symbolic variables in some specific fields, such as IP addresses, dates and times, etc. The role of Sym_Lib is to provide a basic variable space for symbolic execution, so that request expressions can use symbolic variables to represent specific data values. By mapping request parameters, request headers, etc. to symbolic variables in Sym_Lib, the request can be abstracted into an expression with symbolic variables, which is convenient for subsequent symbolic execution and constraint solving. In this application, the symbolic variable library Sym_Lib, together with the request parameter variable Par_i and the request header variable Hdr_j, constitute the basic components of the request expression Req_Sym. By introducing Sym_Lib, Req_Sym can represent request data of various types and values, which improves the applicability and flexibility of symbolic execution.

[0018] The path condition variable Path_Con is a variable used to record path constraints during symbolic execution. It represents the conjunction of the path branch conditions from the entry point of the request expression to the current execution position. During the symbolic execution process, whenever a branch condition (such as an if statement) is encountered, the symbolic expression Bran_Con_k of the branch condition is added to Path_Con to form a path constraint. These path constraints describe the conditions that must be met for request execution and determine the direction of the request in the symbolic execution tree. The role of Path_Con is to provide path-related constraints for constraint solving. By merging Path_Con with the constraints in the security policy rule library Rule_Lib to generate a complete constraint equation Smt_Equ, which is then handed over to the SMT solver for satisfiability determination, it can be determined whether the path meets the security requirements. In this application, the path condition variable Path_Con continuously collects path branch conditions during symbolic execution and records the constraints of request execution. Through the construction of Path_Con and the generation of constraint equations, accurate modeling and security analysis of the request execution path are achieved, and the accuracy and reliability of verification are improved.

[0019] The entry point refers to the starting execution position of the request expression Req_Sym, which is usually the starting statement of the request processing function or method. During the symbolic execution process, starting from the entry point, Req_Sym is explored and analyzed along different execution paths. Each execution path represents a possible request processing flow. By exploring all possible paths, the behavior and security of the request can be comprehensively analyzed. The selection of the entry point determines the starting point and scope of the symbolic execution. By setting the entry point reasonably, the specific request processing logic can be analyzed in a targeted manner to improve the efficiency and accuracy of the verification. In this application, symbolic execution is performed starting from the entry point of the request expression Req_Sym, and a comprehensive verification of the request security is achieved by exploring different execution paths and solving constraints. The determination of the entry point provides a clear starting point for symbolic execution, ensuring the integrity and consistency of the verification process.

[0020] SMT solver is an automated reasoning tool for solving satisfiability problems. SMT is the abbreviation of "Satisfiability Modulo Theories", which means "Satisfiability Modulo Theories". The SMT solver accepts a constraint equation Smt_Equ represented in SMT-LIB format as input, which contains a set of Boolean conditions and arithmetic constraints. The solver determines whether there is a set of variable assignments that make all constraints valid at the same time by reasoning and solving the constraint equation. The advantage of the SMT solver lies in its powerful reasoning ability and efficient solution algorithm. By converting the verification problem into a constraint solving problem, the SMT solver can automatically complete complex logical reasoning and security checks, greatly improving the efficiency and accuracy of verification. In this application, the merged constraint equation Smt_Equ is input into the SMT solver for satisfiability judgment. The SMT solver determines whether there is a set of symbolic variable values ​​that satisfy all constraints by solving Smt_Equ, thereby determining whether the request meets the requirements of the security policy. The introduction of SMT solver improves the automation and scalability of verification, and provides powerful tool support for formal verification.

[0021] Satisfiability judgment refers to solving a logical formula or constraint equation to determine whether there is a set of variable assignments that make the formula or equation valid. In formal verification, satisfiability judgment is used to check whether the verification conditions or security attributes can be satisfied. By expressing the property to be verified as a logical formula or constraint equation and using an automated reasoning tool (such as an SMT solver) to perform satisfiability judgment, it is possible to determine whether the property is valid. There are usually two results of satisfiability judgment: satisfiable (SAT) and unsatisfiable (UNSAT). If there is a set of variable assignments that make the constraint equation valid, the judgment result is satisfiable; otherwise, the judgment result is unsatisfiable. In this application, the SMT solver is used to perform satisfiability judgment on the constraint equation Smt_Equ to obtain the solution result Smt_Res. If Smt_Res is satisfiable, it means that there is a set of symbolic variable values ​​that satisfy Smt_Equ, that is, the request violates the security policy and needs to be rejected; otherwise, if Smt_Res is unsatisfiable, it means that the request meets the requirements of the security policy and the request can be released. The introduction of satisfiability judgment makes the verification process have clear judgment basis and results, which improves the reliability and explainability of verification.

[0022] Further, S33, the first micro-sandbox pool encrypts the request parameters, request header and request body of the access request to generate an encrypted access request, including: the first micro-sandbox pool uses the AES-256-GCM algorithm to generate a session key Sess_Key and an initialization vector IV, and extracts the path expression Path_Exp of the access request from the security policy rule library Rule_Lib; the first micro-sandbox pool matches the sensitive data in the request parameters, request header and request body according to the path expression Path_Exp as the sensitive data block Data_i; for each sensitive data block Data_i, the first micro-sandbox pool dynamically generates a padding string Pad_i of a random length, the length range of which is [1, Max_Pad_Len], where Max_Pad_Len is a preset maximum padding length; the first micro-sandbox pool splices the original sensitive data block Data_i with the padding string Pad_i to generate a disturbed data block Obf_Data_i= Data_i||Pad_i; the first micro-sandbox pool performs AES-256-GCM encryption on the disturbed data block Obf_Data_i, and uses the session key Sess_Key and the initialization vector IV to obtain the ciphertext data Enc_Data_i and the authentication tag Tag_i; the first micro-sandbox pool concatenates the padding length information Pad_Len_i with the ciphertext data Enc_Data_i to generate the final ciphertext block Enc_Block_i=Pad_Len_i||Enc_Data_i; the first micro-sandbox pool concatenates the encrypted ciphertext block Enc_Block_i and the authentication tag Tag_i according to the original position and order of the sensitive data to generate complete ciphertext data Enc_Data and authentication tag Tag; the first micro-sandbox pool fills the ciphertext data Enc_Data and the authentication tag Tag back into the corresponding positions of the access request, replaces the original plaintext sensitive data, and generates an encrypted access request Enc_Req.

[0023] Among them, the AES-256-GCM algorithm (Advanced Encryption Standard with 256-bit key in Galois / Counter Mode), in this application, the first micro-sandbox pool uses the AES-256-GCM algorithm to generate the session key Sess_Key and the initialization vector IV, and uses the algorithm to encrypt and authenticate the scrambled sensitive data block. The use of the AES-256-GCM algorithm ensures the confidentiality and integrity of sensitive data during transmission and storage, and prevents eavesdropping, tampering and forgery of data.

[0024] Dynamic generation refers to the creation or generation of required data, parameters or objects in real time according to specific rules or conditions at runtime. Compared with static generation, dynamic generation has greater flexibility and adaptability, and can dynamically adjust the generated content according to different inputs or environments. In the present application, the first micro-sandbox pool uses a dynamically generated random padding string Pad_i when encrypting sensitive data blocks. Specifically, for each sensitive data block Data_i, the first micro-sandbox pool dynamically generates a padding string Pad_i of random length, with a length range of [1, Max_Pad_Len], where Max_Pad_Len is the preset maximum padding length. The purpose of dynamically generating padding strings is to disrupt the original length and content of sensitive data and increase the randomness and unpredictability of ciphertext. By generating padding strings of different lengths for each sensitive data block, the same sensitive data generates different ciphertexts in different encryption operations, thereby enhancing the security of encryption. The length range of the padding string [1, Max_Pad_Len] is dynamically determined and can be adjusted according to security requirements and performance requirements. A larger padding length can provide stronger security, but it will also increase computational and storage overhead; a smaller padding length can reduce overhead, but security may be reduced. By dynamically generating padding strings, a balance and trade-off can be made between security and efficiency. Another advantage of dynamic generation is that different generation strategies and algorithms can be used according to different data characteristics and environmental factors. For example, according to the type, length, entropy value and other characteristics of sensitive data, the appropriate padding method and parameters can be dynamically selected to achieve optimal security and performance.

[0025] Furthermore, sensitive data includes identity and privacy information. Privacy information refers to sensitive and confidential data related to individuals, which are usually not intended to be disclosed or accessed without authorization. For example, biometric information, medical and health information, financial information, and communication records, etc.

[0026] Further, S31, the first micro-sandbox pool uses a preset intelligence library to perform a first verification on the access request, including: the first micro-sandbox pool extracts the source IP address Src_IP, the destination URL address Dst_URL and the request method Method from the access request to construct a request feature vector Req_Vec; the first micro-sandbox pool queries the known malicious IP address blacklist BL_IP, the malicious URL address blacklist BL_URL and the abnormal request method blacklist BL_Method from the preset intelligence library as threat intelligence vectors; the first micro-sandbox pool matches the request feature vector Req_Vec with the threat intelligence vector, and determines whether the access request passes the first verification based on the matching result.

[0027] Further, the first micro-sandbox pool matches the request feature vector Req_Vec with the threat intelligence vector, including: if the source IP address Src_IP of the request exists in the malicious IP blacklist BL_IP, the request is determined to be a malicious request, the first verification fails, otherwise the next step is executed; if the destination URL address Dst_URL of the request exists in the malicious URL blacklist BL_URL, the request is determined to be a malicious request, the first verification fails, otherwise the next step is executed; if the method Method of the request exists in the abnormal request method blacklist BL_Method, the request is determined to be an abnormal request, the first verification fails, otherwise the first verification passes.

[0028] S23, using the integrated learning strategy Bagging to strengthen the classification model, and obtain the Bagging decision tree strong classifier, including: performing Bootstrap sampling on the training sample set, randomly extracting n samples (n is equal to the size of the original training sample set) from the original training sample set, allowing repeated sampling, and generating T Bootstrap sample sets; wherein each Bootstrap sample set has the same size as the original training sample set, but because repeated sampling is allowed, its content is different from the original training sample set;

[0029] Using the T Bootstrap sample sets generated in step 1, T ordered classification trees OC1 are trained respectively to obtain T weak classifiers; wherein the training process of each weak classifier is the same as the step in claim 3, including: extracting the security level characteristics and timeliness requirement characteristics of the sample to form a training sample set; using the characteristics of the training sample set as the input of OC1, and whether to adopt SGX as the classification target; selecting the optimal split point by calculating the Gini index of the node, and recursively splitting to generate a decision tree; pruning and optimizing the decision tree to obtain the optimized OC1 weak classifier;

[0030] Combine the T OC1 weak classifiers obtained in step 2 to construct a strong classifier of the Bagging decision tree. Specifically, the following steps are performed: extract the security level features and timeliness requirement features of the new access request sample; input the extracted features into each OC1 weak classifier to obtain T classification results of whether the request adopts SGX; vote on the T classification results to obtain the final strong classification result, i.e., whether the new request adopts SGX; and use the consistent decision of the majority of weak classifiers as the output of the strong classifier of the Bagging decision tree.

[0031] The Bagging decision tree strong classifier is used to judge the new access request to determine whether the request needs to use the executable environment SGX; if the output of the strong classifier is to use SGX, the public network server forwards the request to the executable environment SGX for processing; if the output of the strong classifier is not to use SGX, the public network server directly processes the access request.

[0032] Another aspect of the present application also provides a service-side based data security authority management system for executing a service-side based data security authority management method of the present application.

[0033] Compared with the prior art, the advantages of this application are:

[0034] This method introduces micro-sandbox isolation technology and trusted execution environment SGX to perform differentiated processing for access requests with different security levels and time requirements. Compared with the traditional single sandbox, the micro-sandbox pool can isolate and monitor request behaviors more finely, and combined with the hardware-level protection of SGX, it can effectively prevent malicious code damage and sensitive data leakage. In addition, multi-level security inspection mechanisms and dynamic encryption measures further strengthen data protection capabilities, thereby comprehensively improving the security and reliability of the system.

[0035] This method uses micro-sandbox isolation to dynamically divide access requests into different micro-sandbox pools, which can make full use of system resources and improve concurrent processing capabilities. In particular, for requests with lower security levels, SGX can be avoided to reduce unnecessary performance overhead. At the same time, fine-grained security checks can quickly identify and filter malicious requests and reduce the resource usage of invalid requests. Dynamically filled encryption schemes can also reduce the time consumption of data transmission. Compared with traditional solutions, this method can significantly improve system throughput and alleviate performance bottlenecks in high-concurrency scenarios.

[0036] Traditional coarse-grained authentication and authorization methods are difficult to adapt to complex and changing security requirements. This method introduces an intelligent decision-making model based on machine learning. By extracting key features such as the security level and timeliness of the request, an ordered classification tree and an ensemble learning classifier are constructed to achieve accurate classification and prediction of access requests. Combined with technologies such as SymExec symbolic execution and formal verification, the internal logic of the request is deeply explored to verify its legitimacy and security. Compared with manually defined rules, this method can achieve more intelligent, dynamic, and fine-grained authentication and authorization, effectively improving the adaptability and flexibility of the system.

[0037] This method adopts a path-sensitive dynamic encryption scheme to implement encryption protection for sensitive data in access requests, identify sensitive data through request expression matching, use dynamic padding to increase the randomness of ciphertext, and then encrypt it with high-intensity algorithms such as AES-GCM. Compared with static desensitization, this method is more flexible and efficient, and can adapt to the privacy protection needs of different business scenarios. At the same time, formal verification and symbolic execution can enhance the interpretability and compliance of system execution, providing a reliable basis for data security audits. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The present application will be further described in the form of exemplary embodiments, which will be described in detail by the accompanying drawings. These embodiments are not restrictive, and in these embodiments, the same number represents the same structure, wherein:

[0039] Figure 1 is an exemplary flow chart of a data security authority management method based on the service side according to some embodiments of the present application;

[0040] Figure 2 is an exemplary flow chart for determining whether to adopt the executable environment SGX according to some embodiments of the present application;

[0041] Figure 3 is an exemplary flow chart of the first data verification according to some embodiments of the present application;

[0042] Figure 4 is an exemplary flow chart of the second data verification according to some embodiments of the present application;

[0043] Figure 5 This is an exemplary flow chart of encrypting access data according to some embodiments of the present application. DETAILED DESCRIPTION

[0044] The method and system provided in the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0045] like Figure 1As shown, the client sends a digitally signed access request to the public network server; the public network server verifies the access request signature, and for the access request that passes the verification, the public network server determines whether to adopt the executable environment SGX based on the security level and timeliness requirements of the access request; when it is determined that the executable environment SGX is adopted, the corresponding access request is sent to the first message queue; otherwise, the corresponding access request is sent to the second message queue; the first message queue sends the access request to the first micro-sandbox pool; the second message queue sends the access request to the second micro-sandbox pool; the security level of the first message queue is greater than that of the second message queue, and the first micro-sandbox The pool integrates SGX hardware support, and the second micro-sandbox pool does not integrate SGX hardware support; the first micro-sandbox pool uses a preset intelligence library and an executable environment SGX to check access requests, and for access requests that pass the inspection, encrypts them using an encryption algorithm and sends them to the mirror server, otherwise the corresponding access requests are rejected; the second micro-sandbox pool uses a preset intelligence library to check access requests, and for access requests that pass the inspection, encrypts them using an encryption algorithm and sends them to the mirror server, otherwise the corresponding access requests are rejected; the mirror server obtains corresponding response data according to the access request, and sends the response data to the first micro-sandbox pool or the second micro-sandbox pool;

[0046] Specifically, S1, the client sends a digitally signed access request to the public network server; the client builds a standardized access request data structure according to business needs. This structure generally contains the following fields: the target resource of the request (such as URL, file path, etc.), the operation type of the request (such as GET, POST, etc.), the parameter list of the request (such as key-value pairs, JSON, etc.), the timestamp of the request (used to prevent replay attacks), the unique ID of the request (used to identify and track requests), and the identity information of the client (such as user name, device ID, etc.).

[0047] like Figure 2 As shown, S2, after receiving the access request from the client, the public network server needs to first verify the validity of the request signature to ensure that the request has not been tampered with. For requests that have passed the verification, the server determines whether it is necessary to use the trusted execution environment SGX for processing based on the security level and timeliness requirements of the request. S21, the public network server extracts key feature parameters from the access request, mainly including the security level of the request. Different business scenarios and application systems may have different security level classification standards, such as the sensitivity of the data, the user's identity authentication level, the risk level of the operation, etc. The security level can be represented by a numerical variable (such as 1-5 levels) or a categorical variable (such as "low", "medium", and "high").

[0048] S22, the public network server builds a classification model for SGX judgment, where the Ordinal Classification Tree (OC1) algorithm is used. Specifically, historical access request data is collected as a training sample set. Each sample contains the characteristic parameters of the request (such as security level) and a label (0 or 1) indicating whether SGX is used. For each training sample, its security level features are extracted. The original security level value can be used directly or converted (such as one-hot encoding). The extracted features and SGX labels are combined into training samples (feature, label). Using the training sample set, an ordered classification tree is trained using the OC1 algorithm. OC1 is a special decision tree that is suitable for classification problems (such as security levels) where labels have natural order. According to the security level characteristics of the sample, the optimal split point is selected by calculating the Gini index (Giniimpurity) to divide the sample into two child nodes. Each child node is recursively split until the preset stop condition is met, such as the number of samples is less than the threshold, the maximum depth of the tree, etc. Prune the generated decision tree to remove overly complex or overfitted branches to improve the generalization ability of the model. Save the trained OC1 tree as a classification model for online SGX judgment.

[0049] In particular, traditional decision trees generally use CART, ID3, etc. However, on the one hand, in the field of data security, the security level of access requests usually has obvious order, such as "low" < "medium" < "high". Conventional decision trees regard categories as unordered discrete values, ignoring the order relationship between categories. OC1, by designing special splitting criteria (such as the Gini index), can make full use of the order information of labels and learn decision boundaries that are more in line with business semantics. Therefore, OC1 is more suitable for processing ordered classification problems such as the security level of access requests.

[0050] On the other hand, conventional decision trees are more sensitive to disturbances and noise in training samples, and are prone to overfitting problems, resulting in reduced generalization of the model. OC1, by dividing based on category order, can suppress the impact of noise data to a certain extent and improve the robustness of classification. Even if there are a small number of errors or anomalies in the training samples, OC1 can learn relatively stable judgment boundaries. This is crucial for model reliability in data security scenarios.

[0051] In addition, conventional decision trees tend to over-segment training samples, generating overly complex and deep tree structures, which increases the computational overhead and memory consumption of the model. OC1, on the other hand, tends to generate relatively concise and balanced tree structures by leveraging the orderliness of categories. This not only reduces the risk of over-segmentation, but also makes the model more efficient in inference and occupies less resources when serving online.

[0052] S23, in order to further improve the performance of the classifier, the public network server uses the Bagging (Bootstrap Aggregating) strategy to strengthen the OC1 model. Random sampling (with replacement) is performed from the original training set to generate multiple bootstrap sample sets, each of which has the same size as the original training set. For each bootstrap sample set, an independent OC1 tree is trained to obtain a set of base classifiers. The outputs of all base classifiers are combined (such as voting, averaging) to obtain the final strong classifier, namely the Bagging decision tree.

[0053] S24, for each access request that passes the signature verification, the public network server extracts its security level features and inputs them into the trained Bagging decision tree to obtain the judgment result (0 or 1) of whether the request should use the SGX environment. Based on the judgment result, the server distributes the request to the corresponding processing module (such as SGX enclave or ordinary application container) for execution.

[0054] like Figure 3 As shown, S3, the first micro-sandbox pool uses the preset intelligence library and the executable environment SGX to check the access request. For the access request that passes the check, it is encrypted by an encryption algorithm and sent to the mirror server. Otherwise, the corresponding access request is rejected.

[0055] Specifically, S31, the first micro-sandbox pool extracts key feature information from the received access request, mainly including: Source IP address (Src_IP): the IP address of the client initiating the request, used to determine whether the source of the request is legal. Destination URL address (Dst_URL): the URL of the target resource accessed by the request, used to determine whether the purpose of the request is legal. Request method (Method): HTTP request method, such as GET, POST, PUT, etc., used to determine whether the operation type of the request is legal. The first micro-sandbox pool constructs the extracted (Src_IP, Dst_URL, Method) triple into a request feature vector Req_Vec as input for subsequent verification.

[0056] The first micro-sandbox pool queries known threat intelligence from the preset intelligence library, mainly including: Malicious IP blacklist (BL_IP): a list of IP addresses of known malicious clients, such as botnets, malicious crawlers, etc. Malicious URL blacklist (BL_URL): a list of known malicious or high-risk URL addresses, such as phishing websites, malware download pages, etc. Abnormal request method blacklist (BL_Method): a list of known abnormal or illegal HTTP request methods, such as OPTIONS, DELETE, etc. The first micro-sandbox pool constructs the queried (BL_IP, BL_URL, BL_Method) triples into a threat intelligence vector as a basis for determining whether the request is malicious.

[0057] The first micro-sandbox pool matches the request feature vector Req_Vec with the threat intelligence vector to determine whether the request is a malicious request: IP address matching: Check whether the source IP address Src_IP of the request is in the malicious IP blacklist BL_IP. If it exists, the request is determined to be a malicious request, the first check fails, and the request is directly rejected; otherwise, continue to the next step of checking. URL address matching: Check whether the destination URL address Dst_URL of the request is in the malicious URL blacklist BL_URL. If it exists, the request is determined to be a malicious request, the first check fails, and the request is directly rejected; otherwise, continue to the next step of checking. Request method matching: Check whether the request method Method is in the abnormal request method blacklist BL_Method. If it exists, the request is determined to be an abnormal request, the first check fails, and the request is directly rejected; otherwise, the first check passes, and the request is allowed to enter the subsequent processing flow (such as step S32). The above matching process can be implemented through efficient data structures (such as hash tables, Bloom filters, etc.) to improve matching efficiency and real-time performance.

[0058] According to the result of the first verification, the first micro-sandbox pool processes the access request accordingly: if the verification fails, the request is directly rejected, and the corresponding error information (such as "illegal request" or "access denied") is returned to the client, and the relevant information of the request (such as time, IP, URL, etc.) is recorded for subsequent security analysis and audit. If the verification passes, the request is allowed to enter the subsequent processing flow, such as the formal verification in step S32.

[0059] This application is based on the first verification of the intelligence library. The first micro-sandbox pool can quickly identify and filter out known malicious requests, reducing the security risks and computing overhead of subsequent processing. At the same time, by regularly updating the intelligence library, it can also respond to emerging threats and attack methods, and improve the security and real-time protection capabilities of the system.

[0060] like Figure 4As shown, S32, the first micro-sandbox pool sends the access request that passes the first verification to the executable environment SGX. In the executable environment SGX, the access request is verified for the second time through a formal verification method. If it passes, step S33 is executed, otherwise the corresponding access request is rejected.

[0061] Specifically, first, the key fields of the access request are abstracted into symbolic variables, and the symbolic expression Req_Sym of the request is constructed. The symbolic variables mainly include: request parameter variable Par_i: parameter field in the request, such as query string, POST data, etc., i is the index number of the parameter. Request header variable Hdr_j: HTTP header field in the request, such as User-Agent, Referer, etc., j is the index number of the header field. Symbol variable library Sym_Lib: predefined symbolic variables, such as wildcards, regular expressions, etc., used to match and replace specific patterns in requests. Replace the request fields with the corresponding symbolic variables to obtain the symbolic expression Req_Sym of the request as the input for subsequent symbolic execution.

[0062] Then, initialize the path condition variable Path_Con to an empty set. Select a symbolic execution tool, such as KLEE or angr, to perform symbolic execution on the request expression Req_Sym. Symbolic execution starts from the entry point of Req_Sym and explores all possible execution paths in the following way: At each branch point, the symbolic execution tool generates two paths based on the branch condition: one assumes that the condition is true and the other assumes that the condition is false. For each path, the symbolic execution tool maintains a set of path constraints, indicating the prerequisites for the path to be reachable. The symbolic execution tool uses a constraint solver (such as Z3) to determine the satisfiability of the path conditions. If the path condition is not satisfied, the path is unreachable and can be safely pruned to improve execution efficiency. During the symbolic execution process, the conditional expression Bran_Con_k of each path branch is collected, where k is the index number of the path branch. Bran_Con_k is added to Path_Con to generate a complete path constraint. The result of symbolic execution is a set of path constraints Path_Con, which covers all possible path branches during the request execution process. Each path constraint is a set of symbolic variables that express the conditions under which the path is reachable.

[0063] Match the security policy, predefine a set of security policy rules Rule_Lib, and use formal methods (such as first-order logic) to model security constraints. Common security constraints include: Parameter value range: define the value boundary of the symbol variable, such as Par_1>=0&&Par_1<=100. Header field format: define the format requirements of the symbol variable, such as the regular expression Hdr_2.matches("^\w+@\w+\.\w+$"). Data dependency: define the equality relationship between symbol variables, such as Par_3==Par_1+Par_2. Match and replace the symbol variables in the path constraint Path_Con with the constraint variables in Rule_Lib. Specifically: for each symbol variable in Path_Con, search for the corresponding security constraint in Rule_Lib. If a matching constraint is found, replace the symbol variable in Path_Con with the specific expression in the constraint. If no matching constraint is found, keep the symbol variable in Path_Con unchanged. The replaced Path_Con is called a specific path constraint expression, in which the symbolic variables have been constrained by specific conditions in the security policy.

[0064] Solve the constraints, merge the replaced path constraint expression Path_Con and the security policy Rule_Lib, and convert them into the constraint equation Smt_Equ in SMT-LIB format. SMT-LIB is the standard input format of the SMT solver, which supports the representation and solution of first-order logic. Input the constraint equation Smt_Equ into the SMT solver, such as the Z3 solver. The SMT solver makes a satisfiability judgment on Smt_Equ and obtains the solution result Smt_Res. Process the request according to the result of Smt_Res: If Smt_Res is "SAT" (satisfiable), it means that there is a set of symbolic variable values ​​that make the path condition and security constraint meet at the same time. This means that the request may violate the preset security policy and there is a security risk. At this time, the access request is rejected and the corresponding error message is returned, such as "illegal request parameters". If Smt_Res is "UNSAT" (unsatisfiable), it means that there is no symbolic variable value that makes the path condition and security constraint meet at the same time. This means that the request meets the preset security policy and there is no known security risk. At this time, the request is allowed to enter the subsequent processing flow, such as step S33.

[0065] In particular, on the one hand, the program state space in the SGX environment is large, and traditional formal verification methods need to exhaust all possible state combinations, resulting in excessive time and space complexity of the verification process, making it difficult to complete the verification task within limited resources. This application avoids the state space explosion problem by abstracting access requests into symbolic expressions and using symbolic execution technology to automatically explore the execution path of the request. In this application, the key data in the request is abstracted into symbolic variables, such as request parameters, request headers, etc., through symbolic execution to generate a symbolic expression of the request. By performing path exploration and constraint solving on symbolic expressions, symbolic execution can automatically generate test cases that cover different execution paths of the program without manually constructing and enumerating all possible input combinations. This method transforms the verification problem into the solution of path constraints, greatly reducing the search range of the state space and improving verification efficiency.

[0066] On the other hand, the traditional formal verification method requires manual construction of verification conditions and proof rules, which requires high professional knowledge and experience of the verifier, and the verification process is cumbersome and prone to errors. This application integrates path constraints with security policy rules, converts formal verification into SMT constraint solving problems, and uses efficient SMT solvers for automated verification, thereby improving the efficiency and accuracy of verification. This application describes the branch conditions and data dependencies during the execution of the request through path constraints, reflecting the semantics and behavioral characteristics of the request. Security policy rules define the security boundaries and constraints in the SGX environment, such as the value range and format restrictions of the data. By converting the two into constraint equations in SMT-LIB format and using mature SMT solvers such as Z3 for satisfiability determination, it is possible to automatically determine whether the request meets the preset security policy. This automated verification method lowers the verification threshold, reduces the risk of manual intervention and error introduction, and improves the credibility of the verification results.

[0067] In addition, the security requirements of the SGX environment may change dynamically with the development of business and the evolution of attack methods, and traditional formal verification methods are difficult to quickly adapt to changes in requirements. The present application encapsulates the security requirements of the SGX environment in the form of a security policy rule base, decouples security attributes from specific verification processes, and facilitates the adjustment of verification constraints according to dynamically changing requirements. The security policy rule base defines the security boundaries and constraints of the SGX environment in a declarative manner, such as access control rules, data legitimacy requirements, etc. This declarative rule representation method is easy to understand and maintain, and security administrators can add, delete, and modify rules according to actual needs without having to deeply understand the details of the verification process. At the same time, the modular design of the rule base is also easy to reuse and expand, and a verification system that adapts to different scenarios can be quickly built. This flexibility enables the present application to adapt to the dynamic security requirements of the SGX environment and provide continuous and effective security protection.

[0068] Finally, traditional testing and fuzz testing methods are difficult to exhaust all possible input situations. For a complex system like the SGX environment, it is difficult to ensure the completeness and reliability of the verification results. This application introduces a formal verification method, which accurately defines the behavior and properties of the system in a mathematical way, and uses strict logical reasoning and automated tool support to improve the credibility and comprehensiveness of the verification. The formal verification method is based on mathematical logic, models and describes the system through formal language and reasoning rules, and converts the verification problem into a proof problem of mathematical propositions. This mathematical description eliminates the ambiguity and uncertainty of natural language and provides an accurate and rigorous verification basis. At the same time, with the help of mature formal tools and proof-assisted systems, the formal verification method can automatically complete most of the verification tasks, reducing the workload and error risk of manual proof. This highly reliable and automated verification mechanism provides a solid guarantee for the security of the SGX environment.

[0069] like Figure 5 As shown, S33, the first micro-sandbox pool encrypts the request parameters, request header and request body of the access request to generate an encrypted access request, and the first micro-sandbox pool uses the AES-256-GCM algorithm to generate a random session key Sess_Key and initialization vector IV. AES-256-GCM is an authenticated encryption algorithm that can simultaneously ensure the confidentiality and integrity of data. The session key Sess_Key is used to encrypt and decrypt sensitive data to ensure the confidentiality of the data. The initialization vector IV is used to ensure the randomness of the encryption process to prevent the same plaintext from generating the same ciphertext.

[0070] The first micro-sandbox pool extracts the path expression Path_Exp of the access request from the security policy rule library Rule_Lib. The path expression Path_Exp defines the location and format of sensitive data in the request parameters, request header, and request body. The first micro-sandbox pool matches the request data according to Path_Exp and extracts a set of sensitive data blocks Data_i. Sensitive data usually includes the user's identity (such as user name, ID, etc.) and privacy information (such as password, address, etc.).

[0071] For each sensitive data block Data_i, the first micro-sandbox pool performs the following disruption processing: dynamically generate a padding string Pad_i of random length, with a length range of [1, Max_Pad_Len]. Max_Pad_Len is the preset maximum padding length, which is used to control the range of padding. The padding string Pad_i is composed of random characters and is used to disrupt the length and distribution characteristics of sensitive data. The original sensitive data block Data_i is concatenated with the padding string Pad_i to generate the disrupted data block Obf_Data_i.

[0072] For each scrambled data block Obf_Data_i, the first micro-sandbox pool performs the following encryption processing: Obf_Data_i is encrypted using the AES-256-GCM algorithm, using the session key Sess_Key and the initialization vector IV. After encryption, the ciphertext data Enc_Data_i and the authentication tag Tag_i are obtained. The authentication tag Tag_i is used to verify the integrity and authenticity of the ciphertext data to prevent the data from being tampered with or forged.

[0073] The first micro-sandbox pool concatenates the padding length information Pad_Len_i with the ciphertext data Enc_Data_i to generate the final ciphertext block Enc_Block_i. The padding length information Pad_Len_i indicates the length of the padding string in the ciphertext block, which is used to identify and remove the padding during decryption. The format of the ciphertext block Enc_Block_i is "Pad_Len_i||Enc_Data_i", which ensures the complete transmission of the padding length and ciphertext data.

[0074] The first micro-sandbox pool splices the encrypted ciphertext block Enc_Block_i and authentication tag Tag_i according to the original position and order of the sensitive data. After splicing, the complete ciphertext data Enc_Data and authentication tag Tag are obtained. The first micro-sandbox pool fills the ciphertext data Enc_Data and authentication tag Tag back into the corresponding position of the access request, replacing the original plaintext sensitive data. After filling, the ciphertext request message Enc_Req is generated, in which the sensitive data is encrypted and disturbed, and the data boundary and length are inconsistent with the original request.

[0075] After receiving the ciphertext request message Enc_Req, the receiver (such as the second micro-sandbox pool) extracts the ciphertext data Enc_Data and the authentication tag Tag. Use the session key Sess_Key and the initialization vector IV to perform AES-256-GCM decryption on the ciphertext data Enc_Data. After decryption, the scrambled data block Obf_Data_i and the padding length information Pad_Len_i are obtained. According to Pad_Len_i, the padding string Pad_i is identified and removed to restore the original sensitive data block Data_i. According to the original position and order of the sensitive data, the restored data blocks Data_i are spliced ​​to obtain the complete plaintext sensitive data.

[0076] In particular, on the one hand, the traditional AES-256-GCM encryption algorithm directly encrypts the sensitive data matched in the request parameters, request header, and request body. Although the confidentiality of the data is protected, the length of the encrypted ciphertext data is consistent with the length of the original sensitive data. This fixed correspondence may lead to the leakage of data boundaries. Although the attacker cannot decrypt the ciphertext data, he can infer the distribution and scale of sensitive information in the request by analyzing the location and length of the ciphertext data. For example, if the password field in the request is always encrypted as a fixed-length ciphertext, the attacker can locate the password field based on this feature and try to focus on it.

[0077] This application introduces a dynamic padding mechanism to pad the sensitive data block with a random length before encryption, thus changing the length of the encrypted ciphertext data. Since the padding length is randomly generated, even the same sensitive data block will produce ciphertexts of different lengths in different requests. This uncertainty disrupts the boundary characteristics of sensitive information, making it impossible for attackers to accurately infer the distribution and scale of sensitive data based on the ciphertext length, thereby reducing the risk of data privacy leakage.

[0078] On the other hand, the dynamic padding mechanism not only hides the boundaries of sensitive data, but also protects the security of the padding process itself. In this application, the padding length information Pad_Len_i is encrypted together with the ciphertext data Enc_Data_i to generate the final ciphertext block Enc_Block_i. This method ensures the confidentiality of the padding length information and prevents attackers from obtaining the specific length of the padding. At the same time, when decrypting, the recipient needs to first decrypt the ciphertext block, obtain the padding length information, and then remove the padding based on the information to restore the original sensitive data. This decryption order ensures the confidentiality of the padding process. Even if the attacker obtains the ciphertext data, he cannot directly identify and remove the padding, and then restore the original sensitive information.

[0079] In addition, the dynamic padding mechanism is combined with the AES-256-GCM authenticated encryption algorithm, which not only protects the confidentiality of the data, but also is compatible with the security properties of authenticated encryption. While encrypting, the AES-256-GCM algorithm generates an authentication tag Tag to verify the integrity and authenticity of the ciphertext data. In this application, the padded scrambled data block Obf_Data_i is encrypted together with the original sensitive data block Data_i by AES-256-GCM, and the generated authentication tag Tag_i covers the padded part. This method ensures the integrity of the padded data and prevents attackers from tampering with or forging the padded part. At the same time, when decrypting, the recipient needs to verify the validity of the authentication tag to confirm the authenticity and credibility of the ciphertext data. This integrity verification mechanism further enhances the reliability of data protection under dynamic padding.

[0080] Finally, the dynamic padding mechanism provides greater flexibility for data security protection. By adjusting the maximum padding length Max_Pad_Len, the range and strength of the padding can be controlled. When facing higher security threats, Max_Pad_Len can be increased to strengthen the hiding and protection of sensitive data boundaries; in scenarios with higher performance requirements, Max_Pad_Len can be appropriately reduced to balance security and efficiency. In addition, the dynamic padding mechanism is decoupled from the specific encryption algorithm and can be easily combined with other encryption algorithms (such as AES-256-CBC, etc.) to meet different security requirements and application scenarios.

[0081] S34, the first micro-sandbox pool sends the encrypted access request to the mirror server; the first micro-sandbox pool and the mirror server pre-negotiate to generate an AES session key as a shared key. The first micro-sandbox pool and the mirror server negotiate to generate an AES session key through a secure key exchange protocol (such as Diffie-Hellman key exchange). The length of the session key is 256 bits and is used for subsequent AES encryption and decryption operations. The key exchange process should be performed on a secure channel, such as using SSL / TLS encrypted communication to prevent the key from being eavesdropped or tampered with. The negotiated session key is used as a shared key between the first micro-sandbox pool and the mirror server to protect the confidentiality and integrity of communication data.

[0082] The first micro-sandbox pool uses the ciphertext request message Enc_Req generated in step S33 as the encrypted access request. The first micro-sandbox pool sends the encrypted access request to the mirror server through a secure communication protocol (such as HTTPS). The sending process should ensure the integrity and authenticity of the request, and can be verified using mechanisms such as digital signatures or message authentication codes (MAC). After receiving the encrypted access request, the mirror server decrypts the request using the pre-negotiated AES session key. The decryption process corresponds to the encryption process in step S33, and the same key and algorithm (such as AES-256-GCM) need to be used. The mirror server verifies the integrity and authenticity of the request to ensure that the request has not been tampered with or forged. After decryption, the mirror server obtains the plaintext access request and enters the subsequent business processing flow.

[0083] S4, the second micro-sandbox pool uses the same preset intelligence library and verification method as the first micro-sandbox pool to verify the access request. The verification process can refer to steps S31 and S32, including matching the request feature vector with the threat intelligence vector, formal verification, etc. For access requests that pass the inspection, the second micro-sandbox pool performs subsequent encryption processing; for requests that fail the inspection, they are directly rejected and the corresponding error message is returned.

[0084] The second micro-sandbox pool encrypts the access request that has passed the inspection, using the same encryption algorithm and process as the first micro-sandbox pool. The encryption process can refer to step S33, including dynamic filling of sensitive data, AES-256-GCM encryption, etc. The second micro-sandbox pool sends the encrypted access request to the mirror server through a secure communication protocol and ensures the integrity and authenticity of the request.

[0085] S5, the mirror server obtains the corresponding response data from the backend service or data storage according to the received access request. The response data can be different types of content such as text, pictures, videos, etc., depending on the business requirements of the request. The mirror server encrypts the obtained response data using the same encryption algorithm and session key as the access request. The encryption process can refer to step S33, and the sensitive data is dynamically filled and AES-256-GCM encrypted. The mirror server sends the encrypted response data to the first micro-sandbox pool or the second micro-sandbox pool through a secure communication protocol, depending on the source of the request. The sending process should ensure the integrity and authenticity of the response data, which can be verified using mechanisms such as digital signatures or message authentication codes.

[0086] After receiving the encrypted response data, the first micro-sandbox pool or the second micro-sandbox pool uses the pre-negotiated AES session key to decrypt the data. The decryption process corresponds to the encryption process and requires the use of the same key and algorithm. The micro-sandbox pool verifies the integrity and authenticity of the response data to ensure that the data has not been tampered with or forged. After decryption, the micro-sandbox pool obtains the plaintext response data and returns it to the final requester (such as a client or application server).

Claims

1. A data security authority management method based on the service side, characterized in that: include: S1, the client sends a digitally signed access request to the public network server; S2, the public network server verifies the access request signature. For the access request that passes the verification, the public network server determines whether to use the executable environment SGX based on the security level and timeliness requirements of the access request; When it is determined that the executable environment SGX is adopted, the corresponding access request is sent to the first message queue; otherwise, the corresponding access request is sent to the second message queue; the first message queue sends the access request to the first micro-sandbox pool; The second message queue sends the access request to the second micro-sandbox pool; The security level of the first message queue is greater than that of the second message queue, the first micro-sandbox pool integrates SGX hardware support, and the second micro-sandbox pool does not integrate SGX hardware support; S3, the first micro-sandbox pool uses the preset intelligence library and the executable environment SGX to check the access request. For the access request that passes the check, it is encrypted by an encryption algorithm and sent to the mirror server. Otherwise, the corresponding access request is rejected. S4, the second micro-sandbox pool uses the preset intelligence library to check the access request, and encrypts the access request that passes the check using an encryption algorithm and sends it to the mirror server, otherwise the corresponding access request is rejected; S5, the mirror server obtains corresponding response data according to the access request, and sends the response data to the first micro-sandbox pool or the second micro-sandbox pool.

2. The data security authority management method based on the service side according to claim 1 is characterized in that: S2, determining whether to use the executable environment SGX, including: S21, the public network server extracts characteristic parameters from the access request, where the characteristic parameters include a security level; S22, constructing a classification model based on the ordered classification tree OC1 according to the extracted feature parameters; S23, using the integrated learning strategy Bagging to strengthen the classification model and obtain the Bagging decision tree strong classifier; S24, using the Bagging decision tree strong classifier to determine whether the access request uses the executable environment SGX.

3. The data security authority management method based on the service side according to claim 2 is characterized in that: S22, constructing a classification model based on the ordered classification tree OC1, including: Collect historical access request data as training samples; Mark whether each access request sample uses the executable environment SGX; Extract the security level features of each access request sample, and combine the extracted security level features and the label of whether the executable environment SGX is adopted to form a training sample set; The security level features in the training sample set are used as the input of the ordered classification tree OC1, and whether to use the executable environment SGX is used as the classification target; According to the security level characteristics of the current sample node, the optimal split point is obtained by calculating the Gini index of the node; The current sample node is divided into two sub-nodes according to the optimal splitting point, and the sub-nodes are split recursively until the preset stop condition is met, and an ordered classification tree OC1 is obtained as a classification model.

4. The data security authority management method based on the service side according to claim 1 is characterized in that: S3, the first micro-sandbox pool uses the preset intelligence library and the executable environment SGX to check the access request, including: S31, the first micro-sandbox pool uses the preset intelligence library to perform the first verification on the access request. If the verification passes, step S32 is executed, otherwise the corresponding access request is rejected; S32, the first micro-sandbox pool sends the access request that passes the first verification to the executable environment SGX, and in the executable environment SGX, the access request is secondly verified by a formal verification method. If it passes, step S33 is executed, otherwise the corresponding access request is rejected; S33, the first micro-sandbox pool encrypts the request parameters, request header, and request body of the access request to generate an encrypted access request; S34, the first micro-sandbox pool sends the encrypted access request to the mirror server; the first micro-sandbox pool and the mirror server pre-negotiate to generate an AES session key as a shared key.

5. The data security authority management method based on the service side according to claim 4 is characterized in that: The access request is verified a second time using formal verification methods, including: Define symbolic variables of access request, and construct request expression Req_Sym according to the symbolic variables; the symbolic variables include request parameter variable Par_i, request header variable Hdr_j and symbolic variable library Sym_Lib, i is the index number of request parameter, j is the index number of request header field; Define the path condition variable Path_Con, with the initial value being an empty set; Starting from the entry point of the request expression Req_Sym, use the SMT-based symbolic execution tool to perform symbolic execution on Req_Sym and explore all executable paths; During the symbolic execution process, the conditional expressions Bran_Con_k of each path branch are collected, where k is the index number of the path branch; Bran_Con_k is added to Path_Con to generate path constraints; Define a security policy rule base Rule_Lib, which contains formally defined security constraints; Match and replace the symbolic variables in the path constraint condition Path_Con with the constraint condition variables in Rule_Lib; merge the constraints in Path_Con and Rule_Lib and convert them into the constraint equation Smt_Equ; Input the constraint equation Smt_Equ into the SMT solver, and the SMT solver makes a satisfiability judgment on Smt_Equ to obtain the solution result Smt_Res; If Smt_Res is satisfiable, it means that there is a set of symbolic variables whose values ​​satisfy Smt_Equ, and the access request is rejected; If Smt_Res is unsatisfiable, it means that there is no value of the symbolic variable that satisfies Smt_Equ, and step S33 is executed.

6. The data security authority management method based on the service side according to claim 5 is characterized in that: S33, generating an encrypted access request, including: The first micro-sandbox pool uses the AES-256-GCM algorithm to generate the session key Sess_Key and the initialization vector IV, and extracts the path expression Path_Exp of the access request from the security policy rule library Rule_Lib; The first micro-sandbox pool matches the sensitive data in the request parameters, request header, and request body according to the path expression Path_Exp as the sensitive data block Data_i; For each sensitive data block Data_i, the first micro-sandbox pool dynamically generates a padding string Pad_i of random length, with a length range of [1, Max_Pad_Len], where Max_Pad_Len is the preset maximum padding length; The first micro-sandbox pool concatenates the original sensitive data block Data_i with the padding string Pad_i to generate a disturbed data block Obf_Data_i = Data_i||Pad_i; The first micro-sandbox pool performs AES-256-GCM encryption on the disturbed data block Obf_Data_i, using the session key Sess_Key and the initialization vector IV to obtain the ciphertext data Enc_Data_i and the authentication tag Tag_i; The first micro-sandbox pool concatenates the padding length information Pad_Len_i with the ciphertext data Enc_Data_i to generate the final ciphertext block Enc_Block_i = Pad_Len_i||Enc_Data_i; The first micro-sandbox pool concatenates the encrypted ciphertext block Enc_Block_i and the authentication tag Tag_i according to the original position and order of the sensitive data to generate complete ciphertext data Enc_Data and authentication tag Tag; The first micro-sandbox pool fills the ciphertext data Enc_Data and the authentication tag Tag back into the corresponding positions of the access request, replaces the original plaintext sensitive data, and generates an encrypted access request Enc_Req.

7. The data security authority management method based on the service side according to claim 6 is characterized in that: Sensitive data includes identity and privacy information.

8. The data security authority management method based on the service side according to claim 4 is characterized in that: S31, the first micro-sandbox pool uses the preset intelligence library to perform the first verification on the access request, including: The first micro-sandbox pool extracts the source IP address Src_IP, the destination URL address Dst_URL and the request method Method from the access request, and constructs the request feature vector Req_Vec; The first micro-sandbox pool queries the known malicious IP address blacklist BL_IP, malicious URL address blacklist BL_URL and abnormal request method blacklist BL_Method from the preset intelligence library as threat intelligence vectors; The first micro-sandbox pool matches the request feature vector Req_Vec with the threat intelligence vector and determines whether the access request passes the first verification based on the matching result.

9. The data security authority management method based on the service side according to claim 8 is characterized in that: The first micro-sandbox pool matches the request feature vector Req_Vec with the threat intelligence vector, including: If the source IP address Src_IP of the request exists in the malicious IP blacklist BL_IP, the corresponding request is determined to be a malicious request, and the first verification fails. Otherwise, the next step is executed; If the destination URL address Dst_URL of the request exists in the malicious URL blacklist BL_URL, the corresponding request is determined to be a malicious request and the first verification fails. Otherwise, the next step is executed; If the requested method Method exists in the abnormal request method blacklist BL_Method, the corresponding request is determined to be an abnormal request and the first check fails. Otherwise, the first check passes.

10. A data security authority management system based on the service side, characterized in that: include: At least one processing unit; used to execute instructions to implement the service-side based data security authority management method as described in any one of claims 1 to 9.

Images