Block chain-based provenance data dynamic permission access control system and method

Abstract

The invention discloses a blockchain-based provenance data dynamic permission access control system and method, which depend on an attribute-based access control normal form and are combined with access constraints of provenance data to carry out dynamic access control. Firstly, a user sends an access request to a strategy decision point; and the decision point requests related information from the block chain according to the policy loaded from the policy management point, calls a user historical behavior verification module based on the provenance data, and verifies the legality of the current access request by using the dependency relationship and the provenance data graph. And the system administrator records the access request and the verification result into the block chain to support quick verification of the same query, so that the query overhead is reduced. In addition, the system transmits access information such as a query user, time, a result, operation content and the like to the management node for tracking and management of subsequent user access. According to the method, the anonymity and non-tampering property of the block chain are utilized, powerful evidence is provided for user supervision, and efficient management and reasoning of source information are achieved.

Description

Technical Field

[0001] The present invention belongs to the technical fields of lineage data, access control, and blockchain technology, and relates to a fine-grained access control system and method, specifically to a fine-grained access control system and method for lineage data based on blockchain. Background Art

[0002] In recent years, with the development of the industrial Internet, industrial devices have gradually moved towards informatization and intelligence, bringing about an improvement in production efficiency and a reduction in costs. However, this has also led to an increasing number of industrial terminal devices being connected to the Internet, bringing new security challenges. Access control of terminal devices has become an important link in ensuring the security of the industrial Internet. If the access control policy is not flexible enough or the authorization granularity is relatively coarse, the system may be vulnerable to attacks. Therefore, how to effectively control the access rights of terminal devices in a dynamic environment is the focus of current industrial Internet security research.

[0003] With the development of technologies such as the Internet and the Internet of Things, the demand for access control is also constantly changing. Traditional access control models are difficult to meet the security requirements of the industrial Internet. Especially in a dynamic environment, access control not only requires fine-grained authorization management but also needs to track the historical evolution of data objects to better adapt to changes in access relationships between different terminal devices. To solve these problems, some new access control models have been proposed in recent years, attempting to combine the source information of data objects to explain the execution history of access decisions and the evolution process of data.

[0004] Lineage data describes the entire process of data generation and evolution over time. By using lineage data, the historical evolution and access relationships of data objects in the system can be tracked, thereby achieving more precise permission allocation. This lineage-based access control model can dynamically adjust access policies according to changes in time and space to reflect changes in the state of data objects, meeting the fine-grained and dynamic requirements in the industrial Internet.

[0005] With the rise of blockchain technology, its characteristics of decentralization, distribution, and immutability are gradually being applied to the field of access control. Blockchain technology can provide a distributed deployment and auditing mechanism, and a trust mechanism without the endorsement of a third party. These features are very suitable for solving access control problems in a big data environment. Currently, blockchain-based access control technologies have been applied in multiple fields such as the Internet of Things, cloud computing, healthcare, and industrial automation. However, existing access control mechanisms are usually designed for specific application scenarios, lack universality, and are difficult to meet the requirements for fine-grained and traceability in a dynamic environment.

[0006] So far, no access control model has been able to regulate and enforce access restrictions that simultaneously consider lineage data objects and the underlying data fusion process. Summary of the Invention

[0007] The object of the present invention is to provide a fine-grained access control system and method for lineage data based on blockchain. By using the lineage data graph and combining blockchain technology, it realizes fine-grained, more efficient, traceable and supervised access control.

[0008] The technical solution adopted by the system of the present invention is: a dynamic permission access control system for lineage data based on blockchain, characterized in that it includes a dynamic management access control module and a user historical behavior verification module based on lineage data;

[0009] The dynamic management access control module is used to implement request analysis and authorization evaluation for users, and includes a Policy Decision Point (PDP), a Policy Administration Point (PAP) and a blockchain;

[0010] The Policy Decision Point (PDP) is used to collect information and evaluate users' access requests according to given policies; the Policy Administration Point (PAP) is used to maintain a policy repository and provide policies to the Policy Decision Point (PDP) to evaluate access requests; the blockchain is used to record access and decisions and provide information required for policy evaluation to the Policy Decision Point (PDP).

[0011] The user historical behavior verification module based on lineage data is used to analyze users' historical access requests and historical access behaviors by tracing the data; when the Policy Decision Point (PDP) encounters a path condition that needs to evaluate the current request in the policy, it calls the user historical behavior verification module based on lineage data.

[0012] Preferably, the user historical behavior verification module based on lineage data first generates a lineage graph from the system log, then defines temporary dependencies, and combines the two to evaluate path queries.

[0013] Preferably, the lineage graph shows how an object is derived, and uses N, D, P, and S to represent the sets of nodes, artifacts, processes, and agents respectively, where N = D ∪ P ∪ S, and D, P, and S are pairwise disjoint; among them, the nodes of the lineage graph are denoted as Artifact, Process, Agent; Artifact refers to a state, which is a physical object or a digital representation in a computer system; Process refers to one or a series of actions caused by an Artifact, and a Process can generate multiple Artifacts, and these Artifacts will have different roles; Agent refers to the catalyst of a Process, which is used to promote, control, and influence the execution of a Process.

[0014] Preferably, the edges of the lineage graph record three types of temporary dependencies, namely used, wasGeneratedBy, and wasControlledBy; among them, records the Artifact used by a Process; records the source Process of an Artifact; records which Agent controls a Process;

[0015] For a temporary dependency T, where r is a role label, and r ∈ R represents the set of role labels; represents the relationship between node n and node n' in a causal dependency relationship T, specifically limited to role r, and can be used to determine whether a certain node n has an impact on another node n' under a specific role r;

[0016] Derive dependency relationships from the lineage graph through combined dependency relationships, including wasTriggeredBy, wasDerivedFrom°, wasDerivedFrom + and wasTriggeredBy + ; among them, used° records that an Artifact is derived from another Artifact, and all Artifacts on which a Process depends; wasGeneratedBy° records that a Process is triggered by another Process; wasDerivedFrom + records that all Artifacts can be directly or indirectly deduced from it; represents all processes directly or indirectly triggered by a Process, and records all processes before an Artifact is generated;

[0017] For Artifacts, it is supported to indicate the role of another Artifact in its creation process, with tagging describes how an Artifact is indirectly derived from another Artifact, composed of wasGeneratedBy° and used°; among them, wasGeneratedBy° indicates that an Artifact is generated by a certain Process, and used° indicates that a certain Process uses another Artifact;

[0018] Define the ownership of an Artifact, specifying that the ownership of an Artifact comes from the ownership of the Process that generates the Artifact: Among them, wasGeneratedBy owner indicates that the Process that generates the Artifact is controlled by the role "owner", where owns represents ownership and owner represents the owner.

[0019] Define temporary dependencies, including basic temporary dependencies, multi-step temporary dependencies, and custom temporary dependencies;

[0020] The basic temporary dependency used(p:P, d:D, r:R), where r comes from the set of role tags R, p comes from the set of processes P, and d comes from the set of Artifacts D.

[0021] Multi-step temporary dependencies, describe how a process p indirectly uses an Artifact d through another process p i where r represents the specific role involved, and wasTriggeredBy + (p, p i ) indicates that p is directly or indirectly triggered by p i directly or indirectly.

[0022] Custom temporary dependencies

[0023] Preferably, call the user historical behavior verification module based on lineage data to perform path condition evaluation and derive T from the combined dependencies i ; where T j and T j respectively represent the order of activities i and j in time. Between the two activities T i and T j there is a certain used° relationship, which defines the association between entities n and n′ in data usage or lineage graph;

[0024] In the genealogy diagram, used, wasGeneratedBy, and wasControlledBy are defined to represent the relationships between data, that is, security constraint conditions. Among them, used indicates that an activity uses an entity and is used to describe the relationship between the activity and the data it depends on; wasGeneratedBy indicates that an entity is generated by an activity and is used to describe the causal relationship in the data generation process; wasControlledBy indicates that an activity is controlled by an agent and is used to describe who is responsible for the result or behavior of the activity.

[0025] The technical solution adopted by the method of the present invention is: a method for dynamically accessing and controlling permissions of genealogy data based on blockchain, including the following steps:

[0026] Step 1: The user sends an access request to the Policy Decision Point (PDP).

[0027] Step 2: The Policy Decision Point (PDP) processes the request into the form of (attribute name, key value).

[0028] Step 3: The Policy Decision Point (PDP) loads the management policy from the Policy Administration Point (PAP). If an attribute is missing in the request, the Policy Decision Point (PDP) asks the blockchain for additional information about the object.

[0029] Step 4: If the blockchain records the user who sent the request and the corresponding access decision, jump to the following Step 8 and output the decision; otherwise, the blockchain returns the additional information to the Policy Decision Point (PDP).

[0030] Step 5: The Policy Decision Point (PDP) performs policy evaluation. If path conditions are required for policy evaluation, the Policy Decision Point (PDP) sends a request to the User Historical Behavior Verification Module based on Genealogy Data. If path conditions are not required for policy evaluation, directly combine the current user request and the attribute access control list to give the policy evaluation result.

[0031] Step 6: The User Historical Behavior Verification Module based on Genealogy Data parses the corresponding path query.

[0032] Step 7: After the Policy Decision Point (PDP) collects all relevant information and evaluates the path conditions, it makes a decision and records the decision and user access information on the blockchain.

[0033] Step 8: If the decision result is "yes", the Policy Decision Point (PDP) requests authorization from the user. If the decision result is "no", the Policy Decision Point (PDP) outputs an exception of denied access.

[0034] Preferably, in step 3, when the Policy Decision Point (PDP) interacts with the blockchain, it is required to send the user request time, request content, decision result, and the management policy number on which the decision is based to the nodes of the blockchain system for blockchain storage.

[0035] Preferably, in step 5, when the Policy Decision Point (PDP) performs policy evaluation, it first defines a policy set Pol A , a query set Q A , a decision set D, and a policy evaluation function When a given query q and policy pol are provided, semantically represents the evaluation decision of pol on q. Define D = {Permit, Deny, NA}, where Permit means access is allowed, Deny means access is denied, and NA represents not requestable;

[0036] Policy evaluation supports boolean path conditions:

[0037] pol 2 = (contributedTo(subject_organize, resource_id) ∧ (action = readVaction = download), 1);

[0038] Among them, subject_organize is the organization to which the subject belongs, resource_id is the unique identifier of the resource to be accessed, used to determine the specific object to be accessed; read and download respectively represent the read operation and the download operation. Only when the organization to which the requester belongs has contributed to the generation process of resource_id, access (download or read operation) is allowed; contributedTo represents the contribution relationship of a certain subject subject_organize to the resource resource_id. For example, the resource may be created, modified, or participated in by the subject; the lineage module takes the path query as input. If there is 1 path in the lineage graph that matches the path query, it returns True, otherwise it returns False; policy evaluation supports policy reference path conditions:

[0039] pol 3 = dov({uri(x)|wasDrivedFrom(resourced id , x)});

[0040] Among them, resourced idRepresents the target resource in the query; x is a variable representing potential input resources; wasDrivedFrom indicates whether the requested accessed resource is derived from another resource; the uri(x) function is used to obtain the policy associated with resource x according to the path condition; dov() is used to combine policies. In this combination, when accessing resource x, the access control policy associated with this derived resource should be followed. If any policy rejects the access request, the overall decision is to reject.

[0041] First, the control module (Policy Decision Point PDP, Policy Administration Point PAP, and blockchain) runs a path matching algorithm to return all entities in the lineage graph that satisfy the path query, and then retrieves and returns the policies associated with these entities for evaluation.

[0042] Preferably, in step 6, in the case of nested policies, the Policy Decision Point PDP can send multiple requests to the user historical behavior verification module based on lineage data.

[0043] Preferably, in step 8, an evaluation function is used to obtain the verification result, and the target is a boolean value.

[0044] Compared with the prior art, the effective benefits of the present invention include:

[0045] 1. Based on the Attribute-Based Access Control paradigm (ABAC), the present invention proposes a method for dynamic permission access control based on blockchain for lineage data. In the lineage data module, the lineage information is not only used as the basis for access decisions, but also records the evolution of data during the generation and derivation processes through the lineage data graph, supporting dynamic access control for derived objects. Specifically, this method can define access policies by combining the attributes of data sources, derivation relationships, and security constraint conditions involved in the data fusion process in the access restrictions of derived objects, so as to ensure that the access permissions of different participating parties to derived data are consistent with the security policies of the initial data sources.

[0046] 2. The present invention combines blockchain with the access control model, records each user access request and the returned decision on the blockchain, saves the overhead for repeated queries, and provides a way for system administrators to query the origin. Utilizing the immutability of blockchain provides strong evidence for supervising the users who issue requests to achieve the management and reasoning of source information.

[0047] 3. The present invention proposes an innovative method that combines lineage data, blockchain technology, and existing access control models to achieve more fine-grained dynamic permission management and significantly reduce the overhead of the verification process through blockchain. This new method not only meets the access control requirements in the industrial Internet, but also provides new ideas for future access control research. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The following uses embodiments and specific implementation manners to further illustrate the technical solution of the present invention. In addition, during the description of the technical solution, some drawings are also used. For those skilled in the art, without creative work, other drawings and the intention of the present invention can also be obtained based on these drawings.

[0049] Figure 1 It is the system schematic diagram of the embodiment of the present invention;

[0050] Figure 2 It is the method flow chart of the embodiment of the present invention. Specific implementation manner

[0051] To facilitate the understanding and implementation of the present invention by those of ordinary skill in the art, the present invention will be further described in detail below in conjunction with the drawings and embodiments. It should be understood that the embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0052] This embodiment adopts the Open Provenance Model (OPM+). Genealogy data information is usually represented as a labeled genealogy graph to show how an object is derived. The nodes of the genealogy graph can be Artifact, Process, and Agent.

[0053] Artifact is used to refer to a state. It can be a physical object or a digital expression in a computer system.

[0054] Process refers to one or a series of actions caused by Artifact.

[0055] Agent refers to the catalyst of Process. It is used to promote, control, and influence the execution of Process.

[0056] In addition, OPM+ also introduces the concept of role Role. A Process may generate multiple Artifacts, and these Artifacts will have different roles Role. Taking a division operation as an example, the Agent is the calculator operation program, the Process is the division operation, and there are two Artifacts participating in the operation. They respectively belong to the two roles of divisor and dividend. The results of the operation also include two Artifacts, which respectively belong to the two roles of quotient and remainder.

[0057] This embodiment uses R to represent the set of role labels, and N, D, P, and S respectively refer to the sets of nodes, Artifacts, Processes, and Agents. The relationships between them are as follows:

[0058] N = D ∪ P ∪ S and D, P, S are pairwise disjoint.

[0059] The edges of the lineage graph record three types of temporary dependencies, namely:

[0060] Record the Artifact used by the Process;

[0061] Record the source Process of the Artifact;

[0062] Record which Agent controls the Process;

[0063] For a temporary dependency T, where r is a role label, r ∈ R represents the set of role labels; Represents the relationship between node n and node n' in a causal dependency relationship T, specifically limited to the role r. It can be used to determine whether a certain node n has an impact on another node n' under a specific role r;

[0064] OPM+ includes several additional dependency relationships, which can be derived from the lineage graph through combined dependency relationships, expressed as follows:

[0065] used° records that an Artifact is derived from another Artifact, and all Artifacts on which the Process depends.

[0066] wasGeneratedBy° records that a Process is triggered by another Process.

[0067] wasDerivedFrom + (Transitive closure), records that all Artifacts can be directly or indirectly derived from it.

[0068] Represents all processes directly or indirectly triggered by the Process, and records all processes before the generation of the Artifact.

[0069] Based on OPM+, the present invention extends the lineage model. For an Artifact, this model supports indicating the role of another Artifact in its creation process. Therefore, the tag Describes how an Artifact is indirectly derived from another Artifact, composed of wasGeneratedBy° and used°; where wasGeneratedBy° indicates that an Artifact is generated by a certain Process, and used° indicates that a certain Process uses another Artifact;

[0070] The present invention introduces two custom dependencies, which use specific role owners ∈ R to indicate all Artifacts and contributors.

[0071] Define that the owner of a Process that generates an Artifact owns that Artifact:

[0072]

[0073] Define basic temporary dependencies, multi-step temporary dependencies, and custom temporary dependencies.

[0074] The basic temporary dependency used(p:P, d:D, r:R), where r comes from the set of role tags R, p comes from the set of processes P, and d comes from the set of Artifacts D.

[0075] Multi-step temporary dependency, Describes how a process p indirectly uses an Artifact d through another process p i where r represents the specific role involved, and wasTriggeredBy + (p, p i ) indicates that p is directly or indirectly triggered by p i directly or indirectly triggered.

[0076] The custom temporary dependency is expressed as:

[0077] This embodiment adopts the ABAC basic model, and the basic parameters applied in the model are defined as follows:

[0078] Related basic sets: the set of attributes A, where attributes are descriptive information about users, resources, operations, and environments. The values of attributes can be static (e.g., the department of a user) or dynamic (e.g., the current time); the query set Q A ;

[0079] The set of attributes A = {a 1 , …, a n}, given an attribute a ∈ A, V a is the domain of a.

[0080] The query q = {(a 1 , v1 ),…,(a k ,v k )}。

[0081] A policy can be a decision-making policy, a target policy or a composite policy, which is defined as follows:

[0082] Decision-making policy: permit (1), reject (0);

[0083] Target policy: (t, pol), where the target t defines the capabilities of the policy;

[0084] Composite policy: ca(pol 1 ,…,pol n );

[0085] Use the evaluation function to obtain the verification result, and the target is a boolean value: It is defined as follows: It means that if there is an association q between the attribute a and v′, and op(v′, v) is satisfied, that is, v′ and the target value v satisfy the operation relationship op, then return True, otherwise return False.

[0086] Please refer to Figure 1 , a blockchain-based lineage data dynamic permission access control system provided in this embodiment includes a dynamic management access control module and a user historical behavior verification module based on lineage data.

[0087] The dynamic management access control module is used to implement request analysis and authorization evaluation for users, including a Policy Decision Point (PDP), a Policy Administration Point (PAP), and a blockchain;

[0088] The Policy Decision Point (PDP) is used to collect information and evaluate users' access requests according to the given policy; the Policy Administration Point (PAP) is used to maintain the policy repository and provide policies to the Policy Decision Point (PDP) to evaluate access requests; the blockchain is used to record access and decisions and provide information required for policy evaluation to the Policy Decision Point (PDP);

[0089] The user historical behavior verification module based on lineage data is used to analyze users' historical access requests and historical access behaviors by tracing the data; when the Policy Decision Point (PDP) encounters a path condition that needs to evaluate the current request in the policy, the user historical behavior verification module based on lineage data is called.

[0090] In one implementation, the user historical behavior verification module based on lineage data first generates a lineage graph from system logs, then defines temporary dependencies, and combines the two to evaluate path queries.

[0091] In one implementation, the lineage graph, which represents how an object is derived, uses N, D, P, and S to represent the sets of nodes, artifacts, processes, and agents respectively, where N = D ∪ P ∪ S, and D, P, and S are pairwise disjoint; among them, the nodes of the lineage graph are denoted as Artifact, Process, Agent; Artifact refers to a state, a physical object, or a digital representation in a computer system; Process refers to one or a series of actions caused by an Artifact, and one Process can generate multiple Artifacts, and these Artifacts will have different roles; Agent refers to the catalyst of the Process, which is used to promote, control, and influence the execution of the Process.

[0092] In one implementation, the user historical behavior verification module based on lineage data is called to perform path condition evaluation, and T is derived from the combined dependencies. i ; where T i and T j respectively represent the temporal order of activities i and j. Between two activities T i and T j there is a certain used° relationship, and this relationship defines the association of entities n and n′ in data usage or the lineage graph.

[0093] In the lineage graph, used, wasGeneratedBy, and wasControlledBy are defined to represent the relationships between data, that is, security constraint conditions; among them, used means that an activity uses an entity, which is used to describe the relationship between the activity and the data it depends on; wasGeneratedBy means that an entity is generated by an activity, which is used to describe the causal relationship in the data generation process; wasControlledBy means that an activity is controlled by an agent (person or system), which is used to describe who is responsible for the result or behavior of the activity.

[0094] Please refer to Figure 2 , a blockchain-based dynamic permission access control method for lineage data provided in this embodiment includes the following steps:

[0095] Step 1: The user sends an access request to the Policy Decision Point PDP.

[0096] Step 2: The Policy Decision Point (PDP) processes the request in the form of (attribute name, key value).

[0097] Step 3: The Policy Decision Point (PDP) loads the management policy from the Policy Administration Point (PAP). If some attributes are missing in the request, the Policy Decision Point (PDP) asks the blockchain for additional information about the object.

[0098] In one implementation, when the Policy Decision Point (PDP) interacts with the blockchain, it is necessary to send information such as the user request time, request content, decision result, and the management policy number on which the decision is based to the nodes of the blockchain system for on-chain storage.

[0099] Step 4: If the blockchain records the user who issued the request and the corresponding access decision, jump to the following Step 8 and output the decision; otherwise, the blockchain returns the additional information to the Policy Decision Point (PDP).

[0100] Step 5: The Policy Decision Point (PDP) conducts policy evaluation. If path conditions are required for policy evaluation, the Policy Decision Point (PDP) sends a request to the User Historical Behavior Verification Module based on lineage data; if path conditions are not required for policy evaluation, the policy evaluation result is directly given by combining the current user request and the Attribute Access Control List.

[0101] In one implementation, when the Policy Decision Point (PDP) conducts policy evaluation, it first defines a policy set Pol A , a query set Q A , a decision set D, and a policy evaluation function When a given query q and a policy pol semantically represent the evaluation decision of pol on q, define D = {Permit, Deny, NA}, where Permit represents allowed access, Deny represents denied access, and NA represents non-requestable.

[0102] Policy evaluation supports boolean path conditions:

[0103] pol 2 = (contributedTo(subject_organize, resource_id) ∧ (action = readVaction = download), 1);

[0104] Among them, subject_organize is the organization to which the subject belongs, and resource_id is the unique identifier of the resource to be accessed, which is used to determine the specific object to be accessed; read and download respectively represent the read operation and the download operation. Only when the organization to which the requester belongs has contributed to the generation process of resource_id, is access (download or read operation) allowed; contributedTo represents the contribution relationship of a subject subject_organize to a resource resource_id. For example, the resource may be created, modified, or participated in by the subject; the lineage module takes the path query as input. If there is 1 path in the lineage graph that matches the path query, it returns True, otherwise it returns False; the policy evaluation supports the policy reference path condition:

[0105] pol 3 = dov({uri(x)|wasDrivedFrom(resourced id ,x)});

[0106] Among them, resourced id represents the target resource in the query; x is a variable representing a potential input resource; wasDrivedFrom indicates whether the requested resource is derived from another resource; the uri(x) function is used to obtain the policy associated with resource x according to the path condition; dov() is used to combine policies. In this combination, when accessing resource x, the access control policy associated with this derived resource should be followed. If any policy rejects the access request, the overall decision is to reject;

[0107] First, the control module (Policy Decision Point PDP, Policy Administration Point PAP, and blockchain) runs the path matching algorithm to return all entities in the lineage graph that satisfy the path query, and then retrieves and returns the policies associated with these entities for evaluation. The purpose is to extend the access control decision to the source of the resource, ensure that the access rights of the derived resource comply with the policy requirements of its original data, and thus maintain the security and consistency of the data.

[0108] Step 6: The user historical behavior verification module based on lineage data parses the corresponding path query;

[0109] In one implementation, in the case of nested policies, the Policy Decision Point PDP can send multiple requests to the user historical behavior verification module based on lineage data.

[0110] Step 7: After the Policy Decision Point PDP collects all relevant information and evaluates the path conditions, it makes a decision and records the decision and user access information on the blockchain;

[0111] Step 8: If the decision result is "Yes", the Policy Decision Point (PDP) authorizes the request to the user; if the decision result is "No", the PDP outputs an exception of denied access.

[0112] In one implementation, an evaluation function is used to obtain the verification result, and the target is a Boolean value.

[0113] The present invention proposes an innovative method that combines lineage data, blockchain technology, and existing access control models to achieve finer-grained dynamic permission management. This new method not only meets the access control requirements in the industrial Internet but also provides new ideas for future access control research.

[0114] It should be understood that the described embodiments above are some embodiments of the present invention, rather than all embodiments. Additionally, the technical features in each embodiment or individual embodiment provided by the present invention can be combined with each other arbitrarily to form a feasible technical solution. This combination is not restricted by the order of steps and / or the structural composition mode, but must be based on what can be achieved by those of ordinary skill in the art. When the combination of technical solutions results in contradictions or cannot be achieved, it should be considered that such a combination of technical solutions does not exist and is not within the protection scope required by the present invention.

[0115] It should be understood that the above description of the preferred embodiments is relatively detailed and should not be considered as a limitation to the protection scope of the present invention. Those of ordinary skill in the art, under the inspiration of the present invention and without departing from the protection scope defined by the claims of the present invention, can still make substitutions or modifications, which all fall within the protection scope of the present invention. The protection scope claimed by the present invention shall be subject to the appended claims.

Claims

1. A blockchain-based lineage data dynamic permission access control system, characterized by: It includes a dynamic management access control module and a user history behavior verification module based on lineage data; The dynamic management access control module is used to implement the analysis of user requests and authorization evaluation, including a policy decision point PDP, a policy management point PAP and a blockchain; The policy decision point PDP is used to collect information and evaluate the user's access request according to a given policy; The policy management point PAP is used to maintain a policy repository and provide policies to the policy decision point PDP to evaluate access requests; the blockchain is used to record access and decisions and provide the policy decision point PDP with information required for policy evaluation; The user historical behavior verification module based on lineage data is used to analyze the user's historical access requests and historical access behaviors by tracing the data; when the policy decision point PDP encounters a path condition that requires evaluating the current request in the policy, the user historical behavior verification module based on lineage data is called.

2. The blockchain-based lineage data dynamic permission access control system according to claim 1 is characterized by: The user history behavior verification module based on lineage data first generates a lineage graph from system logs, then defines temporary dependencies, and combines the two to evaluate path queries.

3. The blockchain-based lineage data dynamic permission access control system according to claim 2 is characterized by: The lineage graph represents how an object is derived, with N, D, P and S representing the set of nodes, artifacts, processes and agents respectively, where N = D∪P∪S, and D, P and S do not intersect with each other. The nodes of the lineage graph are recorded as Artifact, Process and Agent. Artifact refers to a state, which is a physical object or a digital expression in a computer system. Process refers to one or a series of actions caused by an Artifact. A Process can generate multiple Artifacts, and these Artifacts will have different roles. Agent refers to the catalyst of the Process, which is used to promote, control and influence the execution of the Process.

4. The blockchain-based lineage data dynamic permission access control system according to claim 3 is characterized by: The edges of the lineage graph record three types of temporary dependencies: used, wasGeneratedBy, and wasControlledBy; Record the Artifact used by the Process; Record the source process of the Artifact; Record which Agent controls the Process; For a temporary dependency T, Where r is the role label, r∈R represents the role label set; Indicates the relationship between node n and node n′ in a causal dependency relationship T, specifically limited to role r, which is used to determine whether a node n has an impact on another node n′ under a specific role r; Derives dependencies from the lineage graph by combining dependencies, including wasTriggeredBy, wasDerivedFrom°, wasDerivedFrom + and wasTriggeredBy + ;in, used ° Record that an Artifact comes from another Artifact, as well as all the Artifacts that the Process depends on; wasGeneratedBy° records that a Process is triggered by another Process; wasGeneratedBy + , record all artifacts that can be directly or indirectly derived from it; Represents all processes that are directly or indirectly triggered by Process, and records all processes before Artifact is generated; For Artifact, support indicating the role of another Artifact in its creation process, marking Describes how an Artifact is indirectly derived from another Artifact, through the combination of wasGeneratedBy° and used°; where wasGeneratedBy° indicates that an Artifact is generated by a process, and used° indicates that a process uses another Artifact; Define the ownership of an Artifact and make it clear that the ownership of an Artifact comes from the ownership of the Process that generates the Artifact: Among them, wasGeneratedBy owner Indicates that the process that generates the artifact is controlled by the role "owner", owns indicates ownership, and owner indicates the owner; Define temporary dependencies, including basic temporary dependencies, multi-step temporary dependencies, and custom temporary dependencies; Basic temporary dependency used(p:P,d:D,r:R), r comes from the role label set R, p comes from the process set P, and d comes from the artifact set D; Multi-step temporary dependencies, Describes how a process p is passed through another process p i Indirect use of artifact d; where r represents the specific role involved, wasTriggeredBy + (p,p i ) means p is p i Direct or indirect triggering; Custom temporary dependencies 5. The blockchain-based lineage data dynamic permission access control system according to any one of claims 1 to 4, characterized in that: Call the user historical behavior verification module based on lineage data to evaluate the path conditions and derive T from the combined dependency relationship. i ; Where T i and T j Represent the temporal order of activities i and j respectively. i and T j There is a used° relationship between entities n and n', which defines the association between entities n and n' in the data usage or lineage graph; In the lineage diagram, used, wasGeneratedBy, and wasControlledBy are defined to represent the relationship between data, that is, security constraints; used means that an activity uses an entity, which is used to describe the relationship between the activity and the data it depends on; wasGeneratedBy means that an entity is generated by an activity, which is used to describe the causal relationship in the data generation process; wasControlledBy means that an activity is controlled by an agent, which is used to describe who is responsible for the results or behaviors of the activity.

6. A method for dynamic permission access control of lineage data based on blockchain, applied to the system described in any one of claims 1-5; characterized in that: The following steps are involved: Step 1: The user sends an access request to the policy decision point PDP; Step 2: The policy decision point PDP processes the request into the form of (attribute name, key value); Step 3: The policy decision point PDP loads the management policy from the policy administration point PAP. If the attribute is missing in the request, the policy decision point PDP asks the blockchain for additional information about the object. Step 4: If the blockchain records the user who made the request and the corresponding access decision, jump to the following step 8 and output the decision; otherwise, the blockchain returns the additional information to the policy decision point PDP; Step 5: The policy decision point PDP performs policy evaluation; If the policy evaluation requires a path condition, the policy decision point PDP sends a request to the user historical behavior verification module based on lineage data; If the policy evaluation does not require path conditions, the policy evaluation result is given directly in combination with the current user request and the attribute access control list; Step 6: the user history behavior verification module based on lineage data parses the corresponding path query; Step 7: After the policy decision point PDP collects all relevant information and evaluates the path conditions, it makes a decision and records the decision and user access information on the blockchain; Step 8: If the decision result is "yes", the policy decision point PDP authorizes the request to the user, and if the decision result is "no", the policy decision point PDP outputs an exception of denying access.

7. The blockchain-based lineage data dynamic permission access control method according to claim 6 is characterized by: In step 3, the policy decision point PDP interacts with the blockchain and needs to send the user request time, request content, decision result and the management policy number based on it to the node chain of the blockchain system.

8. The blockchain-based lineage data dynamic permission access control method according to claim 6 is characterized by: In step 5, the policy decision point PDP performs policy evaluation and first defines the policy set Pol A 、Query set Q A , decision set D and strategy evaluation function When given a query q and a policy pol, Semantically, it represents the evaluation decision of pol on q, and defines D = {Permit, Deny, NA}, where Permit means allowing access, Deny means denying access, and NA means not requesting; Policy evaluation supports Boolean path conditions: pol2=(contributedTo(subject_organize,resource_id)∧(action=read∨action=download),1); Among them, subject_organize is the organization to which the subject belongs, resource_id is the unique identifier of the resource to be accessed, which is used to determine the specific object to be accessed; read and download represent read and download operations respectively. Access is allowed only when the organization to which the requester belongs contributes to the generation process of resource_id; contributedTo represents the contribution relationship of a subject subject_organize to the resource resource_id; the lineage module takes the path query as input, and returns True if there is a path in the lineage graph that matches the path query, otherwise it returns False; policy evaluation supports policy reference path conditions: pol3=dov({uri(x)|wasDrivedFrom(resourced id ,x)}); Among them, resourced id represents the target resource in the query; x is a variable representing a potential input resource; wasDrivedFrom indicates whether the resource requested for access is derived from another resource; the uri(x) function is used to obtain the policy associated with resource x based on the path condition; dov() is used to combine policies, in which access to resource x should follow the access control policy associated with the derived resource. If any policy denies the access request, the overall decision is to deny; First, the control module runs a path matching algorithm to return all entities in the lineage graph that satisfy the path query, and then retrieves and returns the policies associated with these entities for evaluation.

9. The blockchain-based lineage data dynamic permission access control method according to claim 6 is characterized by: In step 6, in the case of nested policies, the policy decision point PDP can send multiple requests to the user historical behavior verification module based on lineage data.

10. The blockchain-based lineage data dynamic permission access control method according to any one of claims 6 to 9, characterized in that: In step 8, the evaluation function is used to obtain the verification result, and the target is a Boolean value.

Images