Design and storage method of network access control policy

Abstract

The application discloses a network access control strategy design and storage method, which comprises the following steps: constructing an expression; constructing a rule based on the expression, wherein the operation result of the rule is "true" or "false"; constructing an action; constructing a strategy based on the combination of the rule and the action; setting a general template; generating a corresponding rule file for each rule by using the general template; converting the rule file into machine code by using a dynamic compilation mode and storing the rule file; storing the rule and the action in the memory by using a program according to the combination logic of the rule and the action in the strategy; and calling the arranged strategy according to an access control request. The application can flexibly arrange the execution sequence of the strategy when multiple strategies are processed, and can meet various needs of users.

Description

Technical Field

[0001] This invention relates to the field of network access control technology, and more specifically to a method for designing and storing network access control policies. Background Technology

[0002] An access control system is a technology that restricts a subject's access to certain resources or functions based on the subject's identity and the defined group to which they belong. NIST defines access control as follows: "Access is the ability to use computer resources to do something; access control is a means by which this ability is permitted or restricted under certain circumstances (usually through physical and system-based controls)."

[0003] The purpose of access control is to ensure that specific data and resources can be correctly accessed and utilized by the appropriate subjects at the appropriate time and place. An access control model is an architecture that specifies how subjects access objects. Access control models have evolved from the initial discretionary access control (DAC) and mandatory access control (MAC) to role-based access control (RBAC). In recent years, attribute-based access control (ABAC) has emerged. With increasing attention to dynamic security capabilities, risk-adaptive access control (RAdAC) has been proposed. A typical access control flow is as follows: Figure 1 The basic component of an access control model is the access control policy. An access control process typically consists of one or more access control policies. In early DAC, MAC, and RBAC access control models, the types of operands used when defining policies were limited. For example, in common firewall policies applied to the TCP or UDP layer, the operand types were usually only five: source address, destination address, source port, destination port, and protocol type. In Role-Based Access Control (RBAC), the operand types were also usually limited to account, role, group, department, etc. Even if time and location information were added as operands, the types remained limited. Therefore, the common practice for defining these types of access control policies was to implement fixed-format rules programmatically. For example: Rule 1: If (role = administrator), then access is allowed; Rule 2: If (IP address is in the range of 10.33.1.1 to 10.34.255.255) and (destination port = 8000), then access is not allowed. The rule definition is very simple because the operand types are finite and the data judgment operators are also finite. Therefore, the format of each rule will not change. Even if there is an uncertain number of rules, it can be implemented by simply defining an array to store them.

[0004] For the attribute-based access control model (ABAC) that has emerged in recent years, because the operand types (attributes) of this access control model are completely uncertain, it cannot be implemented with rules in a prescribed format like the models mentioned above. For this model, there are usually two approaches in the industry: 1. Manually limit the number of attributes and the type of operators involved in the rule definition. In this case, the ABAC rules have a fixed format like the rules mentioned above, and can be completely solidified through programming; 2. Do not limit the number of attributes and the type of operators, but use an interpreted language rather than a compiled language to process complex rule expressions. This approach is relatively simple to implement.

[0005] The drawbacks of the definition methods for the aforementioned DAC, MAC, RBAC, and ABAC access control models with restrictions are that they limit the number of operand types and operators. Although the definition and storage of the rules are simple, they are very inflexible and cannot meet the access control requirements of complex conditions.

[0006] Typically, whether a request from a subject allows certain actions to be performed on an object requires decision-making through multiple strategies. Most decision-making systems either fix the execution order of these strategies or offer users only a limited combination of strategies to choose from (e.g., allowing access only if several strategies are satisfied, or allowing access if only one strategy is satisfied). While this approach is relatively simple, it has significant limitations, as users cannot modify the decision-making process according to their own ideas. Regarding the method of using interpreted languages ​​to define and store complex rules, although flexibility is greatly enhanced, using interpreted languages ​​means that each rule is parsed in real time during access control, resulting in significantly lower processing performance compared to defining and storing rules using compiled languages.

[0007] Publication number CN109753819A discloses a method and apparatus for processing access policies, which converts policy expressions into code. This method directly defines policy expressions in code form, a common practice in many open-source policy engines (opa, casbin, drools), which does not help improve performance. Furthermore, the implementation process involves an algorithm to select the final action from multiple conditional expressions, which has poor adaptability to various situations. Summary of the Invention

[0008] Purpose of the invention: The purpose of this invention is to address the shortcomings of existing technologies by providing a method for designing and storing network access control policies. This method allows for flexible arrangement of the execution order of multiple policies when processing them, thus meeting various user needs.

[0009] Technical solution: The design and storage method of network access control policy according to the present invention includes:

[0010] S1: Construct the expression;

[0011] S2: Rules are constructed based on expressions, and the result of the rule operation is "true" or "false";

[0012] S3: Construct an action, which refers to the command executed when the corresponding rule operation result is "true";

[0013] S4: A strategy for constructing a rule-action combination;

[0014] S5: Set a general template. In the general template, "id" represents the unique identifier of the rule, and "expression" corresponds to the code converted from the structured language describing the rule. Use the general template to generate the corresponding rule file for each rule.

[0015] S6: Convert the rule file into a file containing machine code using dynamic compilation, attach a unique identifier for the corresponding policy to the machine code, and store it in memory;

[0016] S7: Based on the rule-action combination logic in the S4 strategy, the combination of rules and actions is stored in memory in the form of a program. When a rule is executed, the machine code is executed directly to realize the strategy operation.

[0017] To further improve the above technical solution, the fixed format of the expression is: operand + operator + operand, where operands include functions, attribute values, constants, and expressions, and operators include arithmetic operators, relational operators, logical operators, and program operators.

[0018] Furthermore, the rule includes one or more expressions, and when the rule includes more than one expression, the operational relationship between the expressions can be only one of "AND" and "OR".

[0019] Furthermore, the action includes two types: type one is to return the command agreed upon with the requesting decision-maker, and type two is to execute the next strategy.

[0020] Furthermore, the strategy includes one or more rule-action combinations. If the strategy includes at least one rule-action combination and the result of the first rule is "true", the corresponding action is executed and the strategy ends. If the strategy includes at least one rule-action combination and the result of the first rule is "false", the second rule is executed, and so on.

[0021] Furthermore, when constructing the strategy, S4 sets a default action, which is the command executed when a situation outside the scope of the rule occurs during the execution of the strategy.

[0022] Furthermore, the situations not within the scope of the rules include: the data carried in the request does not meet the requirements or does not exist, causing the policy execution to be abnormal; the policy receives a request sent by an unknown subject; a policy is closed during the execution of multiple policies; a circular call occurs during the execution of multiple policies; and none of the rules in the policy are satisfied.

[0023] Furthermore, when multiple strategies exist, a chain / tree / graph design is used for strategy orchestration. Typically, multiple strategy execution orchestration designs are chained structures, meaning the next strategy is executed immediately after the previous one, sequentially. However, in the strategy execution process designed in this invention, the next strategy executed changes based on the result of the previous strategy, and it can also involve multiple circular calls such as A -> B -> C -> A. Therefore, the strategy orchestration in this invention will exhibit chaining and tree-like structures. Figure 3 This is one of the situations.

[0024] Beneficial Effects: Compared with existing technologies, the advantages of this invention are as follows: This invention designs and stores rules by converting formatted language into program files, allowing multiple conditional expressions and corresponding execution actions within a single policy. Different actions can be executed when different expressions are satisfied. On one hand, this solves the problem of unconstrained rule parsing when operands and operators are uncertain, flexibly adapting to any complex access control scenario. On the other hand, the dynamic compilation method avoids real-time rule parsing at runtime, significantly improving the processing performance of the policy system. Furthermore, this invention allows for flexible arrangement of policy execution order when processing multiple policies, satisfying any user requirements. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of a typical existing access control flow.

[0026] Figure 2 This is a flowchart of the design and storage method of the network access control policy of the present invention;

[0027] Figure 3 This is a flowchart illustrating the strategy orchestration process. Detailed Implementation

[0028] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings, but the scope of protection of the present invention is not limited to the embodiments described.

[0029] Terminology Explanation:

[0030] Subject: The entity that requests to perform an operation on the object. Sometimes referred to as the requester, it can be a person or an NPE (non-human entity).

[0031] Objects: These are entities or resources that need to be protected to prevent unauthorized use.

[0032] Request: The subject sends a request to the access control system, requesting decision-making data for performing relevant operations on the object.

[0033] Operands: Variables (attributes) that participate in the evaluation of an expression.

[0034] Operators: Operators used for variable operations in expressions. In this invention, they are mainly divided into three categories: arithmetic operators, relational operators, and logical operators.

[0035] Expressions consist of operands and operators, and are divided into three categories in this invention: arithmetic expressions, relational expressions, and logical expressions. The results of relational and logical expressions are either "true" or "false", while the result of arithmetic expressions is a numerical value.

[0036] Rule: A combination expression consisting of one or more relational expressions and logical expressions, whose evaluation result is only "true" or "false".

[0037] Action: When the rule operation result is "true", send a command to the subject requesting a return.

[0038] Strategy: A script consisting of one or more rules and actions that can process relatively complex calculation results.

[0039] Interpreted languages: Programs written in interpreted languages ​​are not pre-compiled. The program code is stored as text and is translated and executed only when the program is executed. The program needs to be compiled every time it is executed.

[0040] Compiled languages: Compiled languages ​​must go through a compilation process before execution, compiling them into an executable machine language file. Because compilation is only done once and does not need to be done again, they have high execution efficiency.

[0041] like Figure 2 The diagram illustrates the design and storage process of the network access control policy of this invention.

[0042] 1. Construct expressions. The expression format is fixed as: operand + operator + operand. Operands are further divided into 4 categories:

[0043] Function: A piece of code that performs calculations, typically used by users to retrieve environment-related data;

[0044] Attribute value: Variable data carried in the decision request sent by the subject to the policy system;

[0045] Constant: Fixed data set manually;

[0046] Expression: The operand can also be an arithmetic expression itself.

[0047] Operators can be any arithmetic operator, relational operator, logical operator, and complex program operations, such as string prefix matching, suffix matching, regular expression matching, etc.

[0048] 2. Constructing rules: A rule is a complex computational process consisting of one or more expressions. The relationship between the expressions in a rule can only be "AND" or "OR". The final result of a rule can only be either "true" or "false".

[0049] 3. Construct actions: Commands executed when the corresponding rule calculation result is "true". Actions include two types: Type 1 is a command returned to the requesting decision-maker, which needs to be agreed upon with the requesting decision-maker. Type 2 is executing the next strategy.

[0050] 4. Construct a strategy. A strategy consists of one or more (a combination of rules and actions). If the result of the first rule is "true", the corresponding action is executed and the strategy ends. If the result of the first rule is "false", the second rule is executed, and so on.

[0051] This invention specifically points out that when constructing a strategy, it is necessary to design a default action for that strategy. The default action indicates that when certain abnormal situations occur during the strategy decision-making process that are not within the scope of the rules, such as: the data carried in the request does not meet the requirements or does not exist, causing the strategy execution to be abnormal; the strategy receives a request sent by an unknown subject; a strategy is closed during the execution of multiple strategies; a circular call occurs during the execution of multiple strategies; and none of the rules in the strategy are satisfied, the execution of the strategy will directly jump to the execution of the default action. The default action is not fixed but can be defined differently according to different situations.

[0052] The strategy execution process is illustrated below:

[0053] If the policy is off or a request is received from an unknown entity, then execute (default action 1: block); otherwise...

[0054] If the result of (Rule 1) is (true), then execute (Action 1: Allow), otherwise...

[0055] If rule 2 is true, then action 2: prevent.

[0056] If the result of (Rule 3) is (true), then execute (Action 3: Execute other strategies); otherwise...

[0057] Then execute the (default action).

[0058] If an exception occurs or a loop occurs during the above process, then execute (default action 2: allow passage).

[0059] 5. To generate the rule file, you first need to determine the compiled language used by the implementation system (e.g., C++, JAVA, etc.). Assuming the implementation system uses JAVA to implement the policy system, first construct a JAVA code segment containing only one class with only one function, as shown in the example below:

[0060] import + Constants.classPath + .instance.RequestInstance;

[0061] import + Constants.classPath + .util.Util;

[0062] import + Constants.classPath + .util.MyException;

[0063] import static + Constants.classPath + .util.UserFunction.*;

[0064] import java.lang.reflect.InvocationTargetException;

[0065] import java.util.*;

[0066] public class Expression_ + id + {

[0067] public static boolean func_ + id + (RequestInstancerequestInstance, Map <String, Map<String, Object> > tags) throwsInvocationTargetException, IllegalAccessException, ABACException {

[0068] return + expression;

[0069] }

[0070] }

[0071] Using the above code snippet as a general template, each defined rule generates a code snippet using this template. In this template, "id" represents a unique identifier assigned to the custom rule; for example, the timestamp used when defining the rule can be used as the unique identifier. The "expression" in the template corresponds to the compiled code that transforms the structured language describing the rule. For example, a policy might be: "Allow access if the subject is not banned" or "the subject's last appearance was more than 1 minute ago." The condition part of this policy, "if the subject is not banned" or "the subject's last appearance was more than 1 minute ago," would be translated into structured language as follows:

[0072] subRule: {logicalOperator: "||", expressionGroups: [{level:0,…},…], level: 0}

[0073] expressionGroups: [{level: 0,…},…]

[0074] 0: {level: 0,…}

[0075] left: {type: "attribute", policySpaceID: "ihpM2H8BAZVaZJFc3SJa",tempID: "8e0od3wBFgpKTvbrkXkI",…}

[0076] attrID: "pRk01n8BAZVaZJFcWKnn"

[0077] handleParameters: []

[0078] handleWithFunction: false

[0079] parameters: []

[0080] policySpaceID: "ihpM2H8BAZVaZJFc3SJa"

[0081] simpleConfigInfo: {parameters: [], handleParameters: [], value:{name: "", enable: false}}

[0082] tempID: "8e0od3wBFgpKTvbrkXkI"

[0083] tempType: "sub"

[0084] type: "attribute"

[0085] level: 0

[0086] operator: "=="

[0087] reversal: false

[0088] right: {type: "constant", value: "false", handleWithFunction: false,handleParameters: [], parameters: [],…}

[0089] handleParameters: []

[0090] handleWithFunction: false

[0091] parameters: []

[0092] simpleConfigInfo: {parameters: [], handleParameters: [], value:{name: "", enable: false}}

[0093] type: "constant"

[0094] value: "false"

[0095] 1: {level: 0, left: {type: "function", funcID: "func_getCurrentTs",handleWithFunction: true,…},…}

[0096] left: {type: "function", funcID: "func_getCurrentTs",handleWithFunction: true,…}

[0097] funcID: "func_getCurrentTs"

[0098] handleFuncID: "handle_programming"

[0099] handleParameters: ["#p-SUB(device model:ts)", "long"]

[0100] handleWithFunction: true

[0101] parameters: []

[0102] simpleConfigInfo: {parameters: [], handleParameters: [{name: "",enable: false}, {name: "", enable: false}],…}

[0103] type: "function"

[0104] level: 0

[0105] operator: ">"

[0106] reversal: false

[0107] right: {type: "constant", value: "60000", handleWithFunction: false,handleParameters: [], parameters: [],…}

[0108] handleParameters: []

[0109] handleWithFunction: false

[0110] parameters: []

[0111] simpleConfigInfo: {parameters: [], handleParameters: [], value:{name: "Ban time (milliseconds)", enable: true}}

[0112] type: "constant"

[0113] value: "60000"

[0114] level: 0

[0115] logicalOperator: "||".

[0116] Whether the structured language is interpreted or compiled, the usual practice is to parse the rules in real time when executing them. When defining the strategy, complex strategy rules are defined. When executing the strategy, the rules need to be parsed again in order to perform rule matching calculations. This process of parsing rules occurs every time a rule is executed, which is very inefficient.

[0117] This invention directly converts complex rules into program code during "policy definition" (the process of converting code is equivalent to the above-mentioned rule parsing process, converting the rules into code word by word) and calls the compiler to compile them into executable machine code. In this way, the machine code can be directly executed during "policy execution", eliminating the process of parsing rules every time it is executed.

[0118] In this invention, it is converted into the following program (JAVA):

[0119] ((((boolean)Util.OBJ(requestInstance,"ihpM2H8BAZVaZJFc3SJa","sub","8e0od3wBFgpKTvbrkXkI","pRk01n8BAZVaZJFcWKnn")==false)||((long)(((long)Util.FUNC(requestInstance,"func_getCurrentTs"))-((long)Util.OBJ(requestInstance,"ihpM2H8BAZVaZJFc3SJa","sub","8e0od3wBFgpKTvbrkXkI","8xk11n8BAZVaZJFcs6nL")))>(long)tags.get("Ban time (milliseconds)").get("realValue"))))

[0120] Replacing the expression part in the template with the transformed code creates a complete program file. This file corresponds to the conditional expression of a rule.

[0121] 6. Storing Rules: The rule files mentioned above are dynamically compiled into machine code and stored on disk. The compiler built into the programming language is called, and the code converted from the rules is input. The compiler compiles it into a file containing machine code, adds a unique identifier for each policy segment to each piece of machine code, and then loads the contents of this file into memory for storage. This has two advantages: First, the rules themselves are essentially encrypted during storage, enhancing security; second, the machine code directly generated by dynamic compilation is already stored in memory, and the execution performance of the policy will far exceed that of real-time rule parsing.

[0122] 7. Storage and execution strategy: Based on the logic of step 4 above, all rules and actions are stored in memory through the program. When executing rules, the "reflection" mechanism of the programming language is usually used to run the rules and thus realize the calculation of the strategy.

[0123] 8. The design of the policy invocation chain / tree / graph: In access control, the decision-making process for a request is often determined by more than one policy. In most cases, a complete access control flow involves a request being evaluated by multiple policies to determine the final command to be issued. This invention designs the operation modes of multiple policies so that they can be freely arranged according to user requirements, such as... Figure 2 As shown.

[0124] This invention designs and stores rules by converting a formatted language into program files. This solves the problem of unconstrained rule parsing when operands and operators are uncertain. Furthermore, the dynamic compilation method avoids real-time rule parsing at runtime, significantly improving the performance of the policy system. Additionally, this invention allows for flexible arrangement of policy execution order when processing multiple policies, meeting any user requirements.

[0125] As described above, although the invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the invention itself. Various changes in form and detail may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A method for designing and storing network access control policies, characterized in that, Includes the following steps: S1: Construct the expression; S2: Rules are constructed based on expressions, and the result of the rule operation is "true" or "false"; S3: Construct an action, which refers to the command executed when the corresponding rule operation result is "true"; S4: A strategy for constructing a rule-action combination; S5: Set a general template. In the general template, "id" represents the unique identifier of the rule, and "expression" corresponds to the program code converted from the structured language describing the rule. Use the general template to generate the corresponding rule code file for each rule. S6: The rule code file is converted into a file containing machine code that can be directly executed by a computer using dynamic compilation. The machine code is then attached with a unique identifier corresponding to the policy and stored in memory. S7: According to the rule-action combination logic in the S4 strategy, the combination of rules and actions is stored in memory in the form of a program. When the rule needs to be executed, the machine code corresponding to the rule in memory is directly called and executed to realize the strategy operation.

2. The method for designing and storing network access control policies according to claim 1, characterized in that: The fixed format of the expression is: operand + operator + operand, where operands include functions, attribute values, constants, and expressions, and operators include arithmetic operators, relational operators, logical operators, and program operators.

3. The method for designing and storing network access control policies according to claim 1, characterized in that: The rule includes one or more expressions, and when the rule includes more than one expression, the operational relationship between the expressions can be only one of "AND" and "OR".

4. The method for designing and storing network access control policies according to claim 1, characterized in that: The actions include two types: type one is to return the command agreed upon with the requesting decision-maker, and type two is to execute the next strategy.

5. The method for designing and storing network access control policies according to claim 1, characterized in that: The strategy includes one or more rule-action combinations. If the strategy includes at least one rule-action combination and the result of the first rule is "true", the corresponding action is executed and the strategy ends. If the strategy includes at least one rule-action combination and the result of the first rule is "false", the second rule is executed, and so on.

6. The method for designing and storing network access control policies according to claim 1, characterized in that: When constructing the strategy, S4 sets a default action, which is the command to be executed when a situation outside the scope of the rule occurs during the execution of the strategy.

7. The method for designing and storing network access control policies according to claim 6, characterized in that: The situations not covered by the rules include: the data carried in the request does not meet the requirements or does not exist, causing the policy execution to be abnormal; the policy receives a request from an unknown subject; a policy is closed during the execution of multiple policies; a circular call occurs during the execution of multiple policies; and none of the rules in the policy are satisfied.

8. The method for designing and storing network access control policies according to claim 1, characterized in that: When multiple strategies exist, the design of chains, trees, or graphs is invoked for strategy orchestration.

Images