An access request overreach detection method, device and storage medium

Abstract

The application discloses an access request authority detection method and device and a storage medium, relates to the technical field of network security, and comprises the following steps: obtaining to-be-detected request data and corresponding response data; performing feature extraction and rule verification on the to-be-detected request data and the response data, determining a rule confidence, a rule risk value and hit rule information; when the rule confidence is less than a preset confidence threshold or the rule risk value is less than a preset risk value threshold, performing semantic reasoning analysis according to the aforementioned data and the hit rule information, and determining a fusion risk value based on the confidence and the risk value of the rule and the semantic, and determining that the request is an unauthorized request when the fusion risk value is greater than a preset fusion threshold; and determining that the request is an unauthorized request when the rule confidence is greater than or equal to the preset confidence threshold and the rule risk value is greater than or equal to the preset risk value threshold. The layered cooperation of rule verification and semantic reasoning in the application takes into account the detection real-time performance and the complex semantic scene recognition capability.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a method, device and storage medium for detecting unauthorized access requests. Background Technology

[0002] In computer network and business system security scenarios, unauthorized access detection is a crucial component of access control. With the development of cloud computing, microservices, and open interface technologies, the relationships between users, roles, organizations, resource ownership, and business states within business systems are constantly increasing, making access control boundaries increasingly complex. Unauthorized access typically falls into two categories: horizontal unauthorized access and vertical unauthorized access. Horizontal unauthorized access refers to a subject with the same permission level accessing resources belonging to other subjects, while vertical unauthorized access refers to a subject with lower privileges performing operations with higher privileges.

[0003] Currently, unauthorized access detection primarily employs static rule-based schemes. These schemes rely on manually configured rules or simple scripts to compare the request to be detected against preset rules and determine whether unauthorized behavior exists based on the matching results. However, these schemes suffer from the following problems: First, their technical identification capabilities are limited, resulting in a high false positive rate and difficulty in effectively distinguishing between legitimate requests and abnormal behavior. This is particularly problematic for public interfaces, leading to both high false positive and false negative rates. The detection system relies too heavily on predefined rules and known features, making it vulnerable to being bypassed by new attack methods. Second, they lack intelligent analysis capabilities, only able to handle preset scenarios. They struggle to understand semantic-level permission relationships such as "whether the returned data belongs to the current subject" and "whether the operation should be allowed in the current context," making them ill-equipped to effectively respond to complex and ever-changing attack methods. Third, maintenance costs are high. Manually configuring and adjusting rules is time-consuming and labor-intensive. As business scale expands and attack methods diversify, the maintenance cost of the rule base continues to increase, making it difficult to adapt to rapidly changing business needs.

[0004] On the other hand, there are also solutions that use a single intelligent analysis engine for unauthorized access detection. These solutions utilize analysis models with strong semantic understanding capabilities to perform deep discrimination of requests. However, the reasoning time of a single intelligent analysis engine is relatively long, making it difficult to meet the response speed requirements of online real-time detection. Furthermore, the stability of the reasoning results is insufficient, making it difficult to directly use as the basis for security decisions.

[0005] Therefore, how to improve the ability of over-authority detection to recognize complex semantic scenes while ensuring real-time detection is an urgent technical problem to be solved.

[0006] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0007] The main purpose of this application is to provide a method, device and storage medium for detecting unauthorized access requests, aiming to solve the technical problem of how to improve the ability of unauthorized access detection to recognize complex semantic scenarios while ensuring real-time detection.

[0008] To achieve the above objectives, this application proposes a method for detecting unauthorized access requests, the method comprising: Obtain the request data to be detected and the corresponding response data related to the access request; Feature extraction is performed on the request data to be detected and the response data, and rule verification is performed based on the feature extraction results to determine the rule confidence, rule risk value and hit rule information of the request. If the rule confidence of the request is less than a preset confidence threshold or the rule risk value is less than a preset risk value threshold, semantic reasoning analysis is performed based on the request data to be detected, the response data, and the hit rule information to determine the semantic confidence and semantic risk value of the request. Based on the rule confidence, rule risk value, semantic confidence, and semantic risk value of the request, the fusion risk value of the request is determined. If the fusion risk value is greater than a preset fusion threshold, the request is determined to be an unauthorized request; If the rule confidence level of the request is greater than or equal to a preset confidence threshold and the rule risk value is greater than or equal to a preset risk value threshold, the request is determined to be an unauthorized request.

[0009] In one embodiment, the step of feature extraction from the request data to be detected and the response data includes: Extract subject features, resource features, action features, environmental features, behavior sequence features, response features, and relationship features from the request data to be detected and the response data; The subject features, the behavior sequence features, and the relationship features are aggregated into a user context; the resource features, the response features, and the relationship features are aggregated into a resource context; the action features are aggregated into an operation context; and the environment features are aggregated into an environment context. The feature extraction result of the request is constructed based on the user context, the resource context, the operation context, and the environment context.

[0010] In one embodiment, the step of performing rule verification based on the feature extraction results to determine the rule confidence, rule risk value, and hit rule information of the request includes: Static rule matching is performed based on the feature extraction results to determine the rule confidence and initial risk score of the request. Based on the feature extraction results, dynamic baseline deviation detection is performed to determine the degree of deviation of the request from the normal behavior baseline; The response data is subjected to response structure analysis to determine the response overreach index, which characterizes the degree to which overreach data is returned in the response data; Based on the degree of deviation and the response overreach index, the initial risk score is corrected to obtain the rule risk value of the request; Based on the rule confidence level, the deviation level, the response overreach index, and the rule risk value, the hit rule information of the request is determined.

[0011] In one embodiment, the step of performing static rule matching based on the feature extraction results to determine the rule confidence of the request includes: Based on the feature extraction results and static rule matching conditions, determine each static rule triggered by the feature extraction results; The rule contribution value of each static rule is calculated based on the preset weight coefficient and matching strength coefficient of each triggered static rule. Based on the rule contribution value of each static rule, the ratio of the standard deviation to the mean of the rule contribution value of each static rule is determined to obtain the evidence consistency measure; The sufficiency of evidence is measured by the ratio of the number of static rules triggered by the feature extraction results to a preset rule number threshold. Based on the accuracy of the static rule matching results within a preset time period after manual review, a historical accuracy feedback metric is obtained. The rule confidence of the request is obtained by weighted and fused the evidence consistency measure, the evidence sufficiency measure, and the historical accuracy feedback measure.

[0012] In one embodiment, the step of performing semantic reasoning analysis based on the request data to be detected, the response data, and the hit rule information to determine the semantic confidence and semantic risk value of the request includes: The request data to be detected, the response data, and the hit rule information are transformed into a structured analysis object, which includes subject identity information, target resource information, request action information, response information, historical request sequence, and hit rule description. Based on the business domain and risk type to which the structured analysis object belongs, select the corresponding target reasoning template from the preset domain reasoning template library; Based on the target reasoning template, the reasoning results of the structured analysis object are output, including the final judgment conclusion, risk type, confidence level, list of evidence items, and reasoning steps; The semantic confidence and semantic risk value of the request are determined based on the reasoning results.

[0013] In one embodiment, the domain inference template library is associated with a case sample library, which includes normal access samples, confirmation of unauthorized access samples, false positive correction samples, and false negative reinforcement samples. The step of outputting the inference result of the structured analysis object based on the target inference template includes: Retrieve case samples similar to the structured analysis object from the case sample library; Based on the discrimination results of the retrieved case samples and the target reasoning template, the reasoning result is output.

[0014] In one embodiment, the step of determining the fusion risk value of the request based on the rule confidence, rule risk value, semantic confidence, and semantic risk value of the request includes: Using the rule confidence level as the reliability weight of the rule risk value, the rule risk value is weighted to obtain the rule weighted risk value; Using the semantic confidence level as the reliability weight of the semantic risk value, the semantic risk value is weighted to obtain the semantic weighted risk value; The fusion risk value of the request is determined based on the rule-weighted risk value, the semantic-weighted risk value, the preset rule weight coefficient, and the preset semantic weight coefficient.

[0015] In one embodiment, the method further includes: The judgment results generated during the execution of the method are stored in the feedback knowledge base. The judgment results include at least the rule confidence, the rule risk value, the hit rule information, and the corresponding unauthorized judgment conclusion. In response to a manual review instruction, perform at least one of the following operations based on the feedback knowledge base: High-frequency feature combinations are mined from the feedback knowledge base to generate static rules; False alarm cases and missed alarm cases are transformed into supplementary conditions for case samples and / or reasoning templates; Based on the accuracy and recall rates of rule validation and semantic reasoning analysis in different business domains, adjust at least one of the preset reliability threshold, the preset risk value threshold, and the preset fusion threshold.

[0016] Furthermore, to achieve the above objectives, this application also proposes an access request unauthorized detection device, which includes: The data acquisition module is used to acquire the request data to be detected and the corresponding response data related to the access request; The rule verification module is used to extract features from the request data to be detected and the response data, and to perform rule verification based on the feature extraction results, so as to determine the rule confidence, rule risk value and hit rule information of the request. The semantic reasoning module is used to perform semantic reasoning analysis based on the request data to be detected, the response data, and the hit rule information when the rule confidence of the request is less than a preset confidence threshold or the rule risk value is less than a preset risk value threshold, so as to determine the semantic confidence and semantic risk value of the request. The fusion risk determination module is used to determine the fusion risk value of the request based on the rule confidence, rule risk value, semantic confidence, and semantic risk value of the request. The first judgment module is used to determine that the request is an unauthorized request when the fusion risk value is greater than a preset fusion threshold. The second judgment module is used to determine that the request is an unauthorized request when the rule confidence of the request is greater than or equal to a preset confidence threshold and the rule risk value is greater than or equal to a preset risk value threshold.

[0017] In addition, to achieve the above objectives, this application also proposes an access request unauthorized detection device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the access request unauthorized detection method as described above.

[0018] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the access request unauthorized detection method as described above.

[0019] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the access request unauthorized detection method described above.

[0020] This application provides a method for detecting unauthorized access requests. First, features are extracted from the request data and corresponding response data to be detected. Based on the feature extraction results, rule verification is performed to determine the request's rule confidence, rule risk value, and rule hit information. Then, if the rule confidence is less than a preset confidence threshold or the rule risk value is less than a preset risk value threshold, semantic reasoning analysis is performed based on the request data, response data, and rule hit information to determine the request's semantic confidence and semantic risk value. Based on the rule confidence, rule risk value, semantic confidence, and semantic risk value, a fusion risk value for the request is determined. If the fusion risk value is greater than a preset fusion threshold, the request is determined to be an unauthorized request. If the rule confidence is greater than or equal to a preset confidence threshold and the rule risk value is greater than or equal to a preset risk value threshold, the request is determined to be an unauthorized request.

[0021] Therefore, this application uses rule confidence and rule risk values ​​output by rule verification as the basis for hierarchical routing. For unauthorized requests that can be determined with high confidence by rule verification, they are directly identified as unauthorized requests at the rule verification stage without further in-depth analysis, ensuring real-time detection. For requests that cannot be determined with high confidence by rule verification, semantic reasoning analysis uses the request data to be detected, response data, and the hit rule information produced by rule verification for in-depth discrimination, supplementing the blind spots of rule verification in complex semantic scenarios. The outputs of rule verification and semantic reasoning analysis are fused into a unified fusion risk value through confidence weighting, avoiding the influence of single engine conclusion bias on the final decision. Through the hierarchical collaboration between the rapid determination of rule verification and the in-depth discrimination of semantic reasoning analysis, and the confidence-weighted fusion decision mechanism, this application improves the ability of unauthorized detection to identify complex semantic scenarios while ensuring real-time detection. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating an embodiment of the access request unauthorized detection method of this application. Figure 2 This is a partial flowchart illustrating Embodiment 2 of the access request unauthorized detection method in this application. Figure 3 This is a partial flowchart illustrating Embodiment 3 of the access request unauthorized detection method for this application. Figure 4 This is a schematic diagram of the module structure of the access request unauthorized detection device in an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the access request unauthorized detection method in the embodiments of this application.

[0025] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0026] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0027] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with specific implementation methods.

[0028] It should be noted that unauthorized access typically includes two categories: horizontal unauthorized access and vertical unauthorized access. Horizontal unauthorized access refers to a subject with the same permission level accessing the resources of other subjects, while vertical unauthorized access refers to a subject with lower permissions performing operations with higher permissions. In this application, rule verification refers to the process of matching and detecting the data to be detected based on preset rules, and semantic reasoning analysis refers to the process of performing deep discrimination on the data to be detected using semantic understanding capabilities. The high-speed direct connection track refers to the processing path in which rule verification independently completes the adjudication, while the deep fusion track refers to the processing path in which rule verification and semantic reasoning analysis collaboratively complete the adjudication.

[0029] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a server, server cluster, or cloud server. The following description uses a server equipped with an unauthorized access detection system as an example to illustrate this embodiment and the subsequent embodiments.

[0030] Example 1 Reference Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the access request unauthorized detection method of this application. This embodiment provides an access request unauthorized detection method, which includes the following steps: Step S10: Obtain the request data to be detected and the corresponding response data related to the access request.

[0031] It's important to note that an access request refers to a request initiated by the client to the server, such as an HTTP (Hypertext Transfer Protocol) request. The request data to be detected refers to the data carried in the request used for privilege escalation detection, including the request method, request path, query parameters, request body, request headers, and information such as user identity, role, tenant, resource identifier, session identifier, and timestamp. The corresponding response data refers to the response information returned by the server after processing the request corresponding to the request data to be detected, including the response status code, response body, response headers, error codes, and a list of data fields.

[0032] It's important to clarify that "corresponding" implies that the request data and response data to be detected belong to the same request-response transaction. In other words, the response data is the result of the request being processed by the server, not a patchwork of arbitrary independent data. The request data to be detected reflects the "intent"—what operation the requesting entity wants to perform; the response data reflects the "result"—what content the server actually returns. Together, they constitute the complete "intent-execution-result" evidence chain required for determining unauthorized access: unauthorized behavior such as "returning sensitive data from another party in the response" cannot be detected solely by the request itself; the request and the corresponding response must be analyzed together.

[0033] It should be noted that the system can obtain raw requests and responses from the business system traffic pool, API (Application Programming Interface) gateway, or interface collection module. After processing, the above-mentioned request data and corresponding response data to be detected are obtained. The above data provides the basic input for subsequent feature extraction, rule validation, and semantic reasoning analysis.

[0034] Step S20: Perform feature extraction on the request data and response data to be detected, and perform rule verification based on the feature extraction results to determine the rule confidence, rule risk value and hit rule information of the request.

[0035] It should be noted that feature extraction refers to the process of extracting multi-dimensional features from the request data and response data to be detected and organizing these features in a structured manner. Feature extraction extracts features from the request data that represent dimensions such as the identity of the requesting entity, resource ownership, operational behavior, and environmental conditions, and extracts features from the response data that represent the response status and data content. The extracted features are then organized into a structured feature representation according to dimensions so that subsequent detection processes can use the relationships within and between dimensions for discrimination.

[0036] It should be noted that rule verification refers to the process of detecting requests based on feature extraction results, through static rule matching, dynamic baseline deviation detection, and response structure analysis. Specifically, rule verification matches the feature extraction results with preset rules, detects explicit unauthorized features, and corrects the matching results by considering the request's deviation from the normal behavior baseline and the return of unauthorized data in the response data, thus obtaining a rule risk value. Simultaneously, rule verification also assesses the reliability of the detection conclusion based on the consistency, sufficiency, and historical accuracy of the triggering rules, obtaining the rule confidence level. Hit rule information refers to the comprehensive output information of rule verification, including a list of triggering rules and corresponding contribution descriptions, for reference in semantic reasoning analysis.

[0037] It should be noted that rule confidence represents the reliability of rule validation for the current detection conclusion, while rule risk value represents a quantitative score of the risk of rule validation for the current request. Rule confidence and rule risk value together serve as the basis for subsequent hierarchical traffic allocation. The specific implementation of feature extraction and rule validation will be further explained in Example 2.

[0038] Step S30: If the confidence level of the requested rule is less than the preset confidence threshold or the risk value of the rule is less than the preset risk value threshold, semantic reasoning analysis is performed based on the request data to be detected, the response data, and the hit rule information to determine the semantic confidence level and semantic risk value of the request.

[0039] It should be noted that the preset confidence threshold refers to a preset threshold used to determine whether the confidence level of a rule reaches the reliability judgment standard, and the preset risk value threshold refers to a preset threshold used to determine whether the risk value of a rule reaches the risk identification standard. These thresholds are pre-configured according to business security requirements. For example, the preset confidence threshold can be configured to 0.9, and the preset risk value threshold can be configured to 80. In a feasible implementation, the preset confidence threshold and preset risk value threshold can be configured hierarchically according to business domain, tenant, or institution. Different business domains can be configured with different threshold combinations to adapt to the differentiated tolerance of each business domain for false positive and false negative rates. For example, for fund transaction business domains, the preset confidence threshold and preset risk value threshold can be configured relatively leniently to reduce the false negative rate; for information display business domains, the thresholds can be configured relatively strictly to reduce the false positive rate.

[0040] It should be noted that when the rule confidence level is lower than the preset confidence threshold or the rule risk value is lower than the preset risk value threshold, it indicates that rule verification cannot independently complete the decision with high confidence. The rule then requests entry into the deep fusion track and is submitted to the message queue to await semantic reasoning analysis. Through message queue decoupling, the real-time detection of the high-speed direct connection track and the deep analysis of the deep fusion track do not block each other. Rule verification and semantic reasoning analysis can be scaled and upgraded independently. Semantic reasoning analysis consumes events to be analyzed from the message queue.

[0041] It should be noted that semantic reasoning analysis refers to the process of using semantic understanding capabilities to perform in-depth discrimination of the requests to be detected. Semantic reasoning analysis organizes the request data, response data, and hit rule information into a structured analysis object, and performs joint discrimination on the permission boundaries of the request subject, the ownership relationship of the target resource, the operation semantics, and the response result based on a pre-set reasoning template, outputting a reasoning result that includes the judgment conclusion and confidence level.

[0042] It should be noted that semantic confidence represents the reliability of the semantic reasoning analysis's own judgment conclusion, and is obtained from the reasoning result; semantic risk value represents the quantified risk of the current request by the semantic reasoning analysis, and is determined based on the judgment conclusion in the reasoning result. The specific implementation of semantic reasoning analysis will be further explained in Example 3.

[0043] Step S40: Determine the fusion risk value of the request based on the rule confidence, rule risk value, semantic confidence, and semantic risk value of the request.

[0044] It should be noted that the fusion risk value refers to the unified risk quantification value obtained by weighting and combining the rule verification output and the semantic reasoning analysis output. The determination of the fusion risk value is performed after the semantic reasoning analysis is completed. The rule confidence and rule risk values ​​are the outputs of rule verification in step S20, and the semantic confidence and semantic risk values ​​are the outputs of semantic reasoning analysis in step S30.

[0045] It should be noted that the determination of the fusion risk value uses confidence level as the reliability weight of the risk value: the rule risk value is weighted by the rule confidence level, and the semantic risk value is weighted by the semantic confidence level. The output with higher confidence level occupies a larger proportion in the fusion result; the two weighted results are combined according to the preset weight coefficient to obtain the fusion risk value. The specific calculation of the fusion risk value will be further explained in Example 3.

[0046] Step S50: If the fusion risk value is greater than the preset fusion threshold, the request is determined to be an unauthorized request.

[0047] It should be noted that the preset fusion threshold refers to a pre-defined threshold used for the final determination of fusion risk values, and it can also be configured hierarchically according to business domains. When the fusion risk value is greater than the preset fusion threshold, the request is determined to be an unauthorized request; when the fusion risk value is less than or equal to the preset fusion threshold, the request is determined to be a normal request. At this point, the request in the deep fusion track has completed its final determination. An unauthorized request refers to a request that exhibits unauthorized behavior, including horizontal and vertical unauthorized behavior.

[0048] Step S60: If the requested rule confidence is greater than or equal to a preset confidence threshold and the rule risk value is greater than or equal to a preset risk value threshold, the request is determined to be an unauthorized request.

[0049] It should be noted that when the above conditions are met, it indicates that the rule verification can determine with high confidence that the current request involves unauthorized behavior. At this time, the request enters the high-speed direct connection track, where rule verification directly determines that the request is an unauthorized request, without needing to enter the semantic reasoning analysis and fusion calculation stages. The processing time of the high-speed direct connection track is typically in the millisecond range. After determining that the request is an unauthorized request, the system also performs alarm handling and evidence recording operations, recording detection evidence such as the triggering rule, rule risk value, rule confidence level, and response unauthorized indicators to the audit log for review by security operations personnel.

[0050] In this embodiment, through steps S10 to S60, rule verification uses rule confidence and rule risk value as the basis for hierarchical routing: requests that cannot be determined with high confidence by rule verification enter the semantic reasoning analysis and fusion calculation stage, and the semantic reasoning analysis performs deep discrimination based on the request data to be detected, response data, and hit rule information, supplementing the blind spots of rule verification in the recognition of complex semantic scenarios, and finally making a unified decision through the fusion risk value; unauthorized requests that can be determined with high confidence by rule verification are identified as unauthorized requests in the rule verification stage, without needing to enter the semantic reasoning analysis and fusion calculation stage, thus ensuring the real-time nature of detection. Through the above-mentioned hierarchical collaboration, this application improves the ability of unauthorized detection to recognize complex semantic scenarios while ensuring the real-time nature of detection.

[0051] Example 2 Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the first embodiment can be referred to the above description, and will not be repeated hereafter.

[0052] This embodiment describes the specific implementation of feature extraction and rule verification in Embodiment 1.

[0053] In one feasible implementation, the step of feature extraction from the request data and response data to be detected can be further implemented through the following sub-steps: Step S210: Extract subject features, resource features, action features, environmental features, behavior sequence features, response features, and relationship features from the request data and response data to be detected.

[0054] It should be noted that: Subject characteristics refer to features that characterize the identity information of the requesting subject, used to determine the permission boundaries of the requesting subject, including user ID, role, organization, tenant, and token identifier; Resource characteristics refer to features that characterize the information of the accessed target resource, used to determine the ownership relationship of the accessed target, including request path pattern, resource ID, resource owner, tenant, and resource status; Action characteristics refer to features that characterize the request operation information, used to distinguish different risky operations such as query, modification, deletion, approval, and authorization, including HTTP methods, interface semantic actions, batch operation identifiers, and standardized signatures of query parameters, request body fields, and key request headers; Environment characteristics refer to features that characterize the environment in which the request occurs, used to describe the operating environment, including source IP (Internet...). Protocol (Internet Protocol) address, User-Agent, device fingerprint, session ID, and access channel, etc.; Behavioral sequence features refer to features that characterize the recent behavioral patterns of the requesting subject, used to identify multi-step bypasses and abnormal request chains, including the most recent N request sequences, request frequency, previous request status, and path jump relationships, etc.; Response features refer to features that characterize the content of the response data, used to identify data return scenarios that appear successful but actually involve unauthorized access, including response status codes, response field structures, sensitive field hit rates, and whether the resource owner matches the current subject, etc.; Relationship features refer to features that characterize the association between the subject and the resource, and between the subject and the role, including the affiliation between the user and the resource, and the subordination between the user and the role, etc.

[0055] It should be noted that during feature extraction, the system also converts the original request path into a structured placeholder pattern to mitigate the impact of resource IDs and random strings on matching stability. For example, the original URL (Uniform Resource Locator) is " / api / v1 / users / 12345 / accounts", and the converted structured pattern is " / api / v1 / users / {user_id} / accounts". Simultaneously, the system sorts, normalizes, de-identifies, and performs signature calculations on the parameters to identify risky behaviors such as similar resource enumeration, out-of-bounds parameter combinations, and cross-tenant access jumps.

[0056] Step S220: Aggregate subject features, behavior sequence features, and relationship features into user context; aggregate resource features, response features, and relationship features into resource context; aggregate action features into operation context; and aggregate environmental features into environmental context.

[0057] It should be noted that user context refers to the set of features describing "who is operating," including user identity, role, permission level, organization, and dynamic behavior sequence; resource context refers to the set of features describing "what is being operated," including target resource type, resource identifier, resource owner, data sensitivity level, and returned data content; operation context refers to the set of features describing "what was done," including operation type, operation time, operation frequency, and operation intent; and environment context refers to the set of features describing "the environment in which the operation took place," including network location, device information, session information, and access channel. Relationship features belong to the association dimension and are aggregated into both user context and resource context to represent the association relationships between users and resources, and between users and roles.

[0058] Step S230: Construct the feature extraction results of the request based on the user context, resource context, operation context, and environment context.

[0059] It should be noted that the feature extraction result refers to the structured representation after organizing the user context, resource context, operation context, and environment context. This serves as the input foundation for subsequent rule validation and semantic reasoning analysis. The context organization of these four dimensions naturally aligns with mature access control models: user context corresponds to subject attributes, resource context to object attributes, operation context to operation types, and environment context to environment attributes. This alignment makes the detection logic naturally conform to the basic model of access control, facilitating rule validation and semantic reasoning analysis in understanding business semantics.

[0060] It should be noted that after aggregating features according to the four dimensions mentioned above, the information input to subsequent detection stages transforms from a scattered list of features into a structured contextual description. Different detection stages can call upon information from the corresponding dimensions according to the needs of the detection task and perform cross-validation using the constraints within and between dimensions. For example, there may be a permission conflict between "ordinary user" in the user context and "administrator configuration interface" in the resource context. This conflict is difficult to capture in flat features, but it can be intuitively detected in the aggregated context. Another example is when the same user performs sensitive operations from an unconventional IP address outside of working hours; both the operation context and the environment context need to be analyzed simultaneously to detect the anomaly. The above context organization method naturally endows the system with the ability for multi-dimensional cross-correlation analysis.

[0061] In this embodiment, through steps S210 to S230, the seven independent features are aggregated into user context, resource context, operation context and environment context according to dimensions to construct a complete access control semantic space. This allows subsequent detection to make full use of the constraints within and between dimensions for cross-validation, while reducing feature noise and providing a structured input basis for rule validation and semantic reasoning analysis.

[0062] In one feasible implementation, refer to Figure 2 , Figure 2 This is a partial flowchart of Embodiment 2 of the access request unauthorized detection method of this application. The step of rule verification based on the feature extraction results can be further implemented through the following sub-steps: Step S240: Perform static rule matching based on the feature extraction results to determine the requested rule confidence and initial risk score.

[0063] It should be noted that static rule matching refers to the process of comparing the feature extraction results with preset static rules to detect whether there are explicit high-risk unauthorized features. Rules are stored in YAML (YAML Ain't Markup Language, a data serialization format), DSL (Domain Specific Language), JSON (JavaScript Object Notation, a lightweight data exchange format), or database rule table format. The rule definition file or rule configuration data is dynamically loaded at runtime without requiring a service restart. Each rule includes elements such as rule identifier, subject scope, resource mode, operation type, matching conditions, risk score, and handling suggestion. For example, a rule can be configured with a subject scope of ordinary user roles, a resource mode of " / api / admin / ", an operation type of DELETE, a risk score of 80, and a handling suggestion of blocking. In one feasible implementation, the rule base supports tenant-isolated management; rule sets for different tenants are maintained and published independently without affecting each other.

[0064] It should be noted that explicit high-risk privilege escalation characteristics detected by static rule matching include, for example, low-privilege entities accessing the paths " / admin / ." or " / api / internal / .", non-administrators performing high-risk write operations, or requests containing abnormal role fields or parameters for unauthorized operations. If a rule is matched, the corresponding risk score is accumulated.

[0065] It should be noted that the initial risk score refers to the quantified risk value determined solely by the static rule matching results and without adjustment in subsequent correction stages. The initial risk score is determined comprehensively based on the rule risk contribution values ​​of each rule triggered in the static rule matching process. For each triggered rule, its rule risk contribution value is jointly determined by the rule's preset weight coefficient, matching strength coefficient, and frequency attenuation factor. The preset weight coefficient is set by security experts based on the severity of the threats covered by the rule, and its value ranges from 0.1 to 1.0. For example, the preset weight coefficient for matching the "accessing other people's sensitive data" rule is 0.9, and the preset weight coefficient for matching the "abnormal User-Agent" rule is 0.3. The matching strength coefficient represents the degree of matching between the current request and the rule definition. For Boolean rules, the value is 1 or 0. For fuzzy matching rules based on regular expressions or similarity calculations, the value is a continuous value from 0 to 1. The frequency decay factor is used to suppress the artificially high score caused by the same source repeatedly triggering the same rule within the sliding time window. The frequency decay factor decreases as the number of triggers increases. The more times the same source triggers the same rule within the sliding time window, the smaller the frequency decay factor becomes.

[0066] It should be noted that when a request triggers multiple rules, an evidence-theory fusion method is used to synthesize the rule risk contribution values ​​of each rule, rather than simply summing them, to avoid score explosion. The evidence-theory fusion method ensures that the overall score always remains within the range of 0 to 1, and that newly added evidence monotonically increases the score. The overall score obtained through evidence-theory fusion is the initial risk score. The specific method for determining the rule confidence level will be explained in steps S2401 to S2406 below.

[0067] Step S250: Based on the feature extraction results, perform dynamic baseline deviation detection to determine the degree of deviation of the request from the normal behavior baseline.

[0068] It should be noted that dynamic baseline deviation detection refers to the process of comparing the feature extraction results of the current request with the normal behavior baseline to measure the degree of abnormality in the request behavior. The normal behavior baseline refers to the historical statistical distribution of normal behavior established by dimension, such as role, tenant, position, or business domain. The deviation degree refers to the quantitative value of the deviation of the current request from the normal behavior baseline. The deviation degree can be calculated using at least one of the following indicators: Mahalanobis distance, cluster center deviation, sequence similarity, or temporal probability distribution deviation.

[0069] For example, for scenarios involving deviations in behavioral sequences, Mahalanobis distance can be used to measure the distance between the multidimensional feature vector of the current request and the center of the normal behavioral baseline distribution; for scenarios involving request path sequences, sequence similarity can be used to measure the difference between the current request path sequence and historical normal sequence patterns. When the deviation exceeds a threshold, the risk score will be increased in subsequent correction stages.

[0070] Step S260: Perform response structure analysis on the response data to determine the response over-weighting index. The response over-weighting index characterizes the degree to which over-weighted data is returned in the response data.

[0071] It should be noted that response structure analysis refers to the process of parsing the status code, response structure, and sensitive fields of the response data to determine whether unauthorized data is returned. The response unauthorized access index is a quantitative indicator characterizing the degree to which unauthorized data is returned in the response data. For example, if the response code is 200 and the returned object contains other users' email addresses, phone numbers, or ID numbers, or if the interface semantics only allow viewing one's own data but the response returns cross-subject resource content, then the response unauthorized access index will take the higher value.

[0072] It should be noted that for scenarios lacking explicit rules for matching, the system can also perform similarity analysis: the target response is vectorized and the normal baseline response or the original response is calculated for similarity. When the similarity is abnormal or the difference exceeds a threshold, it is used as an auxiliary basis for determining unauthorized actions. For example, the field structure, number of fields, and distribution of sensitive fields in the response body can be encoded as feature vectors, and cosine similarity can be used to calculate the degree of difference between the target response and the normal baseline response.

[0073] Step S270: Based on the degree of deviation and the response overreach index, the initial risk score is corrected to obtain the requested rule risk value.

[0074] It should be noted that the rule-based risk value refers to the final quantitative risk score after adjustments for deviation and unauthorized response indicators. The adjustment method is as follows: based on the initial risk score, the rule-based risk value is increased proportionally according to the deviation and unauthorized response indicators. The greater the deviation and the higher the degree of unauthorized data return represented by the unauthorized response indicators, the greater the increase in the rule-based risk value. For example, the default value of the deviation adjustment coefficient can be 0.3, meaning that the increase in the rule-based risk value is directly proportional to the normalized deviation.

[0075] Step S280: Determine the hit rule information of the request based on rule confidence, deviation degree, response overreach index and rule risk value.

[0076] It should be noted that the hit rule information refers to the comprehensive output information of rule verification. It is a rule-layer detection profile for semantic reasoning analysis, including a list of triggering rules and a description of each rule's contribution, deviation degree, response overreach index, and rule risk value. For example, rule verification outputs results using a standard JSON structure. The output content may include fields such as rule risk value, list of triggering rules, deviation degree, rule confidence, and handling suggestions. The above output can be directly consumed by semantic reasoning analysis.

[0077] In this embodiment, through steps S240 to S280, rule verification detects the data to be detected from three dimensions: static rules, dynamic baseline, and response structure, and produces rule confidence, rule risk value, and rule hit information. The rule risk value, after being corrected for deviation degree and response overreach index, reflects the degree of overreach of the request at the level of behavior pattern and response result, providing a reliable quantitative basis for hierarchical traffic division and fusion adjudication.

[0078] In one feasible implementation, the step of determining the confidence level of the requested rule through static rule matching based on the feature extraction results can be further implemented through the following sub-steps: Step S2401: Based on the feature extraction results and static rule matching conditions, determine the static rules triggered by the feature extraction results.

[0079] It should be noted that static rule matching conditions refer to the conditional elements in a rule used to determine whether a rule is triggered, including the subject scope, resource mode, operation type, and matching conditions in the rule. The system compares the user context information, resource context information, and operation context information in the feature extraction results with the static rule matching conditions of each rule to determine which static rules are triggered by the feature extraction results.

[0080] Step S2402: Calculate the rule contribution value of each static rule based on the preset weight coefficient and matching strength coefficient of each triggered static rule.

[0081] It should be noted that the rule contribution value refers to the quantified value of the support strength of the triggering rule for the current detection conclusion, which is determined by the preset weight coefficient of the rule itself and the matching strength coefficient of this match. In a feasible implementation, the determination of the rule contribution value can also be combined with a frequency attenuation factor. The frequency attenuation factor is used to suppress the impact of the same source repeatedly triggering the same rule within the sliding time window on the contribution value. The specific implementation method can be flexibly selected according to the configuration of the detection scenario.

[0082] Step S2403: Based on the rule contribution value of each static rule, determine the ratio of the standard deviation to the mean of the rule contribution value of each static rule to obtain the evidence consistency measure.

[0083] It should be noted that the consistency measure of evidence refers to a quantitative value that characterizes the degree of consistency between the output conclusions of various triggering rules. The consistency measure of evidence can be expressed as:

[0084] Where C_cons represents the evidence consistency measure, sd represents the standard deviation of the rule contribution value of each static rule, and avg represents the mean of the rule contribution value of each static rule. When the contribution values ​​of each rule tend to be consistent, sd / avg is small, and the evidence consistency measure approaches 1; when the contribution values ​​of each rule are dispersed, the evidence consistency measure decreases.

[0085] Step S2404: Based on the ratio of the number of static rules triggered by the feature extraction results to the preset rule number threshold, obtain the evidence sufficiency measure.

[0086] It should be noted that the evidence sufficiency measure is a quantitative value that characterizes the degree to which the number of triggering rules supports the detection conclusion. The preset rule number threshold is the minimum number of rules required for the confidence level to reach saturation. The more triggering rules there are, the higher the evidence sufficiency measure is; when the number of triggering rules reaches the preset rule number threshold, the evidence sufficiency measure takes a saturation value of 1. For example, an empirical value for the preset rule number threshold can be set to 3, that is, when the number of triggering rules reaches 3, the evidence sufficiency measure reaches saturation.

[0087] Step S2405: Based on the accuracy of the static rule matching results within a preset time period after manual review, obtain the historical accuracy feedback metric.

[0088] It should be noted that the historical accuracy feedback metric is a quantitative value characterizing the reliability of the rule verification's historical performance. It is determined by the accuracy of the output conclusions of static rule matching within a sliding time window after manual review. The statistical period is the past 7 days, and the accuracy is obtained by dividing the number of true positives by the sum of the number of true positives and false positives. When the historical review accuracy is high, the historical accuracy feedback metric takes a higher value, and the rule confidence increases accordingly; when the historical review accuracy is low, the rule confidence decreases accordingly.

[0089] Step S2406: The evidence consistency measure, evidence sufficiency measure, and historical accuracy feedback measure are weighted and fused to obtain the requested rule confidence.

[0090] It should be noted that the weighted fusion method can be expressed as:

[0091] Where R_conf represents rule confidence, C_cons represents the evidence consistency measure, C_suff represents the evidence sufficiency measure, H_acc represents the historical accuracy feedback measure, c1 represents the baseline confidence bias with a value of 0.3, and c2 represents the historical accuracy weighting coefficient with a value of 0.7. This weighted fusion method ensures a certain confidence baseline even without historical data.

[0092] In this embodiment, through steps S2401 to S2406, the rule confidence is obtained by weighted fusion of evidence consistency measure, evidence sufficiency measure and historical accuracy feedback measure. The rule verification outputs a quantitative assessment of the reliability of its own judgment while outputting the risk value, which provides a quantitative basis for subsequent hierarchical diversion and fusion adjudication, and avoids the bias of adjudication based solely on a single risk value.

[0093] Example 3 Based on the first embodiment of this application, in the third embodiment of this application, the contents that are the same as or similar to those in the first and second embodiments described above can be referred to the above description and will not be repeated hereafter.

[0094] In one feasible implementation, refer to Figure 3 , Figure 3 The following is a partial flowchart illustrating the third embodiment of the access request unauthorized access detection method of this application. The step of determining the semantic confidence and semantic risk value of the request by performing semantic reasoning analysis based on the request data to be detected, the response data, and the hit rule information can be further implemented through the following sub-steps: Step S310: The request data, response data and hit rule information to be detected are transformed into structured analysis objects. The structured analysis objects include subject identity information, target resource information, request action information, response information, historical request sequence and hit rule description.

[0095] It should be noted that structured analysis objects refer to data objects that organize the request data, response data, and hit rule information to be detected into a unified format, which can be directly consumed by semantic reasoning analysis. Specifically, subject identity information refers to the identity description information of the requesting subject, including user, role, tenant, organization, etc.; target resource information refers to the description information of the target resource requested, including resource type, resource owner, tenant, status, etc.; request action information refers to the operation description information of the request, including HTTP methods and interface semantic actions; response information refers to the description information of the results returned by the server, including response status code and response field structure; historical request sequence refers to the sequence summary of the requesting subject's most recent N related requests; and hit rule description refers to the hit rule information produced by rule verification, i.e., the rule-layer hit items and their risk descriptions.

[0096] It should be noted that the system performs the above transformation after consuming the events to be analyzed from the message queue. For example, the data format of the structured analysis object is as follows: { "subject": {"role": "user", "tenant": "A", "user_id": "u1001"}, "resource": {"type": "profile", "owner_id": "u2048", "tenant": "A"}, "action": {"method": "GET", "semantic_action": "read_profile"}, "response": {"status_code": 200, "sensitive_fields": ["email", "mobile"]}, "history": ["read_self_profile", "list_department_users"], "rule_hits": ["RULE_001", "RULE_017"] } In this structured analysis object, `subject` represents the subject's identity information, `resource` represents the target resource information, `action` represents the request action information, `response` represents the response information, `history` represents the historical request sequence, `rule_hits` represents the hit rule description, `GET` represents the retrieval operation, `semantic_action` represents the interface semantic action, `status_code` represents the response status code, and `sensitive_fields` represents sensitive fields. It should be noted that the structured analysis object can also include business domain permission constraint descriptions, such as "ordinary users are only allowed to access their own information." The system selectively incorporates the above information into the structured analysis object based on the business domain configuration.

[0097] Step S320: Select the corresponding target reasoning template from the preset domain reasoning template library according to the business domain and risk type to which the structured analysis object belongs.

[0098] It should be noted that the business domain refers to the business scenario domain to which the request to be detected belongs, such as account management, fund transaction, or content management; the risk type refers to the category of unauthorized access risks that the request to be detected may involve, such as horizontal unauthorized access, vertical unauthorized access, or response leakage. The domain inference template library refers to a pre-built collection of inference templates for unauthorized access scenarios. The target inference template refers to the template selected from the domain inference template library based on the business domain and risk type, and used for this inference.

[0099] It should be noted that the domain reasoning template library includes built-in domain reasoning templates such as vertical privilege escalation detection templates, horizontal privilege escalation detection templates, response leakage detection templates, multi-step business bypass detection templates, cross-tenant resource access detection templates, and permission inheritance anomaly and state transition detection templates. Each reasoning template pre-sets key points for different types of privilege escalation scenarios: the vertical privilege escalation detection template judges based on the comparison between the subject's permission level and the required permission level of the target resource; the horizontal privilege escalation detection template judges based on the attribution relationship between the target resource owner and the current subject's identity; the response leakage detection template judges based on the relationship between sensitive fields in the response data and the current subject's accessible scope; the multi-step business bypass detection template judges based on the sequential dependencies of each step in the historical request sequence; the cross-tenant resource access detection template judges based on the consistency between the requesting subject tenant and the target resource tenant; and the permission inheritance anomaly and state transition detection template judges based on the role inheritance chain and business state transition conditions. The system selects the corresponding target reasoning template based on the business domain and risk type of the structured analysis object, and makes judgments based on factors such as minimum authority requirements, actual authority of the subject, resource ownership, semantics of response results, and contextual dependencies.

[0100] Step S330: Based on the target reasoning template, output the reasoning results of the structured analysis object. The reasoning results include the final judgment conclusion, risk type, confidence level, list of evidence items, and reasoning steps.

[0101] It should be noted that the reasoning result refers to the structured conclusion output by semantic reasoning analysis after judging the structured analysis object. Specifically, the final judgment conclusion refers to the judgment on whether the structured analysis object carries an unauthorized access risk; the risk type refers to the category of unauthorized access risk corresponding to the judgment conclusion; the confidence level refers to the reliability assessment value of the judgment conclusion by semantic reasoning analysis; the evidence list refers to the set of evidence items supporting the judgment conclusion; and the reasoning steps refer to the description of the reasoning process leading to the judgment conclusion.

[0102] It should be noted that, to improve output stability, semantic reasoning analysis sets input field constraints, output field constraints, conclusion enumeration constraints, evidence extraction constraints, and confidence constraints. Specifically, the conclusion enumeration constraint limits the final judgment to an enumerated value, such as "there is a risk of exceeding authority" and "there is no risk of exceeding authority." The confidence constraint limits the confidence level to the range of 0 to 1. The reasoning results are output using a standardized JSON structure, as exemplified below: { "final_judgment": "There is a risk of unauthorized access". "risk_type": "Horizontal overreach" "confidence": 0.92, "evidence_items": [ "The main user is a regular user and is only allowed to access their own personal information." "The target resource owner_id is inconsistent with the current user_id". The response status code is 200 and sensitive fields such as email and mobile are returned. ], "reasoning_steps": [ "Identify the boundaries of the subject's authority" "Identify the ownership relationship of the target resource" "Judging unauthorized data leakage based on the response content" ] } Here, final_judgment represents the final judgment, risk_type represents the risk type, confidence represents the confidence level, evidence_items represents the list of evidence items, and reasoning_steps represents the reasoning steps.

[0103] It should be noted that semantic reasoning analysis employs an output method that combines an enumerated final judgment with continuously evaluated confidence scores. This is because the analytical model used in semantic reasoning analysis lacks stable numerical calibration capabilities for outputting continuous risk scores. If continuous risk scores are required, the same request may yield significantly different scores in different reasoning rounds, and these scores lack mathematical benchmark support, making precise calibration impossible. By restricting the final judgment to enumerated values ​​through conclusion enumeration constraints, output stability is achieved through discretization. Simultaneously, continuously evaluated confidence scores compensate for the loss of information granularity in enumerated conclusions—the combination of binary conclusions and continuous confidence scores still expresses a nuanced level of risk.

[0104] Step S340: Determine the semantic confidence and semantic risk value of the request based on the reasoning results.

[0105] It should be noted that semantic confidence corresponds to the confidence field in the reasoning result; the semantic risk value is determined quantitatively based on the final judgment conclusion in the reasoning result. When the final judgment conclusion is "there is a risk of exceeding authority", the semantic risk value is 100, and when the final judgment conclusion is "there is no risk of exceeding authority", the semantic risk value is 0.

[0106] In this embodiment, through steps S310 to S340, semantic reasoning analysis transforms the request data, response data, and hit rule information to be detected into structured analysis objects, performs reasoning based on the target reasoning template in the domain reasoning template library, and outputs reasoning results including the final judgment conclusion and confidence level, realizing the quantitative output of deep analysis results; and semantic reasoning analysis can refer to the hit rule information of rule verification for discrimination, forming a collaborative rather than independent detection relationship with rule verification.

[0107] In one feasible implementation, the domain inference template library is associated with a case sample library, which includes normal access samples, confirmation of unauthorized access samples, false positive correction samples, and false negative reinforcement samples. The step of outputting inference results based on the target inference template can be further implemented through the following sub-steps: Step S331: Retrieve case samples similar to the structured analysis object from the case sample library.

[0108] It should be noted that the case sample library refers to a collection of historical cases established based on business domains to assist in reasoning and judgment. Among them, normal access samples refer to normal request cases that have been confirmed to have no unauthorized behavior; confirmed unauthorized access samples refer to unauthorized request cases that have been confirmed to have unauthorized behavior; false alarm correction samples refer to normal request cases that were previously misjudged as unauthorized and corrected by manual review; and missed alarm reinforcement samples refer to unauthorized request cases that were previously missed as normal and corrected by manual review. False alarm samples confirmed by manual review can be bound to the corresponding template category.

[0109] It should be noted that before inference, the system retrieves case samples similar to the current structured analysis object from the case sample library. Similarity can be measured by calculating the similarity between feature vectors based on dimensions such as subject identity information, target resource information, request action information, and response information, and the several case samples with the highest similarity are retrieved as reference samples.

[0110] Step S332: Based on the discrimination results of the retrieved case samples and the target reasoning template, output the reasoning results.

[0111] It should be noted that the judgment results of the retrieved case samples serve as an important reference in addition to the target inference template, and together with the target inference template, they guide the output of the inference results. For example, if the retrieved similar case samples are confirmed by manual review to be out-of-authority cases, the confidence level of the current inference can be increased accordingly; if the similar case samples are false alarm correction samples, the current inference needs to be revised based on the cause of the false alarm in order to enhance the consistency of judgment of subsequent similar cases.

[0112] In this embodiment, through steps S331 to S332, in addition to the target reasoning template, the reasoning process also retrieves case samples similar to the structured analysis object from the case sample library. Based on the discrimination results of the case samples and the target reasoning template, the reasoning results are jointly output, which improves the consistency of semantic reasoning analysis in discriminating similar overreach scenarios.

[0113] In one feasible implementation, the step of determining the fusion risk value of a request based on the request's rule confidence, rule risk value, semantic confidence, and semantic risk value can be further implemented through the following sub-steps: Step S350: Using the rule confidence level as the reliability weight of the rule risk value, the rule risk value is weighted to obtain the rule weighted risk value.

[0114] It should be noted that reliability weight refers to the weighting factor used to measure the credibility of the risk value. Rule-weighted risk value is the risk value obtained by weighting the rule risk value with rule confidence, i.e., the product of rule confidence and rule risk value. The higher the rule confidence, the more reliable the rule risk value, and the greater its contribution to the fusion process.

[0115] Step S351: Using semantic confidence as the reliability weight of semantic risk value, the semantic risk value is weighted to obtain the semantic weighted risk value.

[0116] It should be noted that the semantically weighted risk value refers to the risk value after the semantic risk value is weighted by the semantic confidence value, that is, the product of the semantic confidence value and the semantic risk value. The higher the semantic confidence value, the more reliable the semantic risk value is, and the greater the contribution of the semantic risk value in the fusion.

[0117] Step S352: Determine the fusion risk value of the request based on the rule-weighted risk value, the semantic-weighted risk value, the preset rule weight coefficient, and the preset semantic weight coefficient.

[0118] It should be noted that the preset rule weight coefficient refers to the preset weight of the rule verification side in the fusion calculation, and the preset semantic weight coefficient refers to the preset weight of the semantic reasoning and analysis side in the fusion calculation. The fusion risk value can be expressed as:

[0119] Where F represents the fusion risk value, w1 represents the preset rule weight coefficient with an initial value of 0.7, w2 represents the preset semantic weight coefficient with an initial value of 0.3, R_conf represents the rule confidence score, R_score represents the rule risk value, S_conf represents the semantic confidence score, and S_score represents the semantic risk value. When the fusion risk value is greater than the preset fusion threshold, the request is determined to be an unauthorized request; when the fusion risk value is less than or equal to the preset fusion threshold, the request is determined to be a normal request.

[0120] It should be noted that, in one feasible implementation, when the conclusion of rule verification is inconsistent with the conclusion of semantic reasoning analysis, the system can further integrate information such as the confidence level of both parties, the historical reliability of rule hits, the completeness of evidence, the level of misjudgment cost in the business domain, and recent review results to conduct manual review or enhanced audit of boundary cases, so as to improve the reliability of the final ruling.

[0121] In this embodiment, through steps S350 to S352, the rule confidence level is used as the reliability weight of the rule risk value, and the semantic confidence level is used as the reliability weight of the semantic risk value. The output with higher confidence level occupies a larger proportion in the fused risk value, thereby realizing a unified decision based on reliability weighting and avoiding the influence of the conclusion bias of a single detection link on the final decision.

[0122] In one feasible implementation, this embodiment also provides a feedback learning mechanism, which is specifically implemented through the following steps: Step S360: Store the judgment results generated during the method execution into the feedback knowledge base. The judgment results shall include at least the rule confidence level, rule risk value, hit rule information, and corresponding unauthorized judgment conclusion.

[0123] It should be noted that the judgment result refers to the ruling made during the detection process regarding whether the request exceeded its authority. The feedback knowledge base is a data repository used to store the judgment results for system learning and optimization. All judgment results from the high-speed direct connection track and the deep fusion track are stored in the feedback knowledge base, forming a complete learning data loop. Specifically, cases directly adjudicated by rule verification in the high-speed direct connection track are automatically accumulated as high-confidence samples for rule verification; cases adjudicated by the fusion of rule verification and semantic reasoning analysis in the deep fusion track are simultaneously accumulated as training samples for both rule verification and semantic reasoning analysis.

[0124] Step S370: In response to the manual review instruction, perform at least one of the following operations based on the feedback knowledge base.

[0125] It should be noted that a manual review instruction refers to an instruction triggered by security testers or operations personnel through the management interface, which instructs the system to perform optimization operations based on the feedback knowledge base. After being triggered, the system performs at least one of the following optimization operations based on the feedback knowledge base.

[0126] Step S371: Mine high-frequency feature combinations from the feedback knowledge base to generate static rules.

[0127] It should be noted that high-frequency feature combinations refer to feature combinations that frequently appear in the judgment results of the feedback knowledge base and are related to unauthorized access determination. The system automatically discovers high-frequency feature combinations in the judgment results of the feedback knowledge base through frequent data mining, association rule learning, or pattern clustering, and generates candidate static rule suggestions for security personnel to review and incorporate into the rule base. For example, if a large number of cases in the feedback knowledge base that have been verified as unauthorized access all share the feature combination of "low-privilege role accessing batch export interface," the system can automatically generate corresponding candidate static rules.

[0128] Step S372: Convert false positive cases and false negative cases into supplementary conditions for case samples and / or reasoning templates.

[0129] It should be noted that false positives refer to legitimate requests that are incorrectly judged as unauthorized; false negatives refer to legitimate requests that are incorrectly judged as unauthorized. False positives and false negatives that have been manually reviewed and corrected can be transformed into new case samples, supplementary conditions for reasoning templates, or counterexample constraints. For example, a certain type of falsely reported legitimate batch operation case can be transformed into a false positive correction sample and bound to the corresponding template category; a certain type of false negative response leakage case can be transformed into a false negative reinforcement sample and used as a supplementary condition for the response leakage discrimination template.

[0130] Step S373: Based on the accuracy and recall rates in different business domains analyzed by rule verification and semantic reasoning, adjust at least one of the preset reliability threshold, preset risk value threshold, and preset fusion threshold.

[0131] It should be noted that accuracy refers to the proportion of correctly identified cases in the detection results, while recall refers to the proportion of actually unauthorized requests that are correctly detected. The system dynamically adjusts the aforementioned threshold parameters based on the accuracy, recall, false positive rate, and false negative rate of rule validation and semantic reasoning analysis in different business domains, continuously optimizing the detection accuracy of each business domain. In one feasible implementation, the system can also simultaneously adjust the preset rule weight coefficient and the preset semantic weight coefficient—when the accuracy of rule validation in a specific business domain is consistently higher than that of semantic reasoning analysis, the preset rule weight coefficient is appropriately increased; conversely, when semantic reasoning analysis performs better in terms of recall in a specific business domain, the preset semantic weight coefficient is appropriately increased, so that the calculation of the fused risk value matches the actual detection capability distribution of that business domain.

[0132] In this embodiment, through steps S360 to S373, the judgment results generated during the detection process are stored in the feedback knowledge base, and in response to the manual review instruction, the system performs rule generation, sample transformation and threshold adjustment operations based on the feedback knowledge base. The detection system can continuously optimize its detection capabilities by utilizing the judgment results and review results accumulated in actual operation, thereby achieving the self-evolution of the over-authority detection system.

[0133] It should be noted that the technical features in the above embodiments can be combined arbitrarily according to actual needs. As long as the combined technical solutions do not contradict each other, they all fall within the protection scope of this application. This application does not make specific limitations on the combination methods between the various embodiments.

[0134] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the access request unauthorized detection method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0135] This application also provides an access request unauthorized detection device, please refer to... Figure 4 The access request unauthorized detection device includes: Data acquisition module 10 is used to acquire the request data to be detected and the corresponding response data related to the access request; The rule verification module 20 is used to extract features from the request data to be detected and the response data, and to perform rule verification based on the feature extraction results, so as to determine the rule confidence, rule risk value and hit rule information of the request. The semantic reasoning module 30 is used to perform semantic reasoning analysis based on the request data to be detected, the response data, and the hit rule information when the rule confidence of the request is less than a preset confidence threshold or the rule risk value is less than a preset risk value threshold, so as to determine the semantic confidence and semantic risk value of the request. The fusion risk determination module 40 is used to determine the fusion risk value of the request based on the rule confidence, rule risk value, semantic confidence, and semantic risk value of the request. The first judgment module 50 is used to determine that the request is an unauthorized request when the fusion risk value is greater than the preset fusion threshold. The second judgment module 60 is used to determine that the request is an unauthorized request when the rule confidence of the request is greater than or equal to a preset confidence threshold and the rule risk value is greater than or equal to a preset risk value threshold.

[0136] The access request unauthorized detection device provided in this application, employing the access request unauthorized detection method in the above embodiments, can solve the technical problem of how to improve the recognition capability of unauthorized detection in complex semantic scenarios while ensuring real-time detection. Compared with the prior art, the beneficial effects of the access request unauthorized detection device provided in this application are the same as those of the access request unauthorized detection method provided in the above embodiments, and other technical features in the access request unauthorized detection device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0137] This application provides an access request unauthorized detection device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the access request unauthorized detection method in the first embodiment described above.

[0138] The following is for reference. Figure 5 This document illustrates a structural diagram suitable for implementing an access request unauthorized access detection device according to embodiments of this application. The access request unauthorized access detection device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The access request unauthorization detection device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0139] like Figure 5 As shown, the access request unauthorized detection device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the access request unauthorized detection device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the access request unauthorized access detection device to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show access request unauthorized access detection devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0140] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0141] The access request unauthorized detection device provided in this application, employing the access request unauthorized detection method in the above embodiments, can solve the technical problem of how to improve the recognition capability of unauthorized detection in complex semantic scenarios while ensuring real-time detection. Compared with the prior art, the beneficial effects of the access request unauthorized detection device provided in this application are the same as those of the access request unauthorized detection method provided in the above embodiments, and other technical features in this access request unauthorized detection device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0142] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0143] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0144] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the access request unauthorized detection method in the above embodiments.

[0145] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0146] The aforementioned computer-readable storage medium may be included in the access request unauthorized detection device; or it may exist independently and not be assembled into the access request unauthorized detection device.

[0147] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the access request unauthorized access detection device, cause the access request unauthorized access detection device to: Obtain the request data to be detected and the corresponding response data related to the access request; Feature extraction is performed on the request data and response data to be detected, and rule verification is performed based on the results of feature extraction to determine the rule confidence, rule risk value and hit rule information of the request. If the confidence level of the requested rule is less than the preset confidence threshold or the risk value of the rule is less than the preset risk value threshold, semantic reasoning analysis is performed based on the request data to be detected, the response data, and the hit rule information to determine the semantic confidence level and semantic risk value of the request. Based on the request's rule confidence, rule risk value, semantic confidence, and semantic risk value, determine the request's fusion risk value; If the fusion risk value exceeds the preset fusion threshold, the request is determined to be an unauthorized request. If the requested rule confidence is greater than or equal to the preset confidence threshold and the rule risk value is greater than or equal to the preset risk value threshold, the request is determined to be an unauthorized request.

[0148] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0149] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0150] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0151] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described access request unauthorized access detection method. This solves the technical problem of how to improve the ability of unauthorized access detection to recognize complex semantic scenarios while ensuring real-time detection. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the access request unauthorized access detection method provided in the above embodiments, and will not be repeated here.

[0152] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the access request unauthorized detection method described above.

[0153] The computer program product provided in this application solves the technical problem of improving the ability of unauthorized access detection to recognize complex semantic scenes while ensuring real-time detection. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the access request unauthorized access detection method provided in the above embodiments, and will not be repeated here.

[0154] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for detecting unauthorized access requests, characterized in that, The method includes: Obtain the request data to be detected and the corresponding response data related to the access request; Feature extraction is performed on the request data to be detected and the response data, and rule verification is performed based on the feature extraction results to determine the rule confidence, rule risk value and hit rule information of the request. If the rule confidence of the request is less than a preset confidence threshold or the rule risk value is less than a preset risk value threshold, semantic reasoning analysis is performed based on the request data to be detected, the response data, and the hit rule information to determine the semantic confidence and semantic risk value of the request. Based on the rule confidence, rule risk value, semantic confidence, and semantic risk value of the request, the fusion risk value of the request is determined; If the fusion risk value is greater than a preset fusion threshold, the request is determined to be an unauthorized request; If the rule confidence level of the request is greater than or equal to a preset confidence threshold and the rule risk value is greater than or equal to a preset risk value threshold, the request is determined to be an unauthorized request.

2. The method as described in claim 1, characterized in that, The step of extracting features from the request data to be detected and the response data includes: Extract subject features, resource features, action features, environmental features, behavior sequence features, response features, and relationship features from the request data to be detected and the response data; The subject features, the behavior sequence features, and the relationship features are aggregated into a user context; the resource features, the response features, and the relationship features are aggregated into a resource context; the action features are aggregated into an operation context; and the environment features are aggregated into an environment context. The feature extraction result of the request is constructed based on the user context, the resource context, the operation context, and the environment context.

3. The method as described in claim 2, characterized in that, The step of performing rule verification based on the feature extraction results to determine the rule confidence, rule risk value, and hit rule information of the request includes: Static rule matching is performed based on the feature extraction results to determine the rule confidence and initial risk score of the request. Based on the feature extraction results, dynamic baseline deviation detection is performed to determine the degree of deviation of the request from the normal behavior baseline; The response data is subjected to response structure analysis to determine the response overreach index, which characterizes the degree to which overreach data is returned in the response data; Based on the degree of deviation and the response overreach index, the initial risk score is corrected to obtain the rule risk value of the request; Based on the rule confidence level, the deviation level, the response overreach index, and the rule risk value, the hit rule information of the request is determined.

4. The method as described in claim 3, characterized in that, The step of performing static rule matching based on the feature extraction results to determine the rule confidence of the request includes: Based on the feature extraction results and static rule matching conditions, determine each static rule triggered by the feature extraction results; The rule contribution value of each static rule is calculated based on the preset weight coefficient and matching strength coefficient of each triggered static rule. Based on the rule contribution value of each static rule, the ratio of the standard deviation to the mean of the rule contribution value of each static rule is determined to obtain the evidence consistency measure; The sufficiency of evidence is measured by the ratio of the number of static rules triggered by the feature extraction results to a preset rule number threshold. Based on the accuracy of the static rule matching results within a preset time period after manual review, a historical accuracy feedback metric is obtained. The rule confidence of the request is obtained by weighted and fused the evidence consistency measure, the evidence sufficiency measure, and the historical accuracy feedback measure.

5. The method as described in claim 1, characterized in that, The step of performing semantic reasoning analysis based on the request data to be detected, the response data, and the hit rule information to determine the semantic confidence and semantic risk value of the request includes: The request data to be detected, the response data, and the hit rule information are transformed into a structured analysis object, which includes subject identity information, target resource information, request action information, response information, historical request sequence, and hit rule description. Based on the business domain and risk type to which the structured analysis object belongs, select the corresponding target reasoning template from the preset domain reasoning template library; Based on the target reasoning template, the reasoning results of the structured analysis object are output, including the final judgment conclusion, risk type, confidence level, list of evidence items, and reasoning steps; The semantic confidence and semantic risk value of the request are determined based on the reasoning results.

6. The method as described in claim 5, characterized in that, The domain inference template library is associated with a case sample library, which includes normal access samples, confirmation of unauthorized access samples, false alarm correction samples, and false negative reinforcement samples. The step of outputting the inference result of the structured analysis object based on the target inference template includes: Retrieve case samples similar to the structured analysis object from the case sample library; Based on the discrimination results of the retrieved case samples and the target reasoning template, the reasoning result is output.

7. The method as described in claim 1, characterized in that, The step of determining the fusion risk value of the request based on the rule confidence, rule risk value, semantic confidence, and semantic risk value includes: Using the rule confidence level as the reliability weight of the rule risk value, the rule risk value is weighted to obtain the rule weighted risk value; Using the semantic confidence level as the reliability weight of the semantic risk value, the semantic risk value is weighted to obtain the semantic weighted risk value; The fusion risk value of the request is determined based on the rule-weighted risk value, the semantic-weighted risk value, the preset rule weight coefficient, and the preset semantic weight coefficient.

8. The method as described in claim 1, characterized in that, The method further includes: The judgment results generated during the execution of the method are stored in the feedback knowledge base. The judgment results include at least the rule confidence, the rule risk value, the hit rule information, and the corresponding unauthorized judgment conclusion. In response to a manual review instruction, perform at least one of the following operations based on the feedback knowledge base: High-frequency feature combinations are mined from the feedback knowledge base to generate static rules; False alarm cases and missed alarm cases are transformed into supplementary conditions for case samples and / or reasoning templates; Based on the accuracy and recall rates of rule validation and semantic reasoning analysis in different business domains, adjust at least one of the preset reliability threshold, the preset risk value threshold, and the preset fusion threshold.

9. An access request unauthorized detection device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the access request unauthorized detection method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the access request unauthorized detection method as described in any one of claims 1 to 8.

Images