Business authority control method and device, computer device and storage medium

Abstract

The application relates to the technical field of data security management, and discloses a business permission control method, device, equipment and medium, which can be applied to the business management application scenarios of financial technology and medical health. When a business access request initiated by a client is received, the user account information corresponding to the client is queried; permission matching calculation is performed on the user account information and at least one access rule in a preset rule library, so that the permission determination can be calculated in real time based on the rule conditions configured in the rule library, instead of relying on the static permission configuration of a single account, the flexibility and timeliness of the permission determination are improved; a business management operation corresponding to the permission determination result is executed to respond to the business access request, the business response is strictly corresponding to the real-time determination result, the permission out of control caused by the lag of static configuration is avoided, and the precision of the business permission control is improved.

Description

Technical Field

[0001] This application relates to the field of data security management technology, and in particular to a business access control method, apparatus, computer equipment, and storage medium. Background Technology

[0002] As the digital wave sweeps the globe, data has become a company's most core and confidential asset. Against the backdrop of rapid digital economic development, various industries are increasingly reliant on data, and the value density and sensitivity of data are rising simultaneously. Therefore, enhancing information security awareness and taking necessary protective measures have become crucial. Data access control, as a key component of the information security protection system, directly relates to the security boundary of a company's core data assets through the sophistication and reliability of its technical solutions.

[0003] Currently, business systems commonly employ access control schemes based on company accounts. The mainstream solution uses a static authorization model based on accounts, where the system pre-assigns a fixed set of permissions to each user account, achieving access control through a one-to-one mapping between accounts and permission configuration tables. However, with the deepening of digital transformation in fields such as finance and healthcare, the aforementioned existing technical solutions have a major problem: existing access control schemes have coarse-grained control, failing to provide precise management, and matching user permission configurations at the user account level poses security risks due to untimely updates of user permissions.

[0004] First, existing technical solutions rely solely on account identity for permission determination, resulting in a single level of control granularity and a lack of comprehensive consideration of multiple factors such as user attributes, business scenarios, access environments, and operational behaviors. For example, in a financial scenario, a client manager's account might be configured to query all credit products, even if the manager is only responsible for personal consumer loans. This would constitute excessive permission granting. Second, account permission updates rely on manual or scheduled task synchronization, resulting in a significant delay in the effective implementation of permissions. When a user's position changes, responsibilities are adjusted, or account status changes, the permission configuration table often fails to update in real time. For example, in a medical scenario, if a doctor leaves their job, their electronic medical record account may not be immediately frozen, allowing the departing employee to access patient records for a period of time, severely violating medical data protection regulations.

[0005] Therefore, improving the precision of business access control to enhance data management security has become an urgent technical problem to be solved. Summary of the Invention

[0006] This application provides a business access control method, apparatus, computer equipment, and storage medium to address the technical problem that existing access control schemes in business management application scenarios in fields such as fintech and healthcare suffer from insufficient access control precision due to coarse control granularity and delayed updates, which in turn leads to insufficient data management security.

[0007] Firstly, a business access control method is provided, including: Upon receiving a business access request initiated by a client, query the user account information corresponding to the client; The user account information is matched with at least one access rule in the preset rule base to determine the permission judgment result of the client for the target business corresponding to the business access request. Execute the business management operation corresponding to the permission determination result to respond to the business access request.

[0008] Secondly, a business access control device is provided, including: The user information query module is used to query the user account information corresponding to the client when a business access request is received from the client. The permission determination module is used to perform permission matching calculations between the user account information and at least one access rule in the preset rule base to determine the permission determination result of the client for the target business corresponding to the business access request. The request and response module is used to perform the business management operation corresponding to the permission determination result in order to respond to the business access request.

[0009] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-mentioned business access control method.

[0010] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the aforementioned business access control method.

[0011] In the aforementioned business access control method, device, computer equipment, and storage medium, upon receiving a business access request initiated by a client, the system can query the user account information corresponding to the client, providing a foundation of identity data directly associated with the user account for subsequent access determination. By performing permission matching calculations between the user account information and at least one access rule in a preset rule base, access determination can be performed in real-time based on the configured rule conditions in the rule base, rather than relying on the static access configuration of a single account, thereby improving the flexibility and timeliness of access determination. Simultaneously, the system dynamically matches the real-time acquired user account information with the pre-configured access rules. Real-time comparison allows the same user account to be matched with different rule conditions in different business scenarios, resulting in differentiated permission judgment results. This breaks through the coarse-grained limitation of a single account being bound to a fixed set of permissions, thereby improving the scenario adaptation accuracy of business permission control. It determines the permission judgment result of the target business corresponding to the client's business access request, so that each access request obtains an independent judgment conclusion for the specific scenario of the request. It executes the business management operation corresponding to the permission judgment result to respond to the business access request, ensuring that the business response strictly corresponds to the real-time judgment result, avoiding permission loss of control caused by static configuration lag, thereby improving the accuracy of business permission control. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of an application environment for a business access control method according to an embodiment of this application; Figure 2 This is a flowchart illustrating a business access control method in one embodiment of this application; Figure 3 This is a schematic diagram of a business process for access control via a rules engine, provided in an embodiment of this application. Figure 4 yes Figure 2 A schematic diagram of a specific implementation method for step S102; Figure 5 This is a schematic diagram of the process of executing access rules through a rule engine, provided in an embodiment of this application; Figure 6 This is a schematic diagram of a business access control device in one embodiment of this application; Figure 7 This is a schematic diagram of the structure of a computer device according to one embodiment of this application; Figure 8 This is another structural schematic diagram of a computer device in one embodiment of this application. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0015] The business access control method provided in this application embodiment can be applied to, for example, Figure 1 In this application environment, the client communicates with the server via a network. The server can receive service access requests initiated by users through the client, and upon receiving such requests, query the user account information corresponding to the client; perform permission matching calculations on the user account information and at least one access rule in a preset rule base to determine the client's permission judgment result for the target service corresponding to the service access request; and execute the service management operation corresponding to the permission judgment result to respond to the service access request.

[0016] This application addresses the technical problem of insufficient precision in access control due to coarse control granularity and delayed updates in existing access control schemes used in business management applications in fintech and healthcare, leading to inadequate data management security. Upon receiving a business access request from a client, the application queries the client's corresponding user account information, providing a foundation of identity data directly associated with the user account for subsequent access determination. By performing permission matching calculations between the user account information and at least one access rule in a pre-defined rule base, access determination can be performed in real-time based on the configured rule conditions in the rule base, rather than relying on static access configurations for a single account, thereby improving the flexibility and timeliness of access determination. Simultaneously... This system dynamically compares real-time user account information with pre-configured access rules, allowing the same user account to match different rule conditions in different business scenarios, resulting in differentiated permission judgment results. This overcomes the coarse-grained limitation of a single account binding a fixed set of permissions, thereby improving the scenario adaptation accuracy of business permission control. It determines the permission judgment result of the target business corresponding to the client's business access request, ensuring that each access request receives an independent judgment conclusion specific to the request scenario. It executes the business management operation corresponding to the permission judgment result to respond to the business access request, ensuring that the business response strictly corresponds to the real-time judgment result, avoiding permission control failure caused by static configuration lag, thus improving the accuracy of business permission control. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The following detailed description of specific embodiments further illustrates this application.

[0017] Please see Figure 2 As shown, Figure 2 A flowchart illustrating the business access control method provided in this application embodiment includes the following steps: S101: Upon receiving a business access request initiated by a client, query the user account information corresponding to the client.

[0018] Users can initiate business access requests to the business management system deployed on the server through a client. The client refers to the terminal device or software application that initiates the business access request, including but not limited to various personal computers, laptops, smartphones, tablets, and portable wearable devices, as well as desktop browsers, mobile applications, or dedicated business terminals. The server refers to the server or server cluster that deploys the business management system, serving as the centralized execution end for business logic and data processing, responsible for receiving, parsing, and processing business access requests initiated by the client. The business management system refers to the information system deployed on the server that provides specific business functions.

[0019] A business access request refers to a user's operation request to the business management system for a specific business resource, which includes data such as the request method, the target business resource identifier, the user's identity identifier, and request parameters.

[0020] When a business access request is received from a client, the business management system first parses the request message to extract the user's identity identifier. The specific form of the user's identity identifier includes, but is not limited to, a session token, a digital certificate, or a single sign-on ticket.

[0021] Based on the parsed user identity identifier, the business management system sends a query request to the user directory service, which returns the user account information corresponding to the user identity identifier. User account information refers to the set of basic attribute data bound to the user identity identifier, including user ID, job title, account status, department, and other information.

[0022] For example, in a healthcare setting, a resident physician can log into the electronic medical record system through a hospital workstation and initiate a request to access the medical records of a hospitalized patient. Upon receiving this request, the electronic medical record system extracts the resident physician's digital certificate identifier from the request message. Based on this identifier, it queries the hospital's human resources management system for the corresponding user account information and returns basic attribute data such as user ID, position, account status, and department. This data serves as factual data for subsequent permission matching calculations with the electronic medical record access rule base.

[0023] S102: Perform permission matching calculations on the user account information and at least one access rule in the preset rule base to determine the permission judgment result of the client for the target business corresponding to the business access request.

[0024] In one embodiment, this application uses a rules engine to perform permission determination operations on business access requests. The main idea of ​​a rules engine is to separate the business decision-making part of the application and use predefined semantic modules to write decisions, which can be configured and managed by developers or business administrators when needed.

[0025] Specifically, the user account information obtained from the query is input into the rule engine. The rule engine traverses each access rule in the preset rule base, extracting the attribute fields and corresponding threshold parameters referenced in the condition part of each access rule. Then, the attribute value corresponding to the attribute field in the user account information is compared with the threshold parameter to determine whether the attribute value in the user account information satisfies the operator constraints in the condition part of the access rule. Access rules that satisfy the operator constraints are added to the activation rule set, and then the judgment logic of each access rule in the activation rule set is executed, outputting the client's permission judgment result for the target business.

[0026] To determine the permissions of business access requests using a rule engine, a pre-built rule base and configured access rules are required. In one embodiment, rule configuration data is extracted according to rule configuration instructions; access rule policies are configured on the rule configuration data according to preset attribute dimensions to obtain at least one access rule, wherein the preset attribute dimensions include at least one of user attributes, business attributes, environment attributes, and behavioral attributes; the access rules are validated, and the validated access rules are loaded into the preset rule base.

[0027] In this application, the engine configuration administrator configures access rules based on preset attribute dimensions, describing and limiting access control conditions from multiple perspectives. These preset attribute dimensions may include at least one of user attributes, business attributes, environmental attributes, and behavioral attributes. Specifically, user attributes describe the identity characteristics of the access request initiator, including user ID, job title, department, and account status. Business attributes describe the business characteristics of the accessed resource or business scenario, including domain, business owner, operational timeframe, operable time, and importance level. Environmental attributes describe the external context conditions at the time the access request occurs, including access time and network location. Behavioral attributes describe the specific operation type performed by the subject on the resource request, including read, write, and execute.

[0028] like Figure 3 As shown, engine configuration administrators can initiate rule configuration commands on the rule configuration platform. This rule configuration platform is a dedicated rule management interface, separate from the business management system, providing both visual and command-line access for rule editing.

[0029] After receiving a rule configuration instruction, the rule engine parses and extracts the rule configuration data from the instruction message. This rule configuration data may include information such as the attribute dimension identifier to which the rule applies, the text of the conditional expression, the definition of the decision action, and the rule priority parameters.

[0030] After extracting the rule configuration data, the rule engine parses the attribute dimension identifiers and calls the corresponding attribute dimension rule template. In the rule template, the attribute fields in the conditional expression are bound to the threshold parameter, the decision action is encapsulated as a rule action object, and the priority parameter is assigned to the rule metadata. Then, these elements are combined into a complete access rule object, which contains information such as the rule identifier, applicable attribute dimension, conditional expression object, decision action object, and priority value. This process is repeated until all rule configuration data has been processed, resulting in a collection of multiple access rule objects.

[0031] The obtained set of access rule objects is validated. The validation can include syntactic correctness, matching of attribute fields with preset attribute dimensions, and condition coverage relationships between multiple access rules within the same attribute dimension.

[0032] Specifically, the syntax check calls the conditional expression parser to check whether the operator belongs to the supported set and whether the threshold parameter is a valid type. For example, checking whether "position == senior account manager" conforms to the predefined syntax specification can include checking whether the operator "==" belongs to the supported operator set and whether the threshold parameter "senior account manager" is a valid string type; if the parsing fails, the check item is marked as failing.

[0033] The dimension matching validation checks whether an attribute field exists in the predefined field set of the corresponding attribute dimension. For example, it checks whether the attribute field "job title" exists in the predefined field set of the user attribute dimension; if the field is not registered, the validation item is marked as failing.

[0034] The coverage relationship check compares the new rule with the existing access rules within the same attribute dimension. It checks whether the condition threshold parameters of the new rule and the existing rule are completely mutually exclusive or completely inclusive. If there is a conflict and no resolution strategy is configured, the check item is marked as failing.

[0035] If all validation criteria pass, the access rule is deemed to have passed validation; otherwise, if any validation criterion fails, the access rule is deemed to have failed validation. Access rules that pass validation are stored in a preset rule base, which is a collection of compiled rules used to store active access rules for the rule engine to use during permission matching calculations. Access rules that fail validation return error messages to the rule configuration platform, where the engine configuration administrator corrects and resubmits them.

[0036] This embodiment configures access rules based on preset attribute dimensions such as user attributes, business attributes, environmental attributes, and behavioral attributes, realizing the combined configuration of multi-dimensional attribute conditions and improving the adaptability of access rules to complex business scenarios. By performing multi-dimensional verification on access rules and constructing a preset rule library, the quality and consistency of access rules in the preset rule library are ensured, thereby providing a flexible, reliable, and dynamically updatable rule foundation for subsequent permission matching calculations.

[0037] Based on the pre-built rule base, when a business access request is received, the rule engine can call the corresponding access rules from the pre-built rule base and perform real-time permission matching calculation with the user account information to determine the client's permission judgment result for the target business.

[0038] Furthermore, such as Figure 4 As shown, based on the above Figure 2 In the illustrated embodiment, step S102 further includes steps S1021 to S1022.

[0039] S1021: Traverse each access rule in the preset rule base and perform pattern matching between each traversed access rule and the user account information to determine the activation rule set, the activation rule set including access rules that are determined to meet the conditions and are to be executed by pattern matching.

[0040] Specifically, the rule engine reads each access rule sequentially from the preset rule library, compares the attribute values ​​in the user account information with the threshold parameters in the access rule condition section one by one, and determines the pattern matching result of each access rule.

[0041] Further, each access rule is traversed, and the attribute fields and threshold parameters of the access rule condition part of each access rule are extracted; the attribute values ​​corresponding to the attribute fields in the user account information are compared with the threshold parameters to determine the pattern matching result of the access rule; after completing the traversal of all access rules in the preset rule base, the access rules with successful pattern matching results are added to the activation rule set to obtain the activation rule set composed of all activated access rules.

[0042] In one embodiment, such as Figure 5 As shown, after receiving a business access request from a user, the business management system queries the user account information corresponding to that user, including basic attribute data such as user ID, job title, account status, and department. Simultaneously, based on the specific scenario of this business access request, it collects relevant environmental attribute data (such as current access time and network location) and behavioral attribute data (such as the requested operation type being read, write, or execute). The aforementioned user account information, environmental attribute data, and behavioral attribute data are integrated into structured initial data and written to the rule engine's working memory in the form of fact objects. The working memory is the fact storage area for the rule engine during runtime, used to store the object instances being inferred. The rule engine subsequently retrieves this initial data from the working memory and performs pattern matching with the access rules in the rule base.

[0043] The matcher in the rule engine's inference engine reads initial data from the working memory. The matcher iterates through each access rule in the pre-defined rule base, extracting the attribute dimensions and attribute fields referenced in the conditional parts of each access rule (such as job title and department in user attributes, domain and importance level in business attributes, access time in environmental attributes, and operation type in behavioral attributes). Attribute fields are variable names used in the access rule's conditional expression to compare with user account information, corresponding to specific data items under the pre-defined attribute dimensions. For example, attribute fields under the user attribute dimension include user ID, job title, department, and account status; attribute fields under the business attribute dimension include domain, business owner, operational time limit, operable time, and importance level; attribute fields under the environmental attribute dimension include access time and network location; and attribute fields under the behavioral attribute dimension include read, write, and execute. The rule engine identifies the set of attribute fields contained within the access rule by parsing its conditional expression structure.

[0044] Simultaneously, the rule engine extracts access rules from the preset rule base and reads the threshold parameters from the access rule condition section. The data type of the threshold parameter must match the data type of the corresponding attribute field. For example, the threshold parameter for the job title field is the string type "Senior Account Manager," and the threshold parameter for the access time field is the time interval type "09:00-18:00." The threshold parameter refers to the benchmark value used in the access rule condition expression for comparison with the attribute field value, and is set by the engine configuration administrator when configuring the access rule policy on the rule configuration platform.

[0045] Retrieves the attribute value corresponding to the attribute field from the user account information. For example, when the attribute field is "Position", it retrieves the corresponding attribute value "Senior Account Manager" from the user account information; when the attribute field is "Department", it retrieves the corresponding attribute value "Corporate Finance Department".

[0046] Then, the attribute fields of the corresponding attribute dimension in the user account information are compared one by one with the threshold parameters in the access rule condition section to determine whether the attribute field values ​​meet the operator constraints (such as equal to, greater than, and contain) in the access rule condition section. The comparison process is executed according to the operator constraints in the access rule condition section. The operator constraints are determined by the engine configuration administrator when configuring the access rule policy on the rule configuration platform and are used to define the comparison logic between attribute values ​​and threshold parameters.

[0047] For example, the equality operator can be used for matching. For instance, when the access rule condition expression is "Job Title == Senior Account Manager", the rule engine compares the job attribute value "Senior Account Manager" in the user account information with the threshold parameter "Senior Account Manager" for string equality. The comparison process is case-sensitive, comparing the encoded values ​​of the two strings character by character. If the encoded values ​​of the strings are exactly the same, the attribute value is determined to satisfy the operator constraint, and the pattern matching result is a successful match; if there is any difference in any character, the operator constraint is determined to be unsatisfactory, and the pattern matching result is a failed match.

[0048] When an attribute value satisfies an operator constraint, the pattern matching result is a successful match, the condition of the access rule is met, and the rule is activated. When an attribute value does not satisfy an operator constraint, the pattern matching result is a failed match, and the condition of the access rule is not met. The matcher continues to perform the above traversal and comparison operations until all access rules in the preset rule base have completed matching calculations.

[0049] In one example, the comparison and matching of attribute values ​​with threshold parameters can also be done in other ways. For example, the inclusion operator can be used to determine the membership of a set, and a match is determined when the attribute value is any element in the set; or, the interval operator can be used to determine the range, and a match is determined when the attribute value is between the lower and upper bounds defined by the threshold parameter; or, regular expression matching operators can be used to determine the pattern, and a match is determined when the attribute value matches the regular expression defined by the threshold parameter.

[0050] In one embodiment, after traversing all access rules in the preset rule base, the rule engine summarizes all pattern matching results. Access rules with successfully matched patterns are added to the active rule set. The active rule set is a collection of all access rules whose conditions are met and are yet to be executed. This active rule set may be empty, meaning no access rule's conditions are met; it may also contain one or more access rules.

[0051] This embodiment uses a rule engine to traverse access rules in a preset rule base and compares the attribute values ​​in the user account information with the threshold parameters in the rule conditions in real time. This enables dynamic calculation of permission determination and avoids the update delay problem of traditional static configuration tables. It also supports multiple operator matching methods, improving the flexibility of rule matching and adaptability to different business scenarios.

[0052] Through the aforementioned traversal and pattern matching process, the rule engine filters access rules from the preset rule base that match the user account information, forming an activation rule set. However, because different access rules in the preset rule base may be configured by different engine configuration administrators at different times, and each access rule sets conditions independently based on different attribute dimensions, different access rules may set mutually exclusive condition thresholds for the same attribute dimension, or the action parts of different access rules may define opposite judgment results (e.g., one rule judges access as allowed, while another rule judges access as denied). Therefore, there may be multiple access rules in the activation rule set that simultaneously meet the matching conditions but whose permission judgment results contradict each other.

[0053] The pattern matching operation described above only addresses the question of "which rule conditions are true," not the question of "whether there are conflicts when multiple rules are true simultaneously." Therefore, before executing the judgment logic one by one, it is necessary to further identify whether there are conflicting rule pairs and determine the execution order through a preset conflict resolution strategy before entering the judgment logic execution stage, in order to ensure the consistency and certainty of the subsequent judgment results.

[0054] Further, according to a preset conflict detection method, conflicting rule pairs in the activation rule set are identified to obtain a conflict set; according to a preset conflict resolution strategy, conflict resolution operations are performed on the conflicting rule pairs in the conflict set to obtain a winning rule set; the winning rule set is merged with the non-conflicting access rules in the activation rule set to obtain the conflict-resolved activation rule set.

[0055] Since the access rules in the preset rule base are configured independently by the engine configuration administrator based on different attribute dimensions, and the threshold parameters and judgment actions of each rule may differ, multiple access rules in the active rule set may simultaneously meet the conditions but their judgment results contradict each other or their condition thresholds are mutually exclusive. Therefore, conflict detection needs to be performed on the active rule set to identify conflicting rule pairs.

[0056] Among them, a conflicting rule pair refers to a combination of two or more access rules in the activation rule set that simultaneously satisfy any of the following conditions: First, the condition part references the same attribute field and the threshold parameters are mutually exclusive, that is, the same attribute field is assigned threshold conditions that cannot be met simultaneously in different access rules. For example, one access rule requires "position == senior account manager" and another access rule requires "position == junior account manager". The position attribute value of the same user cannot be equal to two different values ​​at the same time. Therefore, these two access rules are mutually exclusive and constitute a conflicting rule pair; Second, the action part defines opposite judgment results, that is, the judgment action of one access rule is to allow access and the judgment action of another access rule is to deny access. The simultaneous activation of two access rules will lead to contradictory permission judgment results.

[0057] In one embodiment, conflict detection methods can be pre-configured, including attribute field comparison strategies and decision result comparison strategies. The attribute field comparison strategy scans the conditional portions of each access rule in the activation rule set, extracts the referenced attribute fields and threshold parameters, and compares whether there is threshold mutual exclusion for the same attribute field between different access rules. The decision result comparison strategy extracts the decision actions of each access rule and identifies whether there is a mixture of allowed and denied access.

[0058] Specifically, each access rule in the activation rule set is iterated over, and it is paired with other unmatched access rules in the activation rule set to form a comparison rule pair. A double check is performed on each comparison rule pair: first, all attribute fields referenced in the condition parts of the two access rules are extracted, commonly referenced attribute fields are filtered out, and the corresponding threshold parameters are checked for mutual exclusion; second, the judgment results of the action parts of the two access rules are extracted, and whether they are opposite judgments. If either of the above double checks is true, the comparison rule pair is marked as a conflict rule pair and written into the conflict set. This process is repeated until the conflict detection of any two access rules in the activation rule set is completed, ultimately obtaining a conflict set containing all conflict rule pairs.

[0059] In one embodiment, in addition to the detection methods described above, other methods can be used to detect conflicting rule pairs. For example, an index grouping method can be used for conflict detection. The set of active rules is first grouped according to attribute fields, and threshold mutual exclusion comparison is performed only on access rules within the same group to reduce the number of comparisons. Alternatively, a priority pre-screening method can be used for conflict detection. Conflict detection is performed only on access rules with similar priority values, assuming that high-priority rules and low-priority rules will not enter the conflict resolution stage at the same time.

[0060] After obtaining the conflict set, conflict resolution operations are performed on the conflict rule pairs within the conflict set according to a preset conflict resolution strategy. The conflict resolution strategy refers to the decision criteria used to determine the winning rule among conflict rule pairs, including the priority value or dimension weight coefficient of each access rule. The priority value is a weight identifier assigned to each access rule; a higher value indicates that the rule is more likely to be adopted in the conflict. The dimension weight coefficient is a proportional coefficient assigned to each preset attribute dimension, used to calculate the comprehensive score in multi-dimensional conflicts.

[0061] In one example, taking conflict resolution using a direct comparison of priority values ​​as an example, the rule engine sorts and compares the access rules in the conflict set according to the preset priorities (such as the Salience value) set by the engine configuration administrator when configuring each access rule on the rule configuration platform. Rules with higher priorities are retained first, while rules with lower priorities are suppressed or discarded. If conflicting rules come from different attribute dimensions, a weighted score is calculated based on preset dimension weights, and the access rule with the highest score is selected as the winning rule after conflict resolution.

[0062] Besides directly comparing priority values ​​to resolve conflicts, other conflict resolution strategies can also be used. For example, the most recent activation frequency can be used to resolve conflicts by calculating the activation success rate of each rule in historical requests and selecting the rule with the higher success rate as the winning rule.

[0063] After conflict resolution, the rule engine merges the winning rule set with the conflict-free access rules in the active rule set, and writes them into the Agenda (an ordered queue) in a predetermined execution order, forming the conflict-resolved active rule set. Conflict-free access rules are those that did not participate in any conflicting rule pairs within the active rule set; these rules exist independently after pattern matching and can be executed directly without conflict resolution. The Agenda is an ordered queue in the rule engine used to manage and schedule active rules to be executed, recording the rules the rule engine will execute next and their execution order.

[0064] The set of activation rules after conflict resolution refers to the set of access rules that are logically consistent and have a clear execution order after conflict detection and resolution. This set does not contain access rules with contradictory judgment results and can serve as the basic input for subsequent execution of judgment logic. If the conflict set is empty, that is, if there are no conflicting rule pairs in the activation rule set, then the set of activation rules after conflict resolution is the same as the original set of activation rules and can be directly used as the input for subsequent execution of judgment logic.

[0065] Through the above conflict detection and conflict resolution process, the contradictory rules in the activation rule set have been identified and processed. The winning rule and the non-conflicting rule are merged to form a logically consistent execution queue, which ensures the uniqueness and certainty of the subsequent permission determination results, avoids the ambiguity of permission determination caused by rule conflicts, and provides a contradictory and orderly rule foundation for the rule engine to execute the determination logic in sequence.

[0066] S1022: Execute the judgment logic of the access rules in the activation rule set one by one to determine the permission judgment result.

[0067] After conflict resolution, the execution order of each access rule in the activation rule set is determined, and there are no contradictory judgment results. The rule engine can call the judgment action of each access rule one by one according to this execution order, and generate the final permission judgment result based on the output of the judgment action.

[0068] Specifically, the rule engine's execution engine reads the access rules in the Agenda queue sequentially and executes the judgment logic defined in the action section of each activation rule one by one. The judgment logic refers to the specific operations defined in the access rule action section, including setting the permission judgment result value to allow or deny access, and additional operations such as recording audit logs.

[0069] In one embodiment, the permission determination result includes allowing access or denying access. When at least one access rule in the activation rule set has a determination logic of allowing access, the permission determination result is determined to be allowing access; when the activation rule set is empty, or when all access rules in the activation rule set have a determination logic of denying access, the permission determination result is determined to be denying access.

[0070] During the execution of each rule, the rule engine can employ a priority-based decision-making strategy. When the execution of an access rule reaches the action section and outputs an "allow access" decision, the execution engine terminates the execution of subsequent access rules in the Age queue, using "allow access" as the final permission decision. This strategy ensures that when multiple access rules exist, the "allow access" decision has the highest priority and will not be overridden by subsequent "deny access" rules.

[0071] Specifically, the rule engine extracts the decision action object of the current access rule and parses the defined decision result type. If the decision action object is "Allow access", the temporary variable of the permission decision result is assigned the value "Allow access", and the execution of subsequent access rules is terminated, with "Allow access" becoming the final permission decision result. If the decision action object is "Deny access", the temporary variable of the permission decision result is assigned the value "Deny access", and the decision logic of the next access rule is executed, until all access rules in the active rule set have been traversed.

[0072] For example, when a corporate account manager initiates a loan approval inquiry request, after pattern matching and conflict resolution, the activated rule set contains two access rules. Access rule one determines access is denied, while access rule two determines access is allowed. The rule engine executes each rule sequentially. First, access rule one is executed, and the result is temporarily assigned as access denied, then the iteration continues. Next, access rule two is executed, and the result is determined as access allowed, immediately terminating the iteration. Finally, the access decision is made to allow access, and the account manager can inquire about the loan approval progress.

[0073] In one embodiment, if the activation rule set is empty, meaning no access rule condition is met, it indicates that the current user account information does not meet any access rule matching conditions, and access is denied by default to ensure security. In this case, the permission determination result is determined as access denied. For example, if a caregiver initiates a request to modify an elderly person's medication record, and after pattern matching, the activation rule set is empty, the rule engine determines that the permission determination result is access denied. The caregiver cannot modify the medication record and must submit an application for review by a senior caregiver before execution.

[0074] In one embodiment, if the set of activation rules is not empty, but the judgment logic of all access rules in the set of activation rules is to deny access, that is, after traversing all access rules, no judgment result of allowing access is encountered, it indicates that although the current user account information meets the conditions of some access rules, all matching rules determine it as denying access. At this time, the permission judgment result is also determined as denying access.

[0075] Understandably, the strategy for determining access control results can be set according to actual application needs. For example, in security-sensitive scenarios, a denial-first strategy can be adopted, meaning that as soon as any access rule is encountered during the traversal and its judgment logic is "deny access," the traversal is immediately terminated, and "deny access" is output as the final access control result. In scenarios where rule priorities change dynamically, a last rule-wins strategy can be adopted, meaning that all access rules are traversed in execution order, and the judgment result of the last access rule is used as the final access control result.

[0076] exist Figure 5 In the process of the rule engine executing permission determination logic shown, if the action part of an access rule modifies the factual data in the working memory (such as updating the user status flag), the rule engine is triggered to re-execute the loop from step B to E. The matcher performs pattern matching again on the updated data in the working memory with the preset rule base, and processes the newly generated rule activation situation until there are no rules to be executed in the Age and the factual data in the working memory no longer changes, and the entire rule reasoning process is completed.

[0077] Through the process of executing the judgment logic item by item as described above, the rule engine converges multiple access rules in the activation rule set into a single binary permission judgment result, namely, allow access or deny access. This binary result serves as a standardized interaction interface between the rule engine and the business management system, allowing the business management system to focus on the internal details of rule reasoning without needing to concern itself with them. It only needs to execute the corresponding business management operations based on the received permission judgment result, thereby achieving a clear decoupling between permission control logic and business execution logic.

[0078] This embodiment achieves decoupling of permission control logic and business execution logic by executing the judgment logic one by one. This allows the rule engine to converge multiple access rules in the activation rule set into a single binary permission judgment result, enabling the business management system to quickly respond to access requests without having to pay attention to the internal details of rule reasoning.

[0079] S103: Execute the business management operation corresponding to the permission determination result to respond to the business access request.

[0080] By executing the judgment logic line by line, the rule engine outputs a clear permission judgment result based on the judgment actions of each access rule in the activation rule set. However, this permission judgment result is only the internal inference output of the rule engine and needs to be further transformed into control instructions that the business management system can recognize and mapped into specific business management operations before it can finally respond to the client's business access request. Therefore, different business processing paths need to be triggered according to different values ​​of the permission judgment result.

[0081] In one embodiment, when the permission determination result is that access is allowed, the business logic of the target service is executed.

[0082] Specifically, when the permission determination result output by the rules engine is "access allowed," the business management system locates the corresponding business logic processing module based on the target business resource identifier carried in the business access request. A business logic processing module refers to a program unit within the business management system responsible for handling specific business functions, such as a credit approval query module, a medical record retrieval module, and a medication record modification module.

[0083] The business management system passes the request parameters from the business access request to the business logic processing module, triggering the module to execute specific data query, calculation, or update operations. After completing the processing, the business logic processing module encapsulates the business processing result into a response message and returns it to the client through the server, thus completing the response to the business access request.

[0084] For example, a resident physician initiates a request to access a hospitalized patient's medical records. After the rule engine performs permission matching calculations, it outputs a permission determination result that allows access. The electronic medical record system receives this result, parses the target business resource identifier as "medical record access module," calls the medical record access module, and, based on the patient identifier in the request parameters, retrieves all medical records of the patient since admission from the electronic medical record database, including ward round records, treatment plan adjustments, and medical order change history. The results are then rendered into a result display page and returned to the physician's workstation, where the physician can view the complete medical record information.

[0085] In one embodiment, when the permission determination result is access denied, the service access request is terminated.

[0086] Specifically, when the permission determination result output by the rules engine is "access denied," the business management system terminates the subsequent processing flow of the business access request and no longer calls any business logic processing modules to perform data operations. At the same time, the business management system generates an access denied response message, which includes a denial reason identifier and prompt information, such as "Insufficient permissions, unable to access the requested resource."

[0087] The business management system returns an access denial response message to the client via the server, and records the access denial event in the system log, including the request time, client identifier, target business resource identifier, and triggered access rule information, for subsequent security auditing and abnormal behavior analysis.

[0088] For example, a former employee attempts to log into the loan approval system using an unrecovered account and initiates a request to query a customer's credit report. After performing permission matching calculations, the rule engine outputs an access denied result because the account status attribute value "former" does not match any threshold conditions for allowed access rules. The loan approval system receives this result, terminates the query process, and generates an access denied response message returned to the former employee's terminal, indicating "Insufficient permissions to access the requested resource." Simultaneously, the system records this abnormal access attempt in the security audit log, triggers an account status anomaly alert, and notifies the administrator to immediately freeze the account.

[0089] This embodiment, through the execution of differentiated business processing paths, transforms the binary permission judgment results output by the rule engine into specific business response actions, thereby decoupling the permission control logic from the business execution logic. This ensures smooth business access for legitimate users and forms a complete security audit loop through logging and anomaly alarm mechanisms when access is denied, thus enhancing the security protection capabilities and traceability of the business management system.

[0090] As can be seen, in the above solution, for business management application scenarios in fields such as fintech and healthcare, when a business access request is received from a client, the corresponding user account information of the client can be queried, providing an identity data foundation directly associated with the user account for subsequent permission determination. By performing permission matching calculations between the user account information and at least one access rule in the preset rule base, permission determination can be performed in real time based on the rule conditions configured in the rule base, rather than relying on the static permission configuration of a single account, thereby improving the flexibility and timeliness of permission determination. At the same time, the real-time obtained user account information is compared with the pre-configured access rules. Dynamic comparison allows the same user account to be matched with different rule conditions in different business scenarios, resulting in differentiated permission judgment results. This breaks through the coarse-grained limitation of a single account being bound to a fixed set of permissions, thereby improving the scenario adaptation accuracy of business permission control. It determines the permission judgment result of the target business corresponding to the client's business access request, so that each access request obtains an independent judgment conclusion for the specific scenario of the request. It executes the business management operation corresponding to the permission judgment result to respond to the business access request, ensuring that the business response strictly corresponds to the real-time judgment result, avoiding permission loss of control caused by static configuration lag, thereby improving the accuracy of business permission control.

[0091] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0092] In one embodiment, a service access control device is provided, which corresponds one-to-one with the service access control methods described in the above embodiments. For example... Figure 6 As shown, the business access control device includes a user information query module 301, an access control module 302, and a request / response module 303. Detailed descriptions of each functional module are as follows: The user information query module 301 is used to query the user account information corresponding to the client when a business access request is received from the client. The permission determination module 302 is used to perform permission matching calculations on the user account information and at least one access rule in the preset rule base to determine the permission determination result of the client for the target business corresponding to the business access request. The request response module 303 is used to perform the business management operation corresponding to the permission determination result in order to respond to the business access request.

[0093] In one embodiment, the permission determination module 302 is specifically used for: Traverse each access rule in the preset rule base and perform pattern matching between each traversed access rule and the user account information to determine the activation rule set, which includes access rules that are determined to meet the conditions and are to be executed by pattern matching. The decision logic of the access rules in the activation rule set is executed one by one to determine the permission determination result.

[0094] In one embodiment, the permission determination result includes allowing access or denying access; the permission determination module 302 is specifically used for: If at least one of the access rules in the activation rule set has a judgment logic of allowing access, then the permission judgment result is determined to be allowing access; When the activation rule set is empty, or when the judgment logic of all the access rules in the activation rule set is to deny access, the permission judgment result is determined to be deny access.

[0095] In one embodiment, the permission determination module 302 is specifically used for: Iterate through each of the access rules and extract the attribute fields of each access rule and the threshold parameters of the access rule condition part; The attribute value corresponding to the attribute field in the user account information is compared with the threshold parameter to determine the pattern matching result of the access rule; After traversing all access rules in the preset rule base, the access rules that have successfully matched the pattern are added to the activation rule set, thus obtaining the activation rule set consisting of all activated access rules.

[0096] In one embodiment, the permission determination module 302 is further configured to: Based on a preset conflict detection method, conflict rule pairs in the activation rule set are identified to obtain a conflict set; According to the preset conflict resolution strategy, conflict resolution operations are performed on the conflict rule pairs in the conflict set to obtain the winning rule set. The winning rule set is merged with the non-conflicting access rules in the activation rule set to obtain the activation rule set after conflict resolution.

[0097] In one embodiment, the service access control device further includes an access rule configuration module, specifically used for: Extract rule configuration data according to the rule configuration instructions; Based on preset attribute dimensions, access rule policies are configured on the rule configuration data to obtain at least one access rule, wherein the preset attribute dimensions include at least one of user attributes, business attributes, environmental attributes, and behavioral attributes. The access rules are validated, and the validated access rules are loaded into the preset rule base.

[0098] In one embodiment, the request-response module 303 is specifically used for: When the permission determination result is that access is allowed, the business logic of the target service is executed; When the permission determination result is "access denied", the service access request is terminated.

[0099] This application provides a business access control device that, upon receiving a business access request from a client, queries the user account information corresponding to the client, providing a foundation of identity data directly associated with the user account for subsequent access determination. By performing permission matching calculations between the user account information and at least one access rule in a preset rule base, access determination can be performed in real time based on the rule conditions configured in the rule base, rather than relying on the static access configuration of a single account, thereby improving the flexibility and timeliness of access determination. Simultaneously, by dynamically comparing the real-time obtained user account information with the pre-configured access rules, the same user account can be matched with different rule conditions in different business scenarios, obtaining differentiated access determination results. This breaks through the coarse-grained limitation of a single account binding a fixed set of permissions, thereby improving the scenario adaptation accuracy of business access control. The device determines the access determination result of the target business corresponding to the client's business access request, ensuring that each access request obtains an independent determination conclusion specific to the request scenario. Finally, it executes the business management operation corresponding to the access determination result to respond to the business access request, ensuring that the business response strictly corresponds to the real-time determination result, avoiding access control failure caused by static configuration lag, thereby improving the accuracy of business access control.

[0100] Specific limitations regarding the business access control device can be found in the limitations of the intelligent question-answering method described above, and will not be repeated here. Each module in the aforementioned business access control device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0101] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a business access control method on the server side.

[0102] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements the functions or steps of a business access control method on the client side. In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Upon receiving a business access request initiated by a client, query the user account information corresponding to the client; The user account information is matched with at least one access rule in the preset rule base to determine the permission judgment result of the client for the target business corresponding to the business access request. Execute the business management operation corresponding to the permission determination result to respond to the business access request.

[0103] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Upon receiving a business access request initiated by a client, query the user account information corresponding to the client; The user account information is matched with at least one access rule in the preset rule base to determine the permission judgment result of the client for the target business corresponding to the business access request. Execute the business management operation corresponding to the permission determination result to respond to the business access request.

[0104] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0105] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0106] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0107] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0108] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A business access control method, characterized in that, include: Upon receiving a business access request initiated by a client, query the user account information corresponding to the client; The user account information is matched with at least one access rule in the preset rule base to determine the permission judgment result of the client for the target business corresponding to the business access request. Execute the business management operation corresponding to the permission determination result to respond to the business access request.

2. The business access control method as described in claim 1, characterized in that, The step of performing permission matching calculations between the user account information and at least one access rule in a preset rule base to determine the permission determination result of the client for the target service corresponding to the service access request includes: Traverse each access rule in the preset rule base and perform pattern matching between each traversed access rule and the user account information to determine the activation rule set, which includes access rules that are determined to meet the conditions and are to be executed by pattern matching. The decision logic of the access rules in the activation rule set is executed one by one to determine the permission determination result.

3. The business access control method as described in claim 2, characterized in that, The permission determination result includes allowing access or denying access; The step of executing the judgment logic of the access rules in the activation rule set one by one to determine the permission judgment result includes: If at least one of the access rules in the activation rule set has a judgment logic of allowing access, then the permission judgment result is determined to be allowing access; When the activation rule set is empty, or when the judgment logic of all the access rules in the activation rule set is to deny access, the permission judgment result is determined to be deny access.

4. The business access control method as described in claim 2, characterized in that, The step of performing pattern matching between each of the access rules traversed and the user account information to determine the activation rule set includes: Iterate through each of the access rules and extract the attribute fields of each access rule and the threshold parameters of the access rule condition part; The attribute value corresponding to the attribute field in the user account information is compared with the threshold parameter to determine the pattern matching result of the access rule; After traversing all access rules in the preset rule base, the access rules that have successfully matched the pattern are added to the activation rule set, thus obtaining the activation rule set consisting of all activated access rules.

5. The business access control method as described in claim 2, characterized in that, Before determining the permission determination result by executing the judgment logic of the access rules in the activation rule set one by one, the method further includes: Based on a preset conflict detection method, conflict rule pairs in the activation rule set are identified to obtain a conflict set; According to the preset conflict resolution strategy, conflict resolution operations are performed on the conflict rule pairs in the conflict set to obtain the winning rule set. The winning rule set is merged with the non-conflicting access rules in the activation rule set to obtain the activation rule set after conflict resolution.

6. The business access control method as described in claim 1, characterized in that, Before querying the user account information corresponding to the client upon receiving a service access request from the client, the process further includes: Extract rule configuration data according to the rule configuration instructions; Based on preset attribute dimensions, access rule policies are configured on the rule configuration data to obtain at least one access rule, wherein the preset attribute dimensions include at least one of user attributes, business attributes, environmental attributes, and behavioral attributes. The access rules are validated, and the validated access rules are loaded into the preset rule base.

7. The business access control method as described in any one of claims 1-6, characterized in that, The execution of the business management operation corresponding to the permission determination result in response to the business access request includes: When the permission determination result is that access is allowed, the business logic of the target service is executed; When the permission determination result is "access denied", the service access request is terminated.

8. A business access control device, characterized in that, include: The user information query module is used to query the user account information corresponding to the client when a business access request is received from the client. The permission determination module is used to perform permission matching calculations between the user account information and at least one access rule in the preset rule base to determine the permission determination result of the client for the target business corresponding to the business access request. The request and response module is used to perform the business management operation corresponding to the permission determination result in order to respond to the business access request.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the business access control method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the business access control method as described in any one of claims 1 to 7.

Images