Blockchain-based pedigree data dynamic permission access control system and method

Abstract

The application discloses a kind of based on blockchain's pedigree data dynamic permission access control system and method, rely on attribute-based access control paradigm, and combine pedigree data access constraint to carry out dynamic access control.First, user sends access request to policy decision point;Decision point according to the policy loaded from policy management point, request relevant information to blockchain, and call user historical behavior verification module based on pedigree data, the legality of current access request is verified using dependency relationship and pedigree data graph.System administrator records access request and verification result to blockchain, to support the fast verification of same query, reduce query overhead.In addition, the system passes access information such as query user, time, result, operation content to management node, for subsequent user access tracking and management.The method uses the anonymity and non-tamperability of blockchain, provides strong evidence for user supervision, realizes efficient management and reasoning to source information.

Description

Technical Field

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

[0002] In recent years, with the development of the Industrial Internet, industrial equipment has gradually moved towards informatization and intelligence, bringing about increased production efficiency and reduced costs. However, this has also led to an increasing number of industrial terminal devices connecting to the Internet, bringing new security challenges. Access control for terminal devices has become a crucial aspect of ensuring Industrial Internet security. If access control policies are not flexible enough or the authorization granularity is too coarse, the system may be vulnerable to attacks. Therefore, how to effectively control the access permissions of terminal devices in a dynamic environment is a key focus of current Industrial Internet security research.

[0003] With the development of technologies such as the Internet and the Internet of Things (IoT), access control requirements are constantly evolving, and traditional access control models are struggling to meet the security needs of the Industrial Internet. Especially in dynamic environments, 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 address these issues, several 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 of data.

[0004] Provenance data describes the entire process of data generation and evolution over time. Using provenance data, the historical evolution and access relationships of data objects in a system can be tracked, enabling more precise permission allocation. This provenance-based access control model can dynamically adjust access policies based on changes in time and space to reflect changes in the state of data objects, meeting the fine-grained and dynamic requirements of the Industrial Internet.

[0005] With the rise of blockchain technology, its decentralized, distributed, and immutable characteristics are increasingly being applied to the field of access control. Blockchain technology offers distributed deployment and auditing mechanisms, as well as trust mechanisms that do not require third-party endorsement. These features make it highly suitable for solving access control problems in big data environments. Currently, blockchain-based access control technology has been applied in various fields such as the Internet of Things, cloud computing, healthcare, and industrial automation. However, existing access control mechanisms are typically designed for specific application scenarios, lacking universality and failing to meet the needs for fine-grained control and traceability in dynamic environments.

[0006] To date, no access control model has been able to standardize and implement access restrictions that simultaneously consider both lineage data objects and the underlying data fusion process. Summary of the Invention

[0007] The purpose of this invention is to provide a fine-grained access control system and method based on blockchain lineage data. By utilizing lineage data graphs and combining them with blockchain technology, fine-grained, more efficient, traceable, and monitorable access control can be achieved.

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

[0009] The dynamic management access control module is used to analyze user requests and evaluate authorization, including the policy decision point (PDP), the policy management point (PAP), and the blockchain.

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

[0011] The user history 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 evaluation of the current request in the policy, the user history behavior verification module based on lineage data is invoked.

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

[0013] Preferably, the lineage diagram represents how an object is derived, using 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 mutually disjoint. The nodes in the lineage diagram are denoted as Artifact, Process, and 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; a Process can generate multiple Artifacts, each with a different role. Agent refers to the catalyst of a Process, used to promote, control, and influence the execution of the Process.

[0014] The edge records in the preferred phylogenetic graph have three types of temporary dependencies: used, wasGeneratedBy, and wasControlledBy; among them... Record the artifacts used by the Process; Record the source process of the Artifact; Record which agent controls the process;

[0015] For a temporary dependency T, Where r is a character label, and r∈R represents the set of character labels; This represents the relationship between node n and node n′ in a causal dependency T, specifically defined by role r. It can be used to determine whether a node n has an influence on another node n′ under a specific role r.

[0016] Dependencies are derived from the lineage chart by combining dependencies, including wasTriggeredBy, wasDerivedFrom°, and wasDerivedFrom. + and wasTriggeredBy + ;in, The used° record records which artifact originates from another artifact, as well as all artifacts that the process depends on; wasGeneratedBy° records that a process was triggered by another process; wasDerivedFrom + It records that all artifacts can be directly or indirectly derived from it; This represents all processes directly or indirectly triggered by a Process, and records all Processes prior to Artifact generation.

[0017] For Artifacts, support indicating the role of another Artifact in its creation process, tagging It 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 process uses another artifact;

[0018] Define the ownership of an Artifact, and clarify that the ownership of an Artifact derives from the ownership of the Process that generated the Artifact: Among them, wasGeneratedBy owner This indicates that the process that generated the artifact is controlled by the role "owner", where owns means ownership and owner means 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) is derived from the role tag set R, p from the process set P, and d from the workpiece set D.

[0021] Multi-step temporary dependencies This describes how one process p passes through another process p. i Indirectly using workpiece d. Where r represents the specific role involved, wasTriggeredBy + (p,p i ) indicates that p is p i Triggered directly or indirectly.

[0022] Custom temporary dependencies

[0023] Preferably, the user historical behavior verification module based on lineage data is invoked to perform path condition evaluation and derive T from the composite dependency relationship. i ; Where T j and T j These represent the temporal order of activities i and j, respectively, within the two activities T. i and T j There exists a certain used° relationship between them, which defines the association between entities n and n′ in data usage or lineage chart;

[0024] In the phylogenetic diagram, used, wasGeneratedBy, and wasControlledBy are defined to represent the relationships between data, i.e., security constraints. Among them, used indicates that an activity uses an entity, which describes the relationship between the activity and the data it depends on; wasGeneratedBy indicates that an entity is generated by an activity, which describes the causal relationship in the data generation process; and wasControlledBy indicates that an activity is controlled by an agent, which describes who is responsible for the results or actions of the activity.

[0025] The technical solution adopted by the present invention is: a blockchain-based dynamic access control method for lineage data, comprising 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 as (attribute name, key value);

[0028] Step 3: The policy decision point (PDP) loads the management policy from the policy management point (PAP). If the request lacks attributes, the policy decision point (PDP) queries the blockchain for additional information about the object.

[0029] Step 4: If the blockchain records the user who made the request and the corresponding access decision, proceed to step 8 below and output the decision; otherwise, the blockchain will return additional information to the policy decision point (PDP).

[0030] Step 5: The policy decision point (PDP) performs policy evaluation; if the policy evaluation requires path conditions, the policy decision point (PDP) sends a request to the user history behavior verification module based on lineage data; if the policy evaluation does not require path conditions, the policy evaluation result is given directly by combining the current user request and the attribute access control list.

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

[0032] Step 7: After the strategy decision point (PDP) has collected all relevant information and evaluated 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) sends an authorization request to the user; if the decision result is "no", the policy decision point (PDP) outputs an exception indicating that access is denied.

[0034] Preferably, in step 3, the strategy decision point (PDP) interacts with the blockchain, requiring the user's request time, request content, decision result, and the management strategy number on which it is based to be sent to the blockchain system's node for on-chain processing.

[0035] Preferably, the strategy decision point (PDP) mentioned in step 5 is used for strategy evaluation. First, the strategy set Pol is defined. A Query set Q A Decision set D and strategy evaluation function Given a query q and a strategy pol, Semantically, it represents the evaluation decision of pol on q, and defines D = {Permit, Deny, NA}, where Permit means permission is allowed, Deny means access is denied, and NA means access is not allowed;

[0036] Policy evaluation supports Boolean path conditions:

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

[0038] Here, `subject_organize` is the organization to which the subject belongs, `resource_id` is a unique identifier of the resource to be accessed, used to identify the specific object being accessed; `read` and `download` represent read and download operations respectively, and access (download or read operation) is only allowed if the requester's organization has contributed to the generation process of `resource_id`; `contributedTo` represents the contribution relationship of a subject `subject_organize` to the resource `resource_id`, for example, the resource may have been created, modified, or participated in by the subject; 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:

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

[0040] Among them, resourced idThe target resource in the query is represented by x; 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 based on the path conditions; dov() is used to combine policies, in which access to resource x should follow the access control policy associated with the derived resource, and if any policy denies the access request, the overall decision is to deny it.

[0041] First, the control modules (Policy Decision Point (PDP), Policy Management Point (PAP), and the blockchain) run a path matching algorithm to return all entities in the phylogenetic tree that satisfy the path query, and then retrieve and return the policies associated with these entities for evaluation.

[0042] Preferably, in step 6, under the nested strategy, the strategy decision point (PDP) can send multiple requests to the user history behavior verification module based on lineage data.

[0043] Preferably, in step 8, the evaluation function is used to obtain the verification result, with the target being a Boolean value.

[0044] Compared to existing technologies, the advantages of this invention include:

[0045] 1. This invention proposes a blockchain-based dynamic access control method for lineage data, based on the attribute-based access control paradigm (ABAC). In the lineage data module, lineage information not only serves as the basis for access decisions but also records the evolution of data during generation and derivation through a lineage data graph, supporting dynamic access control for derived objects. Specifically, this method can define access policies by combining the attributes of the data source, derivation relationships, and security constraints involved in the data fusion process within the access restrictions of derived objects, thereby ensuring that the access permissions of different participants to derived data are consistent with the security policy of the initial data source.

[0046] 2. This invention combines blockchain with an access control model, recording each user access request and return decision on the blockchain. This saves overhead for repeated queries and provides system administrators with a way to trace the source of information. By leveraging the immutability of blockchain, it provides strong evidence for monitoring users who issue requests, thereby enabling the management and reasoning of source information.

[0047] 3. This invention proposes an innovative method combining lineage data, blockchain technology, and existing access control models to achieve more granular 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. Attached Figure Description

[0048] The technical solutions of the present invention will be further illustrated below using embodiments and specific implementation methods. In addition, some accompanying drawings are used in the description of the technical solutions. Those skilled in the art can obtain other drawings and the intent of the present invention from these drawings without any creative effort.

[0049] Figure 1 This is a system schematic diagram according to an embodiment of the present invention;

[0050] Figure 2 This is a flowchart of a method according to an embodiment of the present invention. Detailed Implementation

[0051] To facilitate understanding and implementation of the present invention by those skilled in the art, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0052] This embodiment uses the Open Source Model (OPM+), where lineage data is typically represented as a labeled lineage chart to show how an object is derived. The nodes of the lineage chart can be Artifact, Process, or Agent.

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

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

[0055] Agent refers to the catalyst of a process, which is used to promote, control, and influence the execution of a process.

[0056] Furthermore, OPM+ introduces the concept of Role. A Process may generate multiple Artifacts, each with a different Role. For example, in a division operation, the Agent is the calculator program, the Process is the division operation, and two Artifacts participate in the operation, belonging to the roles of divisor and dividend. The result of the operation also contains two Artifacts, belonging to the roles of quotient and remainder.

[0057] In this embodiment, R represents the set of role tags, and N, D, P, and S refer to the sets of nodes, artifacts, processes, and agents, respectively. They have the following relationships:

[0058] N = D∪P∪S and D, P, and S do not intersect each other.

[0059] The edges of the phylogenetic graph record three types of temporary dependencies:

[0060] Record the artifacts 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 character label, and r∈R represents the set of character labels; This represents the relationship between node n and node n′ in a causal dependency T, specifically defined by role r. It can be used to determine whether a given node n has an influence on another node n′ under a specific role r.

[0064] OPM+ includes several additional dependencies that can be derived from the lineage chart through composite dependencies, as shown below:

[0065] The used° record records which Artifact originates from another Artifact, as well as all Artifacts that Process depends on.

[0066] wasGeneratedBy° records when a process is triggered by another process.

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

[0068] This represents all processes directly or indirectly triggered by a Process, and records all Processes prior to Artifact generation.

[0069] This invention extends the lineage model based on OPM+. For Artifacts, this model supports indicating the role of another Artifact in its creation process, thus marking... It 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 process uses another artifact;

[0070] This invention introduces two custom dependencies that use a specific role owner ∈R to indicate all artifacts and contributors.

[0071] Define a process that generates an artifact, whose owner owns the 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) is derived from the role tag set R, p from the process set P, and d from the workpiece set D.

[0075] Multi-step temporary dependencies This describes how one process p passes through another process p. i Indirectly using workpiece d. Where r represents the specific role involved, wasTriggeredBy + (p,p i ) indicates that p is p i Triggered directly or indirectly.

[0076] Custom temporary dependencies are represented as:

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

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

[0079] Attribute set A = {a1, ..., a n Given an attribute a∈A, V a It is a field of a.

[0080] Query q = {(a1, v1), ..., (a k ,v k)}.

[0081] A strategy can be a decision-making strategy, an objective strategy, or a combination of strategies, as defined below:

[0082] Decision strategy: Allow (1), Deny (0);

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

[0084] Composite strategy: ca(pol1,…,pol) n );

[0085] Use an evaluation function to obtain the verification result, with the target being a Boolean value: The definition is as follows: This means that if there is an association q between attributes a and v′, and the operation op(v′,v) is satisfied, i.e. v′ and the target value v satisfy the operation relationship op, then True is returned; otherwise, False is returned.

[0086] Please see Figure 1 This embodiment provides a blockchain-based dynamic access control system for lineage data, including a dynamic management access control module and a user history behavior verification module based on lineage data.

[0087] The dynamic management access control module is used to analyze user requests and evaluate authorization, including Policy Decision Point (PDP), Policy Administration Point (PAP), and blockchain.

[0088] The Policy Decision Point (PDP) is used to collect information and evaluate user access requests based on a given policy; the Policy Management Point (PAP) is used to maintain a policy repository and provide policies to the PDP to evaluate access requests; the blockchain is used to record access and decisions and provide the PDP with the information required for policy evaluation.

[0089] The user history 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 evaluation of the current request in the policy, the user history behavior verification module based on lineage data is invoked.

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

[0091] In one implementation, the lineage diagram, representing 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 mutually disjoint. The nodes in the lineage diagram are denoted as Artifact, Process, and 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; a Process can generate multiple Artifacts, each with a different role. Agent refers to the catalyst of a Process, used to promote, control, and influence the execution of the Process.

[0092] In one implementation, the user history behavior verification module based on lineage data is invoked to perform path condition evaluation and derive T from the composite dependency relationship. i ; Where T i and T j These represent the temporal order of activities i and j, respectively, within the two activities T. i and T j There exists a certain used° relationship between them, which defines the association between entities n and n′ in data usage or lineage chart;

[0093] In the genealogy diagram, used, wasGeneratedBy, and wasControlledBy are defined to represent the relationships between data, i.e., security constraints. Among them, used indicates that an activity uses an entity, which describes the relationship between the activity and the data it depends on; wasGeneratedBy indicates that an entity is generated by an activity, which describes the causal relationship in the data generation process; and wasControlledBy indicates that an activity is controlled by an agent (person or system), which describes who is responsible for the results or behavior of the activity.

[0094] Please see Figure 2 This embodiment provides a blockchain-based dynamic access control method for lineage data, comprising 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 as (attribute name, key value);

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

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

[0099] Step 4: If the blockchain records the user who made the request and the corresponding access decision, proceed to step 8 below and output the decision; otherwise, the blockchain will return additional information to the policy decision point (PDP).

[0100] Step 5: The policy decision point (PDP) performs policy evaluation; if the policy evaluation requires path conditions, the policy decision point (PDP) sends a request to the user history behavior verification module based on lineage data; if the policy evaluation does not require path conditions, the policy evaluation result is given directly by combining the current user request and the attribute access control list.

[0101] In one implementation, the policy decision point (PDP) performs policy evaluation by first defining a policy set Pol. A Query set Q A Decision set D and strategy evaluation function Given a query q and a strategy pol, Semantically, it represents the evaluation decision of pol on q, and defines D = {Permit, Deny, NA}, where Permit means permission is allowed, Deny means access is denied, and NA means access is not allowed;

[0102] Policy evaluation supports Boolean path conditions:

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

[0104] Here, `subject_organize` is the organization to which the subject belongs, `resource_id` is a unique identifier of the resource to be accessed, used to identify the specific object being accessed; `read` and `download` represent read and download operations respectively, and access (download or read operation) is only allowed if the requester's organization has contributed to the generation process of `resource_id`; `contributedTo` represents the contribution relationship of a subject `subject_organize` to the resource `resource_id`, for example, the resource may have been created, modified, or participated in by the subject; 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:

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

[0106] Among them, resourced id The target resource in the query is represented by x; 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 based on the path conditions; dov() is used to combine policies, in which access to resource x should follow the access control policy associated with the derived resource, and if any policy denies the access request, the overall decision is to deny it.

[0107] First, the control modules (Policy Decision Point (PDP), Policy Management Point (PAP), and the blockchain) run a path matching algorithm to return all entities in the phylogenetic tree that satisfy the path query. Then, they retrieve and return the policies associated with these entities for evaluation. The aim is to extend access control decisions to the source of resources, ensuring that access permissions for derived resources comply with the policy requirements of their original data, thereby maintaining data security and consistency.

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

[0109] In one implementation, in the case of nested strategies, the strategy decision point (PDP) can send multiple requests to the user history behavior verification module based on lineage data.

[0110] Step 7: After the strategy decision point (PDP) has collected all relevant information and evaluated 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) sends an authorization request to the user; if the decision result is "no", the policy decision point (PDP) outputs an exception indicating that access is denied.

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

[0113] This invention proposes an innovative method that combines lineage data, blockchain technology, and existing access control models to achieve more granular dynamic permission management. This new method not only meets the access control requirements of the Industrial Internet but also provides new ideas for future access control research.

[0114] It should be understood that the embodiments described above are only some, not all, of the embodiments of the present invention. Furthermore, the technical features of the various embodiments or individual embodiments provided by the present invention can be arbitrarily combined to form feasible technical solutions. Such combinations are not constrained by the order of steps and / or structural composition patterns, but must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0115] It should be understood that the above description of the preferred embodiments is quite detailed, but it should not be considered as a limitation on the scope of protection of this invention. Those skilled in the art, under the guidance of this invention, can make substitutions or modifications without departing from the scope of protection of the claims of this invention, and all such substitutions or modifications fall within the scope of protection of this invention. The scope of protection of this invention should be determined by the appended claims.

Claims

1. A blockchain-based dynamic access control system for lineage data, characterized in that: This 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 analyze user requests and evaluate authorization, including the policy decision point (PDP), the policy management point (PAP), and the blockchain. The Policy Decision Point (PDP) is used to collect information and evaluate user access requests based on 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 PDP with the information required for policy evaluation. The user history 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 evaluation of the current request in the policy, the user history behavior verification module based on lineage data is invoked. The user history behavior verification module based on lineage data first generates a lineage chart from the system log, then defines temporary dependency relationships, and combines the two to evaluate path queries; The lineage diagram illustrates how an object is derived. N, D, P, and S represent the sets of nodes, artifacts, processes, and agents, respectively, where N = D∪P∪S, and D, P, and S are pairwise disjoint. The nodes in the lineage diagram are denoted as Artifact, Process, and 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; a Process can generate multiple Artifacts, each with a different role. Agent refers to the catalyst of a Process, used to promote, control, and influence the execution of the Process. The edge records of a lineage graph contain three types of temporary dependencies, namely: , and ;in, Records the artifacts used by the Process; Records the source process of the Artifact; Records which agent controls the process; For a temporary dependency T, , where r is the character label, and r∈R represents the set of character labels; This represents the relationship between node n and node n′ in a causal dependency T, specifically defined by role r, and is used to determine whether a certain node n has an influence on another node n′ under a specific role r. Dependencies are derived from the lineage chart by combining dependencies, including , , and ;in, , Records the origin of one Artifact from another, as well as all Artifacts that the Process depends on; , Record when one process is triggered by another process; It records that all artifacts can be directly or indirectly derived from it; This represents all processes directly or indirectly triggered by a Process, recording all Processes prior to Artifact generation. For Artifacts, support indicating the role of another Artifact in its creation process, tagging This describes how one artifact is indirectly derived from another artifact, via wasGeneratedBy and used Composed of multiple elements; among them, wasGeneratedBy This indicates that a certain artifact was generated by a certain process, used This indicates that a certain process uses another artifact; Define the ownership of an Artifact, and clarify that the ownership of an Artifact derives from the ownership of the Process that generated the Artifact: ;in, This indicates that the process that generated the artifact is controlled by the role "owner," where "owns" means ownership and "owner" means owner. Define temporary dependencies, including basic temporary dependencies, multi-step temporary dependencies, and custom temporary dependencies; Basic temporary dependencies r comes from the set of role tags R, p comes from the set of processes P, and d comes from the set of workpieces D; Multi-step temporary dependencies It describes how one process p is passed through another process. Indirectly using workpiece d; where r represents the specific role involved. Indicates that p is Triggered directly or indirectly; Custom temporary dependencies .

2. The blockchain-based dynamic access control system for lineage data according to claim 1, characterized in that: The system invokes the user history behavior verification module based on lineage data to perform path condition evaluation and derive the path from the composite dependency relationship. ,in and Each represents an activity i and j In chronological order, in the two activities and There exists a certain... Relationships, which define entities n and n' Relationships in data usage or lineage charts; In the phylogenetic diagram, used, wasGeneratedBy, and wasControlledBy are defined to represent the relationships between data, i.e., security constraints. Among them, used indicates that an activity uses an entity, which describes the relationship between the activity and the data it depends on; wasGeneratedBy indicates that an entity is generated by an activity, which describes the causal relationship in the data generation process; and wasControlledBy indicates that an activity is controlled by an agent, which describes who is responsible for the results or actions of the activity.

3. A blockchain-based dynamic access control method for lineage data, applied to the system described in any one of claims 1-2; characterized in that, Includes the following steps: 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 management point (PAP). If the request lacks attributes, the policy decision point (PDP) queries 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, proceed to step 8 below and output the decision; otherwise, the blockchain will return additional information to the policy decision point (PDP). Step 5: The strategy decision point (PDP) performs strategy evaluation; If the strategy evaluation requires path conditions, the strategy decision point (PDP) sends a request to the user history behavior verification module based on lineage data. If the policy evaluation does not require path conditions, the policy evaluation result is given directly by combining 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 strategy decision point (PDP) has collected all relevant information and evaluated 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) sends an authorization request to the user; if the decision result is "no", the policy decision point (PDP) outputs an exception indicating that access is denied.

4. The blockchain-based dynamic access control method for lineage data according to claim 3, characterized in that: In step 3, the strategy decision point (PDP) interacts with the blockchain, requiring the user's request time, request content, decision result, and the management strategy number on which it is based to be sent to the blockchain system's nodes for on-chain processing.

5. The blockchain-based dynamic access control method for lineage data according to claim 3, characterized in that: Step 5 describes the strategy evaluation process using the strategy decision point (PDP). First, a strategy set is defined. Query set Decision set D and strategy evaluation function When a query is given and strategy , Semantic representation right The evaluation of is determined by the definition. ,in This indicates that access is permitted. This indicates that access is denied; NA means that access cannot be requested. Policy evaluation supports Boolean path conditions: ； in, "Organize" refers to the organization to which the subject belongs. It is a unique identifier for the resource to be accessed, used to identify the specific object being accessed; read and download represent read and download operations respectively, and are only used when the requester's organization has access to the resource. Access is only permitted when the user has contributed to the generation process. Indicates a certain subject organize resources The contribution relationship; 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: ； in, Represents the target resource in the query; It is a variable that represents potential input resources; Indicates whether the requested resource is derived from another resource; The function is used to retrieve resources based on path conditions. Related strategies; Used for combination strategies, in which resources are accessed. Access control policies associated with derived resources should be followed. If any policy denies access to a request, the overall decision should be to deny access. First, the control module runs a path matching algorithm to return all entities in the phylogenetic tree that satisfy the path query, and then retrieves and returns the strategies associated with these entities for evaluation.

6. The blockchain-based dynamic access control method for lineage data according to claim 3, characterized in that: In step 6, under the nested strategy, the strategy decision point (PDP) can send multiple requests to the user history behavior verification module based on lineage data.

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

Images